WO2024150195A1

WO2024150195A1 - Communication device determination of random access channel resources for multiple physical random access channel transmissions

Info

Publication number: WO2024150195A1
Application number: PCT/IB2024/050349
Authority: WO
Inventors: Ling Su; Yuande TAN; Oskar MYRBERG
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2023-01-13
Filing date: 2024-01-12
Publication date: 2024-07-18

Abstract

A communication device can transmit (2810) a plurality of physical random access channel ("PRACH") transmissions to the network node as part of a random access ("RA") procedure. The communication device can further determine (2820) a random access-radio network temporary identifier (" RA-RNTI") for the plurality of PRACH transmissions based on a specific RA channel occasion ("RO") of a set of ROs that are determined before applying collision handling rules to the plurality of PRACH transmissions.

Description

COMMUNICATION DEVICE DETERMINATION OF RANDOM ACCESS CHANNEL RESOURCES FOR MULTIPLE PHYSICAL RANDOM ACCESS CHANNEL TRANSMISSIONS

TECHNICAL FIELD

[0001] The present disclosure is related to wireless communication systems and more particularly to a communication device determining a random access channel (“RACH”) resource for multiple physical RACH (“PRACH”) transmissions.

BACKGROUND

[0002] FIG. 1 illustrates an example of a new radio (“NR”) network (e.g., a 5th Generation (“5G”) network) including a 5G core (“5GC”) network 130, network nodes 120a-b (e.g., 5G base station (“gNB”)), multiple communication devices 110 (also referred to as user equipment (“UE”)).

[0003] Random access channel (“RACH”) repetition was introduced in Rel-13 work items (“Wis”) of "Further LTE Physical Layer Enhancements for MTC" and “NarrowBand IOT (NB-IOT)”to extend coverage in Long Term Evolution (“LTE”), although RACH repetition is not presently supported in NR releases up to Rel-17.

[0004] Repetition of the information is a technique to achieve coverage enhancements. It can be used for all physical channels available for coverage enhanced UEs in LTE, for example, machine-type communication physical downlink control channel (“M-PDCCH”), physical broadcast channel (“PBCH”), physical downlink shared channel (“PDSCH”), physical uplink control channel (“PUCCH”), physical uplink shared channel (“PUSCH”), and physical random access channel (“PRACH”).

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

[0006] During an initial random access the UE can measure the downlink (“DL”) quality. The UE can select a suitable repetition level for its initial PRACH preamble transmission among 4 levels. If the UE does not receive a random access response (“RAR”) it can increase its PRACH repetition level. A number of repetitions for RAR and following messages can depend on the level for the successful PRACH

[0007] Coverage enhancement for the physical random access PRACH preamble can be achieved partly through relaxation of the required PRACH misdetection probability and partly through repetition of the legacy LTE PRACH formats. A maximum of three different repetition levels (plus the zero coverage enhancement level) can be configured, where each level has its own configurable number of repetitions and attempts in order to adapt to the UE’s coverage situation. For initial random access the UE choses its repetition level based on RSRP measurements. If the UE does not receive a RAR after the maximum number of attempts of its current level, it moves to the next higher one. No power ramping is used for large repetition levels; otherwise the current procedure is used. Different coverage levels correspond to different PRACH resources (e.g., different combinations of preamble sequences, timing, and narrowbands) and the available resources are signaled in a system information block (“SIB”). [0008] The RAR message in LTE can be scheduled with M-PDCCH and an associated PDSCH. The UE can know the repetition level, possible start subframe, and frequency resource of the M-PDCCH from its most recent PRACH transmission (in combination with information signaled in SIB).

[0009] To enable different operation modes depending on a UE’s need of coverage extension, two coverage enhancement modes have been introduced for RRC_CONNECTED LTE UEs: coverage extension (“CE”) mode A and CE mode B. CE mode A is for no or small coverage enhancement, requiring a few (e.g. up to a few tens of) repetitions. CE mode B is for a medium to large coverage enhancement, requiring several (e.g., hundreds of) repetitions. The CE mode can be signaled to the UE by the network.

SUMMARY

[0010] There currently exist certain challenges. In new radio (“NR”) up to release 17 (“Rel- 17”), random access channel (“RACH”) resources are configured for single physical RACH (“PRACH”) transmission. NR release 18 (“Rel-18”) supports multiple PRACH transmissions for a RACH attempt. A gNB may need to configure a set of RACH resources for multiple PRACH transmissions, and a UE determines the number of multiple PRACH transmissions for a RACH attempt and the corresponding set of RACH occasions.

[0011] For PRACH transmissions multiplexed in frequency domain, each PRACH is transmitted in one of the frequency division multiplexed (“FDMed”) PRACH occasions (“ROs”). If only one random access-radio network temporary identifier (“RA-RNTI”) is assumed for the PRACH transmissions, it is unclear which RO is used to calculate RA-RNTI. Similarly, for PRACH transmissions multiplexed in code domain, a UE transmits multiple PRACH preambles simultaneously with different transmission (“Tx”) chains in one RO. If only one random access preamble identifier (“RAPID”) is assumed for the PRACH transmissions, it is unclear which preamble is used. [0012] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. Various embodiments describe gNB configuration and UE determination of a set of RACH occasions for multiple PRACH transmissions, UE determination of RA-RNTI in case of PRACH transmission cancellation and simultaneous PRACH transmissions and UE determination of the number of PRACH transmissions in different cases.

[0013] According to some embodiments, a method of operating a communication device is provided. The method includes determining a feature combination, FC, based on one or more features associated with at least one of: a capability of the communication device; a number of physical random access channel, PRACH, transmissions to transmit to a network node as part of a random access, RA, procedure; and a capability of the network node. The method further includes transmitting a PRACH transmission based on the FC as part of the RA procedure. [0014] According to other embodiments, a method of operating a communication device during a random access, RA, procedure associated with a network node of a communications network is provided. The method includes determining a physical RA channel occasion, RO, offset configured to indicate an index of a second RO relative to a first RO associated with a set of PRACH transmissions. The method further includes transmitting a first PRACH transmission of the set of PRACH transmissions to the network node at the first RO as part of the RA procedure. The method further includes determining the second RO based on the first RO and the RO offset. The method further includes transmitting a second PRACH transmission of the set of PRACH transmissions to the network node at the second RO as part of the RA procedure. [0015] According to other embodiments, a method of operating a communication device during a random access, RA, procedure associated with a network node of a communications network is provided. The method includes transmitting a plurality of physical RA channel, PRACH, transmissions to the network node as part of the RA procedure. The method further includes determining a random access-radio network temporary identifier, RA-RNTI for the plurality of PRACH transmissions based on a specific RA channel occasion, RO, of at least one PRACH transmission of the plurality of PRACH transmissions.

[0016] According to other embodiments, a method of operating a communication device during a random access, RA, procedure associated with a network node of a communications network is provided. The method includes responsive to transmitting a plurality of physical RA channel, PRACH, transmissions with different preambles in one PRACH occasion, RO, receiving a RA response, RAR, including a RA radio network temporary identifier, RA-RNTI. The method further includes determining if the RAR includes a RA preamble identifier, RAPID, that matches a preamble index associated with the plurality of PRACH transmissions. [0017] According to other embodiments, a method of operating a communication device during a random access, RA, procedure associated with a network node of a communications network is provided. The method includes determining a number of physical RA channel, PRACH, transmissions to transmit to the network node with the same transmission, Tx, beam prior to receiving a random access response as part of the RA procedure based on whether the communication device is capable of beam correspondence for PRACH transmission. The method further includes transmitting the number of PRACH transmissions to the network node as part of the RA procedure.

[0018] According to other embodiments, a method of operating a communication device during a random access, RA, procedure associated with a network node of a communications network is provided. The method includes determining a first number of physical RA channel, PRACH, transmissions to transmit to the network node using a first transmission, Tx, beam prior to receiving a random access response as part of the RA procedure using a first procedure. The method further includes, responsive to transmitting the first number of PRACH transmissions to the network node as part of the RA procedure without receiving the RAR, determining whether to perform retransmission using a second Tx beam that is different than the first Tx beam. The method further includes determining a second number of PRACH transmissions to transmit to the network node based on whether the second Tx beam will be used to transmit the second number of PRACH transmissions.

[0019] According to other embodiments, a method of operating a communication device during a random access, RA, procedure associated with a network node of a communications network is provided. The method includes determining a number of physical RA channel, PRACH, transmissions to transmit to the network node prior to receiving a RA response as part of the RA procedure. The method further includes, responsive to determining the number of PRACH transmissions, determining that transmitting the number of PRACH transmissions will cause an uplink, UL, transmission percentage in an evaluation period to exceed an UL duty cycle. The method further includes, responsive to determining that transmitting the number of PRACH transmissions will cause the UL transmission percentage in the evaluation period to exceed the UL duty cycle, performing an action associated with the number of PRACH transmissions.

[0020] According to other embodiments, a communication device, a network node, a computer program, a computer program product, a non-transitory computer readable medium, a host, or a communication system is provided to perform the method above.

[0021] Certain embodiments may provide one or more of the following technical advantages. In some examples, determining a RACH resource and transmission power for multiple PRACH transmissions can reduce the time it takes for a UE to connect to a communications network and improve the resulting connection.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] 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 inventive concepts. In the drawings:

[0023] FIG. 1 is a schematic diagram illustrating an example of a 5^th generation (“5G”) network;

[0024] FIG. 2 is a table illustrating an example of frame structure type 2 random access configurations for preamble formats 0-4;

[0025] FIG. 3 is a table illustrating an example of frame structure type 2 random access preamble mapping in time and frequency;

[0026] FIG. 4 is a table illustrating an example of random access preamble parameters for frame structure type 2;

[0027] FIG. 5 is a table illustrating an example of random access configurations for FR1 and unpaired spectrum;

[0028] FIG. 6 is a table illustrating an example of random access configurations for FR2 and unpaired spectrum;

[0029] FIG. 7 is a table illustrating an example of a TPC command for PUSCH;

[0030] FIG. 8 is a table illustrating an example of mapping between PRACH configuration period and SS/PBCH block to PRACH occasion association period;

[0031] FIG. 9 is a diagram illustrating an example of a RACH-ConfigCommon IE;

[0032] FIG. 10 is a diagram illustrating an example of a ServingCellConfigCommon IE;

[0033] FIG. 11 is a diagram illustrating an example of a BeamFailureRecoveryConfig IE;

[0034] FIG. 12 is a diagram illustrating an example of feature combinations in accordance with some embodiments;

[0035] FIG. 13 is a flow chart illustrating an example of multiple PRACH transmissions depending on UE implementation in accordance with some embodiments;

[0036] FIG. 14 is a diagram illustrating an example of PRACH-ParametersCE IE in accordance with some embodiments;

[0037] FIG. 15 is a diagram illustrating an example of feature combinations in accordance with some embodiments;

[0038] FIGS. 16A-C are block diagrams illustrating examples of RO groups of FDMed or TDMed ROs in accordance with some embodiments; [0039] FIG. 17 is a diagram illustrating an example of non-overlapping ROs for a selected SSB in accordance with some embodiments;

[0040] FIG. 18 is a diagram illustrating an example of SSB RSRP thresholds in accordance with some embodiments;

[0041] FIGS. 19-20 are schematic diagrams illustrating examples of an implementation of a UE incapable of beamCorrespondenceWithoutUL-BeamSweeping in accordance with some embodiments;

[0042] FIG. 21 is a table illustrating an example of different PRACH transmission schemes for initial attempt and reattempt in accordance with some embodiments;

[0043] FIG. 22 is a table illustrating an example of different numbers of repetition based on different beam patterns in accordance with some embodiments;

[0044] FIG. 23 is a block diagram illustrating an example of an UL duty cycle reached during multiple PRACH transmissions in accordance with some embodiments;

[0045] FIG. 24 is a block diagram illustrating an example of a applying P-MPR for PRACH within a 1 second time evaluation window including the transmitted PRACH/PUSCH/PUCCH/SRS in accordance with some embodiments;

[0046] FIG. 25 is a block diagram illustrating an example of no P-MPR for PRACH within a 1 second time evaluation window including an additional delay on PRACH transmission in accordance with some embodiments;

[0047] FIGS. 26-32 are flow charts illustrating examples of operations performed by a communication device in accordance with some embodiments;

[0048] FIGS. 33-35 are flow charts illustrating examples of operations performed by a network node in accordance with some embodiments;

[0049] FIG. 36 is a block diagram of a communication system in accordance with some embodiments;

[0050] FIG. 37 is a block diagram of a user equipment in accordance with some embodiments

[0051] FIG. 38 is a block diagram of a network node in accordance with some embodiments;

[0052] FIG. 39 is a block diagram of a host, which may be an embodiment of the host of FIG. 36, in accordance with some embodiments;

[0053] FIG. 40 is a block diagram of a virtualization environment in accordance with some embodiments; and [0054] FIG. 41 shows a communication diagram of a host communicating via a network node with a user equipment over a partially wireless connection in accordance with some embodiments.

DETAILED DESCRIPTION

[0055] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art, in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present/used in another embodiment.

[0056] Considering random access operations for the Long Term Evolution (“LTE”) standard, as mentioned above, the user equipment (“UE”) can move from no or small coverage enhancements (coverage extension (“CE”) mode A) to large coverage enhancements (CE mode B) when signaled. The idea is to only keep a UE in CE mode B if it is not able to do synchronization acquisition, system information acquisition, random access or data transmission using small coverage operation. In enhanced coverage operation, the number of repetitions can be adapted according to the UE’s coverage situation.

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

[0058] In additional or alternative examples, a UE is a narrowband internet-of-things (“NB-IoT”) UE. If the random access preamble was transmitted in a non-terrestrial network, the RAR window starts at the subframe that contains the end of the last preamble repetition plus X + UE-eNB RTT subframes and has length ra-ResponseWindowSize for the corresponding enhanced coverage level, where value X is determined based on the used preamble format and the number of NPRACH repetitions. Otherwise, the random access response (“RAR”) window starts at the subframe that contains the end of the last preamble repetition plus X subframes and has length ra-ResponseWindowSize for the corresponding enhanced coverage level, where value X is determined based on the used preamble format and the number of NPRACH repetitions. [0059] The RA-radio network temporary identifier (“RNTI”) associated with the physical random access channel (“PRACH”) in which the Random Access Preamble is transmitted, is computed as:

RA-RNTI= 1 + t_id + 10*f_id where t_id is the index of the first subframe of the specified PRACH (0< t_id <10), and f_id is the index of the specified PRACH within that subframe, in ascending order of frequency domain (0< f_id< 6) except for narrowband internet-of-thins (“NB-IoT”) UEs, bandwidth reduced/low capacity (“BL”) UEs or UEs in enhanced coverage. If the PRACH resource is on a time division duplex (“TDD”) carrier, the f_id is set to

.

[0060] For BL UEs and UEs in enhanced coverage, RA-RNTI associated with the PRACH in which the Random Access Preamble is transmitted, is computed as:

RA-RNTI=l+t_id + 10*f_id + 60*(SFN_id mod (Wmax/10)) where t_id is the index of the first subframe of the specified PRACH (0< t_id <10), f_id is the index of the specified PRACH within that subframe, in ascending order of frequency domain (0< f_id< 6), SFN_id is the index of the first radio frame of the specified PRACH, and Wmax is 400, maximum possible RAR window size in subframes for BL UEs or UEs in enhanced coverage. If the PRACH resource is on a TDD carrier, the f_id is set to

.

[0061] For NB-IoT UEs, the RA-RNTI associated with the PRACH in which the Random Access Preamble is transmitted, is computed as:

RA-RNTI = 1 + floor(SFN_id/4) + 256*carrier_id where SFN_id is the index of the first radio frame of the specified PRACH and carrier_id is the index of the uplink (“UL”) carrier associated with the specified PRACH. The carrier_id of the anchor carrier is 0.

[0062] For BL/CE UEs, for each PRACH coverage enhancement level, there is a PRACH configuration configured by higher layers with a PRACH configuration index (prach- Configurationlndex), a PRACH frequency offset ?r_p ^R _R ^A _Boffsa (prach-Frequency Offset), a number of

