Systems, methods, and devices for OCC covering npusch for IoT

Abstract

Described herein are solutions for narrowband uplink (UL) shared channel (NPUSCH) transmissions encoded with orthogonal cover code (OCC) in an internet of things (IoT) environment. An IoT user equipment (UE) can be capable of narrowband UL transmissions. A base station, satellite, or other type of network device can provide configuration information to enable the UE to address and resolve conflicts between NPUSCH transmissions encoded with OCC and other types of UL transmissions. The conflicts can include overlapping time domain resources. These and many other features and examples are described herein.

Description

SYSTEMS, METHODS, AND DEVICES FOR OCC COVERING NPUSCH FOR IOTFIELD

[0001] This disclosure relates to wireless communication networks and mobile device capabilities.BACKGROUND

[0002] Wireless communication networks and wireless communication services are becoming increasingly dynamic, complex, and ubiquitous. For example, some wireless communication networks can be developed to implement fifth generation (5G) or new radio (NR) technology, sixth generation (6G) technology, and so on. Such technology can include solutions for enabling user equipment (UE) and network devices, such as base stations, to communicate with one another.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present disclosure will be readily understood and enabled by the detailed description and accompanying figures of the drawings. Like reference numerals can designate like features and structural elements. Figures and corresponding descriptions are provided as non-limiting examples of aspects, implementations, etc., of the present disclosure, and references to "an" or “one” aspect, implementation, etc., may not necessarily refer to the same aspect, implementation, etc., and can mean at least one, one or more, etc.

[0004] Fig. 1 is a diagram of an example overview of one or more of the techniques described herein.

[0005] Fig. 2 is a diagram of an example network according to one or more implementations described herein.

[0006] Fig. 3 is a diagram of an example of handling an uplink (UL) transmission encoded using orthogonal cover code (OCC) that overlaps with a narrowband physical random access channel (NPRACH) occasion according to one or more implementations described herein.

[0007] Fig. 4 is a diagram of an example of handling a UL transmissions covered by OCC with a segment that overlaps with a timing adjustment (TA) pre-compensation gap according to one or more implementations described herein.

[0008] Fig. 5 is a diagram of an example of handling a UL transmissions covered by OCC overlaps with a UL segment and compensation gap used for timing adjustment (TA) pre-compensation according to one or more implementations described herein.

[0009] Fig. 6 is a diagram of an example process for OCC covering narrowband physical  uplink shared channel (NPUSCH) for Internet of Things (IoT) according to one or more implementations described herein.

[0010] Fig. 7 is a diagram of an example of implicit indication of an OCC sequence index for a Msg3 NPUSCH transmission according to one or more implementations described herein.

[0011] Fig. 8 is a diagram of an example of using a random access response (RAR) media access control (MAC) control element (CE) to indicate an OCC sequence index for a Msg3 NPUSCH transmission according to one or more implementations described herein.

[0012] Fig. 9 is a diagram of an example of components of a device according to one or more implementations described herein.

[0013] Fig. 10 is a diagram of example interfaces of baseband circuitry according to one or more implementations described herein.

[0014] Fig. 11 is a block diagram illustrating components, according to one or more implementations described herein, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

[0015] Fig. 12 is a diagram of an example process for OCC covering NPUSCH for Internet of Things (IoT) according to one or more implementations described herein.

[0016] Fig. 13 is a diagram of an example process for OCC covering NPUSCH for IoT according to one or more implementations described herein.

[0017] Fig. 14 is a diagram of an example process for OCC covering NPUSCH for IoT according to one or more implementations described herein.DETAILED DESCRIPTION

[0018] The following detailed description refers to the accompanying drawings. Like reference numbers in different drawings can identify the same or similar features, elements, operations, etc. Additionally, the present disclosure is not limited to the following description as other implementations can be utilized, and structural or logical changes made, without departing from the scope of the present disclosure.

[0019] Wireless communication networks can include user equipment (UE) capable of communicating with base stations and / or other network devices, such as satellites. The base stations can provide A UE with access to a core network (CN) and additional external networks, such as the Internet. Wireless communication networks can implement, or be connected to, non-terrestrial networks (NTNs) so that terrestrial network devices (e.g., UEs, base stations, etc. ) can communicate with one another via non-terrestrial devices (e.g., low earth orbit (LEO) satellites, geostationary earth orbit (GEO) satellites, high earth orbit (HEO) satellites, etc. ) . Wireless  communication networks can implement various techniques and standards that enable wireless communications to be reliable, efficient, and commensurate with any number of services being accessed.

[0020] Technologies that fulfill high-density, low-latency requirements of many devices are often required to support a growing proliferation of low-power, widely distributed Internet of Things (IoT) applications. An aspect of fifth (5th) generation and sixth generation (6G) networks of 3rd Generation Partnership Project (3GPP) is narrowband internet of things (NB-IoT) . Low power wide area (LPWA) technology known as NB-IoT is designed to help address the demands of massive machine type (mMTC) communications among devices by having low costs, long battery lives, good ranges, and high reliability. NB-IoT technology can use the licensed spectrum to communicate with other devices.

[0021] NB-IoT device can include a type of user equipment (UE) that uses NB channels to communicate with one another in an uplink (UL) direction and a downlink (DL) direction. A UE, as referred to herein, can refer to a NB-IoT device. In general, a NB channel can include a transmission channel that uses less bandwidth or fewer resources for wireless communications than regular or non-NB channels. The NB physical uplink shared channel (NPUSCH) is an example of a NB UL channel.

[0022] Enhancing the uplink capacity and throughput of NB-IoT device via the NPUSCH can be of particular value, especially within the context of NTNs. A limiting factor of uplink capacity and throughput can be the use of UL transmission gaps. A UL transmission gap can include a period of time during which a NB-IoT device (or UE) refrains from transmitting signals in order to perform one or more procedures. Examples of UL transmission gaps can include UL gaps for synchronization, gaps related to NB physical random access channel (NPRACH) occasions, UL timing adjustment gaps and segmentation for IoT-NTNs, and more. However, as the NB-IoT device must pause UL transmissions during the UL transmission gap, the overall UL capacity and throughput of NB-IoT device is diminished.

[0023] A demodulation reference signal (DMRS) can be used by an NB-IoT device to estimate channel quality and compensate for the channel impairments during the demodulation process. DMRS can also be used to perform channel estimation and tracking, which can be beneficial for beamforming, beam management, and other procedures. The NB-IoT device can support subcarrier spacing (SCS) frequencies of 15 kHz and 3.75 kHz, with bandwidths up to 180 kHz. The NB-IoT devices can implement a resource unit (RU) concept to manage resources efficiently. One RU can be a transport block size (TBS) , which can be configured based on a number of tones and slots.

[0024] UL and DL transmission can be encoded using orthogonal cover code (OCC) to mitigate interference and improve performance. OCC can be particularly effective when multiple devices are transmitting simultaneously. Orthogonal codes refers to sets of binary sequences with an inner product of zero, except when two identical sequences are multiplied together, in which case the inner product is equal to a length of the sequence. This property of orthogonality enables multiple sequences to be transmitted simultaneously without interfering with each other. In the context of OCC, orthogonal codes can be used to encode transmitted data by dividing an available frequency spectrum into multiple subchannels or subcarriers and assigning orthogonal codes to each subchannel. This can allow multiple users to transmit data simultaneously over different subchannels without causing interference. Because of the nature of encoding signals with OCC, pauses in wireless signaling, such as during UL transmission gaps can create complexity in terms of how to use OCC without an undue impact on the need and benefits of UL transmission gaps. A UL transmission gap can be referred to herein as a UL transmission segment gap. OCC covering, as referred to herein, can include ….

[0025] One or more of the techniques described herein include solutions for NPUSCH transmissions encoded with OCC in an IoT environment. A UE and / or baseband circuitry can be capable of NB communications. A base station, satellite, or another type of network access device can provide configuration information to enable the UE to schedule NB UL transmissions and resolve conflicts between NPUSCH transmissions encoded with OCC and other types of UL transmissions, such as NPRACH transmissions. The conflicts can result from overlapping time domain resources, including occasions, gaps, and segmentation. These and many other features and examples are described herein.

[0026] Fig. 1 is a diagram of an example overview 100 of one or more of the implementations described herein. As shown, overview 100 can include UE 110 capable of communicating with base station 120 and / or satellite 130. UE 110 can include a NB-IoT device and can be part of a terrestrial and / or non-terrestrial wireless communication network.

[0027] Base station 120 and / or satellite 130 can provide UE 110 with configuration information for encoding NPUSCH transmissions using OCC (at 1.1) . The configuration information can include an OCC sequence index, a subcarrier index, an OCC length, and more. The configuration information can relate to NPRACH signaling and other types of NB UL transmissions.

[0028] UE 120 can manage and resolve conflicts resulting from UL transmissions that overlap in a time domain. This can include conflicts resulting from time domain resources directly allocated for the UL transmissions and / or time domain resources implicated by UL transmissions. Examples of time domain resources implicated by a UL transmission can include  UL gaps for synchronization, gaps around UL occasions, UL timing adjustment gaps, UL transmission segmentation, guard periods associated with UL transmissions, and more. UE 120 can resolve the conflicts by dropping, modifying, and / or rescheduling the conflicting UL transmissions and / or portions thereof. Additional examples of these and many other techniques, features, and implementations are described below with reference to the figures that follow.

