Method and apparatus for optimizing transmission of random access messages reporting failure in unlicensed spectrum

Abstract

Embodiments described herein relate to methods and apparatus for providing random access information related to a random access procedure. In one embodiment, a method in a user equipment comprises transmitting random access information related to a random access procedure to a network node, the random access information comprising a fourth indication indicating that a second beam is selected for a preamble transmission in the random access procedure before the second beam is selected for the preamble transmission in the random access procedure, whether there is at least one failed transmission attempt of the random access preamble experienced after a last successful transmission attempt of the random access preamble in the first beam.

Description

Technical Field

[0001] The embodiments described herein relate to methods and apparatus for reporting failed random access message transmissions in unlicensed spectrum. Background Technology

[0002] Self-Organizing Networks (SON) in 3GPP

[0003] Self-Organizing Networks (SON) is an automation technology designed to make the planning, configuration, management, optimization, and repair of mobile radio access networks simpler and faster. SON functionality and behavior have been defined and specified in generally accepted mobile industry recommendations developed by organizations such as 3GPP (3rd Generation Partnership Project) and NGMN (Next Generation Mobile Network).

[0004] In 3GPP, processes within the SON domain are categorized into self-configuration processes and self-optimization processes. A self-configuration process is an automated installation process that configures newly deployed nodes to acquire the basic configuration required for system operation.

[0005] The self-configuration process operates in a pre-operational state. The pre-operational state is understood as the state from when the base station (e.g., eNB) is powered on and has a backbone connection until the radio frequency (RF) transmitter is turned on.

[0006] Figure 1 The ramifications of self-configuration / self-optimization functions are shown (from 3GPP TS36.300 Figure 22.1-1). For example... Figure 1 The functions shown, which are processed in the pre-operation state, may include: basic settings; and initial radio configuration, and may be covered by the self-configuration process.

[0007] The self-optimization process is defined as the process by which user equipment (UE) and access node measurements, as well as performance measurements, are used to automatically adjust the network. The self-optimization process operates in an operational state. The operational state is understood as a state where the radio frequency interface is additionally enabled.

[0008] like Figure 1 As shown, the functions processed in the operating state can include: optimization / adaptation, and are covered in the self-optimization process.

[0009] In LTE, support for self-configuration and self-optimization is specified, as described in Section 22.2 of 3GPP TS 36.300 v17.4.0, including features such as dynamic configuration, automatic neighbor relationship (ANR), mobility load balancing, mobility robustness optimization (MRO), RACH optimization, and support for power saving.

[0010] Support for self-configuration and self-optimization is also specified in NR, as described in Section 15 of 3GPP TS 38.300 v15.4.0, starting with self-configuration features (such as dynamic configuration) and Automatic Neighbor Relations (ANR) in Rel-15. In NRRel-16, more SON features are being specified, including self-optimization features such as Mobility Robustness Optimization (MRO).

[0011] Mobility Robustness Optimization (MRO) in 3GPP

[0012] Seamless handover is a key feature of 3GPP technology. Successful handover ensures that the UE can move between different cell coverage areas without causing significant interruptions in data transmission. However, there are scenarios where the network cannot promptly hand the UE over to the 'correct' neighboring cell, and in such scenarios, the UE may declare a radio link failure (RLF) or a handover failure (HOF).

[0013] When a HOF and / or RLF occurs, the UE may take autonomous actions, such as attempting to select a cell and initiate a rebuilding process, to ensure that the UE is trying to restore connectivity as quickly as possible so that it can be reached again. RLF will result in a poor user experience because the UE will only declare an RLF when it realizes that there is no available reliable communication channel (radio link) between itself and the network. Furthermore, rebuilding the connection requires signaling communication with the newly selected cell (random access procedure, Radio Resource Control (RRC) rebuild request, RRC rebuild, RRC rebuild completion, RRC reconfiguration, and RRC reconfiguration completion), and adds some latency until the UE can exchange data with the network again.

[0014] According to the specification (3GPP TS 36.331), the possible causes of radio link failures can be one of the following:

[0015] Radio link monitoring related timer T310 has expired;

[0016] The timer T312 associated with the measurement report expired (although the measurement report was sent while T310 was running, no switching command was received from the network during the duration of this timer).

[0017] To reach the maximum number of Radio Link Control (RLC) retransmissions; and

[0018] A random access problem indication was received from the MAC entity.

[0019] Because RLF (Rapid Regression Failure) leads to rebuilding, which degrades performance and user experience, understanding the causes of RLFs and attempting to optimize mobility-related parameters (such as the triggering conditions for measurement reports) to avoid subsequent RLFs is in the best interest of the network. Before the standardization of MRO-related reporting processing in the network, only the UE was aware of some information associated with the following: how the radio quality looked when the RLF occurred, what the actual reason for the declared RLF was, etc. For the network to identify the causes of RLFs, more information is needed, both from the UE and from neighboring base stations.

[0020] As part of the MRO solution in LTE, the RLF reporting procedure was introduced in the RRC specification in the Rel-9 RAN2 work. This has affected the RRC specification (TS 36.331), which in a sense standardizes that the UE will record relevant information when an RLF occurs and subsequently report it to the target cell upon successful UE connection (e.g., after reconnection). This also affects the gNodeB inter-interface, namely the X2AP specification (3GPP TS 36.423 v 17.4.0), because the eNodeB receiving the RLF report may forward it to the eNodeB from which the failure originated.

[0021] The RLF reports generated by the UE have been enhanced with more information in subsequent versions. The measurements included in the measurement report based on the latest LTE RRC specification (3GPP TS 36.331 v 17.4.0) are:

[0022] Measurements of the previous serving cell (PCell) (Reference Received Power (RSRP) and Reference Received Quality (RSRQ)).

[0023] Measurements of neighboring cells at different frequencies of different RATs (EUTRA, UTRA, GERAN, CDMA2000).

[0024] Measurements associated with WLAN applications (Received Signal Strength Indicator (RSSI)).

[0025] Measurements associated with Bluetooth beacons (RSSI).

[0026] Location information (if available) (including location coordinates and velocity)

[0027] The globally unique identifier of the previous serving cell (if available), or the PCI and carrier frequency of the previous serving cell.

[0028] PCell's tracking area code.

[0029] Time elapsed since the last "switch command" message was received.

[0030] The C-RNTI used in the previous serving cell.

[0031] Is the UE configured with a DRB having a QCI value of 1?

[0032] After an RLF is declared, the RLF report is recorded and included in the VarRLF-Report. Once the UE selects a cell and successfully rebuilds, it includes an indication that it has an available RLF report in the RRC Rebuild Complete message so that the target cell is aware of this availability. Then, when a UEInformationRequest message with the "rlf-ReportReq-r9" flag is received, the UE can include the RLF report (stored in the UE variable VarRLF-Report, as described above) in the UEInformationResponse message and send it to the network.

[0033] Based on the RLF report from the UE and information about which cell the UE re-established with, the original serving cell can infer whether the RLF is due to a coverage hole or due to handover-related parameter configuration. If the RLF is determined to be due to handover-related parameter configuration, the original serving cell can further classify the handover-related failure as too early, too late, or handover to the wrong cell category.

[0034] These switching failure categories will be briefly explained below.

[0035] - Is the handover failure due to a 'too late handover' situation? The original serving cell may classify a handover failure as 'too late handover' when the original serving cell fails to send a handover command to the UE associated with a handover toward a specific target cell, and if the UE rebuilds itself in that target cell after an RLF.

[0036] - An example corrective action from the original serving cell could be to initiate a handover process toward the target cell slightly earlier by reducing the CIO (Cell Individual Offset) toward the target cell. The CIO controls when the IE sends an event-triggered measurement report, which leads to the handover decision.

[0037] Did the handover failure occur due to a 'premature handover' situation?

[0038] - When the original serving cell successfully sends a handover command to the UE associated with the handover direction, but the UE fails to perform random access toward the target cell, the original serving cell can classify the handover failure as 'premature handover'.

[0039] - An example corrective action from the original serving cell could be to increase the CIO (Cell Individual Offset) toward the target cell, and later initiate a handover process toward that target cell. The CIO controls when the IE sends an event-triggered measurement report, which leads to the handover decision.

[0040] Did the handover failure occur due to a 'handover to the wrong cell' situation?

[0041] - When the original serving cell intends to perform a handover to a specific target cell for this UE, but the UE declares an RLF and rebuilds itself in a third cell, the original serving cell can classify the handover failure as 'handover to the wrong cell'.

[0042] - Example corrective actions from the original serving cell could be initiated by reducing the CIO (Cell Individual Offset) toward the target cell, which leads to a handover toward the target cell later, or by initiating a handover toward the cell in which the UE is rebuilt slightly earlier by increasing the CIO toward the rebuilt cell.

[0043] As an enhancement to MRO in Rel.17, 3GPP introduced Successful HO Report (SHR). Unlike RLF Report, which, as described above, is used to report RLF or handover failures experienced by the UE, SHR is used by the UE to report various information associated with a successful HO. A successful HO will not always be reported on every handover, but only when specific triggering conditions are met. For example, if the T310 / T312 / T304 timer exceeds a specific threshold while executing the HO, the UE should store information associated with this HO. Similarly, in the case of a Dual Active Protocol Stack (DAPS) HO, and the UE successfully completes the HO but experiences an RLF in the source cell while executing the DAPS HO, the UE should store information associated with this DAPS HO. When storing a successful handover report, the UE can include various information to help the network optimize the handover, such as measurements of neighboring cells, the conditions that triggered the successful handover report (e.g., threshold exceeding on T310, specific RLF issues in the source cell during DAPS HO execution), etc.

[0044] SHR can be configured by a specific serving cell, and the UE stores this information when the triggering conditions for SHR recording are met, until the network (NW) requests the information. Specifically, the UE can indicate the availability of SHR information in an RRC message (e.g., RRCReconfigurationComplete, RRCReestablishmentComplete, RRCSetupComplete, and RRCResumeComplete), and the network can request such information via a UEInformationRequest message, after which the UE sends the stored SHR in a UEInformationResponse message.

[0045] Both RLF-Report and SHR can contain information associated with the random access procedure. An RLF may actually be caused by random access problems, so by including random access information, the network can optimize the random access procedure and potentially minimize the risk of future RLFs. Similarly, when an SHR is generated due to problems experienced during the HO (House of Interest) period (e.g., the T304 value reaches a certain threshold), the SHR can also contain RA (Rapid Access Response) information. RA information includes information related to the BWP (Browser Window) in which random access was attempted, information related to the DL (Long Distance Path) loss experienced when initiating the random access procedure, information related to each preamble transmission attempt (e.g., whether contention occurred), and the number of preamble transmission attempts in a particular SSB or CSI-RS.

[0046] Channel access procedures in unlicensed NR spectrum

[0047] Listen-Before-Speak (LBT) is designed for unlicensed spectrum to ensure fair coexistence with other Radio Access Technologies (RATs). In this mechanism, radio equipment applies a Clear Channel Assessment (CCA) check (i.e., channel awareness) before any transmission. The transmitter performs an Energy Detection (ED) over a period of time, comparing the signal to a specific threshold (ED threshold) to determine if the channel is idle. If the channel is determined to be occupied, the transmitter performs random backoff within the contention window before the next CCA attempt. To protect ACK transmissions, the transmitter must delay for a period after each busy CCA slot before resuming backoff. Once the transmitter has secured access to the channel, it is only permitted to transmit for a maximum duration (i.e., Maximum Channel Occupancy Time (MCOT)).

[0048] To differentiate Quality of Service (QoS), channel access priorities based on service type have been defined. For example, there are four LBT priority categories, which are defined to differentiate between Contention Window Size (CWS) and MCOT between services. Therefore, the LBT category selected for transmission depends on the priority of the data to be transmitted or the type of signal to be transmitted, such as whether the signal type is PRACH, PUCCH, or Radio Resource Control (RRC).

[0049] Any device operating in unlicensed spectrum can always perform the LBT procedure, but it's important to note that the 3GPP specification includes certain procedures that a UE can perform upon detecting an LBT failure. Specifically, if the UE is configured with lbt-FailureRecoveryConfig by the network, the UE can perform certain actions in response to the detection of persistent uplink LBT failures. Specifically, if the UE detects a specific number of configurable LBT failures within a configurable time window, the UE declares persistent LBT failures. Declaring persistent LBT failures means the UE switches BWPs, is operating in the same BWP in the SpCell, and performs random access in another BWP in the same SpCell (if persistent LBT failures are detected in that SpCell). Otherwise, if persistent LBT failures occur in the SpCell, the UE temporarily stops using that SpCell until a subsequent network scheduling decision. Furthermore, when lbt-FailureRecoveryConfig is enabled, the UE does not step on the random access preamble counter (if a failure is detected in the random access preamble), and it does not perform power boost. On the other hand, if lbt-FailureRecoveryConfig is not configured, the UE will not perform continuous LBT failure detection, and if a failure in RA preamble transmission is detected, the UE will step the random access counter and it will perform a power boost.

[0050] Random access processing in NR-U

[0051] As previously mentioned, random access messages (including PRACH) are subject to LBT before transmission. In NR-U, an LBT counter is specified, and it is incremented whenever a UL transmission in a BWP fails. When the LBT counter reaches its maximum value within a certain time, the UE declares a "persistent LBT failure" for the corresponding BWP. If the affected BWP is located in a PCell or PSCell, the UE will deactivate the affected BWP and activate another configured BWP in the PCell / PSCell, transmitting random access within it. Alternatively, if the affected BWP is in a SCell, the UE will stop transmission in that SCell and can send SRs on another serving cell (not yet affected by the "persistent UL LBT failure") for further communication. Furthermore, due to the persistent LBT failure, the UE will issue a MAC CE to indicate to the network which cells have experienced the "persistent LBT failure".

[0052] In the case of PCell, once the UE has failed to achieve random access in all BWPs of the PCell, the UE will declare an RLF and may attempt to rebuild. Similarly, in the case of PSCell, when the UE has experienced continuous UL LBT failures in all BWPs of the PSCell, the UE will declare an SCG failure.

[0053] Random access information can be reported to the network as part of a Random Access Report (RA-Report), an RLF Report (RLF-Report), or a Successful Handover Report (SHR).

[0054] Specifically, if preamble transmission is blocked by LBT (i.e., channel sensing is busy at lower layers), the UE may not increment the preamble transmission counter (PREAMBLE_TRANSMISSION_COUNTER) if lbt-FailureRecoveryConfig is configured. Otherwise, if lbt-FailureRecoveryConfig is not configured, the preamble transmission counter is incremented.

