Prach with orthogonal cover codes

Abstract

This disclosure relates to techniques for performing orthogonal cover code (OCC) random-access channel (RACH) procedures in a wireless communication system. A wireless device can transmit, to a network, a RACH preamble that includes an OCC index and receive, from the network, a random-access response (RAR) message. The RAR message can include an indication of the OCC index and an uplink grant. The indication of the OCC index can be indicated via a random-access preamble identifier (RAPID) medium access control (MAC) sub-header and / or a MAC RAR control element. The RAPID can be calculated for a frequency identifier (f_id) as a product of the f_id and a number of OCC indexes plus the OCC index and / or as a product of a number of subcarriers and the OCC index plus the f_id. The wireless device can transmit, to the network, on a physical uplink shared channel (PUSCH) associated with the uplink grant.

Description

PRACH WITH ORTHOGONAL COVER CODESFIELD

[0001] The present application relates to wireless communications, and more particularly to systems, apparatuses, and methods for performing narrowband physical random-access channel (NPRACH) procedures with orthogonal cover codes (OCCs) in a wireless communication system, e.g., such as in an Internet of Things (IoT) non-terrestrial network (NTN) .DESCRIPTION OF THE RELATED ART

[0002] Wireless communication systems are ubiquitous. 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 (i.e., user equipment devices or UEs) 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) , LTE, LTE Advanced (LTE-A) , NR, 6G, HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD) , IEEE 802.11 (WLAN or Wi-Fi) , BLUETOOTHTM, etc.

[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. In particular, it is important to ensure the accuracy of transmitted and received signals through user equipment (UE) devices, e.g., through wireless devices such as cellular phones, base stations and relay stations used in wireless cellular communications. In addition, increasing the functionality of a UE device can place a significant strain on the battery life of the UE device. Thus, it is very important to also reduce power requirements in UE device designs while allowing the UE device to maintain good transmit and receive abilities for improved communications. Accordingly, improvements in the field are desired.SUMMARY

[0004] Embodiments are presented herein of apparatuses, systems, and methods for performing narrowband physical random-access channel (NPRACH) procedures with orthogonal cover codes (OCCs) in a wireless communication system, e.g., such as in an Internet of Things (IoT) non-terrestrial network (NTN) .

[0005] For example, in some embodiments, a wireless device can be configured to transmit, to a network, a RACH preamble (e.g., on OCC RACH resources) that includes at least an OCC index. Further, the wireless device can be configured to receive, from the network, a random-access response (RAR) message. The RAR message can include at least an indication of the OCC index and an uplink grant. As an example, the indication of the OCC index included in the RAR message can be indicated via a random-access preamble identifier (RAPID) medium access control (MAC) sub-header and / or a MAC RAR control element. Additionally, the RAPID can be calculated for a frequency identifier (f_id) as a product of the f_id and a number of OCC indexes plus the OCC index and / or as a product of a number of subcarriers and the OCC index plus the f_id. Further, the wireless device can be configured to transmit, to the network, on a physical uplink shared channel (PUSCH) associated with the uplink grant. The transmission can be physical data and / or a radio resource control (RRC) message.

[0006] As another example, in some embodiments, a network entity can be configured to receive, from a wireless device, a RACH preamble (e.g., on OCC RACH resources) that includes at least an OCC index. Further, the network entity can be configured to transmit, to the wireless device, a random-access response (RAR) message. The RAR message can include at least an indication of the OCC index and an uplink grant. As an example, the indication of the OCC index included in the RAR message can be indicated via a random-access preamble identifier (RAPID) medium access control (MAC) sub-header and / or a MAC RAR control element. Additionally, the RAPID can be calculated for a frequency identifier (f_id) as a product of the f_id and a number of OCC indexes plus the OCC index and / or as a product of a number of subcarriers and the OCC index plus the f_id. Further, the network entity can be configured to receive, from the wireless device, on a physical uplink shared channel (PUSCH) associated with the uplink grant. The reception can be physical data and / or a radio resource control (RRC) message.

[0007] Note that the techniques described herein can be implemented in and / or used with a number of different types of devices, including but not limited to cellular phones, tablet computers, accessory and / or wearable computing devices, portable media players, base  stations, access points, and other network infrastructure equipment, servers, unmanned aerial vehicles, unmanned aerial controllers, automobiles and / or motorized vehicles, and various other computing devices.

[0008] 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 THE DRAWINGS

[0009] A better understanding of the present subject matter can be obtained when the following detailed description of various embodiments is considered in conjunction with the following drawings, in which:

[0010] Figure 1 illustrates an exemplary (and simplified) wireless communication system, according to some embodiments.

[0011] Figure 2 illustrates an exemplary base station in communication with an exemplary wireless user equipment (UE) device, according to some embodiments.

[0012] Figure 3 illustrates an exemplary block diagram of a UE, according to some embodiments.

[0013] Figure 4 illustrates an exemplary block diagram of a base station, according to some embodiments.

[0014] Figure 5 illustrates a current implementation of an NPRACH.

[0015] Figure 6 illustrates a RACH procedure from a MAC layer perspective according to a current implementation of NB IoT.

[0016] Figure 7 illustrates an example of a DCI format N1, according to some embodiments.

[0017] Figure 8 illustrates an example of a RAR DCI that includes an OCC index and / or OCC pattern index, according to some embodiments.

[0018] Figures 9A and 9B illustrate examples of RAPID MAC sub-headers that include an OCC index and / or extended RAPID, according to some embodiments.

[0019] Figures 10A and 10B illustrate examples of MAC RARs that indicate an OCC index and / or extended RAPID, according to some embodiments.

[0020] Figures 11A and 11B illustrate examples possible sequences for fallback operation, according to some embodiments.

[0021] Figures 12 and 13 illustrate block diagrams of examples of methods for an orthogonal cover code (OCC) based random-access channel (RACH) procedure, according to some embodiments.

[0022] While features described herein are susceptible to various modifications and alternative forms, specific embodiments 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

[0023] Acronyms

[0024] Various acronyms are used throughout the present disclosure. Definitions of the most prominently used acronyms that can appear throughout the present disclosure are provided below:

[0025] · UE: User Equipment

[0026] · RF: Radio Frequency

[0027] · BS: Base Station

[0028] · GSM: Global System for Mobile Communication

[0029] · UMTS: Universal Mobile Telecommunication System

[0030] · LTE: Long Term Evolution

[0031] · NR: New Radio

[0032] · TX: Transmission / Transmit

[0033] · RX: Reception / Receive

[0034] · RAT: Radio Access Technology

[0035] · TRP: Transmission-Reception-Point

[0036] · DCI: Downlink Control Information

[0037] · CORESET: Control Resource Set

[0038] · QCL: Quasi-Co-Located or Quasi-Co-Location

[0039] · CSI: Channel State Information

[0040] · CSI-RS: Channel State Information Reference Signals

[0041] · CSI-IM: Channel State Information Interference Management

[0042] · CMR: Channel Measurement Resource

[0043] · IMR: Interference Measurement Resource

[0044] · ZP: Zero Power

[0045] · NZP: Non-Zero Power

[0046] · CQI: Channel Quality Indicator

[0047] · PMI: Precoding Matrix Indicator

[0048] · RI: Rank Indicator

[0049] Terms

[0050] The following is a glossary of terms that can appear in the present disclosure:

[0051] Memory Medium –Any of various types of non-transitory memory devices or storage devices. The term “memory medium” is intended to include any computer system memory or random-access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; 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, etc. The term “memory medium” can include two or more memory mediums which can reside in different locations, e.g., in different computer systems that are connected over a network. The memory medium can store program instructions (e.g., embodied as computer programs) that can be executed by one or more processors.

[0052] 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.

[0053] Computer System (or Computer) –any of various types of computing or processing systems, including a personal computer system (PC) , server-based computer system, wearable computer, network appliance, Internet appliance, smartphone, television system, grid computing system, or other device or combinations of devices. In general, the term "computer system" can be broadly defined to encompass any device (or combination of devices) having at least one processor that executes instructions from a memory medium.

[0054] User Equipment (UE) (or “UE Device” ) –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) , tablet computers, portable gaming devices, wearable devices (e.g., smart watch, smart glasses) , laptops, portable Internet devices, music players, data storage devices, other handheld  devices, automobiles and / or motor vehicles, unmanned aerial vehicles (UAVs) (e.g., drones) , UAV controllers (UACs) , etc. In general, the term “UE” or “UE device” can be broadly defined to encompass any electronic, computing, and / or telecommunications device (or combination of devices) which is easily transported by a user and capable of wireless communication.

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

