CN116548047A

CN116548047A - Method and device for identifying RedCAP UE

Info

Publication number: CN116548047A
Application number: CN202180081245.XA
Authority: CN
Inventors: 戴安娜·玛马里; 布莱恩·克拉松; 菲利普·萨特瑞; 维普尔·德赛
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-12-07
Filing date: 2021-12-06
Publication date: 2023-08-04

Abstract

A User Equipment (UE) may determine whether to indicate to a gNB whether the UE is a reduced capability (RedCap) UE during a Random Access (RA) procedure or after the RA procedure based on a criterion, and indicate whether the UE is the RedCap UE during the RA procedure or after the RA procedure according to a determination result. The RedCap UE has fewer receive branches or a smaller bandwidth than a non-RedCap UE. The gNB may determine whether a first message received during the RA procedure indicates that the UE is the RedCap UE. When the first message indicates that the UE is the RedCap UE, the gNB sends a second message to the UE using a coverage recovery technique during the RA procedure. When the first message does not indicate that the UE is the RedCap UE, the gNB determines whether the UE is the RedCap UE after the RA procedure is completed.

Description

Method and device for identifying RedCAP UE

The present patent application claims the priority of the multipath identification of "RedCap UE (Multipath Identification of RedCap UEs)", U.S. provisional application No. 63/122,414 and the multipath identification of "RedCap UE (Multipath Identification of RedCap UEs)", U.S. provisional application No. 63/250,751, filed on month 9 and 30 of 2021, filed on 7 of 12/2020, the contents of which are incorporated herein by reference as if fully set forth herein.

Technical Field

The present disclosure relates generally to telecommunications and, in particular embodiments, to techniques and mechanisms for identifying reduced capability (reduced capability, redCap) User Equipment (UE).

Background

The third generation partnership project (third generation partnership project,3 GPP) has been developing and standardizing several important features of the fifth generation (5G) new air interface (NR) access technology. In RAN #86 (3 GPP RP-201677, 7 of 2020), rel-17 approves a new Study Item (SI) intended to support reduced capability (reduced capability, redCap) NR devices (e.g. User Equipment (UE)). The RedCap UE is an NR entity that serves a relatively low-end service (relatively low end service), but requires a very long battery life unlike a typical cellular UE, e.g., the RedCap UE may have. The RedCap UE can be used in at least three different scenarios: industrial sensors, video monitoring and wearable devices. It is desirable to develop mechanisms that facilitate communication by the RedCap UE.

Disclosure of Invention

Technical advantages are generally achieved by embodiments of the present disclosure, which describe techniques and mechanisms for identifying reduced capability (reduced capability, redCap) User Equipment (UE).

According to an aspect of the present disclosure, there is provided a method comprising: a User Equipment (UE) determining, based on a criterion, whether during a Random Access (RA) procedure of the UE or after the RA procedure, to indicate to a gNB whether the UE is a reduced capability (reduced capability, redCap) UE having fewer receive branches than a minimum receive branch number of a non-RedCap UE or having a bandwidth less than a minimum bandwidth of the non-RedCap UE; and the UE indicates the UE to the gNB as the RedCAP UE according to the determination result.

Alternatively, in any of the above aspects, the non-RedCap UE is a legacy UE (also referred to as legacy UE).

Optionally, in any of the above aspects, the RedCap UE has one or two receiving branches.

Optionally, in any of the above aspects, the minimum number of reception branches of the non-RedCap UE is 4 for frequency range 1 (frequency range 1, fr 1) and 2 for frequency range 2 (frequency range 2, fr 2).

Optionally, in any one of the above aspects, the indication comprises: when determining to indicate during the RA procedure, the UE sends to the gNB a first message indicating that the UE is the RedCap UE during the RA procedure, the first message including message 1 (message 1, msg 1) of the RA procedure, message3 (message 3, msg 3) of the RA procedure, or message a (message a, msgA) of the RA procedure.

Optionally, in any one of the above aspects, the method further comprises: prior to the RA procedure, the UE determines the first message based on a radio resource control (radio resource control, RRC) configuration broadcast by the gNB and received by the UE prior to the RA procedure.

Optionally, in any aspect above, the RRC configuration includes information of the criterion.

Optionally, in any of the above aspects, the first message is sent by the UE according to a physical random access channel (physical random access channel, PRACH) configuration broadcast by the gNB and received by the UE prior to the RA procedure, the PRACH configuration including a RACH preamble (RACH preamble), a RACH occasion (RACH occision), or a combination thereof, associated with the indicating RedCap UE.

Optionally, in any one of the above aspects, the method further comprises: the UE receives a message 2 (message 2, msg 2) or a message 4 (message 4, msg 4) from the gNB during the RA procedure according to the received coverage recovery technique.

Optionally, in any one of the above aspects, the first message is Msg1, the method further comprising: and the UE repeatedly sends the Msg3 to the gNB.

Optionally, in any one of the above aspects, the number of repetitions of the transmission of the Msg3 is based on a RACH configuration.

Optionally, in any of the above aspects, the transmitting of the Msg3 is repeated when a reference signal received power (reference signal received power, RSRP) measurement of the UE is less than a threshold.

Optionally, in any one of the above aspects, the indication comprises: when determining to indicate after the RA procedure, the UE sends UE capability information to the gNB indicating that the UE is the RedCap UE after the RA procedure is completed.

Optionally, in any of the above aspects, the criterion is based on a number of received branches of the UE, a reference signal received power (reference signal received power, RSRP) measured by the UE, a reference signal received quality (reference signal received quality, RSRQ) measured by the UE, a reference signal strength indication (reference signal strength indicator, RSSI) measured by the UE, or a combination thereof.

Optionally, in any of the above aspects, the criterion is based on a capability of the UE.

Optionally, in any one of the above aspects, the determining includes: when the UE has two reception branches, the UE determines to indicate the UE as the RedCap UE after the RA procedure; or when the UE has one receive branch, the UE determines to indicate the UE as the RedCap UE during the RA procedure.

Optionally, in any one of the above aspects, the determining includes: when the UE has two receive branches and is operable in frequency range 1 (FR 1) or FR2, the UE determines to indicate that the UE is the RedCap UE after the RA procedure; when the UE has one receive branch and is operable under FR1 or FR2, the UE determines to indicate that the UE is the RedCap UE during the RA procedure; or when the UE has two receive branches and is operable under FR1, the UE determines to indicate that the UE is the RedCap UE during the RA procedure.

Optionally, in any one of the above aspects, the determining includes: the UE compares the RSRP measured value with a threshold configured for the RedCAP UE; when the RSRP measurement value is greater than the threshold value, the UE determines to indicate the UE as the RedCap UE after the RA procedure; or when the RSRP measurement value of the UE is less than or equal to the threshold, the UE determines to indicate that the UE is the RedCap UE during the RA procedure.

Optionally, in any one of the above aspects, the determining includes: the UE compares the RSRP measured value with a threshold configured for the RedCAP UE; when the UE has two receive branches and the RSRP measurement value is greater than the threshold, the UE determines to indicate that the UE is the RedCap UE after the RA procedure; when the UE has two receive branches and the RSRP measurement of the UE is less than or equal to the threshold, the UE determines to indicate the UE as the RedCap UE during the RA procedure; or when the UE has one receive branch, the UE determines to indicate the UE as the RedCap UE during the RA procedure.

Optionally, in any one of the above aspects, the determining includes: the UE compares the RSRP measured value with a threshold configured for the RedCAP UE; when the UE has one receive branch and the RSRP measurement value is greater than the threshold, the UE determines to indicate the UE as the RedCap UE after the RA procedure; when the UE has one receive branch and the RSRP measurement value is less than or equal to the threshold, the UE determines to indicate the UE as the RedCap UE during the RA procedure; or when the UE has two reception branches, the UE determines to indicate the UE as the RedCap UE after the RA procedure.

According to another aspect of the present disclosure, there is provided a method comprising: the gNB receives a first message from a User Equipment (UE) during a Random Access (RA) procedure; the gNB determining whether the first message indicates that the UE is a reduced capability (reduced capability, redCAP) UE having fewer receive branches than a minimum receive branch of a non-RedCAP UE or having a bandwidth less than a minimum bandwidth of the non-RedCAP UE; when the first message indicates that the UE is the RedCap UE, the gNB sends a second message to the UE during the RA procedure according to a coverage recovery technique; when the first message does not indicate that the UE is the RedCap UE, the gNB determines whether the UE is the RedCap UE after the RA procedure is completed.

Optionally, in any of the above aspects, the non-RedCap UE is a legacy UE.

Optionally, in any of the above aspects, the minimum number of reception branches of the non-RedCap UE is 4 for frequency range 1 (FR 1) and 2 for frequency range 2 (FR 2).

Optionally, in any aspect above, the first message includes message 1 (Msg 1) of the RA procedure, message 3 (Msg 3) of the RA procedure, or message a (MsgA) of the RA procedure.

Optionally, in any of the above aspects, the first message is based on a physical random access channel (physical random access channel, PRACH) configuration broadcast by the gNB, the PRACH configuration including a RACH preamble associated with an indication RedCap UE, a RACH occasion, or a combination thereof.

Alternatively, in any of the above aspects, the second message is message 2 (Msg 2) of the RA procedure, or message 4 (Msg 4) of the RA procedure.

Optionally, in any one of the above aspects, the method further comprises: the gNB receives from the UE capability information indicating that the UE is the RedCap UE after the RA procedure is completed.

Optionally, in any one of the above aspects, the method further comprises: the gNB broadcasts information of criteria to the UE, the criteria enabling the UE to determine whether to indicate to the gNB whether the UE is the RedCap UE during or after the RA procedure based on the criteria.

Optionally, in any of the above aspects, the criterion is based on a number of received branches of the UE, a reference signal received power (reference signal received power, RSRP) measurement of the UE, a reference signal received quality (reference signal received quality, RSRQ) measurement of the UE, a reference signal strength indication (reference signal strength indicator, RSSI) of the UE, or a combination thereof.

Optionally, in any one of the above aspects, the criteria include: when the UE has two reception branches, indicating the RedCap UE after the RA procedure; or indicating the RedCap UE during the RA procedure when the UE has one receiving branch.

Optionally, in any one of the above aspects, the criteria include: when the UE has two receive branches and is operable in frequency range 1 (FR 1) or FR2, the RedCap UE is indicated after the RA procedure; when the UE has one receive branch and is operable under FR1 or FR2, the RedCap UE is instructed during the RA procedure; or indicating the RedCap UE during the RA procedure when the UE has two receive branches and is operable under FR 1.

Optionally, in any one of the above aspects, the criteria include: indicating the RedCap UE after the RA procedure when the RSRP measured by the UE is greater than a threshold; or indicating the RedCap UE during the RA procedure when the RSRP measured by the UE is less than or equal to the threshold.

Optionally, in any one of the above aspects, the criteria include: when the UE has two receive branches and the RSRP measured by the UE is greater than a threshold, indicating the RedCap UE after the RA procedure; indicating the RedCap UE during the RA procedure when the UE has two receive branches and the RSRP measured by the UE is less than or equal to the threshold; or indicating the RedCap UE during the RA procedure when the UE has one receiving branch.

Optionally, in any one of the above aspects, the criteria include: when the UE has one receiving branch and the RSRP measured by the UE is greater than a threshold, indicating the RedCap UE after the RA procedure; indicating the RedCap UE during the RA procedure when the UE has one receive branch and the RSRP measured by the UE is less than or equal to the threshold; or when the UE has two reception branches, indicating the RedCap UE after the RA procedure.

Optionally, in any one of the above aspects, the method further comprises: the gNB broadcasts information indicating that the gNB supports a RedCAP UE.

According to another aspect of the present disclosure, there is provided an apparatus comprising: a non-transitory memory comprising instructions; one or more processors in communication with the memory, wherein the instructions, when executed by the one or more processors, cause the apparatus to perform the method of any of the above aspects.

According to another aspect of the present disclosure, there is provided a non-transitory computer readable medium storing computer instructions which, when executed by one or more processors of an apparatus, cause the apparatus to perform the method of any of the above aspects.

According to another aspect of the present disclosure, there is provided a system including a User Equipment (UE) and a gNB; wherein the UE is configured to perform the following operations: determining, based on a criterion, whether during a Random Access (RA) procedure of the UE or after the RA procedure, to indicate to the gNB that the UE is a reduced capability (reduced capability, redCap) UE having fewer receive branches than a minimum receive branch number of a non-RedCap UE or having a bandwidth less than a minimum bandwidth of the non-RedCap UE; indicating to the gNB that the UE is a RedCAP UE according to a determination result; wherein, the gNB is used for executing the following operations: receiving a first message from the UE during a Random Access (RA) procedure; determining whether the first message indicates that the UE is the RedCap UE; when the first message indicates that the UE is the RedCap UE, sending a second message to the UE during the RA procedure according to a coverage recovery technique; when the first message does not indicate that the UE is the RedCap UE, determining whether the UE is the RedCap UE after the RA procedure is completed.