[0055] Furthermore, regarding power boost, if the preceding preamble transmission is blocked by the LBT, the UE will not increase the transmit power for a preamble. According to MAC specification TS 38.321, after changing the beam used for RA (SSB or CSI-RS), the UE will not increase the power for the first preamble transmission. Summary of the Invention

[0056] One or more challenges exist. UEs are required to include information associated with random access procedures as part of the SON framework. This information can be included in random access reports, RLF reports, successful HO reports (SHR), or successful PSCell change / addition reports (SPR), or in SCGFailureInformation or MCGFailureInformation in dual-connectivity scenarios. In current 3GPP specifications, such random access information does not include information about whether a random access procedure is affected by LBT problems (e.g., LBT failure), particularly regarding each transmission attempt of random access messages (e.g., preambles or Msg3). For example, the network cannot retrieve information from the UE about whether a preamble transmission is blocked due to perceived channel busy (e.g., LBT failure), or whether msg3 or msgA transmissions are blocked by LBT.

[0057] This means that if the network doesn't know which preambles are blocked by LBTs, it cannot determine whether power has been increased from one attempt to another. This is because, according to the MAC specification (TS 38.321), power is only increased for a preamble if the previous preamble transmission was not blocked by LBTs (in other words, if the previous transmission attempt of the preamble had a successful LBT). Conversely, if the previous preamble was blocked by LBTs (in other words, the previous transmission attempt of the preamble had a failed LBT), no power is increased. This means that if the network doesn't know whether a preamble is blocked by LBTs, it cannot know the power used for a particular preamble transmission.

[0058] Specifically, Section 5.1.3 of 3GPP TS 38.321 v17.4.0 (2023-03) states:

[0059] For each random access preamble, the MAC entity should:

[0060] 1> If PREAMBLE_TRANSMISSION_COUNTER is greater than 1; and

[0061] 1> If a notification to pause the power boost counter has not yet been received from the lower layer; and

[0062] 1> If no LBT failure indication for the last random access preamble transmission is received from the lower layer; and

[0063] 1> If the selected SSB or CSI-RS has not changed from the selection in the last random access preamble transmission:

[0064] 2> Then increment PREAMBLE_POWER_RAMPING_COUNTER by 1.

[0065] Figure 2 An example of power boosting for UEs performing RA in SSB1 and SSB2 is shown.

[0066] exist Figure 2 In the example, the UE performs RA in the first SSB (SSB1) and the second SSB (SSB2), some of which preamble transmissions pass through the LBT (indicated by arrows), while others do not pass through the LBT (indicated by circles at the ends of the line segments):

[0067] In SSB1, the UE increases power twice: once after the first attempt (i.e., for the second attempt) and once after the third attempt (i.e., for the fourth failed attempt). After the second failed attempt, the UE switches to SSB2, and it remains... The same power for the fourth attempt However, if the UE does not record any information about the failed RA attempts in chronological order, and only indicates that there have been two successful attempts in SSB1 and one attempt in SSB2, then the network will assume that the power used in the first attempt in SSB2 is the same as that used in SSB1. The same for the third attempt power This is incorrect.

[0068] One approach is to report each transmission attempt of a random access message (including those blocked by the LBT) as part of the random access information. However, in unlicensed systems, the total number of attempted random access transmissions may be higher than in licensed systems because, when configuring the LBT failure recovery configuration (obtained in LBT-FailureRecoveryConfig-r16 IE in RRC), random access preambles blocked due to LBT failures are not counted as MAC layer random access preamble transmission attempts; only random access preambles that pass through the LBT (i.e., successful over-the-air transmissions) are counted (by the MAC layer preamble transmission counter). Therefore, if the UE includes every individual transmission attempt of a random access message (both failed and those that pass through the LBT) in the random access information, the overhead (e.g., report size) of the reports transmitted to the network (i.e., RA reports, RLF reports, SHR) may increase significantly, even risking exceeding the maximum number of RA attempts that can be included in the RA report (which is 200).

[0069] Certain aspects of this disclosure and its embodiments may provide solutions to these or other challenges.

[0070] The first method proposed in this paper provides a mechanism for a UE to include a first set of information in its random access information associated with each successful LBT attempt for that UE. Information associated with each unsuccessful LBT attempt for that UE can be retrieved from the first set of information. For example, the UE may report the first set of information associated with each successful LBT attempt for that UE, depending on whether the UE is configured with an LBT failure recovery configuration (i.e., LBT-FailureRecoveryConfig-r16 IE). In a non-limiting example, the UE will only execute the first method during the random access procedure if the LBT failure recovery configuration has been configured by the network.

[0071] The second method proposed in this paper provides a mechanism for the UE to report the total number of preamble transmission attempts for each random access procedure in the random access information, i.e., the total number of preamble transmission attempts that passed the LBT check and the total number of preamble transmission attempts that failed the LBT check. For example, depending on whether the UE is configured with LBT failure recovery, the UE can report the total number of preamble transmission attempts for each random access procedure in the random access information, i.e., the total number of preamble transmission attempts that passed the LBT check and the total number of preamble transmission attempts that failed the LBT check. In a non-limiting example, the UE executes the second method only when the LBT failure recovery configuration is not configured during the execution of the random access procedure. In a variation of the second method, the UE may report a series of information in the random access information, which includes, in chronological order: a first value indicating the number of consecutive preamble transmissions that passed the LBT check (or alternatively failed the LBT check), followed by a second value indicating the number of consecutive preamble transmissions that failed the LBT check (or alternatively passed the LBT check), followed by a third value having the same purpose as the first value, a fourth value having the same purpose as the second value, and so on.

[0072] The third method proposed in this paper provides a mechanism for the UE to include an indication of whether the UE was configured with LBT failure recovery parameters (i.e., LBT-FailureRecoveryConfig-r16 IE) before the time of the random access preamble transmission attempt. For example, the UE may not record any explicit indication of whether LBT-FailureRecoveryConfig-r16 IE was configured. Information from each random access attempt can implicitly indicate whether the UE was configured with LBT-FailureRecoveryConfig-r16 IE. In a non-limiting example, if the UE does not include the number of LBT failures in successful attempts (as described in the first method), this means that the UE was not configured with LBT-FailureRecoveryConfig-r16 IE, or at least LBT failure recovery was not applied during the random access procedure. In a variation of the third method, the UE may record the number of failed preamble transmissions prior to a continuous LBT failure.

[0073] The fourth approach proposed in this paper provides a mechanism for the UE to include a set of information related to an LBT failure experienced after the last successful LBT transmission attempt before changing the beam (SSB or CSI-RS) used for preamble transmission.

[0074] Therefore, according to some embodiments, a method performed by a user equipment is provided. The method includes sending random access information related to a random access procedure to a network node, the random access information including a fourth indication indicating whether, prior to selecting a second beam for preamble transmission in the random access procedure, there has been at least one failed transmission attempt of the random access preamble experienced after the last successful transmission attempt in the first beam.

[0075] According to some embodiments, a method performed by a network node is provided. The method includes receiving random access information related to a random access procedure from a user equipment (UE), the random access information including a fourth indication indicating whether, prior to the UE selecting a second beam for preamble transmission during the random access procedure, there has been at least one failed transmission attempt of the random access preamble experienced by the UE after the last successful transmission attempt of the random access preamble by the UE in a first beam.

[0076] According to some embodiments, a user equipment is provided, including processing circuitry and a memory. The memory stores instructions executable by the processing circuitry, thereby enabling the user equipment to send random access information related to a random access procedure to a network node. This random access information includes a fourth indication indicating whether, prior to selecting a second beam for preamble transmission during the random access procedure, there has been at least one failed transmission attempt of the random access preamble after the last successful transmission attempt in the first beam.

[0077] According to some embodiments, a user equipment is provided. The user equipment is adapted to send random access information related to a random access procedure to a network node. This random access information includes a fourth indication indicating whether, prior to selecting a second beam for preamble transmission in the random access procedure, there has been at least one failed transmission attempt of the random access preamble after the last successful transmission attempt in the first beam.

[0078] According to some embodiments, a network node is provided, including processing circuitry and a memory. The memory stores instructions executable by the processing circuitry, thereby enabling the network node to operate to receive random access information related to a random access procedure from a user equipment. This random access information includes a fourth indication indicating whether, prior to the user equipment selecting a second beam for preamble transmission during the random access procedure, there has been at least one failed transmission attempt of the random access preamble experienced by the user equipment after the last successful transmission attempt of the random access preamble by the user equipment in the first beam.

[0079] According to some embodiments, a network node is provided. The network node is adapted to receive random access information related to a random access procedure from a user equipment (UE), the random access information including a fourth indication indicating whether, before the UE selects a second beam for preamble transmission during the random access procedure, there has been at least one failed transmission attempt of the random access preamble experienced by the UE after the last successful transmission attempt of the random access preamble by the UE in a first beam.

[0080] Some embodiments may provide one or more of the following technical advantages.

[0081] This minimizes or reduces the overhead required for transmitting random access information related to failed random access transmission attempts. Nevertheless, the network can retrieve random access information in chronological order of each transmission attempt of the random access message, regardless of whether the LBT was successful for that transmission attempt. The network can also determine whether a power boost was performed after a failed random access transmission attempt.

[0082] In some embodiments, the overhead required for the UE to report is reduced, but by using the embodiments described herein, the network will still be able to estimate the transmission power used by the UE for RA preamble transmission attempts. Based on the information provided, the network may be able to adjust / optimize its PRACH configuration, such as the preamble receive target power. Attached Figure Description

[0083] To better understand the embodiments of this disclosure, and to illustrate how the embodiments can be implemented, reference will now be made to the accompanying drawings by way of example only, wherein:

[0084] Figure 1 The derivative relationship of self-configuration / self-optimization functions is shown (from 3GPP TS 36.300 Figure 22.1-1);

[0085] Figure 2 This is an example of a power boosting RA performed by a UE in SSB1 and SSB2;

[0086] Figure 3 This is a flowchart illustrating a method according to some embodiments;

[0087] Figure 4 This is a flowchart illustrating a method according to some embodiments;

[0088] Figure 5 This is a flowchart illustrating a method according to some embodiments;

[0089] Figure 6 This is a flowchart illustrating a method according to some embodiments;

[0090] Figure 7 This is a flowchart illustrating a method according to some embodiments;

[0091] Figure 8 This is a flowchart illustrating a method according to some embodiments;

[0092] Figure 9 Examples of communication systems according to some embodiments are shown;

[0093] Figure 10 A UE according to some embodiments is shown;

[0094] Figure 11 A network node according to some embodiments is shown; and

[0095] Figure 12 This is a block diagram illustrating a virtualized environment in which functions implemented by some embodiments can be virtualized. Detailed Implementation

[0096] Some embodiments of the ideas contemplated herein will now be described more fully with reference to the accompanying drawings. The embodiments are provided by way of example in order to convey the scope of the subject matter to those skilled in the art.

[0097] When the channel is not perceived as busy (i.e., the power detected in the channel is less than the energy detection period for a certain period of time), the LBT is considered successful. The LBT process used to transmit random access messages (e.g., preamble, msg3, or msgA transmission) is considered a successful transmission attempt.

[0098] When the channel is perceived to be busy (i.e., the power detected in the channel is greater than the energy detection period for a certain period of time), the LBT is considered unsuccessful / failed. The LBT process used to transmit random access messages (e.g., preamble, msg3, or msgA transmission) is regarded as an unsuccessful transmission attempt.

[0099] In this document, the term "successful transmission attempt of a random access message" indicates that the LBT check for it was successful (for the random access message (e.g., random access preamble, Msg3, or MsgA)). This means the UE sent the specific random access message via the air interface. However, the random access procedure may still fail later due to factors such as random access response window expiration or unsuccessful contention resolution.

[0100] In this document, the term "unsuccessful (or failed) transmission attempt of random access message" indicates that the LBT check for it was unsuccessful (random access message (e.g., random access preamble or Msg3)) random access transmission attempt, i.e., the UE did not send the specific random access preamble over the air interface due to the detected busy channel.

[0101] This document describes a method for a UE to include information in a random access information report. The random access information report may be included in one of the following: a random access report (RA-Report), an RLF report (RLF-Report), a successful HO report (SHR), a successful primary / secondary cell (PSCell) addition or change report, a primary cell group (MCG) failure message, and a secondary cell group (SCG) failure message.

[0102] The method disclosed herein applies to situations where the random access resource selected for random access is associated with either an SSB or a CSI-RS.

[0103] Figure 3 A method according to certain embodiments is shown.

[0104] Figure 3 A method according to a specific embodiment is described. Method 3 can be performed by a UE or a wireless device (e.g., referred to separately later). Figure 9 and 10 This method is performed by UE 912 or UE 1000 as described. It can be used to provide random access information to a network node. The method begins at step 302, sending random access information related to a first random access procedure to the network node, the random access information including one or more of the following: a first indication of a successful transmission attempt of a random access message, the first indication having an associated indication of the number of consecutive failed transmission attempts of the random access message prior to the successful transmission attempt of the random access message, and a second indication of the total number of transmission attempts of the random access message.

[0105] Figure 4 A method according to certain embodiments is shown.

[0106] Figure 4 A method according to a specific embodiment is described. Method 4 can be performed by network nodes (e.g., referred to separately later). Figure 9 and Figure 11 The method is performed by network node 910 or network node 1100 as described. The method begins at step 402, receiving random access information related to a first random access procedure from user equipment (UE), the random access information including one or more of the following: a first indication of a successful transmission attempt of a random access message, the first indication having an associated indication of the number of consecutive failed transmission attempts of random access messages experienced by the user equipment prior to the successful transmission attempt of the random access message, and a second indication of the total number of transmission attempts of random access messages.

[0107] In some examples, the first indication in method 3 or 4 includes a list of multiple successful transmission attempts for the corresponding random access message. The first set of information may be considered to include the first indication and associated indications. For each successful transmission attempt of the corresponding random access message, the associated indication may include a first field indicating the number of consecutive failed transmission attempts experienced prior to the successful transmission attempt of the corresponding random access message.

[0108] It is understood that if the first field for a particular successful transmission attempt is missing, this can indicate that no failed transmission of the corresponding random access message was experienced prior to the successful transmission of the corresponding random access message. Multiple successful transmission attempts can be listed in chronological order of the attempts.

[0109] In some examples, the UE may depend on whether the UE is configured with LBT failure recovery, including an associated indication associated with the first indication. In a non-limiting example, the UE performs step 302 only if the network has configured LBT failure recovery when the UE performs the random access procedure.

[0110] For example, Figure 3 or Figure 4 The method may include: in response to the network configuring a Listen-After-Talk (LBT) failure recovery configuration at the UE when the UE performs the first random access procedure, performing the steps of sending (or receiving) random access information.

