Methods, apparatus, and systems for network access to non-terrestrial networks

JP7904881B2Active Publication Date: 2026-08-13INTERDIGITAL PATENT HOLDINGS INC
View PDF 3 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2024-10-10
Publication Date
2026-08-13

AI Technical Summary

Benefits of technology

【0007】 非地上ネットワークに対するネットワークアクセスを対象とする方法、装置、およびシステムを提供する。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007904881000002
    Figure 0007904881000002
  • Figure 0007904881000003
    Figure 0007904881000003
  • Figure 0007904881000004
    Figure 0007904881000004
Patent Text Reader

Abstract

To provide methods, apparatuses, systems, etc. for, and / or for use in connection with, performing network access and / or other procedures in a non-terrestrial network (NTN) of a communication system.SOLUTION: Among methods, there are methods that may be implemented in a wireless transmit / receive unit (WTRU) and may include any of receiving, from the NTN, differential delay information and physical random access channel (PRACH) configuration information indicating a set of preambles and a PRACH occasion configuration; determining a set of candidate PRACH occasions, from among a plurality of PRACH occasions of the PRACH occasion configuration, on the basis of the differential delay information; selecting a preamble from a group of the preambles allocated to one candidate PRACH occasion of the set of candidate PRACH occasions; and transmitting the selected preamble using a PRACH resource corresponding to the one candidate PRACH occasion.SELECTED DRAWING: Figure 8
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] This relates to methods, apparatus, and systems for network access to non-terrestrial networks. [Background technology]

[0002] This disclosure relates to network communications, including methods, devices, and systems for network access to non-terrestrial networks, but is not limited to these. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] 3GPP TS38.811, “Study on New Radio (NR) to support non-terrestrial networks”, V15.0.0 [Overview of the project] [Problems that the invention aims to solve]

[0004] The present invention provides a method, apparatus, and system for network access to non-terrestrial networks. [Means for solving the problem]

[0005] Methods, apparatus, systems, etc., for performing network access and / or other procedures in a non-terrestrial network (NTN) of a communication system, and / or for use in connection therewith. Methods may be performed in a wireless transceiver unit (WTRU) and may include receiving differential delay information and physical random access channel (PRACH) configuration information indicating a set of preambles and a PRACH occasion configuration from the NTN; determining a set of candidate PRACH occasions from among multiple PRACH occasions of a PRACH occasion configuration based on the differential delay information; selecting a preamble from a group of preambles assigned to one of the candidate PRACH occasions from the set of candidate PRACH occasions; and transmitting the selected preamble using a PRACH resource corresponding to one of the candidate PRACH occasions.

[0006] A more detailed understanding can be obtained from the following description, which is given as an example in conjunction with the attached drawings. The figures in such drawings, including detailed explanations, are illustrative. Therefore, the figures and detailed explanations should not be considered limiting, and other equally valid examples are possible and appropriate. Furthermore, similar reference figures in the drawings indicate similar elements. [Effects of the Invention]

[0007] The present invention provides a method, apparatus, and system for network access to non-terrestrial networks. [Brief explanation of the drawing]

[0008] [Figure 1A] This figure shows an exemplary communication system in which one or more embodiments are implemented. [Figure 1B] This figure shows an exemplary wireless transceiver unit (WTRU) that may be used in the communication system of Figure 1A according to an embodiment. [Figure 1C]FIG. is a diagram showing an exemplary radio access network (RAN) and a core network (CN) used in the communication system of FIG. 1A according to an embodiment. [Figure 1D] FIG. is a diagram showing a further exemplary RAN and CN used in the communication system of FIG. 1A according to an embodiment. [Figure 2] FIG. is a diagram showing an example of a 4-step initial access procedure. [Figure 3] FIG. is a system resource diagram showing an exemplary preamble group assignment for a synchronization signal block (SSB). [Figure 4] FIG. is a system resource diagram showing an exemplary preamble group assignment for a set of SSBs. [Figure 5] FIG. is a system resource diagram showing an example of a preamble group assignment. [Figure 6] FIG. is a system resource diagram showing an exemplary preamble group assignment for a set of SSBs. [Figure 7] FIG. is a system resource diagram showing an exemplary preamble group assignment. [Figure 8] FIG. is a flowchart showing an exemplary preamble group assignment procedure. [Figure 9] FIG. is a flowchart showing an exemplary preamble group assignment procedure. [Figure 10] FIG. is a system resource diagram of an example of time indexing of a PRACH opportunity. [Figure 11] FIG. is a system resource diagram showing an example of multiple Msg1 transmissions before a random access response (RAR).

MODE FOR CARRYING OUT THE INVENTION

[0009] Various embodiments of apparatus, systems, devices, etc., and / or any element thereof, that perform operations, processes, algorithms, functions, etc., and / or any part thereof are described herein and / or claimed, but it should be understood that any embodiment described herein and / or claimed is deemed to be configured such that any apparatus, systems, devices, etc., and / or any element thereof performs any operation, process, algorithm, function, etc., and / or any part thereof.

[0010] Exemplary communication network Figure 1A illustrates an exemplary communication system 100 that can implement one or more disclosed embodiments. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may utilize one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), quadrature FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filtered bank multicarrier (FBMC).

[0011] As shown in Figure 1A, the communication system 100 may include radio transceiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a radio environment. For example, any of them may be called a “station” and / or “STA,” and WTRU102a, 102b, 102c, and 102d can be configured to transmit and / or receive radio signals and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other radio devices operating in industrial and / or automated processing chain situations), consumer electronics devices, and devices operating on commercial and / or industrial radio networks. Any of WTRU102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0012] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), node B, e-node B (eNB), home node B (HNB), home e-node B (HeNB), gNB, NR node B, site controller, access point (AP), and wireless router. Although each of the base stations 114a and 114b is depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

[0014] Base stations 114a and 114b can communicate with one or more WTRUs 102a, 102b, 102c, and 102d over the air interface 116, and the air interface 116 can be any suitable radio communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).

[0015] More specifically, as mentioned above, the communication system 100 can be a multiple access system and can utilize one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Communications System (UMTS) Terrestrial Radio Access (UTRA), which can establish an air interface 116 using broadband CDMA (WCDMA). 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 ​​UL Packet Access (HSUPA).

[0016] In an embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as Advanced UMTS Terrestrial Radio Access (E-UTRA) that can establish an air interface 116 using Long-Term Evolution (LTE) and / or LTE Advanced (LTE-A) and / or LTE Advanced Pro (LTE-A Pro).

[0017] In this embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using New Radio (NR).

[0018] In 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 implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies, as well as transmissions sent to and from multiple types of base stations (e.g., eNBs and gNBs).

[0019] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (e.g., Wireless Fidelity (WiFi)), IEEE 802.16 (e.g., Global Interoperability for Microwave Access (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), High Speed ​​Data Rate for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0020] In Figure 1A, base station 114b can be, for example, a wireless router, home node B, home enode B, or access point, and any suitable RAT can be used to facilitate wireless connectivity in localized areas such as offices, homes, vehicles, campuses, industrial facilities, air corridors (used by drones, for example), and roadways. In one embodiment, base station 114b and WTRU 102c, 102d can establish a wireless local area network (WLAN) by implementing wireless technology such as IEEE 802.11. In another embodiment, base station 114b and WTRU 102c, 102d can establish a wireless personal area network (WPAN) by implementing wireless technology such as IEEE 802.15. In another embodiment, base station 114b and WTRU 102c, 102d can establish a picocell or femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

[0021] RAN104 / 113 can communicate with CN106 / 115, which can be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, including different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 can provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, and / or perform high-level security functions, such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 can communicate directly or indirectly with other RANs utilizing the same or different RAT as RAN104 / 113. For example, in addition to being connected to RAN104 / 113, which may utilize NR radio technology, CN106 / 115 can also communicate with other RANs (not shown) that utilize GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0022] CN106 / 115 can also serve as a gateway for WTRU102a, 102b, 102c, and 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing basic telephone services (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) within the TCP / IP Internet Protocol Suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs that can utilize the same or different RAT as RAN104 / 113.

[0023] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 can include multimode functionality (for example, WTRUs 102a, 102b, 102c, and 102d can include multiple transceivers for communicating with different radio networks on different radio links). For example, WTRU 102c shown in Figure 1A can be configured to communicate with base station 114a which can utilize cellular-based radio technology, and also with base station 114b which can utilize IEEE 802 radio technology.

[0024] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, 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 peripherals 138. It will be understood that the WTRU 102 may include any subcombinations of the above elements while maintaining consistency with the embodiment.

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

[0026] The transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit / receive element 122 may be a radiator / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of radio signals.

[0027] In Figure 1B, the transmit / receive element 122 is depicted as a single element, but the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can utilize MIMO technology. Therefore, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals over the air interface 116.

[0028] The transceiver 120 can be configured to modulate the signal to be transmitted by the transmit / receive element 122 and to demodulate the signal received by the transmit / receive element 122. As mentioned above, the WTRU 102 can have multimode capabilities. Therefore, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0029] The processor 118 of the WTRU102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from them. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can retrieve information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in them. 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 subscriber identification module (SIM) cards, memory sticks, and secure digital (SD) memory cards, etc. In other embodiments, the processor 118 can obtain information from memory located on a server or home computer (not shown) or the like, which is not physically located on the WTRU 102, and can store data in it.

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

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

[0032] The processor 118 can be further coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, e-compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, TV transceiver, hands-free headset, Bluetooth® module, frequency modulation (FM) radio unit, digital music player, media player, video game player module, internet browser, virtual reality and / or augmented reality (VR / AR) device, and activity tracker. Peripherals 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, orientation sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0033] WTRU102 may include a full-duplex radio where the transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception)) can be in parallel 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., chokes) or via signal processing via a processor (e.g., a separate processor (not shown) or processor 118). In embodiments, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of the signals (e.g., associated with specific subframes for either UL (e.g., for transmission) or downlink (e.g., for reception).

[0034] Figure 1C is a system diagram illustrating RAN104 and CN106 according to an embodiment. As mentioned above, RAN104 can communicate with WTRU102a, 102b, and 102c over the air interface 116 using E-UTRA radio technology. RAN104 can also communicate with CN106.

[0035] RAN104 may include e-nodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of e-nodes B while maintaining consistency with the embodiment. Each of the e-nodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c over the air interface 116. In one embodiment, e-nodes B160a, 160b, and 160c can implement MIMO technology. Thus, e-node B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

[0036] Each of the e-nodes B160a, 160b, and 160c can be associated with a specific cell (not shown) and configured to handle wireless resource management decisions, handover decisions, and user scheduling in UL and / or DL. As shown in Figure 1C, the e-nodes B160a, 160b, and 160c can communicate with each other over the X2 interface.

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

[0038] The MME162 can connect to each of the e-nodes B160a, 160b, and 160c within RAN104 via the S1 interface and can act as a control node. For example, the MME162 can be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 can provide control plane functionality for exchanges between RAN104 and other RANs (not shown) utilizing other radio technologies such as GSM and / or WCDMA.

[0039] The SGW164 can connect to each of the e-nodes B160a, 160b, and 160c within RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can also perform other functions, such as anchoring the user plane during e-node B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0040] SGW164 can connect to PGW166, which in turn provides WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0041] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to circuit-switched networks such as PSTN108, thereby facilitating communication between WTRU102a, 102b, and 102c and conventional fixed-line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. In addition, CN106 can provide WTRU102a, 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.

[0042] In Figures 1A to 1D, the WTRU is described as a wireless terminal, but in a typical embodiment, such a terminal is intended to be able to use a wired communication interface with a communication network (e.g., temporarily or permanently).

[0043] In a typical embodiment, the other network 112 may be a WLAN.

[0044] A WLAN in Infrastructure Basic Service Set (BSS) mode may have access points (APs) for the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating from outside the BSS to an STA can arrive through an AP and be delivered to the STA. Traffic originating from an STA to a destination outside the BSS can be sent to an AP for delivery to its respective destination. Traffic between STAs within the BSS can be sent through an AP; for example, a source STA can send traffic to an AP, which can then deliver the traffic to a destination STA. Traffic between STAs within the BSS can be considered and / or sometimes referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent (e.g., directly) between a source STA and a destination STA using a Direct Link Setup (DLS). In one typical embodiment, the DLS may be an 802.11e DLS or an 802.11z tunnel DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) can communicate directly with one another. Communication in IBSS mode is sometimes referred to herein as “ad hoc” mode communication.

