Method implemented in a wtru for blind retransmission in non-terrestrial networks

Abstract

Methods implemented in a wireless transmit receive unit (WTRU) are described for determining additional PDCCH monitoring occasions to check for a grant for a blind Msg3 retransmission based on receiving an explicit indication of a second PDCCH monitoring, a Msg3 property, a satisfaction of an overriding condition, or one or more conditions.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 445609, filed February 14, 2023, the contents of which are incorporated herein by reference. Background Technology

[0003] In terrestrial networks, the gap between the MAC entity stopping the ra-ResponseWindow and starting the ra-ContentionResolutionTimer is typically short enough to allow for near-continuous monitoring of the PDCCH. In non-terrestrial networks (NTNs), offsetting the start of the ra-ContentionResolutionTimer significantly increases this gap, thus limiting the ability to quickly receive blind Msg3 retransmission grants after the ra-ResponseWindow stops.

[0004] The added latency means the network may not schedule blind MSG3 retransmissions until at least the WTRU-gNB round-trip time (RTT), thus limiting scheduler flexibility and increasing the latency of the RA process. Furthermore, considering RACH congestion caused by a large number of WTRUs simultaneously performing RACH, MSG3 retransmission may not always be a suitable solution in NTN, potentially imposing resource constraints on the execution of multiple consecutive retransmissions. WTRUs can always continuously monitor the PDCCH between RA windows; however, blind retransmission authorization is opportunistic, and the network may always choose not to provide one. Given that the WTRU-gNB RTT can be quite long, this can lead to additional and unnecessary WTRU power consumption.

[0005] Therefore, it may be desirable to enable blind retransmission licensed reception in less than WTRU-gNB RTT after the initial MSG3 retransmission in a non-terrestrial network, without requiring the WTRU to continuously monitor the PDCCH. Summary of the Invention

[0006] In one embodiment, a method for determining additional monitoring timing for Physical Downlink Control Channel (PDCCH) transmissions can be implemented in a Wireless Transmitter Receiver Unit (WTRU). This method may include: receiving first configuration information for performing first monitoring of a first PDCCH transmission retransmitted for a first Msg3 retransmission; receiving second configuration information for performing second monitoring of a second PDCCH transmission retransmitted for a second Msg3 retransmission; transmitting a Physical Random Access Channel (PRACH) preamble; starting a monitoring window and monitoring PDCCH transmissions of random access responses; receiving a random access response and stopping the monitoring window; transmitting at least one Msg3 based on the received random access response; monitoring the PDCCH transmissions based on the second monitoring of the PDCCH transmission retransmitted for the second Msg3 retransmission; receiving the PDCCH transmissions based on the second monitoring of the second PDCCH transmissions; and retransmitting a third Msg3 based on a grant received in the PDCCH transmission. In another embodiment, the method may include the second configuration information including an explicit indication to perform second monitoring of the PDCCH transmission retransmitted for the second Msg3 retransmission. In another embodiment, the method may include: wherein the explicit indication is received via a random access response; a PDCCH command; or SIB signaling. In another embodiment, the method may include: wherein the validity period is associated with an explicit indication indicating a time period in which the explicit indication is valid. In another embodiment, the method may include: wherein the validity region is associated with an explicit indication indicating a region in which the explicit indication is valid. In another embodiment, the method may include: wherein the explicit indication includes time period information indicating when an authorization for Msg3 retransmission is expected to be received. In another embodiment, the method may include monitoring PDCCH transmissions based on a first monitoring of a first PDCCH transmission after a second monitoring of a second PDCCH transmission; and transmitting a fourth Msg3 when the second PDCCH transmission is received. In another embodiment, the condition for performing a second monitoring of PDCCH transmissions for blind Msg3 retransmissions is based on one or more values. In another embodiment, the values ​​may include at least one of the following: WTRU distance from the cell center, satellite angle relative to the Earth, or RSRP. In another embodiment, the method may include providing these values ​​in system information, handover commands, RRC release messages, or RARs.

[0007] In another embodiment, a method can be implemented in a WTRU to determine additional timing for monitoring PDCCH transmissions. This method may include: receiving first configuration information for performing first monitoring of a first PDCCH transmission for a first Msg3 retransmission; receiving second configuration information for performing second monitoring of a second PDCCH transmission for a second Msg3 retransmission; starting a response window and monitoring PDCCH transmissions for RAR; receiving RAR and stopping the response window; transmitting at least one Msg3 based on the received RAR; determining whether to perform second monitoring of the second PDCCH transmission for the retransmission based on a Msg3 repetition characteristic or an override condition; and monitoring the second PDCCH transmission authorized for the second Msg3 retransmission in response to the satisfaction of the Msg3 repetition characteristic or the non-satisfaction of the override condition. In another embodiment, the method may include providing third configuration information via Radio Resource Control (RRC) signaling, random access messages, Media Access Control (MAC) control elements (MAC CE), paging messages, or Downlink Control Information (DCI), the third configuration information indicating whether the WTRU performs additional monitoring of blind Msg3 transmission authorization based on the Msg3 characteristic. In another embodiment, the method may include receiving the override condition via a Random Access Response (RAR), Message B (MSGB), or system information. In another embodiment, the method may include not performing a second monitoring of PDCCH transmissions if the override condition is met, regardless of the Msg3 characteristic. In another embodiment, the method may include performing either second or additional monitoring by the WTRU as a function of a predetermined number of Msg3 retransmissions.

[0008] In another embodiment, the WTRU can be configured to perform any of the methods described above. Attached Figure Description

[0009] A more detailed understanding can be obtained from the following description, given by way of example in conjunction with the accompanying drawings, wherein the same reference numerals in the drawings indicate the same elements, and wherein:

[0010] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented;

[0011] Figure 1B This illustrates that, according to an embodiment, it is possible to Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) used within a communication system shown;

[0012] Figure 1C This illustrates that, according to an embodiment, it is possible to Figure 1AThe system diagram shows an example radio access network (RAN) and an example core network (CN) used within the communication system shown.

[0013] Figure 1D This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shows another example RAN and another example CN used in the communication system shown;

[0014] Figure 2 It is a message sending and receiving diagram of a four-step contention-based random access process;

[0015] Figure 3 It is a message sending and receiving diagram of a two-step contention-based random access process;

[0016] Figure 4 This is a timing diagram for Msg3 blind retransmission license reception in a terrestrial network;

[0017] Figure 5 This is a timing diagram of Msg3 blind retransmission license reception in a non-terrestrial network;

[0018] Figure 6 This is an exemplary flowchart for additional PDCCH monitoring;

[0019] Figure 7 This is an exemplary flowchart of triggering additional PDCCH monitoring based on explicit instructions;

[0020] Figure 8 This is an exemplary flowchart of triggering additional PDCCH monitoring based on the Msg3 repeatability feature;

[0021] Figure 9 This is an exemplary flowchart of triggering additional PDCCH monitoring based on the fulfillment of conditions;

[0022] Figure 10A This is an exemplary flowchart for triggering additional PDCCH monitoring;

[0023] Figure 10B This is another exemplary flowchart for triggering additional PDCCH monitoring;

[0024] Figure 11 It is a timing diagram of the additional monitoring opportunities;

[0025] Figure 12 It is a timing diagram of the additional monitoring opportunities; and

[0026] Figure 13 It is a timing diagram of the additional monitoring opportunities. Detailed Implementation

[0027] Figure 1AThis is a diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, broadcasting, etc., to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero Tail Unique Word Discrete Fourier Transform Spread Spectrum OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and the like.

[0028] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. As examples, any of WTRUs 102a, 102b, 102c, and 102d may be referred to as a Station (STA), configured to transmit and / or receive wireless signals, and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0029] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, the Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), node Bs, eNode Bs (eNBs), home node Bs, home eNode Bs, next-generation node Bs such as gNode Bs (gNBs), new radio (NR) node Bs, site controllers, access points (APs), wireless routers, and the like. Although each of base stations 114a and 114b is depicted as a single element, it will be appreciated that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0030] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, and the like. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. Cells may provide coverage for radio services to a specific geographic area that may be relatively fixed or may change over time. Cells may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0031] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0032] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish an air interface 116. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

[0033] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-APro) to establish air interface 116.

[0034] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0035] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use the dual connectivity (DC) principle to jointly implement LTE radio access and NR radio access. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c may be characterized by transmissions to / from multiple types of base stations (e.g., eNBs and gNBs) and / or multiple types of radio access technologies.

[0036] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate Evolution of GSM (EDGE), GSM EDGE (GERAN), and the like.

[0037] Figure 1A Base station 114b can be, for example, a wireless router, a home node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a commercial location, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to the Internet 110. Therefore, it is not required that base station 114b access the Internet 110 via CN 106.

[0038] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although... Figure 1AAlthough not shown, it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to RAN 104, which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

[0040] Some or all of the WTRUs 102a, 102b, 102c, and 102d in communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, Figure 1A The WTRU 102c shown can be configured to communicate with a base station 114a that can employ cellular-based radio technology and a base station 114b that can employ IEEE 802 radio technology.

[0041] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may, among other things, include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

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

[0043] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF signals and optical signals. It should be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0044] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmit / receive elements 122. More specifically, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0045] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 may include multiple transceivers for enabling WTRU 102 to communicate via various RATs, such as, for example, NR and IEEE 802.11.

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

[0047] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

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

[0049] The processor 118 can also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functionality, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, and the like. Peripheral device 138 may include one or more sensors. Sensors may be gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, and one or more of the like.

[0050] WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with a specific subframe for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In embodiments, WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with a specific subframe for UL (e.g., for transmission) or DL ​​(e.g., for reception)) may occur concurrently and / or simultaneously.

[0051] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can use E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0052] RAN 104 may include eNode-B 160a, 160b, 160c, but will be appreciated that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. Each of eNode-B 160a, 160b, 160c may include one or more transceivers for communicating with WTRU 102a, 102b, 102c via air interface 116. In one embodiment, eNode-B 160a, 160b, 160c may implement MIMO technology. Thus, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

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

[0054] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

[0056] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, and so on.

[0057] The SGW 164 can connect to the PGW 166, which provides WTRU 102a, 102b, and 102c with access to packet-switched networks, such as the Internet, to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

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

[0059] Despite Figure 1A-1D While the WTRU is described as a wireless terminal, it is conceivable that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

[0060] In a representative embodiment, the other network 112 may be a WLAN.

[0061] In Infrastructure Basic Services Set (BSS) mode, a WLAN may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between a source STA and a destination STA (e.g., directly between the source STA and the destination STA) using Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneling DLS (TDLS). WLANs using Standalone BSS (IBSS) mode may not have access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0062] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a bandwidth of 20 MHz) or dynamically configured. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, carrier-sense multiple access (CSMA / CA) with collision avoidance can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA (e.g., each STA includes the AP) and can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0063] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels.