[0029] Fig. 2 is an example network 200 according to one or more implementations described herein. Example network 200 can include UEs 210-1, 210-2, etc. (referred to collectively as “UEs 210” and individually as “UE 210” ) , a radio access network (RAN) 220, a core network (CN) 230, application servers 240, external networks 250, and satellites 260-1, 260-2, etc. (referred to collectively as “satellites 260” and individually as “satellite 260” ) . As shown, network 200 can include a non-terrestrial network (NTN) comprising one or more satellites 260 (e.g., of a global navigation satellite system (GNSS) ) in communication with UEs 210 and RAN 220.

[0030] The systems and devices of example network 200 can operate in accordance with one or more communication standards, such as 2nd generation (2G) , 3rd generation (3G) , 4th generation (4G) (e.g., long-term evolution (LTE) ) , and / or 5th generation (5G) (e.g., new radio (NR) ) communication standards of the 3rd generation partnership project (3GPP) . Additionally, or alternatively, one or more of the systems and devices of example network 200 can operate in accordance with other communication standards and protocols discussed herein, including future versions or generations of 3GPP standards (e.g., sixth generation (6G) standards, seventh generation (7G) standards, etc. ) , institute of electrical and electronics engineers (IEEE) standards, and more.

[0031] As shown, UEs 210 can include smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more wireless communication networks) . Additionally, or alternatively, UEs 210 can include other types of mobile or non-mobile computing devices capable of wireless communications, such as personal data assistants (PDAs) , pagers, laptop computers, desktop computers, wireless handsets, etc. In some implementations, UEs 210 can include Internet of Things (IoT) devices (or IoT UEs) that can implement narrowband (NB) communications and that can comprise, for example, a network access layer designed for low-power IoT applications utilizing short-lived UE connections. Additionally, or alternatively, an IoT UE can utilize one or more types of technologies, such as machine-to-machine (M2M) communications or machine-type communications (MTC) (e.g., to exchanging data with an MTC server or other device via a public land mobile network (PLMN) ) , proximity-based service (ProSe) or device-to-device (D2D) communications, sensor networks, IoT networks, and more. Depending on the scenario, an M2M or MTC exchange of data can be a machine-initiated  exchange, and an IoT network can include interconnecting IoT UEs (which can include uniquely identifiable embedded computing devices within an Internet infrastructure) with short-lived connections. In some scenarios, IoT UEs can execute background applications (e.g., keep-alive messages, status updates, etc. ) to facilitate the connections of the IoT network.

[0032] UEs 210 can communicate and establish a connection with one or more other UEs 210 via one or more wireless channels 212, each of which can comprise a physical communications interface  / layer. The connection can include an M2M connection, MTC connection, D2D connection, SL connection, etc. The connection can involve a PC5 interface. In some implementations, UEs 210 can be configured to discover one another, negotiate wireless resources between one another, and establish connections between one another, without intervention or communications involving RAN node 222 or another type of network node. In some implementations, discovery, authentication, resource negotiation, registration, etc., can involve communications with RAN node 222 or another type of network node.

[0033] UEs 210 can communicate and establish a connection with RAN 220, which can involve one or more wireless channels 214-1 and 214-2, each of which can comprise a physical communications interface  / layer. In some implementations, a UE can be configured with dual connectivity (DC) as a multi-radio access technology (multi-RAT) or multi-radio dual connectivity (MR-DC) , where a multiple receive and transmit (Rx / Tx) capable UE can use resources provided by different network nodes (e.g., 222-1 and 222-2) that can be connected via non-ideal backhaul (e.g., where one network node provides NR access and the other network node provides either E-UTRA for LTE or NR access for 5G) . A network node can be referred to herein as a base station 222. In such a scenario, one network node can operate as a master node (MN) and the other as the secondary node (SN) . The MN and SN can be connected via a network interface, and at least the MN can be connected to the CN 230. In some implementations, a base station (as described herein) can be an example of network node 222. In some scenarios, RAN 220 can coordinate with core network 230 via interfaces 224, 226, and / or 228.

[0034] As shown, UE 210 can also, or alternatively, connect to access point (AP) 216 via connection interface 218, which can include an air interface enabling UE 210 to communicatively couple with AP 216. AP 216 can comprise a wireless local area network (WLAN) , WLAN node, WLAN termination point, etc. The connection 216 can comprise a local wireless connection, such as a connection consistent with any IEEE 702.11 protocol, and AP 216 can comprise a wireless fidelity router or other access point device. While not explicitly depicted in Fig. 2, AP 216 can be connected to another network (e.g., the Internet) without connecting to RAN 220 or CN 230.

[0035] RAN 220 can include one or more RAN nodes 222-1 and 222-2 (referred to collectively as RAN nodes 222, and individually as RAN node 222) that enable channels 214-1 and 214-2 to be established between UEs 210 and RAN 220. RAN nodes 222 can include network access points configured to provide radio baseband functions for data and / or voice connectivity between users and the network based on one or more of the communication technologies described herein (e.g., 2G, 3G, 4G, 5G, WiFi, etc. ) . As examples therefore, a RAN node can be an E-UTRAN Node B (e.g., an enhanced Node B, eNodeB, eNB, 4G base station, etc. ) , a next generation base station (e.g., a 5G base station, NR base station, next generation eNBs (gNB) , etc. ) . RAN nodes 222 can include a roadside unit (RSU) , a transmission reception point (TRxP or TRP) , and one or more other types of ground stations (e.g., terrestrial access points) . In some scenarios, RAN node 222 can be a dedicated physical device, such as a macrocell base station, and / or a low power (LP) base station for providing femtocells, picocells or the like having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells. A RAN node can generally be referred to herein as base station 222. Satellites 260 can operate as RAN nodes 222, with respect to UEs 210. As such, references herein to a base station, RAN node 222, etc., can involve implementations where the base station, RAN node 222, etc., is a terrestrial network (TN) node and also to implementations where the base station, RAN node 222, etc., is an NTN node (e.g., satellite 260) .

[0036] Some or all of RAN nodes 222, or portions thereof, can be implemented as one or more software entities running on server computers as part of a virtual network, which can be referred to as a centralized RAN (CRAN) and / or a virtual baseband unit pool (vBBUP) . In these implementations, the CRAN or vBBUP can implement a RAN function split, such as a packet data convergence protocol (PDCP) split wherein radio resource control (RRC) and PDCP layers can be operated by the CRAN / vBBUP and other Layer 2 (L2) protocol entities can be operated by individual RAN nodes 222; a media access control (MAC)  / physical (PHY) layer split wherein RRC, PDCP, radio link control (RLC) , and MAC layers can be operated by the CRAN / vBBUP and the PHY layer can be operated by individual RAN nodes 222; or a “lower PHY” split wherein RRC, PDCP, RLC, MAC layers and upper portions of the PHY layer can be operated by the CRAN / vBBUP and lower portions of the PHY layer can be operated by individual RAN nodes 222. This virtualized framework can allow freed-up processor cores of RAN nodes 222 to perform or execute other virtualized applications.

[0037] In some implementations, an individual RAN node 222 can represent individual gNB-distributed units (DUs) connected to a gNB-control unit (CU) via individual F1 or other interfaces. In such implementations, the gNB-DUs can include one or more remote radio heads or radio frequency (RF) front end modules (RFEMs) , and the gNB-CU can be operated by a  server (not shown) located in RAN 220 or by a server pool (e.g., a group of servers configured to share resources) in a similar manner as the CRAN / vBBUP. Additionally, or alternatively, one or more of RAN nodes 222 can be next generation eNBs (i. e., gNBs) that can provide evolved universal terrestrial radio access (E-UTRA) user plane and control plane protocol terminations toward UEs 210, and that can be connected to a 5G core network (5GC) 230 via an NG interface.

[0038] Any of the RAN nodes 222 can terminate an air interface protocol and can be the first point of contact for UEs 210. In some implementations, any of the RAN nodes 222 can fulfill various logical functions for the RAN 220 including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. UEs 210 can be configured to communicate using orthogonal frequency-division multiplexing (OFDM) communication signals with each other or with any of the RAN nodes 222 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, an OFDMA communication technique (e.g., for downlink communications) or a single carrier frequency-division multiple access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink (SL) communications) , although the scope of such implementations may not be limited in this regard. The OFDM signals can comprise a plurality of orthogonal subcarriers.

[0039] In some implementations, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 222 to UEs 210, and uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid (e.g., a resource grid or time-frequency resource grid) that represents the physical resource for downlink in each slot. Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. 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 comprises resource blocks, which describe the mapping of certain physical channels to resource elements (REs) . Each resource block can comprise a collection of resource elements; in the frequency domain, this can represent the smallest quantity of resources that currently can be allocated. There are several different physical downlink channels that are conveyed using such resource blocks.