[0045] When using 802.11ac infrastructure mode operation or a similar mode operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be of a fixed width (e.g., 20 MHz bandwidth) or a dynamically set width via signaling. The primary channel can be the operating channel of the BSS and can be used by an STA to establish a connection with the AP. In one typical embodiment, for example, in an 802.11 system, carrier sense multiple access / collision avoidance (CSMA / CA) can be implemented. In the case of CSMA / CA, an STA, including the AP (e.g., any STA), can sense the primary channel. If the primary channel is sensed / detected by a particular STA and / or determined to be busy, that particular STA can backoff. Within a given BSS, at any given time, one STA (e.g., just one station) can transmit.

[0046] High-throughput (HT) STAs can use a 40MHz wide channel for communication, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0047] Ultra-high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. 160MHz channels can be formed by combining eight consecutive 20MHz channels, or by combining two discontinuous 80MHz channels, sometimes referred to as an 80+80 configuration. In the 80+80 configuration, data can pass through a segment parser that, after channel encoding, can split the data into two streams. Each stream can be separately subjected to inverse fast Fourier transform (IFFT) processing and time-domain processing. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation described above for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0048] Sub-1GHz mode operation is supported by 802.11af and 802.11ah. 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, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah can support meter-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have limited functionality, including support for certain bandwidths and / or limited bandwidths (e.g., only support for those). MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0049] A WLAN system that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs within the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating within the BSS. In the case of 802.11ah, even if APs and other STAs within the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, the primary channel may be 1MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1MHz mode. Carrier sensing and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is busy because an STA (which only supports 1MHz operating mode) is transmitting to the AP, the majority of the available frequency band remains idle, and even if it could be available, the entire available frequency band can be considered busy.

[0050] In the United States, the available frequency band for use with 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is from 6 MHz to 26 MHz, depending on national regulations.

[0051] Figure 1D is a system diagram showing RAN113 and CN115 according to an embodiment. As mentioned above, RAN113 can communicate with WTRU102a, 102b, and 102c over air interface 116 using NR radio technology. RAN113 can also communicate with CN115.

[0052] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with the embodiment. Each of the gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c over the air interface 116. In one embodiment, the gNB180a, 180b, and 180c can implement MIMO technology. For example, the gNB180a and 180b can use beamforming to transmit signals to and / or receive signals from the gNB180a, 180b, and 180c. Thus, the gNB180a can, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from the WTRU102a. In embodiments, gNB180a, 180b, and 180c can implement carrier aggregation techniques. For example, gNB180a can transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In embodiments, gNB180a, 180b, and 180c can implement multipoint coordination (CoMP) techniques. For example, WTRU102a can receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0053] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals can vary for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or lasting for varying absolute times).

[0054] The gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configurations, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., e-nodes B160a, 160b, and 160c). In standalone configurations, WTRU102a, 102b, and 102c can use one or more of the gNB180a, 180b, and 180c as mobility anchor points. In standalone configurations, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals within the unlicensed band. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with and connect to other RANs such as e-nodes B160a, 160b, and 160c, while also communicating with and connecting to other RANs. For example, WTRU102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c, and one or more e-nodes B160a, 160b, and 160c. In a non-standalone configuration, e-nodes B160a, 160b, and 160c can act as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRU102a, 102b, and 102c.

[0055] Each of the gNB180a, 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, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPF) 184a and 184b, and routing of control plane information to access and mobility management functions (AMF) 182a and 182b. As shown in Figure 1D, the gNB180a, 180b, and 180c can communicate with each other over the Xn interface.

[0056] The CN115 shown in Figure 1D 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 each of the above elements is depicted as a part of CN115, it will be understood that any of these elements may be owned and / or operated by an entity different from the CN operator.

[0057] AMF182a and 182b can connect to one or more of gNB180a, 180b, and 180c within RAN113 via the N2 interface and can act as control nodes. For example, AMF182a and 182b can be responsible for authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating non-accessible layer (NAS) signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of services utilized by WTRU102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on ultra-high reliability low latency communication (URLLC) access, services that rely on high-speed mobile (e.g., high-capacity mobile) broadband (eMBB) access, and / or services for machine-type communication (MTC) access. The AMF162 can provide control plane functionality for exchange between RAN113 and other RANs (not shown) that utilize other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies like WiFi.

[0058] SMF183a and 183b can connect to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also connect to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure routing of traffic through them. SMF183a and 183b can perform other functions, such as managing and assigning WTRU / UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, and Ethernet-based, among others.

[0059] UPF184a and 184b can connect to one or more of the gNB180a, 180b, and 180c in RAN113 via the N3 interface, providing WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184a and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihoming PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0060] CN115 can facilitate communication with other networks. For example, CN115 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN115 and PSTN108. In addition, CN115 can provide WTRU102a, 102b, 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, WTRU102a, 102b, 102c can connect to local data networks (DN) 185a, 185b through UPF184a, 184b via an N3 interface to UPF184a, 184b, and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0061] In view of Figures 1A to 1D and their corresponding descriptions, one or more or all of the functions described herein relating to one or more of the WTRU102a to d, base stations 114a to b, e-nodes B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein can be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

[0062] Emulation devices can be designed to perform one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more emulation devices can perform one, more, or all functions, fully or partially implemented and / or deployed as part of a wired and / or wireless network, to test other devices in a communications network. One or more emulation devices can perform one, more, or all functions, temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices can be directly coupled to another device for the purpose of performing tests and / or can perform tests using over-the-air radio communication.

[0063] One or more emulation devices can perform one or more functions, including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be used in a test scenario, in a test laboratory and / or in an undeployed (e.g., test) wired and / or wireless communication network, to perform testing of one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., including one or more antennas) can be used by the emulation device to transmit and / or receive data.

[0064] Next-generation wireless interfaces include further evolutions of Long-Term Evolution (LTE) Advanced Pro and New Radio (NR). They support a wide range of use cases, including various service requirements (e.g., low overhead, low data rate power-efficient services, (Mega-Machine Type Communications (mMTC)), ultra-high reliability, low latency communications (URLLC) services, and high data rate mobile broadband services (e.g., Enhanced Mobile Broadband (eMBB))) under various mobile scenarios (e.g., stationary / fixed, high-speed trains, etc.) and diverse radio transceiver unit (WTRU) capabilities (e.g., low-power, low-bandwidth WTRUs, very wide bandwidth WTRUs such as 80MHz, etc., support for WTRUs to high frequencies above 6GHz, etc.). They use architectures that are flexible enough to accommodate diverse deployment scenarios (e.g., standalone, non-standalone with support from different wireless interfaces, centralized, virtualized, distributed via ideal / non-ideal backhaul, etc.).

[0065] Beamforming can be used to compensate for increased path loss at higher frequencies (e.g., above 6 GHz). Multiple antenna elements can be used to achieve high beamforming gain. Analog and / or hybrid beamforming can be used to reduce implementation costs (e.g., by reducing the number of radio front-end (RF) chains). In NR, analog / hybrid beams are multiplexed in time, and beam sweeping can also be used (e.g., to cover a wide area). During the initial access procedure, the WTRU may (and may need to) monitor multiple downlink reference signals to identify the appropriate beam for accessing the network.

[0066] Non-terrestrial networks (NTNs) are discussed in Non-Patent Document 1. They can facilitate the deployment of 5G services in unserviced areas (e.g., isolated remote areas, rural areas, ships at sea, etc.). NTNs can be used to improve the performance of terrestrial networks in unserviced areas in a cost-effective manner. NTNs can be used to enhance the reliability of 5G services, ensure service availability, and provide scalability for 5G deployments.

[0067] Methods, apparatus, systems, etc., for initial and other network access in combined terrestrial and non-terrestrial networks (NTN) (collectively, the “Networks”) are disclosed herein.

[0068] Some such methods address disambiguation of PRACH occasions / resources in network access procedures, including disambiguation between PRACH occasions / resources used by a wireless transceiver unit (WTRU) and network decisions regarding such PRACH occasions / resources. For example, such methods can handle (or address) uncertainties that may ordinarily occur during network access.

[0069] In various embodiments, methods for performing initial or other network access to NTN, and / or methods used in connection therewith, may be performed in a WTRU, and may include any of these.

[0070] In various embodiments, methods for performing initial or other network access to NTN, and / or methods used in connection therewith, may be performed in a WTRU and may include any of the following: generating a preamble message ("Msg1"), sending Msg1 to NTN, receiving a response message ("Msg2") from NTN, generating a connection request message ("Msg3"), sending Msg3 to NTN, and receiving a conflict resolution message ("Msg4") from NTN. In various embodiments, Msg1 and Msg3 may be sent together (e.g., combined) in a message (MsgA). In various embodiments, Msg2 and Msg4 (e.g., combined) may be received together in a message ("MsgB").

[0071] In various embodiments, the method may include receiving NTN's timing offset. In various embodiments, the method may include determining the network's downlink (DL) transmission timing based on the timing offset. In various embodiments, the method may include sending time advance (TA) information in Msg1.

[0072] In various embodiments, the method may include selecting a physical random access channel (PRACH) configuration for transmitting Msg1. In various embodiments, the method may include selecting a PRACH preamble group from a set of PRACH preamble groups corresponding to different ranges of TAs between the WTRU and the network. In various embodiments, the method may include determining a number of preamble groups based on the number of PRACH resources included in the delay deviation period. In various embodiments, the method may include selecting a PRACH preamble group based on the delay deviation period and the SSB. In various embodiments, the method may include selecting at least one frequency resource for transmitting Msg1 based on the PRACH transmission time included in the delay deviation period. In various embodiments, the method may include determining the delay deviation period. In various embodiments, the method may include selecting a PRACH preamble group based on the location of the PRACH resource and the associated synchronous signal block (SSB). In various embodiments, the method may include performing Doppler compensation. In various embodiments, the method may include performing Doppler compensation based on the velocity vector. In various embodiments, the method may include determining a Random Access-Radio Network Temporary Identifier (RA-RNTI) based on (for example, a selected) PRACH configuration.

[0073] In various embodiments, the method may include determining an initial frame for time indexing and / or determining the RA-RNTI. In various embodiments, the method may include determining a time index for a PRACH time instance. In various embodiments, the method may include adjusting the transmit power of Msg1. In various embodiments, the method may include decoding Msg2 by using one or more RA-RNTIs determined within the delay difference period.

[0074] In various embodiments, the method may include determining a RACH configuration for transmitting any of Msg1, Msg3, and MsgA. In various embodiments, the method may include determining a RACH configuration for transmitting any of Msg1, Msg3, and MsgA based on one or more factors. In various embodiments, one or more factors may include any of the following: (i) the type of WTRU, (ii) the class of the WTRU, (iii) whether the WTRU has GNSS capabilities, (iv) the ability to estimate timing advance (TA), (v) the ability to estimate position, (vi) the ability to compensate for Doppler, (vii) the size of Msg1, Msg2, and / or MsgA, (viii) the estimated TA, and (ix) the predicted TA.

[0075] In various embodiments, the method may include selecting one or more parameters for the RACH configuration. In various embodiments, one or more parameters may include any of the following: (i) preamble index, (ii) resources for preamble transmission, (iii) number of preamble transmissions, (iv) resources for PUSCH, (v) number of PUSCH transmissions, (vi) redundant version (RV) sequence, (vii) association between preamble and PUSCH, (viii) transmit power for PUSCH, and (ix) modulation coding scheme (MCS) for PUSCH. In various embodiments, the method may include configuring the WTRU with one or more parameters. In various embodiments, the method may include receiving one or more parameters from NTN.