PRACE

PRACH repetitions per attempt N (numRepetitionPerPreamble Attempt) and optionally a

PRACH starting subframe periodicity ^rra™ (prach-StartingSubframe). PRACH of preamble format 0-3 is transmitted ^,p^ACH>l times, whereas PRACH of preamble format 4 is transmitted one time only. [0063] For BL/CE UEs and for each PRACH coverage enhancement level, if frequency hopping is enabled for a PRACH configuration by the higher-layer parameter prach- HoppingConfig, the value of the parameter „“_{b a} depends on the system frame number

(“SFN”) and the PRACH configuration index.

[0064] In case the PRACH configuration index is such that a PRACH resource occurs in every radio frame when calculated as below from the table in FIG. 2,

otherwise

where n_{ is the system frame number corresponding to the first subframe for each PRACH repetition,

corresponds to a cell-specific higher-layer parameter prach-HoppingOffset. If frequency hopping is not enabled for the PRACH configuration then „

_offsa . [0065] For frame structure type 1 with preamble format 0-3, for each of the PRACH configurations there is at most one random access resource per subframe.

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

[0067] FIG. 2 illustrates an example of a table that lists PRACH configurations allowed for frame structure type 2 where the configuration index corresponds to a certain combination of preamble format, PRACH density value, D_RA and version index, r_RA.

For frame structure type 2 with PRACH configuration indices 0, 1, 2, 20, 21, 22, 30, 31, 32, 40, 41, 42, 48, 49, 50, or with PRACH configuration indices 51, 53, 54, 55, 56, 57 in UL/DL configuration 3, 4, 5, the UE may for handover purposes assume an absolute value of the relative time difference between radio frame i in the current cell and the target cell is less than 153600 • T_S . [0068] FIG. 2 lists the mapping to physical resources for the different random access opportunities needed for a certain PRACH density value, r>_RA . Each quadruple of the format ( f ₍<²>s indicates the location of a specific random access resource, where A. is a frequency resource index within the considered time instance, ₍m ₌ 0,1,2 indicates whether the resource is reoccurring in all radio frames, in even radio frames, or in odd radio frames, respectively,

_{= 0} indicates whether the random access resource is located in first half frame or in second half frame, respectively, and where ,g> is the uplink subframe number where the preamble starts, counting from 0 at the first uplink subframe between 2 consecutive downlink- to-uplink switch points, with the exception of preamble format 4 where ,g> is denoted as (*). The start of the random access preamble formats 0-3 shall be aligned with the start of the corresponding uplink subframe at the UE assuming ,v_T = o and the random access preamble format 4 shall start 4832 • T_S before the end of the UpPTS at the UE, where the UpPTS is referenced to the UE’s uplink frame timing assuming .v _{l x} = o .

[0069] The random access opportunities for each PRACH configuration shall be allocated in time first and then in frequency if and only if time multiplexing is not sufficient to hold all opportunities of a PRACH configuration needed for a certain density value

without overlap in time. For preamble format 0-3, the frequency multiplexing shall be done according to m^od2 = 0 ise

where is the number of uplink resource blocks, „^_B is the first physical resource block allocated to the PRACH opportunity considered and where „ _{B ofSa} is the first physical resource block available for PRACH.

[0070] For BL/CE UEs, only a subset of the subframes allowed for preamble transmission are allowed as starting subframes for the

repetitions. The allowed starting subframes for a PRACH configuration are determined as follows.

[0071] Enumerate the subframes that are allowed for preamble transmission for the PRACH configuration as

correspond to the two subframes allowed for preamble transmission with the smallest and the largest absolute subframe number

, respectively.

[0072] If a PRACH starting subframe periodicity y_s^^CH is not provided by higher layers, the periodicity of the allowed starting subframes in terms of subframes allowed for preamble transmission is _N . The allowed starting subframes defined over

- i are given

[0073] If a PRACH starting subframe periodicity y_s^^CH is provided by higher layers, it indicates the periodicity of the allowed starting subframes in terms of subframes allowed for preamble transmission. The allowed starting subframes defined over

_{= 0 >}... y “ - 1 are given

0,1, 2, ... [0074] No starting subframe defined over „ “ _{= 0 >}... JV “ - 1 such that

is allowed.

[0075] Each random access preamble occupies a bandwidth corresponding to 6 consecutive resource blocks for both frame structures.

[0076] FIG. 3 illustrates an example of frame structure type 2 random access preamble mapping in time and frequency

[0077] The physical layer random access preamble is based on single- subcarrier frequency-hopping symbol groups. A symbol group is illustrated in a table in FIG. 4, consisting of a cyclic prefix of length T_CP and a sequence of N identical symbols with total length T_SEQ . The total number of symbol groups in a preamble repetition unit is denoted by P. The number of time-contiguous symbol groups is given by G.

NPRACH [0078] The preamble consisting of P symbol groups shall be transmitted N_iep times. For frame structure type 2, when an invalid uplink subframe overlaps the transmission of G symbol groups without a gap, the G symbol groups are dropped. For frame structure type 2, the transmission of G symbol groups are aligned with the subframe boundary.

[0079] The frequency location of the NPRACH transmission is constrained within A^.^A = 12 sub-carriers, and within N^_C ^A = 36 subcarriers when preamble format 2 as described in FIG. 4 is configured. Frequency hopping shall be used within the 12 subcarriers and 36 subcarriers when preamble format 2 as described in FIG. 4 is configured, where the frequency location of the i^th symbol group is given by

⁼^tart^+z%c ^z") where

The quantity n^_c ^A(i) depends on the frame structure.

[0080] Referring now to random access operation for the 3^rd Generation Partnership Project (“3GPP”) new radio (“NR”) standard, there are 64 preambles defined in each timefrequency PRACH occasion, enumerated in increasing order of first increasing cyclic shift c_v of a logical root sequence, and then in increasing order of the logical root sequence index, starting with the index obtained from the higher-layer parameter prach-RootSequencelndex or rootSequencelndex-BFR. Additional preamble sequences, in case 64 preambles cannot be generated from a single root Zadoff-Chu sequence, are obtained from the root sequences with the consecutive logical indexes until all the 64 sequences are found. The logical root sequence order is cyclic; the logical index 0 is consecutive to 837 when

= 839 and is consecutive to 137 when = 13 . The sequence number _u is obtained from the logical root sequence index.

[0081] The cyclic shift c_v is given by

where the higher-layer parameter restrictedSetConfig determines the type of restricted sets (unrestricted, restricted type A, restricted type B).

[0082] Parameters for determining the root sequence and their cyclic shifts in the PRACH preamble sequence set include: sequence length; a logic index to the root sequence table; and a preamble subcarrier spacing (“SCS”) (e.g., if SCS = 1.25/5kH then unrestricted, restricted set A, or restricted set B).

[0083] Random access preambles can only be transmitted in the time resources given by the higher-layer parameter prach-Configurationlndex according to the tables in FIGS. 5-6 and depends on FR1 or FR2 and a spectrum type.

[0084] Random access preambles can only be transmitted in the frequency resources given by the higher-layer parameter msgl-FrequencyStart. The PRACH frequency resources n_RA G {0,1, ... , M — 1}, where M equals the higher-layer parameter msgl-FDM, are numbered in increasing order within the initial uplink bandwidth part during initial access, starting from the lowest frequency. Otherwise, n_RA are numbered in increasing order within the active uplink bandwidth part, starting from the lowest frequency.

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

[0086] A number of time domain RACH occasions within a RACH slot for each PRACH configuration index is fixed.

[0087] For unpaired spectrum, if a UE is not provided tdd-UL-DL-ConfigurationCommon, a PRACH occasion in a PRACH slot is valid if it does not precede a synchronization signal (“SS”)/physical broadcast channel (“PBCH”) block in the PRACH slot and starts at least N_gap symbols after a last SS/PBCH block reception symbol, where N_gap is provided and, if channelAccessMode = "semiStatic" is provided, does not overlap with a set of consecutive symbols before the start of a next channel occupancy time where the UE does not transmit, the candidate SS/PBCH block index of the SS/PBCH block corresponds to the SS/PBCH block index provided by ssb-PositionsInBurst in SIB 1 or in ServingCellConfigCommon.

[0088] If a UE is provided tdd-UL-DL-ConfigurationCommon, a PRACH occasion in a PRACH slot is valid if it is within UL symbols or it does not precede a SS/PBCH block in the PRACH slot and starts at least N_gap symbols after a last downlink symbol and at least N_gap symbols after a last SS/PBCH block symbol, where N_gap is provided and if channelAccessMode = "semiStatic" is provided, does not overlap with a set of consecutive symbols before the start of a next channel occupancy time where there shall not be any transmissions. 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.

[0089] For preamble format B4, N_gap = 0.

[0090] For operation on a single carrier in unpaired spectrum, if a UE is configured by higher layers to transmit sounding reference signal (“SRS”), physical uplink control channel (“PUCCH”), physical uplink shared channel (“PUSCH”), or PRACH in a set of symbols of a slot and the UE detects a downlink control information (“DO”) format indicating to the UE to receive channel state information reference signal (“CSI-RS”) or physical downlink shared channel (“PDSCH”) in a subset of symbols from the set of symbols, then if the UE does not indicate the capability of [partialCancellation], the UE does not expect to cancel the transmission of the PUCCH or PUSCH or PRACH in the set of symbols if the first symbol in the set occurs within T_{proc 2} relative to a last symbol of a control resource set (“CORESET”) where the UE detects the DO format; otherwise, the UE cancels the PUCCH, or the PUSCH, or an actual repetition of the PUSCH determined from the PRACH transmission in the set of symbols. If the UE indicates the capability of [partialCancellation], the UE does not expect to cancel the transmission of the PUCCH or PUSCH or PRACH in symbols from the set of symbols that occur within T_{proc 2} relative to a last symbol of a CORESET where the UE detects the DO format. The UE cancels the PUCCH, or the PUSCH, or an actual repetition of the PUSCH [6, TS 38.214], determined from the PRACH transmission in remaining symbols from the set of symbols.

[0091] A PRACH is transmitted using the selected PRACH format with transmission power PpRACH,b,f,c(0 ^on the indicated PRACH resource, with BWP b of carrier f of serving cell c.

[0092] If within a random access response window, the UE does not receive a random access response that contains a preamble identifier corresponding to the preamble sequence transmitted by the UE, the UE determines a transmission power for a subsequent PRACH transmission, if any.

[0093] If prior to a PRACH retransmission, a UE changes the spatial domain transmission filter, Layer 1 notifies higher layers to suspend the power ramping counter. [0094] The MAC entity shall, for each Random Access Preamble:

1> if PREAMBLE_TRANSMISSION_COUNTER is greater than one; and

1> if the notification of suspending power ramping counter has not been received from lower layers; and

1> if SSB or CSI-RS selected is not changed from the selection in the last Random Access Preamble transmission:

2> increment PREAMBLE_POWER_RAMPING_COUNTER by 1.

1> select the value of DELTA_PREAMBLE;

1> set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER - 1) x PREAMBLE_POWER_RAMPING_STEP;

1> except for contention-free Random Access Preamble for beam failure recovery request, compute the RA-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted;

1> instruct the physical layer to transmit the Random Access Preamble using the selected PRACH occasion, corresponding RA-RNTI (if available), PREAMBLE_INDEX and PREAMBLE_RECEIVED_TARGET_POWER.

[0095] Support for Msg3 repetition was introduced in Rel-17 NR. A UE can be configured by parameters given in an SIB to repeat Msg3. Unlike LTE, the UE can request repetitions for PUSCH transmission, and does so by transmitting a RACH preamble associated with the repetition procedure. The network then indicates the number of repetitions Npusc_H via an MCS field in either RAR or in a PDCCH carrying DCI format 0_0.

[0096] A UE can be provided in RACH-ConfigCommon a set of numbers of repetitions for a PUSCH transmission with PUSCH repetition Type A that is scheduled by a RAR UL grant or by a DCI format 0_0 with CRC scrambled by a temporary cell radio network temporary identifier (“TC-RNTI”). If the UE requests repetitions for the PUSCH transmission, the UE transmits the PUSCH over

slots, where

is indicated by the 2 MSBs of the MCS field in the RAR UL grant or in the 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 an MCS for the PUSCH transmission by the 2 LSBs of the MCS field in the RAR UL grant or by the 3 LSBs of the MCS field in the DCI format 0_0, and determines a redundancy version and RBs for each repetition as described in [6, TS 38.214]. For unpaired spectrum operation, the UE determines the Npusc_H slots as the first Npusc_H slots starting from slot n + k₂ + A where a repetition of the PUSCH transmission does not include a symbol indicated as downlink by tdd-UL-DL-ConfigurationCommon or indicated as a symbol of an SS/PBCH block with index provided by ssb-PositionsInBurst.

[0097] If a UE transmits a PUSCH on active UL BWP b of carrier f of serving cell c using parameter set configuration with index j and PUSCH power control adjustment state with index I , the UE determines the PUSCH transmission power _{PUSCH b f c} a, j,q_d ,i) in PUSCH transmission occasion i as

where, for the PUSCH power control adjustment state f_{b f}

for active UL BWP b of carrier f of serving cell c in PUSCH transmission occasion i , if the UE receives a random access response message in response to a PRACH transmission on active UL BWP b of carrier f of serving cell

command value indicated in the random access response grant of the random access response message corresponding to the PRACH transmission on active UL BWP b of carrier f in the serving cell C, and and

, _t , is provided by higher layers and corresponds to the total power ramp-up requested by higher layers from the first to the last random access preamble for carrier f in the serving cell c,

bandwidth of the PUSCH resource assignment expressed in number of resource blocks for the first PUSCH transmission on active UL BWP b of carrier f of serving cell c, and A_{rF b f} (0) is the power adjustment of first PUSCH transmission on active UL BWP b of carrier f of serving cell c.

[0098] The TPC command value

is used for setting the power of the PUSCH transmission is interpreted according to FIG. 7

[0099] In some examples, a UE is provided a number N of SS/PBCH block indexes associated with one PRACH occasion and a number R of contention based preambles per SS/PBCH block index per valid PRACH occasion by ssb-perRACH-OccasionAndCB- PreamblesPerS SB . [0100] If TV < 1 , one SS/PBCH block index is mapped to \/N consecutive valid PRACH occasions and R contention based preambles with consecutive indexes associated with the SS/PBCH block index per valid PRACH occasion start from preamble index 0. If N > 1, R contention based preambles with consecutive indexes associated with SS/PBCH block index n, 0 < n < N - 1, per valid PRACH occasion start from preamble index n ■ Nf _t ^e ₍^^mble / N where Nf_o ^rt ^ble '^s provided by totalNumberOfRA-Preambles for Type-1 random access procedure. [0101] SS/PBCH block indexes provided by ssb-PositionsInBurst in SIB 1 or in ServingCellConfigCommon are mapped to valid PRACH occasions in the following order where the parameters are described. First, in increasing order of preamble indexes within a single PRACH occasion. Second, in increasing order of frequency resource indexes for frequency multiplexed PRACH occasions. Third, in increasing order of time resource indexes for time multiplexed PRACH occasions within a PRACH slot. Fourth, in increasing order of indexes for PRACH slots

[0102] In some examples, an association period, starting from frame 0, for mapping SS/PBCH blocks to PRACH occasions is the smallest value in the set determined by the PRACH configuration period according to FIG. 8 such that

SS/PBCH blocks are mapped at least once to the PRACH occasions within the association period, where a UE obtains

from the value of ssb-PositionsInBurst in SIB 1 or in ServingCellConfigCommon. If after an integer number of SS/PBCH blocks to PRACH occasions mapping cycles within the association period there is a set of PRACH occasions or PRACH preambles that are not mapped to

SS/PBCH blocks, no SS/PBCH blocks are mapped to the set of PRACH occasions or PRACH preambles. An association pattern period includes one or more association periods and is determined so that a pattern between PRACH occasions and SS/PBCH blocks repeats at most every 160 msec. PRACH occasions not associated with SS/PBCH blocks after an integer number of association periods, if any, are not used for PRACH transmissions.

[0103] In some examples, the PRACH occasions are mapped consecutively per corresponding SS/PBCH block index. The indexing of the PRACH occasion indicated by the mask index value is reset per mapping cycle of consecutive PRACH occasions per SS/PBCH block index. The UE selects for a PRACH transmission the PRACH occasion indicated by PRACH mask index value for the indicated SS/PBCH block index in the first available mapping cycle.

[0104] For the indicated preamble index, the ordering of the PRACH occasions is: 1) in increasing order of frequency resource indexes for frequency multiplexed PRACH occasions; 2) in increasing order of time resource indexes for time multiplexed PRACH occasions within a PRACH slot; and 3) in increasing order of indexes for PRACH slots. FIG. 9 illustrates an example of a RACH-ConfigCommon information element (“IE”). FIG. 10 illustrates an example of a ServingCellConfigCommon IE.

