Systems and methods for managing resources for orthogonal cover code-based uplink transmissions in non-terrestrial networks

Abstract

A method (1500) is performed by a User Equipment, UE, (1912, 2000) for performing an uplink transmission that is spread using an Orthogonal Cover Code, OCC, in a Non-Terrestrial Network, NTN. The method includes transmitting (1502) an uplink transmission using Narrowband Physical Uplink Shared Channel, NPUSCH, Format1 with 3.75 kHz subcarrier spacing, SCS. The uplink transmission includes at least one data symbol, at least one Demodulation Reference Signal, DMRS, symbol, and at least one guard period. The location of the guard period within each of the slots comprising the uplink transmission is preserved after OCC spreading is applied to the uplink transmission.

Description

[0001] SYSTEMS AND METHODS FOR MANAGING RESOURCES FOR ORTHOGONAL COVER CODE-BASED UPLINK TRANSMISSIONS IN NON-TERRESTRIAL NETWORKS 5 TECHNICAL FIELD The present disclosure relates, in general, to wireless communications and, more particularly, systems and methods for managing resources for Orthogonal Cover Code (OCC)- based uplink (UL) transmissions in Non-Terrestrial Networks (NTNs). 10 BACKGROUND Non-Terrestrial Networks (NTN) was introduced for New radio (NR), Long Term Evolution-Machine Type Communications (LTE-MTC), and Narrowband-Internet of Things (NB- IoT) in Release 17 (Rel-17). The description of the functionalities added to NR, LTE-MTC and NB-IoT to operate as non-terrestrial networks can be found in a number of published documents. 15 See, X. Lin et al., 5G from Space: An Overview of 3GPP, IEEE Communications Standards Magazine, vol.5, no.4, pp.147-153, December 2021; M. S. Hassan et al., NTN: from 5G NR to 6G, 2023 IEEE International Conference on Wireless for Space and Extreme Environments (WiSEE), Aveiro, Portugal, 2023, pp.173-178, doi: 10.1109 / WiSEE58383.2023.10289427; NTN & Satellite in Rel-17 & 18, Munira Jaffar & Nicolas Chuberre, https: / / www.3gpp.org / news- 20 events / partner-news / ntn-rel17, last visited April 30, 2025. Orthogonal Cover Codes in 3GPP NTN will continue to evolve in 3rdGeneration Partnership Project (3GPP) Release 19 (Rel- 19) since the industry has considered increasing the UL capacity / throughput of the data channels 25 known as Physical Uplink Shared Channel (PUSCH) and Narrowband Physical Uplink Shared Channel (NPUSCH) for New Radio-NTN (NR-NTN) and Internet of Things-NTN (IoT-NTN), respectively. As a result of several Rel-19 workshops and discussions during the 3GPP RAN Plenary# 102 and RAN Plenary# 103, the following Rel-19 objectives for increasing the UL capacity for (N)PUSCH were agreed]: 5 ^ Rel-19 objective on “Uplink Capacity / Throughput Enhancement for FR1-NTN” [RAN1, RAN2, RAN4] ^ Study then specify, if beneficial, [Discrete Fourier Transform-s-Orthogonal Frequency Division Multiplexing (DFT-s-OFDM)] PUSCH enhancements via Orthogonal Cover Codes (OCC) 10 o Determine the achievable capacity improvement to be targeted taking into account realistic impairments (e.g., Doppler, time variation, phase distortion, etc.) o Specify necessary signalling, if needed o Update RF requirements, accordingly, if needed 15 o Note: The study can consider orthogonal cover codes across [Orthogonal Frequency Division Multiplexing (OFDM)] symbols, across slots, and / or within an OFDM symbol. o Note: the study phase is targeted to be completed by RAN#104 ^ Notes for this objective: 20 o The enhancement is not targeting improvements / impacts of [Multi User-Multiple Input Multiple Output (MU-MIMO)] capability o The enhancement is not targeted to PUSCH DMRS o No enhancement for initial access o Enhancements to [Physical Random Access Channel (PRACH)] are not 25 in scope. ^ Rel-19 objective on the “Support of Capacity enhancements for uplink” for IoT- NTN o Study then specify, if beneficial, enhancements to enable multiplexing of multiple [User Equipments (UEs)] (e.g. up to the min of 4 and the maximum 30 allowed by the existing [uplink (UL)] and [downlink (DL)] signalling) in a single 3.75 kHz or 15 kHz subcarrier via orthogonal cover codes (OCC) for NPUSCH format 1 and [Narrowband PRACH (NPRACH)] [RAN1, RAN2, RAN4] ^ Multi-tone support for 15 kHz SCS should also be considered 5 ^ Specify necessary signalling, if needed ^ Update [Radio Frequency (RF)] requirements accordingly, if needed Note: Impact of impairment shall be taken into account See, RP-240775, Revised WID: Non-Terrestrial Networks (NTN) for NR Phase 3, Thales, CATT, 10 RAN#103, Maastricht, The Netherlands, March 2024; RP-234077,New WID: Non-Terrestrial Networks (NTN) for Internet of Things (IoT) Phase 3, 3GPP TSG RAN Meeting #102, Edinburgh, Scotland, December 11-15, 2023; RP-240776, New WID: Non-Terrestrial Networks (NTN) for Internet of Things (IoT) Phase 3, 3GPP TSG RAN Meeting #103, Maastricht, The Netherlands, March 18-22, 2024 [sic]. 15 For the Rel-19 objective on “Uplink Capacity / Throughput Enhancement for FR1-NTN”, the agreements reached until RAN1# 116-bis are listed below: RAN1# 116 Agreement Adopt the table below for assumptions for Evaluation parameters for link level evaluation in NR NTN UL capacity and throughput enhancements

[0002] Parameter ValueChannel model^ NTN-TDL-C Rural, 30° elevation angle Carrier frequency ^ 2 GHz Subcarrier spacing ^ 15 kHzUE speed^ 3 km / hFrequency hopping ^ No frequency hopping PUSCH mapping type A with ^ 14 OS- for OCC across slots including DMRS [Hybrid Automatic Repeat Request ^ No HARQ (HARQ)] configuration Channel coding ^ [Low Density Parity Check (LDPC)] [Transport Block Size Reported by companies, e.g. (TBS)] ^ ≈184 bits payload @AMR 4.75kbps96 bits @Low data rate 1 port per UE Reported by companies ^ DMRS positions for single-symbol DMRS and optional double-symbol DMRS configuration / port / bundling DMRS for PUSCH mapping type A defined in Table 6.4.1.1.3-3 and Table 6.4.1.1.3-4 respectively with ld=14, l0=2 and pos1 in [38.211]. ^ up to 8 DMRS Ports Optional DMRS Bundling [Physical Resource Blocks Reported by companies, e.g. (PRBs)] / [Modulation ^ 1 PRB, 2 PRBs and Coding Scheme ^ MCS in Table 6.1.4.1-2 in [TS 38.214] (MCS)] Max repetition number ^ Reported by companies – up to 20 for [Voice Over Internet Protocol (VoIP)], up to 32 for low data rates OCC length Reported by companies, e.g. ^ Up to 8 Reported by companies, e.g. OCC sequence ^ Walsh sequences in Table 6.3.2.6.3-1 in TS38.211 ^ DFT sequence in Table 6.3.2.6.3-2 in TS38.211 Antenna configuration ^ 1Rx at Satellite Antenna configuration ^ 1Tx at UE Agreement Adopt the table below for assumptions for modelling impairments for link level evaluation in NR NTN UL capacity and throughput enhancements Parameter Value TO Reported by companies ^ With TO: Uniform selection from [-0.94us, 0.94us], where 0.94us=29Ts ^ Optional without TO FO Reported by companies ^ Uniform selection from [-0.1 ppm, +0.1 ppm], Variation of frequency error is negligible. ^ Optional: with lower maximum residual FO, to be reported by companies Timing drift Optional Receiver To be reported by companies, e.g. algorithm ^ MMSE Channel estimation ^ Real channel estimation Agreement Adopt the table below for assumptions for KPIs for link level evaluation in NR NTN UL capacity and throughput enhancements Parameter Value Number of code- Reported by companies (up to 8) division multiplexed users As in Rel-18 (otherwise reported by companies) KPI – SNR for a target BLER per UE ^ VoIP: SNR @2% BLER ^ For other cases: SNR @10% BLER Reported by companies KPI - Aggregated Total throughput according to number of code-division multiplexed users throughput (up to 8) Note: companies should also report the throughput for the case without OCC RAN1# 116-bis Agreement Support OCC for PUSCH in Rel-19 NR NTN: ^ At least PUSCH with Type A repetition o [For Future Study (FFS)] PUSCH without Type A repetition for intra-symbol and / or inter-symbol cases ^ At least code length 2 or 4, FFS code length 8 ^ FFS: number of [Resource Blocks (RBs)] ^ Potential OCC techniques listed below are for further down-selection: o Inter-slot time-domain OCC with PUSCH repetition Type A o Inter-symbol(s) time domain OCC o Intra-symbol pre-DFT-s OCC (comb-like structure as in PUCCH format 4) 5 o Combinations of OCC techniques ^ [Time Based Object Management System (TBoMS)] for OCC techniques is FFS Agreement RAN1 to at least further study the potential specification aspects on OCC 10 techniques: ^ TBS calculation / Rate matching ^ [Uplink Control Information (UCI)] multiplexing ^ [Redundancy Value (RV)] cycling across repetitions ^ Frequency hopping, e.g. intra / inter slot 15 ^ OCC indication / configuration ^ Power control ^ FFS others aspects For the Rel-19 objective on the “Support of Capacity enhancements for uplink” for IoT- NTN, the agreements reached until RAN1# 116-bis are listed below: 20 RAN1# 116 Agreement For single-tone NPUSCH format 1 transmissions with both 3.75kHz and 15kHz [Subcarrier Spacing (SCS)], the following OCC schemes are considered by RAN1 for further study: ^ Time domain OCC where OCC spreads across: 25 o Symbol-level o Slot-level o Repetition-level o RV-level For multi-tone NPUSCH format 1 transmissions, the following OCC schemes are considered by RAN1 for further study: ^ Time domain OCC where OCC spreads across: o Symbol-level 5 o Slot-level (including Nslot level) o Repetition-level o RV-level ^ Intra-symbol pre-DFT spreading OCC 10 Agreement The following evaluation assumptions are used for the study of OCC for NPUSCH format 1:

[0003] Parameter value scenario orbit [Geostationary Earth Orbit [Low Earth Orbit (LEO)]600 (GEO)] Elevation angle 12.5 degree 30degree Channel and carrier frequency 2GHz impairments Channel model [NTN-Tapped Delay Line-C] The channels from different UE are independent. Frequency error Uniform random selection from [-0.1 ppm, +0.1 ppm] for all UEs Variation of frequency error is negligible. Timing error Uniform random selection from [-97Ts, +97Ts] for all UEs Timing drift 80us / s for LEO600 and 0 for GEO. Power imbalance Uniformly distributed between +Pimb and -Pimb for all UEs Proponent to report the value of Pimb (can be zero) and justification for the chosen value transmitter SCS 3.75KHz and 15KHz 15kHz Number of tones Single tone Single tone and multi tone up to 12 tones Waveform DFT-s-OFDM Frequency hopping w / o frequency hopping MIMO scheme [Single Input Single Output (SISO) DMRS configuration For baseline evaluations: For baseline evaluations: OS#3 per slot for 3.75kHz OS#4 per slot for 15kHz OS#4 per slot for 15kHz For OCC evaluations: For OCC evaluations: Up to proponent Up to proponent Number of resource Up to proponent Up to proponent unit ( )Modulation order Up to proponent Up to proponent TBS ( ) Up to proponent Up to proponentNumber of Up to proponent repetitions ( )OCC length Up to 4 OCC sequence Up to proponent Number of UE Up to 4 Velocity of UE 3km / h receiver Receiver algorithm [Minimum Mean Square Error (MMSE)] Channel estimation Real channel estimation KPI SNR at 10% [Block Report for baseline and OCC schemes Error Rate (BLER)] Aggregated Total throughput of up to 4 UEs multiplexed throughput RAN1#116-bis Agreement For the NPUSCH evaluation assumptions, update the DMRS configuration, as follows: DMRS For baseline evaluations: For baseline evaluations: configuration OS#4 per slot for 3.75kHz OS#3 per slot for 15kHz OS#3 per slot for 15kHz For OCC evaluations: For OCC evaluations: Up to proponent Up to proponent Agreement At least the following NPRACH OCC schemes are considered by RAN1 for study: ^ Intra-symbol group OCC ^ Inter-symbol group(s) OCC ^ Inter-repetition OCC Agreement The study of OCC for NPRACH does not consider NPRACH format 2. Agreement The following evaluation assumptions are used for the study of OCC for NPRACH:

[0004] Parameter value Scenario Orbit and elevation angle GEO at 12.5 degrees; LEO600 at 30 degrees Channel and carrier frequency 2GHz impairments Channel model NTN-TDL-C The channels from different UE are independent. Frequency error Uniform random selection from [-0.1 ppm, +0.1 ppm] for all UEs Variation of frequency error is negligible. Timing error Uniform random selection from [-97Ts, +97Ts] for all UEs Timing drift 80us / s for LEO600 and 0 for GEO. Power imbalance Uniformly distributed between +Pimb and -Pimb for all UEs Proponent to report the value of Pimb (can be zero) and justification for the chosen valueTransmitterNPRACH format 1 or 0MIMO scheme SISO Number of repetitions Up to proponent (^^^^^) OCC length Up to proponent OCC sequence Up to proponent Number of UE Up to proponent Velocity of UE 3km / h Total NPRACH time / To be reported by proponent. frequency resource utilisation KPI Target detection 99% probability Target false alarm 0.1% probability SNR operating point Report SNR where target detection probability and false alarm probability are reached for baseline and OCC schemes Agreement OCC multiplexing is not supported between a UE using NPUSCH format 1 with 3.75kHz SCS and another UE using NPUSCH format 1 with 15kHz SCS. Agreement For OCC of NPUSCH format 1, RAN1 will not consider multiplexing more than 4 UEs. Agreement For single-tone DMRS when OCC is applied to NPUSCH format 1, RAN1 considers at least the following for further study: ^ TDM of DMRS. The time domain locations of DMRS for different UEs are different. No OCC is applied for the DMRS of different UEs. o FFS: Detailed mapping ^ CDM of DMRS. The time domain locations of DMRS for different UEs are the same. Different OCCs are applied for the DMRS of different UEs. o FFS: Detailed mapping ^ Other schemes are not precluded, including combinations of the above Agreement For the NPUSCH evaluation assumptions, update the frequency error assumption, as follows. Frequency error Uniform random selection from [-0.1 ppm, +0.1 ppm] for all UEs Variation of frequency error is negligible. For GEO, the same frequency error is applied to each subframe of a transport block. For LEO, the same frequency error is applied to each subframe of a segment (if applied in the evaluation). Companies to report their assumption on frequency error across segments. Pairing of UEs for OCC-based Transmission on the Same UL Resources for Optimized Performance Reception of multiple OCC-based transmissions on the same UL resource relies on that the received signals are orthogonal. However, the signals may be impacted by impairments in the transmitter, on the radio channel, and / or in the receiver. These impairments may degrade the orthogonality of the multiplexed signals. Examples of such impairments are time offset, time drift, frequency offset, and frequency drift. Further, power imbalances such as, for example, the differences in received signal power between multiplexed signals, may degrade the reception performance of the signals with relatively weaker received power in case other impairments make the multiplexed signals non-orthogonal. To reduce the impact of impairments, it is useful to partition UEs into groups, where UEs with similar characteristics are in the same group and multiplexed on the same UL resources. For 5 example, to reduce the effect of power imbalances, UEs with similar received power can be multiplexed on the same UL resources. To reduce the effect of frequency offsets, UEs with similar frequency offsets can be multiplexed on the same UL resources, since orthogonality is degraded when multiplexed signals have large differences in frequency offset. Similarly, to reduce the effect of time drift, UEs with similar time drift can be multiplexed on the same UL resources, etc. 10 There currently exist certain challenge(s), however. For example, introducing OCC to increase the UL capacity / throughput aims at utilizing simultaneously the same time-frequency resources by two or more UEs. However, the DL may end up becoming a bottleneck depending on the number of UEs transmitting simultaneously in the same UL frequency resources using OCC. When scheduling OCC-based UL transmissions, the main problem that may arise in DL is 15 either a DL signaling overhead or even a DL bottleneck. FIGURE 1 illustrates the DL signaling overhead when four NB-IoT UEs are scheduled to transmit in UL using an OCC-based transmission. More specifically, FIGURE 1 demonstrates that even if the UL OCC-based transmissions utilize exactly same time-frequency resources, in the DL (which is not orthogonalized), four independent time-frequency resources are required to schedule those four 20 UEs to transmit in the UL. For NR, consider as an example a total frequency allocation of 24 PRBs and up to four UEs scheduled in each PRB to perform OCC-based UL transmissions across four slots. An NR- NTN based example on the DL resources available to schedule multiple UEs to transmit in UL using OCC-based transmissions includes one PRB across four slots, carrying PUSCH for up to 25 four UEs. In total, up to 96 UEs can be allocated across four slots and 24 PRBs. When dynamic (Downlink Control Information (DCI)-based) scheduling is used, each UE needs to be granted permission to transmit in its UL resources in a UE-dedicated DCI transmitted on Physical Downlink Control Channel (PDCCH) in downlink (DL). The DCIs are transmitted in Control Resource Sets (CORESETs) on the DL. In time domain, a CORESET can span up to three 30 OFDM symbols. The minimum resources needed to transmit one DCI is one Control Channel Element (CCE) consisting of six Resource Element Groups (REGs), where one REG is 1 OFDM symbol x 1 PRB. Assuming the same total frequency allocation in DL and UL (i.e., 24 PRBs), up to 12 CCEs can be transmitted in one CORESET. To balance the DL coverage with the UL coverage, where four slot repetitions are used per UE in the example, it is likely that multiple CCEs are needed to transmit one DCI with a sufficiently robust channel coding, i.e., an PDCCH 5 aggregation level >1 is needed. Assuming, for example, aggregation level four, each PDCCH is transmitted in four CCEs. For example, only three UEs can be given UL grant per CORESET instance for a CORESET with three PDCCHs with aggregation level four. Thus, to schedule 96 UEs, 32 CORESET instances would be needed, which exceeds the available DL resources across 24 PRBs and four DL slots. Even if PDCCH aggregation level 1 is assumed, eight CORESET 10 instances would be needed, which would consume 43% of the DL resources and therefore severely reduce the capacity of DL user data on PDSCH. Therefore, one problem with existing technology is that the capacity and resource efficiency of DL control channels (e.g., PDCCH) is insufficient to grant a high number of UEs UL resources for OCC-based PUSCH transmissions. Another topic under discussion for IoT-NTN is the DMRS design for NPUSCH OCC- 15 based transmissions, which based on recent agreements the ultimate design is still open: Agreement For single-tone DMRS when OCC is applied to NPUSCH format 1, RAN1 considers at least the following for further study: 20 ^ TDM of DMRS. The time domain locations of DMRS for different UEs are different. No OCC is applied for the DMRS of different UEs. o FFS: Detailed mapping ^ CDM of DMRS. The time domain locations of DMRS for different UEs are the same. Different OCCs are applied for the DMRS of different UEs. 25 o FFS: Detailed mapping Other schemes are not precluded, including combinations of the above SUMMARY Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. For example, methods and systems are provided for using DL resources along with OCC-based UL transmissions for NR-NTN and IoT-NTN. 5 According to certain embodiments, a method by a UE for performing an UL transmission that is spread using an OCC in a NTN includes transmitting an UL transmission using NPUSCH Format1 with 3.75 kHz SCS. The UL transmission includes at least one data symbol, at least one DMRS symbol, and at least one guard period. The location of the guard period within each of the slots comprising the UL transmission is preserved after OCC spreading is applied to the UL 10 transmission. According to certain embodiments, a UE for performing OCC spreading for UL transmissions in a NTN includes a memory and processing circuitry. The UE is configured to transmit an UL transmission using NPUSCH Format1 with 3.75 kHz SCS. The UL transmission comprises at least one DMRS symbol. A location of the guard period is preserved after OCC 15 spreading is applied to the UL transmission. According to certain embodiments, a method by a network node for receiving UL transmissions using OCC spreading in a NTN includes receiving, from a UE, an UL transmission using NPUSCH Format1 with 3.75 kHz SCS. The UL transmission comprises at least one data symbol, at least one DMRS symbol, and at least one guard period. The location of the guard period 20 within each of the slots comprising the UL transmission is preserved after OCC spreading is applied to the UL transmission. According to certain embodiments, a network node for receiving UL transmissions using OCC spreading in a NTN includes a memory and processing circuitry. The network node is configured to receive, from a UE, an UL transmission using NPUSCH Format1 with 3.75 kHz 25 SCS. The UL transmission comprises at least one data symbol, at least one DMRS symbol, and at least one guard period. The location of the guard period within each of the slots comprising the UL transmission is preserved after OCC spreading is applied to the UL transmission. According to certain embodiments, a system for OCC spreading for UL transmissions in a NTN includes a UE and a network node. The UE is configured to transmit an UL transmission 30 using NPUSCH Format1 with 3.75 kHz SCS. The network node is configured to receive the UL transmission. The UL transmission comprises at least one data symbol, at least one DMRS symbol, and at least one guard period. A location of a guard period within each of the slots comprising the UL transmission is preserved after OCC spreading is applied to the UL transmission. In particular embodiments, the NTN comprises an IoT-NTN. In particular embodiments, no OCC spreading is applied to the at least one DMRS symbol. 5 In particular embodiments, a DMRS distribution for the UL transmission comprises a number of DMRS symbols per slot and wherein the number of DMRS symbols per slot is one or two. In particular embodiments, the UL transmission comprises at least one data symbol, and the method further comprises applying OCC spreading to the at least one data symbol. 10 Certain embodiments may provide one or more of the following technical advantage(s). For example, certain embodiments may provide a technical advantage of reducing DL overhead when OCC-based UL transmissions are scheduled. As another example, certain embodiments may provide a technical advantage of providing solutions that may be used to avoid a potential DL bottle neck when DL is not orthogonal. 15 As another example, certain embodiments may provide a technical advantage of providing a common solution for NR-NTN and IoT-NTN that alleviates or avoid DL when scheduling OCC- based UL transmissions. As still another example, certain embodiments related to the IoT-NTN topic on the DMRS design may provide a technical advantage of keeping the Guard Period location even after OCC 20 spreading allows keeping the symbol boundary aligned. Additionally, there may be some other UEs on different subcarriers with and / or without OCC that need to keep the symbol boundary aligned to each other so they can share the FFT at the receiver and avoid the inter-subcarrier interference because of un-aligned symbol boundary. Other advantages may be readily apparent to one having skill in the art. Certain 25 embodiments may have none, some, or all of the recited advantages.

[0005] BRIEF DESCRIPTION OF THE DRAWINGS For a more complete understanding of the disclosed embodiments and their features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which: 5 FIGURE 1 illustrates the DL signaling overhead when four NB-IoT UEs are scheduled to transmit in UL using an OCC-based transmission; FIGURE 2 illustrates a slot format for NPUSCH Format 1 with 3.75 kHz SCS, according to certain embodiments; FIGURE 3 illustrates an IoT-NTN based example for reducing the DL resources required 10 to schedule four UEs to transmit in the UL using an OCC-based transmission, according to certain embodiments; FIGURE 4 illustrates a corresponding example for NR-NTN for reducing the DL resources required to schedule four UEs to transmit in the UL using an OCC-based transmission, according to certain embodiments; 15 FIGURE 5 illustrates an NR-NTN based example where the frequency resources allocated to three sets of UEs fully overlap, according to certain embodiments; FIGURE 6 illustrates an NR-NTN based example where each common DCI grants permission to transmit to a dynamically selected subset of UEs in a specific UL time-frequency resource, according to certain embodiments; 20 FIGURE 7 illustrates an example demonstrating frequency hopping length within the UE groups using same resource and different OCC to transmit PUSCH, according to certain embodiments; FIGURE 8 illustrates a first example DMRS distribution before OCC spreading, according to certain embodiments; 25 FIGURE 9 illustrates the first example DMRS distribution after OCC spreading, while keeping the Guard Period location, according to certain embodiments; FIGURE 10 illustrates a second example DMRS distribution before OCC spreading, according to certain embodiments; FIGURE 11 illustrates the second example DMRS distribution after OCC spreading, while 30 keeping the Guard Period location, according to certain embodiments; FIGURE 12 illustrates a third example DMRS distribution before OCC spreading, according to certain embodiments; FIGURE 13 illustrates the third example DMRS distribution after OCC spreading, while keeping the Guard Period location, according to certain embodiments; 5 FIGURE 14 illustrates an example method by a UE for managing resources with OCC- based UL transmissions in NTN, according to certain embodiments; FIGURE 15 illustrates another example method by a network node for managing resources with OCC-based UL transmissions in NTN, according to certain embodiments; FIGURE 16 illustrates an example method performed by a UE for performing an UL 10 transmission that is spread using an OCC in a NTN, according to certain embodiments; FIGURE 17 illustrates an example method performed by a network node for receiving UL transmissions using OCC spreading in a NTN, according to certain embodiments; FIGURE 18 illustrates an example method by a network node for managing resources with OCC based UL transmissions in a NTN, according to certain embodiments; 15 FIGURE 19 illustrates an example method performed by a UE for transmitting OCC based UL transmissions in a NTN, according to certain embodiments; FIGURE 20 illustrates an example communication system, according to certain embodiments; FIGURE 21 illustrates an example UE, according to certain embodiments; 20 FIGURE 22 illustrates an example network node, according to certain embodiments; FIGURE 23 illustrates a virtualization environment in which functions implemented by some embodiments may be virtualized, according to certain embodiments; and FIGURE 24 illustrates a transparent or bent pipe architecture on the left and a regenerative architecture on the right, according to certain embodiments. 25

[0006] DETAILED DESCRIPTION Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. 5 As used herein, ‘node’ can be a network node or a UE. Examples of network nodes are NodeB, base station (BS), multi-standard radio (MSR) radio node such as MSR BS, eNodeB (eNB), gNodeB (gNB), Master eNB (MeNB), Secondary eNB (SeNB), integrated access backhaul (IAB) node, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), Central Unit (e.g., in a gNB), 10 Distributed Unit (e.g., in a gNB), Baseband Unit, Centralized Baseband, Cloud-Radio Access Network (C-RAN), access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), core network node (e.g., Mobile Switching Center (MSC), Mobility Management Entity (MME), etc.), Operations & Maintenance (O&M), Operations Support System (OSS), Self-Organizing Network 15 (SON), positioning node (e.g., Evolved Serving Mobile Location Centers (E-SMLC)), etc. The terms network node and radio network node are used interchangeably herein. Another example of a node is UE, which is a non-limiting term and refers to any type of wireless device communicating with a network node and / or with another UE in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, vehicular 20 to vehicular (V2V), machine type UE, MTC UE or UE capable of machine to machine (M2M) communication, Personal Digital Assistant (PDA), Tablet, mobile terminals, smart phone, laptop embedded equipment (LEE), laptop mounted equipment (LME), Unified Serial Bus (USB) dongles, etc. The term radio access technology (RAT), may refer to any RAT such as, for example, 25 Universal Terrestrial Radio Access Network (UTRA), Evolved Universal Terrestrial Radio Access Network (E-UTRA), narrow band internet of things (NB-IoT), WiFi, Bluetooth, next generation RAT, NR, 4G, 5G, etc. Any of the equipment denoted by the terms node, network node or radio network node may be capable of supporting a single or multiple RATs. The term signal or radio signal used herein can be any physical signal or physical channel. 30 Examples of DL physical signals are reference signal (RS) such as Primary Synchronization Signal (PSS), Secondary Synchronization Signal (SSS), Channel State Information-Reference Signal (CSI-RS), Demodulation Reference Signal (DMRS) signals in SS / PBCH block (SSB), discovery reference signal (DRS), Cell Specific Reference Signal (CRS), Positioning Reference Signal (PRS), etc. RS may be periodic. For example, RS occasions carrying one or more RSs may occur with certain periodicity (e.g., 20 ms, 40 ms, etc.). The RS may also be aperiodic. 5 Each SSB carries New Radio-Primary Synchronization Signal (NR-PSS), New Radio- Secondary Synchronization Signal (NR-SSS) and New Radio-Physical Broadcast Channel (NR- PBCH) in four successive symbols. One or multiple Synchronization Signal Blocks (SSBs) are transmitted in one SSB burst, which is repeated with certain periodicity such as, for example, 5 ms, 10 ms, 20 ms, 40 ms, 80 ms, and 160 ms. The UE is configured with information about SSB 10 on cells of certain carrier frequency by one or more SS / PBCH block measurement timing configuration (SMTC) configurations. The SMTC configuration comprising parameters such as SMTC periodicity, SMTC occasion length in time or duration, SMTC time offset with regard to reference time (e.g., serving cell’s SFN) etc. Therefore, SMTC occasion may also occur with certain periodicity (e.g., 5 ms, 10 ms, 20 ms, 40 ms, 80 ms, and 160 ms). Examples of UL physical 15 signals are reference signals such as Sounding Reference Signals (SRS), Demodulation Reference Signals (DMRS), etc. The term physical channel refers to any channel carrying higher layer information e.g. data, control etc. Examples of physical channels are Physical Broadcast Channel (PBCH), Physical Downlink Control Channel (PDCCH), Physical Downlink Shared Channel (PDSCH), Physical Uplink Shared Channel (PUSCH), Physical Uplink Control Channel 20 (PUCCH), Physical Uplink Shared Channel (PUSCH), Short PUSCH (sPUCCH), Short PDSCH (sPDSCH), Short PUCCH (sPUCCH), Short PUSCH (sPUSCH), MTC PDCCH (MPDCCH), Narrowband PBCH (NPBCH), Narrowband PDCCH (NPDCCH), Narrowband PDSCH (NPDSCH), Narrowband PUSCH (NPUSCH), Enhanced PDCCH (E-PDCCH), etc. As used herein, the term time resource may correspond to any type of physical resource or 25 radio resource expressed in terms of length of time. Examples of time resources are symbol, time slot, subframe, radio frame, transmission time interval (TTI), interleaving time, slot, sub-slot, mini- slot, system frame number (SFN) cycle, hyper-SFN (H-SFN) cycle, etc. According to certain embodiments described herein, systems and methods are provided for using DL resources along with OCC-based UL transmissions for NR-NTN and IoT-NTN. For 30 example, according to certain embodiments, a common DCI will schedule an UL grant for a group of two or more UEs whose UL transmissions will be orthogonalized on the same time-frequency resources. In particular embodiments, a Group-Radio Network Temporary Identifier (G-RNTI) or a new type of RNTI (e.g., OCC-RNTI) is used to assign a common DCI to a group of UEs using OCC-based UL transmissions. Alternatively, according to certain embodiments, when the DCI is independently 5 transmitted to each of the UEs whose UL transmissions will be orthogonalized on the same time- frequency resources, then additional scheduling delays between the control information and the user data are added to the technical specification in such a way that the DCI can point out the UE to transmit on the exact same UL resources. In a particular embodiment, for example, multiple DCI instances will schedule UL grant 10 for multiple groups of UEs, where each DCI is directed to a different group of UEs, and where each DCI may schedule different UL resources to the UEs in a group, and where the sets of UL resources scheduled by different DCIs may partially or fully overlap. According to certain embodiments, related to the IoT-NTN topic on the DMRS design, systems and methods are provided for keeping the Guard Period location even after OCC spreading 15 aiming at keeping the symbol boundary aligned. According to certain other embodiments described herein, systems and methods are provided for DMRS design aspects for IoT-NTN. For example, FIGURE 2 illustrates a slot format 100 for NPUSCH Format 1 with 3.75 kHz SCS, according to certain embodiments, which may be a legacy slot structure. Specifically, the slot format 100 has a duration of 2 ms and includes 20 multiple CP-Data symbols 105a-f, as well as a CP-DMRS symbol 110 and a Guard Period 115 located at the end of the slot. Certain embodiments described herein keep the Guard Period location even after OCC spreading aiming at keeping the symbol boundary aligned. The embodiments described herein are applicable to both Terrestrial and NTNs. 25 Certain embodiments described herein are applicable to Time Division Duplex (TDD). Certain embodiments described herein can be used along repetitions. In any of the described embodiments where information is included in the DCI, which is not in any currently specified DCI format, a new DCI format may be specified to carry the information required for the respective embodiment. 30 In an IoT-NTN specific embodiment, the solutions described herein are applicable to DCI Format N0 or other DCI formats. In an IoT-NTN specific embodiment, the solutions described herein applicable for both 3.75 kHz and 15 kHz SCS and for other suitable SCS. In an IoT-NTN specific embodiment, upon incorporating the solutions described herein, the DCI size associated to DCI Format N0 is not increased, and new indications associated to 5 OCC-based transmissions are incorporated through re-interpreting or re-using existing fields and existing bits in the DCI Format N0. In an IoT-NTN specific embodiment, upon incorporating the solutions described herein, the DCI size associated to DCI Format N0 could alternatively be increased by one or more bits to introduce additional fields associated to OCC-based transmissions. 10 One or more of the embodiments described herein are used in one or more beams transmitted from a given satellite. One or more of the embodiments described herein are used in a deployment having one beam per cell. One or more of the embodiments described herein are used in a deployment having more 15 than one beam per cell. One or more of the embodiments described herein are equally applicable to a non-terrestrial network scenario based on transparent payload or regenerative payload. One or more of the embodiments described herein are equally applicable to different satellite orbits such as LEO, Medium Earth Orbit (MEO), and GEO. 20 Methods For Using DL Resources Along With OCC-Based UL Transmissions For NTN Methods For Efficient Use Of DL Resources For Scheduling OCC-Based UL Transmissions According to certain embodiments, one common DCI carrying scheduling information 25 (i.e., UL grant) is received by one or more UEs towards performing simultaneous OCC-based transmissions on the same time-frequency UL resources. FIGURE 3 illustrates an IoT-NTN based example 200 for reducing the DL resources required to schedule (i.e., reducing DL signaling overhead) four UEs to transmit in the UL using an OCC-based transmission, according to certain embodiments. From FIGURE 3, it can be seen that a common time-frequency resource 205 would30 be used to schedule four UEs to perform OCC-based transmissions utilizing exactly the same time- frequency resources 210 in the UL (e.g., subframes 9-14 in FIGURE 3). FIGURE 4 illustrates a corresponding example 300 for NR-NTN for reducing the DL resources required to schedule (i.e., reducing DL signaling overhead) four UEs to transmit in the UL using an OCC-based transmission, according to certain embodiments. In a particular embodiment, the one or more UEs have been preconfigured each with a 5 different OCC sequence; and the reception of the common DCI carrying scheduling information (i.e., UL grant) indicates to the one or more UEs to perform simultaneous OCC-based transmissions on the same time-frequency UL resources, wherein each UE should use its preconfigured OCC sequence in the transmission. In a particular embodiment, the one or more UEs have been preconfigured each with a UE 10 index; and the reception of the common DCI carrying scheduling information (i.e., UL grant) indicates to the one or more UEs to perform simultaneous OCC-based transmissions on the same time-frequency UL resources, and where the DCI indicates for each UE index an associated OCC sequence. The UE index may be configured via MAC signaling (e.g., using a new MAC CE) or via RRC signaling (e.g., using an RRCReconfiguration message, an 15 RRCConnectionReconfiguration message, an RRCSetup message, or an RRCConnectionSetup message), or via PDCCH (or NPDCCH) signaling (e.g., in a DCI message). In a variant of this embodiment, the UE index is not explicitly configured for this purpose. Instead a certain number of the least significant bits (LSBs) of each UE’s Cell-Radio Network Temporary Identifier (C- RNTI) is used as the UE index. In a further variant, the full C-RNTI serves the purpose of the UE 20 index. In a particular embodiment, the one or more UEs have been preconfigured each with a UE index and a table of one or more OCC sequences (or alternatively the table of one or more OCC sequences may be specified in a standard); wherein the reception of the common DCI carrying scheduling information (i.e., UL grant) indicates to the one or more UEs to perform simultaneous 25 OCC-based transmissions on the same time-frequency UL resources, and where the DCI indicates for each UE index an associated index to the OCC sequence table, thus indicating to each UE which OCC sequence it should use for the transmission. The UE index and a table of one or more OCC sequences may be configured in the UE via MAC signaling (e.g., using a new MAC CE) or via RRC signaling (e.g., using an RRCReconfiguration message, an 30 RRCConnectionReconfiguration message, an RRCSetup message, or an RRCConnectionSetup message), or via PDCCH (or NPDCCH) signaling (e.g., in a DCI message). In a variant of this embodiment, the UE index is not explicitly configured for this purpose. Instead a certain number of the LSBs of each UE’s C-RNTI is used as the UE index. In a further variant, the full C-RNTI serves the purpose of the UE index. In other variants of the embodiment, the DCI does not indicate an index pointing out an OCC sequence in the OCC table. Instead, a certain number of the LSBs 5 (e.g., 4 LSBs) of the C-RNTI are used as the index pointing out an OCC sequence in the OCC table. Methods for Efficient Use of DL Resources for Dynamic Pairing of UEs for OCC-based UL Transmissions 10 The following embodiments are intended to facilitate dynamic pairing of UEs, as described herein. For this purpose, in a particular embodiment, the UEs are partitioned in disjoint groups of one or more UEs. Each UE receives the common DCI of its group, which grants the UEs in the group to transmit in (potentially) different UL resources. Different common DCIs can grant UEs 15 in other groups to transmit in the same UL resources. In a particular embodiment, the one or more UEs in a group have been preconfigured each with a UE index and an OCC sequence, where the reception of the common DCI carrying scheduling information (i.e., UL grant) for that group indicates to the one or more UEs to perform simultaneous OCC-based transmissions, and where the DCI indicates for each UE index an 20 associated frequency resource. With this embodiment, as one option, the network (e.g., a network node such as, for example, a gNB or an eNB) may allocate disjoint frequency resources to different disjoint subsets (of one or more UE(s)) of the one or more UEs, so that the frequency resource of one subset of UE(s) does not overlap with the frequency resources of any other subset of UE(s). As another option, the network node may allocate different frequency resources to different 25 disjoint subsets (of one or more UE(s)) of the one or more UEs, wherein the frequency resources allocated to one subset of UE(s) partially or fully overlaps with the frequency resources allocated to one or more of the other subset(s) of UE(s). As one option, the network node may allocate the disjoint and / or overlapping frequency resources to the disjoint subsets of the one or more UEs in a single DCI message. As another option, the network node may allocate the disjoint and / or 30 overlapping frequency resources to the disjoint subsets of the one or more UEs in multiple DCI messages such as, for example, one DCI message per subset of UEs. As yet another option, network node may have a choice to allocate the disjoint and / or overlapping frequency resources to the disjoint subsets of the one or more UEs in one DCI message or in multiple DCI messages such as, for example, one DCI message per subset of UEs. FIGURE 5 illustrates an NR-NTN based example 400 where the frequency resources 5 allocated to three sets of UEs fully overlap, according to certain embodiments. In a particular embodiment, the one or more UEs in a group have been preconfigured each with a UE index and an OCC sequence, where the reception of the common DCI carrying scheduling information (i.e., UL grant) for that group indicates to the one or more UEs to perform simultaneous OCC-based transmissions, and where the DCI indicates for each UE index an 10 associated time-domain resource. With this embodiment, as one option, the network (e.g., a network node such as, for example, a gNB or an eNB) may allocate disjoint time-domain resources to different disjoint subsets (of one or more UE(s)) of the one or more UEs, so that the time-domain resource of one subset of UE(s) does not overlap with the time-domain resource of any other subset of UE(s). As another option, the network (e.g., a network node such as, for example, a gNB or an 15 eNB) may allocate different time-domain resources to different disjoint subsets (of one or more UE(s)) of the one or more UEs, wherein the time-domain resource allocated to one subset of UE(s) partially or fully overlaps with the time-domain resource(s) allocated to one or more of the other subset(s) of UE(s). As one option, the network node may allocate the disjoint and / or overlapping time-domain resources to the disjoint subsets of the one or more UEs in a single DCI message. As 20 another option, the network node may allocate the disjoint and / or overlapping time-domain resources to the disjoint subsets of the one or more UEs in multiple DCI messages such as, for example, one DCI message per subset of UEs. As yet another option, the network node may have a choice to allocate the disjoint and / or overlapping time-domain resources to the disjoint subsets of the one or more UEs in one DCI message or in multiple DCI messages such as, for example, 25 one DCI message per subset of UEs. In a particular embodiment, the one or more UEs in a group have been preconfigured each with a UE index and an OCC sequence, where the reception of the common DCI carrying scheduling information (i.e., UL grant) for that group indicates to the one or more UEs to perform OCC-based transmissions, and where the DCI indicates for each UE index an associated time- 30 frequency resource. With this embodiment, as one option, the network (e.g., a network node, such as, for example, a gNB or an eNB) may allocate disjoint time-frequency resources to different disjoint subsets (of one or more UE(s)) of the one or more UEs, so that the time-frequency resource of one subset of UE(s) does not overlap with the time-frequency resource of any other subset of UE(s). As another option, the network (e.g., a network node such as, for example, a gNB or an eNB) may allocate different time-frequency resources to different disjoint subsets (of one or more 5 UE(s)) of the one or more UEs, wherein the time-frequency resource allocated to one subset of UE(s) partially or fully overlaps with the frequency resource(s) allocated to one or more of the other subset(s) of UE(s). As one option, the network node may allocate the disjoint and / or overlapping time-frequency resources to the disjoint subsets of the one or more UEs in a single DCI message. As another option, the network node may allocate the disjoint and / or overlapping 10 time-frequency resources to the disjoint subsets of the one or more UEs in multiple DCI messages such as, for example, one DCI message per subset of UEs. As yet another option, the network node may have a choice to allocate the disjoint and / or overlapping time-frequency resources to the disjoint subsets of the one or more UEs in one DCI message or in multiple DCI messages such as, for example, one DCI message per subset of UEs. 15 In a particular embodiment, the one or more UEs in a group have been preconfigured each with a UE index, where the reception of the common DCI carrying scheduling information (i.e., UL grant) for that group indicates to the one or more UEs to perform OCC-based transmissions, and where the DCI indicates for each UE index an associated time-frequency resource and an associated OCC sequence. With this embodiment, as one option, the network (e.g., a network node 20 such as, for example, a gNB or an eNB) may allocate disjoint time-frequency resources to different disjoint subsets (of one or more UE(s)) of the one or more UEs, so that the time-frequency resource of one subset of UE(s) does not overlap with the time-frequency resource of any other subset of UE(s). As another option, the network (e.g., a network node such as, for example, a gNB or an eNB) may allocate different time-frequency resources to different disjoint subsets (of one or more 25 UE(s)) of the one or more UEs, wherein the time-frequency resource allocated to one subset of UE(s) partially or fully overlaps with the frequency resource(s) allocated to one or more of the other subset(s) of UE(s). As another option, the network node may allocate the disjoint and / or overlapping time-frequency resources to the disjoint subsets of the one or more UEs in multiple DCI messages such as, for example, one DCI message per subset of UEs. As yet another option, 30 the network node may have a choice to allocate the disjoint and / or overlapping time-frequency resources to the disjoint subsets of the one or more UEs in one DCI message or in multiple DCI messages such as, for example, one DCI message per subset of UEs. In a particular embodiment, the one or more UEs in a group have been preconfigured each with a UE index and a resource table, each entry of the table consisting of an OCC sequence and 5 a time-frequency resource, where the reception of the common DCI carrying scheduling information (i.e., UL grant) for that group indicates to the one or more UEs to perform OCC-based transmissions, and where the DCI indicates for each UE index an associated index to an entry in the resource table, thus indicating OCC sequence and time-frequency resources to be used by that UE for the transmission. 10 In a particular embodiment, the one or more UEs in a group have been preconfigured each with a UE index and a resource table, each entry of the table consisting of an OCC sequence and a time-frequency resource, where the reception of the common DCI carrying scheduling information (i.e., UL grant) for that group indicates to the one or more UEs to decode the DCI to determine whether to perform OCC-based transmissions, and where the DCI indicates a subset of 15 the UE indices, and for each of these UE indices an associated index to an entry in the resource table for that UE, and the UE performs OCC-based transmissions only if their UE index is indicated in the DCI. For the purpose of facilitating dynamic pairing of UEs, in one embodiment, the UEs are partitioned in non-disjoint groups of one or more UEs. As a special case, a single group is defined 20 that contains all UEs. Each UE receives the common DCI(s) of its group(s), and each DCI grants a subset of the UEs receiving that DCI permission to transmit in the same UL time-frequency resource. Other common DCIs can grant other UEs to transmit in other UL resources. In other words, in this embodiment, a given DCI grants transmission to dynamically selected UEs in one specific UL time-frequency resource. 25 FIGURE 6 illustrates an NR-NTN based example 500, where each common DCI grants permission to transmit to a dynamically selected subset of UEs in a specific UL time-frequency resource, according to certain embodiments. In a particular embodiment, the one or more UEs in a group have been preconfigured each with a UE index and an OCC sequence; wherein the reception of the common DCI carrying 30 scheduling information (i.e., UL grant) for that group indicates to a subset of the one or more UEs to perform simultaneous OCC-based transmissions in the same time-frequency resource, and where the DCI indicates through a set of UE indices which UEs that are granted permission to transmit. In a particular embodiment, the one or more UEs in a group have been preconfigured each with a UE index, where the reception of the common DCI carrying scheduling information (i.e., 5 UL grant) for that group indicates to a subset of the one or more UEs to perform simultaneous OCC-based transmissions in the same time-frequency resource, where the DCI indicates through a set of UE indices which UEs that are granted permission to transmit, and where the DCI indicates for each indicated UE index an associated OCC sequence. In a particular embodiment, the one or more UEs in a group have been preconfigured each 10 with a UE index and a table of one or more OCC sequences, where the reception of the common DCI carrying scheduling information (i.e., UL grant) for that group indicates to a subset of the one or more UEs to perform simultaneous OCC-based transmissions in the same time-frequency resource, where the DCI indicates through a set of UE indices which UEs that are granted permission to transmit, and where the DCI indicates for each indicated UE index an associated 15 index to the OCC sequence table, thus indicating to each indicated UE which OCC sequence it should use for the transmission. Methods for Network Configuration In embodiments where each UE (for which this feature is to be enabled) is preconfigured 20 with a UE index, the UE index may be configured via MAC signaling (e.g., using a new MAC CE), or via RRC signaling (e.g., using an RRCReconfiguration message, an RRCConnectionReconfiguration message, an RRCSetup message, or an RRCConnectionSetup message), or via PDCCH (or NPDCCH) signaling (e.g., in a DCI message). Furthermore, in variants of the embodiments, the UE index is not explicitly configured for this purpose. Instead, a 25 certain number of the LSBs of each UE’s C-RNTI is used as the UE index (wherein as one option, all the bits of the C-RNTI are used as the index). In embodiments where each UE (for which this feature is to be enabled) is preconfigured with an OCC sequence table index (and possibly an OCC sequence table) or a resource table index, the table index (and possibly the OCC sequence table) may be configured via MAC signaling (e.g., 30 using a new MAC CE), or via RRC signaling (e.g., using an RRCReconfiguration message, an RRCConnectionReconfiguration message, an RRCSetup message or an RRCConnectionSetup message), or via PDCCH (or NPDCCH) signaling (e.g., in a DCI message). Furthermore, in variants of the embodiments, the table index is not explicitly configured for this purpose, instead a certain number of the LSBs of each UE’s C-RNTI is used as the table index (wherein as one option, all the bits of the C-RNTI are used as the index). 5 Methods for OCC-based transmission of MSG3 on PUSCH / NPUSCH Consider the case where one or more UEs need to be OCC-multiplexed for transmitting message 3 of a four-step RA procedure (MSG3) on PUSCH / NPUSCH. In the existing NR / LTE specification for contention-based random access, the UL resources for MSG3 are granted using a 10 DCI whose CRC is scrambled with the selected UE’s Random Access-RNTI (RA-RNTI) (e.g., the UE whose PRACH transmission was successful). With this approach, the UE with the correct RA- RNTI is expected to decode the DCI and transmit MSG3 on the indicated UL resources. In a particular embodiment, a new common DCI is defined which includes the RA-RNTI’s of each of the UEs that is to be OCC-multiplexed on the common UL time / frequency resources. In one 15 example, where 2 UEs are to be OCC-multiplexed, this can be achieved by doubling the length of the CRC and scrambling the first half with one UE’s RA-RNTI and the other half with the second UE’s RA-RNTI. The UEs will be expected to decode the entire CRC to determine if this DCI is intended for them. In another example, the length of CRC is kept the same as in the legacy DCI, but the CRC is repeated twice for two UEs where the first CRC is scrambled by the first UE’s RA- 20 RNTI and the second CRC by the second UE’s RA-RNTI. In another embodiment, instead of including the RA-RNTIs of all the UEs to be OCC- multiplexed in the DCI (e.g., via scrambling CRC), a 1-bit indicator is included in the DCI to indicate if the DCI is intended for OCC multiplexing. Then, a certain number of LSBs of the RA- RNTI are used to indicate which UEs are to be OCC-multiplexed. This assumes that the network 25 will OCC-multiplex the UEs which have identical RA-RNTI in the certain number of RA-RNTI bits where the certain number of bits can be fixed in the specification or indicated in the DCI. In another embodiment, if a new common DCI is defined to indicate Random Access Response (RAR) UL grant, the RAR UL grant sent on the PDSCH also needs to be modified. In one embodiment, if a UE decodes a common DCI to learn about RAR UL grant, then it is not 30 expected to check if the RAPID field in the RAR UL grant MAC header matches the UE’s RAPID. In another embodiment, the UL grant MAC header contains the RAPIDs of all the UEs to be OCC- multiplexed and if the UE finds its RAPID, then it can proceed with MSG3 transmission. In one example, the UE can learn the number of RAPIDs included in the MAC carrying the RAR UL grant from the DCI format (e.g., if the number of UEs to be OCC-multiplexed in indicated in the DCI, or from the length of CRC field, etc.). In one embodiment, the number of UEs to be OCC- multiplexed is indicated using System Information (SI). In another embodiment, the DCI format used for OCC-multiplexing the UEs for MSG3 PUSCH is indicated in SI. With this information, the UE need not blindly decode different DCI formats. Note that one or more of the embodiments related to OCC defined elsewhere in this document are also be applied to the embodiments related to OCC-multiplexing for MSG3 transmission on PUSCH / NPUSCH. Methods for Configuring Redundancy Value Cycling for OCC-based Transmissions In a particular embodiment, the one or more UEs have been preconfigured each with a UE index and a resource table, each entry of the table consisting of an OCC sequence and a time- frequency resource, where the reception of the common DCI carrying UE multiplexing number information indicates the UL slots or symbols keep the same Redundancy Value (RV) number, then UE will keep the same RV number across these slots / symbols. The UE will do the RV cycling as TABLE 1 shows where ^^ௌைி^^is the UE multiplexing number information: TABLE 1 ^^^^^ௗindicated by ^^^^^ௗto be applied to ^^௧^transmission occasion the DCI scheduling the n mod (4* ^^ௌைி^^) =0 n mod (4* ^^ௌைி^^) =1 n mod (4* ^^ௌைி^^) =2 n mod (4* ^^ௌைி^^) =3PUSCH 0 0 2 3 1 2 2 3 1 0 3 3 1 0 2 1 1 0 2 3 Methods for Addressing Groups of UEs The following embodiments are related to any of the embodiments described above. In a particular embodiment, the Cyclic Redundancy Check (CRC) associated to the DCI carrying scheduling information is scrambled with a Group-Radio Network Temporary Identifier (G-RNTI) as to target a group of one or more UEs scheduled to perform the simultaneous OCC- based transmissions on the same time-frequency UL resources. 5 In a particular embodiment, a new RNTI type can defined (e.g., OCC-RNTI) which would be used only for a DCI carrying scheduling information targeting a group of one or more UEs scheduled to perform the simultaneous OCC-based transmissions on the same time-frequency UL resources. In a particular embodiment, a UE can be assigned more than one OCC-RNTI and attempts 10 to decode the CRC assuming scrambling with each of its assigned OCC-RNTIs. In all of the above embodiments described in this section, the G-RNTI or OCC-RNTI (or other new type of RNTI) is configured for a UE by provided the G-RNTI, OCC-RNTI (or other new type of RNTI) to the UE using MAC signaling (e.g., using a new MAC CE) and / or in conjunction with a random access procedure, or using RRC signaling (e.g., using an 15 RRCReconfiguration message, an RRCConnectionReconfiguration message, an RRCSetup message, or an RRCConnectionSetup message), or via PDCCH (or NPDCCH) signaling (e.g., in a DCI message). Methods to Configure a Scheduling Offset 20 In a particular embodiment, as part of the scheduling information, when a single DCI is used to schedule two or more UEs, the DCI includes a scheduling delay (e.g., for NB-IoT in NTN, k0 in Table 16.5.1-1 of 3GPP TS 36.213) that equally applies to the one or more UEs scheduled to perform simultaneous OCC-based transmissions on the same time-frequency UL resources. In a particular embodiment, the network (e.g., a network node such as, for example the 25 gNB serving the cell the UE’s are connected in) has previously configured each of the one or more UEs to apply the cell-specific Koffsetwhen the UE is scheduled for UL transmission by scheduling information received in a DCI addressed to an RNTI shared by the one or more UEs (e.g., a G- RNTI or an OCC-RNTI or another new type of RNTI). When the network node configured each of the one or more UEs to use the cell-specific Koffset, the network node may have done this using 30 RRC signaling (e.g., using an RRCReconfiguration message or an RRCSetup message), or using MAC signaling (e.g., a new MAC CE), or using DCI signaling (e.g., on the PDCCH). In yet a variant of this embodiment, the DCI includes an indication (e.g., a single bit set to one) telling the one or more UEs to apply the cell-specific Koffset for the transmission scheduled by the DCI, wherein the cell-specific Koffsetis provided to UEs in the cellSpecificKoffset-r17 IE in the NTN- Config-r17 IE in SIB19 in NR NTN, as per legacy 3GPP specifications. Alternatively, it may be specified in a standard that a UE should use the cell-specific Koffset when the UE is scheduled for UL transmission by scheduling information received in a DCI addressed to an RNTI shared by the one or more UEs (e.g., a G-RNTI or an OCC-RNTI or another new type of RNTI). In a particular embodiment, as part of the scheduling information, the DCI includes a network-controlled scheduling offset (i.e., a Koffset) derived from the average of Timing Advance (TA) reports that were previously reported by the one or more UEs scheduled to perform simultaneous OCC-based transmissions on the same time-frequency UL resources. In a particular embodiment, as part of the scheduling information, the DCI includes a network-controlled scheduling offset (i.e., a Koffset) that corresponds to the maximum TA report among the TA reports that were previously reported by the one or more UEs scheduled to perform simultaneous OCC-based transmissions on the same time-frequency UL resources. Methods To Indicate Frequency Hopping For OCC-Based Transmissions In a particular embodiment, the DCI will indicate frequency hopping length within the UE groups using same resource and different OCC to transmit PUSCH. For example, DCI 0_0 or DCI 0_1 will indicate how many UL slots or UL symbols keep the same frequency that we called frequency hopping length. For inter-slot frequency hopping, the starting RB during slot ^^^ఓis given by: ^^^^^^^^^ , ^^ఓ^^^^^^ ^^^^ ^^^^^^^^^^ℎ = 0^ = ^ ௧^^௧ ^1 FIGURE 7 illustrates an example 600 demonstrating frequency hopping length within the UE groups using same resource and different OCC to transmit PUSCH, according to certain embodiments. Methods for Using Independent DCIs for Scheduling OCC-Based Transmissions on the Same Time-Frequency Resources In a particular embodiment, when independent DCIs are used for scheduling UEs to transmit in UL on the same time-frequency resources using OCC-based transmissions, additional scheduling delay values (delay between control information and user-data, i.e., between (N)PDCCH and (N)PUSCH) are added or re-interpreted into the technical specification in such a way that the DCIs can point out the exact same UL time-frequency resources. In a particular embodiment, using as example NB-IoT in NTN, k0in Table 16.5.1-1 of 3GPP TS 36.213 is updated or re-interpreted as to include consecutive values. For example, as shown in the updated table below, which demonstrates an NB-IoT based example, when four UEs are scheduled to transmit in UL using an OCC-based transmission, then k0 = 8, 9, 10, and 11 are used in DCI#1, DCI#2, DCI#3, and DCI#4, respectively, as to schedule UE1, UE2, UE3, and UE4 on the exact same UL time-frequency resources. Thus, as shown in TABLE 2, scheduling delays indicated via DCI for the four UEs to transmit in UL using OCC-based transmissions (Arrows from top to bottom, corresponding to scheduling delays from k0=8 to k0=11. TABLE 2 Subframe 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 NPDCCH UE1 UE2 UE3 UE4…k0 = k0 = k0 = k0 = 11 10 9 8 NPUSCH UE1 / UE2 / UE3 / UE4 In one NB-IoT NTN specific embodiment, the scheduling delays in Table 16.5.1-1 of 3GPP TS 36.213 are kept unmodified, wherein for two or more UEs to be grouped for transmitting in UL using an OCC-based transmission, once k0 is selected from Table 16.5.1-1, then the scheduling delays used to schedule the grouped UEs are k0, k0+1, … k0+ (Number of grouped UEs -1). For example, if the Number of grouped UEs is 4 and k0= 16 is selected from TABLE 3, which corresponds to Table 16.5.1-1 of 3GPP TS 36.213, then the scheduling delays to be used for the OCC-based transmission are 16, 17, 18, and 19: TABLE 3 IDelay k 00 8 1 16 2 32 3 64 In a particular embodiment, the network entity identifies candidate UEs to be grouped for transmitting in UL on the same time-frequency resources using OCC-based transmissions, once the candidate UEs are selected, the network entity picks up a k0 value from Table 16.5.1-1 (e.g., k0 = 16). Afterwards, the network explicitly assigns consecutive scheduling delay values that are indicated independently via DCI to each of the UEs in the group. For example, in DCI1 k0= 19, DCI2 k0 = 18, DCI3 k0 = 17 and DCI4 k0 = 16. In a particular embodiment, a higher layer parameter can be introduced indicating whether Table 16.5.1-1 in 3GPP TS 36.213 will be interpreted as contiguous scheduling delays A, B, C, or D. For example: ^ When the Higher layer parameter indicates contiguous scheduling delays A, then Table 16.5.1-1 in TS 36.213 is interpreted as shown in TABLE 4: TABLE 4 IDelay k 00 8 1 9 2 10 3 11 ^ When the Higher layer parameter indicates contiguous scheduling delays B, then Table 16.5.1-1 in TS 36.213 is interpreted as shown in TABLE 5: TABLE 5 IDelay k 0 0 16 1 17 2 18 3 19 ^ When the Higher layer parameter indicates contiguous scheduling delays C, then Table 16.5.1-1 in 3GPP TS 36.213 is interpreted as shown in TABLE 6: TABLE 6 IDelay k 00 32 1 33 2 34 3 35 ^ When the Higher layer parameter indicates contiguous scheduling delays D, then Table 16.5.1-1 in 3GPP TS 36.213 is interpreted as shown in TABLE 7: TABLE 7 IDelay k 00 64 1 65 2 66 3 67 In a particular embodiment, Table 16.5.1-1 in 3GPP TS 36.213 is expanded to include more scheduling delays depending on the maximum number of UEs intended to transmit simultaneously on the same time-frequency resources using OCC-based transmissions. For example, a revised Table 16.5.1-1 indicating k0 for DCI format N0 for FDD is shown in TABLE 8: TABLE 8 IDelayk00 8 1 9 2 10 3 11 4 16 5 17 6 18 7 19 8 32 9 33 10 34 11 35 12 64 13 65 14 66 15 67 In a particular embodiment, the 2-bit IDelay parameter in the DCI is kept and an additional 2-bit IDelay2 parameter (i.e., with value range 0-3) is introduced in the DCI. With this embodiment, IDelaypoints out a group of four values. For example, IDelay= 0 points out the group of values {8, 9, 10, 11}, IDelay = 1 points out the group of values {16, 17, 18, 19}, IDelay = 2 points out the group of values {32, 33, 34, 35}, and IDelay = 3 points out the group of values {64, 65, 6667}. Then IDelay2 points out which if the the group of values pointed out by IDelaythat UE should apply. For instance, if IDelay = 1 and thus points out the group of values {16, 17, 18, 19}, and IDelay2 = 2, this means that the UE should apply the third value in the group of values pointed out by IDelay, i.e. the value 18. In a similar particular embodiment, the 2-bit IDelay parameter in the DCI is kept and an additional 2-bit IDelay2 parameter (i.e., with value range 0-3) is introduced in the DCI. With this embodiment, IDelay points out k0 values as in Table 16.5.1-1 in 3GPP TS 36.213, i.e. IDelay = 0 points out k0value 8, IDelay= 1 points out k0value 16, IDelay= 2 points out k0value 32 and IDelay= 3 points out k0 value 64. Then, to arrive at the k0 value the UE should apply, IDelay2 is added to the k0 value pointed out by IDelay. For example, if IDelay = 1, and thus points out k0 value 16, and IDelay2 = 2, then the k0 value the UE should apply is 16 + 2 = 18. DMRS design for IoT-NTN 5 In a particular embodiment, for the slot structure of NPUSCH Format 1 with 3.75 kHz SCS, the DMRS design to be used along with OCC-based UL transmissions accounts for the presence of the Guard Period in such a way that the location of the Guard Period is preserved even after the OCC spreading. In a particular embodiment, regardless of the DMRS distribution used within a slot for 10 NPUSCH Format 1, the location of the Guard Period is preserved before and after the OCC spreading. With regard to the examples depicted in FIGURES 8 to 13, the boxes are illustrated as shown in the key, which is shown in FIGURE 8 and applies to FIGURS 8 through 11, as follows: ^ Patterned boxes represent CP+Data symbols; 15 ^ Solid boxes represent CP+DMRS symbols; and ^ Empty boxes represent Guard Periods. FIGURES 8 and 9 relate to a first example that includes a DMRS distribution having two DMRS symbols per slot in every other slot before OCC spreading. Specifically, FIGURE 8 illustrates the DMRS distribution 700 for the first example before the OCC spreading, according 20 to certain embodiments. FIGURE 9 illustrates the DMRS distribution 800 for the first example after the OCC spreading, while keeping the Guard Period location, according to certain embodiments. FIGURES 10 and 11 relate to a second example that includes DMRS distribution having one DMRS symbol per slot before OCC spreading. Specifically, FIGURE 10 illustrates the DMRS 25 distribution 900 for the second example before the OCC spreading, while keeping the Guard Period location, according to certain embodiments. FIGURE 11 illustrates the DMRS distribution 1000 for the second example after the OCC spreading, while keeping the Guard Period location, according to certain embodiments. FIGURES 12 and 13 relate to at third example that includes a variant of a DMRS 30 distribution having one DMRS symbol per slot before OCC spreading. Specifically, FIGURE 12 illustrates the DMRS distribution of the third example before the OCC spreading, while keeping the Guard Period location, according to certain embodiments. FIGURE 13 illustrates the DMRS distribution of the third example after the OCC spreading, while keeping the Guard Period location, according to certain embodiments. FIGURE 14 illustrates an example method 1300 by a UE for managing resources with 5 OCC-based UL transmissions in NTN, according to certain embodiments. In the illustrated embodiment, the method 1300 includes a receiving step at 1302. For example, at step 1302, the UE may receive, from a network node, one of a plurality of messages comprising scheduling information. The plurality of messages comprising scheduling information is used to schedule the UE to transmit a first UL transmission and at least one other UE to transmit at least one other UL 10 transmission that is orthogonal to the first UL transmission. FIGURE 15 illustrates an example method 1400 by a network node for managing resources with OCC-based UL transmissions in NTN, according to certain embodiments. In the illustrated embodiment, the method 1400 includes a transmitting step at 1402. For example, at step 1402, the network node may transmit, to a plurality of UEs, a message comprising scheduling information. 15 The scheduling information schedules each of the plurality of UEs to transmit a respective one of a plurality of UL transmissions. FIGURE 16 illustrates an example method 1500 performed by a UE for performing an UL transmission that is spread using an OCC in a NTN, according to certain embodiments. In the illustrated embodiment, the method begins at step 1502 when the UE transmits an UL transmission 20 using NPUSCH Format1 with 3.75 kHz SCS. The UL transmission includes at least one data symbol, at least one DMRS symbol, and at least one Guard Period. The location of the guard period within each of the slots of the UL transmission is preserved after OCC spreading is applied to the UL transmission. In other words, the location of the Guard Period is the same before the OCC is applied as it is after the OCC is applied. 25 In a particular embodiment, the NTN comprises an IoT-NTN RAT, for example NB-IoT in NTN. In a particular embodiment, no OCC spreading is applied to the at least one DMRS symbol. In a particular embodiment, a DMRS distribution for the UL transmission comprises a number of DMRS symbols per slot and wherein the number of DMRS symbols per slot is one or 30 two. In a particular embodiment, the UL transmission comprises at least one data symbol, and the method further comprises applying OCC spreading to the at least one data symbol. FIGURE 17 illustrates an example method 1600 performed by a network node for receiving UL transmissions using OCC spreading in a NTN, according to certain embodiments. In the illustrated 5 embodiment, the method begins at step 1602 when the network node receives, from a UE, an UL transmission using NPUSCH Format1 with 3.75 kHz SCS. The UL transmission includes at least one data symbol, at least one DMRS symbol, and at least one Guard Period. The location of the Guard Period within each of the slots of the UUL transmission is preserved after OCC spreading is applied to the UL transmission. In other words, the location of the Guard Period is the same 10 before the OCC is applied as it is after the OCC is applied. In a particular embodiment, the NTN comprises an IoT-NTN. In a particular embodiment, no OCC spreading is applied to the at least one DMRS symbol. In a particular embodiment, a DMRS distribution for the UL transmission comprises a number of DMRS symbols per slot and wherein the number of DMRS symbols per slot is one or 15 two. In a particular embodiment, the UL transmission comprises at least one data symbol, and the method further comprises applying OCC spreading to the at least one data symbol. In a particular embodiment, the network node decodes the UL transmission. For example, the network node may remove the OCC by performing a dispreading operation and then the 20 decoding is performed. FIGURE 18 illustrates an example method 1700 by a network node for managing resources with OCC based UL transmissions in a NTN, according to certain embodiments. In the illustrated embodiment, the method begins at step 1700 when the network node transmits, to a first UE, a first DCI including first scheduling information. The first scheduling information includes a first 25 scheduling delay. At step 1704, the network node transmits, to a second UE, a second DCI that includes second scheduling information, which includes a second scheduling delay. The first scheduling information and the second scheduling information schedule the first and second UEs to transmit first and second OCC-based UL transmissions, respectively, on at least one same time- frequency resource. 30 In a particular embodiment, the first scheduling delay includes a first delay between control information and user data of the first OCC-based UL transmission, and the second scheduling delay comprises a second delay between control information and user data of the second OCC- based UL transmission. In a particular embodiment, the first scheduling delay comprises a first scheduling delay value and the second scheduling delay comprises a second scheduling delay value, and the first 5 and second scheduling delay values are consecutive values. In a particular embodiment, the first and second OCC-based UL transmissions are scheduled to be orthogonal to each other. In a particular embodiment, the network node receives the first and second OCC-based UL transmissions based on the first and second scheduling information, respectively. 10 In a particular embodiment, the first and second UEs are within a group of UEs. In a particular embodiment, the first UE is in a first group of UEs and the second UE is in a second group of UEs. In a particular embodiment, a common group RNTI and / or a OCC-RNTI is assigned to each group of UEs and is indicated in the first and second DCI. 15 In a particular embodiment, the each of the first and second DCI comprise an UL grant. In a particular embodiment, the first DCI indicates a first OCC sequence configured for the first UE and the second DCI indicates a second OCC sequence configured for the second UE. The first OCC sequence is different from the second OCC sequence, and the first UE and the second UE are both in a group of UEs. 20 In a particular embodiment, the first DCI indicates a first UE index configured for the first UE and the second DCI indicates a second UE index configured for the second UE. The first UE index is different from the second UE index. In a particular embodiment, the first DCI indicates a first number of C-RNTI bits associated with the first UE assigned to a first UE index and the second DCI indicates a second number of C- 25 RNTI bits associated with the second UE assigned to a second UE index that is different from the first UE index. In a particular embodiment, the first and second OCC-based UL transmissions comprise simultaneous OCC-based transmissions. In a particular embodiment, at least one of the first and second OCC-based UL 30 transmissions comprises a message3 of a four step RA procedure. In a particular embodiment, at least a portion of a CRC of the first and second DCI is scrambled with a RA-RNTI associated with the first UE, and at least another portion of the CRC is scrambled with a RA-RNTI associated with the second UE. In a particular embodiment, at least a portion of the CRC of the first and second DCI is 5 scrambled with a G-RNTI associated with a group of UEs. In a particular embodiment, the NTN comprises an IoT-NTN. FIGURE 19 illustrates an example method 1800 performed by a UE for transmitting OCC based UL transmissions in a NTN, according to certain embodiments. As illustrated, the method begins at step 1802 when the UE receives, from a network node, a first DCI, which includes first 10 scheduling information. The first scheduling information schedules the first UE to transmit a first OCC-based UL transmission on at least one same time-frequency resource as a second OCC-based UL transmission from a second UE. The first scheduling information includes a first scheduling delay that applies to the first OCC-based UL transmission and is different from a second scheduling delay that applies to the second OCC-based UL transmission. 15 In a particular embodiment, the first scheduling delay includes a first delay between control information and user data of the first OCC-based UL transmission, and the second scheduling delay comprises a second delay between control information and user data of the second OCC- based UL transmission. In a particular embodiment, the first scheduling delay comprises a first scheduling delay 20 value and the second scheduling delay comprises a second scheduling delay value, and the first and second scheduling delay values are consecutive values. In a particular embodiment, the first and second OCC-based UL transmissions are scheduled to be orthogonal to each other. In a particular embodiment, the UE transmits the first and second OCC-based UL 25 transmissions based on the first and second scheduling information, respectively. In a particular embodiment, the first and second UEs are within a group of UEs. In a particular embodiment, the first UE is in a first group of UEs and the second UE is in a second group of UEs. In a particular embodiment, a common group RNTI and / or a OCC-RNTI is assigned to 30 each group of UEs and is indicated in the first and second DCI. In a particular embodiment, the each of the first and second DCI comprise an UL grant. In a particular embodiment, the first DCI indicates a first OCC sequence configured for the first UE and the second DCI indicates a second OCC sequence configured for the second UE. The first OCC sequence is different from the second OCC sequence, and the first UE and the second UE are both in a group of UEs. 5 In a particular embodiment, the first DCI indicates a first UE index configured for the first UE and the second DCI indicates a second UE index configured for the second UE. The first UE index is different from the second UE index. In a particular embodiment, the first DCI indicates a first number of C-RNTI bits associated with the first UE assigned to a first UE index and the second DCI indicates a second number of C- 10 RNTI bits associated with the second UE assigned to a second UE index that is different from the first UE index. In a particular embodiment, the first and second OCC-based UL transmissions comprise simultaneous OCC-based transmissions. In a particular embodiment, at least one of the first and second OCC-based UL 15 transmissions comprises a message3 of a four step RA procedure. In a particular embodiment, at least a portion of a CRC of the first and second DCI is scrambled with a RA-RNTI associated with the first UE, and at least another portion of the CRC is scrambled with a RA-RNTI associated with the second UE. In a particular embodiment, at least a portion of the CRC of the first and second DCI is 20 scrambled with a G-RNTI associated with a group of UEs. In a particular embodiment, the NTN comprises an IoT-NTN. FIGURE 20 shows an example of a communication system 1900 in accordance with some embodiments. In the example, the communication system 1900 includes a telecommunication network 1902 that includes an access network 1904, such as a radio access network (RAN), and a 25 core network 1906, which includes one or more core network nodes 1908. The access network 1904 includes one or more access network nodes, such as network nodes 1910a and 1910b (one or more of which may be generally referred to as network nodes 1910), or any other similar 3rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes 1910 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 30 1912a, 1912b, 1912c, and 1912d (one or more of which may be generally referred to as UEs 1912) to the core network 1906 over one or more wireless connections. Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 1900 may 5 include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 1900 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system. 10 The UEs 1912 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 1910 and other communication devices. Similarly, the network nodes 1910 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 1912 and / or with other network nodes or equipment in the telecommunication network 1902 to enable and / or 15 provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 1902. In the depicted example, the core network 1906 connects the network nodes 1910 to one or more hosts, such as host 1916. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to 20 hosts. The core network 1906 includes one more core network nodes (e.g., core network node 1908) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1908. Example core network nodes include functions of one or more of 25 a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF). 30 The host 1916 may be under the ownership or control of a service provider other than an operator or provider of the access network 1904 and / or the telecommunication network 1902 and may be operated by the service provider or on behalf of the service provider. The host 1916 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics 5 functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server. As a whole, the communication system 1900 of FIGURE 20 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but 10 are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as 15 the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox. In some examples, the telecommunication network 1902 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 1902 may 20 support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1902. For example, the telecommunications network 1902 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive IoT services to yet further UEs. 25 In some examples, the UEs 1912 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1904 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1904. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may 30 operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio – Dual Connectivity (EN-DC). In the example, the hub 1914 communicates with the access network 1904 to facilitate indirect communication between one or more UEs (e.g., UE 1912c and / or 1912d) and network 5 nodes (e.g., network node 1910b). In some examples, the hub 1914 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1914 may be a broadband router enabling access to the core network 1906 for the UEs. As another example, the hub 1914 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be 10 received from the UEs, network nodes 1910, or by executable code, script, process, or other instructions in the hub 1914. As another example, the hub 1914 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1914 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 1914 15 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1914 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 1914 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy IoT devices. 20 The hub 1914 may have a constant / persistent or intermittent connection to the network node 1910b. The hub 1914 may also allow for a different communication scheme and / or schedule between the hub 1914 and UEs (e.g., UE 1912c and / or 1912d), and between the hub 1914 and the core network 1906. In other examples, the hub 1914 is connected to the core network 1906 and / or one or more UEs via a wired connection. Moreover, the hub 1914 may be configured to connect 25 to an M2M service provider over the access network 1904 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1910 while still connected via the hub 1914 via a wired or wireless connection. In some embodiments, the hub 1914 may be a dedicated hub – that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 1910b. In other embodiments, 30 the hub 1914 may be a non-dedicated hub – that is, a device which is capable of operating to route communications between the UEs and network node 1910b, but which is additionally capable of operating as a communication start and / or end point for certain data channels. FIGURE 21 shows a UE 2000, which may be an embodiment of the UE 112 of FIGURE 20, in accordance with some embodiments. 5 As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, 10 mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE. 15 A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or 20 operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter). The UE 2000 includes processing circuitry 2002 that is operatively coupled via a bus 2004 25 to an input / output interface 2006, a power source 2008, a memory 2010, a communication interface 2012, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in FIGURE 21. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc. 30 The processing circuitry 2002 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 2010. The processing circuitry 2002 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field- programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, 5 general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 2002 may include multiple central processing units (CPUs). In the example, the input / output interface 2006 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. 10 Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 2000. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a 15 directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus 20 (USB) port may be used to provide an input device and an output device. In some embodiments, the power source 2008 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 2008 may further include power circuitry for delivering power from the power source 2008 itself, and / or an external power source, 25 to the various parts of the UE 2000 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 2008. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 2008 to make the power suitable for the respective components of the UE 2000 to which power is supplied. 30 The memory 2010 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 2010 includes one or more application programs 2014, such as an operating system, web browser application, a widget, gadget engine, or other 5 application, and corresponding data 2016. The memory 2010 may store, for use by the UE 2000, any of a variety of various operating systems or combinations of operating systems. The memory 2010 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc 10 drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any 15 combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 2010 may allow the UE 2000 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 20 2010, which may be or comprise a device-readable storage medium. The processing circuitry 2002 may be configured to communicate with an access network or other network using the communication interface 2012. The communication interface 2012 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 2022. The communication interface 2012 may include one or more 25 transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 2018 and / or a receiver 2020 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 2018 and receiver 2020 may be coupled to 30 one or more antennas (e.g., antenna 2022) and may share circuit components, software or firmware, or alternatively be implemented separately. In the illustrated embodiment, communication functions of the communication interface 2012 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of 5 the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), 10 synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth. Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 2012, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network 15 node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected, an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient). As another example, a UE comprises an actuator, a motor, or a switch, related to a 20 communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input. 25 A UE, when in the form of an Internet of Things (IoT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart 30 speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item- 5 tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and / or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE 2000 shown in FIGURE 21. 10 As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a 15 vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation. In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information 20 (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the 25 speed sensor and the actuators. FIGURE 18 shows a network node 2100, which may be an embodiment of the network node 1910 of FIGURE 5, in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication 30 network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)). Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, 5 may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an 10 antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS). Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations 15 (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs). The network node 2100 includes a processing circuitry 2102, a memory 2104, a 20 communication interface 2106, and a power source 2108. The network node 2100 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 2100 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components 25 may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 2100 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 2104 for different RATs) and some 30 components may be reused (e.g., a same antenna 2110 may be shared by different RATs). The network node 2100 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 2100, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 2100. 5 The processing circuitry 2102 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 2100 components, such as the 10 memory 2104, to provide network node 2100 functionality. In some embodiments, the processing circuitry 2102 includes a system on a chip (SOC). In some embodiments, the processing circuitry 2102 includes one or more of radio frequency (RF) transceiver circuitry 2112 and baseband processing circuitry 2114. In some embodiments, the radio frequency (RF) transceiver circuitry 2112 and the baseband processing circuitry 2114 may be on 15 separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 2112 and baseband processing circuitry 2114 may be on the same chip or set of chips, boards, or units. The memory 2104 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted 20 memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 2102. The 25 memory 2104 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 2102 and utilized by the network node 2100. The memory 2104 may be used to store any calculations made by the processing circuitry 2102 and / or any data received via the communication interface 2106. In some 30 embodiments, the processing circuitry 2102 and memory 2104 is integrated. The communication interface 2106 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 2106 comprises port(s) / terminal(s) 2116 to send and receive data, for example to and from a network over a wired connection. The communication interface 2106 also includes radio 5 front-end circuitry 2118 that may be coupled to, or in certain embodiments a part of, the antenna 2110. Radio front-end circuitry 2118 comprises filters 2120 and amplifiers 2122. The radio front- end circuitry 2118 may be connected to an antenna 2110 and processing circuitry 2102. The radio front-end circuitry may be configured to condition signals communicated between antenna 2110 and processing circuitry 2102. The radio front-end circuitry 2118 may receive digital data that is 10 to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 2118 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 2120 and / or amplifiers 2122. The radio signal may then be transmitted via the antenna 2110. Similarly, when receiving data, the antenna 2110 may collect radio signals which are then converted into digital data by the radio front-end circuitry 15 2118. The digital data may be passed to the processing circuitry 2102. In other embodiments, the communication interface may comprise different components and / or different combinations of components. In certain alternative embodiments, the network node 2100 does not include separate radio front-end circuitry 2118, instead, the processing circuitry 2102 includes radio front-end circuitry 20 and is connected to the antenna 2110. Similarly, in some embodiments, all or some of the RF transceiver circuitry 2112 is part of the communication interface 2106. In still other embodiments, the communication interface 2106 includes one or more ports or terminals 2116, the radio front- end circuitry 2118, and the RF transceiver circuitry 2112, as part of a radio unit (not shown), and the communication interface 2106 communicates with the baseband processing circuitry 2114, 25 which is part of a digital unit (not shown). The antenna 2110 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 2110 may be coupled to the radio front-end circuitry 2118 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 2110 is separate from the network node 2100 and 30 connectable to the network node 2100 through an interface or port. The antenna 2110, communication interface 2106, and / or the processing circuitry 2102 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, 5 the antenna 2110, the communication interface 2106, and / or the processing circuitry 2102 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment. The power source 2108 provides power to the various components of network node 2100 10 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 2108 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 2100 with power for performing the functionality described herein. For example, the network node 2100 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input 15 circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 2108. As a further example, the power source 2108 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail. 20 Embodiments of the network node 2100 may include additional components beyond those shown in FIGURE 22 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 2100 may include user interface equipment to allow input of information into the network node 2100 and to allow output of 25 information from the network node 2100. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 2100. FIGURE 23 is a block diagram illustrating a virtualization environment 2200 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or 30 devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 2200 hosted by one or more of 5 hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. Applications 2202 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the 10 virtualization environment 2200 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. Hardware 2204 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may 15 be executed by the processing circuitry to instantiate one or more virtualization layers 2206 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 2208a and 2208b (one or more of which may be generally referred to as VMs 2208), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 2206 may present a virtual operating platform that appears like networking 20 hardware to the VMs 2208. The VMs 2208 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 2206. Different embodiments of the instance of a virtual appliance 2202 may be implemented on one or more of VMs 2208, and the implementations may be made in different ways. Virtualization of the 25 hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment. In the context of NFV, a VM 2208 may be a software implementation of a physical machine 30 that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 2208, and that part of hardware 2204 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 2208 on top of the hardware 2204 and corresponds to the application 2202. 5 Hardware 2204 may be implemented in a standalone network node with generic or specific components. Hardware 2204 may implement some functions via virtualization. Alternatively, hardware 2204 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 2210, which, among others, oversees lifecycle management of applications 2202. In some 10 embodiments, hardware 2204 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some 15 signaling can be provided with the use of a control system 2212 which may alternatively be used for communication between hardware nodes and radio units. It is recognized that the ORAN aspects disclosed herein are relevant to NTN embodiments since a satellite may either house just the RF functions (transparent architecture) or any RU / DU parts up to and including a whole gNB. FIGURE 24 illustrates a transparent or bent pipe 20 architecture on the left and a regenerative architecture on the right, according to certain embodiments. It is recognized that any embodiments and / or functions described herein as relating to NTN and as being performed by the network node (such as, for example a gNB or base station) may be distributed between terrestrial parts including the gateway and satellite parts (NTN payload). 25 Section 16.14 of 3GPP TS 38.300 V18.1.0 describes NTNs and is incorporated herein by reference. Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed 30 to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, 5 while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may 10 be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware. In certain embodiments, some or all of the functionality described herein may be provided 15 by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether 20 executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally. 25 EXAMPLE EMBODIMENTS Example Embodiment C1. A method performed by a user equipment (UE) for managing resources with OCC-based UL transmissions in a NTN, the method comprising: receiving, from a network node, one of a plurality of messages comprising scheduling information, wherein the 30 plurality of messages comprising scheduling information is used to schedule the UE to transmit a first UL transmission and at least one other UE to transmit at least one other UL transmission that is orthogonal to the first UL transmission. Example Embodiment C2.The method of Example Embodiment C1, comprising transmitting the at least one UL transmission based on one of the plurality of messages comprising the scheduling information.Example Embodiment C3. The method of any one of Example Embodiments C1 to C2, wherein the scheduling information 5 indicates at least one time and / or frequency resource to be used for the UL transmission by the UE and the at least one other UL transmission by the at least one other UE. Example Embodiment C4. The method of Example Embodiment C3,wherein the time and / or frequency resources to be used for the UL transmission by the UE overlaps entirely with the time and / or frequency resources to be used for the at least one other transmission by the at least one other UE. Example Embodiment 10 C5. The method of Example Embodiment C3,wherein the time and / or frequency resources to be used for the UL transmission by the UE partially overlaps with the time and / or frequency resources to be used for the at least one other transmission by the at least one other UE. Example Embodiment C6. The method of any one of Example Embodiments C1 to C5, wherein the plurality of messages comprise a common message.Example Embodiment C7. The method of 15 any one of Example Embodiments C1 to C6, wherein the plurality of messages are transmitted via DCI.Example Embodiment C8. The method of any one of Example Embodiments C1 to C7, wherein the UE and the at least one other UE are within a group of UEs. Example Embodiment C9. The method of any one of Example Embodiments C1 to C7, wherein the UE is in a first group of UEs and the at least one other is within a second group of UEs. Example Embodiment 20 C10. The method of any one of Example Embodiments C8 to C9, wherein a common group RNTI and / or a OCC-RNTI is assigned to each group of UEs and is indicated in the plurality of messages.Example Embodiment C11.The method of any one of Example Embodiments C1 to C10, wherein the each of the plurality of messages comprise an UL grant.Example Embodiment C12.The method of any one of Example Embodiment C1 to C11, wherein the one message of the 25 plurality of messages indicates an OCC sequence configured for the UE that is different from each OCC sequence configured for each other UE in a group of UEs.Example Embodiment C13.The method of any one of Example Embodiments C1 to C12, wherein the one message of the plurality of messages indicates a UE index configured for the UE that is different from the UE index configured for the at least one other UE. Example Embodiment C14.The method of any one of 30 Example Embodiments C1 to C13, wherein the one message of the plurality of messages indicates a number of C-RNTI bits associated with the UE, and wherein the UE uses the C-RNTI bits to identify an UE index that is different from each UE index configured for each other UE in a group of UEs. Example Embodiment C15. The method of any one of Example Embodiments C1 to C14, wherein the UL transmission and the at least one other transmission comprise simultaneous OCC- based transmissions. Example Embodiment C16. The method of any one of Example 5 Embodiments C1 to C15, wherein the UL transmission comprises a message3 of a four step RA procedure. Example Embodiment C17. The method of any one of Example Embodiments C1 to C16, wherein at least a portion of the CRC of the one message of the plurality of messages is scrambled with a RA-RNTI associated with the UE, and wherein at least another portion of the CRC is scrambled with a RA-RNTI associated with the at least one other UE. Example 10 Embodiment C18. The method of any one of Example Embodiments C1 to C16, wherein at least a portion of the CRC of the one message of the plurality of messages is scrambled with a G- RNTI associated with a group of UE that includes the UE and the at least one other UE. Example Embodiment C19.The method of any one of Example Embodiments C1 to C18, comprising decoding the one message of the plurality of messages using at least one OCC-RNTI assigned to 15 the UE.Example Emboidment C20A. The method of any one of Example Embodiments C1 to C19, wherein the one message of the plurality of messages comprises a scheduling delay that applies to the UL transmission by the UE and the at least one other UL transmission by the at least tone other UE. Example Emboidment C20B. The method of any one of Example Embodiments C1 to C20A, wherein the NTN comprises an IoT-NTN. Example Emboidment C20C. The method of 20 any one of Example Embodiments C1 to C20A, wherein the NTN comprises an NR-NTN. Example Embodiment C21. The method of Example Embodiments C1 to C20C, further comprising: providing user data; and forwarding the user data to a host via the transmission to the network node.Example Embodiment C22. A user equipment comprising processing circuitry configured to perform any of the methods of Example Embodiments C1 to C21.Example 25 Embodiment C23. A user equipment configured to perform any of the methods of Example Embodiments C1 to C21. Example Embodiment C24. A wireless device comprising processing circuitry configured to perform any of the methods of Example Embodiments C1 to C21. Example Embodiment C25. A computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments C1 to C21. 30 Example Embodiment C26. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments C1 to C21. Example Embodiment C27. A non- transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of Example Embodiments C1 to C21. Example Embodiment D1. A method performed by a network node for managing resources with OCC-based UL transmissions 5 in a NTN, the method comprising: transmitting, to a plurality of UEs, a message comprising scheduling information, wherein the scheduling information schedules each of the plurality of UEs to transmit a respective one of a plurality of UL transmissions. Example Embodiment D2. The method of Example Embodiment D1, wherein the plurality of UL transmissions are scheduled to be orthogonal to each other.Example Embodiment D3. The method of any one of Example 10 Embodiments D1 to D2, comprising receiving the plurality of UL transmissions based on the scheduling information.Example Embodiment D4. The method of any one of Example Embodiments D1 to D3, wherein the scheduling information indicates at least one time and / or frequency resource to be used for the plurality of UL transmissions by the plurality of UEs. Example Embodiment D5. The method of Example Embodiment D4,wherein the time and / or 15 frequency resources to be used for each of the plurality of UL transmissions overlaps entirely with each other. Example Embodiment D6. The method of Example Embodiment D4,wherein the time and / or frequency resources to be used for each of the plurality of UL transmissions partially overlaps with each other. Example Embodiment D7. The method of any one of Example Embodiments D1 to D6, wherein the plurality of messages comprise a common message. Example 20 Embodiment D8. The method of any one of Example Embodiments D1 to D7, wherein the plurality of messages are transmitted via DCI. Example Embodiment D9. The method of any one of Example Embodiments D1 to D8, wherein the plurality of UEs are within a group of UEs. Example Embodiment D10. The method of any one of Example Embodiments D1 to D8, wherein a first UE of the plurality of UEs is in a first group of UEs and a second UE of the plurality of UEs 25 is in a second group of UEs. Example Embodiment D11. The method of any one of Example Embodiments D9 to D10, wherein a common group RNTI and / or a OCC-RNTI is assigned to each group of UEs and is indicated in the plurality of messages. Example Embodiment D12. The method of any one of Example Embodiments D1 to D11, wherein the each of the plurality of messages comprise an UL grant. Example Embodiment D13. The method of any one of 30 Example Embodiment D1 to D12, wherein the plurality of messages indicates a first OCC sequence configured for a first UE and a second OCC sequence configured for a second UE, wherein the first OCC sequence is different from the second OCC sequence, and wherein the first UE and the second UE are both in a group of UEs. Example Embodiment D14. The method of any one of Example Embodiments D1 to D13, wherein the plurality of messages indicate a first UE index configured for a first UE and a second UE index configured for a second UE, wherein 5 the first UE index is different from the second UE index. Example Embodiment D15. The method of any one of Example Embodiments D1 to D14, wherein the plurality of messages indicate a first number of C-RNTI bits associated with a first UE assigned to a first UE index and a second number of C-RNTI bits associated with a second UE assigned to a second UE index that is different from the first UE index. Example Embodiment D16. The method of any one of 10 Example Embodiments D1 to D15, wherein the plurality of UL transmissions comprise simultaneous OCC-based transmissions. Example Embodiment D17. The method of any one of Example Embodiments D1 to D16, wherein at least one of the plurality of UL transmissions comprises a message3 of a four step RA procedure. Example Embodiment D18. The method of any one of Example Embodiments D1 to D17, wherein at least a portion of a CRC of the plurality 15 of messages is scrambled with a RA-RNTI associated with a first UE, and wherein at least another portion of the CRC is scrambled with a RA-RNTI associated with a second UE. Example Embodiment D19. The method of any one of Example Embodiments D1 to D17, wherein at least a portion of the CRC of the plurality of messages is scrambled with a G-RNTI associated with a group of UEs. Example Emboidment D20A. The method of any one of Example 20 Embodiments D1 to D19, wherein the plurality of messages comprises a scheduling delay that applies to the plurality of UL transmissions. Example Emboidment D20B. The method of any one of Example Embodiments D1 to D20A, wherein the NTN comprises an IoT-NTN. Example Emboidment D20C. The method of any one of Example Embodiments D1 to D20A, wherein the NTN comprises an NR-NTN. Example Embodiment D21. The method of any of the previous 25 Example Embodiments, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment. Example Embodiment D22. A network node comprising processing circuitry configured to perform any of the methods of Example Embodiments D1 to D21.Example Embodiment D23. A network node configured to perform any of the methods of Example Embodiments D1 to D21.Example Embodiment D24. A computer program 30 comprising instructions which when executed on a computer perform any of the methods of Example Embodiments D1 to D21. Example Embodiment D25. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments D1 to D21. Example Embodiment D26. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of Example Embodiments D1 to 5 D21. Example Embodiment E1. A system for managing resources with OCC-based UL transmissions in a NTN, the method comprising: a network node configured to transmit, to a plurality of UEs, a common message comprising scheduling information for a plurality of UL transmissions; a first UE configured to: receive, from the network node, a first one of the plurality of messages comprising the scheduling information, based on the scheduling information, transmit 10 a first UL transmission; and a second UE configured to: receive, from the network node, a second one of the plurality of messages comprising the scheduling information, based on the scheduling information, transmit a second UL transmission that is orthogonal to the first UL transmission. Example Embodiment E2. The system of Example Embodiment E1, wherein the plurality of UL transmissions are scheduled to be orthogonal to each other.Example Embodiment E3. The 15 system of any one of Example Embodiments E1 to E2, wherein the network node is configured to receive the first and second UL transmissions based on the scheduling information.Example Embodiment E4. The system of any one of Example Embodiments E1 to E3, wherein the scheduling information indicates at least one time and / or frequency resource to be used for the plurality of UL transmissions by the plurality of UEs. Example Embodiment E5. The system of 20 Example Embodiment E4,wherein the time and / or frequency resources to be used for each of the plurality of UL transmissions overlaps entirely with each other. Example Embodiment E6. The system of Example Embodiment E4,wherein the time and / or frequency resources to be used for each of the plurality of UL transmissions partially overlaps with each other. Example Embodiment E7. The system of any one of Example Embodiments E1 to E6, wherein the common message 25 is transmitted to the plurality of UEs via DCI. Example Embodiment E8. The system of any one of Example Embodiments E1 to E7, wherein the plurality of UEs are within a group of UEs. Example Embodiment E9. The system of any one of Example Embodiments E1 to E7, wherein the first UE s is in a first group of UEs and the second UE is in a second group of UEs. Example Embodiment E10. The system of any one of Example Embodiments E8 to E9, wherein a 30 common group RNTI and / or a OCC-RNTI is assigned to each group of UEs and is indicated in the plurality of messages. Example Embodiment E11. The system of any one of Example Embodiments E1 to E10, wherein the each of the plurality of messages comprise an UL grant. Example Embodiment E12. The system of any one of Example Embodiments E1 to E11, wherein the plurality of messages indicates a first OCC sequence configured for the first UE and a second OCC sequence configured for the second UE, wherein the first OCC sequence is different 5 from the second OCC sequence, and wherein the first UE and the second UE are both in a group of UEs. Example Embodiment E13. The system of any one of Example Embodiments E1 to E12, wherein the common message indicates: a first UE index configured for the first UE, and a second UE index configured for a second UE, wherein the first UE index is different from the second UE index. Example Embodiment E14. The system of any one of Example Embodiments E1 to E13, 10 wherein the common message indicates: a first number of C-RNTI bits associated with the first UE assigned to a first UE index, and a second number of C-RNTI bits associated with a second UE assigned to a second UE index that is different from the first UE index. Example Embodiment E15. The system of any one of Example Embodiments E1 to E14, wherein the plurality of UL transmissions comprise simultaneous OCC-based transmissions. Example Embodiment E16. The 15 system of any one of Example Embodiments E1 to E15, wherein at least one of the plurality of UL transmissions comprises a message3 of a four step RA procedure. Example Embodiment E17.The system of any one of Example Embodiments E1 to E16, wherein at least a portion of a CRC of common message is scrambled with a RA-RNTI associated with a first UE, and wherein at least another portion of the CRC is scrambled with a RA-RNTI associated with a second UE. Example 20 Embodiment E18. The system of any one of Example Embodiments E1 to E17, wherein at least a portion of the CRC of the plurality of messages is scrambled with a G-RNTI associated with a group of UEs. Example Emboidment E19. The system of any one of Example Embodiments E1 to E18, wherein the common message comprises a scheduling delay that applies to the plurality of UL transmissions. Example Emboidment C20. The system of any one of 25 Example Embodiments C1 to C19, wherein the NTN comprises an IoT-NTN. Example Emboidment C21. The system of any one of Example Embodiments C1 to C19, wherein the NTN comprises an NR-NTN. Example Embodiment E22. The method of any of the previous Example Embodiments, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment. Example Embodiment F1. A user equipment for managing resources 30 with OCC-based UL transmissions in NTN, the UE comprising: processing circuitry configured to perform any of the steps of any of the A, C, and E Example Embodiments; and power supply circuitry configured to supply power to the processing circuitry.Example Embodiment F2. A network node for managing resources with OCC-based UL transmissions in NTN, the network node comprising: processing circuitry configured to perform any of the steps of any of the B, D, and E Example Embodiments; power supply circuitry configured to supply power to the processing 5 circuitry. Example Embodiment F3. A user equipment (UE) for managing resources with OCC- based UL transmissions in NTN, the UE comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform any of the steps of any of the Group A, C, 10 and E Example Embodiments; an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE. Example Embodiment F4.A host 15 configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; and a network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment (UE), wherein the UE comprises a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any 20 of the steps of any of the Group A, C, and E Example Embodiments to receive the user data from the host. Example Embodiment F5. The host of the previous Example Embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit the user data to the UE from the host. Example Embodiment F6. The host of the previous 2 Example Embodiments, wherein: the processing circuitry of the host is configured to 25 execute a host application, thereby providing the user data; and the host application is configured to interact with a client application executing on the UE, the client application being associated with the host application. Example Embodiment F7. A method implemented by a host operating in a communication system that further includes a network node and a user equipment (UE), the method comprising: providing user data for the UE; and initiating a transmission carrying the user 30 data to the UE via a cellular network comprising the network node, wherein the UE performs any of the operations of any of the Group A embodiments to receive the user data from the host. Example Embodiment F8. The method of the previous Example Embodiment, further comprising: at the host, executing a host application associated with a client application executing on the UE to receive the user data from the UE. Example Embodiment F9. The method of the previous Example Embodiment, further comprising: at the host, transmitting input data to the client 5 application executing on the UE, the input data being provided by executing the host application, wherein the user data is provided by the client application in response to the input data from the host application. Example Embodiment F10. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; and a network interface configured to initiate transmission of the 10 user data to a cellular network for transmission to a user equipment (UE), wherein the UE comprises a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any of the steps of any of the Group A, C, and E Example Embodiments to transmit the user data to the host. Example Embodiment F11. The host of the previous Example Embodiment, wherein the cellular network further 15 includes a network node configured to communicate with the UE to transmit the user data from the UE to the host. Example Embodiment F12. The host of the previous 2 Example Embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the user data; and the host application is configured to interact with a client application executing on the UE, the client application being associated with the host 20 application. Example Embodiment F13. A method implemented by a host configured to operate in a communication system that further includes a network node and a user equipment (UE), the method comprising: at the host, receiving user data transmitted to the host via the network node by the UE, wherein the UE performs any of the steps of any of the Group A, C, and E Example Embodiments to transmit the user data to the host. Example Embodiment F14. The 25 method of the previous Example Embodiment, further comprising: at the host, executing a host application associated with a client application executing on the UE to receive the user data from the UE. Example Embodiment F15. The method of the previous Example Embodiment, further comprising: at the host, transmitting input data to the client application executing on the UE, the input data being provided by executing the host application, wherein the user data is provided by 30 the client application in response to the input data from the host application. Example Embodiment F16. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; and a network interface configured to initiate transmission of the user data to a network node in a cellular network for transmission to a user equipment (UE), the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any 5 of the operations of any of the Group B, D, and E Example Embodiments to transmit the user data from the host to the UE. Example Embodiment F17. The host of the previous Example Embodiment, wherein: the processing circuitry of the host is configured to execute a host application that provides the user data; and the UE comprises processing circuitry configured to execute a client application associated with the host application to receive the transmission of user 10 data from the host. Example Embodiment F18. A method implemented in a host configured to operate in a communication system that further includes a network node and a user equipment (UE), the method comprising: providing user data for the UE; and initiating a transmission carrying the user data to the UE via a cellular network comprising the network node, wherein the network node performs any of the operations of any of the Group B, D, and E Example Embodiments to 15 transmit the user data from the host to the UE. Example Embodiment F19. The method of the previous Example Embodiment, further comprising, at the network node, transmitting the user data provided by the host for the UE. Example Embodiment F20. The method of any of the previous 2 Example Embodiments, wherein the user data is provided at the host by executing a host application that interacts with a client application executing on the UE, the client application 20 being associated with the host application. Example Embodiment F21. A communication system configured to provide an over-the-top service, the communication system comprising: a host comprising: processing circuitry configured to provide user data for a user equipment (UE), the user data being associated with the over-the-top service; and a network interface configured to initiate transmission of the user data toward a cellular network node for transmission to the UE, 25 the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group B, D, and E Example Embodiments to transmit the user data from the host to the UE. Example Embodiment F22. The communication system of the previous Example Embodiment, further comprising: the network node; and / or the user equipment. Example Embodiment F23. A host 30 configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to initiate receipt of user data; and a network interface configured to receive the user data from a network node in a cellular network, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group B, D, and E Example Embodiments to receive the user data from a user equipment (UE) for the host. Example 5 Embodiment F24. The host of the previous 2 Example Embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the user data; and the host application is configured to interact with a client application executing on the UE, the client application being associated with the host application. Example Embodiment F25. The host of the any of the previous 2 Example Embodiments, wherein the initiating receipt of the user 10 data comprises requesting the user data. Example Embodiment F26. A method implemented by a host configured to operate in a communication system that further includes a network node and a user equipment (UE), the method comprising: at the host, initiating receipt of user data from the UE, the user data originating from a transmission which the network node has received from the UE, wherein the network node performs any of the steps of any of the Group B, D, and E Example 15 Embodiments to receive the user data from the UE for the host. Example Embodiment F27. The method of the previous Example Embodiment, further comprising at the network node, transmitting the received user data to the host.