[0040] Further, RAN nodes 222 can be configured to wirelessly communicate with UEs 210, and / or one another, over a licensed medium (also referred to as the “licensed spectrum” and / or the “licensed band” ) , an unlicensed shared medium (also referred to as the “unlicensed spectrum” and / or the “unlicensed band” ) , or combination thereof. A licensed spectrum can  correspond to channels or frequency bands selected, reserved, regulated, etc., for certain types of wireless activity (e.g., wireless telecommunication network activity) , whereas an unlicensed spectrum can correspond to one or more frequency bands that are not restricted for certain types of wireless activity.

[0041] The PDSCH can carry user data and higher layer signaling to UEs 210. The physical downlink control channel (PDCCH) can carry information about the transport format and resource allocations related to the PDSCH channel, among other things. The PDCCH can also inform UEs 210 about the transport format, resource allocation, and hybrid automatic repeat request (HARQ) information related to the uplink shared channel. Typically, downlink scheduling (e.g., assigning control and shared channel resource blocks to UE 210 within a cell) can be performed at any of the RAN nodes 222 based on channel quality information feedback from any of UEs 210. The downlink resource assignment information can be sent on the PDCCH used for (e.g., assigned to) each of UEs 210.

[0042] One or more of the techniques described herein can allow UE 210 to monitor UL traffic of an application or wireless link, detect an increase in UL traffic, and communicate with the network (e.g., base station 222, satellite 260, etc., ) to dynamically increase UL resources. The increase in UL resource can include a change in the number of UL slots per frame. In doing so, UE 210 can determine the UL requirements of the application, assess a current usage of UL resources, and more. For example, UE 210 can verify that DL resources are underused, before requesting an increase in UL resource. UL performance can thus be increased without a meaningful decrease in DL performance, as the increase in UL resources can be achieved by a decrease DL resources. Dynamically increasing the UL resources can enable the UE to improve UL performance commensurate with the requirements or preferences of applications that generate significant UL traffic, engage in edge compute offloading (e.g., application servers 240) , and more. Many other aspects and examples are also described herein.

[0043] The RAN nodes 222 can be configured to communicate with one another via interface 223. In implementations where the system is an LTE system, interface 223 can be an X2 interface. In NR systems, interface 223 can be an Xn interface. The X2 interface can be defined between two or more RAN nodes 222 (e.g., two or more eNBs  / gNBs or a combination thereof) that connect to evolved packet core (EPC) or CN 230, or between two eNBs connecting to an EPC.

[0044] As shown, RAN 220 can be connected (e.g., communicatively coupled) to CN 230. CN 230 can comprise a plurality of network elements 232, which are configured to offer various data and telecommunications services to customers / subscribers (e.g., users of UEs 210) who are connected to the CN 230 via the RAN 220. In some implementations, CN 230 can include an  evolved packet core (EPC) , a 5G CN (5GC) , and / or one or more additional or alternative types of CNs.