[0056] Communication Device –any of various types of computer systems or devices that perform communications, where the communications can be wired or wireless. A communication device can be portable (or mobile) or can 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.

[0057] Base Station (BS) or Access Point (AP) –The term "Base Station" has the full breadth of its 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. The term “access point” (or “AP” ) is typically associated with Wi-Fi-based communications and is used similarly.

[0058] Processing Element (or Processor) –refers to various elements or combinations of elements that are capable of performing a function in a device, e.g., in a communication device or in a network infrastructure device. Processing elements can include, for example: processors and associated memory, portions or circuits of individual processor cores, entire processor cores, processor arrays, circuits such as an ASIC (Application Specific Integrated Circuit) , programmable hardware elements such as a field programmable gate array (FPGA) , and / or larger portions of systems that include multiple processors, as well as any of various combinations of the above.

[0059] Wi-Fi –The term "Wi-Fi" has the full breadth of its ordinary meaning, and at least includes a wireless communication network or RAT that is serviced by wireless LAN (WLAN) access points and which provides connectivity through these access points to the Internet. Most modern Wi-Fi networks (or WLAN networks) are based on IEEE 802.11 standards and are marketed under the name “Wi-Fi” . A Wi-Fi (WLAN) network is different from a cellular network.

[0060] Configured to –Various components can 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 can be  configured to perform the task even when the component is not currently performing that task (e.g., a set of electrical conductors can be configured to electrically connect a module to another module, even when the two modules are not connected) . In some contexts, “configured to” can be a broad recitation of structure generally meaning “having circuitry that” performs the task or tasks during operation. As such, the component can 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” can include hardware circuits.

[0061] Various components can 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.

[0062] Figures 1 and 2 –Exemplary Communication System

[0063] Figure 1 illustrates an exemplary (and simplified) wireless communication system in which aspects of this disclosure can be implemented, according to some embodiments. It is noted that the system of Figure 1 is merely one example of a possible system, and embodiments can be implemented in any of various systems, as desired.

[0064] As shown, the exemplary wireless communication system includes a base station 102 which communicates over a transmission medium with one or more (e.g., an arbitrary number of) user devices 106A, 106B, etc. through 106N. Each of the user devices can be referred to herein as a “user equipment” (UE) or UE device. Thus, the user devices 106 are referred to as UEs or UE devices.

[0065] The base station 102 can be a base transceiver station (BTS) or cell site and can include hardware and / or software that enables wireless communication with the UEs 106A through 106N. If the base station 102 is implemented in the context of LTE, it can alternately be referred to as an 'eNodeB' or 'eNB' . If the base station 102 is implemented in the context of 5G NR, it can alternately be referred to as a 'gNodeB' or 'gNB' . The base station 102 can 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 102 can facilitate communication among the user devices and / or between the user devices and the network 100. The communication area (or coverage area) of the base station can be referred to as a “cell. ” As also used herein, from the perspective of UEs, a base station can sometimes be considered as representing the network insofar as uplink and downlink communications of the UE are  concerned. Thus, a UE communicating with one or more base stations in the network can also be interpreted as the UE communicating with the network.

[0066] Note that, at least in some 3GPP NR contexts, base station (gNB) functionality can be split between a centralized unit (CU) and a distributed unit (DU) . The illustrated base station 102 can support the functionality of either or both of a CU or a DU, in such a network deployment context, at least according to some embodiments. In some instances, the base station 102 can be configured to act as an integrated access and backhaul (IAB) donor (e.g., including IAB donor CU and / or IAB donor DU functionality) . In some instances, the base station 102 can be configured to act as an IAB node (e.g., including IAB mobile termination (MT) and IAB-DU functionality) . Other implementations are also possible.

[0067] The base station 102 and the user devices can 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 LTE, LTE-Advanced (LTE-A) , LAA / LTE-U, 5G NR, 6G, Wi-Fi, etc.

[0068] Base station 102 and other similar base stations operating according to the same or a different cellular communication standard can thus be provided as one or more networks of cells, which can provide continuous or nearly continuous overlapping service to UE 106 and similar devices over a geographic area via one or more cellular communication standards.

[0069] Note that a UE 106 can be capable of communicating using multiple wireless communication standards. For example, a UE 106 might be configured to communicate using multiple 3GPP cellular communication standards. In some instances, the UE 106 can be configured to perform techniques for performing narrowband physical random-access channel (NPRACH) procedures with orthogonal cover codes (OCCs) in a wireless communication system, e.g., such as in an Internet of Things (IoT) non-terrestrial network (NTN) , such as according to the various methods described herein. The UE 106 might also or alternatively be configured to communicate using WLAN, BLUETOOTHTM, one or more global navigational satellite systems (GNSS, e.g., GPS or GLONASS) , one and / or more mobile television broadcasting standards (e.g., ATSC-M / H) , etc. Other combinations of wireless communication standards (including more than two wireless communication standards) are also possible.

[0070] Figure 2 illustrates an exemplary user equipment 106 (e.g., one of the devices 106A through 106N) in communication with the base station 102, according to some embodiments. The UE 106 can be a device with wireless network connectivity such as a mobile phone, a hand-held device, a wearable device, a computer or a tablet, an unmanned aerial vehicle  (UAV) , an unmanned aerial controller (UAC) , an automobile, or virtually any type of wireless device. The UE 106 can include a processor (processing element) that is configured to execute program instructions stored in memory. The UE 106 can perform any of the methods described herein, such as for performing a PRACH procedure with an OCC in an IoT NTN as described herein, by executing such stored instructions. Alternatively, or in addition, the UE 106 can 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 methods described herein, or any portion of any of the methods described herein. The UE 106 can be configured to communicate using any of multiple wireless communication protocols. For example, the UE 106 can be configured to communicate using two or more of LTE, LTE-A, 5G NR, 6G, Wi-Fi, BLUETOOTHTM, or GNSS. Other combinations of wireless communication standards are also possible.

