Random access with new radio unlicensed cell

Abstract

This application discloses utilizing new radio unlicensed cell for random access. A method can perform listen-before-talk (LBT) compliant random access in an NR-U serving cell with multiple models. Random access preamble transmission procedure can be enhanced to enable autonomous BWP switching or subband in case the channel is busy with active UL BWP.

Description

[0001] This application is a divisional application of the application patent application entitled "Random Access with New Radio Unlicensed Cells" with the filing date of April 4, 2019, application number 201980029430.7.

[0002] Cross Reference to Related Applications

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 652,710, filed April 4, 2018, entitled "Random Access with New Radio Unlicensed Cells," and U.S. Provisional Patent Application No. 62 / 753,593, filed October 31, 2018, entitled "Random Access with New Radio Unlicensed Cells," the contents of each of which are incorporated by reference in their entirety. BACKGROUND

[0004] Carrier aggregation with at least one SCell operating in unlicensed spectrum is referred to as License Assisted Access (LAA). Thus, in LAA, the set of serving cells configured for a UE always includes at least one SCell operating in unlicensed spectrum according to frame structure type 3, also referred to as LAA SCell. Unless otherwise specified, LAA SCells behave as regular SCells as disclosed in 3GPP TS 36.300, Overall Description; Stage 2 (Release 15), V15.0.0, which is incorporated by reference herein in its entirety.

[0005] LAA eNBs and UEs apply Listen-Before-Talk (LBT) before performing transmissions on LAA SCells. When LBT is applied, a transmitter listens / senses the channel to determine whether the channel is idle or busy. If the channel is determined to be idle, the transmitter can perform a transmission; otherwise, the transmitter does not perform a transmission. If the LAA eNB uses a channel access signal of other technology for LAA channel access, it shall continue to meet the LAA maximum energy detection threshold requirement.

[0006] Frame structure type 3 is applicable only for LAA- assisted cell operation with normal cyclic prefix. Each radio frame is T f = 307200 · T s = 10 ms long and consists of 20 length-T slot = 15360 · T sA slot consists of 0.5 ms, and these slots are numbered from 0 to 19. A subframe is defined as two consecutive slots, where subframe i consists of slots i and 2i+1, as disclosed in 3GPP TS 36.211, Physical Channels and Modulation (Release 15), V15.0.0, which is incorporated herein by reference in its entirety.

[0007] Ten subframes within a radio frame can be used for downlink or uplink transmission. Downlink transmission occupies one or more consecutive subframes, starting from anywhere within one subframe, to the last subframe or following one of the DwPTS durations specified in Table 4.2-1 of 3GPP TS 36.211. Uplink transmission occupies one or more consecutive subframes.

[0008] 3GPP TR 38.913, Study on Scenarios and Requirements for Next Generation Access Technologies; (Release 14), V14.3.0 defines scenarios and requirements for next generation access technologies. Table 1 summarizes the key performance indicators (KPIs) for eMBB, URLLC, and mMTC devices.

[0009] Table 1: KPIs for eMBB, URLLC, and mMTC devices

[0010]

[0011] SUMMARY

[0012] An exemplary method can perform Listen-Before-Talk (LBT) random access in a NR-U serving cell with multiple models, where in one model the behavior of the MAC random access procedure remains unchanged, and the impact of LBT on the procedure is limited to the PHY layer, while in an alternative model the MAC is informed of every instance of a random access preamble that failed to transmit due to the outcome of LBT, so the MAC can take the necessary corrective actions. Some specific proposals envision include the following enhancements, definitions, and procedures.

[0013] The enhancements can be to the random access resource selection procedure to enable selection of PRACH associated with multiple BWPs or sub-bands. Enhancements can be made to the random access preamble transmission procedure to enable autonomous BWP switching or sub-bands in case the channel is busy with active UL BWPs. There can be definitions of random access preamble (RAP) transmission indications that can be used to inform the MAC of a successful preamble transmission attempt and the BWP used for the preamble transmission. There can be procedures to correct errors in Timing Advance Command due to delays in preamble transmission caused by LBT.

[0014] Exemplary methods can perform two-step RACH, which can include: 1) defining a MAC PDU to signal MsgA and MsgB; 2) performing MAC procedures for MsgA transmission and MsgB reception; 3) falling back to procedures of four-step RACH when two-step RACH fails; or 4) falling back to scheduled transmission to complete the handover procedure when two-step RACH fails.

[0015] Exemplary methods can perform LBT prioritization to support random access prioritization procedures.

[0016] This summary is provided to introduce some concepts of the present disclosure in a simplified form that are further described below in the DETAILED DESCRIPTION. This summary is neither intended nor should it be construed to be an identification of the key features or essential features of the claimed subject matter, nor is it intended to be used in determining the scope of the claimed subject matter. Further, the claimed subject matter is not limited to resolving any or all of the disadvantages with respect to any part of the disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0017] A more detailed understanding can be had from the following description, which is given by way of example in conjunction with the accompanying drawings wherein:

[0018] Figure 1 illustrates exemplary cell coverage with sector beams and multiple high-gain narrow beams;

[0019] Figure 2 illustrates an exemplary NR random access procedure;

[0020] Figure 3 illustrates an exemplary interaction model between L1 and L2 / 3 for random access procedures;

[0021] Figure 4 illustrates an exemplary BA;

[0022] Figure 5 illustrates an exemplary random access for NR-U serving cell using sub-band LBT and BWP switching;

[0023] Figure 6 Figure illustrates an exemplary algorithm where the UE performs sub-band LBT on the UL BWP sequentially;

[0024] Figure 7 Figure illustrates an exemplary algorithm where the UE performs sub-band LBT on the UL BWP simultaneously;

[0025] Figure 8 Figure illustrates an exemplary timing for BWP switching with sub-band LBT on multiple BWPs sequentially;

[0026] Figure 9 Figure illustrates an exemplary timing for BWP switching with sub-band LBT on multiple BWPs simultaneously;

[0027] Figure 10 Figure illustrates an exemplary Model 1 solution for random access for NR-U serving cell using sub-band LBT and BWP switching;

[0028] Figure 11A Figure illustrates an exemplary Model 2 solution for random access for NR-U serving cell using sub-band LBT and BWP switching;

[0029] Figure 11B Another description of the scenario of Figure 11A is provided;

[0030] Figure 12 Figure illustrates an exemplary two-step RACH procedure;

[0031] Figure 13 Figure illustrates an exemplary R / F / LCID / L MAC subheader with 8-bit L field;

[0032] Figure 14 Figure illustrates an exemplary R / F / LCID / L MAC subheader with 16-bit L field;

[0033] Figure 15 Figure illustrates an exemplary R / LCID MAC subheader;

[0034] Figure 16 Figure illustrates an exemplary MsgA MAC PDU;

[0035] Figure 17 Figure illustrates an exemplary MAC RAR for MsgB;

[0036] Figure 18 Figure illustrates an exemplary MAC PDU consisting of MsgB RARs;

[0037] Figure 19 Figure illustrates an exemplary fallback to four-step RACH procedure;

[0038] Figure 20 An example fallback to four-step RACH procedure triggered via MsgB is illustrated;

[0039] Figure 21 An example fallback to four-step RACH procedure is illustrated;

[0040] Figure 22 An example two-step RACH procedure during handover is illustrated;

[0041] Figure 23 An example prioritized random access with NR-U serving cell is illustrated;

[0042] Figure 24 An example display generated by a method and system that can reduce mobility signaling load is illustrated;

[0043] Figure 25A An example communication system is illustrated;

[0044] Figure 25B An example system including a RAN and a core network is illustrated;

[0045] Figure 25C An example system including a RAN and a core network is illustrated;

[0046] Figure 25D An example system including a RAN and a core network is illustrated;

[0047] Figure 25E Another example communication system is illustrated;

[0048] Figure 25F A block diagram of an example apparatus or device, such as a WTRU, is illustrated;

[0049] Figure 25G A block diagram of an example computing system is illustrated. DETAILED DESCRIPTION

[0050] NR Beamformed Access: Based on the understanding that the characteristics of the wireless channel at higher frequencies are significantly different from the sub-6 GHz channels of current LTE deployments, the following is disclosed a framework for beamformed access. The challenge in designing a new radio access technology (RAT) for higher frequencies will be to overcome the greater path loss at higher frequency bands. In addition to this greater path loss, higher frequencies are also affected by an unfavorable scattering environment due to blockage caused by poor diffraction. Thus, MIMO / beamforming can help to ensure sufficient signal levels at the receiver end.

[0051] Relying only on MIMO digital precoding used by digital beamforming to compensate for additional path loss at higher frequencies seems insufficient to provide similar coverage as below 6 GHz. Therefore, using analog beamforming in combination with digital beamforming to obtain additional gain can be an alternative. A sufficiently narrow beam should be formed with many antenna elements, which can be quite different from the beams assumed for LTE evaluation. For large beamforming gain, the beam width tends to decrease accordingly, so a beam with a large directional antenna gain cannot cover the entire horizontal sector area in a 3-sector configuration in particular. Limiting factors for the number of concurrent high-gain beams include the cost and complexity of the transceiver architecture.

[0052] Considering the above observations, having multiple transmissions in time domain with narrow coverage beams steered towards covering different service areas can help to solve some problems. The analog beams of the sub-arrays can be steered in a single direction with time resolution of OFDM symbols or any appropriate time interval unit defined for beam control across different service areas within a cell, so the number of sub-arrays can determine the number of beam directions and the corresponding coverage defined for beam steering on each OFDM symbol or time interval unit. In some literature, providing multiple narrow coverage beams for this purpose is referred to as "beam sweeping". For analog and hybrid beamforming, beam sweeping helps to provide basic coverage in NR. In Figure 1 This concept is illustrated in FIG. 1 1, where the coverage of a sector-level cell is implemented with sector beams and multiple high-gain narrow beams. Also, for analog and hybrid beamforming with massive MIMO, multiple transmissions in time domain with narrow coverage beams steered towards covering different service areas are used to cover the entire coverage area within a serving cell in NR.

[0053] One concept related to beam sweeping is the concept of beam pairing, which is used to select the best beam pair between a UE and its serving cell, which can be used for control signaling or data transmission. For downlink transmission, the beam pair can include a UE RX beam and a NR node TX beam, while for uplink transmission, the beam pair can include a UE TX beam and a NR node RX beam.

[0054] Another related concept is the concept of beam training, which can be used for beam refinement. For example, as shown in Figure 1 illustrated in FIG. 12, a coarser sector beamforming can be applied during the beam sweeping and sector beam pairing process. Then beam training can be performed, e.g., in which the antenna weight vectors are refined, and then pairing of high-gain narrow beams between the UE and the NR node.

[0055] NR random access procedure: The random access procedure can be triggered by multiple events, e.g.: 1) initial access from RRC_IDLE; 2) RRC connection re-establishment procedure; 3) handover; 4) DL or UL data arrival while the UL synchronization status is "non-synchronized" during RRC_CONNECTED; 5) transition from RRC_INACTIVE; 6) requiring other SI; or 7) beam failure recovery.

[0056] Furthermore, as shown in Figure 2 the random access procedure generally takes two different forms: contention-based and contention-free. Normal DL / UL transmissions can take place after the random access procedure.

[0057] For initial access in a cell configured with a supplementary uplink (SUL), the UE can use the SUL carrier if and only if the measured quality of the DL is below a broadcast threshold. Once started, all uplink transmissions of the random access procedure remain on the selected carrier.

[0058] The above random access procedure is modeled in Figure 3 from the perspective of L1 and L2 / L3 interactions. After indicating to L1 to transmit a random access preamble, L2 / L3 receives an indication from L1 whether an ACK is received or DTX is detected. L2 / 3 indicates to L1 to transmit the first scheduled UL transmission (RRC connection request in case of initial access) as needed, or to transmit a random access preamble based on the indication from L1.