Aspects of the present disclosure enable a RedCap UE to identify that the RedCap UE is a RedCap during or after an RA procedure (early identification) and enable a mix of RedCap UE identifications (e.g., some RedCap UEs may perform early identification and some RedCap UEs may perform normal identification). This enables the network to take measures to compensate for loss of link budget of the RedCap UE in communication with the network, improving communication reliability and user experience.

Drawings

For a more complete understanding of the present disclosure and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

FIG. 1 shows a diagram of an embodiment of a wireless communication network;

fig. 2 is a diagram of a 4-step (4-step) random access procedure according to 3gpp ts 38.300;

fig. 3 is a diagram of a 2-step (2-step) random access procedure according to 3gpp ts 38.300;

fig. 4 is a diagram of an embodiment of a communication network highlighting an example coverage area (coverage area) and the antenna/branch number of a UE;

fig. 5 is a diagram of an embodiment of operations of a UE for reduced capability (reduced capability, redCap) indication;

FIG. 6 is a diagram of an embodiment of operations based on path selection for criteria C1 indicated by RedCAP;

FIG. 7 is a diagram of an embodiment of operations for detecting a gNB of a RedCAP UE;

FIG. 8 is a diagram of an embodiment of operations based on path selection for criteria C4 indicated by RedCAP;

FIG. 9 is a diagram of an embodiment of a RedCAP UE-indication method;

FIG. 10 is a diagram of another embodiment of a RedCAP UE detection method;

FIG. 11 is a block diagram of an embodiment of a processing system;

fig. 12 shows a block diagram of a transceiver; and

fig. 13 is a block diagram of an electronic device.

Corresponding reference numerals and characters in the various figures generally refer to corresponding parts unless otherwise indicated. The drawings are drawn to clearly illustrate the relevant aspects of the embodiments and are not necessarily drawn to scale.

Detailed Description

The making and using of the embodiments of the present disclosure are discussed in detail below. It should be understood, however, that the concepts disclosed herein may be embodied in a wide variety of specific contexts and that the specific embodiments discussed herein are merely illustrative and do not limit the scope of the claims. Further, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the disclosure as defined by the appended claims.

Reduced capability (reduced capability, redCap) User Equipment (UE) may suffer from performance degradation due to the use of complexity reduction features/techniques (complexity reduction feature/technique). The RedCap UE may be a UE having a number of receive branches less than a minimum number of receive branches of a non-RedCap UE, a bandwidth less than a minimum bandwidth of a non-RedCap UE, and/or other reduced capabilities. To compensate for the performance degradation, an overlay recovery technique (coverage recovery technique) may be used, such as repetition, low modulation and coding scheme (modulation and coding scheme, MCS) tables, and/or Transport Block (TB) scaling. Because the gNB is unaware of the presence of the RedCAP UE before the UE accesses the gNB, applying these coverage recovery techniques may rely on identifying or indicating that the UE is a RedCAP UE. If the gNB can know early if the UE is a RedCAP UE, the gNB can use one or more of these techniques to improve the performance of the RedCAP UE.

Embodiments of the present disclosure provide mechanisms that enable a RedCap UE to identify itself during a Random Access (RA) procedure (referred to as early identification) or after an RA procedure (referred to as normal identification). Thus, embodiments may enable a mix of RedCap UE identities, e.g., some RedCap UEs may perform early identity and some RedCap UEs may perform normal identity. This provides flexibility for the RedCap UE to determine when to identify itself and enables the network to utilize coverage recovery techniques to improve the communication performance of the RedCap UE.

According to one embodiment, the UE may determine whether to indicate to the gNB whether the UE is a RedCap UE during or after an RA procedure of the UE based on criteria, and then indicate to the gNB that the UE is a RedCap UE according to the determination result. For example, the UE may indicate itself as a RedCap UE in message 1, message 3, or message a in the RA procedure, or indicate itself as a RedCap UE in message 5 after the RA procedure.

According to another embodiment, the gNB may receive the first message from the UE during the RA procedure and determine whether the first message indicates that the UE is a RedCAP UE. When the first message indicates that the UE is a RedCap UE, the gNB may send a second message to the UE according to the coverage recovery technique during the RA procedure. When the first message does not indicate that the UE is a RedCap UE, the gNB may determine whether the UE is a RedCap UE after the RA procedure is completed.

Fig. 1 shows a network 100 for transmitting data. The network 100 includes a base station 110 having a coverage area 101, a plurality of mobile devices 120, and a backhaul network 130. As shown, the base station 110 establishes an uplink (dashed line) connection and/or a downlink (dotted line) connection with the mobile device 120 for carrying data and control information from the mobile device 120 to the base station 110 and vice versa. The data carried on the uplink/downlink connection may include data communicated between the mobile devices 120, as well as data communicated to/from a remote location (not shown) via the backhaul network 130. As used herein, the term "base station" refers to any component (or collection of components) for providing wireless access to a network, such as an enhanced base station (enhanced base station, eNB), macrocell, femtocell, wi-Fi Access Point (AP), or other wireless-enabled device. The base station may provide wireless access according to one or more wireless communication protocols, such as long term evolution (long term evolution, LTE), LTE-advanced (LTE-a), high speed packet access (high speed packet access, HSPA), wi-Fi 802.11a/b/g/n/ac, and the like. As used herein, the term "mobile device" refers to any component (or collection of components) capable of establishing a wireless connection with a base station, such as a User Equipment (UE), mobile Station (STA), and other wireless-enabled devices. In some embodiments, network 100 may include various other wireless devices, such as repeaters, low power nodes, and the like.

Fig. 2 is a diagram of a 4-step random access procedure of fig. 9.6.2-1 according to 3gpp ts 38.300. The overall contention-based random access (contention based random-access, CBRA) procedure in Rel-15 is a four-step procedure, including sending a random access preamble (message 1 (Msg 1)) at a PRACH occasion (PRACH occalation), receiving a Random Access Response (RAR) message (message 2 (Msg 2)) in a physical downlink shared channel (physical downlink shared channel, PDSCH) scheduled by a physical downlink control channel (physical downlink control channel, PDCCH), sending message 3 (Msg 3) in a physical uplink control channel (physical uplink control channel, PUSCH), and receiving message 4 (Msg 4) in the PDCCH, the PDSCH being scheduled by DCI in the PDCCH for contention resolution (contention resolution). Before the UE attempts to access the network, the UE may need to synchronize (in time and frequency) to the downlink and receive the master information block (master information block, MIB) and one or more system information blocks (system information block, SIBs) over the physical broadcast channel (physical broadcast channel, PBCH) and PDCCH/PDSCH. After receiving the SIB (mainly SIB 1), the UE knows the configuration and transmission parameters of the physical random access channel (physical random access channel, PRACH). The random access procedure or procedure may be referred to as RACH or RA procedure/procedure.

To reduce the delay, a two-step procedure of the Random Access (RA) procedure is standardized in Rel-16 and is shown in fig. 3. A description of the two-step process in TS38.300 is reproduced below:

the "2-step RA type MSGA includes a preamble on PRACH and a payload (payload) on PUSCH. After MSGA transmission, the UE monitors for a response from the network within a configured window. For CFRA, dedicated preamble and PUSCH resources are configured for MSGA transmission, and after the UE receives the network response, the random access procedure is ended, as shown in fig. 9.2.6-1 (d). For CBRA, if contention resolution is successful after receiving a network response, the UE ends the random access procedure as shown in fig. 9.2.6-1 (b); if a back-off indication is received in the MSGB (fallback indication), the UE uses the UL grant scheduled in the back-off indication for MSG3 transmission and monitors for contention resolution, as shown in fig. 9.2.6-2. If contention resolution fails after the MSG3 (re) transmission, the UE returns to the MSGA transmission. "

That is, during a two-step RA procedure, the UE sends a message a (MsgA) to the gNB, where MsgA includes a preamble on PRACH and a payload on PUSCH. The gNB sends a message B (MsgB) as a response. Essentially, msgA can be considered to be equivalent to sending Msg1 and Msg3 together, and MsgB to be equivalent to Msg2 and Msg4.

In RAN #86 (3 GPP RP-201677, 7 of 2020), a new Study Item (SI) was approved, aimed at supporting reduced capability (reduced capability, redCap) NR devices (e.g. User Equipment (UE)). SI includes the following objectives:

"identify and study potential UE complexity reduction features:

UE RX/TX antenna count reduction

UE bandwidth reduction

It should be noted that: rel-15 SSB bandwidth should be reused and L1 variation minimized

Half duplex-FDD

Relaxed (related) UE processing time

Loose UE processing capability. "

A RedCap UE is an NR entity that provides relatively low-end services, but its requirements/features are different from typical cellular UEs (non-RedCap UEs). For example, the battery life of a Redcap UE may be very long. A RedCap UE may refer to a UE having a number of receive (Rx or Rx) branches that is less than the minimum number of receive branches of non-RedCap UEs, a bandwidth that is less than the minimum bandwidth of non-RedCap UEs, and/or other reduced capabilities. non-RedCAP UE may refer to a UE having the minimum requirements for the UE specified in Rel 15 and Rel 16 (3 GPP TS38.306, (16 th edition), release 16-2, 2020-10-02). non-RedCap UEs may also be referred to as legacy UEs or normal UEs. For example, the minimum received branch number for a non-RedCap UE is 4 for frequency range 1 (FR 1) and 2 for frequency range 2 (FR 2). The RedCap UE may have one or two receive branches. For another example, for FR1 frequency division duplex (frequency division duplex, FDD) or FR2 bands, where a non-RedCap UE needs to be equipped with at least 2 Rx branches, the minimum number of Rx branches supported by the RedCap UE is 1. The work item description (work item description, WID) also shows that the RedCap UE supports 2 Rx branches. For another example, for FR1, a RedCap UE may have a maximum bandwidth of 20MHz, for FR2, a maximum bandwidth of 100MHz, and for FR1 and FR2, a non-RedCap UE may have minimum bandwidths of 100MHz and 400MHz, respectively. For another example, a RedCap UE may have a maximum number of DL multiple-input multiple-output (MIMO) layers (e.g., a RedCap UE with one Rx branch may have at most one MIMO layer, and a RedCap UE with two Rx branches may have at most two MIMO layers). As another example, the RedCap UE may have a reduced maximum modulation order (256 QAM in DL is optional). The RedCap UE may support Half Duplex (HD) -FDD type a.

A receive branch (receive branch) may have one or more receive antennas. The receive branch is associated with a receive chain. Typically, for FR1, each branch has one physical antenna. In this case, the number of branches is equal to the number of antennas. For FR2, multiple physical antenna (beam forming) signals are typically combined in each branch. In this case, there may be multiple antennas per branch, for example 64 antennas.

For a reduced number of UE antennas/branch characteristics in SI, in 3gpp TR 38.875, clause 7.2.4, V0.1.0, "technical specification group radio access network; the following are obtained in a study (Technical Specification Group Radio Access Network; study on support of reduced capability NR devices) "(version 17) 2020-11-25 supporting reduced capability NR devices:

"typically, a RedCap UE with reduced number of Rx branches may coexist with a legacy UE. However, if some broadcast channels are used for both legacy UEs and RedCap UEs, the presence of the RedCap UE with reduced number of Rx branches may affect the performance of the legacy UE. This is because if there is no early indication of the RedCap UE, the network would consider the legacy UE and the RedCap UE to be the same, which may result in conservative treatment of all UEs. "

In the scenario studied in SI, it was observed that for a RedCap UE with 2 RX branches, no compensation for Msg2/Msg4 on the Downlink (DL) is required, whereas for a RedCap UE with 1 RX branch, up to 6dB of compensation may be required, as described below. Thus, early identification/indication of a RedCap UE with 1 RX branch is advantageous, so that Msg2/Msg4 can be transmitted using appropriate radio parameters due to the 1 RX branch performance limitations. That is, the RedCap UE may indicate or identify to the network (e.g., the gNB) that it is a RedCap UE at an early stage of accessing the network. However, it should be noted that for a RedCap UE with 2 RX branches, such early identification/indication may not be required (or may be rarely required).

Coverage extension analysis of initial access (Coverage extension analysis)

The use of complexity reduction techniques and features may result in coverage being affected, possibly due to frequency diversity loss (due to having less bandwidth) and/or receive branch reduction (diversity loss (loss of diversity) and/or spatial multiplexing (spatial multiplexing)).

The RedCap UE considers a variety of coverage recovery assessment scenarios during the random access procedure. Consider the scenario of FR1 and FR 2. The frequency range 1 (FR 1) spans about 600MHz to 7.25GHz and FR2 spans about 24.25GHz to 47GHz. The link budget for several channels and messages was evaluated for the following example scenario: FR1 city 4GHz (scenario 1), FR1 city 2.6GHz (scenario 2), FR2 indoor (scenario 3).

