阅读说明：本技术 无线系统中的开环harq (Open loop HARQ in wireless systems ) 是由 Y·D·N·桑加拉杰 黄祥杜 吉斯伦·佩尔蒂埃 于 2020-04-30 设计创作，主要内容包括：WTRU可以被配置成执行逻辑信道优先化。WTRU可以接收指示第一HARQ进程ID和第一HARQ处理类型之间以及第二HARQ进程ID和第二HARQ处理类型之间的关联的指示(例如映射)。所述WTRU可以接收指示第一逻辑信道和所述第一HARQ处理类型之间以及第二逻辑信道和所述第二HARQ处理类型之间的关联的指示(例如映射)。所述WTRU可以接收HARQ进程ID指示。所述WTRU可以确定与所述HARQ进程ID相关联的HARQ处理类型。所述WTRU可以确定可用于传输的逻辑信道。该可用的逻辑信道可以基于与所述HARQ进程ID相关联的所述HARQ处理类型而被确定。所述WTRU可以发送所述传输。(The WTRU may be configured to perform logical channel prioritization. The WTRU may receive an indication (e.g., a mapping) indicating an association between the first HARQ process ID and the first HARQ process type and between the second HARQ process ID and the second HARQ process type. The WTRU may receive an indication (e.g., a mapping) indicating an association between a first logical channel and the first HARQ process type and between a second logical channel and the second HARQ process type. The WTRU may receive a HARQ process ID indication. The WTRU may determine a HARQ process type associated with the HARQ process ID. The WTRU may determine logical channels available for transmission. The available logical channels may be determined based on the HARQ process type associated with the HARQ process ID. The WTRU may send the transmission.)

1. A wireless transmit/receive unit (WTRU), comprising:

a memory; and

a processor configured to:

receiving an indication of an association between a first hybrid automatic repeat request (HARQ) process Identifier (ID) and a first HARQ process type and between a second HARQ process ID and a second HARQ process type;

receiving an indication of an association between a first logical channel and the first HARQ process type and between a second logical channel and the second HARQ process type;

receiving an Uplink (UL) grant indicating a HARQ process ID;

determining a HARQ process type associated with the HARQ process ID;

determining logical channels available for transmission, wherein the available logical channels are determined based on the HARQ process type associated with the HARQ process ID; and

the transmission is sent.

2. The WTRU of claim 1, wherein for the determination of the available logical channels:

the first logical channel is determined to be available for the transmission if the HARQ process ID is associated with the first HARQ process type, an

The second logical channel is determined to be available for the transmission if the HARQ process ID is associated with the second HARQ process type.

3. The WTRU of claim 1 wherein the first HARQ process type is a closed-loop HARQ process type and the second HARQ process type is an open-loop HARQ process type.

4. The WTRU of claim 1, wherein the transmission is a Scheduling Request (SR), and wherein the processor is further configured to send the SR on the available logical channel.

5. The WTRU of claim 1, wherein the transmission is sent using the available logical channel.

6. The WTRU of claim 1, wherein the first HARQ process type is associated with a first power parameter and the second HARQ process type is associated with a second power parameter.

7. The WTRU of claim 6, wherein the processor is further configured to send the transmission using the available logical channel, wherein the transmission is associated with a power parameter, wherein the power parameter is the first power parameter or the second power parameter, wherein the first power parameter is a first power offset, a first fractional power value, a first Transmit Power Command (TPC) command, or a first target power, and wherein the second power parameter is a second power offset, a second fractional power value, a second TPC command, or a second target power.

8. A Hybrid Automatic Request (HARQ) processing method, comprising:

a Wireless Transmit Receive Unit (WTRU) receiving a mapping indicating an association between a first hybrid automatic repeat request (HARQ) process Identifier (ID) and a first HARQ process type and an association between a second HARQ process ID and a second HARQ process type;

the WTRU receiving a mapping indicating an association between a first logical channel and the first HARQ process type and an association between a second logical channel and the second HARQ process type;

the WTRU receiving an Uplink (UL) grant indicating a HARQ process ID;

the WTRU determining a HARQ process type associated with the HARQ process ID;

the WTRU determining a logical channel restriction that logical channels are used for transmission, wherein the logical channel restriction is determined based on the HARQ process type associated with the HARQ process ID; and

the transmission is sent.

9. The HARQ method of claim 8, wherein the determination of the available logical channels:

the first logical channel is determined to be available for the transmission if the HARQ process ID is associated with the first HARQ process type, an

The second logical channel is determined to be available for the transmission if the HARQ process ID is associated with the second HARQ process type.

10. The HARQ method of claim 8, wherein the first HARQ process type is a closed-loop HARQ process type and the second HARQ process type is an open-loop HARQ process type.

11. The HARQ method of claim 8, wherein the transmission is a Scheduling Request (SR), and wherein the method further comprises transmitting the SR on the available logical channel.

12. The HARQ method of claim 8, wherein the transmission is sent using the available logical channels.

13. The HARQ method of claim 8, wherein the first HARQ process type is associated with a first power parameter and the second HARQ process type is associated with a second power parameter.

14. The HARQ method of claim 13, further comprising:

sending the transmission using the available logical channel, wherein the transmission is associated with a power parameter, wherein the power parameter is the first power parameter or the second power parameter, wherein the first power parameter is a first power offset, a first fractional power value, a first Transmit Power Command (TPC) command, or a first target power, and wherein the second power parameter is a second power offset, a second fractional power value, a second TPC command, or a second target power.

Background

Mobile communication using wireless communication is continuously developing. The fifth generation may be referred to as 5G. Previous generation (e.g., legacy) mobile communications may be, for example, fourth generation (4G) Long Term Evolution (LTE).

The Round Trip Delay (RTD) for communications in the non-terrestrial network may be much higher than the RTD for communications in the terrestrial network. For example, the RTD for a Low Earth Orbit (LEO) satellite at an altitude of about 600km may be on the order of about 28 ms. RTDs for Medium Earth Orbit (MEO) satellites at an altitude of about 10,000km may be on the order of about 190 ms. RTDs for geosynchronous orbit (GEO) satellites may be on the order of approximately 545 ms. Such long RTD times have various impacts on the ability of a wireless transmit/receive unit (WTRU) to maintain support for high data rate services.

Disclosure of Invention

Systems, methods, and instrumentalities associated with logical channel prioritization (prioritization) are described herein. The WTRU may be configured to perform logical channel prioritization. The WTRU may receive an indication (e.g., a map) indicating an association between a first hybrid automatic repeat request (HARQ) process Identifier (ID) and a first HARQ process (processing) type and an association between a second HARQ process ID and a second HARQ process type. The WTRU may receive an indication (e.g., a map) indicating an association between a first logical channel and the first HARQ process type and between a second logical channel and the second HARQ process type. The WTRU may receive an Uplink (UL) grant indicating a HARQ process ID. The WTRU may determine a HARQ process type associated with the HARQ process ID. The WTRU may determine logical channels available for transmission. For example, the logical channels available for the transmission may be determined based on the HARQ process type associated with the HARQ process ID. The WTRU may send the transmission using the logical channel determined to be available.

For example, if the HARQ process ID is associated with the first HARQ process type, the WTRU may determine that a first logical channel is available for use by the transmission (e.g., to determine an available logical channel based on the HARQ process type associated with the HARQ process ID). For example, if the HARQ process ID is associated with a second HARQ process type, the WTRU may determine that a second logical channel is available for use by the transmission (e.g., to determine an available logical channel based on the HARQ process type associated with the HARQ process ID). For example, if the HARQ process ID is not associated with the first HARQ process type, the WTRU may determine that the first logical channel is not available for the transmission (e.g., to determine an available logical channel based on the HARQ process type associated with the HARQ process ID). For example, if the HARQ process ID is not associated with the second HARQ process type, the WTRU may determine that the second logical channel is not available for the transmission (e.g., to determine an available logical channel based on the HARQ process type associated with the HARQ process ID).