[0059] With bandwidth adaptation (BA), the UE's reception and transmission bandwidth does not have to be as large as the cell's bandwidth and can be adjusted: the width can be commanded to change (e.g., shrink during low activity to save power); the location can be moved in the frequency domain (e.g., to improve scheduling flexibility); and the subcarrier spacing can be commanded to change (e.g., to allow different services). A subset of the total cell bandwidth of a cell is called a bandwidth part (BWP) and BA is implemented by configuring the UE with BWP(s) and telling the UE which of the configured BWP is the current active BWP.

[0060] Figure 4 A case where 3 different BWPs are configured is described: 1) BWP1 has a width of 40 MHz and a subcarrier spacing of 15 kHz; 2) BWP2 has a width of 10 MHz and a subcarrier spacing of 15 kHz; and 3) BWP3 has a width of 20 MHz and a subcarrier spacing of 60 kHz.

[0061] A serving cell can be configured with four BWPs and at any point in time there is one active BWP for the activated serving cell. BWP switching for a serving cell is used to activate an inactive BWP and deactivate the active BWP at a time and is controlled by PDCCH indicating downlink assignment or uplink grant. After adding a SpCell (special cell) or activating a SCell, one BWP is initially active without receiving PDCCH indicating downlink assignment or uplink grant. The active BWP for a serving cell is indicated by RRC or PDCCH. For unpaired spectrum, DL BWP is paired with UL BWP and BWP switching is common for UL or DL.

[0062] Referring to the first issue, for LTE, when UL transmission is performed with a License Assisted Access (LAA) SCell, the MAC entity considers that the transmission has been performed regardless of the LBT outcome, as disclosed in 3GPP TS 36.321, Medium Access Control (MAC) protocol specification (Release 15), V15.0.0, which is incorporated by reference herein in its entirety. For LTE, it is not expected to perform random access with LAA SCell, so there is no need to make enhancements to mitigate the impact of this behavior on the random access procedure.

[0063] For NR-U, it is expected to perform random access with NR-U SCell (Carrier Aggregation - CA - deployment), NR-U PSCell (Dual Connectivity - DC - deployment), and NR-U PCell (Stand-alone - SA - deployment). If the LTE approach for UL transmission with LAA SCell is applied when performing random access in NR-U serving cells, then if LBT fails for Msgl transmission, the UE will wait for the ra-ResponseWindow to expire before attempting retransmission. Similarly, if LBT fails for Msg3, then the transmission of Msg3 can be delayed or even cause the failure of the random access procedure. To reduce the latency when performing the random access procedure in NR-U cells, solutions to avoid unnecessary random access delays due to LBT should be considered.

[0064] Referring to the second question, the NR random access procedure can be triggered by multiple events, as described in 3GPP TS 38.300, NR; NR and NG-RAN Overall Description; Stage 2 (Release 15), V15.0.0, which is incorporated herein by reference in its entirety. Prioritized random access procedures can be incorporated into NR Stage 1, for example, for handover using contention-based access, or for beam fault recovery (BFR) procedures. Considering that listen-before-speak (LBT) failure can cause random access failure or delays during successful random access completion, further enhancements to prioritized random access with LBT should be considered.

[0065] This document discloses several techniques for addressing the two problems mentioned above, as well as other issues. The first technique can be associated with methods for performing LBT-compliant random access in NR-U serving cells with multiple solution models. In one model, the behavior of the MAC random access procedure remains unchanged due to the impact of LBT on the PHY-layer-limited process, while in an alternative model, the MAC is notified of each instance of a failed random access preamble transmission as a result of LBT, allowing the MAC to take necessary corrective actions. Some specific disclosed methods for performing LBT-compliant random access can include the following four approaches. The first approach includes enhancements to the random access resource selection process to enable the selection of PRACH associated with multiple BWPs or subbands. The second approach includes enhancements to the random access preamble transmission process to enable autonomous BWP handover or subband switching when the channel used for the active UL BWP is "busy." The third approach includes a random access preamble (RAP) transmission indication and a BWP for preamble transmission that can be used to notify the MAC of a successful preamble transmission attempt. The fourth approach includes a process for correcting errors in the timing advance command caused by delays in preamble transmission due to LBT.

[0066] The second technique may include a method for performing a two-step RACH, which may include: 1) defining a MAC PDU to signal MsgA and MsgB; 2) performing a MAC procedure for MsgA transmission and MsgB reception; 3) a procedure to fall back to a four-step RACH if the two-step RACH fails; or 4) a procedure to fall back to scheduled transmissions to complete the handover procedure if the two-step RACH fails. The third technique may include a method for performing LBT prioritization to support a random access prioritization procedure.

[0067] Depending on the deployment scenario, the NR-U serving cell can be configured as a SCell, PSCell, or PCell. For carrier aggregation (CA) between licensed frequency bands NR (PCell) and NR-U (SCell), random access can be performed using the NR-U SCell for the following events: 1) establishing time alignment with the NR-U SCell; or 2) beam fault recovery.

[0068] For dual connectivity (DC) between LTE (PCell) and NR-U (PSCell) in licensed frequency bands, random access can be performed using the NR-U PSCell for the following events: 1) CG addition / modification; 2) UL / DL data arrival when UL is "out of sync" or there is no PUCCH resource; or 3) beam fault recovery. For UL / DL data arrival, when UL is "out of sync," DL data arrival can trigger RACH on the NR-U PSCell or NR-U SCell of the SCG, while when UL is "out of sync" or there is no PUCCH resource, UL data arrival can trigger RACH on the NR-U PSCell.

[0069] For standalone (SA) NR-U, random access can be performed in an NR-U SA cell for the following events: 1) initial access; 2) RRC connection re-establishment; 3) handover; 4) arrival of UL / DL data when UL is “out of sync” or there is no PUCCH resource; 5) transition from RRC_INACTIVE; 6) request for other SIs; or 7) beam fault recovery.

[0070] Techniques are described that can address the problems described herein, which are associated with performing random access using an NR-U serving cell. These techniques are intended to be used in conjunction with events that trigger the random access procedures described herein. Some of these techniques are illustrated using specific triggering events, such as the reception of a PDCCH command. However, this does not preclude the use of these techniques in conjunction with other events that trigger the random access procedures described herein.

[0071] Figure 5This is an illustration of signaling that can be used to perform random access in an NR-U serving cell using subband LBT and BWP handover. At step 211, a random access procedure is initiated at UE 201, and UE 201 can perform random access resource selection. At step 212, UE 201 performs LBT subband LBT and BWP handover (if necessary) before preamble transmission. At step 213, if the channel used for at least one of the UL BWPs is "idle" (e.g., it is determined that the channel is not occupied by other devices), then the random access preamble (RAP) is transmitted to gNB 202. At step 214, if the preamble was transmitted in step 213, then UE 201 monitors the PDCCH used for the random access response (RAR) and can subsequently obtain it (e.g., sent by gNB 202).

[0072] When execution Figure 5 During the random access procedure described herein, UE 201 may be configured with one or more BWPs for the NR-U serving cell, wherein one of the configured BWPs is active at a given time.

[0073] BWP handover can be performed after a random access procedure is initiated using an NR-U serving cell to activate the inactive BWP and deactivate the active BWP. BWP handover can be controlled using PDCCH commands or RRC signaling. If no PRACH resources are configured for the active UL BWP, UE 201 can also autonomously perform BWP handover at the start of the random access procedure, in which case UE 201 switches to the initial BWP.

[0074] The LBT procedure can be performed on the active UL BWP before the preamble transmission. If the LBT procedure indicates that the channel is "idle", then UE 201 can begin the preamble transmission on the active UL BWP. If the LBT procedure indicates that the channel is "busy" for the active UL BWP, then the BWP handover can be performed autonomously by UE 201.

[0075] The execution of BWP handover can be controlled by specifying rules. For example, if the active BWP is not the default BWP and the default BWP is configured with PRACH resources, then UE 201 can automatically switch to the default BWP (if it is configured). If no default BWP is configured or if the default BWP is not configured with PRACH resources, then UE 201 can automatically switch to the initial BWP, provided that the active BWP is not the initial BWP.

[0076] After switching BWPs, an LBT procedure can be performed on the active UL BWP (e.g., the default UL BWP or the initial UL BWP) before preamble transmission. If the LBT procedure indicates the channel is "idle," then UE 201 can begin preamble transmission on the active UL BWP. If the LBT procedure indicates the channel is "busy," then UE 201 can attempt to perform a preamble transmission stop for the current PRACH timing. Depending on the capabilities of UE 201, the LBT procedures performed on the UL BWPs can be completed sequentially or simultaneously.

[0077] Alternative rules can also be defined, allowing the BWP to be switched multiple times during the PRACH timing. For example, a first preamble transmission attempt can be made on the active UL BWP. If the LBT indicates the channel is "busy," then the BWP is switched to the default BWP, and another attempt is made. If the LBT indicates the channel on the default UL BWP is "busy," then the BWP is switched back to the initial BWP, and a final attempt is made.

[0078] In another example, UE 201 can select a BWP to autonomously hand over to, where the selected BWP comes from a set of inactive BWPs configured with PRACH resources; if an attempt to use such a BWP fails, UE 201 can make a final attempt with the initial BWP. Alternatively, the set of BWPs to be selected can be signaled to UE 201 (e.g., a PDCCH command can be used to indicate which configured BWP UE 201 can autonomously hand over to). Autonomous handover can be considered as a handover performed without instruction from a remote network device.

[0079] In yet another example, how to perform BWP handover can be left to the UE implementation, but the maximum number of BWP handovers performed can be controlled by a counter, the value of which can be signaled to UE201 via higher-layer signaling or specified in the standard.

[0080] Figure 6 This is an exemplary illustration of a rule-based algorithm where preamble transmission can be attempted on up to two BWPs. The first attempt is on the active UL BWP, followed by a second attempt on the default or initial UL BWP. In this example, UE 201 sequentially performs subband LBT on the UL BWPs. (Reference) Figure 6At step 221, LBT can be performed on the active ULBWP. At step 222, if it is determined that the channel is idle, proceed to step 227 to transmit the preamble on the active ULBWP. If it is determined that the channel is not idle, at step 223 it can also be determined whether the active BWP is the default BWP. If it is not the default BWP, proceed to step 224, and additionally determine whether the default BWP is configured with PRACH resources. If PRACH resources are configured, at step 225, switch to the default BWP and perform LBT. If the channel is idle at step 226, proceed to step 227 to transmit the preamble on the active UL BWP. Note that at step 224, if no PRACH resources are configured, at step 228 it is additionally determined whether the active BWP is the initial BWP.

[0081] Continue to refer to Figure 6 At step 223, if it is determined that the active BWP is the default BWP, then proceed to step 229 to switch to the initial BWP and perform LBT. And if the channel is idle, then proceed to step 227 to transmit the preamble on the active ULBWP.

[0082] Figure 7 This is an illustration of a similar algorithm, in which UE 201 performs subband LBT on UL BWP simultaneously (e.g., at essentially the same time).

[0083] Table 2 below provides algorithms for rule-based BWP handover (such as...). Figure 6 Example pseudocode for the algorithm described in [the document] using random access resource selection by the UE:

[0084] Table 2

[0085]

[0086] Table 2 below provides algorithms for rule-based BWP handover (such as...). Figure 7 Example pseudocode for random access resource selection using the algorithm described in [the document]:

[0087] Table 3

[0088]

[0089]

[0090] Figure 8 It is aimed at Figure 6The diagram illustrates the timing of BWP handover in the algorithm described, where UE 201 sequentially performs subband LBT on multiple UL BWPs. In this example, the NR-U serving cell is configured with four BWPs. When the random access procedure is initiated, BWP1 is the active BWP, and BWP2 is the default BWP, which is configured with PRACH resources. LBT is performed on BWP1 (the active BWP), indicating that the channel is "busy". At time t1, UE 201 autonomously hands over to BWP2 (the default BWP) and performs LBT, indicating that the channel is "idle". At time t2, UE 201 begins preamble transmission on the active BWP (i.e., BWP2).

