Enhancement of early data transmission (EDT) and preconfigured uplink resource (PUR) in internet of things (IOT) non-terrestrial networks (NTN)

Abstract

This disclosure relates to Physical Uplink Shared Channel (PUSCH) and Physical Random Access Channel (PRACH) coverage enhancements for Non-Terrestrial Networks (NTNs). In particular, mechanisms to support uplink multiplexing for Early Data Transmission (EDT) in Internet of Things (IoT) NTN transmissions, e.g., via the use of Orthogonal Cover Codes (OCC), are disclosed herein. In other embodiments, mechanisms to support preconfigured uplink resource (PUR) usage in IoT NTN transmissions are disclosed. In still other embodiments, mechanisms to support uplink multiplexing for PUR in IoT NTN transmissions are disclosed. The embodiments disclosed herein thus provide uplink capacity enhancements, especially for IoT NTN transmissions, as well as enhancements to existing PUR / EDT procedures to minimize the amount of necessary signaling to complete a PUR / EDT transaction. The PUR / EDT enhancements disclosed herein may be used with or without the use of OCC.

Description

ENHANCEMENT OF EARLY DATA TRANSMISSION (EDT) AND PRECONFIGURED UPLINK RESOURCE (PUR) IN INTERNET OF THINGS (IOT) NON-TERRESTRIAL NETWORKS (NTN)TECHNICAL FIELD

[0001] The present application relates to wireless devices and wireless networks, including devices, circuits, and methods for providing enhanced capacity and throughput for uplink (UL) communication channels, such as the Physical Uplink Shared Channel (PUSCH) and the Physical Random Access Channel (PRACH) , and especially in the case of Internet of Things (IoT) devices operating on non-terrestrial networks (NTN) transmissions.BACKGROUND

[0002] Wireless communication systems are rapidly growing in usage. In recent years, wireless devices such as smart phones and tablet computers have become increasingly sophisticated. In addition to supporting telephone calls, many mobile devices now provide access to the Internet, email, text messaging, and navigation using the global positioning system (GPS) and are capable of operating sophisticated applications that utilize these functionalities. Additionally, there exist numerous different wireless communication technologies and standards. Some examples of wireless communication standards include GSM, UMTS (associated with, for example, WCDMA or TD-SCDMA air interfaces) , Long-Term Evolution (LTE) , LTE Advanced (LTE-A) , HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD) , IEEE 802.11 (WLAN or Wi-Fi) , and BLUETOOTHTM, among others.

[0003] The ever-increasing number of features and functionality introduced in wireless communication devices also creates a continuous need for improvement in both wireless communications and in wireless communication devices. To increase coverage and better  serve the increasing demand and range of envisioned uses of wireless communication, in addition to the communication standards mentioned above, there are further wireless communication technologies under development, including the fifth generation (5G) standard and New Radio (NR) communication technologies. Accordingly, improvements in the field in support of such development and design are desired.

[0004] Cellular communication via satellite, e.g., the use of NTNs, is drawing more attention from the industry because of its ability to provide ubiquitous and reliable coverage, e.g., connections anywhere and anytime. One of the challenges for cellular communications via satellite is the link budget, or maximal allowed path loss to achieve certain decoding reliability at the receiver. Satellite communications often suffer from large propagation loss (i.e., path loss) due to the satellite’s large distance from the ground (which applies to both uplink and downlink communication) . For example, Low Earth Orbit (LEO) satellites may have up to 1, 200 miles of altitude. Another issue with satellite communication is the limited total onboard power supply available on most satellites, typically only a few hundred Watts. The limited power needs to be split across multiple concurrent cells / beams, due, in part, to the fact that each satellite needs to cover large areas on Earth’s surface. However, attempting to solve this limitation by having a smaller number of beams used per satellite would necessitate more satellites to be used and result in an even higher cost. Satellite communications are also subject to International Telecommunication Union (ITU) Power Flux Density (PFD) limitations.

[0005] Another challenge faced with regard to IoT devices using NTNs is the need for greater uplink capacity and throughput, considering the much larger coverage area of NTN as compared to traditional terrestrial networks-as well as the potentially much larger number of UEs in the coverage area. In Release-15, the concept of early data transmission (EDT) in IoT devices (e.g., enhanced machine-type communication (eMTC) devices and / or narrow band IoT  (NB-IoT) devices) was introduced. The core concept behind EDT was to enable uplink and downlink data transmissions in Message 3 (Msg3) and Message 4 (Msg4) , respectively. Preconfigured uplink resource (PUR) transmissions were also introduced in Release-16, in an attempt to improve uplink transmissions, predominantly for stationary UEs with either periodic or pseudo-varying traffic. With the use of PUR, both the random access preamble transmission (i.e., Msg1) and the random access response (i.e., Msg2) may be omitted, assuming a UE has a valid time alignment (TA) . However, further enhancements are desired to existing PUR and EDT procedures, and, in particular, to provide enhanced uplink capacity to IoT devices operating on NTNs-with minimal increases to signaling overhead.SUMMARY

[0006] In accordance with one or more aspects, a method of orthogonal cover code (OCC) indication for early data transmission (EDT) in user equipment (UE) is disclosed, the method comprising: receiving, from a network, a first OCC configuration; selecting a Physical Random Access Channel (PRACH) preamble from among a first plurality of configured EDT PRACH preambles; receiving, from the network, a Random Access Response (RAR) message (Msg2) comprising uplink (UL) grant information; determining an OCC sequence to utilize for a Radio Resource Control (RRC) connection request message (Msg3) ; and transmitting the Msg3 message to the network using the determined OCC sequence and UL grant information.

[0007] According to some aspects, the first OCC configuration comprises a predetermined maximum number of OCC sequences.

[0008] According to some aspects, the first OCC configuration is received in a System Information Block (SIB) .

[0009] According to some aspects, the first plurality of configured EDT PRACH preambles further comprises: a first subset of EDT PRACH preambles configured for use with OCC; and  a second subset of EDT PRACH preambles configured for use without OCC. According to some such aspects, the selected PRACH preamble is from the first subset of EDT PRACH preambles.

[0010] According to some aspects, the determination of the OCC sequence is based, at least in part, on information received in the RAR message. According to some such aspects, the determination of the OCC sequence is further based, at least in part, on information received in zero padding bits of the RAR message.

[0011] According to some aspects, the determination of the OCC sequence is based, at least in part, on information received in a Medium Access Control (MAC) RAR message.

[0012] According to some aspects, the determination of the OCC sequence is derived implicitly based on at least one of: the selected PRACH preamble; a Temporary Cell Radio Network Temporary Identifier (TC-RNTI) received in the RAR message; a UE Temporary Mobile Subscriber Identity (TMSI) ; or an indication received in a System Information Block (SIB) .

[0013] According to some aspects, the UE comprises an Internet of Things (IoT) device.

[0014] According to some aspects, the network comprises a Non-Terrestrial Network (NTN) .

[0015] According to other aspects, a method of time alignment validation for preconfigured uplink resource (PUR) transmissions in user equipment (UE) is disclosed, the method comprising: receiving, from a first Non-Terrestrial Network (NTN) , a first PUR configuration, wherein the first PUR configuration indicates a Reference Signal Received Power (RSRP) measurement change threshold; determining, at a first time, a first serving satellite RSRP value and a first UE-satellite parameter associated with the first serving satellite RSRP value; determining, at a second time, a second UE-satellite parameter; estimating, based on: the first  UE-satellite parameter, the determined second UE-satellite parameter, and the first serving satellite RSRP value: an adjusted first serving satellite RSRP value; determining, at the second time, a second serving satellite RSRP value; and determining, based, at least in part, on: the adjusted first serving satellite RSRP value; the second serving satellite RSRP value; and the RSRP measurement change threshold to transmit on a next PUR occasion.

[0016] According to some aspects, when no satellite is serving the UE for a given PUR occasion, the given PUR occasion is not counted towards a threshold of consecutive skipped PUR occasions after which the first PUR configuration is released.

