DE102023110524A1 - PRACH for coverage improvements - Google Patents

Abstract

A system and method for PRACH for coverage improvements are disclosed. In some embodiments, the method includes: sending, by a user equipment (UE), a first Physical Random Access Channel (PRACH) broadcast in a first Random Access Channel Occasion (RO); and transmitting, by the UE, a second PRACH transmission in a second RO, the second PRACH transmission being a repeat of the first PRACH transmission, the second RO having an index different from an index of the first RO by one the set integer differs.

Description

CROSS REFERENCES TO RELATED APPLICATIONS

This application claims priority under 35 USC § 119(e) of US Provisional Application No. 63/335,116 , filed April 26, 2022, and U.S. Provisional Application No. 63/434,881 , filed on December 22, 2022, the disclosure of which is incorporated in its entirety by reference.

TECHNICAL FIELD

The disclosure relates generally to wireless communications. In particular, the subject matter disclosed herein relates to improvements in handling Physical Random Access Channel (PRACH) broadcasts in wireless networks with coverage improvements.

SHORT VERSION

In a wireless communications system, such as a cellular telephone system, the coverage of the wireless network may be a factor that limits the overall performance of the system.

To solve this problem, various approaches can be used to enable reliable communication in low signal-to-noise conditions. For example, certain broadcasts generated by a user device, such as Physical Random Access Channel (PRACH) broadcasts, may be repeated. A problem with the above approach is that various parameters, such as a preamble, may need to be selected for each repeated broadcast. To overcome these problems, systems and methods are described herein for selecting parameters to be used in each PRACH repetition. The above approaches improve previous methods because they can, for example, reduce the decoding complexity for the network node (gNB).

According to an embodiment of the present disclosure, there is provided a method comprising: sending, by a user equipment (UE), a first Physical Random Access Channel (PRACH) transmission in a first Random Access Channel Occasion (RO); and transmitting, by the UE, a second PRACH transmission in a second RO, the second PRACH transmission being a repeat of the first PRACH transmission, the second RO having an index different from an index of the first RO by one the set integer differs.

In some embodiments, the first RO is associated with a first sync signal block (SSB) index and the second RO is associated with the first SSB index.

In some embodiments, the first PRACH transmission uses a first uplink (UL) beam and the second PRACH transmission uses a second UL beam that is different from the first UL beam.

In some embodiments, the set integer is configured using Radio Resource Control (RRC).

In some embodiments, the set integer is configured by a system information block.

In some embodiments, the set integer is configured upon startup of the UE.

In some embodiments, the first PRACH broadcast includes a first preamble with a first preamble index; and the second PRACH broadcast includes a second preamble with a second preamble index that differs from the first preamble index by a set integer.

In some embodiments, the method includes sending L PRACH transmissions comprising: the first PRACH transmission; and L-1 PRACH repeats comprising the second PRACH broadcast, the L PRACH broadcasts being in an SSB-RO association period.

In some embodiments, the first PRACH transmission occurs on one of N' ROs, where the N' ROs are a predefined subset of N available ROs.

In some embodiments, the set own subset is configured using Radio Resource Control (RRC).

In some embodiments, the method includes sending L PRACH transmissions comprising: the first PRACH transmission; and L-1 PRACH repeats comprising the second PRACH transmission, where the N' ROs are selected based on the value of L.

According to an embodiment of the present disclosure, there is provided a method comprising: transmitting by a user device (UE), a first Physical Random Access Channel (PRACH) broadcast comprising a first preamble, in a first RO; and sending, by the UE, a second PRACH transmission comprising a second preamble in a second RO, the second PRACH transmission being a repeat of the first PRACH transmission, the first preamble based on a first root sequence and cyclic a first integer is shifted, and the second preamble is based on the first root sequence and is cyclically shifted by a second integer, which differs from the first integer by a set integer.

In some embodiments, the method includes sending L PRACH transmissions comprising: the first PRACH transmission; and L-1 PRACH repeats comprising the second PRACH broadcast, the L PRACH broadcasts being in an SSB-RO association period.

In some embodiments, the first PRACH transmission occurs on one of N' ROs, where the N' ROs are a predefined subset of N available ROs.

In some embodiments, the set own subset is configured using Radio Resource Control (RRC).

In some embodiments, the method includes sending L PRACH transmissions comprising: the first PRACH transmission; and L-1 PRACH repeats comprising the second PRACH transmission, where the N' ROs are selected based on the value of L.

According to an embodiment of the present disclosure, a user equipment (UE) is provided that includes: one or more processors; and a memory that stores instructions that, when executed by the one or more processors, cause the one or more processors to perform: sending a first Physical Random Access Channel (PRACH) transmission in a first Random Access Channel Occasion ( RO); and sending a second PRACH transmission in a second RO, the second PRACH transmission being a repeat of the first PRACH transmission, the second RO having an index that differs from an index of the first RO by a set integer.

In some embodiments, the first RO is associated with a first sync signal block (SSB) index and the second RO is associated with the first SSB index.

In some embodiments, the first PRACH transmission uses a first uplink (UL) beam and the second PRACH transmission uses a second UL beam that is different from the first UL beam.

In some embodiments, the set integer is configured using Radio Resource Control (RRC).

BRIEF DESCRIPTION OF THE DRAWINGS

• 1 eine Darstellung einer Random-Access-Channel(RACH)-Prozedur mit 4 Schritten gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 2A eine Darstellung von Strahlen, die bei PRACH-aggregierter Sendung verwendet werden, gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 2B eine Darstellung von Strahlen, die bei PRACH-aggregierter Sendung verwendet werden, gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 2C eine Darstellung von Strahlen, die bei PRACH-aggregierter Sendung verwendet werden, gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 3A eine Darstellung eines ersten Beispiels von Uplink(UL)-Sendungen gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 3B eine Darstellung eines zweiten Beispiels von Uplink(UL)-Sendungen gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 3C eine Darstellung eines Beispiels des Verhaltens eines Rel-16-UE und eines Rel-17-UE mit 3-Level-PRACH-Aggregation gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 4A eine erste Reihenfolge eines Durchschaltens durch einen relativen Random-Access-Channel(RACH)-Gelegenheits(RO)-Index und einen Synchronisierungssignalblock(SSB)-Index gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt;
• 4B eine zweite Reihenfolge eines Durchschaltens durch einen relativen RO-Index und einen SSB-Index gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt;
• 4C eine Mehrzahl von Hypothesen, die ein gNB anstellen kann, gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt;
• 4D eine Darstellung der Bestimmung von PRACH-Aggregationslevel gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 5A eine Darstellung einer PRACH-Aggregation gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 5B eine Darstellung einer PRACH-Aggregation gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 6A eine Darstellung einer PRACH-Aggregation gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 6B eine Darstellung einer PRACH-Aggregation gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 6C eine Darstellung einer PRACH-Aggregation gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 6D eine Darstellung einer PRACH-Aggregation gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 7A eine Darstellung eines ersten Beispiels einer Strahlauswahl durch ein UE und durch ein gNB gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 7B eine Darstellung eines zweiten Beispiels einer Strahlauswahl durch ein UE und durch ein gNB gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 7C eine Darstellung eines zweiten Beispiels einer Strahlauswahl durch ein UE gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 7D eine Darstellung eines zweiten Beispiels einer Strahlauswahl durch ein UE gemäß einer Ausführungsform der vorliegenden Offenbarung ist;
• 8A ein Schema eines Abschnitts eines drahtlosen Systems gemäß einigen Ausführungsformen ist;
• 8B ein Flussdiagramm eines Verfahrens gemäß einigen Ausführungsformen ist; und
• 9 ein Blockschaltbild einer elektronischen Vorrichtung in einer Netzwerkumgebung gemäß einer Ausführungsform ist.

In the following section, aspects of the subject matter disclosed herein will be described with reference to exemplary embodiments illustrated in the drawings, in which:

• 1 is an illustration of a 4-step random access channel (RACH) procedure according to an embodiment of the present disclosure;
• 2A is a representation of beams used in PRACH aggregated transmission according to an embodiment of the present disclosure;
• 2 B is a representation of beams used in PRACH aggregated transmission according to an embodiment of the present disclosure;
• 2C is a representation of beams used in PRACH aggregated transmission according to an embodiment of the present disclosure;
• 3A is an illustration of a first example of uplink (UL) transmissions according to an embodiment of the present disclosure;
• 3B is an illustration of a second example of uplink (UL) transmissions according to an embodiment of the present disclosure;
• 3C is an illustration of an example of the behavior of a Rel-16 UE and a Rel-17 UE with 3-level PRACH aggregation according to an embodiment of the present disclosure;
• 4A illustrates a first order of switching through a relative random access channel (RACH) opportunity (RO) index and a synchronization signal block (SSB) index according to an embodiment of the present disclosure;
• 4B illustrates a second order of switching through a relative RO index and an SSB index according to an embodiment of the present disclosure;
• 4C illustrates a plurality of hypotheses that a gNB can make, according to an embodiment of the present disclosure;
• 4D is an illustration of determining PRACH aggregation levels according to an embodiment of the present disclosure;
• 5A is an illustration of a PRACH aggregation according to an embodiment of the present disclosure;
• 5B is an illustration of a PRACH aggregation according to an embodiment of the present disclosure;
• 6A is an illustration of a PRACH aggregation according to an embodiment of the present disclosure;
• 6B is an illustration of a PRACH aggregation according to an embodiment of the present disclosure;
• 6C is an illustration of a PRACH aggregation according to an embodiment of the present disclosure;
• 6D is an illustration of a PRACH aggregation according to an embodiment of the present disclosure;
• 7A is an illustration of a first example of beam selection by a UE and by a gNB according to an embodiment of the present disclosure;
• 7B is an illustration of a second example of beam selection by a UE and by a gNB according to an embodiment of the present disclosure;
• 7C is an illustration of a second example of beam selection by a UE according to an embodiment of the present disclosure;
• 7D is an illustration of a second example of beam selection by a UE according to an embodiment of the present disclosure;
• 8A is a schematic of a portion of a wireless system according to some embodiments;
• 8B is a flowchart of a method according to some embodiments; and
• 9 is a block diagram of an electronic device in a network environment according to an embodiment.

DETAILED DESCRIPTION

The detailed description below sets forth numerous specific details to provide a thorough understanding of the disclosure. However, it will be understood by those skilled in the art that the disclosed aspects can be put into practice without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail in order not to obscure the subject matter disclosed herein.

