Apparatus, system and method for performing two-step RACH

Abstract

A first device in a wireless communication system includes a circuit system configured to trigger a random access channel (RACH) process; select a two-step RACH process as a RACH type to be performed from among multiple RACH processes; select a MsgA transmission resource; transmit the MsgA; and monitor a network response from a second device.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 882,565, filed on August 4, 2019, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure relates generally to wireless communications, and more particularly to wireless communication systems, devices, methods, and computer-readable products that provide a practical solution for implementing 2-step RACH in wireless communication systems, especially 5G NR systems. Background Art

[0004] The "background" description provided herein is intended to generally present the context of the present disclosure. To the extent it is described in this background section, the work of the presently named inventors and the description of aspects that may not be prior art at the time the application was filed are not expressly or impliedly admitted to be prior art to the present invention. Moreover, the inventors recognize the limitations of conventional systems in implementing 2-step RACH processing in 5G systems. For example, the inventors recognize that while LTE RACH has been adopted, implementations of 4-step RACH and 2-step RACH are being developed for 5G NR and many implementation issues remain to be resolved. Summary of the invention

[0005] An exemplary embodiment of the present disclosure provides a first device in a wireless communication system. The first device includes a circuit system configured to trigger a random access channel (RACH) procedure; select a two-step RACH procedure as a RACH type to be performed from a plurality of RACH procedures; select a MsgA transmission resource; transmit MsgA; and monitor a network response from a second device.

[0006] An exemplary embodiment of the present disclosure provides a method performed by a first device in a wireless communication system. The method includes: triggering a random access channel (RACH) procedure; selecting a two-step RACH procedure as a RACH type to be performed from a plurality of RACH procedures; selecting a MsgA transmission resource; transmitting MsgA; and monitoring a network response from a second device.

[0007] An exemplary embodiment of the present disclosure provides a second device in a wireless communication system. The second device includes a circuit system configured to receive MsgA from a first device; send a network response to the first device, wherein the first device triggers a random access channel (RACH) process, selects a two-step RACH process from multiple RACH processes as the RACH type to be performed, and selects MsgA transmission resources.

[0008] This summary is provided to introduce a series of concepts in a simplified form, which will be further described in the following detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. In addition, the claimed subject matter is not limited to limitations that address any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The scope of the present disclosure may be best understood from the following detailed description of exemplary embodiments when read in conjunction with the accompanying drawings, in which:

[0010] Figure 1A is a system diagram illustrating an example 3GPP architecture;

[0011] Figure 1B is a system diagram showing an example of a radio access network (RAN) architecture and a core network architecture;

[0012] Figure 1C is a system diagram showing an example of a radio access network (RAN) architecture and a core network architecture;

[0013] Figure 1D is a system diagram showing an example of a radio access network (RAN) architecture and a core network architecture;

[0014] Figure 1E is a system diagram illustrating an example 3GPP architecture;

[0015] Figure 1F is a system diagram of an example apparatus or device configured for wireless communication;

[0016] Figure 1G is a system diagram illustrating an example of a computing system for use in a communication network;

[0017] Figure 2 is a diagram showing a one-to-one mapping between a preamble and a PRU according to an exemplary embodiment;

[0018] Figure 3 is a diagram illustrating cell partitioning based on DL signal quality according to an exemplary embodiment;

[0019] Figure 4 is a diagram showing a many-to-one mapping between a preamble and a PRU according to an exemplary embodiment;

[0020] Figure 5 is a diagram showing separate configuration of a PUSCH msgA opportunity and a PRACH opportunity by a higher layer parameter according to an exemplary embodiment;

[0021] Figure 6 is a diagram showing relative configuration of PUSCH msgA opportunities and PRACH opportunities by higher layer parameters according to an exemplary embodiment;

[0022] Figure 7 is a diagram illustrating two-step PRACH opportunities and PRACH preamble index association rules configured by higher layer parameters when N≥1 according to an exemplary embodiment;

[0023] Figure 8 is a diagram showing a one-to-many mapping between a preamble and a PRU according to an exemplary embodiment;

[0024] Fig. 9 is a diagram illustrating SR using 2-step RACH according to an exemplary embodiment;

[0025] Fig.10 is a diagram illustrating a MsgA MAC PDU for SR according to an exemplary embodiment;

[0026] Fig.11 is a signal diagram illustrating a request for on-demand system information using a 2-step RACH according to an exemplary embodiment;

[0027] Fig.12 is a signal diagram illustrating BFR using 2-step RACH according to an exemplary embodiment;

[0028] Fig.13 is a diagram showing a MsgA preamble and a PUSCH of TDM; and

[0029] Fig.14 is a signal diagram showing a failed LBT for MsgA preamble transmission, with MsgA retransmission;

[0030] Fig.15 is a signal diagram showing a failed LBT for MsgA PUSCH transmission, falling back to 4-step RACH; and

[0031] Fig.16 is a signal diagram showing a scenario in which the COT obtained by the gNB is used for MsgA preamble transmission and the COT obtained by the UE is used for MsgAPUSCH transmission.

[0032] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter.It should be understood that the detailed description of the exemplary embodiments is for illustration purposes only, and is therefore not intended to necessarily limit the scope of the present disclosure. DETAILED DESCRIPTION

[0033] The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication 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 standards, and New Radio (NR), also referred to as "5G". Development of the 3GPP NR standards is expected to continue and include the definition of next generation radio access technologies (new RATs), which are expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to include new, non-backwards compatible radio access in new spectrum below 7 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide set of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access for, for example, indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with sub-7 GHz flexible radio access, with cmWave- and mmWave-specific design optimizations.

[0034] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for 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-everything (eV2X) communications (which may include vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle communications with other entities). Specific services and applications in these categories include, for example, monitoring sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, car emergency calls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robotics, and aerial drones, among others. All of these use cases and others are contemplated herein.

[0035] The following is a list of acronyms related to service levels and core network technologies that may appear in the following descriptions. Unless otherwise stated, acronyms used in this article refer to the corresponding terms listed below.

[0036] Abbreviations and definitions

[0037]

[0038]

[0039]

[0040]

[0041] Example Communication Systems and Networks

[0042] Figure 1A An example communication system 100 is illustrated in which the systems, methods, and apparatus described and claimed herein may be used. The communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (generally or collectively referred to as WTRUs 102 or WTRUs 102). The communication system 100 may include a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. The network services 113 may include, for example, V2X servers, V2X functions, ProSe servers, ProSe functions, IoT services, video streaming, and / or edge computing, etc.

[0043] It will be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Figure 1A In the example of FIG. 1 , each of the WTRUs 102 is Figures 1A-1E It should be understood that for various use cases contemplated for 5G wireless communications, each WTRU may include or be implemented in any type of device or apparatus configured to transmit and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronics product, a wearable device (such as a smart watch or smart clothing), a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle (such as a car, bus or truck, a train or airplane, etc.).

[0044] The communication system 100 may also include a base station 114a and a base station 114b. Figure 1AIn the example of FIG. 1 , each base station 114 a and 114 b is depicted as a single element. In practice, the base stations 114 a and 114 b may include any number of interconnected base stations and / or network elements. The base station 114 a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102 a, 102 b, and 102 c to facilitate access to one or more communication networks (e.g., the core network 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112). Similarly, the base station 114b may be any type of device configured to interface wired and / or wirelessly with at least one of the remote radio heads (RRHs) 118a, 118b, the transmission and reception points (TRPs) 119a, 119b, and / or the roadside units (RSUs) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102 (e.g., WTRU 102c) to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the network services 113, and / or the other networks 112.

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

[0046] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Similarly, the base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a BSC, an RNC, a relay node, etc. The base station 114a may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may also be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, for example, the base station 114a may include three transceivers, for example, one for each sector of the cell. The base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell, for example.

[0047] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0048] The base station 114b may communicate with one or more of the RRHs 118a and 118b, the TRPs 119a and 119b, and / or the RSUs 120a and 120b over a wired or air interface 115b / 116b / 117b, which may be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). The air interface 115b / 116b / 117b may be established using any suitable RAT.

[0049] The RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f via an air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.). The air interface 115c / 116c / 117c may be established using any suitable RAT.

[0050] The WTRUs 102 may communicate with each other via a direct air interface 115d / 116d / 117d, such as a sidelink communication, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.). The air interface 115d / 116d / 117d may be established using any suitable RAT.

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

[0052] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c and 102g, or the RRHs 118a and 118b, TRPs 119a and 119b and / or RSUs 120a and 120b and the WTRUs 102c and 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish an air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using, for example, Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). The air interface 115 / 116 / 117 or 115c / 116c / 117c may implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and / or V2X technologies and interfaces (such as sidelink communications, etc.). Similarly, 3GPP NR technologies may include NR V2X technologies and interfaces (such as sidelink communications, etc.).

[0053] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, and 102g or the RRHs 118a and 118b, the TRPs 119a and 119b and / or the RSUs 120a and 120b and the WTRUs 102c, 102d, 102e, and 102f in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN) etc.

[0054] For example, Figure 1AThe base station 114c in the example may be a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a business location, a house, a vehicle, a train, an antenna, a satellite, a factory, a campus, etc. The base station 114c and the WTRU 102 (e.g., WTRU 102e) may implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and the WTRU 102 (e.g., WTRU 102d) may implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRU 102 (e.g., WTRU 102e) may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or a femtocell. Figure 1A As shown in FIG, the base station 114c may have a direct connection to the Internet 110. Therefore, the base station 114c may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0055] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and / or perform high-level security functions (such as user authentication).

[0056] Although not in Figure 1A 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM or NR radio technology.

[0057] The core network 106 / 107 / 109 may also serve as a gateway for the WTRU 102 to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet Protocol suite. Other networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 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 employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT.

[0058] 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, the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks via different wireless links. Figure 1A The WTRU 102g shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[0059] Although in Figure 1A 106 / 107 / 109. It will be appreciated that many of the concepts contained herein may be equally applicable to UEs of WTRUs and UEs that connect to the network using a wired connection. For example, concepts applicable to air interfaces 115, 116, 117, and 115c / 116c / 117c may be equally applicable to wired connections.

[0060] Figure 1B 1 is a system diagram of an example RAN 103 and a core network 106. As described above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. Figure 1BAs shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, and 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node-Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and Radio Network Controllers (RNCs).

[0061] like Figure 1B As shown in , Node B 140a, 140b can communicate with RNC 142a. In addition, Node B 140c can communicate with RNC 142b. Node B 140a, 140b and 140c can communicate with corresponding RNC 142a and 142b via Iub interface. RNC 142a and 142b can communicate with each other via Iur interface. Each of RNC 142a and 142b can be configured to control the corresponding Node B 140a, 140b and 140c to which it is connected. In addition, each of RNC 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 function, data encryption, etc.

[0062] Figure 1B The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0063] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices.

[0064] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

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

[0066] Figure 1C 1 is a system diagram of an example RAN 104 and a core network 107. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

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

[0068] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in uplink and / or downlink, etc. Figure 1C As shown in FIG, eNode-Bs 160a, 160b, and 160c may communicate with each other via an X2 interface.

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

[0070] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0071] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, and 102c. The serving gateway 164 may also perform other functions, such as anchoring a user plane during an inter-eNode B handover, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing contexts of the WTRUs 102a, 102b, and 102c, and the like.

[0072] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0073] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices. For example, the core network 107 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks owned or operated by other service providers.

[0074] Figure 1D1 is a system diagram of an example RAN 105 and a core network 109. The RAN 105 may employ NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117. The RAN 105 may also be in communication with the core network 109. A non-3GPP interworking function (N3IWF) 199 may employ non-3GPP radio technology to communicate with the WTRU 102c over the air interface 198. The N3IWF 199 may also be in communication with the core network 109.

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

[0076] 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 over the air interface 198. The non-3GPP access point 180c may communicate with the WTRU 102c over the air interface 198 using the 802.11 protocol.

[0077] Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in uplink and / or downlink, etc. Figure 1D As shown in , for example, gNode-Bs 180a and 180b may communicate with each other via an Xn interface.

[0078] Figure 1DThe core network 109 shown in the figure can be a 5G core network (5GC). The core network 109 can provide a variety of communication services to customers interconnected by a radio access network. The core network 109 includes multiple entities that perform the functions of the core network. As used herein, the term "core network entity" or "network function" refers to any entity that performs one or more functions of the core network. It should be understood that such a core network entity can be a logical entity implemented in the form of computer executable instructions (software) stored in a memory of a device or computer system (such as the system 90 shown in Figure x1G) configured for wireless and / or network communications and executed on its processor.

[0079] exist Figure 1D In the example of , the 5G core network 109 may include access and mobility management function (AMF) 172, session management function (SMF) 174, user plane function (UPF) 176a and 176b, user data management function (UDM) 197, authentication server function (AUSF) 190, network exposure function (NEF) 196, policy control function (PCF) 184, non-3GPP interworking function (N3IWF) 199, user data repository (UDR) 178. Although each of the aforementioned elements is depicted as part of the 5G core network 109, it should be recognized that any of these elements may be owned and / 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 1D The network functions are shown connected directly to each other, however, it should be appreciated that they may communicate via a routing agent such as a diameter routing agent or a message bus.

[0080] exist Figure 1D In the example of , the connectivity between network functions is realized via a set of interfaces or reference points. It will be appreciated that a network function can be modeled, described or realized as a set of services that are invoked or called by other network functions or services. The invocation of network function services can be realized via direct connections between network functions, exchange of message passing on a message bus, calling software functions, etc.

[0081] The AMF 172 may be connected to the RAN 105 via an N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF may be responsible for forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 may generally route and forward NAS packets to / from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not used in Figure 1D Shown in.