[0064] Very High Throughput (VHT) STAs can support wide channels of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels or by combining two non-consecutive 80MHz channels; this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segmented parser, which divides the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0065] The sub-1GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0066] WLAN systems supporting multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs supporting (e.g., only supporting) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1MHz operating mode) is transmitting to the AP, all available frequency bands can be considered busy even if most available bands remain idle.

[0067] In the United States, the available frequency bands for 802.11ah are from 902MHz to 928MHz. In South Korea, the available frequency bands are from 917.5MHz to 923.5MHz. In Japan, the available frequency bands are from 916.5MHz to 927.5MHz. Depending on the country code, the total bandwidth available for 802.11ah ranges from 6MHz to 26MHz.

[0068] Figure 1DThis is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0069] RAN 104 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 104 may include any number of gNBs while remaining consistent with the embodiments. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0070] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable numberology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute durations).

[0071] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without also accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can use signals in unlicensed frequency bands to communicate with gNBs 180a, 180b, and 180c. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate with / connect to gNBs 180a, 180b, and 180c, while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c can be used as mobility anchors for WTRU 102a, 102b, and 102c, and gNB 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRU 102a, 102b, and 102c.

[0072] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, and the like. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0073] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0074] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, and the like. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service being used by WTRU 102a, 102b, and 102c. For example, different network slices can be created for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, and so on. AMF 182a and 182b provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0075] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure the routing of traffic through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and so on. PDU session types can be IP-based, non-IP-based, Ethernet-based, and so on.

[0076] UPF 184a and 184b can be connected via an N3 interface to one or more of gNB 180a, 180b, and 180c in RAN 104. This N3 interface provides WTRU 102a, 102b, and 102c with access to packet-switched networks, such as the Internet, to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and so on.

[0077] CN 106 can facilitate communication with other networks. For example, CN 106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c may be connected to local DNs 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0078] Given Figure 1A-1D and to Figure 1A-1D The corresponding descriptions herein refer to the following: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or one or more other devices described herein. One or more of the functions described herein may be performed by one or more emulation devices (not shown). Emulation devices may be one or more devices configured to emulate one or more of the functions described herein. For example, emulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

[0079] Simulation devices can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices may perform one or more or all of their functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices may perform one or more or all of their functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing and / or performing tests using over-the-air wireless communication.

[0080] One or more simulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices may be used to test test scenarios in laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to implement the testing of one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas). The acronyms and abbreviations used in the preceding and following paragraphs may be defined as follows:

[0081] ACK confirmation

[0082] BLER block error rate

[0083] BWP bandwidth portion

[0084] CAP channel access priority

[0085] CAPC Channel Access Priority Class

[0086] CCA Clear Channel Assessment

[0087] CCE Control Channel Element

[0088] CE control elements

[0089] CG configuration authorization or cell group

[0090] CP cyclic prefix

[0091] CP-OFDM conventional OFDM (depending on the cyclic prefix)

[0092] CQI Channel Quality Indicator

[0093] CRC Cyclic Redundancy Check

[0094] CSI Channel State Information

[0095] CW Competition Window

[0096] CWS Competition Window Size

[0097] CO channel occupancy

[0098] C-RNTI community RNTI

[0099] DAI Downlink Allocation Index

[0100] DCI Downlink Control Information

[0101] DFI downlink feedback information

[0102] DG Dynamic Licensing

[0103] DL downlink

[0104] DM-RS demodulation reference signal

[0105] DRB Data Radio Bearer

[0106] eLAA Enhanced Licensing Assisted Access

[0107] FeLAA Further Enhanced Licensed Assisted Access

[0108] GEO geostationary orbit

[0109] HARQ Hybrid Automatic Repeat Request

[0110] LAA Licensed Assisted Access

[0111] LBT Listen before you speak

[0112] LEO (Low Earth Orbit)

[0113] LTE, for example, from 3GPP LTE R8 and above Long Term Evolution.

[0114] NACK (Negative)

[0115] MCS modulation and coding scheme

[0116] MIMO (Multiple Input Multiple Output)

[0117] NR New Radio

[0118] NTN non-terrestrial networks

[0119] OFDM (Orthogonal Frequency Division Multiplexing)

[0120] PDCCH (Physical Downlink Control Channel)

[0121] PDSCH (Physical Downlink Shared Channel)

[0122] PHY physical layer

[0123] PID (Process ID)

[0124] PO paging timing

[0125] PRACH (Physical Random Access Channel)

[0126] PSS Master Synchronization Signal

[0127] PUCCH (Physical Uplink Control Channel)

[0128] PUSCH Physical Uplink Shared Channel

[0129] RA (Random Access or Procedure)

[0130] RACH Random Access Channel

[0131] RAR Random Access Response

[0132] RCU Radio Access Network Central Unit

[0133] RF radio front end

[0134] RLF radio link failure

[0135] RLM radio link monitoring

[0136] RNTI Radio Network Identifier

[0137] RO RACH timing

[0138] RRC Radio Resource Control

[0139] RRM Radio Resource Management

[0140] RS reference signal

[0141] RSRP reference signal received power

[0142] RSSI Received Signal Strength Indicator

[0143] SDU Service Data Unit

[0144] SRS Detection Reference Signal

[0145] SS synchronization signal

[0146] SSS secondary synchronization signal

[0147] SWG switching interval (within a self-contained subframe)

[0148] SPS (Semi-Persistent Scheduling)

[0149] SUL supplements uplink

[0150] TB transfer block

[0151] TBS (Transfer Block Size)

[0152] TC-RNTI Temporary C-RNTI

[0153] TRP Transmit / Receive Point

[0154] TSC Time-Sensitive Communication

[0155] TSN Time-Sensitive Networking

[0156] UL uplink

[0157] URLLC: Ultra-Reliable and Low-Latency Communication

[0158] WBWP wide bandwidth portion

[0159] WLAN (Wireless Local Area Network) and related technologies (IEEE 802.xx domain)

[0160] The terms further defined herein may be referred to using a variety of different notations. In the following text, 'a' and 'one', as well as similar phrases, may be interpreted as 'one or more' and 'at least one'. Similarly, any term ending with the suffix '(s)' may be interpreted as 'one or more' and 'at least one'. The term 'may' will be interpreted, for example, as 'may'.

[0161] Random access can be performed in a contention-based manner (i.e., contention-based random access (CBRA)) and a contention-free manner (i.e., contention-free random access (CFRA)). NR supports two types of random access: four-step RA and two-step RA. The two-step RACH procedure is useful in latency-critical scenarios because it reduces the signaling exchanges required to complete the random access process.

[0162] This article references respectively Figure 2 and Figure 3 The four-step and two-step processes are described.

[0163] The four-step random access process can be implemented as follows, and as... Figure 2As shown in the diagram. At 210, the four-step random access begins with the WTRU transmitting MSG1, which contains a preamble on PRACH. During MSG1 transmission, the WTRU monitors the network for random access responses (e.g., RAR / Msg2) within a configured window. At 212, upon receiving a RAR containing UL authorization and a timing advance command, the WTRU applies the timing advance command and transmits Msg3 at 214 using the UL authorization provided in the RAR. During Msg3 transmission, the WTRU again monitors the network for responses (e.g., Msg4), which contains contention resolution information. If contention resolution is successful at 216, random access is complete and the WTRU begins connection. If contention resolution fails, the WTRU restarts random access via the transmission of Msg1, repeating step 210.

[0164] The two-step random access process can be implemented as follows and as shown in the figure. Figure 3 As shown in the diagram. Two-step random access begins with the transmission of MsgA, which includes a preamble 310 on PRACH and a payload 312 on PUSCH. After the MsgA transmission, the WTRU monitors the network response (e.g., MsgB) within a configuration window containing information about contention resolution. At 314, if contention resolution is successful, the WTRU terminates the random access procedure. If contention resolution fails and a fallback indication is provided in MsgB, the WTRU can use the UL authorization contained in the MsgB fallback indication to perform the Msg3 transmission and begin monitoring for contention resolution. If contention resolution fails again after the Msg3 transmission, the WTRU reverts to the MsgA transmission. If the MsgA transmission fails the configured number of times, the WTRU can revert to four-step random access.

[0165] When initiating a random access procedure based on network configuration, the WTRU selects which type of random access (two-step or four-step) to use. When contention-free random access resources are configured, the WTRU performs either a four-step or two-step random access procedure, depending on whether the random access resources correspond to a two-step or four-step procedure. If no contention-free random access resources are provided, the WTRU selects between four-step and two-step random access based on the RSRP threshold.

[0166] During random access preamble transmission, the MAC entity will start the ra-ResponseWindow at the PDCCH timing. While the ra-ResponseWindow is running, the WTRU can monitor the PDCCH. Upon successful RAR reception containing a random access preamble identifier that matches the transmitted PREAMBLE_INDEX, the MAC entity can stop the ra-ResponseWindow and thus monitor one or more random access responses.

[0167] like Figure 4 As shown, after the RA preamble transmission 410, ra-ResponseWindow 412, and RAR 414 or blind Msg3 retransmission grant 422, during Msg3 (re)transmission 418, 426, the MAC entity will start ra-ContentionResolutionTimer 420, 428 in the first symbol after the end of Msg3 (re)transmission 418, 426. While ra-ContentionResolutionTimer is running (420, 428), the WTRU can monitor the PDCCH. The MAC entity will stop ra-ContentionResolutionTimer if a receive notification of PDCCH transmission is received from a lower layer and the PDCCH transmission is addressed to C-RNTI or TEMPORARY_C-RNTI 430. The processing time between the reception of RAR or blind Ms3 retransmission grant is... Figure 4 The numbers are shown as 416 and 424.

[0168] To improve NR uplink coverage for both FR1 and FR2, several enhancements to MSG3PUSCH can be supported. These include: MSG3 repetition, where aggregation of multiple slots with TB repetitions for MSG3 transmission can be supported on both NUL and SUL, suitable for CBRA with 4-step RA type. If configured, when the RSRP referenced by DL path loss is below a configured threshold, the WTRU can request MSG3 repetition via a separate PRACH resource and request blind MSG3 retransmission: where the network can send a separate grant for retransmission of MSG3 before the decoding result of the initial transmission.

