EP4229973A1

EP4229973A1 - Enhancing random access channel report content with message3 information

Info

Publication number: EP4229973A1
Application number: EP21795041.9A
Authority: EP
Inventors: Ali PARICHEHREHTEROUJENI; Marco BELLESCHI; Johan Rune; Pradeepa Ramachandra
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2020-10-16
Filing date: 2021-10-14
Publication date: 2023-08-23
Also published as: WO2022081074A1

Abstract

A method (1200) by a wireless device (110) includes transmitting (1202), to a network node (160), a first PUSCH message of a Random Access (RA) procedure and transmitting (1204), to the network node, RA related information associated with the transmission of the first Physical Uplink Shared Channel (PUSCH) message of the RA procedure.

Description

ENHANCING RANDOM ACCESS CHANNEL REPORT CONTENT WITH MESSAGE3 INFORMATION

TECHNICAL FIELD

The present disclosure relates, in general, to wireless communications and, more particularly, systems and methods for enhancing Random Access Channel (RACH) report content with Message3 (MSG3) information.

BACKGROUND

In LTE, the network may request, via the User Equipment (UE) Information procedure in Radio Resource Control (RRC), a report of RACH information when random access channel (RACH) procedure is performed and is successful. That procedure is summarized in RRC specifications and is discussed in more detail below.

In random access procedure in LTE, the UE sends a preamble and waits for a random-access response (RAR) during a pre-configured time window (RAR window). If the RAR does not come within that time, the UE adjusts some preamble transmission parameters (e.g. transmission power) and transmits it again in what is called power ramping adjustment. If the procedure is successful, at the n-th transmission, the preamble will be responded to in the RAR. The number n is provided in the RACH report so that the network knows how many times the UE needed to ramp up the power before the procedure was successful. As such, for each RACH procedure, the UE stores the number of preambles sent, which corresponds to the parameter PREAMBLE TRANSMISSION COUNTER.

The meaning of the PREAMBLE TRANSMISSION COUNTER is described in the Medium Access Control (MAC) specifications in 3GPP TS 36.331 v. 16.6.0, section 5.6.5. First of all, during the initialization the counter is set of 1. Then, at the first attempt, according to the preamble transmission in Section 5.3.1, the UE shall set the preamble received target power, which is the expected power in the RACH receiver at the eNodeB (eNB), to the initial transmission power, which is a parameter provided by the eNB such as, for example, via SIB2 in LTE. These values may range from -120dBm to -90dBm, and are provided as part of the Power Ramping Parameters. Note that this may also be a parameter to be optimized later. A value that is too large may lead to a high RACH success rate, but it could also create unnecessary uplink (UL) interference, which may be especially problematic in high load scenarios. The PREAMBLE RECEIVED TARGET POWER will be in this first attempt the preamblelnitialReceivedTargetPower + DELTA PREAMBLE, and the offset depends on the preamble format that has been configured by the network in prach-Configlndex and may range from -3dB to 8 dB.

Then, as described in Section 3 of 3GPP TS 36.321, if no response is received within the configured RAR time window, another parameter to possibly optimize, PREAMBLE TRANSMISSION COUNTER is incremented by 1. Then, the UE determines whether the number of increments has reached its maximum value or not. The maximum value is also a configurable parameter that may be optimized.

Assuming the UE may still perform preamble re-transmission, power ramping occurs and the new preamble transmission power is incremented by a power ramping step, which is also a configurable parameter. The transmission power in this second attempt will then be:

PREAMBLE RECEIVED TARGET POWER = preamblelnitialReceivedTargetPower + DELTA PREAMBLE + 1* powerRampingStep

The parameter powerRampingStep may be 0 dB, 2 dB, 4 dB or 6 dB. Power ramping parameters as broadcasted in SIB2.

As in LTE, the random access procedure is described in the NR MAC specifications and parameters are configured by RRC such as, for example, in system information or handover (RRCReconfiguration with reconfigurationWithSync). Random access is triggered in many different scenarios. For example, random access may be triggered when the UE is in RRC IDLE or RRC INACTIVE and want to access a cell that it is camping on. In other words, random access may be triggered when the UE wants to transition to RRC CONNECTED.

In NR, RACH configuration is broadcasted in SIB1, as part of the servingCellConfigCommon (with both DL and UL configurations), where the RACH configuration is within the uplinkConflgCommon. The exact RACH parameters are within what is called initialUplinkBWP, since this is the part of the UL frequency the UE shall access and search for RACH resources.

The RACH configuration is discussed below with a primary focus on parameters related to the preamble power ramping functionality, i.e., power ramping step and initial power ramping, as discussed above for LTE. The RACH configuration parameters are defined in 3GPP Technical Specification 38.331 version 16.6.0 and the random access procedure (in which the RACH configuration parameters are utilized) is described in 3GPP Technical Specification 38.321 version 16.6.0.

As discussed above with regard to LTE, the RACH report to assist the network to perform RACH optimization contains the number of preamble transmissions required until the procedure succeeds. It is also very clear what has happened at the UE between the first transmission and the last transmission until the procedure was considered successful. Specifically, as described above, the UE has applied power ramping in accordance with a configured step and then transmitted the preamble once more.

As in LTE, a similar counter, PREAMBLE TRANSMISSION COUNTER, also exists in NR to assist the UE to perform power ramping as sort of a RACH state variable. And, as in LTE, during initialization, the counter is set to 1 so that the initial transmission power for the selected preamble is PREAMBLE RECEIVED TARGET POWER = preambleReceivedTargetPower + DELTA PREAMBLE. This is just like in LTE, where in the first attempt the transmission power is just the initial transmission power configured by the network + a specified offset that depends on the selected preamble.

Also, as in LTE, if no response is received within the configured RAR time window, the PREAMBLE TRANSMISSION COUNTER is incremented by 1. Then, the UE checks whether the number of increments has reached its maximum value or not, which again is also a configurable parameter that may be optimized.

However, there are differences between the power ramping procedure in NR as compared to LTE. Specifically, in NR, random access resource selection needs to be performed within a cell depending on measurements performed on synchronization signal blocks (SSBs) or channel state information-reference signals (CSI-RSs). A cell in NR is basically defined by a set of these SSBs that may be transmitted in one (typical implementation for lower frequencies such as, for example, below 6GHz) or multiple downlink beams (typical implementation for lower frequencies such as, for example, below 6GHz). For the same cell, these SSBs carry the same physical cell identifier (PCI) and a master information block (MIB). For standalone operation, to support UEs camping on an NR cell, they also carry in SIB1 the RACH configuration, which comprises a mapping between the detected SSB covering the UE at a given point in time and the Physical Random Access Channel (PRACH) configuration (e.g. time, frequency, preamble, etc.) to be used. For that, each of these beams may transmit its own SSB which may be distinguished by an SSB index. FIGURE 1 illustrates examples of a network node such as a base station transmitting a single SSB with a single SSB index and a network node transmitting multiple SSBs with different SSB indexes.

The mapping between RACH resources and SSBs (or CSI-RS) is also provided as part of the RACH configuration (in RACH-ConfigCommon). Two parameters are relevant here:

#SSBs-per-PRACH-occasion: 1/8, 1/4, 1/2, 1, 2, 8 or 16, which represents the number of SSBs per RACH occasion, and

#CB-preambles-per-SSB preambles to each SS-block: within a RACH occasion, how many preambles are allocated.

FIGURE 2 illustrates an example scenario where the number of SSBs per RACH occasion is one. If the UE is under the coverage of a specific SSB such as, for example, SSB index 2, there will be a RACH occasion for that SSB index 2. If the UE moves and is then under the coverage of another specific SSB such as, for example, SSB index 5, there will be another RACH occasion for that SSB index 5. For example, each SSB detected by a given UE would have its own RACH occasion. Hence, at the network side, upon detecting a preamble in a particular RACH occasion the network knows exactly which SSB the UE has selected and, consequently, which downlink beam is covering the UE, so that the network can continue a downlink transmission, which may include the RAR. The number of SSBs per RACH occasion is configurable between 1/8 and 16, where 1/8 means that each SSB is associated with 8 RACH occasion (and each RACH occasion is associated with one SSB and 16 means that 16 SSBs are associated with each RACH occasion. The factor 1 (i.e. 1 SSB per RACH occasions, as in the example of FIGURE 2) is an indication that each SSB has its own RACH resource. A preamble detected there indicates to the network which SSB the UE has selected, which in turn indicates the DL beam the network should use to communicate with the UE such as, for example, the DL beam to use to send the RAR to the UE.

Each SS-block typically maps to multiple preambles (different cyclic shifts and Zadoff-Chu roots) within a PRACH occasion, so that it is possible to multiplex different UEs in the same RACH occasions since they may be under the coverage of the same SSB. FIGURE 3 illustrates another example where the number of SSBs per RACH occasion is two. Hence, a preamble received in that RACH occasion indicates to the network that one of the two beams are being selected by the UE. Either the network has means via implementation to distinguish these two beams and/or should perform a beam sweeping in the downlink by transmitting the RAR in both beams, either simultaneously or, transmitting in one, waiting for a response from the UE, and if absent, transmit in the other.

In an example scenario, it may be assumed that in a first attempt the UE selects an SSB (based on measurements performed in that cell). The UE transmits with initial power a selected preamble associated to the PRACH resource mapped to the selected SSB. Even if the UE has not received a RAR within the RAR time window, according to the specifications, the UE may still perform preamble re-transmission if the maximum number of allowed transmissions has not been reached.

As in LTE, at every preamble retransmission attempt, the UE may assume the same SSB as the previous attempt and perform power ramping similar to LTE. A maximum number of attempts is also defined in NR, which is also controlled by the parameter PREAMBLE TRANSMISSION COUNTER.

On the other hand, different from LTE, at every preamble retransmission attempt, the UE may alternatively select a different SSB, as long as that new SSB has an acceptable quality (i.e., its measurements are above a configurable threshold). In that case, when a new SSB (or, in more general term, a new beam) is selected, the UE does not perform power ramping but instead transmits the preamble with the same previously transmitted power (i.e. UE shall not re-initiate the power to the initial power transmission). FIGURE 4 illustrates such an example transmission and retransmission scenario.

For that reason, a new variable is defined in the 3GPP TS 38.321 called PREAMBLE POWER RAMPING COUNTER, for the case when the same beam is selected at a retransmission. At the same time, the previous LTE variable still exists (PREAMBLE TRANSMISSION COUNTER), so that the total number of attempts is still limited, regardless if the UE performs at each attempt SSB/beam re-selection or power ramping.

If the initial preamble transmission, e.g. associated to SSB-2 in FIGURE 4, does not succeed and the UE selects the same SSB/beam, the PREAMBLE POWER RAMPING COUNTER is incremented (i.e. set to 2 in this second attempt) and the transmission power will be:

PREAMBLE RECEIVED TARGET POWER = preambleReceivedTargetPower + DELTA PREAMBLE + I * PREAMBLE POWER RAMPING _STEP; Else, if instead the UE selects a different SSB/beam, the PREAMBLE POWER RAMPING COUNTER is not incremented (i.e. remains 1) and the transmission power will be as in the first transmission:

PREAMBLE RECEIVED TARGET POWER = preambleReceivedTargetPower + DELTA PREAMBLE;

The preamble power ramping procedure, in case of multiple preamble transmission attempts, is described in more detail in 3GPP TS 38.321.

Certain problems exist. For example, Self Optimizing Network (SON) features are used to enable self-optimization of network functions, based on various types of data collected by network entities, including data collected by UEs, which may report such data to the network. Some of the information the network obtains from a UE using the UEInformationRequest-UEInformationResponse RRC message exchange are used for tuning/optimizing the network’s configurations related to the random access (RA) procedure.

To maximize the network’s possibilities to tune and optimize the RA related configurations based on the information retrieved from UEs, the reported information should ideally allow the network to analyze the RA attempts the UE has performed in such detail that it can distinguish different cases, e.g. failure cases, with as fine granularity as possible. Among the RA related parameters the network can retrieve from the UE about the RA attempts/ procedures the UE has performed, the only parameter that essentially aids the network to distinguish between different RA attempt failure cases is the Boolean parameter contentionDetected-r 16, which is set to “true” if the UE received a Msg4 addressed to the UE’s Temporary Cell Specific-Radio Network Temporary Identifier (TC- RNTI) indicating another UE in the UE Contention Resolution Identity Medium Access Control Element (MAC CE) or if the UE’s contention resolution timer expires.

This parameter is a very coarse tool in the network’s analysis of what has happened in the RA attempts a UE has performed. To enable more advanced SON functionality related to random access related configurations, new means are needed that allows the network to perform more detailed analysis of the RA related feedback obtained from the UEs.

SUMMARY Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges. For example, according to certain embodiments, a wireless device such as, for example, a UE may log additional information on transmission of preamble, receiving random access response, transmission of msg3, and/or reception of msg4 in RA procedure. Such information may be provided to the network (such as to a network node such as a RAN node, for example) as RACH feedback for mobility robustness optimization and/or RACH optimization and/or Coverage and capacity optimization (CCO) by the network.

According to certain embodiments, a method by a wireless device includes transmitting, to a network node, a first PUSCH message of a RACH procedure. The method also includes transmitting RA related information associated with the transmission of the first PUSCH message of the RACH procedure.

According to certain embodiments, a wireless device is adapted to transmit, to a network node, a first PUSCH message of a RACH procedure. The wireless device is also adapted to transmit RA related information associated with the transmission of the first PUSCH message of the RACH procedure.

According to certain embodiments, a method by a network node includes receiving, from a wireless device, RA related information associated with a transmission of a first PUSCH message of a RACH procedure.

According to certain embodiments, a network node is adapted to receive, from a wireless device, RA related information associated with a transmission of a first PUSCH message of a RACH procedure

Certain embodiments may provide one or more of the following technical advantages. For example, one technical advantage may be that certain embodiments include the wireless device providing an indication in the RACH report indicating whether the msg3 failed as part of four-step RACH procedure (or failure of pay load as part of msgA transmission in two-step RACH procedure). As a result, a further technical advantage may be that certain embodiments enable the network to tune the corresponding parameters to enhance the signaling of msg3 (or payload as part of msgA transmission in two-step RACH procedure) to avoid failure of RACH procedure caused by failure of msg3 (or payload of msgA in two-step RACH procedure). As another example, a technical advantage may be that certain embodiments enable the network to determine that a UE is not capable in decoding the msg4 (e.g., due to high interference) and possibly reconfigure the msg4 resources in such a way that UE decodes the msg4 in a more robust way. As another example, a technical advantage may be that certain embodiments provide an indication of a transmission power level used for transmitting the msg3 (or payload of msgA in two-step RACH procedure) as well as measured downlink pathloss. Accordingly, certain embodiments may assist and/or enable the network to determine if there is any uplink/downlink mismatch and tune the related parameters in such a way to balance the downlink and uplink. Balancing the downlink and uplink may enable the UE to calculate the transmission power level more accurately.

As still another example, a technical advantage may be that certain embodiments provide an indication of a root cause of contention resolution failure after successful transmission of msg3. Accordingly, certain embodiments may help the RAN node to determine if the failure has been caused by an actual contention between UEs or due to radio link issue which impaired delivery of the msg4 to the UE and expiry of the contention resolution timer.

Other advantages may be readily apparent to one having skill in the art. Certain embodiments may have none, some, or all of the recited advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the disclosed embodiments and their features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:

FIGURE 1 illustrates examples of a network node such as a base station transmitting a single SSB with a single SSB index and a network node transmitting multiple SSBs with different SSB indexes;

FIGURE 2 illustrates an example scenario where the number of SSBs per RACH occasion is one;

FIGURE 3 illustrates another example where the number of SSBs per RACH occasion is two;

FIGURE 4 illustrates such an example transmission and retransmission scenario;

FIGURE 5 illustrates an example wireless network, according to certain embodiments;

FIGURE 6 illustrates an example network node, according to certain embodiments;

FIGURE 7 illustrates an example wireless device, according to certain embodiments;

FIGURE 8 illustrate an example user equipment, according to certain embodiments;

FIGURE 9 illustrates a virtualization environment in which functions implemented by some embodiments may be virtualized, according to certain embodiments;

FIGURE 10 illustrates an example method by a wireless device, according to certain embodiments;

FIGURE 11 illustrates another example method by a wireless device, according to certain embodiments;

FIGURE 12 illustrates an example method by a network node, according to certain embodiments; and

FIGURE 13 illustrates another example method by a network node, according to certain embodiments.

DETAILED DESCRIPTION

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

In some embodiments, a more general term “network node” may be used and may correspond to any type of radio network node or any network node, which communicates with a UE (directly or via another node) and/or with another network node. Examples of network nodes are NodeB, Master eNodeB (MeNB), a network node belonging to a Master Cell Group (MCG) or Secondary Cell Group (SCG), base station (BS), multi-standard radio (MSR) radio node such as MSR BS, eNodeB (eNB), gNodeB (gNB), network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), core network node (e.g. MSC, Mobility Management Entity (MME), etc.), Operations & Maintenance (O&M), Operations Support System (OSS), Self Optimizing Network (SON), positioning node (e.g. Evolved-Serving Mobile Location Centre (E-SMLC)), Minimization of Drive Test (MDT), test equipment (physical node or software), etc. In some embodiments, the non-limiting term user equipment (UE) or wireless device may be used and may refer to any type of wireless device communicating with a network node and/or with another UE in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine (M2M) communication, Personal Digital Assistant (PDA), Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), Unified Serial Bus (USB) dongles, UE category Ml, UE category M2, Proximity Serves (ProSe) UE, Vehicle-to-Vehicle (V2V) UE, Vehicle-to-Anything (V2X) UE, etc.