For example, it is estimated that for all FR1 scenarios, it may be necessary to compensate PUSCH (including Msg 3) for 3dB link budget loss due to small form factor. It is also estimated that for urban 4GHz scenario 1, when the receive branch number is 1, msg2 may require 5dB to 6dB compensation and Msg4 may require 2dB to 3dB compensation. When the RedCap UE has one receive antenna, the amount of compensation required for the channels and messages for urban 4GHz scenario 1 is summarized in table 1 below. Some channels and messages may require coverage recovery.

TABLE 1

Channel/message	Compensation quantity dB
		Msg2	5-6
PUSCH/Msg3	3
		Msg4	2-3
PDCCH	1

The following was observed:

_– it is estimated that successful detection of PUSCH/Msg3 at the base station may require 3dB (due to small form factor (small form factor)) compensation because UE transmit power may be incorrect (e.g., using minimum power control).With small physical dimensions, the distance between the two receiving branches may be close to half a wavelength. Therefore, it is difficult to obtain 3dB gain from the receive diversity (receive diversity). Another factor is that the estimation of the downlink power may be less accurate at small physical dimensions, which affects the transmit power of Msg1 and Msg 3. In order to successfully detect PUSCH/Msg3, the UE may need to compensate for the loss by using coverage compensation techniques (e.g., repetition). The application of any technique may depend on identifying the UE as a RedCap UE. In other words, the gNB may need to know that the UE is a RedCap UE early in the RACH procedure.

_– It is estimated that in case of a RedCap UE with one receive branch, a coverage loss of 5dB to 6dB may be required for successful detection of the Msg2 random access response (random access response, RAR). Thus, it is necessary to identify/indicate early in Msg1 that the UE is a RedCap UE, which will help the gNB know when to apply the coverage recovery technique to the identified RedCap UE in the downlink. This may also help the gNB optimize resources for both the RedCap UE and the normal (legacy) UE (which may not need any coverage enhanced UEs).

Table 2 below shows that urban 4GHz scenario 1 requires coverage restored channels and messages when the RedCap UE has 2 Rx branches. When the number of reception branches is 2, as shown in table 2, coverage recovery is not required for Msg2, msg4, and PDCCH. That is, for FR1 including FDD and TDD bands, and for the RedCap UE having 2 Rx branches and reduced antenna efficiency, it is shown that the maximum isotropic loss (maximum isotropic loss, MILs) of all downlink channels is better than the maximum isotropic loss of the bottleneck channel of the reference NR UE, and the downlink channels of the RedCap UE do not need coverage recovery.

TABLE 2

Channel/message	Compensation quantity dB
		Msg2	0
PUSCH/Msg3	3
		Msg4	0
PDCCH	0

Table 3 below shows the performance degradation of the UE from using 4 Rx branches to 2 Rx branches and from using 4 Rx branches to 1 Rx branch, which is based on the simulation study of urban scenarios in 3GPPTR 38.875V0.1.0 (release 17). CSS represents the common search space (common search space) and USS represents the UE-specific search space (UE-specific search space).

TABLE 3 Table 3

Messages involved in RACH procedure/procedure should not be coverage limited in order to achieve successful uplink synchronization (uplink synchronization) and to obtain authorization of the initial connection (initial attachment), but this may occur for the RedCap UE due to the complexity reduction feature/technique. To compensate for this loss, an overlay recovery technique may be used. For example, repetition, low modulation and coding scheme (modulation and coding scheme, MCS) tables and/or Transport Block (TB) scaling may be used to compensate for losses due to reduced complexity. Discussion about the coverage restoration technique is not within the scope of the present disclosure. Because the gNB does not know any presence of the RedCap UE before the UE accesses the gNB, applying these coverage restoration techniques may rely on identifying or indicating that the UE is a RedCap UE. If the gNB can know if the UE is a RedCAP UE early in the RACH procedure, the gNB can use one or more of these techniques to improve the performance of the RedCAP UE.

Furthermore, it should be noted that although coverage limitations are discussed herein, other aspects are contemplated. For example, a UE may have coverage but require a large amount of resources to transmit a message. In this case, attention is required to waste of resources. As another example, a 5dB to 6dB penalty (penalty) from Msg2 may be handled by always using a repetition factor of 4. However, in this case, the overhead is huge (due to repetition), and it is better from the resource efficiency point of view to compensate only the UEs that really need compensation.

Early identification scheme discussed in RedCap SI

In 3gpp TR 38.875, v0.1.0, the following options identified by the RedCap UE are discussed:

"feasibility, necessity, advantage and disadvantage of the following RedCap UE identification scheme has been studied:

_– option 1: during Msg1 transmission

_– For example, by separate initial UL BWP, separate PRACH resources or PRACH preamble partitioning

_– Option 2: during Msg3 transmission

_– Option 3: issue Msg4 acknowledgement.

_– For example during Msg5 transmission or during part of the UE capability reporting. "

A fourth option for the two-step RA procedure (two-step RACH) was also initially considered, but the priority of this option was cancelled during SI.

During the study, it was determined that all 3 of the options described above were viable. For example, identification in Msg1 may be achieved by providing (e.g., by configuration information, by standardization in a specification, or by SIB) a PRACH preamble or a timing in time or frequency associated with the RedCap UE. The identification may be in the same initial bandwidth part (BWP) or in a separate initial BWP. Similarly, recognition in Msg3 is also possible.

If the performance of the RedCap UE is worse than that of a normal (legacy, non-RedCap) UE, this early identification allows the RedCap UE and the normal UE to be treated differently, rather than requiring all UEs (RedCap and normal) to be treated conservatively because there may be a RedCap UE. Poor performance may be due to complexity reduction features such as fewer receive branches, or due to antenna performance loss with small form factor.

Initial access of LTE-M device

In Rel-13, the network indicates support for long term evolution machine type communication (long term evolution-machine type communication, LTE-M) devices by transmitting PDSCH indications for SIB1 in the MIB. Initial access for machine type communication (machine type communication, MTC) devices is specified in 3gpp TS 36.213 and 36.331. The RACH procedure of the LTE-M device has much commonality with the conventional LTE RACH procedure and the protocol/exchanged messages are identical.

MTC UEs do not formally identify themselves as MTC devices until their UE category (UE category) is transmitted. However, some MTC UEs are limited in coverage. Thus, the RACH preamble (Msg 1) and MPDCCH/PDSCH (Msg 2 and Msg 4) may be repeated multiple times. Different coverage levels (also referred to as coverage extension (coverage extension, CE) levels) are defined based on reference signal received power (reference signal received power, RSRP) and are defined in the RSRP-threshprachinfolist information element (information element, IE) specified in TS 36.331v16.2.1, as shown in table 4 below.

TABLE 4 Table 4

According to TS 36.331v16.2.1, the existing PRACH-Config of Rel-12 was amplified to include RSRP-ThresholdsPrachInfoList, as shown in Table 5 below.

TABLE 5

Furthermore, the RACH-ConfigCommon also includes a new IE, RACH-CE-LevelInfoList, which is a list of RACH-CE-LevelInfo according to TS 36.331, v16.2.1, as shown in Table 6 (RACH-CE-LevelInfoList-r 13) below.

TABLE 6

/>

The RACH-CE-leveinfo contains the physical parameters for each UE at a given CE level expected by RACH, as shown in table 7 below:

TABLE 7

As shown in TS 36.331, all these IEs are nested in SIBs.

In this way, a normal (legacy) UE may be made to share the PRACH region with the best-conditioned (RSRP) LTE-MUE in terms of channel gain conditions.

When the base station receives Msg1, the UE of a given CE level is identified as LTE-M UE. The UE selects the appropriate preamble according to RSRP. The base station does not know the required coverage enhancement until Msg1 is received. The network is unaware of the presence of the LTE-M device until Msg1 is received in the configured uplink resources. However, the following aspects need to be explained:

early identification from the selected RACH resources determined by the UE based on RSRP.

UEs of different CE levels are identified at Msg1, but there is no case where MTC UEs are identified at Msg1 and other UEs are identified at Msg 5: such a procedure is practically impossible to implement in the current LTE framework because the base station needs to monitor the MTCUE occupying a limited number (6) of PRBs. Therefore, the MTC UE needs to be identified at Msg1 in order to be able to correctly receive Msg2.

Embodiments of the present disclosure provide mechanisms for a UE to identify itself as a RedCap UE either by Msg5 (or late UE capability exchange (capability exchange)) or by early identification (e.g., at Msg 1). That is, at the same time, the gNB may provide a configuration such that some of the RedCAP UEs are identified early, while other of the RedCAP UEs are identified at a later stage (as opposed to identifying all of the RedCAP UEs at the same time-whether early or not). Some RedCap UEs may have similar identities (using the current initial access procedure) as normal UEs until a capability exchange in which these RedCap UEs will be identified as RedCap UEs, while other RedCap UEs may be identified in Msg1 or Msg3 phases. For the latter case, additional capacity exchange may be performed after Msg5 (or at Msg 5) after the RA procedure.

The proposed RedCap UE identification scheme may mix the identifications (some at early stages-either Msg1 or Msg3, and others at Msg 5) compared to the dedicated initial access procedure of LTE-M devices. It should be noted that the present solution does not exclude the use of dedicated resources.

In some embodiments, the RedCap UE types may be defined (the types may differ based on, for example, the number of receive antennas, supported bandwidth, or a combination thereof), and in this case, different types of RedCap UEs may be processed along separate paths (i.e., at different stages of the RACH procedure) depending on when the identification occurs. In this case, the gNB can avoid the need to identify all UEs at Msg5, and can also avoid the need to identify all UEs at Msg1 or Msg 3. With such a scheme, optimization can be based on the RedCap UE type. In one embodiment, the RedCap UE type is defined based on the number of receive antennas/branches or supported bandwidth or both the RedCap UE has.

As used herein, for convenience of description, identifying or indicating that the UE is a RedCap UE may be referred to as an identification or indication of the RedCap UE, or an identification or indication of the UE. The identification or indication of the RedCap UE before the completion of the random access procedure (or during the random access procedure), e.g. in the Msg1, msg3 or MsgA phase, may be referred to as early identification or indication, or identification or indication at an early stage. For ease of description, the identification or indication of the RedCap UE during the capability exchange after completion of the random access procedure (as conventionally performed) may be referred to as a late (or conventional, or standard) identification or indication, or a late stage identification or indication. In the following description, unless otherwise specified, the term "path" is used to indicate a way or manner of indicating/identifying a UE as a RedCap UE, for example, by early identification/indication or later identification/indication. The terms "identify UE" and "indicate UE" are used interchangeably. Hereinafter, for convenience of description only, the "Redcap UE having n Rx branches" may be referred to as "nRXRedCap UE", "nRX UE" or "UE having nRX", where n is an integer greater than 0.

In some embodiments, two paths (i.e., path a and path B) are defined for indicating that the UE is a RedCap UE:

Path a: during Msg5 (capability exchange), the UE is identified as a RedCap UE. One or more of the UE capabilities/features/feature sets of the UE may be used to identify the UE as a RedCap UE. This may be achieved by using a dedicated UE capability (e.g., defining a feature, such as a RedCap UE), or by a set of existing and/or new UE capabilities (e.g., UE bandwidth, number of antennas, etc.). In this case, the gNB knows that the UE is a RedCap UE when some UE features are selected from a given set of combinations (e.g., BW of 20MHz, 1 RX antennas).

Path B: the UE was identified as RedCap prior to Msg 5. This may be done, for example, during transmission of Msg1, msgA or Msg 3. The UE may inform the network implicitly (e.g., by using a preamble/resource selection for transmitting Msg 1) or explicitly (e.g., by setting 1 bit in Msg 3) that it is a RedCap UE.

Path a corresponds to a later identification or indication and path B corresponds to an earlier identification or indication. Path B may also be referred to as an early path. Path a may also be referred to as a normal, late, or normal path. In the above, the path a is associated with Msg5, and the path B is associated with Msg1, msg3, or MsgA.

Fig. 4 is a diagram of an embodiment of a communication network 400 highlighting example coverage areas and antenna/branch numbers of UEs. As shown, the network 400 includes a gNB 410, the gNB 410 having a coverage area 412 for UEs with one Rx branch and a coverage area 414 for UEs with two Rx branches. Each of the RedCap UEs 422 and 424 has one Rx branch. Each of the RedCap UEs 426 and 428 has two Rx branches. UEs 422 and 426 in coverage area 412 and UE 428 in coverage area 414 may use path a to indicate that they are RedCap UEs. UE 424 in coverage area 414 may use path B to indicate that it is a RedCap UE.

In some embodiments, a criterion (criterion) may be defined for the UE to select/determine whether to use path a or path B to identify the RedCap UE. Example criteria (C) C1 and C2 are provided below:

c1: the choice of path a or path B is based on the number of receive antennas of the RedCap UE:

UE with 2RX (2 RX antennas/branches) uses path a

UE with 1RX (1 RX antenna/branch) uses path B