[0076] In various embodiments, determining a RACH configuration for transmitting any of Msg1, Msg3, and MsgA may include determining the number of PUSCH and / or preamble transmissions based on the estimated TA. In various embodiments, determining a RACH configuration for transmitting any of Msg1, Msg3, and MsgA may include deciding to use one preamble and one or more PUSCH transmissions based on the ability to accurately estimate the TA. In various embodiments, determining a RACH configuration for transmitting any of Msg1, Msg3, and MsgA may include deciding to use one preamble with multiple PUSCH transmissions based on the lack of the ability to accurately estimate the TA. In various embodiments, the method may include determining a RACH configuration for transmitting any of Msg1, Msg3, and MsgA may include deciding to use multiple transmissions of both preamble and PUSCH based on the lack of the ability to accurately estimate the TA.

[0077] In various embodiments, the method may include informing NTN (e.g., a network entity) of the estimated TA. In various embodiments, informing NTN of the estimated TA may include informing NTN of the estimated TA using MsgA. In various embodiments, informing NTN of the estimated TA may include sending MsgA the estimated TA and / or an index corresponding to a table of estimated TAs. In various embodiments, informing NTN of the estimated TA may include implicitly informing NTN of the estimated TA by using specific parameters or combinations of specific parameters to MsgA.

[0078] In various embodiments, the method may include determining one or a combination of various transmission characteristics for use in transmitting and / or retransmitting MsgA. In various embodiments, the method may include determining one or a combination of various transmission characteristics for use in transmitting and / or retransmitting MsgA based on the reception status of MsgB. In various embodiments, the reception status of MsgB may include any of the following: no MsgB, MsgB decoding failure, MsgB showing an ACK to the preamble and a NACK to PUSCH, MsgB showing a NACK to the preamble and an ACK to PUSCH, and MsgB showing an ACK to both the preamble and PUSCH.

[0079] In various embodiments, various transmission characteristics may include (i) performing a power increase for the preamble, (ii) adjusting the transmit power, (iii) adjusting the modulation coding scheme (MCS) for PUSCH, (iv) switching from 2-step RACH to 4-step RACH, (v) adjusting the number of PUSCH transmissions, (vi) adjusting the number of preamble transmissions, (vii) adjusting the estimated TA value, (viii) using a different resource configuration for MsgA, (ix) selecting a specific preamble format, and (x) using a different (e.g., different) preamble format, or switching to a different (e.g., different) preamble format.

[0080] In various embodiments, the method may include determining the transmit power TxP for Msg1 based, for example, at least in part, on various satellite information received from the network. In various embodiments, the satellite information may include any of the target power, power rise step, satellite transmit power, satellite type, altitude, speed, and ephemeris data from which the preamble is received. In various embodiments, the method may include receiving the satellite information in any of the L1, L2, and / or L3 signaling.

[0081] In various embodiments, the method may include determining the received power based on a reference signal. In various embodiments, the determined received power may include the reference signal received power (RSRP).

[0082] In various embodiments, the method may include estimating the path loss (PL) at time t1 based on satellite transmit and receive power based on a reference signal. In various embodiments, the method may include predicting the PL at time t2 based on any of the calculated distance to the relevant satellite at time t1, the estimated PL at time t1, and the predicted distance to the satellite at time t2. In various embodiments, the method may include calculating the distance from the satellite at time t1 based on satellite information. In various embodiments, the satellite information may include satellite altitude and ephemeris data. In various embodiments, the method may include predicting the distance from the satellite at time t2 based on information including any of the WTRU, satellite altitude, velocity, and ephemeris data.

[0083] In various embodiments, the method may include calculating two transmit powers, TxP1 and TxP2. In various embodiments, the first and second transmit powers TxP1 and TxP2 may be based on an estimated PL and a predicted PL, respectively. In various embodiments, the first transmit power TxP1 may be calculated as a combination of the target power at which the preamble is received and the estimated PL, and the second transmit power TxP2 may be calculated as a combination of the target power at which the preamble is received and the predicted PL. In various embodiments, the target power at which the preamble is received may be obtained from satellite information.

[0084] In various embodiments, the method may include determining the transmit power TxP for Msg1 based on first and second transmit powers TxP1, TxP2. In various embodiments, determining the transmit power TxP for Msg1 may include determining the transmit power TxP for Msg1 as the maximum, average, or other function of the first and second transmit powers TxP1, TxP2.

[0085] In various embodiments, the method may include setting and / or applying the transmit power TxP for Msg1 according to TxP = min(maximum power, f(TxP1, TxP2)), where maximum power can be the maximum transmit power, and f(TxP1, TxP2) is a function applied to either the first or second transmit power TxP1, TxP2.

[0086] In various embodiments, the method may include adjusting a first transmit power TxP1 according to a power-up step for the retransmission of Msg1. In various embodiments, the method may include determining the transmit power TxP for the retransmission of Msg1 based, for example, at least in part, on various satellite information received from the network.

[0087] In various embodiments, the method may include determining a third transmit power TxP3 for retransmitting Msg1 at time t3 based on a second predicted PL between the WTRU and the satellite, when Msg1 is intended and / or predicted to reach the satellite after retransmission. In various embodiments, the method may include predicting a second predicted PL at time t3 based on (for example, using) any of the calculated distance to the relevant satellite at time t1, the estimated PL at time t1, and the predicted distance to the satellite at time t3. In various embodiments, the method may include setting and / or applying a transmit power TxP to retransmit Msg1 according to TxP = min(maximum power, f(TxP1 + power rise step, TxP3)), where maximum power can be the maximum transmit power, and f(TxP1(t1) + power rise step, TxP2(t2)) is a function applied to TxP1(t1) + power rise step and / or TxP2(t2).

[0088] In various embodiments, methods used to perform network access to NTN and / or other procedures in NTN, and / or in connection therewith, may be performed in a WTRU and may include receiving Doppler shift compensation information from a network entity, or performing Doppler pre-compensation after receiving Doppler shift compensation. In various embodiments, the Doppler shift compensation information may be a Doppler shift compensation command.

[0089] In various embodiments, the network entity can be a base station. In various embodiments, Doppler shift compensation information can be received in any of Layer 1 (L1), Layer 2 (L2), and Layer 3 (L3) signaling. In various embodiments, the method may include receiving Doppler shift compensation information in (or by) a Media Access Control (MAC) control element (CE) and a Radio Resource Control (RRC) message.

[0090] In various embodiments, performing Doppler pre-compensation may include adjusting Doppler shift pre-compensation using a previously pre-compensated Doppler shift. In various embodiments, the method may include the previously pre-compensated Doppler shift being based on (e.g., by) information received from a network (e.g., a base station). In various embodiments, the previously pre-compensated Doppler shift may be based on (e.g., by) the last UL transmission.

[0091] In various embodiments, a method used to implement network access to NTN and / or other procedures in NTN and / or in connection therewith may be implemented in WTRU and may include determining which of one or more synchronous rasters should be used based on the type of satellite ("satellite type"). In various embodiments, each (or any) of the synchronous rasters may be associated with one or more satellite types. In various embodiments, the method may include determining which of the synchronous rasters should be used based on the target and / or accessed satellite type. In various embodiments, a large synchronous raster may be used for LEO satellites. In various embodiments, a small synchronous raster may be used for GEO satellites.

[0092] In various embodiments, methods for performing network access to NTN and / or other procedures at NTN, and / or methods used in connection therewith, can be performed at WTRU and may include determining the SSB timing of multiple beams transmitted by the satellite based on the timing of one SSB and an inter-beam timing pattern. In various embodiments, the timing pattern may be a (pre-defined) timing pattern. In various embodiments, determining the SSB timing may include determining the time to monitor various frequencies to detect SSBs from beams transmitted by the satellite based on the SSB timing of different beams.

[0093] In various embodiments, a method used to perform network access to NTN and / or other procedures in NTN and / or in connection therewith may be performed in a WTRU and may include either monitoring a group-common PDCCH (GC-PDCCH) and receiving indications of TA commands (TACs) for one or more WTRUs. In various embodiments, the method may include adjusting the TA to match that of the group of WTRUs indicated by the TAC. In various embodiments, monitoring the GC-PDCCH may include using GC-RNTI and / or CORSET to monitor the TAC for the group of WTRUs.

[0094] In various embodiments, methods used to implement network access to NTN and / or other procedures in NTN and / or in connection therewith may be implemented in the WTRU and may include autonomously adjusting the TA in the WTRU based on any of the satellite ephemeris, control timing and data transmitted from the network, and GNSS information. In various embodiments, the method may include the WTRU indicating its TA estimation capabilities to the network. In various embodiments, the method may include the WTRU indicating its TA adjustment capabilities to the network. In various embodiments, a WTRU (e.g., UE) function message may be used to indicate the WTRU's TA estimation capabilities to the network. In various embodiments, a WTRU (e.g., UE) function message may be used to indicate the WTRU's TA adjustment capabilities to the network.

[0095] In various embodiments, methods used to perform network access to NTN and / or other procedures in NTN and / or in connection therewith may be performed in a WTRU and may include indicating to the network either the WTRU's TA estimation function or the WTRU's TA tuning function. In various embodiments, a WTRU (e.g., UE) function message may be used to indicate to the network the WTRU's TA estimation function. In various embodiments, a WTRU (e.g., UE) function message may be used to indicate to the network the WTRU's TA tuning function.

[0096] In various embodiments, the method used to perform network access to NTN and / or other procedures in NTN and / or in connection therewith may be performed in the WTRU and may include determining the TAC mode for use based on information from the network. In various embodiments, the TAC mode may indicate a reference timing for TAC.

[0097] In various embodiments, the TAC mode can be an autonomous mode or a non-autonomous mode. In various embodiments, in an autonomous TAC mode, the method may include the WTRU adjusting the TA based on a reference timing from either a previous UL transmission or a previously successful transmission. In various embodiments, in a non-autonomous TAC mode, the method may include the WTRU adjusting the TA based on a reference timing from a previous TAC. In various embodiments, the method may include receiving the TAC mode in any of the L1, L2, and L3 signaling. In various embodiments, the WTRU may be dynamically informed of the TAC mode in each TAC message. In various embodiments, the WTRU may receive the TAC mode by either a MAC CE or an RRC message.

[0098] In various embodiments, methods used for performing network access to NTN and / or other procedures in NTN, and / or in connection therewith, may include methods for reducing the initial access time to NTN of a WTRU. In various embodiments, the method may be performed in a WTRU and may include sending one of several preambles (Msg1) before receiving a random access response (Msg2) from the network. In various embodiments, the method may be performed in a WTRU and may include deciding whether to perform a two-step random access channel (RACH) procedure or a four-step RACH procedure, and, based on that decision, performing either the two-step RACH or the four-step RACH procedure. In various embodiments, the method may be performed in a WTRU and may include performing both the two-step and four-step RACH procedures before monitoring a random access response (RAR).

[0099] Figure 2 shows an exemplary four-step initial access procedure 200. The four-step initial access procedure 200 may be applicable to, for example, NR and NTN. According to the four-step initial access procedure 200, WTRU102 can receive and read a Master Information Block (MIB) (not shown) and / or System Information Block-1 (SIB1) (201). WTRU102 can perform DL synchronization using the information obtained from and / or indicated by the MIB and / or SIB1 ("M / SIB Information"). WTRU102 can, for example, use the SIB Information to determine the resources used to send a RACH preamble (Msg1) to the network to indicate its intention to access the network. WTRU102 can send Msg1 using such resources (203). WTRU102 can monitor Random Access Responses (RARs) from the network during the RAR window.

[0100] If the network (e.g., gNB) successfully receives Msg1, it can send RAR("Msg2") to the WTRU (205). Msg2 can be scrambled using RA-RNTI. WTRU102 can calculate RA-RNTI as a function of time and frequency of the resources used to transmit Msg1.

[0101] WTRU102 can receive Msg2(205) from gNB and descramble the message using RA-RNTI. Msg2 may include any of the following: timing advance (TA), power adjustment / correction, temporary cell radio network temporary identifier (TC-RNTI), and resource (permission) to WTRU102, which WTRU102 uses to send a Radio Resource Control (RRC) connection request ("Msg3").