Claims

CLAIMS 1. A method (1500) performed by a User Equipment, UE, (1912, 2000) for performing an uplink transmission that is spread using an Orthogonal Cover Code, OCC in a Non-Terrestrial Network, NTN, the method comprising: 5 transmitting (1502) an uplink transmission using Narrowband Physical Uplink Shared Channel, NPUSCH, Format1 with 3.75 kHz subcarrier spacing, SCS, wherein the uplink transmission comprises at least one data symbol, at least one Demodulation Reference Signal, DMRS, symbol, and at least one guard period; wherein the location of the guard period within each of the slots comprising the uplink transmission is preserved after OCC spreading is applied to the uplink transmission.

2. The method of Claim 1, wherein the NTN comprises an Internet-of-Things-NTN, IoT-NTN radio access technology (RAT), for example Narrowband Internet of things (NB-IoT) in NTN.

3. The method of any one of Claims 1 to 2, wherein no OCC spreading is applied to the at least one DMRS symbol.

4. The method of any one of Claims 1 to 3, wherein a DMRS distribution for the uplink transmission comprises a number of DMRS symbols per slot and wherein the number of DMRS symbols per slot is one or two.

5. The method of any one of Claims 1 to 4, wherein the uplink transmission comprises at least one data symbol, and the method further comprises applying OCC spreading to the at least one data symbol.