[0091] Figure 9 yes Figure 7 The diagram illustrates the timing of BWP handover in the algorithm described, where UE 201 simultaneously performs subband LBT on multiple UL BWPs. In this example, the NR-U serving cell is configured with four BWPs. When the random access procedure is initiated, BWP1 is the active BWP, and BWP2 is the default BWP, which is configured with PRACH resources. LBT is performed simultaneously on both BWP1 (active BWP) and BWP2 (default BWP). The LBT procedure performed on BWP1 indicates that the channel is "busy," while the LBT procedure performed on BWP2 indicates that the channel is "busy." At time t1, UE 201 autonomously switches the active BWP to BWP2 and begins preamble transmission.

[0092] With regard to Problem Statement 1 (i.e., the first problem disclosed above), the technical statement can be further modeled based on the UE behavior in the MAC layer and the UE behavior in the PHY layer, as well as the interaction between the MAC layer and the PHY layer, as described below.

[0093] As disclosed herein, one approach can be used to perform Listen-Before-Speak (LBT) random access in an NR-U serving cell using multiple models. In the first model, the behavior of the MAC random access procedure remains unchanged, while the effect of LBT on the procedure is limited to the PHY layer. In the second model, due to the results of LBT, the MAC is notified of each instance that failed to transmit the random access preamble, and thus the MAC can take necessary corrective actions.

[0094] Referring to the first model, due to the LBT result, the MAC is notified of each instance where the random access preamble failed to be transmitted, and therefore the MAC can take necessary corrective actions. In summary, this series of techniques can be considered as follows: the MAC transmits MSG1 or MSG3 of the random access procedure to the PHY. For each instance where MSG1 or MSG3 cannot be transmitted, the PHY can notify the MAC of the failed instance, and the MAC can then take necessary actions, such as re-initiating message retransmissions with different LBT parameters, such as channel access priority categories, including corresponding access parameters, energy detection thresholds, etc. Parameters that should be used for MSG1 or MSG3 transmission (such as frequency subbands or BWP) can also be provided to the PHY.

[0095] Referring to the second model, this technology family can generally be considered as follows: (via RRC or MAC) the PHY is configured with multiple sets of LBT parameters (e.g., frequency subband, BWP, channel access priority category, or corresponding channel access parameters). As a result of channel busyness from the LBT process, the PHY notifies the MAC of the failure to transmit a random access message (Msg1 or Msg3), not per LBT instance, but after the PHY has performed one or more LBT attempts based on the LBT configuration parameters configured for the PHY and concludes that the LBT process has failed. In this case, the MAC can treat the LBT failure as a normal failure of the process that triggered the LBT (in this case, the random access process) and notify the RRC layer accordingly.

[0096] To support this second model, the PHY or MAC can be configured with more than one BWP / subband (e.g., a RACH default or RACH primary BWP / subband, followed by other RACH secondary BWP / subbands, or prioritization of BWP / subbands). For example, if the PHY does not already have such a list configured, the MAC can provide the PHY with a list of BWPs / subbands to be used for the random access procedure. Note that a BWP can include multiple subbands. The topics presented in this paper for different BWPs can also be applied to subbands within the same BWP.

[0097] After triggering random access from the MAC, the PHY can perform LBT on the BWP / subbands in descending order of priority. The priority order can be, for example, primary or default RACH - the BWP / subband is the highest priority BWP / subband used to perform the random access procedure. LBT is considered successful when it succeeds on one of the BWP / subbands configured for the PHY. The PHY then transmits MSG1 (or Msg3) on the BWP / subband where the LBT was successfully performed.

[0098] Alternatively, the PHY can perform LBT on more than one BWP / subband. The PHY then selects one of the BWP / subbands with successful LBT (e.g., the channel is not busy) to perform RACH, where the criteria for selecting the BWP / subband for the RACH procedure can be based on: 1) the lowest CBR (Channel Busy Rate); 2) the lowest channel occupancy rate; 3) the BWP / subband with the most configured dedicated RACH resources; or 4) the BWP / subband with the most configured public RACH resources. The PHY then transmits MSG1 on the selected BWP / subband from the BWP / subbands that have successfully performed LBT.

[0099] In another alternative, the PHY can perform LBT on more than one BWP / subband, and then select more than one BWP / subband from the BWP / subbands with successful LBTs to perform a random access procedure. The number of BWP / subbands selected can be configured and can be configured for either the PHY or MAC. The PHY then transmits MSG1 (or Msg3) on the selected BWP / subband without waiting for RAR on the BWP / subband.

[0100] The following discloses a method for performing random access in an NR-U serving cell using subband LBT and BWP handover in association with a first model (e.g., model 1). Figure 10This is an example illustration of signaling based on Model 1 technology, which can be used to perform random access with respect to the NR-U serving cell using subband LBT and BWP handover, where the random access procedure is initiated by the network via PDCCH commands. The signaling for Model 1 can be summarized as RACH initiation and resource selection (step 260), RAP transmission (step 261), and RAR reception (step 262). At step 260, a random access procedure is initiated at UE 201 (e.g., based on obtaining the PDCCH), and UE 201 performs random access resource selection. At step 251, the MAC entity 204 provides a set of parameters to PHY 205 to configure preamble transmission. These parameters include preamble index, selected PRACH resources, BWP, LBT parameters, etc. At step 252, PHY 205 can then perform subband LBT on the selected BWP. If the channel is "busy," then at step 253, a RAP transmission indication can be sent to notify the MAC of the failure to transmit the preamble. At step 254, MAC 204 can then perform random access resource selection using a different BWP and repeat this process. When the channel is “idle,” at step 256, the preamble is transmitted (step 257), and a RAP transmission indication can be sent to notify MAC 204 that the preamble has been transmitted. While the preamble is being transmitted, UE 201 can monitor the RAR on the PDCCH (e.g., step 258).

[0101] The following discloses a method for performing random access in an NR-U serving cell using subband LBT and BWP handover in association with a second model (e.g., Model 2). Figure 11 is a diagram of signaling based on the Model 2 technique, which can be used to perform random access with respect to an NR-U serving cell using subband LBT and BWP handover, wherein the random access procedure is initiated by the network via a PDCCH command.

[0102] exist Figure 11A In the scenario described, if the random access response window timer expires, the MAC can notify the RRC of the failure of the random access procedure (not shown). Figure 11B Provided with Figure 11A Another depiction of the same scenario. The signaling used for Model 2 can be summarized as RACH initiation (step 270a) and resource selection (step 270b), RAP transmission (step 271), and RAR reception (step 272). This document provides more details.

[0103] The following UE variables can be used when performing a random access procedure:

[0104] 1) PREAMBLE_INDEX;

[0105] 2)PREAMBLE_TRANSMISSION_COUNTER;

[0106] 3)PREAMBLE_POWER_RAMPING_COUNTER;

[0107] 4)PREAMBLE_RECEIVED_TARGET_POWER;

[0108] 5) PREAMBLE_BACKOFF;

[0109] 6) PCMAX; or

[0110] 7) TEMPORARY_C-RNTI.

[0111] These UE variables are typically configured in step 270 and can be used by PHY 205 in step 271. Since MAC 204 typically waits for confirmation that the preamble from PHY 205 has been transmitted, the counter cannot increment until step 271.

[0112] Referring to step 270a's RACH initiation, UE 201 receives the PDCCH command to initiate the random access procedure. gNB 202 can transmit the PDCCH command, thus UE 202 can establish time alignment with the NR-U serving cell, where, depending on the deployment scenario, the NR-U serving cell can be configured as SCell, PSCell, or PCell. The PDCCH command may include one or more of the following parameters: 1) preamble index; 2) PRACH mask index; or 3) BWP handover command. If the PDCCH command may include a BWP handover command, then the BWP is switched according to that command. MAC entity 204 may initialize UE variables as follows: 1) PREAMBLE_TRANSMISSION_COUNTER is set to 1; 2) PREAMBLE_POWER_RAMPING_COUNTER is set to 1; 3) PREAMBLE_BACKOFF is set to 0ms; 4) PCMAX is set to the P... provided by the higher layer. CMAX,c The value; for example, RRC signaling; 5) PREAMBLE_INDEX is set to the value of the preamble index notified by a signal in the PDCCH command; or 6) PRACH_MASK_INDEX is set to the value of the PRACH mask index notified by a signal in the PDCCH command. The PDCCH commands mentioned above can be applied to other PDCCH commands (e.g., Figure 10 Step 26 or Step 270 in Figure 11).

[0113] Referring to the resource selection in step 270b, MAC entity 204 can perform random access resource selection. To enable autonomous BWP handover when the channel used for the active UL BWP is "busy," MAC 204 can select a PRACH associated with multiple BWPs, which may include the active BWP, the default BWP, the initial BWP, or a configured inactive BWP. The selected resources can be provided to PHY 205 in an ordered list, for example, sorted according to the associated BWPs.

[0114] The following example pseudocode in Table 4 is used for rule-based BWP switching algorithms (such as...). Figure 6 or Figure 7 The algorithm described in Table 4 is used for random access resource selection. The text in Table 4 may be a procedural description of the behavior described in 270b.

[0115] Table 4

[0116]

[0117]

[0118] To provide the network with control over autonomous BWP handover, PDCCH commands (e.g., step 270 in Figure 11 or...) are used. Figure 10 Step 260) may also include the following parameters: 1) a flag to enable / disable autonomous BWP switching; or 2) a set of BWP IDs that can be used for autonomous BWP switching.

[0119] One or more UE variables can be defined to store parameter values. For example, a UE variable named BWP_SWITCHING_CONTROL can be defined as a bit field, where each bit in the field can be set or cleared to indicate whether the corresponding BWP can be used for autonomous BWP handover.

[0120] In one example, the BandwidthPartID used for configuring a BWP can be used to associate the configured BWP with the corresponding bit in the bit field; for example, a BWP with ID 0 will correspond to bit 0, a BWP with ID 1 will correspond to bit 1, and so on. Additional bits can be reserved for the default BWP and the initial BWP. For example, if we assume that a maximum of 4 BWPs can be configured for the serving cell, then the 4th and 5th bits of the bit field can be used for the default BWP and the initial BWP, respectively.

[0121] At step 271, UE 201 may perform preamble transmission. As part of this step 271, MAC entity 204 calculates the PREAMBLE_RECEIVED_TARGET_POWER and RA-RNTI associated with the PRACH in which the preamble is transmitted. In some cases, the PRACH resource configurations used for the configured BWPs may be different. To enable autonomous BWP handover in the event that the channel used for the active UL BWP is "busy", MAC 204 may calculate the RA-RNTI for PRACH associated with multiple BWPs, which may include the active BWP, the default BWP, the initial BWP, or a configured inactive BWP.

[0122] For example, if a rule-based BWP handover algorithm (such as...) is used... Figure 6 or Figure 7 If the algorithm described in [the document] is followed, then MAC204 can calculate the RA-RNTI associated with the active BWP and the default BWP; or the active BWP and the initial BWP. If the default BWP is configured with PRACH resources and it is assumed that the active BWP is not the default BWP, then parameters can be calculated for the default BWP. Otherwise, assuming that the active BWP is not the default BWP, then parameters can be calculated for the initial BWP.

[0123] After calculating PREMBLE_RECEIVED_TARGET_POWER and (one or more) RA-RNTIs, MAC entity 204 can instruct PHY 205 to transmit the preamble using a selected (one or more) PRACH, the corresponding (one or more) RA-RNTI, PREMBLE_INDEX, or PREMBLE_RECEIVED_TARGET_POWER. PHY 205 can then perform subband LBT and BWP switching (if necessary) before preamble transmission.

[0124] Table 5 below provides algorithms for rule-based BWP handover (such as...). Figure 6 or Figure 7 Example pseudocode for preamble transmission of the algorithm described in [the document].

[0125] Table 5

[0126]

[0127]