[0169] WTRU-gNB RTT calculation and pre-compensation in non-terrestrial networks can be implemented as follows. Due to the altitude and beam diameter of the NTN platform, the round-trip time (RTT) and maximum differential delay are significantly greater than those of terrestrial systems. In a typical NTN deployment, the RTT can vary from 25.77 ms (LEO@600km altitude) to 541.46 ms (GEO), and the maximum differential delay can vary from 3.12 ms to 10.3 ms. To minimize the impact on existing NR systems (e.g., to avoid preamble ambiguity or appropriate timing reception windows), the WTRU can perform timing pre-compensation before initial access. The timing pre-compensation process requires the WTRU to obtain its position via GNSS and the feeder link (or common) delay and satellite position via satellite ephemeris data. Satellite ephemeris data is periodically broadcast in system information and includes satellite velocity, orientation, and speed. The WTRU can then estimate the distance to the satellite (and therefore the delay), and then add the feeder link delay component to obtain the full WTRU-gNB RTT, which is then used for the offset timer, receive window, or timing relationship.

[0170] Adapting PDCCH monitoring for non-terrestrial networks can be achieved as follows: PDCCH monitoring during random access can be modified for non-terrestrial networks by adjusting the start offset of ra-ResponseWindow, msgB-ResponseWindow, and ra-ContentionResolutionTimer to WTRU-gNB RTT. This ensures that ra-ResponseWindow and ra-ContentionResolutionTimer do not expire prematurely due to the long propagation delay characteristics of non-terrestrial networks.

[0171] Adaptation for MSG3 coverage enhancement on non-terrestrial networks can be implemented as follows. For NTN, two Msg3 coverage enhancement techniques can be supported. For example, type A PUSCH repetition is supported by starting ra-ContentionResolutionTimer in the first symbol after the end of all Msg3 repetitions plus the WTRU-gNB RTT. Blind Msg3 retransmission is supported if a PDCCH addressing a TC-RNTI indicating UL authorization for Msg3 retransmission is received after the start of ra-ContentionResolutionTimer, then ignoring the expiration of ra-ContentionResolutionTimer.

[0172] like Figure 4As shown, in the terrestrial network, the gap 416 between the MAC entity stopping 414ra-ResponseWindow 412 and starting ra-ContentionResolutionTimer 420 is typically very short, allowing for near-continuous monitoring of the PDCCH. Figure 5 The beginning 520 of ra-ContentionResolutionTimer 522 in NTN is offset, which significantly increases the gap including processing time 514 and additional time 518, thereby limiting the ability to quickly receive blind Msg3 retransmission authorization after ra-ResponseWindow 510 stops 512.

[0173] The added delay means the network may not schedule blind MSG3 retransmissions until at least the WTRU-gNB RTT, thus limiting scheduler flexibility and increasing the latency of the RA process. Furthermore, considering RACH congestion caused by a large number of WTRUs simultaneously performing RACH, MSG3 retransmission may not always be a suitable solution in NTN, which could impose limitations on the resources required to perform multiple consecutive retransmissions.

[0174] WTRU can continuously monitor WTRUs between RA windows; however, blind retransmission authorization 422 is opportunistic, and the network may always choose not to provide one. Considering that WTRU-gNB RTT 518 can be quite long, this can lead to additional and unnecessary WTRU power consumption.

[0175] In the embodiment, the general solution components supporting blind MSG3 retransmission enhancement in non-terrestrial networks are... Figure 6 The diagram schematically illustrates, and may include, for example,: a preamble transmission 610, which may optionally indicate WTRU coverage conditions (e.g., partitions from the preamble index or RACH timing); a trigger condition 612 for performing additional PDCCH monitoring for blind retransmission grant reception; an optional configuration 614 for the WTRU to exceed the additional monitoring timing triggered by 620 based on an exceedance decision 616; and additional PDCCH monitoring 618 for blind MSG3 retransmission grant reception. The following is an exemplary description of embodiments in which these component solutions can be combined.

[0176] As used herein, the term "fast blind MSG3 retransmission grant reception" refers to the reception of a retransmission grant prior to the WTRU-gNB RTT after the initial Msg3 transmission. The solution described herein can be applied to any device operating in non-terrestrial networks (e.g., NTNWTRU, VSAT terminals, NB-IoT and / or eMTC devices) or in other network deployments with large WTRU-gNB RTTs.

[0177] The embodiments described herein are primarily intended for additional PDCCH monitoring timing following the initial MSG3 transmission in non-terrestrial networks. However, the embodiments described herein can also be applied to blind retransmission license reception that supports transmissions other than MSG3 transmissions (e.g., other RRC messages or even user plane data).

[0178] Channel conditions can refer to any condition related to the state of the radio / channel, which can be determined by the WTRU from the following: WTRU measurements (e.g., L1 / SINR / RSRP, CQI / MCS, channel occupancy, RSSI, headroom, exposure margin), L3 / mobility-based measurements (e.g., RSRP, RSRQ), RLM status, and / or channel availability in unlicensed spectrum (e.g., determining whether a channel is occupied based on LBT).

[0179] In this document, PRACH resources refer to PRACH resources (e.g., in frequency), PRACH timing (RO) (e.g., in time), preamble format (e.g., in terms of total preamble duration, sequence length, guard duration, and / or the length of the cyclic prefix), and / or a preamble sequence used to transmit a preamble during random access.

[0180] The nature of the scheduling information (e.g., uplink grant or downlink allocation) may include, for example, at least one of the following: frequency allocation; one aspect of time allocation, such as duration; priority; modulation and coding scheme; transport block size; number of spatial layers; number of transport blocks to be carried; TCI status or SRI; number of repetitions; and whether the grant is a configured grant type 1, type 2, or dynamic grant.

[0181] For example, indications or indications via DCI may include at least one of the following: explicit indications via DCI fields or via RNTI for CRC used to mask PDCCH; implicit indications via properties such as DCI format, DCI size, core set or search space, aggregation level, identifier of the first control channel resource for DCI (e.g., index of the first CCE), wherein the mapping between properties and values ​​can be signaled via RRC or MAC; and explicit indications via DL MAC CE.

[0182] The embodiments provided herein address the following considerations: WTRU power savings (i.e., ensuring that the WTRU performs additional monitoring only when blind retransmission authorization is expected); the expected limited ability to signal / indicate blind retransmission authorization due to limited opportunities for DL ​​signaling; the WTRU coverage scenario can vary greatly due to cell size in the NTN, which can complicate broadcast signaling; and different scenarios (e.g., two-step RACH backoff, RACH in CONN for idle / inactive, IoTNTN for NRNTN, priority of access attempts, number of failed RACH attempts, distance from cell center, etc.) may require differentiated WTRU behavior.

[0183] The following common benefits can be derived from the embodiments described herein: allowing the WTRU to perform limited additional PDCCH monitoring during random access; allowing trade-offs between WTRU power consumption and network scheduler flexibility. This ensures that the WTRU monitors blind MSG3 retransmission grants only when blind MSG3 retransmission grants are anticipated or in scenarios where blind MSG3 retransmission grants are most needed.

[0184] In some embodiments, the WTRU may use one or more of the solutions described below to indicate one or more of the following: the WTRU supports additional monitoring of enhanced blind MSG3 retransmission (e.g., the WTRU supports this as a WTRU capability); the WTRU is in a coverage-limited scenario (e.g., the WTRU may benefit from additional coverage enhancements, such as additional blind MSG3 retransmission); and the WTRU may perform additional monitoring of blind MSG3 retransmission authorization; the WTRU may request additional blind MSG3 retransmission authorization.

[0185] WTRUs can report capabilities and / or coverage characteristics via implicit indication of their ability to perform enhanced blind MSG3 retransmission. WTRUs can request, indicate their capabilities, coverage scenarios, or the additional monitoring they will perform on enhanced blind MSG3 retransmission via implicit indication, whereby the WTRU may use a specific PRACH preamble during the RA procedure. The preamble may be within a set of PRACH preambles reserved for / associated with such WTRUs.

[0186] A WTRU can request, indicate, its capabilities, its coverage scenario, or its intention to perform additional monitoring for enhanced blind MSG3 retransmissions via implicit indication. The WTRU can send a PRACH at a specific random access timing (e.g., within a set of RACH timings reserved for such a WTRU / associated with such a WTRU). The WTRU can also request, indicate, its capabilities, its coverage scenario, or its intention to perform additional monitoring for enhanced blind MSG3 retransmissions via implicit indication, where the WTRU may use a combination of PRACH preambles and random access timings.

[0187] The WTRU can request, indicate its capabilities, its coverage scenarios, or its intention to perform additional monitoring of enhanced blind MSG3 retransmission via implicit indication, wherein the WTRU can send a PRACH preamble more than once (e.g., twice) to indicate its support for opportunistic blind Msg3 retransmission, such as in more than one RO (e.g., a specific combination) or using more than one preamble to send preamble transmission.

[0188] The WTRU can report capabilities and / or coverage characteristics by explicitly indicating its capabilities for enhanced blind MSG3 retransmission, whereby the WTRU can send the indication to the network via explicit signaling (e.g., via RRC, MAC CE, UCI, RACH messages). Explicit indications can be flags (e.g., indicating that the WTRU supports additional monitoring authorized for blind MSG3 retransmission), fields indicating one or more aspects (e.g., the WTRU is in a coverage-limited scenario and supports additional monitoring), or indexes pointing to one or more pre-configured meanings. In one example, the WTRU can include the indication within a RACH message, such as within an MSGAPUSCH resource. For example, the WTRU can indicate that it supports additional blind MSG3 retransmission and / or will perform additional monitoring if the WTRU may fall back to a four-step RACH. In another example, the WTRU can include the indication via RRC signaling, such as within a WTRU capability transmission (e.g., during connection to an RRC connection mode). The WTRU can apply the indicated behavior, for example, for subsequent random access procedures. In another solution, the WTRU can include this information within a WTRU information response message (e.g., in response to a WTRU information request message).

[0189] WTRUs can report capability and / or coverage characteristics via conditional indications for enhanced blind MSG3 retransmission capabilities, whereby the WTRU can send the indication to the network based on its power / battery level. For example, a WTRU with this capability but a full battery (or, for example, currently charging) can avoid sending the indication. In another example, the WTRU can send one indication associated with a range of one power level, and another indication associated with a range of another power level, and so on.

[0190] The WTRU can report capability and / or coverage characteristics through conditional indications for enhanced blind MSG3 retransmission capabilities, where the WTRU can send indications based on whether its coverage is limited. For example, the WTRU may include indications and / or select PRACH partitions associated with limited coverage in one or more of the following scenarios: Determination of coverage based on measurement / signal level: if the serving cell's signal level (e.g., RSRP) is below a certain level, but this can be avoided if the serving cell's signal level is above a certain level. The WTRU may send one indication associated with one range of the serving cell's signal level, and another indication associated with another range of the serving cell's signal level, and so on.

[0191] The WTRU can report capability and / or coverage characteristics through conditional indications for enhanced blind MSG3 retransmission capability, wherein this can be avoided if the WTRU's location (e.g., acquired via GNSS) is above a threshold distance from the serving satellite, but if the serving cell's signal level is above a certain level.