Reference in this description to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment disclosed herein. Thus, the appearance of the phrase “in one embodiment” or “in one embodiment” or “according to one embodiment” (or other expressions having similar meaning) in various places throughout this specification does not necessarily refer to the same embodiment. Further, the particular features, structures, or properties may be combined in any suitable manner in one or more embodiments. In this regard, the word “exemplary” as used herein means “serving as an example, case study, or illustration.” Any embodiment described herein as “exemplary” should not be interpreted as necessarily preferred or advantageous over other embodiments. Additionally, the particular features, structures, or properties may be combined in any suitable manner in one or more embodiments. Also, depending on the context of a discussion herein, a singular term may include the corresponding plural forms and a plural term may include the corresponding singular form. Likewise, a hyphenated term (e.g. "two-dimensional", "pixel-specific", etc.) can sometimes be used interchangeably with a corresponding version without a hyphen (e.g. "two-dimensional", "predefined", "pixel-specific " etc.) and a capitalized entry (e.g. "Counter Clock", "Row Select", "PIXOUT", etc.) can be used interchangeably with a non-capitalized version (e.g. "counter clock", "row select”, “pixout”, etc.). Such occasional interchangeable usages should not be construed as inconsistent.

Also, depending on the context of a discussion herein, a singular term may include the corresponding plural forms and a plural term may include the corresponding singular form. It is further noted that various figures (including component diagrams) shown and explained herein are for illustrative purposes only and are not drawn to scale. For example, the dimensions of some of the elements may be excessively enlarged compared to other elements for clarity. Furthermore, where appropriate, reference numbers were used chen repeated in figures to identify corresponding and/or analogous elements.

The terminology used herein is solely for the purpose of describing some example embodiments and is not intended to limit the subject matter claimed. As used herein, the singular forms "a", "an", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It is further understood that the terms "comprising" and/or "comprising" when used in this specification indicate the presence, but not the presence, of given features, integers, steps, processes, elements and/or components or exclude addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof.

It is understood that when an element or layer is referred to as being “on,” “connected to,” or “coupled with” another element or layer, it means that it is directly on top of the other element or layer can be connected or coupled to this or this, or intermediate elements or layers can be present. In contrast, there are no intermediate elements or layers when an element is referred to as “directly on,” “directly connected to,” or “directly coupled to” another element or layer. The same reference numbers refer to the same elements throughout. As used herein, the term “and/or” includes any combination of one or more of the associated bullet points listed. As used herein, the term "or" should be interpreted as "and/or" such that, for example, "A or B" means "A" or "B" or "A and B".

The terms "first", "second", etc., as used herein, are used as a closer designation of nouns they precede and are not intended to imply order (e.g., spatial, temporal, logical, etc.) unless they are explicit defined as such. Furthermore, the same reference numerals may be used in two or more figures to designate parts, components, blocks, circuits, units or modules that have the same or similar functionality. However, such use is only for the purposes of illustration and simple discussion; it does not imply that the construction or structural details of such components or units are the same in all embodiments or that such commonly referred to parts/modules are the only way to implement some of the example embodiments disclosed herein.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meanings normally understood by one skilled in the art to which such subject matter pertains. It is further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning consistent with their meaning in the context of the relevant subject matter, and not in an idealized or excessively formal sense interpreted unless expressly so defined herein.

As used herein, the term “module” refers to any combination of software, firmware and/or hardware designed to provide the functionality described herein, in connection with a module. For example, software may be embodied as a software package, code and/or instruction set or instructions, and the term "hardware" as used in an implementation described herein may, for example, individually or in any combination, mean an arrangement hardwired circuitry, a programmable circuitry, a state machine circuitry, and/or firmware storing instructions executable by a programmable circuitry. The modules may be embodied together or individually as a circuit device that forms part of a larger system, for example, but not limited to, an integrated circuit (IC), a system on chip (SoC), an array, etc.

When used as an adjective, the word “discontinued” means available to both the UE and the gNB at the time of its use. For example, the shift value P mentioned in rule P1 below may be a set integer.

The present disclosure describes a procedure for Physical Random Access Channel (PRACH) improvements in Coverage Enhancement (CE) scenarios. In the New Radio (NR) Fifth Generation of Mobile Telephony (5G) standard distributed by the 3rd Generation Partnership Project (3GPP), a UE is designed to send different uplink (UL) signals to the base station (gNB). . In NR, a UE uses a UL broadcast to transmit a variety of information to the gNB. In particular, the UE sends user data to the gNB in a specific configuration of time and frequency resources, which is known as Physical Uplink Shared Channel (PUSCH). In particular, the Medium Access Control (MAC) layer provides user data to be delivered to the corresponding layer on the gNB side. The Physical (PHY) layer of the UE takes the MAC layer data as input and outputs the corresponding PUSCH signal through a PUSCH processing chain. Similarly, the UE sends control data to the gNB in the so-called Physical Uplink Control Channel (PUCCH). The control data is called Uplink Control Information (UCI) and is considered the payload of the PUCCH signal.

Conversely, the UE is designed to receive different downlink (DL) signals from the base station (gNB). Similar to UL, a UE receives a DL broadcast to extract a variety of information from the gNB. The UE receives user data from the gNB in a specific configuration of time and frequency resources known as a Physical Downlink Shared Channel (PDSCH). The PHY layer of the UE extracts data from the physical signal received on the PDSCH and provides it to the MAC layer. Similarly, the UE receives control data from the gNB in the Physical Downlink Control Channel (PDCCH). The control data is referred to as Downlink Control Information (DCI) and is considered a payload to the PDCCH signal.

A UE is provided Search Space (SS) set configuration and Control Resource Set (CORESET) configuration for monitoring DCI in a PDCCH in a serving cell. In particular, an SS set configuration provides PDCCH monitoring opportunity information in the time domain, and each monitoring opportunity is associated with the CORESET configuration associated with the SS set configuration. A CORESET configuration provides a set of resource blocks (RB) and a symbol duration for a PDCCH candidate monitor, where a PDCCH candidate consists of a set of Control Channel Elements (CCE) depending on an aggregation level. A CCE consists of 6 Resource Element Groups (REGs) and each REG is a group of 12 consecutive Resource Elements (REs). In other words, a UE will monitor a set of REs for PDCCH candidates located in a specific, time and frequency range based on the CORESET and search space set configurations.

Another physical signal sent by the UE is called Physical Random Access Channel (PRACH). Similar to Long-Term Evolution (LTE) radio systems, communication between the UE and the gNB is based on frames. During an initial access, the UE UL transmissions are not timed to the gNB frame time because the round trip delay time is not taken into account. To synchronize the frame time of both the UE and the gNB - or the UL and the DL - the UE sends the PRACH signal, which is used by the gNB to make a determination of the round trip delay time. The UE is then informed about the value of the Timing Adjustment (TA) which it must apply to its UL transmission for an appropriate adjustment of frame time. Therefore, in the initial access procedure, the UE sends a PRACH signal in addition to obtaining the system information from the gNB, as explained below.

Similar to LTE, the UE performs initial access through Random Access (RA) processing. NR-Rel-16 supports the 4-step RACH procedure described here and in 1 is shown. Before the random access procedure is initialized, the UE receives the transmitted system information (Master Information Block (MIB) and System Information Block (SIB)) from the gNB by means of a synchronization signal block (SSB) transmission. In particular, the UE attempts to receive the transmission information, which provides the UE with the necessary information about obtaining the MIB and SIB. The system information informs the UE about the configuration of the random access procedure. Multiple SSBs are typically transmitted periodically, with each SSB transmitted by the gNB using a different wide transmission beam. The UE then tries to decode different SSBs and selects the best SSB as the one with the highest Reference Signal Received Power (RSRP). This SSB indicates the best wide beam to be used by the gNB to communicate with the UE.

The 4-step RACH procedure is as follows. The UE begins by sending a preamble to the gNB. This is called sending msg1 to the gNB. The UE selects a preamble from a pool of possible preambles. The ID of the preamble selected by the UE is called RAPID. At this point, multiple UEs could potentially have 4-step RA processes initiated simultaneously. Each UE can use a preamble with a different RAPID. If the preamble reception at the gNB is successful, the gNB sends msg2 to the UE. msg2 contains the RAPID of the preamble selected by one (or in case of conflicts, multiple) UEs, a TA value for the UE with the corresponding RAPID, and a UL assignment for the transmission of msg3.

The UE proceeds by sending msg3 using the resources specified in the UL allocation. msg3 contains a Contention Resolution ID (CRID), provided by higher layers, to the UE's physical layer. The UE applies the value of the TA specified in msg2 when sending msg3. If multiple UEs have the same RAPID in step 1, these UEs can send msg3 containing different CRIDs. The gNB then sends msg4, which contains the CRID of a UE. The UE having the corresponding CRID proceeds by sending an acknowledgment (ACK) message confirming the successful receipt of msg4 and the initial access procedure. These steps are described in more detail below.

A first step is to send msg1 (PRACH broadcast). The UE initiates the 4-step RACH procedure by sending msg1. During an initial access, the UE initiates a Contention-Based RA (CBRA) RACH procedure. The UE begins by selecting a preamble from a pool of possible preambles. The pool of preambles is determined based on the selected SSB and the UE makes a random selection from the preambles in the pool. Depending on the selected SSB, the UE also determines the set of time and frequency resources to be used when transmitting the selected preamble, which is referred to as a PRACH opportunity (RO). Since a valid TA is not necessarily available, the preamble is sent without timing adjustment. The standard specifies a switching time gap between DL transmissions and a subsequent UL PRACH transmission.

A second step is to send msg2 (Random Access Response (RAR)). The gNB records all preambles sent and consequently determines the TA values associated with each TA. Assuming that each transmitted preamble was selected by exactly one UE, the gNB then sends a response to each UE, the response including the RAPID of the scheduled UE; this response is called Random Access Response (RAR). The gNB broadcast, msg2, may include the RAR to one or more UEs. If a UE has a RAR in msg2, msg2 would also include: 1) the TA value that should be applied by the UE's further transmissions, and 2) a UL allocation to the UE representing the time/frequency resources to be used by the UE to send msg3.

After msg1 is sent, the UE does not know whether it will receive a RAR, nor does it know the exact timing of msg2. Instead, it monitors a certain duration of a Typel PDCCH Common Search Space (CSS) configured to send msg2. The monitoring period is called the RAR window. During the RAR window, the UE attempts to decode a DCI format 1_0, which would schedule the transmission of msg2.

A third step is to send msg3 (conflict resolution). Once msg2 is received, a UE that acquires its RAPID sends msg3 according to the UL assignment provided to the UE in msg2. msg3 contains a Contention Resolution ID (CRID), a 39-bit random number generated by the UE (if not configured). msg3 is sent after applying the TA.

A fourth step is to send msg4 (conflict resolution 2). After receiving msg3, possibly from multiple UEs that are in conflict, the gNB sends msg4 with the CRID of a UE. All UEs sending msg3 would attempt to decode the scheduled msg4. The UE that acquires its CRID may consider its RACH procedure successful and may send an ACK.

When selecting a preamble for an msg1 transmission, the UE first determines a group from a collection of groups of preambles from which the UE selects a particular preamble. The collection of groups are non-overlapping pools of preambles configured by the gNB in the cell. When a UE selects a preamble from a particular group, the gNB, once it receives the preamble, determines which group was selected by the UE. This specification method is adopted in Release 16-RACH, which has 4 steps to specify information about the path loss level between the UE and the gNB and the potential payload size of msg3. Specifically, in Release-16 RACH with 4 steps, the gNB configures two groups of preambles, Group A and Group B. If configured, (i) the UE selects Group B if the path loss between the UE and the gNB is above a configured threshold and if the expected payload size of msg3 is above a certain threshold, and (ii) otherwise, the UE selects group A.

After the UE sends msg1 and msg3, the UE begins to monitor for an expected response from the gNB. Specifically, once the last symbol of msg1 (or msg3) is sent, the UE starts a watchdog timer, called a watchdog window, on the first subsequent symbol of a CORESET, where reception of msg3 (or msg4) scheduling DCIs is expected. The monitoring window duration is configured using Radio Resource Control (RRC) on the UE. If re-sending is required is, the UE receives a DCI 0_0 during the window, which plans to retransmit msg3. The monitoring window is restarted after each new transmission.