Additionally, terminologies such as base station/gNB and UE should be considered non-limiting and do in particular not imply a certain hierarchical relation between the two; in general, “gNB” could be considered as device 1 and “UE” could be considered as device 2 and these two devices communicate with each other over some radio channel. And in the following the transmitter or receiver could be either gNB, or UE.

A detailed analysis of the RA procedure reveals that in general, RA failure may happen due to various reasons including but not limited to:

1. The gNB fails to correctly receive the RA preamble. No RAR is transmitted to the UE (although a RAR may be transmitted in response to one or more other preambles the gNB may have received in the same PRACH occasion).

2. The gNB receives the RA preamble, but does not have the available capacity to respond to it (a backoff indicator may be included in the RAR).

3. The gNB transmits a RAR to the UE, but the UE fails to receive RAR message. a. The UE received nothing after transmitting the RA preamble. b. The UE received at least one downlink scheduling assignment on the Physical Downlink Control Channel (PDCCH) addressed to the RA- RNTI matching the PRACH occasion the UE used for the RA preamble transmission, but the UE failed to decode the actual RAR message on the PDSCH.

4. The UE transmits Msg3 (possibly requiring multiple Hybrid Automatic Repeat Request (HARQ) retransmissions) and receives a Msg4 (contention resolution) in response indicating another UE identifier (UE ID). As used herein, Msg3 refers to a message that the UE sends to the network in response to receiving a random access response message in a 4 step RA procedure. Msg 4 refers to a message that the network node sends to the UE in response to the Msg3. 5. The UE (re)transmits Msg3 a number of times (that may be less than or equal to the maximum number of HARQ retransmissions) and receives no more Negative Acknowledgement (NACK) (i.e. no more uplink (UL) grant with a non-toggled New Data Indicator(NDI)). The gNB has transmitted a maximum number of NACKs (i.e. UL grants with non-toggled NDI), failed to receive the UE’s Msg3 and transmits no Msg4. The UE’s contention resolution timer (ra- ContentionResolutionTimer) expires. a. The UE failed to receive the last NACK(s) from the gNB. b. The UE received all NACKs from the gNB, but the maximum number of HARQ retransmissions was reached (and the gNB still failed to receive Msg3).

6. The UE (re)transmits Msg3 a number of times (that may be less than or equal to the maximum number of HARQ retransmissions) and receives no more NACK (i.e. no more UL grant with a non-toggled NDI). The gNB has received the UE’s Msg3 and transmits a Msg4, but the UE fails to receive it. The UE’s contention resolution timer (ra-ContentionResolutionTimer) expires. a. The UE received nothing at all after transmitting Msg3. b. The UE received at least one downlink scheduling allocation on the PDCCH addressed to the UE’s TC-RNTI after transmitting Msg3 but the UE failed to decode the actual Msg4 on the PDSCH.

To maximize the network’s possibilities to tune and optimize the RA related configurations, the network should ideally obtain information that allows it to distinguish all the above RA failure cases. Most of this information would have to be collected from the UE. As described above, the network receives information related to RA attempts performed by a UE in the RA-Report-r 16 IE (or more specifically in the PerRAInfoList-r 16 IE (containing a list of PerRAInfo-rl6 IES), which can also be included in the ConnEstFailReport-r 16 IE) sent from the UE to the gNB in the UEInformationResponse message in response to a UEInformationRequest message from the gNB. The only parameter in those IEs that aids the network to distinguish between different RA attempt failure cases is the Boolean parameter contentionDetected-r 16, which is set to “true” if the UE received a Msg4 addressed to the UE’s TC-RNTI indicating another UE in the UE Contention Resolution Identity MAC CE or if the UE’s contention resolution timer expires.

If the contentionDetected-r 16 IE is set to “true”, this tells the network that either the UE received a Msg4 addressed to the UE’s TC-RNTI indicating another UE in the UE Contention Resolution Identity MAC CE or the UE’s contention resolution timer expired, which means that the UE did not receive any Msg4 addressed to the UE’s TC-RNTI, or, if the UE was in RRC CONNECTED state when it performed the RA attempt and consequently included its Cell Specific-Radio Network Temporary Identifier (C-RNTI) in Msg3, the UE did not receive any PDCCH transmission addressed to the UE’s C-RNTI. From this, the network can deduce that the UE has experienced either of the failure cases 4, 5. a, 5.b, a or b.

If the contentionDetected-r 16 IE is set to “false” (and the RA attempt failed), this tells the network that the UE did not transmit Msg3, which means that the UE experienced either of failure cases 1, 2, 3. a or 3.b.

Hence, based on the RA related information, the network can obtain from the UE according to the current standard specification (i.e. in the UEInformationRespon.se RRC message), the network can distinguish between two groups of failure cases (i.e. failure cases 1, 2, 3. a and 3.b being one group and failure cases 4, 5. a, 5.b, a or b being another group), but it cannot distinguish between the failure cases within each respective group.

In light of the above detailed problem analysis, there is ample room - and need - for improvements in the provision of information related to RA attempts/procedures performed by a UE to facilitate for the network to distinguish between different RA attempt failure cases, which in turn facilitates for the network to optimize the RA related configurations in order to reduce the future RA failure frequency.

According to certain embodiments, the above described problem(s) are addressed by providing more details in the information provided from a UE to the network regarding RA procedures/attempts performed by the UE. In certain particular embodiments, this extended information may be conveyed to the network in the UEInformationResponse RRC message. More specifically, this extended information (i.e. the additional details, or parameters) may be included in the PerRAAttemptlnfo-r 16 IE r!6 (which via the PerRAAttemptlnfoList-r 16 IE and the PerRASSBInfo-r 16 IE is included in the PerRAInfo- rl6 E).

With reference to the failure cases described above, certain embodiments propose to extend the RA related information provided by the UE to the network to distinguish the failure cases 1, 2, 3. a and 3.b from each other (or at least provide hints that has implications on the probability for the respective failure cases) as well as to distinguish the failure cases 4, 5. a, 5.b, a or b from each other (or at least provide hints that has implications on the probability for the respective failure cases), e.g. included in the PerRAAttemptInfo-rl6 IE. According to certain embodiments, to aid the network to distinguish the failure cases 1, 2, 3. a and 3.b from each other (or at least provide hints that has implications on the probability for the respective failure cases), the UE may provide one or more of the following information items: o An indication of whether the UE, after transmitting the RA preamble, received a RAR addressed (in the DL scheduling allocation on the PDCCH) to the RA-RNTI matching the PRACH occasion the UE used for the RA preamble transmission, which did not include the preamble ID (i.e. the RAPID parameter) associated with the RA preamble the UE transmitted.

■ If the UE did receive such a RAR, the UE may provide an indication of whether the RAR included a Backoff Indicator.

■ As another option, the UE may indicate how many such RARs it received (within the RA response window) and optionally whether each of them, or how many of them, contained a Backoff Indicator. o An indication of whether the UE, after transmitting the RA preamble (and within the RA response window), received at least one DL scheduling allocation addressed to the RA-RNTI matching the PRACH occasion the UE used for its preamble transmission, but failed to decode the actual RAR message on the PDSCH. o An indication of how many times the UE, after transmitting the RA preamble (and within the RA response window), received a DL scheduling allocation addressed to the RA-RNTI matching the PRACH occasion the UE used for its preamble transmission, but failed to decode the actual RAR message on the PDSCH. o Any combination of the above.

In a particular embodiment, the information may be provided in the form of parameters such as, for example, the PerRAAttemptInfo-rl6 IE.

If the information the network receives from the UE indicates a failed RA attempt without detected contention (i.e. failure case 1, 2, 3. a or 3.b) and further indicates at least one successfully received RAR message addressed to the expected RA-RNTI, which included a Backoff Indicator, this increases the probability that the reason for the failure was that the gNB’s RA processing resources were overloaded and could not fully process the UE’s preamble and respond to the UE. If the information the network receives from the UE indicates a failed RA attempt without detected contention (i.e. failure case 1, 2, 3. a or 3.b) and further indicates successfully received RAR message(s) addressed to the expected RA-RNTI, which did not include a Backoff Indicator, this implies that the gNB failed to receive the RA preamble the UE transmitted.

If the information the network receives from the UE indicates a failed RA attempt without detected contention (i.e. failure case 1, 2, 3. a or 3.b) and further indicates that it received nothing of relevance during the RA response window, this implies that there may be a radio channel quality issue which either caused the gNB to fail to detect the RA preamble the UE transmitted or caused the UE to fail to detect and receive a RAR message transmitted by the network. Information about possible subsequent RA attempts, which includes ramping (i.e. increase) of the RA preamble transmit power may shed further light on this and further guide the network’s analysis.

If the information the network receives from the UE indicates a failed RA attempt without detected contention (i.e. failure case 1, 2, 3. a or 3.b) and further indicates that it (during the RA response window) received at least one DL scheduling allocation addressed to the RA-RNTI matching the PRACH occasion the UE used for its preamble transmission, but failed to decode the actual RAR message on the PDSCH, this increases the probability that the failure case was that the gNB successfully received the RA preamble the UE transmitted, but the UE failed to receive the RAR message the gNB sent in response. This in turn implies an increased probability that the failure was caused by downlink radio channel quality problem.

According to certain embodiments, to aid the network in distinguishing the failure cases 4, 5. a, 5. b, a and b from each other (or at least provide hints that has implications on the probability for the respective failure cases), the UE may provide one or more of the following information items: o An indication of whether the UE, after transmitting Msg3, received a Msg4 with a non-matching UE Contention Resolution Identity MAC CE. o An indication of whether the UE, after transmitting Msg3, received nothing relevant and contention resolution timer finally expired. o An indication of whether the UE, after transmitting Msg3 and while the UE’s contention resolution timer was running, received at least one downlink scheduling allocation on the PDCCH addressed to the UE’s TC- RNTI, but failed to decode the actual Msg4 on the PDSCH. o An indication of how many times the UE, after transmitting Msg3 and while the UE’s contention resolution timer was running, received a downlink scheduling allocation on the PDCCH addressed to the UE’s TC-RNTI, but failed to decode the actual Msg4 on the PDSCH.

If the information the network receives from the UE indicates a failed RA attempt with detected contention (i.e. failure case 4, 5. a, 5.b, a or b) and further indicates that after transmitting Msg3 it successfully received a Msg4 addressed to the UE’s TC-RNTI, which included anon-matching UE Contention Resolution Identity MAC CE, this indicates to the network that the failure is caused by preamble collision and failed contention (i.e. failure case 4).

If the information the network receives from the UE indicates a failed RA attempt with detected contention (i.e. failure case 4, 5. a, 5.b, a or b) and further indicates that after transmitting Msg3 the UE received nothing of relevance while the UE’s contention resolution timer was running (i.e. the contention resolution timer eventually expired), this implies, or increases the probability, that the failure was caused by a failure by the gNB to receive Msg3 and that this may have been caused by a radio related problem, such as poor channel quality and/or too low Msg3 transmission power.