[0192] In another embodiment, the WTRU may send an indication to the network based on its mobility state. For example, if the WTRU is in a high mobility state, it may include the indication, but otherwise avoid doing so. In another example, the WTRU may send one indication associated with a low mobility state, another indication associated with a medium mobility state, another indication associated with a high mobility state, and so on.

[0193] In another embodiment, the WTRU can send an indication based on an indication received in broadcast signaling. For example, the network can enable blind MSG3 retransmission by including an indication in a system information block, and if the WTRU receives this indication, the WTRU can send a capability indication. In some examples, the network can indicate the type of blind retransmission enabled (e.g., a different operating mode or different parameters), and the WTRU can determine whether it supports the indicated type and, based on this determination, can send a capability indication. In some examples, the presence of any type of configuration information related to blind Msg3 retransmission is used to implicitly determine whether the network has enabled the feature and whether the WTRU can send a capability indication.

[0194] Additional PDCCH monitoring for enhanced blind MSG3 retransmission grant reception can be predefined, configured by the network, and / or explicitly indicated. Such configuration can be used to support one or more solutions described herein and may include one or more of the following: the preamble or RACH timing associated with such capability, and any dependencies on previously described coverage limitations, battery levels, or mobility states, etc.; instructions for performing additional monitoring of blind MSG3 retransmissions (e.g., enable / disable configuration); a mapping between characteristics of MSG3 retransmission behavior and additional monitoring of blind MSG3 retransmissions; conditions for performing additional blind MSG3 retransmissions (e.g., associated thresholds and / or threshold ranges); whether additional monitoring is performed based on failure conditions (e.g., the number of transmission attempts prior to requiring additional monitoring after a two-step RACH fallback to a four-step RACH, etc.); conditions exceeding the additional monitoring of blind MSG3 retransmission grants (e.g., thresholds, disable timer duration); and / or characteristics of how additional monitoring should be performed (e.g., start, duration, periodicity).

[0195] The WTRU can be configured to monitor (receive) the PDCCH during a set of timings during a random access procedure. The WTRU can determine the set of PDCCH monitoring timings by monitoring according to a DRX configuration for random access, wherein, in an embodiment, the WTRU can determine this set of PDCCH monitoring timings based on at least one DRX configuration and operation. This DRX configuration may be referred to as the DRX for random access. The WTRU can receive parameters for at least one of the following: a DRX enable duration timer, a DRX inactivity timer, a DRX long period and start offset, a DRX short period, a DRX slot offset, and so on. The WTRU can monitor the PDCCH while at least one of the DRX enable duration timer or the DRX inactivity timer is running. The WTRU can restart the inactivity timer upon receiving a PDCCH scrambled with TC-RNTI.

[0196] The WTRU can determine the set of PDCCH monitoring opportunities by monitoring according to a time pattern, wherein, in an embodiment, the WTRU can determine the set of PDCCH monitoring opportunities based on a configured time pattern. The time pattern can include a repeating sequence of durations alternating between periods when the WTRU monitors the PDCCH (on duration) and periods when the WTRU does not monitor the WTRU (off duration). For example, the sequence can include two slots for the on duration, followed by twelve slots for the off duration. Such a sequence can be indicated by a bitmap, where each bit corresponds to a duration (e.g., a slot), and the value of the bit indicates whether the duration is an on duration or an off duration. Alternatively, such a sequence can be indicated by a time offset (duration) between a slot, subframe, and / or symbol boundary and the start and duration of the on duration period. The configuration can also include periodicity of pattern repetition.

[0197] The WTRU can determine the set of PDCCH monitoring opportunities through configured signaling, whereby the WTRU can receive the value of at least one parameter of the configuration for PDCCH monitoring from RRC, MAC, or DCI signaling. The WTRU can receive multiple configurations for PDCCH monitoring, each identified by an index, and receive an indication of the applicable configuration from the signaling. A configuration may correspond to each possible monitoring opportunity, e.g., each time slot, in which the WTRU monitors the PDCCH. The configuration may be specific to one or more of, for example, the following: cell (e.g., serving cell); a set of cells; satellite; and orbit or orbit classification (e.g., GEO or LEO). For example, the WTRU can determine at least one value based on system information, based on dedicated RRC messages (RRC reconfiguration, RRC connection release), based on fields of Random Access Response (RAR) messages, or based on the nature of RAR authorization. For example, the WTRU can determine the values ​​of periodicity, on-duration, and / or configuration index based on multiple most or least significant bits of the Modulation and Coding Scheme (MCS) field, or based on the Time Domain Resource Allocation (TDRA) field, or based on the Backoff Indicator (BI) field. The mapping between bits and their corresponding values ​​can be predefined, or it can be signaled by the RRC.

[0198] When the WTRU determines the set of PDCCH monitoring opportunities through configured signaling, the WTRU can determine the value of at least one parameter or configuration index based on one or more of the same conditions used to determine the number of preambles or preamble repetitions. For example, the WTRU can determine the value of the configuration index based on path loss estimates or RSRP measurements performed on resources such as SSBs.

[0199] When the WTRU determines the set of PDCCH monitoring opportunities through signaling configured as described above, at least one parameter or configuration index can be determined from a combination of the solutions described above. For example, the WTRU can first determine a set of possible configuration index values ​​associated with preamble selection and then determine the applicable configuration index value from that set based on fields in the RAR.

[0200] The WTRU can determine the set of PDCCH monitoring opportunities by updating the configuration upon DCI reception or based on the number of Msg3 repeats / retransmissions. In an embodiment, the WTRU can update the value of at least one parameter based on received DCIs, such as those addressed to the TC-RNTI. For example, the WTRU can apply a first PDCCH monitoring configuration upon receiving a RAR and a second PDCCH monitoring configuration upon receiving a DCI addressed to the TC-RNTI. The WTRU can update this value based on information from both the DCI addressed to the TC-RNTI and the DCI containing the RAR. For example, if the MCS indicated in the RAR is higher than the MCS indicated in the DCI addressed to the TC-RNTI, the WTRU can apply the first PDCCH monitoring configuration upon receiving the RAR and the second PDCCH monitoring configuration upon receiving the DCI addressed to the TC-RNTI. In an embodiment, the WTRU can update the value of at least one parameter or configuration index when the number of Msg3 repeats and / or retransmissions reaches a configured or predefined threshold. For example, if the number of Msg3 repeats or retransmissions exceeds 32, the WTRU can monitor the WTRU at every possible monitoring opportunity (e.g., in each time slot).

[0201] The WTRU may apply PDCCH monitoring mode when one of the following occurs: reception of RAR; or the start (or end) of the initial transmission of Msg3 PUSCH. In an embodiment, the WTRU may stop applying PDCCH monitoring mode when at least one of the following occurs: successful contention resolution; reception of PDCCH for C-RNTI; the number of Msg3 PUSCH repetitions and / or retransmissions reaches a predefined or configured threshold; RRC signaling indicating the applicable DRX configuration (e.g., connection establishment or reconfiguration); and / or after a configured or predefined period of time since the WTRU began applying monitoring mode.

[0202] In an embodiment, the network configuration / configuration indicated by the network can be received along with the first message and can then be enabled / disabled via NW signaling (e.g., MAC CE, DCI, SIB, RRC, RACH messages, etc.) in the second message.

[0203] The WTRU can receive instructions from the network regarding the timing / period of additional PDCCH monitoring to check the authorization of blind Msg3 retransmissions. The WTRU then performs PDCCH monitoring during the indicated timing / period following the initial transmission of Msg3.

[0204] The WTRU can receive instructions from the network regarding the timing / period of additional PDCCH monitoring to check the authorization of blind Msg3 retransmissions, wherein the WTRU can receive configuration for the first PDCCH monitoring (e.g., normal PDCCH monitoring) for blind MSG3 retransmissions.

[0205] The WTRU can receive from the network an indication of when / period of additional PDCCH monitoring to check the authorization of blind Msg3 retransmissions. The WTRU can receive configuration information associated with performing a second PDCCH monitoring (e.g., additional PDCCH monitoring) for blind MSG3 retransmission authorization reception, or an indication (e.g., explicit indication) to perform a second PDCCH monitoring (e.g., additional PDCCH monitoring) for blind MSG3 retransmission authorization reception. In the example, the second PDCCH monitoring can be performed before the first PDCCH monitoring. (The configuration information or indication may be provided in, for example, system information, RRC release messages, handover commands, and / or RACH configurations. The configuration information or indication may include when and / or how to perform the second PDCCH monitoring (e.g., starting a new timer for X ms to monitor periodically, starting monitoring at a Z offset from RAR reception or MSG3 transmission)).

[0206] The WTRU can receive indications from the network regarding the timing / period of additional PDCCH monitoring to check the authorization for blind Msg3 retransmissions, wherein the WTRU can optionally select and transmit a PRACH preamble. The preamble can optionally be segmented, and the WTRU can optionally indicate a preamble for at least one of the following: the WTRU is in a coverage-limited scenario; the WTRU supports and / or will perform a second (e.g., additional) PDCCH monitoring; and a request for authorization for blind retransmissions based on or using the second (e.g., additional) PDCCH monitoring.

[0207] The WTRU can receive instructions from the network regarding the timing / period of additional PDCCH monitoring to check the authorization of blind Msg3 retransmissions, whereby the WTRU can start a ra-ResponseWindow and monitor the PDCCH of random access responses.

[0208] The WTRU can receive indications from the network regarding the timing / period of additional PDCCH monitoring to check the authorization of blind Msg3 retransmissions, wherein the WTRU can receive a random access response and stop the ra-ResponseWindow. In an example embodiment, the random access response may include an indication (e.g., an explicit indication) to perform a second (e.g., additional) PDCCH monitoring for blind MSG3 retransmission authorization. This indication may, for example, activate the WTRU based on configuration information or instruct the WTRU to perform a second PDCCH.

[0209] The WTRU can receive indications from the network regarding the timing / period of additional PDCCH monitoring to check the authorization for blind Msg3 retransmissions, wherein the WTRU can transmit at least one MSG3 based on a received RAR (e.g., based on the UL authorization received in the RAR).

[0210] The WTRU can receive indications from the network regarding additional PDCCH monitoring timing / periods to check authorization for blind Msg3 retransmissions. The WTRU can monitor the PDCCH during the monitoring timing based on received configurations and / or indications for second PDCCH monitoring for authorization of blind MSG3 retransmissions. In embodiments, these can be at a second or additional timing.

[0211] The WTRU can receive an indication from the network regarding the timing / period of additional PDCCH monitoring to check the authorization for blind Msg3 retransmissions, wherein when the WTRU receives a PDCCH based on a second PDCCH monitoring, the WTRU retransmits at least one MSG3 based, for example, on the authorization received in the PDCCH (e.g., in the DCI carried by the PDCCH).