[0105] In response to a PRACH transmission, a UE attempts to detect a DCI format l_0 with CRC scrambled by a corresponding RA-RNTI during a window controlled by higher layers. The window starts at the first symbol of the earliest CORESET the UE is configured to receive PDCCH for Typel-PDCCH CSS set, as defined in Clause 10.1, that is at least one symbol, after the last symbol of the PRACH occasion corresponding to the PRACH transmission, where the symbol duration corresponds to the SCS for Typel-PDCCH CSS set. The length of the window in number of slots, based on the SCS for Typel-PDCCH CSS set, is provided by ra-ResponseWindow.

[0106] The TPC command value s _{2 b f c} is used for setting the power of the PUSCH transmission is interpreted according to FIG. 7. The CSI request field is reserved.

[0107] In some example, if the UE receives a random access response message in response to a PRACH transmission on active UL BWP b of carrier f of serving cell c,

, is a TPC command value indicated in the random access response grant of the random access response message corresponding to the PRACH transmission on active UL BWP b of carrier f in the serving cell c.

[0108] Radio resource control (“RRC”) can configure the following parameters for a RA procedure.

[0109] prach-Configurationlndex: the available set of PRACH occasions for the transmission of the Random Access Preamble.

[0110] preambleReceivedTargetPower: initial Random Access Preamble power.

[0111] rsrp-ThresholdSSB: an RSRP threshold for the selection of the SSB. If the Random Access procedure is initiated for beam failure recovery, rsrp-ThresholdSSB used for the selection of the SSB within candidateBeamRSList refers to rsrp-ThresholdSSB in BeamFailureRecoveryConfig IE.

[0112] rsrp-ThresholdCSI-RS: an RSRP threshold for the selection of CSI-RS. If the Random Access procedure is initiated for beam failure recovery, rsrp-ThresholdCSI-RS is equal to rsrp-ThresholdSSB in BeamFailureRecoveryConfig IE.

[0113] rsrp-ThresholdSSB-SUL: an RSRP threshold for the selection between the NUL carrier and the SUL carrier.

[0114] candidateBeamRSList: a list of reference signals (CSLRS and/or SSB) identifying the candidate beams for recovery and the associated Random Access parameters. [0115] recoverySearchSpaceld: the search space identity for monitoring the response of the beam failure recovery request.

[0116] powerRampingStep: the power-ramping factor.

[0117] powerRampingStepHighPriority: the power-ramping factor in case of prioritized Random Access procedure.

[0118] scalingFactorBI: a scaling factor for prioritized Random Access procedure.

[0119] ra-Preamblelndex: Random Access Preamble.

[0120] ra-ssb-OccasionMasklndex: defines PRACH occasion(s) associated with an SSB in which the MAC entity may transmit a Random Access Preamble.

[0121] ra-OccasionList: defines PRACH occasion(s) associated with a CSI-RS in which the MAC entity may transmit a Random Access Preamble.

[0122] ra-PreambleStartlndex: the starting index of Random Access Preamble(s) for on- demand SI request.

[0123] preambleTransMax: the maximum number of Random Access Preamble transmission.

[0124] ssb-perRACH-OccasionAndCB-PreamblesPerSSB: defines the number of SSBs mapped to each PRACH occasion and the number of contention-based Random Access Preambles mapped to each SSB.

[0125] If groupB configured is configured, then Random Access Preambles group B is configured. Amongst the contention-based Random Access Preambles associated with an SSB, the first numberOfRA-PreamblesGroupA Random Access Preambles belong to Random Access Preambles group A. The remaining Random Access Preambles associated with the SSB belong to Random Access Preambles group B (if configured). If Random Access Preambles group B is supported by the cell Random Access Preambles group B is included for each SSB.

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

[0127] In some examples, for beam failure detection, the gNB configures the UE with beam failure detection reference signals (SSB or channel state information reference signal (“CSI- RS”)) and the UE declares beam failure when the number of beam failure instance indications from the physical layer reaches a configured threshold before a configured timer expires.

[0128] In additional or alternative examples, SSB-based Beam Failure Detection is based on the SSB associated to the initial DL bandwidth part (“BWP”) and can only be configured for the initial DL BWPs and for DL BWPs containing the SSB associated to the initial DL BWP. For other DL BWPs, Beam Failure Detection can only be performed based on CSI-RS.

[0129] After 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, those will be prioritized by the UE).

[0130] Upon completion of the Random Access procedure, beam failure recovery is considered complete.

[0131] In some examples, the media access control (“MAC”) entity shall:

1> if beam failure instance indication has been received from lower layers:

2> start or restart the beamFailureDetectionTimer;

2> increment BFI_COUNTER by 1 ;

2> if BFI_COUNTER >= beamFailurelnstanceMaxCount:

3> initiate a Random Access procedure on the SpCell.

1> if the beamFailureDetectionTimer expires; or

1> if beamFailureDetectionTimer, beamFailurelnstanceMaxCount, or any of the reference signals used for beam failure detection is reconfigured by upper layers: 2> set BFI_COUNTER to 0.

1> if the Random Access procedure is successfully completed (:

2> set BFI_COUNTER to 0;

2> stop the beamFailureRecoveryTimer, if configured;

2> consider the Beam Failure Recovery procedure successfully completed.

[0132] A UE can be provided, for each BWP of a serving cell, a set ~q₀ of periodic CSI-RS resource configuration indexes by failureDetectionResources and a set q of periodic CSI-RS resource configuration indexes and/or SS/PBCH block indexes by candidateBeamRSEist for radio link quality measurements on the BWP of the serving cell. If the UE is not provided failureDetectionResources, the UE determines the set q~₀ to include periodic CSI-RS resource configuration indexes with same values as the RS indexes in the RS sets indicated by TCI-State for respective CORESETs that the UE uses for monitoring PDCCH and, if there are two RS indexes in a TCI state, the set q₀ includes RS indexes with QCL-TypeD configuration for the corresponding TCI states. The UE expects the set q₀ to include up to two RS indexes. The UE expects single port RS in the set ~q₀ .

[0133] In non-DRX mode operation, the physical layer in the UE provides an indication to higher layers when the radio link quality for all corresponding resource configurations in the set To that the UE uses to assess the radio link quality is worse than the threshold Q_Out,LR. The physical layer informs the higher layers when the radio link quality is worse than the threshold QOUI,LR with a periodicity determined by the maximum between the shortest periodicity among the periodic CSI-RS configurations and/or SS/PBCH blocks in the set To that the UE uses to assess the radio link quality and 2 msec. In DRX mode operation, the physical layer provides an indication to higher layers when the radio link quality is worse than the threshold Q_0Ut,LR with a periodicity.

[0134] Upon request from higher layers, the UE provides to higher layers the periodic CSI- RS configuration indexes and/or SS/PBCH block indexes from the set

and the corresponding Ll-RSRP measurements that are larger than or equal to the Qi_n,LR threshold.

[0135] The UE may receive by PRACH-ResourceDedicatedBFR, a configuration for PRACH transmission. For PRACH transmission in slot n and according to antenna port quasi co-location parameters associated with periodic CSI-RS resource configuration or with SS/PBCH block associated with index _new provided by higher layers, the UE monitors PDCCH in a search space set provided by recoverySearchSpaceld for detection of a DO format with CRC scrambled by C-RNTI or MCS-C-RNTI starting from slot n + 4 within a window configured by BeamFailureRecoveryConfig. For PDCCH monitoring in a search space set provided by recoverySearchSpaceld and for corresponding PDSCH reception, the UE assumes the same antenna port quasi-collocation parameters as the ones associated with index q_nev/ until the UE receives by higher layers an activation for a TCI state or any of the parameters tci- StatesPDCCH-ToAddList and/or tci-StatesPDCCH-ToReleaseList. After the UE detects a DO format with CRC scrambled by C-RNTI or MCS-C-RNTI in the search space set provided by recoverySearchSpaceld, the UE continues to monitor PDCCH candidates in the search space set provided by recoverySearchSpaceld until the UE receives a MAC CE activation command for a TCI state or tci-StatesPDCCH-ToAddList and/or tci-StatesPDCCH-ToReleaseList.

[0136] After 28 symbols from a last symbol of a first PDCCH reception in a search space set provided by recoverySearchSpaceld for which the UE detects a DO format with CRC scrambled by C-RNTI or MCS-C-RNTI and until the UE receives an activation command for PUCCH-SpatialRelationlnfo or is provided PUCCH-SpatialRelationlnfo for PUCCH resource(s), the UE transmits a PUCCH on a same cell as the PRACH transmission using a same spatial filter as for the last PRACH transmission and a power determined with q_u - 0 , q_d - q_nev/ , and 1=0.

[0137] After 28 symbols from a last symbol of a first PDCCH reception in a search space set provided by recoverySearchSpaceld where a UE detects a DO format with CRC scrambled by C-RNTI or MCS-C-RNTI, the UE assumes same antenna port quasi-collocation parameters as the ones associated with index q_nev/ for PDCCH monitoring in a CORESET with index 0. [0138] FIG. 11 illustrates an example of a BeamFailureRecoveryConfig. The list of reference signals (CSI-RS and/or SSB) identifying the candidate beams for recovery and the associated RA parameters. The UE shall consider this list to include all elements of candidateBeamRSList (without suffix) and all elements of candidateBeamRSListExt-vl610. The network configures these reference signals to be within the linked DL BWP (i.e., within the DL BWP with the same bwp-Id) of the UL BWP in which the BeamFailureRecoveryConfig is provided.

[0139] As many features in Rel-17 wanted to utilize Msgl preambles to indicate early on the existence of certain features such as Msg3 repetitions, redcap, slicing and Small Data Transmissions. The solution was to introduce a common framework for allocating preambles in ROs and conditions for using these preambles groups as well as the combination of different features, such as Msg3 repetitions and Redcap. With this framework, it is possible to for instance define an RO#1 with a preamble group indicating Redcap and Msg3 repetitions, and then an RO#2 with a preamble group defining Small Data transmissions and Redcap+Msg3 Repetitions. The conditions to use these preamble groups are then defined.

[0140] NR Rel-17 features of RedCap, Small Data, Msg3 repetition, and Slicing can require early UE indication. One or more of them can be configured as a feature combination (“FC”), for which RACH resources are signaled with FC-specific starting preamble, number of preambles, and PRACH mask ID as indicated in FIG. 12

[0141] In NR Rel-15~17, a UE transmits a single PRACH in a PRACH occasion associated with a selected SSB. In Rel-18, one objective is to support multiple PRACH transmissions. [0142] In NR up to Rel-17, it is up to UE implementation to determine its uplink beam for PRACH transmission, for instance, depending on its capability of beam correspondence in FR2. For UEs incapable of beamCorrespondenceWithoutUL-BeamSweeping, to be on the safe side, such UEs transmit PRACH with a wide uplink beam, with the beam width probably larger than the selected SSB. Thus, the transmission power on main lobe outside of the SSB is wasted. On the other hand, a UE, which is capable of beamCorrespondenceWithoutUL-BeamSweeping, may initiate random access before or after finishing beam refinement, depending on the time duration of beam refinement. If it can refine a narrow UL beam within a short period of time, it can transmit PRACH with the refined narrow beam. Otherwise, the beam refinement process may prolong RA latency, and the UE may opt to transmit PRACH with a wide beam and continue the beam refinement for later UL transmission.

[0143] Apart from PRACH transmission with a wide beam or a narrow beam, Rel-18 provides a third way of multiple PRACH transmissions with different beams. UEs of different capabilities of beam correspondence may have different choices as illustrated in FIG. 13. For a UE capable of beam correspondence, if it finishes beam refinement before initiating random access, it can transmit multiple PRACHs with the same narrow beam. Otherwise, it can rely on beam sweeping for multiple PRACH transmissions and then probably continue beam correspondence for the subsequent UL transmission. For a UE incapable of beam correspondence, it can transmit PRACHs with the same wide beam or with beam sweeping. [0144] In some examples, maxUplinkDutyCycle-FR2 is a UE capability to facilitate electromagnetic power density exposure requirements. This UE capability is applicable to all FR2 power classes.

[0145] If the field of UE capability maxUplinkDutyCycle-FR2 is present and the percentage of uplink symbols transmitted within any 1 s evaluation period is larger than maxUplinkDutyCycle-FR2, the UE follows the uplink scheduling and can apply P-MPRf,_c.

[0146] If the field of UE capability maxUplinkDutyCycle-FR2 is absent, the compliance to electromagnetic power density exposure requirements are ensured by means of scaling down the power density or by other means.

[0147] In some examples, maxUplinkDutyCycle-FR2 indicates the maximum percentage of symbols during Is that can be scheduled for uplink transmission at the UE maximum transmission power, so as to ensure compliance with applicable electromagnetic power density exposure requirements provided by regulatory bodies. This field is applicable for all power classes UE in FR2. Value nl5 corresponds to 15%, value n20 corresponds to 20% and so on. If the field is absent or the percentage of uplink symbols transmitted within any Is evaluation period is larger than maxUplinkDutyCycle-FR2. This capability is not applicable to IAB-MT. [0148] In some examples, maxUplinkDutyCycle-PC2-FRl indicates the maximum percentage of symbols during a certain evaluation period that can be scheduled for uplink transmission so as to ensure compliance with applicable electromagnetic energy absorption requirements provided by regulatory bodies. This field is only applicable for FR1 power class 2 UE. If the field is absent, 50% shall be applied. Value n60 corresponds to 60%, value n70 corresponds to 70% and so on. This capability is not applicable to IAB-MT.

[0149] In some examples, maxUplinkDutyCycle-PCldot5-MPE-FRl-rl6 indicates the maximum percentage of symbols during a certain evaluation period that can be scheduled for uplink transmission so as to ensure compliance with applicable electromagnetic energy absorption requirements provided by regulatory bodies. This field is only applicable for FR1 power class 1.5 UE. If the field is absent, UE shall mitigate MPE autonomously by P-MPR or by other means and no restriction on scheduled uplink duty cycle is needed.

[0150] If a UE supports a different power class than the default UE power class for the band and the supported power class enables the higher maximum output power than that of the default power class and one of the following is true: 1) If the field of UE capability maxUplinkDutyCycle-PC2-FRl is absent and the field of UE capability maxUplinkDutyCycle- PCldot5-MPE-FRl is absent and the percentage of uplink symbols transmitted in a certain evaluation period is larger than 50% (The exact evaluation period is no less than one radio frame); 2) If the field of UE capability maxUplinkDutyCycle-PC2-FRl is not absent and the percentage of uplink symbols transmitted in a certain evaluation period is larger than maxUplinkDutyCycle-PC2-FRl (The exact evaluation period is no less than one radio frame); 3) if the field of UE capability maxUplinkDutyCycle-PCldot5-MPE-FRl is not absent and half the percentage of uplink symbols transmitted in a certain evaluation period is larger than maxUplinkDutyCycle-PCldot5-MPE-FRl (The exact evaluation period is no less than one radio frame); or 4) if the IE P-Max is provided and set to the maximum output power of the default power class or lower; Then all requirements for the default power class can be applied to the supported power class and set the configured transmitted power.