[0102] WTRU102 can use the resources scheduled and authorized in Msg2 to send its identification and initial access establishment (Msg3) to the network (207). The network can notify WTRU102 of the completion of the initial access procedure by sending a conflict resolution message ("Msg4") (209). Alternatively, WTRU102 can determine that the initial access procedure failed if it does not receive Msg4.

[0103] The four-step initial access procedure 200 is applicable to both NR and NTN, but such a procedure 200 can be adapted to the differences between NR and NTN. Alternatively, modifying a procedure 200 adapted for NR for NTN (and vice versa) is not straightforward due to various differences between NTN and NR, including the need to support longer round-trip times (RTT) between WTRU102 and the network, and the possibility of supporting larger cell sizes (e.g., cell radii up to 1000 km) associated with NTN integration.

[0104] The transmission delay in NR can be very small and negligible compared to other delays due to processing time. As a result of the slight transmission delay in NR, WTRU102 can determine the transmission slot of the DL signal when it receives the MIB and / or SIB1, and then identify the resources to be used to transmit Msg1 and the time (RAR window) to monitor Msg2 at that time / in between, as indicated by / SIB1 in SIB1.

[0105] Due to the long RTT in NTN, performing the NR-adapted initial access procedure 200 as an initial access procedure to the integrated NTN may introduce ambiguity in the resources used for such a procedure. For example, WTRU102 may not be able to accurately identify the resources used to transmit Msg1 and / or the time (RAR window) to monitor Msg2, as the timing for Msg1 and Msg2 may change based on the RTT received by the WTRU. Similarly, due to RTT and Doppler shift, the network may determine that Msg1 was received on resources different from those actually used by WTRU102, and as a result may miscalculate or otherwise determine the RA-RNTI for scrambling Msg2, potentially sending a mis-scrambled Msg2 and / or being unable to send Msg2 within the expected time frame (RAR window). If the network uses one value for RA-RNTI to scramble Msg2, and WTRU102 uses a different value for RA-RNTI to descramble Msg2, WTRU102 may not receive Msg2 and / or be unable to decrypt it, which could result in a failure of the initial access procedure.

[0106] NTN satellites can travel at speeds of up to 7 km / s (for example, in low Earth orbit (LEO)). Depending on the relative position of the WTRU and the satellite, the signals transmitted to and from the WTRU may have significantly shifted receive / transmit frequencies, which may not be beneficial to the WTRU and gNB for the decoding process. Doppler shift pre-compensation can be implemented in various embodiments. To support the WTRU in implementing Doppler pre-compensation, information such as satellite velocity and position can be exchanged between the WTRU and the network.

[0107] In NTN, the WTRU may require a very long wait between Msg1 and Msg2. In NTN, it may be beneficial to apply a two-step RACH procedure. A possible two-step RACH procedure is one in which Msg1 and Msg3 are combined as MsgA, and Msg2 and Msg4 are combined as MsgB.

[0108] Similarly, various 4-step RACH procedures can be considered for NTN. Furthermore, 4-step RACH procedures for NTN can be beneficial in various ways, including, for example, maximizing the probability of access and / or minimizing delay (e.g., latency).

[0109] In this embodiment, the WTRU can determine the System Frame Number (SFN) of the NTN based on various pieces of information. This information may include any of the following: Global Navigation Satellite System (GNSS) timing, M / SIB1 information, and offsets.

[0110] In this embodiment, the WTRU can determine the DL transmission timing based on any of the following information received from NTN: (i) the time offset T between the GNSS time and the DL SFN0. offset (ii) The timing offset between the GNSS time and the time information indicated by the SIB1 information.

[0111] In the embodiment, the network has a time offset T between its SFN and GNSS time. offset It can be shown that T offset The value can be sent by MIB and / or SIB1 to assist the WTRU in the initial access procedure. The WTRU can determine the DL transmission time and RTT by comparing the time the SIBI was received with the time information indicated by / in the SIBI information. For example, the WTRU can compare the WTRU GNSS time (e.g., locally determined) and the T indicated in the M / SIB information. offsetBy using these values, the network's time frame can be determined. After decoding the timing information in the M / SIB information, the WTRU can determine the exact time the network sent the SIB1 and the time delay before sending the SIB1.

[0112] In the embodiment, the WTRU can send its estimated timing to the network based on the PRACH prinble and / or resource selection.

[0113] In embodiments, the WTRU can send TA information to the network to support the network in the scheduling of Msg3 and / or in further scheduling. The WTRU can implicitly send TA information. The WTRU can send, for example, RTT, transmit delay, and an offset between the RTT or transmit delay and a predefined value.

[0114] Predefined values ​​can be sent to the WTRU via the MIB and / or SIB. Alternatively, predefined values ​​can be pre-configured based on the satellite type.

[0115] WTRU can implicitly send TA information to the network in Msg1. For example, WTRU can send TA information by selecting one of the following: PRACH resource, PRACH group, PRACH format, and PRACH configuration.

[0116] In this embodiment, the WTRU can be configured using multiple PRACH resources (e.g., time and frequency) to transmit Msg1. Each PRACH resource can be associated with a range of TA.

[0117] In this embodiment, the WTRU can be configured using multiple PRACH preamble groups. Each PRACH preamble group may correspond to a range of TAs (e.g., one). Based on the estimated TA values, the WTRU can select an appropriate PRACH resource and / or PRACH preamble group. The WTRU may also select a default preamble group and / or resource, for example, if TA information is not carried in Msg1. This technique can support non-GNSS WTRUs that may not have TA information between the network and themselves.

[0118] In embodiments, a WTRU may be configured using one or more PRACH configurations (e.g., statically, semi-statically, and / or dynamically). Any PRACH configuration may define, indicate, and / or include a preamble format and / or a PRACH opportunity duration ("PRACH-Opportunity Duration"). The preamble format may define, indicate, and / or include one of the following: the length of the preamble sequence, the number of iterations, a cyclic prefix, a guard period, etc. The PRACH-Opportunity Duration may define, indicate, and / or include the time between two consecutive PRACH opportunities.

[0119] In the embodiment, the WTRU can select a PRACH configuration based on its functions and information in / provided in the M / SIB information. In the embodiment, the WTRU can select a PRACH configuration to transmit Msg1 based on whether the WTRU is a GNSS-based WTRU, satellite type, minimum transmission delay, maximum transmission delay, WTRU priority level, QoS of data in the Media Access Control (MAC) layer buffer, Doppler compensation capabilities, and the WTRU's TA (e.g., TA estimation).

[0120] In the embodiment, the WTRU can select one or more PRACH configurations depending on its ability to estimate the transmit delay. For example, if the WTRU is not equipped with a GNSS receiver and / or cannot accurately estimate the transmit delay (e.g., cannot), the WTRU can select a PRACH configuration with a longer sequence length and / or a higher number of iterations. Alternatively, for example, if the WTRU is equipped with GNSS and can accurately estimate the transmit delay, the WTRU can select a PRACH configuration with a shorter sequence length and / or a lower number of sequence iterations.

[0121] In the embodiment, the WTRU can select a preamble group based on the location of the PRACH resource. In the embodiment, the WTRU can select different preamble groups based on the location of the PRACH resource within the delay difference period. The delay difference period can be defined as the maximum delay difference in the beam, based on the maximum delay difference in the beam, or a function of the maximum delay difference in the beam. This technique allows the network to determine which PRACH resource is used by the WTRU to transmit Msg1, since the WTRU cannot have the precise timing of the uplink frame. By selecting PRACH resources in the same group for different PRACH time resources, the network and the WTRU may interpret the PRACH time resources differently. As a result, the WTRU may fail to decode the control resource set (CORESET) for Msg2.

[0122] In the embodiment, if the WTRU is a high-priority WTRU and / or has high QoS requirements for data in the MAC layer buffer, it may select a PRACH configuration with a longer sequence length and / or a higher number of iterations. In the embodiment, if the WTRU is a low-priority WTRU, it may select a PRACH configuration with a shorter sequence length and / or a lower number of sequence iterations.

[0123] In the embodiment, the WTRU can determine the delay difference period. In the embodiment, the WTRU can determine the delay difference period (such as as a function thereof) based on one of the following: the maximum delay difference in the beam, the PRACH configuration period, the synchronization signal block (SSB) period, and a pre-configured value based on the satellite type.

[0124] In the embodiment, the maximum delay difference within the beam may be transmitted to the WTRU via the network through the MIB and / or SIB1. In the embodiment, the PRACH configuration period may be communicated to the WTRU via SIB1. In the embodiment, the synchronization signal block (SSB) period may be pre-configured or communicated to the WTRU via SIB1. In the embodiment, the start of the delay difference period may be determined based on the time the WTRU receives SIB1 or the first opportunity for the PRACH resource.

[0125] In the embodiment, the WTRU can determine the number of preamble groups N_pg based on any of the following: the number of PRACH resources in the delay difference period, the number of PRACH counts in the delay difference period, and the number of PRACH frequencies in the delay difference period.

[0126] The number of preambles within a preamble group can be the same for different preamble loops. The mapping between PRACH resources and preamble groups can follow predefined rules for indexing preamble groups and PRACH resources. Indexing of PRACH resources can follow a sequential order of time and frequency, or a sequential order of frequency and time.

[0127] Figure 3 is a system resource (time and frequency) diagram 300 showing an exemplary allocation of preamble groups to SSB ("Preamble Group Allocation"). As shown in the diagram, resource diagram 300 shows the first (time) SSB 301 ncan include, and then, a second (time-based) SSB 301 n+1 follows, and SSB 301n is followed by a first preamble group 305-1, a second preamble group 305-2, a first delay difference period 307-1, and a second delay difference period 307-2. Although not shown, the resource diagram 300 can include a PRACH selection window after each of SSB 301 n , SSB 301 n+1 .

[0128] Referring to FIG. 3, the WTRU 102 can detect SSB 301 n and can also decode and read SIB1 for SSB 301 n . Based on the reading of the information from SIB1, the WTRU 102 can obtain the PRACH configuration indicated by SIB1. The WTRU 102 can divide the PRACH selection window into one or more delay difference periods. The WTRU can determine two possible times for transmitting Msg1 within the delay difference period. The WTRU can determine the number of preamble groups based on the number of possible PRACH occurrences within the delay difference period. Since there are two possible occurrences for transmitting Msg1 within the delay difference period, the WTRU can divide the set of preambles into two equal-sized preamble groups, namely, the first and second preamble groups 305-1, 305-2. As shown, the first preamble group 305-1 can be assigned to the first possible time for PRACH transmission, and the second preamble group 305-2 can be assigned to the second possible time for PRACH transmission. If the number of PRACH preambles assigned to an SSB is N_preamble, the size of each PRACH group is N_preamble / N_pg. When applied to the example of FIG. 3 where N_pg = 2 and N_preamble = 64, 32 (i.e., 64 / 2 = 32) of the 64 preambles are assigned to each of the first and second PRACH preamble groups.

[0129] In one embodiment, the WTRU may be configured to select one or more preamble groups based on the location of the PRACH resource within the delay difference period and its associated SSB. This technique allows the WTRU to inform the network using its intended SSB if multiple SSBs are supported.

[0130] In the embodiment, the WTRU can be configured to have access to all possible PRACH opportunities. The WTRU can be configured to determine the total number of PRACH preambles assigned to it by dividing the total number of preambles assigned to each PRACH opportunity by the total number of SSBs. The initial index associated with the SSB and PRACH opportunity can be calculated based on the index of the intended SSB and the location of the PRACH opportunity. The WTRU can be configured to inform the network of the intended SSB.

[0131] In the embodiment, the WTRU can select its PRACH opportunity and PRACH group based on its associated SSB and its selected PRACH opportunity during the delay difference period, respectively. For example, the WTRU can be configured to sequentially associate PRACH opportunities with SSBs. Alternatively, for all PRACH opportunities, the WTRU can be configured to select different preamble groups based on the time of the PRACH resources during the delay difference period.

[0132] Figure 4 is a system resource (time and frequency) diagram 400 showing an exemplary preamble group assignment for an SSB set. As shown, resource diagram 400 may include an SSB set 401, a first preamble group 405-1, a second preamble group 405-2, a first delay difference period 407-1, and a second delay difference period 407-2. Although not shown, resource diagram 400 may include a third delay difference period after the second delay difference period, and a PRACH selection window after each instance of SSB set 401.