[0082] The SMF 174 may be connected to the AMF 172 via an N11 interface. Similarly, the SMF may be connected to the PCF 184 via an N7 interface and to the UPFs 176a and 176b via an N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may be responsible for session management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPFs 176a and 176b, and generation of downlink data notifications to the AMF 172.

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

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

[0085] PCF 184 may be connected to SMF 174 via an N7 interface, may be connected to AMF 172 via an N15 interface, and may be connected to application function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not Figure 1D 1. The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, thereby allowing the control plane nodes to enforce these rules. The PCF 184 may send policies for the WTRUs 102a, 102b, and 102c to the AMF 172 so that the AMF may deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies may then be enforced or applied at the WTRUs 102a, 102b, and 102c.

[0086] The UDR 178 may act as a repository for authentication credentials and subscription information. The UDR may be connected to network functions so that the network functions may add to, read, and modify data in the repository. For example, the UDR 178 may be connected to the PCF 184 via an N36 interface. Similarly, the UDR 178 may be connected to the NEF 196 via an N37 interface, and the UDR 178 may be connected to the UDM 197 via an N35 interface.

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

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

[0089] NEF 196 exposes the capabilities and services in the 5G core network 109 to the application function (AF) 188. The exposure can occur on the N33 API interface. NEF can be connected to AF 188 via the N33 interface and it can be connected to other network functions to expose the capabilities and services of the 5G core network 109.

[0090] The application function 188 may interact with the network function in the 5G core network 109. The interaction between the application function 188 and the network function may occur via a direct interface or may occur via the NEF 196. The application function 188 may be considered part of the 5G core network 109 or may be external to the 5G core network 109 and deployed by an enterprise having a business relationship with a mobile network operator.

[0091] 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 running across a single RAN. Network slicing enables operators to create networks that are customized to provide optimized solutions for different market scenarios that require different requirements (for example, in terms of functionality, performance and isolation).

[0092] 3GPP has designed the 5G core network to support network slicing. Network slicing is a great tool that network operators can use to support a diverse set of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband) that have very diverse and sometimes extreme requirements. Without using network slicing technology, the network architecture may not be flexible and scalable enough to efficiently support a wide range of use case requirements when each use case has its own specific set of performance, scalability, and availability requirements. In addition, the introduction of new network services should be made more efficient.

[0093] Reference again Figure 1D In a network slicing scenario, the WTRU 102a, 102b, or 102c may be connected to the AMF 172 via the N1 interface. The AMF may be logically part of one or more slices. The AMF may coordinate the connection or communication of the WTRU 102a, 102b, or 102c with one or more UPFs 176a and 176b, SMF 174, and other network functions. Each of the UPFs 176a and 176b, the SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.

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

[0095] This article describes and Figure 1A , 1C The core network entities shown in 1D and 1E are identified by the names given to those entities in certain existing 3GPP specifications, but it will be appreciated that those entities and functions may be identified by other names in the future, and that certain entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Figure 1A , 1B , 1C, 1D and 1E, and it should be understood that the subject matter disclosed and claimed herein may be implemented or realized in any similar communication system (whether currently defined or defined in the future).

[0096] Figure 1E An example communication system 111 is illustrated in which the systems, methods, and apparatus described herein may be used. The communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 1024, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein may be applied to any number of WTRUs, base stations gNBs, V2X networks, and / or other network elements. One or several or all WTRUs A, B, C, D, E, and F may be outside the range of access network coverage 1022. WTRUs A, B, and C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members.

[0097] If WTRUs A, B, C, D, E, and F are within the coverage of the access network, they can communicate with each other via gNB 121 over the Uu interface 129b (in Figure 1EOnly B and F are shown within the network coverage in FIG. 1 ). If WTRUs A, B, C, D, E, F are within or outside the access network coverage, they can communicate directly with each other via the sidelink (PC5 or NR PC5) interface 125a, 125b, the vehicle-to-person (V2P) interface 1028 (e.g., in Figure 1E In A, C, WTRU A, B, C, D, E, F can communicate with each other, D and E are shown as outside the network coverage).

[0098] WTRUs A, B, C, D, E, and F may communicate with the RSU 123a or 123b via the vehicle-to-network (V2N) 1026 or the sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate with the V2X server 1024 via the vehicle-to-infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate with another UE via the vehicle-to-person (V2P) interface 1028.

[0099] Figure 1F is a block diagram of an example apparatus or device WTRU 102 that may be configured to wirelessly communicate and operate in accordance with the systems, methods, and apparatus described herein, such as Figure 1A , 1B , 1C, 1D, or 1E. Figure 1F As shown in FIG, 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, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements, and that the base stations 114a and 114b and / or the nodes that the base stations 114a and 114b may represent (such as, but not limited to, a transceiver station (BTS), a Node B, a site controller, an access point (AP), a Home Node B, an evolved Home Node B (eNodeB), a Home evolved Node B (HeNB), a Home evolved Node B gateway, a next generation Node B (gNode-B), and a proxy node, among others) may include Figure 1F Some or all of the elements depicted in and described herein.

[0100] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of 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 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1F The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0101] The transmit / receive element 122 of the UE may be configured to transmit data to a base station (eg, Figure 1A The transmission / reception element 122 may be a base station 114a) of a wireless communication network, or may transmit or receive signals to or from another UE via an air interface 115d / 116d / 117d. For example, the transmission / reception element 122 may be an antenna configured to transmit and / or receive RF signals. The transmission / reception element 122 may be a transmitter / detector configured to, for example, transmit and / or receive IR, UV, or visible light signals. The transmission / reception element 122 may be configured to transmit and receive both RF and optical signals. It will be appreciated that the transmission / reception element 122 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0102] In addition, although the transmit / receive element 122 is Figure 1F Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0103] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA) or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

[0104] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. The processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server hosted in a cloud or edge computing platform or in a home computer (not shown).

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

[0106] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / 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 by any suitable location-determination method.

[0107] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 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, modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

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

[0109] Figure 1G is a block diagram of an exemplary computing system 90 in which Figure 1A , 1C , 1D and 1E, such as certain nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, other networks 112 or network services 113. The computing system 90 may include a computer or a server and may be primarily controlled by computer-readable instructions, which may be in the form of software, wherever, whenever, or by any means to store or access such software. Such computer-readable instructions may be executed within the processor 91 to enable the computing system 90 to operate. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of 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 and / or any other function that enables the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0110] In operation, processor 91 fetches, decodes and executes instructions, and transfers information to and from other resources via the computing system's main data transfer path, system bus 80. Such a system bus connects components in computing system 90 and defines a medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0111] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes a circuit system that allows information to be stored and retrieved. ROM 93 generally contains stored data that is not easily modified. The data stored in RAM 82 can be read or changed by a processor 91 or other hardware device. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that translates a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set up, it cannot access memory within the virtual address space of another process.

[0112] In addition, the computing system 90 may include a peripheral device controller 83 that 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 .

[0113] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such 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 with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

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

[0115] It should be understood that any or all of the devices, 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), causes the processor to perform and / 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 executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in 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 technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassette, tape, disk storage or other magnetic storage device, or any other tangible or physical medium that can be used to store desired information and can be accessed by a computing system.

[0116] Random access process

[0117] A high-level description of the NR random access procedure is defined in 3GPP TS 38.300 [1].

[0118] LTE License Assisted Access

[0119] A high-level description of LTE Grant Assisted Access is provided in 3GPP TS 36.300 [2].

[0120] Channel Access Category

[0121] The channel access schemes evaluated for LAA are defined in 3GPP TR 36.889 [3].

[0122] UL channel access process

[0123] LAA Type 1 and Type 2 UL channel access procedures are defined in 3GPP TS 36.213 [4].

[0124] Beam Fault Detection and Restoration

[0125] NR beam failure detection and recovery is defined in 3GPP TS 38.300[1].

[0126] Problems to be solved by the present disclosure

[0127] First problem: Efficient transmission of MAC PDUs with various sizes and QoS requirements using 2-step RACH

[0128] The triggers defined for NR 4-step RACH are also applicable to 2-step RACH. In addition, Early Data Transfer (EDT) is already supported for LTE, which allows an optional uplink data transfer followed by a downlink data transfer during the random access procedure [2], and is likely to be considered as a use case for 2-step RACH in NR. When 2-step RACH is selected as the RACH type, MsgA corresponds to the preamble and payload transmission of the random access procedure. [1] The requirements for the MsgA payload (e.g., size, latency, reliability) will depend on the triggering event; e.g., control plane (CP) signaling, user plane (UP) data transmission. Therefore, a mechanism is needed to support efficient transmission of MAC PDUs of various sizes via MsgA and MsgB; and to ensure that the QoS requirements (e.g., latency, reliability) of the messages signaled via the 2-step RACH procedure are met. In addition, since it is expected that networks supporting 2-step RACH will also support 4-step RACH, a mechanism is also needed to select the RACH type that ensures load balancing between 2-step RACH and 4-step RACH.

[0129] Second question: MsgA PUSCH reception for unsynchronized UEs

[0130] Typically, in a cellular system, a UE initially acquires UL synchronization through a random access procedure during which the base station signals to the UE an initial timing advance value as an absolute time advance value of the start of an uplink frame relative to the start of a corresponding downlink frame as part of a random access response message. The UE then continues to maintain uplink synchronization with the base station through periodic UL transmissions controlled by a timing advance timer, which allows the base station to determine whether an adjustment to the timing advance is required; and if so, the base station updates the timing advance value to the UE by signaling to the UE a timing advance value relative to the current timing advance value in the UE.

[0131] When performing 2-step RACH, the UE may not have UL synchronization. For non-terrestrial networks (NTN) and terrestrial networks (TN) with large cells, MsgA PUSCH reception may fail for a given UE if the timing error exceeds the CP length. In addition, MsgA transmissions from multiple UEs will not be orthogonal if they are not properly time-aligned when received by the gNB, which will cause interference between MsgA PUSCH transmissions of neighboring UEs. Therefore, in order to ensure that MsgA PUSCH transmissions can be reliably received in NTNs and TNs with large cells, a mechanism is needed to improve the time alignment of UEs that are not synchronized when performing the 2-step RACH procedure.

[0132] The third problem: BFR latency and radio resource efficiency

[0133] NR Release 15 supports both CF BFR and CB BFR. CF BFR requires the UE to configure dedicated RACH resources for each candidate beam that can be selected by the UE when performing BFR. The gNB can implicitly identify the UE performing BFR and the selected beam based on the detected random access preamble. From a signaling and latency perspective, the CF BFR procedure is optimal because the BFR procedure can be completed in two steps. However, from a radio resource perspective, it can be very inefficient because it requires dedicated RACH resources to be provided for each candidate beam that can be selected by the UE when performing BFR. CB BFR does not require the configuration of dedicated RACH resources, but instead uses a 4-step RACH procedure to indicate the UE identity and selected beam to the gNB when performing BFR. The benefit of not requiring dedicated RACH resources comes at the expense of increased signaling and latency because 4 steps are required to complete the BFR procedure. If the number of candidate beams is very large, which may be the case for deployments in FR2 and FR4 bands where beam failure rates are expected to be higher when compared to deployments in FR1 bands, then using CF BFR may not be practical, however, the increased signaling and latency associated with CB BFR may not be tolerable. Therefore, a mechanism is needed to perform BFR that is more efficient from a radio resource perspective while not introducing additional signaling and latency.

[0134] Table 1: Definition of frequency range

[0135] Frequency range specification Corresponding frequency range FR1 410MHz–7125MHz FR2 24250MHz–52600MHz FR4 52600MHz–114250MHz

[0136] Fourth problem: Large changes in RTT for NTN

[0137] For non-terrestrial networks (NTNs), the round trip time (RTT) can vary significantly for a UE at the cell edge relative to the cell center. This variation can result in ambiguity in the reception of the MsgA preamble at the gNB if the preamble reception windows for the RACH occasions (ROs) overlap. If the gNB cannot determine which RO is used to transmit the preamble, the timing advance command cannot be calculated correctly, which will cause interference in subsequent UL transmissions. The ROs can be configured so that the preamble reception windows do not overlap. However, this will reduce the RACH capacity. In addition, if the RTT is not considered when determining the start of the ra-Response-Window, the usable portion of the ra-Response-Window will be reduced, which will cause congestion when scheduling MsgB / RAR. Failure to consider the RTT when determining the start of the ra-Response-Window will also result in unnecessary power consumption by the UE 102 because it will monitor the MsgB / RAR before the gNB 180b can transmit the MsgB / RAR. Therefore, in order to increase RACH capacity and minimize unnecessary UE power consumption for NTNs, a mechanism is needed to consider the RTT when performing the 2-step RACH procedure.

[0138] Issue 5: Impact of LBT failure on 2-step RACH for NR-U

[0139] To mitigate the impact of LBT failure, the 2-step RACH procedure can be used for NR-U as it reduces the number of LBT attempts by half compared to the 4-step RACH procedure. However, to achieve 2-step RACH performance comparable to licensed bands, additional enhancements will be required to further reduce the LBT impact. During the NR-U SI [3], it was agreed that to mitigate the impact of LBT failure, additional opportunities could be introduced for RACH messages, e.g., in the time domain or frequency domain. COT sharing has also been discussed as a mechanism to reduce the impact of LBT failure. The NR 2-step RACH procedure being developed for licensed band operation does not include support for mechanisms to reduce the impact of LBT failure (e.g., additional opportunities for MsgA transmission, COT sharing). Therefore, there is a need to enhance the 2-step RACH procedure to provide support for new mechanisms to reduce the impact of LBT failure when performing 2-step RACH for NR-U.