[0111] In another example, Figure 3 or Figure 4 The method may include: in response to the failure of the network to restore the Listen-After-Talk (LBT) configuration at the UE when the UE performs the first random access procedure, performing the steps of sending (or receiving) random access information.

[0112] It is understood that the random access message in step 302 or 402 may include one of the following: a random access preamble, MsgA, and Msg3. The list of multiple successful transmission attempts may include a mixture of successful transmission attempts: one or more random access preambles, one or more MsgA, and one or more Msg3. In other words, for example, where method 3 involves reporting the number of consecutively failed transmission attempts due to LBT failure, method 3 or 4 may involve sending an attempt to send Msg3 or MsgA during the random access process, instead of an attempt to send a random access preamble, or an attempt to send a random access preamble simultaneously. Attempts to send a random access preamble and attempts to send Msg3 or MsgA may be mixed in the same random access information (e.g., the same random access information sent in step 302 or received in step 402).

[0113] In some embodiments, random access information may be included in the RA report (e.g., RA-Report-r16IE).

[0114] In some embodiments, random access information may be included in the RLF report (e.g., RLF-Report-r16IE).

[0115] exist Figure 3 or Figure 4 In some examples of this method, the UE is configured with an LBT failure recovery configuration, such as LBT-FailureRecoveryConfig. In another method, the UE is not configured with an LBT failure recovery configuration, such as LBT-FailureRecoveryConfig.

[0116] In some examples, Figure 3 or Figure 4The second indication of the method includes a second field indicating the total number of random access transmission attempts for the first random access procedure in the selected beam, the total number counting both successful transmission attempts and failed transmission attempts of random access messages.

[0117] In some examples, the UE includes a second indication in the random access information, depending on whether the UE is configured with LBT failure recovery. In non-restrictive examples, the UE includes the second indication only if the LBT failure recovery configuration is not configured when initiating the random access procedure.

[0118] A second indication of the total number of transmission attempts of random access messages in the first random access procedure may include a series of information, which, in chronological order, includes: a first information element indicating the number of consecutive successful transmission attempts of random access messages; and a second information element indicating the number of consecutive failed transmission attempts of random access messages.

[0119] For example, the second indication may include a first value indicating the number of consecutive preamble transmissions that passed the LBT check (or alternatively, failed the LBT check), followed by a second value indicating the number of consecutive preamble transmissions that failed the LBT check (or alternatively, passed the LBT check), followed by a third value having the same purpose as the first value, a fourth value having the same purpose as the second value, and so on. In other words, the first information element may include the first value, and the second information element may include the second value.

[0120] In some examples, the second indication includes, in chronological order: a series of values ​​indicating preamble transmissions that passed the LBT check; followed by a second value indicating the number of consecutive preamble transmissions that failed the LBT check since the last successful preamble transmission; followed by a series of values ​​indicating preamble transmissions that passed the LBT check; followed by a fourth value indicating the number of consecutive preamble transmissions that failed the LBT check since the last successful preamble transmission, and so on. For example, the first information element may include a series of first values, and the second information element may include second values.

[0121] It is understandable that the second instruction can begin with either the first or the second information element.

[0122] For example, the second indication may include a series of information in chronological order, including: a value indicating the number of consecutive preamble transmissions that failed the LBT check, a value indicating the consecutive values ​​of preamble transmissions that passed the LBT check, followed by a value indicating the number of consecutive preamble transmissions that failed the LBT check since the last successful preamble transmission, and so on.

[0123] Understandable. Figure 3 and Figure 4 The random access information in the method may further include a third indication to indicate the number of consecutive successful transmission attempts for random access messages for which the LBT failure indication was not received by the lower layer. For example, the third indication may include a modification to the numberOfPreamblesSentOnSSB field such that it lists only transmission attempts for which the LBT failure indication was not received by the lower layer.

[0124] It is understandable that the UE can be configured with an LBT failure recovery configuration, i.e., LBT-FailureRecoveryConfig. Alternatively, the UE can be configured without an LBT failure recovery configuration, i.e., LBT-FailureRecoveryConfig.

[0125] Figure 5 Methods according to some embodiments are shown.

[0126] Figure 5 A method according to a particular embodiment is described. Figure 5 The method can be performed by the UE or a wireless device (e.g., see references later). Figure 9 and 10 The method is performed by the UE 912 or UE 1000 described. This method can be used to provide random access information to a network node. The method begins at step 502, sending random access information to the network node, which includes an indication of whether the UE is configured with a Listen-After-Talk (LBT) failure recovery configuration at one of the following: the time of the random access preamble transmission attempt or the time of initiating the random access procedure.

[0127] Figure 6 Methods according to some embodiments are shown.

[0128] Figure 6 A method according to a particular embodiment is described. Figure 6 The method can be used by network nodes (e.g., see later for details). Figure 9 and 11 The method is performed by network node 910 or network node 1100 as described. The method begins at step 602, whereby random access information is received from the user equipment, which includes an indication of whether the UE is configured with a Listen-Before-Talk (LBT) failure recovery configuration at one of the following: the time of the random access preamble transmission attempt or the time of initiating the random access procedure.

[0129] Figure 5 and Figure 6The method provides a mechanism for the UE to include a third field (e.g., an indication in step 502 or 602) indicating whether the UE is configured with LBT failure recovery parameters (i.e., LBT-FailureRecoveryConfig-r16IE) at the time of the random access preamble transmission attempt or alternatively at the time of initiating the random access procedure. In one approach, the indication is included in RA-InformationCommon-r16 IE; in another approach, it is included in RA-Report-r16 IE, or in RLF-Report-r16 IE, or in SHR (e.g., SuccessHO-Report-r17 IE).

[0130] In some examples, Figure 5 The method further includes recording the number of failed transmission attempts of the random access message prior to the persistent LBT failure. In other words, the UE can record the number of failed preamble transmission attempts prior to the persistent LBT failure. Optionally, this can be extended to also include recording the number of failed Msg3 transmission attempts prior to the persistent LBT failure.

[0131] In some embodiments, the first indication and its associated indication or second indication of method 3 or 4 are included in the random access information only if the indication related to LBT-FailureRecoveryConfig-r16 in method 5 or 6 is set to true. In some embodiments, the indication related to LBT-FailureRecoveryConfig-r16 is not explicitly set, but the conditional inclusion of the first indication and its associated indication and / or the second indication implies the presence of LBT-FailureRecoveryConfig-r16.

[0132] Some embodiments involve situations where the first random access procedure fails and ultimately leads to a radio link failure declaration at the UE. Therefore, it is necessary to include the random access information reported to the network as feedback in the RLF report, rather than in the random access report itself. In such embodiments, as an option, when the LBT failure information reported by the UE is related to an RLF, i.e., the LBT failure information is included in the RLF report (e.g., RLF-Report-r16 IE), for example, when the UE has declared an RLF after a failed RA procedure due to persistent LBT failures in all BWPs of the bandwidth supported in the cell, the UE can indicate the total number of LBT failures detected in multiple bandwidth portions (BWPs), or the number of LBT failures per BWP.

[0133] exist Figure 4In this context, the network node can determine the number of consecutive failed transmission attempts (due to LBT failures) prior to each successful transmission attempt performed by the UE, based on a first field (e.g., an associated indication). Furthermore, the network can determine a first value, which may include the sum of the number of consecutive failures prior to each successful transmission attempt. Therefore, the first value may include the number of failed attempts performed during the first random access procedure prior to the last successful transmission attempt. total .

[0134] exist Figure 4 In this context, the network node can determine the second value based on the second field (e.g., the second indication), which is the total number of transmission attempts performed by the UE.

[0135] Furthermore, by taking the difference between the first and second values, the network can calculate a third value. Network nodes can then use this third indicator, such as `numberOfPreamblesSentOnSSB`, which can be modified to indicate the total number of successful transmission attempts. The difference between the third value and the third indicator can then give the last successful random access transmission attempt experienced during the RA procedure for BWP. after The number of failed random access transmission attempts experienced by the UE.

[0136] Consider the following example, where it is assumed that the UE performs RA in a selected beam (e.g., SSB1), where 1 indicates that the LBT for it is a successful preamble transmission attempt (but the preamble transmission attempt fails due to, for example, contention resolution failure), and 0 indicates that the LBT for it is an unsuccessful preamble transmission attempt:

[0137] SSB1: 0 0 0 1 1 0 0 1 0 0

[0138] Based on the first field (e.g., the associated indication) included by the UE in the random access information in step 302 or 402, the network can determine that the UE experienced three consecutive LBT failures in the RA preamble before the first successful transmission and two failures before the third successful transmission. The network can also determine that the UE experienced a total of five failures (e.g., the first value) before the last successful transmission attempt.

[0139] Based on the second field (e.g., the second indication), the network can determine that the UE experienced a total of 10 transmission attempts (e.g., the second value). The third indication can indicate that 3 transmission attempts were successful, and therefore the network can determine that 7 failed transmission attempts occurred during the RA process in the selected beam. Therefore, the network can determine that the UE experienced 7-5 LBT failures after the last successful transmission attempt.

[0140] refer to Figure 5 and Figure 6 This method allows the network to determine whether the UE performed a preamble power boost after a random access transmission attempt. If LBT-FailureRecoveryConfig-r16 IE is configured, the network determines that no power boost was performed after a failed random access preamble transmission attempt (due to LBT failure). Otherwise, if LBT-FailureRecoveryConfig-r16 IE If not configured, the network determines that a power boost is performed after each failed random access preamble transmission.

[0141] in other words, Figure 6 The method may also include: in response to an indication that the UE is configured with a Listen-After-Talk LBT failure recovery configuration at one of the following: the time of the random access preamble transmission attempt or the time of initiating the random access procedure, determining that the UE did not perform a power boost after the failed transmission attempt of the random access preamble.

[0142] Figure 6 The method may also include: in response to an indication that the UE is not configured to resume the Listen-After-Talk LBT configuration in one of the following: the time of the random access preamble transmission attempt or the time of initiating the random access procedure, determining that the UE performed a power boost after the failed transmission attempt of the random access preamble.

[0143] Figure 7 A method according to certain embodiments is shown.

[0144] Figure 7 A method according to a particular embodiment is described. Figure 7 The method can be performed by the UE or a wireless device (e.g., referred to separately later). Figure 9 and 10 This method is performed by UE 912 or UE 1000 as described. It can be used to provide random access information to a network node. The method begins at step 702, sending random access information related to a random access procedure to the network node. This random access information includes a fourth indication relating to the number of failed transmission attempts of the random access preamble experienced after the last successful transmission attempt of the random access preamble in the first beam, prior to the selection of the second beam for preamble transmission in the random access procedure. For example, the fourth indication could indicate whether there have been at least one failed transmission attempt of the random access preamble experienced after the last successful transmission attempt of the random access preamble in the first beam, prior to the selection of the second beam for preamble transmission in the random access procedure.

[0145] Figure 8 A method according to certain embodiments is shown.

[0146] Figure 8 A method according to a particular embodiment is described. Figure 8 The method can be used by network nodes (e.g., see later for details). Figure 9 and 11 The method is executed by network node 910 or network node 1100 as described. The method begins at step 802, receiving random access information related to the random access procedure from the user equipment. This random access information includes a fourth indication relating to the number of failed transmission attempts of the random access preamble experienced by the user equipment in the first beam after the last successful transmission attempt of the random access preamble made by the user equipment, prior to the user equipment selecting a second beam for preamble transmission in the random access procedure. For example, the fourth indication could indicate whether there were at least one failed transmission attempt of the random access preamble experienced after the last successful transmission attempt of the random access preamble in the first beam before the second beam was selected for preamble transmission in the random access procedure.

[0147] Figure 7 and Figure 8 The method provides a mechanism for the UE to include a fourth indication related to an LBT failure experienced after a previous successful LBT transmission attempt in the first beam (SSB or CSI-RS) prior to the selection of a second beam (SSB or CSI-RS) for preamble transmission in the same RA procedure. The fourth indication may include one or more of the following:

[0148] - A flag indicating whether, before selecting the second beam (SSB or CSI-RS) for preamble transmission, there has been at least one failed LBT preamble transmission attempt since the last successful LBT transmission attempt for the first beam (SSB or CSI-RS). For example, the fourth indication in step 702 or 802 could indicate whether there has been at least one failed transmission attempt for the random access preamble since the last successful transmission attempt.

[0149] - A flag indicating whether the last preamble transmission attempt in the first beam (SSB or CSI-RS) was successful according to the LBT procedure before switching to the second beam (SSB or CSI-RS). For example, the fourth indication in step 702 or 802 could indicate whether the last successful transmission attempt of the random access preamble was the last transmission attempt of the random access preamble before the selection of the second beam.

[0150] - A field indicating the number of consecutive LBT preamble failures following the last successful preamble transmission attempt in the first beam (SSB or CSI-RS) before selecting the second beam (SSB or CSI-RS) for preamble transmission. For example, the fourth indication in step 702 or 802 could indicate the number of consecutive failed transmission attempts of the random access preamble following the last successful transmission attempt.

[0151] In one embodiment, the fourth instruction described above can be included in the LBT failure recovery configuration.

[0152] For example, a UE can include the fourth instruction mentioned above in, for example, an RA report only if the LBT failure recovery configuration is configured. In other words, a UE can perform step 702 in response to the network configuring the listen-before-talk LBT failure recovery configuration at the UE during the UE's random access procedure.

[0153] In another embodiment, the UE includes the fourth instruction described above in, for example, the RA report only if the LBT failure recovery configuration is not configured and the UE does not perform an LBT failure recovery operation. In other words, the UE may perform step 702 in response to the network not configuring the listen-before-talk LBT failure recovery configuration at the UE during the UE random access procedure.

[0154] Alternatively, the UE can include a fourth indication regardless of whether the LBT failure recovery configuration is configured.

[0155] Figure 8 The method may also include network nodes estimating the preamble transmission power for each RA preamble transmission for which their UE has not experienced any LBT problems. For example, if a fourth indication associated with the last successful transmission attempt for the random access preamble (e.g., the LBT for it was successful in the first selected beam) indicates that there has been at least one failed transmission attempt for the preamble since the last successful transmission attempt in the first beam, the network can determine that the power used for the first preamble transmission for which the LBT was successful in the second beam has been increased relative to the last successful transmission attempt in the first beam.

[0156] Otherwise, if the fourth indication indicates that no failed transmission attempt has occurred since the last successful transmission attempt of the preamble in the first beam, then since no power increase occurs when the UE switches beams, the network determines that the power used by the first successful transmission attempt of the preamble in the second beam is the same as the power used by the last successful transmission attempt in the first beam.

[0157] Therefore, the network can determine the total number of power ramps performed by the UE before successfully completing a random access procedure or before a failed random access procedure (i.e., RLF or HOF). Consequently, the network may change certain parameters of the RACH configuration, such as the preambleReceivedTargetPower and the power ramping step for PRACH.