[0133] Referring to Figure 4, SSB set 401 can include first and second SSBs 401-1 and 401-2. The total number of PRACH time instances associated with the two SSBs can be equal to 6 (for example, as shown in the figure). The WTRU can associate the first SSB 401-1 with 3 PRACH time instances, and the second 401-2 with 3 PRACH time instances. The WTRU can divide the PRACH selection window into one or more delay difference periods. The WTRU can select any of the possible PRACH time instances associated with the selected SSB 401-1 and 401-2. The WTRU can select one PRACH opportunity in one PRACH time instance to send Msg1. Based on the time instance of a selected PRACH opportunity contained within either delay difference period 407-1 or 407-2, the WTRU can select either the first preamble group 405-1 or the second preamble group 405-2.

[0134] In the embodiment, WTRU102 can select a preamble group and preambles within the group based on a selected delay difference period. In the embodiment, WTRU102 can be configured using a set of preambles. WTRU102 can divide its PRACH selection window into one or more delay difference periods, in which case each period can be associated with one preamble group. When WTRU102 selects a PRACH location for sending Msg1, WTRU can select an appropriate preamble depending on the selected delay difference period.

[0135] Figure 5 is a system resource (time and frequency) diagram 500 showing an exemplary preamble group assignment in the PRACH selection window. As shown in the figure, resource diagram 500 is the second (time) SSB501 n+1 The first (time) SSB501 followed byn SSB501 n The following PRACH selection window 503 may include the first preamble group 505-1, the second preamble group 505-2, the first delay difference period 507-1, the second delay difference period 507-2, and the third delay difference period 507-3. Although not shown, resource diagram 500 is SSB501 n+1 A PRACH selection window can be included afterwards.

[0136] Referring to Figure 5, WTRU102 can divide the PRACH selection window into three delay difference periods. If WTRU sends Msg1 in delay difference period 507-1 and delay difference period 507-3, WTRU102 can select the first preamble group 505-1; otherwise, if WTRU102 selects delay difference period 507-2, it can select preamble group 505-2.

[0137] In the embodiment, WTRU105 can select a preamble group based on the selected SSB and delay difference period. For example, WTRU102 can sequentially associate PRACH opportunities with SSBs. Furthermore, for all PRACH opportunities, WTRU can select a different preamble group based on its selected delay difference period.

[0138] Figure 6 is a system resource (time and frequency) diagram 600 showing an exemplary preamble group assignment for an SSB set. As shown, resource diagram 600 may include an SSB set 601, a first preamble group 605-1, a second preamble group 605-2, a first delay difference period 607-1, and a second delay difference period 607-2. Although not shown, resource diagram 600 may include a third delay difference period after the second delay difference period, and a PRACH selection window after each instance of SSB set 601.

[0139] Referring to Figure 6, SSB set 601 can include first and second SSBs 601-1, 601-2. The number of PRACH time instances associated with the two SSBs 601-1, 601-2 is equal to 6 (as shown, for example). WTRU102 can associate the first SSB 601-1 with 3 PRACH time instances, and the second SSB 601-2 with 3 PRACH time instances. WTRU102 can divide the PRACH selection window into one or more delay difference periods. WTRU102 can select one of the PRACH time instances associated with the selected SSB 601-1, 601-2. WTRU102 can select one PRACH opportunity and send Msg1. Based on which of the delay difference periods 607-1 or 607-2 contains the selected PRACH opportunity, WTRU102 can select either the first preamble group 605-1 or the second preamble group 605-2.

[0140] In one embodiment, the WTRU can be configured to select a different frequency for transmitting Msg1 based on its PRACH transmission time within the delay difference period. This technique can avoid misunderstandings between the network and the WTRU in the calculation of RA-RNTI. The initial frequency for a PRACH can be carried to the WTRU via SIB1. Based on the time index of PRACH opportunities within the delay difference period, the WTRU can determine the frequency for transmitting Msg1. This frequency can be determined as f = finit + PRACHindex * Δf, where finit is the initial frequency of the PRACH indicated by / in SIB1, and Δf is the frequency resource for each PRACH.

[0141] Figure 7 is a system resource (time and frequency) diagram 700 showing an exemplary preamble group allocation. As shown, resource diagram 700 is the first (time) SSB701 n This includes, followed by the second (time) SSB701 n+1This can then include six PRAH resources 711-1 to 711-6, a first delay difference period 707-1, and a second delay difference period 707-2.

[0142] Referring to Figure 7, WTRU102 can be configured to have at least three PRACH transmissions within a first delay difference period 707-1. Based on the time index within the delay difference period 707-1, WTRU102 can select an appropriate frequency for transmitting Msg1. Selecting a different frequency for each PRACH transmission time within the delay difference period allows gNB to identify the time resources that WTRU uses for PRACH transmissions.

[0143] Figure 8 is a flowchart illustrating an exemplary procedure ("Preamble Group Assignment Procedure") 800 for performing preamble group assignment. For ease of explanation and for simplicity, the Preamble Group Assignment Procedure 800 is presented from the perspective of WTRU 102. Those skilled in the art will understand that the Preamble Group Assignment Procedure 800 may be performed using system resources other than or different from those disclosed herein, and / or from other or different perspectives and architectures.

[0144] WTRU102 can receive differential delay information and PRACH configuration information (801). Differential delay information and PRACH configuration information can be received from NTN network elements. PRACH configuration information may indicate the set of preambles and PRACH opportunity configuration. Differential delay information may be and / or include the maximum delay difference.

[0145] Based on differential delay information, WTRU102 can determine a set of candidate PRACH opportunities from among multiple PRACH opportunities in the PRACH opportunity configuration (803). WTRU102 can select a preamble from the preamble group assigned to one of the candidate PRACH opportunities in the set of candidate PRACH opportunities (805). WTRU102 can send the selected preamble using the RACH resource corresponding to the one candidate PRACH opportunity (807).

[0146] In various embodiments, WTRU102 can at least partially determine a set of candidate PRACH opportunities by determining a set of candidate PRACH opportunities within a single delay difference period from among multiple PRACH opportunities in a PRACH opportunity configuration. In various embodiments, WTRU102 can determine the number of preamble groups based on the number of PRACH resources included in the delay difference period.

[0147] In various embodiments, WTRU102 can assign a preamble group (e.g., one of several preamble groups) to a candidate PRACH opportunity. In various embodiments, WTRU102 can assign a preamble group to a candidate PRACH opportunity based on a rule. In various embodiments, the rule may specify that one segment of a set of preambles should be assigned. In various embodiments, a preamble group can be assigned to a candidate PRACH opportunity based on a configured mapping. In various embodiments, a preamble group may be a subset of a set of preambles. In various embodiments, WTRU102 can assign each group of preambles to a candidate PRACH opportunity.

[0148] In various embodiments, WTRU102 can randomly select one candidate PRACH opportunity from a set of candidate PRACH opportunities. In various embodiments, WTRU102 can determine one candidate PRACH opportunity from a set of candidate PRACH opportunities based on a group of preambles assigned to one candidate PRACH opportunity that includes a preamble having a specific characteristic. In various embodiments, WTRU102 can determine one candidate PRACH opportunity from a set of candidate PRACH opportunities based on a second group of preambles assigned to another candidate PRACH opportunity that lacks a preamble lacking a specific characteristic.

[0149] Figure 9 is a flowchart illustrating an exemplary preamble group assignment procedure 900. For ease of explanation and for simplicity, the preamble group assignment procedure 900 is presented from the perspective of WTRU 102. Those skilled in the art will understand that the preamble group assignment procedure 900 may be performed using system resources other than or different from those disclosed herein, and / or from other or different perspectives and architectures.

[0150] WTRU102 can receive differential delay information and PRACH configuration information (901). Differential delay information and PRACH configuration information can be received from NTN network elements. PRACH configuration information may indicate the set of preambles and PRACH opportunity configuration. Differential delay information is and / or may contain the maximum delay difference.

[0151] WTRU102 can determine the delay difference period based on the differential delay information (903). Based on the delay difference period, WTRU102 can determine a set of candidate PRACH opportunities for the PRACH opportunity configuration (905). WTRU102 can assign a preamble group to each candidate PRACH opportunity in the set of candidate PRACH opportunities (907). WTRU102 can select a preamble from the preamble group assigned to one candidate PRACH opportunity in the set of candidate PRACH opportunities (909). WTRU102 can send the selected preamble using the PRACH resource corresponding to one candidate PRACH opportunity (911).

[0152] The preamble group assignment procedure 900 in Figure 9 is similar to the preamble group assignment procedure 800 in Figure 8. Those skilled in the art will understand that the various embodiments disclosed in relation to the preamble group assignment procedure 800 in Figure 8 are equally applicable as various embodiments of the preamble group assignment procedure 900 in Figure 9. In addition, those skilled in the art will understand that the various embodiments disclosed below are applicable to both the preamble group assignment procedures 800 and 900.

[0153] In various embodiments, the WTRU 102 can determine one candidate PRACH opportunity from a set of candidate PRACH opportunities based on a group of preambles assigned to one candidate PRACH opportunity corresponding to the range of timing advance between the WTRU and the network.

[0154] In various embodiments, a set of candidate PRACH opportunities can be associated with an SSB. In various embodiments, the WTRU102 can inform the network of the estimated TA.

[0155] In various embodiments, WTRU102 can select at least one frequency resource to transmit a selected preamble. In various embodiments, WTRU102 can select a PRACH resource corresponding to a candidate PRACH opportunity based on frequency hopping configured by the network, and can use that PRACH resource to transmit the selected preamble.

[0156] In various embodiments, WTRU102 can determine the RA-RNTI based on the PRACH resource. In various embodiments, WTRU102 can decode Msg2 using the determined RA-RNTI.

[0157] In an embodiment, the WTRU can perform Doppler pre-compensation based on velocity vectors transmitted by the network. In an embodiment, the WTRU may be configured to perform Doppler pre-compensation using information received from the network, and / or information estimated by and / or pre-configured by the WTRU. Information received from the network may include, for example, velocity vectors, and maximum and / or minimum distances. Information estimated by and / or pre-configured by the WTRU may include, for example, TA and satellite ephemeris.

[0158] In the embodiment, the WTRU can receive Doppler shift compensation information (e.g., Doppler shift compensation commands, other trigger information, etc.) from the gNB (or other access node). After receiving the Doppler shift compensation information (e.g., upon reception), the WTRU can perform Doppler pre-compensation. The WTRU can receive Doppler shift compensation information from the gNB in ​​any of the Layer 1 (L1), Layer 2 (L2), or Layer 3 (L3) signaling, such as a MAC control element (CE) or a Radio Resource Control (RRC) message. After receiving the Doppler shift compensation information (e.g., upon reception), the WTRU can adjust the Doppler shift pre-compensation, possibly using the previous pre-compensated Doppler shift from the gNB and / or the pre-compensated Doppler shift from the last UL transmission as a reference. Doppler shift pre-compensation techniques can help reduce mutual frequency interference in variously scheduled resources.

[0159] According to various embodiments disclosed herein, RA-RNTI can be determined in various ways. In embodiments, WTRU can determine RA-RNTI based on a selected PRACH configuration. In embodiments, WTRU can calculate RA-RNTI using time and frequency indices of PRACH opportunities. This method can reduce the number of RA-RNTI used. In embodiments, WTRU can follow the following formula for RA-RNTI: RA - RNTI = C + t index +X*f index (1) In the formula, C is a constant, and t index ,f index is the time and frequency index of the PRACH opportunity, and X can be determined based on one of the following:

[0160] X is based on the maximum time and frequency index of all possible PRACH configurations.

[0161] X is based on the maximum time and frequency index of the current PRACH configuration.

[0162] X is pre-configured.

[0163] In this embodiment, RA-RNTI can be calculated as follows: RA-RNTI=C+f index +Y*t index (2) In the formula, C is a constant, and t index ,f index is the time and frequency index of the PRACH opportunity, and Y can be determined based on any of the following combinations:

[0164] Y is based on the maximum time and frequency index of all possible PRACH configurations.

[0165] Y is based on the maximum time and frequency index of the current PRACH configuration.

[0166] Y was pre-configured.

[0167] According to one embodiment, the WTRU can determine an initial frame for time indexing.

[0168] WTRU is RAR Windows F, which the network hopes to support. R Based on the duration of t index The initial frame for time indexing, or the initial frame for RA-RNTI calculation, can be determined. In this embodiment, the frame index from which the WTRU sends Msg1 can be calculated as follows:

[0169]

number

[0170] During the ceremony, PRACH frameThe WTRU indicates the SFN that can send Msg1. The WTRU is t index The initial frame for indexing and / or the initial frame for RA-RNTI calculation is the frame prior to the current SFN. index It can be determined that this is -1 frame.

[0171] In the embodiment, the WTRU can determine the time index of the selected PRACH location.

[0172] In this embodiment, the WTRU can determine the time index of any PRACH time opportunity. This technique can be interesting when the network and the WTRU have a common understanding of the intended PRACH location to which the WTRU sent.

[0173] In the embodiment, the WTRU can determine the time index of any delay difference period. This technique allows the network to group all Msg1 transmissions at a single frequency and within a delay difference period into a single RA-RNTI value. For example, as shown in Figure 10, each delay difference period consists of two PRACH time instances. Therefore, two PRACH time instances within a single delay difference period have the same index.

[0174] In an alternative approach, the WTRU may be configured to decode Msg2 using multiple RA-RNTIs within the delay difference period. Specifically, the WTRU can determine the number of PRACH time instances within the delay difference period in which it sends Msg1. The WTRU can then compute all possible RA-RNTIs within the delay difference period. These RA-RNTIs can then be used to descramble Msg2 during the random access response period. This approach allows the WTRU to consider the delay difference of WTRUs served by a single SSB.

[0175] According to various embodiments disclosed herein, it is possible to reduce delays that contribute to the amount of time required to perform the initial access procedure, and / or increase the probability of access (e.g., fewer unsuccessful access attempts). In embodiments, a WTRU can transmit multiple Msg1 transmissions before receiving Msg2. In embodiments, a WTRU can decide to transmit N Msg1s before each RACH opportunity, and the WTRU can transmit such N Msg1s over M RACH opportunities. A WTRU can apply various (e.g., different) power adjustments to make different transmissions of Msg1. Power adjustments can be determined based on assumptions about the PRACH location and / or delays between the WTRU and the network. This allows the WTRU to adjust the transmission power of Msg1 if different delays are assumed by the WTRU.

[0176] The WTRU can be configured using the maximum values ​​of M and N. The M and N values ​​included in its configuration range can be determined based on one of the following: the WTRU's function in delay estimation, the minimum and / or maximum transmission delay, the QoS of the data, the WTRU's priority level, the number of applicable PRACH sequences, and the PRACH configuration.

[0177] In this embodiment, the WTRU can send one Msg1 in one PRACH opportunity if it can accurately estimate the transmission delay. The transmission delay can be obtained using GNSS information. Alternatively, as shown in Figure 11, for example, the WTRU can send several Msg1 before one PRACH opportunity, and across multiple PRACH opportunities if the transmission delay cannot be accurately estimated by the WTRU.

[0178] In the embodiment, the WTRU can determine whether to perform a two-step RACH procedure or a four-step RACH procedure based on any of the following: whether the WTRU is a GNSS-based WTRU, i.e., a satellite type that is targeted and / or accessible; the minimum transmission delay; the maximum transmission delay; the QoS of the data; the priority level of the WTRU; the number of available PRACH sequences; the configuration of the PRACH; the Doppler compensation capability; and the size of Msg3.

[0179] In the embodiment, assuming a GNSS receiver and appropriate processing are provided, the WTRU can perform a two-step RACH procedure if it can accurately determine the timing and data of the PRACH opportunity. In the embodiment, the WTRU can perform a four-step RACH procedure if it cannot accurately estimate the transmit delay. If the WTRU cannot accurately estimate the transmit delay, abandoning the use of the two-step RACH procedure can increase the probability of success of the two-step RACH procedure, as it avoids a situation where the WTRU does not have accurate timing for data transmission, and subsequently the network cannot accurately receive and / or decode the transmitted data.

[0180] In the embodiment, a WTRU may perform a two-step RACH if it is a high-priority WTRU and / or has high QoS data in its data buffer. In the embodiment, a WTRU may perform a four-step RACH if it is a low-priority WTRU and / or has low QoS data in its buffer. Not using the two-step RACH procedure when a WTRU is a low-priority WTRU and / or has low QoS data in its buffer allows for prioritization of high-priority WTRUs when accessing the network during the initial access procedure, and allows for avoidance of low-priority WTRUs by using data resources dedicated to high-priority WTRUs.

[0181] In this embodiment, the WTRU can perform two-step and four-step RACH procedures before monitoring the RAR. For example, the WTRU can perform both two-step and four-step RACH procedures by sending one Msg1 and one MsgA, where Msg1 is for a RACH opportunity following a four-step RACH configuration, and MsgA is sent for a RACH opportunity following a two-step RACH configuration. The WTRU may decide to perform both two-step and four-step RACH procedures based on any of the following: whether the WTRU is a GNSS-based WTRU, minimum transmission delay, maximum transmission delay, data QoS, WTRU priority level, number of available PRACH sequences, PRACH configuration, Doppler compensation capability, and the size of Msg3.

[0182] In an embodiment, the WTRU can determine the RACH configuration to send one of several messages, such as MsgA. In an embodiment, the WTRU can be configured with various parameters from which it selects a RACH configuration for sending MsgA. Such parameters may include, for example, the preamble index, resources for preamble transmission, the number of preamble transmissions, resources for PUSCH in MsgA, the number of PUSCH transmissions, the redundant version (RV) sequence, the association between the preamble and PUSCH, the transmit power of PUSCH (e.g., maximum transmit power, calculated transmit power, etc.), and / or the modulation coding scheme (MCS) for PUSCH.

[0183] In the embodiment, one of several parameters can be selected based on one factor or a combination thereof. Such factors may include, for example, the type of WTRU, the class of the WTRU, whether the WTRU has GNSS capabilities, whether the WTRU has the capability to estimate TA, position, etc. (e.g., whether a particular capability exists and / or is sufficient to make an accurate estimate), Doppler compensation capability, the size of MsgA (e.g., number of bits), the estimated TA, and the predicted TA.

[0184] In some embodiments, the WTRU can determine the number of PUSCHs and / or the number of preamble transmissions based on the estimated TA and / or the accuracy of the estimated TA. For example, the WTRU may decide (and use) to use one preamble and one or more PUSCH transmissions based on the fact that the WTRU has the capability to accurately estimate and / or be able to estimate the TA (e.g., conditionally). In another example, the WTRU may decide (and use) to use one preamble with multiple PUSCH transmissions based on the fact that the WTRU does not have the capability to accurately estimate and / or is unable to estimate the TA (e.g., conditionally). In yet another example, the WTRU may decide (and use) to use multiple preambles with one PUSCH transmission based on the fact that the WTRU does not have the capability to accurately estimate and / or is unable to estimate the TA (e.g., conditionally). In yet another example, a WTRU may decide (and use) to use multiple transmissions of both the preamble and the push, based on the fact that the WTRU does not have the capability to accurately estimate the TA and / or is unable to do so (for example, conditionally).

[0185] In the example above, the parameters and factors refer to the number of preambles and / or the number of PUSCH transmissions, along with the estimated TA. However, the WTRU can use parameters and factors other than the number of preambles, the number of PUSCH transmissions, and the estimated TA to determine the RACH configuration for transmitting MsgA. For example, the WTRU can determine the MCS of a PUSCH based on the estimated TA. If the estimated TA is relatively large, the WTRU can decide to use a relatively small MCS index in the MCS table, and if the estimated TA is relatively small, it can decide to use a relatively large MCS index. In another example, the WTRU can determine the transmit power of a PUSCH based on the estimated TA. For example, if its estimated TA is relatively high, the WTRU can decide to use a relatively high power, and if its estimated TA is relatively low, it can decide to use a relatively low power.

[0186] In the embodiment, the WTRU can disclose (or report) its estimated TA to the network. The WTRU can inform the network of the estimated TA, for example, using MsgA. Informing the network of the estimated TA can provide various benefits, including the ability to support gNB in, for example, scheduling HARQ ACK / NACK for MsgB and / or in scenarios where decoding MsgA is unsuccessful.

[0187] A WTRU can explicitly and / or implicitly inform the network of the estimated TA. In an embodiment, the WTRU may include the estimated TA in the MsgA's PUSCH. Alternatively, the WTRU may include an index on a table of estimated TAs in the MsgA's PUSCH. The index may, for example, indicate one or more ranges of the estimated TA within multiple ranges in the table. In an embodiment, the WTRU can implicitly inform the network of its estimated TA by using specific parameters or combinations of specific parameters to the MsgA. For example, the WTRU may use a fixed preamble index (such as a fixed preamble resource), where the preamble index (such as a preamble resource) is associated with a range of the estimated TA. In another example, the WTRU may use a combination of a preamble index and a preamble resource, where the combination of the preamble index and the preamble resource is associated with a range of the estimated TA.

[0188] In the example above, the parameters refer to the preamble index and preamble resource, but a WTRU can implicitly inform the network of its estimated TA using parameters other than and / or in addition to the preamble index and preamble resource. For example, a WTRU can implicitly inform the network of its estimated TA using a selected preamble format, preamble route sequence, preamble cyclic prefix, etc.

[0189] In the embodiment, the WTRU can determine one or a combination of transmission characteristics used to transmit and / or retransmit MsgA. Some or all of the transmission characteristics can be based on the reception conditions of MsgB. The reception conditions of MsgB can be any of the following:

[0190] No MsgB (for example, WTRU does not receive PDCCH (scrambled by RA-RNTI) within the MsgB window).

[0191] MsgB decryption fails (for example, WTRU successfully decrypts the PDCCH scrambled by RA-RNTI in the MsgB window, but fails to decrypt the corresponding PDSCH).

[0192] MsgB indicates an ACK to the preamble and a NACK to PUSCH.

[0193] MsgB indicates NACK to the preamble and ACK to PUSCH.

[0194] MsgB indicates an ACK to both the preamble and PUSCH.

[0195] The various transmit characteristics available for use by the WTRU may include any of the following: performing a power boost on the preamble, adjusting the transmit power (e.g., increasing / decreasing), adjusting the MCS for PUSCH (e.g., decreasing / increasing the data rate), switching from 2-step RACH to 4-step RACH (e.g., transmitting only the preamble), adjusting the number of PUSCH transmissions (e.g., increasing / decreasing), adjusting the number of preamble transmissions (e.g., increasing / decreasing), adjusting the estimated TA value, using a different resource configuration for MsgA, selecting a specific preamble format, and using or switching to a different (e.g., different) preamble format.

[0196] For example, a WTRU may increase the number of PUSCH and / or preamble transmissions based on (or on) the fact that it has not received an MsgB ("no MsgB" situation) and / or has failed to decode an MsgB ("failed to decode MsgB" situation). Increasing the number of PUSCH and / or preamble transmissions can provide various benefits, including, for example, increasing the probability of receiving an MsgA. Alternatively, a WTRU may use a different preamble format and / or a different resource configuration for the preamble transmission in an MsgA.

[0197] As previously disclosed herein, a WTRU can initiate an initial access procedure by sending Msg1 (e.g., a RACH preamble) to the network. In embodiments, the WTRU can determine the transmit power TxP for Msg1 based (at least partially) on various satellite information received from the network, for example. The satellite information may include any of the following: target power information elements (IE) to which the preamble is received, power rise step IE, satellite transmit power ("Sat Tx power") IE, satellite type IE, altitude IE, speed IE, and ephemeris data IE.

[0198] The target power IE from which the preamble is received can specify the target power to be received for each of one or more satellites (e.g., in dB). The power rise step IE can specify one or more power rise steps for each of one or more satellites (e.g., each has a power with a sign indicating an increase or decrease of a specified power (e.g., in dB)).