[0140] In addition, for some configurations, separate LBT procedures may be required for MsgA preamble and PUSCH; for example, when MsgA preamble and PUSCH are TDMed or MsgA preamble and PUSCH are FDMed in different subbands. For such configurations, a mechanism is needed to determine when the UE needs to perform two LBT procedures, how to determine the channel access priority class (CAPC) for the LBT procedures, and the behavior for scenarios where one or both LBT procedures fail.

[0141] Overview

[0142] As a non-limiting overview of the contents of the present disclosure, at least the following solutions are set forth.

[0143] Solution for efficient transmission of MAC PDUs with various sizes and QoS requirements using 2-step RACH

[0144] o A method for performing RACH type selection based on network configuration, DL radio quality, MsgA payload size, logical channel, and the state of timeAlignmentTimer. Throughout the disclosure, DL radio quality and DL signal quality are interchangeable.

[0145] o Method for performing MsgA resource selection for one-to-one, many-to-one, and one-to-many mapping between preamble and PUSCH resource elements

[0146] οMethod for performing MsgA preamble and PUSCH transmission

[0147] οMethod for executing MsgB / Msg2 reception

[0148] Solution for MsgA PUSCH reception by unsynchronized UEs

[0149] ο Method for calculating open-loop timing advance value based on distance

[0150] o Method for determining timing advance based on neighboring UE timing

[0151] ο Method for determining timing advance based on assistance information from gNB

[0152] Solutions for BFR latency and radio resource efficiency

[0153] οMethod for performing BFR using 2-step RACH

[0154] οMethod for performing BFR on Scell ​​using 2-step RACH

[0155] Solution for the impact of LBT failure on 2-step RACH for NR-U

[0156] o Method for performing channel access procedure for MsgA configuration with TDM preamble and PUSCH

[0157] οMethods to prevent MsgA inter-blocking

[0158] οMethod for transmitting MsgA preamble and PUSCH on different beams

[0159] Detailed description of the solution

[0160] In the following subsections, solutions are defined to address the problems identified above. These solutions may be used alone or in combination with one or more of the solutions described herein. In the solution description, the term LBT is used to refer to UL channel access procedures that are the same or similar to the Type 1 and Type 2 UL channel access procedures used for LTE LAA.

[0161] Example embodiments for efficient transmission of MAC PDUs with various sizes and QoS requirements using 2-step RACH

[0162] In the following subsections, a process for performing a 2-step RACH is described, which can be used to solve the problem associated with efficiently transmitting MAC PDUs of various sizes and QoS requirements using a 2-step RACH as described in the first problem to be solved above.

[0163] RACH type selection

[0164] The network may support both 2-step and 4-step RACH procedures. For such scenarios, the UE may perform RACH type selection before starting the random access procedure. In the following subsections, the procedures for performing RACH type selection are defined. In addition to selecting between 2-step RACH and 4-step RACH, the UE 102 may also consider selecting a prioritized 2-step RACH procedure. The procedures described herein may be extended to include selecting a prioritized 2-step RACH procedure.

[0165] RACH type selection based on network configuration

[0166] RACH type selection may be based on network configuration, which is provided via broadcast or dedicated signaling to UE 102. For example, the network may configure UE 102 to use 2-step RACH for specific triggering events; e.g., initial access from RRC_IDLE, transition from RRC_INACTIVE.

[0167] To implement this behavior, the RACH type selection process can be defined as follows:

[0168] 1> if the serving cell for the random access procedure is configured for 2-step RACH; and

[0169] 1> If the random access procedure is initiated for initial access from RRC_IDLE or transition from RRC_INACTIVE;

[0170] 2> Select 2-step RACH as the RACH type for performing the random access procedure.

[0171] 1> Otherwise:

[0172] 2> Select 4-step RACH as the RACH type for performing the random access procedure.

[0173] For NR, the UE 102 can be configured to perform a prioritized random access procedure for specific triggers (e.g., handover and BFR). When performing a prioritized random access procedure, different values ​​are used for some of the RACH parameters as configured by the network; for example, powerRampingStepHighPriority, scalingFactorBI. The parameter powerRampingStepHighPriority corresponds to the power ramp factor used in the case of a prioritized random access procedure, which controls how much the power is "stepped" up for retransmissions after an unsuccessful RACH attempt. The parameter scalingFactorBI corresponds to the scaling factor used in the case of a prioritized random access procedure, which is used to scale the value of the backoff indicator signaled via the random access response.

[0174] Prioritization of the random access procedure can also be achieved by performing a 2-step RACH. In this case, the network configuration can be used to configure the UE to perform a 2-step RACH procedure. The prioritized RACH parameter set; powerRampingStepHighPriority, scalingFactorBI used when performing a prioritized 2-step RACH can be the same as the parameter set used when performing a prioritized 4-step RACH procedure, or a separate prioritized 2-step RACH parameter set can be configured. And in another exemplary embodiment, the default parameters for 4-step RACH broadcasted by the cell can also be used.

[0175] RACH type selection based on DL radio quality

[0176] RACH type selection may be based on DL radio quality; for example, SS-RSRP or CSI-RSRP. The DL radio quality is compared to a threshold to determine the RACH type, where the threshold may be predefined or provided by the network via broadcast or dedicated signaling. The threshold may be defined as an absolute value; for example, 2-step-rsrp-ThresholdSSB, 2-step-rsrp-ThresholdCSI-RS. Alternatively, the threshold may be defined as a relative value, where the threshold is relative to a threshold for random access resource selection; for example, rsrp-ThresholdSSB, rsrp-ThresholdCSI-RS.

[0177] To implement this behavior, the RACH type selection process can be defined as follows:

[0178] 1> If the serving cell used for the random access procedure is configured for 2-step RACH;

[0179] 2>If you select SSB;

[0180] 3> If SS-RSRP is higher than rsrp-ThresholdSSB or 2-step-rsrp-

[0181] ThresholdSSB:

[0182] 4> Select 2-step RACH as the RACH type for performing the random access procedure.

[0183] 3> Otherwise:

[0184] 4> Select 4-step RACH as the RACH type for performing the random access procedure.

[0185] 2> Otherwise if CSI-RS is selected;

[0186] 3> If CSI-RSRP is higher than rsrp-ThresholdCSI-RS or 2-step-

[0187] rsrp-ThresholdCSI-RS:

[0188] 4> Select 2-step RACH as the RACH type for performing the random access procedure.

[0189] 3> Otherwise:

[0190] 4> Select 4-step RACH as the RACH type for performing the random access procedure.

[0191] In another exemplary embodiment, RACH type selection may be based on path loss, wherein the downlink path loss calculation may be based on the DL RS associated with the selected SSB.

[0192] To implement this behavior, the RACH type selection process can be defined as follows:

[0193] 1> If the serving cell used for the random access procedure is configured for 2-step RACH;

[0194] 2> If the RSRP referenced by the downlink path loss is less than rsrp-ThresholdSSB-2-step-ra:

[0195] 3> Select 4-step RACH as the RACH type for performing the random access procedure.

[0196] 2> Otherwise:

[0197] 3> Select 2-step RACH as the RACH type for performing the random access procedure.

[0198] And in still other embodiments, RACH type selection may be based on other measurement quantities; for example, RSRQ, RSSI, SINR, etc.

[0199] RACH type selection based on MsgA PDU size

[0200] RACH type selection may be based on MsgA PDU size. For example, if the MsgA PDU is below a threshold, such as ra-MsgASize, then a 2-step RACH procedure is selected; otherwise, a 4-step RACH is selected. The threshold may be predefined or provided by the network via broadcast or dedicated signaling.

[0201] To implement this behavior, the RACH type selection process can be defined as follows:

[0202] 1> If the serving cell used for the random access procedure is configured for 2-step RACH;

[0203] 2> If the MsgA PDU size is smaller than ra-MsgASize:

[0204] 3> Select 2-step RACH as the RACH type for performing the random access procedure.

[0205] 2> Otherwise:

[0206] 3> Select 4-step RACH as the RACH type for performing the random access procedure.

[0207] RACH type selection based on logical channel

[0208] The RACH type selection may be based on the logical channel that triggered the random access procedure. The mapping between logical channels and RACH types may be predefined or provided by the network via broadcast or dedicated signaling. The logical channel that triggered the random access procedure may correspond to the logical channel associated with the BSR that triggered the SR and thus the RACH procedure.

[0209] In an exemplary embodiment, a 2-step RACH is selected for the CCCH or CCCH1 logical channel, allowing the RRC message for (re)establishing the connection to be signaled via MsgA.

[0210] To implement this behavior, the RACH type selection process can be defined as follows:

[0211] 1> If the serving cell used for the random access procedure is configured for 2-step RACH;

[0212] 2> If the random access procedure is initiated for the CCCH or CCCH1 logical channel:

[0213] 3> Select 2-step RACH as the RACH type for performing the random access procedure.

[0214] 2> Otherwise:

[0215] 3> Select 4-step RACH as the RACH type for performing the random access procedure.

[0216] In an exemplary embodiment, RACH type selection is based on one or more QoS characteristic parameters, such as the priority of the logical channel that triggered the random access procedure.The priority of the logical channel that triggered the random access procedure is compared with a threshold to determine the RACH type.

[0217] To implement this behavior, the RACH type selection process can be defined as follows:

[0218] 1> If the serving cell used for the random access procedure is configured for 2-step RACH;

[0219] 2> If the priority of the logical channel that triggered the random access process is less than 2-step-priority:

[0220] 3> Select 2-step RACH as the RACH type for performing the random access procedure.

[0221] 2> Otherwise:

[0222] 3> Select 4-step RACH as the RACH type for performing the random access procedure.

[0223] Note: In this example, increasing priority values ​​are assumed to indicate lower priorities.

[0224] In an exemplary embodiment, the RACH type may be explicitly configured for a logical channel. In this embodiment, the RACH type used to perform the random access procedure will be set to the RACH type configured for the logical channel that triggered the random access procedure.

[0225] To implement this behavior, the RACH type selection process can be defined as follows:

[0226] 1> Set the RACH type to the RACH type configured for the logical channel that triggered the random access procedure.

[0227] RACH type selection based on timeAlignmentTimer

[0228] RACH type selection may be based on whether timeAlignmentTimer is running. When timeAlignmentTimer is running, the UL is assumed to be "in sync", allowing MsgA PUSCH transmissions to occur without causing UL interference.

[0229] To implement this behavior, the RACH type selection process can be defined as follows:

[0230] 1> If the serving cell used for the random access procedure is configured for 2-step RACH;

[0231] 2> If the timeAlignmentTimer associated with the serving cell for which the random access procedure has been triggered is running:

[0232] 3> Select 2-step RACH as the RACH type for performing the random access procedure.

[0233] 2> Otherwise:

[0234] 3> Select 4-step RACH as the RACH type for performing the random access procedure.

[0235] For scenarios where timeAlignmentTimer is not running, RACH type selection may also be based on whether an open-loop timing advance command is applicable, where the open-loop timing advance command may be calculated using the method described herein.

[0236] RACH type selection based on UE location

[0237] The RACH type selection may be based on, for example, a reception time difference measured between two or more reference signals at the UE 102 or between a serving cell and one or more neighbor cells at the UE 102, e.g., a received frame time difference between the cells. For example, if the time difference is above a configurable threshold, the UE 102 may select a 2-step RACH, and if the time difference is below the threshold, the UE 102 may select a 4-step RACH. In some cases, multiple thresholds are configured, and if the time difference is above one threshold but below another threshold, the UE 102 may select a 2-step RACH.

[0238] In some cases, the reference point in the time difference measurement is the path that is received first in time.

[0239] The time difference between signals / cells may be related, for example, to the distance to the corresponding transmission reception point (TRP). Consider an example of synchronously transmitting signals from two TRPs. If the UE 102 is located in the middle between the TRPs, the signal may be received with a small time difference. If the UE 102 is close to one TRP but far from another TRP, the signal may be received with a larger time difference. Therefore, UEs 102 with similar reception time differences may be received aligned at the TRP time.

[0240] RACH type selection for retransmission

[0241] When performing a 2-step RACH or 4-step RACH procedure, for scenarios where the UE 102 does not receive a response from the network (e.g., MsgB or RAR), the UE 102 may retransmit using the RACH type selected before starting the random access procedure. Alternatively, the UE 102 may perform RACH type selection before performing a retransmission.

[0242] In an exemplary embodiment, a timer or retransmission counter may be used to determine when UE 102 should select a different RACH type; for example, fall back from 2-step RACH to 4-step RACH.

[0243] When UE 102 falls back to 4-step RACH, if a prioritized 2-step RACH procedure is being performed, a prioritized 4-step RACH may also be performed. In an exemplary embodiment, the same prioritized parameters are used for 2-step and 4-step RACH; for example, powerRampingStepHighPriority, scalingFactorBI. Alternatively, separate prioritized RACH parameter sets may be configured for 2-step RACH and 4-step RACH. In an exemplary embodiment, when UE 102 falls back to 4-step RACH, a prioritized 4-step RACH procedure may be performed regardless of the priority of the 2-step RACH procedure. In an exemplary embodiment, when UE 102 falls back to 4-step RACH, a conventional 4-step RACH procedure may be performed regardless of the priority of the 2-step RACH procedure.

[0244] RACH type selection based on UL carrier

[0245] In an exemplary embodiment, RACH type selection can be based on the UL carrier. For example, the RACH type can be configured per carrier; for example, using 4-step RACH for SUL and 2-step RACH for NUL. This configuration would allow separation of Msg1 and MsgA transmissions onto different carriers. If the selection of the UL carrier is based on a measurement, such as SSB RSRP, then the selection of the UL carrier, or equivalently between a 2-step or 4-step RACH procedure, can be based on a configurable threshold, such as rsrp-ThresholdSSB-SUL.