[0158] The ASN.1 code in 38.331 and in section 5.7.10.5 Figure 3 and Figure 4 Example implementation of the method:

[0159] In this example, the random access information includes a first indication and its associated indication, but does not include a second indication.

[0160] For each successful random access attempt performed on the selected beam, an entry is included in perRAAttemptInfoList in chronological order of the attempt. The entry contains a first set of information, which includes at least the field (numberOfSuccessiveLBTFailures), which indicates the number of consecutive random access preamble transmission failures experienced prior to this successful random access transmission attempt.

[0161] The method can be applied to both SSB-based random access and CSI-RS scenarios.

[0162] The baseline is 38.331 v17.4.0, and the new parts are marked with an underline:

[0163] RA-InformationCommon-r16 ::=SEQUENCE {

[0164] [...]

[0165] ]], [[

[0167] numberOfSuccessiveLBTFailuresOnSSBINTEGER (1..200) OPTIONAL]]

[0168] }

[0169] 5.7.10.5 RA Information Determination

[0170] The UE should configure the contents of ra-InformationCommon as follows:

[0171] 1>[…]

[0172] 3> In perRAInfoList, set the parameters associated with the individual random access attempts in chronological order, as shown below. In addition to random access attempts that receive an LBT failure indication from the lower layer, :

[0173] 2> If the random access resource used is associated with an SS / PBCH block, set the associated random access parameters for consecutive random access attempts associated with the same SS / PBCH block used for one or more random access attempts, as follows:

[0174] 3> Configure ssb-Index to include the SS / PBCH block index associated with the random access resources used;

[0175] 3> Set numberOfPreamblesSentOnSSB to indicate the number of consecutive random access attempts associated with an SS / PBCH block;

[0176] 3> For each random access attempt performed on the random access resource, In addition to receiving it from the lower layer LBT failure indication random access attempt The parameters, ordered by the time sequence of random access attempts, include the following:

[0177] [...]

[0178] 6> Set dlRSRPAboveThreshold to false;

[0179] 4> Set the numberOfSuccessiveLBTFailuresOnSSB parameter to indicate the association with the SS / PBCH block. The number of consecutive random access attempts received from the lower layer for an LBT failure indication;

[0180] 2> Otherwise, if the random access resource used is associated with a CSI-RS, set the associated random access parameters for consecutive random access attempts associated with the same CSI-RS used for one or more random access attempts, as follows:

[0181] 3> Set the csi-RS-Index parameter to include the CSI-RS index associated with the random access resource used;

[0182] 3> Set numberOfPreamblesSentOnCSI-RS to indicate the number of consecutive random access attempts associated with CSI-RS.

[0183] Note 1: Empty.

[0184] In ASN.1 code in 38.331 and in section 5.7.10.5 for UE (device) Figure 3 Second example implementation of the method:

[0185] In this example, the random access information includes a second indication. For each random access procedure performed in the selected beam of the BWP, the UE includes both the number of random access attempts performed by the UE and the count of failed and successful random access preamble transmission attempts.

[0186] The baseline is 38.331 v17.4.0, and the new parts are marked with an underline:

[0187]

[0188] 5.7.10.5 RA Information Determination

[0189] The UE should configure the contents of ra-InformationCommon as follows:

[0190] [...]

[0191] 3> Set numberOfPreamblesSentOnSSB to indicate the number of consecutive random access attempts associated with an SS / PBCH block. For this continuous random access attempt, the lower layer did not receive an LBT failure indication. ;

[0192] 3> Set numberOfPreambleAttemptsOnSSB to indicate the consecutive preambles associated with the SS / PBCH block. The number of machine access attempts;

[0193] 3> For each random access attempt performed on a random access resource, the following parameters are included in the chronological order of the random access attempts:

[0194] [...]

[0195] In section 5.7.10.5 of 38.331, the ASN.1 code... Figure 5 or Figure 6 Example implementation of the method:

[0196] In this example, the third field (such as the indication of step 501 or 601) can be represented by a Boolean value or an enumerated value, as shown below, where the third field is set if the UE is configured for LBT failure recovery (lbt-FailureRecoveryConfig).

[0197] In some embodiments, this Boolean value is included according to the UL BWP associated with the RA procedure. An advantage of this embodiment is that the UE provides detailed instructions regarding the configuration related to lbt-FailureRecoveryConfig only when only some UL BWP configurations may contain lbt-FailureRecoveryConfig.

[0198] In some other embodiments, this Boolean value is included only once per RA process.

[0199] The baseline is 38.331 v17.4.0, and the new parts are... underline Marked:

[0200]

[0201] In ASN.1 code 38.331 and in section 5.7.10.5 Figure 3 and Figure 4 The methods and Figure 5 and Figure 6 Example implementation of a combination of methods in the code:

[0202] In this example, the UE only includes a first indication and associated indication in the random access information if the UE is configured with LBT failure recovery (lbt-FailureRecoveryConfig). (That is, for each successful random access attempt performed on the selected beam, an entry is included in perRAAttemptInfoList in chronological order of the attempt, where the entry contains a first set of information, which at least includes the field (numberOfSuccessiveLBTFailures), indicating the number of consecutive random access preamble transmission failures experienced before this successful random access transmission attempt.) In other words, when the UE is not configured with lbt-FailureRecoveryConfig, the UE will not include any new parameters in the RA information.

[0203] The baseline is 38.331 v17.4.0, and the new parts are... underline Marked:

[0204]

[0205] 5.7.10.5 RA Information Determination

[0206] The UE should configure the contents of ra-InformationCommon as follows:

[0207] 3> 1>[…] Set the parameters associated with individual random access attempts in perRAInfoList in chronological order of the attempts, as shown below, In addition to random access attempts that receive an LBT failure indication from the lower layer, :

[0208] 2> If the random access resource used is associated with an SS / PBCH block, set the associated random access parameters for consecutive random access attempts associated with the same SS / PBCH block used for one or more random access attempts, as follows:

[0209] 3> Configure ssb-Index to include the SS / PBCH block index associated with the random access resources used;

[0210] 3> Set the numberOfPreamblesSentOnSSB parameter to indicate the number of consecutive random access attempts associated with the SS / PBCH block;

[0211] 3> For each random access attempt performed on the random access resource, In addition to receiving it from the lower layer LBT failure indication random access attempt The parameters, ordered by the time sequence of random access attempts, include the following:

[0212] 4> If the random access attempt is performed on a contention-based random access resource and raPurpose is not equal to "requestForOtherS", then contentionDetected is included, as follows:

[0213] 5> If contention resolution fails, as specified in TS 38.321 [6] for the transmitted preamble:

[0214] 6> Set contentionDetected to true;

[0215] 5> Otherwise:

[0216] 6> Set contentionDetected to false;

[0217] 4> If the random access attempt is a two-step random access attempt:

[0218] 5> If a fallback from two-step random access to four-step random access occurs during a random access attempt:

[0219] 6> Set fallbackToFourStepRA to true;

[0220] 4> If the random access attempt is performed on contention-based random access resources; or

[0221] 4> If the random access attempt is performed on a non-contentionable random access resource, and if the random access procedure is initiated due to PDCCH ordering:

[0222] 5> If the random access attempt is a four-step random access attempt, and the SS / PBCH block RSRP of the SS / PBCH block corresponding to the random access resource used in the random access attempt is higher than rsrp-ThresholdSSB; or

[0223] 5> If the random access attempt is a two-step random access attempt, and the SS / PBCH block RSRP of the SS / PBCH block corresponding to the random access resource used in the random access attempt is higher than msgA-RSRP-ThresholdSSB:

[0224] 6> Then set dlRSRPAboveThreshold to true;

[0225] 5> Otherwise:

[0226] 6> Set dlRSRPAboveThreshold to false;

[0227] 4> If lbt-FailureRecoveryConfig is configured for the UL bandwidth portion associated with RA resources:

[0228] 5> Then set numberOfSuccessiveLBTFailuresOnSSB to indicate the number of failures associated with the SS / PBCH block. The number of consecutive random access attempts received from the lower layer for an LBT failure indication;

[0229] 2> Otherwise, if the random access resource used is associated with a CSI-RS, set the associated random access parameters for consecutive random access attempts associated with the same CSI-RS used for one or more random access attempts, as follows:

[0230] 3> Configure the csi-RS-Index to include the CSI-RS index associated with the random access resources used;

[0231] 3> Set numberOfPreamblesSentOnCSI-RS to indicate the number of consecutive random access attempts associated with CSI-RS.

[0232] Note 1: Empty.

[0233] In ASN.1 code 38.331 and section 5.7.10.5 for UE devices Figure 7 and Figure 8 Example implementation of the method

[0234] In this method, the UE reports a fourth indication (e.g., a fourth field) that relates to the number of LBT failures experienced after the last successful preamble transmission attempt in the first beam (SSB or CSI-RS) before changing the beam (SSB or CSI-RS) used for preamble transmission, i.e. before selecting a second beam (SSB or CSI-RS) for preamble transmission in the same RA procedure.

[0235] Consider an example where, for a Re-Action (RA) procedure, the UE performs the RA in the first selected beam SSB1, then it switches to the second beam SSB2 for the RA, then it switches again to the third beam SSB3, and finally switches to the fourth beam SSB4, where the UE successfully completes the RA.

[0236] The 1 below indicates that the LBT for it was a successful preamble transmission attempt (but could not be completed due to, for example, a contention resolution failure), and the 0 below indicates that the LBT for it was an unsuccessful preamble transmission attempt:

[0237] SSB1: 1 0 0 1 0 0

[0238] SSB2: 1 0 0 1 0 0 0

[0239] SSB3:1

[0240] SSB4:1

[0241] So Figure 7 and Figure 8 The method means that the UE reports a fourth indication related to the last two failures in SSB1, another fourth indication related to the last three failures in SSB2, and yet another fourth indication related to the failure of LBT after the preamble transmission attempt in SSB3.

[0242] It should be understood that the absence of the field for the fourth indication can be interpreted as an implicit fourth indication, namely, that the number of failed transmission attempts of the random access preamble experienced after a successful transmission attempt of the random access preamble in the first beam before the second beam is selected for preamble transmission during the random access process.

[0243] In one example, if the fourth indication specifies the number of consecutive LBT preamble failures (numberOfLBTFailuresBeforeBeamChange) after the last successful LBT transmission attempt before changing the beam (SSB or CSI-RS) used for preamble transmission, then the UE reports the fourth indication for SSB1 as '2', the fourth indication for SSB2 as '3', and either the UE does not include this field for SSB3 at all (which would be equivalent to an implicit fourth indication), or it includes a value of 0 for SSB3 (an explicit fourth indication).

[0244] In some examples, if the fourth indication includes a flag indicating whether there has been at least one LBT preamble failure (lbtFailuresBeforeBeamChange) since the last successful LBT transmission attempt before changing the beam (SSB or CSI-RS) used for preamble transmission, the UE sets this flag to 'true' for SSB1 and SSB2, and either sets the flag to 'false' for SSB3 (explicit fourth indication), or does not include the flag for SSB3 at all (implicit fourth indication).

[0245] In some examples, if the fourth indication includes a flag indicating whether the last preamble transmission attempt in the first beam (SSB or CSI-RS) was successful according to the LBT procedure (lbtFailureForLastAttemptBeforeBeamChange) before switching to the second beam (SSB or CSI-RS), then the UE will set the flag to 'true' for SSB1 and SSB2, and either set the flag to 'false' for SSB3 (explicit fourth indication), or not include the flag for SSB3 at all (implicit fourth indication).

[0246] In one UE implementation, the UE assigns a fourth indication after a successful preamble transmission of the first LBT in the first beam, and updates the value of the fourth indication after one or more consecutive failed LBT preamble transmissions in the same first beam. If the UE performs a second successful LBT preamble transmission in the same first beam, the UE deletes the aforementioned fourth indication; otherwise, if the UE selects a second beam (SSB or CSI-RS) for RA preamble transmission, the UE stores the value of the fourth indication.

[0247] The stored fourth indication value can be stored in a report that will be sent to the network, such as RLF-Report, RA-Report, SHR, etc.

[0248] The aforementioned fourth instruction can be presented as a field containing information related to the previous successful preamble transmission attempt before the beam (SSB or CSI-RS) used for preamble transmission was changed. This option is represented in the following specification example, where the baseline is 38.331 v17.4.0, and the new section begins with... underline Marked:

[0249] RA-InformationCommon-r16 ::= SEQUENCE {

[0250] [...] [[

[0252] fallbackToFourStepRA-r17 ENUMERATED {true} OPTIONAL

[0253] ]], [[

[0255] numberOfLBTFailuresBeforeBeamChange INTEGER(1..200)OPTIONAL

[0256] lbtFailuresBeforeBeamChange ENUMERATED {true} OPTIONAL

[0257] lbtFailureForLastAttemptBeforeBeamChange ENUMERATED {true} OPTIONAL ]]

[0259] }

[0260] 3> The UE should set the contents of ra-InformationCommon as follows: Set absoluteFrequencyPointA to indicate the absolute frequency of the reference resource block associated with the random access resources used in the random access procedure;

[0261] [...]

[0262] 3> Set onDemandSISuccess to true; In perRAInfoList, set the parameters associated with the individual random access attempts in chronological order of attempt time, as shown below. In addition to receiving an LBT failure for it from the lower layer Indicated random access attempt :

[0263] 2> If the random access resource used is associated with an SS / PBCH block, set the associated random access parameters for consecutive random access attempts associated with the same SS / PBCH block used for one or more random access attempts, as follows:

[0264] 3> Configure ssb-Index to include the SS / PBCH block index associated with the random access resources used;

[0265] 3> Set numberOfPreamblesSentOnSSB to indicate the number of consecutive random access attempts associated with an SS / PBCH block;

[0266] 3> For each random access attempt performed on the random access resource, In addition to receiving it from the lower layer LBT failure indication of random access attempt The parameters, ordered by the time sequence of random access attempts, include the following:

[0267] 4> If the random access attempt is performed on a contention-based random access resource, and if raPurpose is not equal to "requestForOtherS", then contentionDetected is included, as follows:

[0268] 5> If contention resolution is unsuccessful, as specified in TS 38.321 [6] for the transmitted preamble:

[0269] 6> Set contentionDetected to true;

[0270] 5> Otherwise:

[0271] 6> Set contentionDetected to false;

[0272] 4> If the random access attempt is a two-step random access attempt:

[0273] 5> If a fallback from two-step random access to four-step random access occurs during a random access attempt:

[0274] 6> Set fallbackToFourStepRA to true;