If the information the network receives from the UE indicates a failed RA attempt with detected contention (i.e. failure case 4, 5. a, 5.b, a or b) and further indicates that after transmitting Msg3 the UE received at least one downlink scheduling allocation on the PDCCH addressed to the UE’s TC-RNTI, but failed to decode the actual Msg4 on the PDSCH, this implies that the failure may have been caused by downlink radio channel related problems (including e.g. interference, not robust enough MCS and/or too low Msg4 transmission power) and/or that the Msg4 was actually intended for another UE, which successfully received it and returned positive HARQ feedback (ACK) to the gNB (i.e. the root cause may have been a RA preamble collision).

If the UE, instead of a 4-step RA procedure, attempted to use a 2-step RA procedure, the UE can indicate in, for example, the UEInformationRespon.se RRC message, whether the UE, after transmitting MsgA (and within the MsgB window): o received nothing of relevance; or o received at least one downlink scheduling allocation addressed to the MSGB-RNTI matching the PRACH occasion the UE used for the RA preamble transmission, but failed to decode the actual MsgB on the PDSCH (or how many times this happened within the MsgB window); or o received a MsgB addressed to the MSGB-RNTI matching the PRACH occasion the UE used for the RA preamble transmission, where the MsgB neither included a successRAR MAC subPDU with a matching UE Contention Resolution Identity nor a fallbackRAR MAC subPDU with a RAPID field indicating the RA preamble identifier associated with the RA preamble the UE transmitted and where the MsgB did not include a Backoff Indicator; or o received a MsgB addressed to the MSGB-RNTI matching the PRACH occasion the UE used for the RA preamble transmission, where the MsgB neither included a successRAR MAC subPDU with a matching UE Contention Resolution Identity nor a fallbackRAR MAC subPDU with a RAPID field indicating the RA preamble identifier associated with the RA preamble the UE transmitted and where the MsgB included a Backoff Indicator; or o received a MsgB addressed to the MSGB-RNTI matching the PRACH occasion the UE used for the RA preamble transmission, where the MsgB included a fallbackRAR MAC subPDU with a RAPID field indicating the RA preamble identifier associated with the RA preamble the UE transmitted; or o received a MsgB addressed to the MSGB-RNTI matching the PRACH occasion the UE used for the RA preamble transmission, where the MsgB included a successRAR MAC subPDU with a matching UE Contention Resolution Identity.

If the UE indicates within the MsgB window that the UE did receive at least one downlink scheduling allocation addressed to the MSGB-RNTI matching the PRACH occasion the UE used for the RA preamble transmission, but failed to decode the actual MsgB on the PDSCH, this implies an increased probability that the gNB successfully received the RA preamble and possibly also the MsgA transmission on the Physical Uplink Shared Channel (PUSCH). If, on the other hand, the UE indicates that it received nothing of relevance during the duration of the MsgB window, this implies an increased probability that the gNB failed to receive the RA preamble. If the UE indicates that it received a MsgB which neither included a successRAR MAC subPDU with a matching UE Contention Resolution Identity nor a fallbackRAR MAC subPDU with a RAPID field indicating the RA preamble identifier associated with the RA preamble the UE transmitted, but where the MsgB did include a Backoff Indicator, this implies that the failure may have been caused by an overload of the gNB’s MsgA processing resources.

According to certain embodiments, a method at a wireless terminal, which may include a UE, may include, after the transmission of a msg3 (as part of 4-step RACH procedure) or msgA (payload part) as part of 2-step RACH procedure: o Upon detection of failure in transmitting msg3 (or transmitting the payload of msgA, if RACH procedure is a two-step RACH), logging

■ An indication, indicating the failure of the msg3 transmission (or payload part of msgA, if RACH procedure is a two-step RACH). o Maximum number of msg3 HARQ retransmissions without network acknowledgment.

■ The power level used to transmit the msg3 or payload part of msgA,

• In case HARQ retransmissions has been performed for the msg3, the UE includes the power used for the transmission of each HARQ retransmission. In another case, the UE only includes the power used for the first transmission of the msg3, and the TPC commands indicated by the gNB in the DCI for the following retransmission.

■ The pathloss measured when transmitting msg3 (or transmitting msgA, if RACH procedure is a two-step RACH).

• In case HARQ retransmissions has been performed for the msg3, the UE includes the path loss measured before the transmission of each HARQ retransmission. In another case, the UE only includes the path loss if there the change in the path loss measured with respect to the previous transmission is larger than a certain threshold.

■ The number of HARQ retransmissions performed as part of transmitting msg3 (or transmitting msgA, if RACH procedure is a two-step RACH).

■ The number of NACK received as part of HARQ procedure. Upon detection of successful transmission of msg3 (or transmitting the payload of msgA, if RACH procedure is a two-step RACH), logging

■ An indication, indicating the successful transmission of the msg3 transmission,

■ An indication, indicating the failure of decoding the msg4, upon successful transmission of msg3

■ The power level used to transmit the msg3 or payload part of msgA,

■ The number of retransmissions performed as part of transmitting msg3 (or transmitting msgA, if RACH procedure is a two-step RACH).

■ The number of NACK received as part of HARQ procedure. Upon detection of contention resolution failure,

■ An indication, indicating the “cause” of this failure. For example, the UE may indicate that the Contention Resolution was declared not successful because of:

• Receiving a MAC PDU transmitted by the network after the msg3 transmission indicating a UE Contention Resolution Identity MAC CE which did not match the UE identity included in the RRCSetupRequest transmitted as part of the Msg3. • Expiry of the ra-ContentionResolutionTimer

In a particular embodiment, the UE logs the above information for every failed or successful transmission of msg3.

In another particular embodiment, the UE logs the above information for every failed or successful transmission of the payload of the msgA in two step RACH procedure.

In a particular embodiment, UE indicates the frequency related information of the active Bandwidth Part (BWP) used to transmit any kind of msg3 (e.g., RRC Connection Request, or RRC Resume Request, or RRC Reestablishment Request, etc.) or msgA.

In a particular embodiment, UE logs the size of the UL grant provided by the network. For example, the UE logs the modulation and coding scheme used for transmitting the msg3 as well as the transmission block size. These are the configuration UE reads as part of Random Access Response message.

In a particular embodiment, UE logs the information regarding the HARQ procedure configuration including but not limited to o The redundancy version o Automatic Repeat Request-Acknowledgment (ARQ-ACK) codebook determination information o Whether the HARQ was adaptive or non-adaptive o Whether the HARQ was synchronous or asynchronous

Note that all or at least part of the above information can be logged as part of the UE accessibility measurement that is logged as part of failed initial access and connection resume procedure.

According to certain embodiments, the UE may also indicate whether the UE was already in connected mode (in which case the UE included the C-RNTI MAC CE in Msg3), or it was in IDLE mode (in which case the UE included the UE identity in the Common Control Channel Service Data Unit (CCCH SDU) containing the RRCSetupRequesf) when the random access was initiated.

One way to implement the proposed method in the RRC specifications is to create a RACH report containing at least some of the proposed information. The RACH report is included in an UEInformationResponse message:

5.7.10.5 RA information determination for RA report and RLF report

The UE shall set the content in ra-InformationCommon-r 16 as follows: > set the absoluteFrequencyPointA to indicate the absolute frequency of the reference resource block associated to the random-access resources used in the random-access procedure; > set the locationAndBandwidth and subcarrierSpacing associated to the UL BWP of the random-access resources used in the random-access procedure; > set the msgl-FrequencyStart, msgl-FDM and msgl -SubcarrierSpacing associated to the contention based random-access resources used in the random-access procedure; > set the msgl-FrequencyStartCFRA, msgl-FDMCFRA and msgl- SubcarrierSpacingCFRA associated to the contention free random-access resources used in the random-access procedure; > set msg3PathLoss to the path loss value measured for the active UL BWP for transmitting a msg3 based on the DL RS associated with the PRACH transmission on the active DL BWP of serving cell; > set the msg3Failed to indicate whether transmission of msg3 has failed or not; > set the msg3succeed to indicate whether transmission of msg3 has succeeded or not; > set the msgSTransmissionPower to indicate the power transmission used for transmitting msg3; > set the msg3Pathloss to indicate the path loss calculated when transmitting msg3; > set the parameters associated to individual random-access attempt in the chronological order of attempts in the perRAInfoList as follows:

2> if the random-access resource used is associated to a SS/PBCH block, set the associated random-access parameters for the successive randomaccess attempts associated to the same SS/PBCH block for one or more random-access attempts as follows:

3> set the ssb-Index to include the SS/PBCH block index associated to the used random-access resource;

> set the numberOfPreamblesSentOnSSB to indicate the number of successive random-access attempts associated to the SS/PBCH block; 3> for each random-access atempt performed on the random-access resource, include the following parameters in the chronological order of the random-access atempt: 4> if the random-access attempt is performed on the contention based random-access resource and if raPurpose is not equal to 'requestForOtherSI', include contentionDetected as follows:

5> if contention resolution was not successful as specified in TS 38.321 [6] for the transmited preamble:

6> set the contentionDetected to true,'

6> if contention resolution failure was due to expiry of contention resolution timer:

7>set the contentionResolutionFailureCause to contentionResolutionTimer,

6>else:

7>set the contentionDetected to contention,'

5> else:

6> set the contentionDetected to false,'

4> if the random-access attempt is performed on the contention based random-access resource; or

4> if the random-access atempt is performed on the contention free random-access resource and if the random-access procedure was initiated due to the PDCCH ordering:

5> if the SS/PBCH block RSRP of the SS/PBCH block corresponding to the random-access resource used in the random-access attempt is above rsrp-ThresholdSSB'.

6> set the dlRSRPAboveThreshold to true,'

5> else:

6> set the dlRSRPAboveThreshold to false,' > else if the random-access resource used is associated to a CSI-RS, set the associated random-access parameters for the successive randomaccess atempts associated to the same CSI-RS for one or more randomaccess atempts as follows:

3> set the csi-RS-Index to include the CSI-RS index associated to the used random-access resource; 3> set the number OfPr eambles SentOnCSI-RS to indicate the number of successive random-access attempts associated to the CSI-RS.

NOTE 1 : The UE does not log the RA information in the RA report if the triggering event of the random access is consistent UL LBT on SpCell as specified in TS 38.321 [6],

UElnformationResponse

The UElnformationResponse message is used by the UE to transfer the information requested by the NG-RAN.

Signalling radio bearer: SRB1 or SRB2 (when logged measurement information is included)

RLC-SAP: AM

Logical channel: DCCH

Direction: UE to NG-RAN

UElnformationResponse message

According to certain embodiments, the network node may use the RA report information described above as an input for RACH optimization and Coverage and

Capacity Optimization (CCO).

For example, according to certain embodiments, if the network/network node receives frequent RA feedback indicating failure in the transmission of the RA preambles, the network may increase the preamble received target power value or increase the power ramping step.

As another example, according to certain embodiments, if the network/network node receives frequent RA feedback indicating that UE’s may have problems to receive the RAR message, the network may use a more robust Modulation Coding Scheme (MCS) or increase the transmission power for the RAR message. An additional means to improve the probability that RAR messages are successfully received by UEs may be to divide responses to multiple received RA preambles into multiple RAR messages, e.g. responding to one preamble in each RAR message, instead of including multiple responses in the same

RAR message. If this method is used, the network may also consider increasing the size of the RAR reception window. As another example, according to certain embodiments, if the network/network node receives frequent RA feedback that indicates frequent collisions/contentions, this indicates high load on the RACH resources of the cell. The counter action may be to allocate more RACH occasions in the cell or changing the frequency priorities or cell selection priorities in such a way to balance the UE load (offloading the UEs to the other cells). Thus, the network/network node may to allocate more RACH occasions in the cell or changing the frequency priorities or cell selection priorities in response to the RA feedback.

As yet another example, according to certain embodiments, if RA feedback indicates that the measured path loss in the downlink is significantly different from the path loss in the uplink (countable based on the logged transmission power and the uplink measurements), the network/network node may tune the uplink/downlink coverage and mitigate the downlink uplink mismatch if it exists.

As yet another example, according to certain embodiments, if the network/network node receives RA feedback indicating frequent failure of msg3 transmissions, the network can change the MCS assigned for msg3, so the UEs send the msg3 with a more robust MCS. In addition, the network/network node can change the configuration of the msg3 transmission power which is indicated as part of random access response message. In addition, network can tune the preamble received target power or power ramping step to allow transmission at higher power level.

As yet another example, according to certain embodiments, if the network/network node receives RA feedback with frequent indications of successful msg3 transmission, which indicates failure in receiving msg4, the network/network node may change the MCS for transmission of the msg4.

As yet another example, according to certain embodiments, from the indication of the cause of the failure, the network/network node may determine whether the msg3 reception failed because of radio reasons or because of contention resolution issue with other colliding UEs performing random access.

According to certain embodiments, the same optimizations can be applied to the 2- step RACH procedure and concerning parameters, based on the 2-step RA report including the measurements proposed in this disclosure, e.g. increasing the configured transmission power or configuring a more robust MCS for the PUSCH part of MsgA (i.e. MsgA PUSCH). FIGURE 5 illustrates a wireless network, in accordance with some embodiments. Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a wireless network, such as the example wireless network illustrated in FIGURE 5. For simplicity, the wireless network of FIGURE 5 only depicts network 106, network nodes 160 and 160b, and wireless devices 110. In practice, a wireless network may further include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or end device. Of the illustrated components, network node 160 and wireless device 110 are depicted with additional detail. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate the wireless devices’ access to and/or use of the services provided by, or via, the wireless network.

The wireless network may comprise and/or interface with any type of communication, telecommunication, data, cellular, and/or radio network or other similar type of system. In some embodiments, the wireless network may be configured to operate according to specific standards or other types of predefined rules or procedures. Thus, particular embodiments of the wireless network may implement communication standards, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, or 5G standards; wireless local area network (WLAN) standards, such as the IEEE 802.11 standards; and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z- Wave and/or ZigBee standards.