6. A method (1600) performed by a network node (1910, 2100) for receiving uplink transmissions using Orthogonal Cover Code, OCC, spreading in a Non-Terrestrial Network, NTN, the method comprising: receiving (1602), from a User Equipment, UE, (1912) an uplink transmission using Narrowband Physical Uplink Shared Channel, NPUSCH, Format1 with 3.75 kHz subcarrier spacing, SCS, wherein the uplink transmission comprises at least one data symbol, at least one Demodulation Reference Signal, DMRS, symbol, and at least one guard period;wherein the location of the guard period within each of the slots comprising the uplink transmission is preserved after OCC spreading is applied to the uplink transmission.

7. The method of Claim 6, wherein the NTN comprises an Internet-of-Things-NTN, IoT- NTN. 5 8. The method of any one of Claims 6 to 7, wherein no OCC spreading is applied to the at least one DMRS symbol.

9. The method of any one of Claims 6 to 8, wherein a DMRS distribution for the uplink transmission comprises a number of DMRS symbols per slot and wherein the number of DMRS symbols per slot is one or two.

10. The method of any one of Claims 6 to 9, wherein the uplink transmission comprises at least one data symbol, and the method further comprises applying OCC spreading to the at least one data symbol.

11. The method of any one of Claims 6 to 10, comprising a dispreading operation followed by successfully decoding the uplink transmission.