In an example, the first HARQ process type may be a closed-loop HARQ process type and the second HARQ process type may be an open-loop HARQ process type.

Systems, methods, and instrumentalities associated with logical channel prioritization are described herein. The WTRU may be configured to perform logical channel prioritization. The WTRU may receive a mapping indicating an association between a first hybrid automatic repeat request (HARQ) process Identifier (ID) and a first HARQ process type and an association between a second HARQ process ID and a second HARQ process type. The WTRU may receive a mapping indicating an association between a first logical channel and the first HARQ process type and an association between a second logical channel and the second HARQ process type. The WTRU may receive an Uplink (UL) grant indicating a HARQ process ID. The WTRU may determine a HARQ process type associated with the HARQ process ID. The WTRU may determine a logical channel restriction that logical channels are used for transmission. For example, the logical channel restriction may be determined based on the HARQ process type associated with the HARQ process ID.

For example, the WTRU may restrict the first logical channel for the transmission if the HARQ process ID is associated with the first HARQ process type (e.g., to determine the logical channel restriction based on the HARQ process type associated with the HARQ process ID), and/or may restrict the second logical channel for the transmission, for example, if the HARQ process ID is associated with the second HARQ process type.

The first HARQ process type may be, for example, a closed-loop HARQ process type, and the second HARQ process type may be, for example, an open-loop HARQ process type. The first HARQ process type may be associated with a first power parameter and the second HARQ process type may be associated with a second power parameter. The transmission may be, for example, a Scheduling Request (SR). The WTRU may send the transmission (e.g., SR) using (e.g., on) a logical channel with unrestricted use. The transmission may be associated with a power parameter. The power parameter may be the first power parameter or the second power parameter. The first power parameter may be, for example, a first power offset, a first fractional power value, a first Transmit Power Command (TPC) command, or a first target power. The second power parameter may be, for example, a second power offset, a second fractional power value, a second TPC command, or a second target power.

Systems, methods, and instrumentalities are described herein to determine and apply various types of Hybrid Automatic Request (HARQ) processes to downlink and/or uplink processes. The WTRU may determine a first HARQ Process Type (HPT) associated with the first HARQ process and a second HARQ process type associated with the second HARQ process. For example, the first HARQ process type and/or the second HARQ process type may be determined based on a semi-static configuration and/or received dynamic signaling. For example, the first HARQ process type and/or the second HARQ process type may be preconfigured.

The WTRU may apply the first HARQ process type to the first HARQ process associated with a first transmission and apply the second HARQ process type to the second HARQ process associated with a second transmission. The first or second HARQ process type may be, for example, a closed-loop HARQ process, an open-loop HARQ process, or a stateless HARQ process. For example, the first HARQ process type and/or the second HARQ process type may be applied based on, for example, a type of scheduling information received from a network.

For example, the first HARQ process type or the second HARQ process type may be applied to the first transmission for a duration of an RRC connection or an RRC configured duration. The first HARQ process type and/or the second HARQ process type may be specific to a serving cell. The WTRU may receive a configuration for the first HARQ process type and/or the second HARQ process type, for example, via system information. The first HARQ process type or the second HARQ process type may be for one or more HARQ process identifications.

The WTRU may determine HARQ behavior associated with one or more configured grants based on the HARQ configuration. The WTRU may determine HARQ behavior associated with one or more configured grants, e.g., based on HARQ configurations for transmissions associated with dynamic (e.g., non-configured) grants.

Drawings

FIG. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented.

Figure 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in figure 1A, according to an embodiment.

Fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A, according to an embodiment.

Fig. 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used within the communication system shown in fig. 1A, according to an embodiment.

Fig. 2 illustrates an exemplary next generation radio access network (NG-RAN) architecture with bent-pipe payload in a non-terrestrial network.

Fig. 3 shows an exemplary NG-RAN architecture with payload handling of a gNB-DU in a non-terrestrial network.

Fig. 4 illustrates an exemplary NG-RAN architecture with a payload handled by a gNB in a non-terrestrial network.

Fig. 5 shows an example associated with logical channel restriction.

Fig. 6 shows an example of a WTRU determining HARQ types for configured granted resources.

Detailed Description

Fig. 1A is a schematic diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcast, etc., to a plurality of wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, communication system 100 may use one or more channel access methods such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), orthogonal FDMA (ofdma), single carrier FDMA (SC-FDMA), zero-tailed unique word DFT-spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), among others.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104/113, CNs 106/115, Public Switched Telephone Networks (PSTNs) 108, the internet 110, and other networks 112, although it should be appreciated that any number of WTRUs, base stations, networks, and/or network components are contemplated by the disclosed embodiments. The WTRUs 102a, 102b, 102c, 102d may each be any type of device configured to operate and/or communicate in a wireless environment. For example, any of the WTRUs 102a, 102b, 102c, 102d may be referred to as a "station" and/or a "STA," which may be configured to transmit and/or receive wireless signals, and may include User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an internet of things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in industrial and/or automated processing chain environments), consumer electronics devices and applications, a wireless transceiver, or a wireless device, or a wireless device, or a wireless device, and devices operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, 102d may be referred to interchangeably as a UE.

The communication system 100 may also include a base station 114a and/or a base station 114 b. Each of the base stations 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., the CN106/115, the internet 110, and/or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102 d. For example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node B, e node bs, home e-nodes B, gNB, New Radio (NR) node bs, site controllers, Access Points (APs), and wireless routers, among others. Although each of the base stations 114a, 114b is depicted as a single component, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network components.

The base station 114a may be part of the RAN 104/113, and the RAN may also include other base stations and/or network components (not shown), such as Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, known 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 wireless service coverage for a particular geographic area that is relatively fixed or may vary over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., each transceiver corresponding to a sector of a cell. In an embodiment, base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of a cell. For example, using beamforming, signals may be transmitted and/or received in desired spatial directions.

The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., Radio Frequency (RF), microwave, centimeter-wave, millimeter-wave, Infrared (IR), Ultraviolet (UV), visible, etc.). Air interface 116 may be established using any suitable Radio Access Technology (RAT).

More specifically, as described above, communication system 100 may be a multiple-access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, among others. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104/113 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may establish the air interface 115/116/117 using wideband cdma (wcdma). WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (HSPA +). HSPA may include high speed Downlink (DL) packet access (HSDPA) and/or High Speed UL Packet Access (HSUPA).

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-advanced (LTE-a) and/or LTE-Pro (LTE-a Pro).

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology, such as NR radio access, that may establish the air interface 116 using a New Radio (NR).

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may collectively implement LTE radio access and NR radio access (e.g., using Dual Connectivity (DC) principles). As such, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., eNB and gNB).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless high fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA 20001X, CDMA2000EV-DO, interim standard 2000(IS-2000), interim standard 95(IS-95), interim standard 856(IS-856), Global System for Mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), and GSM EDGE (GERAN), among others.

The base station 114B in fig. 1A may be, for example, a wireless router, a home nodeb, a home enodeb, or an access point, and may facilitate wireless connectivity in a local area using any suitable RAT, such as a business, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by a drone), and a road, among others. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a Wireless Local Area Network (WLAN) by implementing a radio technology such as IEEE 802.11. In an embodiment, the base station 114b and the WTRUs 102c, 102d may establish a Wireless Personal Area Network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish the pico cell or the femto cell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-A, LTE-a Pro, NR, etc.). As shown in fig. 1A, the base station 114b may be directly connected to the internet 110. Thus, base station 114b need not access the internet 110 via CN 106/115.