[0246] RACH type selection based on preamble group

[0247] For 4-step RACH, there are two preamble groups (Group A and B) from which the UE selects the preamble based on the Msg3 size. If 2-step RACH is configured, then Group A preambles can be assigned to 2-step RACH and Group B preambles can be assigned to 4-step RACH.

[0248] RACH type selection based on power / battery status

[0249] The power / battery status of the UE 102 may be considered for RACH type selection. For example, for a scenario where a 2-step RACH may consume less power than a 4-step RACH, if the UE 102 is in a low power mode, it will use the selected 2-step RACH for power saving purposes. In an exemplary embodiment, in order to reduce the latency and / or number of retransmissions associated with completing a RACH procedure, the UE 102 may select a prioritized 2-step RACH procedure to reduce power consumption.

[0250] RACH type selection based on network indication

[0251] The network may provide an indication to the UE 102 to indicate the type of RACH procedure to be performed, where the indication may be provided via physical layer or higher layer signaling. In one example, a DCI field in a PDCCH order may be used to indicate the type of RACH to be used.

[0252] In an exemplary embodiment, the handover command signaled via the RRC layer may include a field indicating a RACH type to be used when performing a RACH procedure with the target cell.

[0253] The network indication may also include information for configuring UE 102 to perform a prioritized 2-step RACH procedure. For example, a RACH-ConfigDedicated IE included in the handover command may include a field indicating whether to perform a 2-step RACH, and may also include a ra-Prioritization parameter for specifying powerRampingStepHighPriority and scalingFactorBI RACH parameters.

[0254] MsgA Resource Selection

[0255] MsgA consists of a random access preamble and a PUSCH transmission. Therefore, the selection of MsgA resources includes the selection of PRACH resources; that is, the preamble and RACH opportunity (RO), and the PUSCH resource unit (PRU). The RO and the associated PRU can be multiplexed using TDM or FDM. PRUs can also be TDM and / or FDM with each other. One-to-one, many-to-one, and one-to-many mappings can be envisioned for mapping between random access preambles in each RO and associated PRUs. In the following subsections, the MsgA resource selection process that can be used when performing a 2-step RACH is described.

[0256] One-to-one mapping between preamble and PUSCH resource elements

[0257] For one-to-one mapping, each random access preamble in the RO is associated with a PRU. The preamble space can be partitioned into one or more groups, where each group corresponds to a different PUSCH configuration. For example, one or more parameters such as MCS, TBS size, number of PRBs per PRU or number of symbols per PRU, DMRS, etc. can be defined differently for each PUSCH configuration. Figure 2 is an illustration of an exemplary one-to-one mapping between random access preambles and PRUs for a configuration in which two preamble groups (e.g., group 1 and group 2) are configured. In this example, group 1 consists of M preambles and group 2 consists of N preambles. When initiating a random access procedure, the UE 102 may select a preamble group based on one or more of: MsgA PDU size, DL signal quality, path loss, random access triggering event, etc.

[0258] In an exemplary embodiment, multiple preamble groups associated with PUSCH configurations corresponding to different TBS sizes are defined.The threshold parameter may be used by the UE 102 to select an appropriate preamble group based on the MsgA PDU size.

[0259] To illustrate this example, consider a configuration in which two preamble groups (e.g., group 1 and group 2) are configured, such as Figure 2To facilitate MsgA resource selection, a higher layer (e.g., RRC) may configure an IE (e.g., msgAGroup2Configured) consisting of a threshold for determining the random access preamble group (e.g., ra-MsgASizeGroup1) and the number of random access preambles in random access preamble group 1 for each SSB (e.g., numberOfRA-PreamblesMsgAGroup1).

[0260] MsgA resource selection based on MsgA PDU size can be performed as follows:

[0261] 1> If at least one SSB with SS-RSRP higher than rsrp-ThresholdSSB is available:

[0262] 2> Select an SSB whose SS-RSRP is higher than rsrp-ThresholdSSB.

[0263] 1> Otherwise:

[0264] 2>Select Any SSB.

[0265] 1> If MsgA has not been transmitted:

[0266] 2> If random access preamble MsgA group 2 is configured:

[0267] 3> If the size of MsgA is greater than ra-MsgASizeGroup1:

[0268] 4> Select random access preamble code MsgA group 2.

[0269] 3> Otherwise:

[0270] 4> Select random access preamble code MsgA group 1.

[0271] 2> Otherwise:

[0272] 3> Select random access preamble code MsgA group 1.

[0273] 1> Otherwise (i.e., MsgA is being retransmitted):

[0274] 2> Select the MsgA group of the same random access preamble as that used for the random access preamble transmission attempt corresponding to the first transmission of MsgA.

[0275] 1> Randomly select a random access preamble with equal probability from the random access preambles associated with the selected SSB and the selected random access preamble MsgA group.

[0276] 1> Set PREAMBLE_INDEX to the selected random access preamble.

[0277] 1> If configured or indicated by PDCCH, determine the next available PRACH opportunity from the PRACH opportunities corresponding to the selected SSB allowed by the restrictions given by ra-ssb-OccasionMaskIndex (the MAC entity shall randomly select the PRACH opportunity with equal probability among the consecutive PRACH opportunities corresponding to the selected SSB according to subclause 8.1 of TS 38.213; the MAC entity may consider the possible occurrence of measurement gaps when determining the next available PRACH opportunity corresponding to the selected SSB).

[0278] 1> Determine the next available PUSCH opportunity from the PUSCH opportunities corresponding to the selected PRACH opportunity and the selected random access preamble.

[0279] 1>Perform the MsgA transmission process as described in this article.

[0280] In the above example, UE 102 selects the MsgA group of the same random access preamble as the random access preamble transmission attempt corresponding to the first transmission of MsgA. Alternatively, UE 102 may perform MsgA resource selection for each retransmission of MsgA. In the above example, UE 102 selects an SSB with an SS-RSRP higher than a threshold (e.g., rsrp-ThresholdSSB). In another example, UE 102 may select a CSI-RS with a CSI-RSRP higher than a threshold (e.g., RSRP-ThresholdCSI-RS or msgA-RSRP-ThresholdCSI-RS).

[0281] In another example, multiple preamble groups associated with different PUSCH configurations are defined, and a threshold parameter is used by the UE 102 to select an appropriate preamble group based on DL signal quality. The PUSCH configurations associated with different preamble groups may be defined so that they provide minimum BLER for different areas of the cell; for example, a different MCS may be used for the PUSCH configuration associated with each preamble group.

[0282] To illustrate this example, consider Figure 3The cell shown in FIG. 1 is divided into a scenario of 2 regions corresponding to UEs 102 near the cell edge and UEs 102 near the cell center. Preambles in a first group (e.g., group 1 associated with a first PUSCH configuration) are selected by UEs in region 1; and preambles in a second group (e.g., group 2 associated with a second PUSCH configuration) are selected by UEs in region 2. A higher layer (e.g., RRC) may configure an IE (e.g., msgAGroup2Configured) consisting of a threshold for determining a group of random access preambles (e.g., ra-MsgAThreshGroup1) and the number of random access preambles in random access preamble group 1 for each SSB (e.g., numberOfRA-PreamblesMsgAGroup1).

[0283] MsgA resource selection based on DL signal quality can be performed as follows:

[0284] 1> If at least one SSB with SS-RSRP higher than rsrp-ThresholdSSB is available:

[0285] 2> Select an SSB whose SS-RSRP is higher than rsrp-ThresholdSSB.

[0286] 1> Otherwise:

[0287] 2>Select Any SSB.

[0288] 1> If MsgA has not been transmitted:

[0289] 2> If random access preamble MsgA group 2 is configured:

[0290] 3> If the SS-RSRP of the selected SSB is higher than ra-

[0291] MsgAThreshGroup1:

[0292] 4> Select random access preamble code MsgA group 2.

[0293] 3> Otherwise:

[0294] 4> Select random access preamble code MsgA group 1.

[0295] 2> Otherwise:

[0296] 3>Select random access preamble group 1.

[0297] 1> Otherwise (i.e., MsgA is being retransmitted):

[0298] 2> Select the MsgA group of the same random access preamble as that used for the random access preamble transmission attempt corresponding to the first transmission of MsgA.

[0299] 1> Randomly select a random access preamble with equal probability from the random access preambles associated with the selected SSB and the selected random access preamble MsgA group.

[0300] 1> Set PREAMBLE_INDEX to the selected random access preamble.

[0301] 1> If configured or indicated by PDCCH, then determine the next available PRACH opportunity from the PRACH opportunities corresponding to the selected SSB allowed by the restrictions given by ra-ssb-OccasionMaskIndex (the MAC entity shall randomly select the PRACH opportunity with equal probability among the consecutive PRACH opportunities corresponding to the selected SSB according to subclause 8.1 of [5]; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH opportunity corresponding to the selected SSB).

[0302] 1> Determine the next available PUSCH opportunity from the PUSCH opportunities corresponding to the selected PRACH opportunity and the selected random access preamble.

[0303] 1>Perform the MsgA transmission process as described in this article.

[0304] In the above example, UE 102 selects the MsgA group of the same random access preamble as used for the random access preamble transmission attempt corresponding to the first transmission of MsgA. Alternatively, UE 102 may perform MsgA resource selection for each retransmission of MsgA. It is also contemplated that a MsgA resource selection process based on measurements such as RSRQ, SINR, path loss, etc. is used, where a similar process is used, such as that described for MsgA resource selection based on DL signal quality.

[0305] In an exemplary embodiment, MsgA resource selection may be based on the available power headroom. For example, UE 102 may select a PRU corresponding to a PUSCH configuration that allows it to perform MsgA transmission without exceeding the available power headroom.

[0306] Many-to-one mapping between preamble and PUSCH resource elements

[0307] For many-to-one mapping, multiple random access preambles in the RO are associated with the same PRU. From a physical resource perspective, this configuration is efficient because it allows multiple UEs 102 to share the same PRU. To facilitate sharing of PRUs, different DMRS ports or DMRS sequences can be used for fully orthogonal DMRS for PUSCH transmission based on the selected random access preamble. When performing MsgA transmission, the DMRS port or DMRS sequence can be implicitly indicated to the physical layer. Alternatively, the DMRS port or DMRS sequence can be implicitly determined by the physical layer based on the selected random access preamble.

[0308] In one example, there is a one-to-one mapping of the DMRS ports of the preamble and MsgA, which includes code division multiplexing (CDM), frequency division (FD) orthogonal cover code (OCC), time division TD (OCC), or both FD-TD OCC. This mapping can be configured via a higher layer (e.g., RRC). MsgA transmission can be performed with transform precoding (e.g., DFT precoding). Transform precoding can be configured via a higher layer (e.g., RRC), where each PRU can be configured with or without transform precoding. For scenarios where precoding is turned off, the DMRS sequence can be based on a Zadoff-Chu sequence, which can be applicable when the number of RBs is greater than a threshold (e.g., (RB≥3)); or for low PAPR when transform precoding is turned on, which can be applicable when the number of RBs is less than a threshold (e.g., (RB<3)).

[0309] Figure 4 is an illustration of a many-to-one mapping, where a RO consists of (M+N) preambles partitioned into two preamble groups, and 4 preambles are mapped to each PRU. Similar MsgA resource selection procedures as those described for one-to-one mapping may be applied.

[0310] In an exemplary embodiment, multiple (N) SS / PBCH blocks associated with a single 2-step PRACH opportunity may be provided to the UE 102, or the SS / PBCH may be associated with multiple 2-step PRACH opportunities. The number R of contention-based preambles (distinguished by preamble ID) per 2-step PRACH opportunity is given by the higher layer parameter IE ssb-perRACH-OccasionAndCB-PreamblesPerSSB as follows:

[0311]

[0312] This disclosure proposes two options for PUSCH timing for MsgA transmission:

[0313] Option 1: PUSCH MsgA opportunities can be configured separately from PRACH opportunities, such as Figure 5 In this option, the SIB provides higher layer parameters for PUSCH MsgA opportunities and the PUSCH MsgA resource allocation can be similar to uplink transmissions with configured grants. The PUSCH MsgA configuration can be based on the following higher layer parameters

[0314] -Time domain resource allocation is timeDomainAllocation, indicating the combination of the starting codeword and length and PUSCH msgA timing

[0315] - For a given resource allocation type indicated by resourceAllocation, the frequency domain resource allocation is determined by the higher layer parameter frequencyDomainAllocation;

[0316] -MSC Level I MCS Provided by the higher layer parameter mcsAndTBS;

[0317] -The number of DM-RS CDM groups, DM-RS ports and DM-RS sequences, antenna port values, and bit values ​​for DM-RS sequence initialization are provided by antennaPort and dmrs-SeqInitialization, respectively;

[0318] - Backoff indicator: Indicates the time delay between a PUSCH msgA and the next PUSCH msgA.

[0319] - When frequency hopping is enabled, the frequency offset between two hop frequencies can be configured via the higher layer parameter frequencyHoppingOffset.

[0320] The PUSCH msgA CRC may be scrambled by the RA-RNTI, which is derived from the actual PRACH preamble transmitted in the PRACH opportunity. In addition, the UE 102 may assume that the PRACH preamble transmitted in the PRACH opportunity is quasi co-located (QCL) with the DM-RS transmitted with the PUSCH msgA opportunity.

[0321] Option 2: PUSCH MsgA timing can be configured relative to PRACH timing, such as Figure 6 As shown in . In option 2, more higher layer parameters need to be signaled, such as relative timing offset and frequency offset.