[0212] The WTRU can receive instructions from the network regarding the timing / period of additional PDCCH monitoring to check the authorization of blind Msg3 retransmissions, wherein, after monitoring the PDCCH based on the second PDCCH monitoring, the WTRU can monitor the PDCCH based on the first PDCCH monitoring, and transmit at least one MSG3 when a PDCCH is received (e.g., with UL authorization).

[0213] In an embodiment, the WTRU may receive explicit indications via, for example, one or more of the following: a random access response (e.g., msg2); a PDCCH command; SIB signaling (e.g., SIB19, SIB31, and / or SIB32); a paging message (e.g., CN paging, RAN paging, etc.) which, for example, when the WTRU is idle / inactive; a handover command (e.g., within the reconfigurationWithSyncIE of an RRC reconfiguration message); an RRC release message when the WTRU transitions from a connected state to an idle / inactive state; or an RRC reconfiguration message that indicates the arrival of DL data to the WTRU when it is neither a HO command nor an RRC release.

[0214] In one embodiment, the WTRU may receive an explicit instruction, wherein the WTRU may be configured to use the received instruction / configuration only if it transitions to a connected state within the validity period.

[0215] In an embodiment, the WTRU may receive an explicit indication, wherein a valid region (e.g., a list of cells, frequencies, etc.) may be associated with the indication. For example, the WTRU may use the indication only if it has not yet performed cell reselection outside the valid region.

[0216] In an embodiment, the WTRU may receive an explicit indication, which includes exact timing information (e.g., exact frame / slot, etc.) when an authorization for Msg3 retransmission is expected to be received in the PDCCH.

[0217] In an embodiment, the WTRU may receive an explicit indication that includes a time window for the expected receipt of a Msg3 retransmission in the PDCCH (e.g., between frames / slots n and m, between times t1 and t2, etc.). In one solution, the indication may include timing information for the authorization of multiple retransmissions. For example, the indication may include periodicity information (e.g., the expected authorization every n frames / slots since the indication was received or some other point in time). For example, the indication may be aperiodic or quasi-periodic (e.g., the expected authorization at t1, t2, t3, etc., where the durations between t1 and t2 and between t2 and t3 are different).

[0218] In an embodiment, the WTRU may receive explicit indications, which may be agreed-upon configurations depending on the indications received from the WTRU regarding the WTRU's capabilities and conditions / requirements. For example, for a specific PRACH preamble or PRACH timing used by the WTRU (as described herein, which may depend on the WTRU's capabilities / conditions / requirements), the WTRU will know when to monitor the PRACH for a license used for MSG3 retransmission. The WTRU may be pre-configured with this mapping between indications from the WTRU and the PDCCH monitoring timing / duration / window for MSG3 (e.g., mappings specified in 3GPP standards, SIBs, RRC signaling, mapping indications in MAC signaling, etc.).

[0219] Below and about Figure 7 The exemplary flowchart further illustrates the above embodiments, in which additional PDCCH monitoring is triggered by explicit indication and / or configuration.

[0220] At 710, the WTRU receives the configuration for the first PDCCH monitoring (e.g., normal PDCCH monitoring) for MSG3 retransmission.

[0221] At 712, the WTRU receives configuration information associated with performing a second PDCCH monitoring (e.g., supplementary PDCCH monitoring) for blind MSG3 retransmission grant reception, or an indication (e.g., explicit indication) to perform a second PDCCH monitoring (e.g., supplementary PDCCH monitoring) for blind MSG3 retransmission grant reception, wherein, in the example, the second PDCCH monitoring may be performed before the first PDCCH monitoring. The configuration information or indication may be provided, for example, in system information, RRC release messages, handover commands, and / or RACH configurations. The configuration information or indication may include when and / or how to perform the second PDCCH monitoring (e.g., starting a new timer for X ms, monitoring at a certain periodicity, or starting monitoring at the Z offset from RAR reception or MSG3 transmission).

[0222] At 714, the WTRU selects and transmits a PRACH preamble. The preamble may optionally be segmented, and the WTRU may optionally indicate a preamble that represents at least one of the following: the WTRU is in a coverage-limited scenario; the WTRU supports and / or will perform a second (e.g., additional) PDCCH monitoring; and a request for blind retransmission authorization based on or using the second (e.g., additional) PDCCH monitoring.

[0223] At 716, WTRU starts the ra-ResponseWindow and monitors the PDCCH for random access responses.

[0224] At 718, the WTRU receives the random access response and stops the ra-ResponseWindow. In the example, the random access response may include an indication (e.g., an explicit indication) to perform a second (e.g., additional) PDCCH monitoring for blind MSG3 retransmission authorization. This indication may, for example, activate the WTRU based on configuration information or instruct the WTRU to perform a second WTRU.

[0225] At 720, the WTRU transmits at least one MSG3 based on the received RAR (e.g., based on the UL authorization received in the RAR).

[0226] At 722, WTRU monitors the PDCCH at the monitoring time based on the received configuration and / or instruction for the second PDCCH monitoring (e.g., at the second or additional timing) for blind MSG3 retransmission authorization.

[0227] At 724, when the WTRU receives a PDCCH based on the second PDCCH monitoring, the WTRU retransmits at least one MSG3 based, for example, on the authorized retransmission received in the PDCCH (e.g., in the DCI carried by the PDCCH).

[0228] In an embodiment, at 726, after monitoring the PDCCH based on the second PDCCH monitoring, the WTRU monitors the PDCCH based on the first PDCCH monitoring, and transmits at least one MSG3 when the PDCCH is received (e.g., with UL authorization).

[0229] The WTRU can perform additional PDCCH monitoring triggered based on the Msg3 repetition feature, specifically for enhanced blind MSG3 retransmission authorization. The WTRU's behavior can vary depending on whether it is performing random access during RRC idle / inactive periods or within an RRC connection.

[0230] In this embodiment, the WTRU can perform additional PDCCH monitoring triggered by the Msg3 repetitive characteristic, such as... Figure 8As shown in the diagram. At 810, the WTRU receives configuration for first PDCCH monitoring (e.g., normal PDCCH monitoring) for MSG3 retransmission. At 812, the WTRU receives configuration information associated with performing second PDCCH monitoring (e.g., supplementary PDCCH monitoring) for blind MSG3 retransmission authorization reception, wherein, in this example, the second PDCCH monitoring may be performed before the first PDCCH monitoring. At 814, the WTRU selects and transmits a PRACH preamble. The preamble may optionally be segmented, and the WTRU may optionally select a preamble indicating at least one of the following: the WTRU is in a coverage-limited scenario; the WTRU supports and / or will perform second (e.g., supplementary) PDCCH monitoring; a request for blind retransmission authorization based on or using the second (e.g., supplementary) PDCCH monitoring. At 816, the WTRU starts the ra-ResponseWindow and monitors the PDCCH for random access responses. At 818, the WTRU receives a random access response (RAR) indicating MSG3 retransmission and stops the ra-ResponseWindow. The number of MSG3 repetitions to be performed can be indicated by or determined based on the content of the RAR and / or can be based on the received configuration. At 820, the WTRU transmits at least one MSG3 based on the received RAR (e.g., based on the UL authorization received in the RAR). At 822, the WTRU determines whether to perform a second (e.g., additional) PDCCH monitoring for blind MSG3 retransmissions based on at least one MSG3 repetition characteristic and / or overrun conditions. In an embodiment, the MSG3 characteristic is the number of MSG3 repetitions configured or indicated. The relationship between performing a second (e.g., additional) PDCCH monitoring and the number of MSG3 repetitions can be predefined, configured (e.g., in RACH configuration, RRC release messages, or HO commands), or indicated, for example, in system information or the RAR. In an example, this relationship can be identified to perform a second PDCCH monitoring when the number of MSG3 repetitions is higher or lower than a defined or configured value or threshold. In an embodiment, overrun conditions can be configured. The exceeding condition can be based, for example, on RSRP or a distance threshold (e.g., provided in SIB, RRC messages, RRC releases, etc.) and, for example, when RSRP is higher than the RSRP threshold and / or (e.g., from the WTRU) the distance to the satellite is within a distance threshold (e.g., X km) (e.g., below the distance threshold (e.g., X km)). If this condition is met, the WTRU does not perform a second (e.g., additional) PDCCH monitoring.

[0231] If the MSG3 repetition characteristic indicates the need for a second (e.g., additional) monitoring, and / or an optional overriding condition is not met, then at 824, the WTRU monitors the PDCCH during the monitoring timing (e.g., based on the received configuration) for a second PDCCH monitoring authorized for blind MSG3 retransmission (e.g., during the second or additional timing). When the WTRU receives the PDCCH based on the second PDCCH monitoring, at 826, the WTRU retransmits at least one MSG3 based on the authorization received in the PDCCH (e.g., PDCCH DCI). In another embodiment, at 828, after monitoring the PDCCH based on the second PDCCH monitoring, the WTRU monitors the PDCCH based on the first PDCCH monitoring, and transmits at least one MSG3 when a PDCCH with UL authorization (e.g., PDCCH DCI) is received.

[0232] The WTRU can perform additional monitoring for blind MSG3 retransmission authorization based on whether the transmission indication MSG3 repeats. In one embodiment, if the WTRU receives an indication that MSG3 repeat is configured for MSG3 transmission (e.g., within a RAR), the WTRU can perform additional monitoring for blind MSG3 retransmission authorization. In another example, if the WTRU receives an indication that MSG3 repeat is configured for MSG3 transmission (e.g., within a RAR), the WTRU may not perform additional monitoring for blind MSG3 retransmission authorization. This indication may be, for example, a flag or a repurposed MCS codepoint, which can be reinterpreted to trigger additional monitoring.

[0233] Whether the WTRU performs additional monitoring of blind MSG3 transmission authorization based on the MSG3 repetition feature can be configuration-based. For example, the configuration may exist in system information where additional monitoring can be explicitly enabled / disabled, or alternatively, the presence of parameters may indicate that additional monitoring for blind retransmissions is enabled. In another example, this indication / configuration may be provided via RRC signaling (e.g., RRC release, RRC release with pending, or RRC reconfiguration), via random access messages (e.g., RAR, MSGB), MAC CE, paging messages, or DCI.

[0234] Whether the WTRU performs additional monitoring of the authorization of blind MSG3 transmissions based on the MSG3 retransmission feature can be based on configuration, where the configuration / instruction can describe the behavior to be applied, such as one or more of the following: if MSG3 retransmission is instructed, the WTRU may perform additional monitoring; if MSG3 retransmission is instructed, the WTRU may not perform additional monitoring; the method of additional monitoring that the WTRU may perform; and the characteristics of the additional monitoring (e.g., start, duration, periodicity).