[0045] As shown, CN 230, application servers 240, and external networks 250 can be connected to one another via interfaces 234, 236, and 238, which can include IP network interfaces. Application servers 240 can include one or more server devices or network elements (e.g., virtual network functions (VNFs) offering applications that use IP bearer resources with CN 230 (e.g., universal mobile telecommunications system packet services (UMTS PS) domain, LTE PS data services, etc. ) . Application servers 240 can also, or alternatively, be configured to support one or more communication services (e.g., voice over IP (VoIP sessions, push-to-talk (PTT) sessions, group communication sessions, social networking services, etc. ) for UEs 210 via the CN 230. Similarly, external networks 250 can include one or more of a variety of networks, including the Internet, thereby providing the mobile communication network and UEs 210 of the network access to a variety of additional services, information, interconnectivity, and other network features.

[0046] Satellites 260 can communicate with UEs 210 via service link or wireless interface 262 and / or RAN 220 via feeder links or wireless interfaces 264 (depicted individually as 264-1 and 264-2) . In some implementations, satellite 260 can operate as a passive or transparent network relay node regarding communications between UE 210 and the terrestrial network (e.g., RAN 220) . In some implementations, satellite 260 can operate as an active or regenerative network node such that satellite 260 can operate as a base station to UEs 210 (e.g., as a base station of RAN 220) . In some implementations, satellites 260 can communicate with one another via a direct wireless interface (e.g., 266) or an indirect wireless interface (e.g., via RAN 220 using interfaces 264-1 and 264-2) .

[0047] Additionally, or alternatively, satellite 260 may include a GEO satellite, LEO satellite, or another type of satellite. Satellite 260 may also, or alternatively pertain to one or more satellite systems or architectures, such as a global navigation satellite system (GNSS) , global positioning system (GPS) , global navigation satellite system (GLONASS) , BeiDou navigation satellite system (BDS) , etc. In some implementations, satellites 260 may operate as bases stations (e.g., RAN nodes 222) with respect to UEs 210. As such, references herein to a base station, RAN node 222, etc., may involve implementations where the base station, RAN node 222, etc., is a terrestrial network node and implementation, where the base station, RAN node 222, etc., is a non-terrestrial network node (e.g., satellite 260) . As described herein, UE 210 and base station 222 may communicate with one another, via interface 214, to enable enhanced power saving techniques.

[0048] Fig. 3 is a diagram of an example 300 of handling uplink (UL) transmissions encoded  using orthogonal cover code (OCC) that overlaps with a narrowband physical random access channel occasion according to one or more implementations described herein. UE 210 can receive configuration information via a narrowband downlink control channel (NDCCH) from base station 222 or satellite 260. The configuration information can schedule an NPUSCH transmission. UE 210 can encode the NPUSCH using OCC, which can increase the time domain resources used for the NPUSCH transmission. The change in time domain resources can depend on whether the OCC is applied to slots (e.g., at a slot level) or to symbols (e.g., at a symbol level) . The change in time domain resources can cause the NPUSCH wit OCC to overlap or conflict with time domain resources allocated to another procedure or transmission. For example, as shown in example 300, a subframe or slot of an NPUSCH transmission with OCC can overlap in a time domain with an NPRACH occasion and / or one or more gaps incidental to the NPRACH procedure. The NPRACH occasion and gaps of example 300 is provided for simplicity. A more detailed example of NPRACH UL transmissions is provided in Fig. 7.

[0049] With respect to gaps around an NPRACH occasion, UL transmissions can have a gap of 40ms or every 256 subframe transmissions. When NPUSCH transmissions with OCC overlaps with a gap around an NPRACH occasion, the UL transmission gap can 40ms for every 256 subframe transmission. When an NPUSCH transmission encoded with OCC overlaps in a time domain with an NPRACH occasion, UE 210 can manage or resolve the conflict in one or more ways, which can depend on whether OCC is applied to slots (e.g., at a slot level) or to symbols (e.g., at a symbol level) .

[0050] Example 300 provides two alternatives to resolving conflicts between UL transmissions based on whether OCC is applied at a lost level or a symbol level. For slot level OCC (at 310) , UE 210 can resolve a conflict by dropping an entire NPUSCH transmission covered by OCC regardless of whether the overlapping portion of the NPUSCH transmission includes one subframe or multiple subframes. In another implementation, if at least one NPUSCH transmission covered by OCC overlaps with an NPRACH occasion, UE 210 can delay the entire NPUSCH transmission covered by OCC and resume the NPUSCH transmission after the NPRACH occasion is complete.

[0051] For symbol level OCC (at 320) , UE 210 can resolve a conflict by dropping an entire NPUSCH transmission covered by OCC regardless of whether one symbol or many symbols overlap with the NPRACH occasion. In another implementation, UE 210 can resolve a conflict by delay the whole NPUSCH transmission covered by OCC when at least one symbol of NPUSCH transmission covered by OCC overlaps with NPRACH occasion, and by resuming the NPUSCH after the NPRACH occasion.

[0052] Fig. 4 is a diagram of an example 400 of handling a UL transmissions covered by  OCC with a segment that overlaps with a timing adjustment (TA) pre-compensation gap according to one or more implementations described herein. The timing adjustment can be a timing advance or another type of change in the time domain. An NPUSCH transmission can include timing adjustment gaps and segmentations in IoT-NTN environments (e.g., when UE 210 is communicating information to satellite 260) . A UL segment and compensation gap can be used for TA pre-compensation. The UL segment and compensation gap can be 1 symbol, 1 slot, or 2 slots, and each NPUSCH segment can transmit for 2ms, 4ms, and so on, up to 256ms.

[0053] For slot level OCC scenarios (at 410) , when a symbol-level TA pre-compensation gap is configured and when the NPUSCH over OCC overlaps in one segment with the slot level TA pre-compensation gap, UE 210 can be configured to only drop conflicting or colliding symbols in the NPUSCH transmission. In other implementations, when a slot level TA pre-compensation gap is configured and at least one segment of an NPUSCH over OCC overlaps with the slot level TA pre-compensation gap, UE 210 can be configured to drop the entire NPUSCH transmission covered by OCC (including the colliding slot) regardless of whether the overlap involves one subframe or several subframes.

[0054] For symbol level OCC (at 420) , when a symbol level TA pre-compensation gap is configured and an NPUSCH over OCC in one segment overlaps with the symbol level TA pre-compensation gap, UE 210 can be configured to drop all of the NPUSCH symbols covered by OCC regardless of whether the overlap involves only one symbol or several symbols. In some implementations, when a slot level TA pre-compensation gap is configured and one segment overlaps with the slot level TA pre-compensation gap, UE 210 can be configured to drop all of the colliding or conflicting slots of the NPUSCH transmission.

[0055] Fig. 5 is a diagram of an example 500 of handling a UL transmissions covered by OCC overlaps with a UL segment and compensation gap used for timing adjustment (TA) pre-compensation according to one or more implementations described herein. An NPRACH transmission can include UL timing adjustment gaps and segmentation for IoT-NTN. The UL segment and compensation gap can used for TA pre-compensation, which can be 1 symbol, 1 slot, or 2 slots. An NPRACH repetition duration for the NPRACH transmission can be 2 repetitions, 4 repetitions, and so on, up to 64 repetitions. For NPRACH transmissions with symbol level OCC applied to symbol groups, overlapping time domain resources (e.g., a symbol or a symbol group) can result in an entire symbol group of the NPRACH transmission being dropped regardless of how many symbols overlap. In other implementations, UE 210 can drop the entire PRACH transmission (e.g., all symbol groups of the NPRACH transmission are dropped) when a symbol or a symbol group of the NPRACH transmission overlaps. An example of a PRACH UL transmission with symbol groups is described below with reference to Fig. 7.

[0056] Fig. 6 is a diagram of an example process for OCC covering NPUSCH for IoT according to one or more implementations described herein. As shown, process 600 can include UE 210, base station 222, and satellite 260. Process 600 can be performed by UE 210 and base station 222, by UE 210 and satellite 260, and / or UE 210 and a combination of base station 222 and satellite 260. A cell, as referred to herein, can include base station 222, satellite 260, or another type of radio access network device. In some implementations, operations performed by UE 210 can instead by performed by one or more components of UE 210, such as baseband circuitry, which can include or be part of an IoT device capable of narrowband communications. For simplicity, process 600 is described below as involving UE 210 and satellite 260.

[0057] In some implementations, some or all of process 600 can be performed by one or more other systems or devices, including one or more of the devices of Fig. 2. Additionally, process 600 can include one or more fewer, additional, differently ordered and / or arranged operations than those shown in Fig. 6. In some implementations, some or all of the operations of process 600 can be performed independently, successively, simultaneously, etc., of one or more of the other operations of process 600. As such, the techniques described herein are not limited to the number, sequence, arrangement, timing, etc., of the operations or processes depicted in Fig. 6.

[0058] As shown, process 600 can include satellite 260 can communicate configuration information to UE 210 (block 610) . The configuration information can include instructions and information for enabling UE 210 to engage in OCC-based NPUSCH communications. For example, the configuration information can cause or enable UE to use OCC to encode data sent to satellite 260 via an NPUSCH. Satellite 260 can communicate the configuration information as system information, which can include a system information block (SIB) , such as SIB1, SIB2, or one or more additional or other SIBs. In some implementations, the SIB can cause or enable UE 210 to determine the configuration information (e.g., locate the configuration information in one or more other SIBs) based on an indication, instructions, or configuration information in one SIB.

[0059] The configuration information can include an indication of a dedicated NPRACH resource for encoding a message 3 (Msg3) NPUSCH transmission using OCC, which can be referred to herein as an OCC-based Msg3 NPUSCH transmission. For example, configuration information can include an RRC parameter (e.g., a nprach-NumOCC-StartSubcarriers parameter) that indicates NPRACH subcarriers that are dedicated or reserved for OCC-based Msg3 NPUSCH transmissions. In some implementations, UE 210 can report (to satellite 260) a capability to use OCC-based Msg3 NPUSCH transmissions by selecting the reserved or dedicated NPRACH subcarrier.

[0060] The configuration information can include an indication of an OCC length from a set of OCC lengths (e.g., {2, 4} ) and / or an OCC code to be applied to a NB UL transmission. Examples of the OCC code can include a Walsh code, a discrete Fourier transform (DFT) , or another type of OCC code. In some implementations, UE 210 can select an OCC code from a set of OCC codes provided in the configuration information. The configuration information can include an indication of an of an OCC sequence and / or an OCC sequence index. For example, for an OCC length of 2 and a Walsh OCC code, the OCC sequence index zero (0) can have [1 1] , whereas the OCC sequence index one (1) can have [1 -1] .

[0061] Process 600 can include satellite 260 sending UE 210 instructions and / or information to enable or disable OCC-based Msg3 NPUSCH transmissions (block 620) . This can be done explicitly or implicitly. For example, satellite 260 can use RRC signaling, a media access control (MAC) control element (CE) , and / or downlink control information (DCI) (block 625) . The RRC signaling can include an RRC parameter to introduce or enable OCC-based Msg3 NPUSCH transmissions, and the RRC parameter can be included in, or referenced by, an SIB (e.g., SIB1, SIB2, another SIB, or a combination thereof) . OCC-based Msg3 NPUSCH transmissions can be implicitly enabled and / or disabled based on enabling or disabling an NPRACH resource configuration that is dedicated or reserved for OCC-based Msg3 NPUSCH transmissions.

[0062] As shown, process 600 can include UE 210 determining an OCC sequence index (block 630) . UE 210 can do so based on the configuration information from satellite 260. In some implementations, UE 210 can be configured to implicitly derive or determine an OCC sequence index. This can include defining or determining an association between an OCC sequence index and PRACH start subcarrier index.

[0063] In some implementations, an OCC sequence index can be equal to (start subcarrier index) mod (OCC length) . For example, when the OCC code comprises a Walsh code length of 2, an OCC sequence index #0 can be [1 1] . Similarly, when the OCC code comprises a Walsh code length of 2, an OCC sequence index of one #1 can be [1 1] . Additionally, or alternatively, when 12 subcarriers are configured for a PRACH transmission, subcarrier index #0, …subcarrier index#11. An OCC sequence index can be determined as, or based on, (start subcarrier index) mod (2) , so subcarrier index #3 can be associated with OCC sequencing index #1. As such, when UE 210 transits NPRACH information using subcarrier index #3, in response to detecting a corresponding random access response (RAR) , UE 210 can use OCC sequence index #1 to cover the Msg3 NPUSCH transmission.

[0064] In some implementations, an OCC sequence index can be determined by dividing PRACH subcarriers into several subgroups according to OCC length and subcarriers in different subgroups can be associated with different OCC sequence indexes. For example, 12 subcarrier  can be divided into 2 subgroups with an OCC length of 2. The subcarriers in the first subgroup can be associated with OCC sequence index #0, and the subcarriers in the second subgroup can be associate with OCC sequence index #1.

[0065] When satellite 260 detects two or more UEs 210 using the same OCC sequence index, satellite 260 can determine scheduling to avoid an OCC sequence index collision. For example, satellite 260 can schedule colliding or conflicting Msg3 NPUSCH transmissions in different frequency locations. This can be achieved via RRC signaling, a MAC CE, or DCI sent to one UE 210 or both UEs 210.

[0066] Process 600 can also include UE 210 determining an OCC code for encoding NPUSCH transmissions and applying the OCC to NPUSCH data (block 640) . Process 600 can include UE 210 determining and resolving time domain conflicts (650) . For example, encoding NPUSCH data can result in a conflict or overlap in a time domain between NB UL transmissions. This can include conflicts resulting from time domain resources directly allocated for the UL transmissions and / or time domain resources implicated by UL transmissions. Examples of time domain resources implicated by a UL transmission can include UL gaps for synchronization, gaps around UL occasions, UL timing adjustment gaps, UL transmission segmentation, guard periods associated with UL transmissions, and more. UE 120 can resolve the conflicts by dropping, modifying, and / or rescheduling the conflicting UL transmissions and / or portions thereof. Examples of resolving time domain conflicts between NB UL transmissions are described above with reference to Figs. 3-5.

[0067] Process 600 can include UE 210 generating NB UL transmissions to satellite 260 (block 660) . The NB UL transmissions can include an NPUSCH transmission, an NPRACH transmission, or another type of NB UL transmission. The NB UL transmissions can be modified based on the manner or technique used to resolve conflicts between the NB UL transmissions. In some implementations, an NB UL transmission can include an OCC-BASED Msg3 NPUSCH transmission, which can be a Msg3 transmission of a random access channel (RACH) procedure involving NB transmissions. One or more of the examples, processes, or procedures described herein can also, or alternatively be part of process 600.

[0068] Fig. 7 is a diagram of an example 700 of an NPRACH UL transmission according to one or more implementations described herein. As shown, an NPRACH UL transmission can include 4 symbol groups transmitted consecutively using different frequency carriers. Each symbol group can include a cyclic prefix followed by 5 symbols for data transmission. UE 210 can be configured to randomly select a starting subcarrier index from start subcarrier indices provided by an RRC parameter (e.g., a nprach-NumCBRA-StartSubcarriers parameter) . The techniques described herein can include a dedicated NPRACH resource for OCC-based Msg3  NPUSCH transmission. UE 210 can receive configuration information indicating the dedicated responses via an RRC parameter (e.g., a nprach-NumOCC-StartSubcarriers parameter) that indicates NPRACH subcarriers that are dedicated or reserved for OCC-based Msg3 NPUSCH transmissions. In some implementations, UE 210 can report (to satellite 260) a capability to use OCC-based Msg3 NPUSCH transmissions by selecting the reserved or dedicated NPRACH subcarrier. An OCC length, OCC code, etc., can also be provided by configuration information or derived implicitly based on a combination of an OCC sequence index and PRACH start subcarrier index or by dividing an available frequency spectrum into multiple subchannels or subcarriers and assigning orthogonal codes to each subchannel.

[0069] Fig. 8 is a diagram of an example 800 of using a random access response (RAR) media access control (MAC) control element (CE) to indicate an OCC sequence index for a Msg3 NPUSCH transmission according to one or more implementations described herein. As shown, example 800 can include a data structure comprising six rows of 8-bits. Each row can be referred to as an octet (e.g., octet 1, octet 2, and so on) . The data structure can include one or more reserved (R) bits, TA command bits, UL grant bits, and temporary cell radio network temporary identifier (C-RNTI) bits that function as a unique identifier used in cellular networks. One or more of the techniques described herein can include using one or more of the reserved bits for OCC covering NPUSCH for IoT. For example, satellite 260 can provide UE 210 with a RAR MAC CE to indicate an OCC sequence index in one or more reserved bits (e.g., of octet 4) . In some implementations, 1 reserved bit can be used to indicate the OCC sequence index associated with an OCC length of 2. In some implementations, 2 reserved bits can be used to indicate an OCC sequence index associated with an OCC length of 4. In some implementations, OCC length can changed dynamically and the number of reserved bits used to indicate the OCC sequence index can change dynamically as well.

[0070] Fig. 9 is a diagram of an example of components of a device according to one or more implementations described herein. In some implementations, device 900 can include application circuitry 902, baseband circuitry 904, RF circuitry 906, front-end module (FEM) circuitry 908, one or more antennas 910, and power management circuitry (PMC) 912 coupled together at least as shown. In some implementations, device 900 can include fewer elements (e.g., a RAN node may not utilize application circuitry 902 and can instead include a processor / controller to process data received from a core network. In some implementations, device 900 can include additional elements such as, for example, memory / storage, display, camera, sensor (including one or more temperature sensors, such as a single temperature sensor, a plurality of temperature sensors at different locations in device 900, etc. ) , or input / output (I / O) interface. In other implementations, the components described below can be included in more  than one device (e.g., said circuitries can be separately included in more than one device for cloud-RAN (C-RAN) implementations) .

[0071] Application circuitry 902 can include one or more application processors. For example, application circuitry 902 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor (s) can include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc. ) . The processors can be coupled with or can include memory / storage and can be configured to execute instructions stored in the memory / storage to enable various applications or operating systems to run on device 900. In some implementations, processors of application circuitry 902 can process data packets received from a core network.

[0072] Baseband circuitry 904 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. Baseband circuitry 904 can include one or more baseband processors or control logic to process baseband signals received from a receive signal path of RF circuitry 906 and to generate baseband signals for a transmit signal path of RF circuitry 906. Baseband circuity 904 can interface with application circuitry 902 for generation and processing of the baseband signals and for controlling operations of RF circuitry 906. For example, in some implementations, baseband circuitry 904 can include a 3G baseband processor 904A, a 4G baseband processor 904B, a 5G baseband processor 904C, or other baseband processor (s) 904D for other existing generations, generations in development or to be developed in the future (e.g., 5G, 6G, 7G, etc. ) . Baseband circuitry 904 (e.g., one or more of baseband processors 904A-D) can handle various radio control functions that enable communication with one or more radio networks via RF circuitry 906. In other implementations, some or all of the functionality of baseband processors 904A-D can be included in modules stored in memory 904G and executed via a central processing unit (CPU) 904E. The radio control functions can include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some implementations, modulation / demodulation circuitry of baseband circuitry 904 can include Fast-Fourier Transform (FFT) , precoding, or constellation mapping / de-mapping functionality. In some implementations, encoding / decoding circuitry of baseband circuitry 904 can include convolution, tail-biting convolution, turbo, Viterbi, or low-density parity check (LDPC) encoder / decoder functionality. Implementations of modulation / demodulation and encoder / decoder functionality are not limited to these examples and can include other suitable functionality in other implementations.

[0073] In some implementations, memory 904G can receive and / or store information and instructions for NPUSCH transmissions encoded with OCC in an IoT environment. UE 210 and / or baseband circuitry 904 can be capable of NB UL transmissions. Base station 222, satellite  260, or another type of network device, can provide configuration information to enable UE 210 to schedule NB UL transmissions and resolve conflicts between NPUSCH transmissions encoded with OCC and other types of UL transmissions, such as NPRACH transmissions. The conflicts can result from overlapping time domain resources, including occasions, gaps, and segmentation associated with the UL transmissions. These and many other features and examples are described herein.

[0074] In some implementations, baseband circuitry 904 can include one or more audio digital signal processor (s) (DSP) 904F. Audio DSP 904F can include elements for compression / decompression and echo cancellation and can include other suitable processing elements in other implementations. Components of baseband circuitry 904 can be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some implementations. In some implementations, some or all of the constituent components of baseband circuitry 904 and application circuitry 902 can be implemented together such as, for example, on a system on a chip (SOC) .

[0075] In some implementations, baseband circuitry 904 can provide for communication compatible with one or more radio technologies. For example, in some implementations, baseband circuitry 904 can support communication with a NG-RAN, an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN) , a wireless local area network (WLAN) , a wireless personal area network (WPAN) , etc. Implementations in which baseband circuitry 904 is configured to support radio communications of more than one wireless protocol can be referred to as multi-mode baseband circuitry.

[0076] RF circuitry 906 can enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various implementations, RF circuitry 906 can include switches, filters, amplifiers, etc., to facilitate the communication with the wireless network. RF circuitry 906 can include a receive signal path which can include circuitry to down-convert RF signals received from FEM circuitry 908 and provide baseband signals to baseband circuitry 904. RF circuitry 906 can also include a transmit signal path which can include circuitry to up-convert baseband signals provided by baseband circuitry 904 and provide RF output signals to FEM circuitry 908 for transmission.

[0077] In some implementations, the receive signal path of RF circuitry 906 can include mixer circuitry 906A, amplifier circuitry 906B and filter circuitry 906C. In some implementations, the transmit signal path of RF circuitry 906 can include filter circuitry 906C and mixer circuitry 906A. RF circuitry 906 can also include synthesizer circuitry 906D for synthesizing a frequency for use by mixer circuitry 906A of the receive signal path and the  transmit signal path. In some implementations, mixer circuitry 906A of the receive signal path can be configured to down-convert RF signals received from FEM circuitry 908 based on the synthesized frequency provided by synthesizer circuitry 906D. Amplifier circuitry 906B can be configured to amplify the down-converted signals and filter circuitry 906C can be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals can be provided to baseband circuitry 904 for further processing. In some implementations, the output baseband signals can be zero-frequency baseband signals, although this may not be a requirement. In some implementations, mixer circuitry 906A of the receive signal path can comprise passive mixers, although the scope of the implementations is not limited in this respect.

[0078] In some implementations, mixer circuitry 906A of the transmit signal path can be configured to up-convert input baseband signals based on the synthesized frequency provided by synthesizer circuitry 906D to generate RF output signals for FEM circuitry 908. The baseband signals can be provided by baseband circuitry 904 and can be filtered by filter circuitry 906C. In some implementations, mixer circuitry 906A of the receive signal path and mixer circuitry 906A of the transmit signal path can include two or more mixers and can be arranged for quadrature down conversion and up conversion, respectively. In some implementations, mixer circuitry 906A of the receive signal path and mixer circuitry 906A of the transmit signal path can include two or more mixers and can be arranged for image rejection. In some implementations, mixer circuitry 906A of the receive signal path and mixer circuitry 906A can be arranged for direct down conversion and direct up conversion, respectively. In some implementations, mixer circuitry 906 of the receive signal path and mixer circuitry 906A of the transmit signal path can be configured for super-heterodyne operation.

[0079] In some implementations, the output baseband signals, and the input baseband signals can be analog baseband signals, although the scope of the implementations is not limited in this respect. In some alternate implementations, the output baseband signals, and the input baseband signals can be digital baseband signals. In these alternate implementations, RF circuitry 906 can include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and baseband circuitry 904 can include a digital baseband interface to communicate with RF circuitry 906.

[0080] In some dual-mode implementations, a separate radio integrated circuitry can be provided for processing signals for each spectrum, although the scope of the implementations is not limited in this respect. In some implementations, synthesizer circuitry 906D can be a fractional-N synthesizer or a fractional N / N+1 synthesizer, although the scope of the implementations is not limited in this respect as other types of frequency synthesizers can be  suitable. For example, synthesizer circuitry 906D can be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

[0081] Synthesizer circuitry 906D can be configured to synthesize an output frequency for use by mixer circuitry 906A of RF circuitry 906 based on a frequency input and a divider control input. In some implementations, synthesizer circuitry 906D can be a fractional N / N+1 synthesizer. In some implementations, frequency input can be provided by a voltage-controlled oscillator (VCO) . Divider control input can be provided by either baseband circuitry 904 or the applications circuitry 902 depending on the desired output frequency. In some implementations, a divider control input (e.g., N) can be determined from a look-up table based on a channel indicated by the applications circuitry 902.

[0082] Synthesizer circuitry 906D of RF circuitry 906 can include a divider, a delay-locked loop (DLL) , a multiplexer, and a phase accumulator. In some implementations, the divider can be a dual modulus divider (DMD) , and the phase accumulator can be a digital phase accumulator (DPA) . In some implementations, the DMD can be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example implementations, the DLL can include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these implementations, the delay elements can be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0083] In some implementations, synthesizer circuitry 906D can be configured to generate a carrier frequency as the output frequency, while in other implementations, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some implementations, the output frequency can be a LO frequency (fLO) . In some implementations, RF circuitry 906 can include an in-phase / quadrature (I / Q)  / polar converter.