C2: the selection of path a or path B is based on the number of receive antennas and duplex mode of the RedCap UE:

UE with 2RX uses path a under FR1 FDD and FR2

UE with 1RX uses path B under FR1 FDD and FR2

UE with 2RX using path B under FR1 TDD

According to criterion C1, the UE may indicate that it is a RedCap UE after the RA procedure when the UE has two reception branches, and may indicate that it is a RedCap UE during the RA procedure when the UE has one reception branch.

According to criterion C2, when the UE has two reception branches and is operable in the FR1 FDD band and the FR2 band, it may be indicated after the RA procedure as a RedCap UE. When the UE has one reception branch and is operable in FR1 FDD and FR2 bands, it may be indicated during the RA procedure as a RedCap UE. When the UE has two reception branches and is operable in the FR1 TDD band, it may be indicated during the RA procedure as a RedCap UE. It should be noted that: FR2 is currently defined as TDD. The above criteria C1 and C2 are defined according to the number of Rx antennas. The RedCap UE may support operation in one or more frequency bands. However, it should be noted that, depending on the WID target, the RedCap UE is not allowed to operate at two or more frequencies at the same time. In this case, the appropriately modified criterion C2 may also be applicable. For example, C2 may change to designate a UE usage path a having 2RX when the UE is operable in FR1 FDD or FR2, and a UE usage path B having 1RX when the UE is operable in FR1 FDD or FR 2. Thus, the implementation of the embodiment criteria for path selection may vary depending on whether the RedCap UE is allowed to operate in one or more frequency bands. Those of ordinary skill in the art will recognize that various modifications, alternatives, and embodiments of the criteria may be applied to the UE selection of a path for identifying it as a RedCap UE without departing from the spirit and principles of the present disclosure.

In some embodiments, the criteria may be defined based on bandwidth or frequency band. For example, for a first frequency band (or first frequency bands), e.g., a bandwidth greater than 20mhz, the RedCap UE may use an early indication, and for a second frequency band (or second frequency bands), e.g., a bandwidth no greater than 20mhz, the RedCap UE may indicate itself as a RedCap UE during a capability exchange (Msg 5).

In some embodiments, criteria may also be defined based on one or more other parameters, such as parameters indicative of wireless channel conditions, including RSRP (before or after antenna combining (antenna combining)), reference signal received quality (reference signal received quality, RSRQ), reference signal strength indication (reference signal strength indicator, RSSI), and the like. For example, possible criteria C3 may be:

c3: the selection of path a or path B is based on RSRP after antenna combining:

UE using path a for omicron RSRP > threshold

UE usage path B of O RSRP less than or equal to threshold value

In general, the estimated signal quality may be performed separately for each branch, and the highest signal quality may be used. The signal quality estimation may also be based on two or more branches, wherein the signals from the antennas/branches are combined. For example, the estimation of the received power may be based on the sum of the estimated values of each branch (in the linear domain). In one specific example, one RSRP estimate is-80 dBm, a second RSRP estimate is-83 dBm, and the combined estimate is-78.2 dBm.

According to criterion C3, the UE may compare the RSRP measurement value with a threshold configured for the RedCap UE for identification. When the RSRP measurement value is greater than the threshold, the UE indicates that it is a RedCap UE after the RA procedure. When the RSRP measurement of the UE is less than or equal to the threshold, the UE indicates that it is a RedCap UE during the RA procedure.

C3 has a single threshold for the UE. In some embodiments, the UE may select or modify a single threshold provided based on its type (RedCap type as described above) or capabilities, assuming that the difference between the different thresholds does not naturally appear on the RSRP metric that the UE uses to determine which path to use. For example, if the RSRP measurement is 3db, the rx antenna number is doubled, multiple thresholds may not be needed. However, for other measurements (e.g., RSRP measured on only one antenna), a factor may be added to the threshold. Or, alternatively, correction based on small form factor dB may be performed on the threshold.

The threshold may be associated with a coverage area. For example, the "coverage area 412 of a UE with 1 RX antenna" in fig. 4 may be associated with a first threshold, and the "coverage area 414 of a UE with 2 RX antennas" in fig. 4 may be associated with a second threshold. UEs in coverage areas 412 and 414 may use the corresponding thresholds to determine paths for the indication of the RedCap UEs. For C3, the measurement of RSRP may be defined, for example, based on measurements performed on SSB blocks, or measurements performed on demodulation reference signals (demodulation reference signal, DMRS) of PDCCH. Those skilled in the art will recognize that various measures of RSRP may be applied to embodiments of the present disclosure.

Fig. 5 is a flow chart 500 of an operational embodiment of a UE. The UE may obtain path selection criteria (block 502). The UE needs to know the path selection criteria, e.g. C1, C2 or C3. There are several possibilities for the UE to obtain the path selection criteria. In one embodiment, the standard specification may specify which path the UE uses. For example, for C1, the UE behavior may be hard coded in a standard specification, e.g., "RedCap UE with one receive antenna recognizes itself during Msg1 or Msg 3. "this may indicate that C1 or C2 will be used by the UE. In one embodiment, the UE may be preconfigured with which path the UE uses for the RedCap UE indication. For example, which path to use may be indicated in a SIB or other signaling message. For example, for C3, the network/base station may indicate the RSRP threshold in the SIB. This may indicate that C3 is to be used by the UE. The network may implicitly or explicitly signal which criteria are to be used to identify the RedCap UE.

The UE may obtain a path configuration (block 504). The UE needs to know a) if there is more than one path, and B) the configuration of path B. For a), there may be a case where one path (e.g., path a) is configured. For example, in a dense deployment scenario where the gnbs are close to each other, it is expected that even a RedCap UE with only one RX antenna would be sufficient to communicate with the gnbs without CE measures. Thus, the parameters in the SIB may indicate whether only one path is configured. Based on the configuration of b), the signaling may also be explicit. For b), in this example, the UE needs to acquire a resource configuration for early identification. For example, if identification is made during Msg1/MsgA or Msg3, the RedCap UE needs to know which parameters (time resource/PRB/preamble) will be used for early indication. The signaling that can be used is similar to that for LTE-M devices with different CE levels. In general, the path configuration may include information on available paths to be used, RACH configuration (time-frequency resources and/or preambles) for early indication, and/or information indicating whether path B is performed during Msg1 or Msg3 or MsgA.

The UE may determine/select a path to use (block 506). When the RedCap UE obtains all relevant RACH configuration parameters, the RedCap UE needs to determine which path to use. In some cases, this operation is trivial, and no operation needs to be performed (e.g., for C1, the RedCap UE knows the number of antennas it owns, and the RedCap UE can directly select the corresponding path). However, in some cases, it is determined that additional operations are required. For example, for C3, the RedCap UE needs to perform RSRP measurements to select a path.

The UE may identify itself as RedCap based on the selected path (block 508). When a path is selected, the RedCap UE continues according to the selected path. For example, if path a is selected, the UE may not need to do any special operations and may only send its capabilities (indicating whether it is a RedCap UE) during a capability exchange after the RACH procedure. If path B is selected, which may indicate an identification during Msg1, for example, the RedCap UE needs to select a set of resources (time resource/PRB/preamble index) indicated/configured by the gNB for early identification (path B).

Fig. 6 is a diagram 600 of an operational embodiment of path selection based on criteria C1. The UE (RedCap UE) may obtain a path configuration from the SIB (block 602). The path configuration may be similar to that described in block 504 of fig. 5. The UE may then check if it has one Rx antenna (block 604). When the UE has more than one Rx antenna, the UE may perform conventional identification (block 606), i.e., path a. That is, the UE may identify itself as a RedCap UE after the RACH procedure, e.g., during capability exchange between the UE and the network. When the UE has one Rx antenna, the UE may perform early identification (block 608), i.e., path B. That is, the UE may identify that it is a RedCap UE during the RACH procedure, e.g., during transmission of Msg1, msg3, or MsgA.

Fig. 7 is a diagram 700 of an operational embodiment of a gNB. The gNB may check whether it supports a RedCAP UE (block 702). If the gNB does not support the RedCAP UE, the gNB may block (bar) the RedCAP UE (block 704). In this case, the gNB may not serve the RedCap UE. If the gNB supports the RedCAP UE, it may be checked whether the gNB supports coverage recovery (block 706). If the gNB does not support coverage recovery, the gNB may detect the RedCAP UE according to path A (block 708). That is, the gNB may know that the UE is a RedCap UE based on the indication/identification performed according to path a. If the gNB supports coverage recovery, the gNB may provide parameters for coverage recovery to the UE (block 710). The gNB may perform early detection (block 712). That is, the gNB may detect during the RACH procedure of the UE whether the UE indicates/recognizes that it is a RedCap UE, e.g., in Msg1, msg3, or MsgA (according to path B). If the gNB does not detect any indication/identification from the UE during early detection (from path B), the gNB may detect the UE from path A (block 714), i.e., the gNB detects the RedCap UE after the RACH procedure. If the gNB detects an indication/identification from the UE during early detection, the gNB may apply coverage recovery means (coverage recovery means) to communicate with the UE (block 716). For example, if the UE indicates in Msg1, the gNB may apply the coverage recovery means for all DL transmissions after receiving Msg1 during the RACH procedure. If the UE is indicated in Msg3, the gNB may apply the coverage recovery means for all DL transmissions after receiving Msg3 during the RACH procedure. If the UE is indicated in the MsgA, an overlay recovery means may be applied to transmit the MsgB to the UE. The UE may apply the received coverage recovery techniques to receive these DL transmissions. In the uplink, the UE may repeat transmitting the message during the RA procedure. When both the UE and the network support Msg3 repetition, the UE may repeat transmission of Msg3 according to a repetition configuration. Msg3 may also be retransmitted based on HARQ processes, which may result in greater latency.

For the FR1 TDD band where a normal UE uses 4RX branches, the 2RX RedCap UE and the 1RX RedCap UE have different behavior from the normal UE (e.g., because of the fewer number of branches), so making the 2RX UE use the normal path may require some conservative treatment for the RedCap UE and the non-RedCap UE. The Redcap UE and the non-Redcap UE may be differentiated based on frequency bands. In this case, identification of the RedCap UE can be done in the above-described framework using criteria of RX antenna number (1, 2 or 4) as an input parameter and frequency band. Based on the indication, the network may take action to compensate for the communication with the RedCap UE. If FR1 TDD uses criterion C1, the 2Rx UE may use the normal path with conservative handling. This may not be the case for other frequency bands.

In some embodiments, a RedCap UE operable in the FR1 TDD band identifies itself from the normal path or may configure/indicate the early path through SIB configuration. For example, SIB configurations may be broadcast to include path selection criteria and parameters for different paths. For another example, the gNB may only add one field in the SIB to indicate the path to use (e.g., always use path B). Similarly, for a RedCap UE operating in the FDD band, where 4RX is mandatory for legacy UEs, a SIB may be broadcast to instruct the UE to determine the path configuration and path selection criteria for the path.

In some embodiments, as described in C3, the UE may consider instantaneous channel conditions (e.g., channel conditions represented by RSRP after antenna combining) to determine which path to use. In one embodiment, the RedCap UE may identify it as a RedCap UE using the normal path if the channel condition is within a threshold configured for the normal path. Thus, if a 2 RX-bearing RedCap UE is in a particularly bad condition, the 2 RX-bearing RedCap UE may be accessed like a 1RX UE, while if a 1RX UE is in a particularly good condition, the 1RX UE may be accessed like a 2RX UE.

In some embodiments, criteria for the RedCap UE to select a path may be defined such that one of the 1RX RedCap UE or the 2RX RedCap UE may select a path. Such an example criterion C4 is provided below:

c4: for a UE with 2RX antennas, the selection of path a or path B is based on RSRP after antenna combining:

UE with 2RX antennas and RSRP > threshold value uses path a

UE with 2RX antennas and RSRP +.threshold value uses path B

UE with 1RX antenna using path B

Or:

c5: for a UE with 1RX antenna, the selection of path a or path B is based on RSRP after antenna combining:

UE with 1RX antenna and RSRP > threshold value uses path a

UE with 1RX antenna and RSRP ∈threshold value uses path B

UE usage path a with 2RX antennas

In the above criteria (C4 and C5), the use of the threshold selection path is based on the RedCap UE characteristics. One RedCap UE feature is that the UE has 2RX antennas and another RedCap UE feature is that the UE has 1RX antenna. For example, in C4, only 2Rx RedCap UEs are allowed to use RSRP thresholds to select paths, while 1Rx UEs are not allowed to use RSRP. The 1Rx UE always uses path B, i.e. early identification.

The principle of C4 is that even 1RX UEs are in good channel conditions, it may be desirable to prohibit them from using the normal path to prevent too many UEs from using the normal path and initial access resources, such as PRACH preambles. C5 is similar in principle. In an example, semi-static partitioning of RACH resources between path a and path B may be possible without having to consider the individual radio conditions of each RedCap UE.