[0275] 4> If the random access attempt is performed on contention-based random access resources; or

[0276] 4> If the random access attempt is performed on a contention-free random access resource, and the random access procedure is initiated due to PDCCH ordering:

[0277] 5> If the random access attempt is a four-step random access attempt, and the SS / PBCH block RSRP of the SS / PBCH block corresponding to the random access resource used for the random access attempt is higher than rsrp-ThresholdSSB; or

[0278] 5> If the random access attempt is a two-step random access attempt, and the SS / PBCH block RSRP of the SS / PBCH block corresponding to the random access resource used for the random access attempt is higher than msgA-RSRP-ThresholdSSB:

[0279] 6> Then set dlRSRPAboveThreshold to true;

[0280] 5> Otherwise:

[0281] 6> Set dlRSRPAboveThreshold to false;

[0282] 4> If the random access attempt is the last random access attempt in the SS / PBCH block:

[0283] 5> Set numberOfLBTFailuresBeforeBeamChange to indicate before changes are made for random access. Before the SS / PBCH block of the preamble transmission, the number of consecutive random access attempts receiving LBT failure indications for it from the lower layer. quantity;

[0284] 5> If an LBT failure indication is received from the lower layer for at least one consecutive random access attempt, then... Set lbtFailuresBeforeBeamChange to 'True'.

[0285] 5> If, before altering the SS / PBCH block used for random access preamble transmission, a request is received from a lower layer targeting... If the LBT failure indication of the last random access preamble transmission attempt in the SS / PBCH block is used, then lbtFailureForLastA Set ttemptBeforeBeamChange to 'true'.

[0286] 2> Otherwise, if the random access resource used is associated with a CSI-RS, then for consecutive random access attempts associated with the same CSI-RS used for one or more random access attempts, set the associated random access parameters as follows:

[0287] 3> Configure the csi-RS-Index to include the CSI-RS index associated with the random access resources used;

[0288] 3> Set numberOfPreamblesSentOnCSI-RS to indicate the number of consecutive random access attempts associated with CSI-RS.

[0289] Note 1: Empty.

[0290] In another approach, the fourth indication can be included as a field within the information associated with each beam (SSB or CSI-RS) selected by the UE for the RA. In this case, the fourth indication could indicate an LBT failure associated with the last preamble transmission attempt in which the LBT for a given beam was successful. This option is represented in the following specification example, where the baseline is 38.331 v17.4.0, and the newer parts are underlined:

[0291] RA-InformationCommon-r16 ::= SEQUENCE {

[0292] [...]

[0293] perRAAttemptInfoList-r16 PerRAAttemptInfoList-r16

[0294] numberOfLBTFailuresBeforeBeamChange INTEGER(1..200)OPTIONAL

[0295] lbtFailuresBeforeBeamChange ENUMERATED {true} OPTIONAL

[0296] lbtFailureForLastAttemptBeforeBeamChange ENUMERATED {true} OPTIONAL

[0297] }

[0298] PerRACSI-RSInfo-r16 ::= SEQUENCE {

[0299] csi-RS-Index-r16 CSI-RS-Index,

[0300] numberOfPreamblesSentOnCSI-RS-r16 INTEGER(1..200)

[0301] numberOfLBTFailuresBeforeBeamChangeINTEGER(1..200)OPTIONAL

[0302] lbtFailuresBeforeBeamChange ENUMERATED {true} OPTIONAL

[0303] lbtFailureForLastAttemptBeforeBeamChange ENUMERATED {true} OPTIONAL

[0304] }

[0305] PerRACSI-RSInfo-v1660 ::= SEQUENCE {

[0306] csi-RS-Index-v1660 INTEGER(1..96)OPTIONAL

[0307] }

[0308] PerRAAttemptInfoList-r16 ::= SEQUENCE(SIZE(1..200))OFPerRAAttemptInfo-r16

[0309] PerRAAttemptInfo-r16 ::= SEQUENCE {

[0310] contentionDetected-r16 BOOLEAN OPTIONAL,

[0311] dlRSRPAboveThreshold-r16 BOOLEAN OPTIONAL,

[0312] ..., [[

[0314] fallbackToFourStepRA-r17 ENUMERATED{true} OPTIONAL ]]

[0316] }

[0317] 3> The UE should set the contents of ra-InformationCommon as follows: Set absoluteFrequencyPointA to indicate the absolute frequency of the reference resource block associated with the random access resources used in the random access procedure;

[0318] [...]

[0319] 3> Set onDemandSISuccess to true; in perRAInfoList, set the parameters associated with the individual random access attempts in chronological order of the attempts, as shown below. In addition to receiving an LBT failure indication for it from the lower layer random access attempts :

[0320] 2> If the random access resource used is associated with an SS / PBCH block, set the associated random access parameters for consecutive random access attempts associated with the same SS / PBCH block used for one or more random access attempts, as follows:

[0321] 3> Configure ssb-Index to include the SS / PBCH block index associated with the random access resources used;

[0322] 3> Set numberOfPreamblesSentOnSSB to indicate the number of consecutive random access attempts associated with an SS / PBCH block;

[0323] 3> Set numberOfLBTFailuresBeforeBeamChange to indicate before changes are made for random access. Before the SS / PBCH block of the preamble transmission, in the last random access attempt where no LBT failure indication was received from the lower layer. The number of consecutive random access attempts that receive an LBT failure indication from the lower layer after the attempt;

[0324] 3> If, before modifying the SS / PBCH block for random access preamble transmission, it is not addressed from the lower layers... After receiving the last random access attempt with an LBT failure indication, for at least one consecutive random access attempt, from the lower layer... If an LBT failure indication is received, set lbtFailuresBeforeBeamChange to 'true'.

[0325] 3> If, before altering the SS / PBCH block used for random access preamble transmission, a request is received from a lower layer targeting... If the LBT failure indication of the last random access preamble transmission attempt in the SS / PBCH block is used, then lbtFailureForLastA Set ttemptBeforeBeamChange to 'true'.

[0326] 3> For each random access attempt performed on a random access resource, the following parameters are included in the chronological order of the random access attempts:

[0327] [...]

[0328] 2> Otherwise, if the random access resource used is associated with a CSI-RS, set the associated random access parameters for consecutive random access attempts associated with the same CSI-RS used for one or more random access attempts, as follows:

[0329] 3> Configure the csi-RS-Index to include the CSI-RS index associated with the random access resources used;

[0330] 3> Set numberOfPreamblesSentOnCSI-RS to indicate the number of consecutive random access attempts associated with CSI-RS.

[0331] 3> Set numberOfLBTFailuresBeforeBeamChange to indicate before changes are made for random access. Precode transmission CSI-RS Previously, in the last random access attempt, no LBT failure indication was received from the lower layer. Then, the number of consecutive random access attempts that receive an LBT failure indication for it from the lower layer;

[0332] 3> If changes are made to the transmission of the random access preamble... CSI-RS Previously, without receiving needles from the lower level Following the last random access attempt that indicates a failure of its LBT, for at least one consecutive random access attempt from the lower layer... If an LBT failure indication is received, set lbtFailuresBeforeBeamChange to 'true'.

[0333] 3> If the method used for random access preamble transmission is changed... CSI-RS Previously, received from lower layers targeting SS / If the LBT failure indication of the last random access preamble transmission attempt in the PBCH block is lbtFailureForLastAtte, then... Set mptBeforeBeamChange to 'true'.

[0334] Note 1: Empty.

[0335] Figure 9 An example of a communication system 900 according to some embodiments is shown.

[0336] In this example, the communication system 900 includes a telecommunications network 902, which includes an access network 904 (e.g., a radio access network (RAN)) and a core network 906, which includes one or more core network nodes 908. The access network 904 includes one or more access network nodes, such as network nodes 910a and 910b (one or more of which may generally be referred to as network node 910), or any other similar 3GPP access node or non-3GPP access point. Furthermore, as those skilled in the art will understand, network nodes are not necessarily limited to implementations of radio and baseband portions provided and integrated by a single supplier. Therefore, it will be understood that network nodes include their decomposed implementations or portions. For example, in some embodiments, the telecommunications network 902 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunications network 902 that supports ORAN specifications (e.g., specifications published by the O-RAN Alliance or any similar organization) and can operate independently or together with other nodes to perform one or more functions of any node in the telecommunications network 902 (including one or more network nodes 910 and / or core network nodes 908).

[0337] Examples of ORAN network nodes include Open Radio Units (O-RUs), Open Distributed Units (O-DUs), Open Central Units (O-CUs), O-CU control planes (O-CU-CPs) or O-CU user planes (O-CU-UPs), RAN intelligent controllers (near real-time or non-real-time) with managed software or software plugins, such as near real-time control applications (e.g., xApps) or non-real-time control applications (e.g., rApps), or any combination thereof (the adjective "open" indicates support for the ORAN specification). Network nodes can support the specification by, for example, supporting interfaces defined by the ORAN specification (e.g., A1, F1, W1, E1, E2, X2, Xn interfaces, Open Fronthaul User Plane interfaces, or Open Fronthaul Management Plane interfaces). Furthermore, ORAN access nodes can be logical nodes within physical nodes. Additionally, ORAN network nodes can be implemented in a virtualized environment (described further below), where one or more network functions are virtualized. For example, a virtualized environment may contain an O-Cloud computing platform orchestrated by a service management and orchestration framework via the O-2 interface or comparable technologies defined by the O-RAN Alliance. Network node 910 facilitates direct or indirect connections of user equipment (UEs), such as connecting UEs 912a, 912b, 912c, and 912d (one or more of which may generally be referred to as UE 912) to the core network 906 via one or more wireless connections.

[0338] Examples of wireless communication via wireless connectivity include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without the use of wires, cables, or other conductors. Furthermore, in various embodiments, communication system 900 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals, whether via wired or wireless connections. Communication system 900 may include and interface with any type of communication, telecommunications, data, cellular, radio network, and / or other similar type of system.

[0339] UE 912 can be any of a wide variety of communication devices, including wireless devices that are arranged, configured, and / or operable to communicate wirelessly with network node 910 and other communication devices. Similarly, network node 910 is arranged, capable, configured, and / or operable to communicate directly or indirectly with UE 912 and / or with other network nodes or devices in telecommunication network 902 to enable and / or provide network access (e.g., wireless network access) and / or perform other functions (e.g., management in telecommunication network 902).

[0340] In the depicted example, core network 906 connects network node 910 to one or more hosts (e.g., host 916). These connections can be direct or indirect, via one or more intermediate networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 906 includes one or more core network nodes (e.g., core network node 908) that consist of hardware and software components. The characteristics of these components may be substantially similar to those described for UEs, network nodes, and / or hosts, such that the description generally applies to the corresponding components of core network node 908. Example core network nodes include one or more of the following: Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier Dehiding Function (SIDF), Unified Data Management (UDM), Security Edge Protection Agent (SEPP), Network Open Function (NEF), and / or User Plane Function (UPF).

[0341] Host 916 may be owned or controlled by a service provider other than the operator or provider of access network 904 and / or telecommunications network 902, and may be operated by or on behalf of the service provider. Host 916 may host various applications to provide one or more services. Examples of such applications include providing live and / or pre-recorded audio / video content, data collection services (e.g., retrieving and compiling data on various environmental conditions detected by multiple UEs), analytics functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or any other such functions performed by a server.

[0342] Overall, Figure 9 The communication system 900 enables connections between the UE, network nodes, and hosts. In this sense, the communication system can be configured to operate according to predefined rules or procedures, such as specific standards, including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE) and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other suitable wireless communication standards, such as Global Microwave Access Interoperability (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards, such as LoRa and Sigfox.

[0343] In some examples, Telecom Network 902 is a cellular network implementing 3GPP standardized features. Therefore, Telecom Network 902 can support network slicing to provide different logical networks to different devices connected to it. For example, Telecom Network 902 can provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs while providing enhanced mobile broadband (eMBB) services to other UEs, and / or providing massive machine-type communication (mMTC) / massive IoT services to even more UEs.

[0344] In some examples, UE 912 is configured to send and / or receive information without direct human-machine interaction. For example, the UE may be designed to transmit information to access network 904 according to a predetermined schedule, when triggered by internal or external events, or in response to a request from access network 904. Furthermore, the UE may be configured to operate in single or multiple RAT or multi-standard modes. For example, the UE may operate using any one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., configured for multiple radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio Dual Connectivity (EN-DC).

[0345] In such Figure 9In the examples shown, hub 914 communicates with access network 904 to facilitate indirect communication between one or more UEs (e.g., UEs 912c and / or 912d) and network nodes (e.g., network node 910b). In some examples, hub 914 may be a controller, router, content source and analytics node, or any other communication device described herein with respect to the UE. For example, hub 914 may be a broadband router that enables the UE to access core network 906. As another example, hub 914 may be a controller that sends commands or instructions to one or more actuators in the UE. Commands or instructions may be received from the UE, network node 910, or by executable code, scripts, procedures, or other instructions in hub 914. As another example, hub 914 may be a data collector that acts as temporary storage for UE data, and in some embodiments, may perform data analysis or other processing. As another example, hub 914 may be a content source. For example, for a UE acting as a VR headset, display, speaker, or other media delivery device, hub 914 can retrieve VR assets, video, audio, or other media or data related to sensing information via network nodes, and then hub 914 provides it to the UE directly, after performing local processing, and / or after adding additional local content. In yet another example, hub 914 acts as a proxy server or coordinator for the UE, particularly when one or more of the UEs are low-power IoT devices.

[0346] Hub 914 may have a constant / persistent or intermittent connection to network node 910b. Hub 914 may also allow different communication schemes and / or scheduling between hub 914 and UEs (e.g., UEs 912c and / or 912d) and between hub 914 and core network 906. In other examples, hub 914 is connected to core network 906 and / or one or more UEs via a wired connection. Furthermore, hub 914 may be configured to connect to an M2M service provider via access network 904 and / or to another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with network node 910 while still being connected via hub 914 via a wired or wireless connection. In some embodiments, hub 914 may be a dedicated hub, i.e., a hub whose primary function is to route communication from UE to network node 910b and / or from network node 910b to UE. In other embodiments, hub 914 may be a non-dedicated hub, i.e., a device that can operate to route communication between the UE and network node 910b, but which can also operate as a communication start and / or end point for some data channels.

[0347] Figure 10A UE 1000 according to some embodiments is illustrated. As used herein, a UE refers to a device capable of, configured, positioned, and / or operable to wirelessly communicate with network nodes and / or other UEs. Examples of UEs include, but are not limited to, smartphones, mobile phones, cellular phones, VoIP phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless client devices (CPEs), vehicles, in-vehicle or in-vehicle embedded / integrated wireless devices, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including Narrowband Internet of Things (NB-IoT) UEs, Machine Type Communication (MTC) UEs, and / or Enhanced MTC (eMTC) UEs.

[0348] For example, by implementing 3GPP standards for sidelink communication, Dedicated Short Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X), the UE can support device-to-device (D2D) communication. In other examples, the UE may not necessarily have a user in the sense of a human user who owns and / or operates the associated equipment. Instead, the UE may represent equipment intended for sale to or operated by a human user, but may not be associated with a particular human user, or may not initially be associated with a particular human user (e.g., a smart sprinkler controller). Alternatively, the UE may represent equipment not intended for sale to or operated by an end user, but may be associated with a user or operated for the user's benefit (e.g., a smart meter).