In coverage enhancement CE scenarios, the PRACH signal is a UL signal that is degraded in decoding performance due to low SNR. To increase its performance, PRACH repetition may be a possible solution. However, introducing a functional PRACH repeat mechanism into Rel-17 that is both efficient and backwards compatible with Rel-16 is challenging.

As used herein, a “Rel-17 UE” is a UE capable of performing one or more of the features described herein that are not specified in Release-16 of the 5G standard. This terminology is not intended to limit the applicability of the features of this disclosure to a specific release of the 5G (NR) standard or specification.

In some embodiments, PRACH signal transmission with aggregation may be performed in a manner that is somewhat analogous to the transmission of PUSCHs with repetition. A first set of embodiments may be referred to as Scheme 1. This scheme involves PRACH signaling with aggregation, e.g. For example, a Rel-17 UE can send multiple PRACH signals in a sequence to Random Access Channel (RACH) Occasions (ROs) without initiating a Random Access Response (RAR) response monitoring window after each transmission. This is in contrast to Rel-16 PRACH signaling rebroadcast, where a UE initiates a RAR response monitoring window after each PRACH transmission, and only retransmits if the window expires without receiving a corresponding RAR message. A UE can use PRACH signaling with aggregation in different ways, e.g. B. as described below for a first embodiment and a second embodiment.

In the first embodiment, a UE can transmit the PRACH transmissions each using the same uplink transmit (UL-Tx) beam. This may allow the gNB to improve the received signal in terms of interference and noise ratio (SINR) of the received PRACH signal. Alternatively, the gNB may also use these aggregated PRACH transmissions to perform a form of uplink receive (UL-Rx) beam enhancement, in which the gNB attempts to transmit each of the PRACH aggregated transmissions using a different receive (Rx) beam to recieve. The set of Rx beams used by the gNB may be a set of narrow beams which together cover the range of the wide Rx beam originally used. Upon receiving the PRACH aggregated broadcasts that use different beams, the gNB determines the best one.

In the second embodiment, the UE may send each of the aggregated PRACH transmissions using a different UL-Tx beam to attempt to perform UL-Tx beam enhancement. The gNB can then indicate to the UE which UL Tx beam is the best. The set of Tx beams used by the UE may be a set of narrow beams which together cover the range of the wide Tx beam originally used. The UE can then be provided with information that assists the UE in determining which Tx beam was best received by the gNB. These embodiments are in 2A-2C shown, where 2A represents the use of consistent rays, 2 B the use of different transmission beams shows and 2C shows the use of different reception beams.

In both of these embodiments, sending a PRACH signal consisting of preamble repeats by the gNB can be used to perform some type of UL-Rx beam enhancement within those preamble repeats. This is a mechanism that can be deployed by the gNB using Rel-16 PRACH broadcasts and can still be deployed in addition to (i.e. in combination with) the PRACH aggregated broadcasts described herein.

In another mechanism, a UE performing PRACH sending with aggregation may send some retries using the same UL beam while sending other retries using different UL beams. Specifically, in a set of L aggregations, a UE may send N ≤ L repetitions using the same UL beam and then change the UL beam over the different sets of non-overlapping N repetitions. Each set of N reps can be consecutive or, alternatively, the sets of N reps can be interlaced. 3A and 3B show examples where L = 6 and N = 2, where 3A Sentences without interlacing shows and 3B interlaced sentences shows.

During Rel-16 PRACH signal repetition, a UE applies a power ramping behavior that increases the transmit power associated with each PRACH transmission. Rel-17-PRACH-Send with aggregation can have similar performance increase behavior as in Rel-16. This power ramp behavior can be configured with the same or different power ramp parameters. In other embodiments, a Rel-17 PRACH transmission with aggregation may elect to use the same transmit power on all PRACH signals.

In one set of embodiments, which may be referred to as Scheme 2, a RACH mechanism for Rel-17 UEs with CE capabilities is performed in parallel with Rel-16 UEs in the same resources. In particular, the Rel-17 RACH procedure allows UEs to send PRACH signals with aggregation in the same resources specified for a Rel-16 RACH procedure, i.e. i.e., the same ROs and preambles. This approach can be advantageous in terms of resource utilization because it does not require a separate set of PRACH resources.

With this scheme, a Rel-16 UE follows the legacy RACH procedure by selecting a preamble and RO resource according to the Synchronization Signal Block (SSB) index received with the highest Reference Signal Received Power (RSRP), and performs a PRACH transmission (from Msg1) in this RO. After the PRACH transmission, the UE starts a RAR response monitoring window that starts at the first Control Resource Set (CORESET) symbol after the PRACH transmission. The UE does not resort to PRACH retransmission unless the RAR window expires and a corresponding RAR is not received. At the same time, a Rel-17 UE uses the same RO and preamble determination scheme as the legacy RACH procedure. However, the Rel-17 UE sends PRACH signal repeats in later ROs associated with the same SSB; the UE does not need to start a RAR window until it sends the last configured retransmission. Behaviors of a Rel-16 and a Rel-17 UE in this scheme are in 3C shown. A Rel-17 UE has the option to start a RAR window after any of the PRACH broadcasts in the PRACH aggregation. This may promote early termination of the PRACH procedure as well as the UL-Tx beam enhancement procedure described below.

When a Rel-17 UE determines the sequence of PRACH sequences for broadcasts, a UE may follow a specific procedure to select preambles from the available set of ROs. One mechanism is to allow the UE intending to transmit L PRACH repeats to select preambles from ROs associated with the selected SSB index. More generally, a UE can select preambles from different ROs according to a specific selection procedure. This procedure can select preambles from ROs associated with the same SSB index or other ROs. This procedure may also be deterministic (i.e., a UE wishing to perform L PRACH transmissions selects a deterministic set of L preambles) or random (i.e., a UE wishing to perform L PRACH transmissions may choose from the procedure of L preambles exhibit randomness).

The following nomenclature is used to provide a general description of the preamble selection procedure. The ith preamble in a set of L preambles may be denoted by r _i , the label of the RO carrying the PRACH broadcast, and by p _i , the label of the preamble sequence included in the pool of available preamble sequences in the RO can be used. Similar to the legacy process, it may be the case that the UE determines the set of L preambles based on an SSB index, denoted by s, which is determined by the UE during the phase of an SSB acquisition corresponding to a PRACH Transmission phase precedes. For example, the SSB index s can be selected as the one with the highest recorded RSRP value.

The set of RACH resources provided by the RACH configuration parameters consists of a set of ROs, each associated with a specific SSB index. An RO label r = ( ^rs , r ^t ) can therefore consist of two indices: the SSB index r ^S associated with the RO and the relative RO index r ^t from the set of ROs associated with are associated with the SSB index r ^s . For example, if there are 4 ROs associated with the SSB index s, they would be labeled (s, 1), (s, 2), (s, 3), (s, 4). Conversely, if there are, for example, 4 available SSB indices, the set of tth ROs associated with each of the SSB indices is (1, t), (2, t), (3, t), (4, t). The time and frequency resource configuration of the ROs may result in different arrangements of the ROs. For example, with a frequency-first ordering of ROs, the ROs can be ordered by first cycling through r ^t index ( 4A) or is first switched through by r ^s index ( 4B) . The aforementioned arrangements of ROs are not necessarily the explicit configuration of PRACH resources as provided to the UE via RRC configurations. In fact, these arrangements are most likely the implicit result of certain PRACH configurations. For example, the arrangement in 4A be the result of there being 4 SSB indexes, 4 ROs per SSB index in an association period, and this PRACH configuration period of 4 sets of ROs consists that have been subjected to Time Division Multiplexing (TDM) and there are 4 FDM subjected ROs within a set; 4A shows an association period. Deviating from this shows 4B an arrangement that is the result of having 4 SSB indices, 1 RO per SSB index in an association period, and this one PRACH configuration period consists of 4 ROs subjected to frequency division multiplexing (FDM); 4B shows four association periods.

Selecting the ith preamble in a set of L preambles consists of selecting r _i , the label for the RO to be used when sending the ith preamble, and p _i , the preamble used in that RO. Index. There can be different rules, e.g. B. five rules, referred to herein as R1 to R5, to select r _i for i E {1, ..., L}.

R1: a UE can select r _i in any order. This corresponds to a selection of L preambles without structure; this may be a simple mechanism but may not support a gNB decoding operation.

und ein beliebiger gültiger Wert von $r_1^t$

ist. Dies ist eine strukturiertere Version von R1, bei der alle ausgewählten ROs mit dem gleichen SSB-Index assoziiert sind.R2: a UE can select r _i such that $r_i^s=s$

and any valid value of $r_1^t$

is. This is a more structured version of R1, where all selected ROs are associated with the same SSB index.

und $r_1^t=1$

und verbleibende r_i werden derart ausgewählt, dass $r_i^s=s$

und $r_i^t$

ein beliebiger gültiger Wert ist. Dies zwingt das UE, eine Präambelsendung in der ersten verfügbaren RO zu initiieren, die mit dem SSB-Index assoziiert ist; dies kann eine Auswirkung auf die Decodierungskomplexität für den gNB haben (wie unten detaillierter erläutert).R2a: a UE can select r ₁ such that $r_1^s=s$

and $r_1^t=1$

and remaining r _i are selected such that $r_i^s=s$

and $r_i^t$

is any valid value. This forces the UE to initiate a preamble broadcast in the first available RO associated with the SSB index; this may have an impact on the decoding complexity for the gNB (as explained in more detail below).

Dies kann für starke Struktur in der Auswahlprozedur sorgen; der Wert von X kann 1 oder andere Werte sein. Wenn R3 verwendet wird, kann jede PRACH-Sendung, von einem Satz konsekutiver PRACH-Sendungen, die einen SSB-Index teilen, einen RO-Index aufweisen, der um eine eingestellte ganze Zahl (die ganze Zahl X) größer ist als der RO-Index der vorherigen PRACH-Sendung. X = 1 erlaubt es einem UE, L konsekutive ROs zu verwenden, die mit dem SSB-Index assoziiert sind. Die eingestellte ganze Zahl (X) kann RRC-konfiguriert sein oder durch einen Systeminformationsblock konfiguriert sein, oder in dem 5G-Standard spezifiziert und in dem UE programmiert sein (und bei Starten des UE konfiguriert sein).R3: another variant to R2a is to add more structure to the selection of r _i , i > 1, ie, $r_i^t=r_{i-1}^t+X.$

This can provide strong structure to the selection process; the value of X can be 1 or other values. When R3 is used, each PRACH transmission, of a set of consecutive PRACH transmissions that share an SSB index, can have an RO index that is a set integer (the integer X) greater than the RO Index of the previous PRACH broadcast. X = 1 allows a UE to use L consecutive ROs associated with the SSB index. The set integer (X) may be RRC configured, or configured by a system information block, or specified in the 5G standard and programmed in the UE (and configured upon startup of the UE).

In diesem Fall können andere Verfahren verwendet werden, um $r_i^s$

auszuwählen. Ein Verfahren ist, die L aktuellsten ROs ungeachtet ihrer SSB-Indexassoziation auszuwählen; dies kann hilfreich sein, um Latenz beim Senden der Präambeln zu reduzieren.R4: another variation to R3 is to not associate r _i ,i > 1 with the same SSB index, ie $r_i^s\ne s.$

In this case, other methods can be used $r_i^s$

to select. One method is to select the L most recent ROs regardless of their SSB index association; this can be helpful to reduce latency when sending the preambles.