In C5, only the RedCap UE with 1Rx is allowed to select paths using RSRP threshold, where the UE can be identified at an early stage or at a later stage. The 2Rx UE always uses path a.

In all of these example criteria above, the gNB may have a RedCAP UE that satisfies different criteria and may be identified at different stages. For example, some RedCap UEs may be identified at an early stage (early identification), while other RedCap UEs may be identified at a later stage. After identifying the RedCap UE via path a or path B, the full capability exchange may be performed at a later stage (e.g., at Msg 5).

Fig. 8 is a diagram 800 of an operational embodiment of path selection based on criteria C4. The UE (RedCap UE) may obtain a path configuration from the SIB (block 802). The path configuration may be similar to that described in block 504 of fig. 5. The UE may then check whether it has two Rx antennas and whether the RSRP measurement is greater than a threshold (block 804). When the UE has two Rx antennas and the RSRP measurement is greater than the threshold, the UE may perform conventional identification (block 806), path a. When the UE does not have two Rx antennas or the RSRP measurement is not greater than the threshold, the UE may perform early identification (block 808), i.e., path B. This example may be combined with the example shown in fig. 6, where the 1Rx RedCap UE always uses early identification.

In the above embodiment, two paths are described. However, it should be noted that more than two paths may be defined. For example, three paths may be defined that correspond to recognition by Msg1, msg3, and Msg5, respectively. The UE may determine which path to use to identify it as a RedCap UE, e.g., based on network configuration or criteria. In this case, when multiple (more than two) paths are available, the selection of paths may be based on many different embodiments, considerations, and/or factors. For example, the selection may be:

Based on a threshold (e.g. RSRP)

Based on UE implementation (e.g., UE knows about own antenna defect (antenna imperfection))

Traffic-based (e.g., the UE knows its subscription or other information of normal communication after RRC connection)

In the case where there are a "high end" wearable device and a "low end" wearable device, the criteria for selecting the path may be based on the type of wearable device. For example, the high-end wearable device may use path a and the low-end wearable device may use path B.

Although embodiments of the present disclosure are described with respect to a RedCap UE, these embodiments are applicable to other scenarios, such as: low-end smartphones, "regular" UEs requiring coverage extension, industrial sensors, etc.

Embodiments of Msg5 identification (i.e., the RedCap UE recognizes it as RedCap at Msg5 (during capability exchange), i.e., path a) are described below. In the following description, msg5 recognition may also be referred to as Msg5 path recognition.

The RedCap identifies that there are different paths, one of which is a typical Msg5 after RACH procedure or later UE capability exchange, where the UE informs the gNB of its characteristics, which may include indicating or identifying that it is a RedCap UE. This approach does not actually require any standard modifications other than the RedCap feature. In one embodiment, the Msg5 path identification may be used to identify a RedCAP UE with 2 Rx antennas. In another embodiment, a RedCap UE with 1 Rx antenna but with very strong channel gain conditions (e.g., RSRP greater than RSRP threshold) may also use Msg5 path identification. This recognition path may be combined with other recognition paths through Msg1 or Msg3, as described later in this disclosure.

An embodiment of Msg1 identification (i.e., the RedCAP UE identifies it as a RedCAP at Msg1 (during the RACH procedure), path B) is described below. As described above, one possible way to identify the RedCap UE is through early path identification, e.g. during transmission of Msg1 by the RedCap UE. The configuration of this path may be provided in the SIB. For example, identification in Msg1 may be achieved by providing (e.g., by configuration information, by specifying a standard specification or in a SIB) a PRACH preamble or an opportunity in time or frequency associated with the RedCap UE. These may be in the same initial BWP or in separate initial BWP. Early path recognition may be performed in the same or separate initial UL BWP as that used for normal recognition. Information about the initial BWP may be broadcast in the SIB. RACH configurations associated with different initial UL BWP may be different.

In an example, the PRACH configuration may be broadcast in a SIB, wherein the PRACH configuration includes information for identifying the RedCap UE using path B. For example, the PRACH configuration may include information associated with indicating/identifying the PRACH preamble, RACH occasion, or a combination thereof associated with the RedCap UE. Other messages during the RACH procedure, such as Msg3 or MsgA, may also be used for early identification of the RedCap UE, as described above. Which of Msg1, msg3 or MsgA is to be used for early identification may be configured by radio resource control (radio resource control, RRC) configuration. The RRC configuration may be broadcast by the gNB.

Upon receiving the SIB, the UE will know PRACH configuration and transmission parameters, such as one or more of the following:

the PRACH preamble format,

the time-frequency resources of the system,

parameters for determining root sequence,

cyclic shift in PRACH preamble sequence set, or

Index of logical root sequence table (logical root sequence table), unrestricted association set type (associate set type), restricted type a or type B.

According to TS 38.331, v16.2.0, for a normal NR UE, the time domain position of the PRACH preamble is determined by the RRC parameters PRACH-configuration index and the frequency domain resources of the PRACH preamble are determined by the RRC parameters msg1-FDM and msg 1-FrequencyStart.

In one embodiment, a RedCap UE using early path identification (e.g., a RedCap UE with 1Rx or a RedCap UE with 2Rx but RSRP < threshold) may have a separate PRACH configuration (also referred to as RACH configuration) information element, e.g., RACH-ConfigGeneric-RedCap information element, that is different from a normal UE, where the RACH configuration information element specifies a RedCap random access parameter, such as a suffix indication. In this information element, the frequency and time resources may be indicated by the parameters prach-configuration index-redcap, msg1-FDM-redcap, and msg 1-FrequencyStart-redcap. Other configuration designations may include v17 and/or the abbreviation rc (RedCap), and are not limited to the examples described above. The RedCap UE PRACH (or RACH) configuration is not limited to time, frequency location, but may also include periodicity of resources, subcarrier offset, number of subcarriers, maximum number of preamble transmissions and power ramp step size, starting slot number, number of slots, etc. Thus, the RedCap UE may receive a different configuration from the normal UE for early identification, or the RedCap UE may use a later stage for identification as the normal UE.

In another embodiment, the same RACH-ConfigGeneric information element may include PRACH configurations for a RedCap UE identified at a later stage (by Msg 5) and a RedCap UE identified at an earlier stage (e.g., by Msg 1). In another embodiment, the PRACH resources may be non-overlapping for different types of RedCap UEs to be identified at different phases, in which case there may be information elements of different types of UEs for configuring the indication of the RedCap UEs.

In another embodiment, the gNB may indicate that a RedCap UE with 2 Rx (which may not need coverage compensation) may use a legacy PRACH configuration, while a RedCap UE with 1Rx may use a different PRACH configuration. In yet another embodiment, the resources for the RedCap UE (to be identified at an early stage) may be specified according to an offset from the resources configured for the normal UE. The offset may be a time-frequency resource offset. It should be noted that the individual configuration is not limited to the time-frequency resource location configuration, but may include all other configurations related to the RACH procedure, such as different preambles.

Table 8 below provides an example embodiment of a configuration IE. In this example, individual general PRACH resources (italics) are configured for the RedCap UE performing early identification. The RedCap UE does not use the PRACH configuration of the normal UE, but uses a separate PRACH configuration.

TABLE 8

/>

In another embodiment, if the RedCap UE is to use early-identified paths based on criteria (e.g., C3, C4, C5) for using the threshold, a threshold is defined. In one embodiment, the threshold may be defined using an rsrp-threshold PrachInfoList-r17 IE. Different coverage levels may be defined based on RSRP and in information elements. The RACH-ConfigGeneric IE may be amplified to include the rsrp-ThresholdsPrachInfoList-r17 IE. In another embodiment, the RACH-ConfigCommon IE may be amplified to include an rsrp-Threshold PrachInfoList-r17 IE.

In another embodiment, the network may also configure a set of preambles that are dedicated for use by the RedCap UE to be identified at Msg 1. These preambles may have different properties than preambles configured for normal UEs. The attributes that may be different may include one or more of sequence type, cyclic shift, etc.

Different sets of preambles may be defined. In one embodiment, two sets of preambles are defined, with or without a threshold, one set configured for UEs to be identified early and the other set configured for UEs to be identified later.

After identifying the RedCap UE PRACH resources by the PRACH configuration, the UE may send a PRACH preamble (random access preamble) to the gNB (at PRACH occasion) accordingly. The gNB may calculate an RA-RNTI associated with a RACH occasion (RACH timing, RO) for transmitting the random access preamble, and the parameters for calculating the RA-RNTI may include time and frequency resources of the transmission preamble as indicated by the prach-configuration index-redcap, msg1-FDM-redcap, and msg 1-FrequencyStart-redcap. Since the RedCap UE may require multiple transmissions of the preamble (e.g., for uplink coverage enhancement), the RedCap UE may be configured with a configuration that includes the maximum number of repetitions allowed, e.g., in the SIB. This number may be related to the coverage enhancement level.

In the second step of the RACH procedure (see fig. 2), the UE waits for a random access response from the gNB after PRACH preamble transmission. The random access response (random access response, RAR) may be sent by DCI scrambled with an RA-RNTI value. The UE may attempt to detect a PDCCH (i.e., DCI) with a corresponding RA-RNTI within a period of RA-ResponseWindow. In another embodiment, a RedCap UE with 1Rx (or a RedCap UE with 2Rx and poor channel gain conditions (e.g., RSRP less than threshold)) may be configured with a separate period ra-ResponseWindow-RedCap different from a normal UE for monitoring DCI.

Although the criteria for path selection may be configured using the configuration received in the SIB, as described above, the criteria may also be obtained in the technical specification. For example, the specification may specify that a RedCap UE with 2Rx branches operating in a particular band supporting at least 2Rx branches of a non-RedCap UE may identify itself using path a, while a 1Rx RedCap UE may identify itself using path B. Furthermore, the use of path a by the 2Rx RedCap UE may also be determined based on whether some RAN4 performance requirements are met. For example, a 2RX UE with very small form factor and poor reception performance may use path B due to antenna correlation.

In some embodiments, if the UE uses Msg1 for early identification, other steps in, for example, a 4-step random access procedure may consider the following.

In some examples, to receive Msg2 (or Msg 2), the UE may receive an associated PDCCH (associated with Msg 2) using a downlink coverage enhancement technique (downlink coverage enhancement technique) (or downlink performance compensation technique (downlink performance compensation technique)) of the associated PDCCH. The following may be considered:

if there is a dedicated PDCCH for early identification, then:

the UE may receive PDSCH carrying Msg2 through one or more coverage enhancement techniques, which may be signaled through DCI within the PDCCH

_– Downlink coverage enhancement techniques may include, for example, TB scaling (TB scaling), repetition, and/or low MCS levels

_– It should be noted that when coverage enhancement is applied, the timing of RACH (e.g., msg3 transmission) may change

If there is no dedicated PDCCH for early identification, then:

the omicron UE may receive PDSCH using one or more downlink coverage enhancement techniques provided by SIB configurations

_– It should be noted that when downlink coverage enhancement is applied, the timing of RACH may change

In some examples, to send Msg3 (or Msg 3) when Msg1 performs early recognition, some options may include:

Transmitting Msg3 without changing the RAR UL grant, i.e. using the UL grant received in the RAR

Modifying RAR UL grants (e.g., by using TB scaling, different MCS levels, and/or repetition)

Augmenting RAR UL grants using SIB configuration (e.g., performing uplink coverage enhancement, such as Msg3 repetition based on SIB configuration)

In some examples, to receive Msg4 (or Msg 4) when Msg1 performs early identification, a base station (e.g., gNB) may reuse techniques for transmitting Msg2 PDCCH to schedule Msg4. Since the base station has a better knowledge of the UE (which the UE recognizes as a RedCap UE at Msg 1), the base station can use the configured parameters to transmit PDCCH of Msg4. It is noted that in this regard, the base station may use a temporary RNTI dedicated to the UE instead of the RA-RNTI. The signaling is now "mostly" dedicated, since the temporary RNTI is dedicated to that particular UE, PDSCH scheduling may be more appropriate for that UE.

An embodiment of Msg3 identification (i.e., the RedCap UE identifies Msg3 (during RACH procedure) as RedCap, i.e., path B) is described below. As described above, msg3 can also be used for early identification of the RedCap UE. This early identification enables the RedCap UE and the normal UE to be treated differently if the performance of the RedCap UE is worse than the normal UE, rather than requiring all UEs (RedCap and normal) to be treated conservatively because there may be a RedCap UE.

In one embodiment, one or more bits in Msg3 may be used to identify the RedCap UE that is passing through the early identified path. In the NR RACH procedure, RACH-ConfigCommon is used to configure Msg3 related parameters, such as the transform precoder in RACH-ConfigCommon. In one embodiment, one bit in Msg3 may be used to explicitly identify the UE as a RedCap UE. In another embodiment, if the Msg3 size exceeds a certain threshold, bits of another field of Msg3 (e.g., a transform precoder field) may be used to identify the UE as a RedCap UE. Table 9 below shows an example RACH-ConfigCommon IE including msg3-transform precoder (msg 3-transform precoder, italics).