[0084] FEM circuitry 908 can include a receive signal path which can include circuitry configured to operate on RF signals received from one or more antennas 910, amplify the received signals and provide the amplified versions of the received signals to RF circuitry 906 for further processing. FEM circuitry 908 can also include a transmit signal path which can include circuitry configured to amplify signals for transmission provided by RF circuitry 906 for transmission by one or more of the one or more antennas 910. In various implementations, the amplification through the transmit or receive signal paths can be done solely in RF circuitry 906, solely in FEM circuitry 908, or in both RF circuitry 906 and FEM circuitry 908.

[0085] In some implementations, FEM circuitry 908 can include a transmit / receive switch to switch between transmit mode and receive mode operation. FEM circuitry 908 can include a receive signal path and a transmit signal path. The receive signal path of FEM circuitry 908 can include a low noise amplifier to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to RF circuitry 906) . The transmit signal path of FEM circuitry 908 can include a power amplifier to amplify input RF signals (e.g., provided by RF circuitry 906) , and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of one or more antennas 910) .

[0086] In some implementations, PMC 912 can manage power provided to baseband circuitry 904. In particular, PMC 912 can control power-source selection, voltage scaling, battery charging, or direct current (DC) to DC (DC-to-DC) conversion. PMC 912 can often be included when device 900 is capable of being powered by a battery, for example, when device 900 is included in a UE. PMC 912 can increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