[0151] If a UE supports a different power class than the default UE power class for the band and the supported power class enables the higher maximum output power than that of the default power class and one of the following is true: 1) if the UE does not support a power class with higher maximum output power than PC2; 2) if the field of UE capability maxUplinkDutyCycle- PC2-FR1 is absent and the field of UE capability maxUplinkDutyCycle-PCldot5-MPE-FRl is absent and the percentage of uplink symbols transmitted in a certain evaluation period is larger than 25% (The exact evaluation period is no less than one radio frame); 3) if the field of UE capability maxUplinkDutyCycle-PC2-FRl is not absent and the percentage of uplink symbols transmitted in a certain evaluation period is larger than Q.5*maxUplinkDutyCycle-PC2-FRl (The exact evaluation period is no less than one radio frame); 4) if the field of UE capability maxUplinkDutyCycle-PCldot5-MPE-FRl is not absent and the percentage of uplink symbols transmitted in a certain evaluation period is larger than maxUplinkDutyCycle-PCldot5-MPE- FR1 (The exact evaluation period is no less than one radio frame); or 4) if the IE P-Max is provided and set to the maximum output power of the power class 2 or lower; Then requirements for power class 2 can be applied to the supported power class and the configured transmitted power can be set.

[0152] Otherwise, all requirements for the supported power class and the configured transmitted power can be set as based on a default specification.

[0153] In Rel-13 LTE eMTC, for each coverage level (number of PRACH transmissions), specific frequency resources and starting subframes are configured.

[0154] FIG. 14 illustrates an example of a PRACH-Parameters CE IE.

[0155] However, the LTE eMTC differentiation among different numbers of PRACH transmissions by separate frequency RACH resources is not resource efficient. Some innovations introduce a procedure of configuring a set of ROs for a RACH attempt, “one ra-ssb- OccasionMasklndex is associated with a K value, where K denotes the number of PRACH transmission(s) supported by a gNB.” In some examples, ra-ssb-OccasionMasklndex defines PRACH occasion(s) associated with an SSB in which the MAC entity may transmit a Random Access Preamble. Considering ra-ssb-OccasionMasklndex can be hard-coded, some additional procedures taking into account Rel-17 RACH configuration for each FC and ROs multiplexed in frequency domain.

[0156] NR Rel-17 features of RedCap, Small Data, Msg3 repetition and Slicing require early UE indication. One or more of them can be configured as a FC. A set of RACH resources configured by FeatureCombinationPreambles are associated with a feature combination. In some examples, “feature combination” can refer to the corresponding RACH resources (e.g., those configured by the corresponding FeatureCombinationPreambles).

[0157] In some embodiments, in order to configure separate RACH resources for different numbers of PRACH transmissions, separate features, which constitute a feature combination, are configured for different numbers of PRACH transmissions.

[0158] FIG. 15 illustrates an example of a FC that includes multiple PRACH transmissions. [0159] In additional or alternative embodiments, a feature combination includes at most one number of multiple PRACH transmissions. A FeatureCombinationPreabmles includes RACH resources for at most one number of multiple PRACH transmissions.

[0160] In additional or alternative embodiments, a RO offset is configured to indicate the index of an RO relative to that of a previous RO for the same RACH attempt, namely for the same selected SSB/CSI-RS. If there are more than one FDMed ROs for the selected SSB, and RO offset is configured as 1, it indicates the resources are for FDMed PRACH transmissions. The absence of RO offset can indicate TDMed PRACH transmissions, where there is no FDMed ROs for the selected SSB, the default value of RO offset equals the number of FDMed ROs for the SSB, or the gNB does not allow FDMed PRACH transmissions.

[0161] In some examples, only RACH occasions associated with the selected SSB/CSI-RS are numbered. In other words, ROs for different SSBs are numbered separately. The legacy RO numbering is reused, namely “each RACH occasion is sequentially numbered, first, in increasing order of frequency resource indexes for frequency multiplexed PRACH occasions; second, in increasing order of time resource indexes for time multiplexed PRACH occasions within a PRACH slot and Third, in increasing order of indexes for PRACH slots.”

[0162] In additional or alternative examples, two FDMed ROs for the selected SSB, as illustrated in FIG. 16A, for two TDMed PRACH transmissions, the starting RO index can be 0, 1, 4 or 5, and RO offset is 2, so that two ROs in each ellipse are grouped for a RACH attempt. As illustrated in FIG. 16B, for two FDMed PRACH transmissions in each ellipse, the starting RO index can be 0, 2, 4 or 6, and RO offset is 1. As illustrated in FIG. 16C, for four TDMed PRACH transmissions, the starting RO index is 0 or 1, and RO offset =2.

[0163] In additional or alternative examples, RO hopping is used. For two PRACH transmissions, with a configuration of starting RO index as 0 and RO offset as 3, a UE can transmit PRACHs in RO#0 and RO#3. Similarly, with starting RO index as 1 and RO offset as 1, it can transmit in RO#1 and RO#2.

[0164] The parameter of RO offset is essential not only to FDMed PRACH transmissions, but also to TDMed PRACH transmissions, where there are FDMed ROs associated with a selected SSB, and therefore TDMed multiple PRACH transmissions can’t be transmitted in ROs with consecutive indices. What’s more, even if there are no FDMed ROs for a selected SSB, RO offset allows time domain diversity for TDMed PRACH transmissions. For an example of 4 SSBs, with 2 SSBs mapping to one RO and msgl-FDM =2, as illustrated in FIG. 17.

[0165] Among the four ROs for an selected SSB, possible configurations for two PRACH transmissions can be {starting RO index=0, 2; RO offset=l } and {starting RO index=0, 1; RO offset=2 } . The former configuration allows consecutive ROs for a RACH attempt, while the latter one leverages time domain diversity.

[0166] In additional or alternative embodiments, the UE is configured to perform multiple PRACH transmissions in several ROs configured for single PRACH transmissions, but that still spans in time and frequency in such a way that the UE can maintain phase coherency across all PRACH transmissions. The reason for this is that multiple PRACH transmissions can be costly from a network resource perspective, and it could be beneficial to try first on resources that are already available. This could keep the configuration of feature combinations with multiple PRACH transmission to a lower level.

[0167] In additional or alternative embodiments, if the UE consider the Random Access procedure as unsuccessful after an attempt made across legacy ROs, it reverts back to the pool of ROs that is covered by previous embodiments (e.g., a feature combination that indicates multiple PRACH transmissions).

[0168] In additional or alternative embodiments, the network signals if a UE capable of multiple PRACH transmissions should try first in the dedicated pool or in the common pool. The signaling could be done as part of System Information.

[0169] In additional or alternative embodiments, the use of multiple PRACH transmission does not include any combination towards other features that requires early indication of capabilities from the RACH Partitioning framework (e.g., small data, slicing, redcap). Instead, the network only configures multiple PRACH transmissions as a capability (and does not allow separate pools for the combination of other features within the framework). A UE which supports and wants to do multiple PRACH transmissions do this, and then additionally sends a preamble in one RO that corresponds to the additional feature combination that it wants to support (e.g. slicing + RedCap). The combination of multiple PRACH transmission in the dedicated ROs together with the time and phase synchronized preamble in the additional feature indication RO can allow the gNB to determine what features the UE support.

[0170] In NR up to Rel-17, RA-RNTI for single PRACH transmission is derived from the time and frequency resource of RO. The RA-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted, is computed as:

RA-RNTI = 1 + s_id + 14 x t_id + 14 x 80 x f_id + 14 x 80 x 8 x ul_carrier_id where s_id is the index of the first OFDM symbol of the PRACH occasion (0 < s_id < 14), t_id is the index of the first slot of the PRACH occasion in a system frame (0 < t_id < 80), where the subcarrier spacing to determine t_id is based on the value of p for p = {0, 1, 2, 3}, and for p = {5, 6}, t_id is the index of the 120 kHz slot in a system frame that contains the PRACH occasion (0 < t_id < 80), f_id is the index of the PRACH occasion in the frequency domain (0 < f_id < 8), and ul_carrier_id is the UL carrier used for Random Access Preamble transmission (0 for NUL carrier, and 1 for SUL carrier).

[0171] In Rel-18 if one RA-RNTI is determined for multiple PRACH transmissions, it could be computed based on a predetermined RO, e.g., the first/earliest one or the last/latest one. However, PRACH transmission is subject to the legacy collision handling rule, where part of PRACH transmissions may be cancelled. A problem worth consideration is how to compute RA-RNTI, if the PRACH transmission in a RO, which determines RA-RNTI, is dropped.

[0172] In some embodiments, it can be predetermined that RA-RNTI for multiple PRACH transmissions is computed based on the RO of the PRACH transmissions before applying collision handling rule or the RO of actual PRACH transmissions, i.e., after applying collision handling rule.

[0173] Here is an example of RO of the PRACH transmissions before applying collision handling rule. Assume RA-RNTI for multiple PRACH transmissions is calculated based on RO of the first PRACH transmission, and the first PRACH transmission is cancelled due to dynamic SFI or overlapping with PUCCH/PUSCH/SRS in a slot. Since the cancellation is known by gNB, it is able to derive the dropped first PRACH from the received PRACH transmissions and compute the corresponding RA-RNTI.

[0174] On the other hand, since the dropping is known by both gNB and UE, it also makes sense that RA-RNTI is calculated based on the first/last RO of the actual PRACH transmissions. But this may cause ambiguity in the case that the first actual PRACH transmission is misdetected. [0175] One way of thinking is the multiple PRACH transmissions are at non-overlapping time instances. In addition, it was agreed in RAN1#110b to further study the simultaneous PRACH transmissions, including PRACH transmissions in ROs multiplexed in frequency domain (FDM) and transmissions of different preambles in one RO (CDM). In some examples, for multiple PRACH transmissions with same beam, at least ROs located at different time instances can be utilized for the transmissions.

[0176] Simultaneous PRACH transmissions can be considered for a UE with multiple Tx chains, where each PRACH is transmitted with one Tx chain. Multiple Tx chains each with a single RACH transmission could provide Tx diversity gains with a single time domain RACH transmission occasion, thereby minimizing latency. Furthermore, frequency and spatial diversity mechanisms naturally combine when Tx chains transmit in different frequency domain ROs, which can be beneficial in channels where frequency or spatial diversity is limited.

[0177] In some embodiments, for the simultaneous PRACH transmissions multiplexed in different frequency domain ROs, RA-RNTI is computed based on one specific frequency domain RO, which could be the one with the smallest or largest RO index.

[0178] If the multiple PRACHs are transmitted in both TDMed and FDMed ROs, e.g., 2

FDMed RO at two time instances, the frequency-domain rule of determining one of the FDMed RO is applied together with the time-domain rule to identify a RO and the corresponding RA- RNTI.

[0179] After successful reception of a Random Access Response with RA-RNTI, a UE will check if the RAR contains its Random Access Preamble identifiers (RAPID) that matches the transmitted PREAMBLE_INDEX. For CDMed PRACH transmissions, where a UE transmits multiple preambles in a RO with different Tx chains, it is better to define one RAPID for the UE, otherwise it would have to search all of its transmitted preamble indices.

[0180] In some embodiments, if a UE transmits multiple preambles in an RO with different Tx chains, one RAPID is included in RAR for the UE, which can be predetermined to be the smallest or largest PREAMBLE_INDEX.

[0181] In some examples, for multiple PRACH transmissions with same Tx beam, at least SSB-RSRP threshold(s) are used to determine-the number of PRACH transmissions at least for the first RACH attempt. In additional or alternative examples, whether to support multiple numbers of PRACH transmissions is separately discussed. An example of SSB-RSRP thresholds mentioned in the agreement is illustrated in FIG. 18, where the candidate numbers of PRACH transmissions configured by gNB are 1, 2, 4 and 8. By comparing the measured SSB RSRP and the configured thresholds, a UE can derive the corresponding number of PRACH transmission(s). [0182] In some examples, beam correspondence is the ability of the UE to select a suitable beam for UL transmission based on DL measurements with or without relying on UL beam sweeping. Unless explicitly addressed in subclauses below, the beam correspondence requirement is fulfilled if the UE meets the minimum peak EIRP requirement and spherical coverage requirement with its autonomously chosen UL beams and without uplink beam sweeping.

[0183] A UE incapable of beamCorrespondenceWithoutUL-BeamSweeping may be able to sweep narrow Rx beams to receive SSB in order to meet Rx sensitivity requirement and select the best DL Rx beam, but the UE is incapable of generating an UL beam, which corresponds to the best DL Rx beam, i.e., the beam with which the UE receives the selected SSB with the strongest SSB RSRP. Therefore, the UE may transmit PRACH with a wide beam, e.g., with one antenna element, as illustrated in FIGS. 19-20. When the UE measures SSB with a best narrow beam, antenna gain is obtained. However, the mis-match between a wide UL Tx beam and narrow DL Rx beam will result in that the determined number of PRACH transmissions from the agreement is underestimated.

[0184] In some embodiments, it can be predetermined/indicated gNB configures SSB- RSRP threshold(s) for UE to determine the number of PRACH transmissions with the same Tx beam under the assumption the PRACH Tx beam corresponds to the DL Rx beam, with which the strongest SSB-RSRP is measured. This assumption applies to UEs capable of beamCorrespondenceWithoutUL-BeamSweeping, but not to UEs incapable of beamCorrespondenceWithoutUL-BeamSweeping, as illustrated in FIGS. 19-20, for which we have the following methods.

[0185] In additional or alternative embodiments, for UEs, which is incapable of generating an UL Tx beam corresponding to the best narrow Rx beam and thus transmits PRACHs with a wide Tx beam, in order to determine the number of multiple PRACH transmissions with same Tx beam, one or more of the following ways can be used in addition to the comparison between the measured SSB RSRP and the configured RSRP threshold(s).

[0186] In some examples, the UE compares SSB RSRP measured with a wide DL Rx beam with the threshold(s) to derive the number. In additional or alternative examples, if the SSB RSRP measured with the narrow Rx beam is to be compared with SSB-RSRP threshold(s), a different set of SSB-RSRP threshold(s) is indicated and used by the UE to determine the number. If only one set of SSB-RSRP threshold(s) is configured for multiple PRACH transmissions with same Tx beam. Denote K as the number of PRACH transmissions determined with the comparison between RSRP measured with a narrow Rx beam and the configured RSRP threshold. The UE will determine K’ , the actual number of PRACH transmissions, which is supported by gNB, based on one or more of the following methods. One or multiple offsets to the configured thresholds are indicated for UE to determine K’ . The multiple offsets may aim at UEs with different numbers of antennas to generate a narrow Rx beam. A UE is allowed to determine K’ , which is no smaller than K, based on its number of antennas and/or UE estimate of its DL beam forming gain.

[0187] In LTE eMTC, if a UE does not receive a RAR with its Random Access Preamble identifiers (RAPID) after the maximum number of unsuccessful attempts with the current repetition level (number of PRACH transmissions), it changes to a higher level for the following reattempt. No power ramping is allowed when the repetition level changes. However, there are several schemes of NR PRACH transmission in Rel-18, with the same narrow beam, with same wide beam, with different beams. UEs are allowed to switch to a different scheme for Msgl retransmission. A question is whether the unsuccessful previous attempts affect the UE determination of the number of PRACH transmissions with a different scheme.

[0188] FIG. 21 shows several UE choices of different PRACH transmission schemes between initial attempt and reattempt. UE2 and UE3 are capable of beam correspondence without beam sweeping but may not be able to refine its beam well for the initial RACH transmissions due to latency concern, however they are able to transmit with a refined beam for Msg 1 retransmission.

[0189] FIG. 22 shows an example of the threshold of the SSB_RSRP being related to the UE beam correspondence side condition for SSB based Ll-RSRP measurements. The X dBm is referring to the SSB_RP. The Y1 and Y2 is depending on the UE antenna gain difference of DL measured beam and UL Tx beam. For example, the number of antenna elements that are used to receive the SSB signal, Z1 and Z2, may relate to the P-MPR applied to the UE transmission power Pcmax.