12. A User Equipment, UE, (1912, 2000) for performing Orthogonal Cover Code, OCC, spreading for uplink transmissions in a Non-Terrestrial Network, NTN, the UE comprising a memory (2010) and processing circuitry (2002), the UE configured to: transmit an uplink transmission using Narrowband Physical Uplink Shared Channel, NPUSCH, Format1 with 3.75 kHz subcarrier spacing, SCS, wherein the uplink transmission comprises at least one Demodulation Reference Signal, DMRS, symbol, and wherein a location of the guard period is preserved after OCC spreading is applied to the uplink transmission.

13. The UE of Claim 12, wherein the NTN comprises an Internet-of-Things-NTN, IoT-NTN radio access technology (RAT), for example Narrowband Internet of things (NB-IoT) in NTN.

14. The UE of any one of Claims 12 to 13, wherein no OCC spreading is applied to the at least one DMRS symbol.

15. The UE of any one of Claims 12 to 14, wherein a DMRS distribution for the uplink transmission comprises a number of DMRS symbols per slot and wherein the number of DMRS symbols per slot is one or two.

16. The UE of any one of Claims 12 to 15 wherein the uplink transmission comprises at least 5 one data symbol, and the method further comprises applying OCC spreading to the at least one data symbol.

17. A network node (1910, 2100) for receiving uplink transmissions using Orthogonal Cover Code, OCC, spreading in a Non-Terrestrial Network, NTN, the network node comprising memory (2104) and processing circuitry (2102), the network node configured to: receive, from a User Equipment, UE, (1912, 2000) an uplink transmission using Narrowband Physical Uplink Shared Channel, NPUSCH, Format1 with 3.75 kHz subcarrier spacing, SCS, wherein the uplink transmission comprises at least one data symbol, at least one Demodulation Reference Signal, DMRS, symbol, and at least one guard period; wherein a location of the guard period within each of the slots comprising the uplink transmission is preserved after OCC spreading is applied to the uplink transmission.