verwendet wird, ist, die L aktuellsten ROs ungeachtet ihrer SSB-Indexassoziation auszuwählen, während gleichzeitig vermieden wird, ROs mit bestimmten Eigenschaften zu haben, z. B. FDM-unterzogene ROs oder ROs ohne ausreichenden Zeitrahmen dazwischen. Dies kann dazu beitragen, die Auslastung des UE-Betriebs zu reduzieren.R5: another variant of R4 in the process that is available for selection $r_i^s,i>1$

is to select the L most recent ROs regardless of their SSB index association, while avoiding having ROs with certain properties, e.g. B. ROs subjected to FDM or ROs without sufficient time frame in between. This can help reduce the load on UE operations.

There can be different rules, e.g. B. two rules, here referred to as P1 and P2, to select p _i for i ∈ {1, ..., L}.

P1: p _i can be randomly selected from the pool of available preambles in the ith RO; this can be a simple mechanism to describe the operation, although it has no structure in the set of selected preambles and therefore can complicate the gNB decoding process.

P2: p _i can be determined depending on the preamble selected in the previous broadcast, e.g. B. p _i = p _i-1 + P for an integer value of P while p ₁ is randomly selected from the first RO; this gives more structure to the set of selected preambles. The integer P can be a set integer, e.g. B. it may be available (e.g. known) to both the UE and the gNB at the time the preamble is sent. One possibility is to have P = 0, in which case selected preambles are the same for all broadcasts.

Below are some examples of how the procedure for selecting the L preambles can be carried out. In the above determination rules, there may be a restriction on the selected set of L PRACH broadcasts in that they must all occur within an SSB-RO association period. That is, for N SSBs, all L preambles must be selected in a set of ROs in which the N SSBs are fully mapped at least once. This has the advantage of maintaining a legacy nature of the RACH procedure, which guarantees that any UE performing a RACH operation will complete an msg1 transmission within the duration of the association period which would consequently guarantee certain latency levels for the RACH procedure as well as limit the UE complexity.

When considering the transmission of L PRACH transmissions by Rel-17 UEs, a gNB does not necessarily know the identity of the UE making a PRACH transmission and whether it is a legacy UE or a Rel-17 UE. Assuming that the maximum candidate value for a number of repetitions is M, the gNB also does not know the exact value of L ≤ M that the UE has selected as the number of PRACH transmissions. Furthermore, in the case where a UE transmits PRACH repeats using the same beam, the gNB can employ these transmissions for a common decoding operation, which can increase the decodability of the PRACH transmissions. Therefore, the gNB has two options when decoding PRACH broadcasts. First, a gNB can independently treat each PRACH transmission as if it came from a legacy UE. Second, given a PRACH transmission, a gNB can make an assumption that a Rel-17 UE has performed that transmission, and thus use that transmission along with the corresponding potential L - 1 other repeats to perform joint decoding.

Option 1 provides a simple decoding process for the gNB with limited performance, while the second process can provide better decoding performance at the expense of higher decoding complexity. The main reason for this complexity is the fact that a gNB must consider different hypotheses for the potential sequence of L PRACH transmissions when decoding a PRACH transmission.

For example, the preamble selection process performed on R3 with used) follows. Given a selected SSB index i, when a gNB receives a preamble p in a RO r, there are different hypotheses as to which UE created the preamble. For example, it may be (i) a UE performing a PRACH transmission (e.g. Rel-16 UE), (ii) a UE performing L = 2 PRACH transmissions, and where this preamble is either the corresponds to the first or the second of these transmissions, or (iii) a UE which carries out L = 3 PRACH transmissions (where the present preamble corresponds to either the first or the second or the third of these transmissions). There are analogous hypotheses for L > 3. 4C shows a selection of the hypotheses that a gNB makes when decoding a received PRACH transmission under the configuration that Rel-17 UEs can attempt PRACH transmissions with L aggregations.

Without restrictions, the number of potential hypotheses for UEs that could perform a preamble broadcast at any RO is M. The decoding procedure of the gNB can be strongly influenced by the number of potential hypotheses as to which case this preamble broadcast corresponds to. To evaluate the decoding complexity of the gNB, the following distinction can be made in the implementation of the decoding process on the gNB side.

Joint Decoding (JD) Approach: In this implementation, the gNB can share the preambles sent in all iterations in the decoding procedure. In this approach, the gNB can determine or hypothesize which set of preambles belong to a set of repetitions, so that the decoding process can be based on that set of preambles.

Repeated-decoding (RD) approach: in this implementation, the gNB can successively and independently attempt to decode each preamble broadcast, thus declaring that the preamble broadcast is successful if any of the repetitions are received successfully. In this approach, a gNB may primarily require determining or hypothesizing whether a preamble broadcast is from a legacy UE or a Rel-17 UE performing replays.

Depending on the implementation, certain measures can be taken to limit the decoding complexity of the gNB. The following are three example restrictions that may limit which preambles a UE targeting L PRACH repeats can use.

wäre die maximale Anzahl an Hypothesen, die durch einen RD-gNB aufgestellt wird, 2 in $N\text{'}\left(\lfloor \frac{N}{N\text{'}}\rfloor -M\right)$

und 1 in $M-N\text{'}\left(\lfloor \frac{N}{N\text{'}}\rfloor -M\right).$

In a first restriction, a UE may be limited to transmitting a set of L preambles in only a subset of the ROs available for legacy preamble transmission. For RD, this limits the number of hypotheses raised by the gNB to only one (legacy) in the ROs, which are only allowed to use legacy UEs. In particular, a UE may be instructed to use only a set of N'< N ROs from the N available ROs (ie, use only its own subset of the N available ROs) to transmit the first preamble in a set of L preambles, and then the subsequent ones can be sent in consecutive subsequent ROs (e.g. R3 with X = 1). The own Subset (ie the set of N' ROs may be a set own subset, ie it may be a separate subset that is available (ie known) to both the UE and the gNB at the time of sending the preambles. The set from N' ROs can be RRC-configured. The set of N' ROs can be uniformly distributed among the N ROs. If M ≤ $\lfloor \frac{N}{N\text{'}}\rfloor$

The maximum number of hypotheses generated by an RD-gNB would be 2 in $N\text{'}\left(\lfloor \frac{N}{N\text{'}}\rfloor -M\right)$

and 1 in $M-N\text{'}\left(\lfloor \frac{N}{N\text{'}}\rfloor -M\right).$

In a second restriction, a UE may be restricted to transmit only the first preamble broadcast of a set of L repeats on the first RO in the association period corresponding to the selected SSB index. With this approach, for JD, the number of hypotheses made by the gNB when it receives a preamble in an RO depends on the relative RO position with the association period. For example, if the RO is the i-th RO associated with the target SSB index in the association period, the number of potential hypotheses for UEs that could perform this preamble broadcast is M - i + 1. This means, that the first RO in the association period may require a gNB to hypothesize L, while the gNB only hypothesizes 1 for the last RO.

oder weniger Wiederholungen entweder bei der ersten RO oder der (N/2)-ten RO in der Assoziierungsperiode gestartet werden, während die erste Präambelsendung in einem Satz aus mehr als $\frac{M}{2}$

Wiederholungen lediglich bei der ersten RO gestartet werden kann. Dies bietet dem UE mehr Flexibilität beim Starten seiner Sendungen auf Kosten größerer Decodierungskomplexität am gNB. Für JD kann die Anzahl an Hypothesen, die durch einen gNB bei jeder RO aufgestellt werden können, kleiner sein, als wenn zufällige Startpositionen für L Präambelsendungen zugelassen werden. Eine Verallgemeinerung der dritten Beschränkung ist, RO-Indizes für die beginnenden Präambelsendungen bereitzustellen, die unterschiedlichen Werten von L in einer feineren Granularität als L/2 entsprechen. Die oben beschriebenen Beschränkungen können wiederverwendet werden, während die Assoziationsmusterperiode anstelle der Assoziierungsperiode verwendet wird.In a third restriction, a UE may be instructed to transmit the first preamble in a set of L PRACH repetitions in an RO position that is dependent on the number of repetitions L. For example, assuming there are N ROs in the association period corresponding to the selected SSB index, the first preamble broadcast in a sentence can be output $\frac{M}{}$$\frac{}{2}$

or fewer repetitions are started at either the first RO or the (N/2)th RO in the association period, while the first preamble broadcast in a sentence consists of more than $\frac{\mathrm{<figure-callout\; id="2"\; label="M"\; filenames="DE102023110524A1\_0017.png,DE102023110524A1\_0018.png"\; state="\{\{state\}\}">M</figure-callout>}}{2}$

Repetitions can only be started at the first RO. This provides the UE with more flexibility in starting its transmissions at the expense of greater decoding complexity at the gNB. For JD, the number of hypotheses that can be made by a gNB at each RO can be smaller than if random starting positions are allowed for L preamble broadcasts. A generalization of the third constraint is to provide RO indices for the beginning preamble broadcasts that correspond to different values of L at a finer granularity than L/2. The restrictions described above can be reused while using the association pattern period instead of the association period.

In Scheme 2, a Rel-17 UE only sends a PRACH signal with aggregations if the UE is in a Coverage Enhancement (CE) scenario. Specifically, a UE makes such a decision based on the received RSRP of the best SSB index it has selected. Such a decision can be made in different ways. For example, in a first embodiment, a UE may have a threshold γ and the UE may use Rel-17 PRACH signal aggregations if the received RSRP of the best SSB is less than or equal to γ; is, otherwise it can use the Rel-16 approach.

In a second embodiment, a UE may have multiple threshold values γ ₁ ≥ γ ₂ ≥ γ ₃ ≥ ··· ≥ γ _N. If the received RSRP of the best SSB is greater than γ ₁ , it uses Rel-16 PRACH transmission. If the received RSRP of the best SSB is greater than γ ₂ and less than or equal to γ ₁ , then it uses Rel-17 PRACH signal aggregation with a certain number of retransmissions. If the received RSRP of the best SSB is greater than γ ₃ and less than or equal to γ ₂ , it uses Rel-17 PRACH signal aggregation with a larger number of retransmissions, and so on. 4D represents this process for determining PRACH aggregation levels.

Configuring Rel-17 UEs with PRACH signal aggregation to conduct their broadcasts in the same resources as Rel-16 UEs may be considered unfair behavior in the sense that such behavior results in, for example, a higher contention rate for Rel-16 UEs may result, which increases latency in the initial access procedure. However, there are counterarguments to these concerns. For example, a UE only performs PRACH signal aggregation if it is in a CE scenario. In this case, a single PRACH transmission is exposed to poor channel conditions and is therefore typically received with a low SNR. If this PRACH transmission collides with another PRACH signal from a Rel-16 UE, its effect will likely be only limited levels of interference and therefore is unlikely to significantly impede the Rel-16 UE's initial access procedure. Furthermore, a Rel-17 UE in a CE situation may be considered to be in an inherently disadvantageous situation since its PRACH broadcasts are likely to be missed or not decoded. Accordingly, use of PRACH signal aggregation may be considered a mechanism available for a Rel-17 UE to overcome a drawback, e.g. B. poor SNR to compensate.

In this setting, a gNB receives PRACH signals without being able to communicate these signals with either (i) Rel-16 UEs broadcasting individually PRACH or (ii) Rel-17 UEs broadcasting PRACH with aggregation to be able to carry out, associate. In other words, from a gNB perspective, a Rel-17 UE performing PRACH broadcast with, for example, 5-level aggregation can be viewed as 5 virtual Rel-16 UEs. If this situation is not handled correctly, it can result in misconfiguration of a Rel-17 UE that can receive different RAR messages, each with different configurations and TC-RNTI.