[0190] In some embodiments, if the Msgl retransmission is to be performed with a different beam(s) from that used in the previous unsuccessful attempt(s), the number of multiple PRACH transmissions for the retransmission is determined in the same way as for initial transmission, namely it is independent from the number of PRACH transmissions in the previous unsuccessful attempt and the number of unsuccessful attempts with a different beam(s) (e.g., the unsuccessful previous attempts does not affect the UE determination of the number of PRACH transmission for a new attempt..

[0191] In NR up to Rel-18, a FR2 UE may report a UE capability of maxUplinkDutyCycle- FR2, which indicates the maximum percentage of symbols during Is that can be scheduled for uplink transmission at the UE maximum transmission power, so as to ensure compliance with applicable electromagnetic power density exposure requirements provided by regulatory bodies. If the field of UE capability maxUplinkDutyCycle-FR2 is present and the percentage of uplink symbols transmitted within any 1 s evaluation period is larger than maxUplinkDutyCycle-FR2, the UE follows the uplink scheduling and can apply P-MPRf,_c. If the field of UE capability maxUplinkDutyCycle-FR2 is absent, the compliance to electromagnetic power density exposure requirements are ensured by means of scaling down the power density or by other means. [0192] Similarly, a FR1 UE, which supports a different power class than the default UE power class for the band and the supported power class enables the higher maximum output power than that of the default power class, may fallback to the default UE power class with the lower maximum output power, if the percentage of uplink symbols transmitted in a certain evaluation period is larger than its UE capability or a predetermined fixed threshold.

[0193] The legacy UE behaviors of applying P-MPRf._c, scaling down the power density and power class fallback are needed so that the UE can follow gNB’s UL scheduling. However, CBRA PRACH and CFRA PRACH transmission are not scheduled by gNB but initiated by UE. Even if the number of PRACH(s) is indicated by gNB for CFRA, the timing of launching random access is determined by UE. The UL percentage is not a problem for single PRACH transmission, while Rel-18 multiple PRACH transmissions will increase the UL transmission duration within the evaluation period, possibly exceeding the UE capability of maximum uplink duty cycle or the predetermined threshold. A question is whether the legacy rules of reducing UE transmission power apply to Rel-18 multiple PRACH transmissions.

[0194] In some examples, given a high SCS in FR2, multiple PRACH transmissions may not reach the maximum UL percentage in 1 second. However, an RRC connected UE may transmit multiple PRACHs and other UL transmissions within the same evaluation period, which together contribute to the UL percentage. For example, after performing UL transmissions in the source cell, a UE is handed over to another cell, where it starts random access. Another example is an RRC connected UE has configured grant for PUSCH transmissions, therefore it knows the percentage of potential CG-PUSCH transmissions in an evaluation period. If its UL synchronization status is “non-synchronised,” it has to start random access to synchronize before UL transmissions. In both cases, the uplink transmissions consist of not only PRACH transmissions, but also PUSCH transmissions.

[0195] One issue related to UL duty cycle is that it is possible that during the multiple PRACH transmissions, UL transmission percentage in the evaluation period exceeds the UE’s capability of UL duty cycle. As illustrated in FIG. 23, for K PRACH transmissions, the UE can transmit the first kl PRACHs at the UE maximum transmission power and the following K-kl PRACHs with reduced transmission power. However, it is not ideal especially for multiple PRACH transmissions with different Tx beams. A large change of PRACH transmission power affects gNB estimation of UL pathloss and its determination of the best beam. In fact, before PRACH transmissions, the UE can estimate if UL duty cycle will be reached during the multiple PRACH transmissions.

[0196] In some embodiments, if the UE determined number of PRACH transmissions and the corresponding ROs configured by gNB trigger a UE to reduce transmission power for some or all PRACH transmissions, e.g. by applying P-MPRf._c, scaling down the power density or UE power class fallback, so as to ensure compliance with applicable electromagnetic power density exposure requirements, the UE can instead proceed with one or more of the following options: 1) reduce the total number of PRACH transmissions so that all of them can be transmitted at the UE’s maximum transmission power (e.g., in FIG. 23 the UE only transmits kl PRACHS for the RACH attempt); 2) transmit all the multiple PRACH transmissions with reduced transmission power in order to avoid big transmission power variation, though the first several PRACH transmissions may not reach its uplink duty cycle; and 3) select different RACH resources so as to avoid transmission power reduction (e.g., those in the following evaluation period).

[0197] In some examples, since a UE can decide when to launch random access, if the random access is not for delay sensitive service, it can postpone PRACH transmissions until the next evaluation period to avoid applying the P-MPR. This may happen for a RRC connected UE, in case other UL transmissions lead to very high UL transmission percentage. In one case, when the previous transmission time before PRACH is already exceeding the maxUplinkDutyCycle- FR2 from duty cycle calculation, without introducing an additional delay of the PRACH transmission, there will be P-MPR of x dB evaluated within a 1 second time window as illustrated in FIG. 24. An enhanced UE can decide a configurable delay parameter before the transmission of PRACH, such PRACH postponement is to avoid the PRACH transmissions and other UL transmissions in the same evaluation period as illustrated in FIG. 25.

[0198] In another enhancement case, when the previous transmission time before PRACH is equals to the maxUplinkDutyCycle-FR2 from duty cycle calculation, UE can apply a smaller number of PRACH transmissions to avoid applying the P-MPR if more number of PRACH transmission would exceed the maxUplinkDutyCycle-FR2 and incur to apply P-MPR.

[0199] In some embodiments,, for CFRA, if gNB indicates the number of PRACH transmissions and corresponding RACH resources for a UE-selected SSB/CSLRS, and the PRACH transmissions lead to UE transmission power reduction, e.g., P-MPRf._c, scaling down the power density or UE power class fallback, so as to ensure compliance with applicable electromagnetic power density exposure requirements, the UE follows gNB indication of PRACH transmissions and applies the P-MPR for the transmission power. In such a case, UE considers the UL transmission before PRACH transmission within a 1-second evaluation time window, including the PUSCH, PUCCH, SRS transmitted within the 1 second evaluation window. This is the case for the same frequency carrier, for example, in the RRC connection state, the UE lost its uplink synchronization after some idle time and initiate the RACH based on the network order.

[0200] In some examples, maxUplinkDutyCycle-FR2 is defined as a UE capability to facilitate electromagnetic power density exposure requirements. This UE capability can be applicable to all FR2 power classes. If the field of UE capability maxUplinkDutyCycle-FR2 is present and the percentage of uplink symbols transmitted (including PRACH transmission) within any 1 s evaluation period is larger than maxUplinkDutyCycle-FR2, the UE follows the uplink scheduling and can apply P-MPRf,_c. If the field of UE capability maxUplinkDuty Cycle - FR2 is absent, the compliance to electromagnetic power density exposure requirements are ensured by means of scaling down the power density or by other means.

[0201] As Rel-18 multiple PRACH transmissions may account for bigger percentage than single PRACH transmission, a large number of PRACH transmissions will reduce the opportunities of other UL transmissions in an evaluation period at the non-reduced transmission power. Some embodiments avoid the situation that multiple PRACH transmissions take too much of the UL duty cycle. In additional or alternative embodiments, the issue that UL duty cycle is reached during the multiple PRACH transmissions can be solved.

[0202] In some embodiments, multiple PRACH transmissions are excluded from the calculation of UL transmission percentage in an evaluation period. In some examples, if the field of UE capability maxUplinkDutyCycle-FR2 is present and the percentage of uplink symbols transmitted within any 1 s evaluation period other than the PRACH transmission if UE is capable of multiple PRACH transmission is larger than maxUplinkDutyCycle-FR2, the UE follows the uplink scheduling and can apply P-MPRf,_c. In additional or alternative examples, If the field of UE capability maxUplinkDutyCycle-FR2 is absent and UE is capable of multiple PRACH transmission, the compliance to electromagnetic power density exposure requirements are ensured other than PRACH transmission by means of scaling down the power density or by other means.

[0203] In the ICNIRP exposure limit regulation requirements, the average time for the SAR limit is 6 min. For the UE with capability of the multiple PRACH transmission, UE should avoid applying the P-MPR and/or evaluation of the P-MPR for PRACH transmission. For one example, excluding applying P-MPR and/or evaluation of P-MPR only when the field of UE capability maxUplinkDutyCycle-FR2 is present, for such UE, it will not apply the P-MPR when it transmit the PRACH and will not evaluate P-MPR for PRACH transmission. [0204] In additional or alternative embodiments, given P-MPR may be considered as a factor affecting UE determination of the number of PRACH transmissions. If P-MPR is applied in a source cell before inter-frequency intra-band HO, the UE can 1) continue the evaluation period and applies the P-MPR, which affects UE determination of the number PRACH(s) in the target cell; and/or 2) restart an evaluation period and stops using P-MPR.

[0205] Operations of the communication device 3700 (implemented using the structure of the block diagram of FIG. 37) will now be discussed with reference to the flow chart of FIGS. 26-32 according to some embodiments of inventive concepts. For example, modules may be stored in memory 3710 of FIG. 37, and these modules may provide instructions so that when the instructions of a module are executed by respective communication device processing circuitry 3702, processing circuitry 3702 performs respective operations of the flow chart.

[0206] FIG. 26 illustrates an example of operations performed by a communication device. [0207] At block 2610, processing circuitry 3702 determines a features combination based on one or more features. In some examples, the features are associated with at least one of: a capability of the communication device; a number of physical random access channel, PRACH, transmissions to transmit to a network node as part of a random access, RA, procedure; and a capability of the network node.

[0208] At block 2620, processing circuitry 3702 determines a PRACH repetition factor based on the feature combination. In some examples, the PRACH repetition factor is a number of PRACH transmissions to transmit to the network node.

[0209] At block 2630, processing circuitry 3702 transmits, via communication interface 3712, a PRACH transmission based on the feature combination as part of a RA procedure.

[0210] FIG. 27 illustrates an example of operations performed by a communication device during a random access, RA, procedure associated with a network node of a communications network.

[0211] At block 2710, processing circuitry 3702 determines a RO offset. The RO offset is configured to indicate index of a second RO relative to a first RO associated with a set of PRACH transmissions.

[0212] In some embodiments, determining the RO offset includes: determining that there are more than one frequency division multiplexed, FDMed, ROs; determining that there are no FDMed ROs associated with the set of PRACH transmissions; and determining, based on there being no FDMed ROs associated with the set of PRACH transmissions, that the RO offset is not configured or is configured to be the same value as the number of FDMed ROs.

[0213] In additional or alternative embodiments, determining the RO offset includes: determining that there are no frequency division multiplexed, FDMed, ROs; determining the time-domain consecutive ROs associated with the set of PRACH transmissions; and determining, based on the time-domain consecutive ROs associated with the set of PRACH transmissions, that the RO offset is not configured or is configured to be 1.

[0214] In additional or alternative embodiments, determining the RO offset includes determining the RO offset based on the FC.

[0215] At block 2720, processing circuitry 3702 transmits, via communication interface 3712, a first PRACH transmission of the set of PRACH transmissions to the network node at the first RO as part of the RA procedure. At block 2730, processing circuitry 3702 determines the second RO based on the first RO and the RO offset. At block 2740, processing circuitry 3702 transmits a second PRACH transmission of the set of PRACH transmissions to the network node at the second RO as part of the RA procedure.

[0216] FIG. 28 illustrates an example of operations performed by a communication device during a random access, RA, procedure associated with a network node of a communications network.

[0217] At block 2810, processing circuitry 3702 transmits, via communication interface 3712, a plurality of PRACH transmissions to a network node as part of a RA procedure.

[0218] At block 2820, processing circuitry 3702 determines a RA-RNTI for the plurality of PRACH transmission based on a specific RO of a set of ROs that are determined before applying collision handling rules to the PRACH transmissions. In some embodiments, the plurality of PRACH transmissions includes a first PRACH transmission and a second PRACH transmission multiplexed in different frequency domain ROs at the same time instance. The specific RO comprises at least one of: a first RO with a smallest RO index; and a last RO with a largest RO index.

[0219] FIG. 29 illustrates an example of operations performed by a communication device during a random access, RA, procedure associated with a network node of a communications network.

[0220] At block 2910, processing circuitry 3702 transmits, via communication interface 3712, a plurality of PRACH transmissions to a network node as part of a RA procedure.

[0221] At block 2920, processing circuitry 3702 receives, via communication interface 3712, a RAR including a RA-RNTI.

[0222] At block 2930, processing circuitry 3702 determines if the RAR includes a RAPID that matches a preamble index associated with the plurality of PRACH transmissions. In some embodiments, the preamble index includes a specific preamble index of a plurality of preamble indices associated with the plurality of PRACH transmissions. In additional or alternative embodiments, the specific preamble index of a plurality of preamble indices includes at least one of: a smallest preamble index; and a largest preamble index.

[0223] At block 2940, processing circuitry 3702 processes or disregards the RAR based on whether the RAR includes the RAPID.

[0224] FIG. 30 illustrates an example of operations performed by a communication device during a random access, RA, procedure associated with a network node of a communications network.

[0225] At block 3010, processing circuitry 3702 determines a number of PRACH transmissions to transmit to a network node (with the same Tx beam prior to receiving a RAR) based on whether the communication device is capable of beam correspondence. In some embodiments, determining the number of PRACH transmissions includes determining whether the communication device is capable of beam correspondence.

[0226] In additional or alternative embodiments, determining whether the communication device is capable of beam correspondence includes determining at least one of: whether the communication device is capable of generating an uplink, UL, transmission, Tx, beam corresponding to a best narrow reception, Rx, beam; and whether the communication device is capable of beamCorrespondenceWithoutUL-BeamSweeping.

[0227] At block 3020, processing circuitry 3702 transmits, via communication interface 3712, the number of PRACH transmission to the network node as part of the RA procedure.

[0228] In some embodiments, the communication device is incapable of beam correspondence. Determining the number of PRACH transmissions includes determining a characteristic of a wide downlink, DL, reception, Rx, beam; and determining the number of PRACH transmissions based on the characteristic of the wide DL Rx beam. In some examples, the characteristic of the wide DL Rx beam comprises at least one of: a reference signal received power, RSRP; and a reference signal received quality, RSRQ.

[0229] In additional or alternative embodiments, the communication device is capable of beam correspondence. Determining the number of PRACH transmissions includes: determining a characteristic of a narrow downlink, DL, reception, Rx, beam; determining a narrow uplink, UL, transmission, Tx, beam corresponding to the narrow DL Rx beam; and determining the number of PRACH transmissions based on the characteristic of the narrow DL Rx beam.

[0230] In additional or alternative embodiments, determining the number of PRACH transmissions includes determining a set of one or more threshold values based on the communication device being incapable of beam correspondence. Determining the number of PRACH transmissions based on the characteristic of the narrow DL Rx beam includes determining the number of PRACH transmissions based on comparing the characteristic with the set of one or more threshold values.

[0231] In additional or alternative embodiments, determining the number of PRACH transmissions based on the characteristic of the narrow DL Rx beam includes: determining a first value based on comparing the characteristic with a set of one or more threshold values; and determining the number of PRACH transmissions by adjusting the first value based on an offset. In some examples, determining the set of one or more threshold values includes determining the offset based on at least one of: a number of antennas of the communication device; an estimate of a DL beam forming gain; and an indication received from the network node.

[0232] In additional or alternative embodiments, the communication device is capable of beam correspondence. Determining the number of PRACH transmissions includes: determining a characteristic of a narrow downlink, DL, reception, Rx, beam; determining a narrow uplink, UL, transmission, Tx, beam corresponding to the narrow DL Rx beam; and determining the number of PRACH transmissions based on the characteristic of the narrow DL Rx beam. In some examples, the characteristic of the narrow DL Rx beam includes at least one of: a reference signal received power, RSRP; and a reference signal received quality, RSRQ. In some examples, determining the number of PRACH transmissions further includes determining the number of PRACH transmissions by comparing the characteristic to one or more predetermined threshold values.

[0233] FIG. 31 illustrates an example of operations performed by a communication device during a random access, RA, procedure associated with a network node of a communications network.