TABLE 9

/>

In one embodiment, separate information elements, which function similarly to RACH-ConfigCommon functions but have different values configured for the RedCap UEs, may be used for RedCap configuration purposes to provide configuration information for the RedCap UEs to be identified at an early stage.

The gNB receives Msg3 and is therefore able to identify the RedCapUE based on Msg3 and the configuration used. Msg3 may be sent by the UE using the coverage recovery technique. After knowing that Msg3 is transmitted using the coverage recovery technique, the gNB can correctly detect Msg3 and can also transmit Msg4 for the RedCap UE using the downstream coverage recovery technique (e.g., repeat Msg4 several times and/or use a low MCS value, or TB scaling).

Coverage enhancement (coverage enhancement, CE) is described below.

Msg3 repetition is an optional feature of non-RedCap UEs. Traditionally, msg3 repetition can be used to provide uplink coverage enhancement for transmitting Msg3 by non-RedCap UEs. Msg3 may be transmitted repeatedly (multiple times) by the UE during the RACH procedure. Msg3 repetition may be referred to hereinafter as "CE feature". The gNB may configure a non-RedCAP UE that may be used to perform RACH occasions (RACH occisions, RO) and/or preambles for Msg3 repetitions. In an example, if the measured RSRP is less than a threshold, the non-RedCap may perform Msg3 repetition for coverage enhancement.

The early indication may be configured by the gNB as mandatory features/capabilities of the RedCap UE. In this case, for the RedCap UE, it is mandatory to identify itself as the RedCap UE at an early stage (path B) during the RACH procedure, for example at Msg1, msg3 or MsgA. When the size of the non-RedCap UL BWP is equal to or greater than the size of the RedCap UE UL BWP, the RedCap UE may use or configure the early indication. The main reason for using the early indication in this case is to provide a more efficient resource allocation (or effective size BWP) for the RedCap UE and the non-RedCap UE during the RA procedure (wherein the non-RedCap UE may use a wider BWP during the RA procedure).

If desired, the Msg3 repetition can also be used for the RedCap UE (according to WID) with minor modifications. Even though this feature (Msg 3 repetition) may be useful for all RedCap UEs, this feature (Msg 3 repetition) may be optional for the RedCap UEs. To apply Msg3 repetition, the UE may need to send Msg1 using the appropriate RACH resources. In an example, msg1 may be used to indicate that the UE is a RedCap UE (early indication). Msg1 may also be used to indicate that this CE feature is to be applied (or Msg3 repetition is to be performed). In another example, msg1 may be repeated and Msg3 may be used for early indication of RedCap.

The gNB may need to divide the preamble/RO into four groups/regions if it is desired to support CE characteristics (Msg 3 repetition) for all UE types (non-RedCAP UE and RedCAP UE): (RedCap, non-RedCap) x (Msg 3 repeat, no Msg3 repeat) (see table 10 below).

Table 10

UE type	No Msg3 repeat	Msg3 repeat
			RedCap	RACH1	RACH2
non-RedCAP	RACH3	RACH4

In table 10 above, RACHi represents the ith RACH configuration, each of which may include one or more preambles, one or more ROs, or a combination thereof. The number of groups/regions is the number of RACH configurations. Each RACH configuration provides a configuration of Msg1 transmissions. According to table 10, four RACH configurations, RACH1 to RACH4, may be configured, corresponding to four different UE feature combinations, respectively: a RedCap UE without an Msg3 repetition, a RedCap UE with an Msg3 repetition, a non-RedCap UE without an Msg3 repetition, and a non-RedCap UE with an Msg3 repetition.

However, how to divide the resources may require the UE to do excessive operations, and thus rules may need to be defined for the UE to determine which RACH configuration to use. Another problem is that the number of preambles and RACH resources are limited.

In the first embodiment, when no early indication is configured for the RedCap UE, both the RedCap UE and the non-RedCap UE may use RO/preambles defined by CE characteristics with a threshold. That is, when a threshold (e.g., RSRP < threshold) is met, both the RedCap UE and the non-RedCap UE may perform Msg3 coverage enhancement using the defined RO/preamble. The same threshold may be used for both the RedCap UE and the non-RedCap UE, or separate thresholds may be used for the RedCap UE (e.g., if complexity reduction features are to be considered). For example, the UE (RedCap or non-RedCap) may perform Msg3 repetition when the RSRP measurement is less than a threshold. For another example, threshold 1 is configured for non-RedCap UEs and threshold 2 is configured for RedCap UEs. In this case, the non-RedCap UE may perform Msg3 repetition when the RSRP measurement value is less than the threshold value 1, and the RedCap UE may perform Msg3 repetition when the RSRP measurement value is less than the threshold value 2. Table 11 below shows the RACH configuration of the first embodiment. As shown, two RACH configurations are required, RACH1 and RACH2, corresponding to two categories: a UE without an Msg3 repetition and a UE with an Msg3 repetition. When the RSRP measured value of the UE is greater than the threshold, the UE transmits Msg1 according to RACH1 without repeating Msg 3. When the RSRP measured value of the UE is smaller than the threshold value, the UE transmits Msg1 according to RACH2 and repeats Msg 3.

TABLE 11

UE type	No Msg3 repeat	Msg3 repeat
			RedCap	RACH1	RACH2
non-RedCAP	RACH1	RACH2

In some embodiments, a RedCap UE with certain characteristics (e.g., a RedCap UE with a 1Rx branch (or a 2Rx branch) in a frequency band requiring a 4Rx branch for a non-RedCap UE) may be allocated to a non-repetition region (e.g., a RedCap UE with 2 Rx) (i.e., RACH1 in table 11) or a repetition region (e.g., a RedCap UE with 1Rx branch) (i.e., RACH2 in table 11).

A combination of UE characteristics and thresholds may also be used. For example, a RedCap UE and a non-RedCap UE having 2Rx branches with RSRP above a threshold may use a normal RO (i.e., RACH 1), or a RedCap UE having 1Rx branch with RSRP below a threshold may use a CE RO (i.e., RACH2 in table 11). The use of the repetition area (for Msg 3), i.e. RACH2 in table 11, would require the UE to support the CE feature.

It should be noted that if this CE feature (Msg 3 repetition) is mandatory for the RedCap UE, then the CE feature (Msg 3 repetition) may be considered to be similar to the form of the early indication, but not the only one. For example, if Msg3 repetition is mandatory for a RedCap UE, the network knows that the RedCap UE supports Msg3 repetition, and that the RedCap UE can use Msg3 repetition (if the conditions are met, e.g., as shown in tables 10 and 11). In addition, the number of repetitions used in Msg3 can be used by the network to distinguish between RedCap UEs and non-RedCap UEs. The Msg1 resource indicating CE may be requested by the RedCap UE or may be requested by a non-RedCap UE. If the number of repetitions is also unique to both the RedCap UE and the non-RedCap UE, the base station may count the number of repetitions of Msg3 received to identify whether the message is from the RedCap UE or the non-RedCap UE. If the repetition number is not unique, the base station cannot use the repetition number to distinguish between the RedCap UE and the non-RedCap UE. For example, a non-RedCap UE may use {1,2} repetition, while a RedCap UE uses {4} repetition to provide an early indication form. The symbol { x } is the number of allowed Msg3 repetitions. If the number of repetitions between non-RedCap UE and RedCap UE has a common value, e.g., {1,2} for non-RedCap UE and {2,4} for RedCap UE, then when two (2) Msg3 repetitions are received at the base station, the UE types may not be distinguishable. That is, the base station may not know whether 2 Msg3 repetitions were transmitted by the RedCap UE or the non-RedCap UE. The RedCap UE may not configure a separate UL BWP. For example, both types of UEs (RedCap and non-RedCap) share the same UL BWP, e.g., bandwidth, location, under the constraints of the UL BWP of the RedCap UE.

In a second embodiment, early indication and Msg3 repetition feature may be configured for a RedCap UE, where non-RedCap UE and RedCap UE use the same region (same RACH configuration) for Msg3 repetition (thus, there are 3 regions (RACH 1-3) in this example). The following table 12 shows RACH configuration of the second embodiment. When using Msg3 repetition, the non-RedCAP UE and the RedCAP UE transmit Msg1 according to RACH 2. When Msg3 repetition is not used, the RedCAP UE transmits Msg1 according to RACH1, and the non-RedCAP UE transmits Msg3 according to RACH 3.

Table 12

In this example, the non-RedCap UE may send Msg3 repetition in the same UL BWP as the RedCap UL BWP, even though the uniqueness of the early indication is impaired because the RedCap UE and the non-RedCap UE use the "same RACH configuration" (e.g., channel conditions are poor because RSRP is less than a threshold). non-RedCap UEs can still efficiently transmit Msg3. Similar to the first embodiment described above, the threshold value used to determine whether to perform Msg3 repetition may be different for a RedCap UE and a non-RedCap UE. It is not possible to use the repetition number to distinguish between the different characteristic RedCap UEs (e.g. RedCap UEs with one Rx branch always use repetition), since in this case embodiment 2 is simplified to embodiment 1. One limitation of this embodiment is that because the RedCap UE and the non-RedCap UE use the same RACH configuration (RACH 2), the RedCap UE and the non-RedCap UE share the same initial UL BWP during initial access. Thus, there may be no separate BWP for both the RedCap UE and the non-RedCap UE with repetition.

In the third embodiment, the early indication and the Msg3 repetition CE feature may be configured for the RedCap UE, and when Msg3 repetition is not performed but repeated using different areas (different RACH configurations), the non-RedCap UE and the RedCap UE use the same non-repeated area (RACH configuration) (thus, the present example has a total of 3 areas). The following table 12 shows RACH configuration according to the third embodiment. When Msg3 repetition is not used, the non-RedCap UE and the RedCap UE transmit Msg1 according to RACH 1. When using Msg3 repetition, the RedCAP UE transmits Msg1 according to RACH2, and the non-RedCAP UE transmits Msg1 according to RACH 4.

TABLE 13

UE type	No Msg3 repeat	Msg3 repeat
			RedCap	RACH1	RACH2
non-RedCAP	RACH1	RACH4

The third embodiment may be less attractive, e.g. a non-RedCap UE in good condition (e.g. RSRP above threshold and thus not using Msg3 repetition) needs to follow the RedCap BW limit (same RACH 1). Furthermore, if a RedCap UE does not support the CE feature of Msg3 repetition, it is similarly treated as a non-RedCap UE according to the "same RACH configuration" regardless of its condition with respect to the threshold or supported feature. The same embodiments as described in the first embodiment, for example, the threshold value, may be applied. Because the early indication may be performed by the RedCap UE, this scheme may cause the RedCap UE and the non-RedCap UE to repeat a different number of times (support 1, 2, 4, and possibly 8 repetitions). This is reasonable because the branches of the RedCap UE are fewer, and the number of repetitions allowed for the RedCap UE may be greater than the number of repetitions configured for non-RedCap UEs. This may also be considered more attractive if separate BWP for CE is used for Msg3 transmission by both the RedCap UE and the non-RedCap UE during initial access.

In the fourth embodiment, only the RedCap UE may be allowed to use the CE feature (thus, there may be two or three regions). The fourth embodiment may be similar to the second embodiment with three regions if the early indication is enabled (configured for the RedCap UE) and a) the CE feature is signaled only for the RedCap UE, or b) the threshold of the CE is set to a value such that the CE feature is disabled for the non-RedCap UE and the RedCap UE has a separate RedCap threshold from the non-RedCap UE. Table 14 below shows a RACH configuration according to the fourth embodiment, wherein Msg3 repetition is typically disabled for non-RedCap UEs with appropriate thresholds. When the Msg3 repetition is not used, the RedCAP UE transmits Msg1 according to the RACH1, and the non-RedCAP UE transmits Msg1 according to the RACH 3. When repeated with Msg3, the RedCap UE transmits Msg1 according to RACH 2. The non-RedCap UE may be configured with a very low threshold such that the non-RedCap UE does not perform Msg3 repetition and the non-RedCap UE transmits Msg1 according to RACH 3. The threshold value of the RedCap UE configuration (for performing Msg3 repetition) is different from the threshold value of the non-RedCap UE configuration. Since three regions are configured, there is no problem (support of early indication) for the RedCap UE to use a separate BWP. non-RedCap UEs do not use CEs (or the network decides not to support CEs for non-RedCap UEs).

TABLE 14

UE type	No Msg3 repeat	Msg3 repeat
			RedCap	RACH1	RACH2
non-RedCAP	RACH3	b) RACH3 (with very low threshold)