The RAN 104/113 may communicate with a CN106/115, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements, among others. CN106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, internet connectivity, video distribution, etc., and/or may perform advanced security functions such as user authentication. Although not shown in fig. 1A, it should be appreciated that the RAN 104/113 and/or CN106/115 may communicate directly or indirectly with other RANs that employ the same RAT as the RAN 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113 using NR radio technology, the CN106/115 may communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technologies.

The CN106/115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the internet 110, and/or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). The internet 110 may include a system of globally interconnected computer network devices that utilize common communication protocols, such as transmission control protocol/internet protocol (TCP), User Datagram Protocol (UDP), and/or IP in the TCP/IP internet protocol suite. The network 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may use the same RAT as the RAN 104/113 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers communicating with different wireless networks over different wireless links). For example, the WTRU102 c shown in fig. 1A may be configured to communicate with a base station 114a using a cellular-based radio technology and with a base station 114b, which may use an IEEE 802 radio technology.

Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, the WTRU102 may include a processor 118, a transceiver 120, a transmit/receive component 122, a speaker/microphone 124, a keypad 126, a display/touch pad 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and/or peripherals 138. It should be appreciated that the WTRU102 may include any subcombination of the foregoing components while maintaining consistent embodiments.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 and the transceiver 120 may be coupled to a transmit/receive component 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic component or chip.

The transmit/receive component 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit/receive component 122 may be an antenna configured to transmit and/or receive RF signals. As an example, in another embodiment, the transmit/receive component 122 may be an emitter/detector configured to emit and/or receive IR, UV or visible light signals. In yet another embodiment, the transmit/receive component 122 may be configured to transmit and/or receive RF and optical signals. It should be appreciated that the transmit/receive component 122 may be configured to transmit and/or receive any combination of wireless signals.

Although transmit/receive component 122 is depicted in fig. 1B as a single component, WTRU102 may include any number of transmit/receive components 122. More specifically, the WTRU102 may use MIMO technology. Thus, in one embodiment, the WTRU102 may include two or more transmit/receive components 122 (e.g., multiple antennas) that transmit and receive wireless signals over the air interface 116.

Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and to demodulate signals received by transmit/receive element 122. As described above, the WTRU102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

The processor 118 of the WTRU102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touchpad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. Further, processor 118 may access information from and store information in any suitable memory, such as non-removable memory 130 and/or removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), Read Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and so forth. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located in the WTRU102, such memory may be located, for example, in a server or a home computer (not shown).

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

The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and/or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU102 may acquire location information via any suitable positioning method while maintaining consistent embodiments.

The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, the peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and/or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, BluetoothModules, Frequency Modulation (FM) radio units, digital music players, media players, video game modules, internet browsers, virtual reality and/or augmented reality (VR/AR) devices, and activity trackers, among others. The peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geographic position sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor, among others.

The WTRU102 may include a full duplex radio for which reception or transmission of some or all signals (e.g., associated with particular subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and/or simultaneous. The full-duplex radio may include an interference management unit that reduces and/or substantially eliminates self-interference via signal processing by hardware (e.g., a choke coil) or by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU102 may include a half-duplex radio that transmits and receives some or all signals, such as associated with a particular subframe for UL (e.g., for transmission) or downlink (e.g., for reception).

Figure 1C is a system diagram illustrating the RAN 104 and the CN106 according to an embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c using E-UTRA radio technology over the air interface 116. The RAN 104 may also communicate with a CN 106.

RAN 104 may include enodebs 160a, 160B, 160c, however, it should be appreciated that RAN 104 may include any number of enodebs while maintaining consistent embodiments. The enodebs 160a, 160B, 160c may each include one or more transceivers that communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the enodebs 160a, 160B, 160c may implement MIMO technology. Thus, for example, the enodeb 160a may use multiple antennas to transmit wireless signals to the WTRU102a and/or to receive wireless signals from the WTRU102 a.

The enodebs 160a, 160B, 160c may each be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and so forth. As shown in FIG. 1C, eNode Bs 160a, 160B, 160C may communicate with each other over an X2 interface.

The CN106 shown in fig. 1C may include a Mobility Management Entity (MME)162, a Serving Gateway (SGW)164, and a Packet Data Network (PDN) gateway (or PGW) 166. While each of the foregoing components are described as being part of the CN106, it should be understood that any of these components may be owned and/or operated by an entity other than the CN operator.

The MME 162 may be connected to each of the enodebs 162a, 162B, 162c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, performing bearer activation/deactivation processes, and selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, among other things. MME 162 may provide a control plane function for switching between RAN 104 and other RANs (not shown) that use other radio technologies (e.g., GSM and/or WCDMA).

The SGW 164 may be connected to each of the enodebs 160a, 160B, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102 c. The SGW 164 may also perform other functions such as anchoring the user plane during inter-eNB handovers, triggering paging processing when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

The SGW 164 may be connected to a PGW 146, which may provide packet switched network (e.g., internet 110) access for the WTRUs 102a, 102b, 102c to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

The CN106 may facilitate communications with other networks. For example, the CN106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (e.g., the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, the CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), and the IP gateway may serve as an interface between the CN106 and the PSTN 108. In addition, the CN106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers.

Although the WTRU is depicted in fig. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments, such a terminal may use a (e.g., temporary or permanent) wired communication interface with a communication network.

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

A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may access another type of wired/wireless network that is either interfaced to a Distribution System (DS) or that carries traffic into and/or out of the BSS. Traffic originating outside the BSS and destined for the STAs may arrive through the AP and be delivered to the STAs. Traffic originating from the STAs and destined for destinations outside the BSS may be sent to the AP for delivery to the respective destinations. Traffic between STAs that are inside the BSS may be transmitted through the AP, for example, in the case where the source STA may transmit traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and/or referred to as point-to-point traffic. The point-to-point traffic may be transmitted between (e.g., directly between) the source and destination STAs using Direct Link Setup (DLS). In certain representative embodiments, DLS may use 802.11e DLS or 802.11z channelized DLS (tdls)). For example, a WLAN using an Independent Bss (IBSS) mode has no AP, and STAs (e.g., all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "Ad-hoc" communication mode.

When using the 802.11ac infrastructure mode of operation or similar mode of operation, the AP may transmit a beacon on a fixed channel (e.g., the primary channel). The primary channel may have a fixed width (e.g., 20MHz bandwidth) or a width that is dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In some representative embodiments, implemented may be carrier sense multiple access with collision avoidance (CSMA/CA) (e.g., in 802.11 systems). For CSMA/CA, STAs (e.g., each STA) including the AP may sense the primary channel. A particular STA may back off if it senses/detects and/or determines that the primary channel is busy. In a given BSS, there is one STA (e.g., only one station) transmitting at any given time.

High Throughput (HT) STAs may communicate using 40MHz wide channels (e.g., 40MHz wide channels formed by combining a20 MHz wide primary channel with 20MHz wide adjacent or non-adjacent channels).

Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining consecutive 20MHz channels. The 160MHz channel may be formed by combining 8 consecutive 20MHz channels or by combining two discontinuous 80MHz channels (this combination may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel encoding, the data may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The streams may be mapped on two 80MHz channels and data may be transmitted by STAs performing the transmissions. At the receiver of the STA performing the reception, the above-described operations for the 80+80 configuration may be reversed, and the combined data may be transmitted to a Medium Access Control (MAC).

802.11af and 802.11ah support operating modes below 1 GHz. The use of channel operating bandwidths and carriers in 802.11af and 802.11ah is reduced compared to 802.11n and 802.11 ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. In accordance with a representative embodiment, 802.11ah may support meter type control/Machine Type Communication (MTC) (e.g., MTC devices in a macro coverage area). MTC devices may have certain capabilities, such as limited capabilities including supporting (e.g., supporting only) certain and/or limited bandwidth. The MTC device may include a battery, and the battery life of the battery is above a threshold (e.g., to maintain a long battery life).

For WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah), these systems include channels that can be designated as primary channels. The bandwidth of the primary channel may be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA that is sourced from all STAs operating in the BSS supporting the minimum bandwidth operating mode. In the example for 802.11ah, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth operating modes, the width of the primary channel may be 1MHz for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode. Carrier sensing and/or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy (e.g., because STAs (which support only 1MHz mode of operation) transmit to the AP), the entire available band may be considered busy even though most of the available band remains free and available for use.

In the united states, the available frequency band available for 802.11ah is 902MHz to 928 MHz. In korea, the available frequency band is 917.5MHz to 923.5 MHz. In Japan, the available frequency band is 916.5MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, in accordance with the country code.

Figure 1D is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, the RAN 113 may communicate with the WTRUs 102a, 102b, 102c using NR radio technology over the air interface 116. RAN 113 may also communicate with CN 115.

RAN 113 may include gnbs 180a, 180b, 180c, but it should be appreciated that RAN 113 may include any number of gnbs while maintaining consistent embodiments. The gnbs 180a, 180b, 180c may each include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gnbs 180a, 180b, 180c may implement MIMO techniques. For example, the gnbs 180a, 180b may use beamforming processing to transmit and/or receive signals to and/or from the gnbs 180a, 180b, 180 c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU102a and to receive wireless signals from the WTRU102 a. In an embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the 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 an embodiment, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU102a may receive a cooperative transmission from gNB 180a and gNB 180b (and/or gNB 180 c).

The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with a scalable digital configuration. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may be different for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) having different or scalable lengths (e.g., including different numbers of OFDM symbols and/or lasting different absolute time lengths).