[0234] At block 3110, processing circuitry 3702 determines a first number of PRACH transmissions to transmit to a network node using a first Tx beam as part of a RA procedure. [0235] At block 3120, processing circuitry 3702 determines whether to perform retransmission using a second Tx beam.

[0236] At block 3130, processing circuitry 3702 determines a second number of PRACH transmissions to transmit to the network node based on whether the second Tx beam will be used. In some embodiments, determining whether to perform the retransmission using the second Tx beam includes determining to perform the retransmission using the first Tx beam. Determining the second number of PRACH transmissions includes determining the second number of PRACH transmission using the first procedure.

[0237] In additional or alternative embodiments, determining whether to perform the retransmission using the second Tx beam includes determining to perform the retransmission using the second Tx beam. Determining the second number of PRACH transmissions includes determining the second number of PRACH transmission using a second procedure that is different from the first procedure.

[0238] FIG. 32 illustrates an example of operations performed by a communication device during a random access, RA, procedure associated with a network node of a communications network.

[0239] At block 3210, processing circuitry 3702 determines a first number of PRACH transmissions to transmit to a network node as part of a RA procedure.

[0240] At block 3220, processing circuitry 3702 determines that transmitting the first number of PRACH transmissions will cause an UL transmission percentage to exceed an UL duty cycle.

[0241] At block 3230, processing circuitry 370 performs an action associated with the number of PRACH transmissions.

[0242] In some embodiments, performing the action includes reducing PRACH transmission power associated with the number of PRACH transmissions.

[0243] In additional or alternative embodiments, performing the action includes delaying transmission of the number of PRACH transmissions.

[0244] In additional or alternative embodiments, performing the action includes reducing the number of PRACH transmissions.

[0245] In additional or alternative embodiments, performing the action includes selecting different RA channel, RACH, resources associated with the number of PRACH transmissions. [0246] Various operations from the flow chart of FIG. 26-32 may be optional with respect to some embodiments of communication devices and related methods.

[0247] Operations of the RAN node 3800 (implemented using the structure of FIG. 38) will now be discussed with reference to the flow chart of FIGS. 33-35 according to some embodiments of inventive concepts. For example, modules may be stored in memory 3804 of FIG. 38, and these modules may provide instructions so that when the instructions of a module are executed by respective RAN node processing circuitry 3802, RAN node 3800 performs respective operations of the flow chart.

[0248] FIG. 33 illustrates an example of operations performed by a network node of a communications network during a random access, RA, procedure associated with a communication device.

[0249] At block 3310, processing circuitry 3802 determines a features combination based on one or more features. In some examples, the features are associated with at least one of: a capability of the communication device; a number of physical random access channel, PRACH, transmissions to transmit to a network node as part of a random access, RA, procedure; and a capability of the network node.

[0250] At block 3320, processing circuitry 3802 determines a PRACH repetition factor based on the feature combination. In some examples, the PRACH repetition factor is a number of PRACH transmissions to transmit to the network node.

[0251] At block 3330, processing circuitry 3802 receives, via communication interface 3806, a PRACH transmission based on the feature combination as part of a RA procedure. [0252] FIG. 34 illustrates an example of operations performed by a network node of a communications network during a random access, RA, procedure associated with a communication device.

[0253] At block 3410, processing circuitry 3802 determines a RO offset. The RO offset is configured to indicate index of a second RO relative to a first RO associated with a set of PRACH transmissions.

[0254] In some embodiments, determining the RO offset includes: determining that there are more than one frequency division multiplexed, FDMed, ROs; determining that there are no FDMed ROs associated with the set of PRACH transmissions; and determining, based on there being no FDMed ROs associated with the set of PRACH transmissions, that the RO offset is not configured or is configured to be the same value as the number of FDMed ROs.

[0255] In additional or alternative embodiments, determining the RO offset includes: determining that there are no frequency division multiplexed, FDMed, ROs; determining the time-domain consecutive ROs associated with the set of PRACH transmissions; and determining, based on the time-domain consecutive ROs associated with the set of PRACH transmissions, that the RO offset is not configured or is configured to be 1.

[0256] In additional or alternative embodiments, determining the RO offset includes determining the RO offset based on the FC.

[0257] At block 3420, processing circuitry 3802 receives, via communication interface 3806, a first PRACH transmission at a first RO. At block 3430, processing circuitry 3802 determines a second RO based on the first RO and the RO offset. At block 3440, processing circuitry 3802 receives, via communication interface 3806, a second PRACH transmission at the second RO.

[0258] FIG. 35 illustrates an example of operations performed by a network node of a communications network during a random access, RA, procedure associated with a communication device. [0259] At block 3510, processing circuitry 3802 receives, via communication interface 3806, a plurality of PRACH transmissions from a communication device as part of a RA procedure.

[0260] At block 3520, processing circuitry 3802 determines a RAPID that matches a preamble index associated with the plurality of PRACH transmissions. In some embodiments, the preamble index includes a specific preamble index of a plurality of preamble indices associated with the plurality of PRACH transmissions. In additional or alternative embodiments, the specific preamble index of a plurality of preamble indices includes at least one of: a smallest preamble index; and a largest preamble index.

[0261] At block 3530, processing circuitry 3802 transmits, via communication interface 3806, a RAR including the RAPID.

[0262] Various operations from the flow chart of FIGS. 33-35 may be optional with respect to some embodiments of network nodes and related methods.

[0263] FIG. 36 shows an example of a communication system 3600 in accordance with some embodiments.

[0264] In the example, the communication system 3600 includes a telecommunication network 3602 that includes an access network 3604, such as a radio access network (RAN), and a core network 3606, which includes one or more core network nodes 3608. The access network 3604 includes one or more access network nodes, such as network nodes 3610a and 3610b (one or more of which may be generally referred to as network nodes 3610), or any other similar 3^rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes 3610 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 3612a, 3612b, 3612c, and 3612d (one or more of which may be generally referred to as UEs 3612) to the core network 3606 over one or more wireless connections.

[0265] Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 3600 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. The communication system 3600 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.

[0266] The UEs 3612 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes 3610 and other communication devices. Similarly, the network nodes 3610 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 3612 and/or with other network nodes or equipment in the telecommunication network 3602 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 3602.

[0267] In the depicted example, the core network 3606 connects the network nodes 3610 to one or more hosts, such as host 3616. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 3606 includes one more core network nodes (e.g., core network node 3608) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 3608. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF).

[0268] The host 3616 may be under the ownership or control of a service provider other than an operator or provider of the access network 3604 and/or the telecommunication network 3602, and may be operated by the service provider or on behalf of the service provider. The host 3616 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0269] As a whole, the communication system 3600 of FIG. 36 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are 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); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any low- power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0270] In some examples, the telecommunication network 3602 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 3602 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 3602. For example, the telecommunications network 3602 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)/Massive loT services to yet further UEs. [0271] In some examples, the UEs 3612 are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 3604 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 3604.Additionally, a UE may be configured for operating in single- or multi-RAT or multi- standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured 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 example, the hub 3614 communicates with the access network 3604 to facilitate indirect communication between one or more UEs (e.g., UE 3612c and/or 3612d) and network nodes (e.g., network node 3610b). In some examples, the hub 3614 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 3614 may be a broadband router enabling access to the core network 3606 for the UEs. As another example, the hub 3614 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 3610, or by executable code, script, process, or other instructions in the hub 3614. As another example, the hub 3614 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 3614 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 3614 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 3614 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 3614 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy loT devices.

[0273] The hub 3614 may have a constant/persistent or intermittent connection to the network node 3610b. The hub 3614 may also allow for a different communication scheme and/or schedule between the hub 3614 and UEs (e.g., UE 3612c and/or 3612d), and between the hub 3614 and the core network 3606. In other examples, the hub 3614 is connected to the core network 3606 and/or one or more UEs via a wired connection. Moreover, the hub 3614 may be configured to connect to an M2M service provider over the access network 3604 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 3610 while still connected via the hub 3614 via a wired or wireless connection. In some embodiments, the hub 3614 may be a dedicated hub - that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 3610b. In other embodiments, the hub 3614 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 3610b, but which is additionally capable of operating as a communication start and/or end point for certain data channels.

[0274] FIG. 37 shows a UE 3700 in accordance with some embodiments. As used herein, a UE refers to a device capable, 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 smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band 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) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle- to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and/or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0276] The UE 3700 includes processing circuitry 3702 that is operatively coupled via a bus 3704 to an input/output interface 3706, a power source 3708, a memory 3710, a communication interface 3712, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in FIG. 37. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0277] The processing circuitry 3702 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 3710. The processing circuitry 3702 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 3702 may include multiple central processing units (CPUs).

[0278] In the example, the input/output interface 3706 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and/or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 3700. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0279] In some embodiments, the power source 3708 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 3708 may further include power circuitry for delivering power from the power source 3708 itself, and/or an external power source, to the various parts of the UE 3700 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 3708. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 3708 to make the power suitable for the respective components of the UE 3700 to which power is supplied.

[0280] The memory 3710 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable readonly memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 3710 includes one or more application programs 3714, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 3716. The memory 3710 may store, for use by the UE 3700, any of a variety of various operating systems or combinations of operating systems. [0281] The memory 3710 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as 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 ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 3710 may allow the UE 3700 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 3710, which may be or comprise a device-readable storage medium.

[0282] The processing circuitry 3702 may be configured to communicate with an access network or other network using the communication interface 3712. The communication interface 3712 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 3722. The communication interface 3712 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 3718 and/or a receiver 3720 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 3718 and receiver 3720 may be coupled to one or more antennas (e.g., antenna 3722) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0283] In the illustrated embodiment, communication functions of the communication interface 3712 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short- range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and/or standards, such as IEEE 802.11, Code Division Multiplexing 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), and so forth. [0284] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 3712, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0285] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0286] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity 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 electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and/or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE 3700 shown in FIG. 37.

[0287] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another UE and/or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation.

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

[0289] FIG. 38 shows a network node 3800 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)). [0290] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and/or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0291] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell/multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and/or Minimization of Drive Tests (MDTs).

[0292] The network node 3800 includes a processing circuitry 3802, a memory 3804, a communication interface 3806, and a power source 3808. The network node 3800 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 3800 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 3800 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 3804 for different RATs) and some components may be reused (e.g., a same antenna 3810 may be shared by different RATs). The network node 3800 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 3800, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 3800.

[0293] The processing circuitry 3802 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node 3800 components, such as the memory 3804, to provide network node 3800 functionality.

[0294] In some embodiments, the processing circuitry 3802 includes a system on a chip (SOC). In some embodiments, the processing circuitry 3802 includes one or more of radio frequency (RF) transceiver circuitry 3812 and baseband processing circuitry 3814. In some embodiments, the radio frequency (RF) transceiver circuitry 3812 and the baseband processing circuitry 3814 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 3812 and baseband processing circuitry 3814 may be on the same chip or set of chips, boards, or units. [0295] The memory 3804 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processing circuitry 3802. The memory 3804 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and/or other instructions capable of being executed by the processing circuitry 3802 and utilized by the network node 3800. The memory 3804 may be used to store any calculations made by the processing circuitry 3802 and/or any data received via the communication interface 3806. In some embodiments, the processing circuitry 3802 and memory 3804 is integrated.

[0296] The communication interface 3806 is used in wired or wireless communication of signaling and/or data between a network node, access network, and/or UE. As illustrated, the communication interface 3806 comprises port(s)/terminal(s) 3816 to send and receive data, for example to and from a network over a wired connection. The communication interface 3806 also includes radio front-end circuitry 3818 that may be coupled to, or in certain embodiments a part of, the antenna 3810. Radio front-end circuitry 3818 comprises filters 3820 and amplifiers 3822. The radio front-end circuitry 3818 may be connected to an antenna 3810 and processing circuitry 3802. The radio front-end circuitry may be configured to condition signals communicated between antenna 3810 and processing circuitry 3802. The radio front-end circuitry 3818 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 3818 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 3820 and/or amplifiers 3822. The radio signal may then be transmitted via the antenna 3810. Similarly, when receiving data, the antenna 3810 may collect radio signals which are then converted into digital data by the radio front-end circuitry 3818. The digital data may be passed to the processing circuitry 3802. In other embodiments, the communication interface may comprise different components and/or different combinations of components.

[0297] In certain alternative embodiments, the network node 3800 does not include separate radio front-end circuitry 3818, instead, the processing circuitry 3802 includes radio front-end circuitry and is connected to the antenna 3810. Similarly, in some embodiments, all or some of the RF transceiver circuitry 3812 is part of the communication interface 3806. In still other embodiments, the communication interface 3806 includes one or more ports or terminals 3816, the radio front-end circuitry 3818, and the RF transceiver circuitry 3812, as part of a radio unit (not shown), and the communication interface 3806 communicates with the baseband processing circuitry 3814, which is part of a digital unit (not shown).

[0298] The antenna 3810 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. The antenna 3810 may be coupled to the radio front-end circuitry 3818 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In certain embodiments, the antenna 3810 is separate from the network node 3800 and connectable to the network node 3800 through an interface or port.

[0299] The antenna 3810, communication interface 3806, and/or the processing circuitry 3802 may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by the 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 3810, the communication interface 3806, and/or the processing circuitry 3802 may be configured to perform any transmitting operations described herein as being performed by the 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 source 3808 provides power to the various components of network node 3800 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 3808 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 3800 with power for performing the functionality described herein. For example, the network node 3800 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 3808. As a further example, the power source 3808 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0301] Embodiments of the network node 3800 may include additional components beyond those shown in FIG. 38 for providing 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, the network node 3800 may include user interface equipment to allow input of information into the network node 3800 and to allow output of information from the network node 3800. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 3800.

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

[0303] The host 3900 includes processing circuitry 3902 that is operatively coupled via a bus 3904 to an input/output interface 3906, a network interface 3908, a power source 3910, and a memory 3912. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as FIGS. 37 and 38, such that the descriptions thereof are generally applicable to the corresponding components of host 3900.

[0304] The memory 3912 may include one or more computer programs including one or more host application programs 3914 and data 3916, which may include user data, e.g., data generated by a UE for the host 3900 or data generated by the host 3900 for a UE. Embodiments of the host 3900 may utilize only a subset or all of the components shown. The host application programs 3914 may be implemented in a container-based architecture and may provide support for video codecs (e.g., 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 multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 3914 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host 3900 may select and/or indicate a different host for over-the-top (OTT) services for a UE. The host application programs 3914 may support various protocols, such as the 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. 40 is a block diagram illustrating a virtualization environment 4000 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 4000 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized.

[0306] Applications 4002 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

[0307] Hardware 4004 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 4006 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 4008a and 4008b (one or more of which may be generally referred to as VMs 4008), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 4006 may present a virtual operating platform that appears like networking hardware to the VMs 4008.

[0308] The VMs 4008 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 4006. Different embodiments of the instance of a virtual appliance 4002 may be implemented on one or more of VMs 4008, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0309] In the context of NFV, a VM 4008 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non- virtualized machine. Each of the VMs 4008, and that part of hardware 4004 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 4008 on top of the hardware 4004 and corresponds to the application 4002.

[0310] Hardware 4004 may be implemented in a standalone network node with generic or specific components. Hardware 4004 may implement some functions via virtualization.

Alternatively, hardware 4004 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 4010, which, among others, oversees lifecycle management of applications 4002. In some embodiments, hardware 4004 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 4012 which may alternatively be used for communication between hardware nodes and radio units. [0311] FIG. 41 shows a communication diagram of a host 4102 communicating via a network node 4104 with a UE 4106 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 3612a of FIG. 36 and/or UE 3700 of FIG. 37), network node (such as network node 3610a of FIG. 36 and/or network node 3800 of FIG. 38), and host (such as host 3616 of FIG. 36 and/or host 3900 of FIG. 39) discussed in the preceding paragraphs will now be described with reference to FIG. 41.