If there is no early indication configured for the RedCap UE, there will be two regions (RACH configuration). This example may be similar to the first embodiment if a) the CE feature is signaled only for the RedCap UE, or b) the threshold of the CE is set to a value such that the CE feature is disabled for non-RedCap UEs and there is a separate RedCap threshold that is different from the non-RedCap UE. This example is shown in table 15 below. When Msg3 repetition is not used, the RedCap UE and the non-RedCap UE transmit Msg1 according to RACH 1. When repeated with Msg3, the RedCap UE transmits Msg1 according to RACH 2. The non-RedCap UE may be configured with a very low threshold such that the non-RedCap UE does not perform Msg3 repetition and, therefore, the non-RedCap UE transmits Msg1 according to RACH 1. The threshold value of the RedCap UE configuration (for performing Msg3 repetition) is different from the threshold value of the non-RedCap UE configuration.

TABLE 15

UE type	No Msg3 repeat	Msg3 repeat
			RedCap	RACH1	RACH2
non-RedCAP	RACH1	b) RACH2 (with very low threshold)

Fig. 9 is a flow chart of an embodiment of a method 900 for RedCap UE indication. The method 900 may indicate operation of the UE. The UE may determine whether during or after a Random Access (RA) procedure of the UE, based on criteria, indicate to the gNB that the UE is a reduced capability (reduced capability, redCap) UE (block 902). The RedCap UE has a fewer number of receive branches than the minimum number of receive branches of the non-RedCap UE or a smaller bandwidth than the minimum bandwidth of the non-RedCap UE. The UE may indicate to the gNB that it is a RedCap UE based on the determination (block 904). The non-RedCap UE may be a legacy UE.

Fig. 10 is a flow chart of another embodiment of a method 1000 for RedCap UE detection. Method 1000 may indicate operation of the gNB. The gNB may receive a first message from a UE during a Random Access (RA) procedure (block 1002). The gNB may determine whether the first message indicates that the UE is a reduced capability (reduced capability, redCap) UE (block 1004). The RedCap UE has a fewer number of receive branches than the minimum number of receive branches of the non-RedCap UE or a smaller bandwidth than the minimum bandwidth of the non-RedCap UE. When the first message indicates that the UE is a RedCap UE, the gNB may send a second message to the UE according to the coverage recovery technique during the RA procedure (block 1006). When the first message does not indicate that the UE is a RedCap UE, the gNB may determine whether the UE is a RedCap UE after the RA procedure is complete (block 1008).

FIG. 11 illustrates a block diagram of an embodiment processing system 1100 that may be installed in a host device for performing the methods described herein. As shown, the processing system 1100 includes a processor 1104, a memory 1106, and interfaces 1110 to 1114, which may (or may not) be arranged as shown in fig. 11. Processor 1104 may be any component or collection of components for performing computing and/or other processing related tasks, and memory 1106 may be any component or collection of components for storing programming and/or instructions for execution by processor 1104. In one embodiment, memory 1106 includes a non-transitory computer-readable medium. Interfaces 1110, 1112, 1114 may be any component or collection of components that enable processing system 1100 to communicate with other devices/components and/or users. For example, one or more of interfaces 1110, 1112, 1114 may be used to communicate data, control, or management messages from processor 1104 to applications installed on the host device and/or remote device. As another example, one or more of interfaces 1110, 1112, 1114 may be used to enable a user or user device (e.g., personal computer (personal computer, PC), etc.) to interact/communicate with processing system 1100. The processing system 1100 may include additional components not shown in fig. 11, such as long term memory (e.g., non-volatile memory, etc.).

In some embodiments, the processing system 1100 is included in a network device that accesses or otherwise becomes part of a telecommunications network. In one example, the processing system 1100 is located in a network-side device in a wireless or wireline telecommunications network, such as a base station, relay station, scheduler, controller, gateway, router, application server, or any other device in a telecommunications network. In other embodiments, the processing system 1100 is located in a user-side device that accesses a wireless or wired telecommunications network, such as a mobile station, a User Equipment (UE), a personal computer (personal computer, PC), a tablet, a wearable communication device (e.g., a smart watch, etc.), or any other device for accessing a telecommunications network.

In some embodiments, one or more of interfaces 1110, 1112, 1114 connect processing system 1100 to a transceiver for sending and receiving signaling over a telecommunications network. Fig. 12 shows a block diagram of a transceiver 1200 for transmitting and receiving signaling over a telecommunications network. Transceiver 1200 may be installed in a host device. As shown, transceiver 1200 includes a network-side interface 1202, a coupler 1204, a transmitter 1206, a receiver 1208, a signal processor 1210, and a device-side interface 1212. Network-side interface 1202 may include any component or collection of components for sending or receiving signaling over a wireless or wireline telecommunications network. Coupler 1204 may include any component or collection of components for facilitating two-way communication through network-side interface 1202. Transmitter 1206 may include any component or collection of components (e.g., an up-converter, a power amplifier, etc.) for converting a baseband signal to a modulated carrier signal suitable for transmission through network-side interface 1202. Receiver 1208 can include any component or collection of components (e.g., a down-converter, low noise amplifier, etc.) for converting a carrier signal received through network-side interface 1202 to a baseband signal. The signal processor 1210 may include any component or collection of components for converting baseband signals to data signals suitable for communication through one or more device side interfaces 1212 or vice versa. The one or more device-side interfaces 1212 may include any component or collection of components for transmitting data signals between the signal processor 1210 and components within a host device (e.g., processing system 1100, local area network (local area network, LAN) port, etc.).

Transceiver 1200 may send and receive signaling over any type of communication medium. In some embodiments, transceiver 1200 sends and receives signaling over a wireless medium. For example, transceiver 1200 may be a wireless transceiver for communicating according to a wireless telecommunications protocol, such as a cellular protocol (e.g., long-term evolution (LTE), etc.), a wireless local area network (wireless local area network, WLAN) protocol (e.g., wi-Fi, etc.), or any other type of wireless protocol (e.g., bluetooth, near field communication (near field communication, NFC), etc.). In these embodiments, the network-side interface 1202 includes one or more antenna/radiating elements. For example, network-side interface 1202 may include a single antenna, multiple independent antennas, or a multi-antenna array for multi-layer communications, such as single-input multiple-output (single input multiple output, SIMO), multiple-input single-output (multiple input single output, MISO), multiple-input multiple-output (multiple input multiple output, MIMO), and so forth. In other embodiments, transceiver 1200 sends and receives signaling over twisted pair cables, coaxial cable, fiber optic, and other wired media. The particular processing system and/or transceiver may utilize all of the components shown, or only a subset of these components, and the level of integration may vary from device to device.

Fig. 13 is a block diagram of an electronic device (electronic device, ED) 1352 shown within a computing and communication environment 1300, the electronic device 1352 being operable to implement the devices and methods disclosed herein. Examples of EDs include UEs, tablet computers, ioT devices, computers, or other devices with wireless communication capabilities.

In some embodiments, the electronic device may be an element of a communication network infrastructure, such as a base station (e.g., a NodeB, evolved NodeB, eNodeB, or eNB), a next generation NodeB (sometimes referred to as a gndeb or gNB), a home subscriber server (home subscriber server, HSS), a Gateway (GW) such as a Packet Gateway (PGW) or Serving Gateway (SGW), or various other nodes or functions in a Core Network (CN) or public land mobile network (public land mobility network, PLMN). In other embodiments, the electronic device may be a device that connects to the network infrastructure over a wireless interface, such as a cell phone, smart phone, or other such device that may be categorized as a User Equipment (UE). In some embodiments, ED 1352 may be a machine-type communication (machine type communications, MTC) device (also referred to as a machine-to-machine (M2M) device) or other such device that may be categorized as a UE (although no direct service is provided to the user). In some references, ED may also be referred to as a mobile device, whether the mobile device itself is designed to be mobile or capable of moving, the purpose of this term being to denote a device connected to a mobile network. A particular device may use all or only a subset of the components shown, and the degree of integration may vary between devices. Further, a device may include multiple instances of components, e.g., multiple processors, multiple memories, multiple transmitters, multiple receivers, etc. ED 1352 generally includes a processor 1354, e.g., a central processing unit (central processing unit, CPU), and may also include a special purpose processor (e.g., a graphics processing unit (graphics processing unit, GPU) or other such processor), memory 1356, a network interface 1358, and a bus 1360 for connecting the various components in ED 1352. ED 1352 may optionally further include mass storage device 1362, video adapter 1364, and I/O interface 1368 (shown in phantom), among other components.