One way to handle such a situation may be to configure the Rel-17 UE to perform PRACH sending with aggregation to respond to at least one RAR message corresponding to the preamble IDs of its PRACH broadcasts. This allows the gNB to automatically resolve the problem of dealing with multiple virtual UEs as soon as the gNB receives at most one Msg3 corresponding to at most one from the set of virtual UEs. As used herein, a “preamble ID” means a complete identification of the preamble sequence used.

Alternatively, a Rel-17 UE may respond to more than one RAR message corresponding to the preamble IDs of its PRACH transmissions, but may indicate in these RAR reply messages which preamble IDs are those that are part of its PRACH transmissions are. Once a RAR response message has been decoded, the gNB is made aware of the preamble IDs used by the same Rel-17 UE and can then act accordingly.

5A and 5B shows examples of messages between the gNB and both UE types when PRACH sending with aggregation is enabled. A Rel-17 UE that performs PRACH aggregated sending can only send a RAR window after sending the last PRACH repeat. The UE may use a different RAR window configuration than that configured for a Rel-16 UE sending a PRACH broadcast. In this case, the gNB may be aware of the potential PRACH aggregations sequences and send RAR messages in the corresponding RAR windows, which could be initiated by potential Rel-17 UEs performing PRACH aggregations. The UE may use the same RAR window configuration as that configured for Rel-16. In this case, the gNB can correspond with the potential Rel-17 UE with the same RAR message as it does for a Rel-16 UE.

In this communication, a UE can send a response to one RAR message, multiple RAR messages, or all RAR messages. One can argue that the aforementioned operation of the gNB wastes resources since, e.g. B., a gNB may respond to receiving multiple PRACH signals from a Rel-17 UE that sends PRACH with aggregation by sending multiple RAR messages. However, such an event is not likely since only one Rel-17 UE will perform PRACH transmission with aggregation in a CE situation due to the expected low SNR of the received PRACH signal. If multiple RAR messages are actually received by the UE, a UE can then select the one received with the highest RSRP to respond to. This may be particularly helpful when the PRACH signals are transmitted by the UE using different and narrower beams than in the second embodiment described above and in 2A-2C is shown. This additional advantage of implementing some form of UL beam enhancement comes at the expense of sending multiple RAR messages. A UE may use sending multiple RAR reply messages to inform the gNB of information that may be useful for a beam enhancement operation. For example, a UE may indicate to the UE the received signal strength associated with each RAR message.

When a Rel-17 UE sends a PRACH signal with L-level aggregation, it is required to start a RAR response monitoring window at least after sending the Lth PRACH signal. However, a UE can also start a RAR response monitoring window at earlier times after the first PRACH signal is sent. If the UE operates in this manner, a UE may receive a RAR response message corresponding to one of the transmitted PRACH signals before transmitting all L PRACH signals. Assume that the UE receives a RAR message before sending the jth PRACH signal (where “before” in this context means that the time between the received RAR reply message and the jth signal is longer than the time , which is required to process the received message and stop sending the PRACH signal), the UE can behave as follows.

In a first behavior, referred to as Behavior-1, the UE may stop transmitting the jth PRACH signal and all subsequent PRACH signals. This may be a possible solution if PRACH signals within the PRACH aggregation are sent by the UE using the same UL beam. Therefore there is Receiving a RAR message indicates that a PRACH transmission was successful and repeats are therefore no longer necessary.

In a second behavior, referred to as Behavior-2, the UE may continue sending the jth PRACH signal and all subsequent PRACH signals as if a RAR message has not yet been received.

In a third behavior, referred to as Behavior-3, the UE may continue transmitting the jth PRACH signal and all subsequent PRACH signals. To use these broadcasts, the gNB must identify the set of PRACH signals that belong to the PRACH aggregation. Therefore, with this option, the UE can report the IDs of the upcoming PRACH shipments to the gNB. This can be useful in two ways as follows.

In a first variant of the third behavior, referred to as Behavior-3a, if PRACH aggregations were sent using a different UL Tx beam, in an attempt to identify the best narrow UL beam, continuing such transmission may result in the UL beam improvement. The gNB can send a RAR-like message after the last PRACH transmission indicating which preamble was best received. Rel-16 PRACH broadcast includes PRACH formats that include episode repeats. These repeats can be used by the gNB to perform a UL-Rx beam enhancement procedure. In this case, Behavior 3a can perform both UL-Tx and UL-Rx beam enhancement.

In a second variant of the third behavior, referred to as behavior-3b, the UE can send each PRACH aggregation using the same UL beam. This may allow the option that the gNB can perform a UL-Rx beam enhancement procedure: the UE can send the remaining PRACH signals using the best UL-Tx beam and the gNB can use this UL-Tx beam to achieve the Find the best narrow UL Rx beam.

6A-6D show different possibilities for the behavior of a Rel-17 UE regarding remaining PRACH signals after a RAR message has been received. When an identification of the ROs used in PRACH aggregation is provided to a gNB using a specific Msg3, there may be several options. One option is that the identification of each RO can be done in terms of the RO's absolute time and frequency positions. Another option is that the identification can be done in terms of time and frequency offsets with respect to the RO associated with the Msg3 sent. For example, a RO specified in the PRACH aggregation may be in terms of slots (Time Division Multiplexed (TDMed)) ROs before or after the particular RO and (Frequency Division Multiplexed (FDMed)) ROs above and below the particular RO. This approach can be useful to reduce the overhead of specifying absolute time and frequency values of multiple ROs.

If a UE initiates a RAR monitoring window after sending a PRACH other than the last one in the L aggregations, it is possible that the RAR monitoring window may overlap with time periods that include ROs where the UE should send the subsequent PRACH repeat . In this case, the UE may not be able to monitor for the DL-RAR message and perform the UL-PRACH retry simultaneously. In this case, certain priority rules (such as the three priority rules described below) may be useful. In a first priority rule, the UE may prioritize the transmission of the PRACH repeat over monitoring for the RAR message. If the UE is expected to prioritize the transmission of the PRACH repeat, a time frame can be established between the time to transmit the PRACH signal and the time to receive or monitor the PDCCH corresponding to the RAR message. In particular, a UE is not expected to receive a PDCCH corresponding to the RAR message after a time frame measured with respect to sending the PRACH repeat. The time frame can be established from the end of the last symbol carrying the PRACH repeat or the end of the last symbol for the RO where the PRACH is sent. The duration of the time frame may be equal to the time required to switch from UL transmit to DL receive: this duration T _switch may be equal to the same switching time value defined in the legacy NR specification, or any one different value. The time may also be extended to accommodate the time required to complete the broadcast of the PRACH, as the time frame is established from the beginning of the PRACH broadcast. When the statement "the time for receiving/monitoring the PDCCH corresponding to the RAR message" is mentioned (in the standard), the time may be a) the time of the first symbol carrying the PDCCH, or b) the time for the first symbol of the CORESET, which carries PDCCH.

An additional time frame can be established before the broadcast of the PRACH repeat. In particular, since a PRACH transmission is compared to the reception of a PDCCH, which is a RAR Message corresponds to, is prioritized, sufficient time can be reserved before the start time for a PRACH transmission to allow a UE to switch from DL reception to UL transmission. In particular, a time frame can be created from a time before the start time of a PRACH broadcast with a duration T _switch (or other values as mentioned above) to the start time of a PRACH broadcast. At this time frame, a UE is not expected to receive a PDCCH corresponding to a RAR message. The start time of a PRACH transmission may be the time of the first symbol carrying the PRACH repeat or the first symbol for the RO where the PRACH will be transmitted.

When a gNB attempts to schedule a RAR message according to the successful reception of a PRACH transmission, it does not know in advance whether this PRACH transmission is made by a legacy UE or by a Rel-17 UE that repeats PRACH carries out. If the UE is a Rel-17 UE, the RAR message must be scheduled according to the aforementioned time frame, while for a legacy UE this is not necessary. Therefore, a gNB may take a conservative approach and maintain the time frame in anticipation that the UE may be a Rel-17 UE performing PRACH repeats. This conservative approach may have an indirect effect on legacy UE operations since a portion of the RAR window that does not meet the PRACH retry opportunity time frame cannot be used by the gNB. In contrast, a gNB may take an aggressive approach and not stick to the time frame. Since a UE is not expected to receive this RAR, this behavior is essentially identical to not sending this RAR message for Rel-17 UEs. This reserves the operation and potential performance impact on legacy operations at the expense of not using previous RAR broadcasts to send msg2 to Rel-17 UEs.

In a second priority rule, the mechanism for determining ROs for PRACH replay may create a set of potential ROs that may include more than one available RO for sending a PRACH replay. The i-th PRACH repetition can be sent, for example, in any RO within the set RO _i , which can contain more than one RO. In this case, skipping the use of one or more ROs in favor of monitoring for the RAR message cannot entirely eliminate the possibility of the UE sending the PRACH repeat. With this observation in mind, the UE can prioritize monitoring for the RAR message over sending overlapping ROs as long as there is at least one potential RO to send the PRACH repeat. With a third priority rule, a UE can always prioritize monitoring with respect to the RAR message.

Depending on the UE behavior, a Rel-17 UE may be required to send the gNB some additional information after receiving a RAR message, e.g. B. it may be necessary to send to the gNB the IDs of the preambles that were and will be sent by the UE during PRACH aggregation. This information may be included in the corresponding Msg3. For example, (i) this information may be added in the payload of Msg3 or (ii) the information may be included in the MAC header of the PUSCH corresponding to Msg3. The latter approach can be useful to help decode Msg3 if the MAC header was successfully decoded but not the PUSCH payload. In this case, the information extracted from the MAC header may allow the gNB to receive repetitions of Msg3, as explained below in the context of a message combination.

In another mechanism, a Rel-17 UE may select a preamble to use in a first PRACH transmission from the PRACH aggregations, and then the UE is restricted to using the same preamble sequence in all future PRACH replays use. By using this mechanism, the gNB is able to identify the sequence of PRACH aggregation broadcasts once the gNB identifies the preamble sequence used by the Rel-17 UE. This reduces the overhead of transmitting the preamble ID information of all PRACH transmissions carried out by the Rel-17 UE since only the RO positions are specified in the Msg3 payload and MAC header. In particular, a reduction of L _* log ₂ 64 = 6L bits can be achieved for an L-level PRACH aggregation, assuming 64 preambles per RO.

For each Msg2 (RAR message) scheduled by the gNB, there is a corresponding resource allocation for a PUSCH corresponding to the expected Msg3 (RAR reply message) by the UE. A UE with Rel-17 PRACH aggregation is required to respond to at least one Msg2 by sending the corresponding Msg3. Then the resource allocations for all remaining hypothetical Msg3s remain to be managed.

One option, referred to as resource reservations, can be used as follows. The Resource allocations can be reserved in anticipation of the upcoming Msg3. This is a direct consequence of the gNB behavior, which treats all PRACH broadcasts as coming from different virtual UEs. This is the simplest behavior, although it results in wasted resources. This would be a direct result of UE Behavior-1 and Behavior-2.