[0235] Whether the WTRU performs additional monitoring of blind MSG3 retransmission grants based on the MSG3 repeatability characteristic can be configuration-based, where the WTRU can override a first configuration to perform additional monitoring of blind MSG3 retransmission grants based on the MSG3 repeatability characteristic due to a second indication / configuration. In one example, an indication (e.g., within a system message) can configure the WTRU to perform additional monitoring based on the MSG3 repeatability characteristic. The WTRU can receive subsequent indications (e.g., within a RAR or MSGB) to override the indication within the system message, where the WTRU will not perform additional monitoring regardless of the MSG3 repeatability characteristic.

[0236] The WTRU can perform additional monitoring of blind MSG3 retransmission grants based on whether the transmission indication MSG3 is repeated, and the WTRU can perform one or more of the following: The WTRU can receive configuration for a first PDCCH monitoring (e.g., normal PDCCH monitoring) for blind MSG3 retransmissions. The WTRU can receive configuration information associated with performing a second PDCCH monitoring (e.g., additional PDCCH monitoring) for receiving blind MSG3 retransmission grants, wherein, in the example, the second PDCCH monitoring can be performed before the first PDCCH monitoring. The WTRU can optionally select and transmit a PRACH preamble. (The preamble can optionally be segmented, and the WTRU can optionally select a preamble indicating at least one of the following: the WTRU is in a coverage-limited scenario; the WTRU supports and / or will perform a second (e.g., additional) PDCCH monitoring; a request for a blind retransmission grant based on or using the second (e.g., additional) PDCCH monitoring.) The WTRU can start a ra-ResponseWindow and monitor the PDCCH for random access responses. The WTRU can receive a Random Access Response (RAR) that does not indicate MSG3 repetition and stops the ra-ResponseWindow. The WTRU can transmit at least one MSG3 based on the received RAR (e.g., based on the UL grant received in the RAR). Based on the absence of MSG3 repetition, the WTRU can monitor the PDCCH at a monitoring time (e.g., based on the received configuration) for a second PDCCH monitoring for blind MSG3 retransmission grants (e.g., at a second or additional time).

[0237] The WTRU can receive a mapping between the MSG3 repetition feature and additional monitoring received for blind MSG3 retransmission grants. Based on the configured mapping behavior, upon receiving an MSG3 grant, the WTRU will determine additional blind MSG3 monitoring behavior based on the MSG3 retransmission feature. In an embodiment, whether the WTRU performs additional monitoring can be mapped to a specific number of MSG3 retransmissions (i.e., a function thereof). For example, similar to Table 1 below, the WTRU can be configured to perform additional monitoring for MSG3 grants.

[0238] Table 1

[0239]

[0240] The WTRU can receive a mapping between MSG3 repetition characteristics and additional monitoring received for blind MSG3 retransmission licenses, wherein in another embodiment, additional monitoring characteristics (e.g., start, duration, periodicity) can be mapped to a specific number of MSG3 retransmissions. For example, similar to Table 2 below, the WTRU can be configured to perform additional monitoring for MSG3 licenses:

[0241] Table 2

[0242]

[0243] The WTRU can receive a mapping between the MSG3 repetition feature and additional monitoring of blind MSG3 retransmission grant reception, wherein in another embodiment, the WTRU can receive the mapping information, for example, via RRC signaling or MAC CE. In one example, the WTRU can receive information within a handover command (e.g., and an RRC reconfiguration with a synchronization message) for random access to the target cell.

[0244] For example, such as combining Figure 9 As described, the WTRU can perform additional PDCCH monitoring for enhanced MSG3 blind retransmission authorization based on the fulfillment of conditions and / or combinations of conditions.

[0245] At 910, the WTRU may receive configuration for the first PDCCH monitoring (e.g., normal PDCCH monitoring) of MSG3 retransmissions. At 912, the WTRU receives configuration information associated with performing a second PDCCH monitoring (e.g., supplementary PDCCH monitoring) for authorized reception of blind MSG3 retransmissions, wherein, in the example, the second PDCCH monitoring may be performed before the first PDCCH monitoring. At 914, the WTRU receives conditions for performing the second (e.g., supplementary) PDCCH monitoring of blind MSG3 retransmissions. In an embodiment, the conditions may be based on one or more values, such as one or more of the following: distance from the cell center, satellite angle relative to the Earth, and / or RSRP. In another embodiment, configuration or identification of which one or more values ​​to evaluate and one or more associated thresholds (e.g., against which to evaluate one or more values) may be provided, for example, in system information, HO commands, RRC release messages, or RARs. At 916, the WTRU selects and transmits the RACH preamble. The preamble may be optionally segmented, and the WTRU may optionally indicate a preamble that represents at least one of the following: the WTRU is in a coverage-limited scenario; the WTRU supports and / or will perform second (e.g., supplemental) PDCCH monitoring; or a request for blind retransmission authorization based on or using second (e.g., supplemental) PDCCH monitoring. At 918, the WTRU starts the ra-ResponseWindow and monitors the PDCCH for random access responses. At 920, the WTRU receives the random access response and stops the ra-ResponseWindow. At 922, the WTRU transmits at least one MSG3 based on the received RAR (e.g., based on the UL authorization received in the RAR). At 924, the WTRU determines whether to perform second (e.g., supplemental) PDCCH monitoring for blind MSG3 retransmission based on configured conditions (e.g., based on whether one or more values ​​are higher or lower than their associated thresholds). If one or more conditions for second (e.g., additional) PDCCH monitoring are met, at 926, the WTRU monitors the PDCCH during the monitoring timing (e.g., based on the received configuration) for second PDCCH monitoring authorized for blind MSG3 retransmission (e.g., at the second or additional timing). When the WTRU receives a PDCCH based on the second PDCCH monitoring, at 928, the WTRU retransmits at least one MSG3 based on the authorization received in the PDCCH (e.g., PDCCH DCI). In an embodiment, after monitoring the PDCCH based on the second PDCCH monitoring, at 930, the WTRU monitors the PDCCH based on the first PDCCH monitoring, and when a PDCCH with UL authorization (e.g., PDCCHDCI) is received, at least one MSG3 is transmitted.

[0246] The WTRU can perform additional PDCCH monitoring for enhanced MSG3 blind retransmission grant reception based on satisfied conditions and / or combinations of conditions. The conditions for additional PDCCH monitoring for enhanced blind MSG3 retransmission grant reception can include one or more of the following: a threshold, where, for example, a condition is satisfied if the measured value is higher than, lower than, or equal to a threshold; a specific value, where, for example, a condition is satisfied if the measured value equals one or more indication values; a range of values, where, for example, a condition is satisfied if the measured value falls within a range. Alternatively, a condition is satisfied if the measured value falls outside an indication range.

[0247] The WTRU can perform additional PDCCH monitoring for enhanced MSG3 blind retransmission authorization based on met conditions and / or combinations of conditions. The WTRU can be configured with distance-based conditions to determine parameters, behaviors, etc. Distance can be defined as one or more of the following: WTRU-satellite distance; WTRU-satellite cell center distance; WTRU-satellite coverage area (footprint); WTRU-terrestrial gNB distance; or WTRU-reference point distance. Distance-based conditions can be in the form of the WTRU reaching at least or at most a certain distance. For example: the WTRU's distance is higher than a configured threshold; the WTRU's distance is lower than a configured threshold; and / or the WTRU's distance is between two configured thresholds. Distance-based conditions can also be in the form of changes in the WTRU's distance. In an embodiment, the conditions may be: the distance of the WTRU may change by an amount greater than a threshold within a configured time period / duration; the distance of the WTRU may increase by an amount greater than a threshold within a configured time period / duration; the distance of the WTRU may decrease by an amount greater than a threshold within a configured time period / duration; the change in the distance of the WTRU may have increased by an amount greater than a threshold within a configured time period / duration; or the change in the distance of the WTRU may have decreased by an amount greater than a threshold within a configured time period / duration.

[0248] Distance-based conditions can take the form of the time a WTRU spends at a certain distance. For example, the WTRU's distance remains at the same value for at least the configured time period; the WTRU's distance remains within the configured range for at least the configured time period; the WTRU's distance changes less than the configured amount over the configured time period; and / or the WTRU spends the maximum amount of time at a certain distance within the configured time period.

[0249] The WTRU can perform additional PDCCH monitoring for enhanced MSG3 blind retransmission authorization based on satisfying conditions and / or combinations of conditions, wherein the WTRU can be configured with speed-based conditions for determining parameters, behaviors, etc. Speed-based conditions can be in the form of the WTRU reaching at least or at most a certain speed. For example: the WTRU's speed is higher than a configured threshold; the WTRU's speed is lower than a configured threshold; and / or the WTRU's speed is between two configured thresholds. Speed-based conditions can be in the form of WTRU speed changes (e.g., acceleration / deceleration). In embodiments, conditions can be: the WTRU's speed may change by an amount greater than a threshold over a time period; the WTRU's speed may increase by an amount greater than a threshold over a time period; or the WTRU's speed may decrease by an amount greater than a threshold over a time period. Speed-based conditions can be in the form of the time the WTRU spends at a certain speed. In embodiments, conditions can be: the WTRU's speed remains at the same value for at least a configured time period; the WTRU's speed remains within a configured range for at least a configured time period; the WTRU's speed changes by an amount greater than / less than a configured amount over a configured time period.

[0250] The WTRU can perform additional PDCCH surveillance for enhanced MSG3 blind retransmission authorization based on satisfying conditions and / or combinations of conditions, wherein the WTRU can be based on satellite-based conditions configured to determine parameters, behaviors, etc. In embodiments, satellite-based conditions can depend on satellite characteristics, which can be explicitly indicated or implicitly determined (e.g., via satellite ephemeris). In embodiments, satellite conditions can be based on one or more of the following: differential delay within the cell (e.g., differential delay is above, below, or within range); cell size and / or coverage area (e.g., cell coverage area is above, below, or within range); remaining t-service of the cell (e.g., remaining t-service is above, below, or within range); gap between the t-service of the current cell and the start of t-service of neighboring cells (e.g., whether there is continuous or discontinuous coverage); whether the satellite payload is configured with a fixed Earth beam or a moving Earth beam; satellite orbit classification (e.g., whether the satellite is GEO, LEO, MEO, or HAPS); or the angle of the satellite relative to the Earth.

[0251] The WTRU can perform additional PDCCH monitoring for enhanced MSG3 blind retransmission grants based on satisfying conditions and / or combinations of conditions. The WTRU can be configured with channel-based conditions for determining parameters, behaviors, etc. Embodiments of channel-based conditions may include one or more of the following: measuring channel conditions below or above a threshold (e.g., RSRP, RSRQ); applied TA estimation / WTRU-gNB RTT (e.g., applied timing pre-compensation above, below, or within range); and / or frequency compensation (e.g., applied frequency compensation above, below, or within range).

