Random access channel resource and transmit power determination for multiple physical random access channel transmissions - Patents.com

By determining optimal RACH resources and transmit power for multiple PRACH transmissions, the method addresses the lack of RACH repetition in NR, improving connection efficiency for UEs in diverse coverage conditions.

JP7791364B2Active Publication Date: 2025-12-23TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
JP2024574629
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2022-07-04
Filing Date
2023-06-30
Publication Date
2025-12-23
Estimated Expiration
2043-06-30

AI Technical Summary

Technical Problem

The challenge in wireless communication systems is the lack of support for random access channel (RACH) repetition in New Radio (NR) releases up to Rel-17, which hinders effective coverage extension for UEs, particularly in challenging environments.

Method used

The method involves determining the number of physical RACH transmissions and transmit power for multiple PRACH transmissions based on channel information, allowing UEs to adapt to coverage situations and improve connection times by optimizing RACH resources and power settings.

Benefits of technology

This approach reduces the time required for UEs to connect to a communication network by optimizing RACH resources and transmit power, enhancing connection efficiency in various coverage scenarios.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007791364000016
    Figure 0007791364000016
  • Figure 0007791364000017
    Figure 0007791364000017
  • Figure 0007791364000018
    Figure 0007791364000018
Patent Text Reader

Abstract

During a random access ("RA") procedure associated with a network node of a new radio ("NR") communication network, a communication device may determine information associated with at least one of the communication device and a channel between the communication device and the network node. The communication device may further determine, based on the information, the number of physical RA channel ("PRACH") transmission signals to be transmitted to the network node prior to receiving a random access response as part of the RA procedure. The communication device may further transmit the number of PRACH transmission signals to the network node as part of the RA procedure.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present disclosure relates to wireless communication systems, and more particularly to determining random access channel ("RACH") resources and transmit power for multiple physical random access channel ("PRACH") transmissions. [Background technology]

[0002] FIG. 1 illustrates an example of a new radio ("NR") network (e.g., a fifth-generation ("5G") network) that includes a 5G core ("5GC") network 130, network nodes 120a-b (e.g., 5G base stations ("gNBs"), and a plurality of communication devices 110 (also referred to as user equipment ("UE")).

[0003] Random Access Channel ("RACH") repetition was introduced in the Rel-13 work items ("Wis") titled "Further LTE Physical Layer Enhancements for MTC" and "NarrowBand IOT (NB-IOT)" to extend coverage in Long Term Evolution ("LTE"). However, RACH repetition is not currently supported in NR releases up to Rel-17.

[0004] Information repetition is a technique for achieving coverage extension, and in LTE it can be used for all physical channels available to coverage extension UEs, such as the Machine Type Communications Physical Downlink Control Channel ("M-PDCCH"), the Physical Broadcast Channel ("PBCH"), the Physical Downlink Shared Channel ("PDSCH"), the Physical Uplink Control Channel ("PUCCH"), the Physical Uplink Shared Channel ("PUSCH"), and the Physical Random Access Channel ("PRACH").

[0005] The UE can determine the repetition level for the initial PRACH transmission. The repetition levels supported by the cell (e.g., 5, 10, and 15 dB) can be included in the system information, and the UE can select one of them based on, for example, the estimated channel quality.

[0006] During the initial random access, the UE may measure the quality of the downlink ("DL"). The UE may select a suitable repetition level for its initial PRACH preamble transmission from among four levels. The UE may increase its PRACH repetition level if it does not receive a random access response ("RAR"). The number of repetitions for the RAR and subsequent messages may depend on the level for a successful PRACH.

[0007] Coverage extension for the physical random access PRACH preamble can be achieved partly through mitigation of the required PRACH false detection probability and partly through repetition of the legacy LTE PRACH format. Up to three different repetition levels (plus a zero coverage extension level) can be configured, with each level having its own configurable number of repetitions and attempts to adapt to the UE's coverage situation. For initial random access, the UE selects its own repetition level based on RSRP measurements. If the UE does not receive an RAR after the maximum number of attempts for the current level, it moves to the next higher one. Power ramping is not used for higher repetition levels; otherwise, the current procedure is used. Different coverage levels correspond to different PRACH resources (e.g., various combinations of preamble sequence, timing, and narrowband), and the available resources are signaled in the system information block ("SIB").

[0008] RAR messages in LTE may be scheduled together with the M-PDCCH and associated PDSCH. The UE may know the repetition level, possible starting subframe, and frequency resource of the M-PDCCH from the most recent PRACH transmission (combined with information signaled in the SIB).

[0009] To allow different operation modes depending on the UE's coverage extension needs, two coverage extension modes are introduced for RRC_CONNECTED LTE UEs: Coverage Extension ("CE") Mode A and CE Mode B. CE Mode A is for no or small coverage extension and requires few iterations (e.g., up to tens of iterations). CE Mode B is for medium to large coverage extension and requires many iterations (e.g., hundreds of iterations). The CE mode can be signaled to the UE by the network. Summary of the Invention

[0010] According to some embodiments, there is provided a method of operating a communications device during a random access ("RA") procedure associated with a network node of a New Radio ("NR") communications network. The method includes determining information associated with at least one of the communications device and a channel between the communications device and the network node. The method further includes determining, based on the information, a number of physical RA channel ("PRACH") transmissions to transmit to the network node as part of the RA procedure prior to receiving a random access response. The method further includes transmitting the number of PRACH transmissions to the network node as part of the RA procedure.

[0011] According to another embodiment, a method is provided for operating a network node of a New Radio ("NR") communications network during a random access ("RA") procedure associated with a communications device. The method includes determining information associated with at least one of the communications device and a channel between the communications device and the network node. The method further includes determining, based on the information, a number of physical radio access channel ("PRACH") transmissions to be received from the communications device as part of the RA procedure. The method further includes monitoring the NR communications network for the number of PRACH transmissions from the communications device as part of the RA procedure.

[0012] According to other embodiments, a communication device, a network node, a non-transitory readable medium, a computer program or a computer program product is provided for performing one of the above methods.

[0013] Certain embodiments may provide one or more of the following technical advantages: In some examples, determining RACH resources and transmit powers for multiple PRACH transmission signals may reduce the time it takes for a UE to connect to a communication network, thereby improving the connection. [Brief explanation of the drawings]

[0014] The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiments of the inventive concepts. [Figure 1] FIG. 1 is a schematic diagram illustrating an example of a fifth generation ("5G") network. [Figure 2] 10 is a table showing an example of a random access configuration of frame structure type 2 for preamble formats 0 to 4. [Figure 3]10 is a table illustrating an example of frame structure type 2 random access preamble mapping in time and frequency. [Figure 4] FIG. 10 is a diagram illustrating an example of an information element called PRACH-Config. [Figure 5] FIG. 10 is a diagram illustrating an example of an information element called PRACH-ConfigCommon. [Figure 6] 10 is a table illustrating an example of random access preamble parameters for frame structure type 2. [Figure 7] 1 is a table illustrating an example of a random access configuration for FR1 and unpaired spectrum. [Figure 8] 1 is a table illustrating an example of a random access configuration for FR2 and unpaired spectrum. [Figure 9] 10 is a table illustrating an example of TPC commands for a PUSCH. [Figure 10] 1 is a table illustrating an example of a mapping between PRACH configuration periods and association periods from SS / PBCH blocks to PRACH opportunities. [Figure 11] FIG. 10 is a diagram illustrating an example of an IE called RACH-ConfigCommon. [Figure 12] FIG. 10 is a diagram illustrating an example of BeamFailureRecoveryConfig. [Figure 13A] FIG. 1 is a schematic diagram illustrating an example scenario associated with multiple PRACH transmissions according to some embodiments. [Figure 13B] FIG. 1 is a schematic diagram illustrating an example scenario associated with multiple PRACH transmissions according to some embodiments. [Figure 13C] FIG. 1 is a schematic diagram illustrating an example scenario associated with multiple PRACH transmissions according to some embodiments. [Figure 13D] FIG. 1 is a schematic diagram illustrating an example scenario associated with multiple PRACH transmissions according to some embodiments. [Figure 14]1 is a graph illustrating an example of a preamble pattern according to some embodiments. [Figure 15] 1 is a graph illustrating an example of a repetition and partitioning framework for Msg1 configured with RACH indication, according to some embodiments. [Figure 16A] FIG. 10 illustrates an example of PRACH opportunities for two PRACH configuration indexes according to some embodiments. [Figure 16B] FIG. 10 illustrates an example of PRACH opportunities for two PRACH configuration indexes according to some embodiments. [Figure 17A] FIG. 10 illustrates an example of an RO with preambles for a particular number of PRACH transmissions according to some embodiments. [Figure 17B] FIG. 10 illustrates an example of an RO with preambles for a particular number of PRACH transmissions according to some embodiments. [Figure 18] 10 is a flowchart illustrating an example of a network node coherently combining multiple PRACH transmissions. [Figure 19] 10 is a flowchart illustrating an example of a network node non-coherently combining multiple PRACH transmissions. [Figure 20] FIG. 1 illustrates an example of larger delay spread caused by transmitted signals in different Tx beams in accordance with some embodiments. [Figure 21A] FIG. 10 illustrates an example of RO and SSB mapping according to some embodiments. [Figure 21B] FIG. 10 illustrates an example of RO and SSB mapping according to some embodiments. [Figure 22] FIG. 10 illustrates an example of preamble selection with multiple SSBs mapping one RO according to some embodiments. [Figure 23] 1 is a flowchart illustrating an example of operations performed by a communications device during an RA procedure in accordance with some embodiments. [Figure 24]1 is a flowchart illustrating an example of operations performed by a network node during an RA procedure according to some embodiments. [Figure 25] 1 is a block diagram of a communication system according to some embodiments. [Figure 26] FIG. 1 is a block diagram of a user equipment according to some embodiments. [Figure 27] FIG. 1 is a block diagram of a network node according to some embodiments. [Figure 28] FIG. 1 is a block diagram of a host computer in communication with user equipment in accordance with some embodiments. [Figure 29] FIG. 1 is a block diagram of a virtualization environment according to some embodiments. [Figure 30] FIG. 1 is a block diagram of a host computer in communication with user equipment via a base station over a partially wireless connection in accordance with some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0015] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. The embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art, and in so doing set forth example embodiments of the inventive concepts. However, the inventive concepts may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, the embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concepts to those skilled in the art. It should also be noted that the embodiments are not mutually exclusive. It may be implicitly assumed that components from one embodiment are present or used in other embodiments.

[0016] Considering the random access operation for the Long Term Evolution ("LTE") standard, as mentioned above, a user equipment ("UE") can transition from no coverage extension or small coverage extension (coverage extension ("CE" mode A)) to large coverage extension (CE mode B) when signaled. The idea is to keep the UE in CE mode B only if it is not possible to acquire synchronization, acquire system information, perform random access, or transmit data using small coverage operation. In extended coverage operation, the number of iterations can be adapted according to the UE's coverage situation.

[0017] In some examples, the UE is a reduced bandwidth / low complexity ("BL") UE or a UE in extended coverage. If a random access preamble is transmitted in a non-terrestrial network, the random access response ("RAR") window starts at the subframe containing the end of the last preamble repetition plus 3+round trip time (RTT) subframes between the UE and the eNB and has a length ra-ResponseWindowSize for the corresponding extended coverage level. Otherwise, the RAR window starts at the subframe containing the end of the last preamble repetition plus 3 subframes and has a length ra-ResponseWindowSize for the corresponding extended coverage level.

[0018] In a further or alternative example, the UE is a Narrowband Internet of Things ("NB-IoT") UE. If the random access preamble is transmitted in a non-terrestrial network, the RAR window starts at the subframe containing the end of the last preamble repetition plus X+RTT subframes between the UE and the eNB and has a length ra-ResponseWindowSize for the corresponding extended coverage level, where X is determined based on the preamble format and number of NPRACH repetitions used. Otherwise, the random access response ("RAR") window starts at the subframe containing the end of the last preamble repetition plus X subframes and has a length ra-ResponseWindowSize for the corresponding extended coverage level, where X is determined based on the preamble format and number of NPRACH repetitions used.

[0019] The RA-Radio Network Temporary Identifier ("RNTI") associated with the Physical Random Access Channel ("PRACH") on which the random access preamble is transmitted is calculated as follows: RA-RNTI = 1+t_id+10*f_id where t_id is the index of the first subframe of the designated PRACH (0≦t_id<10), and f_id is the index of the designated PRACH within that subframe in ascending order in the frequency domain (0≦f_id<6), except for narrowband Internet of Things ("NB-IoT") UEs, reduced bandwidth / low capacity ("BL") UEs, or UEs in extended coverage. If the PRACH resource is on a time division duplex ("TDD") carrier, f_id is the index of the first subframe of the designated PRACH (0≦t_id<10), and f_id is the index of the designated PRACH within that subframe in ascending order in the frequency domain (0≦f_id<6), except for narrowband Internet of Things ("NB-IoT") UEs, reduced bandwidth / low capacity ("BL") UEs, or UEs in extended coverage. If the PRACH resource is on a time division duplex ("TDD") carrier, then f_id is the index of the first subframe of the designated PRACH within that subframe in ascending order in the frequency domain (0≦f_id<6). RA is set to

[0020] For BL UEs and UEs in extended coverage, the RA-RNTI associated with the PRACH on which the random access preamble is transmitted is calculated as follows: RA-RNTI = 1+t_id+10*f_id+60*(SFN_id mod(Wmax / 10)) where t_id is the index of the first subframe of the designated PRACH (0≦t_id<10), f_id is the index of the designated PRACH in that subframe in ascending order in the frequency domain (0≦f_id<6), SFN_id is the index of the first radio frame of the designated PRACH, and Wmax is 400, which is the maximum possible RAR window size in a subframe for a BL UE or a UE in extended coverage. If the PRACH resource is on a TDD carrier, f_id is the index of the first subframe of the designated PRACH in ascending order in the frequency domain (0≦f_id<6). If the PRACH resource is on a TDD carrier, f_id is the index of the first radio frame of the designated PRACH in ascending order in the frequency domain (0≦f_id<6). If the PRACH resource is on a TDD carrier, f_id is the maximum possible RAR window size in a subframe for a BL UE or a UE in extended coverage. If the PRACH resource is on a TDD carrier, f_id is the index of the first radio frame ... maximum possible RAR window size in a subframe for a BL UE or a UE in extended coverage. If the PRACH resource is on a TDD carrier, f_id is the index of the first radio frame of the designated PRACH in ascend RA is set to

[0021] For an NB-IoT UE, the RA-RNTI associated to the PRACH on which the random access preamble is transmitted is calculated as follows: RA-RNTI = 1 + floor(SFN_id / 4) + 256*carrier_id where SFN_id is the index of the first radio frame of the designated PRACH, and carrier_id is the index of the uplink ("UL") carrier associated with the designated PRACH. The carrier_id of the anchor carrier is 0.

[0022] For BL / CE UE, there is a PRACH configuration configured by higher layers for each PRACH coverage extension level, including a PRACH configuration index (prach-ConfigurationIndex), a PRACH frequency offset, and so on.

number

[0023] For BL / CE UE, for each PRACH coverage extension level, if frequency hopping is enabled for the PRACH configuration by the higher layer parameter prach-HoppingConfig, parameter n PRBoffsset RA The value of depends on the system frame number ("SFN") and the PRACH configuration index.

[0024] In the case where the PRACH configuration index is calculated from the table in Figure 2 as follows, the PRACH resource is generated per radio frame:

number

number

number

[0025] For frame structure type 1 with preamble formats 0-3, there is at most one random access resource per subframe for each PRACH configuration.

[0026] For frame structure type 2 with preamble formats 0-4, for each PRACH configuration there may be multiple random access resources within the UL subframe (or UpPTS for preamble format 4) depending on the UL / DL configuration.

[0027] Figure 2 shows an example of a table listing the allowed PRACH configurations for frame structure type 2, where the configuration index is the preamble format, the PRACH density value D RA , and version index r RA For frame structure type 2 with PRACH configuration indexes 0, 1, 2, 20, 21, 22, 30, 31, 32, 40, 41, 42, 48, 49, 50 or with PRACH configuration indexes 51, 53, 54, 55, 56, 57 in UL / DL configurations 3, 4, 5, the UE may assume, for handover purposes, that the absolute value of the relative time difference between a radio frame in the current cell and a target cell is less than 153600 Ts.