[0071] The UE 106 can include one or more antennas for communicating using one or more wireless communication protocols according to one or more RAT standards. In some embodiments, the UE 106 can share one or more parts of a receive chain and / or transmit chain between multiple wireless communication standards. The shared radio can include a single antenna, or can include multiple antennas (e.g., for multiple-input, multiple-output or “MIMO” ) for performing wireless communications. In general, a radio can include any combination of a baseband processor, analog RF signal processing circuitry (e.g., including filters, mixers, oscillators, amplifiers, etc. ) , or digital processing circuitry (e.g., for digital modulation as well as other digital processing) . Similarly, the radio can implement one or more receive and transmit chains using the aforementioned hardware. For example, the UE 106 can share one or more parts of a receive and / or transmit chain between multiple wireless communication technologies, such as those discussed above.

[0072] In some embodiments, the UE 106 can include any number of antennas and can be configured to use the antennas to transmit and / or receive directional wireless signals (e.g., beams) . Similarly, the BS 102 can also include any number of antennas and can be configured to use the antennas to transmit and / or receive directional wireless signals (e.g., beams) . To receive and / or transmit such directional signals, the antennas of the UE 106 and / or BS 102 can be configured to apply different “weight” to different antennas. The process of applying these different weights can be referred to as “precoding” .

[0073] In some embodiments, the UE 106 can 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 can include one or more radios that are shared between multiple wireless communication protocols, and one or more radios that are used exclusively by a single wireless communication protocol. For example, the UE 106 can include a shared radio for communicating using either of LTE or NR, and separate radios for communicating using each of Wi-Fi and BLUETOOTHTM. Other configurations are also possible.

[0074] Figure 3 –Block Diagram of an Exemplary UE Device

[0075] Figure 3 illustrates a block diagram of an exemplary UE 106, according to some embodiments. As shown, the UE 106 can include a system on chip (SOC) 300, which can include portions for various purposes. Some or all of the various illustrated components (and / or other device components not illustrated, e.g., in variations and alternative arrangements) can be “communicatively coupled” or “operatively coupled, ” which terms can be taken herein to mean components that can communicate, directly or indirectly, when the device is in operation.

[0076] As shown, the SOC 300 can include processor (s) 302 which can execute program instructions for the UE 106 and display circuitry 304 which can perform graphics processing and provide display signals to the display 360. The SOC 300 can also include sensor circuitry 370, which can include components for sensing or measuring any of a variety of possible characteristics or parameters of the UE 106. For example, the sensor circuitry 370 can include motion sensing circuitry configured to detect motion of the UE 106, for example using a gyroscope, accelerometer, and / or any of various other motion sensing components. As another possibility, the sensor circuitry 370 can include one or more temperature sensing components, for example for measuring the temperature of each of one or more antenna panels and / or other components of the UE 106. Any of various other possible types of sensor circuitry can also or alternatively be included in UE 106, as desired. The processor (s) 302 can also be coupled to memory management unit (MMU) 340, which can 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, radio 330, connector I / F 320, and / or display 360. The MMU 340 can be configured to perform memory protection and page table translation or set up. In some embodiments, the MMU 340 can be included as a portion of the processor (s) 302.

[0077] As shown, the SOC 300 can be coupled to various other circuits of the UE 106. For example, the UE 106 can include various types of memory (e.g., including NAND flash 310) , a connector interface 320 (e.g., for coupling to a computer system, dock, charging station, etc. ) ,  the display 360, and wireless communication circuitry 330 (e.g., for LTE, LTE-A, 5G NR, 6G, BLUETOOTHTM, Wi-Fi, GPS, etc. ) . The UE device 106 can include or couple to at least one antenna (e.g., 335a) , and possibly multiple antennas (e.g., illustrated by antennas 335a and 335b) , for performing wireless communication with base stations and / or other devices. Antennas 335a and 335b are shown by way of example, and UE device 106 can include fewer or more antennas. Overall, the one or more antennas are collectively referred to as antenna 335. For example, the UE device 106 can use antenna 335 to perform the wireless communication with the aid of radio circuitry 330. The communication circuitry can include multiple receive chains and / or multiple transmit chains for receiving and / or transmitting multiple spatial streams, such as in a multiple-input multiple output (MIMO) configuration. As noted above, the UE can be configured to communicate wirelessly using multiple wireless communication standards in some embodiments.

[0078] The UE 106 can include hardware and software components for implementing methods for the UE 106 to perform techniques for performing NPRACH procedures with OCCs in a wireless communication system, e.g., such as in an IoT NTN, such as described further subsequently herein. The processor (s) 302 of the UE device 106 can be configured to implement part or all of the methods described herein, e.g., by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium) . In other embodiments, processor (s) 302 can be configured as a programmable hardware element, such as an FPGA (Field Programmable Gate Array) , or as an ASIC (Application Specific Integrated Circuit) . Furthermore, processor (s) 302 can be coupled to and / or can interoperate with other components as shown in Figure 3, to perform techniques for performing NPRACH procedures with OCCs in a wireless communication system, e.g., such as in an IoT NTN according to various embodiments disclosed herein. Processor (s) 302 can also implement various other applications and / or end-user applications running on UE 106.

[0079] In some embodiments, radio 330 can include separate controllers dedicated to controlling communications for various respective RAT standards. For example, as shown in Figure 3, radio 330 can include a Wi-Fi controller 352, a cellular controller (e.g., 6G, 5G NR, LTE and / or LTE-Acontroller) 354, and BLUETOOTHTM controller 356, and in at least some embodiments, one or more or all of these controllers can be implemented as respective integrated circuits (ICs or chips, for short) in communication with each other and with SOC 300 (and more specifically with processor (s) 302) . For example, Wi-Fi controller 352 can communicate with cellular controller 354 over a cell-ISM link or WCI interface, and / or BLUETOOTHTM controller 356 can communicate with cellular controller 354 over a cell-ISM  link, etc. While three separate controllers are illustrated within radio 330, other embodiments have fewer or more similar controllers for various different RATs that can be implemented in UE device 106.

[0080] Further, embodiments in which controllers can implement functionality associated with multiple radio access technologies are also envisioned. For example, according to some embodiments, the cellular controller 354 can, in addition to hardware and / or software components for performing cellular communication, include hardware and / or software components for performing one or more activities associated with Wi-Fi, such as Wi-Fi preamble detection, and / or generation and transmission of Wi-Fi physical layer preamble signals.

[0081] Figure 4 –Block Diagram of an Exemplary Base Station

[0082] Figure 4 illustrates a block diagram of an exemplary base station 102, according to some embodiments. It is noted that the base station of Figure 4 is merely one example of a possible base station. As shown, the base station 102 can include processor (s) 404 which can execute program instructions for the base station 102. The processor (s) 404 can also be coupled to memory management unit (MMU) 440, which can 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.

[0083] The base station 102 can include at least one network port 470. The network port 470 can 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 Figures 1 and 2. The network port 470 (or an additional network port) can also or alternatively be configured to couple to a cellular network, e.g., a core network of a cellular service provider. The core network can 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 can couple to a telephone network via the core network, and / or the core network can provide a telephone network (e.g., among other UE devices serviced by the cellular service provider) .

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

[0085] The base station 102 can include at least one antenna 434, and possibly multiple antennas. The antenna (s) 434 can be configured to operate as a wireless transceiver and can be further configured to communicate with UE devices 106 via radio 430. The antenna (s) 434 communicates with the radio 430 via communication chain 432. Communication chain 432 can be a receive chain, a transmit chain or both. The radio 430 can be designed to communicate via various wireless telecommunication standards, including, but not limited to, 6G, 5G NR, 5G NR SAT, LTE, LTE-A, Wi-Fi, etc.