Another option, called resource sharing, can be used as follows. The reservation of such resources can be canceled upon determining that the corresponding PRACH broadcasts belong to the same UE. This requires the gNB to obtain such information and is therefore a valid option for UE Behavior-3. This can be done by allowing the Rel-17 UE to include in Msg3 all preamble IDs sent by the UE. When the gNB receives this Msg3, it knows which other Msg3 reservations correspond to PRACH aggregations and can therefore release their resources.

Another option, called message combination, can be used as follows. The UE may be allowed to use the extra resources to perform Msg3 retries or aggregations. This also requires that the gNB be informed that these resource allocations belong to PRACH shipments in a PRACH aggregation. The same specifying mechanism that can be used in a resource share can be used here. The Msg3 repeats can be used by the gNB to improve the reception of the RAR message response. This option is only valid if the gNB is able to obtain information regarding the preamble IDs in the UE's PRACH aggregation, while still being unable to decode the payload of Msg3; this may be the case if the UE includes the preamble ID information in the MAC header of Msg2.

Both resource reservations and resource release may require a specific time frame to be feasible. In particular, a Msg2 containing the required information must be received sufficiently far in advance of the subsequent Msg3 in order to release or combine the resources. For example, any Msg3 resources that occur after the receipt of Msg2 but before sufficient time has elapsed to process the Msg2 are automatically handled according to the resource reservation process. Also, any Msg3 transmission informing the gNB about (i) the UE behavior regarding PRACH aggregated transmissions and about (ii) the associated Msg3 resources must be decoded by the gNB and its information must be processed by the gNB.

The embodiment of 5A may include the following measures in the standard. First, a Rel-17 UE is allowed to transmit PRACH signals with L-level aggregation (ie, without using a RAR response monitoring window after each PRACH transmission) if the UE satisfies the CE condition specified therein Aggregation level corresponds. Secondly, Rel-17 UE sending PRACH signal with aggregation can be employed with or without power ramp behavior. Third, once a PRACH signal with aggregation is sent, a Rel-17 UE responds to at most one corresponding RAR message. A UE may be configured to respond to the first RAR message received, or a UE may be configured to wait for possible multiple RAR messages. In the case of the latter, it can select the RAR message it responds to based on some criteria. An example of such a criterion is the RSRP level of each RAR message. Another example is an indication added by the gNB in the RAR message indicating the RSRP level of the received PRACH signal.

In one set of embodiments, which may be referred to as Scheme 3, a RACH mechanism for Rel-17 UEs with CE capabilities may be performed in parallel with Rel-16 UEs in separate resources. In particular, the Rel-17 RACH procedure allows UEs to send PRACH signals with aggregation in resources other than those used for a Rel-16 RACH procedure. The set of separate resources for Rel-17 UEs may consist of separate ROs, or separate preambles within the same ROs, or a combination of both. With such separation of resources, a gNB is able to determine the presence of Rel-17 UEs performing a RACH procedure with PRACH aggregation and handle the broadcasts from the UEs accordingly.

In this scheme, a Rel-17 UE follows the legacy RACH procedure by selecting a preamble and RO resource according to the SSB index received with the highest RSRP. However, the UE selects those resources in the set of resources that are configured for a Rel-17 RACH procedure with PRACH aggregation. After transmitting, a UE can start a RAR response monitoring window after the last PRACH repetition, after each PRACH repetition, or proceed according to other options. In any configuration, a gNB is responsible for the UE behavior with regard to the RAR response monitoring window and acts accordingly.

Although a Rel-17 UE may perform a PRACH broadcast with L aggregations using dedicated resources, it may still have the ability to start these L aggregations at any resource suitable for sending the first PRACH broadcast . This may affect the complexity of the decoding process at the gNB, as explained in Scheme 2 above. Therefore, the solutions mentioned in the explanation above are also applicable in this case.

In this scheme, a Rel-17 UE only sends a PRACH signal with aggregations if the UE is in a CE scenario. A UE makes such a decision based on the received RSRP of the best SSB index using one or different thresholds as explained in Scheme 2.

When a Rel-17 UE sends a PRACH signal with L-level aggregation, it is required to start a RAR response monitoring window at least after sending the Lth PRACH signal. However, a UE can also start a RAR response monitoring window at earlier times after the first PRACH signal is sent. If the UE operates in this manner, the gNB may provide the UE with a RAR response message corresponding to one of the transmitted PRACH signals before the UE transmits all L PRACH signals. This gives the UE the opportunity to complete the RACH procedure earlier with reduced latency, but at the cost of increased complexity when monitoring for multiple RAR instances. Once it receives a RAR message, the UE has the same options (Behavior-1, Behavior-2 and Behavior-3) regarding sending the remaining PRACH signals.

Depending on the UE behavior, a Rel-17 UE may be required to send the gNB some additional information after receiving a RAR message, e.g. B. the IDs of the preambles that were and are still being sent by the UE during PRACH aggregation. This information may be included in the corresponding Msg3. For example, (i) this information may be added in the payload of Msg3 or (ii) the information may be included in the MAC header of the PUSCH corresponding to Msg3. The latter can be useful to help decode Msg3 if the MAC header was successfully decoded but not the PUSCH payload. In this case, the information extracted from the MAC header may allow the gNB to receive repetitions of Msg3, as explained above in the context of a message combination.

Alternatively, a Rel-17 UE can combine the preamble sequences used in PRACH aggregated transmission. In particular, a Rel-17 UE may select a preamble to use in a first PRACH transmission from the PRACH aggregations, and then the UE is restricted to using the same preamble sequence in all future PRACH replays. By using this mechanism, the gNB is able to identify the sequence of PRACH aggregation broadcasts once the gNB identifies the preamble sequence used by the Rel-17 UE. Since the RO configuration for PRACH aggregated sending is a separate configuration from Rel-16, there is a natural connection behavior in the ROs used for PRACH aggregated sending. Therefore, when preamble sequences are also connected, this allows the gNB to uniquely determine the sequence of PRACH preambles and ROs in a PRACH aggregation by detecting the first preamble sequence and without additional information from the UE.

If the UE sends multiple PRACHs, they may be associated with different SSBs or the same SSB as described in this disclosure or using any other method. In this case, it is important to determine which beam should be applied for the subsequent transmissions or receptions in the initial access procedures, Msg2, Msg3, Msg4 and the PUCCH containing the Hybrid Automatic Repeat Request (HARQ) information for Msg4 carries.

Beam handling for Msg2 reception can be performed as follows. If the PRACH repeats sent are associated with the same SSB, e.g. For example, if PRACHs are sent in ROs associated with the same SSB, the UE may assume that Msg2, e.g. B. the Msg2-PDCCH or the Msg2-PDSCH, is sent using the same beam as that used to send the SSB associated with PRACH repeats. In other words, the UE may assume that the beam used for Msg2 (DM-RS of Msg2-PDCCH or Msg2-PDSCH) has the same Quasi-Colocation (QCL) characteristics for the SSB and the channel state Information reference signal (CSI-RS) associated with one of the PRACH repeats.

If the PRACH repeats sent are associated with different SSBs, e.g. B. PRACHs are sent in ROs that have under are associated with different SSBs, any of the following approaches can be used to assist the UE in determining which beam to use for receiving Msg2, e.g. B. Msg2-PDCCH or Msg2-PDSCH.

• Der Strahl, der für Msg2 (DM-RS aus Msg2-PDCCH oder Msg2-PDSCH) verwendet wird, weist die gleichen QCL-Eigenschaften für einen bestimmten SSB/CSI-RS auf, die mit bestimmten PRACH-Wiederholungen assoziiert sind, welche gemäß einer bestimmten Regel bestimmt werden, für die ein paar Beispiele im Nachfolgenden gegeben werden.

To receive a single RAR after the last PRACH repetition or earlier, the properties of the transmit beam for Msg2, e.g. B. Msg2-PDCCH or Msg2-PDSCH, can be determined as follows:

• The beam used for Msg2 (DM-RS from Msg2-PDCCH or Msg2-PDSCH) has the same QCL properties for a particular SSB/CSI-RS associated with particular PRACH repeats, which according to a certain rule, for which a few examples are given below.

The SSB associated with the last or first PRACH transmission can be assumed to be the QCL source reference signal (RS) for Msg2. Also, the Random Access Radio Network Temporary Identifier (RA-RNTI) is determined based on the selected PRACH to determine which beam to use for receiving Msg2.

Because the PRACH repeats are associated with different SSBs, each has a different measurement quality, such as RSRP. Due to channel reciprocity, the best measured SSB beam on the UE side will correspond to the best measured PRACH on the gNB side. In this case, it is advantageous that this beam, ie the beam corresponding to the best measured SSB, can be used for Msg2 transmission in order to increase the probability of correct reception of Msg2. This is in 7A exemplified in which it is determined that SSB2 is the SSB with the best measurement quality and the UE assumes that SSB2 is the QCL source RS for Msg2. Also, the RA-RNTI is determined based on the selected PRACH associated with the best measured SSB.

Another possibility is that the UE attempts to receive Msg2 in a RAR window using different beams in different portions of the RAR window. One possibility, assuming L PRACH repeats are sent, is to divide the RAR window into "L" equal sections. In each section, the UE assumes that the beam of Msg2 has the same QCL characteristics of one of the SSBs associated with PRACH repetition. In particular, for the PDCCH monitoring occasions that fall within a certain portion of the RAR window, the UE assumes that the SSB associated with that portion is used as the QCL reference signal for receiving Msg2. The Msg2 receive beams in the RAR window may have the same order as the transmitted PRACH, as in 7B shown. It is worth noting that once the UE successfully receives one of the RAR responses in one of the earlier portions of the RAR window, it is not necessary for the UE to monitor each section in a RAR window. In each section, the RA-RNTI is determined based on the selected PRACH. The transmitted PRACH repeat can be arranged based on its transmission position in the time domain, frequency domain, RACH opportunity index, preamble index. For example, the order may be: first in increasing order of RACH opportunity index in the frequency domain, second in increasing order of PRACH opportunity index in the time domain, etc.

To receive multiple RARs for each transmitted PRACH repeat associated with different SSBs, the legacy approach can be applied to determine the beam characteristics of Msg2 in each RAR, i.e. i.e., to determine that a beam of Msg2 is QCLed Source-RS. However, it may happen that the RAR windows associated with different transmitted PRACHs overlap in the time range. In this case, it is important to define what assumptions should be made regarding the QCL source RS within the overlapped section of the RAR windows. To deal with this case, any of the following two options can be used.

A first possibility is that the UE does not expect RAR windows to overlap if they correspond to different PRACH repeats associated with different SSBs. However, if the PRACH repeats are associated with the same SSB, it may be allowed to have overlapping RARs since the UE does not need to adjust the receive beam based on the beam characteristics of Msg2.

A second possibility is that if the RAR windows corresponding to different PRACH repeats associated with different SSB are overlapped, any of the following procedures may be applied.

For the non-overlapping sections of RAR, the QCL source RS is determined similarly to legacy mechanisms, that is, the beam of Msg2 has the same properties as the SSB/CSI RS, the one with the PRACH repeat is associated, whose RAR is monitored in the RAR window.

For the overlapped sections of RAR, the QCL source RS can be based on the RAR window launched earlier. This is in 7C shown where the QCL assumption of the RAR window that starts earlier overrides the QCL assumptions of the RAR windows that starts later. Other parameters associated with the earlier starting RAR window may override those of the later RAR, such as RA-RNTI, which the UE may apply.