[0028] Figure 2 shows the PRACH density at a certain value D RA The table lists the mapping of various random access opportunities to physical resources required for each of the quadruple formats (f RA ,t RA (0),t RA (1),t RA (2)) indicates the location of a particular random access resource, and f RA is the frequency resource index within the range of the considered time point, and t RA(0) = 0, 1, 2 indicates whether the resource reappears in every radio frame, even radio frame, or odd radio frame, respectively, and t RA (1)=0,1 indicates whether the random access resource is located in the first half or the second half of the frame, respectively, and t RA (2) is the uplink subframe number where the preamble starts, counting from 0 in the first uplink subframe between two consecutive downlink-to-uplink switching points, with the exception of preamble format 4, where t RA (2) is represented as (*). The start point of random access preamble formats 0 to 3 is N TA = 0, the random access preamble format 4 is aligned with the start of the corresponding uplink subframe in the UE, and the random access preamble format 4 is started 4832Ts before the end of the UpPTS in the UE, where the UpPTS is N TA = 0 and use the UE uplink frame timing as a reference.

[0029] Random access opportunities for each PRACH configuration are first allocated in time and then at a certain density value D RA For preamble formats 0 to 3, frequency multiplexing shall be performed according to the following formula:

number

[0030] For BL / CE UEs, only a subset of subframes are allowed for preamble transmission, N rep PRACH The allowed starting subframes for a PRACH configuration are determined as follows:

[0031] The subframes allowed for preamble transmission for the PRACH configuration are defined as n sf RA =0,...,N sf RA -1, where n sf RA = 0 and n sf RA =N sf RA -1 are the minimum and maximum absolute subframe numbers n sf abs , which corresponds to the two subframes allowed for preamble transmission.

[0032] PRACH start subframe periodicity N is set by the upper layer. start PRACH If N is not provided, the periodicity of the allowed starting subframes in terms of the subframes allowed for preamble transmission is N rep PRACH n sf RA =0,...,N sf RA The allowable starting subframes defined over jN rep PRACH where j=0,1,2,....

[0033] PRACH Starting Subframe Periodicity N start PRACH indicates the periodicity of the allowed starting subframes in terms of subframes allowed for preamble transmission, if provided by higher layers. sf RA =0,...,Nsf RA The allowable starting subframes defined over jN start PRACH +N rep PRACH where j=0,1,2,....

[0034] n sf RA >N sf RA -N rep PRACH So that n sf RA =0,...,N sf RA It is permissible to not define a starting subframe over -1.

[0035] Each random access preamble occupies a bandwidth equivalent to six consecutive resource blocks for both frame structures.

[0036] Figure 3 shows an example of frame structure type 2 random access preamble mapping in time and frequency, Figure 4 shows an example of an information element called PRACH-Config, and Figure 5 shows an example of an information element called PRACH-ConfigCommon. The physical layer random access preamble is based on single carrier frequency hopping symbol groups. The symbol groups are shown in the table in Figure 6 and have a length of T CP cyclic prefix and total length T SEQ The total length of the symbol groups in the preamble repetition unit is denoted by P. The number of symbol groups adjacent in time is given by G.

[0037] A preamble consisting of P symbol groups is rep NPRACHFor frame structure type 2, if an invalid uplink subframe overlaps the transmission of G symbol groups without a gap, the G symbol groups are discarded. For frame structure type 2, the transmission of G symbol groups is aligned to a subframe boundary.

[0038] The frequency location of the NPRACH transmission is N SC RA = 12 subcarriers and preamble format 2 as described in Figure 6 is configured, SC RA = 36. Frequency hopping is assumed to be used within a range of 12 subcarriers, and within a range of 36 subcarriers when preamble format 2 as described in FIG. 6 is configured, and the frequency location of the ith symbol group is given by:

number

number

[0039] Now, referring to random access operation for the 3rd Generation Partnership Project ("3GPP") New Radio ("NR") standard, there are 64 preambles defined for each time-frequency PRACH opportunity, ordered first by increasing cyclic shift C of the logical root sequence, and then by increasing logical root sequence index, starting with an index derived from the upper layer parameter prach-RootSequenceIndex or rootSequenceIndex-BFR. If the 64 preambles cannot be generated from a single root Zadoff-Chu sequence, additional preamble sequences are obtained from root sequences with adjacent logical indices until all 64 sequences have been found. The ordering of the logical root sequences is cyclic, with logical index 0 beginning with L.RA = 839, it is adjacent to 837, and L RA = 139, it is adjacent to 137. The sequence number μ is obtained from the logical root sequence index.

[0040] Cyclic Shift C ν is given by:

number

[0041] The parameters for determining the root sequences and their cyclic shifts within the PRACH preamble sequence set include: sequence length, logical index into the root sequence table, and preamble subcarrier spacing ("SCS") (e.g., if SCS=1.25 / 5 kHz, then it is unrestricted, restricted set A, or restricted set B).

[0042] The random access preamble can only be transmitted in the time resource given by the higher layer parameter prach-ConfigurationIndex, which depends on FR1 or FR2 and the spectrum type, according to the tables in FIGS.

[0043] The random access preamble can only be transmitted in the frequency resource given by the higher layer parameter msg1-FrequencyStart. RA∈{0,1,...,M-1} are numbered in ascending order within the initial uplink bandwidth during the initial access period, starting from the lowest frequency. Otherwise, n RA are numbered in ascending order within the active uplink bandwidth portion, starting from the lowest frequency.

[0044] For the purpose of slot numbering, the following subcarrier spacing can be assumed: 15 kHz for FR1 and 60 kHz for FR2.

[0045] For each PRACH configuration index, the number of time-domain RACH opportunities within a RACH slot is fixed.

[0046] For unpaired spectrum, if the UE is not provided with tdd-UL-DL-ConfigurationCommon, a PRACH opportunity within a PRACH slot is valid if it does not precede a synchronization signal ("SS") / physical broadcast channel ("PBCH") block within the PRACH slot, and N gap is provided, and at least N received symbols of the last SS / PBCH block gap symbols later and does not overlap with any set of consecutive symbols before the start of the next channel occupancy period during which the UE will not transmit if channelAccessMode="semiStatic" is provided, the candidate SS / PBCH block indices for the SS / PBCH blocks correspond to the SS / PBCH block indices provided by ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon.

[0047] If the UE is not provided with tdd-UL-DL-ConfigurationCommon, a PRACH opportunity within a PRACH slot is valid if it is within the UL symbol or does not precede an SS / PBCH block within the PRACH slot, and N gap is provided, and at least N of the last downlink symbols gapsymbols after the last SS / PBCH block symbol and at least Ngap symbols after the last SS / PBCH block symbol, and does not overlap with any set of consecutive symbols before the start of the next channel occupancy period during which no transmission shall occur if channelAccessMode="semiStatic" is provided. The candidate SS / PBCH block index of the SS / PBCH block corresponds to the SS / PBCH block index provided by ssb-PositionsInBurst in System Information Block 1 ("SIB1") or in ServingCellConfigCommon.

[0048] For preamble format B4, N gap =0.

[0049] For operation on a single carrier in unpaired spectrum, when a UE is configured by higher layers to transmit a Sounding Reference Signal ("SRS"), a Physical Uplink Control Channel ("PUCCH"), a Physical Uplink Shared Channel ("PUSCH"), or a PRACH in a set of symbols of a slot, detects downlink control information ("DCI") instructing the UE to receive a Channel State Information Reference Signal ("CSI-RS") or a Physical Downlink Shared Channel ("PDSCH") in a subset of symbols of that set of symbols, and, unless the UE indicates the capability "partialCancellation," performs a T for the last symbol of the control resource set ("CORESET") in which the UE detected the DCI format. proc,2If the first symbol in that set occurs within the CORESET, the UE does not expect to cancel the PUCCH, PUSCH, or PRACH transmission within that set of symbols; otherwise, the UE cancels the PUCCH or PUSCH, or the actual repetition of the PUSCH determined from the PRACH transmission within that set of symbols. If the UE indicates the capability [partialCancellation], the UE shall proc,2 The UE does not expect to cancel PUCCH, PUSCH, or PRACH transmissions on symbols within that set of symbols occurring within the set of symbols. The UE cancels the actual repetitions of PUCCH, PUSCH, or PUSCH that are determined from the PRACH transmissions on the remaining symbols within that set of symbols [6, TS38.214].

[0050] The PRACH transmits with transmit power P on the indicated PRACH resource for BWP b of carrier f of serving cell c. PRACH,b,f,c (i) is transmitted using the selected PRACH format.

number

[0051] If the UE does not receive a random access response containing a preamble identifier corresponding to the preamble sequence transmitted by the UE within the random access response window, the UE determines the transmit power for subsequent PRACH transmissions, if any.

[0052] If it is before a PRACH retransmission, the UE changes the spatial domain transmit filter and Layer 1 notifies higher layers to pause the power ramping counter.

[0053] The MAC entity shall, for each random access preamble: 1> PREAMBLE_TRANSMISSION_COUNTER is greater than 1, and 1> No notification of the suspension of the power ramping counter is received from the lower layer, and 1> If the selected SSB or CSI-RS is unchanged from the selection in the last random access preamble transmission, 2>Increment PREAMBLE_POWER_RAMPING_COUNTER by 1 1>Select a value for DELTA_PREAMBLE 1> Set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower+DELTA_PREAMBLE+(PREAMBLE_POWER_RAMPING_COUNTER-1)×PREAMBLE_POWER_RAMPING_STEP 1> Calculate the RA-RNTI associated with the PRACH opportunity on which the random access preamble is transmitted, excluding the contention-free random access preamble for the beam failure recovery request. 1> Instruct the physical layer to transmit a random access preamble using the selected PRACH opportunity, the corresponding RA-RNTI (if any), PREAMBLE_INDEX and PREAMBLE_RECEIVED_TARGET_POWER.

[0054] Rel-17 NR introduced support for Msg3 repetition. The UE can be configured to repeat Msg3 via parameters provided in the SIB. Unlike LTE, the UE can request repetition for PUSCH transmission by transmitting a RACH preamble associated with the repetition procedure. The network then specifies the number of repetitions N via the MCS field either in the RAR or in the PDCCH carrying DCI format 0_0. PUSCH repeat Points to.

[0055] For PUSCH transmissions with PUSCH repetition type A scheduled by a RAR UL grant or by DCI format 0_0 with CRC scrambled with a Temporary Cell Radio Network Temporary Identifier ("TC-RNTI"), the UE may be provided with a set of repetition numbers in RACH-ConfigCommon. If the UE requests repetitions for a PUSCH transmission, the UE may provide N PUSCH repeat Transmit PUSCH over N slots PUSCH repeat is indicated by the two most significant bits of the MCS field in the RAR UL grant or in DCI format 0_0, from a set of four values ​​provided by numberOfMsg3Repetitions, or from {1,2,3,4} if numberOfMsg3Repetitions is not provided. The UE determines the MCS for PUSCH transmission by the two least significant bits of the MCS field in the RAR UL grant or the three least significant bits of the MCS field in DCI format 0_0, and determines the redundancy version and RB for each repetition, as described in [6, TS38.214]. PUSCH repeat As slots, N PUSCH repeat Determine slots in which the repetition of the PUSCH transmission does not include symbols indicated as downlink by tdd-UL-DL-ConfigurationCommon or symbols of the SS / PBCH block with index provided by ssb-PositionsInBurst.

[0056] When a UE transmits a PUSCH on an active UL BWP b of carrier f of serving cell c using a parameter set configuration with index j and a PUSCH power control adjustment state with index l, the PUSCH transmit power P PUSCH,b,f,c (i,j,q d , l) is determined as follows:

number

number

[0057] TPC command value δ msg2,b,f,c is used to set the power of the PUSCH transmission and is interpreted according to FIG.

[0058] In some examples, the UE is provided with the number N of SS / PBCH block indices associated with one PRACH opportunity and the number R of contention-based preambles per SS / PBCH block index per enabled PRACH opportunity via ssb-perRACH-OccasionAndCB-PreamblesPerSSB.

[0059] If N<1, one SS / PBCH block index is mapped to 1 / N consecutive valid PRACH opportunities, and for each valid PRACH opportunity, R contention-based preambles with consecutive indices associated with the SS / PBCH block index, starting from preamble index 0. If N≥1, R contention-based preambles with consecutive indices associated with the SS / PBCH block index n (0≤n≤N-1), for each valid PRACH opportunity, starting from preamble index n·N. total preamble Start at / N, where N total preamble is provided by totalNumberOfRA-Preambles for Type 1 random access procedures.

[0060] The SS / PBCH block indices provided by ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon are mapped to valid PRACH opportunities in the following order as the parameters are described: First, by ascending preamble index within a single PRACH opportunity; Second, by ascending frequency resource index for frequency multiplexed PRACH opportunities; Third, by ascending time resource index for time multiplexed PRACH opportunities within a PRACH slot; Fourth, by ascending index for multiple PRACH slots.

[0061] In some examples, the association period for mapping SS / PBCH blocks to PRACH opportunities, starting from frame 0, is NTx SSB The smallest value in a set determined by the PRACH configuration period according to Figure 10 such that N SS / PBCH blocks are mapped to PRACH opportunities at least once within that association period, where the UE selects N from the value of ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon. Tx SSB After an integer number of SS / PBCH block to PRACH opportunity mapping cycles within an association period, N Tx SSB If there is a set of PRACH opportunities or PRACH preambles that are not mapped to an SS / PBCH block, no SS / PBCH blocks are mapped to that set of PRACH opportunities or PRACH preambles. An association pattern period includes one or more association periods and is determined such that the pattern between PRACH opportunities and SS / PBCH blocks repeats at most every 160 msec. PRACH opportunities that are not associated with an SS / PBCH block after an integer number of association periods, if any, are not used for PRACH transmission.

[0062] In some examples, the PRACH opportunities are mapped consecutively for each corresponding SS / PBCH block index. The indexing of the PRACH opportunities indicated by the mask index value is reset for each mapping cycle of consecutive PRACH opportunities for each SS / PBCH block index. For PRACH transmission, the UE selects the PRACH opportunity indicated by the PRACH mask index value for the SS / PBCH block index indicated in the first available mapping cycle.

[0063] For a given preamble index, the order of the PRACH opportunities is as follows: 1) ascending frequency resource index for frequency multiplexed PRACH opportunities, 2) ascending time resource index for time multiplexed PRACH opportunities within a PRACH slot, and 3) ascending index for multiple PRACH slots. Figure 11 shows an example of an information element ("IE") called RACH-ConfigCommon.

[0064] In response to a PRACH transmission, the UE attempts to detect DCI format 1_0 with CRC scrambled with the corresponding RA-RNTI during a window controlled by higher layers. The window starts at the first symbol of the earliest CORESET for which the UE is configured to receive a PDCCH for the Type 1-PDCCH CSS set, as defined in Section 10.1, and is at least one symbol after the last symbol of the PRACH opportunity corresponding to the PRACH transmission, and the symbol length corresponds to the SCS for the Type 1-PDCCH CSS set. The length of the window in number of slots based on the SCS for the Type 1-PDCCH CSS set is provided by ra-ResponseWindow.

[0065] TPC command value δ msg2,b,f,c is used to set the power of the PUSCH transmission and is interpreted according to Figure 9. The CSI request field is reserved.

[0066] In some examples, if a UE receives a random access response message in response to a PRACH transmission on an active UL BWP b of carrier f of serving cell c, then f b,f,c (0,1)=ΔP rampup,b,f,c +δ msg2,b,f,c where l=0 and δ msg2,b,f,cis the TPC command value indicated in the random access response grant of the random access response message corresponding to a PRACH transmission on an active UL BWP b of carrier f in serving cell c.

[0067] The Radio Resource Control ("RRC") may configure the following parameters for the RA procedure:

[0068] prach-ConfigurationIndex: The available set of PRACH opportunities for transmission of random access preambles.

[0069] preambleReceivedTargetPower: The power of the initial random access preamble.

[0070] rsrp-ThresholdSSB: RSRP threshold for SSB selection. When a random access procedure is initiated for beam failure recovery, the rsrp-ThresholdSSB used for selecting an SSB in the candidateBeamRSList refers to the rsrp-ThresholdSSB in the BeamFailureRecoveryConfig IE.

[0071] rsrp-ThresholdCSI-RS: RSRP threshold for CSI-RS selection. If the random access procedure is initiated for beam failure recovery, rsrp-ThresholdCSI-RS is equal to rsrp-ThresholdSSB in the IE BeamFailureRecoveryConfig.

[0072] rsrp-ThresholdSSB-SUL: The RSRP threshold for selecting between the NUL and SUL carriers.