[0199] Sat Tx power IE can specify the power (e.g., in dB) for each of the various signals transmitted from the associated satellites for each of one or more satellites. These various signals may include reference signals such as synchronization signals.

[0200] The satellite type IE can specify one or more satellite types, such as geostationary orbit (GEO), medium Earth orbit (MEO), low Earth orbit (LEO), and high-altitude pseudo-satellite (HAPS). The altitude IE can specify one or more altitudes for each of the one or more satellites associated with that satellite. Altitudes can include, for example, current altitude, past altitude, and future altitude. The altitude IE can include different precision values ​​for some or all of the specified altitudes.

[0201] A velocity IE can specify one or more velocities for each of one or more satellites. Each velocity can be specified as a velocity relative to Earth. Velocities can include, for example, current velocity, past velocity, and future velocity. A velocity IE can include different precision values ​​for some or all of the specified velocities.

[0202] An ephemeris IE can specify one or more ephemeris data for each of one or more satellites, and for each of the associated satellites. The ephemeris data can include, for example, ephemeris data received from the associated satellites and / or long-term ephemeris data. The ephemeris data IE can include different precision values ​​for some or all of the specified ephemeris data.

[0203] Satellite information can be transmitted via a network and received by a WTRU in any of the Layer 1 (L1), Layer 2 (L2), and Layer 3 (L3) signaling (e.g., one or more information elements (IEs)). For example, satellite information can be transmitted via a network and received by a WTRU in a dedicated SIB (or other IE), or in system information in an MIB and / or one or more SIBs. For example, the target power IE and power rise step IE, in which the preamble is received, can be transmitted via a network and received by a WTRU in SIB2, while satellite type, altitude, speed, and ephemeris data IE can be transmitted via a network and received by a WTRU in the MIB and one or more other SIBs.

[0204] In the embodiment, the WTRU can determine the received power based on a reference signal. The determined received power may be, for example, the reference signal received power (RSRP). For simplicity of explanation, it is assumed below that the reference signal to be measured is a synchronization signal, and the determined received power is the RSRP of the synchronization signal (hereinafter referred to as "SS-RSRP").

[0205] In this embodiment, the WTRU can estimate the path loss (PL) based on the Sat Tx power IE and SS-RSRP (for example, as a function thereof), for example, by the following: PL=Sat Tx Power-SS-RSRP (4) The estimated PL may be valid at the corresponding time t1 when the synchronization signal was measured in connection with determining the SS-RSRP. However, due to mobility, satellite velocity (especially for LEO satellites and similar), and other factors, the estimated PL may not reflect (e.g., not accurately reflect) the PL between the WTRU and the satellite at time t2, when Msg1 is intended and / or expected to reach the satellite. Using a PL that reflects the PL between the WTRU and the satellite at time t2 will ensure that the transmit power TxP for Msg1 is set appropriately and that unnecessary retransmissions of Msg1 and / or transmissions of other WTRUs (e.g., due to an interfering transmit power TxP for Msg1) are avoided.

[0206] In an embodiment, the WTRU can predict the PL at time t2 based on (e.g., using and / or a function thereof) any of the following: the calculated distance to the relevant satellite at time t1, the estimated PL at time t1, and the predicted distance to the satellite at time t2. For example, the predicted PL may be based on the ratio of the calculated distance to the predicted distance applied to the estimated PL. In an embodiment, the WTRU can calculate its distance from the satellite at time t1 based on satellite information, such as satellite altitude and ephemeris data IE. The WTRU can predict its distance from the satellite at time t2 based on information such as the WTRU's orbit, satellite altitude IE, velocity IE, and ephemeris data IE, such as (e.g., using).

[0207] In this embodiment, the WTRU can calculate two transmit powers TxP1 and TxP2. The first and second transmit powers TxP1 and TxP2 can be based, for example, on an estimated PL and a predicted PL, respectively. The first and second transmit powers TxP1 and TxP2 can be calculated, for example, as follows: TxP1(t1) = Target power at which the preamble is received + PL(t1) (5) TxP2(t2) = Target power at which the preamble is received + PL(t2) (6) In the formula, the target power at which the preamble is received can be obtained from satellite information, PL(t1) can be the estimated PL (or based on it), and PL(t2) can be the predicted PL (or based on it).

[0208] In the embodiment, the WTRU can determine the transmit power TxP for Msg1 based on first and second transmit powers TxP1 and TxP2. For example, the transmit power TxP for Msg1 can be the maximum of the first and second transmit powers TxP1 and TxP2. Alternatively, the transmit power TxP for Msg1 can be the average of the first and second transmit powers TxP1 and TxP2, or a function of the same thing.

[0209] In this embodiment, the WTRU can set and / or apply the transmit power TxP to Msg1 as follows: TxP=min(maximum power, f(TxP1(t1), TxP2(t2))) (7) In the formula, Maximum Power can be the maximum transmit power, TxP1(t1) can be the first transmit power TxP1 (or based on it), TxP2(t2) can be the first transmit power TxP1 (or based on it), and f(TxP1(t1), TxP2(t2)) refers to some function applied to TxP1(t1) and / or TxP2(t2). Maximum Power can be the configured maximum transmit power (e.g., configured using any of L1, L2, or L3 signaling) and / or based on the WTRU class.

[0210] If an initial attempt to transmit Msg1 fails (e.g., no response from the satellite within the RAR window), the WTRU may modify (e.g., increase) the first transmit power TxP1 according to a power rise step IE. Alternatively, and / or further, the WTRU may determine a third transmit power TxP3 for retransmitting Msg1 based on a second predicted PL between the WTRU and the satellite at time t3, which is intended and / or predicted to be the time after retransmission of Msg1. The WTRU may predict a second predicted PL at time t3 based on (e.g., using and / or based on) any of the following: the calculated distance to the relevant satellite at time t1, the estimated PL at time t1, and the predicted distance to the satellite at time t3. The WTRU may determine the transmit power TxP3 using Equation 6, except that PL(t2) is replaced by PL(t3), where PL(t3) may be (or based on) the second predicted PL. For Msg1 retransmission, the WTRU can configure and apply TxPower to Msg1 as follows: TxP = min(maximum power, f(TxP(t1) + power increase step, TxP3(t3))) (8) In the formula, the maximum power can be the maximum transmit power, TxP1(t1) can be the first transmit power TxP1 (or based on it), TxP3(t3) can be the third transmit power TxP3 (or based on it), and f(TxP(t1) + power rise step, TxP2(t2)) refers to some function applied to TxP(t1) + power rise step, TxP2(t2). The maximum power can be the configured maximum transmit power (e.g., configured using any of L1, L2, or L3 signaling) and / or based on the WTRU class.

[0211] Although the embodiments described above relate to Msg1 transmission and / or retransmission, such embodiments are equally applicable to and can be implemented in accordance with preamble transmission and / or retransmission.

[0212] In embodiments, the WTRU can determine which synchronous raster (or any of several synchronous rasters) to use. The determination may be based on the satellite type that the WTRU is targeting and / or accessing. In embodiments, the WTRU may be configured with one or more synchronous rasters. Each (or any) of the synchronous rasters may be associated with one or more satellite types. The WTRU can determine which of the configured synchronous rasters to use based on the satellite type it is targeting. In embodiments, the WTRU may be configured with a large raster for LEO satellites and a smaller (compared to LEO satellites) synchronous raster for GEO satellites. Configuring a large synchronous raster for LEO satellites can reduce the number of SSB frequency positions the WTRU needs to access the satellite (for example, to compensate for the high Doppler shift of LEO satellites).

[0213] In an embodiment, the WTRU can determine the SSB timing of multiple beams transmitted by the satellite based, for example, on the timing of one SSB in a beam and a timing pattern (e.g., a (pre-defined) timing pattern). In an embodiment, the satellite can (pre-)configure a predefined timing pattern for multiple beams on the satellite. Based on the SSB timing of different beams, the WTRU can determine the time to monitor different frequencies to detect SSBs from the beams on the satellite.

[0214] In this embodiment, the WTRU can monitor a group-common PDCCH (GC-PDCCH) and can receive indications of timing advance (TA) commands (TACs) for itself and / or for a group of WTRUs ("Group TAC").

[0215] In the embodiment, the WTRU can monitor the GC-PDCCH relative to the group TAC and adjust its timing advance to match that of the group TAC. In the embodiment, the WTRU may be configured using GC-RNTI and CORSET to monitor the group TAC relative to the WTRU group.

[0216] In embodiments, a WTRU can autonomously adjust its TA. For example, a WTRU can autonomously determine (e.g., estimate) its TA based on the timing of control and / or data sent from the network, satellite ephemeris, and GNSS information. A WTRU can receive, for example, the rate of change of TA in the ephemeris to adjust its TA. Alternatively, a WTRU can estimate its TA based on its position obtained from GNSS information. In embodiments, a WTRU can indicate its TA estimation function to the network. In embodiments, a UE can indicate its TA adjustment function to the network. The TA estimation function and / or TA adjustment function can be sent to the network in a WTRU (e.g., UE) function message.

[0217] In embodiments, the WTRU can determine the TAC mode to use based on information from the network (e.g., information provided by the gNB). In embodiments, the gNB and / or the network may support one or more TAC modes for the WTRU. Each (or any) of the TAC modes may indicate a reference timing for the TAC. The TAC modes may include autonomous and non-autonomous modes. In autonomous modes, the WTRU can measure the TA, while in non-autonomous modes, the WTRU may not be able to measure the TA on its own. In autonomous modes, the WTRU can modify the TA based on reference timings from, for example, its previous UL transmission, previously successful transmissions, and similar. In non-autonomous modes, the WTRU can modify the TA based on reference timings from, for example, a previous TAC.

[0218] The WTRU can be informed of its TAC mode in any of the L1, L2, or L3 signaling. For example, the WTRU can be dynamically informed of its TAC mode in each TAC message. Alternatively, the WTRU can semi-statically configure which TAC mode is available based on either the MAC CE or RRC message. conclusion While features and elements are provided 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. This disclosure should not be limited to the specific embodiments described herein, intended as illustrative examples of various aspects. Many modifications and variations can be made without departing from its spirit and scope, as will be apparent to those skilled in the art. Elements, actions, or commands used in the description of this application should not be construed as important or essential to the invention unless expressly provided as such. In addition to those enumerated herein, functionally equivalent methods and apparatus within the scope of this disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to be covered within the appended claims. This disclosure should be limited only by the claims of the appended claims, together with the entire scope of equivalents to which such claims are eligible to include it. It should be understood that this disclosure is not limited to any particular method or system.

[0219] It should be understood that the terms used herein are intended solely to describe specific embodiments and are not intended to be limiting. Where used herein, the terms “station” and its abbreviation “STA,” “user equipment” and its abbreviation “UE” may mean (i) a radio transmit and / or receive unit (WTRU) as described below, (ii) any of the various embodiments of a WTRU as described below, (iii) a radio-enabled and / or wired (e.g., connectable) device configured to use some or all of the structures and functionalities of a WTRU, in particular, as described below, (iv) a radio-enabled and / or wired device configured to use fewer structures and functionalities than all of a WTRU, as described below, or (v) something similar. Details of exemplary WTRUs that can represent any UE listed herein are provided, for example, with respect to Figures 1A to 1D.

[0220] In addition, the methods described herein can be implemented in computer programs, software, or firmware contained within a computer-readable medium for execution by a computer or processor. Examples of non-temporary 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-ROM disks and digital multipurpose disks (DVDs). A radio frequency transceiver can be implemented using a processor associated with software for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0221] Modifications of the methods, apparatus, and systems described above are possible without departing from the scope of the present invention. It should be noted that, in terms of the broad variety of applicable embodiments, the embodiments described above are merely examples and are not limited to the scope of the claims described below. For example, embodiments included herein also include handheld devices, which include, or are used with, a suitable voltage source, such as a battery or similar device, that provides a suitable power supply voltage.