[0322] The association rule between PRACH opportunities and PUSCH MsgA opportunities may be based on the preamble index assigned in the PRACH opportunity (RO) and the number of PUSCH MsgA opportunities per PRACH opportunity. When N ≥ 1 SS / PBCH blocks are associated with a single 2-step PRACH opportunity (RO), R contention-based preambles with consecutive indices associated with SS / PBCH block n (0 ≤ n ≤ N-1) per PRACH opportunity are assigned, starting from the preamble index For example, Figure 7 As shown in , the 2-step PRACH opportunity configuration from higher layer parameters: msg1-FDM=2 (i.e., FDM for RO is 2), and ssb-perRACH-OccasionAndCB-PreamblesPerSSB=4, so The PRACH preamble index in a PRACH opportunity can be mapped to a single or multiple PUSCH msgA opportunities. The number of PUSCH msgA opportunities per PRACH opportunity is denoted as Q. Figure 7 In the example, Q is set to 2. The association rule between PRACH timing and PUSCH MsgA timing transmission can be defined as follows

[0323] The PRACH preamble index in RO is passed Assigned to PUSCH msgA opportunity, where P i Indicates the PRACH preamble index in the PRACH opportunity.

[0324] The DM-RS antenna port p and the PRACH preamble index in the PUSCH msgA opportunity (PO) association rule can be expressed as p = mod (P i ,Q).

[0325] When N < 1, a single SS / PBCH block can be associated with multiple (2-step) PRACH opportunities. In this case, the proposed association rules are still valid when N ≥ 1.

[0326] One-to-many mapping between preamble and PUSCH resource elements

[0327] For one-to-many mapping, each random access preamble in the RO can be associated with multiple PRUs. Figure 8 is an illustration of a one-to-many mapping, where a RO consists of L preambles and each preamble is mapped to M PRUs.

[0328] In an exemplary embodiment, multiple PRUs may each be associated with a different PUSCH configuration, thereby allowing the UE 102 to select a PUSCH configuration. In an exemplary embodiment, multiple PUSCH configurations corresponding to different TBS sizes are associated with each random access preamble. A threshold parameter may be used by the UE 102 to select an appropriate PUSCH configuration based on the MsgA PDU size. Alternatively, a threshold parameter based on DL signal quality or path loss may also be used. In an exemplary embodiment, the selection may be based on a triggering event.

[0329] In an exemplary embodiment, multiple PRUs may each be associated with the same PUSCH configuration, thereby facilitating FDM repetition of the MsgAPDU, which may be used to increase the reliability of the transmission. The UE 102 using such repetition may randomly select multiple PRUs from the M PRUs so as not to collide on all PRUs. For PDUs with lower reliability requirements, the UE 102 may select a single PRU from the M PRUs. For NR-U, one or more of the multiple PRUs may be associated with different subbands or BWPs, allowing the UE to select a PRU based on the result of the LBT process.

[0330] MsgA transmission

[0331] After MsgA resource selection, the UE performs MsgA transmission, which consists of preamble transmission and PUSCH transmission.

[0332] MsgA transfer can be performed as follows:

[0333] 1> if PREAMBLE_TRANSMISSION_COUNTER is greater than one; and

[0334] 1> If no notification of suspending the power ramp counter is received from the lower layer; and

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

[0336] 2>Increase PREAMBLE_POWER_RAMPING_COUNTER by 1.

[0337] 1>Select the value of DELTA_PREAMBLE, where the value of DELTA_PREAMBLE can be determined based on the preamble format;

[0338] 1>Set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower+DELTA_PREAMBLE+(PREAMBLE_POWER_RAMPING_COUNTER–1)×PREAMBLE_POWER_RAMPING_STEP;

[0339] 1> Except for the contention-free random access preamble for beam failure recovery request, calculate the RA-RNTI associated with the PRACH opportunity in which the random access preamble is transmitted;

[0340] 1> Instruct the physical layer to transmit the random access preamble using the selected PRACH opportunity, the corresponding RA-RNTI (if available), PREAMBLE_INDEX and PREAMBLE_RECEIVED_TARGET_POWER.

[0341] 1> Indicate to lower layers the PUSCH configuration for the selected PRU.

[0342] 1> If no transmission is performed for the CCCH logical channel:

[0343] 2> Instruct the multiplexing and assembly entity to include C-

[0344] RNTI MAC CE.

[0345] 1> Obtain the MAC PDU to be transmitted from the multiplexing and assembly entity and store it in the MsgA buffer.

[0346] 1> Instruct the physical layer to use the selected PRU to transmit MsgA PUSCH.

[0347] 1>Perform the MsgB reception process as described in this article.

[0348] The RA-RNTI associated with the PRACH opportunity in which the random access preamble is transmitted is calculated as:

[0349] RA-RNTI=1+s_id+14xt_id+14x80xf_id+14x80x8xul_carrier_id where s_id is the index of the first OFDM symbol of the PRACH opportunity (0≤s_id<14), t_id is the index of the first slot of the PRACH opportunity in the system frame (0≤t_id<80), where the subcarrier spacing determining t_id is based on the value of μ specified in subclause 5.3.2 in TS 38.211, f_id is the index of the PRACH opportunity in the frequency domain (0≤f_id<8), and ul_carrier_id is the UL carrier used for random access preamble transmission (0 for NUL carrier and 1 for SUL carrier). NOTE: In this example, the MsgAPUSCH power is calculated by lower layers and is related to the value signaled via the UE variable PREAMBLE_RECEIVED_TARGET_POWER. Alternatively, MsgA PUSCH may be based on its own targeted power level.

[0350] MsgB / Msg2 reception

[0351] After MsgA transmission, UE 102 monitors the response from the network within the configured window; i.e., MsgB / Msg2. If the C-RNTI MAC CE is included in MsgA, UE 102 monitors the PDCCH of the SpCell for a response addressed to the C-RNTI. The response addressed to the C-RNTI is used to signal successRAR. The successRAR may include the following fields: Contention Resolution ID; C-RNTI, UL Grant, and TA Command. The response addressed to the C-RNTI may also include an RRC message transmitted by the network in response to the CCCH message included in MsgA.

[0352] If the C-RNTI MAC CE is not included in the MsgA, the network cannot address the response to the C-RNTI. In this scenario, the response can be addressed to the RA-RNTI, where the RA-RNTI is determined based on the PRACH opportunity in which the MsgA preamble is transmitted. A separate search can be used to prevent legacy UEs from also receiving MsgA responses addressed to the RA-RNTI, which may use a new MAC PDU format that is incompatible with legacy UEs. In an exemplary embodiment, a new RNTI (e.g., msgB-RNTI) can be used in this scenario. In an exemplary embodiment, a field can be included in the DL grant DCI to indicate whether the response is for a 2-step RACH or a 4-step RACH.

[0353] UE 102 also monitors the PDCCH of the SpCell for responses addressed to the RA-RNTI; for example, Msg2. The response addressed to the RA-RNTI may be used to signal a FallBackRAR or a backoff indication. Upon receiving the FallBackRAR, UE 102 begins transmitting Msg3 of the 4-step RACH procedure. The FallBackRAR may include the following fields: RAPID, UL grant for Msg3 transmission, TC-RNTI, and TA command.

[0354] For an alternative scheme where a new RNTI (e.g., msgB-RNTI) is used for MsgB response when the C-RNTI MAC CE is not included in msgA, MsgB / Msg2 reception may be performed as follows:

[0355] 1> The ra-ResponseWindow configured in RACH-ConfigCommon starts at the first PDCCH opportunity after the end of the random access preamble transmission, as specified in TS 38.213;

[0356] 1> If C-RNTI MAC CE is included in MsgA:

[0357] 2> Monitor the PDCCH of the SpCell to obtain the PDCCH addressed to the C-RNTI.

[0358] 1> Otherwise:

[0359] 2> Monitor the PDCCH of SpCell to obtain the PDCCH addressed to msgB-RNTI

[0360] 1> While ra-ResponseWindow is running, monitor the PDCCH of the SpCell to obtain (one or more) random access responses identified by RA-RNTI.

[0361] 1> If a notification of receipt of a PDCCH transmission addressed to the SpCell of the C-RNTI is received from the lower layers:

[0362] 2> If C-RNTI MAC CE is included in MsgA:

[0363] 3> If the timeAlignmentTimer associated with the TAG of the serving cell used to transmit the random access preamble is running;

[0364] 4> If the random access response includes a UL grant:

[0365] 5>Process the received UL authorization value and indicate it to the lower layer;

[0366] 5> It is considered that MsgB is received successfully.

[0367] 5> This random access process is considered to be completed successfully.

[0368] 3> Otherwise:

[0369] 4> If the random access response includes a timing advance command;

[0370] 5> Process the received timing advance command;

[0371] 5> It is considered that MsgB is received successfully.

[0372] 5> This random access process is considered to be completed successfully.

[0373] 1> If a downlink assignment for msgB-RNTI is received on PDCCH and the MAC PDU is successfully decoded:

[0374] 2> if the Random Access Response includes a UE Contention Resolution Identity; and

[0375] 2> If the UE contention resolution identity matches the CCCH SDU transmitted in MsgA:

[0376] 3> If this random access procedure is initiated for SI request:

[0377] 4>Indicates receipt of confirmation of SI request to the upper layer.

[0378] 3> Otherwise:

[0379] 4> Set C-RNTI to the value of C-RNTI in the random access response;

[0380] 4> Apply the following actions to the serving cell that transmits the random access preamble:

[0381] 5> If the random access response includes a timing advance command;

[0382] 6>Process the received timing advance command.

[0383] 5> If the random access response includes a UL grant:

[0384] 6>Process the received UL grant value and indicate it to the lower layer.

[0385] 3> It is considered that MsgB is received successfully.

[0386] 3> This random access process is considered to be completed successfully.

[0387] 1> If a downlink assignment for RA-RNTI is received on PDCCH and the received TB is successfully decoded:

[0388] 2> If the random access response contains a MAC sub-PDU with a backoff indicator:

[0389] 3> Set PREAMBLE_BACKOFF to the value of the BI field of the MAC sub-PDU, multiplied by SCALING_FACTOR_BI, using Table 7.2-1.

[0390] 2> Otherwise:

[0391] 3> Set PREAMBLE_BACKOFF to 0ms.

[0392] 2> If the random access response contains a MAC sub-PDU, its random access preamble identifier corresponds to the transmitted PREAMBLE_INDEX.

[0393] 2> Apply the following actions to the serving cell that transmitted the random access preamble:

[0394] 3> Process the received timing advance command;

[0395] 3> Indicates preambleReceivedTargetPower and the amount of power ramp applied to the latest random access preamble transmission of the lower layer (i.e., (PREAMBLE_POWER_RAMPING_COUNTER–1)×PREAMBLE_POWER_RAMPING_STEP);

[0396] 3> Process the received UL authorization value and indicate it to the lower layer;

[0397] 3> Set TEMPORARY_C-RNTI to the value received in the random access response;

[0398] 3> Store the MAC PDU transmitted in MsgA in the Msg3 buffer.

[0399] 1> If the ra-ResponseWindow configured in RACH-ConfigCommon expires, and if a Random Access Response containing a Random Access Preamble identifier matching the transmitted PREAMBLE_INDEX has not been received, and if MsgB reception was unsuccessful:

[0400] 2> The random access response reception is considered unsuccessful;

[0401] 2>Increment PREAMBLE_TRANSMISSION_COUNTER by 1;

[0402] 2>If PREAMBLE_TRANSMISSION_COUNTER=preambleTransMax+1:

[0403] 3> If the random access preamble is transmitted on SpCell:

[0404] 4>Indicate random access problems to the upper layer;

[0405] 4> If the random access procedure is triggered by an SI request:

[0406] 5> The random access process is considered to have not been successfully completed.

[0407] 3> Otherwise, if the random access preamble is transmitted on the SCell:

[0408] 4> The random access process is considered to have not been completed successfully.

[0409] 2> If the random access process is not completed:

[0410] 3> Select a random backoff time based on a uniform distribution between 0 and PREAMBLE_BACKOFF;

[0411] 3> Perform random access resource selection process after the backoff time.

[0412] Exemplary Signaling Procedure

[0413] SR using 2-step RACH

[0414] A Scheduling Request (SR) is used to request UL-SCH resources for a new transmission. If the MAC entity does not have valid PUCCH resources configured for a pending SR, the MAC entity initiates a random access procedure on the SpCell and cancels the pending SR. In this scenario, a 2-step RACH may be used to obtain an UL grant to transmit data for the logical channel(s) associated with the BSR that triggered the SR.

[0415] In an exemplary embodiment, the MsgA PDU includes the BSR and the UE identity. Depending on the TB size associated with the MsgA PUSCH resource, a PHR may also be optionally included. Whether a 2-step RACH can be triggered for a SR may be configured by higher layers (eg, RRC) via broadcast or dedicated signaling.

[0416] The triggering of a 2-step RACH for an SR may also depend on the LCH associated with the BSR that triggered the SR. Higher layer signaling may be used to indicate which LCHs are allowed to use a 2-step RACH to trigger an SR. For example, the LogicalChannelConfig IE may include a flag to indicate whether a 2-step RACH is used to trigger an SR. In an exemplary embodiment, this may be indicated as a selection between a PUCCH or a 2-step RACH, as shown in the exemplary LogicalChannelConfig IE below. In an exemplary embodiment, whether a 2-step RACH is used to trigger an SR may be configured per logical channel group (LCG).

[0417] LogicalChannelConfig Information Element

[0418] LogicalChannelConfig Information Element

[0419]

[0420]