[0086] The base station 102 can be configured to communicate wirelessly using multiple wireless communication standards. In some instances, the base station 102 can include multiple radios, which can enable the base station 102 to communicate according to multiple wireless communication technologies. For example, as one possibility, the base station 102 can 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 can be capable of operating as both an LTE base station and a 5G NR base station. As another possibility, the base station 102 can include a multi-mode radio which is capable of performing communications according to any of multiple wireless communication technologies (e.g., 5G NR and Wi-Fi, 5G NR SAT and Wi-Fi, LTE and Wi-Fi, etc. ) .

[0087] As described further subsequently herein, the BS 102 can include hardware and software components for implementing or supporting implementation of features described herein. The processor 404 of the base station 102 can be configured to implement and / or support implementation of part or all of the methods described herein, e.g., by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium) . Alternatively, the processor 404 can be configured as a programmable hardware element, such as an FPGA (Field Programmable Gate Array) , or as an ASIC (Application Specific Integrated Circuit) , or a combination thereof. In the case of certain RATs, for example Wi-Fi, base station 102 can be designed as an access point (AP) , in which case network port 470 can be implemented to provide access to a wide area network and / or local area network (s) , e.g., it can include at least one Ethernet port, and radio 430 can be designed to communicate according to the Wi-Fi standard.

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

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

[0090] MAC Design for NPRACH with OCC in IoT NTN

[0091] In current implementations, the capacity / throughput in a Non-Terrestrial Network (NTN) for Internet of Things (IoT) is limited to one UE in a subcarrier, e.g., one UE per single 3.75 kilohertz (kHz) or 15 kHz subcarrier for a narrowband physical uplink shared channel (NPUSCH) format 1 or a narrowband physical random-access channel (NPRACH) . For example, Figure 5 illustrates a current implementation of an NPRACH, e.g., as defined in 3GPP standards. As shown, a preamble symbol (e.g., a cyclic prefix (CP) symbol) can be repeated N times in one symbol group and frequency hopping can be applied between symbol groups. Thus, as shown, a CP can be repeated at a first frequency 6 times (e.g., in one symbol group) and then shifted 3.75kHz and repeated another 6 times. Further, the CP can then be shifted 22.5kHz and repeated 6 times and then shifted 3.75kHz and repeated another 6 times. Note that 4 symbol groups form 1 PRACH (or NPRACH) transmission. The transmitter can then perform a random hop (e.g., shift the frequency by a random amount) and then repeat the PRACH transmission, as shown. Further, Figure 6 illustrates a random-access channel (RACH) procedure from a medium access control (MAC) layer perspective according to a current implementation of narrowband (NB) IoT, e.g., as defined in 3GPP standards. As shown, a UE initiates the RACH procedure via a message 1 (e.g., MSG1) to a radio access network (RAN) . For the MSG1, the UE selects a random access preamble and a random sequence number for the preamble. After choosing the preamble and sequence number, the UE transmits the preamble on the PRACH. The RAN (e.g., after receiving the MSG1) responds with a message 2 (e.g., MSG2) which includes a random-access response (RAR) with a random-access (RA) radio network temporary identifier (RNTI) . In addition, the MSG2 includes a Time Advance (TA) command for timing adjustment, a RAPID (Random Access Preamble ID) matching the preamble sent by the UE, and an initial uplink grant for the UE. The UE (e.g., upon receipt of the MSG2) can then respond with a message 3 (e.g., MSG3) using the initial uplink grant. The MSG3 is a PUCH that can carry an RRC message (e.g., such as RrcRequest) or just be physical data. After processing the MSG3, the RAN can send a message 4 (e.g., MSG4) for contention resolution. The MSG4 is a MAC data message and contains the UE's identity, confirming that the RAN has correctly identified the UE and contention has been resolved. In addition, the  RAN can provide UE with a cell radio network temporary identifier (C-RNTI) . In current implementations, RACH resource selection starts with early data transmission (EDT) based resource selection, then moves to coverage enhancement level based selection (e.g., rsrp-ThresholdsPrachInfoList-r16) , and then to anchor carrier / non-anchor carrier selection. In addition, RA preamble (e.g., subcarrier) selection is based on MSG3 single tone / multitone capability and then moves to preamble group A / B selection. Other aspects for NB-IoT RACH includes physical downlink control channel (PDCCH) order triggered RACH, power control for preamble transmission, and RAR reception, e.g., Random Access Radio Network Temporary Identifier (RA-RNTI) determination.

[0092] Based on current implementations, there are several impacts that can arise from adding OCC to NPRACH, such as RACH resource selection with OCC, OCC index selection, power control on preamble transmission, MSG2 reception, MSG3 transmission with OCC, RACH fallback from OCC coded RACH to non-OCC coded RACH, and UE-RAN interoperability.

[0093] Further, it is undefined how a network can address each UE within a RAR. For example, for each RACH preamble, multiple UEs could transmit the same RACH preamble with different OCC. In current implementations, a Random Access Radio Network Temporary Identifier (RA-RNTI) is determined by a UE’s RACH preamble resource in time domain and carrier domain. Additionally, frequency domain RACH resource information is reflected in a random-access preamble identifier (RAPID) , which is carried in the RAR. In addition, for NB-IoT UEs, a RA-RNTI associated with a PRACH in which a random-access preamble is transmitted can be computed as shown in equation (1) :

[0094] wherein SFNid is an index of a first radio frame of a specified PRACH and carrierid is an index of an uplink (UL) carrier associated with the specified PRACH. Note that a carrierid of an anchor carrier is 0.

[0095] Embodiments described herein provide systems, methods, and mechanisms for NPRACH with OCC, e.g., such as in an IoT NTN. For example, embodiments described herein provide systems, methods, and mechanisms for configuration and / or selection of RACH resources with OCC coded, selection of an OCC code index in a preamble transmission, power control for OCC coded RACH, RA-RNTI determination, RAR configuration (e.g., MSG2 configuration) , MSG3 configuration, fallback operation, and UE-RAN interoperability.