[0222] Furthermore, the embodiments described above have included other devices, including processing platforms, computing systems, controllers, and processors. These devices may include at least one central processing unit ("CPU") and memory. In accordance with the practice of those skilled in the art in the field of computer programming, references to symbolic representations of actions, and operations or instructions, can be performed by various CPUs and memories. Such actions, and operations or instructions may be said to be "executed," "executed on a computer," or "executed on a CPU."

[0223] Those skilled in the art will understand that actions, and symbolically represented operations or instructions, involve the manipulation of electrical signals by the CPU. The electrical system represents data bits, which can cause the resulting transformation or reduction of electrical signals and the preservation of data bits in memory locations within the memory system, thereby reconfiguring or otherwise altering the CPU's operation and other processing of signals. The memory locations where data bits are preserved are physical locations having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. Representative embodiments are not limited to the platforms or CPUs mentioned above, and it should be understood that other platforms and CPUs may support the methods provided.

[0224] Data bits may also be maintained on a computer-readable medium, including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory ("RAM")) or non-volatile (e.g., Read-On Memory ("ROM")) mass storage systems, which are readable by the CPU. The computer-readable medium may include cooperative or interconnected computer-readable media, which may reside exclusively on one processing system or be local or remote to one processing system, and may be distributed across multiple interconnected processing systems. It should be understood that typical embodiments are not limited to the memory mentioned above, and other platforms and memories may support the methods described. It should also be understood that typical embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the methods provided.

[0225] In descriptive embodiments, any of the operations, processes, etc., described herein can be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions can be executed by a processor in a mobile unit, network element, and / or any other computing device.

[0226] There are only minor differences between hardware and software implementations of a system configuration. The choice between using hardware or software is generally (but not always) a design choice representing a cost-efficiency trade-off, as in some situations the choice between hardware and software can be significant. Various means (e.g., hardware, software, and / or firmware) can influence the processes and / or systems, and / or other technologies described herein, and the preferred means may change depending on the context in which the processes and / or systems, and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are paramount, they may primarily choose hardware and / or firmware means. If flexibility is paramount, they may primarily choose software implementation. Alternatively, they may choose any combination of hardware, software, and / or firmware.

[0227] The detailed description above illustrates various embodiments of devices and / or processes through the use of block diagrams, flowcharts, and / or examples. Those skilled in the art will understand that, insofar as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or substantially any combination thereof. In some representative embodiments, several parts of the invention described herein can be implemented through application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated configurations. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be implemented in whole or in part as an integrated circuit, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or substantially any combination thereof, and that designing circuits and / or writing code for software and / or firmware is well within the skill of those skilled in the art in light of this disclosure. In addition, those skilled in the art will understand that the mechanisms of the present invention described herein can be distributed in various forms as program products, and that the explanatory embodiments of the present invention described herein are applicable regardless of the particular type of signal-holding medium used to actually carry out the distribution.Examples of signal-retaining media include, but are not limited to, recording-type media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, and computer memory, as well as transmission-type media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0228] Those skilled in the art will understand that it is common practice in the art to describe devices and / or processes as described herein and then integrate such described devices and / or processes into a data processing system using technical methods. That is, at least some of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will understand that a typical data processing system may generally include one or more of the following: a system unit housing, a video display device, memory such as volatile or non-volatile memory, a microprocessor and a digital signal processor, computing entities such as an operating system, a driver, a graphical user interface, and an application program, one or more interaction devices such as a touchpad or a screen, and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0229] A radio frequency transceiver can be implemented using a software-associated processor for use in a radio transmit / receive unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME), or evolved packet core (EPC), or any host computer. The WTRU can be used in conjunction with other components, including hardware and / or software-implemented modules, such as software-implemented radio (SDR), as well as other components such as cameras, video camera modules, videophones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, Bluetooth® modules, frequency modulation (FM) radio units, near-field communication (NFC) modules, liquid crystal display (LCD) units, organic light-emitting diode (OLED) display units, digital music players, media players, video game player modules, internet browsers, and / or wireless local area network (WLAN) or ultra-wideband (UWB) modules.

[0230] The invention as described herein sometimes illustrates different components that are contained within or connected to other different components. Such described architectures are merely examples, and it should be understood that in practice, many other architectures can be implemented to achieve the same functionality. Conceptually, any arrangement of components to achieve the same functionality is effectively “associated” in such a way that the desired functionality can be achieved. Therefore, any two components in this specification that are combined to achieve a particular functionality can be seen as “associated” with each other, regardless of the architecture or intervening components, in such a way that the desired functionality can be achieved. Similarly, any two components thus associated can be seen as “operably connected” or “operably coupled” with each other to achieve the desired functionality, and any two components that can be associated in such a way can also be seen as “operably coupled” with each other to achieve the desired functionality. Specific examples of components that can be operationally coupled include, but are not limited to, components that can be physically paired and / or interact physically, as well as components that are wirelessly interactive and / or interact wirelessly, and / or interact logically and / or interact logically.

[0231] In substantially any use of plural and / or singular terms herein, a person skilled in the art can convert from plural to singular and / or singular to plural as appropriate to the context or use. For clarity, various singular / plural substitutions may be explicitly described herein.

[0232] In general, it will be understood by those skilled in the art that the terms used herein, and in particular in the appended claims (e.g., the text of the appended claims), are generally intended as “open” terms (for example, the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” and the term “includes” should be interpreted as “including but not limited to,” etc.). If a specific number of claims to be introduced is intended, such intention will be explicitly stated in the claim; if no such statement is made, such intention does not exist, it will be understood by those skilled in the art. For example, if only one item is intended, the term “single” or similar wording may be used. For the sake of understanding, the following appended claims and / or descriptions herein may include the use of the introductory phrases “at least one” and “one or more” to introduce claims. However, the use of such phrases should not be interpreted as implying that the introduction of a claim enumeration by the indefinite article "a" or "an" limits any particular claim containing such introduced claim enumeration to embodiments containing only one such enumeration (for example, "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim enumerations. In addition, even if the specific number of claim enumerations introduced is explicitly stated, a person skilled in the art will recognize that such statement should be interpreted as meaning at least the stated number (for example, the unmodified enumeration of "two enumerations" without other modifiers means at least two enumerations or two or more enumerations).Furthermore, when a conventional expression similar to "at least one of A, B, and C, etc." is used, such a construction is generally intended to be understood by a person skilled in the art (for example, "a system having at least one of A, B, and C" includes, but is not limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or a system having A, B, and C together). When a conventional expression similar to "at least one of A, B, or C, etc." is used, such a construction is generally intended to be understood by a person skilled in the art (for example, "a system having at least one of A, B, or C" includes, but is not limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or a system having A, B, and C together). It will be further understood by those skilled in the art that any substantially disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood as construing the possibility of including one of the terms, either of the terms, or both of the terms. For example, the phrase “A or B” is understood to include the possibilities of “A” or “B” or “A and B.” Furthermore, as used herein, the term “any of ~” followed by a list of multiple items and / or multiple categories of items is intended to include “any of,” “any combination of,” “any multiple of,” and / or “any combination of multiple,” of the items and / or categories of items, individually or in conjunction with other items and / or other categories of items. Furthermore, as used herein, the term “set” or “group” is intended to include any number of items, including zero. In addition, as used herein, the term “number” is intended to include any number, including zero.

[0233] In addition, if any feature or aspect of this disclosure is described in relation to the Markush group, a person skilled in the art will recognize that the disclosure is also described in relation to any individual member or subgroup of a member of the Markush group.

[0234] For all purposes, including providing a written description, as will be understood by those skilled in the art, all scopes disclosed herein encompass all possible sub-scopes and combinations thereof. Any scope described can be readily recognized as adequately describing and enabling the same scope to be divided into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope described herein can be readily divided into a lower third, a middle third, an upper third, etc. Again, as will be understood by those skilled in the art, all words such as “at most,” “at least,” “greater than,” and “less than” include the number described and refer to a scope that can be later divided into sub-scopes as described above. Finally, as will be understood by those skilled in the art, a scope includes each individual member. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

[0235] Furthermore, unless otherwise stated, the claims should not be interpreted as being limited to the order or elements provided. In addition, the use of the term “means for” in any claim is intended to exercise the means-plus-function claim form under 112, paragraph 6 of the U.S. Patent Act, and no claim without the term “means for” is intended to do so. [Industrial applicability]

[0236] This invention can be used for communications. [Explanation of Symbols]

[0237] 102a~102d WTRU 104 RAN 106 Core Network 108 PSTN 110 Internet 112 Other networks

Claims

1. A method implemented in a wireless transceiver unit (WTRU), The steps include receiving one or more physical random access channel configurations that indicate either a preamble format or a physical random access channel opportunity period, Based on the ability of the WTRU to estimate the timing advance, the step of selecting a physical random access channel configuration from among the physical random access channel configurations, The steps include: estimating the aforementioned timing advance value, A step of showing the estimated value of the timing advance to the network, A step of determining parameters associated with the physical random access channel configuration, wherein determining the parameters includes selecting either the number of physical uplink shared channels and the number of preamble transmissions based on the estimated value of the timing advance, The steps include sending a preamble using the selected physical random access channel configuration, and A method for providing this.

2. Steps to demonstrate to the network the ability to estimate the timing advance of the WTRU. The method according to claim 1, comprising:

3. A step of adjusting the estimated value of the timing advance before indicating the value to the network, based on either the satellite's ephemeris, the timing of control and data transmitted from the network, or Global Navigation Satellite System (GNSS) information. The method according to claim 1, comprising:

4. The method of claim 1, wherein the preamble format includes any of the preamble sequence length, number of iterations, cyclic prefix, or guard period.

5. The method according to claim 1, wherein the physical random access channel opportunity period represents the time between two consecutive physical random access channel opportunities.

6. The method of claim 1, wherein the step of selecting the physical random access channel configuration, based on the fact that the WTRU has the ability to accurately estimate the timing advance, includes selecting a physical random access channel configuration associated with one preamble and one or more physical uplink shared channel (PUSCH) transmissions.

7. The method of claim 1, wherein the step of selecting the physical random access channel configuration, based on the fact that the WTRU does not have the ability to accurately estimate the timing advance, includes selecting a physical random access channel configuration associated with a plurality of preambles and one or more physical uplink shared channel (PUSCH) transmissions.

8. A wireless transceiver unit (WTRU), Includes transmitter, receiver, processor and memory, Upon receiving one or more physical random access channel configurations that each indicate either the preamble format or the physical random access channel opportunity period, Based on the ability to estimate the timing advance of the WTRU, a physical random access channel configuration is selected from among the physical random access channel configurations. The value of the aforementioned timing advance is estimated, The estimated value of the timing advance is shown to the network. Determine the parameters associated with the aforementioned physical random access channel configuration, To determine the aforementioned parameters, the system is configured to select either the number of physical uplink shared channels or the number of preamble transmissions based on the estimated value of the timing advance. Send the preamble using the selected physical random access channel configuration. Circuit configured in such a way WTRU equipped with.

9. A WTRU according to claim 8, configured to show the network the capability to estimate the timing advance of the WTRU.

10. The WTRU of claim 8, configured to adjust the estimated value of the timing advance before indicating the value to the network, based on any of the following: satellite ephemeris, timing of control and data transmitted from the network, or Global Navigation Satellite System (GNSS) information.

11. The WTRU of claim 8, wherein the preamble format includes any of the preamble sequence length, number of repetitions, cyclic prefix, or guard period.

12. The WTRU of claim 8, wherein the physical random access channel opportunity period represents the time between two consecutive physical random access channel opportunities.

13. A WTRU according to claim 8, configured to select a physical random access channel configuration associated with one preamble and one or more physical uplink shared channel (PUSCH) transmissions, based on the WTRU having the ability to accurately estimate timing advance.

14. A WTRU according to claim 8, configured to select a plurality of preambles and a physical random access channel configuration associated with one or more physical uplink shared channel (PUSCH) transmissions, based on the fact that the WTRU does not have the ability to accurately estimate timing advance.

Citation Information

Patent Citations

  • Time-advanced random access channel transmission

    US20140044108A1

  • Communication control method and base station

    WO2015115457A1

  • Method for performing random access procedure and device therefor

    WO2018203698A1