[0017] According to other aspects, skipped PUR occasions count towards a threshold of consecutive skipped PUR occasions after which the first PUR configuration is released, whether a skipped PUR occasion is due to a lack of serving satellite or a lack of data for transmission.

[0018] According to still other aspects, a number of contiguously skipped PUR occasions is tracked, whether the contiguously skipped PUR occasions are due to a lack of serving satellite or a lack of data for transmission. According to some such aspects, the first PUR configuration is released when the number of contiguously skipped PUR occasions reaches a threshold value.

[0019] According to some aspects, the second UE-satellite parameter comprises at least one of: an estimated second UE-satellite distance at the second time; or an estimated UE-satellite elevation angle at the second time.

[0020] According to some aspects, the determination to transmit on a next PUR occasion further comprises determining that at least one of the following conditions are met: a Global Navigation Satellite System (GNSS) validity duration of the UE has not passed; satellite ephemeris data for a serving satellite of the UE are valid; or a common timing alignment (TA)  for a serving satellite and the UE are valid.

[0021] According to still other aspects, a method of orthogonal cover code (OCC) indication for preconfigured uplink resource (PUR) transmissions in user equipment (UE) is disclosed, the method comprising: transmitting, to a first Non-Terrestrial Network (NTN) , in a first PUR configuration request, a first OCC capability; receiving, from the first NTN, a first PUR configuration, wherein the first PUR configuration indicates a first OCC sequence; applying the indicated first OCC sequence to Physical Uplink Shared Channel (PUSCH) transmissions in PUR; receiving, from the first NTN, uplink (UL) grant information for PUSCH retransmissions, wherein the UL grant information comprises an indication of a second OCC sequence; and transmitting PUSCH retransmissions to the first NTN using the second OCC sequence and UL grant information.

[0022] According to some aspects, the first OCC sequence and the second OCC sequence are the same. According to other aspects, the first OCC sequence and the second OCC sequence are different.

[0023] According to some aspects, the second OCC sequence is indicated via a DCI Format 6-0A or a DCI Format 6-0B.

[0024] According to some aspects, the indication of the first OCC sequence comprises an indication of an OCC sequence index.

[0025] The various methods and techniques summarized in this section may likewise be performed by a device comprising: a receiver; a transmitter; and a processor configured to perform any of the various methods and techniques summarized herein. The various methods and techniques summarized in this section may likewise be stored as instructions in a non-transitory computer-readable medium, wherein the instructions, when executed, cause the performance of the various methods and techniques summarized herein. A baseband processor  may also be configured to cause a user equipment (UE) device to perform the various methods and techniques summarized herein.

[0026] This Summary is intended to provide a brief overview of some of the subject matter described in this document. Accordingly, it will be appreciated that the above-described features are merely examples and should not be construed to narrow the scope or spirit of the subject matter described herein in any way. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following Detailed Description, Figures, and Claims.BRIEF DESCRIPTION OF DRAWINGS

[0027] A better understanding of the present subject matter may be obtained when the following detailed description of various aspects is considered in conjunction with the following drawings:

[0028] Figure 1 illustrates an example wireless communication system, according to some aspects.

[0029] Figure 2 illustrates another example of a wireless communication system including non-terrestrial communications, according to some aspects.

[0030] Figure 3 illustrates an example block diagram of a UE, according to some aspects.

[0031] Figure 4 illustrates an example block diagram of a Base Station (BS) , according to some aspects.

[0032] Figure 5 illustrates time alignment (TA) validation examples in NTN PUR, according to some aspects.

[0033] Figure 6 is a flowchart detailing a method of orthogonal cover code (OCC)  indication for early data transmission (EDT) in user equipment (UE) , according to some aspects.

[0034] Figure 7 is a flowchart detailing a method of time alignment validation for preconfigured uplink resource (PUR) transmissions in UE, according to some aspects.

[0035] Figure 8 is a flowchart detailing a method of OCC indication for PUR transmissions in UEs, according to some aspects.

[0036] While the features described herein may be susceptible to various modifications and alternative forms, specific aspects thereof are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to be limiting to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the subject matter as defined by the appended claims.DETAILED DESCRIPTION

[0037] This disclosure relates to Physical Uplink Shared Channel (PUSCH) and Physical Random Access Channel (PRACH) coverage enhancements for Non-Terrestrial Networks (NTNs) . In particular, mechanisms to support uplink multiplexing for Early Data Transmission (EDT) in Internet of Things (IoT) NTN transmissions, e.g., via the use of Orthogonal Cover Codes (OCC) , are disclosed herein. In other embodiments, mechanisms to support preconfigured uplink resource (PUR) usage in IoT NTN transmissions are disclosed. In still other embodiments, mechanisms to support uplink multiplexing for PUR in IoT NTN transmissions are disclosed. The embodiments disclosed herein thus provide uplink capacity enhancements, especially for IoT NTN transmissions, as well as enhancements to existing PUR / EDT procedures to minimize the amount of necessary signaling to complete a PUR / EDT transaction. The PUR / EDT enhancements disclosed herein may be used with or without the use of OCC.

[0038] The following is a glossary of additional terms that may be used in this disclosure:

[0039] Memory Medium –Any of various types of non-transitory memory devices or storage devices. The term “memory medium” is intended to include an installation medium, (e.g., a CD-ROM, floppy disks, or tape device; a computer system memory or random-access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM) , a non-volatile memory such as a Flash, magnetic media (e.g., a hard drive, or optical storage; registers, or other similar types of memory elements) . The memory medium may include other types of non-transitory memory as well or combinations thereof. In addition, the memory medium may be located in a first computer system in which the programs are executed or may be located in a second different computer system which connects to the first computer system over a network, such as the Internet. In the latter instance, the second computer system may provide program instructions to the first computer for execution. The term “memory medium” may include two or more memory mediums which may reside in different locations (e.g., in different computer systems that are connected over a network) . The memory medium may store program instructions (e.g., embodied as computer programs) that may be executed by one or more processors.

[0040] Carrier Medium –a memory medium as described above, as well as a physical transmission medium, such as a bus, network, and / or other physical transmission medium that conveys signals such as electrical, electromagnetic, or digital signals.

[0041] Programmable Hardware Element -includes various hardware devices comprising multiple programmable function blocks connected via a programmable interconnect. Examples include FPGAs (Field Programmable Gate Arrays) , PLDs (Programmable Logic Devices) , FPOAs (Field Programmable Object Arrays) , and CPLDs (Complex PLDs) . The programmable function blocks may range from fine grained (combinatorial logic or look up tables) to coarse grained (arithmetic logic units or processor  cores) . A programmable hardware element may also be referred to as “reconfigurable logic. ”

[0042] User Equipment (UE) (also “User Device, ” “UE Device, ” or “Terminal” ) –any of various types of computer systems or devices that are mobile or portable and that perform wireless communications. Examples of UE devices include mobile telephones or smart phones (e.g., iPhoneTM, AndroidTM-based phones) , portable gaming devices (e.g., Nintendo SwitchTM, Nintendo DSTM, PlayStation VitaTM, PlayStation PortableTM, Gameboy AdvanceTM, iPhoneTM) , laptops, wearable devices (e.g., smart watch, smart glasses) , PDAs, portable Internet devices, music players, data storage devices, other handheld devices, in-vehicle infotainment (IVI) , in-car entertainment (ICE) devices, an instrument cluster, head-up display (HUD) devices, onboard diagnostic (OBD) devices, dashtop mobile equipment (DME) , mobile data terminals (MDTs) , Electronic Engine Management System (EEMS) , electronic / engine control units (ECUs) , electronic / engine control modules (ECMs) , embedded systems, microcontrollers, control modules, engine management systems (EMS) , networked or “smart” appliances, machine type communications (MTC) devices, machine-to-machine (M2M) , internet of things (IoT) devices, and the like. In general, the terms “UE” or “UE device” or “terminal” or “user device” may be broadly defined to encompass any electronic, computing, and / or telecommunications device (or combination of devices) that is easily transported by a user (or vehicle) and capable of wireless communication.