[0087] While Fig. 9 shows PMC 912 coupled only with baseband circuitry 904. However, in other implementations, PMC 912 can be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 902, RF circuitry 906, or FEM circuitry 908.

[0088] In some implementations, PMC 912 can control, or otherwise be part of, various power saving mechanisms of device 900. For example, if device 900 is in an RRC_Connected state, where device 900 is still connected to the RAN node as device 900 expects to receive traffic shortly, then device 900 can enter a state known as discontinuous reception mode (DRX) after a period of inactivity. During this state, device 900 can power down for brief intervals of time and thus save power.

[0089] If there is no data traffic activity for an extended period of time, then device 900 can transition off to an RRC_Idle state, where device 900 disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. Device 900 can go into a very low power state and device 900 can perform paging where again device 900 periodically can wake up to listen to the network and then power down again. Device 900 may not receive data in this state; in order to receive data, device 900 can transition back to RRC_Connected state.

[0090] An additional power saving mode can allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours) . During this time, the device 900 can be unreachable to the network and can power down completely. Any data sent during this time can incur a large delay and device 900 can assume the delay is acceptable.

[0091] Processors of application circuitry 902 and processors of baseband circuitry 904 can be used to execute elements of one or more instances of a protocol stack. For example, processors of baseband circuitry 904, alone or in combination, can be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of baseband circuitry 904 can utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers) . As referred to herein, Layer 3 can comprise a radio resource control layer. As referred to herein, Layer 2 can comprise a medium access control layer, a radio link control layer, and a packet data convergence protocol layer, described in further detail below. As referred to herein, Layer 1 can comprise a physical layer of a UE / RAN node.

[0092] Fig. 10 is a diagram of example interfaces 1000 of baseband circuitry according to one or more implementations described herein. One or more components or features of example interfaces 1000 can correspond to one or more components or features described above or elsewhere. Baseband circuitry 1004 can comprise processors 1004A, 1004B, 1004C, 1004D, and 1004E and a memory 1004G utilized by said processors. Each of processors 1004A, 1004B, 1004C, 1004D, and 1004E can include a memory interface, 1006A, 1006B, 1006C, 1006D, and 1006E, respectively, to send / receive data to / from memory 1004G. Baseband circuitry can be a component of a UE and / or another type of device or system capable of transmitting and / or receiving wireless signals.

[0093] Baseband circuitry 1004 can further include one or more interfaces to communicatively couple to other circuitries / devices, such as memory interface 1012 (e.g., an interface to send / receive data to / from memory external to baseband circuitry 1004) , an application circuitry interface 1014 (e.g., an interface to send / receive data to / from the application circuitry as described herein) , an RF circuitry interface 1016, a wireless hardware connectivity interface 1018 (e.g., an interface to send / receive data to / from near field communication components,  components (e.g.,  Low Energy) ,  components, and other communication components) , and a power management interface 1020 (e.g., an interface to send / receive power or control signals to / from a PMC) .

[0094] Fig. 11 is a block diagram illustrating components, according to some example implementations, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, Fig. 11 shows a diagrammatic representation of hardware resources 1100 including one or more processors 1110 (or processor cores) , one or more memory / storage devices 1120, and one or more communication resources 1130, each of which can be communicatively coupled via a bus 1140. For implementations  where node virtualization or network function virtualization is utilized, a hypervisor can be executed to provide an execution environment for one or more network slices / sub-slices to utilize hardware resources 1100. Hardware resources 1100 can interact with hypervisor 1102. For example, hypervisor 1102 can schedule or otherwise manage hardware resource 1100.

[0095] Processors 1110 (e.g., a central processing unit (CPU) , a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU) , a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC) , a radio-frequency integrated circuit (RFIC) , another processor, or any suitable combination thereof) can include, for example, a processor 1112 and a processor 1114.