[0128] PHY 205 can notify MAC 204 of the result of a preamble transmission attempt. For example, an indication (e.g., a RAP transmission indication) can be used to notify MAC 204 of a successful preamble transmission attempt and the BWP used for the preamble transmission. This indication can also be used to explicitly notify MAC 204 of an unsuccessful preamble transmission; for example, if the UL BWP on which LBT is performed is “busy.” Alternatively, depending on how the indication is designed, there is no such indication that can be used to implicitly notify MAC 204 of the preamble transmission result.

[0129] At step 272, UE 201 can perform a random access response (RAR) reception. Once the preamble has been transmitted, MAC 204 can initiate the ra-ResponseWindow at the beginning of the first PDCCH timing, X symbol durations after the end of the preamble transmission.

[0130] When performing random access on an NR-U SpCell (e.g., PCell for MCG and PSCell for SCG), UE 201 uses the active BWP of the SpCell to monitor the RAR identified by RA-RNTI on the PDCCH of the SpCell during ra-ResponseWindow operation, where the active BWP of the SpCell corresponds to the BWP used for preamble transmission.

[0131] When performing random access on an NR-U SCell, UE 201 can also monitor the RAR on the PDCCH of the SpCell. However, in this case, the active BWP of the SpCell may not be the same as the BWP used for preamble transmission because the preamble transmission occurs on a different cell (e.g., SCell).

[0132] To increase the likelihood of gNB 202 successfully accessing the channel when attempting to transmit RAR on the downlink from SpCell, UE 201 can use multiple BWPs to monitor RAR on the PDCCH of SpCell. Note that multiple BWPs can typically be monitored simultaneously, and some actions are generally targeted at the PHY, while others are targeted at the MAC. gNB 202 can then use a DL BWP to transmit RAR, where LBT indicates the channel is "idle".

[0133] The RAR can include a timing advance command, which can be used to adjust the timing of a TAG that includes information about the NR-U serving cell UE 201 performing the random access procedure. gNB 202 can calculate the timing advance command assuming the preamble transmission begins at the start of the PRACH timing. However, since UE 201 can be required to perform LBT before the preamble transmission, which results in a BWP handover followed by an additional LBT procedure, the preamble transmission can begin at time Δt (greater than zero) relative to the start of the PRACH timing. MAC entity 204 can correct the timing advance command by subtracting the value Δt before application. Alternatively, the PHY can maintain the value Δt and apply the correction.

[0134] When performing random access on an NR-U SpCell, a time advance command can be applied to the pTAG. Furthermore, when performing random access on an NR-U SCell, a time advance command can be applied to the sTAG, including the NR-U SCell. After applying the time advance command, MAC entity 204 can start or restart the timeAlignmentTimer associated with the TAG.

[0135] Table 6 below provides rule-based BWP handover algorithms (such as...) Figure 6 or Figure 7 The following is a pseudocode example for receiving RAR data (as described in the code above).

[0136] Table 6

[0137]

[0138]

[0139] Among other things, the following discloses, in particular, a method for performing a two-step RACH. A two-step process can be used to reduce the number of LBT procedures performed during the random access procedure. Figure 12 This is an exemplary diagram of a signaling diagram used to perform a two-step random access procedure (RACH). The techniques disclosed herein for two-step RACH can also be used when operating on channels where LBT is not required. For such deployments, performing the LBT procedure before transmission may not be required. Figure 12 In step 281, UE 201 transmits MsgA, which may include a signal similar to a preamble and a payload, the payload including information that can be equivalent to the information transmitted in Msg3 of the four-step RACH procedure. Examples include CCCH SDU and UE identity. MsgA can also be used for UL data transmission; for example, UL DCCH or UL DTCH SDU.

[0140] exist Figure 12In step 282, UE 201 monitors and obtains MsgB transmitted by gNB 202, and may include information equivalent to the information transmitted in Msg2 and Msg4 of the four-step RACH procedure; such as TA command, UL authorization, TC-RNTI, UE contention resolution identity, CCCH SDU. MsgB can also be used for DL ​​data transmission; such as DL DCCH or DL ​​DTCH SDU. In scenarios where UE 201 does not receive MsgB, UE 201 can retransmit MsgA, where the number of retransmissions can be configured by the network. Alternatively, when performing MsgA retransmission, UE 201 can use the same preamble-like signal. Alternatively, a different preamble-like signal can be selected for each MsgA retransmission. This behavior can be defined according to network configuration standards.

[0141] MAC PDU (MsgA): A MsgA MAC PDU may include one or more MAC sub-PDUs, each of which may include the following: 1) MAC subheader only (including padding); 2) MAC subheader and MAC SDU; 3) MAC subheader and MAC CE; or 4) MAC subheader and padding. The size of the MAC SDU included in a MsgA MAC PDU may be fixed or variable. Figure 13 and Figure 14 As shown, the MAC sub-header, excluding the fixed-size MAC CE, padding, and MAC SDU including UL CCCH, consists of four header fields: R / F / LCID / L. For example... Figure 15 As shown, the MAC subheader for a fixed-size MAC CE, padding, and MAC SDU including ULCCCH consists of two header fields, R / LCID.

[0142] The MsgA MAC subheader is byte-aligned and may include the following fields: 1) LCID, L, F, or R. The Logical Channel ID (LCID) field identifies the logical channel instance of the corresponding MAC SDU or the type of the corresponding MAC CE or padding, as described in Tables 6.2.1-1 and 6.2.1-2 of TS 38.321. Each MAC subheader has only one LCID field. The LCID field is 6 bits in size. The Length (L) field indicates the length (in bytes) of the corresponding MAC SDU or variable-size MAC CE. Each MAC subheader has only one L field, except for subheaders corresponding to fixed-size MAC CEs, padding, and MAC SDUs including UL CCCHs. The size of the L field is indicated by the F field. The Format (F) field indicates the size of the Length field. Each MAC subheader has only one F field, except for subheaders corresponding to fixed-size MAC CEs, padding, and MAC SDUs including UL CCCHs. The F field is 1 bit in size. A value of 0 indicates 8 bits for the Length field. A value of 1 indicates 16 bits for the Length field. Reserve the (R) bit and set it to zero.

[0143] One or more MsgA MAC sub-PDUs having one or more MAC CEs are placed after all (one or more) MAC sub-PDUs having MAC SDUs and before MAC sub-PDUs with padding in the MAC PDU, as shown. Figure 16 As depicted in [the text]. The fill size can be zero.

[0144] A MAC PDU used to signal MsgB RAR can consist of one or more sub-PDUs and optional padding. Each MAC sub-PDU may include the following: 1) a MAC sub-header with only a backoff indicator; 2) a MAC sub-header with only RAPID (e.g., acknowledgment of an SI request); or 3) a MAC sub-header with both RAPID and Msg3 RAR.

[0145] A MAC subheader with a backoff indicator consists of five header fields: E / T / R / R / BI, as in TS 38.321. Figure 6 As described in .1.5-1. If included, then only the MAC sub-PDU with the backoff indicator should be placed at the beginning of the MAC PDU. "MAC sub-PDU with only RAPID (one or more)" and "MAC sub-PDU with RAPID and Msg3RAR (one or more)" can be placed between the MAC sub-PDU with only the backoff indicator and padding (if any). The MAC sub-header with RAPID consists of three header fields: E / T / RAPID, as described in TS 38.321. Figure 6As described in .1.5-2.

[0146] If present, padding is placed at the end of the MAC PDU. The presence and length of padding are implied based on the TB size and the size of (one or more) MAC sub-PDUs.

[0147] The following is a public MAC PDU (MsgB). Figure 17 The document describes an exemplary MsgB RAR with an octet alignment and may include the following fields: 1) A / N, 2) Timing Advance Command, 3) UL Authorization, 4) Temporary C-RNTI, 5) UE Contention Resolution Identity, or 6) Data. The A / N field is a flag indicating whether the MsgA payload was successfully decoded. For example, a value "0" can be used to indicate that the payload was successfully decoded, while a value "1" can be used to indicate that the payload was not successfully decoded. The Timing Advance Command field indicates the index value TA of the timing adjustment amount that must be applied by the MAC entity in TS 38.213. The Timing Advance Command field is 12 bits in size. The Uplink Authorization field indicates the resources to be used on the uplink in TS 38.213. The UL Authorization field is 27 bits in size. The Temporary C-RNTI field indicates the temporary identity used by the MAC entity during random access. The Temporary C-RNTI field is 16 bits in size. The UE Contention Resolution Identity field includes the UL CCCH SDU. If the UL CCCH SDU is longer than 48 bits, then this field may include the first 48 bits of the UL CCCH SDU. The data field is used for the transmission of control plane signaling (e.g., RRC messages) and / or user plane data. In this example, the data field is defined as a fixed size of 32 bits. The use of different fixed sizes is not excluded. Alternatively, the data field may have a variable length, where the length is indicated via a length field included in the MACRAR.

[0148] MsgB RAR can also include a QCL field, which indicates the QCL relationship of the DMRS of the first PDCCH. In some scenarios, such as when performing a contention-free two-step RACH procedure or when there is no DL data to be transmitted, it may not be necessary to use this field. Figure 17 The MsgB RAR describes all fields. In such a scenario, unused fields can be considered reserved. Alternatively, the MsgB RAR may include a format field F to indicate whether optional fields exist. And in another alternative, the format field may be included in the MAC subheader.

[0149] Table 7 defines an exemplary 2-digit format field that can be used to indicate whether there is a UE contention to resolve the identity and data fields. Alternative format field definitions are not excluded.

[0150] Table 7: Example Format Fields

[0151] Format UE contention resolution identity field Data field 00 Absent Absent 01 Present Absent 10 Absent Present 11 Present Present

[0152] Figure 18 An exemplary MAC PDU consisting of MsgB RAR is shown. In another alternative, the MAC PDU may consist of Msg2 and MsgB RAR. The format field F may be included in the subheader or RAR to indicate the RAR format. In one embodiment, the gNB may use format "00" as defined in Table 1 for a UE performing a two-step RACH procedure, while any defined format may be used for a UE performing a two-step RACH procedure; for example, format "10" is used for events such as UL / DL data arrival, and format "11" is used for events such as initial access.

[0153] The MAC procedure for two-step RACH is disclosed below. Table 8 shows example pseudocode for the MAC procedure used for MsgA transmission. In this example, the same UE variables (such as those defined in Section 5.1.1 of TS 38.321 and used to control the four-step RACH procedure) can also be used to control the two-step RACH procedure. However, the use of UE variables and configuration parameters specific to the two-step RACH procedure is not excluded.

[0154] Table 8

[0155]

[0156]

[0157] The RA-RNTI associated with the PRACH in which the random access preamble is transmitted can be calculated as follows:

[0158] RA-RNTI=1+s_id+14×t_id+14×80×f_id+14×80×8×ul_carrier_id

[0159] Where s_id is the index of the first OFDM symbol of the specified PRACH (0≤s_id<14), t_id is the index of the first slot of the specified PRACH in the system frame (0≤t_id<80), f_id is the index of the specified PRACH in the frequency domain (0≤f_id<8), and ul_carrier_id is the UL carrier used for Msg1 transmission (0 for NUL carrier and 1 for SUL carrier).

[0160] Table 9 shows example pseudocode for the MAC procedure used for MsgB reception. In this example, the same UE variables used to control the four-step RACH procedure are also used to control the two-step RACH procedure. However, the use of UE variables and configuration parameters specific to the two-step RACH procedure is not excluded.

[0161] Table 9

[0162]

[0163]

[0164]

[0165]

[0166] The MAC entity can stop the ra-ResponseWindow (and thus monitor one or more random access responses) after successfully receiving a random access response that includes a random access preamble identifier matching the transmitted PREAMBLE_INDEX. HARQ operation may not be applicable to random access response transmissions.