[0073] candidateBeamRSList: A list of reference signals (CSI-RS and / or SSB) that identify candidate beams for recovery and associated random access parameters.

[0074] recoverySearchSpaceId: The search space identity to monitor the response of the beam failure recovery request.

[0075] powerRampingStep: Power ramping factor.

[0076] powerRampingStepHighPriority: Power ramping factor in case of prioritized random access procedure.

[0077] scalingFactorBI: The scaling factor for the preferred random access procedure.

[0078] ra-PreambleIndex: Random access preamble.

[0079] ra-ssb-OccasionMaskIndex: defines the PRACH occasion associated with the SSB, in which the MAC entity may transmit the random access preamble.

[0080] ra-OccasionList: defines the PRACH occasions associated with the CSI-RS, in which the MAC entity may transmit the random access preamble.

[0081] ra-PreambleStartIndex: The start index of the random access preamble for on-demand SI requests.

[0082] preambleTransMax: The maximum number of random access preamble transmissions.

[0083] ssb-perRACH-OccasionAndCB-PreamblesPerSSB: defines the number of SSBs mapped to each PRACH opportunity and the number of contention-based random access preambles mapped to each SSB.

[0084] If groupBconfigured is configured, group B of random access preambles is configured. Among the contention-based random access preambles associated with the SSB, the first numberOfRA-PreamblesGroupA random access preambles belong to random access preamble group A. The remaining random access preambles (if configured) are associated with the SSB belonging to random access preamble group B. If random access preamble group B is supported by the cell, random access preamble group B is included for each SSB.

[0085] Beam failure detection and recovery is described below.

[0086] In some examples, for beam failure detection, the gNB configures the UE with a beam failure detection reference signal (SSB or Channel State Information Reference Signal ("CSI-RS")), and the UE declares beam failure if the number of beam failure instance indications from the physical layer reaches a configured threshold before a configured timer expires.

[0087] In a further or alternative example, SSB-based beam failure detection may be based on SSBs associated with an initial DL bandwidth portion ("BWP") and may be configured only for the initial DL BWP and for DL ​​BWPs that include SSBs associated with the initial DL BWP. For other DL BWPs, beam failure detection may be based only on CSI-RS.

[0088] After a beam failure is detected, the UE triggers beam failure recovery by initiating a random access procedure on the PCell and selects a suitable beam to perform beam failure recovery (if the gNB has provided dedicated random access resources for certain beams, they will be preferred by the UE).

[0089] Once the random access procedure is completed, the beam failure recovery is considered complete.

[0090] In some examples, a media access control ("MAC") entity is responsible for: 1> If a beam failure instance indication is received from a lower layer: 2>Start or restart beamFailureDetectionTimer; 2>Increment BFI_COUNTER by 1; 2>If BFI_COUNTER≧beamFailureInstanceMaxCount: 3>Start random access procedure in SpCell. 1>beamFailureDetectionTimer expires, or 1>When beamFailureDetectionTimer, beamFailureInstanceMaxCount, or any of the reference signals used for beam failure detection are reconfigured by higher layers: 2>Set BFI_COUNTER to 0. 1> If the random access procedure is completed successfully: 2>Set BFI_COUNTER to 0; 2> Stop the beamFailureRecoveryTimer if configured; 2> The beam failure recovery procedure is considered to have been successfully completed.

[0091] For each BWP of the serving cell, the UE periodically updates the set of CSI-RS resource configuration indices q0 by failureDetectionResources. - ("qx -" " shall represent that there is a bar above "qx" and a set q1 of periodic CSI-RS resource configuration indices and / or SS / PBCH block indices by candidateBeamRSList for radio link quality measurement on the BWP of the serving cell. - If the UE is not provided with failureDetectionResources, the UE shall configure the set q0 with a periodic CSI-RS resource configuration index having the same value as the RS index in the RS set indicated by TCI-State for each CORESET that the UE uses to monitor the PDCCH. - If there are two RS indices in the TCI state, determine the set q0 - contains the RS index with the QCL-TypeD configuration for the corresponding TCI state. The UE - The UE expects that the set q0 - It is expected that there will be a single port RS in the

[0092] In non-DRX mode operation, the physical layer in the UE uses a set q0 - For all corresponding resource configurations in out,LR When the radio link quality is worse than a threshold Q, the physical layer provides an indication to the higher layers. out,LR The UE reports to the upper layer if the radio link quality is worse than the set q0 ― In DRX mode operation, the physical layer performs a periodicity check to determine whether the radio link quality exceeds a threshold Q out,LR provides an indication to higher layers if the performance is worse than

[0093] Upon request from higher layers, the UE may -periodic CSI-RS configuration index and / or SS / PBCH block index from Q in,LR Provide corresponding L1-RSRP measurements above a threshold to upper layers.

[0094] The UE may receive a configuration for PRACH transmission via PRACH-ResourceDedicatedBFR. new For a PRACH transmission in slot n according to the periodic CSI-RS resource configuration associated with the SS / PBCH block or according to the antenna port quasi-co-location parameters associated with the SS / PBCH block, the UE shall monitor the PDCCH in the search space set provided by recoverySearchSpaceId for detection of a DCI format with CRC scrambled with C-RNTI or MCS-C-RNTI, starting from slot n+4 within the window configured by BeamFailureRecoveryConfig. For PDCCH monitoring in the search space set provided by recoverySearchSpaceId and for corresponding PDSCH reception ... new After detecting a DCI format with CRC scrambled with C-RNTI or MCS-C-RNTI in the search space set provided by recoverySearchSpaceId, the UE continues to monitor PDCCH candidates in the search space set provided by recoverySearchSpaceId until it receives a MAC CE activation command for the TCI state or tci-StatesPDCCH-ToAddList and / or tci-StatesPDCCH-ToReleaseList.

[0095] 28 symbols after the last symbol of the first PDCCH reception for which a DCI format with a CRC scrambled by C-RNTI or MCS-C-RNTI is detected within the search space set provided by recoverySearchSpaceId, and until the UE receives an activation command for PUCCH-SpatialRelationInfo or is provided with PUCCH-SpatialRelationInfo for a PUCCH resource, the UE shall use the same spatial filter and q u =0, q d =q new , and the power determined for l=0, transmit the PUCCH on the same cell as the PRACH transmission.

[0096] 28 symbols after the last symbol of the first PDCCH reception in which a DCI format with a CRC scrambled by a C-RNTI or MCS-C-RNTI is detected in the search space set provided by recoverySearchSpaceId, the UE shall new Assume the same antenna port quasi-co-location parameters as those associated with

[0097] An example of BeamFailureRecoveryConfig is shown in Figure 12. A list of reference signals (CSI-RS and / or SSB) identifying candidate beams for recovery and associated RA parameters. The UE shall consider this list to include all elements of candidateBeamRSList (without suffix) and all elements of candidateBeamRSListExt-v1610. The network shall configure these reference signals within the linked DL BWPs (i.e., DL BWPs with the same bwp-Id) of the UL BWP for which BeamFailureRecoveryConfig is provided.

[0098] Many features in Rel-17, such as Msg3 repetition, Redcap, slicing, and small data transmission, wanted to use the Msg1 preamble to provide an early indication of the presence of some feature. The solution was to introduce a common framework for allocating preambles in ROs and the conditions for using different feature combinations, such as Msg3 repetition and Redcap, with those preamble groups. With this framework, for example, RO#1 could be defined with preamble groups indicating Redcap and Msg3 repetition, and RO#2 could be defined with preamble groups indicating small data transmission and Redcap + Msg3 repetition. The conditions for using those preamble groups would then be defined.

[0099] In NR, a UE is allowed to transmit one PRACH preamble for a given attempt, and since the PRACH has been identified as a coverage bottleneck, its coverage can be extended by multiple PRACH transmissions.

[0100] In some examples, solutions for PRACH repetition have been adopted in LTE eMTC and NB-IoT, which can be rejected or extended to support multiple NR PRACH transmissions. For example, new solutions are needed to accommodate the significantly larger number of NR PRACH configuration indices and more flexible PRACH opportunities in the time and frequency domains. Furthermore, some new issues are specific to NR, including multiple PRACH transmissions involving different UL Tx beams and the association between PRACH opportunities and SSBs.

[0101] Various embodiments described herein provide operations for determining preambles (ROs) and corresponding powers, TAs, and phases for multiple PRACH transmit signals, including PRACH transmit signal and UL Tx beam / SSB mapping.

[0102] In some embodiments, the UE can transmit a PRACH on a PRACH opportunity associated with a selected synchronization signal block ("SSB"). The RAR is quasi-colocated ("QCL") with the SSB to which the transmitted PRACH is associated. The timing advance ("TA") and transmit power control ("TPC") fields in the RAR are based on the received PRACH. If the UE does not receive an RAR containing its random access preamble identifier ("RAPID") within the RAR window, it can initiate a PRACH retransmission, which may be associated with the same SSB as the initial transmission or a different SSB. Whether the retransmission uses the same UL Tx beam or a different beam is up to the UE implementation.

[0103] As shown in Figures 13A-13D, there are several scenarios for multiple PRACH transmission signals in terms of UL Tx beams and SSBs. Figure 13A shows an example in which a UE transmits multiple PRACHs on the same beam (e.g., the same UL spatial relationship), and all PRACH transmission signals are associated with the same SSB. Figure 13B shows an example in which different beams are used for multiple PRACH transmission signals and associated with one SSB. The UL Tx beam decision is left to the UE implementation and is transparent to the gNB. Figures 13C-13D show examples in which multiple PRACH transmission signals are associated with different SSB beams. In Figure 13C, only one PRACH is associated with each selected SSB, while in Figure 13D, at least one SSB is associated with more than one PRACH transmission signal. Figure 13D is a combination of Figures 13B and 13C, and the embodiments associated with each may be applied to the example of Figure 13D.

[0104] In some embodiments, determining the UL Tx beam for MSg1 is left to the UE implementation. For UEs performing assisted beam sweeping to have beam correspondence and for UEs that cannot refine the TX beam within the limited time of random access, a wide UL Tx beam may be used, resulting in relatively small received power at the gNB until the UE can undergo the beam refinement procedure after RRC connection establishment. Multiple PRACH transmissions on different UL Tx beams allow the UE to sweep narrower beams with better directionality to achieve higher received power at the gNB.

[0105] Depending on the value of ssb-perRACH-OccasionAndCB-PreamblesPerSSB, there is an association between a PRACH occasion and an SS block, or between a PRACH preamble index and an SS block, which may be referred to as a PRACH transmission associated with an SSB. "Multiple PRACH transmissions" refer to those of one RACH attempt, i.e., multiple PRACH transmissions precede the reception of one RAR, unless otherwise stated.

[0106] Some embodiments herein apply to contention-based random access ("CBRA") and contention-free random access ("CFRA"). CFRA resources for beam failure recovery requests may be associated with SSBs and / or CSI-RS. However, for simplicity, reference is made herein to PRACH transmissions associated with SSBs instead of PRACH transmissions associated with SSBs and / or CSI-RS.

[0107] Some embodiments herein apply to a four-step RACH and a two-step RACH.

[0108] Several embodiments related to determining single or multiple PRACH transmissions are described below.

[0109] In LTE eMTC and NB-IoT, the network configures multiple N PRACH configurations with different repetition counts for cell coverage extension. The UE will select an appropriate PRACH configuration for RA depending on the coverage level estimation from RSRP measurements. In a similar manner, an NR UE can determine the number of PRACH transmissions based on the measured RSRP and a configured threshold.

[0110] In some embodiments, rsrp-ThresholdMsg3 is reused to determine whether to perform multiple PRACH transmissions, which is configured via a flag in RRC for either a specific BWP or a specific preamble feature group. If the RSRP is below rsrp-ThresholdMsg3, the UE repeats the PRACH. A repetition procedure is also applied to Msg3 transmission, where Msg3 is repeated the number of times indicated in the random access response or in DCI format 0_0 with CRC scrambled by the TC-RNTI.

[0111] In additional or alternative embodiments, the NUL and SUL may have separate new thresholds for multiple PRACH transmissions, which may be manifested through an offset relative to the threshold for deciding whether to select the NUL or the SUL (rsrp-ThresholdSUL).

[0112] Except for relying on the RSRP threshold, there are other ways for the UE to select multiple PRACH transmissions. A typical network has very limited information about the power headroom available for a UE during initial access because there is usually no power headroom report available for the UE during initial access. In contrast, the UE knows how much power it has. Based on the PRACH target received power and path loss estimate, CMAX,f,cIf it is not possible to convey the required amount of power above (i), then multiple PRACH transmissions can be triggered. By allowing the UE to perform repetitions only when needed, uplink resources and UE power can be avoided from being wasted on unnecessary repetitions.

[0113] In some embodiments, the UE decides between single PRACH transmission or multiple PRACH transmissions based on its power headroom. PRACH,target,f,c +PL b,f,c is its maximum configuration power P CMAX,f,c (i) If it is greater than (hereinafter abbreviated as "Pcmax"), the UE performs multiple PRACH transmissions; otherwise, the UE performs a single PRACH transmission.

[0114] In additional or alternative embodiments, the gap between the required power and Pcmax, i.e., Pcmax, is determined according to predetermined rules and configured values. PRACH,target,f,c +PL b,f,c -P CMAX,f,c (i) may be scaled to different numbers of PRACH repetitions.

[0115] For example, the UE transmits the PRACH two times when the gap is between 0 and 3 dB, and transmits the PRACH four times when the gap is between 3 and 6 dB.

[0116] In some embodiments, after the first PRACH transmission, if the UE fails to receive an RAR or receives an RAR but is not addressed to it, it may initiate multiple PRACH transmissions for PRACH retransmissions. The number of retransmissions and the power of the retransmissions may depend on parameters configured by the network at that time. It may be configured or predetermined whether the UE can increase both the number of PRACH transmissions and the transmit power for Msg1 retransmissions, or only one of them.

[0117] In some embodiments, the network enables multiple PRACH transmissions for a particular service through a SIB. For example, if the establishmentCause in the RRCSetupRequest is set as emergency or for a mission-critical service, the UE can initiate multiple PRACH transmissions if the network configures and allows it.

[0118] In NR up to Rel-17, the gNB points to the BI field in the RAR if it detects energy but fails to detect the preamble. A UE that does not receive the RAR with its RAPID may perform a PRACH retransmission after a backoff time. As described below, for CBRA, it is a random value between 0 and PREAMBLE_BACKOFF * SCALING_FACTOR_BI. SCALING_FACTOR_BI is set as 1 unless it is configured in beamFailureRecoveryConfig or rach-ConfigDedicated. 2> If the random access response includes a MAC sub-PDU with a backoff indicator, 3>Set PREAMBLE_BACKOFF to the result of multiplying the value of the BI field of the MAC sub-PDU by SCALING_FACTOR_BI using Table 7.2-1; 2> If the random access procedure has not been completed, 3> A random backoff time is chosen according to a uniform distribution between 0 and PREAMBLE_BACKOFF; 3> If the criteria for selecting a contention-free random access resource are met during the backoff time, 4> Execute random access resource selection procedure; 3> Otherwise, 4> After the backoff time, perform the random access resource selection procedure.

[0119] The MAC subheader may include a backoff indicator ("BI") field that identifies an overload condition in the cell. The size of the BI field is 4 bits.

[0120] If the network is not overloaded, UEs in poor coverage may transmit more PRACH transmissions by using more RACH resources. If the network is overloaded, UEs transmitting a large number of PRACH transmissions may cause many preamble detection errors from other UEs, and the network may use a different strategy to ensure that all UEs, regardless of whether they are in good or poor cell coverage, have a fair opportunity for network access. If UEs that transmitted different numbers of PRACH transmissions in previous attempts use the same backoff time for retransmissions, fair access cannot be achieved. UEs using more PRACH resources must start retransmissions after a larger backoff time.

[0121] In some embodiments, UEs that transmitted a large number of PRACH transmissions in their last attempt are configured or instructed to use a larger backoff time than UEs that transmitted a smaller number of PRACH transmissions. For example, PREAMBLE_BACKOFF and / or SCALING_FACTOR_BI may be specific to a particular number of PRACH transmissions.

[0122] To reduce the impact on legacy UEs and facilitate preamble detection by the gNB, specific preambles and / or ROs may be assigned for UEs capable of multiple PRACH transmissions.

[0123] Regarding preamble determination for multiple transmissions, a common practice is to transmit the same preamble multiple times, just like in LTE eMTC. In LTE eMTC, the number of PRACH repetitions is determined by the UE, so the eNB can interpret the number by receiving the corresponding preamble. That is, the preamble or PRACH resource differs between repetition levels, which reduces the capacity of the PRACH.

[0124] In some embodiments, the UE may transmit different preambles across multiple ROs associated with a selected SSB.

[0125] In additional or alternative embodiments, the UE selects the preamble index for the SSB selected for the first PRACH in a legacy manner. For the remaining PRACH transmissions, an offset of the preamble index, logical / physical index of the root sequence, and / or cyclic shift is applied relative to the previous PRACH, where the offset pattern may be configured / predetermined. This is shown in Figure 14. The offset may be added modulo some value (e.g., modulo the number of preambles available for the PRACH), or the addition to the offset to form the updated index k may be performed according to the following formula: k new =mod(k prev -K min +offset,K)+K min where mod is the modulo operation, k represents the preamble index (according to any of the methods described above), K is the number of consecutive preambles allocated for multiple PRACH repetitions, and K min may be the preamble with the smallest index assigned to the multiple PRACH repetitions, and in this way, all of the multiple PRACH transmission signals are within the range K min From K min+K-1. The offset may be different for different repetitions, but may be the same for all UEs at a given time instance in the system frame structure to maintain orthogonality among UEs within a cell. Alternatively, k i =mod(k0-K min +Δ i ,K)+K min for the ith iteration according to the index k i may be defined, where Δ i is the offset for the ith repetition, and k0 is the index for the first iteration. See the contents of Figure 14. The offset may be different in different cells to achieve interference diversity. Alternatively, index i may refer to a time instance relative to the system frame structure, which can be used to ensure orthogonality between UEs in a cell even if they start the repetition set at different times. RAPID is determined based on the first PRACH transmission. In addition to being based on the repetition index and / or slot index, Δ i could also be based on one or more of configuration, signaling, a random number determined by the UE, or UE identity (e.g., IMSI, IMEI), so that multiple UEs in a cell will not collide in all iterations if their preambles collide in the first iteration.

[0126] Based on the cyclic shift and logical root sequence, 64 preambles are generated. The indexes 0 to 63 are in ascending order of the cyclic shift and then the logical root sequence. In the same order, preambles with indexes 64 to 127, 128 to 191, 192 to 255, ... can be generated. For example, the UE uses preamble indexes 0, 64, 128, and 192 for four PRACH transmission signals, respectively. In another example, if one root sequence can provide 64 preambles with different cyclic shifts, the first preamble uses logical root index u, and the second preamble transmitted by the UE uses logical root index u+1. The gNB needs to perform blind detection of the following possible preambles in the next RO for the SSB. Different repetition levels can share the same set of preambles and ROs.

[0127] In some embodiments, the PRACH opportunities are mapped consecutively for each corresponding SS / PBCH block index. The indexing of the PRACH opportunities indicated by the mask index value is reset for each mapping cycle of consecutive PRACH opportunities for each SS / PBCH block index. For PRACH transmission, the UE selects the PRACH opportunity indicated by the PRACH mask index value for the SS / PBCH block index indicated in the first available mapping cycle.

[0128] For a given preamble index, the order of PRACH opportunities is as follows: 1) ascending frequency resource index for frequency multiplexed PRACH opportunities, 2) ascending time resource index for time multiplexed PRACH opportunities within a PRACH slot, and 3) ascending index for multiple PRACH slots.