[0043] Wireless Device –any of various types of computer systems or devices that perform wireless communications. A wireless device may be portable (or mobile) or may be stationary or fixed at a certain location. A UE is an example of a wireless device.

[0044] Communication Device –any of various types of computer systems or devices that perform communications, where the communications may be wired or wireless. A communication device may be portable (or mobile) or may be stationary or fixed at a certain location. A wireless device is an example of a communication device. A UE is another  example of a communication device.

[0045] Base Station –The terms “base station, ” “wireless base station, ” or “wireless station” have the full breadth of their ordinary meaning, and at least includes a wireless communication station installed at a fixed location and used to communicate as part of a wireless telephone system or radio system. For example, if the base station is implemented in the context of LTE, it may alternately be referred to as an ‘eNodeB’ or ‘eNB’ . If the base station is implemented in the context of 5G NR, it may alternately be referred to as a ‘gNodeB’ or ‘gNB’ . Although certain aspects are described in the context of LTE or 5G NR, references to “eNB, ” “gNB, ” “nodeB, ” “base station, ” “NB, ” and the like, may refer to one or more wireless nodes that service a cell to provide a wireless connection between user devices and a wider network generally and that the concepts discussed are not limited to any particular wireless technology. Although certain aspects are described in the context of LTE or 5G NR, references to “eNB, ” “gNB, ” “nodeB, ” “base station, ” “NB, ” and the like, are not intended to limit the concepts discussed herein to any particular wireless technology and the concepts discussed may be applied in any wireless system.

[0046] Node –The term “node, ” or “wireless node” as used herein, may refer to one more apparatus associated with a cell that provide a wireless connection between user devices and a wired network generally.

[0047] Processing Element (or Processor) –refers to various elements or combinations of elements that are capable of performing a function in a device, such as a user equipment or a cellular network device. Processing elements may include, for example: processors and associated memory, portions or circuits of individual processor cores, entire processor cores, individual processors, processor arrays, circuits such as an Application Specific Integrated Circuit (ASIC) , programmable hardware elements such as a field programmable gate array (FPGA) , as well any of various combinations of the above.

[0048] Channel -a medium used to convey information from a sender (transmitter) to a receiver. It should be noted that since characteristics of the term “channel” may differ according to different wireless protocols, the term “channel” as used herein may be considered as being used in a manner that is consistent with the standard of the type of device with reference to which the term is used. In some standards, channel widths may be variable (e.g., depending on device capability, band conditions, and the like) . For example, LTE may support scalable channel bandwidths from 1.4 MHz to 20MHz. WLAN channels may be 22MHz wide while Bluetooth channels may be 1Mhz wide. Other protocols and standards may include different definitions of channels. Furthermore, some standards may define and use multiple types of channels (e.g., different channels for uplink or downlink and / or different channels for different uses such as data, control information, and the like) .

[0049] Band -The term “band” has the full breadth of its ordinary meaning, and at least includes a section of spectrum (e.g., radio frequency spectrum) in which channels are used or set aside for the same purpose.

[0050] Configured to -Various components may be described as “configured to” perform a task or tasks. In such contexts, “configured to” is a broad recitation generally meaning “having structure that” performs the task or tasks during operation. As such, the component may be configured to perform the task even when the component is not currently performing that task (e.g., a set of electrical conductors may be configured to electrically connect a module to another module, even when the two modules are not connected) . In some contexts, “configured to” may be a broad recitation of structure generally meaning “having circuitry that” performs the task or tasks during operation. As such, the component may be configured to perform the task even when the component is not currently on. In general, the circuitry that forms the structure corresponding to “configured to” may include hardware circuits.

[0051] Various components may be described as performing a task or tasks, for  convenience in the description. Such descriptions should be interpreted as including the phrase “configured to. ” Reciting a component that is configured to perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112 (f) interpretation for that component.

[0052] Example Wireless Communication System

[0053] Turning now to Figure 1, a simplified example of a wireless communication system is illustrated, according to some aspects. It is noted that the system of Figure 1 is a non-limiting example of a possible system, and that features of this disclosure may be implemented in any of various systems, as desired.

[0054] As shown, the example wireless communication system includes a base station 102A, which communicates over a transmission medium with one or more user devices 106A and 106B, through 106N. Each of the user devices may be referred to herein as a “user equipment” (UE) . Thus, the user devices 106 are referred to as UEs or UE devices.

[0055] The base station (BS) 102A may be a base transceiver station (BTS) or cell site (e.g., a “cellular base station” ) and may include hardware that enables wireless communication with the UEs 106A through 106N.

[0056] The communication area (or coverage area) of the base station may be referred to as a “cell. ” The base station 102A and the UEs 106 may be configured to communicate over the transmission medium using any of various radio access technologies (RATs) , also referred to as wireless communication technologies, or telecommunication standards, such as GSM, UMTS (associated with, for example, WCDMA or TD-SCDMA air interfaces) , LTE, LTE-A, 5G NR, HSPA, 3GPP2 CDMA2000. Note that if the base station 102A is implemented in the context of LTE, it may alternately be referred to as an ‘eNodeB’ or ‘eNB’ . Note that if the base station 102A is implemented in the context of 5G NR, it may alternately be referred to as a ‘gNodeB’ or ‘gNB’ .

[0057] In some aspects, the UEs 106 may be IoT UEs, which may comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. An IoT UE may utilize technologies such as M2M or MTC for exchanging data with an MTC server or device via a public land mobile network (PLMN) , proximity service (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An IoT network describes interconnecting IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) , with short-lived connections. As an example, vehicles to everything (V2X) may utilize ProSe features using an SL interface for direct communications between devices. The IoT UEs may also execute background applications (e.g., keep-alive messages, status updates, and the like) to facilitate the connections of the IoT network.

[0058] As shown, the UEs 106, such as UE 106A and UE 106B, may directly exchange communication data via an SL interface 108. The SL interface 108 may be a PC5 interface comprising one or more physical channels, including but not limited to a Physical Sidelink Shared Channel (PSSCH) , a Physical Sidelink Control Channel (PSCCH) , a Physical Sidelink Broadcast Channel (PSBCH) , and a Physical Sidelink Feedback Channel (PSFCH) .

[0059] In V2X scenarios, one or more of the base stations 102 may be or act as Road Side Units (RSUs) . The term RSU may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable wireless node or a stationary (or relatively stationary) UE, where an RSU implemented in or by a UE may be referred to as a “UE-type RSU, ” an RSU implemented in or by an eNB may be referred to as an “eNB-type RSU, ” an RSU implemented in or by a gNB may be referred to as a “gNB-type RSU, ” and the like. In one example, an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle  UEs (vUEs) . The RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications / software to sense and control ongoing vehicular and pedestrian traffic. The RSU may operate on the 5.9 GHz Intelligent Transport Systems (ITS) band to provide very low latency communications required for high speed events, such as crash avoidance, traffic warnings, and the like. Additionally, or alternatively, the RSU may operate on the cellular V2X band to provide the aforementioned low latency communications, as well as other cellular communications services. Additionally, or alternatively, the RSU may operate as a Wi-Fi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communications. The computing device (s) and some or all of the radio frequency circuitry of the RSU may be packaged in a weather enclosure suitable for outdoor installation, and it may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller and / or a backhaul network.

[0060] As shown, the base station 102A may also be equipped to communicate with a network 100 (e.g., a core network of a cellular service provider, a telecommunication network such as a public switched telephone network (PSTN) , and / or the Internet, among various possibilities) . Thus, the base station 102A may facilitate communication between the user devices and / or between the user devices and the network 100. In particular, the cellular base station 102A may provide UEs 106 with various telecommunication capabilities, such as voice, SMS and / or data services.

[0061] Base station 102A and other similar base stations (such as base stations 102B through 102N) operating according to the same or a different cellular communication standard may thus be provided as a network of cells, which may provide continuous or nearly continuous overlapping service to UEs 106A-106N and similar devices over a geographic area via one or more cellular communication standards.