The gnbs 180a, 180b, 180c may be configured to communicate with WTRUs 102a, 102b, 102c in independent configurations and/or non-independent configurations. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c without accessing other RANs (e.g., enodebs 160a, 160B, 160 c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gnbs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using signals in an unlicensed frequency band. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate/connect with the gnbs 180a, 180B, 180c while communicating/connecting with other RANs, such as the enodebs 160a, 160B, 160 c. For example, the WTRUs 102a, 102B, 102c may communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c in a substantially simultaneous manner by implementing DC principles. In a non-standalone configuration, the enode bs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput to serve the WTRUs 102a, 102B, 102 c.

The gnbs 180a, 180b, 180c may each be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and/or DL, support network slicing, dual connectivity, implement interworking processing between NR and E-UTRA, route user plane data to User Plane Functions (UPFs) 184a, 184b, and route control plane information to access and mobility management functions (AMFs) 182a, 182b, among other things. As shown in fig. 1D, the gnbs 180a, 180b, 180c may communicate with each other over an Xn interface.

The CN 115 shown in fig. 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, 185 b. While each of the foregoing components are depicted as being part of the CN 115, it should be appreciated that any of these components may be owned and/or operated by an entity other than the CN operator.

The AMFs 182a, 182b may be connected to one or more of the gnbs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as control nodes. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMFs 183a, 183b, managing registration areas, terminating NAS signaling, and mobility management, among others. The AMFs 182a, 182b may use network slicing to customize the CN support provided for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102 c. As an example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced large-scale mobile broadband (eMBB) access, and/or services for Machine Type Communication (MTC) access, among others. The AMF 182 may provide control plane functionality for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies (e.g., LTE-A, LTE-a Pro, and/or non-3 GPP access technologies such as WiFi).

The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b, and may configure traffic routing through the UPFs 184a, 184 b. The SMFs 183a, 183b may perform other functions such as managing and assigning WTRU or UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notification, among others. The PDU session type may be IP-based, non-IP-based, and ethernet-based, among others.

The UPFs 184a, 184b may connect one or more of the gnbs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network (e.g., the internet 110) to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices, and the UPFs 184, 184b may perform other functions, such as routing and forwarding packets, implementing user-plane policies, supporting multi-homed PDU sessions, processing user-plane QoS, buffering downlink packets, and providing mobility anchoring processing, among others.

The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 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, the WTRUs 102a, 102b, 102c may connect to the local Data Networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface that interfaces to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185 b.

In view of fig. 1A-1D and the corresponding description with respect to fig. 1A-1D, one or more or all of the functions described herein with respect to one or more of the following may be performed by one or more emulation devices (not shown): WTRUs 102a-d, base stations 114a-B, enode bs 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMFs 182a-B, UPFs 184a-B, SMFs 183a-B, DN185a-B, and/or any other device(s) described herein. These emulation devices can be one or more devices configured to simulate one or more or all of the functions described herein. These emulation devices may be used, for example, to test other devices and/or to simulate network and/or WTRU functions.

The simulated device may be designed to conduct one or more tests with respect to other devices in a laboratory environment and/or in a carrier network environment. For example, the one or more simulated devices may perform one or more or all functions while implemented and/or deployed, in whole or in part, as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices can perform one or more or all functions while temporarily implemented or deployed as part of a wired and/or wireless communication network. The simulation device may be directly coupled to another device to perform testing and/or may perform testing using over-the-air wireless communication.

The one or more emulation devices can perform one or more functions, including all functions, while not being implemented or deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test scenario of a test laboratory and/or a wired and/or wireless communication network that is not deployed (e.g., tested) in order to conduct testing with respect to one or more components. The one or more simulation devices may be test devices. The simulation device may transmit and/or receive data using direct RF coupling and/or wireless communication via RF circuitry (e.g., the circuitry may include one or more antennas).

For example, hybrid automatic repeat request (HARQ) operation at the WTRU may be modified due to the larger RTD time of the non-terrestrial network. For example, the soft buffer size at the WTRU may be increased for large RTD times. For example, the HARQ process may be modified to address the case of high RTD.

A non-terrestrial network (NTN) may be used, for example, to provide 5G services in service-free areas that may not be covered by a terrestrial 5G network. The unserved areas may include, for example, isolated remote areas, rural areas, the ocean, etc. The NTN may be used to upgrade the performance of the terrestrial network in underserved areas (e.g., in a cost-effective manner). The NTN may be used to enhance 5G service reliability, for example, by providing service availability and scalability for 5G deployments.

The term "network" may refer to one or more gnbs, which may be associated with one or more transmission/reception points (TRPs) and/or any other node in a Radio Access Network (RAN).

Various NTN architectures may be based on RAN functional partitioning between terrestrial units and satellites, for example, as shown in the examples shown in fig. 2-4.

Fig. 2 shows an example of a next generation radio access network (NG-RAN) architecture with bent-pipe payload in a non-terrestrial network. In an example, the NG-RAN may comprise a radio access network connected to a 5G Core Network (CN). For example (e.g., as shown in fig. 2), the WTRU may communicate with a data network through a NG-RAN (e.g., including transponders (e.g., RF bent-tube transponders), NTN Remote Radio Units (RRUs), and a gNB) coupled to the 5G CN (e.g., through an N1/2/3 interface).

Fig. 3 shows an example of NG-RAN architecture with a payload handled by a gNB number of distributed units (gNB-DUs) in a non-terrestrial network. As shown in the example in fig. 3, gnB-DUs may be connected to gnB-CUs via an F1 interface, e.g., using a Satellite Radio Interface (SRI). For example (e.g., as shown in fig. 3), the WTRU may communicate with the data network via a NG-RAN (e.g., including a gNB-DU, an NTN RRU, and a gNB-CU) coupled to the 5G CN (e.g., via an N1/2/3 interface).

Fig. 4 shows an example of NG-RAN architecture with payload handled by the gNB in a non-terrestrial network. As shown in the example in fig. 4, the gNB may be connected to the 5G CN via an N1/2/3 interface (e.g., through SRI). For example (e.g., as shown in fig. 4), the WTRU may communicate with the data network via a NG-RAN (e.g., including a gNB and an NTN RRU) coupled to the 5G CN (e.g., via an N1/2/3 interface).

The WTRU may be configured (e.g., in the NR) to utilize one or more hybrid automatic repeat request (HARQ) protocols, e.g., to achieve robustness against transmission errors. For example, robustness can be achieved by (e.g., enabling) soft combining and fast retransmission. Hybrid ARQ may utilize multiple stop-and-wait protocols to allow for continuous transmission of data. The WTRU MAC may include a HARQ entity for (e.g., each) serving cell. The WTRU may maintain several parallel HARQ processes. The (e.g., each) HARQ process may be associated with a HARQ process identifier. The (e.g., each) HARQ process may be associated with a HARQ buffer. The asynchronous HARQ protocol may be used in the downlink direction and the uplink direction. The HARQ process identification associated with a downlink transmission or an uplink transmission may be signaled (e.g., explicitly signaled), for example, as part of Downlink Control Information (DCI).

The Round Trip Delay (RTD) of communications in a non-terrestrial network (NTN) may be higher than the RTD of communications in a terrestrial network. For example, an RTD for a Low Earth Orbit (LEO) satellite at an altitude of about 600km may be on the order of about 28 ms. The RTD of the Medium Earth Orbit (MEO) at an altitude of about 10,000km may be on the order of about 190 ms. The RTD of geosynchronous orbit (GEO) may be on the order of approximately 545 ms. A large RTD time may have a direct impact on the number of HARQ processes that a WTRU may maintain to support high data rate services. The soft buffer size at the WTRU may, for example, increase with the number of HARQ processes.

In an example, HARQ functionality may be disabled for non-terrestrial communications. The WTRU may rely on higher layer retransmissions (e.g., in case HARQ is disabled). However, disabling the HARQ functionality may result in reduced reliability or increased latency to achieve the desired reliability. For example, if HARQ is disabled, voice services using radio link monitoring-unacknowledged mode (RLM-UM), for example, may lack reliability. Services with infrequent data transmissions may benefit from HARQ operations and may not be constrained by large propagation delays for NTN communications.

The WTRU may transmit a Radio Resource Control (RRC) message, for example, on signaling radio bearer 0(SRB 0). For example, the RRC message may be sent before receiving the full RRC configuration or before establishing signaling radio bearer 1(SRB 1). In an example, the WTRU may send the MSG3 (e.g., the RRCSetupRequest message) using, for example, a Radio Link Control (RLC) transparent mode (e.g., during initial access). The WTRU may receive a MSG4 (e.g., a RRCSetup message) from the network, for example, to establish a SRB 1. HARQ may be used, for example, to ensure reliability of communications, such as during (e.g., legacy) MSG3 and/or MSG4 transmissions. For example, if HARQ is disabled, the reliability of the initial signaling exchange may be compromised. One or more RRC procedures may involve the transmission of (e.g., a single) RLC Protocol Data Unit (PDU). Using RLC level status reports (e.g., without HARQ) to recover lost PDUs can add significant delay to the RRC procedure.

Systems and methods for providing open loop HARQ are described herein. The WTRU may (e.g., be configured to) apply a first set of HARQ functions and/or a first HARQ activity for a first set of HARQ processes and a second activity for a second set of processes. The HARQ configuration may be for a downlink HARQ process, an uplink process, or both a downlink process and an uplink process.

In an example, HARQ behavior may be modeled and/or configured as a type of HARQ process. The type and/or behavior of the HARQ process may include, for example, one or more of: closed-loop HARQ processes, open-loop HARQ processes, and/or stateless HARQ processes. Soft combining of various transmissions may be applicable to, for example, closed loop HARQ processes. The transmission and/or reception of HARQ feedback (e.g., HARQ ACK/NACK) may be applicable to, for example, closed-loop HARQ processes. Soft combining of various transmissions may be applicable to, for example, open loop HARQ processes. The transmission/reception of HARQ feedback may not be suitable for e.g. open loop HARQ processes. Soft combining and transmission/reception of HARQ feedback may not be suitable for, e.g., stateless HARQ processes.

The WTRU may determine the type of HARQ process associated with a given HARQ process based on, for example, semi-static configuration and/or dynamic signaling. In an example, the WTRU may apply a preconfigured HARQ Process Type (HPT) to (e.g., each) transmission and/or reception, e.g., for the duration of an RRC connection or an RRC configured duration. In an example (e.g., an example using semi-static configuration), the WTRU may apply a pre-configured HARQ process type specific to the serving cell. For example, the type of HARQ process and/or HARQ process to apply may be indicated (e.g., in system information) and/or implicitly determined (e.g., from serving frequency and/or cell identity).

Dynamic methods (e.g., for determining HARQ process types) may include one or more of the following. In an example of a dynamic approach, the WTRU may apply a specific HARQ process type to a subset of the configured HARQ process (es). The WTRU may take open loop HARQ operations for one or more predefined HARQ process identifications (e.g., HARQ process id (pid)0, etc.). The WTRU may be configured (e.g., explicitly configured) with a list of HARQ process Identifiers (IDs) to which open loop HARQ process types may be applied. For example, the configuration may be provided via an RRC message.

In an example of a dynamic approach, the WTRU may apply a preconfigured type of HARQ process for a particular transmission (e.g., downlink transmission, uplink transmission, or both downlink and uplink transmissions). For example, the type of HARQ process applied may be based on dynamic indications or assignments in Downlink Control Information (DCI) and/or grant information (e.g., dynamic or configured). The WTRU may determine the type of HARQ process based on, for example, the type of DCI received for the transmission. For example, the WTRU may apply a first HARQ process if the WTRU receives a first DCI type or format, and apply a second HARQ process otherwise (e.g., and/or if the WTRU receives a second DCI type or format).

In an example of a dynamic approach, the WTRU may apply a preconfigured type of HARQ process for a particular transmission (e.g., downlink transmission, uplink transmission, or both downlink and uplink transmissions). For example, the type of HARQ process applied may be based on the type of scheduling information. In an example, the WTRU may apply a first process to HARQ processes associated with semi-statically configured assignments and/or grants and may apply a second process to dynamically scheduled transmissions. For example, the WTRU may apply a first process to HARQ processes associated with semi-statically configured assignments of a first type (e.g., semi-persistent scheduling (SPS) type 0), and may apply a second process otherwise.

In an example, the WTRU may determine the type of HARQ process to be applied to a transmission based on, for example, the HARQ process identification that may be included in the UL grant. In an (e.g., additional or alternative) example, the WTRU may determine the type of HARQ process to apply (e.g., for reception) based on, for example, a HARQ process identification, which may be included in Downlink Control Information (DCI) carrying a Downlink (DL) assignment.

In an example, the WTRU may (e.g., be configured to) apply a first HARQ process to HARQ processes scheduled for HARQ PID ═ x, where x may be, for example, zero (PID ═ 0), which may represent a closed loop HARQ process. Otherwise, the WTRU may (e.g., be configured to) apply the second process (e.g., an open-loop HARQ process). The WTRU MAC layer may instruct the PHY layer to generate HARQ feedback for (e.g., only for) DL transmissions with HARQ PID ═ x. The WTRU MAC layer may assume (e.g., implicitly assume) HARQ ACKs for UL transmissions other than HARQ PID x (e.g., based on HARQ feedback for HARQ PID x), such that, for example, HARQ processes may be suspended and/or HARQ buffers may be cleared after the transmission. The WTRU may use different (e.g., legacy) processes (e.g., NR R15 HARQ processes, LTE R8 HARQ processes, etc.) to process the HARQ feedback, e.g., for other PID values. The WTRU may be configured, for example, such that UL HARQ processes (e.g., UL HARQ processes configured for open-loop HARQ processing or for stateless HARQ processing) may not reach a maximum number of HARQ retransmissions and/or may not trigger a Radio Link Failure (RLF). The WTRU may be configured to not count and/or update the HARQ retransmission counter, for example. For example, the WTRU may be (e.g., configured to) switch a New Data Indicator (NDI) for a HARQ process corresponding to a HARQ PID configured for stateless HARQ processing (e.g., HARQ PID | ═ 0 in the previous example). The WTRU may perform a different (e.g., legacy) determination (e.g., NR R15 procedure for handing over NDI, LTE R8 procedure for handing over NDI, etc.) for handing over the NDI (e.g., otherwise).

The WTRU may be (e.g., configured to) transmit an indication of long-term HARQ performance to a network entity, e.g., without HARQ feedback. The network entity may use the indication to, for example, adjust the number of blind retransmissions. For example, the indication may be conveyed via an RLC status report. For example, long-term HARQ feedback may be triggered based on the number of Cyclic Redundancy Check (CRC) failures within a time period. For example, the RLC status report may be triggered based on the number of CRC failures over a period of time. The triggered RLC status report may or may not include the long term HARQ feedback.

The WTRU may be configured with Discontinuous Reception (DRX). DRX behavior may be based on (e.g., may be a function of) the HARQ process. In an example, the WTRU may (e.g., be configured to) handle one or more timers associated with DRX based on, for example, HARQ process types associated with DL assignments and/or UL grants.

For example, if (e.g., when) DRX is configured, the WTRU may perform various actions (e.g., as described herein). A MAC entity of the WTRU (e.g., in an active time state) may monitor a Physical Downlink Control Channel (PDCCH), e.g., to determine whether the PDCCH indicates an UL transmission or a DL transmission. The WTRU may determine whether the corresponding HARQ process type is open-loop or closed-loop.

The WTRU may start a drx-HARQ-RTT-TimerDL (drx-HARQ-RTT-timer DL) timer for a corresponding HARQ process (e.g., for a DL transmission with a corresponding closed loop HARQ process type indicated by the PDCCH), for example, in a first symbol (e.g., after the end of the corresponding transmission carrying the DL HARQ feedback), and stop the drx-retransmission TimerDL (drx-retransmission timer DL) timer for the corresponding HARQ process. The WTRU may, for example, start or restart a drx-retransmission timerdl timer for the corresponding HARQ process (e.g., for DL transmissions with the corresponding open-loop HARQ process type indicated by the PDCCH).

The WTRU may start a drx-HARQ-RTT-timerll (drx-HARQ-RTT-timer UL) timer for the corresponding HARQ process (e.g., for a UL transmission with a corresponding closed loop HARQ process type indicated by the PDCCH), for example, in a first symbol (e.g., after the end of a first repetition of a corresponding PUSCH transmission), and stop the drx-retransmission timerll (drx-retransmission timer UL) timer for the corresponding HARQ process. The WTRU may, for example, start or restart a drx-retransmission timerll (drx-retransmission timer UL) timer for the corresponding HARQ process (e.g., for the UL transmission indicated by the PDCCH and the corresponding open-loop HARQ process type).

The WTRU may (e.g., be configured to) perform DRX adaptation, e.g., to provide or account for propagation delay. DRX adaptation may be performed by the WTRU (e.g., autonomously) and/or may be based on a configuration and/or command received from a network entity. In an example, DRX may be used to provide power savings at the WTRU, e.g., based on (e.g., as a function of) data transmission/reception activity. Non-terrestrial networks may experience large propagation delays (e.g., 95ms for LEO and 272ms for GEO). For example, the WTRU may not (e.g., be required to) monitor the PDCCH if (e.g., when) not in the active time (e.g., in the inactive time). The active time may include, for example, a time when one or more of the following timers are running: DRX-duration timer; drx-onDurationTimer (drx-on duration timer); drx-InactivityTimer (drx-inactivity timer); drx-retransmission timerdl (drx-retransmission timer DL); drx-retransmission timer UL (drx-retransmission timer UL); or ra-ContentionResolutionTimer (ra-contention resolution timer). In an example, the active time may include, for example, a time at which the scheduling request is pending. For example, if the WTRU stays active while waiting for a response from a network with significant propagation delay (e.g., NTN), unnecessary power consumption may occur.

The WTRU may (e.g., be configured to) apply Discontinuous Reception (DRX), for example, based on propagation delay. The application of DRX may be used to attempt to maximize sleep time without a large negative impact on performance (e.g., latency, reliability, etc.). In an example, the WTRU may enter the sleep mode for a preconfigured duration upon completion of the UL transmission (for which a response to the UL transmission is expected), e.g., if no other DL reception and/or UL transmission is expected before the expected response to the UL transmission. In an example, the WTRU may be (e.g., configured to) sleep (e.g., instead of continuously monitoring the PDCCH), e.g., while waiting for a response from the network entity. In an (additional and/or alternative) example, the WTRU may apply DRX based on the propagation delay for UL transmissions including, but not limited to, transmission of a preamble, MSG3, scheduling request, etc. In an example, the WTRU may be (e.g., configured to) start a timer (e.g., a propagation delay timer) upon UL transmission. In an example, the WTRU may not (e.g., be required to) monitor the PDCCH, for example, if a propagation delay timer is running. In an example, the WTRU may not (e.g., be required to) monitor the PDCCH, for example, if a propagation delay timer is running and one or more of the following timers are not running: drx-onDurationTimer; drx-inactivytytimer; drx-retransfissiontimerdl; or drx-retransmission timerll. In an example, the WTRU may not (e.g., be required to) monitor the PDCCH, for example, if the propagation delay timer is running and the ra-ContentionResolutionTimer is running. In an example, the WTRU may not (e.g., be required to) monitor the PDCCH, for example, if a propagation delay timer is running and a response to the scheduling request is pending. The WTRU may (e.g., be configured to) wake up and monitor the PDCCH, for example, upon expiration of a propagation delay timer.

Fig. 5 shows an example associated with logical channel restriction/logical channel prioritization.

Systems and methods are described herein for providing logical channel prioritization and/or multiplexing that may be based on HARQ processes (e.g., HARQ process type or HARQ process ID). The WTRU may (e.g., be configured to) select logical channel(s) for UL transmission, e.g., based on HARQ characteristics associated with the UL grant. For example, fig. 5 shows a UL grant identifying a HARQ process ID "x" associated with an open-loop HARQ process type as shown under "HARQ process configuration". In this example, one or more of logical channels 2 … n may be selected for UL transmissions (e.g., LCH1 has been restricted from use because LCH1 is a closed-loop type as shown in "logical channel configuration").

The WTRU may be configured with applicable HARQ characteristics associated with the logical channel. The HARQ characteristics may correspond to the applicable process ID(s) and/or applicable HARQ process type (e.g., open-loop or closed-loop). In an example, one or more UL grants may provide various reliability values or various delay values to achieve a given reliability level. One or more UL transmissions (e.g., one or more UL transmissions having a priority above a threshold in a category indicated as having a higher priority than one or more other categories, etc.) may be mapped to an UL grant that provides better reliability. For example, a Logical Channel (LCH) associated with a signaling radio bearer may be mapped to an UL grant with HARQ feedback enabled. The mapping may be an indication of association, where the indication may be received (e.g., via a signal), preconfigured, etc. The mapping restriction may be an indication of a selection (e.g., a selection of one or more channels allowed for use, a selection of one or more channels not allowed for use, etc.), where the indication may be received (e.g., via signal reception), preconfigured, etc.

The WTRU may be configured with LCH mapping restrictions associated with the type of HARQ process (e.g., as shown in fig. 5, where use of LCH1 is restricted based on the HARQ process ID and its associated HARQ process type indicated in the UL grant, and use of LCH2 … n is allowed based on the HARQ process ID and its associated HARQ process type indicated in the UL grant). For example, data available for transmission of a first set of LCH(s) can be multiplexed to a transport block corresponding to HARQ process(s) for a first type of HARQ process, and data available for transmission of a second set of LCH(s) can be multiplexed based on a second set of HARQ process(s) for a second type of HARQ process.

The WTRU may perform Logical Channel Prioritization (LCP), for example, based on (e.g., (pre-) configured) mapping restrictions between a logical channel and the allowed HARQ process type(s) for the logical channel (e.g., the mapping restrictions are on selection of one or more logical channels associated with the allowed HARQ process type (s)). For example, the WTRU may perform LCP based on (e.g., (pre-) configured) mapping restrictions between the logical channel and the allowed HARQ process ID(s) for the logical channel (e.g., as shown in fig. 5, where the LCH1 is restricted for transmission based on the LCH1 being associated with a closed-loop HARQ process type that is not allowed (e.g., not associated with an indicated HARQ process ID), and/or the LCH2 and LCH n are allowed for transmission based on the LCH2 and LCH n being associated with an open-loop HARQ process type that is allowed). The WTRU may transmit UL MAC SDUs from a logical channel using a UL grant that includes the HARQ process ID(s) configured for the logical channel and/or applicable HARQ process types (e.g., one or more allowed LCHs resulting from the mapping restriction). For example, if the configured HARQ characteristics of a logical channel do not match the HARQ characteristics of the UL grant (e.g., as shown in fig. 5, where LCH1 is skipped, e.g., restricted from being used, based on the HARQ process type not matching the HARQ process type associated with the HARQ process ID indicated in the UL grant), the WTRU may skip the logical channel. For example, the WTRU may apply a lower priority to logical channels whose HARQ characteristics do not match the HARQ characteristics of the UL grant than to logical channels whose HARQ characteristics match the HARQ characteristics of the UL grant. For example, if a logical channel is not configured with applicable HARQ characteristics, the WTRU may assume (e.g., based on the configuration) that the logical channel may be mapped to any UL grant without regard to the applicable HARQ characteristics.

The WTRU may be configured with (e.g., common to) a Service Request (SR) configuration for an LCH configured with mapping restrictions that may correspond to (e.g., common to) types of HARQ processing. In an example, the WTRU may perform transmission of the SR (e.g., on a Physical Uplink Control Channel (PUCCH) or on a Physical Random Access Channel (PRACH)) using the first set of resources, e.g., if new data becomes available for transmission of the LCH with a mapping restriction for the first HARQ process type. Otherwise, the WTRU may perform transmission of the SR using the second set of resources, for example.

For example, the WTRU may perform LCP accounting for the time that data is stored in the buffer. In an example, the WTRU may perform LCP based on the age (Δ T) of the data in the logical channel. The age of the data may measure the time the data is stored in the buffer. For example, the age of the data may be determined based on the arrival time of the data in the buffer. For example, if the WTRU selects a logical channel to meet the configured resources, the WTRU may consider the Δ T of the (e.g., each) logical channel. In an example, the WTRU may perform LCP, for example, by selecting the logical channel based on the time that data has been stored in a buffer and the priority of the data (e.g., in combination with the token bucket Bj value of the logical channel). For example, a function f (Δ T, priority) may be defined and used to select a logical channel. The function f (Δ T, priority) may be calculated, for example, based on the priority of the logical channel and the value of Δ T. The function f (Δ T, priority) may depend on the Bj value of the logical channel (e.g., the current number of available tokens in the token bucket scheme). In an example associated with the function f, the WTRU may be configured to select the logical channel belonging to the highest priority. Among these selected logical channels, the WTRU may be configured to serve the logical channels based on a descending order of Δ ts. The process may continue to the next priority until the logical channels (e.g., all logical channels) are served or UL resources in the grant (e.g., all UL resources) are exhausted, e.g., to an earlier arrival. In an example associated with the function f, the WTRU may be configured to select the logical channel(s) whose Δ T value is above a threshold. Among these selected logical channels, the WTRUs may be configured to serve these logical channels based on their priority levels (e.g., highest to lowest). The process may continue in order of decreasing Δ T first and decreasing priority second. This may continue until the logical channels (e.g., all logical channels) are served or the UL resources in the grant (e.g., all UL resources) are exhausted, e.g., by an earlier arrival.

MAC control element (MAC CE) multiplexing may be performed, for example, according to HARQ processes. The WTRU may (e.g., be configured to) select one or more MAC CEs for transmission, e.g., based on HARQ characteristics associated with the UL grant. For example, the WTRU may be (e.g., configured to) multiplex the MAC CE to the MAC PDU if the HARQ characteristics associated with the UL grant match the HARQ characteristics for the MAC CE (e.g., preconfigured). The HARQ characteristics may correspond to the applicable process ID(s) and/or the applicable HARQ process type(s). In an example, the (e.g., each) MAC CE may be configured with (e.g., a single) applicable HARQ characteristic. In (e.g., additional and/or alternative) examples, the HARQ characteristics may be configured by MAC CE type. For example, if multiple UL grants provide different reliabilities or different delays to achieve a given reliability, MAC CE(s) (e.g., one or more critical MAC CEs) may be mapped to the UL grant that provides better reliability. In an example, a failure in a MAC CE transmission may not be recoverable via higher layer retransmissions (e.g., RLC layer retransmissions). MAC CE transmission may be allowed on the UL grant associated with the enabled HARQ feedback.

The WTRU may (e.g., be configured to) apply prioritization of logical channels based on, for example, HARQ characteristics associated with UL grants. In an example, the WTRU may apply the first prioritization order, for example, if the UL grant indicates (e.g., explicitly or implicitly indicates) that HARQ feedback is enabled. For example, the WTRU may apply the second prioritization order if the UL grant indicates (e.g., explicitly or implicitly indicates) that HARQ feedback is disabled. In an example of the first prioritization order, the Buffer Status Report (BSR) and the Power Headroom (PHR) MAC CE may have a lower priority than data from a logical channel (e.g., other than the uplink common control channel (UL-CCCH)). In an example of a second prioritization order, the BSR and PHR MAC CEs may have a higher priority than data from a logical channel (e.g., other than UL-CCCH).

Systems and methods for covering (overriding) HARQ restrictions are described. For example, if the MAC CE is triggered, the WTRU may (e.g., be configured to) start a timer. For example, the WTRU may reset a timer if the MAC CE is successfully transmitted. For example, the WTRU may transmit the MAC CE (e.g., while a timer is running) if the UL grant matches a pre-configured HARQ characteristic for the MAC CE. For example, if the MAC CE cannot be sent before the timer expires, the WTRU may override the HARQ characteristic configuration and send the MAC CE at the earliest available UL grant.

For example, the WTRU may skip HARQ feedback transmission if the received DL transport block is associated with an open loop HARQ process type. The WTRU may (e.g., be configured to) override a rule (e.g., a rule that HARQ feedback transmission is skipped if the received DL transport block is associated with an open loop HARQ process type), e.g., based on the contents of the MAC PDU. For example, if the WTRU determines that the DL MAC PDU includes a MAC CE, the WTRU may ignore the HARQ process type configuration and transmit HARQ feedback.

The WTRU may (e.g., be configured to) multiplex a first set of MAC CEs to transport blocks corresponding to HARQ process (es) of a first type of HARQ process. Other set(s) of MAC CEs may be multiplexed to the transport blocks corresponding to the second set(s) of HARQ processes. In an example, the set of MAC CEs may be a function of a type of MAC CE (e.g., BSR, PHR).

UL power control may be based on HARQ processing. In an example, the WTRU may be (e.g., configured to) associate one or more parameters and/or a table for power control with a set of HARQ process ID(s) and/or applicable HARQ process type. Examples of the parameters and/or tables may include one or more of the following: (a) a power offset that can increase/decrease the final power level of the transmission; (b) fractional power values, which may be used for fractional path loss compensation; (c) a Transmit Power Command (TPC) command mapping table that may map TPC command fields in DCI to absolute and/or cumulative power adjustments; (d) target power P for power setting of transmission_oValue and/or adjustment.

The WTRU may be configured with a power offset value associated with (e.g., may be associated with) a HARQ process type that may require HARQ retransmission. The WTRU may be configured with another power offset value that may be associated with other HARQ process types that may not require HARQ retransmissions.

The WTRU may be configured with a TPC command mapping table that may be associated with HARQ process types that may not require HARQ retransmissions. The WTRU may be configured with another TPC command mapping table that may be associated with HARQ process types that may require HARQ retransmissions.

The WTRU may (e.g., be configured to) associate the TPC command mapping table with the HARQ process type (e.g., in a one-to-one relationship). The WTRU may (e.g., further) be configured to perform an operation on the absolute and/or cumulative power adjustment values according to the HARQ process type (e.g., using parameter a addition or multiplication). For example, the WTRU may be configured to apply a first operation (e.g., addition or multiplication) for absolute and/or cumulative power adjustment values associated with a first HARQ process type (e.g., HARQ process type requires HARQ retransmission) using a first parameter (e.g., α 1) and a second operation (e.g., addition or multiplication) for absolute and/or cumulative power adjustment values associated with a second HARQ process type (e.g., HARQ process type does not require HARQ retransmission) using a second parameter (e.g., α 2).

The WTRU may (e.g., be configured to) cover one or more TPC codepoints in the TPC command mapping table, e.g., to have different meanings for the covered codepoints. In an example, the WTRU may be (e.g., configured to) override a TPC code point in the TPC command mapping table, e.g., to indicate that the TPC code point in the TPC command is for an absolute "Pcmax".

The WTRU may be (e.g., configured to) use a Modulation and Coding Scheme (MCS) table for one type of HARQ process. In an example, a WTRU may be configured with a table having a low block error rate (BLER) target. The MCS table (e.g., configured with a table with a low BLER target) may be used, for example, for HARQ process types that may not require HARQ retransmissions. In an example, the WTRU may be configured with a table with a high (higher) BLER target. The MCS table (e.g., configured with a table with a high (higher) BLER target) may be used for HARQ process types that may require HARQ retransmissions.

The WTRU may (e.g., be configured to) associate the MCS table with the TPC command mapping table and/or vice versa. In an example, the WTRU may (e.g., be configured to) use one MCS table at a time. The WTRU may be configured (e.g., based on the active MCS table) to use a corresponding TPC command mapping table, e.g., to interpret TPC commands for power control.

The WTRU may (e.g., be configured to) determine HARQ behavior associated with the configured grant, e.g., based on the HARQ configuration. In an example, the WTRU may determine HARQ behavior associated with the configured grant based on (e.g., implicitly based on) a HARQ configuration for transmissions associated with the dynamic grant. For example, if open-loop HARQ is configured for dynamic grants, the WTRU may apply open-loop HARQ functionality to transmissions associated with the configured grants. In an example, the WTRU may apply HARQ functionality based on, for example, HARQ processes allocated for the configured grants and HARQ behaviors (e.g., open/closed/stateless) configured for those HARQ processes.

In an example (e.g., in addition to and/or in the alternative), the WTRU may (e.g., be configured to) apply a distinct HARQ functionality to the configured grant, e.g., as compared to a transmission with a dynamic grant. For example, the WTRU may be (e.g., configured to) apply HARQ behavior to transmissions without dynamic grants (e.g., configured grants). For example, the HARQ behavior may be configured via RRC signaling (e.g., in a configuredGrantConfig information element).

The WTRU may (e.g., be configured to) determine the HARQ type associated with (e.g., each) resource in the configured grant. The WTRU may be (e.g., configured to) determine that (e.g., each) resource may belong to or may be associated with one or more HARQ types (e.g., stateless HARQ, open-loop HARQ, and/or closed-loop HARQ).

The HARQ type associated with each resource may be determined, for example, based on one or more of the following parameters: a number of HARQ processes assigned to the configured grant; a period of the configured license; a time gap between two consecutive HARQ processes; and/or HARQ reuse time (e.g., minimum time for the WTRU to reuse the same HARQ process). The WTRU may (e.g., thereby) selectively buffer transmission packets for possible HARQ retransmissions, e.g., without sacrificing data rate.

In an (e.g., additional and/or alternative) example, the WTRU may be (e.g., configured to) use a stateless HARQ transmission for the resources in the configured grant. In an example, the WTRU may (e.g., be configured to) use stateless HARQ transmissions for resources in the configured grant, e.g., if one or more (e.g., each) HARQ processes assigned to the resources in the configured grant are in use.

Figure 6 shows an example of the WTRU determining the HARQ type of each resource in the configured grant. As shown in the example in fig. 6, the WTRU may have two HARQ processes (e.g., identified by PID1 and PID2) assigned to the configured grant. In an example (e.g., as shown in option 1), the time gap may be configured for two consecutive HARQ processes (e.g., PID1 and PID 2): 2 by periodicity. In an (e.g., additional and/or alternative) example (e.g., as shown in option 2), no time gap may be configured between two consecutive HARQ processes (e.g., PID1 and PID 2). In an example (e.g., as shown in option 1 and option 2), the WTRU may determine (e.g., based on the configuration) a HARQ type associated with (e.g., each) resource in the configured grant.

Although the solutions provided herein may be described with reference to LTE, LTE-a, New Radio (NR), or 5G specific protocols, and may be described using non-terrestrial networks, it is to be understood that the solutions described herein are not limited to those scenarios, and may also be applicable to other wireless systems, deployments, or networks. The solutions discussed herein may be applicable at least to network deployments with similar characteristics, e.g., network deployments with similar characteristics in terms of long latency, round trip time delay, and/or non-stationary network components (e.g., gnbs) (e.g., satellites, antennas, etc.).

Although features and elements are described above in particular combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer readable media include electronic signals (transmitted over wired or wireless connections) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.