18. The network node of Claim 17, wherein the NTN comprises an Internet-of-Things-NTN, IoT-NTN.

19. The network node of any one of Claims 17 to 18, wherein no OCC spreading is applied to the at least one DMRS symbol.

20. The network node of any one of Claims 17 to 19, wherein a DMRS distribution for the uplink transmission comprises a number of DMRS symbols per slot and wherein the number of DMRS symbols per slot is one or two.

21. The network node of any one of Claims 17 to 20, wherein the uplink transmission comprises at least one data symbol, and the method further comprises applying OCC spreading to the at least one data symbol.

22. The network node of any one of Claims 17 to 21, configured to decode the uplink transmission.

23. A system (1900) for Orthogonal Cover Code, OCC, spreading for uplink transmissions in a Non-Terrestrial Network, NTN, the method comprising: a User Equipment, UE, (1912, 2000) configured to transmit an uplink transmission using Narrowband Physical Uplink Shared Channel, NPUSCH, Format1 with 3.75 kHz subcarrier 5 spacing, SCS; and a network node (1910, 2100) configured to receive the uplink transmission, and wherein the uplink transmission comprises at least one data symbol, at least one Demodulation Reference Signal, DMRS, symbol, and at least one guard period; wherein a location of a guard period within each of the slots comprising the uplink transmission is preserved after OCC spreading is applied to the uplink transmission.

Images