Other rules can be applied to determine the QCL assumption for Msg2 reception and the corresponding RNTI in the overlapped section of the RAR windows. The determination may, for example, be based on the measured quality of the SSB associated with the RAR window. Going back to the previous example, and assuming that a measured SSB quality (e.g. RSRP) is as follows, RSRP _SSB1 < RSRP _SSB3 < RSRP _SSB2 , i.e. SSB2 the best measured quality followed by SSB3, then SSB1, , the parameters related to the RAR window associated with SSB2, such as the QCL assumption and RA-RNTI, override the parameters associated with other RAR windows, as in 7D shown as an example.

Beam handling for Msg3 broadcast can be done as follows. To ensure that the UE and the gNB have a common understanding of which transmit beam to use for Msg3 on the UE side and which Rx beam on the gNB side, the transmit beam of Msg3 can be the same as the PRACH Transmit beam associated with the received RAR carrying the Msg3 assignment. Due to the channel reciprocity between DL and UL, the SSB associated with this PRACH repeat can also be used to determine the transmit beam of Msg3.

To provide more flexibility, the gNB can indicate to the UE which beam should be used when sending Msg3. This solution may be advantageous, for example, when the UE transmits multiple PRACH repeats associated with different SSBs and the earliest RAR window does not correspond to the best transmit beam on the UE side. In this case, the gNB may use the previously transmitted PRACH repeats or their associated SSBs to indicate the transmit beam of Msg3.

For example, a new field in the RAR itself can be used to specify the beam of Msg3. The bit width of this field can be equal to the number of PRACH repeats configured. In this case, the field may indicate the beam which can be used by PRACH-Repeat to send Msg3. The PRACH repeats may be as described in this disclosure or indexed using another method. Alternatively, the gNB may specify the SSB index that the UE should use to determine the transmit beam of Msg3, which relies on the reciprocity between DL and UL. In this case, the field size may depend on the number of SSBs sent.

This field can also be in the Msg2 PDCCH, instead of in the RAR itself. In this case, the specified transmit beam for Msg3 can be applied by all UEs that can find a preamble ID in the scheduled RARs. This field may be similar to the previous fields indicating either the PRACH repeat or the SSB that should be used to determine the transmit beam of Msg3. This is advantageous when the gNB attempts to use a single receive beam for Msg3 for all UEs provided by RARs in a single Msg2.

For Msg3 retransmissions scheduled by DCI 0_0 with CRC scrambled by Temporary Cell RNTI (TC-RNTI), a field similar to the aforementioned field may be included in DCI 0_0 to indicate which PRACH -Repeat or associated SSB should be used to determine the beam of Msg3. For example, in this DCI, the NDI and HARQ fields are reserved and they can be repurposed to specify which beam should be applied for an Msg3 retransmission, as described above. Alternatively, a new field can be introduced to specify the beam for Msg3.

Another option for determining the beam for Msg3 retransmission is that the same beam specified in the initial transmission by Msg2 (Msg2-PDCCH or Msg2-PDSCH) can still be applied in the event of an Msg3 retransmission.

Beam handling for Msg4 reception can be performed as follows. If the UE receives a single Msg2, the UE may assume that the same SSB that is used as the QCL source RS for Msg2 is the one that should be adopted as the QCL source RS for Msg4. In other words, the DM-RS of PDCCH that schedules Msg4 has the same QCL characteristics as the SSB that the UE uses for receiving Msg2. If there are several planned Msg2s QCLed with different SSBs and each provides different RARs, the UE can select one of these RARs based on their quality, e.g. B. RSRP of the Msg2-PDCCH or the Msg2-PDSCH based on the reception order in the time domain, etc. to determine the resources of Msg3. In this case, the UE may assume that the SSB used as the QCL source RS for Msg2, which provided the used allocation of Msg3, may be the QCL source RS for Msg4.

Configuration handling can be done as follows. In legacy NR, the gNB can define multiple sets of features consisting of reduced capability (redcap), smallData, msg3 repeat, etc. and specify the associated set of preambles and ROs. For example, the gNB can configure the following feature sets: S ₀ = {redcap}, S ₁ = {msg3-repeat}, S ₂ = {redcap, msg3-receive} and S ₃ = {smallData, msg3-repeat}. For each, the gNB can specify dedicated preambles by specifying the index of the first preamble and the number of consecutive preambles per SSB to associate with the feature sets, e.g. B. S ₀ , S ₁ , S ₂ or S ₃ . Also, the gNB can specify a subset of ROs that can be used for each feature set, e.g. B. S ₀ , S ₁ , S ₂ or S ₃ .

Defining a new feature related to PRACH reception is a simple solution that can allow the gNB to combine this feature with other features if necessary and specify the appropriate preambles. That is, FeatureCombination-r 17 has several remaining values, one of which can be used for PRACH repetition. This allows the gNB to define a feature set consisting of {PRACH repeat, msg3 repeat} and then use FeatureCombinationPreambles to configure common preamble resources for both features.

In order to preserve the remaining values for the future and to take advantage of the fact that if Msg3 requires repetitions, PRACH may also require repetitions, the set of preambles associated with PRACH repetition can be the same as the set of preambles that to be used when Msg3 repeats are requested.

Also, in legacy NR, the gNB can configure a unique priority index for each feature, which can be used to determine the set of preambles from which to select when a feature is assigned to more than one feature set, e.g. B. is the feature msg3 repeat in S ₁ , S ₂ and S ₃ . One possibility is to define a priority for the PRACH repeat feature. Alternatively, the UE may assume that PRACH retry has the same priority as a priority specified over msg3 retry to reduce signaling overhead. This is also significant when both msg3 repeat and PRACH repeat occur together. Also, in legacy NR, rsrp-ThresholdMsg3 is used by the UE to determine whether to select resources that indicate whether Msg3 retry is required. This field is mandatory if the random access resource set is configured for both Msg3 with repeat and Msg3 without repeat. As described in this disclosure, a dedicated RRC parameter, e.g. B. rsrpthresholdPRACH, may be configured separately so that the UE can use it to determine whether a PRACH retry is required or not. However, if this parameter is not configured, the UE may use rsrp-ThresholdMsg3 to make a decision about the need for PRACH retry in addition to using it to determine whether retry is required for Msg3 or not.

8A shows a section of a wireless system. A user equipment (UE) 805 sends broadcasts to a network node (gNB) 810 and receives broadcasts from the gNB 810. The UE includes a radio 815 and a processing circuit (or “processor”) 820. In operation, the processing circuit can perform various processes that are described herein, e.g. B. it may receive information from the gNB 810 (by means of the radio, as part of transmissions received by the gNB 810), and it may transmit information to the gNB 810 (by means of the radio, as part of transmissions received to sent to the gNB 810).

8B is a flowchart of a method in some embodiments. The method includes sending, at 830, by a user equipment (UE), a first Physical Random Access Channel (PRACH) transmission, using a first preamble, in a first Random Access Channel Occasion (RO); and transmitting, at 832, by the UE, a second PRACH transmission, using a second preamble, in a second RO. The second PRACH broadcast may be a repeat of the first PRACH broadcast, and (i) the second RO may have an index that differs from an index of the first RO by a set integer, or (ii) the first preamble may based on a first root sequence and cyclically shifted by a first integer, and the second preamble may be based on the first root sequence and cyclically shifted by a second integer Number can be shifted that differs from the first integer by a set integer. In some embodiments, the first RO is associated with a first sync signal block (SSB) index and the second RO is associated with the first SSB index. In some embodiments, the first RO is associated with a first SSB that is transmitted on a first downlink beam, and the second RO is associated with a second SSB that is transmitted on a second downlink beam that is different from the first downlink -Beam differs. In some embodiments, the set integer is configured using Radio Resource Control (RRC). In some embodiments, the set integer is configured by a system information block. In some embodiments, the set integer is configured upon startup of the UE. In some embodiments: the first PRACH broadcast includes a first preamble based on a first root sequence and cyclically shifted by a first integer; and the second PRACH broadcast includes a second preamble based on the first root sequence and cyclically shifted by a second integer that differs from the first integer by a set integer.

The method may further include sending at 834 L PRACH transmissions, comprising: the first PRACH transmission; and L-1 PRACH retransmissions comprising the second PRACH transmission, the L PRACH transmissions being in an SSB-RO association period. In some embodiments, the L PRACH transmissions are performed within a set of N' ROs, where the N' ROs are a set own subset of N available ROs. In some embodiments, the set own subset is configured using Radio Resource Control (RRC). In some embodiments, the first RO is selected based on the value of L.

9 is a block diagram of an electronic device in a network environment 900 according to one embodiment.

Referring to 9 An electronic device 901 in a network environment 900 may communicate with an electronic device 902 via a first network 998 (e.g., a short-range wireless communications network), or with an electronic device 904 or a server 908 via a second network 999 (e.g., a long-distance wireless communications network). The electronic device 901 can communicate with the electronic device 904 via the server 908. The electronic device 901 may include a processor 920, a memory 930, an input device 940, a sound output device 955, a display device 960, an audio module 970, a sensor module 976, an interface 977, a haptic module 979, a camera module 980, a power management module 988, a battery 989, a communication module 990, a subscriber identity module (SIM) card 996 or an antenna module 994. In one embodiment, at least one (e.g., display device 960 or camera module 980) of the components may be omitted from electronic device 901, or one or more other components may be added to electronic device 901. Some of the components may be implemented in the form of a single integrated circuit (IC). For example, the sensor module 976 (e.g., a fingerprint sensor, an iris sensor, or an exposure sensor) may be incorporated into the display device 960 (e.g., a display).

For example, the processor 920 may execute software (e.g., a program 940) to control at least one other component (e.g., a hardware or software component) of the electronic device 901 coupled to the processor 920, and may perform various data processing operations or calculations.

At least as part of the data processing operations or calculations, the processor 920 may load a command or data received from another component (e.g., the sensor module 946 or the communications module 990) into a volatile memory 932, the command or data, stored in the volatile memory 932 and store resulting data in a non-volatile memory 934. The processor 920 may include a main processor 921 (e.g., a central processing unit (CPU) or an application processor (AP)) and an additional processor 923 (e.g., a graphics processing unit (GPU), an image signal processor (ISP), a sensor Hub processor or a communications processor (CP)), which is operable independently of or in conjunction with the main processor 921. Additionally or alternatively, the additional processor 923 may be capable of consuming less power than the main processor 921 or performing a particular function. The additional processor 923 may be implemented separately from or as part of the main processor 921.

The additional processor 923 may control at least some of the functions or states affecting at least one component (e.g., the display device 960, the sensor module 976, or the communication module 990) of the components of the electronic devices 901, instead of the main processor 921, while the main processor 921 is in an inactive (e.g. standby) state, or together with the main processor 921 while the main processor 921 is in an active state (e.g. executing an application). The additional processor 923 (e.g., an image signal processor or a communications processor) may be implemented as part of another component (e.g., the camera module 980 or the communications module 990) that is functionally related to the additional processor 923.

Memory 930 may store various data used by at least one component (e.g., processor 920 or sensor module 976) of electronic device 901. The various data may include, for example, software (e.g., program 940) and input data or output data for an associated command. The memory 930 may include the volatile memory 932 or the non-volatile memory 934.

The program 940 may be stored in the memory 930 as software and may include, for example, an operating system (OS) 942, middleware 944, or an application 946.

The input device 950 may receive a command or data to be used by another component (e.g., the processor 920) of the electronic device 901 from outside (e.g., a user) of the electronic device 901. The input device 950 may include, for example, a microphone, a mouse, or a keyboard.