[0167] Fallback to four-step RACH: In scenarios where the two-step RACH process fails, the UE can fall back to the four-step RACH process. This fallback will occur after the configured number of failed attempts. Figure 19 This is an example of a signaling diagram where the UE falls back to a four-step RACH procedure after one failed attempt. Figure 19 Steps 291-296 are disclosed Figure 19 Example description of the steps. At step 291, UE 201 performs LBT. At step 292, MsgA is transmitted to gNB 202. At step 293, LBT fails, therefore MsgB is not transmitted. At step 294, UE 201 monitors the PDCCH identified by RA-RNTI on the DL during the ra-ResponseWindow. At step 295, the ra-ResponseWindow expires. At step 296, UE 201 begins the four-step RACH procedure, performs LBT, transmits the random access preamble as described in TS 38.321, and performs other mechanisms as described below. UE 201 performs random access response reception as described in TS 38.321. UE 201 uses resources allocated via RAR grant scheduling as described in TS 38.321 to perform LBT and transmit the MsgA payload. UE 201 performs contention resolution as described in TS 38.321.

[0168] In scenarios where the gNB 202 can detect the transmission of MsgA (e.g., detect a signal similar to a preamble) but cannot successfully decode the payload, the gNB 202 can provide an indication via MsgB. This indication can be used to trigger a fallback to the four-step RACH process, such as... Figure 20 As shown in the diagram. This can help reduce the latency of completing the RACH process, because UE 201 can start the fallback immediately without having to wait for the ra-ResponseWindow to expire.

[0169] GNB 202 can indicate this condition to UE 201 via the A / N field of the MAC RAR proposed for MsgB as described herein, or by including a MAC subheader with only RAPID in the MAC PDU, where RAPID corresponds to a preamble-like signal included in the MsgA transmission. Upon receiving this indication, the MAC entity can initiate the four-step RACH procedure immediately or after a configured backoff time. Figure 20 Steps 301-306 disclose Figure 20 Example description of the steps. At step 301, UE 201 performs LBT. At step 302, UE 201 transmits MsgA to gNB 202. At step 303, GNB 202 detects the MsgA preamble but cannot decode the MsgA payload. At step 304, UE 201 monitors the PDCCH identified by RA-RNTI on the DL during the ra-ResponseWindow. At step 305, UE 201 obtains MsgB indicating that the MsgA payload was not successfully decoded. GNB 202 can indicate this condition to UE 201 via the A / N field of the MACRAR proposed for MsgB as described herein or by including a MAC subheader with only RAPID in the MAC PDU, where RAPID corresponds to a preamble-like signal included in the MsgA transmission. At step 306, based on the message obtained in step 305, the UE determines the four-step RACH to be performed. At step 307, UE 201 begins the four-step RACH procedure, performs LBT, transmits the random access preamble as described in TS 38.321, and performs other mechanisms as described below. UE 201 may perform random access response reception as described in TS 38.321. UE 201 may use resources allocated via RAR grant scheduling as described in TS 38.321 to perform LBT and transmit the MsgA payload. UE 201 performs contention resolution as described in TS 38.321.

[0170] In another example, upon receiving an indication that gNB 202 could not successfully decode the payload, UE 201 can immediately (e.g.,Figure 21 Alternatively, step 3 of the four-step RACH process can begin after the configured backoff time. UL authorization signaled via RAR can be used for Msg3 transmission. This alternative can further reduce latency by skipping Msg1 and Msg2 of the four-step RACH process. The following disclosure... Figure 21 Example description of the steps. At step 311, UE 201 performs LBT. At step 312, UE 201 transmits MsgA to gNB 202. After transmitting MsgA, the UE begins monitoring the PDCCH identified by RA-RNTI on the DL during the ra-ResponseWindow. At step 313, GNB 202 detects the MsgA preamble but cannot decode the MsgA payload. At step 313, UE 201 monitors the PDCCH identified by RA-RNTI on the DL during the ra-ResponseWindow. At step 314, UE 201 obtains MsgB, including a MAC RAR for MsgB, as described herein, where the A / N field of the RAR is set to "NACK". At step 315, UE 201 uses resources authorized and scheduled via RAR to perform LBT and transmit a payload similar to MsgA. In this step, the UE does not transmit MsgA. It is transmitting Msg3, in which the data signaled via Msg3 corresponds to the MsgA payload. RAR grants scheduling for Msg3 transmission. The MsgA payload is signaled via Msg3 transmission. UE 201 monitors the PDCCH on the DL identified by the TC-RNTI signaled via MsgB, receives Msg4, and performs contention resolution as described in TS 38.321.

[0171] Fallback to scheduled transmissions during handover: For schemes using two-step RACH during handover, if the two-step RACH fails, a fallback to scheduled transmissions can be used to complete the handover process, such as... Figure 22 As shown below. Figure 22 Example description of the steps (e.g., Figure 22Steps 321-324). At step 321, the source gNB provides RRC configuration to UE 201 in a handover command; for example, an RRCReconfiguration message. The handover command message may include the cell ID and information required to access the target cell, allowing UE 201 to access the target cell without reading system information. In some cases, information required for contention-based and contention-free random access may be included in the handover command message. Access information for the target cell may include beam-specific information (if any). At step 322, UE 201 transmits an RRCReconfigurationComplete message via MsgA. At step 323, GNB 202 detects the MsgA preamble but cannot decode the MsgA payload; for example, an RRCReconfigurationComplete message. At step 324, UE 201 monitors the PDCCH on the DL identified by RA-RNTI or C-RNTI during the ra-ResponseWindow. At step 325, UE 201 obtains MsgB, including the MAC RAR for MsgB, as described herein, wherein the A / N field of the RAR is set to “NACK”. At step 326, UE 201 performs LBT and transmits the MsgA payload, such as the RRCReconfigurationComplete message, using resources authorized and scheduled via the RAR.

[0172] The following discloses techniques associated with Problem Statement 2 (e.g., the second problem), wherein UE 201 can perform LBT prioritization to support random access prioritization procedures. UE 201 can perform LBT prioritization to support random access prioritization procedures, such as in the case of handover using contention-based access or in the case of beam failure recovery (BFR) procedures. In the case of UL data arriving when UL is "unsynchronized" or PUCCH resources are absent, the logical channel that triggers the scheduling request can be used to determine LBT prioritization.

[0173] To support LBT prioritization, UE 201 can be configured with different values ​​for LBT parameters, such as channel access priority class or energy detection threshold. The corresponding parameters for channel access priority class may include: 1) minimum contention window; 2) maximum contention window; 3) maximum occupancy time; 4) allowed contention window size; or 5) the number of consecutive time periods (e.g., time slots) for carrier sensing.

[0174] UE 201 can perform LBTs with the same priority during the random access procedure. Alternatively, the first LBT can be performed with the highest priority, and subsequent LBTs can be performed with the highest priority to minimize disruption caused by LBTs during the RACH procedure.

[0175] Figure 23 This is an exemplary diagram of signaling that can be used when performing prioritized random access with an NR-U serving cell. At step 330, a random access procedure can be initiated at UE 201, and UE 201 performs random access resource selection. At step 331, MAC entity 204 provides PHY 205 with a set of configuration parameters to configure preamble transmission, the set of configuration parameters including a set of LBT parameters for providing prioritized random access. At step 332, PHY 205 performs LBT, and if the channel is “idle,” then the preamble (Msg1) is transmitted at step 333. If the preamble is transmitted in step 333, then UE 201 monitors the RAR on the PDCCH at step 334. At step 335, if a contention-based random access procedure is being performed, then MAC 204 provides PHY 205 with the UL data and control parameters required for Msg3 transmission at step 336. The Msg3 transmission at step 336 can be performed with the same priority as Msg1. Alternatively, Msg3 transmission can be performed with the highest priority to ensure that interruptions caused by LBT are minimized. At step 334, if Msg3 was transmitted in step 333, then UE 201 monitors Msg4 on the PDCCH.

[0176] Table 10 provides translations of some of the abbreviations published in this paper.

[0177] Table 10 - Abbreviations and Definitions

[0178]

[0179]

[0180]

[0181]

[0182] It should be understood that performing the steps shown in this article (such as...) Figure 5 and Figures 10-23 The entities can be logical entities (e.g., MAC 204 and PHY 205). These steps can be stored on devices, servers, or computer systems (such as...). Figure 25C or Figure 25DThe methods disclosed herein (e.g., those shown) reside in their memory and are executed on their processors. Figures 5-7 and Figures 10-23 You can skip steps, combine steps, or add steps between them.

[0183] Figure 24 The illustration shows an exemplary display (e.g., a graphical user interface) that can be generated based on methods and systems associated with random access to an NR-U cell as discussed herein. Display interface 901 (e.g., a touchscreen display) may provide text associated with random access to an NR-U cell in block 902, such as parameters related to handover using subband LBT and BWP, method flow, and the serving cell with associated current conditions. Progress of any step discussed herein (e.g., messages sent or success of a step) may be displayed in block 902. Furthermore, graphical output 902 may be displayed on display interface 901.

[0184] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities—including work on codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced, and New Radio (NR), also known as “5G.” The development of 3GPP NR standards is expected to continue and include definitions for next-generation radio access technologies (new RATs), including new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to include new, non-backward-compatible radio access in new spectrum below 6 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with varying requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access for applications such as indoor spaces and hotspots. In particular, Ultra Mobile Broadband is expected to share a common design framework with flexible radio access below 7 GHz, featuring design optimizations specific to cmWave and mmWave.

[0185] 3GPP has identified a variety of use cases expected to be supported by NR, resulting in diverse user experience requirements regarding data rates, latency, and mobility. Use cases include the following general categories: Enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), Massive Machine-Type Communications (mMTC), Network Operations (e.g., network slicing, routing, migration and interworking, energy saving), and Enhanced Vehicle-to-All (eV2X) Communications (which can include Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I), Vehicle-to-Network (V2N), Vehicle-to-Pedestrian (V2P), and vehicle-to-other-entities communication). Specific services and applications within these categories include, for example, monitoring sensor networks, remote device control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first-aid connectivity, car emergency calls, disaster alerts, real-time gaming, multi-person video calling, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones, among others. This document anticipates all of these and other use cases.

[0186] Figure 25A The illustration shows an example communication system 100 in which the methods and apparatus for random access to NR-U cells described and claimed herein (such as...) can be used. Figures 5-7 and Figures 10-23 (The systems and methods shown). Communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, or 102g (generally or collectively referred to as WTRU 102 or WTRU 102). Communication system 100 may include radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. Network services 113 may include, for example, V2X servers, V2X functions, ProSe servers, ProSe functions, IoT services, video streaming, or edge computing.