[0096] Memory / storage devices 1120 can include main memory, disk storage, or any suitable combination thereof. Memory / storage devices 1120 can include, but are not limited to any type of volatile or non-volatile memory such as dynamic random-access memory (DRAM) , static random-access memory (SRAM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , flash memory, solid-state storage, etc.

[0097] In some implementations, memory / storage devices 1120 receive and / or store information and instructions 1155 for NPUSCH transmissions encoded with OCC in an IoT environment. UE 210 and / or baseband circuitry 904 can be capable of NB UL transmissions. Base station 222, satellite 260, or another type of network device, can provide configuration information to enable UE 210 to schedule NB UL transmissions and resolve conflicts between NPUSCH transmissions encoded with OCC and other types of UL transmissions, such as NPRACH transmissions. The conflicts can result from overlapping time domain resources, including occasions, gaps, and segmentation associated with the UL transmissions. These and many other features and examples are described herein.

[0098] Communication resources 1130 can include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 1104 or one or more databases 1106 via a network 1108. For example, communication resources 1130 can include wired communication components (e.g., for coupling via a universal serial bus) , cellular communication components, near field communication components,  components (e.g.,  Low Energy) ,  components, and other communication components.

[0099] Instructions 1150A, 1150B, 1150C, 1150D, and / or 1150E can comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of processors 1110 to perform any one or more of the methodologies discussed herein. Instructions  1150 can reside, completely or partially, within at least one of processors 1110 (e.g., within a cache memory) , memory / storage devices 1120, or any suitable combination thereof. Furthermore, any portion of instructions 1150A-E can be transferred to hardware resources 1100 from any combination of peripheral devices 1104 or databases 1106. Accordingly, memory of processors 1110, memory / storage devices 1120, peripheral devices 1104, and databases 1106 are examples of computer-readable and machine-readable media.

[0100] Fig. 12 is a diagram of an example process 1200 for OCC covering NPUSCH for IoT according to one or more implementations described herein. As shown, process 1200 can be implemented by UE 210 and / or baseband circuitry 904, which can include or be part of an IoT device capable of narrowband communications. In some implementations, some or all of process 1200 can be performed by one or more other systems or devices, including one or more of the devices of Fig. 2. Additionally, process 1200 can include one or more fewer, additional, differently ordered and / or arranged operations than those shown in Fig. 12. In some implementations, some or all of the operations of process 1200 can be performed independently, successively, simultaneously, etc., of one or more of the other operations of process 1200. As such, the techniques described herein are not limited to the number, sequence, arrangement, timing, etc., of the operations or processes depicted in Fig. 12.

[0101] As shown, process 1200 can include determining that a scheduled narrowband physical uplink shared channel (NPUSCH) transmission encoded with orthogonal cover code (OCC) overlaps in a time domain with at least one of a narrowband physical random access channel (NPRACH) occasion or an uplink timing adjustment gap (block 1210) . Process 1200 can include modifying the scheduled NPUSCH transmission based on the determined overlap (block 1220) . One or more of the examples described herein can also, or alternatively, be part of process 1200.

[0102] Fig. 13 is a diagram of an example process 1300 for OCC covering NPUSCH for IoT according to one or more implementations described herein. As shown, process 1300 can be implemented by UE 210 and / or baseband circuitry 904, which can include or be part of an IoT device capable of narrowband communications. In some implementations, some or all of process 1300 can be performed by one or more other systems or devices, including one or more of the devices of Fig. 2. Additionally, process 1300 can include one or more fewer, additional, differently ordered and / or arranged operations than those shown in Fig. 13. In some implementations, some or all of the operations of process 1300 can be performed independently, successively, simultaneously, etc., of one or more of the other operations of process 1300. As such, the techniques described herein are not limited to the number, sequence, arrangement, timing, etc., of the operations or processes depicted in Fig. 13.

[0103] As shown, process 1300 can include determining time domain resources associated with a narrowband physical random access channel (NPRACH) occasion (block 1310) . Process 1300 can include determining NPRACH transmission encoded with orthogonal cover code (OCC) overlaps in a time domain with an uplink timing adjustment gap (block 1320) . Process 1300 can include modifying a NPRACH transmission based on the NPRACH transmission overlapping with in the time domain with the uplink timing adjustment gap (block 1330) . One or more of the examples described herein can also, or alternatively, be part of process 1300.

[0104] Fig. 14 is a diagram of an example process 1400 for OCC covering NPUSCH for IoT according to one or more implementations described herein. As shown, process 1400 can be implemented by base station 222, satellite 260, or another type of network access device. In some implementations, some or all of process 1400 can be performed by one or more other systems or devices, including one or more of the devices of Fig. 2. Additionally, process 1400 can include one or more fewer, additional, differently ordered and / or arranged operations than those shown in Fig. 14. In some implementations, some or all of the operations of process 1400 can be performed independently, successively, simultaneously, etc., of one or more of the other operations of process 1400. As such, the techniques described herein are not limited to the number, sequence, arrangement, timing, etc., of the operations or processes depicted in Fig. 14.

[0105] As shown, process 1400 can include communicating, to a narrowband internet-of-things (NB-IoT) user equipment (UE) , time domain resources associated with a narrowband physical uplink shared channel (NPUSCH) transmission (block 1410) . Process 1400 can include communicating, to the NB-IoT UE, time domain resources associated with a narrowband physical random access channel (NPRACH) occasion (block 1420) . Process 1400 can include communicating, to the NB-IoT UE, configuration information to enable the UE to: encode NPUSCH transmissions with orthogonal cover code (OCC) and modify the encoded NPUSCH transmission when the encoded NPUSCH transmission overlaps with the time domain resources associated with the NPRACH occasion (block 1430) . One or more of the examples described herein can also, or alternatively, be part of process 1400.

[0106] Examples herein can include subject matter such as a method, means for performing acts or blocks of the method, at least one machine-readable medium including executable instructions that, when performed by a machine (e.g., a processor (e.g., processor, etc. ) with memory, an application-specific integrated circuit (ASIC) , a field programmable gate array (FPGA) , or the like) cause the machine to perform acts of the method or of an apparatus or system for concurrent communication using multiple communication technologies according to implementations and examples described.

[0107] In example 1, which can also include one or more of the examples described herein,  baseband circuitry can comprise: one or more processors configured to: determine that a scheduled narrowband physical uplink shared channel (NPUSCH) transmission encoded with orthogonal cover code (OCC) overlaps in a time domain with at least one of a narrowband physical random access channel (NPRACH) occasion or an uplink timing adjustment gap; and modify the scheduled NPUSCH transmission based on the determined overlap.

[0108] In example 2, which can also include one or more of the examples described herein, the scheduled NPUSCH transmission overlaps with the time domain with the NPRACH occasion based on at least one of: at least one symbol allocated to the NPUSCH transmission, at least one slot allocated to the NPUSCH transmission, at least one subframe allocated to a NPUSCH transmission or repetition, or a combination thereof.

[0109] In example 3, which can also include one or more of the examples described herein, the scheduled NPUSCH transmission overlaps with the uplink timing adjustment gap based on at least one of: a timing adjustment (TA) pre-compensation gap associated with the NPUSCH transmission, an uplink segment associated with the NPUSCH transmission, or a combination thereof.

[0110] In example 4, which can also include one or more of the examples described herein, slot level OCC is applied to the NPUSCH transmission, and the scheduled NPUSCH transmission is modified by dropping the scheduled NPUSCH transmission when at least one subframe of the scheduled NPUSCH transmission overlaps with the time domain resources associated with the NPRACH occasion.

[0111] In example 5, which can also include one or more of the examples described herein, slot level OCC is applied to the NPUSCH transmission, and the scheduled NPUSCH transmission is modified by delaying transmission of the scheduled NPUSCH transmission until after the time domain resources associated with the NPRACH occasion.

[0112] In example 6, which can also include one or more of the examples described herein, symbol level OCC is applied to the NPUSCH transmission, and the scheduled NPUSCH transmission is modified by dropping the scheduled NPUSCH transmission when at least one symbol of the scheduled NPUSCH transmission overlaps with the time domain resources associated with the NPRACH occasion.

[0113] In example 7, which can also include one or more of the examples described herein, symbol level OCC is applied to the NPUSCH transmission, and the scheduled NPUSCH transmission is modified by delaying the scheduled NPUSCH transmission until after the time domain resources associated with the NPRACH occasion.

[0114] In example 8, which can also include one or more of the examples described herein, slot level OCC is applied to the NPUSCH transmission, and when a symbol level timing  adjustment (TA) pre-configured gap is configured and a segment of the scheduled NPUSCH transmission overlaps with a compensation gap, the scheduled NPUSCH transmission is modified by dropping one colliding symbol of the scheduled NPUSCH transmission.

[0115] In example 9, which can also include one or more of the examples described herein, slot level OCC is applied to the NPUSCH transmission, and when a slot level timing adjustment (TA) pre-configured gap is configured and a segment of the scheduled NPUSCH transmission overlaps with a compensation gap, the scheduled NPUSCH transmission is modified by dropping the scheduled NPUSCH transmission.

[0116] In example 10, which can also include one or more of the examples described herein, symbol level OCC is applied to the NPUSCH transmission, and when a symbol level timing adjustment (TA) pre-configured gap is configured and a segment of the scheduled NPUSCH transmission overlaps with a compensation gap, the scheduled NPUSCH transmission is modified by dropping the scheduled NPUSCH transmission.

[0117] In example 11, which can also include one or more of the examples described herein, symbol level OCC is applied to the NPUSCH transmission, and when a slot level timing adjustment (TA) pre-configured gap is configured and a segment of the scheduled NPUSCH transmission overlaps with a compensation gap, the scheduled NPUSCH transmission is modified by dropping at least one colliding slot of the scheduled NPUSCH transmission.

[0118] In example 12, which can also include one or more of the examples described herein, baseband circuitry can comprise: one or more processors configured to: one or more processors configured to: determine time domain resources associated with a narrowband physical random access channel (NPRACH) occasion; determine NPRACH transmission encoded with orthogonal cover code (OCC) overlaps in a time domain with an uplink timing adjustment gap; and modify a NPRACH transmission based on the NPRACH transmission overlapping with in the time domain with the uplink timing adjustment gap.

[0119] In example 13, which can also include one or more of the examples described herein, the NPRACH transmission overlaps with the uplink timing adjustment gap based on at least one of:a timing adjustment (TA) pre-compensation gap associated with the NPRACH transmission, an uplink segment associated with a NPRACH uplink transmission or repetition, or a combination thereof.

[0120] In example 14, which can also include one or more of the examples described herein, a symbol level OCC is applied to a symbol group of the NPRACH occasion, when a timing adjustment (TA) pre-configured gap overlaps with the symbol group of the NPRACH occasion, the symbol group is dropped.

[0121] In example 15, which can also include one or more of the examples described herein,  a symbol group level OCC is applied to the NPRACH occasion, and when a timing adjustment (TA) pre-configured gap overlaps with a symbol group of an NPRACH transmission of the NPRACH, the NPRACH transmission is dropped.

[0122] In example 16, which can also include one or more of the examples described herein, the one or more processors are configured to: receive configuration information comprising dedicated NPRACH resources for an OCC-based Msg3 NPUSCH transmission indicated by a system information block (SIB) . determine NPRACH frequency domain resources for OCC-based Msg3 NPUSCH transmission and determine an OCC sequence index.

[0123] In example 17, which can also include one or more of the examples described herein, the one or more processors are configured to: receive at least one of: an OCC length from an OCC length set, an OCC code to be applied to a narrowband uplink transmission, an OCC sequence index associated with an OCC sequence, or a combination thereof.

[0124] In example 18, which can also include one or more of the examples described herein, the OCC sequence index is determined implicitly.

[0125] In example 19, which can also include one or more of the examples described herein, the OCC sequence index is determined based on NPRACH subcarriers, a number of subcarrier groups, and an OCC length associated with the subcarrier groups.

[0126] In example 20, which can also include one or more of the examples described herein, the OCC sequence index is indicated explicitly by at least one reserved bit of a media access control (MAC) random access response (RAR) message.

[0127] In example 21, which can also include one or more of the examples described herein, the one or more processors are configured to: receive an explicit indication to enable or disable OCC-based Msg3 NPUSCH transmissions.

[0128] In example 22, which can also include one or more of the examples described herein, the one or more processors are configured to: determine an implicit indication to enable or disable OCC-based Msg3 NPUSCH transmissions.

[0129] In example 23, which can also include one or more of the examples described herein, a satellite device, base station, or another type of access point can comprise: one or more processors configured to: communicate, to a narrowband internet-of-things (NB-IoT) user equipment (UE) , time domain resources associated with a narrowband physical uplink shared channel (NPUSCH) transmission; communicate, to the NB-IoT UE, time domain resources associated with a narrowband physical random access channel (NPRACH) occasion; and communicate, to the NB-IoT UE, configuration information to enable the UE to: encode NPUSCH transmissions with orthogonal cover code (OCC) , and modify the encoded NPUSCH transmission when the encoded NPUSCH transmission overlaps with the time domain resources  associated with the NPRACH occasion.

[0130] The above description of illustrated examples, implementations, aspects, etc., of the subject disclosure, including what is described in the Abstract, is not intended to be exhaustive or to limit the disclosed aspects to the precise forms disclosed. While specific examples, implementations, aspects, etc., are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such examples, implementations, aspects, etc., as those skilled in the relevant art can recognize.

[0131] In this regard, while the disclosed subject matter has been described in connection with various examples, implementations, aspects, etc., and corresponding Figures, where applicable, it is to be understood that other similar aspects can be used or modifications and additions can be made to the disclosed subject matter for performing the same, similar, alternative, or substitute function of the subject matter without deviating therefrom. Therefore, the disclosed subject matter should not be limited to any single example, implementation, or aspect described herein, but rather should be construed in breadth and scope in accordance with the appended claims below.

[0132] In particular regard to the various functions performed by the above described components or structures (assemblies, devices, circuits, systems, etc. ) , the terms (including a reference to a “means” ) used to describe such components are intended to correspond, unless otherwise indicated, to any component or structure which performs the specified function of the described component (e.g., that is functionally equivalent) , even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations. In addition, while a particular feature can have been disclosed with respect to only one of several implementations, such feature can be combined with one or more other features of the other implementations as can be desired and advantageous for any given application.

[0133] As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or” . That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B;or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. Furthermore, to the extent that the terms “including” , “includes” , “having” , “has” , “with” , or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising. ” Additionally, in situations wherein one or more numbered items are  discussed (e.g., a “first X” , a “second X” , etc. ) , in general the one or more numbered items can be distinct, or they can be the same, although in some situations the context can indicate that they are distinct or that they are the same.

[0134] 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 to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

Claims

1.Baseband circuitry, comprising:one or more processors configured to:determine that a scheduled narrowband physical uplink shared channel (NPUSCH) transmission encoded with orthogonal cover code (OCC) overlaps in a time domain with at least one of a narrowband physical random access channel (NPRACH) occasion or an uplink timing adjustment gap; andmodify the scheduled NPUSCH transmission based on the determined overlap.2.The baseband circuitry of claim 1, wherein the scheduled NPUSCH transmission overlaps with the time domain with the NPRACH occasion based on at least one of:at least one symbol allocated to the NPUSCH transmission,at least one slot allocated to the NPUSCH transmission,at least one subframe allocated to a NPUSCH transmission or repetition, ora combination thereof.3.The baseband circuitry of claim 1, wherein the scheduled NPUSCH transmission overlaps with the uplink timing adjustment gap based on at least one of:a timing adjustment (TA) pre-compensation gap associated with the NPUSCH transmission,an uplink segment associated with the NPUSCH transmission, ora combination thereof.4.The baseband circuitry of claim 1, wherein:slot level OCC is applied to the NPUSCH transmission, andthe scheduled NPUSCH transmission is modified by dropping the scheduled NPUSCH transmission when at least one subframe of the scheduled NPUSCH transmission overlaps with the time domain resources associated with the NPRACH occasion.5.The baseband circuitry of claim 1, wherein:slot level OCC is applied to the NPUSCH transmission, andthe scheduled NPUSCH transmission is modified by delaying transmission of the scheduled NPUSCH transmission until after the time domain resources associated with the NPRACH occasion.6.The baseband circuitry of claim 1, wherein:symbol level OCC is applied to the NPUSCH transmission, andthe scheduled NPUSCH transmission is modified by dropping the scheduled NPUSCH transmission when at least one symbol of the scheduled NPUSCH transmission overlaps with the time domain resources associated with the NPRACH occasion.7.The baseband circuitry of claim 1, wherein:symbol level OCC is applied to the NPUSCH transmission, andthe scheduled NPUSCH transmission is modified by delaying the scheduled NPUSCH transmission until after the time domain resources associated with the NPRACH occasion.8.The baseband circuitry of claim 1, wherein:slot level OCC is applied to the NPUSCH transmission, andwhen a symbol level timing adjustment (TA) pre-configured gap is configured and a segment of the scheduled NPUSCH transmission overlaps with a compensation gap,the scheduled NPUSCH transmission is modified by dropping one colliding symbol of the scheduled NPUSCH transmission.9.The baseband circuitry of claim 1, wherein:slot level OCC is applied to the NPUSCH transmission, andwhen a slot level timing adjustment (TA) pre-configured gap is configured and a segment of the scheduled NPUSCH transmission overlaps with a compensation gap,the scheduled NPUSCH transmission is modified by dropping the scheduled NPUSCH transmission.10.The baseband circuitry of claim 1 , wherein:symbol level OCC is applied to the NPUSCH transmission, andwhen a symbol level timing adjustment (TA) pre-configured gap is configured and a segment of the scheduled NPUSCH transmission overlaps with a compensation gap,the scheduled NPUSCH transmission is modified by dropping the scheduled NPUSCH transmission.11.The baseband circuitry of claim 1, wherein:symbol level OCC is applied to the NPUSCH transmission, andwhen a slot level timing adjustment (TA) pre-configured gap is configured and a segment of the scheduled NPUSCH transmission overlaps with a compensation gap,the scheduled NPUSCH transmission is modified by dropping at least one colliding slot of the scheduled NPUSCH transmission.12.Baseband circuitry, comprising:one or more processors configured to:determine time domain resources associated with a narrowband physical random access channel (NPRACH) occasion;determine NPRACH transmission encoded with orthogonal cover code (OCC) overlaps in a time domain with an uplink timing adjustment gap; andmodify a NPRACH transmission based on the NPRACH transmission overlapping with in the time domain with the uplink timing adjustment gap.13.The baseband circuitry of claim 12, wherein the NPRACH transmission overlaps with the uplink timing adjustment gap based on at least one of:a timing adjustment (TA) pre-compensation gap associated with the NPRACH transmission,an uplink segment associated with a NPRACH uplink transmission or repetition, ora combination thereof.14.The baseband circuitry of claim 12, wherein:a symbol level OCC is applied to a symbol group of the NPRACH occasion, andwhen a timing adjustment (TA) pre-configured gap overlaps with the symbol group of the NPRACH occasion, the symbol group is dropped.15.The baseband circuitry of claim 12, wherein:a symbol group level OCC is applied to the NPRACH occasion, andwhen a timing adjustment (TA) pre-configured gap overlaps with a symbol group of an NPRACH transmission of the NPRACH, the NPRACH transmission is dropped.16.The baseband circuitry of claim 12, wherein the one or more processors are configured to:receive configuration information comprising dedicated NPRACH resources for an OCC-based Msg3 NPUSCH transmission indicated by a system information block (SIB) .determine NPRACH frequency domain resources for OCC-based Msg3 NPUSCH transmission, anddetermine an OCC sequence index.17.The baseband circuitry of claim 16, wherein the one or more processors are configured to:receive at least one of:an OCC length from an OCC length set,an OCC code to be applied to a narrowband uplink transmission,an OCC sequence index associated with an OCC sequence, ora combination thereof.18.The baseband circuitry of claim 17, wherein the OCC sequence index is determined based on NPRACH subcarriers, a number of subcarrier groups, and an OCC length associated with the subcarrier groups.19.The baseband circuitry of claim 17, wherein the OCC sequence index is indicated explicitly by at least one reserved bit of a media access control (MAC) random access response (RAR) message.20.A satellite device, comprising:one or more processors configured to:communicate, to a narrowband internet-of-things (NB-IoT) user equipment (UE) , time domain resources associated with a narrowband physical uplink shared channel (NPUSCH) transmission;communicate, to the NB-IoT UE, time domain resources associated with a narrowband physical random access channel (NPRACH) occasion; andcommunicate, to the NB-IoT UE, configuration information to enable the UE to:encode NPUSCH transmissions with orthogonal cover code (OCC) , andmodify the encoded NPUSCH transmission when the encoded NPUSCH transmission overlaps with the time domain resources associated with the NPRACH occasion.

Images