[0096] In some instances, a legacy UE, e.g., a UE that does not support OCC coded RACH, cannot transmit over RACH resources with OCC coded. Hence, an additional metric (e.g.,  “OCC enabled” ) for RACH resources via NPRACH-ConfigSIB-NB can be introduced to a network configuration. The metric can be applicable for early data transmission (EDT) RACH, anchor carriers, and / or non-anchor carriers. In some instances, the network configuration can be flexible, e.g., only configured in anchor carrier or non-EDT RACH. Further, among PRACH resources selection procedures, EDT / non-EDT differentiation can be most important in determining PRACH resources, as it allows the network to differentiate the intention of MSG3. Note, however, coverage enhancement level based non-anchor carrier exclusion can also be crucial in determining PRACH resources because those non-anchor carriers which do not meet a minimum reference signal received power (RSRP) threshold should not be selected for OCC coded RACH. Thus, conditions for using OCC coded PRACH resources can include requiring a UE to have valid Global navigation satellite system (GNSS) location and ephemeris data of a satellite to initiate an OCC coded RACH procedure since uplink synchronization can be crucial to enable OCC coded RACH. Similarly, a UE without an accurate GNSS location (e.g., not meeting an accuracy of X meters) can be required to initiate legacy RACH resource selection. In some instances, RACH resources with OCC coded selection can proceed in the following order: EDT based selection followed by coverage enhancement (CE) level based (e.g., rsrp-ThresholdsPrachInfoList-r16) selection, followed by OCC coded based selection, followed by anchor carrier / non-anchor carrier-based selection. As a first alternative, RACH resources with OCC coded selection can proceed in the following order: EDT based selection followed by coverage enhancement level based (rsrp-ThresholdsPrachInfoList-r16) selection, followed by anchor carrier / non-anchor carrier-based selection, followed by OCC coded based selection. As a second alternative, RACH resources with OCC coded selection can proceed in the following order: EDT based selection followed by OCC coded based selection, followed by coverage enhancement level based (rsrp-ThresholdsPrachInfoList-r16) selection, followed by anchor carrier / non-anchor carrier-based selection. Note that with a flexible network configuration, it can be possible that one carrier has either OCC enabled or OCC non-enabled RACH resource, hence, a UE can be allowed to perform carrier selection and OCC based PRACH selection at one time, e.g., EDT based selection followed by coverage enhancement level based (e.g., rsrp-ThresholdsPrachInfoList-r16) selection, followed by OCC coded based selection, followed by anchor carrier / non-anchor carrier based selection.

[0097] In some instances, for UE triggered RACH, an OCC code index can be randomly selected by a UE. Alternatively, an OCC code index can be based on a UE identifier, e.g., such as a System Architecture Evolution (SAE) Temporary Mobile Subscriber Identity (TMSI) (S- TMSI) , a resume identifier (ID) , and so forth. For example, an OCC index can be calculated as (UE ID) mod (OCC coding number) .

[0098] In some instances, for network triggered RACH (e.g., a physical downlink control channel (PDCCH) or narrowband PDCCH (NPDCCH) ordered triggered RACH) , an OCC code index can be indicated in a downlink control information (DCI) format N1, e.g., as illustrated by Figure 7. As shown, the DCI format N1 can include, among other fields, an OCC index field. The OCC index field can include 2 bits, as illustrated. In addition, the DCI format N1 can include fields such as a flag for format N0 / N1 differentiation (e.g., 1 bit) , an NPDCCH order indicator (e.g., 1 bit) , a starting number of NPRACH repetitions (e.g., 2 bits) , a subcarrier indication of NPRACH (e.g., 6 bits) , the OCC index (e.g., associated with a RACH resource) , as well as additional fields.

[0099] In some instances, for EDT and / or Pre-configured UL resource (PUR) procedures, a network can indicate an OCC index via radio resource control (RRC) signaling. For example, an OCC index can be configured via an RRCConnectionRelease message.

[0100] In some instances, for OCC coded RACH transmission, a target received power and a power ramping step can demand a different configuration due to possible interference from other UE (s) with the same OCC index and / or a different OCC index (e.g., if not perfectly orthogonal duet to a time difference) . Thus, for power control configurations for OCC coded RACH, a network can provide a different configuration on a power ramping step (e.g., preambleInitialReceivedTargetPower) for non-OCC coded RACH resources and a power ramping step (e.g., powerRampingStep) for OCC coded RACH resources. Then, when a UE operates in OCC coded RACH resource, the UE can apply corresponding power control parameters, e.g., for OCC coded RACH resources and non-OCC coded RACH resources.

[0101] In some instances, to address a UE for OCC coded MSG2 transmissions, e.g., to determine an RA-RNTI to address a UE in an MSG2 transmission when OCC is used, an RA-RNTI field in the MSG2 transmission can be extended to indicate an OCC index and / or an OCC pattern index, e.g., as illustrated in equations (2) and (3) .

[0102] In other instances, to address a UE for OCC coded MSG2 transmissions, e.g., to determine an RA-RNTI to address a UE in an MSG2 transmission when OCC is used, an OCC index and / or an OCC pattern index can be scrambled into an RAR DCI. Alternatively, in other instances, an OCC index and / or OCC pattern index can be included in an RAR DCI, e.g., as  illustrated by Figure 8. As shown, an OCC index and / or OCC pattern index field can be added to a DCI by reducing a number of reserved bits. Thus, instead of 5 bits being reserved, the number of reserved bits can be reduced to 3. In addition, the RAR DCI can include fields such as a flag for format N0 / N1 differentiation (e.g., 1 bit) , an NPDCCH order indicator (e.g., 1 bit) , a scheduling delay (e.g., 3 bits) , a resource assignment (e.g., 3 bits) , a modulation and coding scheme (e.g., 4 bits) , a repetition number (e.g., 4 bits) , and a DCI subframe repetition number (e.g., 2 bits) .

[0103] In some instances, to address a UE for OCC coded MSG2 transmissions, e.g., to determine an RA-RNTI to address a UE in an MSG2 transmission when OCC is used, an enhanced algorithm can be introduced to calculate and / or determine a RAPID of a UE. For example, the RAPID for an OOC index over one index of a specified PRACH in the frequency domain (e.g., f_id and / or fid) can be calculated as shown in equations (4) and (5) : fid=NOCC*fid+OCCindex        (4) fid=Nsubcarries*OCCindes+fid        (5)

[0104] where OCCindex and fid start from zero. In some instances, the OCC index and / or extended RAPID (e.g., extended from 8 bits to 10 or more bits) can be carried and / or included in a RAPID MAC sub-header, e.g., as illustrated by Figures 9A and 9B. As shown in Figure 9A, an OCC index and / or OCC pattern can be included in a second octet of the RAPID MAC sub-header. The OCC index / pattern can have a size of 2 bits, for example. As shown in Figure 9B, alternatively, the RAPID can be extend to 10 bits, with 2 bits being included in a second octet of the RAPID MAC sub-header. In other instances, the OCC index and / or extended RAPID (e.g., extended from 8 bits to 10 or more bits) can be carried and / or included in a MAC RAR by repurposing an “R” field of the MAC RARfto indicate the OCC index and / or extended RAPID, e.g., as illustrated by Figures 10A and 10B. For example, Figure 10A illustrates a MAC RAR for NB-IoT UEs in which an “R” field is repurposed as an OCC index / RAPID field. As another example, Figure 10B illustrates a MAC RAR for NB-IoT UEs using PRACH preamble format 2 in which an “R” field is repurposed as an OCC index / RAPID field.

[0105] In some instances, to address a UE for OCC coded MSG2 transmissions, e.g., to determine an RA-RNTI to address a UE in an MSG2 transmission when OCC is used, an RA-RNTI algorithm can be reformatted to reflect an fid of a preamble and a RAPID of a RAR can be repurposed to represent an OCC index, e.g., as shown in equation (6) :

[0106] In some instances, to address a UE for OCC coded MSG2 transmissions, e.g., to determine an RA-RNTI to address a UE in an MSG2 transmission when OCC is used, multiple timing advance command (TAC) fields can be introduced to address multiple UEs that have transmitted the same preamble. In addition, other fields can be shared as UL grant can be the same for multiple UEs.