Network 106 may comprise one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTNs), packet data networks, optical networks, wide-area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices.

Network node 160 and wireless device 110 comprise various components described in more detail below. These components work together in order to provide network node and/or wireless device functionality, such as providing wireless connections in a wireless network. In different embodiments, the wireless network may comprise any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, 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.

FIGURE 6 illustrates an example network node 160, according to certain embodiments. As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a wireless device and/or with other network nodes or equipment in the wireless network to enable and/or provide wireless access to the wireless device and/or to perform other functions (e.g., administration) in the wireless 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)). Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and may then also 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). Yet further examples of network nodes include multistandard 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), core network nodes (e.g., MSCs, MMEs), O&M nodes, OSS nodes, SON nodes, positioning nodes (e.g., E-SMLCs), and/or MDTs. As another example, a network node may be a virtual network node as described in more detail below. More generally, however, network nodes may represent any suitable device (or group of devices) capable, configured, arranged, and/or operable to enable and/or provide a wireless device with access to the wireless network or to provide some service to a wireless device that has accessed the wireless network.

In FIGURE 6, network node 160 includes processing circuitry 170, device readable medium 180, interface 190, auxiliary equipment 184, power source 186, power circuitry 187, and antenna 162. Although network node 160 illustrated in the example wireless network of FIGURE 6 may represent a device that includes the illustrated combination of hardware components, other embodiments may comprise network nodes with different combinations of components. It is to be understood that a network node comprises any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Moreover, while the components of network node 160 are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, a network node may comprise multiple different physical components that make up a single illustrated component (e.g., device readable medium 180 may comprise multiple separate hard drives as well as multiple RAM modules).

Similarly, network node 160 may be composed of multiple physically separate components (e.g., aNodeB 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 network node 160 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 NodeB’s. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, network node 160 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate device readable medium 180 for the different RATs) and some components may be reused (e.g., the same antenna 162 may be shared by the RATs). Network node 160 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 160, such as, for example, GSM, WCDMA, LTE, NR, WiFi, 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 160.

Processing circuitry 170 is configured to perform any determining, calculating, or similar operations (e.g., certain obtaining operations) described herein as being provided by a network node. These operations performed by processing circuitry 170 may include processing information obtained by processing circuitry 170 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.

Processing circuitry 170 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 160 components, such as device readable medium 180, network node 160 functionality. For example, processing circuitry 170 may execute instructions stored in device readable medium 180 or in memory within processing circuitry 170. Such functionality may include providing any of the various wireless features, functions, or benefits discussed herein. In some embodiments, processing circuitry 170 may include a system on a chip (SOC).

In some embodiments, processing circuitry 170 may include one or more of radio frequency (RF) transceiver circuitry 172 and baseband processing circuitry 174. In some embodiments, radio frequency (RF) transceiver circuitry 172 and baseband processing circuitry 174 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 172 and baseband processing circuitry 174 may be on the same chip or set of chips, boards, or units.

In certain embodiments, some or all of the functionality described herein as being provided by a network node, base station, eNB or other such network device may be performed by processing circuitry 170 executing instructions stored on device readable medium 180 or memory within processing circuitry 170. In alternative embodiments, some or all of the functionality may be provided by processing circuitry 170 without executing instructions stored on a separate or discrete device readable medium, such as in a hardwired manner. In any of those embodiments, whether executing instructions stored on a device readable storage medium or not, processing circuitry 170 can be configured to perform the described functionality. The benefits provided by such functionality are not limited to processing circuitry 170 alone or to other components of network node 160 but are enjoyed by network node 160 as a whole, and/or by end users and the wireless network generally.

Device readable medium 180 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 processing circuitry 170. Device readable medium 180 may store any suitable instructions, data or information, including a computer program, software, an application including one or more of logic, rules, code, tables, etc. and/or other instructions capable of being executed by processing circuitry 170 and, utilized by network node 160. Device readable medium 180 may be used to store any calculations made by processing circuitry 170 and/or any data received via interface 190. In some embodiments, processing circuitry 170 and device readable medium 180 may be considered to be integrated.

Interface 190 is used in the wired or wireless communication of signalling and/or data between network node 160, network 106, and/or wireless devices 110. As illustrated, interface 190 comprises port(s)/terminal(s) 194 to send and receive data, for example to and from network 106 over a wired connection. Interface 190 also includes radio front end circuitry 192 that may be coupled to, or in certain embodiments a part of, antenna 162. Radio front end circuitry 192 comprises filters 198 and amplifiers 196. Radio front end circuitry 192 may be connected to antenna 162 and processing circuitry 170. Radio front end circuitry may be configured to condition signals communicated between antenna 162 and processing circuitry 170. Radio front end circuitry 192 may receive digital data that is to be sent out to other network nodes or wireless devices via a wireless connection. Radio front end circuitry 192 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 198 and/or amplifiers 196. The radio signal may then be transmitted via antenna 162. Similarly, when receiving data, antenna 162 may collect radio signals which are then converted into digital data by radio front end circuitry 192. The digital data may be passed to processing circuitry 170. In other embodiments, the interface may comprise different components and/or different combinations of components.

In certain alternative embodiments, network node 160 may not include separate radio front end circuitry 192, instead, processing circuitry 170 may comprise radio front end circuitry and may be connected to antenna 162 without separate radio front end circuitry 192. Similarly, in some embodiments, all or some of RF transceiver circuitry 172 may be considered a part of interface 190. In still other embodiments, interface 190 may include one or more ports or terminals 194, radio front end circuitry 192, and RF transceiver circuitry 172, as part of a radio unit (not shown), and interface 190 may communicate with baseband processing circuitry 174, which is part of a digital unit (not shown). Antenna 162 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. Antenna 162 may be coupled to radio front end circuitry 192 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In some embodiments, antenna 162 may comprise one or more omni-directional, sector or panel antennas operable to transmit/receive radio signals between, for example, 2 GHz and 66 GHz. An omni-directional antenna may be used to transmit/receive radio signals in any direction, a sector antenna may be used to transmit/receive radio signals from devices within a particular area, and a panel antenna may be a line of sight antenna used to transmit/receive radio signals in a relatively straight line. In some instances, the use of more than one antenna may be referred to as MIMO. In certain embodiments, antenna 162 may be separate from network node 160 and may be connectable to network node 160 through an interface or port.

Antenna 162, interface 190, and/or processing circuitry 170 may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by a network node. Any information, data and/or signals may be received from a wireless device, another network node and/or any other network equipment. Similarly, antenna 162, interface 190, and/or processing circuitry 170 may be configured to perform any transmitting operations described herein as being performed by a network node. Any information, data and/or signals may be transmitted to a wireless device, another network node and/or any other network equipment.