[0062] Thus, while base station 102A may act as a “serving cell” for UEs 106A-106N as illustrated in Figure 1, each UE 106 may also be capable of receiving signals from (and possibly within communication range of) one or more other cells (which may be provided by base stations 102B-102N and / or any other base stations) , which may be referred to as “neighboring cells. ” Such cells may also be capable of facilitating communication between user devices and / or between user devices and the network 100. Such cells may include “macro” cells, “micro” cells, “pico” cells, and / or cells which provide any of various other granularities of service area size. For example, base stations 102A and 102B illustrated in Figure 1 may be macro cells, while base station 102N may be a micro cell. Other configurations are also possible.

[0063] In some aspects, base station 102A may be a next generation base station, (e.g., a 5G New Radio (5G NR) base station, or “gNB” ) . In some aspects, a gNB may be connected to a legacy evolved packet core (EPC) network and / or to a NR core (NRC)  / 5G core (5GC) network. In addition, a gNB cell may include one or more transition and reception points (TRPs) . In addition, a UE capable of operating according to 5G NR may be connected to one or more TRPs within one or more gNBs. For example, it may be possible that that the base station 102A and one or more other base stations 102 support joint transmission, such that UE 106 may be able to receive transmissions from multiple base stations (and / or multiple TRPs provided by the same base station) . For example, as illustrated in Figure 1, both base station 102A and base station 102C are shown as serving UE 106A.

[0064] Note that a UE 106 may be capable of communicating using multiple wireless communication standards. For example, the UE 106 may be configured to communicate using a wireless networking (e.g., Wi-Fi) and / or peer-to-peer wireless communication protocol (e.g., Bluetooth, Wi-Fi peer-to-peer, and the like) in addition to at least one of the cellular communication protocol discussed in the definitions above. The UE 106 may also or  alternatively be configured to communicate using one or more global navigational satellite systems (GNSS) (e.g., GPS or GLONASS) , one or more mobile television broadcasting standards (e.g., ATSC-M / H) , and / or any other wireless communication protocol, if desired. Other combinations of wireless communication standards (including more than two wireless communication standards) are also possible.

[0065] In one or more embodiments, the UE 106 may be a device with cellular communication capability such as a mobile phone, a hand-held device, a computer, a laptop, a tablet, a smart watch, or other wearable device, or virtually any type of wireless device.

[0066] The UE 106 may include a processor (processing element) that is configured to execute program instructions stored in memory. The UE 106 may perform any of the method aspects described herein by executing such stored instructions. Alternatively, or in addition, the UE 106 may include a programmable hardware element such as an FPGA (field-programmable gate array) , an integrated circuit, and / or any of various other possible hardware components that are configured to perform (e.g., individually or in combination) any of the method aspects described herein, or any portion of any of the method aspects described herein.

[0067] The UE 106 may include one or more antennas for communicating using one or more wireless communication protocols or technologies. In some aspects, the UE 106 may be configured to communicate using, for example, NR or LTE using at least some shared radio components. As additional possibilities, the UE 106 could be configured to communicate using CDMA2000 (1xRTT  / 1xEV-DO  / HRPD  / eHRPD) or LTE using a single shared radio and / or GSM or LTE using the single shared radio. The shared radio may couple to a single antenna, or may couple to multiple antennas (e.g., for a multiple-input multiple output (MIMO) configuration) for performing wireless communications. In general, a radio may include any combination of a baseband processor, analog RF signal processing circuitry (e.g., including filters, mixers, oscillators, amplifiers, and the like) , or digital processing circuitry (e.g., for  digital modulation as well as other digital processing) . Similarly, the radio may implement one or more receive and transmit chains using the aforementioned hardware. For example, the UE 106 may share one or more parts of a receive and / or transmit chain between multiple wireless communication technologies, such as those discussed above.

[0068] In some aspects, the UE 106 may include separate transmit and / or receive chains (e.g., including separate antennas and other radio components) for each wireless communication protocol with which it is configured to communicate. As a further possibility, the UE 106 may include one or more radios which are shared between multiple wireless communication protocols, and one or more radios which are used exclusively by a single wireless communication protocol. For example, the UE 106 might include a shared radio for communicating using either of LTE or 5G NR (or either of LTE or 1xRTT, or either of LTE or GSM, among various possibilities) , and separate radios for communicating using each of Wi-Fi and Bluetooth. Other configurations are also possible.

[0069] In some aspects, a downlink resource grid may be used for downlink transmissions from any of the base stations 102 to the UEs 106, while uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Such a time-frequency plane representation is a common practice for Orthogonal Frequency Division Multiplexing (OFDM) systems, which makes it intuitive for radio resource selection. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element. Each resource grid may comprise a number of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements. There are several different physical downlink  channels that are conveyed using such resource blocks.

[0070] The physical downlink shared channel (PDSCH) may carry user data and higher layer signaling to the UEs 106. The physical downlink control channel (PDCCH) may carry information about the transport format and resource allocations related to the PDSCH channel, among other things. It may also inform the UEs 106 about the transport format, resource allocation, and HARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (assigning control and shared channel resource blocks to the UE 102 within a cell) may be performed at any of the base stations 102 based on channel quality information fed back from any of the UEs 106. The downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the UEs.

[0071] The PDCCH may use control channel elements (CCEs) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols may first be organized into quadruplets, which may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements known as resource element groups (REGs) . Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH may be transmitted using one or more CCEs, depending on the size of the Downlink Control Information (DCI) and the channel condition. There may be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation level, L=1, 2, 4, or 8) .

[0072] As illustrated in Figure 2, the base stations 102 may comprise a traditional terrestrial base station 200, a non-terrestrial base station, such as satellite 202, or a combination thereof. For example, in a first, so-called “transparent” or “bent-pipe” mode, the gNB is on the ground (e.g., 200) , and the orbiting satellite (e.g., 202) merely acts as a signal repeater (i.e., the gNB  does all processing, and the satellite just relays / reflects the processed signals to other places on the Earth) . Alternately, in a so-called “non-transparent” or “regenerative” mode, the gNB may be located on the satellite (e.g., 202) and the gateway (e.g., 200) is located on the ground. In non-transparent modes, all the scheduling and signaling occurs onboard the satellite, which may result in faster scheduling decisions and shorter round-trip time (RTT) , but is a much more power-hungry design.

[0073] Example Communication Device

[0074] Figure 3 illustrates an example simplified block diagram of a communication device 106, according to some aspects. It is noted that the block diagram of the communication device of Figure 3 is only one example of a possible communication device. According to aspects, communication device 106 may be a UE device or terminal, a mobile device or mobile station, a wireless device or wireless station, a desktop computer or computing device, a mobile computing device (e.g., a laptop, notebook, or portable computing device) , a tablet, and / or a combination of devices, among other devices. As shown, the communication device 106 may include a set of components configured to perform core functions. For example, this set of components may be implemented as a system on chip (SOC) , which may include portions for various purposes. Alternatively, this set of components may be implemented as separate components or groups of components for the various purposes. The set of components may be coupled (e.g., communicatively; directly or indirectly) to various other circuits of the communication device 106.

[0075] For example, the communication device 106 may include various types of memory (e.g., including NAND flash 310) , an input / output interface such as connector I / F 320 (e.g., for connecting to a computer system; dock; charging station; input devices, such as a microphone, camera, keyboard; output devices, such as speakers; and the like) , the display 360, which may be integrated with or external to the communication device 106, and wireless communication  circuitry 330 (e.g., for LTE, LTE-A, NR, UMTS, GSM, CDMA2000, Bluetooth, Wi-Fi, NFC, GPS, and the like) . In some aspects, communication device 106 may include wired communication circuitry (not shown) , such as a network interface card (e.g., for Ethernet connection) .

[0076] The wireless communication circuitry 330 may couple (e.g., communicatively; directly or indirectly) to one or more antennas, such as antenna (s) 335 (each of which may include an antenna panel) , as shown. The wireless communication circuitry 230 may include cellular communication circuitry and / or short to medium range wireless communication circuitry, and may include multiple receive chains and / or multiple transmit chains for receiving and / or transmitting multiple spatial streams, such as in a MIMO configuration.