[0349] UE 1000 includes processing circuitry 1002, which is operatively coupled via bus 1004 to input / output interface 1006, power supply 1008, memory 1010, communication interface 1012, and / or any other component, or any combination thereof. Some UEs may use... Figure 10 The components shown may be all or some of the components. The degree of integration between components may vary from UE to UE. In addition, some UEs may contain multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0350] Processing circuitry 1002 is configured to process instructions and data and can be configured to implement any sequential state machine operable to execute instructions stored in memory 1010 as a machine-readable computer program. Processing circuitry 1002 can be implemented as one or more hardware-implemented state machines (e.g., discrete logic, field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, a general-purpose processor (e.g., a microprocessor or digital signal processor (DSP)) together with appropriate software; or any combination thereof. For example, processing circuitry 1002 may include multiple central processing units (CPUs). Processing circuitry 1002 can operate alone or in combination with other UE 1000 components (e.g., memory 1010) to provide the functionality of UE 1000. For example, processing circuitry 1002 can be configured to cause UE 1002 to perform as described in the reference. Figure 3 , 5 And / or the method described in 7.

[0351] In this example, the input / output interface 1006 can be configured to provide one or more interfaces to input devices, output devices, or one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, transmitters, smart cards, other output devices, or any combination thereof. Input devices can allow users to capture information into the UE 1000. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital camcorders, webcams, etc.), microphones, sensors, mice, trackballs, steering wheels, touchpads, scroll wheels, smart cards, etc. Presence-sensitive displays may include capacitive or resistive touch sensors to sense input from the user. Sensors may be, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, optical sensors, proximity sensors, biosensors, etc., or any combination thereof. Output devices can use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port can be used to provide both input and output devices.

[0352] In some embodiments, power supply 1008 is configured as a battery or battery pack. Other types of power sources may be used, such as external power sources (e.g., power outlets), photovoltaic devices, or batteries. Power supply 1008 may also include power supply circuitry for delivering power from power supply 1008 itself and / or external power sources to various components of UE 1000 via input circuitry or interfaces (e.g., power cables). The delivery of power may, for example, be used to charge power supply 1008. The power supply circuitry may format, convert, or otherwise modify the power from power supply 1008 to suit the power supply for the various components of the UE 1000 being powered.

[0353] Memory 1010 may be memory or configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), disk, optical disk, hard disk, removable cassette tape, flash drive, etc. In one example, memory 1010 includes one or more applications 1014, such as an operating system, web browser application, widget, utility engine, or other application, and corresponding data 1016. Memory 1010 may store any of a variety of operating systems or combinations of operating systems for use by UE 1000.

[0354] The memory 1010 can be configured to include multiple physical drive units, such as a redundant array of independent disks (RAID), flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile optical disc (HD-DVD) drive, an internal hard drive, a Blu-ray disc drive, a holographic digital data storage (HDDS) disc drive, an external micro dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), an external micro DIMM SDRAM, smart card memory (e.g., a tamper-proof module in the form of a universal integrated circuit card (UICC), including one or more subscriber identification modules (SIMs), such as USIM and / or ISIM), other memory, or any combination thereof. The UICC can be an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card". The memory 1010 can allow the UE 1000 to access instructions, applications, etc., stored on temporary or non-temporary memory media to offload or upload data. Articles of manufacture (e.g., articles of manufacture utilizing a communication system) may be tangibly embodied in or located in memory 1010, which may be or include a device-readable storage medium.

[0355] Processing circuitry 1002 can be configured to communicate with an access network or other network using communication interface 1012. Communication interface 1012 may include one or more communication subsystems and may include or be communicatively coupled to antenna 1022. Communication interface 1012 may include one or more transceivers for communication, such as through one or more remote transceivers (e.g., another UE or network node in the access network) of another device capable of wireless communication. Each transceiver may include a transmitter 1018 and / or a receiver 1020 suitable for providing network communication (e.g., optical, electrical, frequency allocation, etc.). Furthermore, transmitter 1018 and receiver 1020 may be coupled to one or more antennas (e.g., antenna 1022) and may share circuitry, software, or firmware, or alternatively may be implemented separately.

[0356] In some embodiments, the communication functions of the communication interface 1012 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication (e.g., Bluetooth, near-field communication), location-based communication (e.g., using a Global Positioning System (GPS) to determine location), other similar communication functions, or any combination thereof. Communication may be implemented according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Fiber Network (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

[0357] Regardless of the sensor type, the UE can provide the output of data captured by its sensors via its communication interface 1012 through a wireless connection to the network node. The data captured by the UE's sensors can be transmitted to the network node via another UE through a wireless connection. The output can be periodic (e.g., every 15 minutes if it reports sensed temperature), random (e.g., to balance the load of reports from multiple sensors), responsive to trigger events (e.g., sending an alarm when moisture is detected), responsive to requests (e.g., user-initiated requests), or continuous streaming (e.g., real-time video feed of a patient).

[0358] As another example, the UE includes actuators, motors, or switches associated with a communication interface configured to receive wireless input from a network node via a wireless connection. The state of the actuator, motor, or switch can change in response to the received wireless input. For example, the UE may include a motor that adjusts the control surfaces or rotors of a drone in flight based on the received input, or control a robotic arm performing a medical procedure based on the received input.

[0359] When a UE is in the form of an Internet of Things (IoT) device, it can be a device used in one or more application areas, including but not limited to urban wearable technology, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices include or are embedded in the following devices: connected refrigerators or freezers, TVs, connected lighting devices, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, electric door locks, connected doorbells, air conditioning systems (such as heat pumps), autonomous vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearable devices for haptic or sensory enhancement, sprinklers, animal or object tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any type of medical device (such as heart rate monitors or remote-controlled surgical robots). UEs in the form of IoT devices, in addition to including those related to… Figure 10 In addition to the other components described in the UE 1000 description, it further includes circuitry and / or software depending on the intended application of the IoT device.

[0360] As another specific example, in IoT scenarios, a UE can represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another UE and / or network node. In this case, the UE can be an M2M device, which may be referred to as an MTC device in the 3GPP context. As a specific example, the UE can implement the 3GPP NB-IoT standard. In other scenarios, a UE can represent a vehicle, such as a car, bus, truck, ship, and aircraft, or other devices capable of monitoring and / or reporting their operational status or other functions related to their operation.

[0361] In practice, any number of UEs can be used for a single use case. For example, the first UE may be a drone or integrated into a drone, providing the drone's speed information (obtained via a speed sensor) to a second UE, i.e., a remote controller operating the drone. When the user makes a change from the remote controller, the first UE can adjust the throttle on the drone (e.g., by controlling actuators) to increase or decrease the drone's speed. The first UE and / or the second UE may also include more than one of the functions described above. For example, the UE may include sensors and actuators, as well as communication for processing data from the speed sensors and actuators.

[0362] Figure 11 A network node 1100 according to some embodiments is illustrated. As used herein, a network node refers to a device that is capable of, configured, arranged, and / or operable to communicate directly or indirectly with a UE and / or other network nodes or devices in a telecommunications network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)), O-RAN nodes, or components of O-RAN nodes (e.g., O-RUs, O-DUs, O-CUs).

[0363] Base stations can be classified according to the coverage they provide (or, in other words, their transmit power level); therefore, depending on the coverage provided, a base station can be referred to as a femtobase, picobase, microbase, or macrobase. A base station can be a relay node or a relay donor node controlling a relay. Network nodes can also include one or more (or all) parts of a distributed radio base station, such as centralized digital units, distributed units (e.g., in O-RAN access nodes), and / or remote radio units (RRUs), sometimes referred to as remote radio headends (RRHs). Such remote radio units may or may not be integrated with an antenna as antenna-integrated radios. The parts of a distributed radio base station can also be referred to as nodes in a distributed antenna system (DAS).

[0364] Other examples of network nodes include multiple transport point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment (e.g., MSR BS), network controllers (e.g., radio network controller (RNC) or base station controller (BSC)), base transceiver stations (BTS), transport points, transport nodes, multi-cell / multicast coordination entities (MCE), operation and maintenance (O&M) nodes, operations support system (OSS) nodes, self-organizing network (SON) nodes, location nodes (e.g., evolved servicing mobile location center (E-SMLC)), and / or minimized drive test (MDT).

[0365] Network node 1100 includes processing circuitry 1102, memory 1104, communication interface 1106, and power supply 1108, and / or any other components, or any combination thereof. Network node 1100 may consist of multiple physically independent components (e.g., node B components and RNC components, or BTS components and BSC components, etc.), each component may have its own components. In some scenarios where network node 1100 includes multiple independent components (e.g., BTS and BSC components), one or more of the independent components may be shared among multiple network nodes. For example, a single RNC may control multiple node Bs. In this case, each unique node B and RNC pair may be considered a single independent network node in some situations. In some embodiments, network node 1100 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1104 for different RATs), and some components may be reused (e.g., the same antenna 1110 may be shared by different RATs). Network node 1100 may also include various components shown in multiple groups for different wireless technologies integrated into network node 1100, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chips or chipsets and other components within network node 1100.

[0366] Processing circuitry 1102 may include a combination of one or more of the following: a microprocessor, controller, 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 coding logic, which may be used alone or in conjunction with other network node 1100 components (e.g., memory 1104) to provide network node 1100 functionality. For example, processing circuitry 1102 may be configured to cause the network node to perform actions as described in the reference. Figure 4 , 6 And / or the method described in 8.

[0367] In some embodiments, the processing circuitry 1102 includes a system-on-a-chip (SOC). In some embodiments, the processing circuitry 1102 includes one or more of a radio frequency (RF) transceiver circuitry 1112 and a baseband processing circuitry 1114. In some embodiments, the RF transceiver circuitry 1112 and the baseband processing circuitry 1114 may be located on separate chips (or chipsets), circuit boards, or units (e.g., radio units and digital units). In alternative embodiments, some or all of the RF transceiver circuitry 1112 and the baseband processing circuitry 1114 may be located on the same chip or a set of chips, boards, or units.

[0368] Memory 1104 may include any form of volatile or non-volatile computer-readable memory, including but not limited to persistent memory, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, optical disc (CD), or digital video disc (DVD)) and / or any other volatile or non-volatile, non-transient device-readable and / or computer-executable memory device for storing information, data, and / or instructions that can be used by processing circuitry 1102. Memory 1104 may store any suitable instructions, data, or information, including computer programs, software, applications, including one or more of the following: logic, rules, code, tables, and / or other instructions that can be executed by processing circuitry 1102 and utilized by network node 1100. Memory 1104 may be used to store any calculations performed by processing circuitry 1102 and / or any data received via communication interface 1106. In some embodiments, processing circuitry 1102 and memory 1104 are integrated.

[0369] Communication interface 1106 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, communication interface 1106 includes a port / terminal 1116 for transmitting and receiving data to and from a network, for example, via a wired connection. Communication interface 1106 further includes radio front-end circuitry 1118, which may be coupled to antenna 1110, or in some embodiments to a portion of antenna 1110. Radio front-end circuitry 1118 includes a filter 1120 and an amplifier 1122. Radio front-end circuitry 1118 may be connected to antenna 1110 and processing circuitry 1102. Radio front-end circuitry 1118 may be configured to modulate the signal transmitted between antenna 1110 and processing circuitry 1102. Radio front-end circuitry 1118 may receive digital data to be transmitted wirelessly to other network nodes or UEs. Radio front-end circuitry 1118 may use a combination of filter 1120 and / or amplifier 1122 to convert digital data into radio signals with appropriate channel and bandwidth parameters. Radio signals can then be transmitted via antenna 1110. Similarly, when receiving data, antenna 1110 can collect radio signals, which are then converted into digital data by radio front-end circuitry 1118. The digital data can then be passed to processing circuitry 1102. In other embodiments, communication interface 1106 may include different components and / or different combinations of components.

[0370] In some alternative embodiments, network node 1100 does not include a separate radio front-end circuitry 1118; instead, processing circuitry 1102 includes radio front-end circuitry and is connected to antenna 1110. Similarly, in some embodiments, all or part of RF transceiver circuitry 1112 is part of communication interface 1106. In other embodiments, communication interface 1106 includes one or more ports or terminals 1116, radio front-end circuitry 1118, and RF transceiver circuitry 1112 (not shown) as part of a radio unit, and communication interface 1106 communicates with baseband processing circuitry 1114, which is part of a digital unit (not shown).

[0371] Antenna 1110 may include one or more antennas or an antenna array configured to transmit and / or receive wireless signals. Antenna 1110 may be coupled to radio front-end circuitry 1118 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 1110 is separate from network node 1100 and may be connected to network node 1100 via an interface or port.

[0372] Antenna 1110, communication interface 1106, and / or processing circuitry 1102 can be configured to perform any receive operation and / or certain acquire operation described herein by a network node. Any information, data, and / or signals can be received from the UE, another network node, and / or any other network device. Similarly, antenna 1110, communication interface 1106, and / or processing circuitry 1102 can be configured to perform any transmit operation described herein by a network node. Any information, data, and / or signals can be transmitted to the UE, another network node, and / or any other network device.

[0373] Power supply 1108 provides power to the various components of network node 1100 in a manner suitable for each component (e.g., at the voltage and current levels required by each individual component). Power supply 1108 may also include or be coupled to power management circuitry to provide power to the components of network node 1100 for performing the functions described herein. For example, network node 1100 may be connected to an external power source (e.g., mains, power outlet) via input circuitry or an interface such as a cable, thereby supplying power to the power circuitry of power supply 1108. As a further example, power supply 1108 may include a power source in the form of a battery or battery pack, which is connected to or integrated into the power circuitry. The battery can provide backup power in the event of an external power failure.

[0374] Embodiments of network node 1100 may include, except Figure 11Additional components beyond those shown may be used to provide certain aspects of the network node's functionality, including any of the functions described herein and / or any functionality required to support the topics described herein. For example, network node 1100 may include a user interface device to allow information to be input into and output from network node 1100. This can allow users to perform diagnostic, maintenance, repair, and other management functions on network node 1100.