[0129] In additional or alternative embodiments, the preamble selected for each RO depends on where the preamble group for msg1 is located within the RO. This can be considered a virtual preamble with the same relative index to the starting preamble configured for a certain number of PRACH transmissions in the RO. For example, consider only K=2, i.e., the gNB supports only two PRACH transmissions. Suppose the preamble groups for msg1 repetitions in RO#1 are 30-35, and the preamble groups for msg1 repetitions in RO#2 are 19-24. If the UE selects preamble 30 in RO#1, preamble 30 is mapped to the first preamble in RO#2, which is preamble 19. This is important because there is not a specific RO for msg1 repetitions alone, but rather as if there are preamble groups in different ROs, and a mapping must exist. This can be seen in Figure 15.

[0130] In additional or alternative embodiments, if the UE uses the above to select a virtual preamble, upon detection of RAR, the UE will use the first preamble as the selected RAPID. Furthermore, when selecting the RA-RNTI / msgB-RNTI, the first RACH opportunity will be used to calculate the RA-RNTI.

[0131] The pattern given by the PRACH Config Index is repeated for each RACH Configuration Period. Figure 16A shows an example of a PRACH configuration index #160 in FR1 TDD. For a 30 kHz SCS, there are two time-domain PRACH opportunities within a radio frame. Figure 16B shows a PRACH configuration index #127 in FR2. For a 120 kHz SCS, there are eight time-domain PRACH opportunities within a radio frame. These time-domain PRACH opportunities and frequency-division multiplexed ROs are divided among multiple SSBs and possibly among different repetition levels (i.e., a certain number of PRACH transmissions). Briefly, it is assumed that there is at least one RO associated with the selected SSB and the determined repetition level in a time-domain PRACH opportunity. Otherwise, time-domain PRACH opportunities associated with SSBs other than the selected one and those for other repetition levels are skipped for RO determination.

[0132] In additional or alternative embodiments, the preamble pattern is not based on a fixed offset (or modulo of the fixed offset) from one transmission to the next within the set of repetitions as in the above embodiments, but rather follows some other pattern, such as a pattern to achieve better interference diversity between cells. In this case, the pattern is fixed relative to the frame structure within the cell for the purpose of restricting the search space for the gNB. The UE may still be allowed to initiate transmissions in any time-domain RO within the pattern, or may be restricted to initiate transmissions only in certain time-domain ROs within the pattern and / or within the radio frame structure within the cell.

[0133] For a certain number of PRACH repetitions transmitted by an LTE eTMC UE, if a random access resource exists in every subframe, the subframe of the first PRACH transmission is determined explicitly by the configured periodicity or implicitly by the repetition factor so that the time-domain PRACH resources for that number of PRACH repetitions do not overlap. Similarly, in NR, a periodicity can be configured for multiple PRACH transmissions, and multiple PRACH transmissions of a RACH attempt occur within that period. The unit of periodicity can be predetermined as an association period, a PRACH configuration period, a radio frame, a subframe, or a slot with an SCS used for slot numbering. Among the time-domain PRACH opportunities associated with a selected SSB, for K PRACH transmissions, the RO index for the first PRACH transmission is mod(i,K)=0.

[0134] For example, for PRACH configuration index #127 in FR2 and TDD, if the periodicity is 1 PRACH configuration period, there are 8 time-domain PRACH opportunities within the period for the selected SSB. Two, four, or eight PRACH transmissions of RACH attempts are supported. For eight PRACH transmissions, the time-domain PRACH opportunity for the first PRACH has index 0. For four PRACH transmissions, the UE can transmit the first one in RO #0 or RO #4. ​​For two PRACH transmissions, the first ROs are RO #0, 2, 4, and 6. For two, four, and eight PRACH transmissions, each RO must have a different preamble, as shown in Figure 17A. This adds further partitioning in preamble groups for multiple PRACH transmissions. This is a legacy issue in LTE eMTC, but can be resolved by preamble groups in NR.

[0135] In some embodiments, for multiple PRACH transmissions of an attempt, the set of PRACH opportunities is determined in one or more of the following ways:

[0136] In some examples, K represents the number of PRACH transmission signals supported by the gNB, including K=1 and K>1, and the gNB can configure preambles for a subset of all K values ​​in the RO. In some methods, a ra-ssb-OccasionMaskIndex is associated with a value of K. For a selected SSB, among the time-domain PRACH opportunities within a period having preambles configured for K PRACH transmission signals, the RO for the first PRACH transmission signal attempted has an RO index i such that mod(i,K)=0. For example, the right portion of FIG. 17B shows that for two PRACH transmission signals, the UE can start transmission in RO#0 or RO#6. RO#2 and RO#4 do not have preambles for the 2-PRACH transmission.

[0137] In a further or alternative example, if multiple FDMed ROs are associated with the SSB selected at a given time, the UE may use the same frequency resources or hop between frequency-domain PRACH resources across multiple PRACH transmissions. The PRACH frequency hopping configuration, including frequency hopping enable / disable, frequency hopping offset in units of PRBs or ROs, and frequency hopping interval indicating how long the hop lasts, is configured or predetermined in SIB1.

[0138]

number

[0139] For example, the PRACH configuration index 127, RO offset = 4RO, msg1-FDM = 8. For index 127, K = 2. For 8 PRACH transmissions, the UE alternates between two frequency hopping offsets after two PRACH transmissions.

[0140] In additional or alternative examples, for the hybrid PRACH preamble format "Ax / By," either it cannot be used with multiple PRACH transmissions or the UE transmits multiple PRACH transmissions for Ax.

[0141] In NR, up until Rel-17, the available RO is determined by the MAC entity. If the physical layer checks it and it is valid, the UE transmits the PRACH, and no collisions occur, leading to PRACH discard. The UL beam switching time can also be a cause of PRACH discard. One coverage enhancement in Rel-17 is PUSCH repetition based on available slots. DL slots and SSB transmission slots are not considered available slots to avoid discarding PUSCH transmissions. However, transmission based on available slots is not suitable for PRACH. First, PRACH time-domain resources occur at specific times. Second, consideration must be given to PRACH collisions between UEs. If a PRACH transmission is discarded, its postponement may increase PRACH collisions. Unlike PUSCH transmission, whose repetition factor is scheduled by the gNB, the number of PRACH repetitions is determined by the UE when the LTE eMTC rule is reused. Besides counting available slots, several methods are possible to reduce the impact of PRACH discard.

[0142] In some embodiments, for multiple PRACH transmissions, if a PRACH transmission in an available RO as determined by the MAC entity is discarded by the physical layer considering it invalid or due to collision handling, it is not postponed.

[0143] For RedCap UEs, if an RO overlaps with some DL reception, it is up to the UE implementation whether a PRACH should be transmitted.

[0144] For case 8, where the valid RO overlaps with dynamic DL reception, it is up to the UE implementation whether to receive the dynamically scheduled DL or transmit the PRACH.

[0145] For Case 8, where the valid RO overlaps with a DL reception configured specifically for the UE (e.g., PDCCH, SPS PDSCH, CSI-RS, or DL ​​PRS in USS), it is up to the UE implementation whether to receive the DL or transmit the PRACH.

[0146] In additional or alternative embodiments, if a valid RO overlaps with a DL reception that is dynamically scheduled or configured for UL only, and the RedCap UE does not transmit a PRACH in that RO, it is not postponed.

[0147] In some embodiments, it may be configured or predetermined whether the UE is allowed to change the repetition level, determined for example according to an RSRP threshold, when determining that a PRACH transmission should be discarded. In a predetermined manner, the UE may make a decision based on whether random access is triggered by the physical layer or a higher layer, or by CBRA or CFRA.

[0148] For example, a UE for CBRA may be allowed to select a higher repetition factor than that determined based on the RSRP threshold to compensate for some or all of the discarded transmissions. Alternatively, if the UE wanted to transmit four PRACH transmissions but the last two would be discarded, it may select a lower repetition factor of 2, which has similar performance but lower latency. How to balance latency and repetition factor may be left to the UE implementation. However, even if the repetition factor determined and its modification is left to the UE implementation, it is beneficial for the gNB to be aware that the UE may change the repetition level, since it may determine the number of repetitions of Msg3 based on the repetition level of the PRACH. In addition, for some latency-sensitive trigger events, such as CFRA for HO or beam failure recovery, it is not desirable for the UE to decide to upgrade the repetition level.

[0149] For NB-IoT and LTE eMTC, the multiple PRACH transmissions of an attempt have the same transmit power based on the same path loss estimate. However, if the multiple NR PRACH transmissions span a long time or the radio channel changes very quickly, the UE may update the RSRP filtered by higher layers multiple times, depending also on the filter input rate and the PRACH transmit power. Changes in the PRACH transmit power may affect the TPC commands in the RAR.

[0150] In some embodiments, it may be predetermined or configured whether the UE is allowed to change the PRACH transmit power in the middle of multiple PRACH transmission attempts.

[0151] When a gNB receives multiple repetitions of the same random access preamble from a UE, it can perform coherent or non-coherent combining. Coherent combining means that the gNB combines the repetitions of the RACH preamble and processes the combined signal without a calculated modular value. In non-coherent combining, the gNB estimates each repetition independently and then adds the modular values ​​of each repetition.

[0152] FIG. 18 shows an example of coherent combining during iterations.

[0153] FIG. 19 shows an example of non-coherent combining during iterations.

[0154] For coherent combining without the UE ensuring phase continuity across PRACH repetitions, the gNB must align the phase of all received PRACH repetitions by phase compensation before combining them. This would increase the implementation complexity of the gNB. If the UE maintains phase continuity across several PRACH repetitions, the gNB can perform coherent combining on them without phase pre-compensation. The output sequence of the coherent combination can be treated as the detected PRACH sequence, and the UE can non-coherently combine for repetitions where it cannot maintain the same phase. It is possible for the UE to maintain phase continuity across multiple PRACH repetitions, especially if the corresponding ROs are consecutive in time.

[0155] Some of the phase continuity violations agreed upon for Rel-17 DMRS bundling can be reused for multiple PRACH transmissions, including a gap of at least 14 symbols between two PUSCH transmissions. In addition, several other methods can be considered.

[0156] In some embodiments, the gNB determines whether some / all PRACH transmissions from the UE are aligned in phase by one or more of the following approaches: In some examples, the gNB determines whether some / all PRACH transmissions from the UE are aligned in phase based on an explicit or implicit indication by a guard in the preamble sequence. This can be used when the actual cell radius is smaller than the maximum cell radius designed for the PRACH format.

[0157] In a further or alternative example, the gNB determines whether some / all PRACH transmissions from the UE are aligned in phase based on unique preambles configured for various levels of PRACH phase continuity. For example, preambles #0-9 are configured for phase continuity between two PRACH repetitions, and preambles #10-19 are configured for phase continuity between four PRACH repetitions. Furthermore, if all preambles #0-19 are associated with a total of four PRACH repetitions according to SIB1, the transmission of preambles #0-9 indicates that the UE may switch beams after the first two PRACH transmissions and that the phase may change after the beam switch.

[0158] In additional or alternative examples, the gNB determines whether some / all PRACH transmissions from the UE are aligned in phase based on the fact that supporting phase continuity is mandatory for a UE transmitting multiple PRACHs unless a violation occurs, or if it is an optional UE capability, the UE implicitly indicates its capability with the first PRACH transmission.

[0159] In some embodiments, it may be predetermined whether adjusting the TA between multiple PRACH transmissions on the same beam is applied to the UE.

[0160] An embodiment related to multiple PRACH transmissions on different beams is described below.

[0161] In some embodiments, the UE may inform the gNB (e.g., implicitly via a unique preamble) if different Tx beams will be used for multiple PRACH transmissions. Otherwise, the gNB assumes that the same Tx beam will be used. In additional or alternative embodiments, the same or different Tx beams are determined by the UE capability for beam correspondence. For example, if the capability beamCorrespondenceWithoutUL-BeamSweeping is supported in the UE, the PRACH is transmitted on the same Tx beam.

[0162] In additional or alternative embodiments, the UE desires network assistance to reduce beam refinement time, thereby transmitting multiple beams, potentially increasing received power at the gNB. In this case, the number of Tx beams may be determined by the network via the SIB. The UE may select a Tx beam based on the received SSB RSRP, for example, if the gNB allows PRACH transmission on two Tx beams according to the SIB configuration; if the UE receives a higher SSB RSRP on two panels but not on the other panel, it could transmit one beam on each of those two panels.

[0163] In additional or alternative embodiments, the number of PRACH transmissions is determined based on the number of Tx beams of the UE.

[0164] For example, if the UE determines the value according to the RSRP measurement of the SSB and the configured threshold, it will transmit the number of PRACHs on each of its TX beams. In another example, the number of PRACH transmissions is equal to the number of its Tx beams, such that each PRACH is transmitted on a different beam. In some such embodiments, the network may indicate the number of repetitions the UE should use when transmitting the PRACHs, which may be considered as the candidate repetitions. If the number of different Tx beams on which the UE can transmit is less than the indicated or "candidate" repetitions, the UE may transmit the number of PRACHs equal to the number of different Tx beams and not transmit the remaining PRACHs in the candidate repetitions indicated by the network.