[0077] In some aspects, as further described below, cellular communication circuitry 330 may include one or more receive chains (including and / or coupled to (e.g., communicatively; directly or indirectly) dedicated processors and / or radios) for multiple Radio Access Technologies (RATs) (e.g., a first receive chain for LTE and a second receive chain for 5G NR) . In addition, in some aspects, cellular communication circuitry 330 may include a single transmit chain that may be switched between radios dedicated to specific RATs. For example, a first radio may be dedicated to a first RAT (e.g., LTE) and may be in communication with a dedicated receive chain and a transmit chain shared with a second radio. The second radio may be dedicated to a second RAT (e.g., 5G NR) and may be in communication with a dedicated receive chain and the shared transmit chain. In some aspects, the second RAT may operate at mmWave frequencies. As mmWave systems operate in higher frequencies than typically found in LTE systems, signals in the mmWave frequency range are heavily attenuated by environmental factors. To help address this attenuating, mmWave systems often utilize beamforming and include more antennas as compared LTE systems. These antennas may be organized into antenna arrays or panels made up of individual antenna elements. These antenna  arrays may be coupled to the radio chains.

[0078] The communication device 106 may also include and / or be configured for use with one or more user interface elements.

[0079] The communication device 106 may further include one or more smart cards 345 that include Subscriber Identity Module (SIM) functionality, such as one or more Universal Integrated Circuit Card (s) (UICC (s) ) cards 345.

[0080] As shown, the SOC 300 may include processor (s) 302, which may execute program instructions for the communication device 106 and display circuitry 304, which may perform graphics processing and provide display signals to the display 360. The processor (s) 302 may also be coupled to memory management unit (MMU) 340, which may be configured to receive addresses from the processor (s) 302 and translate those addresses to locations in memory (e.g., memory 306, read only memory (ROM) 350, NAND flash memory 310) and / or to other circuits or devices, such as the display circuitry 304, wireless communication circuitry 330, connector I / F 320, and / or display 360. The MMU 340 may be configured to perform memory protection and page table translation or set up. In some aspects, the MMU 340 may be included as a portion of the processor (s) 302.

[0081] As noted above, the communication device 106 may be configured to communicate using wireless and / or wired communication circuitry. As described herein, the communication device 106 may include hardware and software components for implementing any of the various features and techniques described herein. The processor 302 of the communication device 106 may be configured to implement part or all of the features described herein (e.g., by executing program instructions stored on a memory medium) . Alternatively (or in addition) , processor 302 may be configured as a programmable hardware element, such as a Field Programmable Gate Array (FPGA) , or as an Application Specific Integrated Circuit (ASIC) .  Alternatively (or in addition) the processor 302 of the communication device 106, in conjunction with one or more of the other components 300, 304, 306, 310, 320, 330, 340, 345, 350, 360 may be configured to implement part or all of the features described herein.

[0082] In addition, as described herein, processor 302 may include one or more processing elements. Thus, processor 302 may include one or more integrated circuits (ICs) that are configured to perform the functions of processor 302. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and the like) configured to perform the functions of processor (s) 302.

[0083] Further, as described herein, wireless communication circuitry 330 may include one or more processing elements. In other words, one or more processing elements may be included in wireless communication circuitry 330. Thus, wireless communication circuitry 330 may include one or more integrated circuits (ICs) that are configured to perform the functions of wireless communication circuitry 330. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and the like) configured to perform the functions of wireless communication circuitry 330.

[0084] Example Base Station

[0085] Figure 4 illustrates an example block diagram of a base station 102, according to some aspects. It is noted that the base station of Figure 4 is a non-limiting example of a possible base station. As shown, the base station 102 may include processor (s) 304 which may execute program instructions for the base station 102. The processor (s) 404 may also be coupled to memory management unit (MMU) 440, which may be configured to receive addresses from the processor (s) 404 and translate those addresses to locations in memory (e.g., memory 460 and read only memory (ROM) 450) or to other circuits or devices.

[0086] The base station 102 may include at least one network port 470. The network port  470 may be configured to couple to a telephone network and provide a plurality of devices, such as UE devices 106, access to the telephone network as described above in Figure 1.

[0087] The network port 470 (or an additional network port) may also or alternatively be configured to couple to a cellular network, e.g., a core network of a cellular service provider. The core network may provide mobility related services and / or other services to a plurality of devices, such as UE devices 106. In some cases, the network port 470 may couple to a telephone network via the core network, and / or the core network may provide a telephone network (e.g., among other UE devices serviced by the cellular service provider) .

[0088] In some aspects, base station 102 may be a next generation base station, (e.g., a 5G New Radio (5G NR) base station, or “gNB” ) . In such aspects, base station 102 may be connected to a legacy evolved packet core (EPC) network and / or to a NR core (NRC)  / 5G core (5GC) network. In addition, base station 102 may be considered a 5G NR cell and may include one or more transition and reception points (TRPs) . In addition, a UE capable of operating according to 5G NR may be connected to one or more TRPs within one or more gNBs.

[0089] The base station 102 may include at least one antenna 434, and possibly multiple antennas or antenna panels. The at least one antenna 434 may be configured to operate as a wireless transceiver and may be further configured to communicate with UE devices 106 via radio 430. The antenna 434 communicates with the radio 430 via communication chain 432. Communication chain 432 may be a receive chain, a transmit chain or both. The radio 430 may be configured to communicate via various wireless communication standards, including 5G NR, LTE, LTE-A, GSM, UMTS, CDMA2000, Wi-Fi, and the like.

[0090] The base station 102 may be configured to communicate wirelessly using multiple wireless communication standards. In some instances, the base station 102 may include multiple radios, which may enable the base station 102 to communicate according to multiple  wireless communication technologies. For example, as one possibility, the base station 102 may include an LTE radio for performing communication according to LTE as well as a 5G NR radio for performing communication according to 5G NR. In such a case, the base station 102 may be capable of operating as both an LTE base station and a 5G NR base station. When the base station 102 supports mmWave, the 5G NR radio may be coupled to one or more mmWave antenna arrays or panels. As another possibility, the base station 102 may include a multi-mode radio, which is capable of performing communications according to any of multiple wireless communication technologies (e.g., 5G NR and LTE, 5G NR and Wi-Fi, LTE and Wi-Fi, LTE and UMTS, LTE and CDMA2000, UMTS and GSM, and the like) .

[0091] Further, the BS 102 may include hardware and software components for implementing or supporting implementation of features described herein. The processor 404 of the base station 102 may be configured to implement or support implementation of part or all of the methods described herein (e.g., by executing program instructions stored on a memory medium) . Alternatively, the processor 404 may be configured as a programmable hardware element, such as a Field Programmable Gate Array (FPGA) , or as an Application Specific Integrated Circuit (ASIC) , or a combination thereof. Alternatively (or in addition) the processor 404 of the BS 102, in conjunction with one or more of the other components 430, 432, 434, 440, 450, 460, 470 may be configured to implement or support implementation of part or all of the features described herein.

[0092] In addition, as described herein, processor (s) 404 may include one or more processing elements. Thus, processor (s) 404 may include one or more integrated circuits (ICs) that are configured to perform the functions of processor (s) 404. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and the like) configured to perform the functions of processor (s) 404.

[0093] Further, as described herein, radio 430 may include one or more processing  elements. Thus, radio 430 may include one or more integrated circuits (ICs) that are configured to perform the functions of radio 430. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and the like) configured to perform the functions of radio 430.

[0094] Non-Terrestrial Networks (NTNs) and Uplink Coverage Limitations

[0095] As mentioned above, “non-terrestrial, ” e.g., satellite-based, telecommunication has drawn great research interest in recent years, due to its ability provide reliable coverage-even in difficult-to-service places on Earth. In fact, 3GPP has been standardizing NTN support since Release-17. One of the challenges for satellite communications is the uplink capacity / throughput for NTN, especially for satellites that may be serving large coverage regions-and thus many UEs-e.g., IoT UEs that are within the coverage region of a given satellite. Release-18 also focused on specific coverage enhancements for NR-based NTN, with a particular focus on the uplink channels, e.g., using HARQ ACK for Message 4 (Msg4) in the PUCCH and / or performing demodulation reference signal (DM-RS) bundling in the PUSCH.