[0187] It will be appreciated that the concepts disclosed herein can be used with any number of WTRUs, base stations, networks, or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, or 102g can be any type of apparatus or device configured to operate or communicate in a wireless environment. Although it is possible to Figure 25A , Figure 25B , Figure 25C , Figure 25D , Figure 25E or Figure 25FEach WTRU 102a, 102b, 102c, 102d, 102e, 102f, or 102g is described as a handheld wireless communication device. However, it should be understood that for the various use cases anticipated for 5G wireless communication, each WTRU may include or be implemented in any type of device or apparatus configured to transmit or receive wireless signals. As an example only, such devices or apparatus include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, tablets, netbooks, notebook computers, personal computers, wireless sensors, consumer electronics, wearable devices (such as smartwatches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, and vehicles (such as cars, buses, trucks, trains, or airplanes).

[0188] The communication system 100 may also include base station 114a and base station 114b. Figure 25A In the example, each base station 114a and 114b is depicted as a single element. In practice, base stations 114a and 114b may include any number of interconnected base station or network elements. Base station 114a may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks (e.g., core networks 106 / 107 / 109, Internet 110, network service 113, or other network 112). Similarly, base station 114b may be any type of device configured to wired or wirelessly interface with at least one of Remote Radio Headers (RRHs) 118a and 118b, Transmit and Receive Points (TRPs) 119a and 119b, or Roadside Units (RSUs) 120a and 120b to facilitate access to one or more communication networks (such as core networks 106 / 107 / 109, Internet 110, other network 112, or network service 113). RRH 118a, 118b can be any type of device configured to wirelessly interface with at least one of WTRU 102 (e.g., WTRU 102c) to facilitate access to one or more communication networks (such as core networks 106 / 107 / 109, Internet 110, network services 113, or other networks 112).

[0189] TRPs 119a and 119b can be any type of device configured to interface wirelessly with at least one of the WTRUs 102d to facilitate access to one or more communication networks (such as core networks 106 / 107 / 109, Internet 110, network services 113, or other networks 112). RSUs 120a and 120b can be any type of device configured to interface wirelessly with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks (such as core networks 106 / 107 / 109, Internet 110, network services 113, or other networks 112). For example, base stations 114a and 114b can be base transceiver stations (BTS), node Bs, eNode Bs, home node Bs, home eNode Bs, next-generation node Bs (gNodeBs), satellites, site controllers, access points (APs), wireless routers, etc.

[0190] Base station 114a may be part of RAN 103 / 104 / 105, and may also include other base stations or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Similarly, base station 114b may be part of RAN 103b / 104b / 105b, and may also include other base stations or network elements (not shown), such as BSCs, RNCs, relay nodes, etc. Base station 114a may be configured to transmit or receive radio signals within a specific geographical area, which may be referred to as a cell (not shown). Similarly, base station 114b may be configured to transmit or receive wired or radio signals within a specific geographical area, which may be referred to as a cell (not shown) for random access methods, systems, and devices for NR-U cells, as disclosed herein. Similarly, base station 114b may be configured to transmit or receive wired or radio signals within a specific geographical area, which may be referred to as a cell (not shown). Cells may be further subdivided into cell sectors. For example, the cell associated with base station 114a can be divided into three sectors. Therefore, in this example, base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In this example, base station 114a may employ multiple-input multiple-output (MIMO) technology, and therefore can utilize multiple transceivers for each sector of the cell.

[0191] Base station 114a can communicate with one or more of WTRUs 102a, 102b, 102c, or 102g via air interfaces 115 / 116 / 117, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Any suitable radio access technology (RAT) can be used to establish air interfaces 115 / 116 / 117.

[0192] Base station 114b can communicate with one or more of RRH 118a, 118b, TRP 119a, 119b, or RSU 120a, 120b via wired or air interfaces 115b / 116b / 117b. Air interfaces 115b / 116b / 117b can be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Any suitable radio access technology (RAT) can be used to establish air interfaces 115b / 116b / 117b.

[0193] RRH 118a, 118b, TRP 119a, 119b, or RSU 120a, 120b can communicate with one or more of WTRU 102c, 102d, 102e, 102f via air interface 115c / 116c / 117c. Air interface 115c / 116c / 117c can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 115c / 116c / 117c.

[0194] WTRUs 102a, 102b, 102c, 102d, 102e, or 102f can communicate with each other via air interfaces 115d / 116d / 117d, such as sidelink communication. Air interfaces 115d / 116d / 117d can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Any suitable radio access technology (RAT) can be used to establish air interfaces 115d / 116d / 117d.

[0195] Communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c, or RRH 118a, 118b, TRP 119a, 119b and RSU 120a, 120b in RAN 103b / 104b / 105b and WTRU 102c, 102d, 102e, 102f, can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c respectively. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) or evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink Packet Access (HSDPA) or High-Speed ​​Uplink Packet Access (HSUPA).

[0196] In the example, base station 114a can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA) with WTRUs 102a, 102b, 102c, or RRH118a, 118b, TRP 119a, 119b in RANs 103b / 104b / 105b, or RSU 120a, 120b with WTRUs 102c, 102d. These technologies can establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c using Long Term Evolution (LTE) or LTE-Advance (LTE-A), respectively. In the future, air interfaces 115 / 116 / 117 or 115c / 116c / 117c can implement 3GPP NR technology. LTE and LTE-A technologies can include LTE D2D and V2X technologies and interfaces (such as sidelink communication). Similarly, 3GPP NR technology includes NR V2X technology and interfaces (such as sidelink communication).

[0197] Base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c and 102g, or RRH 118a, 118b, TRP 119a, 119b, or RSU 120a, 120b and WTRU 102c, 102d, 102e, 102f in RAN 103b / 104b / 105b, can implement radio technologies such as IEEE 802.16 (e.g., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), and GSM. EDGE (GERAN) etc.

[0198] For example, Figure 25A Base station 114c can be a wireless router, home node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a localized area (such as a business premises, house, vehicle, train, antenna, satellite, factory, campus, etc.) for implementing methods, systems, and devices for random access to NR-U cells, as disclosed herein. In the example, base station 114c and WTRU 102 (e.g., WTRU 102e) can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, base station 114c and WTRU 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another example, base station 114c and WTRU 102 (e.g., WTRU 102e) can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or femtocell. Figure 25A As shown, base station 114c may have a direct connection to Internet 110. Therefore, it may not be required for base station 114c to access Internet 110 via core network 106 / 107 / 109.

[0199] RAN 103 / 104 / 105 or RAN 103b / 104b / 105b can communicate with core networks 106 / 107 / 109, which can be any type of network configured to provide voice, data, messaging, authorization and authentication, application, or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. For example, core networks 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., or perform advanced security functions such as user authentication.

[0200] Although not in Figure 25A As shown, but it should be recognized that RAN 103 / 104 / 105 or RAN 103b / 104b / 105b or core network 106 / 107 / 109 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 103 / 104 / 105 or RAN 103b / 104b / 105b. For example, in addition to being connected to RAN 103 / 104 / 105 or RAN 103b / 104b / 105b that can utilize E-UTRA radio technology, core network 106 / 107 / 109 can also communicate with another RAN (not shown) that uses GSM or NR radio technology.

[0201] Core networks 106 / 107 / 109 can also serve as gateways for WTRUs 102a, 102b, 102c, 102d, and 102e to access PSTN 108, the Internet 110, or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired or wireless communication networks owned or operated by other service providers. For example, network 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may use the same RAT as or a different RAT than RAN 103 / 104 / 105 or RAN 103b / 104b / 105b.

[0202] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multi-mode capabilities. For example, WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks via different radio links to implement methods, systems, and apparatus for random access to NR-U cells, as disclosed herein. For example, Figure 25A The WTRU 102g shown can be configured to communicate with a base station 114a that can employ cellular-based radio technology and with a base station 114c that can employ IEEE 802 radio technology.

[0203] Although Figure 25A Although not shown, it will be understood that user equipment can establish a wired connection to a gateway. The gateway may be a residential gateway (RG). The RG can provide connectivity to the core network 106 / 107 / 109. It will be appreciated that many of the ideas contained herein can be equivalently applied to UEs with WTRUs and UEs using wired connections to connect to the network. For example, ideas applicable to radio interfaces 115, 116, 117, and 115c / 116c / 117c can be equivalently applied to wired connections.

[0204] Figure 25B This is a system diagram of example RAN 103 and core network 106, which can implement the methods, systems, and devices for random access to NR-U cells as disclosed herein. As mentioned above, RAN 103 can use UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 115. RAN 103 can also communicate with core network 106. Figure 25B As shown, RAN 103 may include Node Bs 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 115. Node Bs 140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNCs 142a and 142b. It will be appreciated that RAN 103 may include any number of Node Bs and Radio Network Controllers (RNCs).

[0205] like Figure 25BAs shown, nodes B 140a and 140b can communicate with RNC 142a. Additionally, node B 140c can communicate with RNC 142b. Nodes B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each of RNCs 142a and 142b can be configured to control the corresponding nodes B 140a, 140b, and 140c to which it is connected. Furthermore, each of RNCs 142a and 142b can be configured to perform or support other functions, such as outer-loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0206] Figure 25B The core network 106 shown may include a Media Gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, or a Gateway GPRS Support Node (GGSN) 150. While each of the foregoing elements is depicted as part of the core network 106, it will be appreciated that any of these elements may be owned or operated by an entity other than the core network operator.

[0207] RNC 142a in RAN 103 can be connected to MSC 146 in core network 106 via IuCS interface. MSC 146 can be connected to MGW 144. MSC 146 and MGW 144 can provide WTRU 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRU 102a, 102b, and 102c and legacy terrestrial line communication equipment.

[0208] RNC 142a in RAN 103 can also be connected to SGSN 148 in core network 106 via IuPS interface. SGSN 148 can be connected to GGSN 150. SGSN 148 and GGSN 150 can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

[0209] The core network 106 can also be connected to other networks 112, which may include other wired or wireless networks owned or operated by other service providers.

[0210] Figure 25CThis is a system diagram of an example RAN 104 and core network 107 that can implement the methods, systems, and devices for random access to NR-U cells as disclosed herein. As described above, RAN 104 can employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with core network 107.

[0211] RAN 104 may include eNode-B 160a, 160b, and 160c, although it will be appreciated that RAN 104 may include any number of eNode-Bs. eNode-B 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRU 102a, 102b, and 102c via air interface 116. For example, eNode-B 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a.

[0212] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink or downlink, etc. Figure 25C As shown, eNode-B 160a, 160b and 160c can communicate with each other via the X2 interface.

[0213] Figure 25C The core network 107 shown may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements is depicted as part of the core network 107, it should be understood that any of these elements may be owned or operated by an entity other than the core network operator.

[0214] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can also provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0215] Serving Gateway 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. Serving Gateway 164 can generally route and forward user data packets to and from WTRUs 102a, 102b, and 102c. Serving Gateway 164 can also perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when downlink data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0216] Service gateway 164 can also be connected to PDN gateway 166, which can provide WTRUs 102a, 102b, and 102c with access to a packet-switched network (e.g., Internet 110) to facilitate communication between WTRUs 102a, 102b, 102c and IP-enabled devices.

[0217] Core network 107 can facilitate communication with other networks. For example, core network 107 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, core network 107 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between core network 107 and PSTN 108, or can communicate with it. Furthermore, core network 107 can provide WTRUs 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned or operated by other service providers.

[0218] Figure 25D This is a system diagram of example RAN 105 and core network 109, which can implement the methods, systems, and devices for random access in NR-U cells as disclosed herein. RAN 105 can use NR radio technology to communicate with WTRUs 102a and 102b via air interface 117. RAN 105 can also communicate with core network 109. Non-3GPP Interoperability Function (N3IWF) 199 can use non-3GPP radio technology to communicate with WTRU 102c via air interface 198. N3IWF 199 can also communicate with core network 109.

[0219] RAN 105 may include gNode-B 180a and 180b. It will be appreciated that RAN 105 may include any number of gNode-Bs. gNode-B 180a and 180b may each include one or more transceivers for communicating with WTRU 102a and 102b via air interface 117. When using integrated access and backhaul connections, the same air interface can be used between the WTRU and the gNode-B, which may be via the core network 109 of one or more gNBs. gNode-B 180a and 180b may implement MIMO, MU-MIMO, or digital beamforming technologies. Thus, for example, gNode-B 180a may use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a. It should be appreciated that RAN 105 may employ other types of base stations, such as eNode-Bs. It should also be appreciated that RAN 105 may employ more than one type of base station. For example, RAN can use eNode-B and gNode-B.

[0220] The N3IWF 199 may include a non-3GPP access point 180c. It will be appreciated that the N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with the WTRU 102c via air interface 198. The non-3GPP access point 180c may use the 802.11 protocol to communicate with the WTRU 102c via air interface 198.

[0221] Each of the gNode-B 180a and 180b can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink or downlink, etc. Figure 25D As shown, for example, gNode-B180a and 180b can communicate with each other via the Xn interface.

[0222] Figure 25D The core network 109 shown may be a 5G core network (5GC). The core network 109 can provide various communication services to customers interconnected via a radio access network. The core network 109 includes multiple entities that perform the functions of the core network. As used herein, the terms "core network entity" or "network function" refer to any entity that performs one or more functions of the core network. It should be understood that such a core network entity may be stored in a device or computer system (such as...) configured for wireless or network communication. Figure 25G The system 90 shown is a logical entity implemented in the form of computer-executable instructions (software) that are stored in the memory of the system and executed on its processor.