[0165] For a given PRACH transmission opportunity, there are 64 preambles. The network can detect 64 PRACHs transmitted in the same time-frequency PRACH opportunity. For simplicity, we consider only preambles with the same root sequence but different cyclic shifts. For an unrestricted set, N CS If C = 2, the short sequence PRACH can have 64 cyclic shifts, which are v =vN CS where v = 0, 1, ..., 63 for one root index. For a single PRACH transmission, 64 simultaneously transmitted PRACHs are received by the gNB and land in corresponding non-overlapping time domain search windows. N CS is indicated by the gNB via zeroCorrelationZoneConfig based on the UL delay spread of the channel for a single PRACH transmission.

[0166] When a UE transmits PRACH on different Tx beams, the delay spread of multiple PRACH transmissions on different Tx beams may be larger than that configured by the gNB for a single PRACH transmission, if some Tx beams are not well aligned with the gNB or different TAs are applied to different Tx beams. In Figure 20, the UE transmits a preamble with v = 0 in three ROs on different beams. The second PRACH transmission arrives with a longer delay than the first transmission but still lands within the correct search window. The third transmission is transmitted within the configured N CS , and will land in other windows and be erroneously detected as preamble v=1. To avoid false detection, the UE may have to restrict its Tx beams to a small number of degrees of freedom so that they can all be received in the NCS-based search window. However, it is difficult for the UE to determine the angular range. Therefore, in some embodiments, a larger N than that of the legacy for a single PRACH transmission is used. CS is configured for multiple PRACH transmissions on different Tx beams.

[0167] In a separate RO, the logical root sequence index obtained from the higher layer parameter prach-RootSequenceIndex or rootSequenceIndex-BFR is used to set the new N CS In combination with, it applies to multiple PRACH transmission signals in different Tx beams. However, in the case of a shared RO, the logical root sequence index needs to be considered.

[0168] In additional or alternative embodiments, different N CS In the case of a shared RO with a preamble of CS The logical root sequence index of the first preamble with may be one or more of the following:

[0169] In some examples, the logical root sequence index is configured separately in SIB1 or is determined by a configured offset relative to prach-RootSequenceIndex or rootSequenceIndex-BFR.

[0170] In a further or alternative example, the logical root sequence index is L RA = 839, then logical index 0 follows 837, and L RA = 139 follows 137 in circular order (offset and legacy N CS The sum of the largest logical root sequence index among the preambles with the largest logical root sequence index is equal to the sum of the largest logical root sequence index among the preambles with ... CS The default offset may be 1, regardless of whether the preamble can still be generated.

[0171] In an additional or alternative example, the largest logical root sequence index may be used to generate a new N for the remaining preamble. CS If the preamble can still be generated in the CS is equal to the largest logical root sequence index of the preamble in

[0172] The UL beam switching time is required for the UE to perform Tx beam switching, particularly across UE panels. The PRACH configuration index 127 in FR2 TDD as shown in FIG. 16B has a two-symbol gap between two PRACH opportunities in two consecutive PRACH slots. In some embodiments, if the beam switching time is greater than the gap, the UE may not be prepared to transmit on a different beam in the second PRACH opportunity and therefore transmits the PRACH in the PRACH opportunity without changing beams. Otherwise, in some embodiments, determining the number of PRACH transmissions actually transmitted by the UE includes determining the number of PRACH transmissions based on the UL beam switching time and the amount of time between PRACH opportunities, such that the time between any two consecutive transmissions is greater than the beam switching time.

[0173] In some embodiments, one or more of the following approaches are used to determine the PRACH opportunity:

[0174] In some examples, the UE selects an SSB taking into account its own beam switching time so that multiple PRACH transmission signals on different Tx beams in the RO associated with the selected SSB can be transmitted without new discarding rules, such as autonomous discarding at the UE.

[0175] Since the decision of the SSB is left to the UE implementation, if the UE wants to switch Tx beams within or across panels, it can estimate whether the gap in the RO for the selected SSB is sufficient for beam switching. If the beam switching time is larger than the gap in the RO, it may select multiple Tx beams transmitted from a single panel or select different SSBs or fewer repetitions so that the beam switching time is smaller than the gap in the RO. In other examples, the UE may first activate a different panel before performing a beam switch, thus reducing the beam switching time so that the beam switching time is smaller than the gap in the RO; it is all up to the UE implementation or its discretion. From the gNB and standard point of view, the UE should not discard PRACH transmissions due to its own reasons, such as when the beam switching time is larger than the gap in the RO, which is agnostic to the gNB and therefore affects the detection rate.

[0176] If the UE can transmit multiple PRACHs associated with multiple SSBs, the selection of multiple SSBs follows the same rules.

[0177] In an additional or alternative example, the network could select the PRACH configuration index such that the gap between consecutive PRACH ROs is greater than the maximum UE beam switching time, so that autonomous discarding by the UE does not occur in different PRACH beam transmissions.

[0178] In an additional or alternative example, the MAC entity may consider the possible occurrence of UL beam switching times when determining the next available PRACH opportunity.

[0179] In a further or alternative example, the MAC entity does not consider the UL beam switching time when determining the next available PRACH opportunity. A PRACH opportunity is valid if it starts at least N symbols after the last symbol of the PRACH opportunity corresponding to the previous PRACH transmission, where N represents the UL beam switching time. It can be predetermined whether a PRACH transmission can be postponed on a PRACH opportunity that is considered invalid by the physical layer.

[0180] In additional or alternative embodiments, if the UE's UL beam switching time is unknown to the gNB, the gNB can use a predetermined value to determine at which PRACH occasion the PRACH should be received for that UE. The UE reports that time after the RRC connection is established. The UE may report separate beam switching times for one SSB and for multiple PRACH transmissions associated with multiple SSBs.

[0181] In NR up to Rel-17, according to 38.213, 7.1.1, the PRACH transmission power is PL b,f,c The UE determines the PL based on the SS / PBCH block associated with the PRACH transmission. b,f,c Determine.

number

[0182] The UE may sweep the DL Rx beam for the same SSB index received over time to calculate different DL path loss estimates on different DL Rx beams, which it can use to determine the PRACH UL Tx power on the corresponding UL Tx beam.

[0183] In some embodiments, the PRACH transmit power may be in one or more of the following forms:

[0184] In some examples, the same transmit power is used for all UL Tx beams based on a predetermined / minimum / maximum / average DL path loss estimate. The UE maintains one PREAMBLE_POWER_RAMPING_COUNTER for all UL Tx beams.

[0185] In an additional or alternative example, the PRACH transmit power on a UL Tx beam is based on the DL path loss estimate of the corresponding DL Rx beam. The UE maintains a PREAMBLE_POWER_RAMPING_COUNTER for each UL Tx beam.

[0186] For the transmit power of Msg1 retransmissions, the following existing rules for PRACH retransmissions on one UL Tx beam in 38.213 can be reused for different UL Tx beams: If before a PRACH retransmission, the UE changes the spatial domain transmit filter and Layer 1 notifies higher layers to pause the power ramping counter.

[0187] A retransmission of Msg1 may use a different UL Tx beam than the previous attempt. In the second example above, since the UE maintains one power control loop for one UL Tx beam, the above rule can be reused. For example, if beams #0 and #1 are used in one attempt and beams #1 and #2 are used for a subsequent attempt, the power ramping counter for beam #1 is incremented by 1 and not for beam #2.

[0188] In the first example above, the standard may be updated as follows: If before a PRACH retransmission, the UE changes any of the spatial domain transmit filters, and Layer 1 notifies higher layers to pause the power ramping counter as described. The UE may determine different values ​​of timing advance for different beams, especially for UEs with multiple panels. If the difference in TA values ​​is within the CP, a single TA can be applied to all beams. Otherwise, the UE either discards the use of UL Tx beams that result in a difference between TAs greater than the CP, or the UE can transmit PRACH with a different TA.

[0189] In some embodiments, it may be predetermined whether the UE can apply different timing advances for multiple PRACH transmissions on different beams.

[0190] The UE has limited power, i.e., P PRACH,target,f,c +PL b,f,c ≧P CMAX,f,c(i) If so, it would be helpful for the gNB to know which beam has the smallest PL, even if they transmit PRACH with the same power. Furthermore, it can be suggested that the UE will use the DL Rx beam corresponding to the first PRACH transmission to receive Msg2.

[0191] In some embodiments, the order of different UL Tx beams for multiple PRACH transmissions is determined according to the increasing PL estimates of the corresponding DL Rx beams, or the first UL Tx beam corresponds to the DL Rx beam with the smallest PL estimate.

[0192] In some embodiments, the mapping between UL Tx beams and PRACH transmissions can be predetermined or configured. One predetermined approach is that the UE does not transmit two consecutive PRACHs in the time domain on the same UL Tx beam; that is, every PRACH is transmitted on a unique beam. Another predetermined approach is that the same UL Tx beam is used across PRACH opportunities in one PRACH slot or consecutive PRACH slots. The UE can switch Tx beams across PRACH opportunities in non-consecutive PRACH slots.

[0193] The mapping allows the gNB to implicitly know the number of UL Tx beams used by the UE, and with that knowledge the gNB can point to one of the Tx beams for the next UL transmission.

[0194] An embodiment relating to multiple PRACH transmissions on different Tx beams associated with different SSBs is described below.

[0195] In some embodiments, the UE may transmit multiple PRACHs on different beams and associate them with multiple SSBs.

[0196] PRACH transmissions associated with multiple SSBs may provide more spatial diversity gain. On the one hand, due to short-term barriers or implementation concerns, such as latency, the selected SSB may not be the strongest beam. Therefore, when multiple PRACH repetitions are associated with one SSB, the UE can adjust the UL Tx beam, but it may not be the ideal beam for the gNB. On the other hand, the received RSRP of two adjacent SSBs is similar, especially in overlapping coverage areas. Therefore, multiple PRACHs associated with different SSBs may provide spatial diversity gain compared to one SSB.

[0197] In some embodiments, whether the UE is allowed to transmit multiple attempted PRACH transmissions associated with more than one SSB may be configured for the UE (e.g., in SIB1) or predetermined by one or more of the following parameters: These parameters may be SSB-wide or SSB-specific. In some examples, this is an indication of whether the UE is allowed to transmit PRACH transmissions associated with different SSBs. If the gNB so configures but does not configure a specific number of SSBs to which the PRACH transmissions may be associated, this is left to the UE to decide. An additional or alternative example is the number of selected SSBs to which the PRACH transmissions are associated. For example, a value of 2 allows the UE to select two adjacent SSBs. The absence or default value of this parameter indicates that the UE is only allowed to associate the PRACH transmissions with one SSB. An additional or alternative example is the maximum number of selected SSBs to which multiple PRACH transmissions are associated.

[0198] An additional or alternative example is a combination of SSBs. For example, if a UE is configured with two SSBs for PRACH transmission and there are four SSBs in the cell, it may be configured with the following SSB combinations: {SSB#0, SSB#1}, {SSB#1, SSB#2}, {SSB#2, SSB#3}, and {SSB#3, SSB#0}. If the UE is configured with a maximum of two SSBs, some additional SSB combinations are {SSB#0, SSB#0}, {SSB#1, SSB#1}, {SSB#2, SSB#2}, and {SSB#3, SSB#3}, in case the UE selects only one SSB. In other words, if the UE selects a first SSB#X, it can select an SSB#Y such that Y=mod(X-1,N) or Y=mod(X+1,N), where N is the number of SSBs. This assumes that the SSBs transmitted by the network are spatially adjacent. For mTRP scenarios, the UE selects one SSB from the TRP, and the gNB may provide a combination of SSB indices from each TRP.

[0199] Per-SSB configuration is beneficial when coverage and UE density are uneven across the SSBs of a cell. When configuration is per cell, it applies to all its SSBs.

[0200] Since the RSRPs of multiple selected SSBs may be different, the corresponding repetition levels of the SSBs will be different, which may increase the combination complexity of the gNBs.

[0201] In some embodiments, it may be predetermined whether different numbers of PRACH transmissions are allowed for different selected SSBs. If the same number of PRACH transmissions applies to multiple selected SSBs, it may be based on the RSRP of the particular SSBs and the number of UL Tx beams that the UE will use for the PRACH transmissions associated with those SSBs.

[0202] For example, a UE may transmit on a UE pair of antenna panels and SSBs, where for the two selected SSBs, the two panels have different numbers of antenna elements and therefore different numbers of UL Tx beams.

[0203] In some embodiments, retransmissions of Msg1 may be associated with the same or different number of SSBs. If the first RACH attempt associates multiple PRACH transmissions with the same SSB, subsequent attempts may associate multiple PRACH transmissions with multiple SSBs.

[0204] In some examples, the UE calculates path loss based on "SS block transmit power" and SS block RSRP. Different SS blocks in an SS burst set may be transmitted with different powers and / or different Tx beamforming gains, at least in network implementations. RMSI only indicates a single transmit power for multiple SS blocks in Rel-15.

[0205] In NR, a RACH transmission opportunity is defined as a time-frequency resource during which PRACH message 1 is transmitted on a single specific tx beam using a configured PRACH preamble format.

[0206] In some embodiments, if multiple PRACH transmissions are associated with multiple SSBs, the PRACH opportunity may be determined by one or more of the following options:

[0207] For multiple PRACH transmissions associated with multiple SSBs, in some examples, PRACH transmissions associated with certain SSBs precede those associated with other SSBs. In additional or alternative examples, PRACH transmissions associated with selected different SSBs may be interleaved.

[0208] Regarding determining the RO for the first PRACH transmission, in some examples, the first PRACH may be associated with the SSB with the strongest RSRP. In additional or alternative examples, the UE determines a PRACH opportunity associated with any of the selected SSBs.

[0209] These examples can be used in different configurations. Consider that a UE selects SSB#0 and SSB#1 for a RACH procedure. In some examples, mapping one SSB to two ROs can be applied as shown in FIG. 21A to reduce latency. If SSB#0 has a higher RSRP than SSB#1, FIG. 21A also shows the selected ROs according to option a. However, if SSB#1 has a higher RSRP than SSB#0, the UE starts with the RO associated with SSB#1 first, followed by the available ROs in SSB#0, which are non-contiguous. However, when the UE determines a PRACH opportunity associated with either of the selected SSBs, it can select an RO as shown in FIG. 21A.

[0210] In an additional or alternative example, one SSB can be mapped to one RO, as shown in FIG. 21B.

[0211] In some embodiments, a preamble associated with one SSB in an RO may be split into one for a PRACH transmission associated with one SSB and one associated with multiple SSBs.

[0212] In the example of possible SSB combinations of {SSB#0}, {SSB#1}, {SSB#2}, {SSB#3}, {SSB#0,SSB1}, {SSB#1,SSB2}, {SSB#2,SSB3}, {SSB#3,SSB#0}, different PRACH resources would be configured for {SSB#0}, {SSB#0,SSB1} and {SSB#3,SSB#0} so that the gNB knows whether to transmit PRACH repetitions for SSB#0 alone or together with other adjacent SSBs.

[0213] In some embodiments, if different preambles in an RO are associated with multiple SSBs and PRACH repetition is enabled, the UE transmits one preamble in the RO for one selected SSB, and a preamble index offset is selected and applied to the starting preamble for the selected SSB.

[0214] Figure 22 shows that ssb-perRACH-OccasionAndCB-PreamblesPerSSB is configured as 4, i.e., four SSBs have four corresponding preambles in the RO. If the UE selects offset 0, it can transmit if preamble indexes #0, 16, 32, 48 are selected for the corresponding SSBs. More generally, the UE selects preamble index i for PRACH repetition 1, and SSBn is associated with the next preamble index.

number

[0215] In additional or alternative embodiments, the multiple PRACH transmissions may be ordered such that the associated SSBs have decreasing / increasing SSB RSRPs or SSB indices.

[0216] In some embodiments, the PRACH transmit power is determined in one or more of the following forms:

[0217] In some examples, the UE maintains the same transmit power for all PRACH transmissions, determined independently based on the minimum or average PL of the selected SSBs, or the PL of the reference SSB with the lowest index, for example. The UE maintains one PREAMBLE_POWER_RAMPING_COUNTER for all UL Tx beams. The reference SSB for pathloss estimation may be determined in the same manner as the previous attempt, but with the most recent SSB before the PRACH retransmission.

[0218] In additional or alternative examples, the UE maintains the same transmit power for multiple PRACH transmissions associated with the same SSB, independently determined based on the RSRP of the received SSB. The UE maintains one PREAMBLE_POWER_RAMPING_COUNTER for each selected SSB. The reference SSB for path loss estimation may be the most recent SSB with the previous index of the PRACH transmission associated with the same SSB index. Because the UE maintains a counter for each SSB, legacy rules can be reused. In some examples, the rules may be updated as follows: 1> Selected All If SSB or CSI-RS is not changed from the selection in the last random access preamble transmission,

[0219] That means that the power ramping counter is not incremented as long as some SSBs in the set of SSBs for retransmission are different from those of the previous attempt.

[0220] In the following description, a communications device may be any of wireless devices 2512A, 2512B, wired or wireless devices UE 2512C, UE 2512D, UE 2600, virtualization hardware 2904, virtual machines 2908A, 2908B, or UE 3006, but UE 2600 (also referred to herein as communications device 2600) will be used to describe the operational functionality of a communications device. In accordance with some embodiments of the inventive concepts, operation of communications device 2600 (implemented using the block diagram structure of FIG. 26) will now be discussed with reference to the flowchart of FIG. 23. For example, modules may be stored within memory 2610 of FIG. 26 that provide instructions such that the instructions of a module are executed by the processing circuitry 2602 of the respective communications device, causing the processing circuitry 2602 to perform the respective operations of the flowchart.

[0221] FIG. 23 illustrates an example of operations performed by a communications device during an RA procedure associated with a network node of an NR communications network.

[0222] At block 2310, the processing circuit 2602 receives, via the communication interface 2612, an indication of PRACH transmission configuration information from a network node.

[0223] At block 2320, the processing circuit 2602 determines the rsrp-ThresholdMsg3 threshold value based on a flag in the RRC message, which in some embodiments is associated with a particular BWP or preamble feature group.

[0224] At block 2330, the processing circuit 2602 determines information associated with at least one of the communication device and a channel between the communication device and the network node.

[0225] In block 2340, the processing circuit 2602 determines, based on the information, a number of PRACH transmissions to send to the network node as part of the RA procedure (prior to receiving the RAR). In some embodiments, determining the information includes determining an RSRP associated with the channel. Determining the number of PRACH transmissions includes 1) determining the number of PRACH transmissions based on a comparison of the RSRP to a predetermined threshold, 2) determining that an iteration procedure applies to Msg3 transmissions according to the RSRP and the threshold, and 3) repeating the Msg3 transmission at least the number of times indicated in the random access response.