[0375] Figure 12 This is a block diagram illustrating a virtualization environment 1200, in which functionality implemented in certain embodiments can be virtualized. In this context, virtualization means creating a virtual version of a device or apparatus, which may include virtualized hardware platforms, storage devices, and network resources. As used herein, virtualization can be applied to any device or component thereof described herein and involves at least a portion of functionality being implemented as an implementation of one or more virtual components. Some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1200 hosted by one or more hardware nodes (e.g., hardware computing devices operating as network nodes, UEs, core network nodes, or hosts). Furthermore, in embodiments where virtual nodes do not require radio connectivity (e.g., core network nodes or hosts), the nodes may be fully virtualized. In some embodiments, the virtualization environment 1200 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a service management and orchestration framework via an O-2 interface.

[0376] Application 1202 (which may also be referred to as a software instance, virtual device, network function, virtual node, virtual network function, etc.) runs in the virtualization environment Q400 to implement some of the features, functions and / or advantages of some embodiments disclosed herein.

[0377] Hardware 1204 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices described herein, such as network interfaces, input / output interfaces, etc. The software can be executed by the processing circuitry to instantiate one or more virtualization layers 1206 (also referred to as a hypervisor or virtual machine monitor (VMM)), provide VMs 1208a and 1208b (one or more of which may be collectively referred to as VM 1208), and / or perform any functionality, features, and / or advantages related to some embodiments described herein. Virtualization layer 1206 can present a virtual operating platform to VM 1208, which appears as networked hardware.

[0378] VM 1208 includes virtual processing, virtual memory, virtual network or interface, and virtual storage devices, and can be operated by a corresponding virtualization layer 1206. Different embodiments of instances of virtual device 1202 can be implemented on one or more VMs 1208, and can be implemented in different ways. Hardware virtualization is sometimes referred to as Network Functions Virtualization (NFV). NFV can be used to consolidate many types of network devices onto industry-standard high-capacity server hardware, physical switches, and physical storage, which can reside in data centers and client devices.

[0379] In the context of NFV, VM 1208 can be a software implementation of a physical machine, whose programs run as if they were running on a physical, non-virtualized machine. Each VM 1208, along with the portion of the hardware 1204 running that VM (whether dedicated to that VM or shared by that VM with other VMs), forms a separate virtual network element. Still within the context of NFV, the virtual network function is responsible for handling specific network functions running on one or more VMs 1208 above hardware 1204, and corresponds to application 1202.