[0223] exist Figure 25D In the example, the 5G core network 109 may include Access and Mobility Management Functions (AMF) 172, Session Management Functions (SMF) 174, User Plane Functions (UPF) 176a and 176b, User Data Management Functions (UDM) 197, Authentication Server Functions (AUSF) 190, Network Exposure Functions (NEF) 196, Policy Control Functions (PCF) 184, Non-3GPP Interoperability Functions (N3IWF) 199, and User Data Repository (UDR) 178. While each of the foregoing elements is depicted as part of the 5G core network 109, it should be recognized that any of these elements may be owned or operated by an entity other than the core network operator. It will also be recognized that the 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these elements. Figure 25D The network functions are shown to be directly interconnected; however, it should be recognized that they can communicate via routing proxies such as diameter routing proxies or message buses.

[0224] exist Figure 25D In the example, connectivity between network functions is achieved through a set of interfaces or reference points. It will be recognized that a network function can be modeled, described, or implemented as a collection of services invoked or called by other network functions or services. Invocation of network function services can be achieved through direct connections between network functions, exchange of messages on a message bus, invocation of software functions, etc.

[0225] The AMF 172 can connect to RAN 105 via the N2 interface and can be used as a control node. For example, the AMF 172 can be responsible for registration management, connection management, reachability management, access authentication, and access authorization. The AMF can forward user plane tunnel configuration information to RAN 105 via the N2 interface. The AMF 172 can receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 can typically route and forward NAS packets to / from WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not used in... Figure 25D As shown in the image.

[0226] SMF 174 can connect to AMF 172 via interface N11. Similarly, SMF 174 can connect to PCF184 via interface N7 and to UPF 176a and 176b via interface N4. SMF 174 can be used as a control node. For example, SMF 174 can be responsible for session management, IP address allocation for WTRU 102a, 102b and 102c, management and configuration of traffic redirection rules in UPF 176a and UPF 176b, and generation of downlink data notifications to AMF 172.

[0227] UPF 176a and UPF 176b can provide WTRU 102a, 102b, and 102c with access to packet data networks (PDNs) (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and other devices. UPF 176a and UPF 176b can also provide WTRU 102a, 102b, and 102c with access to other types of packet data networks. For example, other networks 112 can be Ethernet networks or any type of network that exchanges packet data. UPF 176a and UPF 176b can receive traffic redirection rules from SMF 174 via the N4 interface. UPF 176a and UPF 176b can provide access to packet data networks by connecting the packet data network to the N6 interface or by connecting to each other and connecting to other UPFs via the N9 interface. In addition to providing access to packet data networks, UPF 176 can also be responsible for packet routing and forwarding, policy and rule enforcement, quality of service handling of user plane traffic, and downlink packet buffering.

[0228] The AMF 172 can also connect to the N3IWF 199, for example, via the N2 interface. The N3IWF facilitates the connection between the WTRU 102c and the 5G core network 170, for example, via a 3GPP-undefined radio interface technology. The AMF can interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

[0229] The PCF 184 can be connected to the SMF 174 via the N7 interface, to the AMF 172 via the N15 interface, and to the Application Function (AF) 188 via the N5 interface. The N15 and N5 interfaces are not... Figure 25DAs shown in the diagram, PCF 184 can provide policy rules to control plane nodes such as AMF 172 and SMF 174, thereby allowing control plane nodes to enforce these rules. PCF 184 can send policies for WTRUs 102a, 102b, and 102c to AMF 172, enabling AMF to deliver the policies to WTRUs 102a, 102b, and 102c via the N1 interface. The policies can then be enforced or applied at WTRUs 102a, 102b, and 102c.

[0230] UDR 178 can act as a repository for authentication credentials and subscription information. The UDR can connect to network functions, allowing them to add to, read from, and modify data within the repository. For example, UDR 178 can connect to PCF 184 via interface N36. Similarly, UDR 178 can connect to NEF 196 via interface N37, and UDR 178 can connect to UDM 197 via interface N35.

[0231] The UDM 197 can be used as an interface between the UDR 178 and other network functions. The UDM 197 can authorize network functions to access the UDR 178. For example, the UDM 197 can connect to the AMF 172 via interface N8, and to the SMF 174 via interface N10. Similarly, the UDM 197 can connect to the AUSF 190 via interface N13. The UDR 178 and UDM 197 can be tightly integrated.

[0232] The AUSF 190 performs authentication-related operations and is connected to the UDM 178 via the N13 interface and to the AMF 172 via the N12 interface.

[0233] NEF 196 exposes the capabilities and services of the 5G core network 109 to Application Function (AF) 188. Exposure can occur on the N33 API interface. NEF can connect to AF 188 via the N33 interface and it can connect to other network functions to expose the capabilities and services of the 5G core network 109.

[0234] Application function 188 can interact with network functions in the 5G core network 109. The interaction between application function 188 and network functions can occur via a direct interface or via NEF 196. Application function 188 can be considered part of the 5G core network 109, or it can be deployed outside the 5G core network 109 by an enterprise with business relationships with the mobile network operator.

[0235] Network slicing is a mechanism that mobile network operators can use to support one or more “virtual” core networks behind the operator’s air interface. This involves “slicing” the core network into one or more virtual networks to support different RANs or different service types operating across a single RAN. Network slicing enables operators to create networks that are tailored to provide optimized solutions for different market scenarios with varying requirements, such as functionality, performance, and isolation.

[0236] 3GPP has designed the 5G core network to support network slicing. Network slicing is a valuable tool for network operators to support a wide range of 5G use cases, such as massive IoT, critical communications, V2X, and enhanced mobile broadband, which have highly diverse and sometimes extreme requirements. Without network slicing, the network architecture may not be flexible and scalable enough to efficiently support a broad range of use case requirements when each use case has its own specific set of performance, scalability, and availability needs. Furthermore, the introduction of new network services should be made more efficient.

[0237] Refer again Figure 25D In a network slicing scenario, WTRU 102a, 102b, or 102c can connect to AMF 172 via the N1 interface. AMF can logically be part of one or more slices. AMF can coordinate connections or communication between WTRU 102a, 102b, or 102c and one or more UPF 176a and 176b, SMF 174, and other network functions. Each of UPF 176a and 176b, SMF 174, and other network functions can be part of the same slice or different slices. When they are part of different slices, they can be isolated from each other in terms of potentially utilizing different computing resources, security credentials, etc.

[0238] Core network 109 can facilitate communication with other networks. For example, core network 109 may include or communicate with an IP gateway (such as an IP Multimedia Subsystem (IMS) server), which serves as an interface between 5G core network 109 and PSTN 108. For example, core network 109 may include or communicate with a Short Message Service (SMS) service center, facilitating communication via SMS. For example, 5G core network 109 can facilitate the exchange of non-IP data packets between WTRUs 102a, 102b, and 102c and a server or application function 188. Furthermore, core network 170 can provide access to network 112 to WTRUs 102a, 102b, and 102c, which may include other wired or wireless networks owned or operated by other service providers.

[0239] This article describes and Figure 25A , Figure 25C , Figure 25D or Figure 25E The core network entities shown are identified by the names given to those entities in certain existing 3GPP specifications. However, it is understood that those entities and functions may be identified by other names in the future, and some entities or functions may be combined in future 3GPP specifications (including future 3GPP NR specifications). Therefore, the examples provided are only provided by way of illustration. Figure 25A , Figure 25B , Figure 25C , Figure 25D or Figure 25E The specific network entities and functions described and illustrated herein should be understood to be applicable to any similar communication system, whether currently defined or to be defined in the future.

[0240] Figure 25E An example communication system 111 is illustrated, in which the systems, methods, and apparatuses described herein for implementing random access to an NR-U cell are used. Communication system 111 may include radio transmit / receive units (WTRUs) A, B, C, D, E, and F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein can be applied to any number of WTRUs, base station gNBs, V2X networks, or other network elements. One or more, or all, of WTRUs A, B, C, D, E, and F may be outside the coverage area of ​​the access network 131. WTRUs A, B, and C form a V2X group, where WTRU A is the group leader, and WTRUs B and C are group members.

[0241] If WTRUs A, B, C, D, E, and F are within the access network coverage 131, they can communicate with each other via gNB 121 through Uu interface 129. Figure 25E In the example, WTRUs B and F are shown within access network coverage 131. WTRUs A, B, C, D, E, and F can communicate with each other directly via sidelink interfaces such as interfaces 125a, 125b, or 128 (e.g., PC5 or NR PC5) that they are within or outside access network coverage 131. For example, in Figure 25E In the example, WRTU D outside the access network coverage 131 communicates with WTRU F inside the coverage 131.

[0242] WTRUs A, B, C, D, E, and F can communicate with RSUs 123a or 123b via Vehicle-to-Network (V2N) 133 or side link port 125b. WTRUs A, B, C, D, E, and F can communicate with V2X server 124 via Vehicle-to-Infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F can communicate with another UE via Vehicle-to-Person (V2P) interface 128.

[0243] Figure 25F This is a block diagram of an example apparatus or device WTRU 102, which can be configured for wireless communication and operation according to the systems, methods, and apparatuses for implementing random access to NR-U cells described herein, among other things, particularly such as Figure 25A , Figure 25B , Figure 25C , Figure 25D or Figure 25E or Figures 5-7 WTRU 102 (e.g., UE 201). For example... Figure 25F As shown, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It will be appreciated that WTRU 102 may include any sub-combination of the foregoing elements. Furthermore, the nodes that base stations 114a and 114b or base stations 114a and 114b may represent (among others, particularly such as, but not limited to, transceiver stations (BTS), Node B, site controllers, access points (APs), home nodes (B), evolved home nodes (eNodeB), home evolved node B (HeNB), home evolved node B gateways, next-generation node B (gNode-B), and proxy nodes) may include... Figure 25F Some or all of the elements depicted herein may be exemplary implementations of the disclosed systems and methods for random access to NR-U cells described herein.

[0244] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, or any other function that enables WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, and transceiver 120 can be coupled to transmit / receive element 122. Although Figure 25F The processor 118 and transceiver 120 are depicted as separate components, but it should be recognized that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

[0245] The UE's transmit / receive element 122 can be configured to transmit data to the base station (e.g., via air interface 115 / 116 / 117). Figure 25A The base station 114a) transmits or receives signals from it, or transmits or receives signals to or from another UE via air interface 115d / 116d / 117d. For example, the transmit / receive element 122 may be an antenna configured to transmit or receive RF signals. The transmit / receive element 122 may be a transmitter / detector configured to, for example, transmit or receive IR, UV, or visible light signals. The transmit / receive element 122 may be configured to transmit and receive both RF and optical signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit or receive any combination of wireless or wired signals.

[0246] Furthermore, although the transmitting / receiving element 122 is in Figure 25F While depicted as a single element, WTRU 102 may include any number of transmit / receive elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interfaces 115 / 116 / 117.

[0247] Transceiver 120 can be configured to modulate signals transmitted by transmit / receive element 122 and demodulate signals received by transmit / receive element 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA), or via multiple beams to the same RAT at different RRHs, TRPs, RSUs, or nodes.