[0226] In a further or alternative embodiment, determining the information includes determining a power headroom of the communications device, and determining the number of PRACH transmissions includes determining the number of PRACH transmissions based on a comparison of an amount of power required for PRACH transmissions to the power headroom.

[0227] In a further or alternative embodiment, determining the number of PRACH transmission signals to transmit to the network node includes receiving an indication of a candidate number of PRACH transmission signals, and determining the number of PRACH transmission signals as the smaller of the candidate number and a number of different Tx beams that the communication device can use for PRACH transmission signals.

[0228] In additional or alternative embodiments, determining the number of PRACH transmission signals includes determining the number of PRACH transmission signals based on an uplink (UL) beam switching time and the amount of time between PRACH opportunities, such that the time between any two consecutive transmission signals is greater than the beam switching time.

[0229] In block 2345, the processing circuit 2602 determines a periodicity associated with the PRACH transmission signal based on the association period.

[0230] At block 2350, the processing circuit 2602 transmits the number of PRACH transmissions to the network node via the communications interface 2612. In some embodiments, transmitting the number of PRACH transmissions includes transmitting a plurality of different preambles across a plurality of ROs associated with SSBs associated with some of the PRACH transmissions.

[0231] In a further or alternative embodiment, the number of PRACH transmission signals includes at least two PRACH transmission signals, and transmitting the number of PRACH transmission signals includes: 1) transmitting the first PRACH transmission signal of the at least two PRACH transmission signals in the first RO of the plurality of ROs with a first preamble based on where in the first RO a preamble group associated with the first PRACH transmission signal is located, and 2) transmitting the second PRACH transmission signal of the at least two PRACH transmission signals in the second RO of the plurality of ROs with a second preamble based on where in the second RO a preamble group associated with the second PRACH transmission signal is located.

[0232] In additional or alternative embodiments, the number of PRACH transmission signals includes at least two PRACH transmission signals each associated with a different uplink (UL) transmit (Tx) beam, and transmitting the number of PRACH transmission signals includes transmitting the at least two PRACH transmission signals using the different UL Tx beams.

[0233] In a further or alternative embodiment, the number of PRACH transmission signals includes at least two PRACH transmission signals, and transmitting the number of PRACH transmission signals includes 1) transmitting a first PRACH transmission signal of the at least two PRACH transmission signals using a first preamble index, 2) determining a second preamble index based on the first preamble index and an offset (e.g., a logical index or a cyclic shift of a root sequence), and 3) transmitting a second PRACH transmission signal of the at least two PRACH transmission signals using the second preamble index.

[0234] In a further or alternative embodiment, the number of PRACH transmission signals includes at least two PRACH transmission signals each associated with a different transmit power, and transmitting the number of PRACH transmission signals includes 1) transmitting the at least two PRACH transmission signals using the different transmit powers, 2) determining each of the different transmit powers according to at least one corresponding path loss value, and 3) determining the different transmit powers according to different values ​​of a power ramping counter.

[0235] In a further or alternative embodiment, the number of PRACH transmission signals includes at least two PRACH transmission signals each associated with a different Timing Advance (TA), and transmitting the number of PRACH transmission signals includes transmitting the at least two PRACH transmission signals using the different TAs.

[0236] In a further or alternative embodiment, the number of PRACH transmission signals includes at least two PRACH transmission signals, and transmitting the number of PRACH transmission signals includes transmitting the at least two PRACH transmission signals in an order based on a path loss associated with each of the at least two PRACH transmission signals.

[0237] In additional or alternative embodiments, the number of PRACH transmission signals includes at least two PRACH transmission signals each associated with a different synchronization signal block (SSB), and transmitting the number of PRACH transmission signals includes transmitting the at least two PRACH transmission signals using UL Tx beams associated with the different SSBs.

[0238] In additional or alternative embodiments, transmitting the number of PRACH transmission signals further includes transmitting an indication that the communications device will transmit the at least two PRACH transmission signals using the different UL Tx beams.

[0239] In a further or alternative embodiment, the number of PRACH transmission signals includes at least two PRACH transmission signals, and transmitting the number of PRACH transmission signals includes transmitting a first PRACH transmission signal of the at least two PRACH transmission signals using a first preamble index, determining a second preamble index by applying the same offset between the first preamble index and a starting preamble index configured for the plurality of PRACH transmission signals in the first RO to a starting preamble index configured for the plurality of PRACH transmission signals in the second RO, and transmitting the second PRACH transmission signal of the at least two PRACH transmission signals using the second preamble index.

[0240] In some embodiments, transmitting the number of PRACH transmissions includes transmitting the number of PRACH transmissions with the periodicity. In further or alternative embodiments, transmitting the number of PRACH transmissions with the periodicity includes transmitting the number of PRACH transmissions during a time period equal to one or more association periods.

[0241] In additional or alternative embodiments, transmitting the number of PRACH transmissions includes transmitting the number of PRACH transmissions during a time period starting at a resource opportunity (RO) index I, defined as mod(I,K)=0, where K is the number of PRACH transmissions.

[0242] In additional or alternative embodiments, for a point in time associated with the number of PRACH transmission signals, there are a plurality of frequency division multiplexed (FDM) resource opportunities (ROs) associated with a selected synchronization signal block (SSB). In some examples, transmitting the number of PRACH transmission signals includes hopping among the plurality of FDMed ROs across the number of PRACH transmission signals based on a number of FDMed ROs configured for the number of PRACH transmission signals associated with a selected SSB.

[0243] In additional or alternative embodiments, transmitting the number of PRACH transmissions comprises transmitting an RO index RO in the frequency domain defined as: start (i) transmitting an i-th PRACH transmission signal among the number of PRACH transmission signals;

number

[0244] In a further or alternative embodiment, transmitting the number of PRACH transmission signals includes transmitting a first PRACH transmission signal of the number of PRACH transmission signals; determining, following transmission of the first PRACH transmission signal, that the first PRACH transmission signal is to be discarded; and, in response to determining that the first PRACH transmission signal is to be discarded, transmitting all remaining PRACH transmission signals of the number of PRACH transmission signals.

[0245] At block 2360, processing circuit 2602 determines that an RAR has not been received. At block 2370, processing circuit 2602 determines at least one of the number of PRACH retransmissions and the transmit power for the PRACH retransmissions based on parameters configured by the network. At block 2380, processing circuit 2602 transmits the number of PRACH retransmissions via communication interface 2612.

[0246] Various operations from the flowchart of Figure 23 may be optional with respect to some embodiments of the communications device and associated methods. In some examples, blocks 2310, 2320, 2360, 2370, and 2380 of Figure 23 may be optional.

[0247] In the following description, network node 2700 will be used to describe the operational functionality of a network node, although the network node may be any of network nodes 2510A, 2510B, core network node 2508, network node 2700, virtualization hardware 2904, virtual machines 2908A, 2908B, or network node 3004. In accordance with some embodiments of the inventive concepts, operation of network node 2700 (implemented using the block diagram structure of FIG. 27) will now be discussed with reference to the flowchart of FIG. 24. For example, modules may be stored within memory 2704 of FIG. 27 that provide instructions such that the instructions of a module are executed by processing circuitry 2702 of the respective network node, causing processing circuitry 2702 to perform the operations of the flowchart.

[0248] FIG. 24 illustrates an example of operations performed by a network node of an NR communication network during an RA procedure associated with a communication device.

[0249] At block 2410, the processing circuit 2702 transmits, via the communication interface 2706, an indication of the PRACH transmission configuration information to the communication device.

[0250] At block 2420, the processing circuit 2702 transmits an indication of the rsrp-ThresholdMsg3 threshold via a flag in an RRC message via the communication interface 2706.

[0251] At block 2430, the processing circuit 2702 may determine information associated with at least one of the communications device and a channel between the communications device and the network node.

[0252] At block 2440, the processing circuit 2702 determines a number of PRACH transmissions to be received from the communication device as part of an RA procedure based on the information. In some embodiments, determining the information includes determining an RSRP associated with the channel. Determining the number of PRACH transmissions includes determining the number of PRACH transmissions based on a comparison of the RSRP to a predetermined threshold.

[0253] In a further or alternative embodiment, determining the information includes determining a power headroom of the communications device, and determining the number of PRACH transmission signals includes determining the number of PRACH transmission signals based on a comparison of an amount of power required for the number of PRACH transmission signals to the power headroom.

[0254] At block 2450, processing circuit 2702 monitors the NR communication network for the number of PRACH transmission signals from the communication device via communication interface 2706. In some embodiments, monitoring the NR communication network for the number of PRACH transmission signals includes monitoring the NR communication network for a plurality of different preambles across a plurality of RA channel opportunities (ROs) associated with synchronization signal blocks associated with some of the plurality of PRACH transmission signals.

[0255] In additional or alternative embodiments, the number of PRACH transmission signals includes at least two PRACH transmission signals each associated with a different uplink (UL) transmit (Tx) beam, and monitoring the NR communication network for the number of PRACH transmission signals includes monitoring the NR communication network for the at least two PRACH transmission signals via different UL Tx beams.

[0256] In a further or alternative embodiment, the number of PRACH transmission signals includes at least two PRACH transmission signals each associated with a different transmit power, and monitoring the NR communication network includes monitoring the NR communication network for the at least two PRACH transmission signals using different transmit powers.

[0257] In a further or alternative embodiment, the number of PRACH transmission signals includes at least two PRACH transmission signals each associated with a different timing advance (TA), and monitoring the NR communication network includes monitoring the at least two PRACH transmission signals using different TAs of the NR communication network.

[0258] In a further or alternative embodiment, the number of PRACH transmission signals includes at least two PRACH transmission signals, and monitoring the NR communication network includes monitoring the NR communication network for the at least two PRACH transmission signals in an order based on a path loss associated with each of the at least two PRACH transmission signals.

[0259] In additional or alternative embodiments, the number of PRACH transmission signals includes at least two PRACH transmission signals each associated with a different synchronization signal beam (SSB), and monitoring the NR communication network includes monitoring the NR communication network for the at least two PRACH transmission signals using different SSBs.

[0260] At block 2460, the processing circuit 2702 determines that a PRACH transmission is not being received.

[0261] At block 2470, the processing circuit 2702 monitors the NR communication network for a number of PRACH retransmissions based on parameters configured by the network.

[0262] Various operations from the flowchart of Figure 24 may be optional with respect to some embodiments of the network entities and associated methods. In some examples, blocks 2410, 2420, 2460, and 2470 of Figure 24 may be optional.

[0263] FIG. 25 illustrates an example of a communication system 2500 according to some embodiments.

[0264] In this example, communications system 2500 includes a telecommunications network 2502 including an access network 2504, such as a radio access network (RAN), and a core network 2506 including one or more core network nodes 2508. Access network 2504 includes one or more access network nodes, such as network nodes 2510a and 2510b (one or more of which may be generally referred to as network nodes 2510), or some other similar Third Generation Partnership Project (3GPP) access node or non-3GPP access point. Network node 2510 facilitates direct or indirect connectivity of user equipment (UE), such as connecting UEs 2512a, 2512b, 2512c, and 2512d (one or more of which may be generally referred to as UEs 2512), to the core network 2506 over one or more wireless connections.

[0265] Exemplary wireless communications over wireless connections include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for carrying information without the use of wires, cables, or other material conductors. Moreover, in various embodiments, communications system 2500 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals, whether via wired or wireless connections. Communications system 2500 may include and / or interface with any type of communications, telecommunications, data, cellular, wireless networks, and / or other similar types of systems.

[0266] The UE 2512 may be any of a wide variety of communication devices, including wireless devices, that are positioned, configured, and / or operable to communicate wirelessly with the network node 2510 and other communication devices. Similarly, the network node 2510 is positioned, capable, configured, and / or operable to communicate, directly or indirectly, with the UE 2512 and / or with other network nodes or equipment within the telecommunications network 2502 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as management within the telecommunications network 2502.

[0267] In the illustrated example, core network 2506 connects network node 2510 to one or more hosts, such as host 2516. The connections may be direct or indirect through one or more intermediary networks or devices. In other examples, a network node may be directly coupled to a host. Core network 2506 includes one or more core network nodes (e.g., core network node 2508) structured with hardware and software components. The functionality of those components may be substantially similar to that described with respect to UEs, network nodes, and / or hosts, and thus those descriptions are generally applicable to the corresponding components of core network node 2508. Exemplary core network nodes include one or more of a Mobile Switching Center (MSC), a Mobility Management Entity (MME), a Home Subscriber Server (HSS), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Subscription Identifier Deciphering Function (SIDF), a Unified Data Management (UDM), a Security Edge Protection Proxy (SEPP), a Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0268] Host 2516 may be owned or controlled by, and operated by or for, a non-operator service provider or provider of access network 2504 and / or telecommunications network 2502. Host 2516 may host a variety of applications to provide one or more services. Examples of such applications include live and pre-recorded audio / video content, data collection services such as acquiring and compiling data about various ambient conditions sensed by multiple UEs, analytics functionality, social media, functionality for controlling or otherwise interacting with remote devices, functionality for alarm and monitoring centers, or any other such functionality performed by a server.

[0269] Overall, the communication system 2500 of Figure 25 enables connectivity between UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as a particular standard, including, but not limited to, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G), a wireless local area network (WLAN) standard such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi), and / or any other suitable wireless communication standard, such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC), ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standard such as LoRa and Sigfox.

[0270] In some examples, telecommunications network 2502 is a cellular network implementing functions standardized by 3GPP. Thus, telecommunications network 2502 may support network slicing to provide different logical networks to different devices connected to telecommunications network 2502. For example, telecommunications network 2502 may provide Ultra-Reliable Low Latency Communications (URLLC) services to some UEs, while providing enhanced Mobile Broadband (eMBB) services to other UEs and massive machine type communications (mMTC) / massive IoT services to still further UEs.

[0271] In some examples, the UE 2512 is configured to transmit and / or receive information without direct human interaction. For example, the UE may be designed to transmit information to the access network 2504 on a predetermined schedule, when triggered by an internal or external event, or in response to a request from the access network 2504. Additionally, the UE may be configured to operate in a single or multi-RAT or multi-standard mode. For example, the UE may be configured and operate in any one or combination of Wi-Fi, NR (New Radio), and LTE, i.e., for Multi-Radio Dual Connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).