[0107] As noted, the same UL grant can be assigned for multiple UE (s) that have transmitted the same preamble with OCC coded. However, some UEs can have a higher priority and the OCC configuration for PUSCH can be different from PRACH. Thus, PUSCH OCC index selection can be performed again. Thus, in some instances, an OCC index (and / or no OCC coding) can be indicated to each UE in an uplink (UL) grant in RAR. Such a scheme can be used to achieve non-conflict for high prioritized UEs (e.g., can be specifically useful when a network pre-allocates a PRACH resource to the UE) . In some instances, OCC index selection during initial MSG3 transmission can be accomplished by the network indicating the OCC index (e.g., for PUSCH) for UL grant in RAR. In some instances, OCC index selection during initial MSG3 transmission can be accomplished by a UE randomly selecting an OCC index from a PUSCH OCC configuration, e.g., when an OCC index has not been provided by the network. Further, in some instances, OCC index selection during initial MSG3 transmission can be accomplished by the UE re-using the same OCC index from PRACH transmission, e.g., when the PUSCH OCC configuration is the same as PRACH OCC configuration and an OC index has not been provided by the network. In some instances, OCC index selection during MSG3 re-transmission can be accomplished by the UE selecting the same OCC index as an initial MSG3 transmission for network to perform soft combining, e.g., when the network schedules the MSG3 re-transmission. Alternatively, e.g., when the UE starts from a preamble transmission due to contention resolution timer expiry and the UE selects OCC coded PRACH resource, the UE can optionally re-use the same OCC index or can perform the PRACH resource / preamble selection from scratch.

[0108] In some instances, for fallback operation, when a UE has tried RACH attempts for a certain number of times without success, the UE can fallback to a non-OCC coded RACH. Note that the number of RACH attempts can be pre-configured. Figures 11A and 11B illustrate possible sequences for fallback operation. As illustrated by Figure 11A, once a maximum number of RACH attempts with OCC (e.g., at 1102a-n) has been reached without success (e.g., met a threshold, such as maxNumPreambleAttemptOCC) , the UE can fallback to non-OCC coded RACH with coverage enhancement (CE) level n. Further, if the non-OCC coded RACH with CE level n at 1104 fails, the UE can fallback to non-OCC coded RACH with CE level  n+1 (e.g., a higher CE level) at 1106. Alternatively, as illustrated by Figure 11B, once a maximum number of RACH attempts with OCC (e.g., at 1102a-n) has been reached without success (e.g., met a threshold, such as maxNumPreambleAttemptOCC) , the UE can fallback to OCC coded RACH with coverage enhancement (CE) level n+1. Further, if the OCC coded RACH with CE level n+1 fails at 1108, the UE can fallback to non-OCC coded RACH with CE level n+1 at 1110.

[0109] In some instances, for UE-RAN interoperability, a UE can indicate supported OCC patterns / types to the network via a UE capability information element (IE) . In addition, the network can indicate enabling of OCC coded RACH via a system information block (SIB) . For example, enabling of OCC coded RACH can be implicitly indicated by OCC coded RACH resource configuration and / or explicitly indicated by a dedicated field in a SIB1. Further, the network can indicate an OCC pattern in each RACH resource, where an OCC pattern can be size 2, 4, and / or 8.

[0110] Figure 12 illustrates a block diagram of an example of a method for an orthogonal cover code (OCC) based random-access channel (RACH) procedure, according to some embodiments. Aspects of the method of Figure 12 can be implemented by a wireless device, e.g., in conjunction with one or more cellular base stations, such as a UE 106 and a base station 102 illustrated in and described with respect to various of the Figures herein, or more generally in conjunction with any of the computer circuitry, systems, devices, elements, or components shown in the above Figures, among others, as desired. For example, a processor (and / or other hardware) of such a device can be configured to cause the device to perform any combination of the illustrated method elements and / or other method elements.

[0111] Note that while at least some elements of the method of Figure 12 are described in a manner relating to the use of communication techniques and / or features associated with 3GPP and / or NR specification documents, such description is not intended to be limiting to the disclosure, and aspects of the method of Figure 12 can be used in any suitable wireless communication system, as desired. In various embodiments, some of the elements of the methods shown can be performed concurrently, in a different order than shown, can be substituted for by one or more other method elements, or can be omitted. Additional method elements can also be performed as desired. As shown, the method of Figure 12 can operate as follows.

[0112] At 1202, a wireless device, such as UE 106, can transmit, to a network, e.g., to a network entity such as base station 102, a RACH preamble that includes at least an OCC index. The RACH preamble can be transmitted on OCC RACH resources, e.g., that have been  indicated to the wireless device by the network. In some instances, the wireless device can only transmit on the OCC RACH resources when the wireless device has a valid GNSS location and ephemeris data of a satellite associated with the network. In some instances, the network can be a non-terrestrial network (NTN) and the network entity can be located on a satellite of the NTN. In some instances, the wireless device can be an Internet-of-Things (IoT) wireless device.

[0113] In some instances, the OCC index can be randomly selected, e.g., by the wireless device. In other instances, the OCC index can be indicated by the network via a downlink control information (DCI) format N1. The DCI format N1 can include a field indicating the OCC index. The field can include at least 2 bits. In such instances, the wireless device can receive, from the network, the DCI format N1 that includes the field indicating the OCC index. In yet other instances, the OCC index can be based on a device identifier. For example, the device identifier comprises can be at least one of a System Architecture Evolution (SAE) Temporary Mobile Subscriber Identity (TMSI) (S-TMSI) and / or a resume identifier (ID) . In such instances, the wireless device can calculate the OCC index as a product of the device identifier and a modulo of an OCC coding number. In further instances, the OCC index can be indicated via a radio resource control (RRC) connection release message, e.g., such as when the OCC index is used for an early data transmission (EDT) procedure or a pre-configured uplink resource (PUR) procedure.

[0114] At 1204, the wireless device can receive, from the network, a random-access response (RAR) message. The RAR message can include at least an indication of the OCC index and an uplink grant.

[0115] In some instances, the indication of the OCC index included in the RAR message can be indicated via a random-access preamble identifier (RAPID) medium access control (MAC) sub-header and / or a MAC RAR control element. In such instances, the RAPID can be calculated for a frequency identifier (f_id) as a product of the f_id and a number of OCC indexes plus the OCC index and / or as a product of a number of subcarriers and the OCC index plus the f_id. In some instances, the indication can be the OCC index. In other instances, the indication can be the RAPID derived based on the OCC index.

[0116] In some instances, the indication of the OCC index included in the RAR message can be indicated via a Random Access Radio Network Temporary Identifier (RA-RNTI) derived using the OCC index, e.g., as show above in equations (2) and / or (3) .

[0117] In some instances, the indication of the OCC index included in the RAR message can be indicated by scrambling the OCC index into a RAR DCI. In other instances, the indication of the OCC index included in the RAR message can be included in a RAR DCI.

[0118] In some instances, the indication of the OCC index included in the RAR message can be indicated in a RAPID field in the RAR. In such instances, the RA-RNTI can be calculated as shown above in equation (6) .

[0119] In some instances, a timing advance control field of a RAR DCI can be used as the indication of the OCC index included in the RAR message.

[0120] At 1206, the wireless device can transmit, to the network, on a physical uplink shared channel (PUSCH) associated with the uplink grant. The transmission can be physical data and / or a radio resource control (RRC) message.

[0121] In some instances, prior to sending the RACH preamble, the wireless device can receive, from the network, power control parameters for OCC coded RACH. Further, the wireless device can apply the power control parameters to transmissions to the network using OCC coded RACH resources.