[0421] Fig. 9 A signaling diagram for SR using 2-step RACH is shown in . Step S900: Trigger the SR procedure in response to the arrival of UL data on the LCH that cannot be transmitted using available UL-SCH resources (if any). Step S902: UE 102 checks the LCH configuration and determines that a 2-step RACH should be triggered for the SR. Step S904: UE 102 transmits MsgA, which consists of a PDU, the PDU including the BSR that triggered the SR and the UE identity; for example, a C-RNTI MAC CE. After transmitting MsgA, the UE monitors the PDCCH for MsgB / Msg2 responses. An exemplary MsgA MAC PDU is shown in Fig.10 Step S906: UE 102 receives a MsgB response transmitted by gNB 180b, wherein the MsgB response consists of a UL grant for transmitting UL data that triggered the SR.

[0422] Handover using 2-step RACH

[0423] The random access procedure may be triggered by the RRC at synchronization reconfiguration (e.g., handover) to establish UL synchronization with the target cell. After establishing UL synchronization with the target cell, the network schedules (one or more) UL transmissions used by the UE 102 to transmit the RRCReconfigurationComplete message to complete the handover procedure. In order to reduce the latency associated with the handover procedure, a 2-step RACH procedure may be used to transmit the RRCReconfigurationComplete message.

[0424] In an exemplary embodiment, a handover command (ie, an RRCReconfigurationRequest message including a reconfigurationWithSync parameter) may be used to configure the UE 102 with a MsgA preamble and PUSCH resources for the UE 102 to transmit the RRCReconfigurationComplete message.

[0425] Request for on-demand system information using 2-step RACH

[0426] RRCSystemInfoRequest may be used to request the SI message(s) required for UE 102 to operate within the cell. To reduce the latency associated with requesting SI on demand, the RRCSystemInfoRequest message may be transmitted using a 2-step RACH procedure. Higher layer signaling (e.g., RRC signaling) may be used to indicate whether requesting SI on demand using a 2-step RACH procedure is supported in the cell. Fig.11 A signaling diagram for a request for SI on demand using 2-step RACH is shown in FIG. 100 . Step S1100 : The UE 102 sets the content of the RRCSystemInfoRequest message to indicate the SI message(s) required for the UE 102 to operate within the cell, and sets the si-BroadcastStatus to notBroadcasting for these SI messages. Step S1102 : If SI on demand using 2-step RACH is supported, the UE 102 triggers a 2-step RACH procedure, where the MsgA payload consists of the RRCSystemInfoRequest message. Step S1104 : The UE performs MsgB / Msg2 reception using the procedures described herein.

[0427] Solution for MsgA PUSCH reception by unsynchronized UEs

[0428] Distance-based open-loop timing advance value calculation

[0429] Typically, in a cellular system, a UE 102 initially acquires UL synchronization through a random access procedure during which, as part of a random access response message, the base station signals an initial timing advance value that is an absolute time advance value of the start of an uplink frame relative to the start of a corresponding downlink frame to the UE 102. The UE 102 then continues to maintain uplink synchronization with the base station through periodic UL transmissions controlled by a timing advance timer, which allows the base station to determine whether an adjustment to the timing advance is required, and if so, the base station updates the timing advance value to the UE 102 by signaling the timing advance value relative to the current timing advance value in the UE 102.

[0430] As described in the second problem to be solved above, in the 2-step RACH process, MsgA PUSCH transmission may occur before a timing advance command with an initial timing advance value is received from the base station. This will cause potential problems with MsgA reception in the base station, and in order to avoid such MsgA reception problems, a new method for determining the initial timing advance value is needed. In this subsection, the present disclosure proposes a method represented as distance-based open-loop timing advance value calculation, which can be used by the UE to autonomously determine the initial timing advance value instead of obtaining the initial timing advance value from the base station. For scenarios where the distance d between the UE and a network node (e.g., a gNB or TRP) can be estimated, the open-loop initial timing advance value T can be calculated by the UE. TA_open_loop For 2 μ For a 15kHz SCS, the open-loop initial timing advance value can be calculated in seconds as follows:

[0431]

[0432] The initial timing advance value can be expressed in units of T as follows: c Description:

[0433]

[0434] In addition, in order to reduce the T c The number of bits required for the base station to signal the initial timing advance value to the UE 102 in units of units. The initial timing advance value can be expressed in the number (16·64·T c ) / 2 μ The units are expressed as follows:

[0435]

[0436] where c is the speed of light, μ is the subcarrier configuration defined in Table 4.2-1 of [6], and T cis the basic unit time for NR defined in [6]. The initial timing advance value T in the current NR specification TS 38.213 [5] is A The possible values ​​of are 0, 1, 2, ..., 3846. The open-loop initial timing advance T A_open_loop The possible values ​​of may also be set to 0, 1, 2, ..., 3846. Alternatively, for example in the case of a large cell such as a satellite cell, the open-loop initial timing advance value may be set to a larger range of values. In another alternative, the range of open-loop initial timing advance values ​​may be set to a range of values ​​smaller than the currently specified range, for example, to support small radius cells or low-capability devices. For example, T A_open_loop The possible values ​​can be 0, 1, 2, ... (2 N -1), where N is the number of A_open_loop For example, if N = 4 bits are used, then T A_open_loop The possible values ​​are 0,1,2,…15.

[0437] The timing advance offset for the serving cell may be configured into the UE 102. The UE 102 may apply the timing advance offset specific to such serving cell to the calculated open loop initial timing advance value proposed above.

[0438] The distance d may be calculated based on an estimate of the location of the UE 102 and an estimate of the location of the network node. The UE 102 may use GPS or any other available technology to obtain an estimate of its location. For scenarios where the UE 102 is stationary, the location of the UE 102 may be preconfigured.

[0439] The location of the network node(s) may be broadcast to the UE 102 or preconfigured. For NTN, the location of the network node (e.g., satellite) may be based on satellite ephemeris. In one example, the open-loop timing advance command is applied only to PUSCH transmissions, allowing the network to calculate the timing advance command based on the received preamble. The timing advance command calculated by the network may then be signaled to the UE 102 in the MsgB / Msg2 response and applied by the UE 102.