[0272] In the above example, hub 2514 communicates with access network 2504 to facilitate indirect communication between one or more UEs (e.g., UE 2512c and / or 2512d) and a network node (e.g., network node 2510b). In some examples, hub 2514 may be a controller, router, content source, analytics, or any of the other communications devices described herein with respect to UEs. For example, hub 2514 may be a broadband router that enables access to core network 2506 for the UE. As another example, hub 2514 may be a controller that sends commands or instructions to one or more actuators in the UE. The commands or instructions may be received from the UE or the network node 2510, or may be accepted by executable code, scripts, processes, or other instructions in hub 2514. As another example, hub 2514 may be a data controller that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of that data. As another example, hub 2514 may be a content source. For example, for UEs that are VR headsets, displays, loudspeakers, or other media delivery devices, hub 2514 may obtain media or data related to VR assets, video, audio, or other sensory information via a network node, and then provide it to the UE either directly, after performing local processing, and / or adding additional local content. In yet another example, hub 2514 acts as a proxy server or orchestrator for the UEs, particularly if one or more of the UEs are low energy IoT devices.

[0273] Hub 2514 may have a constant / permanent or intermittent connection to network node 2510b. Hub 2514 may also enable different communication schemes and / or schedules between hub 2514 and UEs (UEs 2512c and / or 2512d) and between hub 2514 and core network 2506. In other examples, hub 2514 is connected to core network 2506 and / or one or more UEs via a wired connection. Additionally, hub 2514 may be configured to connect to an M2M service provider over access network 2504 and / or to other UEs over a direct connection. In some scenarios, a UE may establish a wireless connection with network node 2510b while still being connected via hub 2514 via a wired or wireless connection. In some embodiments, hub 2514 may be a dedicated hub, i.e., a hub whose primary function is to route communications between UEs and network node 2510b. In other embodiments, hub 2514 may be a non-dedicated hub, i.e., a device that is operable to route communications between UEs and network node 2510b, but that is also operable as a communications origination and / or termination point for any data channel.

[0274] Figure 26 illustrates a UE 2600 according to some embodiments. As used herein, a UE refers to a device capable of, configured, arranged, and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smartphone, a mobile phone, a cell phone, a Voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless camera, a game console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop embedded equipment (LEE), a laptop mounted equipment (LME), a smart device, a wireless customer premises equipment (CPE), a vehicle-mounted or vehicle-embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a Narrowband Internet of Things (NB-IoT) UE, a Machine Type Communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0275] A UE may support device-to-device (D2D) communications, e.g., by implementing 3GPP standards for sidelink communications, dedicated short-range communications (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2E). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the associated device. Instead, a UE may represent a device (e.g., a smart sprinkler controller) that is intended for sale to or operation by a human user, but that may not, at least initially, be associated with a particular human user. Alternatively, a UE may represent a device (e.g., a smart power meter) that is not intended for sale to or operation by an end user, but that may be associated with or operated for the benefit of a user.

[0276] The UE 2600 includes a processing circuit 2602, a power supply 2608, a memory 2610, a communication interface 2612, and / or any other components, or any combination thereof, operably coupled via a bus 2604 to an input / output interface 2606. A given UE may utilize all or a subset of the components shown in FIG. 26. The level of integration between components may vary from one UE to another. Furthermore, a given UE may include multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0277] Processing circuit 2602 is configured to process instructions and data, and may be configured to implement any sequential state machine operable to execute instructions stored as a machine-readable computer program in memory 2610. Processing circuit 2602 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), programmable logic with appropriate firmware, one or more stored computer programs, a general-purpose processor such as a microprocessor or digital signal processor (DSP) with appropriate software, or any combination of the above. For example, processing circuit 2602 may include multiple central processing units (CPUs).

[0278] In the above example, the input / output interface 2606 may be configured to provide one or more interfaces for an input device, an output device, or one or more input / output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, emitters, smart cards, other output devices, or any combination thereof. An input device may enable a user to capture information from the UE 2600. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, webcams, etc.), microphones, sensors, mice, trackballs, directional pads, trackpads, scroll wheels, and smart cards. A presence-sensitive display may include a capacitive or resistive touch sensor for sensing input from a user. The sensor may be, for example, an accelerometer, gyroscope, tilt sensor, force sensor, magnetometer, light sensor, proximity sensor, biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as the input device. For example, a universal serial bus (USB) port may be used to provide input and output devices.

[0279] In some embodiments, the power source 2608 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electrical outlet), a solar-powered device, or batteries, may also be used. The power source 2608 may further include power circuitry for transferring power from the power source 2608 itself and / or the external power source to various portions of the UE 2600 via interfaces, such as input circuits or power cables. The power transfer may be for charging the power source 2608, for example. The power circuitry may perform some shaping, conversion, or other modification of the power from the power source 2608 to make it suitable for the respective components of the UE 2600 that it powers.

[0280] The memory 2610 may be or be configured to include random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, hard disk, removable cartridge, flash drive, etc. In one example, the memory 2610 includes one or more application programs 2614, such as an operating system, a web browser application, a widget, a gadget engine, or other applications, and corresponding data 2616. The memory 2610 may store any of a wide variety of operating systems or combinations of operating systems for use by the UE 2600.

[0281] The memory 2610 may be configured to include multiple physical drive units such as a redundant array of independent disks (RAID), flash memory, a USB flash drive, an external hard disk drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disc (HD-DVD), an optical disk drive, an internal hard disk drive, a Blu-ray optical disk drive, a holographic digital data storage (HDDS) optical disk drive, an external mini-DIMM (Dual In-Line Memory Module), a synchronous dynamic random access memory (SDRAM), an external micro-DIMM (SDRAM), a smart card memory such as a tamper-resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs) such as a USIM and / or an ISIM, other memory, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly known as a "SIM card." The memory 2610 may enable the UE 2600 to access instructions, application programs, and the like stored on a temporary or non-transitory storage medium to offload or upload data. An item of manufacture, such as one utilizing a communication system, may be tangibly embodied as or within the memory 2610, which may be or include a device-readable storage medium.

[0282] The processing circuit 2602 may be configured to communicate with an access network or other networks using a communication interface 2612. The communication interface 2612 may include one or more communication subsystems and may include or be communicatively coupled to an antenna 2622. The communication interface 2612 may include one or more transceivers used to perform communications, such as by communicating with one or more remote transceivers of other devices capable of wireless communication (e.g., other UEs or network nodes within the access network). Each transceiver may include a transmitter 2618 and / or receiver 2620 appropriate for providing network communications (e.g., optical, electrical, frequency-assigned, etc.). Moreover, the transmitter 2618 and receiver 2620 may be coupled to one or more antennas (e.g., antenna 2622), which may share circuit components, software, or firmware, or may alternatively be implemented separately.

[0283] In the illustrated embodiment, the communication capabilities of communication interface 2612 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as using the Global Positioning System (GPS) to determine location, other similar communication capabilities, or any combination thereof. Communications may be implemented in accordance with one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

[0284] Regardless of the type of sensor, the UE may provide an output of data captured by its sensors to a network node via a wireless connection through its communications interface 2612. Data captured by the UE's sensors may be communicated via other UEs to the network node via a wireless connection. The output may be periodic (e.g., every 15 minutes when reporting measured temperature), random (e.g., to even out reports from multiple sensors), in response to a trigger event (e.g., an alert is sent when moisture is detected), on request (e.g., a user-initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0285] As another example, the UE may include an actuator, motor, or switch associated with a communications interface configured to receive wireless input from a network node via a wireless connection. The state of the actuator, motor, or switch may change in response to the received wireless input. For example, the UE may include a motor that adjusts a control surface or rotor of a drone in flight in accordance with the received input, or a robotic arm that performs a medical procedure in accordance with the received input.

[0286] When the UE is in the form of an Internet of Things (IoT) device, it may be a device for use in one or more application domains, including but not limited to wearable technology in the city, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices are or are incorporated into a connected refrigerator or freezer, a TV, a connected lighting device, an electric meter, a robot vacuum cleaner, a voice-controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electric door lock, a connected doorbell, an air conditioning system such as a heat pump, an autonomous vehicle, a surveillance system, a climate monitoring device, a parking monitoring device, a vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for augmented reality (AR) or virtual reality (VR), a wearable for augmented haptics or augmented perception, a water sprinkler, an animal or item tracking device, a sensor for monitoring plants or animals, an industrial robot, an unmanned aerial vehicle (UAV), and any type of medical device such as a heart rate monitor or a remote-controlled surgical robot. A UE in the form of an IoT device comprises other components as described in connection with the UE 2600 shown in FIG. 26, in addition to circuitry and / or software depending on the intended application of the IoT device.

[0287] As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements and transmits results of such monitoring and / or measurements to other UEs and / or network nodes. The UE, in this case, may be an M2M device, which may also be referred to as an MTC device in the 3GPP context. As one specific example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a car, bus, truck, ship, or aircraft, or other equipment that can monitor and / or report on its operational status or other functionality associated with its operation.

[0288] In practice, any number of UEs may be used together for a single use case. For example, a first UE may be a drone or integrated into a drone and provide drone speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When a user makes changes from the remote controller, the first UE may adjust the drone's throttle (e.g., by controlling an actuator) to increase or decrease the drone's speed. The first and / or second UE may also include more than one of the above-described functionalities. For example, a UE may include a sensor and an actuator and handle communication of data for both the speed sensor and the actuator.

[0289] 27 illustrates a network node 2700 according to some embodiments. As used herein, a network node refers to a device that is capable of, configured, arranged, and / or operable to communicate directly or indirectly with UEs and / or other network nodes or devices in a telecommunications network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., wireless access points) and base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)).

[0290] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power levels), and thus may be referred to as femto, pico, micro, or macro base stations, depending on the amount of coverage provided. A base station may also be a relay node or a relay donor node that controls a relay. A network node may include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU), sometimes referred to as a remote radio head (RRH). Such remote radio units may or may not be integrated with an antenna, such as an antenna-integrated radio. Some distributed radio base stations may also be referred to as nodes in a distributed antenna system (DAS).

[0291] Other examples of network nodes include multi-transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as an MSR BS, a network controller such as a radio network controller (RNC) or base station controller (BSC), a base transceiver station (BTS), a transmission point, a transmitting node, a multi-cell / multicast coordination entity (MCE), an operation and maintenance (O&M) node, an operation support system (OSS) node, a self-organizing network (SON) node, a positioning node (e.g., an evolved serving mobile location center (E-SMLC) and / or a minimized drive test (MDT).

[0292] The network node 2700 includes a processing circuit 2702, a memory 2704, a communication interface 2706, and a power source 2708. The network node 2700 may be composed of multiple physically separate components (e.g., a Node B component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have its own respective components. In certain scenarios in which the network node 2700 includes multiple separate components (e.g., a BTS and a BSC component), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple Node Bs. In such scenarios, each unique pair of Node B and RNC may, in some examples, be considered a single separate network node. In some embodiments, the network node 2700 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be redundant (e.g., separate memories 2704 for different RATs) and some components may be reused (e.g., the same antenna 2710 may be shared by different RATs). Network node 2700 may also include multiple sets of the various illustrated components for different wireless technologies, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, RFID (Radio Frequency Identification), or Bluetooth wireless technologies, that are integrated into network node 2700. The wireless technologies may be integrated into the same or different chips or sets of chips and other components within network node 2700.

[0293] The processing circuitry 2702 may include one or more combinations of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or other suitable computing device, resources, or combination of hardware, software, and / or coded logic operable, alone or in conjunction with other network node 2700 components, such as memory 2704, to provide the functionality of the network node 2700.

[0294] In some embodiments, the processing circuit 2702 comprises a system on a chip (SOC). In some embodiments, the processing circuit 2702 includes one or more of a radio frequency (RF) transceiver circuit 2712 and a baseband processing circuit 2714. In some embodiments, the radio frequency (RF) transceiver circuit 2712 and the baseband processing circuit 2714 may be on separate chips (or set of chips), boards, or units, such as a radio unit and a digital unit. In alternative embodiments, some or all of the RF transceiver circuit 2712 and the baseband processing circuit 2714 may be on the same chip or set of chips, board, or unit.

[0295] Memory 2704 may include any type of volatile or non-volatile computer-readable memory, including, but not limited to, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, compact disc (CD) or digital video disc (DVD)), and / or any other volatile or non-volatile non-transitory device-readable and / or computer-executable memory device that stores information, data and / or instructions that can be used by processing circuit 2702. Memory 2704 may store any suitable instructions, data or information, including applications, including one or more of computer programs, software, logic, rules, code, tables, and / or other instructions, that are executable by processing circuit 2702 and usable by network node 2700. The memory 2704 may be used to store any computational results produced by the processing circuit 2702 and / or any data received via the communication interface 2706. In some embodiments, the processing circuit 2702 and the memory 2704 are integrated.

[0296] The communications interface 2706 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or the UE. As shown, the communications interface 2706 includes a port / terminal 2716 for transmitting and receiving data to and from a network, for example, over a wired connection. The communications interface 2706 also includes radio front-end circuitry 2718, which is coupled to the antenna 2710 or, in some embodiments, may be part of the antenna 2710. The radio front-end circuitry 2718 includes a filter 2720 and an amplifier 2722. The radio front-end circuitry 2718 may be connected to the antenna 2710 and the processing circuit 2702. The radio front-end circuitry may be configured to condition signals communicated between the antenna 2710 and the processing circuit 2702. The radio front-end circuitry 2718 may accept digital data to be sent to another network node or the UE via a wireless connection. The radio front-end circuitry 2718 may convert the digital data into a radio signal having appropriate channel and bandwidth parameters using a combination of filters 2720 and / or amplifiers 2722. The radio signal may then be transmitted via the antenna 2710. Similarly, when data is received, the antenna 2710 collects the radio signal, which may then be converted into digital data by the radio front-end circuitry 2718. The digital data may be passed to the processing circuitry 2702. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0297] In an alternative embodiment, the network node 2700 may not include a separate radio front-end circuit 2718; rather, the processing circuit 2702 may include the radio front-end circuitry and may be connected to the antenna 2710. Similarly, in some embodiments, all or some of the RF transceiver circuitry 2712 is part of the communications interface 2706. In yet another embodiment, the communications interface 2706 includes one or more ports or terminals 2716, the radio front-end circuitry 2718, and the RF transceiver circuitry 2712 as part of a radio unit (not shown), and the communications interface 2706 communicates with baseband processing circuitry 2714 that is part of a digital unit (not shown).

[0298] Antenna 2710 may include one or more antennas or an antenna array configured to transmit and / or receive wireless signals. Antenna 2710 may be coupled to radio front-end circuitry 2718 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 2710 is separate from network node 2700 and connectable to network node 2700 through an interface or port.

[0299] The antenna 2710, the communication interface 2706, and / or the processing circuit 2702 may be configured to perform any receiving operation and / or any obtaining operation described herein as being performed by a network node. Any information, data, and / or signals may be received from a UE, another network node, and / or any other network equipment. Similarly, the antenna 2710, the communication interface 2706, and / or the processing circuit 2702 may be configured to perform any transmitting operation described herein as being performed by a network node. Any information, data, and / or signals may be transmitted to a UE, another network node, and / or any other network equipment.

[0300] The power supply 2708 provides power to the various components of the network node 2700 in a format appropriate for each component (e.g., at the voltage and current levels required for each component). The power supply 2708 may include or be coupled to power management circuitry for providing power to the components of the network node 2700 to perform the functionality described herein. For example, the network node 2700 may be connectable to an external power source (e.g., a power grid, an electrical outlet) via an input circuit or interface, such as an electrical cable, whereby the external power source provides power to the power circuitry of the power supply 2708. As a further example, the power supply 2708 may include a source of power in the form of a battery or battery pack connected to or integrated into the power circuitry. The battery may provide backup power in case of failure of the external power source.

[0301] Embodiments of network node 2700 may include additional components beyond those shown in Figure 27 to provide certain aspects of the network node's functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, network node 2700 may include user interface devices that allow information to be input into network node 2700 and information to be output from network node 2700. This may enable a user to perform diagnostic, maintenance, repair, and other administrative functions on network node 2700.

[0302] 28 is a block diagram of a host 2800, which may be an embodiment of the host 2516 of FIG. 25, in accordance with various aspects described herein. As used herein, the host 2800 may be or include hardware and / or software in various combinations, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, a container, or processing resources within a server farm. The host 2800 may provide one or more services to one or more UEs.