[0312] Eike host 3900, embodiments of host 4102 include hardware, such as a communication interface, processing circuitry, and memory. The host 4102 also includes software, which is stored in or accessible by the host 4102 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 4106 connecting via an over-the-top (OTT) connection 4150 extending between the UE 4106 and host 4102. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 4150. [0313] The network node 4104 includes hardware enabling it to communicate with the host 4102 and UE 4106. The connection 4160 may be direct or pass through a core network (like core network 3606 of FIG. 36) and/or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

[0314] The UE 4106 includes hardware and software, which is stored in or accessible by UE 4106 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE 4106 with the support of the host 4102. In the host 4102, an executing host application may communicate with the executing client application via the OTT connection 4150 terminating at the UE 4106 and host 4102. In providing the service to the user, the UE’s client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection 4150 may transfer both the request data and the user data. The UE’s client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 4150. [0315] The OTT connection 4150 may extend via a connection 4160 between the host 4102 and the network node 4104 and via a wireless connection 4170 between the network node 4104 and the UE 4106 to provide the connection between the host 4102 and the UE 4106. The connection 4160 and wireless connection 4170, over which the OTT connection 4150 may be provided, have been drawn abstractly to illustrate the communication between the host 4102 and the UE 4106 via the network node 4104, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

[0316] As an example of transmitting data via the OTT connection 4150, in step 4108, the host 4102 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 4106. In other embodiments, the user data is associated with a UE 4106 that shares data with the host 4102 without explicit human interaction. In step 4110, the host 4102 initiates a transmission carrying the user data towards the UE 4106. The host 4102 may initiate the transmission responsive to a request transmitted by the UE 4106. The request may be caused by human interaction with the UE 4106 or by operation of the client application executing on the UE 4106. The transmission may pass via the network node 4104, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 4112, the network node 4104 transmits to the UE 4106 the user data that was carried in the transmission that the host 4102 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 4114, the UE 4106 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 4106 associated with the host application executed by the host 4102.

[0317] In some examples, the UE 4106 executes a client application which provides user data to the host 4102. The user data may be provided in reaction or response to the data received from the host 4102. Accordingly, in step 4116, the UE 4106 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input/output interface of the UE 4106. Regardless of the specific manner in which the user data was provided, the UE 4106 initiates, in step 4118, transmission of the user data towards the host 4102 via the network node 4104. In step 4120, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 4104 receives user data from the UE 4106 and initiates transmission of the received user data towards the host 4102. In step 4122, the host 4102 receives the user data carried in the transmission initiated by the UE 4106.

[0318] One or more of the various embodiments improve the performance of OTT services provided to the UE 4106 using the OTT connection 4150, in which the wireless connection 4170 forms the last segment. More precisely, the teachings of these embodiments may improve UE determination of a number of PRACH transmissions, RA-RNTI, and RAPID, which can reduce the time it takes for a UE to connect to a communications network and improve the resulting connection.

[0319] In an example scenario, factory status information may be collected and analyzed by the host 4102. As another example, the host 4102 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 4102 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 4102 may store surveillance video uploaded by a UE. As another example, the host 4102 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host 4102 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and/or transmitting data.

[0320] In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 4150 between the host 4102 and UE 4106, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 4102 and/or UE 4106. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 4150 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 4150 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 4104. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 4102. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 4150 while monitoring propagation times, errors, etc.

[0321] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0322] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain 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 the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and/or by end users and a wireless network generally.

[0323] Example Embodiments are described below.

[0324] Embodiment 1. A method of operating a communication device, the method comprising: determining (2610) a feature combination, FC, based on one or more features associated with at least one of: a capability of the communication device; a number of physical random access channel, PRACH, transmissions to transmit to a network node as part of a random access, RA, procedure; and a capability of the network node; transmitting (2630) a PRACH transmission based on the FC as part of the RA procedure.

[0325] Embodiment 2. The method of Embodiment 1, further comprising: determining (2620) a PRACH repetition factor to use during the RA procedure based on the FC.

[0326] Embodiment 3. The method of Embodiment 2, wherein the PRACH repetition factor comprises a number of PRACH transmissions to transmit to the network node, and wherein transmitting the PRACH transmission comprises transmitting the number of PRACH transmissions as part of the RA procedure with the network node.

[0327] Embodiment 4. A method of operating a communication device during a random access, RA, procedure associated with a network node of a communications network, the method comprising: determining (2710) a physical RA channel occasion, RO, offset configured to indicate an index of a second RO relative to a first RO associated with a set of PRACH transmissions; transmitting (2720) a first PRACH transmission of the set of PRACH transmissions to the network node at the first RO as part of the RA procedure; determining (2730) the second RO based on the first RO and the RO offset; and transmitting (2740) a second PRACH transmission of the set of PRACH transmissions to the network node at the second RO as part of the RA procedure. [0328] Embodiment 5. The method of Embodiment 4, further comprising: determining ROs associated with the set of PRACH transmissions, wherein determining the ROs associated with the set of PRACH transmissions comprises: determining that there are more than one frequency division multiplexed, FDMed, ROs; and determining that there are no FDMed ROs associated with the set of PRACH transmissions based on the RO offset being not configured or being configured to be the same value as the number of FDMed ROs.

[0329] Embodiment 6. The method of Embodiment 4, further comprising: determining ROs associated with the set of PRACH transmissions, wherein determining the RO offset comprises: determining that there are no frequency division multiplexed, FDMed, ROs; and determining the time-domain consecutive ROs associated with the set of PRACH transmissions based on the RO offset being not configured or being configured to be 1.

[0330] Embodiment 7. The method of any of Embodiments 4-6, further comprising any of the features of Embodiment 1-3.

[0331] Embodiment 8. The method of Embodiment 7, wherein determining the RO offset comprises determining the RO offset based on the FC.

[0332] Embodiment 9. A method of operating a communication device during a random access, RA, procedure associated with a network node of a communications network, the method comprising: transmitting (2810) a plurality of physical RA channel, PRACH, transmissions to the network node as part of the RA procedure; and determining (2820) a random access-radio network temporary identifier, RA-RNTI for the plurality of PRACH transmissions based on a specific RA channel occasion, RO, of at least one PRACH transmission of the plurality of PRACH transmissions.

[0333] Embodiment 10. The method of Embodiment 9, wherein the plurality of PRACH transmissions comprise a first PRACH transmission and a second PRACH transmission multiplexed in different frequency domain ROs at the same time instance, and wherein the specific RO comprises at least one of: a first RO with a smallest RO index; and a last RO with a largest RO index.

[0334] Embodiment 11. The method of any of Embodiments 9-10, further comprising any of the operations of Embodiments 1-8. [0335] Embodiment 12. A method of operating a communication device during a random access, RA, procedure associated with a network node of a communications network, the method comprising: responsive to transmitting a plurality of physical RA channel, PRACH, transmissions with different preambles in one PRACH occasion, RO, receiving (2920) a RA response, RAR, including a RA radio network temporary identifier, RA-RNTI; and determining (2930) if the RAR includes a RA preamble identifier, RAPID, that matches a preamble index associated with the plurality of PRACH transmissions.

[0336] Embodiment 13. The method of Embodiment 12, further comprising: disregarding (2940) the RAR based on determining that the RAR does not include the RAPID that matches the preamble index associated with the plurality of PRACH transmissions. [0337] Embodiment 14. The method of any of Embodiments 12-13, wherein the preamble index comprises a specific preamble index of a plurality of preamble indices associated with the plurality of PRACH transmissions.

[0338] Embodiment 15. The method of Embodiment 14, wherein the specific preamble index of a plurality of preamble indices comprises at least one of: a smallest preamble index; and a largest preamble index.

[0339] Embodiment 16. The method of any of Embodiments 12-15, further comprising any of the operations of Embodiments 1-11.

[0340] Embodiment 17. A method of operating a communication device during a random access, RA, procedure associated with a network node of a communications network, the method comprising: determining (3010) a number of physical RA channel, PRACH, transmissions to transmit to the network node with the same transmission, Tx, beam prior to receiving a random access response as part of the RA procedure based on whether the communication device is capable of beam correspondence for PRACH transmission; and transmitting (3020) the number of PRACH transmissions to the network node as part of the RA procedure.

[0341] Embodiment 18. The method of Embodiment 17, wherein determining the number of PRACH transmissions comprises determining whether the communication device is capable of beam correspondence.

[0342] Embodiment 19. The method of Embodiment 18, wherein determining whether the communication device is capable of beam correspondence comprises determining at least one of: whether the communication device is capable of generating an uplink, UL, transmission, Tx, beam corresponding to a best narrow reception, Rx, beam; and whether the communication device is capable of beamCorrespondenceWithoutUL- BeamS weeping.

[0343] Embodiment 20. The method of any of Embodiments 17-19, wherein the communication device is incapable of beam correspondence, and wherein determining the number of PRACH transmissions comprises: determining a characteristic of a wide downlink, DL, reception, Rx, beam; and determining the number of PRACH transmissions based on the characteristic of the wide DL Rx beam.

[0344] Embodiment 21. The method of Embodiment 20, wherein the characteristic of the wide DL Rx beam comprises at least one of: a reference signal received power, RSRP; and a reference signal received quality, RSRQ.

[0345] Embodiment 22. The method of any of Embodiments 17-19, wherein the communication device is capable of beam correspondence, and wherein determining the number of PRACH transmissions comprises: determining a characteristic of a narrow downlink, DL, reception, Rx, beam; determining a narrow uplink, UL, transmission, Tx, beam corresponding to the narrow DL Rx beam; and determining the number of PRACH transmissions based on the characteristic of the narrow DL Rx beam.

[0346] Embodiment 23. The method of Embodiment 22, wherein determining the number of PRACH transmissions comprises determining a set of one or more threshold values based on the communication device being incapable of beam correspondence, wherein determining the number of PRACH transmissions based on the characteristic of the narrow DL Rx beam comprises determining the number of PRACH transmissions based on comparing the characteristic with the set of one or more threshold values.

[0347] Embodiment 24. The method of Embodiment 22, wherein determining the number of PRACH transmissions based on the characteristic of the narrow DL Rx beam comprises: determining a first value based on comparing the characteristic with a set of one or more threshold values; and determining the number of PRACH transmissions by adjusting the first value based on an offset. [0348] Embodiment 25. The method of Embodiment 24, wherein determining the set of one or more threshold values comprises determining the offset based on at least one of: a number of antennas of the communication device; an estimate of a DL beam forming gain; and an indication received from the network node.

[0349] Embodiment 26. The method of any of Embodiments 17-25, wherein the communication device is capable of beam correspondence, and wherein determining the number of PRACH transmissions comprises: determining a characteristic of a narrow downlink, DL, reception, Rx, beam; determining a narrow uplink, UL, transmission, Tx, beam corresponding to the narrow DL Rx beam; and determining the number of PRACH transmissions based on the characteristic of the narrow DL Rx beam.

[0350] Embodiment 27. The method of Embodiment 26, wherein the characteristic of the narrow DL Rx beam comprises at least one of: a reference signal received power, RSRP; and a reference signal received quality, RSRQ.

[0351] Embodiment 28. The method of any of Embodiments 26-27, wherein determining the number of PRACH transmissions further comprises determining the number of PRACH transmissions by comparing the characteristic to one or more predetermined threshold values.

[0352] Embodiment 29. The method of any of Embodiments 17-28, further comprising any of the operations of Embodiments 1-16.

[0353] Embodiment 30. A method of operating a communication device during a random access, RA, procedure associated with a network node of a communications network, the method comprising: determining (3110) a first number of physical RA channel, PRACH, transmissions to transmit to the network node using a first transmission, Tx, beam prior to receiving a random access response as part of the RA procedure using a first procedure; responsive to transmitting the first number of PRACH transmissions to the network node as part of the RA procedure without receiving the RAR, determining (3120) whether to perform retransmission using a second Tx beam that is different than the first Tx beam; determining (3130) a second number of PRACH transmissions to transmit to the network node based on whether the second Tx beam will be used to transmit the second number of PRACH transmissions. [0354] Embodiment 31. The method of Embodiment 30, wherein determining whether to perform the retransmission using the second Tx beam comprises determining to perform the retransmission using the first Tx beam, and wherein determining the second number of PRACH transmissions comprises determining the second number of PRACH transmission using the first procedure.

[0355] Embodiment 32. The method of Embodiment 30, wherein determining whether to perform the retransmission using the second Tx beam comprises determining to perform the retransmission using the second Tx beam, and wherein determining the second number of PRACH transmissions comprises determining the second number of PRACH transmission using a second procedure that is different from the first procedure.

[0356] Embodiment 33. The method of any of Embodiments 30-32, further comprising any of the operations of Embodiments 1-29.

[0357] Embodiment 34. A method of operating a communication device during a random access, RA, procedure associated with a network node of a communications network, the method comprising: determining (3210) a number of physical RA channel, PRACH, transmissions to transmit to the network node prior to receiving a RA response as part of the RA procedure; responsive to determining the number of PRACH transmissions, determining (3220) that transmitting the number of PRACH transmissions will cause an uplink, UL, transmission percentage in an evaluation period to exceed an UL duty cycle; and responsive to determining that transmitting the number of PRACH transmissions will cause the UL transmission percentage in the evaluation period to exceed the UL duty cycle, performing (3230) an action associated with the number of PRACH transmissions.

[0358] Embodiment 35. The method of Embodiment 34, wherein performing the action comprises reducing PRACH transmission power associated with the number of PRACH transmissions.

[0359] Embodiment 36. The method of any of Embodiments 34-35, wherein performing the action comprises delaying transmission of the number of PRACH transmissions.

[0360] Embodiment 37. The method of any of Embodiments 34-36, wherein performing the action comprises reducing the number of PRACH transmissions.

[0361] Embodiment 38. The method of any of Embodiments 34-37, wherein performing the action comprises selecting different RA channel, RACH, resources associated with the number of PRACH transmissions. [0362] Embodiment 39. The method of any of Embodiments 34-38, further comprising any of the operations of Embodiments 1-33.

[0363] Embodiment 40. A communication device (3700), the communication device comprising: processing circuitry (3702); and memory (3710) coupled to the processing circuitry and having instructions stored therein that are executable by the processing circuitry to cause the communication device to perform operations comprising any of the operations of Embodiments 1-39.

[0364] Embodiment 41. A communication device (3700) adapted to perform any of the operations of Embodiments 1-39.

[0365] Embodiment 42. A computer program comprising program code to be executed by processing circuitry (3702) of a communication device (3700), whereby execution of the program code causes the communication device to perform operations comprising any operations of Embodiments 1-39.

[0366] Embodiment 43. A computer program product comprising a non-transitory storage medium (3704) including program code to be executed by processing circuitry (3702) of a communication device (3700) communicatively coupled to a communications network that includes a network node, whereby execution of the program code causes the communication device to perform operations comprising any operations of Embodiments 1-39.

[0367] Embodiment 44. A non-transitory computer-readable medium having instructions stored therein that are executable by processing circuitry (3702) of a communication device (3700) to cause the communication device to perform operations comprising any of the operations of Embodiments 1-39.

[0368] Embodiment 45. A method of operating a network node, the method comprising: determining (3310) a feature combination, FC, based on one or more features associated with at least one of: a capability of a communication device; a number of physical random access channel, PRACH, transmissions that will be transmitted to the network node as part of a random access, RA, procedure; and a capability of the network node; receiving (3330) a PRACH transmission based on the FC as part of the RA procedure.

[0369] Embodiment 46. The method of Embodiment 45, further comprising: determining (3320) a PRACH repetition factor that will be used during the RA procedure based on the FC. [0370] Embodiment 47. The method of Embodiment 46, wherein the PRACH repetition factor comprises a number of PRACH transmissions to transmitted towards the network node, and wherein receiving the PRACH transmission comprises receiving the number of PRACH transmissions as part of the RA procedure with the communication device.

[0371] Embodiment 48. A method of operating a network node of a communications network during a random access, RA, procedure associated with a communication device, the method comprising: determining (3410) a physical RA channel occasion, RO, offset configured to indicate an index of a second RO relative to a first RO associated with a set of PRACH transmissions; receiving (3420) a first PRACH transmission of the set of PRACH transmissions form the communication device at the first RO as part of the RA procedure; determining (3430) the second RO based on the first RO and the RO offset; and receiving (3440) a second PRACH transmission of the set of PRACH transmissions from the communication device at the second RO as part of the RA procedure.