Power circuitry 187 may comprise, or be coupled to, power management circuitry and is configured to supply the components of network node 160 with power for performing the functionality described herein. Power circuitry 187 may receive power from power source 186. Power source 186 and/or power circuitry 187 may be configured to provide power to the various components of network node 160 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). Power source 186 may either be included in, or external to, power circuitry 187 and/or network node 160. For example, network node 160 may be connectable to an external power source (e.g., an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry 187. As a further example, power source 186 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry 187. The battery may provide backup power should the external power source fail. Other types of power sources, such as photovoltaic devices, may also be used. Alternative embodiments of network node 160 may include additional components beyond those shown in FIGURE 6 that may be responsible 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, network node 160 may include user interface equipment to allow input of information into network node 160 and to allow output of information from network node 160. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for network node 160.

FIGURE 7 illustrates an example wireless device 110. According to certain embodiments. As used herein, wireless device refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other wireless devices. Unless otherwise noted, the term wireless device may be used interchangeably herein with user equipment (UE). Communicating wirelessly may involve transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information through air. In some embodiments, a wireless device may be configured to transmit and/or receive information without direct human interaction. For instance, a wireless device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the network. Examples of a wireless device include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless cameras, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a smart device, a wireless customer-premise equipment (CPE), a vehicle-mounted wireless terminal device, etc. A wireless device may support device-to- device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to- everything (V2X) and may in this case be referred to as a D2D communication device. As yet another specific example, in an Internet of Things (loT) scenario, a wireless device 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 wireless device and/or a network node. The wireless device may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the wireless device may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances (e.g. refrigerators, televisions, etc.) personal wearables (e.g., watches, fitness trackers, etc.). In other scenarios, a wireless device may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. A wireless device as described above may represent the endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Furthermore, a wireless device as described above may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal.

As illustrated, wireless device 110 includes antenna 111, interface 114, processing circuitry 120, device readable medium 130, user interface equipment 132, auxiliary equipment 134, power source 136 and power circuitry 137. Wireless device 110 may include multiple sets of one or more of the illustrated components for different wireless technologies supported by wireless device 110, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, just to mention a few. These wireless technologies may be integrated into the same or different chips or set of chips as other components within wireless device 110.

Antenna 111 may include one or more antennas or antenna arrays, configured to send and/or receive wireless signals, and is connected to interface 114. In certain alternative embodiments, antenna 111 may be separate from wireless device 110 and be connectable to wireless device 110 through an interface or port. Antenna 111, interface 114, and/or processing circuitry 120 may be configured to perform any receiving or transmitting operations described herein as being performed by a wireless device. Any information, data and/or signals may be received from a network node and/or another wireless device. In some embodiments, radio front end circuitry and/or antenna 111 may be considered an interface.

As illustrated, interface 114 comprises radio front end circuitry 112 and antenna 111. Radio front end circuitry 112 comprise one or more filters 118 and amplifiers 116. Radio front end circuitry 112 is connected to antenna 111 and processing circuitry 120 and is configured to condition signals communicated between antenna 111 and processing circuitry 120. Radio front end circuitry 112 may be coupled to or a part of antenna 111. In some embodiments, wireless device 110 may not include separate radio front end circuitry 112; rather, processing circuitry 120 may comprise radio front end circuitry and may be connected to antenna 111. Similarly, in some embodiments, some or all of RF transceiver circuitry 122 may be considered a part of interface 114. Radio front end circuitry 112 may receive digital data that is to be sent out to other network nodes or wireless devices via a wireless connection. Radio front end circuitry 112 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 118 and/or amplifiers 116. The radio signal may then be transmitted via antenna 111. Similarly, when receiving data, antenna 111 may collect radio signals which are then converted into digital data by radio front end circuitry 112. The digital data may be passed to processing circuitry 120. In other embodiments, the interface may comprise different components and/or different combinations of components.

Processing circuitry 120 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 wireless device 110 components, such as device readable medium 130, wireless device 110 functionality. Such functionality may include providing any of the various wireless features or benefits discussed herein. For example, processing circuitry 120 may execute instructions stored in device readable medium 130 or in memory within processing circuitry 120 to provide the functionality disclosed herein.

As illustrated, processing circuitry 120 includes one or more of RF transceiver circuitry 122, baseband processing circuitry 124, and application processing circuitry 126. In other embodiments, the processing circuitry may comprise different components and/or different combinations of components. In certain embodiments processing circuitry 120 of wireless device 110 may comprise a SOC. In some embodiments, RF transceiver circuitry 122, baseband processing circuitry 124, and application processing circuitry 126 may be on separate chips or sets of chips. In alternative embodiments, part or all of baseband processing circuitry 124 and application processing circuitry 126 may be combined into one chip or set of chips, and RF transceiver circuitry 122 may be on a separate chip or set of chips. In still alternative embodiments, part or all of RF transceiver circuitry 122 and baseband processing circuitry 124 may be on the same chip or set of chips, and application processing circuitry 126 may be on a separate chip or set of chips. In yet other alternative embodiments, part or all of RF transceiver circuitry 122, baseband processing circuitry 124, and application processing circuitry 126 may be combined in the same chip or set of chips. In some embodiments, RF transceiver circuitry 122 may be a part of interface 114. RF transceiver circuitry 122 may condition RF signals for processing circuitry 120.

In certain embodiments, some or all of the functionality described herein as being performed by a wireless device may be provided by processing circuitry 120 executing instructions stored on device readable medium 130, which in certain embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by processing circuitry 120 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 device readable storage medium or not, processing circuitry 120 can be configured to perform the described functionality. The benefits provided by such functionality are not limited to processing circuitry 120 alone or to other components of wireless device 110, but are enjoyed by wireless device 110 as a whole, and/or by end users and the wireless network generally.

Processing circuitry 120 may be configured to perform any determining, calculating, or similar operations (e.g., certain obtaining operations) described herein as being performed by a wireless device. These operations, as performed by processing circuitry 120, may include processing information obtained by processing circuitry 120 by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored by wireless device 110, 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.

Device readable medium 130 may be operable to store a computer program, software, an application including one or more of logic, rules, code, tables, etc. and/or other instructions capable of being executed by processing circuitry 120. Device readable medium 130 may include computer memory (e.g., Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (e.g., a hard disk), removable storage media (e.g., 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 processing circuitry 120. In some embodiments, processing circuitry 120 and device readable medium 130 may be considered to be integrated. User interface equipment 132 may provide components that allow for a human user to interact with wireless device 110. Such interaction may be of many forms, such as visual, audial, tactile, etc. User interface equipment 132 may be operable to produce output to the user and to allow the user to provide input to wireless device 110. The type of interaction may vary depending on the type of user interface equipment 132 installed in wireless device 110. For example, if wireless device 110 is a smart phone, the interaction may be via a touch screen; if wireless device 110 is a smart meter, the interaction may be through a screen that provides usage (e.g., the number of gallons used) or a speaker that provides an audible alert (e.g., if smoke is detected). User interface equipment 132 may include input interfaces, devices and circuits, and output interfaces, devices and circuits. User interface equipment 132 is configured to allow input of information into wireless device 110 and is connected to processing circuitry 120 to allow processing circuitry 120 to process the input information. User interface equipment 132 may include, for example, a microphone, a proximity or other sensor, keys/buttons, a touch display, one or more cameras, a USB port, or other input circuitry. User interface equipment 132 is also configured to allow output of information from wireless device 110, and to allow processing circuitry 120 to output information from wireless device 110. User interface equipment 132 may include, for example, a speaker, a display, vibrating circuitry, a USB port, a headphone interface, or other output circuitry. Using one or more input and output interfaces, devices, and circuits, of user interface equipment 132, wireless device 110 may communicate with end users and/or the wireless network and allow them to benefit from the functionality described herein.

Auxiliary equipment 134 is operable to provide more specific functionality which may not be generally performed by wireless devices. This may comprise specialized sensors for doing measurements for various purposes, interfaces for additional types of communication such as wired communications etc. The inclusion and type of components of auxiliary equipment 134 may vary depending on the embodiment and/or scenario.

Power source 136 may, in some embodiments, be in the form of a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic devices or power cells, may also be used, wireless device 110 may further comprise power circuitry 137 for delivering power from power source 136 to the various parts of wireless device 110 which need power from power source 136 to carry out any functionality described or indicated herein. Power circuitry 137 may in certain embodiments comprise power management circuitry. Power circuitry 137 may additionally or alternatively be operable to receive power from an external power source; in which case wireless device 110 may be connectable to the external power source (such as an electricity outlet) via input circuitry or an interface such as an electrical power cable. Power circuitry 137 may also in certain embodiments be operable to deliver power from an external power source to power source 136. This may be, for example, for the charging of power source 136. Power circuitry 137 may perform any formatting, converting, or other modification to the power from power source 136 to make the power suitable for the respective components of wireless device 110 to which power is supplied.

FIGURE 8 illustrates one embodiment of a UE in accordance with various aspects described herein. As used herein, a user equipment or 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). UE 200 may be any UE identified by the 3^rd Generation Partnership Project (3GPP), including a NB-IoT UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE. UE 200, as illustrated in FIGURE 6, is one example of a wireless device configured for communication in accordance with one or more communication standards promulgated by the 3^rd Generation Partnership Project (3GPP), such as 3GPP’s GSM, UMTS, LTE, and/or 5G standards. As mentioned previously, the term wireless device and UE may be used interchangeable. Accordingly, although FIGURE 8 is a UE, the components discussed herein are equally applicable to a wireless device, and vice-versa.

In FIGURE 8, UE 200 includes processing circuitry 201 that is operatively coupled to input/output interface 205, radio frequency (RF) interface 209, network connection interface 211, memory 215 including random access memory (RAM) 217, read-only memory (ROM) 219, and storage medium 221 or the like, communication subsystem 231, power source 233, and/or any other component, or any combination thereof. Storage medium 221 includes operating system 223, application program 225, and data 227. In other embodiments, storage medium 221 may include other similar types of information. Certain UEs may utilize all of the components shown in FIGURE 8, or only a subset of the components. 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.

In FIGURE 8, processing circuitry 201 may be configured to process computer instructions and data. Processing circuitry 201 may be configured to implement any sequential state machine operative to execute machine instructions stored as machine- readable computer programs in the memory, such as one or more hardware-implemented state machines (e.g., in discrete logic, FPGA, ASIC, etc.); programmable logic together with appropriate firmware; one or more stored program, 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 201 may include two central processing units (CPUs). Data may be information in a form suitable for use by a computer.

In the depicted embodiment, input/output interface 205 may be configured to provide a communication interface to an input device, output device, or input and output device. UE 200 may be configured to use an output device via input/output interface 205. An output device may use the same type of interface port as an input device. For example, a USB port may be used to provide input to and output from UE 200. The output device may be 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. UE 200 may be configured to use an input device via input/ output interface 205 to allow a user to capture information into UE 200. The input device may include a touch-sensitive or presencesensitive 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, another like sensor, or any combination thereof. For example, the input device may be an accelerometer, a magnetometer, a digital camera, a microphone, and an optical sensor.

In FIGURE 8, RF interface 209 may be configured to provide a communication interface to RF components such as a transmitter, a receiver, and an antenna. Network connection interface 211 may be configured to provide a communication interface to network 243a. Network 243a may encompass wired and/or wireless networks such as a local-area network (LAN), a wide-area network (WAN), a computer network, a wireless network, a telecommunications network, another like network or any combination thereof. For example, network 243a may comprise a Wi-Fi network. Network connection interface 211 may be configured to include a receiver and a transmitter interface used to communicate with one or more other devices over a communication network according to one or more communication protocols, such as Ethernet, TCP/IP, SONET, ATM, or the like. Network connection interface 211 may implement receiver and transmitter functionality appropriate to the communication network links (e.g., optical, electrical, and the like). The transmitter and receiver functions may share circuit components, software or firmware, or alternatively may be implemented separately.

RAM 217 may be configured to interface via bus 202 to processing circuitry 201 to provide storage or caching of data or computer instructions during the execution of software programs such as the operating system, application programs, and device drivers. ROM 219 may be configured to provide computer instructions or data to processing circuitry 201. For example, ROM 219 may be configured to store invariant low-level system code or data for basic system functions such as basic input and output (I/O), startup, or reception of keystrokes from a keyboard that are stored in a non-volatile memory. Storage medium 221 may be configured to include memory such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, floppy disks, hard disks, removable cartridges, or flash drives. In one example, storage medium 221 may be configured to include operating system 223, application program 225 such as a web browser application, a widget or gadget engine or another application, and data file 227. Storage medium 221 may store, for use by UE 200, any of a variety of various operating systems or combinations of operating systems.

Storage medium 221 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), floppy disk drive, 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 a subscriber identity module or a removable user identity (SIM/RUIM) module, other memory, or any combination thereof. Storage medium 221 may allow UE 200 to access computerexecutable instructions, application programs or 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 in storage medium 221, which may comprise a device readable medium.

In FIGURE 8, processing circuitry 201 may be configured to communicate with network 243b using communication subsystem 231. Network 243a and network 243b may be the same network or networks or different network or networks. Communication subsystem 231 may be configured to include one or more transceivers used to communicate with network 243b. For example, communication subsystem 231 may be configured to include one or more transceivers used to communicate with one or more remote transceivers of another device capable of wireless communication such as another wireless device, UE, or base station of a radio access network (RAN) according to one or more communication protocols, such as IEEE 802.2, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, or the like. Each transceiver may include transmitter 233 and/or receiver 235 to implement transmitter or receiver functionality, respectively, appropriate to the RAN links (e.g., frequency allocations and the like). Further, transmitter 233 and receiver 235 of each transceiver may share circuit components, software or firmware, or alternatively may be implemented separately.

In the illustrated embodiment, the communication functions of communication subsystem 231 may include 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. For example, communication subsystem 231 may include cellular communication, Wi-Fi communication, Bluetooth communication, and GPS communication. Network 243b may encompass wired and/or wireless networks such as a local-area network (LAN), a wide-area network (WAN), a computer network, a wireless network, a telecommunications network, another like network or any combination thereof. For example, network 243b may be a cellular network, a Wi-Fi network, and/or a near- field network. Power source 213 may be configured to provide alternating current (AC) or direct current (DC) power to components of UE 200.

The features, benefits and/or functions described herein may be implemented in one of the components of UE 200 or partitioned across multiple components of UE 200. Further, the features, benefits, and/or functions described herein may be implemented in any combination of hardware, software or firmware. In one example, communication subsystem 231 may be configured to include any of the components described herein. Further, processing circuitry 201 may be configured to communicate with any of such components over bus 202. In another example, any of such components may be represented by program instructions stored in memory that when executed by processing circuitry 201 perform the corresponding functions described herein. In another example, the functionality of any of such components may be partitioned between processing circuitry 201 and communication subsystem 231. In another example, the non- computationally intensive functions of any of such components may be implemented in software or firmware and the computationally intensive functions may be implemented in hardware.

FIGURE 9 is a schematic block diagram illustrating a virtualization environment 300 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 a node (e.g., a virtualized base station or a virtualized radio access node) or to a device (e.g., a UE, a wireless device or any other type of communication device) 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 (e.g., via one or more applications, components, functions, virtual machines or containers executing on one or more physical processing nodes in one or more networks).

In some embodiments, some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments 300 hosted by one or more of hardware nodes 330. Further, in embodiments in which the virtual node is not a radio access node or does not require radio connectivity (e.g., a core network node), then the network node may be entirely virtualized.

The functions may be implemented by one or more applications 320 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operative to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein. Applications 320 are run in virtualization environment 300 which provides hardware 330 comprising processing circuitry 360 and memory 390. Memory 390 contains instructions 395 executable by processing circuitry 360 whereby application 320 is operative to provide one or more of the features, benefits, and/or functions disclosed herein.

Virtualization environment 300, comprises general-purpose or special-purpose network hardware devices 330 comprising a set of one or more processors or processing circuitry 360, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuitry including digital or analog hardware components or special purpose processors. Each hardware device may comprise memory 390-1 which may be non-persistent memory for temporarily storing instructions 395 or software executed by processing circuitry 360. Each hardware device may comprise one or more network interface controllers (NICs) 370, also known as network interface cards, which include physical network interface 380. Each hardware device may also include non-transitory, persistent, machine-readable storage media 390-2 having stored therein software 395 and/or instructions executable by processing circuitry 360. Software 395 may include any type of software including software for instantiating one or more virtualization layers 350 (also referred to as hypervisors), software to execute virtual machines 340 as well as software allowing it to execute functions, features and/or benefits described in relation with some embodiments described herein.

Virtual machines 340, comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 350 or hypervisor. Different embodiments of the instance of virtual appliance 320 may be implemented on one or more of virtual machines 340, and the implementations may be made in different ways.

During operation, processing circuitry 360 executes software 395 to instantiate the hypervisor or virtualization layer 350, which may sometimes be referred to as a virtual machine monitor (VMM). Virtualization layer 350 may present a virtual operating platform that appears like networking hardware to virtual machine 340.

As shown in FIGURE 9, hardware 330 may be a standalone network node with generic or specific components. Hardware 330 may comprise antenna 3225 and may implement some functions via virtualization. Alternatively, hardware 330 may be part of a larger cluster of hardware (e.g. such as in a data center or customer premise equipment (CPE)) where many hardware nodes work together and are managed via management and orchestration (MANO) 3100, which, among others, oversees lifecycle management of applications 320. 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.

In the context of NFV, virtual machine 340 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, nonvirtualized machine. Each of virtual machines 340, and that part of hardware 330 that executes that virtual machine, be it hardware dedicated to that virtual machine and/or hardware shared by that virtual machine with others of the virtual machines 340, forms a separate virtual network elements (VNE).

Still in the context of NFV, Virtual Network Function (VNF) is responsible for handling specific network functions that run in one or more virtual machines 340 on top of hardware networking infrastructure 330 and corresponds to application 320 in FIGURE 12.

In some embodiments, one or more radio units 3200 that each include one or more transmitters 3220 and one or more receivers 3210 may be coupled to one or more antennas 3225. Radio units 3200 may communicate directly with hardware nodes 330 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 affected with the use of control system 3230 which may alternatively be used for communication between the hardware nodes 330 and radio units 3200.

FIGURE 10 depicts a method 1000 by a wireless device 110, according to certain embodiments. At step 1002, the wireless device performs at least one operation associated with a Random Access Channel (RACH) procedure. At step 1004, the wireless device logs Random Access (RA) related information associated with the at least one operation associated with the RACH procedure. At step 1006, the wireless device transmits, to a network node 160, the RA related information associated with the at least one operation.

FIGURE 11 depicts another method 1200 by a wireless device 110, according to certain embodiments. At step 1202, the wireless device 110 transmits, to a network node 160, a first PUSCH message of a RA procedure. At step 1204, the wireless device 110 transmits, to the network node 160, RA related information associated with the transmission of the first PUSCH message of the RA procedure. In a particular embodiment, the RA related information comprises pathloss information associated with the transmission of the first PUSCH message.

In a particular embodiment, the RA related information comprises an indication of a reason or cause of a contention resolution failure.

In a further particular embodiment, the indication of the reason or the cause of the contention resolution failure is indicative of at least one of: an expiration of a contention resolution timer; and an occurred contention when a contention resolution identity does not match with an identity of the wireless device as included in the first PUSCH message.

In a particular embodiment, the wireless device 110 logs the RA related information associated with the transmission of the first PUSCH message of the RA procedure.

In a particular embodiment, the first PUSCH message is transmitted during a first step of the RA procedure.

In a particular embodiment, the RA procedure comprises a two-step RA procedure, and a msgA includes the first PUSCH message.

In a particular embodiment, the RA procedure comprises a four-step RA procedure, and a msg3 includes the first PUSCH message. As used herein, the term msg3 refers to a message UE sends to the network in response to receiving a random access response message in a 4 step RA procedure.

In a particular embodiment, the wireless device 110 detects a failure associated with the transmission of the first PUSCH message, and wherein the RA related information comprises at least one of: an indication of the failure associated with the transmission of the first PUSCH message; an indication of a maximum number of transmissions of the first PUSCH message; a number of HARQ retransmissions associated with the first PUSCH message; a number of NACKs received after transmitting the first PUSCH message; a cause of the failure associated with the transmission of the first PUSCH message; a power level associated with the transmission of the first PUSCH message; a power level associated with each retransmission of the first PUSCH message; a pathloss measured when transmitting the first PUSCH message; and a pathloss measured before transmitting each retransmission of the first PUSCH message.

In a particular embodiment, the wireless device 110 detects that the transmission of the first PUSCH message was successful, and the RA related information comprises at least one of: an indication of the successful transmission of the first PUSCH message; an indication of a failure to decode a second message received after transmitting the first PUSCH message; a number of HARQ retransmissions associated with the first PUSCH message; a number of NACKs received after transmiting the first PUSCH message; a power level associated with the transmission of the first PUSCH message; a power level associated with each retransmission of the first PUSCH message; a pathloss measured when transmiting the first PUSCH message; and a pathloss measured before transmiting each retransmission of the first PUSCH message.

In a particular embodiment, the wireless device 110 monitors a channel for a response message from the network node after the transmission of the first PUSCH message, and a determination of a failure or a success of the transmission of the first PUSCH message is based on whether the response message is received after the transmission of the first PUSCH message.

In a further particular embodiment, the RA related information comprises at least one of: an indication of whether the response message was received; an indication of whether the response message included a backoff indicator; an indication of a number of response messages received; an indication of a number of response messages received that included a backoff indicator; an indication of whether, in response to transmiting the first PUSCH message, the wireless device received at least one downlink scheduling allocation within a response window; and an indication of a number of times, after transmiting the first PUSCH message, that the wireless device received at least one downlink scheduling allocation within a response window.

In a particular embodiment, the RA related information comprises at least one of: an indication of whether the wireless device is in a connected mode or an idle mode when the RA procedure was initiated; a size of an uplink grant provided by the network node; a modulation and coding scheme used for transmitting the first PUSCH message associated with the RA procedure; a transmission block size used for transmiting the first PUSCH message associated with the RA procedure; a redundancy version associated with a HARQ procedure configuration; information associated with determining a codebook; an indication of whether a HARQ procedure is adaptive or non-adaptive; and an indication of whether a HARQ procedure is synchronous or asynchronous.

FIGURE 12 depicts a method 1400 by a network node 160, according to certain embodiments. At step 1402, the network node receives, from a wireless device 110, RA related information associated with the at least one operation performed by the wireless device during the performance of a RACH procedure. Optionally, at step 1404, the network node 160 may perform at least one action based on the RA related information. For example, in a particular embodiment, when performing the at least one action, the network node may adapt at least one parameter associated with the RACH procedure.

FIGURE 13 depicts another method 1600 by a network node 160, according to certain embodiments. At step 1602, the network node 160 receives, from a wireless device 110, RA, related information associated with a transmission of a first PUSCH message of a RA procedure.

In a particular embodiment, the network node 160 adapts at least one parameter associated with the RA procedure based on the RA related information.

In a further particular embodiment, adapting the at least one parameter associated with the RA procedure comprises at least one of: adapting a modulation and coding scheme for transmitting a RACH related message to the wireless device; adapting a target power value or power ramping step; adapting a transmission power for transmitting a RACH related message to the wireless device; transmitting a plurality of RACH related messages associated with a plurality of RA preambles to the wireless device; increasing a size of a RAR window; allocating more RACH occasions; changing at least one frequency priority or cell selection priority; adapt uplink and/or downlink coverage; adapt a modulation and coding scheme for the wireless device; adapt a transmission power for the wireless device; and adapt a preamble received target power or power ramping step for the wireless device.

In a particular embodiment, the network node 160 transmits, to the wireless device 110, a message comprising an indication of the at least one parameter associated with the RA procedure that is adapted based on the RA related information.

In a particular embodiment, the RA related information comprises pathloss information associated with the transmission of the first PUSCH message.

In a particular embodiment, the RA procedure comprises a two-step RA procedure, and a msgA includes the first PUSCH message. In a particular embodiment, the RA procedure comprises a four-step RA procedure, and a msg3 includes the first PUSCH message.

In a particular embodiment, the RA related information comprises at least one of: an indication of a failure associated with the transmission of the first PUSCH message; an indication of a successful transmission of the first PUSCH message; an indication of a failure to decode a message received after transmitting the first PUSCH message; an indication of a maximum number of transmissions of the first PUSCH message; a number of HARQ retransmissions associated with the first PUSCH message; a number of NACKs received after transmitting the first PUSCH message; a cause of the failure associated with the transmission of the first PUSCH message; a power level associated with the transmission of the first PUSCH message; a power level associated with each retransmission of the first PUSCH message; a pathloss measured when transmitting the first PUSCH message; a pathloss measured before transmitting each retransmission of the first PUSCH message; an indication of whether a response message was received; an indication of whether a response message included a backoff indicator; an indication of a number of response messages received; an indication of a number of response messages received that included a backoff indicator; an indication of whether, in response to transmitting the first PUSCH message, the wireless device received at least one downlink scheduling allocation within a response window; and an indication of a number of times, after transmitting the first PUSCH message, that the wireless device received at least one downlink scheduling allocation within a response window.

In a particular embodiment, the RA related information is received via a UEInformationRespon.se RRC message.

In a particular embodiment, the RA related information associated with the at least one operation is transmitted to the network node in a PerRAAttemptInfoList-rl6 Information Element or a PerRASSBInfo-Rl 6 Information Element.

In a particular embodiment, the RA related information comprises at least one of: an indication of whether the wireless device is in a connected mode or an idle mode when the RA procedure was initiated; a size of an uplink grant provided by the network node; a modulation and coding scheme used for transmitting, by the wireless device, a message associated with the RA procedure; a transmission block size used for transmitting, by the wireless device, a message associated with the RA procedure; a redundancy version associated with a HARQ procedure configuration; information associated with determining, by the wireless device, a AEQ-ACK codebook; an indication of whether a HARQ procedure is adaptive or non-adaptive; and an indication of whether a HARQ procedure is synchronous or asynchronous.

EXAMPLE EMBODIMENTS

The following are example embodiments of the present disclosure.

Example Embodiment Al. A method by a wireless device comprising: performing at least one operation associated with a Random Access Channel (RACH) procedure; logging Random Access (RA) related information associated with the at least one operation associated with the RACH procedure; and transmitting, to a network node, the RA related information associated with the at least one operation.

Example Embodiment A2. The method of Example Embodiment Al, wherein: the RACH procedure comprises a four step RACH procedure; and performing the at least one operation comprises transmitting a msg3 to the network node.

Example Embodiment A3. The method of Example Embodiment A2, further comprising detecting that a failure associated with a transmission of the msg3, and wherein the RA related information comprises at least one of: an indication of the failure associated with the transmission of the msg3; an indication of a maximum number of transmissions of the msg3; a number of Hybrid Automatic Repeat Request (HARQ) retransmissions associated with the msg3; a number of NACKs received after transmitting the msg3; a cause of the failure associated with the transmission of the msg3; a power level associated with the transmission of the msg3; a power level associated with each retransmission of the msg3; a pathloss measured when transmitting the msg3; and a pathloss measured before transmitting each retransmission of the msg3.

Example Embodiment A4. The method of Example Embodiment A2, further comprising detecting that a transmission of the msg3 was successful, and wherein the RA related information comprises at least one of: an indication of the successful transmission of the msg3; an indication of a failure to decode a msg4 received after transmitting the msg3; a number of Hybrid Automatic Repeat Request (HARQ) retransmissions associated with the msg3; a number of NACKs received after transmitting the msg3; a power level associated with the transmission of the msg3; a power level associated with each retransmission of the msg3; a pathloss measured when transmitting the msg3; and a pathloss measured before transmitting each retransmission of the msg3.

Example Embodiment A5a. The method of Example Embodiment A3 or A4, further comprising monitoring a channel for a response message from the network node after the transmission of the msg3, and wherein the failure or the successful transmission of the msg3 is determined based on whether the response message is received after the transmission of the msg3.

Example Embodiment A5b. The method of Example Embodiment A5a, wherein the RA related information comprises at least one of: an indication of whether the response message was received; an indication of whether the response message included a backoff indicator; an indication of a number of response messages received; an indication of a number of response messages received that included a backoff indicator; an indication of whether, in response to transmitting the msg3, the wireless device received at least one downlink scheduling allocation within a response window; and an indication of a number of times, after transmitting the msg3, that the wireless device received at least one downlink scheduling allocation within a response window.

Example Embodiment A6. The method of any one of Example Embodiments A2 to A3 and A5a to A5b, further comprising detecting a contention resolution failure after a successful transmission of the msg3, and wherein the RA related information comprises an indication of a reason or cause of the contention resolution failure.

Example Embodiment A7. The method of Example Embodiment A6, wherein the indication of the reason or the cause of the contention resolution failure comprises at least one of: an expiration of a contention resolution timer; and an occurred contention when a contention resolution identity does not match with an identity of the wireless device as included in the msg3.

Example Embodiment A8. The method of Example Embodiment Al, wherein: the RACH procedure comprises a two-step RACH procedure; and performing the at least one operation comprises transmitting a payload portion of a msgA to the network node.

Example Embodiment A9. The method of Example Embodiment A8, further comprising detecting that a failure associated with a transmission of the msgA, and wherein the RA related information comprises at least one of: an indication of the failure associated with the transmission of the payload portion of the msgA; an indication of a maximum number of transmissions of the msgA; a number of Hybrid Automatic Repeat Request (HARQ) retransmissions associated with the msgA; a number of NACKs received after transmitting the msgA; a cause of the failure associated with the transmission of the payload portion of the msgA; a power level associated with the transmission of the payload portion of the msgA; a power level associated with each retransmission of the payload portion of the msgA; a pathloss measured when transmitting the payload portion of the msgA; and a pathloss measured before transmitting each retransmission of the payload portion of the msgA.

Example Embodiment Al 0 The method of Example Embodiment A8, further comprising detecting that a transmission of the payload portion of the msgA was successful, and wherein the RA related information comprises at least one of: an indication of the successful transmission of the payload portion of the msgA; a number of Hybrid Automatic Repeat Request (HARQ) retransmissions associated with the msgA; a number of NACKs received after transmitting the payload portion of the msgA; a power level associated with the transmission of the payload portion of the msgA; a power level associated with each retransmission of the payload portion of the msgA; a pathloss measured when transmitting the payload portion of the msgA; and a pathloss measured before transmitting each retransmission of the pay load portion of the msgA.

Example Embodiment Al 1 a. The method of Example Embodiment A9 or Al 0, further comprising monitoring a channel for a response message from the network node after the transmission of the msgA, and wherein the failure or the successful transmission of the msgA is determined based on whether the response message is received after the transmission of the msgA.

Example Embodiment Al lb. The method of Example Embodiment Al la, wherein the RA related information comprises at least one of: an indication of whether the response message was received; an indication of whether the response message included a backoff indicator; an indication of a number of response messages received; and an indication of a number of response messages received that included a backoff indicator; an indication of whether, in response to transmitting the payload portion of the msgA, the wireless device received at least one downlink scheduling allocation within a response window; and an indication of a number of times, after transmitting the payload portion of the msgA, that the wireless device received at least one downlink scheduling allocation within a response window.

Example Embodiment A12. The method of any one of Example Embodiments A8 to A9 and Alla to Al lb, further comprising detecting a contention resolution failure after a successful transmission of the payload portion of the msgA, and wherein the RA related information comprises an indication of a reason or cause of the contention resolution failure.

Example Embodiment Al 3. The method of Example Embodiment Al 2, wherein the indication of the reason or the cause of the contention resolution failure comprises at least one of: an expiration of a contention resolution timer; and an occurred contention when a contention resolution identity does not match with an identity of the wireless device as included in the msgA.

Example Embodiment A14. The method of any one of Example Embodiments Al to A13, wherein the RA related information associated with the at least one operation is transmitted to the network node via a UEInformationRespon.se Radio Resource Control (RRC) message.

Example Embodiment Al 5. The method of any one of Example Embodiment

A14, wherein the RA related information associated with the at least one operation is transmitted to the network node in a PerRAAttemptlnfoList-r 16 Information Element or a PerRASSBInfo-R16 Information Element.

Example Embodiment Al 6. The method of any one of Example Embodiments 1 to Al 5, wherein logging the RA related information comprises logging information associated with every failed and/or successful performance of the at least one operation.

Example Embodiment A17. The method of any one of Example Embodiments Al to A15, wherein logging the RA related information comprises logging information associated with only a first performance or first attempted performance of the at least one operation.

Example Embodiment Al 8. The method of any one of Example Embodiments Al to Al 7, wherein the RA related information comprises frequency related information of an active bandwidth part used to transmit a message associated with the RACH procedure.

Example Embodiment Al 9. The method of any one of Example Embodiments Al to Al 8, wherein the RA related information comprises at least one of: an indication of whether the wireless device is in a connected mode or an idle mode when the RACH procedure was initiated; a size of an uplink grant provided by the network node; a modulation and coding scheme used for transmitting a message associated with the RACH procedure; a transmission block size used for transmitting a message associated with the RACH procedure; a redundancy version associated with a HARQ procedure configuration; information associated with determining a AEQ-ACK codebook; an indication of whether a HARQ procedure is adaptive or non-adaptive; and an indication of whether a HARW procedure is synchronous or asynchronous. Example Embodiment A20. The method of any one of Example Embodiments Al to Al 9, further comprising receiving, from the network node, a message comprising an indication of at least one adapted parameter associated with the RACH procedure.

Example Embodiment A21. The method of Example Embodiment A20, wherein the at least one adapted parameter associated with the RACH procedure comprises any one or more of: an adapted modulation and coding scheme for transmitting or receiving a RACH related message; an adapted target power value or power ramping step for transmitting or receiving a RACH related message; an adapted transmission power for transmitting or receiving a RACH related message; at least one adapted RA preamble; an increased size of a Random Access Response (RAR) window; an increase in RACH occasions; at least one adapted frequency priority or cell selection priority; and an adapted uplink and/or downlink coverage.

Example Embodiment A22. A wireless device comprising processing circuitry configured to perform any of the methods of Example Embodiments Al to A21.

Example Embodiment A23. A computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments Al to A21.

Example Embodiment A24. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments Al to A21.

Example Embodiment A25. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of Example Embodiments Al to A21.

Example Embodiment Bl. A method by a network node comprising: receiving, from a wireless device, Random Access (RA) related information associated with the at least one operation performed by the wireless device during the performance of a RACH procedure.

Example Embodiment B2. The method of Example Embodiment Bl, further comprising performing at least one action based on the RA related information.

Example Embodiment B3. The method of Example Embodiment B2, wherein performing the at least one action comprises adapting at least one parameter associated with the RACH procedure. Example Embodiment B4. The method of Example Embodiment B3, wherein adapting the at least one parameter associated with the RACH procedure comprises any one or more of: adapting a modulation and coding scheme for transmitting a RACH related message to the wireless device; adapting a target power value or power ramping step; adapting a transmission power for transmitting a RACH related message to the wireless device; transmitting a plurality of RACH related messages associated with a plurality of RA preambles to the wireless device; increasing a size of a Random Access Response (RAR) window; allocating more RACH occasions; changing at least one frequency priority or cell selection priority; adapt uplink and/or downlink coverage; adapt a modulation and coding scheme for the wireless device; adapt a transmission power for the wireless device; and adapt a preamble received target power or power ramping step for the wireless device.

Example Embodiment B5. The method of any one of Example Embodiments B3 to B4, further comprising: transmitting, to the wireless device, a message comprising an indication of the adaptation of the at least one parameter associated with the RACH procedure.

Example Embodiment B6. The method of any one of Example Embodiments Bl to B5, wherein: the RACH procedure comprises a four step RACH procedure; and the at least one operation performed by the wireless device comprises a transmission of a msg3 to the network node.

Example Embodiment B7. The method of Example Embodiment B6, wherein the RA related information comprises at least one of: an indication of a failure associated with the transmission of the msg3; an indication of a successful transmission of the msg3; an indication of a failure to decode a msg4 received after transmitting the msg3; an indication of a maximum number of transmissions of the msg3 ; a number of Hybrid Automatic Repeat Request (HARQ) retransmissions associated with the msg3; a number of NACKs received after transmitting the msg3; a cause of the failure associated with the transmission of the msg3; a power level associated with the transmission of the msg3; a power level associated with each retransmission of the msg3; a pathloss measured when transmitting the msg3; and a pathloss measured before transmitting each retransmission of the msg3; an indication of whether the response message was received; an indication of whether the response message included a backoff indicator; an indication of a number of response messages received; an indication of a number of response messages received that included a backoff indicator; an indication of whether, in response to transmitting the msg3, the wireless device received at least one downlink scheduling allocation within a response window; and an indication of a number of times, after transmitting the msg3, that the wireless device received at least one downlink scheduling allocation within a response window.

Example Embodiment B8. The method of any one of Example Embodiments Bl to B7, wherein the RA related information comprises an indication of a reason or cause of a contention resolution failure associated with the RACH procedure.

Example Embodiment B9. The method of Example Embodiment B8, wherein the indication of the reason or the cause of the contention resolution failure comprises at least one of: an expiration of a contention resolution timer; and an occurred contention when a contention resolution identity does not match with an identity of the wireless device.

Example Embodiment BIO. The method of any one of Example Embodiments Bl to B5, wherein: the RACH procedure comprises a two-step RACH procedure; and the at least one operation performed by the wireless device comprises a transmission of a payload portion of a msgA to the network node.

Example Embodiment B 11. The method of Example Embodiment BIO, wherein the RA related information comprises at least one of: an indication of the failure associated with the transmission of the payload portion of the msgA; an indication of the successful transmission of the payload portion of the msgA; an indication of a maximum number of transmissions of the msgA; a number of Hybrid Automatic Repeat Request (HARQ) retransmissions associated with the msgA; a number of NACKs received by the wireless device after transmitting the msgA; a cause of the failure associated with the transmission of the payload portion of the msgA; a power level associated with the transmission of the payload portion of the msgA; a power level associated with each retransmission of the payload portion of the msgA; a pathloss measured when transmitting the payload portion of the msgA; a pathloss measured before transmitting each retransmission of the payload portion of the msgA; an indication of whether the wireless device received a response message from the network node after transmitting the payload portion of the msgA; an indication of whether a response message included a backoff indicator; an indication of a number of response messages received by the wireless device after transmitting the payload portion of the msgA; an indication of a number of response messages received by the wireless device that included a backoff indicator; an indication of whether, in response to transmitting the payload portion of the msgA, the wireless device received at least one downlink scheduling allocation within a response window; and an indication of a number of times, after transmitting the payload portion of the msgA, that the wireless device received at least one downlink scheduling allocation within a response window.

Example Embodiment B12.The method of any one of Example Embodiments Bl to Bll, wherein the RA related information associated with the at least one operation is transmitted to the network node via a UEInformationRespon.se Radio Resource Control (RRC) message.

Example Embodiment Bl 3. The method of any one of Example Embodiments Bl 2, wherein the RA related information associated with the at least one operation is transmitted to the network node in a PerRAAttemptInfoList-rl6 Information Element or a PerRASSBInfo-R16 Information Element.

Example Embodiment B14.The method of any one of Example Embodiments Bl to Al 3, wherein the RA related information comprises information associated with every failed and/or successful performance of the at least one operation by the wireless device.

Example Embodiment B15. The method of any one of Example Embodiments Bl to Bl 4, wherein the RA related information comprises information associated with only a first performance or first attempted performance of the at least one operation by the wireless device.

Example Embodiment Bl 6. The method of any one of Embodiments Bl to Bl 5, wherein the RA related information comprises frequency related information of an active bandwidth part used to transmit, by the wireless device, a message associated with the RACH procedure.

Example Embodiment B17.The method of any one of Example Embodiments Bl to Bl 6, wherein the RA related information comprises at least one of: an indication of whether the wireless device is in a connected mode or an idle mode when the RACH procedure was initiated; a size of an uplink grant provided by the network node; a modulation and coding scheme used for transmitting, by the wireless device, a message associated with the RACH procedure; a transmission block size used for transmitting, by the wireless device, a message associated with the RACH procedure; a redundancy version associated with a HARQ procedure configuration; information associated with determining, by the wireless device, a AEQ-ACK codebook; an indication of whether a HARQ procedure is adaptive or non-adaptive; and an indication of whether a HARQ procedure is synchronous or asynchronous.

Example Embodiment B18. A network node comprising processing circuitry configured to perform any of the methods of Example Embodiments Bl to Bl 7. Example Embodiment Bl 9. A computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments Bl to B17.

Example Embodiment B20. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments Bl to Bl 7.

Example Embodiment B21. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of Example Embodiments Bl to B17.

Example Embodiment Cl. A wireless device comprising: processing circuitry configured to perform any of the steps of any of Example Embodiments Al to A25; and power supply circuitry configured to supply power to the wireless device.

Example Embodiment C2. A network node comprising: processing circuitry configured to perform any of the steps of any of Example Embodiments Bl to B21; power supply circuitry configured to supply power to the wireless device.

Example Embodiment C3. A wireless device, the wireless device comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform any of the steps of any of Example Embodiments Al to A25; an input interface connected to the processing circuitry and configured to allow input of information into the wireless device to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the wireless device that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the wireless device.

Example Embodiment C4. A communication system including a host computer comprising: processing circuitry configured to provide user data; and a communication interface configured to forward the user data to a cellular network for transmission to a wireless device, wherein the cellular network comprises a network node having a radio interface and processing circuitry, the network node’s processing circuitry configured to perform any of the steps of any of Example Embodiments Bl to B21.

Example Embodiment C5. The communication system of the pervious embodiment further including the network node. Example Embodiment C6. The communication system of the previous 2 embodiments, further including the wireless device, wherein the wireless device is configured to communicate with the network node.

Example Embodiment C7. The communication system of the previous 3 embodiments, wherein: the processing circuitry of the host computer is configured to execute a host application, thereby providing the user data; and the wireless device comprises processing circuitry configured to execute a client application associated with the host application.

Example Embodiment C8. A method implemented in a communication system including a host computer, a network node and a wireless device, the method comprising: at the host computer, providing user data; and at the host computer, initiating a transmission carrying the user data to the wireless device via a cellular network comprising the network node, wherein the network node performs any of the steps of any of Example Embodiments Bl to B21.

Example Embodiment C9. The method of the previous embodiment, further comprising, at the network node, transmitting the user data.

Example Embodiment CIO. The method of the previous 2 embodiments, wherein the user data is provided at the host computer by executing a host application, the method further comprising, at the wireless device, executing a client application associated with the host application.

Example Embodiment Cl 1. A wireless device configured to communicate with a network node, the wireless device comprising a radio interface and processing circuitry configured to performs the of the previous 3 embodiments.

Example Embodiment C12. A communication system including a host computer comprising: processing circuitry configured to provide user data; and a communication interface configured to forward user data to a cellular network for transmission to a wireless device, wherein the wireless device comprises a radio interface and processing circuitry, the wireless device’s components configured to perform any of the steps of any of Example Embodiments Al to A25.

Example Embodiment Cl 3. The communication system of the previous embodiment, wherein the cellular network further includes a network node configured to communicate with the wireless device.

Example Embodiment C14. The communication system of the previous 2 embodiments, wherein: the processing circuitry of the host computer is configured to execute a host application, thereby providing the user data; and the wireless device’s processing circuitry is configured to execute a client application associated with the host application.

Example Embodiment C 15. A method implemented in a communication system including a host computer, a network node and a wireless device, the method comprising: at the host computer, providing user data; and at the host computer, initiating a transmission carrying the user data to the wireless device via a cellular network comprising the network node, wherein the wireless device performs any of the steps of any of Example Embodiments Al to A25.

Example Embodiment Cl 6. The method of the previous embodiment, further comprising at the wireless device, receiving the user data from the network node.

Example Embodiment Cl 7. A communication system including a host computer comprising: communication interface configured to receive user data originating from a transmission from a wireless device to a network node, wherein the wireless device comprises a radio interface and processing circuitry, the wireless device’s processing circuitry configured to perform any of the steps of any of Example Embodiments Al to A25.

Example Embodiment C 18. The communication system of the previous embodiment, further including the wireless device.

Example Embodiment C19. The communication system of the previous 2 embodiments, further including the network node, wherein the network node comprises a radio interface configured to communicate with the wireless device and a communication interface configured to forward to the host computer the user data carried by a transmission from the wireless device to the network node.

Example Embodiment C20. The communication system of the previous 3 embodiments, wherein: the processing circuitry of the host computer is configured to execute a host application; and the wireless device’s processing circuitry is configured to execute a client application associated with the host application, thereby providing the user data.

Example Embodiment C21. The communication system of the previous 4 embodiments, wherein: the processing circuitry of the host computer is configured to execute a host application, thereby providing request data; and the wireless device’s processing circuitry is configured to execute a client application associated with the host application, thereby providing the user data in response to the request data. Example Embodiment C22. A method implemented in a communication system including a host computer, a network node and a wireless device, the method comprising: at the host computer, receiving user data transmitted to the network node from the wireless device, wherein the wireless device performs any of the steps of any of Example Embodiments Al to A25.

Example Embodiment C23. The method of the previous embodiment, further comprising, at the wireless device, providing the user data to the network node.

Example Embodiment C24. The method of the previous 2 embodiments, further comprising: at the wireless device, executing a client application, thereby providing the user data to be transmitted; and at the host computer, executing a host application associated with the client application.

Example Embodiment C25. The method of the previous 3 embodiments, further comprising: at the wireless device, executing a client application; and at the wireless device, receiving input data to the client application, the input data being provided at the host computer by executing a host application associated with the client application, wherein the user data to be transmitted is provided by the client application in response to the input data.

Example Embodiment C26. A communication system including a host computer comprising a communication interface configured to receive user data originating from a transmission from a wireless device to a network node, wherein the network node comprises a radio interface and processing circuitry, the network node’s processing circuitry configured to perform any of the steps of any of Example Embodiments Bl to B21.

Example Embodiment C27. The communication system of the previous embodiment further including the network node.

Example Embodiment C28. The communication system of the previous 2 embodiments, further including the wireless device, wherein the wireless device is configured to communicate with the network node.

Example Embodiment C29. The communication system of the previous 3 embodiments, wherein: the processing circuitry of the host computer is configured to execute a host application; the wireless device is configured to execute a client application associated with the host application, thereby providing the user data to be received by the host computer. Example Embodiment C30. A method implemented in a communication system including a host computer, a network node and a wireless device, the method comprising: at the host computer, receiving, from the base station, user data originating from a transmission which the network node has received from the wireless device, wherein the wireless device performs any of the steps of any of Example Embodiments Al to A25.

Example Embodiment C31. The method of the previous embodiment, further comprising at the network node receiving the user data from the wireless device.

Example Embodiment C32. The method of the previous 2 embodiments, further comprising at the network node, initiating a transmission of the received user data to the host computer.

Example Embodiment C33. The method of any of the previous embodiments, wherein the network node comprises a base station.

Example Embodiment C34. The method of any of the previous embodiments, wherein the wireless device comprises a user equipment (UE).

Modifications, additions, or omissions may be made to the systems and apparatuses described herein without departing from the scope of the disclosure. The components of the systems and apparatuses may be integrated or separated. Moreover, the operations of the systems and apparatuses may be performed by more, fewer, or other components. Additionally, operations of the systems and apparatuses may be performed using any suitable logic comprising software, hardware, and/or other logic. As used in this document, “each” refers to each member of a set or each member of a subset of a set.

Modifications, additions, or omissions may be made to the methods described herein without departing from the scope of the disclosure. The methods may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order.

Although this disclosure has been described in terms of certain embodiments, alterations and permutations of the embodiments will be apparent to those skilled in the art. Accordingly, the above description of the embodiments does not constrain this disclosure. Other changes, substitutions, and alterations are possible without departing from the spirit and scope of this disclosure.

Claims

1. A method (1200) by a wireless device (110) comprising: transmitting (1202), to a network node (160), a first Physical Uplink Shared Channel, PUSCH, message of a random access, RA, procedure; and transmitting (1204), to the network node, RA related information associated with the transmission of the first PUSCH message of the RA procedure.

2. The method of Claim 1, wherein the RA related information comprises pathloss information associated with the transmission of the first PUSCH message.

3. The method of Claim 1, wherein the RA related information comprises an indication of a reason or cause of a contention resolution failure.

4. The method of Claim 3, wherein the indication of the reason or the cause of the contention resolution failure is indicative of at least one of: an expiration of a contention resolution timer; and an occurred contention when a contention resolution identity does not match with an identity of the wireless device as included in the first PUSCH message.

5. The method of any one of Claims 1 to 4, wherein the first PUSCH message is transmitted during a first step of the RA procedure.

6. The method of any one of Claims 1 to 4, wherein: the RA procedure comprises a two-step RA procedure; and a msgA includes the first PUSCH message.

7. The method of any one of Claims 1 to 4, wherein: the RA procedure comprises a four-step RA procedure; and a msg3 includes the first PUSCH message.

8. The method of any one of Claims 1 to 7, further comprising detecting a failure associated with the transmission of the first PUSCH message, and wherein the RA related information comprises at least one of: an indication of a maximum number of transmissions of the first PUSCH message; a number of Hybrid Automatic Repeat Request, HARQ, retransmissions associated with the first PUSCH message; a number of Negative Acknowledgements, NACKs, received after transmitting the first PUSCH message; a cause of the failure associated with the transmission of the first PUSCH message; a power level associated with the transmission of the first PUSCH message; a power level associated with each retransmission of the first PUSCH message; a pathloss measured when transmitting the first PUSCH message; and a pathloss measured before transmitting each retransmission of the first PUSCH message.

9. The method of any one of Claims 1 to 7, further comprising detecting that the transmission of the first PUSCH message was successful, and wherein the RA related information comprises at least one of: an indication of the successful transmission of the first PUSCH message; an indication of a failure to decode a second message received after transmitting the first PUSCH message; a number of Hybrid Automatic Repeat Request, HARQ, retransmissions associated with the first PUSCH message; a number of Negative Acknowledgements, NACKs, received after transmitting the first PUSCH message; a power level associated with the transmission of the first PUSCH message; a power level associated with each retransmission of the first PUSCH message; a pathloss measured when transmitting the first PUSCH message; and a pathloss measured before transmitting each retransmission of the first PUSCH message.

10. The method of any one of Claims 1 to 9, further comprising monitoring a channel for a response message from the network node after the transmission of the first PUSCH message, and wherein a determination of a failure or a success of the transmission of the first PUSCH message is based on whether the response message is received after the transmission of the first PUSCH message.

11. The method of Claim 10, wherein the RA related information comprises at least one of: an indication of whether the response message was received; an indication of whether the response message included a backoff indicator; an indication of a number of response messages received; an indication of a number of response messages received that included a backoff indicator; an indication of whether, in response to transmitting the first PUSCH message, the wireless device received at least one downlink scheduling allocation within a response window; and an indication of a number of times, after transmitting the first PUSCH message, that the wireless device received at least one downlink scheduling allocation within a response window.

12. The method of any one of Claims 1 to 11, wherein the RA related information comprises at least one of: an indication of whether the wireless device is in a connected mode or an idle mode when the RA procedure was initiated; a size of an uplink grant provided by the network node; a modulation and coding scheme used for transmitting the first PUSCH message associated with the RA procedure; a transmission block size used for transmitting the first PUSCH message associated with the RA procedure; a redundancy version associated with a Hybrid Automatic Repeat Request, HARQ, procedure configuration; information associated with determining a codebook; an indication of whether a HARQ procedure is adaptive or non-adaptive; and an indication of whether a HARQ procedure is synchronous or asynchronous.

13. A method (1600) by a network node (160) comprising: receiving (1602), from a wireless device (110), Random Access, RA, related information associated with a transmission of a first Physical Uplink Shared Channel, PUSCH, message of a RA procedure.

14. The method of Claim 13, further comprising adapting at least one parameter associated with the RA procedure based on the RA related information.

15. The method of Claim 14, wherein adapting the at least one parameter associated with the RA procedure comprises at least one of: adapting a modulation and coding scheme for transmitting a RA related message to the wireless device; adapting a target power value or power ramping step; adapting a transmission power for transmitting a RA related message to the wireless device; transmitting a plurality of RA related messages associated with a plurality of RA preambles to the wireless device; increasing a size of a Random Access Response, RAR, window; allocating more RACH occasions; changing at least one frequency priority or cell selection priority; adapt uplink and/or downlink coverage; adapt a modulation and coding scheme for the wireless device; adapt a transmission power for the wireless device; and adapt a preamble received target power or power ramping step for the wireless device.

16. The method of any one of Claims 14 to 15, further comprising: transmitting, to the wireless device, a message comprising an indication of the at least one parameter associated with the RA procedure that is adapted based on the RA related information.

17. The method of any one of Claims 13 to 16, wherein the RA related information comprises pathloss information associated with the transmission of the first PUSCH message.

18. The method of any one of Claims 13 to 16, wherein the RA related information comprises an indication of a reason or cause of a contention resolution failure.

19. The method of Claim 18, wherein the indication of the reason or the cause of the contention resolution failure is indicative of at least one of: an expiration of a contention resolution timer; and an occurred contention when a contention resolution identity does not match with an identity of the wireless device as included in the first PUSCH message.

20. The method of any one of Claims 13 to 19, wherein the first PUSCH message is transmitted during a first step of the RA procedure.

21. The method of any one of Claims 13 to 19, wherein: the RA procedure comprises a two-step RA procedure; and a msgA includes the first PUSCH message.

22. The method of any one of Claims 13 to 19, wherein: the RA procedure comprises a four-step RA procedure; and a msg3 includes the first PUSCH message.

23. The method of any one of Claims 13 to 22, wherein the RA related information comprises at least one of: an indication of a successful transmission of the first PUSCH message; an indication of a failure to decode a message received after transmitting the first PUSCH message; an indication of a maximum number of transmissions of the first PUSCH message; a number of Hybrid Automatic Repeat Request, HARQ, retransmissions associated with the first PUSCH message; a number of Negative Acknowledgements, NACKs, received after transmitting the first PUSCH message; a cause of the failure associated with the transmission of the first PUSCH message; a power level associated with the transmission of the first PUSCH message; a power level associated with each retransmission of the first PUSCH message; a pathloss measured when transmitting the first PUSCH message; a pathloss measured before transmitting each retransmission of the first PUSCH message; an indication of whether a response message was received; an indication of whether a response message included a backoff indicator; an indication of a number of response messages received; an indication of a number of response messages received that included a backoff indicator; an indication of whether, in response to transmitting the first PUSCH message, the wireless device received at least one downlink scheduling allocation within a response window; and an indication of a number of times, after transmitting the first PUSCH message, that the wireless device received at least one downlink scheduling allocation within a response window.

24. The method of any one of Claims 13 to 23, wherein the RA related information is received via a UEInformationRespon.se Radio Resource Control, RRC, message.

25. The method of Claim 24, wherein the RA related information associated with the at least one operation is transmitted to the network node in a PerRAAttemptlnfoList-r 16 Information Element or a PerRASSBInfo-Rl 6 Information Element.

26. The method of any one of Claims 13 to 25, wherein the RA related information comprises at least one of: an indication of whether the wireless device is in a connected mode or an idle mode when the RA procedure was initiated; a size of an uplink grant provided by the network node; a modulation and coding scheme used for transmitting, by the wireless device, a message associated with the RA procedure; a transmission block size used for transmitting, by the wireless device, a message associated with the RA procedure; a redundancy version associated with a HARQ procedure configuration; information associated with determining, by the wireless device, a AEQ-ACK codebook; an indication of whether a HARQ procedure is adaptive or non-adaptive; and an indication of whether a HARQ procedure is synchronous or asynchronous.

27. A wireless device (110) adapted to: transmit (1202), to a network node (160), a first Physical Uplink Shared Channel, PUSCH, message of a Random Access, RA, procedure; and transmit (1204), to the network node, RA related information associated with the transmission of the first PUSCH message of the RA procedure.

28. The wireless device of Claim 27, wherein the RA related information comprises pathloss information associated with the transmission of the first PUSCH message.

29. The wireless device of Claim 27, wherein the RA related information comprises an indication of a reason or cause of a contention resolution failure.

30. The wireless device of Claim 39, wherein the indication of the reason or the cause of the contention resolution failure is indicative of at least one of: an expiration of a contention resolution timer; and an occurred contention when a contention resolution identity does not match with an identity of the wireless device as included in the first PUSCH message.

31. The wireless device of any one of Claims 27 to 30, wherein the first PUSCH message is transmitted during a first step of the RA procedure.

32. The wireless device of any one of Claims 27 to 30, wherein: the RA procedure comprises a two-step RA procedure; and a msgA includes the first PUSCH message.

33. The wireless device of any one of Claims 27 to 30, wherein: the RA procedure comprises a four-step RA procedure; and a msg3 includes the first PUSCH message.

34. The wireless device of any one of Claims 27 to 33, wherein the wireless device is further adapted to detect a failure associated with the transmission of the first PUSCH message, and wherein the RA related information comprises at least one of: an indication of a maximum number of transmissions of the first PUSCH message; a number of Hybrid Automatic Repeat Request, HARQ, retransmissions associated with the first PUSCH message; a number of Negative Acknowledgements, NACKs, received after transmitting the first PUSCH message; a cause of the failure associated with the transmission of the first PUSCH message; a power level associated with the transmission of the first PUSCH message; a power level associated with each retransmission of the first PUSCH message; a pathloss measured when transmitting the first PUSCH message; and a pathloss measured before transmitting each retransmission of the first PUSCH message.

35. The wireless device of any one of Claims 27 to 33, wherein the wireless device is further adapted to detect that the transmission of the first PUSCH message was successful, and wherein the RA related information comprises at least one of: an indication of the successful transmission of the first PUSCH message; an indication of a failure to decode a second message received after transmitting the first PUSCH message; a number of Hybrid Automatic Repeat Request, HARQ, retransmissions associated with the first PUSCH message; a number of Negative Acknowledgements, NACKs, received after transmitting the first PUSCH message; a power level associated with the transmission of the first PUSCH message; a power level associated with each retransmission of the first PUSCH message; a pathloss measured when transmitting the first PUSCH message; and a pathloss measured before transmitting each retransmission of the first PUSCH message.

36. The wireless device of any one of Claims 27 to 35, wherein the wireless device is adapted to monitor a channel for a response message from the network node after the transmission of the first PUSCH message, and wherein a determination of a failure or a success of the transmission of the first PUSCH message is based on whether the response message is received after the transmission of the first PUSCH message.

37. The wireless device of Claim 36, wherein the RA related information comprises at least one of: an indication of whether the response message was received; an indication of whether the response message included a backoff indicator; an indication of a number of response messages received; an indication of a number of response messages received that included a backoff indicator; an indication of whether, in response to transmitting the first PUSCH message, the wireless device received at least one downlink scheduling allocation within a response window; and an indication of a number of times, after transmitting the first PUSCH message, that the wireless device received at least one downlink scheduling allocation within a response window.

38. The wireless device of any one of Claims 27 to 37, wherein the RA related information comprises at least one of: an indication of whether the wireless device is in a connected mode or an idle mode when the RA procedure was initiated; a size of an uplink grant provided by the network node; a modulation and coding scheme used for transmitting the first PUSCH message associated with the RA procedure; a transmission block size used for transmitting the first PUSCH message associated with the RA procedure; a redundancy version associated with a Hybrid Automatic Repeat Request, HARQ, procedure configuration; information associated with determining a codebook; an indication of whether a HARQ procedure is adaptive or non-adaptive; and an indication of whether a HARQ procedure is synchronous or asynchronous.

39. A network node (160) adapted to: receive (1602), from a wireless device (110), Random Access, RA, related information associated with a transmission of a first Physical Uplink Shared Channel, PUSCH, message of a RA procedure.

40. The network node of Claim 39, wherein the network node is further adapted to adapt at least one parameter associated with the RA procedure based on the RA related information.

41. The network node of Claim 40, wherein adapting the at least one parameter associated with the RA procedure comprises at least one of: adapting a modulation and coding scheme for transmitting a RA related message to the wireless device; adapting a target power value or power ramping step; adapting a transmission power for transmitting a RA related message to the wireless device; transmitting a plurality of RA related messages associated with a plurality of RA preambles to the wireless device; increasing a size of a Random Access Response, RAR, window; allocating more RA occasions; changing at least one frequency priority or cell selection priority; adapt uplink and/or downlink coverage; adapt a modulation and coding scheme for the wireless device; adapt a transmission power for the wireless device; and adapt a preamble received target power or power ramping step for the wireless device.

42. The network node of any one of Claims 39 to 41, wherein the network node is adapted to: transmit, to the wireless device, a message comprising an indication of the at least one parameter associated with the RA procedure that is adapted based on the RA related information.

43. The network node of any one of Claims 39 to 42, wherein the RA related information comprises pathloss information associated with the transmission of the first PUSCH message.

44. The network node of any one of Claims 39 to 42, wherein the RA related information comprises an indication of a reason or cause of a contention resolution failure.

45. The network node of Claim 44, wherein the indication of the reason or the cause of the contention resolution failure is indicative of at least one of: an expiration of a contention resolution timer; and an occurred contention when a contention resolution identity does not match with an identity of the wireless device as included in the first PUSCH message.

46. The network node of any one of Claims 39 to 45, wherein the first PUSCH message is transmitted during a first step of the RA procedure.

47. The network node of any one of Claims 39 to 46, wherein: the RA procedure comprises a two-step RA procedure; and a msgA includes the first PUSCH message.

48. The network node of any one of Claims 39 to 46, wherein: the RA procedure comprises a four-step RA procedure; and a msg3 includes the first PUSCH message.

49. The network node of any one of Claims 39 to 48, wherein the RA related information comprises at least one of: an indication of a successful transmission of the first PUSCH message; an indication of a failure to decode a message received after transmitting the first PUSCH message; an indication of a maximum number of transmissions of the first PUSCH message; a number of Hybrid Automatic Repeat Request, HARQ, retransmissions associated with the first PUSCH message; a number of Negative Acknowledgements, NACKs, received after transmitting the first PUSCH message; a cause of the failure associated with the transmission of the first PUSCH message; a power level associated with the transmission of the first PUSCH message; a power level associated with each retransmission of the first PUSCH message; a pathloss measured when transmitting the first PUSCH message; a pathloss measured before transmitting each retransmission of the first PUSCH message; an indication of whether a response message was received; an indication of whether a response message included a backoff indicator; an indication of a number of response messages received; an indication of a number of response messages received that included a backoff indicator; an indication of whether, in response to transmitting the first PUSCH message, the wireless device received at least one downlink scheduling allocation within a response window; and an indication of a number of times, after transmitting the first PUSCH message, that the wireless device received at least one downlink scheduling allocation within a response window.

50. The network node of any one of Claims 39 to 49, wherein the RA related information is received via a UEInformationRespon.se Radio Resource Control, RRC, message.

51. The network node d of Claim 50, wherein the RA related information associated with the at least one operation is transmitted to the network node in a PerRAAttemptlnfoList-r 16 Information Element or a PerRASSBInfo-Rl 6 Information Element.

52. The network node of any one of Claims 39 to 51, wherein the RA related information comprises at least one of: an indication of whether the wireless device is in a connected mode or an idle mode when the RA procedure was initiated; a size of an uplink grant provided by the network node; a modulation and coding scheme used for transmitting, by the wireless device, a message associated with the RA procedure; a transmission block size used for transmitting, by the wireless device, a message associated with the RA procedure; a redundancy version associated with a HARQ procedure configuration; information associated with determining, by the wireless device, a AEQ-ACK codebook; an indication of whether a HARQ procedure is adaptive or non-adaptive; and an indication of whether a HARQ procedure is synchronous or asynchronous.