[0122] In some instances, prior to sending the RACH preamble, the wireless device can transmit, to the network, an indication of support for OCC based RACH procedures. The indication can include supported OCC patterns and / or OCC types.

[0123] In some instances, prior to sending the RACH preamble, the wireless device can receive, from the network, an indication of an OCC pattern associated with a RACH resource.

[0124] In some instances, prior to sending the RACH preamble, the wireless device can receive, from the network, a RACH resource configuration. The RACH resource configuration implicitly indicates support for OCC based RACH procedures.

[0125] In some instances, prior to sending the RACH preamble, the wireless device can receive, from the network, an indication for OCC based RACH procedures in a system information block (SIB) . The SIB can be a SIB1, in at least some instances.

[0126] In some instances, an OCC index for the PUSCH can be included or indicated in the RAR message, can be randomly selected from a PUSCH OCC configuration, e.g., by the wireless device, and / or can be the OCC index from the RACH transmission when a PUSCH OCC configuration is the same as a PRACH OCC configuration.

[0127] In some instances, such as when the wireless device does not receive a contention resolution message from the network (e.g., indicating RACH failure) , the wireless device can repeat the OCC RACH procedure (e.g., repeat transmitting the RACH preamble, receiving the RAR message, and transmitting on the PUSCH) a number of times. Further, the wireless device  can determine, when the number of times repeating the OCC RACH procedure exceeds a threshold, a RACH failure. In some instances, in response to determining the RACH failure, the wireless device can attempt a non-OCC coded RACH procedure with a coverage enhancement (CE) level equivalent to a CE level used for the OCC coded RACH procedure and, upon determining failure of the non-OCC coded RACH procedure, attempt another non-OCC coded RACH procedure with an increased CE level as compared to the CE level used for the non-OCC coded RACH procedure. In other instances, the wireless device can attempt an other OCC coded RACH procedure with an increased CE level as compared to the CE level used for the OCC coded RACH procedure, and upon failure of the other OCC coded RACH procedure, attempt a non-OCC coded RACH procedure with a CE level equivalent to the CE level used for the other OCC coded RACH procedure.

[0128] Thus, at least according to some embodiments, the method of Figure 12 can be used to provide a framework according to which a wireless device can be configured to perform an OCC based RACH procedure, e.g., such as in an IoT NTN and thus to assist a cellular network to effectively and efficiently schedule and perform wireless communications with the wireless device, at least in some instances.

[0129] Figure 13 illustrates a block diagram of another example of a method for an orthogonal cover code (OCC) based random-access channel (RACH) procedure, according to some embodiments. Aspects of the method of Figure 13 can be implemented by a network entity, e.g., in conjunction with one or more wireless devices, such as a UE 106 and a base station 102 illustrated in and described with respect to various of the Figures herein, or more generally in conjunction with any of the computer circuitry, systems, devices, elements, or components shown in the above Figures, among others, as desired. For example, a processor (and / or other hardware) of such a device can be configured to cause the device to perform any combination of the illustrated method elements and / or other method elements.

[0130] Note that while at least some elements of the method of Figure 13 are described in a manner relating to the use of communication techniques and / or features associated with 3GPP and / or NR specification documents, such description is not intended to be limiting to the disclosure, and aspects of the method of Figure 13 can be used in any suitable wireless communication system, as desired. In various embodiments, some of the elements of the methods shown can be performed concurrently, in a different order than shown, can be substituted for by one or more other method elements, or can be omitted. Additional method elements can also be performed as desired. As shown, the method of Figure 13 can operate as follows.

[0131] At 1302, a network entity, such as base station 102, can receive, from a wireless device, e.g., such as US 106, a RACH preamble that includes at least an OCC index. The RACH preamble can be received on OCC RACH resources, e.g., that have been indicated to the wireless device by the network entity. In some instances, the wireless device can only transmit on the OCC RACH resources when the wireless device has a valid GNSS location and ephemeris data of a satellite associated with the network. In some instances, the network can be a non-terrestrial network (NTN) and the network entity can be located on a satellite of the NTN. In some instances, the wireless device can be an Internet-of-Things (IoT) wireless device.

[0132] In some instances, the OCC index can be randomly selected, e.g., by the wireless device. In other instances, the OCC index can be indicated by the network via a downlink control information (DCI) format N1. The DCI format N1 can include a field indicating the OCC index. The field can include at least 2 bits. In such instances, the wireless device can receive, from the network, the DCI format N1 that includes the field indicating the OCC index. In yet other instances, the OCC index can be based on a device identifier. For example, the device identifier comprises can be at least one of a System Architecture Evolution (SAE) Temporary Mobile Subscriber Identity (TMSI) (S-TMSI) and / or a resume identifier (ID) . In such instances, the wireless device can calculate the OCC index as a product of the device identifier and a modulo of an OCC coding number. In further instances, the OCC index can be indicated via a radio resource control (RRC) connection release message, e.g., such as when the OCC index is used for an early data transmission (EDT) procedure or a pre-configured uplink resource (PUR) procedure.

[0133] At 1304, the network entity can transmit, to the wireless device, a random-access response (RAR) message. The RAR message can include at least an indication of the OCC index and an uplink grant.

[0134] In some instances, the indication of the OCC index included in the RAR message can be indicated via a random-access preamble identifier (RAPID) medium access control (MAC) sub-header and / or a MAC RAR control element. In such instances, the RAPID can be calculated for a frequency identifier (f_id) as a product of the f_id and a number of OCC indexes plus the OCC index and / or as a product of a number of subcarriers and the OCC index plus the f_id. In some instances, the indication can be the OCC index. In other instances, the indication can be the RAPID derived based on the OCC index.

[0135] In some instances, the indication of the OCC index included in the RAR message can be indicated via a Random Access Radio Network Temporary Identifier (RA-RNTI) derived using the OCC index, e.g., as show above in equations (2) and / or (3) .

[0136] In some instances, the indication of the OCC index included in the RAR message can be indicated by scrambling the OCC index into a RAR DCI. In other instances, the indication of the OCC index included in the RAR message can be included in a RAR DCI.

[0137] In some instances, the indication of the OCC index included in the RAR message can be indicated in a RAPID field in the RAR. In such instances, the RA-RNTI can be calculated as shown above in equation (6) .

[0138] In some instances, a timing advance control field of a RAR DCI can be used as the indication of the OCC index included in the RAR message.

[0139] At 1306, the network entity can receive, from the wireless device, on a physical uplink shared channel (PUSCH) associated with the uplink grant. The reception can be physical data and / or a radio resource control (RRC) message.

[0140] In some instances, prior to receiving the RACH preamble, the network entity can transmit, to the wireless device, power control parameters for OCC coded RACH. Further, the wireless device can apply the power control parameters to transmissions to the network entity using OCC coded RACH resources.

[0141] In some instances, prior to receiving the RACH preamble, the network entity can receive, from the wireless device, an indication of support for OCC based RACH procedures. The indication can include supported OCC patterns and / or OCC types.

[0142] In some instances, prior to receiving the RACH preamble, the network entity can transmit, to the wireless device, an indication of an OCC pattern associated with a RACH resource.

[0143] In some instances, prior to receiving the RACH preamble, the network entity can transmit, to the wireless device, a RACH resource configuration. The RACH resource configuration implicitly indicates support for OCC based RACH procedures.

[0144] In some instances, prior to receiving the RACH preamble, the network entity can transmit, to the wireless device, an indication for OCC based RACH procedures in a system information block (SIB) . The SIB can be a SIB1, in at least some instances.