The sound output device 955 can output sound signals related to the electronic device 901 to the outside. The sound output device 955 may include, for example, a speaker or a receiver. The speaker can be used for general purposes such as playing multimedia or a recording, and the receiver can be used to receive an incoming call. The receiver can be implemented separately from or as part of the speaker.

The display device 960 can visually provide information to the outside (e.g., to a user) of the electronic device 901. The display device 960 may include, for example, a display, a hologram device, or a projector, and a control circuit to control a respective element of the display, the hologram device, and the projector. The display device 960 may include a touch circuit capable of detecting a touch or a sensor circuit (e.g., a pressure sensor) capable of measuring the intensity of a force applied by the touch.

The audio module 970 can convert a sound into an electrical signal and vice versa. The audio module 970 may receive the sound via the input device 950 or output the sound via the sound output device 955 or a headphone of an external electronic device 902 that is directly (e.g., wired) or wirelessly coupled to the electronic device 901.

The sensor module 976 may sense an operating state (e.g., power or temperature) of the electronic device 901 or an environmental state (e.g., a user's state) external to the electronic device 901 and then generate an electrical signal or data value that corresponds to the recorded condition. The sensor module 976 may, for example, include a gesture sensor, a gyroscope sensor, an atmospheric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an infrared (IT) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or a Include exposure sensor.

The interface 977 may support one or more specified protocols to be used to couple the electronic device 901 to the external electronic device 902 directly (e.g., wired) or wirelessly. The interface 977 may include, for example, High Definition Multimedia Interface (HDMI), a Universal Serial Bus (USB) interface, a Secure Digital (SD) card interface, or an audio interface.

A connection port 978 may include a connector through which the electronic device 901 may be physically connected to the external electronic device 902. The connection port 978 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

The haptic module 979 can convert an electrical signal into a mechanical impulse (e.g., a vibration or movement) or into an electrical impulse that can be detected by a user via the sense of touch or a kinesthetic sensation. The haptic module 979 may include, for example, an electric motor, a piezoelectric element, or an electrical pulse generator.

The camera module 980 can capture a still image or moving images. The camera module 980 may include one or more lenses, image sensors, image signal processors, or flashes. The power management module 988 may manage power supplied to the electronic device 901. The power management module 988 may be implemented as at least a portion of, for example, a power management integrated circuit (PMIC).

The battery 989 can provide power to at least one component of the electronic device 901. The battery 989 may include, for example, a primary cell that is non-rechargeable, a secondary battery that is rechargeable, or a fuel cell.

The communication module 990 may establish a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device 901 and the external electronic device (e.g., the electronic device 902, the electronic device 904, or the server 908) and support carrying out communication via the established communication channel. The communications module 990 may include one or more communications processors operable independently of the processor 920 (e.g., the AP) and supports direct (e.g., wired) communication or wireless communication. The communications module 990 may include a wireless communications module 992 (e.g., a cellular communications module, a short-range wireless communications module, or a global navigation satellite system (GNSS) communications module) or a wired communications module 994 (e.g., a Local Area Network (LAN) communication module or a Power Line Communication (PLC) module). A corresponding one of these communication modules can be connected to the external electronic device via the first network 998 (e.g. a short-range communication network such as Bluetooth™, Wireless Fidelity (Wi-Fi) or an Infrared Data Association (IrDA) standard) or communicate via the second network 999 (e.g. a long-distance communications network such as a cellular network, the Internet or a computer network (e.g. LAN or Wide Area Network (WAN)). These different types of communication modules can be used as individual components (e.g., as a single IC) or as multiple components (e.g., multiple ICs) that are separate from each other. The wireless communication module 992 may be the electronic device 901 in a communication network such as the first network 998 or the identify and authenticate second network 999 using subscriber information (e.g. International Mobile Subscriber Identity (IMSI)) stored in subscriber identity module 996.

The antenna module 997 may transmit a signal or power to the outside or receive it from outside (e.g., the external electronic device) of the electronic device 901. The antenna module 997 may include one or more antennas and therefore at least one antenna suitable for a communication system used in the communication network, such as the first network 998 or the second network 999, may be selected, for example by the communication module 990 (e.g. the wireless communication module 992). The signal or power may then be sent or received between the communications module 990 and the external electronic device via the at least one selected antenna.

Commands or data may be sent or received between the electronic device 901 and the external electronic device 904 via the server 908 coupled to the second network 999. Each of the electronic devices 902 and 904 may be a device of the same type or a different type than the electronic device 901. All or some of the operations to be performed on the electronic device 901 may be performed on one or more of the external electronic devices 902, 904 or 908 can be executed. For example, if the electronic device 901 is to perform a function or service automatically or in response to a request from a user or other device, the electronic device 901 may request that the one be performed instead of or in addition to performing the function or service or multiple external electronic devices perform at least part of the function or service. The one or more external electronic devices that receive the request may perform at least the portion of the function or service that is requested, or perform an additional function or service related to the request and a result of performing the electronic device 901 transmitted. The electronic device 901 may provide the result as at least part of a response to the query, with or without further processing of the result. For example, cloud computing, distributed processing or client-server computing technology can be used for this purpose.

Embodiments of the subject matter and operations described in this specification may be implemented in digital electronic circuits or in computer software, firmware, or hardware comprising the structures disclosed in this specification and their structural equivalents, or in combinations of one or more than one thereof be implemented. Embodiments of the subject matter described in this specification may be implemented as one or more computer programs, ie, one or more modules of computer program instructions encoded on a computer storage medium for execution by a data processing device or for controlling operations thereof. Alternatively or additionally, the program instructions can be encoded on an artificially generated, widespread signal, e.g. B. a machine-generated electrical, optical or electromagnetic signal generated to encode information for transmission to a suitable receiver device for execution by a data processing device. A computer storage medium may be or be included in a computer-readable storage device, a computer-readable storage substrate, a random or serial access storage array or device, or a combination thereof. Additionally, while a computer storage medium is not a propagated signal, a computer storage medium may be a source or destination for computer program instructions encoded in an artificially generated propagated signal. The computer storage medium may also be or be comprised in one or more separate physical components or media (e.g., multiple CDs, floppy disks, or other storage devices). Additionally, the operations described in this specification may be implemented as operations performed by a data processing device on data stored on one or more computer-readable storage devices or received from other sources.

While this description may contain many specific implementation details, the implementation details should not be construed as limitations on the scope of any claimed subject matter, but rather as descriptions of features specific to particular embodiments. Certain features described in this specification in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in particular combinations and may even be originally claimed as such, in some cases one or more features of a claimed combination may be separated from the combination and the claimed combination may refer to a subcombination or to a modification a sub-combination.

Also, while operations are shown in a particular order in the drawings, this should not be understood as requiring that operations be performed in the particular order shown or in a sequential order, or that all operations shown be performed to achieve desired ones to achieve results. In certain circumstances, multitasking and parallel processing can be beneficial. Further, the separation of various system components in the embodiments described above should not be understood to mean that such separation is required in all embodiments, and it should be recognized that the program components and systems described generally come together in a single software product can be integrated or packaged in multiple software products.

In this way, certain embodiments of the subject matter have been described herein. Other embodiments are included within the scope of the following claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve desired results. Additionally, the processes illustrated in the accompanying figures do not necessarily require the particular order or sequential order shown to achieve desired results. In certain implementations, multitasking and parallel processing can be beneficial.

It will be apparent to one skilled in the art that the innovative concepts described herein can be modified and varied for a wide range of applications. Accordingly, the scope of claimed subject matter should not be limited to any of the specific exemplary teachings set forth above, but rather is defined by the following claims.

QUOTES INCLUDED IN THE DESCRIPTION

This list of documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• US 63/335116 [0001]
• US 63/434881 [0001]

Claims (20)

Process comprising: Sending, by a user equipment (UE), a first Physical Random Access Channel (PRACH) transmission in a first Random Access Channel Occasion (RO); and Sending, by the UE, a second PRACH transmission in a second RO, wherein the second PRACH transmission is a repeat of the first PRACH transmission, the second RO having an index that differs from an index of the first RO by a set integer. Procedure according to Claim 1 , wherein the first RO is associated with a first synchronization signal block (SSB) index and the second RO is associated with the first SSB index. Procedure according to Claim 1 , wherein the first PRACH transmission uses a first uplink (UL) beam and the second PRACH transmission uses a second UL beam that is different from the first UL beam. Procedure according to Claim 1 , whereby the set integer is configured using Radio Resource Control (RRC). Procedure according to Claim 1 , where the set integer is configured by a system information block. Procedure according to Claim 1 , whereby the set integer is configured when the UE is started. Procedure according to Claim 1 , wherein: the first PRACH broadcast has a first preamble with a first preamble index; and the second PRACH broadcast has a second preamble with a second preamble index that differs from the first preamble index by a set integer. Procedure according to Claim 1 , comprising sending L PRACH broadcasts comprising: the first PRACH broadcast; and L-1 PRACH repeats comprising the second PRACH broadcast, the L PRACH broadcasts being in an SSB-RO association period. Procedure according to Claim 1 , where the first PRACH transmission occurs on one of N' ROs, the N' ROs being a set own subset of N available ROs. Procedure according to Claim 9 , whereby the set own subset is configured using Radio Resource Control (RRC). Procedure according to Claim 9 , comprising sending L PRACH broadcasts comprising: the first PRACH broadcast; and L-1 PRACH repeats comprising the second PRACH transmission, where the N' ROs are selected based on the value of L. Process comprising: Sending, by a user equipment (UE), a first Physical Random Access Channel (PRACH) broadcast having a first preamble in a first RO; and Sending, by the UE, a second PRACH transmission having a second preamble in a second RO, where the second PRACH broadcast is a repeat of the first PRACH broadcast, the first preamble is based on a first root sequence and is cyclically shifted by a first integer, and the second preamble is based on the first root sequence and is cyclically shifted by a second integer, which differs from the first integer by a set integer. Procedure according to Claim 12 , comprising sending L PRACH broadcasts comprising: the first PRACH broadcast; and L-1 PRACH repeats comprising the second PRACH broadcast, the L PRACH broadcasts being in an SSB-RO association period. Procedure according to Claim 12 , where the first PRACH transmission occurs on one of N' ROs, the N' ROs being a set own subset of N available ROs. Procedure according to Claim 14 , whereby the set own subset is configured using Radio Resource Control (RRC). Procedure according to Claim 14 , comprising sending L PRACH broadcasts comprising: the first PRACH broadcast; and L-1 PRACH repeats comprising the second PRACH transmission, where the N' ROs are selected based on the value of L. User device (UE) comprising: one or more processors; and a memory that stores instructions that, when executed by the one or more processors, cause performing: Sending a first Physical Random Access Channel (PRACH) broadcast in a first Random Access Channel Occasion (RO); and sending a second PRACH transmission in a second RO, the second PRACH transmission being a repeat of the first PRACH transmission, the second RO having an index that differs from an index of the first RO by a set integer. UE after Claim 17 , wherein the first RO is associated with a first synchronization signal block (SSB) index and the second RO is associated with the first SSB index. UE after Claim 17 , wherein the first PRACH transmission uses a first uplink (UL) beam and the second PRACH transmission uses a second UL beam that is different from the first UL beam. UE after Claim 17 , where the set integer is configured using Radio Resource Control (RRC).

Images