[0372] Embodiment 49. The method of Embodiment 48, further comprising: determining ROs associated with the set of PRACH transmissions, wherein determining the ROs associated with the set of PRACH transmissions comprises: determining that there are more than one frequency division multiplexed, FDMed, ROs; and determining that there are no FDMed ROs associated with the set of PRACH transmissions based on the RO offset being not configured or being configured to be the same value as the number of FDMed ROs.

[0373] Embodiment 50. The method of Embodiment 48, further comprising: determining ROs associated with the set of PRACH transmissions, wherein determining the RO offset comprises: determining that there are no frequency division multiplexed, FDMed, ROs; and determining the time-domain consecutive ROs associated with the set of PRACH transmissions based on the RO offset being not configured or being configured to be 1.

[0374] Embodiment 51. The method of any of Embodiments 48-50, further comprising any of the features of Embodiment 45-47.

[0375] Embodiment 52. The method of Embodiment 51, wherein determining the RO offset comprises determining the RO offset based on the FC. [0376] Embodiment 53. A method of operating a network node of a communications network during a random access, RA, procedure associated with a communication device, the method comprising: receiving (3510) a plurality of physical RA channel, PRACH, transmissions with different preambles in one PRACH occasion, RO; responsive to receiving the plurality of PRACH transmissions with different preambles in one PRACH occasion, RO, determining (3520) a RA preamble identifier, RAPID, that matches a preamble index associated with the plurality of PRACH transmissions; and transmitting (3530) a RA response, RAR, including the RAPID to the communications device.

[0377] Embodiment 54. The method of Embodiment 53, wherein the preamble index comprises a specific preamble index of a plurality of preamble indices associated with the plurality of PRACH transmissions.

[0378] Embodiment 55. The method of Embodiment 54, wherein the specific preamble index of a plurality of preamble indices comprises at least one of: a smallest preamble index; and a largest preamble index.

[0379] Embodiment 56, The method of any of Embodiments 53-55, further comprising any of the operations of Embodiments 45-52.

[0380] Embodiment 57. A network node (3800), the network node comprising: processing circuitry (3802); and memory (3804) coupled to the processing circuitry and having instructions stored therein that are executable by the processing circuitry to cause the network node to perform operations comprising any of the operations of Embodiments 45-56.

[0381] Embodiment 58. A network node (3800) adapted to perform operations comprising any of the operations of Embodiments 45-56.

[0382] Embodiment 59. A computer program comprising program code to be executed by processing circuitry (3802) of a network node (3800), whereby execution of the program code causes the network node to perform operations comprising any operations of Embodiments 45- 56.

[0383] Embodiment 60. A computer program product comprising a non-transitory storage medium (3804) including program code to be executed by processing circuitry (3802) of a network node (3800), whereby execution of the program code causes the network node to perform operations comprising any operations of Embodiments 45-56. [0384] Embodiment 61. A non-transitory computer-readable medium having instructions stored therein that are executable by processing circuitry (3802) of a network node (3800) to cause the network node to perform operations comprising any of the operations of Embodiments 45-56.

[0385] Embodiment 62. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; and a network interface configured to initiate transmission of the user data to a network node in a cellular network for transmission to a user equipment (UE), the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform the following operations to transmit the user data from the host to the UE: determining (3310) a feature combination, FC, based on one or more features associated with at least one of: a capability of a communication device; a number of physical random access channel, PRACH, transmissions that will be transmitted to the network node as part of a random access, RA, procedure; and a capability of the network node; receiving (3330) a PRACH transmission based on the FC as part of the RA procedure.

[0386] Embodiment 63. The host of the previous embodiment, wherein: the processing circuitry of the host is configured to execute a host application that provides the user data; and the UE comprises processing circuitry configured to execute a client application associated with the host application to receive the transmission of user data from the host.

[0387] Embodiment 64. A method implemented in a host configured to operate in a communication system that further includes a network node and a user equipment (UE), the method comprising: providing user data for the UE; and initiating a transmission carrying the user data to the UE via a cellular network comprising the network node, wherein the network node performs the following operations to transmit the user data from the host to the UE: determining (3310) a feature combination, FC, based on one or more features associated with at least one of: a capability of a communication device; a number of physical random access channel, PRACH, transmissions that will be transmitted to the network node as part of a random access, RA, procedure; and a capability of the network node; receiving (3330) a PRACH transmission based on the FC as part of the RA procedure.

[0388] Embodiment 65. The method of the previous embodiment, further comprising, at the network node, transmitting the user data provided by the host for the UE.

[0389] Embodiment 66. The method of any of the previous 2 embodiments, wherein the user data is provided at the host by executing a host application that interacts with a client application executing on the UE, the client application being associated with the host application.

[0390] Embodiment 67. A communication system configured to provide an over-the-top service, the communication system comprising: a host comprising: processing circuitry configured to provide user data for a user equipment (UE), the user data being associated with the over-the-top service; and a network interface configured to initiate transmission of the user data toward a cellular network node for transmission to the UE, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform the following operations to transmit the user data from the host to the UE: determining (3310) a feature combination, FC, based on one or more features associated with at least one of: a capability of a communication device; a number of physical random access channel, PRACH, transmissions that will be transmitted to the network node as part of a random access, RA, procedure; and a capability of the network node; receiving (3330) a PRACH transmission based on the FC as part of the RA procedure.

[0391] Embodiment 68. The communication system of the previous embodiment, further comprising: the network node; and/or the user equipment.

[0392] Embodiment 69. The communication system of the previous 2 embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the user data; and the host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.

[0393] Embodiment 70. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to initiate receipt of user data; and a network interface configured to receive the user data from a network node in a cellular network, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform the following operations to receive the user data from the UE for the host: determining (3310) a feature combination, FC, based on one or more features associated with at least one of: a capability of a communication device; a number of physical random access channel, PRACH, transmissions that will be transmitted to the network node as part of a random access, RA, procedure; and a capability of the network node; receiving (3330) a PRACH transmission based on the FC as part of the RA procedure.

[0394] Embodiment 71. The host of the previous 2 embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the user data; and the host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.

[0395] Embodiment 72. The host of the any of the previous 2 embodiments, wherein the initiating receipt of the user data comprises requesting the user data.

[0396] Embodiment 73. A method implemented by a host configured to operate in a communication system that further includes a network node and a user equipment (UE), the method comprising: at the host, initiating receipt of user data from the UE, the user data originating from a transmission which the network node has received from the UE, wherein the network node performs the following operations to receive the user data from the UE for the host: determining (3310) a feature combination, FC, based on one or more features associated with at least one of: a capability of a communication device; a number of physical random access channel, PRACH, transmissions that will be transmitted to the network node as part of a random access, RA, procedure; and a capability of the network node; receiving (3330) a PRACH transmission based on the FC as part of the RA procedure.

[0397] Embodiment 74. The method of the previous embodiment, further comprising at the network node, transmitting the received user data to the host.

[0398] Embodiment 75. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; and a network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment (UE), wherein the UE comprises a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform the following operations to receive the user data from the host: determining (2610) a feature combination, FC, based on one or more features associated with at least one of: a capability of the communication device; a number of physical random access channel, PRACH, transmissions to transmit to a network node as part of a random access, RA, procedure; and a capability of the network node; transmitting (2630) a PRACH transmission based on the FC as part of the RA procedure.

[0399] Embodiment 76. The host of the previous embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit the user data to the UE from the host.

[0400] Embodiment 77. The host of the previous 2 embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the user data; and the host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.

[0401] Embodiment 78. A method implemented by a host operating in a communication system that further includes a network node and a user equipment (UE), the method comprising: providing user data for the UE; and initiating a transmission carrying the user data to the UE via a cellular network comprising the network node, wherein the UE performs the following operations to receive the user data from the host: determining (2610) a feature combination, FC, based on one or more features associated with at least one of: a capability of the communication device; a number of physical random access channel, PRACH, transmissions to transmit to a network node as part of a random access, RA, procedure; and a capability of the network node; transmitting (2630) a PRACH transmission based on the FC as part of the RA procedure.

[0402] Embodiment 79. The method of the previous embodiment, further comprising: at the host, executing a host application associated with a client application executing on the UE to receive the user data from the UE.

[0403] Embodiment 80. The method of the previous embodiment, further comprising: at the host, transmitting input data to the client application executing on the UE, the input data being provided by executing the host application, wherein the user data is provided by the client application in response to the input data from the host application.

[0404] Embodiment 81. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to utilize user data; and a network interface configured to receipt of transmission of the user data to a cellular network for transmission to a user equipment (UE), wherein the UE comprises a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform the following operations to transmit the user data to the host: determining (2610) a feature combination, FC, based on one or more features associated with at least one of: a capability of the communication device; a number of physical random access channel, PRACH, transmissions to transmit to a network node as part of a random access, RA, procedure; and a capability of the network node; transmitting (2630) a PRACH transmission based on the FC as part of the RA procedure. [0405] Embodiment 82. The host of the previous embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit the user data from the UE to the host.

[0406] Embodiment 83. The host of the previous 2 embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the user data; and the host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.

[0407] Embodiment 84. A method implemented by a host configured to operate in a communication system that further includes a network node and a user equipment (UE), the method comprising: at the host, receiving user data transmitted to the host via the network node by the UE, wherein the UE performs the following operations to transmit the user data to the host: determining (2610) a feature combination, FC, based on one or more features associated with at least one of: a capability of the communication device; a number of physical random access channel, PRACH, transmissions to transmit to a network node as part of a random access, RA, procedure; and a capability of the network node; transmitting (2630) a PRACH transmission based on the FC as part of the RA procedure.

[0408] Embodiment 85. The method of the previous embodiment, further comprising: at the host, executing a host application associated with a client application executing on the UE to receive the user data from the UE.

[0409] Embodiment 86. The method of the previous embodiments, further comprising: at the host, transmitting input data to the client application executing on the UE, the input data being provided by executing the host application, wherein the user data is provided by the client application in response to the input data from the host application.

Claims

CLAIMS What is Claimed is:

1. A method of operating a communication device during a random access, RA, procedure associated with a network node of a communications network, the method comprising: transmitting (2810) a plurality of physical RA channel, PRACH, transmissions to the network node as part of the RA procedure; and determining (2820) a random access-radio network temporary identifier, RA-RNTI, for the plurality of PRACH transmissions based on a specific RA channel occasion, RO, of a set of ROs that are determined before applying collision handling rules to the plurality of PRACH transmissions.

2. The method of Claim 1, wherein the plurality of PRACH transmissions comprise a first PRACH transmission and a second PRACH transmission multiplexed in different frequency domain ROs at the same time instance, and wherein the specific RO comprises at least one of: a first RO with a smallest RO index; and a last RO with a largest RO index.

3. The method of any of Claims 1-2, further comprising: determining (2610) a feature combination, FC, based on one or more features associated with at least one of: a capability of the communication device; and a capability of the network node; wherein transmitting the plurality of PRACH transmissions comprises transmitting a PRACH transmission based on the FC as part of the RA procedure.

4. The method of Claim 3, wherein a PRACH repetition factor comprises a number of PRACH transmissions to transmit to the network node, and wherein transmitting the PRACH transmission comprises transmitting the number of PRACH transmissions as part of the RA procedure with the network node.

5. The method of any of Claims 1-4, further comprising: determining (2710) a RO offset configured to indicate an index of a second RO relative to a first RO associated with the plurality of PRACH transmissions; transmitting (2720) a first PRACH transmission of the plurality of PRACH transmissions to the network node at the first RO as part of the RA procedure; determining (2730) the second RO based on the first RO and the RO offset; and transmitting (2740) a second PRACH transmission of the plurality of PRACH transmissions to the network node at the second RO as part of the RA procedure.

6. The method of Claim 5, further comprising: determining ROs associated with the set of PRACH transmissions, wherein determining the ROs associated with the plurality of PRACH transmissions comprises: determining that there are more than one frequency division multiplexed, FDMed, ROs; and determining that there are no FDMed ROs associated with the plurality of PRACH transmissions based on the RO offset being not configured or being configured to be the same value as a number of FDMed ROs.

7. The method of Claim 5, further comprising: determining ROs associated with the plurality of PRACH transmissions, wherein determining the RO offset comprises: determining that there are no frequency division multiplexed, FDMed, ROs; determining time-domain consecutive ROs associated with the plurality of PRACH transmissions based on the RO offset being not configured or being configured to be 1.

8. The method of any of Claims 5-7, wherein determining the RO offset comprises determining the RO offset based on the FC.

9. The method of any of Claims 1-8, further comprising: responsive to transmitting the plurality of PRACH transmissions with different preambles in one RO, receiving (2920) a RA response, RAR, including a RA radio network temporary identifier, RA-RNTI; and determining (2930) if the RAR includes a RA preamble identifier, RAPID, that matches a preamble index associated with the plurality of PRACH transmissions.

10. The method of Claim 9, further comprising: disregarding (2940) the RAR based on determining that the RAR does not include the RAPID that matches the preamble index associated with the plurality of PRACH transmissions.

11. The method of any of Claims 9-10, wherein the preamble index comprises a specific preamble index of a plurality of preamble indices associated with the plurality of PRACH transmissions.

12. The method of Claim 11, wherein the specific preamble index of a plurality of preamble indices comprises at least one of: a smallest preamble index; and a largest preamble index.

13. The method of any of Claims 1-12, further comprising: determining (3010) a number of the plurality of PRACH transmissions to transmit to the network node with the same transmission, Tx, beam prior to receiving a random access response as part of the RA procedure based on whether the communication device is capable of beam correspondence for PRACH transmission

14. The method of any of Claims 1-13, further comprising: determining (3110) a first number of PRACH transmissions to transmit to the network node using a first transmission, Tx, beam prior to receiving a random access response as part of the RA procedure; responsive to transmitting the first number of PRACH transmissions to the network node as part of the RA procedure without receiving a RA response, RAR, associated with the first number of PRACH transmissions, determining (3120) whether to perform retransmission using a second Tx beam that is different than the first Tx beam; determining (3130) a second number of PRACH transmissions to transmit to the network node based on whether the second Tx beam will be used to transmit the second number of PRACH transmissions.

15. A communication device (3700) adapted to perform operations during a random access, RA, procedure associated with a network node of a communications network comprising: transmitting (2810) a plurality of physical RA channel, PRACH, transmissions to the network node as part of the RA procedure; and determining (2820) a random access-radio network temporary identifier, RA-RNTI, for the plurality of PRACH transmissions based on a specific RA channel occasion, RO, of a set of ROs that are determined before applying collision handling rules to the plurality of PRACH transmissions.

16. The communication device of Claim 15, further adapted to perform any of the operations of Claims 2-14.

17. A computer program comprising program code to be executed by processing circuitry (3702) of a communication device (3700) during a random access, RA, procedure associated with a network node of a communications network, whereby execution of the program code causes the communication device to perform operations comprising: transmitting (2810) a plurality of physical RA channel, PRACH, transmissions to the network node as part of the RA procedure; and determining (2820) a random access-radio network temporary identifier, RA-RNTI, for the plurality of PRACH transmissions based on a specific RA channel occasion, RO, of a set of ROs that are determined before applying collision handling rules to the plurality of PRACH transmissions.

18. The computer program of Claim 17, the operations further comprising any operations of Claims 2-14.

19. A computer program product comprising a non-transitory storage medium (3704) including program code to be executed by processing circuitry (3702) of a communication device (3700) during a random access, RA, procedure associated with a network node of a communications network, whereby execution of the program code causes the communication device to perform operations comprising: transmitting (2810) a plurality of physical RA channel, PRACH, transmissions to the network node as part of the RA procedure; and determining (2820) a random access-radio network temporary identifier, RA-RNTI, for the plurality of PRACH transmissions based on a specific RA channel occasion, RO, of a set of ROs that are determined before applying collision handling rules to the plurality of PRACH transmissions.

20. The computer program product of Claim 19, the operations further comprising any operations of Claims 2-14.