The memory 1356 may comprise any type of non-transitory system memory readable by the processor 1354, such as static random access memory (static random access memory, SRAM), dynamic random access memory (dynamic random access memory, DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or a combination thereof. In one embodiment, memory 1356 may include more than one type of memory, such as ROM for use at power-up and DRAM for storing programs and data when the programs are executed. Bus 1360 may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus, or a video bus.

The electronic device 1352 may also include one or more network interfaces 1358, and the one or more network interfaces 1358 may include at least one of a wired network interface and a wireless network interface. As shown in fig. 13, network interface 1358 may include a wired network interface for connecting to a network 1374 and may also include a wireless access network interface 1372 for connecting to other devices via a wireless link. When ED 1352 is a network infrastructure element, wireless access network interface 1372 may be omitted for nodes or functions that are PLMN elements other than elements at the wireless edge (e.g., eNB). When ED 1352 is an infrastructure located at the wireless edge of the network, both wired network interfaces and wireless network interfaces may be included. When ED 1352 is a wireless connected device, such as a user device, wireless access network interface 1372 may exist and it may be supplemented by other wireless interfaces, such as Wi-Fi network interfaces. The network interface 1358 enables the ED 1352 to communicate with remote entities, e.g., entities connected to the network 1374.

The mass storage device 1362 may include any type of non-transitory storage device for storing data, programs, and other information and making such data, programs, and other information accessible via the bus 1360. The mass storage device 1362 may include, for example, one or more of a solid state disk, hard disk drive, magnetic disk drive, or optical disk drive. In some embodiments, the mass storage device 1362 may be remote from the electronic device 1352 and accessible through a network interface such as the interface 1358. In the illustrated embodiment, the mass storage device 1362 is different from the memory 1356 that includes the mass storage device 1362 and may generally perform storage tasks compatible with higher latency, but is generally less volatile or non-existent. In some embodiments, the mass storage device 1362 may be integrated with the heterogeneous memory 1356.

Optional video adapter 1364 and I/O interface 1368 (shown in phantom) provide interfaces to couple electronic device 1352 to external input and output devices. Examples of input and output devices include a display 1366 coupled with the video adapter 1364 and an I/O device 1370, such as a touch screen, coupled with the I/O interface 1368. Other devices may be coupled to ED 1352 and may use more or fewer interfaces. For example, a serial interface (not shown) such as a universal serial bus (universal serial bus, USB) may be used to provide an interface for external devices. Those skilled in the art will appreciate that in embodiments where ED 1352 is part of a data center, I/O interface 1368 and video adapter 1364 may be virtualized and provided through network interface 1358.

In some embodiments, ED 1352 may be a standalone device, while in other embodiments, electronic device 1352 may be located within a data center. In the art, a data center may be understood as a collection of computing resources (typically in the form of servers) that may serve as a collective computing and storage resource. Within a data center, multiple servers may be connected together to provide a pool of computing resources on which virtualized entities may instantiate. The data centers may be interconnected to form a network comprising computing and storage resource pools interconnected by connection resources. The connection resources may be physical connections such as ethernet or optical communication links, and may also include wireless communication channels in some instances. If two different data centers are connected by a plurality of different communication channels, the links may be combined together using any of a number of techniques including forming a link aggregation group (link aggregation group, LAG). It should be appreciated that any or all of the computing resources, storage resources, and connection resources (as well as other resources within the network) may be partitioned between different subnets, in some cases in the form of resource slices. If resources across multiple connected data centers or other node sets are sliced, different network slices can be created.

It should be understood that one or more steps of the method embodiments provided herein may be performed by corresponding units or modules. For example, the signal may be transmitted by a transmitting unit or a transmitting module. The signal may be received by a receiving unit or a receiving module. The signals may be processed by a processing unit or processing module. Other steps may be performed by the following modules: a determination unit/module, a RedCap UE indication or identification unit/module, a comparison unit/module, a measurement unit/module, a capability exchange unit/module, a RACH configuration unit/module, a broadcast coverage recovery, a RACH execution unit/module, a reception coverage recovery unit/module, and/or a coverage recovery unit/module. The corresponding units/modules may be hardware, software or a combination thereof. For example, one or more of the units/modules may be an integrated circuit, such as a field programmable gate array (field programmable gate array, FPGA) or an application-specific integrated circuit (ASIC).

The following references are relevant to the subject matter of the present disclosure, the entire disclosures of which are incorporated herein by reference:

ericsson, "revision SID (Revised SID on Study on Supportof Reduced Capability NR Devices) to support reduced capability NR device research", document RP-201677,3gpp, month 7 of 2020;

TR38.875, v0.1.0 "support research (Study on Support of ReducedCapability NR Devices) of reduced capability NR devices" (version 17), 2020-11-25;

TS 36.300, v16.3.0, "E-UTRA E-UTRAN Overall description phase 2 (E-UTRA E-UTRAN Overall Description Stage-2)";

TS 38.331, v16.2.0, "radio resource RRC protocol specification (Radio Resource RRC protocol specification)" (release 16);

TS 36.331, V13.11.0, "radio resource RRC protocol Specification (Radio Resource RRC protocol specification)" (release 13), 2018-09-27;

TS 38.300, V16.3.0, "NR and NG-RAN overall description; stage 2 (NR and NG-RAN Overall description; stage-2) "(version 16), 2020-10-02;

TS 36.213, V13.11.0, "evolved Universal terrestrial radio Access (E-UTRA); physical layer program (Evolved Universal Terrestrial Radio Access (E-UTRA); physical layer procedures) "(version 13), 2018-10-01;

TS38.306, V16-2, "User Equipment (UE) radio Access capability (User Equipment (UE) radio access capabilities)" (release 16), 2020-10-02.

Although the detailed description has been described, it should be understood that various changes, substitutions and alterations can be made hereto without departing from the spirit and scope of the disclosure as defined by the appended claims. Furthermore, the scope of the present disclosure is not intended to be limited to the particular embodiments described herein, as one of ordinary skill in the art will readily appreciate from the present disclosure, processes, machines, manufacture, compositions of matter, means, methods, or steps (including those presently existing or later to be developed) that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

Claims

1. A method, the method comprising:

a User Equipment (UE) determines, based on a criterion, whether to indicate to a gNB during a Random Access (RA) procedure of the UE or after the RA procedure, whether the UE is a reduced capability (RedCap) UE having fewer receive branches than a minimum receive branch number of a non-RedCap UE or having a bandwidth less than a minimum bandwidth of the non-RedCap UE; and

and the UE indicates the UE to the gNB as the RedCAP UE according to the determination result.

2. The method of claim 1, wherein the non-RedCap UE is a legacy UE.

3. The method according to claim 1 or 2, characterized in that the RedCap UE has one or two receiving branches.

4. A method according to any of claims 1 to 3, characterized in that the minimum reception branch of the non-RedCap UE is 4 for frequency range 1 (FR 1) and 2 for frequency range 2 (FR 2).

5. The method of any one of claims 1 to 4, wherein the indication comprises:

when determining to indicate during the RA procedure, the UE sends a first message to the gNB during the RA procedure indicating that the UE is the RedCap UE, the first message including message 1 (Msg 1) of the RA procedure, message 3 (Msg 3) of the RA procedure, or message a (MsgA) of the RA procedure.

6. The method as recited in claim 5, further comprising:

prior to the RA procedure, the UE determines the first message based on a Radio Resource Control (RRC) configuration broadcast by the gNB and received by the UE prior to the RA procedure.

7. The method of claim 6, wherein the RRC configuration includes information of the criteria.

8. The method of any of claims 5-7, wherein the first message is sent by the UE according to a Physical Random Access Channel (PRACH) configuration broadcast by the gNB and received by the UE prior to the RA procedure, the PRACH configuration comprising a RACH preamble associated with an indication RedCap UE, a RACH occasion, or a combination thereof.

9. The method according to any one of claims 5 to 8, further comprising:

the UE receives message 2 (Msg 2) or message 4 (Msg 4) from the gNB during the RA procedure according to the received coverage recovery technique.

10. The method according to any one of claims 5 to 9, wherein the first message is the Msg1, the method further comprising:

and the UE repeatedly sends the Msg3 to the gNB.

11. The method of claim 10, wherein the number of repetitions of the transmission of Msg3 is based on a RACH configuration.

12. The method of claim 10, wherein the transmitting of the Msg3 is repeated when a Reference Signal Received Power (RSRP) measurement of the UE is less than a threshold.

13. The method of any one of claims 1 to 4, wherein the indication comprises:

when determining to indicate after the RA procedure, the UE sends UE capability information indicating that the UE is the RedCap UE to the gNB after the RA procedure is completed.

14. The method according to any of claims 1 to 13, wherein the criterion is based on a number of received branches of the UE, a Reference Signal Received Power (RSRP) measured by the UE, a Reference Signal Received Quality (RSRQ) measured by the UE, a Reference Signal Strength Indication (RSSI) measured by the UE, or a combination thereof.

15. The method according to any of claims 1 to 14, wherein the criterion is based on a capability of the UE.

16. The method according to any one of claims 1 to 15, wherein the determining comprises:

When the UE has two reception branches, the UE determines to indicate the UE as the RedCap UE after the RA procedure; or (b)

When the UE has one receive branch, the UE determines to indicate the UE as the RedCap UE during the RA procedure.

17. The method according to any one of claims 1 to 15, wherein the determining comprises:

when the UE has two receive branches and is operable in frequency range 1 (FR 1) or FR2, the UE determines to indicate that the UE is the RedCap UE after the RA procedure;

when the UE has one receive branch and is operable under FR1 or FR2, the UE determines to indicate that the UE is the RedCap UE during the RA procedure; or (b)

When the UE has two receive branches and is operable under FR1, the UE determines to indicate that the UE is the RedCap UE during the RA procedure.

18. The method according to any one of claims 1 to 15, wherein the determining comprises:

the UE compares the RSRP measured value with a threshold configured for the RedCAP UE;

when the RSRP measurement value is greater than the threshold value, the UE determines to indicate the UE as the RedCap UE after the RA procedure; or (b)

When the RSRP measurement value of the UE is less than or equal to the threshold, the UE determines to indicate that the UE is the RedCap UE during the RA procedure.

19. The method according to any one of claims 1 to 15, wherein the determining comprises:

when the UE has two receive branches and the RSRP measurement value is greater than the threshold, the UE determines to indicate that the UE is the RedCap UE after the RA procedure;

when the UE has two receive branches and the RSRP measurement of the UE is less than or equal to the threshold, the UE determines to indicate the UE as the RedCap UE during the RA procedure; or (b)

20. The method according to any one of claims 1 to 15, wherein the determining comprises:

when the UE has one receive branch and the RSRP measurement value is greater than the threshold, the UE determines to indicate the UE as the RedCap UE after the RA procedure;

When the UE has one receive branch and the RSRP measurement value is less than or equal to the threshold, the UE determines to indicate the UE as the RedCap UE during the RA procedure; or (b)

When the UE has two reception branches, the UE determines to indicate the UE as the RedCap UE after the RA procedure.

21. A method, the method comprising:

the gNB receives a first message from a User Equipment (UE) during a Random Access (RA) procedure;

the gNB determining whether the first message indicates that the UE is a reduced capability (RedCAP) UE having fewer receive branches than a minimum receive branch of a non-RedCAP UE or having a bandwidth less than a minimum bandwidth of the non-RedCAP UE;

when the first message indicates that the UE is the RedCap UE, the gNB sends a second message to the UE during the RA procedure according to a coverage recovery technique; and

when the first message does not indicate that the UE is the RedCap UE, the gNB determines whether the UE is the RedCap UE after the RA procedure is completed.

22. The method of claim 21, wherein the non-RedCap UE is a legacy UE.

23. The method according to claim 21 or 22, wherein the RedCap UE has one or two receiving branches.

24. The method according to any of claims 21 to 23, wherein the minimum reception branch of the non-RedCap UE is 4 for frequency range 1 (FR 1) and 2 for frequency range 2 (FR 2).

25. The method according to any of the claims 21 to 24, wherein the first message comprises message 1 (Msg 1) of the RA procedure, message 3 (Msg 3) of the RA procedure or message a (MsgA) of the RA procedure.

26. The method of claim 25, wherein the first message is based on a Physical Random Access Channel (PRACH) configuration broadcast by the gNB, the PRACH configuration including a RACH preamble associated with an indication of a RedCap UE, a RACH occasion, or a combination thereof.

27. The method according to any of claims 21 to 26, characterized in that the second message is message 2 (Msg 2) of the RA procedure or message 4 (Msg 4) of the RA procedure.

28. The method according to any one of claims 21 to 25, further comprising:

the gNB receives from the UE capability information indicating that the UE is the RedCap UE after the RA procedure is completed.

29. The method according to any one of claims 21 to 28, further comprising:

the gNB broadcasts information of criteria to the UE, the criteria enabling the UE to determine whether to indicate to the gNB whether the UE is the RedCap UE during or after the RA procedure based on the criteria.

30. The method of claim 29, wherein the criterion is based on a number of received branches of the UE, a Reference Signal Received Power (RSRP) measurement of the UE, a Reference Signal Received Quality (RSRQ) measurement of the UE, a Reference Signal Strength Indication (RSSI) of the UE, or a combination thereof.

31. The method according to claim 29 or 30, wherein the criterion is based on a capability of the UE.

32. The method of any one of claims 29 to 31, wherein the criteria include:

when the UE has two reception branches, indicating the RedCap UE after the RA procedure; or (b)

The RedCap UE is indicated during the RA procedure when the UE has one receive branch.

33. The method of any one of claims 29 to 31, wherein the criteria include:

When the UE has two receive branches and is operable in frequency range 1 (FR 1) or FR2, the RedCap UE is indicated after the RA procedure;

when the UE has one receive branch and is operable under FR1 or FR2, the RedCap UE is instructed during the RA procedure; or (b)

The RedCap UE is indicated during the RA procedure when the UE has two receive branches and is operable under FR 1.

34. The method of any one of claims 29 to 31, wherein the criteria include:

indicating the RedCap UE after the RA procedure when the RSRP measured by the UE is greater than a threshold; or (b)

The RedCap UE is indicated during the RA procedure when the RSRP measured by the UE is less than or equal to the threshold.

35. The method of any one of claims 29 to 31, wherein the criteria include:

when the UE has two receive branches and the RSRP measured by the UE is greater than a threshold, indicating the RedCap UE after the RA procedure;

indicating the RedCap UE during the RA procedure when the UE has two receive branches and the RSRP measured by the UE is less than or equal to the threshold; or (b)

36. The method of any one of claims 29 to 31, wherein the criteria include:

when the UE has one receiving branch and the RSRP measured by the UE is greater than a threshold, indicating the RedCap UE after the RA procedure;

indicating the RedCap UE during the RA procedure when the UE has one receive branch and the RSRP measured by the UE is less than or equal to the threshold; or (b)

The RedCap UE is indicated after the RA procedure when the UE has two receive branches.

37. The method according to any one of claims 21 to 36, further comprising:

the gNB broadcasts information indicating that the gNB supports a RedCAP UE.

38. An apparatus, the apparatus comprising:

a non-transitory memory comprising instructions; and

one or more processors in communication with the memory, wherein the instructions, when executed by the one or more processors, cause the apparatus to:

determining, based on a criterion, whether to indicate to a gNB during or after a Random Access (RA) procedure of the apparatus, whether the apparatus is a reduced capability (RedCap) UE having fewer receive branches than a minimum number of receive branches of a non-RedCap UE or having a bandwidth less than the minimum bandwidth of the non-RedCap UE; and

And indicating the device to be the RedCAP UE to the gNB according to a determination result.

39. An apparatus, the apparatus comprising:

a non-transitory memory comprising instructions; and

during a Random Access (RA) procedure, receiving a first message from a User Equipment (UE);

determining whether the first message indicates that the UE is a reduced capability (RedCap) UE having fewer receive branches than a minimum receive branch of a non-RedCap UE or having a bandwidth less than a minimum bandwidth of the non-RedCap UE;

when the first message indicates that the UE is the RedCap UE, sending a second message to the UE during the RA procedure according to a coverage recovery technique; and

when the first message does not indicate that the UE is the RedCap UE, determining whether the UE is the RedCap UE after the RA procedure is completed.

40. A non-transitory computer-readable medium storing computer instructions that, when executed by one or more processors of an apparatus, cause the apparatus to:

Determining, based on a criterion, whether to indicate to a gNB whether the apparatus is a reduced capability (RedCAP) UE during or after a Random Access (RA) procedure of the apparatus, the RedCAP UE having fewer receive branches than a minimum receive branch of a non-RedCAP UE or having a bandwidth less than the minimum bandwidth of the non-RedCAP UE; and

41. A non-transitory computer-readable medium storing computer instructions that, when executed by one or more processors of an apparatus, cause the apparatus to:

receiving a first message from a User Equipment (UE) during a Random Access (RA) procedure;

42. A system comprising a User Equipment (UE) and a gNB;

wherein the UE is configured to perform the following operations:

determining, based on a criterion, whether to indicate to the gNB whether the UE is a reduced capability (RedCap) UE during a Random Access (RA) procedure of the UE or after the RA procedure, the RedCap UE having a fewer number of receive branches than a minimum number of receive branches of a non-RedCap UE or having a bandwidth less than the minimum bandwidth of the non-RedCap UE; and

indicating to the gNB that the UE is the RedCAP UE according to a determination result; and

wherein, the gNB is used for executing the following operations:

receiving a first message from the UE during a Random Access (RA) procedure;

determining whether the first message indicates that the UE is the RedCap UE;