[0303] Host 2800 includes a processing circuit 2802 operably coupled via bus 2804 to an input / output interface 2806, a network interface 2808, a power supply 2810, and memory 2812. In other embodiments, other components may be included, the functionality of which may be substantially similar to those described with respect to the devices in previous figures, such as Figures 26 and 27, and therefore those descriptions are generally applicable to the corresponding components of host 2800.

[0304] Memory 2812 may include one or more computer programs, including one or more host application programs 2814, and data 2816, which may include user data, such as data generated by a UE for the host 2800 or data generated by the host 2800 for the UE. An embodiment of the host 2800 may utilize only a subset or all of the illustrated components. The host application programs 2814 may be implemented in a container-based architecture and may provide support for video codecs (Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G_711), including transcoding for different UE classes, types, or implementations (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application program 2814 may also provide user authentication and license checks, and may periodically report health, route, and content availability to a central node, such as a device in or at the edge of the core network. Thus, the host 2800 may select and / or point to different hosts for over-the-top services for the UE. The host application program 2814 may support a variety of protocols, such as HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0305] FIG. 29 is a block diagram illustrating a virtualization environment 2900 in which functionality implemented according to some embodiments may be virtualized. In this context, virtualization means for creating a virtual version of an apparatus or device may include a virtualized hardware platform, storage devices, and networking resources. As used herein, virtualization may apply to any device or component thereof described herein and refers to implementations in which at least a portion of its functionality is implemented as one or more virtual components. Some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented within one or more virtual environments 2900 hosted by one or more hardware nodes, such as a network node, a UE, a core network node, or a hardware computing device acting as a host. Furthermore, in embodiments in which a virtualized node does not require wireless connectivity (e.g., a core network node or a host), the node may be virtualized in its entirety.

[0306] An application 2902 (which may alternatively be referred to as a software instance, a virtual appliance, a network function, a virtual node, a virtual network function, etc.) runs in the virtualized environment Q400 to implement some of the features, functions and / or benefits of some of the embodiments disclosed herein.

[0307] Hardware 2904 may include processing circuitry, memory for storing software and / or instructions executable by the processing circuitry, and / or hardware devices as described herein, such as network interfaces and input / output interfaces. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 2906 (also referred to as a hypervisor or virtual machine monitor (VMM)), provide VMs 2908a and 2908b (one or more of which may be collectively referred to as VMs 2908), and / or perform any of the functions, features, and / or benefits described in connection with some embodiments described herein. Virtualization layer 2906 may present a virtual operating platform that appears to virtual machines 2908 as networking hardware.

[0308] VMs 2908 may include virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be executed by a corresponding virtualization layer 2906. Various embodiments of instances of virtual appliances 2902 may be implemented in one or more of the VMs 2908, and the implementation may be done in various ways. Hardware virtualization is referred to in some contexts as network functions virtualization (NFV). NFV may be used to aggregate many network equipment types into industry-standard, high-capacity server hardware, physical switches, and physical storage that may be located in data centers and customer premises equipment.

[0309] In the context of NFV, a VM 2908 may be a software implementation of a physical machine that runs programs as if they were running on a physical, non-virtualized machine. Each VM 2908 and the portion of hardware 2904 on which that VM runs, whether on hardware dedicated to that VM and / or shared by that VM with other VMs, forms a separate virtual network element. Also in the context of NFV, a virtual network function is responsible for handling specific network functions running in one or more VMs 2908 on top of the hardware 2904 and corresponds to the application 2902.

[0310] The hardware 2904 may be implemented in a standalone network node with generic or proprietary components. The hardware 2904 may implement some functions via virtualization. Alternatively, the hardware 2904 may be part of a larger hardware cluster (e.g., in a data center or CPE) where multiple hardware nodes cooperate and are managed via management and orchestration 2910, which oversees, among other things, the lifecycle management of the application 2902. In some embodiments, the hardware 2904 is coupled to one or more radio units, each including one or more transmitters and one or more receivers, which may be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces or may be used in combination with virtual components, such as radio access nodes or base stations, to provide wireless capabilities to virtual nodes. In some embodiments, some signaling may be provided with the use of a control system 2912, which may alternatively be used for communication between the hardware nodes and the radio units.

[0311] Figure 30 shows a communications diagram of a host computer 3002 communicating with a UE 3006 via a network node 3004 over a partially wireless connection according to some embodiments. Exemplary implementations according to various embodiments of the UE (UE 2512a of Figure 25 and / or UE 2600 of Figure 26), network node (network node 2510a of Figure 25 and / or network node 2700 of Figure 27), and host (host 2516 of Figure 25 and / or host 2800 of Figure 28) discussed in the previous paragraphs will now be described with reference to Figure 30.

[0312] Similar to host 2800, an embodiment of host 3002 includes hardware such as a communications interface, processing circuitry, and memory. Host 3002 also includes software stored within or accessible by host 3002 and executable by the processing circuitry. The software includes a host application that may be operable to provide services to a remote user, such as UE 3006, connecting via an over-the-top (OTT) connection 3050 extending between UE 3006 and host computer 3002. During the provision of services to the remote user, the host application may provide user data that is transmitted using OTT connection 3050.

[0313] The network node 3004 includes hardware that enables communication with the host 3002 and the UE 3006. The connection 3060 may be direct or may pass through one or more other intermediate networks, such as a core network (such as the core network 2506 of FIG. 25) and / or one or more public, private, or hosted networks. For example, the intermediate network may be a backbone network or the Internet.

[0314] The UE 3006 also includes software stored within or accessible by the UE 3006 and executable by the UE's processing circuitry. This software includes client applications, such as a web browser or operator-specific "apps," that, with the support of the host 3002, may be operable to provide services to a human or non-human user via the UE 3006. Host applications running on the host 3002 may communicate with client applications running on the host 3002 via an OTT connection 3050 that terminates at the UE 3006 and the host 3002. During the provision of services to the user, the UE's client applications may receive request data from the host application and provide user data in response to the request data. The OTT connection 3050 may transport both the request data and user data. The UE's client applications may interact with the user to generate user data that they provide to the host application through the OTT connection 3050.

[0315] The OTT connection 3050 may extend via a connection 3060 between the host 3002 and the network node 3004 and via a wireless connection 3070 between the network node 3004 and the UE 3006, providing connectivity between the host 3002 and the UE 3006. The connection 3060 and the wireless connection 3070 over which the OTT connection 3050 may be provided are depicted abstractly to illustrate communication between the host 3002 and the UE 3006 via the network node 3004 without explicit reference to any intermediate devices and the precise routing of messages through those devices.

[0316] As an example of transmitting data over the OTT connection 3050, in step 3008, the host 3002 provides user data, which may be done by executing a host application. In some embodiments, the user data is associated with a specific human user interacting with the UE 3006. In other embodiments, the user data is associated with the UE 3006 sharing data with the host 3002 without explicit human interaction. In step 3010, the host 3002 initiates a transmission to the UE 3006 carrying user data. The host 3002 may initiate the transmission in response to a request sent by the UE 3006. The request may be triggered by human interaction with the UE 3006 or by the operation of a client application running on the UE 3006. The transmission may pass through the network node 3004 in accordance with the teachings of embodiments described throughout this disclosure. In response, in step 3012, the network node 3004 transmits the user data carried in the transmission initiated by the host 3002 to the UE 3006, in accordance with the teachings of embodiments described throughout this disclosure. In step 3014, the UE 3006 receives the user data carried in the transmission, which may be done by a client application running on the UE 3006 that is associated with a host application executed by the host 3002.

[0317] In some examples, the UE 3006 executes a client application, which provides user data destined for the host 3002. The user data may be provided in reaction or response to receiving the data from the host 3002. In response, the UE 3006 may provide the user data in step 3016, which may be done by executing the client application. During the provision of the user data, the client application may further consider user input received from the user via an input / output interface of the UE 3006. Regardless of the specific manner in which the user data is provided, the UE 3006 initiates transmission of the user data to the host 3002 via the network node 3004 in step 3018. In step 3020, the network node 3004 receives the user data from the UE 3006 and initiates transmission of the received user data to the host 3002, in accordance with the teachings of embodiments described throughout this disclosure. In step 3022, the host 3002 receives the user data carried in the transmission initiated by the UE 3006.

[0318] One or more of the various embodiments improve the performance of the OTT service provided to the UE 3006 using the OTT connection 3050, of which the radio connection 3070 forms the final segment. More precisely, the teachings of these embodiments may enable the identification of the UL Tx beam to be used for Msg3 transmission.

[0319] In an exemplary scenario, factory status information may be collected and analyzed by the host 3002. As another example, the host 3002 may process audio and video data, possibly obtained from UEs, for use in generating maps. As another example, the host 3002 may collect and analyze real-time data to assist in traffic congestion control (e.g., traffic light control). As another example, the host 3002 may store surveillance video uploaded by UEs. As another example, the host 3002 may store or control access to media content, such as video, audio, VR, or AR, that may be broadcast, multicast, or unicast to UEs. As another example, the host 3002 may be used for energy pricing, remote control of non-time-critical power loads for balancing power generation needs, location services, presentation services (e.g., compiling diagrams from data collected from remote devices), or any other function that collects, acquires, stores, analyzes, and / or transmits data.

[0320] In some examples, measurement procedures may be provided to monitor data rates, latency, and other factors that may be improved by one or more embodiments. There may also be optional network functionality for reconfiguring the OTT connection 3050 between the host 3002 and the UE 3006 in response to fluctuations in the measurements. The measurement procedures and / or network functionality for reconfiguring the OTT connection may be implemented in software and hardware in the host 3002 and / or the UE 3006. In some embodiments, sensors (not shown) may be deployed in or associated with other devices through which the OTT connection 3050 passes, and these sensors may participate in the measurement procedures by providing values ​​for the monitored quantities exemplified above or other physical quantities from which the monitored quantities may be calculated or estimated by software. Reconfiguration of the OTT connection 3050 may include message formats, retransmission settings, preferred routing, etc., and the reconfiguration need not directly change the operation of the network node 3004. Such procedures and functionality may be known or practiced in the art. In one embodiment, the measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation time, latency, etc. by the host 3002. The measurements may be implemented by software sending messages over the OTT connection 3050, specifically empty or "dummy" messages, while monitoring propagation time, errors, etc.

[0321] While the computing devices (e.g., UEs, network nodes, hosts) described herein may include combinations of the illustrated hardware components, other embodiments may include computing devices with different combinations of components. It should be understood that the computing devices may include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determining, calculating, obtaining, or similar operations described herein may be performed by processing circuitry, which may process information by, for example, transforming the obtained information into other information, comparing the obtained or transformed information with information stored at a network node, and / or performing one or more operations based on the obtained or transformed information, and making a decision as a result of the processing. Moreover, while components are depicted as single boxes located within larger boxes or nested within multiple boxes, in reality, the computing device may include multiple different physical components that make up the illustrated single component, and functionality may be partitioned among the separate components. For example, a communication interface may be configured to include any of the components described herein, and the functionality of those components may be partitioned between the processing circuitry and the communication interface. In other examples, the computationally less intensive functions of any of these components may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.

[0322] In some embodiments, some or all of the functionality described herein may be provided by a processing circuit executing instructions stored in a memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by a processing circuit, such as in a hardwired manner, without executing instructions stored on a separate or discrete device-readable storage medium. In any of these specific embodiments, the processing circuit can be configured to perform the described functionality regardless of whether it executes instructions stored on a non-transitory computer-readable storage medium. Benefits provided by such functionality are not limited to just the processing circuit or other components of the computing device, but are enjoyed by the computing device as a whole and / or by end users and wireless networks in general.

Claims

1. 1. A method of operating a communications device during a random access (RA) procedure associated with a network node of a New Radio (NR) communications network, comprising: determining 2330 information associated with at least one of the communication device and a channel between the communication device and the network node; determining (2340) based on the information a number of Physical RA Channel (PRACH) transmissions to transmit to the network node prior to receiving a Random Access Response as part of the RA procedure, the PRACH transmissions being associated with the same Synchronization Signal Block (SSB); transmitting (2350) the number of PRACH transmissions to the network node as part of the RA procedure; Including, The method, wherein the number of PRACH transmission signals includes at least two PRACH transmission signals each associated with a different transmit power.

2. 10. The method of claim 1 further comprising: determining 2345 a periodicity associated with the PRACH transmission based on an association period; Including, The method, wherein transmitting the number of PRACH transmission signals includes transmitting the number of PRACH transmission signals using the periodicity.

3. 3. The method of claim 2, wherein transmitting the number of PRACH transmissions with the periodicity comprises transmitting the number of PRACH transmissions during a time period equal to one or more association periods.

4. 3. The method of claim 2, wherein transmitting the number of PRACH transmissions comprises transmitting the number of PRACH transmissions during a time period starting at a resource opportunity (RO) index I, defined as mod(I, K) = 0, where K is the number of PRACH transmissions.

5. 10. The method of claim 1, For a given point in time associated with the number of PRACH transmissions, there are a plurality of frequency division multiplexed (FDM) resource opportunities (ROs) associated with the SSB; transmitting the number of PRACH transmission signals includes hopping among the plurality of FDMed ROs across the number of PRACH transmission signals based on a number of FDMed ROs configured for the number of PRACH transmission signals associated with the SSB.

6. 2. The method of claim 1, wherein transmitting the number of PRACH transmission signals comprises: transmitting a first PRACH transmission signal of the number of PRACH transmission signals; determining, following transmission of the first PRACH transmission, that the first PRACH transmission is to be discarded; transmitting all remaining PRACH transmission signals of the number of PRACH transmission signals in response to determining that the first PRACH transmission signal is discarded; A method comprising:

7. 10. The method of claim 1, determining the information includes determining a power headroom of the communication device; The method, wherein determining the number of PRACH transmissions includes determining the number of PRACH transmissions based on a comparison of an amount of power required for PRACH transmissions to the power headroom.

8. 2. The method of claim 1, wherein transmitting the number of PRACH transmission signals comprises transmitting a plurality of different preambles over a plurality of RA channel opportunities (ROs) associated with synchronization signal blocks associated with the PRACH transmission signals.

9. 9. The method of claim 8, Transmitting the number of PRACH transmission signals includes: transmitting the first PRACH transmission of the at least two PRACH transmissions in the first RO of the plurality of ROs using a first preamble based on where in the first RO a preamble group associated with the first PRACH transmission is located; transmitting the second PRACH transmission signal of the at least two PRACH transmission signals in the second RO of the plurality of ROs with a second preamble based on where in the second RO a preamble group associated with the second PRACH transmission signal is located.

10. 10. The method of claim 1, Transmitting the number of PRACH transmission signals includes: transmitting the at least two PRACH transmission signals using the different transmit powers; determining each of the different transmit powers according to at least one of the corresponding path loss values; A method comprising:

11. 10. The method of claim 1, the at least two PRACH transmission signals are each associated with a different timing advance (TA); 4. The method of claim 3, wherein transmitting the number of PRACH transmissions comprises transmitting the at least two PRACH transmissions using the different TAs.

12. 10. The method of claim 1, 4. The method of claim 3, wherein transmitting the number of PRACH transmission signals comprises transmitting the at least two PRACH transmission signals in an order based on a path loss associated with each of the at least two PRACH transmission signals.

13. 1. A method of operating a network node of a New Radio (NR) communications network during a Random Access (RA) procedure associated with a communications device, the method comprising: determining 2430 information associated with at least one of the communication device and a channel between the communication device and the network node; determining, based on the information, a number of Physical RA Channel (PRACH) transmissions to receive from the communication device as part of the RA procedure, the PRACH transmissions being associated with the same Synchronization Signal Block (SSB) (2440); As part of the RA procedure, monitoring the NR communication network for the number of PRACH transmissions from the communication device (2450); Including, The method, wherein the number of PRACH transmission signals includes at least two PRACH transmission signals each associated with a different transmit power.

14. A communication device (2600), A processing circuit (2602); A communications device comprising: a memory (2610) coupled to the processing circuitry and having instructions stored therein, the instructions being executable by the processing circuitry to cause the communications device to perform a method according to any one of claims 1 to 12.

15. A network node (2700), comprising: A processing circuit (2702); a memory (2704) coupled to the processing circuitry and having instructions stored therein, the instructions being executable by the processing circuitry to cause the network node to perform the method of claim 13.

Citation Information

Patent Citations

  • RACH Procedures Using Multiple PRACH Transmissions

    JP2019532583A

  • RACH Power Offset

    JP2020519172A

  • Repetition of prach preamble transmission for ues

    US20210058971A1

  • Coverage for physical random access channel and repetition of CSI report on pusch for coverage enhancement

    US20220038935A1