[0252] The WTRU can perform additional PDCCH monitoring for enhanced MSG3 blind retransmission authorization based on met conditions and / or combinations of conditions. Where the WTRU conditions can be evaluated at the WTRU with limited capability to coordinate with the network to determine whether the conditions are met and the WTRU performs additional monitoring, there may be a correlation between WTRU coverage characteristics and / or WTRU location and NW decisions using blind MSG3 retransmission. In embodiments, the WTRU may explicitly indicate that the conditions have been met (e.g., via a dedicated preamble, or within an MSA PUSCH).

[0253] WTRU can perform additional PDCCH monitoring for blind MSG3 retransmission authorization based on failure conditions, as described below and in reference. Figure 10A and 10BDescribed. At 1012, the WTRU receives configuration information associated with performing a second PDCCH monitoring (e.g., supplementary PDCCH monitoring) for blind MSG3 retransmission grant reception, wherein, in this example, the second PDCCH monitoring may be performed before the first PDCCH monitoring. At 1014, the WTRU initiates two-step random access via a transmission of the MSGA including a preamble and a PUSCH transmission. The preamble may optionally be segmented, and the WTRU may optionally indicate a preamble indicating at least one of the following WTRU information or WTRU requests: the WTRU is in a coverage-limited scenario; the WTRU supports and / or will perform a second (e.g., supplementary) PDCCH monitoring; a request for a blind retransmission grant based on or using the second (e.g., supplementary) PDCCH monitoring. The WTRU information and / or request may optionally be included in the MSGA PUSCH. At 1016, the WTRU starts the msgB-ResponseWindow and monitors the PDCCH for the MSGB carrying the random access response. At 1018, the WTRU receives a random access response, where the RAR triggers a fallback to a four-step RA and stops the msgB-ResponseWindow. At 1020, the WTRU transmits at least one MSG3 based on the received RAR (e.g., based on the UL grant received in the RAR). In an embodiment, at 1022, the WTRU evaluates an overrun condition, if configured. In an embodiment, the overrun condition may be based on RSRP or a distance threshold (e.g., provided in SIB, RRC messages, RRC releases, etc.) and when the RSRP is higher than the RSRP threshold and / or (e.g., from the WTRU) the distance to the satellite is within a distance threshold (e.g., X km) (e.g., below the distance threshold (e.g., X km)). If the overrun condition is met, at 1024, the WTRU determines not to perform a second (e.g., additional) PDCCH monitoring. If the overrun condition is not met, at 1026, the WTRU determines to perform a second (e.g., additional) PDCCH monitoring (based on fallback triggering).

[0254] WTRU can perform additional PDCCH monitoring on blind MSG3 retransmission authorization based on failure conditions, wherein, in another embodiment, an example is shown in Figure 10BAs shown, based on a fallback trigger, at 1030, the WTRU determines to perform a second (e.g., additional) PDCCH monitoring. If the WTRU determines to perform a second (e.g., additional) PDCCH monitoring: then at 1032, the WTRU monitors the PDCCH during the monitoring timing (e.g., based on the received configuration) for the second PDCCH monitoring for blind MSG3 retransmission authorization (e.g., at the second or additional timing). When the WTRU receives a PDCCH based on the second PDCCH monitoring, the WTRU retransmits at least one MSG3 based on the authorization received in the PDCCH (e.g., PDCCH DCI). In an embodiment, after monitoring the PDCCH based on the second PDCCH monitoring, the WTRU monitors the PDCCH based on the first PDCCH monitoring, and transmits at least one MSG3 when a PDCCH with UL authorization (e.g., PDCCH DCI) is received. If the WTRU determines that a second (e.g., additional) PDCCH monitoring is not to be performed: then the WTRU monitors the PDCCH based on the first PDCCH monitoring, and transmits at least one MSG3 when a PDCCH with UL authorization (e.g., PDCCH DCI) is received.

[0255] Failure conditions may trigger additional monitoring of blind MSG3 retransmission authorization. In an embodiment, the WTRU may initiate a two-step RACH procedure (e.g., transmission via MSGA) and subsequently begin monitoring the PDCCH for a response (e.g., undergoing an MSGB response window). The WTRU may then receive a random access response (RAR) instead of the expected MSGB, causing the WTRU to fall back to a four-step random access procedure. Upon receiving the RAR after the MSGA transmission, the WTRU may then transmit MSG3 and begin additional monitoring for blind MSG3 retransmission authorization.

[0256] In another embodiment, in the event of a failure to trigger additional monitoring of blind MSG3 retransmission authorization, the WTRU can transmit a random access preamble and begin monitoring for the response (e.g., subject to a ra-response window). For example, if the WTRU does not receive a random access response (RAR) before the ra-response window expires, the WTRU can perform additional monitoring for blind MSG3 retransmission authorization. In another example, if the WTRU does not receive a RAR within X ms of the ra response window expiring, the WTRU can perform additional monitoring.

[0257] In another embodiment, in the event of failure to trigger additional monitoring of blind MSG3 retransmission authorization, the WTRU may transmit one or more preambles without receiving a response from the network. The WTRU may perform additional monitoring of blind MSG3 retransmission authorization after Y unsuccessful transmissions (e.g., the WTRU does not receive a response from the preamble transmission). Y may be indicated, for example, within system information and an RRC release / release or HO command with a pending message (e.g., an RRC reconfiguration with synchronization).

[0258] The WTRU can avoid authorizing the monitoring of the PDCCH for Msg3 retransmissions, even if the network has implicitly or explicitly instructed it to monitor the PDCCH at certain times / durations. For example, the WTRU can stop monitoring the PDCCH at the time / duration at which the authorization for Msg3 retransmissions is given when it determines that it is in good coverage conditions (e.g., the signal level of the serving cell is above a configured threshold).

[0259] The WTRU can avoid monitoring the PDCCH for Msg3 retransmission authorization, where the WTRU can be configured to monitor the PDCCH for obtaining authorization for Msg3 retransmission at t1, t2, and t3 (e.g., all within the WTRU-gNB RTT time). The WTRU could monitor the PDCCH at t1, obtain authorization, and perform the retransmission. However, at this point, the WTRU might detect that network conditions have significantly improved, and it is likely that no further blind retransmissions for message 3 are expected. Therefore, the WTRU can choose not to monitor the PDCCH at t2 and t3. In one example, if no DCI or PDCCH is received during a given PDCCH monitoring timeframe addressed to the WTRU's computed RA-RNTI or T-CRNTI, the WTRU can skip the additional PDCCH monitoring timeframe.

[0260] The WTRU can avoid authorized monitoring of the PDCCH for Msg3 retransmissions, whereby the WTRU can send an indication to the network that it is not monitoring the PDCCH as previously configured. This indication can, for example, be included in one of the last retransmissions of Msg3, where the WTRU has determined that retransmission is no longer expected / needed. As another example, the indication can be a separate indication (e.g., a UCI multiplexed on the PUSCH).

[0261] WTRU can avoid authorized monitoring of the PDCCH for Msg3 retransmissions, whereby WTRU can bypass or skip the additional PDCCH monitoring timing configured for Msg3 retransmissions if or not any of the above conditions are met.

[0262] The WTRU can avoid authorization monitoring PDCCH for Msg3 retransmissions, whereby the WTRU can receive authorization for the RA-RNTI corresponding to the RO and preamble of the transmission in msg2 or msgB with multiple associated temporary C-RNTIs. If a condition is met (e.g., from the condition described in 4.6), the WTRU can select a temporary C-RNTI and transmit Msg3 with such a TC-RNTI; if that condition is not met or another condition is met, the WTRU can transmit Msg3 with a TC-RNTI that has a different signal notification. For example, the WTRU can receive authorization in a RAR with two temporary C-RNTIs, whereby if the measured RSRP is above a threshold, the WTRU transmits Msg3 with a temporary C-RNTI that has a first signal notification, or if the measured RSRP is below the threshold, the WTRU transmits Msg3 with a temporary C-RNTI that has a second signal notification. The WTRU can implicitly determine the second temporary C-RNTI by adding an offset to the first temporary C-RNTI portion of the signal notification in the RAR or msgB. If the first TC-RNTI is selected, the WTRU can scramble the Msg3 PUSCH transmission with the sequence corresponding to the first TC-RNTI, and if the second TC-RNTI is selected, the WTRU can scramble the Msg3 PUSCH transmission with the sequence corresponding to the second TC-RNTI.

[0263] The WTRU can avoid authorized monitoring of the PDCCH for Msg3 retransmissions. The WTRU can be predefined or configured such that if the WTRU uses a second temporary C-RNTI to transmit Msg3, the WTRU can skip the additional monitoring timing for Msg3 retransmissions. The WTRU can also be configured or predefined such that if a first temporary C-RNTI is selected for the initial Msg3 transmission, the WTRU monitors the additional PDCCH timing for Msg3 retransmissions. The WTRU can monitor Msg3 retransmission DCIs scheduled using any temporary RNTIs notified in the RAR, or (optionally) any temporary RNTI selected for the initial Msg3 transmission.

[0264] The WTRU can avoid authorized monitoring PDCCH for Msg3 retransmissions. The WTRU can be configured with multiple physical layer transmission Msg3 PUSCH parameters (e.g., transmission power, PUSCH scrambling sequence). A first set of PHY transmission parameters is applied to the Msg3 transmission if certain conditions are met, and a second set of PHY transmission parameters (one or more) is used if the conditions are not met (or different conditions are met). For example, the WTRU can be configured or predefined to scramble the Msg3 PUSCH with two sequences. Thus, if the measured RSRP is less than a threshold, the WTRU transmits the Msg3 PUSCH scrambled with the first sequence, and if the measured RSRP is greater than the threshold, the WTRU transmits the Msg3 PUSCH scrambled with the second sequence.

[0265] The WTRU can avoid monitoring the PDCCH for Msg3 retransmission entitlements, whereby the WTRU can receive more than one entitlement in msg2 or msgB, thus allowing one entitlement to be used if one condition is met, and another entitlement to be met if another condition is not met. Conditions may include at least one as described above. A subset of entitlements can be used for one or more Msg3 retransmissions / repetitions. Entitlements can be used for the same HARQ procedure (e.g., HARQ PID 0) or different PIDs.

[0266] The WTRU can avoid monitoring the PDCCH for Msg3 retransmission grants. The WTRU can receive multiple grants from the network, and thus, if a condition is met (e.g., RSRP is above a threshold) and the WTRU discards one or more other grants, the WTRU will transmit on the first grant. If a condition is met, the WTRU can use one or more second grants signaling Msg3 retransmission. For example, the WTRU can receive more than one grant, and thus, if the WTRU measures RSRP (e.g., SS-RSRP) above a threshold, the WTRU can select the first grant, and if the condition is not met (e.g., RSRP is below a threshold), the WTRU can select one or more secondary grants (e.g., grants signaling Msg3 retransmission). The WTRU can discard unused or unselected secondary grants.