[0145] In some instances, an OCC index for the PUSCH can be included or indicated in the RAR message, can be randomly selected from a PUSCH OCC configuration, e.g., by the wireless device, and / or can be the OCC index from the RACH transmission when a PUSCH OCC configuration is the same as a PRACH OCC configuration.

[0146] Thus, at least according to some embodiments, the method of Figure 13 can be used to provide a framework according to which a wireless device can be configured to perform an OCC based RACH procedure, e.g., such as in an IoT NTN and thus to assist a cellular network to effectively and efficiently schedule and perform wireless communications with the wireless device, at least in some instances.

[0147] A further exemplary embodiment can include a method, comprising performing, by a wireless device, any and / or all parts of the preceding examples.

[0148] Another exemplary embodiment can include a device, comprising an antenna; a radio coupled to the antenna and a processing element operably coupled to the radio, where the device is configured to implement any or all parts of the preceding examples.

[0149] A further exemplary set of embodiments can include a non-transitory computer accessible memory medium comprising program instructions which, when executed at a device, cause the device to implement any or all parts of any of the preceding examples.

[0150] A still further exemplary set of embodiments can include a computer program comprising instructions for performing any or all parts of any of the preceding examples.

[0151] Yet another exemplary set of embodiments can include an apparatus comprising means for performing any or all of the elements of any of the preceding examples.

[0152] Still another exemplary set of embodiments can include an apparatus comprising a processing element configured to cause a wireless device to perform any or all of the elements of any of the preceding examples.

[0153] 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.

[0154] Any of the methods described herein for operating a user equipment (UE) can be the basis of a corresponding method for operating a base station, by interpreting each message / signal X received by the UE in the downlink as message / signal X transmitted by the base station, and each message / signal Y transmitted in the uplink by the UE as a message / signal Y received by the base station.

[0155] Embodiments of the present disclosure can be realized in any of various forms. For example, in some embodiments, the present subject matter can be realized as a computer-implemented method, a computer-readable memory medium, or a computer system. In other embodiments, the present subject matter can be realized using one or more custom-designed hardware devices such as ASICs. In other embodiments, the present subject matter can be realized using one or more programmable hardware elements such as FPGAs.

[0156] In some embodiments, a non-transitory computer-readable memory medium (e.g., a non-transitory memory element) can 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 methods described herein, or, any combination of the methods described herein, or, any subset of any of the methods described herein, or, any combination of such subsets.

[0157] In some instances, a device (e.g., a UE) can be configured to include a processor (or a set of processors) and a memory medium (or memory element) , 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 methods described herein (or, any combination of the methods described herein, or, any subset of any of the methods described herein, or, any combination of such subsets) . The device can be realized in any of various forms.

[0158] Although the embodiments 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 for an orthogonal cover code (OCC) based random-access channel (RACH) procedure, comprisingtransmitting, to a network, a RACH preamble that includes at least an OCC index;receiving, from the network, a random-access response (RAR) message that includes at least an indication of the OCC index and an uplink grant; andtransmitting, to the network, on a physical uplink shared channel (PUSCH) associated with the uplink grant.2.The method of claim 1,wherein the OCC index is randomly selected.3.The method of claim 1,wherein the OCC index is indicated by the network via a downlink control information (DCI) format N1.4.The method of claim 3,wherein the DCI format N1 includes a field indicating the OCC index.5.The method of claim 4,wherein the field comprises 2 bits.6.The method of claim 4, further comprising:receiving, from the network, the DCI format N1 that includes the field indicating the OCC index.7.The method of claim 1,wherein the OCC index is based on a device identifier.8.The method of claim 7,wherein the device identifier comprises at least one of:a System Architecture Evolution (SAE) Temporary Mobile Subscriber Identity (TMSI) (S-TMSI) ; ora resume identifier (ID) .9.The method of claim 7, further comprising:calculating the OCC index as a product of the device identifier and a modulo of an OCC coding number.10.The method of claim 1,wherein the OCC index is indicated via a radio resource control (RRC) connection release message.11.The method of claim 10,wherein the OCC index is used for an early data transmission (EDT) procedure or a pre-configured uplink resource (PUR) procedure.12.The method of claim 1, further comprising:receiving, from the network, power control parameters for OCC coded RACH; andapplying, to transmission to the network using OCC coded RACH resources, the power control parameters.13.The method of claim 1,wherein the indication of the OCC index included in the RAR message is indicated via a random-access preamble identifier (RAPID) medium access control (MAC) sub-header or a MAC RAR control element.14.The method of claim 13,wherein the RAPID is calculated for a frequency identifier (f_id) as:a product of the f_id and a number of OCC indexes plus the OCC index; ora product of a number of subcarriers and the OCC index plus the f_id.15.The method of claim 14,wherein the indication is the OCC index.16.The method of claim 13,wherein the indication is the RAPID derived based on the OCC index.17.The method of claim 1,wherein an OCC index for the PUSCH is:included or indicated in the RAR message;randomly selected from a PUSCH OCC configuration; orthe OCC index from the RACH transmission when a PUSCH OCC configuration is the same as a PRACH OCC configuration.18.The method of claim 1, further comprising:not receiving a contention resolution message from the network;repeating said transmitting, receiving, and transmitting a number of times;determining, when the number of times repeating said transmitting, receiving and transmitting exceeds a threshold, a RACH failure; andattempting a non-OCC coded RACH procedure with a coverage enhancement (CE) level equivalent to a CE level used for the OCC coded RACH procedure.19.The method of claim 18, further comprising:determining failure of the non-OCC coded RACH procedure; andattempting another non-OCC coded RACH procedure with an increased CE level as compared to the CE level used for the non-OCC coded RACH procedure.20.The method of claim 1, further comprising:not receiving a contention resolution message from the network;repeating said transmitting, receiving, and transmitting a number of times;determining, when the number of times repeating said transmitting, receiving and transmitting exceeds a threshold, a RACH failure; andattempting an other OCC coded RACH procedure with an increased CE level as compared to the CE level used for the OCC coded RACH procedure.21.The method of claim 20, further comprising:determining failure of the other OCC coded RACH procedure; andattempting a non-OCC coded RACH procedure with a CE level equivalent to the CE level used for the other OCC coded RACH procedure.22.The method of claim 1, further comprising:transmitting, to the network, an indication of support for OCC based RACH procedures.23.The method of claim 22,wherein the indication includes supported OCC patterns and / or OCC types.24.The method of claim 1, further comprising:receiving, from the network, an indication of an OCC pattern associated with a RACH resource.25.The method of claim 1, further comprising:receiving, from the network, a RACH resource configuration, wherein the RACH resource configuration implicitly indicates support for OCC based RACH procedures.26.The method of claim 1, further comprising:receiving, from the network, an indication for OCC based RACH procedures in a system information block (SIB) .27.A baseband processor comprising circuitry configured to perform a method according to any of claims 1 to 26.28.An apparatus comprising:a memory; andat least one processor, wherein the at least one processor is configured to cause the apparatus to perform a method according to any of claims 1 to 26.29.A non-transitory computer readable memory medium comprising instructions executable by processing circuitry to perform a method according to any of claims 1 to 26.30.A computer program product, comprising computer instructions which, when executed by one or more processors, perform steps of the method of any of claims 1-26.

Images