[0096] However, additional NR-based NTN coverage enhancements are still desired to improve uplink capacity and throughput, and specifically with regard to mobile-originated (MO) early data transmission (EDT) and preconfigured uplink resource (PUR) transmissions, e.g., the use of RRC early data request / complete delivery, Msg3 contention-based operation without PRACH and RAR, and / or the use of orthogonal cover codes (OCCs) .

[0097] Multiplexing for EDT in IoT NTN Transmissions

[0098] According to some aspects, the uplink budget for IoT NTN transmissions may be enhanced by multiplexing uplink transmissions via the usage of orthogonal cover codes (OCCs) , e.g., Wash codes, Gold codes, DFT-generated sequences, etc.. For example, according to some embodiments, a process of OCC sequence indication for EDT may first  involve an OCC sequence configuration process. In some implementations, a predetermined number of OCC sequences may be configured (e.g., 4, 16, 64, etc. ) . This configuration may be signaled to the UE, e.g., via a System Information Block (e.g., SIB 1, SIB 31, or a new SIB) .

[0099] According to some implementations, among a set of preambles configured to indicate EDT transmissions, the network may further configure a subset of PRACH preambles to indicate UE’s OCC capability for EDT. For instance, if PRACH preamble sequences 1–20 are configured for the UE’s indication of EDT transmissions, then a first subset of the preamble sequences (e.g., sequences 1–10) may be used for the UE’s indication of EDT transmissions with OCC capability, while a second subset of the preamble sequences (e.g., sequences 11–20) may be used for the UE’s indication of EDT transmissions without OCC capability. It is to be understood that this type of OCC sequence configuration and preamble configuration scheme is merely illustrative.

[0100] Next, the UE may select a PRACH preamble at random from among the subset of configured preambles for reporting its capability of OCC in EDT.

[0101] Next, the UE may determine which OCC sequence to use for the Msg3 message. For example, in one embodiment, the OCC sequence for the UE to use may be explicitly indicated in the RAR, e.g., a field of the UL grant. In one embodiment, for CE mode A, the network may reuse part (or all) of the “zero padding” bits in the RAR (either the most-significant bits or the least-significant bits) to indicate the OCC sequence index that the UE is to use. For example, for a 5 MHz bandwidth, the number of “zero padding” bits available is 2, meaning that up to 2^2, or 4, OCC sequences are allowed. In another embodiment, for CE mode B, the network may simply increase the total number of bits in the RAR grant, e.g., from 12 bits to 12 + log2 (numberOfConfiguredOCCSequences) bits.

[0102] In an alternative embodiment, rather than the OCC sequence being explicitly  indicated in the RAR, it may be indicated in a MAC RAR. For example, a new field for “OCC Sequence Index” may be added to an enhanced MAC RAR, e.g., after Oct 6 in the MAC RAR shown in TS 36.321, Figure 6.1.5-3.

[0103] In yet another alternative embodiment, rather than being explicitly indicated, the OCC sequence that is to be used by the UE may be implicitly derived from the Temporary Cell Radio Network Temporary Identifier (TC-RNTI) and / or preamble that is selected. For example, in one alternative, the OCC sequence index may be a function of the preamble ID (e.g., the OCC sequence index may be equal to (preamble ID) mod (configured OCC size) ) . In another alternative, the OCC sequence index may be a function of the TC-RNTI in the RAR grant (e.g., the OCC sequence index may be equal to (TC-RNTI) mod (configured OCC size) ) . In yet another alternative, the OCC sequence index may be a function of the UE Temporary Mobile Subscriber Identity (TMSI) (e.g., the OCC sequence index may be equal to (TMSI) mod (configured OCC size) ) . In still another alternative, the OCC sequence index may be a function of any combination of preamble ID, TC-RNTI, and / or TMSI. This combination may be configured and indicated via SIB, e.g., a SIB may indicate that the OCC sequence index is derived from the Random Access Preamble Identifier (RAPID) and TC-RNTI.

[0104] Turning now to Figure 6, a flowchart detailing a method 600 of orthogonal cover code (OCC) indication for early data transmission (EDT) in user equipment (UE) is illustrated, according to some aspects. First, at step 602 a UE practicing the method 600 may receive, from a network, a first OCC configuration. For example, the first OCC configuration may comprise an indication of a particular number and / or type of OCC sequences to be used by the UE.

[0105] Next, at step 604, the UE may select a Physical Random Access Channel (PRACH) preamble from among a first plurality of configured early data transmission (EDT) PRACH preambles (e.g., a first subset of EDT PRACH preambles configured for use with OCC and a  second subset of EDT PRACH preambles configured for use without OCC) .

[0106] Next, at step 606, the UE may receive, from the network, a Random Access Response (RAR) message (Msg2) comprising uplink (UL) grant information. At step 608, the UE may determine an OCC sequence to utilize for a Radio Resource Control (RRC) connection request message (Msg3) . In some embodiments, the UE may determine the OCC sequence to utilize via explicit signaling form the network, e.g., via the RAR. For example, the network may use the zero-padding bits (or extra bits) in the RAR to indicate the OCC sequence the UE should utilize for Msg3 uplink transmissions. In other embodiments, the UE may implicitly determine the OCC sequence to utilize, e.g., based on one or more of: RAPID, TC-RNTI, or TMSI.

[0107] Finally, at step 610, the UE may transmit the Msg3 message to the network using the determined OCC sequence and UL grant information.

[0108] Time Alignment Validation in NTN PUR

[0109] In legacy preconfigured uplink resource (PUR) transmissions for IoT, the timing alignment validation for transmission using PUR included confirmation that: 1) the pur-TimeAlignmentTimer, defined as a multiple of PUR periodicity, is running (or valid) ; and 2) the serving cell RSRP measurement is not between [decreaseThresh, increaseThresh] of the stored serving cell RSRP value (wherein pur-RSRP-changeThreshold configures the values of [decreaseThresh, increaseThresh] ) .

[0110] In NTN PUR, additional criteria may be needed for the performance of timing alignment validation for transmissions using PUR. For example, the UE may need to confirm that: 1) the UE’s Global Navigation Satellite System (GNSS) validity duration has not passed; and / or 2) the satellite ephemeris data and common timing alignment (TA) for a serving satellite of the UE are valid (e.g., by confirming that the difference between a current time and  epochTime is smaller than or equal to ul-SyncValidityDuration) . In some embodiments, the consideration of change in measured RSRP between PUR occasions may not be applied if a different satellite is serving the area with the same Physical Cell ID (PCI) . According to some embodiments, power control for transmissions using PUR may also depend on the measurement of RSRP.

[0111] In NTN PUR, a stored serving cell RSRP value may be adjusted, based on various factors, e.g., the distance between the UE and the serving satellite and / or the elevation angle of the serving satellite. In the case of adjustment based on the distance between the UE and the serving satellite, say that the stored serving cell RSRP value is RSRPstored = -100 dBm at UE-satellite distance of dref = 2000 km. Then, if, in the next RSRP measurement, the distance between UE-satellite distance is dmeasure = 2500 km, then the stored serving cell RSRP value may be appropriately adjusted based on the distance change from 2000 km to 2500 km. For example, in one implementation, the adjusted RSRP value may be determined as RSRPadj = RSRPstored -10*log10 ( (dmeasure / dref) ^2) . In the case of adjustment based on the elevation angle changing between the UE and the serving satellite, the stored serving cell RSRP value may be associated with a particular UE elevation angle.