[0267] The WTRU can avoid monitoring the PDCCH for Msg3 retransmission authorization, whereby the WTRU can use a first HARQ procedure (e.g., HARQ procedure 0) to select authorization for Msg3 transmission if the conditions are met (e.g., RSRP is above a threshold), or the WTRU can use a second HARQ procedure to select authorization if the conditions are not met.

[0268] WTRU can continue monitoring PDCCH based on ra-ResponseWindow, regardless of whether RAR has been received. Figure 11 An example is shown where, after the RA preamble transmission 1110, RAR 1114 is received and there is a significant unused duration 1116 of the response window 1112. 1116. Figure 12 As shown, after successfully receiving RAR 1114, the WTRU can continue monitoring the PDCCH for blind Msg3 retransmission grant 1118. Whether the WTRU can continue monitoring can be conditional on the remaining time in the RAR window. For example, the WTRU can use this embodiment only if more than X ms remain in the ra-ResponseWindow duration, which may be a better option for additional scheduling opportunities. In another embodiment, the WTRU will use this solution only if less than X ms remain in the ra-ResponseWindow duration, which may be a better option for additional power savings.

[0269] In another embodiment, such as Figure 13 As shown, the WTRU can start ra-ContentionResolutionTimer 1318 immediately after the initial Msg3 transmission 1316 to monitor additional blind MSG3 retransmission grants. In this case, the WTRU operating in a non-terrestrial network can start ra-ContentionResolutionTimer in the first symbol after the end of the initial Msg3 transmission 1316 to monitor blind Msg3 retransmission grants. In another example, the WTRU can start ra-ContentionResolutionTimer 1322 at an offset 1320 from the end of the initial MSG3 transmission. The WTRU can then start ra-Contention Resolution timer 1322 a second time after WTRU-gNB RTT 1320. When considering whether the MSG3 transmission was successful, the WTRU can ignore the expiration of the ra-ContentionResolutionTimer used for blind Msg3 retransmission grant reception.

[0270] In an embodiment, the WTRU may maintain an additional Msg3 re-TX timer, which the WTRU may start or resume at the beginning of each additional PDCCH monitoring period. The WTRU may monitor the PDCCH (e.g., for receiving Msg3 re-TX grants) while such a timer is running. The WTRU may (re)start the timer when Msg3 is (re)transmitted. The WTRU may pause or stop the timer outside of the additional PDCCH monitoring periods configured for Msg3 re-TX.

[0271] When the time period expires, the WTRU can avoid or skip monitoring additional PDCCH monitoring for Msg3 re-TX. The WTRU can (re)start or stop the timer upon receiving a retransmission grant for Msg3 retransmission. The WTRU can (re)start the timer upon determining a HARQ NACK for the Msg3 payload. The WTRU can stop the timer upon receiving Msg4 or determining a HARQ-ACK for the Msg3 or msgA payload as an ACK. The WTRU can only run such a timer if the ra-responsewindow, msgB-responsewindow, and / or contention resolution timer are not running.

[0272] The WTRU can be configured (e.g., as part of broadcast SIB signaling) with the following: whether the WTRU should monitor additional PDCCH timings for scheduling Msg3 retransmissions, the configuration of additional PDCCH timings for scheduling Msg3 retransmission modes (referred to herein as "Msg3 re-TX DRX mode"), applicable PDCCH resources, and / or timers associated with additional PDCCH monitoring for Msg3 re-TX. The "Msg3 re-TX DRX mode" configuration indicates at least one of the following: the number of additional PDCCH timings to monitor (e.g., after the initial Msg3 transmission and / or before the start of the contention resolution timer), the start offset of (one or more) PDCCH timings—e.g., offset from PRACH resources—, the periodicity between timings, and / or one or more applicable conditions for this mode, such as those listed above herein, and whether to monitor additional timings if scheduling is received at a given timing within the mode. The WTRU may monitor additional PDCCH monitoring timings for Msg3 re-TX if at least one of the conditions listed above herein is met or not met.

[0273] The WTRU can monitor additional PDCCH monitoring times for Msg3 re-TX during the configured paging timings and / or one or more paging timings within the paging PDCCH monitoring timings. The WTRU can be configured, for example, as part of broadcast signaling, to have a subset of paging PDCCH monitoring times and / or POs to monitor the reception of Msg3 or msgA retransmission grants. The WTRU can implicitly determine a subset of PO or PDCCH monitoring times within a PO to monitor the reception of Msg3 re-TX. For example, the WTRU can monitor one or more PO / paging monitoring times based on the PACH timing selected for msg1 transmission and / or the timing of the last Msg3 repetition transmission. For example, if Msg3 is transmitted at t0, the WTRU can monitor PO and / or PDCCH paging monitoring times starting from t1+δt, where δt is pre-configured, predefined, or implicitly determined by the WTRU as gNB-WTRURTT or a multiple thereof. In another example, if msg1 is transmitted on RO at t0, and possibly depending on whether an indication of extended coverage was selected from the associated preamble partition, the WTRU may begin monitoring the PO and / or PDCCH paging timing from t0+δt, where δt is preconfigured, predefined, or implicitly determined by the WTRU according to the gNB-WTRU RTT.

[0274] After falling back to the four-step RA, the PDCCH monitoring timing used for Msg3 retransmission can be applied as an additional PDCCH monitoring timing used for msgB, msgA, or Msg3 retransmission. These terms are interchangeable.

[0275] Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROMs and digital multifunction discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, terminal, base station, RNC, or any host computer.

Claims

1. A method implemented in a wireless transmit-receive unit (WTRU) for determining additional monitoring timing for transmission of the physical downlink control channel (PDCCH), comprising: Receive first configuration information for performing first monitoring of the first PDCCH transmission for the first Msg3 retransmission; Receive second configuration information for performing second monitoring of the second PDCCH transmission for the second Msg3 retransmission; Transmit the Physical Random Access Channel (PRACH) preamble; Start the monitoring window and monitor the PDCCH transmission of the Random Access Response (RAR); Receive RAR and stop monitoring window; Transmit at least one Msg3 based on the received RAR; PDCCH transmission is monitored based on a second monitoring of PDCCH transmission used for the second Msg3 retransmission; Receive PDCCH transmissions based on second monitoring of second PDCCH transmissions; as well as The third Msg3 is retransmitted based on the authorization received in the PDCCH transmission.

2. The method according to claim 1, wherein, The second configuration information includes an explicit instruction to perform a second monitoring of the PDCCH transmission used for the second Msg3 retransmission.

3. The method according to claim 2, wherein, Explicit indications are received via RAR, PDCCH commands, or System Information Block (SIB) signaling.

4. The method according to any one of claims 1 to 3, wherein, The validity period is associated with an explicit indication, which indicates the period during which the information is valid.

5. The method according to any one of claims 2 to 4, wherein, Valid areas are associated with explicit indications, which indicate the areas that are valid.

6. The method according to any one of claims 2 to 5, wherein, Explicit indications include time period information regarding when authorization for Msg3 retransmission is expected to be received.

7. The method according to any one of claims 1 to 6, further comprising, after a second monitoring of the second PDCCH transmission, monitoring the PDCCH transmission based on a first monitoring of the first PDCCH transmission, and transmitting a fourth Msg3 upon receiving the second PDCCH transmission.

8. The method according to any one of claims 1 to 7, wherein, The conditions for performing a second monitoring of PDCCH transmissions used for blind Msg3 retransmissions are based on one or more values; 9. The method according to claim 8, wherein, The values ​​include at least one of the following: the distance from the WTRU to the center of the cell, the angle of the satellite relative to the Earth, or the RSRP.

10. The method according to claim 8 or 9, wherein, The value is provided in system information, handover (HO) commands, radio resource control (RRC) release messages, or RARs.

11. A method implemented in a wireless transmit receiver unit (WTRU) for determining additional timing for monitoring physical downlink control channel (PDCCH) transmissions, comprising: Receive first configuration information for performing first monitoring of the first PDCCH transmission for the first Msg3 retransmission; Receive second configuration information for performing second monitoring of the second PDCCH transmission for the second Msg3 retransmission; Start the response window and monitor the PDCCH transmission of random access responses; Receive the random access response and stop the response window; Transmit at least one Msg3 based on the received random access response; The decision to perform a second monitoring of the second PDCCH transmission used for retransmission is based on the Msg3 repeatability characteristic or overrun condition. as well as In response to either satisfying the Msg3 repeatability characteristic or not satisfying the override condition, monitor the transmission of the second PDCCH for the second Msg3 retransmission authorization.

12. The method according to claim 11, wherein, The third configuration information is provided via Radio Resource Control (RRC) signaling, random access messages, Media Access Control (MAC) control elements (MAC CE), paging messages, or downlink control information (DCI). The third configuration information indicates whether the WTRU performs additional monitoring of blind Msg3 transmission grants based on the Msg3 feature.

13. The method according to claim 11 or 12, wherein, Exceeding the condition is received via Random Access Response (RAR), Message B (MSGB), or system information.

14. The method according to any one of claims 11 to 13, wherein, If the overriding condition is met, then no second monitoring of PDCCH transmission will be performed, regardless of the Msg3 characteristic.

15. The method according to any one of claims 11 to 14, wherein, Whether the WTRU performs a second or additional monitoring depends on the predetermined number of Msg3 retransmissions.

16. A wireless transmit-receive unit (WTRU) configured to: Receive first configuration information for performing first monitoring of the first physical downlink control channel (PDCCH transmission) for the first Msg3 retransmission; Receive second configuration information for performing second monitoring of the second PDCCH transmission for the second Msg3 retransmission; Transmit the Physical Random Access Channel (PRACH) preamble; Start the monitoring window and monitor the PDCCH transmission of the Random Access Response (RAR); Receive RAR and stop monitoring window; Transmit at least one Msg3 based on the received RAR; PDCCH transmission is monitored based on a second monitoring of PDCCH transmission used for the second Msg3 retransmission; Receive PDCCH transmissions based on second monitoring of second PDCCH transmissions; as well as The third Msg3 is retransmitted based on the authorization received in the PDCCH transmission.

17. The WTRU of claim 16, wherein, The second configuration information includes an explicit instruction to perform a second monitoring of the PDCCH transmission used for the second Msg3 retransmission.

18. The WTRU according to claim 17, wherein, Explicit indications are received via RAR, PDCCH commands, or System Information Block (SIB) signaling.

19. The WTRU according to any one of claims 16 to 18, wherein, The validity period is associated with an explicit indication, which indicates the period during which the information is valid.

20. The WTRU according to any one of claims 16 to 19, wherein, Valid areas are associated with explicit indications, which indicate the areas that are valid.

Images