[0380] Hardware 1204 can be implemented in a standalone network node with general or specific components. Hardware 1204 may implement some functions via virtualization. Alternatively, hardware 1204 may be part of a larger hardware cluster (e.g., in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1210, which, among other things, oversees the lifecycle management of application 1202. In some embodiments, hardware 1204 is coupled to one or more radio units, each radio unit including one or more transmitters and one or more receivers, which may be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more suitable network interfaces and may be used in conjunction with virtual components to provide radio capabilities to virtual nodes (e.g., radio access nodes or base stations). In some embodiments, a control system 1212 may be used to provide signaling, and the control system 1212 may alternatively be used for communication between hardware nodes and radio units.

[0381] While the computing devices described herein (e.g., UE, network node, host) may include the hardware component combinations shown, other embodiments may include computing devices with different component combinations. It will be understood that these computing devices may include any suitable hardware and / or software combination required to perform the tasks, features, functions, and methods disclosed herein. The determination, computation, acquisition, or similar operations described herein may be performed by processing circuitry that processes information by, for example, converting acquired information into other information, comparing the acquired or converted information with information stored in a network node, and / or performing one or more operations based on the acquired or converted information, and making determinations based on the results of said processing. Furthermore, although components are depicted as single boxes located within larger boxes or nested within multiple boxes, in practice, a computing device may include multiple different physical components constituting a single illustrated component, and functionality may be partitioned between individual components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of a component may be partitioned between processing circuitry and the communication interface. In another example, non-computationally intensive functionality of any such component may be implemented in software or firmware, while computationally intensive functionality may be implemented in hardware.

[0382] In some embodiments, some or all of the functionality described herein may be provided by processing circuitry that executes instructions stored in memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by processing circuitry without executing instructions stored, for example, on a separate or discrete device-readable storage medium in a hard-wired manner. In any of these particular embodiments, the processing circuitry may be configured to perform the described functionality regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functionality are not limited to processing circuitry alone or to other components of a computing device, but can generally be enjoyed by the entire computing device and / or end users and wireless networks.

[0383] Example

[0384] Group A Examples

[0385] 1. A method executed by a user equipment for providing random access information to a network node, the method comprising:

[0386] Send random access information related to the first random access procedure to the network node, the random access information including one or more of the following:

[0387] A first indication of a successful transmission attempt of a random access message, the first indication having an associated indication of the number of consecutive failed transmission attempts of the random access message prior to the successful transmission attempt of the random access message, and

[0388] A second indication of the total number of random access message transmission attempts.

[0389] 2. The method according to embodiment 1, wherein the first indication includes a list of multiple successful transmission attempts of the corresponding random access message.

[0390] 3. The method according to embodiment 2, wherein multiple successful transmission attempts are listed in chronological order in the list.

[0391] 4. The method according to embodiment 2 or 3, wherein, for each successful transmission attempt of a corresponding random access message in the list, the associated indication includes: an associated indication of the number of consecutive failed transmission attempts of the corresponding random access message experienced prior to the successful transmission attempt of the corresponding random access message.

[0392] 5. The method according to any of the foregoing embodiments further includes: in response to the network configuring a Listen-After-Talk (LBT) failure recovery configuration at the UE when the UE performs a first random access procedure, performing the step of sending random access information.

[0393] 6. The method according to any of the foregoing embodiments further includes: in response to a failure to restore the network configuration at the UE due to the network not configuring Listen-After-Talk (LBT) at the UE during a first random access procedure, performing the step of sending random access information.

[0394] 7. The method according to any of the foregoing embodiments, wherein random access information is included in one of the following: random access report, radio link failure report, successful handover report, successful primary / secondary cell (PSCell) addition or change report, primary cell group (MCG) failure information message, and secondary cell group (SCG) failure information message.

[0395] 8. The method according to any of the foregoing embodiments, wherein the random access message includes one of the following: a random access preamble, MsgA, and Msg3.

[0396] 9. According to the method of embodiment 8, when subordinate to embodiment 2, the list of multiple successful transmission attempts includes a mixture of the following successful transmission attempts: one or more random access preambles, one or more MsgA, and one or more Msg3.

[0397] 10. The method according to embodiments 1 to 9, wherein the second indication of the total number of transmission attempts of random access messages in the first random access procedure includes:

[0398] A series of information, arranged in chronological order, includes: a first information element representing the number of consecutive successful transmission attempts of a random access message; and a second information element representing the number of consecutive failed transmission attempts of a random access message.

[0399] 11. The method according to embodiment 10, wherein the first information element includes a first value.

[0400] 12. The method according to embodiment 10, wherein the first information element includes a series of first values.

[0401] 13. The method according to embodiments 10 to 12, wherein the second information element includes a second value.

[0402] 14. The method according to embodiments 10 to 13, wherein the indication of the total number of transmission attempts represents transmission attempts of random access messages arranged in chronological order.

[0403] 15. The method according to any of the foregoing embodiments, wherein the random access information further includes an indication of whether the UE is configured with an LBT failure recovery configuration in one of the following: the time of the random access preamble transmission attempt or the time of initiating the random access procedure.

[0404] 16. The method according to any of the foregoing embodiments, wherein a successful transmission attempt of a random access message includes: a transmission attempt for a random access message whose listen-before-speak process is successful.

[0405] 17. The method according to any of the foregoing embodiments, wherein a failed transmission attempt of a random access message includes: a transmission attempt for a random access message whose listen-before-speak process has failed.

[0406] 18. A method performed by a user equipment (UE) for providing random access information to a network node, the method comprising:

[0407] Send random access information to the network node, which includes an indication of whether the UE is configured with a Listen-Before-Talk (LBT) failure recovery configuration in one of the following: the time of the random access preamble transmission attempt or the time of initiating the random access procedure.

[0408] 19. The method according to embodiment 18 further includes recording the number of failed transmission attempts of the random access message prior to a persistent LBT failure.

[0409] 20. A method performed by a user equipment, the method comprising:

[0410] Send random access information related to the random access procedure to the network node. The random access information includes a fourth indication that relates to the number of failed transmission attempts of the random access preamble that have occurred since the last successful transmission attempt of the random access preamble in the first beam before the selection of the second beam for preamble transmission in the random access procedure.

[0411] 21. The method according to embodiment 20, wherein the fourth indication indicates whether there has been at least one failed transmission attempt of the random access preamble since the last successful transmission attempt of the random access preamble.

[0412] 22. The method according to embodiment 20 or 21, wherein the fourth indication indicates the number of consecutive failed transmission attempts of the random access preamble after the last successful transmission attempt of the random access preamble.

[0413] 23. The method according to any of embodiments 20 to 22, wherein the fourth indication indicates whether the last successful transmission attempt of the random access preamble was the last transmission attempt of the random access preamble before the selection of the second beam.

[0414] 24. The method according to any one of embodiments 20 to 23 further includes: in response to the network configuring a Listen-After-Talk (LBT) failure recovery configuration at the UE when the UE performs a random access procedure, performing the step of sending random access information.

[0415] 25. The method according to any one of embodiments 20 to 23 further includes: in response to the failure of the network to configure Listen-After-Talk (LBT) recovery at the UE during a random access procedure, performing the step of sending random access information.

[0416] 26. The method according to any of the foregoing embodiments further includes:

[0417] Provide user data; and

[0418] User data is forwarded to the host via transmission to network nodes.

[0419] Group B Implementation Examples

[0420] 27. A method executed by a network node, the method comprising:

[0421] The user equipment (UE) receives random access information related to the first random access procedure, which includes one or more of the following:

[0422] A first indication of a successful transmission attempt of a random access message, the first indication having an associated indication of the number of consecutive failed transmission attempts of random access messages experienced by the user equipment prior to the successful transmission attempt of the random access message, and

[0423] A second indication of the total number of random access message transmission attempts.

[0424] 28. The method according to embodiment 27, wherein the first indication includes a list of multiple successful transmission attempts of the corresponding random access message.

[0425] 29. The method according to embodiment 28, wherein a plurality of successful transmission attempts are listed in chronological order in the list.

[0426] 30. The method according to embodiments 27 to 29, wherein, for each successful transmission attempt of a corresponding random access message in the list, the random access information further includes: an indication of the number of consecutive failed transmission attempts of the corresponding random access message prior to the successful transmission attempt of the corresponding random access message.

[0427] 31. The method according to any one of embodiments 27 to 30 further includes: in response to configuring a Listen-Before-Talk (LBT) failure recovery configuration at the UE when the UE performs a first random access procedure, performing the step of receiving random access information.

[0428] 32. The method according to any one of embodiments 27 to 30 further includes: in response to a failure to restore the network configuration at the UE when the UE performs a first random access procedure due to the network not configuring the Listen-After-Talk LBT at the UE, performing the step of receiving random access information.

[0429] 33. The method according to any one of embodiments 27 to 32, wherein random access information is included in one of the following: random access report, radio link failure report, successful handover report, successful primary / secondary cell (PSCell) addition or change report, primary cell group (MCG) failure information message, and secondary cell group (SCG) failure information message.

[0430] 34. The method according to any one of embodiments 27 to 33, wherein the random access message includes one of the following: a random access preamble, Msg 3, and MsgA.

[0431] 35. The method according to embodiment 34, when subordinate to embodiment 28, wherein the list of multiple successful transmission attempts includes a mixture of successful transmission attempts of: one or more random access preambles, one or more Msg3, and one or more MsgA.

[0432] 36. The method according to embodiments 27 to 35, wherein the indication of the total number of transmission attempts of random access messages in the first random access procedure includes:

[0433] A series of information, arranged in chronological order, includes: an information element representing the number of consecutive successful transmission attempts of a random access message; and an information element representing the number of consecutive failed transmission attempts of a random access message.

[0434] 37. The method according to embodiment 36, wherein the information element representing the number of consecutive successful transmission attempts of the random access message includes a first value.

[0435] 38. The method according to embodiment 36, wherein the information element representing the number of consecutive successful transmission attempts of the random access message includes a series of first values.

[0436] 39. The method according to embodiments 36 to 38, wherein the information element representing the number of consecutive failed transmission attempts of the random access message includes a second value.

[0437] 40. The method according to embodiments 36 to 39, wherein the indication of the total number of transmission attempts represents transmission attempts of random access messages arranged in chronological order.

[0438] 41. The method according to any one of embodiments 27 to 40, wherein the random access information further includes an indication of whether the UE is configured with an LBT failure recovery configuration in one of the following: the time of the random access preamble transmission attempt or the time of initiating a random access procedure including a random access message.

[0439] 42. The method according to any one of embodiments 27 to 41, wherein a successful transmission attempt of a random access message includes: a transmission attempt for a random access message whose listen-before-speak process is successful.

[0440] 43. The method according to any one of embodiments 27 to 42, wherein a failed transmission attempt of a random access message includes: a transmission attempt for a random access message whose listen-before-speak process has failed.

[0441] 44. A method executed by a network node, the method comprising:

[0442] Receive random access information from the user equipment, which includes an indication of whether the UE is configured with a Listen-Before-Talk (LBT) failure recovery configuration in one of the following: the time of the random access preamble transmission attempt or the time of initiating the random access procedure.

[0443] 45. The method according to embodiment 44 further includes:

[0444] In response to an indication that the UE was configured with a Listen-Before-Speak (LBT) failure recovery configuration at one of the following: the time of the random access preamble transmission attempt or the time of initiating the random access procedure, it is determined that the UE did not perform a power boost after the failed transmission attempt of the random access preamble.

[0445] 46. ​​The method according to embodiment 44 or 45 further comprises:

[0446] In response to an indication that the UE was not configured to resume the Listen-After-Talk LBT configuration in one of the following situations: at the time of the random access preamble transmission attempt or at the time of initiating the random access procedure, it is determined that the UE performed a power boost after the failed transmission attempt of the random access preamble.

[0447] 47. The method according to any of the foregoing embodiments further includes:

[0448] Obtaining user data; and

[0449] The user data is forwarded to the host or user device.

[0450] 48. A method executed by a network node, the method comprising:

[0451] The user equipment receives random access information related to the random access procedure, which includes a fourth indication relating to the number of failed transmission attempts of the random access preamble experienced by the user equipment after the last successful transmission attempt of the random access preamble made by the user equipment in the first beam before the user equipment selects the second beam for preamble transmission in the random access procedure.

[0452] 49. The method according to embodiment 48, wherein the fourth indication indicates whether there has been at least one failed transmission attempt of the random access preamble since the last successful transmission attempt of the random access preamble.

[0453] 50. The method according to embodiment 48 or 49, wherein the fourth indication indicates the number of consecutive failed transmission attempts of the random access preamble after the last successful transmission attempt of the random access preamble.

[0454] 51. The method according to any one of embodiments 48 to 50, wherein the fourth indication indicates whether the last successful transmission attempt of the random access preamble was the last transmission attempt of the random access preamble before the selection of the second beam.

[0455] 52. The method according to any one of embodiments 48 to 51 further includes: in response to the network configuring a Listen-After-Talk (LBT) failure recovery configuration at the UE when the UE performs a random access procedure, performing the step of receiving random access information.

[0456] 53. The method according to any one of embodiments 48 to 51 further includes: in response to the network failing to configure Listen-After-Talk (LBT) recovery at the UE during a random access procedure, performing the step of receiving random access information.

[0457] Group C Implementation Examples

[0458] 54. A user equipment, comprising:

[0459] The processing circuitry is configured to cause the user equipment to perform any step in any of the Group A embodiments; and

[0460] The power supply circuit is configured to supply power to the processing circuit.

[0461] 55. A network node comprising:

[0462] The processing circuitry is configured to cause the network node to perform any step in any of the Group B embodiments;

[0463] The power supply circuit is configured to supply power to the processing circuit.

[0464] 56. A user equipment (UE) comprising:

[0465] The antenna is configured to transmit and receive wireless signals;

[0466] A radio front-end circuit that is connected to an antenna and a processing circuit and is configured to modulate the signal used for communication between the antenna and the processing circuit;

[0467] The processing circuitry is configured to perform any step in any of the Group A embodiments;

[0468] An input interface, which is connected to the processing circuitry and configured to allow information to be input into the UE for processing by the processing circuitry;

[0469] An output interface, which is connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and

[0470] The battery is connected to the processing circuitry and is configured to power the UE.

[0471] 57. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising:

[0472] Processing circuitry is configured to provide user data; and

[0473] A network interface is configured to initiate the transmission of user data to a network node in a cellular network for transmission to a user equipment (UE). The network node has a communication interface and processing circuitry, the processing circuitry of which is configured to perform any operation in any of the Group B embodiments to send user data from the host to the UE.

[0474] 58. The host according to the foregoing embodiments, wherein:

[0475] The host's processing circuitry is configured to run host applications that provide user data; and

[0476] The UE includes processing circuitry configured to run a client application associated with the host application to receive transmissions of user data from the host.

[0477] 59. A method implemented in a host, the host being configured to operate in a communication system, the communication system further including a network node and a user equipment (UE), the method comprising:

[0478] Provide user data to the UE; and

[0479] Transmission of user data to the UE is initiated via a cellular network including the network node, wherein the network node performs any operation in any of the Group B embodiments to send the user data from the host to the UE.

[0480] 60. The method according to the foregoing embodiments further includes transmitting user data provided by the host to the UE at the network node.

[0481] 61. The method according to any of the first two embodiments, wherein the user data is provided at the host by running a host application that interacts with a client application running on the UE, the client application being associated with the host application.

[0482] 62. A communication system configured to provide over-the-top (OTT) services, the communication system comprising:

[0483] The host includes:

[0484] Processing circuitry is configured to provide user data to a user equipment (UE), the user data being associated with an over-the-top service; and

[0485] A network interface is configured to initiate the transmission of user data to a cellular network node for transmission to a UE. The network node has a communication interface and processing circuitry, the processing circuitry of which is configured to perform any operation in any of the Group B embodiments to send user data from the host to the UE.

[0486] 63. The communication system according to the foregoing embodiments further includes:

[0487] The network node; and / or

[0488] The UE.

[0489] 64. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising:

[0490] The processing circuitry is configured to initiate the reception of user data; and

[0491] A network interface is configured to receive user data from a network node in a cellular network, the network node having a communication interface and processing circuitry, the processing circuitry of the network node being configured to perform any operation in any of the Group B embodiments to receive user data from the user equipment (UE) for the host.

[0492] 65. The host according to the first two embodiments, wherein:

[0493] The host's processing circuitry is configured to run host applications that receive user data; and

[0494] The host application is configured to interact with a client application running on the UE, which is associated with the host application.

[0495] 66. The host according to any of the first two embodiments, wherein initiating the reception of user data includes requesting user data.

[0496] 67. A method implemented by a host configured to operate in a communication system, the communication system further including a network node and a user equipment (UE), the method comprising:

[0497] At the host, the reception of user data from the UE is initiated, which originates from a transmission that the network node has already received from the UE, wherein the network node performs any of the steps in any of the Group B embodiments in order to receive user data from the UE for the host.

[0498] 68. The method according to the foregoing embodiments further includes sending the received user data to the host at the network node.

[0499] 69. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising:

[0500] Processing circuitry is configured to provide user data; and

[0501] A network interface is configured to initiate the transmission of user data to a cellular network for transmission to a user equipment (UE), wherein the UE includes a communication interface and processing circuitry, and the UE's communication interface and processing circuitry are configured to perform any operation in any of the Group A embodiments to receive user data from a host.

[0502] 70. The host according to the foregoing embodiments, wherein the cellular network further includes a network node configured to communicate with the UE to send user data from the host to the UE.

[0503] 71. The host according to the first two embodiments, wherein:

[0504] The host's processing circuitry is configured to run host applications, thereby providing user data; and

[0505] The host application is configured to interact with a client application running on the UE, which is associated with the host application.

[0506] 72. A method implemented by a host operating in a communication system, the communication system further including a network node and a user equipment (UE), the method comprising:

[0507] Provide user data to the UE; and

[0508] The transmission of user data to the UE is initiated via a cellular network including the network node, wherein the UE performs any operation in any of the Group A embodiments to receive user data from the host.

[0509] 73. The method according to the foregoing embodiments further includes:

[0510] At the host, a host application associated with the client application running on the UE is run to receive user data from the host application.

[0511] 74. The method according to the foregoing embodiments further includes:

[0512] At the host, input data is sent to the client application running on the UE, which is provided by the host application.

[0513] User data is provided by the client application in response to input data from the host application.

[0514] 75. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising:

[0515] Processing circuitry is configured to provide user data; and

[0516] A network interface is configured to initiate the transmission of user data to a cellular network for transmission to a user equipment (UE), wherein the UE includes a communication interface and processing circuitry, and the UE's communication interface and processing circuitry are configured to perform any step in any of the Group A embodiments to send user data to a host.

[0517] 76. The host according to the foregoing embodiments, wherein the cellular network further includes a network node configured to communicate with the UE to transmit user data from the UE to the host.

[0518] 77. The host according to the first two embodiments, wherein:

[0519] The host's processing circuitry is configured to run host applications, thereby providing user data; and

[0520] The host application is configured to interact with a client application running on the UE, which is associated with the host application.

[0521] 78. A method implemented by a host configured to operate in a communication system, the communication system further including network nodes and user equipment (UE), the method comprising:

[0522] At the host, user data sent by the UE to the host via a network node is received, wherein the UE performs any step in any of the Group A embodiments to send the user data to the host.

[0523] 79. The method according to the foregoing embodiments further includes:

[0524] At the host, a host application associated with the client application running on the UE is run to receive user data from the UE.

[0525] 80. The method according to the preceding two embodiments further includes:

[0526] At the host, input data is sent to the client application running on the UE, which is provided by the host application.

[0527] This user data is provided by the client application in response to input data from the host application.

Claims

1. A method performed by a user equipment, the method comprising: Send random access information related to the random access procedure to the network node, the random access information including a fourth indication indicating whether, before selecting the second beam for the preamble transmission in the random access procedure, there has been at least one failed transmission attempt of the random access preamble after the last successful transmission attempt in the first beam.

2. The method according to claim 1, wherein, The fourth indication specifies whether the last successful transmission attempt of the random access preamble was the last transmission attempt of the random access preamble before the selection of the second beam.

3. The method according to claim 2, wherein, The fourth instruction includes an implicit instruction.

4. The method according to claim 3, wherein, The fourth indication includes the absence of a sign.

5. The method according to claim 1, wherein, The fourth indication specifies whether the previous transmission attempt of the random access preamble in the first beam failed before selecting the second beam for preamble transmission.

6. The method according to any one of claims 5, wherein, The fourth instruction includes a sign.

7. The method according to any one of claims 1 to 4, wherein, The fourth indication specifies the number of consecutive failed transmission attempts of the random access preamble after the last successful transmission attempt of the random access preamble.

8. The method according to any one of claims 1 to 7, further comprising: In response to the network configuring a Listen-After-Talk (LBT) failure recovery configuration at the UE during the UE's execution of the random access procedure, the step of sending the random access information is performed.

9. The method according to any one of claims 1 to 7, further comprising: In response to a failure to restore the network configuration at the UE due to the UE not having a Listen-After-Talk (LBT) configuration configured during the random access procedure, the step of sending the random access information is performed.

10. The method according to any one of claims 1 to 9, wherein, The first beam and the second beam include SSB or CSI-RS.

11. The method according to any one of claims 1 to 10, wherein, The fourth indication is sent as part of the random access information in a random access report, radio link failure report, successful handover report, or successful PSCell change / addition report.

12. The method according to any one of claims 1 to 11, wherein, The random access information further includes one or more of the following: A first indication of a successful transmission attempt of a random access message, the first indication having an associated indication of the number of consecutive failed transmission attempts of the random access message prior to the successful transmission attempt of the random access message, and A second indication of the total number of random access message transmission attempts.

13. The method according to any one of claims 1 to 12, wherein, The random access information further includes: Whether the UE is configured with an indication of listen-before-talk LBT failure recovery configuration at one of the following: the time of the random access preamble transmission attempt or the time of initiating the random access procedure.

14. A method performed by a network node, the method comprising: The user equipment receives random access information related to the random access procedure, the random access information including a fourth indication indicating whether, before the user equipment selects a second beam for preamble transmission in the random access procedure, there has been at least one failed transmission attempt of the random access preamble experienced by the user equipment after the last successful transmission attempt of the random access preamble by the user equipment in the first beam.

15. The method according to claim 14, wherein, The fourth indication specifies whether the last successful transmission attempt of the random access preamble was the last transmission attempt of the random access preamble before the selection of the second beam.

16. The method according to claim 15, wherein, The fourth instruction includes an implicit instruction.

17. The method according to claim 16, wherein, The fourth indication includes the absence of a sign.

18. The method according to claim 14, wherein, The fourth indication specifies whether the previous transmission attempt of the random access preamble in the first beam failed before selecting the second beam for preamble transmission.

19. The method according to claim 18, wherein, The fourth instruction includes a sign.

20. The method according to any one of claims 14 to 17, wherein, The fourth indication specifies the number of consecutive failed transmission attempts of the random access preamble after the last successful transmission attempt of the random access preamble.

21. The method according to any one of claims 14 to 20, further comprising: Before receiving the random access information, send the Listen-Before-Speak (LBT) failure recovery configuration to the UE.

22. The method according to any one of claims 14 to 20, further comprising: In response to the network's failure to configure Listen-Before-Talk (LBT) recovery at the UE, the step of receiving the random access information is performed.

23. The method according to any one of claims 14 to 22, further comprising: In response to the fourth indication indicating that at least one failed transmission attempt of the preamble occurred after the last successful transmission attempt in the first beam, it is determined that the power used for the first successful preamble transmission in the second beam has been increased relative to the last successful transmission attempt in the first beam.

24. The method according to any one of claims 14 to 23, further comprising: In response to the fourth indication indicating that no failed transmission attempt has occurred since the last successful transmission attempt of the preamble in the first beam, it is determined that the power used for the first successful preamble transmission in the second beam is the same as the power used for the last successful transmission attempt in the first beam.

25. The method according to any one of claims 14 to 24, wherein, The first beam and the second beam include SSB or CSI-RS.

26. The method according to any one of claims 14 to 25, wherein, The fourth indication is received as part of the random access information in a random access report, radio link failure report, successful handover report, or successful PSCell change / addition report.

27. The method according to any one of claims 14 to 26, wherein, The random access information further includes one or more of the following: A first indication of a successful transmission attempt of a random access message, the first indication having an associated indication of the number of consecutive failed transmission attempts of the random access message experienced by the user equipment prior to the successful transmission attempt of the random access message, and A second indication of the total number of random access message transmission attempts.

28. The method according to any one of claims 14 to 27, wherein, The random access information further includes: whether the UE is configured with an indication of listen-before-talk (LBT) failure recovery configuration at one of the following: the time of the random access preamble transmission attempt or the time of initiating the random access procedure.

29. A user equipment comprising processing circuitry and a memory, the memory storing instructions executable by the processing circuitry, thereby enabling the user equipment to: Send random access information related to the random access procedure to the network node, the random access information including a fourth indication indicating whether, before selecting the second beam for the preamble transmission in the random access procedure, there has been at least one failed transmission attempt of the random access preamble after the last successful transmission attempt in the first beam.

30. The user equipment according to claim 29, wherein, The memory further stores instructions executable by the processing circuitry, thereby enabling the user equipment to perform the method described in any one of claims 2 to 13.

31. A user equipment, wherein, The user equipment is suitable for: Send random access information related to the random access procedure to the network node, the random access information including a fourth indication indicating whether, before selecting the second beam for the preamble transmission in the random access procedure, there has been at least one failed transmission attempt of the random access preamble after the last successful transmission attempt in the first beam.

32. The user equipment according to claim 31, wherein, The user equipment is further adapted to perform the method according to any one of claims 2 to 13.

33. A network node comprising processing circuitry and a memory, the memory storing instructions executable by the processing circuitry, thereby enabling the network node to: The user equipment receives random access information related to the random access procedure, the random access information including a fourth indication indicating whether, before the user equipment selects a second beam for preamble transmission in the random access procedure, there has been at least one failed transmission attempt of the random access preamble experienced by the user equipment after the last successful transmission attempt of the random access preamble by the user equipment in the first beam.

34. The network node according to claim 33, wherein, The memory stores further instructions executable by the processing circuitry, thereby enabling the network node to perform the method described in any one of claims 15 to 28.

35. A network node, wherein, The network node is suitable for: The user equipment receives random access information related to the random access procedure, the random access information including a fourth indication indicating whether, before the user equipment selects a second beam for preamble transmission in the random access procedure, there has been at least one failed transmission attempt of the random access preamble experienced by the user equipment after the last successful transmission attempt of the random access preamble by the user equipment in the first beam.

36. The network node according to claim 35, wherein, The network node is further adapted to perform the method according to any one of claims 15 to 28.

Images