[0112] In legacy PUR, a UE is allowed to skip transmitting a defined number, pur-ImplicitReleaseAfter, PUR occasions in a row, after which the PUR configuration is implicitly released. However, in NTN PUR, the serving satellite may not always cover the area of the UE for quasi-earth fixed cell. (Note: “serviceInfo” in SIB32 for discontinuous coverage provides the coverage timing of the NTN cell. ) Thus, in the case of skipped PUR occasions in discontinuous satellite coverage, there remains an open question of how to best count the skipped PUR transmissions. In one embodiment, if no satellite is serving the UE’s area for a given PUR occasion, then the skipped PUR occasion is not counted in association with pur-ImplicitReleaseAfter. In another embodiment, the skipped PUR occasions may always be  counted in association with pur-ImplicitReleaseAfter, i.e., no matter whether the skipped occasion is due to a lack of satellite coverage or a lack of UL data to transmit. In yet another embodiment, a new parameter, e.g., referred to here as pur-ImplicitReleaseAfter2 may also be configured in PUR-config, i.e., to indicate the continuous number of PUR transmission occasions skipped in NTN, no matter whether the skipped occasion is due to no satellite coverage or a lack of UL data to transmit. In such an embodiment, the legacy pur-ImplicitReleaseAfter could advantageously still be used for the scenario of counting skipped PUR occasions when the UE is within satellite coverage.

[0113] Turning back now to Figure 5, various of the time alignment (TA) validation principles in NTN PUR described above are illustrated, according to some aspects. First, diagram 500 shows examples of various relevant aspects of NTN PUR. For example, a PUR time alignment timer 504 is shown along a time axis 502 with PUR occasions PUR1 (5081) , PUR2 (5082) , and PUR3 (5083) , having PUR periodicity 506. As mentioned above, according to some embodiments, additional criteria may be needed for the performance of timing alignment validation for transmissions using PUR. For example, the UE may need to confirm that: 1) the UE’s Global Navigation Satellite System (GNSS) validity duration 510 has not passed; and / or 2) the validation duration 512 for the satellite ephemeris data and common timing alignment (TA) for the serving satellite have not passed.

[0114] Next, diagram 520 shows an exemplary UE 5241 at a first time (T = T1) that is being served by a serving satellite shown at 5221. At this first time, the UE 5241 may store a first RSRP value 5261. Later, at a second time (T = T2) , the exemplary UE is shown at updated position 5242, and the serving satellite shown at updated position 5222. As may be seen, the elevation angle (and also the overall distance) between the UE 524 and serving satellite 522 have changed between the first time and the second time. Thus, and adjusted RSRP value 5262 may be computed for the UE at the second time, e.g., according to one or more of the various  techniques described above. According to some embodiments, based on a comparison of an RSRP value actually measured at the second time and the aforementioned adjusted RSRP value 5262 (e.g., a computed difference between the two values) , the UE 526 may determine whether or not to use its configured PUR resource at the second time.

[0115] Next, diagram 540 shows the same timeline 502 from diagram 500 with PUR occasions PUR1 (5081) , PUR2 (5082) , and PUR3 (5083) . In the example of diagram 540, it is further illustrated that a serving satellite is present during PUR occasions PUR1 (5081) and PUR3 (5083) (as shown at 5421 and 5423, respectively) , but that the serving satellite is not present during PUR occasion PUR2 (5082) . Thus, according to some embodiments, two separate counters (e.g., labeled as Counter_1 and Counter_2 in Figure 5) may be used to track the skipped PUR occasions (and the reasons therefore) . As shown at 5441, if there is no PUSCH transmission at PUR occasion PUR1 (5081) due to there being no UL data to transmit, then Counter_1 and Counter_2 may be incremented. Next, as shown at 5442, if there is no PUSCH transmission at PUR occasion PUR2 (5082) due to there being no satellite coverage, then Counter_2 may be incremented, but Counter_1 may not be incremented (i.e., Counter_2 does not take into account whether the reason for the skip was due to a lack of satellite coverage; it simply counts all skipped occasions as skips) . Finally, as shown at 5443, if there is no PUSCH transmission at PUR occasion PUR3 (5083) again, i.e., due to there being no UL data to transmit, then Counter_1 and Counter_2 may again both be incremented. As may now be appreciated, Counter_1 and Counter_2 may eventually have different skip values after a number of PUR occasions, depending on the reasons for the lack of PUSCH transmission. Depending on the desires of a given implementation, either Counter_1 or Counter_2 may be configured with threshold values, after which the PUR configuration may be released when the desired counter reaches its threshold value.

[0116] Turning next to Figure 7, a flowchart detailing a method 700 of time alignment  validation for preconfigured uplink resource (PUR) transmissions in UE is shown, according to some aspects. First, at step 702, a UE practicing the method 700 may receive, from a first Non-Terrestrial Network (NTN) , a first preconfigured uplink resource (PUR) configuration, wherein the first PUR configuration indicates a Reference Signal Received Power (RSRP) measurement change threshold.

[0117] Next, at step 704, the UE may determine, at a first time, a first serving satellite RSRP value and a first UE-satellite parameter (e.g., a UE-satellite distance) associated with the first serving satellite RSRP value.

[0118] Next, at step 706, the UE may determine, at a second time, a second UE-satellite parameter (e.g., a UE-satellite distance, a UE-satellite elevation angle, etc. ) . Then, at step 708, the UE may estimate, based on the first UE-satellite parameter, the determined second UE-satellite parameter, and the first serving satellite RSRP value: an “adjusted” first serving satellite RSRP value. According to some embodiments, this adjusted first serving satellite RSRP value may be adjusted to reflect an estimated change in the distance and / or elevation angle of the serving satellite with respect to the UE between the first time and the second time.

[0119] Next, at step 710, the UE may determine, at the second time, a second serving satellite RSRP value. At step 712, the UE may then determine, based, at least in part, on: the adjusted first serving satellite RSRP value; the second serving satellite RSRP value; and the RSRP measurement change threshold to transmit on a next PUR occasion (i.e., rather than skipping the next PUR occasion) . For example, according to some embodiments, if the difference between the adjusted first serving satellite RSRP value and the second serving satellite RSRP value is less than the RSRP measurement change threshold, the UE may transmit on the next PUR occasion. On the other hand, if the difference between the adjusted first serving satellite RSRP value and the second serving satellite RSRP value is greater than the RSRP measurement change threshold, the UE may skip the next PUR occasion.

[0120] As described above with reference to Figure 5 example 540 and shown at optional step 714, according to some embodiments, when no satellite is serving the UE for a given PUR occasion, the given PUR occasion is not counted towards a threshold of consecutive skipped PUR occasions after which the first PUR configuration is released. According to other embodiments, and as shown at optional step 716, skipped PUR occasions count towards a threshold of consecutive skipped PUR occasions after which the first PUR configuration is released, whether a skipped PUR occasion is due to a lack of serving satellite or a lack of data for transmission.

[0121] According to still other embodiments, a number of contiguously skipped PUR occasions may be tracked (i.e., whether the contiguously skipped PUR occasions are due to a lack of serving satellite or a lack of data for transmission) , and, then, the first PUR configuration may be released once the number of contiguously-skipped PUR occasions reaches a corresponding threshold value (e.g., 2 or 4 or 8 contiguous skipped PUR occasions, etc. ) .

[0122] OCC Indication in NTN PUR

[0123] According to some embodiments, a UE indicates its capability for handling orthogonal cover codes (OCCs) in a PURConfigurationRequest. For example, the PURConfigurationRequest information element (IE) may contain a new parameter called “OCC capability” (or the like) . Assuming the UE is configured to support OCC for PUSCH transmission in PUR, the PUR-config IE may contain a new parameter of “OCC sequence index value. ”

[0124] This new parameter may provide an indication of the OCC for the UE to use for PUSCH retransmission for PUR. For example, in some embodiments, the same OCC sequence that is used in PUSCH transmission in PUR may be applied for PUSCH retransmissions (which  value may have been configured in the PUR-config IE) . In other embodiments, a new OCC sequence may be explicitly indicated for PUSCH retransmissions (e.g., via a new “OCC sequence index” filed in DCI Format 6-0A or Format 6-0B) . In still other embodiments, no OCC may be used for PUSCH retransmissions. It is to be understood that the above alternatives may be supported with the choice of alternative configured by SIB or PUR-config.