[0248] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from there. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, or display / touchpad / indicator 128. Furthermore, the processor 118 can access information and store data in any type of suitable memory, such as non-removable memory 130 or removable memory 132. Non-removable memory 130 can include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 can include a subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. The processor 118 can access information and store data in memory that is not physically located on WTRU 102 (such as on a server hosted in the cloud or on an edge computing platform or in a home computer (not shown). Processor 118 can be configured to control the lighting pattern, image, or color on display or indicator 128, or otherwise indicate the random access status and associated components of the NR-U cell, in response to whether the random access settings for the NR-U cell in some examples described herein are successful or unsuccessful. The control lighting pattern, image, or color on display or indicator 128 may reflect the diagrams illustrated or discussed herein (e.g., Figures 5-7 and Figures 10-23 The state of any method, process, or component (etc.). This document discloses messages and procedures related to random access to an NR-U cell. Messages and procedures can be extended to provide an interface / API for users to request resources via input sources (e.g., speaker / microphone 124, keypad 126, or display / touchpad / indicator 128), and among other things, to request, configure, or query information related to random access to an NR-U cell, which can be displayed on display 128.

[0249] The processor 118 can receive power from the power supply 134 and can be configured to distribute or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0250] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 115 / 116 / 117 or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable location determination method.

[0251] The processor 118 can also be coupled to other peripheral devices 138, which may include one or more software or hardware modules that provide additional features, functions, or wired or wireless connectivity. For example, peripheral devices 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), Universal Serial Bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, and Bluetooth. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0252] WTRU 102 may be included in other devices or equipment, such as sensors, consumer electronics, wearable devices (such as smartwatches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, and vehicles (such as cars, trucks, trains, or airplanes). WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces (such as interconnect interfaces that may include one of the peripheral devices 138).

[0253] Figure 25G This is a block diagram of an exemplary computing system 90, in which implementations can be performed. Figure 25A , Figure 25C , Figure 25D and Figure 25E The communication network shown includes one or more devices and random access to NR-U cells, such as those described and claimed herein. Figures 5-7 and Figures 10-23The systems and methods shown may include certain nodes or functional entities in RAN 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, the Internet 110, other networks 112, or network services 113. The computing system 90 may include a computer or server and may be primarily controlled by computer-readable instructions, which may be in software form and stored or accessed whenever, where, or by any means. Such computer-readable instructions may be executed within a processor 91 to enable the computing system 90 to function. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, or any other function that enables the computing system 90 to operate within a communication network. The coprocessor 81 is an optional processor, distinct from the main processor 91, which can perform additional functions or assist the main processor 91. The processor 91 or the coprocessor 81 can acquire, generate, and process data relating to the methods and apparatus disclosed herein for random access to NR-U cells, such as obtaining Msg2.

[0254] During operation, processor 91 fetches, decodes, and executes instructions, and transmits information to and from other resources via the main data transfer path of the computing system, system bus 80. This system bus connects components within the computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and for the operating system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0255] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. This memory includes circuitry that allows for the storage and retrieval of information. ROM 93 generally contains stored data that is not easily modified. Data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 or ROM 93 can be controlled by the memory controller 92. The memory controller 92 provides address translation functionality, which translates virtual addresses into physical addresses during instruction execution. The memory controller 92 also provides memory protection functionality, which isolates processes within the system and separates system processes from user processes. Therefore, a program running in first mode can only access memory mapped by its own process virtual address space; it cannot access memory in another process's virtual address space unless inter-process memory sharing is configured.

[0256] In addition, the computing system 90 may include a peripheral device controller 83, which is responsible for transmitting instructions from the processor 91 to peripheral devices such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

[0257] A display 86, controlled by a display controller 96, is used to display visual output generated by a computing system 90. This visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touchpad. The display controller 96 includes the electronic components required to generate the video signals sent to the display 86.

[0258] Additionally, the computing system 90 may include a communication circuitry, such as a wireless or wired network adapter 97, which can be used to connect the computing system 90 to external communication networks or devices (such as RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102, or...). Figure 25A , Figure 25B , Figure 25C , Figure 25D or Figure 25E Other networks 112) enable the computing system 90 to communicate with other nodes or functional entities in those networks. Alone or in combination with the processor 91, the communication circuitry can be used to perform the transmission and reception steps of certain means, nodes, or functional entities described herein.

[0259] It should be understood that any or all of the apparatuses, systems, methods, and processes described herein may be implemented in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), cause the processor to perform or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer-executable instructions that execute on a processor of an apparatus or computing system configured for wireless or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented using any non-transient (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, Digital Universal Disc (DVD) or other optical disc storage devices, magnetic tape cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other tangible or physical medium that can be used to store desired information and is accessible by a computing system.

[0260] In describing the preferred methods, systems, or apparatuses of the subject matter of this disclosure (with regard to random access in NR-U cells) as illustrated in the figures, specific terminology has been used for clarity. However, the claimed subject matter is not intended to be limited to the specific terminology chosen so far, and it should be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve similar purposes.

[0261] The various techniques described herein can be implemented using hardware, firmware, software, or a combination thereof, where appropriate. Such hardware, firmware, and software can reside in devices located at various nodes of a communication network. Devices can operate individually or in combination with each other to implement the methods described herein. As used herein, the terms “device,” “network device,” “node,” “apparatus,” “network node,” etc., are used interchangeably. Furthermore, unless otherwise provided herein, the use of the word “or” is generally inclusive.

[0262] This written description uses examples to disclose the invention, including the best mode, and also enables any person skilled in the art to practice the invention, including making and using any device or system and performing any combined methods. The patentable scope of the invention is defined by the claims and may include other examples that would occur to a person skilled in the art (e.g., skipping steps, combining steps, or adding steps between the exemplary methods disclosed herein). Such other examples are intended to be included within the scope of the claims if they have structural elements that are not different from the literal language of the claims, or if they include equivalent structural elements that are not substantially different from the literal language of the claims.

[0263] Among other things, the methods, systems, and apparatuses described herein can particularly provide components for performing wireless communication. The methods, systems, computer-readable storage media, or apparatuses have components for: acquiring a message; performing random access resource selection based on the acquired message; providing one or more parameters from the Media Access Control (MAC) layer to the Physical (PHY) layer to configure preamble transmission; and, based on these one or more parameters, performing subband listen-before-speak (LBT) by the Physical layer on a selected bandwidth portion (BWP) associated with these one or more parameters. Components may be present for transmitting the preamble when the channel is indicated to be idle. Components may be present for transmitting the preamble when the channel is indicated to be idle; and transmitting a random access preamble transmission indication to the MAC layer to indicate that the preamble has been transmitted. Components may be present for transmitting the preamble when the channel is indicated to be idle; transmitting a random access preamble transmission indication to the MAC layer to indicate that the preamble has been transmitted; and monitoring the Physical Downlink Control Channel (PDCCH). When the channel is indicated to be busy, components may exist for: providing a random access preamble (RAP) transmission indication from the PHY layer to the MAC layer indicating a failure to transmit the preamble; and, based on the received RAP indication, performing another random access resource selection by the MAC layer using a second-selected BWP. One or more parameters may include multiple sets of LBT parameters. When the channel is indicated to be busy, components may exist for: performing multiple LBT attempts by the PHY layer based on one or more parameters including multiple sets of LBT parameters or multiple indications of subbands. Components may exist for providing prioritized random access by the PHY based on one or more parameters. One or more parameters may include a set of LBT parameters. Components may exist for monitoring the PDCCH on the same subband or BWP on which the preamble is transmitted. A method, system, computer-readable storage medium, or apparatus may provide multiple subbands to the PHY for transmission from the MAC layer; determine that a first subband among the multiple subbands is idle; and transmit the preamble by the PHY on the first subband. Methods, systems, computer-readable storage media, or apparatuses have components for: detecting events (e.g., CG addition, initial access, beam fault recovery, etc., as disclosed herein); performing random access resource selection based on the event; providing one or more parameters from the Media Access Control (MAC) layer to the Physical (PHY) layer to configure preamble transmission; and performing subband listen-before-speak (LBT) by the Physical layer on a selected bandwidth portion (BWP) associated with the one or more parameters. All combinations in this paragraph (including the removal or addition of steps) are contemplated.

Claims

1. A user equipment comprising a circuit system, said circuit system being configured to: The network node receives a configuration including a first threshold relative to a first counter for a four-step random access RA, wherein the first threshold is the configured number of failed attempts, and a fallback to a four-step random access process occurs after the first counter reaches the first threshold. Based on the confirmation that the value of the first counter is not greater than the first threshold, the second counter is incremented and MsgA is sent to the network node as a two-step RA preamble transmission. The second counter is used to calculate the RA target power of the two-step RA preamble transmission. Launch the RA response window to monitor the response to MsgA; During the RA response window, the network node receives a MsgB as a two-step RA preamble transmission of the Random Access Response (RAR), wherein the MsgB includes an indication that the MsgA payload was not successfully decoded and an uplink UL grant for Msg3 transmission, wherein the indication that the MsgA payload was not successfully decoded is provided by the RA preamble ID field in the MAC sub-header; and Based on the detection of the indication, step 3 of the four-step RA is initiated by sending Msg3 to the network node on the UL resource configured in the UL authorization, wherein Msg3 includes the MsgA payload.

2. The user equipment according to claim 1, wherein the first counter is configured to increment upon detection of a Listen Before Talk (LBT) fault indication.

3. The user equipment according to claim 2, wherein the LBT fault indication is provided from the physical PHY layer to the media access control (MAC) layer.

4. The user equipment according to claim 1, wherein the RA response window is configured to stop if the received RA preamble ID matches the PREAMBLE_INDEX sent in the MsgA.

5. A network node including a circuit system, said circuit system being configured to: The configuration is sent to the user equipment including a first threshold relative to a first counter for a four-step random access RA, wherein the first threshold is the configured number of failed attempts, and a four-step random access process occurs after the first counter reaches the first threshold; MsgA is received as a two-step RA preamble transmission to the network node, wherein MsgA is sent after a second counter is incremented based on confirmation that the value of the first counter is not greater than the first threshold, and the second counter is used to calculate the RA target power of the two-step RA preamble transmission. Send MsgB to the User Equipment as a Random Access Response (RAR) for the two-step RA preamble transmission, wherein the MsgB is received by the User Equipment during an RA response window for monitoring responses to the MsgA, wherein the MsgB includes an indication that the MsgA payload was not successfully decoded and an uplink UL grant for Msg3 transmission, wherein the indication that the MsgA payload was not successfully decoded is provided by the RA preamble ID field in the MAC sub-header; and Based on the instruction, Msg3 is received from the user equipment as step 3 of the four-step RA on the UL resources configured in the UL authorization, wherein Msg3 includes the MsgA payload.

6. The network node of claim 5, wherein the first counter is configured to increment upon detection of a Listen Before Talk (LBT) fault indication.

7. The network node of claim 6, wherein the LBT fault indication is provided from the physical PHY layer to the media access control (MAC) layer.

8. The network node of claim 5, wherein the RA response window is configured to stop if the received RA preamble ID matches the PREAMBLE_INDEX sent in the MsgA.

9. A method for a network system, the method comprising: The configuration is sent to the user equipment including a first threshold relative to a first counter for a four-step random access RA, wherein the first threshold is the configured number of failed attempts, and a four-step random access process occurs after the first counter reaches the first threshold; MsgA is received as a two-step RA preamble transmission to the network node, wherein MsgA is sent after a second counter is incremented based on confirmation that the value of the first counter is not greater than the first threshold, and the second counter is used to calculate the RA target power of the two-step RA preamble transmission. Send MsgB to the User Equipment as a Random Access Response (RAR) for the two-step RA preamble transmission, wherein the MsgB is received by the User Equipment during an RA response window for monitoring responses to the MsgA, wherein the MsgB includes an indication that the MsgA payload was not successfully decoded and an uplink UL grant for Msg3 transmission, wherein the indication that the MsgA payload was not successfully decoded is provided by the RA preamble ID field in the MAC sub-header; and Based on the instruction, Msg3 is received from the user equipment as step 3 of the four-step RA on the UL resources configured in the UL authorization, wherein Msg3 includes the MsgA payload.

10. The method of claim 9, wherein the first counter is configured to increment upon detection of a Listen Before Talk (LBT) fault indication.

11. The method of claim 10, wherein the LBT fault indication is provided from the physical PHY layer to the media access control (MAC) layer.

12. The method of claim 9, wherein the RA response window is configured to stop if the received RA preamble ID matches the PREAMBLE_INDEX sent in the MsgA.

Images