[0440] In an exemplary embodiment, open-loop timing advance commands are applied to random access preambles and PUSCH transmissions. This solution can be applied to NTNs where the expected propagation delay is very large. Applying open-loop timing advance commands in this scenario will help align transmissions from UE 102 at the cell edge and cell center when received at a network node (e.g., satellite), thereby mitigating the impact of overlapping preamble reception windows for RO, as described in the fourth problem to be solved above. Adjustments to the current timing advance (e.g., the open-loop initial timing advance value) can be configured into UE 102 by a base station (e.g., gNB 180b). Assume that M bits are used to represent the adjustment T to the current timing advance value A_Adjustment , T A_Adjustment The possible values ​​are: 0, 1, 2, ..., (2 M -1). UE 102 may c The adjustment of the current timing advance value expressed in units of N TA_Adjustment Calculated as N TA_Adjustment =(T A_Adjustment -floor((2M-1) / 2)D·(16·64·T c ) / 2 μ In addition, the UE can use T c The new timing advance value N is TA_new Calculated as Where N TA_old is the current timing advance value in UE 102.

[0441] The accuracy of UE 102 and / or network node location estimates and / or UE mobility state may be considered when determining whether an open-loop timing advance command should be applied.For scenarios where the accuracy exceeds a threshold, UE 102 may use 4-step RACH instead of 2-step RACH.

[0442] In an exemplary embodiment, an initial adjustment to the timing advance value may be calculated by the network and provided to the UE 102 via a handover command or a conditional handover command. The UE 102 will then apply the adjustment when performing the handover. In an exemplary embodiment, the UE 102 may apply the received adjustment to a new open-loop initial timing advance value calculated relative to the target cell. In another exemplary embodiment, the adjustment may be applied to the current timing advance value relative to the source cell. The timing advance command may also indicate whether the timing advance adjustment value is applied to the current timing advance determined relative to the source cell or to the current timing advance determined relative to the target cell.

[0443] Determine timing advance based on neighboring UE timing

[0444] UE 102 may share location, distance, and / or timing advance command information with other UEs or network entities, such as with a nearby roadside unit (RSU) via a side link interface. In an exemplary embodiment, the information is shared by a UE 102 that has achieved uplink synchronization (e.g., a UE in RRC_CONNECTED) and a UE that has not yet received uplink synchronization (e.g., a UE in RRC_IDLE / RRC_INACTIVE). The information received by the unsynchronized UE may then be used by this UE 102 to determine an initial timing advance value.

[0445] In an exemplary embodiment, a UE 102 that has acquired uplink synchronization with a gNB may actively signal one or more of the following information: its (absolute) timing advance value relative to its serving cell, information about its serving cell such as the identity of its serving cell, information about the gNB controlling the serving cell (such as the identity of the gNB), location information of the synchronized UE. The signaling may be common signaling (e.g., system information broadcast signaling), or the signaling may be dedicated signaling. The signaling may be on a sidelink interface.

[0446] In an exemplary embodiment, an unsynchronized UE may signal a request for timing advance information or timing advance assistance information from a neighboring UE. For example, if there is a sidelink connection between the unsynchronized UE and the synchronized UE, such signaling may be common signaling such as broadcast signaling or dedicated signaling. The signaling may be on a sidelink interface. The request may carry one or more of the following information: the location of the unsynchronized UE, information about the serving cell of the unsynchronized UE (such as a serving cell identity), information about the gNB 180b that controls the serving cell of the unsynchronized UE (such as a gNB identity). In response to the request, the synchronized UE may signal to the unsynchronized UE one or more of the following information: its (absolute) timing advance value relative to its serving cell, information about its serving cell (such as an identity of its serving cell), information about the gNB 180b that controls the serving cell (such as an identity of gNB 180b), location information of the synchronized UE. The signaling may be common signaling (system information broadcast signaling), or the signaling may be dedicated signaling. The signaling may be on a sidelink interface.

[0447] In an exemplary embodiment, a group may be formed where a group leader acquires UL synchronization and then signals one or more of the following information using group / multicast signaling: its (absolute) timing advance value relative to its serving cell, information of its serving cell (such as the identity of its serving cell), information about the gNB 180b controlling the serving cell (such as the identity of gNB 180b), location information mobility status and / or trajectory of the group leader.

[0448] Determine timing advance based on assistance information from gNB

[0449] To assist the UE 102 in determining the initial timing advance value, the gNB 180b may broadcast assistance information. For example, a cell may broadcast a set of distance ranges (where the distance is relative to the cell center) and a mapping between the distance ranges and (one or more) potential timing advance values. Each distance range within the set of distance ranges may be defined by a minimum distance relative to the cell center and a maximum distance relative to the cell center. In an exemplary embodiment, the gNB 180b may broadcast a set of geographic regions and a mapping between those geographic regions and (one or more) potential timing advance values. In an exemplary embodiment, the gNB 180b may broadcast a set of location information and a mapping between this location information and (one or more) potential timing advance values.

[0450] UE 102 uses the received information to determine an initial timing advance value to replace the timing advance value that will be acquired through the random access procedure. In an exemplary embodiment, UE 102 may use the received value as is as the initial timing advance value. In an exemplary embodiment, UE 102 may use the received value in conjunction with a timing advance value determined based on neighboring UE timing (see the subsection entitled "Determining Timing Advance Based on Neighboring UE Timing" above), or in conjunction with an initial timing advance value based on an open loop (see the subsection entitled "Open Loop Timing Advance Value Calculation Based on Distance" above).

[0451] In an exemplary embodiment, in the case of NTN, a cell (e.g., satellite, drone, UAV, etc.) broadcasts a timing advance value that corresponds to the propagation delay between the cell and the center of the coverage area on the earth. The UE 102 can then determine its initial timing advance by calculating its distance from the center of the coverage area of ​​the cell and calculating an additional timing advance component to account for the additional propagation delay due to not being in the center of the cell's coverage area. The initial timing advance value used by the UE 102 will then be the sum of the value broadcast by the network and the compensation factor calculated by the UE 102.

[0452] Solutions for BFR Latency and Radio Resource Efficiency

[0453] In this subsection, solutions for performing BFR are provided to address issues associated with radio resource efficiency and latency that exist in the R15 BFR process in the third issue to be addressed.

[0454] BFR using 2-step RACH

[0455] In an exemplary embodiment, UE 102 is configured with a dedicated preamble for performing CF 2-step RACH when initiating a RACH procedure to perform beam failure recovery in response to beam failure detection. The MAC PDU signaled by UE 102 in MsgA includes an indication of the selected candidate beam. This indication may be signaled as a field in a MAC CE or a MAC subheader.

[0456] Alternatively, BFR may be performed using a CB 2-step RACH procedure. In this example, the UE 102 selects a random access preamble from a set of contention-based random access preambles that other UEs may use when performing a RACH procedure. The set of contention-based preambles may be used only for BFR purposes or may also be used when performing a RACH procedure initiated for other triggers. In this example, the MAC PDU signaled in MsgA by the UE 102 includes an indication of the UE identity and the selected candidate beam. The indication may be signaled in a field in the MAC CE and / or the MAC subheader.

[0457] After transmitting MsgA, UE 102 monitors the PDCCH for MsgB / Msg2 responses. Receiving a MsgB response addressed to the UE's C-RNTI is used to indicate successful completion of the 2-step BFR procedure.

[0458] Fig.12 The signaling diagram of BFR using 2-step RACH is shown in FIG.

[0459] Step S1200: Initiate a RACH procedure in response to beam failure detection.

[0460] Step S1202: The UE checks the BFR configuration and determines that a 2-step RACH procedure should be selected.

[0461] Step S1204: The UE transmits MsgA, which consists of a MAC PDU including an indication of the selected candidate beam. For the scenario of performing the CB BFR process, the MAC PDU also includes an indication of the UE identity. After transmitting MsgA, the UE monitors the PDCCH for MsgB / Msg2 responses.

[0462] Step S1206: The UE receives an MsgB response addressed to the C-RNTI of the UE transmitted by the gNB, wherein the MsgB response may include UL grant, timing advance command, etc. The MsgB response may also include signaling of parameters that are used to facilitate beam management; for example, indicating that the CSI-RS configuration is for a new beam or a candidate beam to be switched to. For example, the network may activate and deactivate the configured TCI state for the PDSCH of the serving cell by including a TCI state activation / deactivation for a UE-specific PDSCH MAC CE in the MsgB response. And in another example, the network may indicate the TCI state for PDCCH reception of the CORESET of the serving cell by including a TCI state indication for a UE-specific PDCCH MAC CE in the MsgB response.

[0463] BFR for SCell using 2-step RACH

[0464] UE 102 may perform BFR on the SCell using a 2-step RACH procedure. In this scenario, MsgA may include an indication of the cell for which BFR is being performed (e.g., a serving cell index) and an indication of the selected beam (e.g., a candidate beam RS index). UE 102 may be configured with a dedicated preamble per cell or group of cells for which UE 102 will report beam failure on the considered cell. The network will then be able to implicitly identify UE 102 based on detection of the reserved preamble(s). Alternatively, if a dedicated preamble is not used, MsgA may also include the identity of UE 102; for example, a C-RNTI MAC CE.

[0465] UE 102 may provide an indication to the network regarding a scenario where a suitable beam is not found. In an exemplary embodiment, this is implicitly indicated by not including an indication of the selected beam in MsgA. Alternatively, an explicit indication may be provided; for example, a reserved value for a candidate beam or a flag indicating whether a candidate beam is selected. And in other embodiments, UE 102 may report the best beam for a scenario where a suitable beam is not found. UE 102 may also include measurement metrics in the MsgA transmission to help facilitate beam management. For scenarios where a suitable beam is not found, the MsgB response may include an SCell deactivation command.

[0466] The process of performing BFR on SCell using two-step RACH can be defined as follows:

[0467] 1. A beam failure is detected on the cell.

[0468] 2. The UE 102 determines whether it should transmit an SR carried by the PUCCH dedicated to BFR ("dedicated SR") or MsgA.

[0469] 3. If UE 102 transmits a dedicated SR:

[0470] a. UE 102 receives a PUSCH grant.

[0471] b. UE 102 transmits a Beam Failure Recovery Request (or its second part, a dedicated SR is the first part) on PUSCH as a MAC CE or piggy-backed UCI.

[0472] c. UE 102 receive beam failure recovery response (optional)

[0473] 4. Otherwise (UE transmits MsgA):

[0474] a. UE 102 performs a 2-step RACH procedure where the beam failure recovery request (or the second part thereof, where MsgAPRACH is the first part) is included in MsgA PUSCH as a MAC CE or piggybacked UCI.

[0475] In the second step, the determination of UE 102 may be based on the UE configuration. For example, the RRC configuration of the UE (e.g., the configuration of the active UL BWP of the SpCell) determines whether a dedicated SR or MsgA should be used. In another example, the UE may determine whether a dedicated SR or MsgA should be used, for example, based on the expected latency or whether the UE is currently UL synchronized. The network response may be signaled on the SpCell or SCell.

[0476] Solution to the impact of LBT failure on NR-U's 2-step RACH

[0477] In this subsection, a process is described that may be used to address issues associated with obtaining access to an unlicensed channel for MsgA transmissions, as described in the fifth issue to be addressed above.

[0478] Channel access procedure for MsgA configuration with preamble and PUSCH with TDM

[0479] For configurations where the MsgA preamble and PUSCH are TDMed and there is a non-zero duration between the preamble and PUSCH transmissions, such as Fig.13 As shown in , the channel access procedure (i.e., LBT category) performed before PUSCH transmission can be the same as the channel access procedure (e.g., Cat4 or Cat2 LBT) performed before preamble transmission.

[0480] Alternatively, the channel access procedure performed prior to PUSCH transmission may depend on the duration of the gap. For example, for scenarios where the duration is less than a threshold, Cat1 LBT (i.e., no LBT) may be performed prior to PUSCH transmission. And for scenarios where the duration is greater than or equal to the threshold, Cat2 or Cat4 LBT may be performed. In an exemplary embodiment, the channel access procedure performed prior to PUSCH transmission may depend on the CAPC of the data being transmitted on the MsgA PUSCH or the event that triggered the random access procedure. The threshold and / or the channel access procedure to be performed prior to PUSCH transmission may be predefined; for example, specified by a standard, or configured by a higher layer (e.g., RRC) using broadcast or dedicated signaling.

[0481] If the channel access procedure performed before the preamble transmission fails, then neither the preamble nor the PUSCH is transmitted. In this scenario, an indication of the failure is provided to the MAC, and the UE variables PREAMBLE_TRANSMISSION_COUNTER and PREAMBLE_POWER_RAMPING_COUNTER are not incremented. The UE 102 returns to the MsgA resource selection and continues with another attempt to perform the MsgA transmission, such as Fig.14 as shown in .

[0482] If the preamble is transmitted but the channel access procedure performed before the PUSCH transmission fails, an indication of the failure is provided to the MAC. In this case, the UE variables PREAMBLE_TRANSMISSION_COUNTER and PREAMBLE_POWER_RAMPING_COUNTER are incremented due to the transmission of the preamble. UE 102 then performs MsgB / Msg2 reception. However, UE 102 may only monitor Msg2 because PUSCH is not transmitted. If the preamble is detected, the network responds with Msg2 including FallBackRAR, at which point UE 102 starts Msg3 transmission of the 4-step RACH procedure. If Msg2 is not received before the ra-ResponseWindow expires, the UE returns to MsgA resource selection to continue another attempt to perform MsgA transmission. Fig.15 , a diagram of a scenario where the channel access procedure for PUSCH fails and Msg2 is used to trigger fallback to the 4-step RACH procedure.

[0483] In an exemplary embodiment for a one-to-many mapping RO and PO case, the UE 102 may attempt to access the channel again before the monitoring window of MsgB starts to transmit the PUSCH in any configured PO. If the UE 102 starts monitoring MsgB, the UE 102 may attempt to transmit the PUSCH between the PDCCH monitoring opportunities in the RAR window as long as no response is received from the gNB and until the RAR monitoring window ends. For any PO, if the UE 102 fails to access the channel at the start of the PO, the UE 102 may attempt to access part of the PO based on the LBT result at the UE 102. In an exemplary embodiment, the COT obtained by the gNB 180b is for the MsgA preamble transmission, and the COT obtained by the UE 102 is for the MsgA PUSCH transmission. This allows a more aggressive channel access procedure (e.g., Cat1 or Cat2) to be performed before the MsgA preamble transmission, and a less aggressive channel access procedure (e.g., Cat4) to be performed before the PUSCH transmission, as Fig.16 as shown in .

[0484] In this example, MsgB may be transmitted during the UE acquisition of COT or the gNB acquisition of COT. For scenarios where the UE-acquired COT is used for MsgB transmission, the entire contents of MsgB may be transmitted in a single message. Alternatively, the MsgB transmission may be split into two parts. In an exemplary embodiment, MsgB is split into a first part consisting of the DFI and a second part consisting of other contents.

[0485] The indication of channel access procedure failure may be used as input to the process of detecting consistent UL LBT failures. For example, if the number of UL LBT failures exceeds a threshold within a specified time, an indication of the problem may be provided to higher layers.

[0486] Methods to prevent MsgA blocking

[0487] If the RO / PO are continuous in the time domain and there are no gaps between them, then the UE 102 attempting to access the later RO / PO may be blocked by (one or more) UEs using the earlier RO / PO, which is referred to as inter-MsgA blocking in this disclosure. In NR Release 15, if multiple ROs are configured in a RACH slot, they must be continuous with no gaps between them. To address this issue, a time gap can be introduced between consecutive RO / POs. This gap can be signaled by higher layer signaling, for example, RRC parameters such as RACH_gap. The time gap can start from the last OFDM symbol of the previous RO / PO to the first OFDM symbol of the next RO / PO.

[0488] Alternatively, if the RO / PO is continuous in the time domain without gaps, the process introduces an invalid RO / PO that may not be used by the UE 102. The invalid RO / PO falls between two other RO / POs, causing the UE 102 to select the last RO / PO that will not be blocked by the UE using the previous RO / PO. The invalid RO / PO can be signaled to the UE 102 through higher layer signaling (e.g., RRC parameters such as invalid_RO_PO set to an even or odd number). For example, if the RACH slot contains three ROs and the invalid_RO_PO is set to an even number, the first and third ROs with the RACH slot can be used, while the second RO is invalid.

[0489] Method for transmitting MsgA Preamble and PUSCH on different beams

[0490] The MsgA preamble and PUSCH may be transmitted on the same or different beams. Therefore, if the beam carrying the MsgA preamble is not available, the UE 102 may attempt to transmit the MsgA preamble again on the same beam in the RO. After a certain number of attempts, the UE 102 may attempt to transmit the MsgA preamble on a different beam even if the RO is not associated with the best SSB. The maximum number of MsgA preamble transmission attempts on the same beam may be signaled by higher layer signaling.

[0491] An exemplary embodiment of the present disclosure provides a first device (eg, UE 102) in a wireless communication system. The first device includes a circuit system (eg, processor 118, memory 130, 132, transceiver 120, etc.) (see Figure 1F ), configured to trigger a random access channel (RACH) process; select a two-step RACH process as the RACH type to be performed from multiple RACH processes; select a MsgA transmission resource; transmit MsgA; and monitor a network response from a second device (e.g., gNB 180b).

[0492] In an exemplary embodiment, the circuitry is configured to: receive a first threshold from a second device; and select a two-step RACH procedure as the RACH type based on a downlink (DL) signal quality being above the first threshold.

[0493] In an exemplary embodiment, the DL signal quality is synchronization signal-reference signal received power (SS-RSRP) or channel state information-reference signal received power (CSI-RSRP).

[0494] In an exemplary embodiment, the circuitry is configured to: select a two-step RACH procedure as the RACH type based on a logical channel associated with a scheduling request that triggered the RACH procedure; and receive a mapping between the logical channel and the RACH type from a second device.

[0495] In an exemplary embodiment, the circuit system is configured to: receive a second threshold from a second device; and select an MsgA transmission resource, wherein the selection of the MsgA transmission resource includes selecting a synchronization signal block (SSB) having an SS-RSRP higher than the second threshold.

[0496] In an exemplary embodiment, the selection of the MsgA transmission resource includes randomly selecting a random access preamble from among the random access preambles associated with the selected SSB.

[0497] In an exemplary embodiment, the selection of the MsgA transmission resource includes selecting a preamble group based on SS-RSRP, and selecting a first preamble group if the SS-RSRP is above a third threshold, and selecting a second preamble group if the SS-RSRP is equal to or below the third threshold, wherein the first device receives the third threshold from the second device.

[0498] In an exemplary embodiment, the circuitry monitors the network response, and monitoring the network response includes monitoring the network response addressed to a msgB-Radio Network Temporary Identifier (msgB-RNTI).

[0499] In an exemplary embodiment, the circuit system is configured to: receive a fourth threshold from the second device; and perform the four-step random access channel procedure when the number of unsuccessful attempts of the two-step random access channel procedure is equal to the fourth threshold.

[0500] In an exemplary embodiment, the circuit system triggers a RACH procedure, and the RACH procedure is triggered in response to beam failure detection of a serving cell (e.g., a PCell or an SCell). MsgA includes a C-RNTI medium access control element (C-RNTI MACCE). MsgA includes an indication of the selected candidate beam. The circuit system monitors a network response, and monitoring the network response includes monitoring a network response addressed to the C-RNTI.

[0501] In an exemplary embodiment, MsgA includes an indication of a cell that is performing beam failure recovery (BFR).

[0502] In an exemplary embodiment, the circuitry triggers a RACH procedure, and triggers the RACH procedure in response to a scheduling request (SR). MsgA includes a C-RNTI MAC CE and a buffer status report (BSR) that triggered the SR.

[0503] In an exemplary embodiment, the circuit system triggers a RACH procedure, and the RACH procedure is triggered in response to a handover, and MsgA includes an RRCReconfigurationComplete message. In an exemplary embodiment, the circuit system triggers a RACH procedure, and the RACH procedure is triggered in response to an on-demand system information request, and MsgA includes an RRCSystemInfoRequest message. In an exemplary embodiment, the circuit system triggers a RACH procedure, and the RACH procedure is triggered in response to a handover or beam failure detection, and the first device performs a prioritized RACH procedure using a prioritized parameter value received by the second device.

[0504] In an exemplary embodiment, the prioritized parameters include powerRampingStepHighPriority and scalingFactorBI.

[0505] In an exemplary embodiment, the circuit system transmits MsgA, and transmitting MsgA includes applying a distance-based open-loop timing advance value.

[0506] In an exemplary embodiment, the circuitry is configured to perform a channel access procedure prior to transmitting MsgA.

[0507] In an exemplary embodiment, an indication of a channel access failure is provided to a medium access control (MAC) and the variables PREAMBLE_TRANSMISSION_COUNTER and PREAMBLE_POWER_RAMPING_COUNTER are not incremented. In an exemplary embodiment, the indication of a channel access procedure failure is used to detect consistent uplink (UL) listen-before-talk (LBT) failures.

[0508] In an exemplary embodiment, a system includes a first device and a base station (e.g., gNB180b). The first device includes a circuit system configured to trigger a random access channel (RACH) procedure; select a two-step RACH procedure as a RACH type to be performed from a plurality of RACH procedures; select a MsgA transmission resource; transmit MsgA; and monitor a network response from a second device.

[0509] In an exemplary embodiment, a method performed by a first device in a wireless communication system includes: triggering a random access channel (RACH) procedure; selecting a two-step RACH procedure as a RACH type to be performed from among a plurality of RACH procedures; selecting a MsgA transmission resource; transmitting the MsgA; and monitoring a network response from a second device.

[0510] In an exemplary embodiment, the second device is in a wireless communication system. The second device includes a circuit system configured to receive MsgA from the first device; and send a network response to the first device. The first device triggers a random access channel (RACH) procedure, selects a two-step RACH procedure as a RACH type to be performed from a plurality of RACH procedures, and selects a MsgA transmission resource.

[0511] An exemplary embodiment provides a first apparatus in a wireless communication system. The first apparatus includes a circuit system configured to identify at least one of a MAC PDU size and a QoS requirement of a wireless device transmitting data in the wireless communication system, and perform a 2-step RACH procedure adapted based on at least one of the MAC PDU size and the QoS requirement.

[0512] In an exemplary embodiment, the circuitry is further configured to perform RACH type selection based on at least one of network configuration, DL radio quality, MsgA payload size, logical channel, and a status of timeAlignmentTimer.

[0513] In an exemplary embodiment, the circuitry is further configured to perform MsgA resource selection for one-to-one, many-to-one, and one-to-many mappings between preambles and PUSCH resource elements.

[0514] In an exemplary embodiment, the circuit system is further configured to perform 2-step RACH including at least one of transmission of MsgA preamble and PUSCH or reception of MsgB / Msg2.

[0515] In an exemplary embodiment, the circuitry is further configured to perform 2-step RACH as part of a beam failure recovery (BFR) operation.

[0516] In an exemplary embodiment, the circuitry is further configured to perform 2-step RACH as part of a beam failure recovery (BFR) operation of the Scell ​​using the 2-step RACH.

[0517] In an exemplary embodiment, the circuit system is further configured to identify a listen-before-talk (LBT) failure and perform a 2-step RACH using the NR-U device.

[0518] In an exemplary embodiment, the circuitry is further configured to perform a channel access procedure for a MsgA configuration with a preamble of TDM and a PUSCH.

[0519] In an exemplary embodiment, the circuitry is further configured to perform inter-MsgA blocking.

[0520] In an exemplary embodiment, the circuitry is further configured to transmit the MsgA preamble and the PUSCH on different beams.

[0521] An exemplary embodiment provides a first apparatus in a wireless communication system. The first apparatus includes circuitry configured to perform a 2-step RACH procedure in the wireless communication system, the procedure including receiving a MsgA PUSCH reception for an unsynchronized UE.

[0522] In an exemplary embodiment, the circuitry is further configured to perform the receiving after determining a distance between the unsynchronized UE and the other device by performing an open-loop timing advance value calculation.

[0523] In an exemplary embodiment, the circuitry is further configured to perform the receiving after determining the timing advance based on the neighboring UE timing.

[0524] In an exemplary embodiment, the circuit system is also configured to perform reception after determining the timing advance based on the assistance information from the gNB.

[0525] In an exemplary embodiment, the circuitry is further configured to perform 2-step RACH as part of a beam failure recovery (BFR) operation.

[0526] In an exemplary embodiment, the circuitry is further configured to perform 2-step RACH as part of a beam failure recovery (BFR) operation of the Scell ​​using the 2-step RACH.

[0527] In an exemplary embodiment, the circuit system is further configured to identify a listen-before-talk (LBT) failure and perform a 2-step RACH using the NR-U device.

[0528] In an exemplary embodiment, the circuitry is further configured to perform a channel access procedure for a MsgA configuration with a preamble of TDM and a PUSCH.

[0529] In an exemplary embodiment, the circuitry is further configured to perform inter-MsgA blocking.

[0530] In an exemplary embodiment, the circuitry is further configured to transmit the MsgA preamble and the PUSCH on different beams.

[0531] In an exemplary embodiment, a method is performed by a first device in a wireless communication system, the method comprising: identifying at least one of a MAC PDU size and a QoS requirement of a wireless device transmitting data in the wireless communication system; and performing a 2-step RACH process adapted based on at least one of the MAC PDU size and the QoS requirement.

[0532] An exemplary embodiment provides a non-transitory computer-readable storage medium having computer-readable instructions tangibly recorded thereon, which, when executed by a processing circuit system, causes the processing circuit system to perform a message service method on a network, the method comprising: identifying at least one of a MAC PDU size and a QoS requirement of a wireless device transmitting data in a wireless communication system; and performing a 2-step RACH process adapted based on at least one of the MAC PDU size and the QoS requirement.

[0533] It will be understood that any of the methods and processes described herein may be implemented in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium, and when the instructions are executed by a machine (such as a computer, server, M2M terminal device, M2M gateway device, etc.), the systems, methods, and processes described herein are executed and / or implemented. Specifically, any of the above steps, operations, or functions may be implemented in the form of such computer executable instructions. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any 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 technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other physical medium that can be used to store desired information and can be accessed by a computer.

[0534] In describing the preferred embodiments of the disclosed subject matter, as shown in the figures, specific terminology is employed for the sake of clarity. However, the claimed subject matter is not intended to be limited to the specific terminology so selected, and it should be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

[0535] Therefore, it will be appreciated by those skilled in the art that the disclosed systems and methods can be implemented in other specific forms without departing from their spirit or essential features. Therefore, the embodiments disclosed at present are considered to be illustrative rather than restrictive in all respects. It is not exhaustive and does not limit the present disclosure to the disclosed precise form. Without departing from the breadth or scope, modifications and changes are possible according to the above teachings or can be obtained from the practice of the present disclosure. Therefore, although specific configurations have been discussed herein, other configurations may also be adopted. Many modifications and other embodiments (e.g., combinations, rearrangements, etc.) are implemented by the present disclosure and are within the scope of ordinary technicians in the art and are expected to fall within the scope of the disclosed subject matter and any equivalents thereof. Within the scope of the present invention, the features of the disclosed embodiments, such as combinations, rearrangements, omissions, etc., may be combined, rearranged, omitted, etc. to produce additional embodiments. In addition, sometimes certain features may be advantageously used without correspondingly using other features. Thus, (one or more) applicants intend to include all these substitutions, modifications, equivalents, and changes within the spirit and scope of the disclosed subject matter.

[0536] Unless explicitly stated, reference to an element in the singular does not mean "one and only one," but rather "one or more." Furthermore, when a phrase similar to "at least one of A, B, or C" is used in a claim, it is intended that the phrase be interpreted to mean that A can be present alone in an embodiment, B can be present alone in an embodiment, C can be present alone in an embodiment, or any combination of elements A, B, and C can be present in a single embodiment; for example, A and B, A and C, B and C, or A and B and C.

[0537] No claim element herein is to be interpreted under 35 U.S.C. 112(f) unless the element is expressly recited using the phrase "means for..." As used herein, the term "comprise" or any other variation thereof is intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements does not include only those elements, but may include other elements not expressly listed or inherent to such a process, method, article, or apparatus. The scope of the invention is indicated by the appended claims rather than the foregoing description, and all changes within the meaning and range and equivalents thereof are intended to be embraced therein.

[0538] The following [1]-[6] are incorporated herein by reference in their entirety:

[0539] [1]3GPP TS 38.300,NR; NR and NG-RAN Overall Description; Stage 2 (15th edition), V15.6.0

[0540] [2] 3GPP TS 36.300, (E-UTRAN); Overall description; Stage 2 (15th edition), V15.6.0

[0541] [3] 3GPP TR 36.889, Study on Licensed-Assisted Access to Unlicensed Spectrum; (13th edition), V13.0.0

[0542] [4]3GPP TS 36.213,NR; Physical Layer Procedures for Control (15th edition), V15.6.0

[0543] [5]3GPP TS 38.213,NR; Physical Layer Procedures for Control (15th edition), V15.6.0

[0544] [6]3GPP TS 38.211,NR; Physical channels and modulation (15th edition), V15.6.0

Claims

1. A wireless transmit / receive unit WTRU, comprising: A processor and a memory, wherein the processor and the memory are configured to: In response to beam failure detection of the serving cell, triggering a random access channel (RACH) procedure; selecting a two-step RACH procedure as a RACH type to be performed from among a plurality of RACH procedures; receiving a first threshold from a network; Selecting an MsgA transmission resource, wherein the selecting of the MsgA transmission resource comprises selecting a synchronization signal block SSB whose synchronization signal-reference signal received power SS-RSRP is higher than a first threshold, wherein if the SS-RSRP is higher than a second threshold, the first preamble group is selected, and if the SS-RSRP is equal to or lower than the second threshold, the second preamble group is selected; transmitting an MsgA using the MsgA transmission resource, wherein the MsgA includes a cell radio network temporary identifier C-RNTI medium access control MAC control element CE and an indication of the selected candidate beam; and Monitor the network response from the network for a network response addressed to the C-RNTI.

2. The WTRU of claim 1 , wherein the processor and the memory are configured to: receiving a third threshold from the network; and The two-step RACH procedure is selected as the RACH type based on the downlink DL signal quality being higher than a third threshold.

3. The WTRU of claim 2, wherein the DL signal quality is SS-RSRP or Channel State Information-Reference Signal Received Power (CSI-RSRP).

4. The WTRU of claim 1 , wherein the processor and memory are configured to: selecting a two-step RACH procedure as the RACH type based on a logical channel associated with a scheduling request that triggered the RACH procedure; and The mapping between logical channels and RACH types is received from the network.

5. The WTRU of claim 1 , wherein the processor and memory are configured to randomly select a random access preamble from the random access preambles associated with the selected SSB to select the MsgA transmission resource.

6. The WTRU of claim 1 , wherein the processor and memory are configured to select a preamble group based on SS-RSRP to select a MsgA transmission resource, and wherein the WTRU receives a second threshold from a network.

7. The WTRU of claim 1, wherein the processor and memory are configured to monitor a network response, and monitoring the network response comprises monitoring a network response addressed to a msgB-Radio Network Temporary Identifier msgB-RNTI.

8. The WTRU of claim 1 , wherein the processor and memory are configured to: receiving a fourth threshold value from the network; and When the number of unsuccessful attempts of the two-step RACH procedure is equal to a fourth threshold, the four-step RACH procedure is performed.

9. The WTRU of claim 1, wherein MsgA includes an indication of a cell for which beam failure recovery (BFR) is being performed.

10. The WTRU of claim 1 , wherein the processor and the memory are configured to trigger a RACH procedure, and the RACH procedure is triggered in response to a scheduling request (SR), MsgA includes a buffer status report BSR that triggers the SR.

11. The WTRU of claim 1 , wherein the processor and memory trigger a RACH procedure, and the RACH procedure is triggered in response to a handover, and the MsgA includes an RRCReconfigurationComplete message; or The processor and the memory trigger a RACH process, and the RACH process is triggered in response to an on-demand system information request, and MsgA includes an RRCSystemInfoRequest message; or The processor and memory trigger a RACH procedure, and the RACH procedure is triggered in response to handover or beam failure detection, and the WTRU performs a prioritized RACH procedure using a prioritized parameter value received by the network.

12. The WTRU of claim 11, wherein the prioritized parameters include powerRampingStepHighPriority and scalingFactorBI.

13. The WTRU of claim 1, wherein the processor and memory are configured to transmit MsgA, and transmitting MsgA comprises applying a distance-based open-loop timing advance value.

14. The WTRU of claim 1, wherein the processor and memory are configured to perform a channel access procedure prior to transmitting MsgA.

15. The WTRU of claim 14, wherein An indication of a channel access failure is provided to the medium access control MAC and the variables PREAMBLE_TRANSMISSION_COUNTER and PREAMBLE_POWER_RAMPING_COUNTER are not incremented; or The indication of channel access procedure failure is used to detect uplink UL listen-before-talk LBT failure.

16. A method performed by a wireless transmit / receive unit WTRU, the method comprising: In response to beam failure detection of the serving cell, triggering a random access channel (RACH) procedure; selecting a two-step RACH procedure as a RACH type to be performed from among a plurality of RACH procedures; receiving a first threshold from a network; Selecting an MsgA transmission resource, wherein the selecting of the MsgA transmission resource comprises selecting a synchronization signal block SSB whose synchronization signal-reference signal received power SS-RSRP is higher than a first threshold, wherein if the SS-RSRP is higher than a second threshold, the first preamble group is selected, and if the SS-RSRP is equal to or lower than the second threshold, the second preamble group is selected; transmitting an MsgA using the MsgA transmission resource, wherein the MsgA includes a cell radio network temporary identifier C-RNTI medium access control MAC control element CE and an indication of the selected candidate beam; and Monitor the network response from the network for a network response addressed to the C-RNTI.

17. A wireless transmit / receive unit WTRU, comprising: A processor and a memory, wherein the processor and the memory are configured to: Triggering the random access channel RACH process; selecting a two-step RACH procedure as a RACH type to be performed from among a plurality of RACH procedures; Receive thresholds from the network; Selecting the MsgA transmission resource based on a synchronization signal block SSB whose synchronization signal-reference signal received power SS-RSRP is higher than the threshold, wherein if the SS-RSRP is higher than the threshold, the first preamble group is selected, and if the SS-RSRP is equal to or lower than the threshold, the second preamble group is selected; Using the MsgA transmission resource to transmit MsgA; as well as Monitor network responses from the network.

Images