[0125] Turning now to Figure 8, a flowchart detailing a method 800 of OCC indication for PUR transmissions in UEs is shown, according to some aspects. First, at step 802, a UE practicing the method 800 may transmit, to a first Non-Terrestrial Network (NTN) , in a first preconfigured uplink resource (PUR) configuration request, a first orthogonal cover code (OCC) capability.

[0126] Next, at step 804, the UE may receive, from the first NTN, a first PUR configuration, wherein the first PUR configuration indicates a first OCC sequence (e.g., a first OCC sequence index) . For example, in one implementation, for an OCC set with a size of 4: OCC sequence index #1 = [1 1 1 1] ; OCC sequence index #2 = [1 1 -1 -1] ; OCC sequence index #3 = [1 -1 1 -1] ; and OCC sequence index #4 = [1 -1 -1 1] .

[0127] Next, at Step 806, the UE may apply the indicated first OCC sequence to Physical Uplink Shared Channel (PUSCH) transmissions in PUR. At Step 808, the UE may receive, from the first NTN, uplink (UL) grant information for PUSCH retransmissions, wherein the UL grant information comprises an indication of a second OCC sequence (wherein, e.g., the first and second OCC sequences may be the same or may be different) .

[0128] At step 810, the UE may then transmit PUSCH retransmissions to the first NTN using the second OCC sequence and UL grant information.

[0129] Additional Comments

[0130] The use of the connective term “and / or” is meant to represent all possible  alternatives of the conjunction “and” and the conjunction “or. ” For example, the sentence “configuration of A and / or B” includes the meaning and of sentences “configuration of A and B” and “configuration of A or B. ”

[0131] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0132] Aspects of the present disclosure may be realized in any of various forms. For example, some aspects may be realized as a computer-implemented method, a computer-readable memory medium, or a computer system. Other aspects may be realized using one or more custom-designed hardware devices such as ASICs. Still other aspects may be realized using one or more programmable hardware elements such as FPGAs.

[0133] In some aspects, a non-transitory computer-readable memory medium may be configured so that it stores program instructions and / or data, where the program instructions, if executed by a computer system, cause the computer system to perform a method (e.g., any of a method aspects described herein, or, any combination of the method aspects described herein, or any subset of any of the method aspects described herein, or any combination of such subsets) .

[0134] In some aspects, a device (e.g., a UE 106, a BS 102) may be configured to include a processor (or a set of processors) and a memory medium, where the memory medium stores program instructions, where the processor is configured to read and execute the program instructions from the memory medium, where the program instructions are executable to  implement any of the various method aspects described herein (or, any combination of the method aspects described herein, or, any subset of any of the method aspects described herein, or, any combination of such subsets) . The device may be realized in any of various forms.

[0135] Although the aspects above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1.A method of orthogonal cover code (OCC) indication for early data transmission (EDT) in user equipment (UE) , the method comprising:receiving, from a network, a first OCC configuration;selecting a Physical Random Access Channel (PRACH) preamble from among a first plurality of configured EDT PRACH preambles;receiving, from the network, a Random Access Response (RAR) message (Msg2) comprising uplink (UL) grant information;determining an OCC sequence to utilize for a Radio Resource Control (RRC) connection request message (Msg3) ; andtransmitting the Msg3 message to the network using the determined OCC sequence and UL grant information.2.The method of claim 1, wherein the first OCC configuration comprises a predetermined maximum number of OCC sequences.3.The method of claim 1, wherein the first OCC configuration is received in a System Information Block (SIB) .4.The method of claim 1, wherein the first plurality of configured EDT PRACH preambles further comprises: a first subset of EDT PRACH preambles configured for use with OCC; and a second subset of EDT PRACH preambles configured for use without OCC.5.The method of claim 4, wherein the selected PRACH preamble is from the first subset of EDT PRACH preambles.6.The method of claim 1, wherein the determination of the OCC sequence is based, at least in part, on information received in the RAR message.7.The method of claim 6, wherein the determination of the OCC sequence is further based, at least in part, on information received in zero padding bits of the RAR message.8.The method of claim 1, wherein the determination of the OCC sequence is based, at least in part, on information received in a Medium Access Control (MAC) RAR message.9.The method of claim 1, wherein the determination of the OCC sequence is derived implicitly based on at least one of: the selected PRACH preamble; a Temporary Cell Radio Network Temporary Identifier (TC-RNTI) received in the RAR message; a UE Temporary Mobile Subscriber Identity (TMSI) ; or an indication received in a System Information Block (SIB) .10.The method of claim 1, wherein the UE comprises an Internet of Things (IoT) device.11.The method of claim 1, wherein the network comprises a Non-Terrestrial Network (NTN) .12.A method of time alignment validation for preconfigured uplink resource (PUR) transmissions in user equipment (UE) , the method comprising:receiving, from a first Non-Terrestrial Network (NTN) , a first PUR configuration, wherein the first PUR configuration indicates a Reference Signal Received Power (RSRP) measurement change threshold;determining, at a first time, a first serving satellite RSRP value and a first UE-satellite parameter associated with the first serving satellite RSRP value;determining, at a second time, a second UE-satellite parameter;estimating, based on: the first UE-satellite parameter, the determined second UE-satellite parameter, and the first serving satellite RSRP value: an adjusted first serving satellite RSRP value;determining, at the second time, a second serving satellite RSRP value; anddetermining, based, at least in part, on: the adjusted first serving satellite RSRP value; the second serving satellite RSRP value; and the RSRP measurement change threshold to transmit on a next PUR occasion.13.The method of claim 12, wherein, when no satellite is serving the UE for a given PUR occasion, the given PUR occasion is not counted towards a threshold of consecutive skipped PUR occasions after which the first PUR configuration is released.14.The method of claim 12, wherein skipped PUR occasions count towards a threshold of consecutive skipped PUR occasions after which the first PUR configuration is released, whether a skipped PUR occasion is due to a lack of serving satellite or a lack of data for transmission.15.The method of claim 12, wherein a number of contiguously skipped PUR occasions is tracked, whether the contiguously skipped PUR occasions are due to a lack of serving satellite or a lack of data for transmission.16.The method of claim 15, wherein the first PUR configuration is released when the number of contiguously skipped PUR occasions reaches a threshold value.17.The method of claim 12, wherein the second UE-satellite parameter comprises at least one of: an estimated second UE-satellite distance at the second time; or an estimated UE-satellite elevation angle at the second time.18.The method of claim 12, wherein the determination to transmit on a next PUR occasion further comprises determining that at least one of the following conditions are met:a Global Navigation Satellite System (GNSS) validity duration of the UE has not passed;satellite ephemeris data for a serving satellite of the UE are valid; ora common timing alignment (TA) for a serving satellite and the UE are valid.19.A method of orthogonal cover code (OCC) indication for preconfigured uplink resource (PUR) transmissions in user equipment (UE) , the method comprising:transmitting, to a first Non-Terrestrial Network (NTN) , in a first PUR configuration request, a first OCC capability;receiving, from the first NTN, a first PUR configuration, wherein the first PUR configuration indicates a first OCC sequence;applying the indicated first OCC sequence to Physical Uplink Shared Channel (PUSCH) transmissions in PUR;receiving, from the first NTN, uplink (UL) grant information for PUSCH retransmissions, wherein the UL grant information comprises an indication of a second OCC sequence; andtransmitting PUSCH retransmissions to the first NTN using the second OCC sequence and UL grant information.20.The method of claim 19, wherein the first OCC sequence and the second OCC sequence are the same.21.The method of claim 19, wherein the first OCC sequence and the second OCC sequence are different.22.The method of claim 21, wherein the second OCC sequence is indicated via a DCI Format 6-0A or a DCI Format 6-0B.23.The method of claim 19, wherein the indication of the first OCC sequence comprises an indication of an OCC sequence index.24.A user device comprising: a receiver; a transmitter; and a processor configured to perform any of the methods of claims 1–23.25.A baseband processor configured to cause a user equipment (UE) device to perform any of the methods of claims 1–23.

Images