Orthogonal cover code management in a network

Abstract

Provided are system, method, and device for automatically manage orthogonal cover code (OCC). According to example embodiments, the system may include a base station. The base station may be configured to receive, from a plurality of user equipment (UEs), a status notification specifying an orthogonal cover code (OCC) length associated with the respective UE. The base station may also be configured to assign each of the plurality of UEs to one of a plurality of OCC groups based on the OCC length associated with the respective UE, such that OCC lengths of all UEs in a particular OCC group are same. The base station may also be configured to allocate physical resource blocks (PRBs) to the plurality of UEs based on an OCC group assigned to the respective UE.

Description

ORTHOGONAL COVER CODE MANAGEMENT IN A NETWORK CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application No.63 / 754,788, filed with the U.S. Patent and Trademark Office on February 6, 2025, the entire contents of which are incorporated herein by reference.FIELD

[0002] The present disclosure relates to the management of orthogonal cover code (OCC) in a telecommunications network.BACKGROUND

[0003] The information disclosed in this background section is only for enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0004] An orthogonal cover code (OCC) may refer to a coding technique applied to an uplink transmission from a user equipment (UE) to a base station in a network in order to enable the uplink transmission to be multiplexed with other uplink transmissions from other UEs to the same base station.

[0005] The OCC may be effective in mitigating interference and improving overall network performance in scenarios where multiple UEs are transmitting simultaneously to the same base station.SUMMARY

[0006] Example embodiments of the present disclosure automatically manage orthogonal cover code (OCC). As such, example embodiments of the present disclosure may enable effective assignments of UEs to appropriate OCC groups within NTN deployments.

[0007] According to example embodiments, a system is provided. The system may include a base station. The base station may be configured to receive, from a plurality of user equipment (UEs), a status notification specifying an orthogonal cover code (OCC) length associated with the respective UE. The base station may also be configured to assign each of the plurality of UEs to one of a plurality of OCC groups based on the OCC length associated with the respective UE, such that OCC lengths of all UEs in a particular OCC group are same. The base station may also be configured to allocate physical resource blocks (PRBs) to the plurality of UEs based on an OCC group assigned to the respective UE.

[0008] According to example embodiments, a method is provided. The method may include receiving, from a plurality of user equipment (UEs), a status notification specifying an orthogonal cover code (OCC) length associated with the respective UE. The method may also include assigning each of the plurality of UEs to one of a plurality of OCC groups based on the OCC length associated with the respective UE, such that OCC lengths of all UEs in a particular OCC group are same. The method may also include allocating physical resource blocks (PRBs) to the plurality of UEs based on an OCC group assigned to the respective UE.

[0009] According to example embodiments, a non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium may have recorded thereon instructions executable by a system to cause the system to perform a method includingreceiving, from a plurality of user equipment (UEs), a status notification specifying an orthogonal cover code (OCC) length associated with the respective UE. The method may also include assigning each of the plurality of UEs to one of a plurality of OCC groups based on the OCC length associated with the respective UE, such that OCC lengths of all UEs in a particular OCC group are same. The method may also include allocating physical resource blocks (PRBs) to the plurality of UEs based on an OCC group assigned to the respective UE.

[0010] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0012] FIG. 1 illustrates a block diagram of an example system configuration for managing orthogonal cover code (OCC) in a network, according to one or more example embodiments;

[0013] FIG. 2 illustrates a flow diagram of an example method for managing orthogonal cover code (OCC), according to one or more example embodiments;

[0014] FIG. 3 illustrates a flow diagram of an example method for managing orthogonal cover code (OCC), according to one or more example embodiments;

[0015] FIG. 4 illustrates a flow diagram of an example method for managing orthogonal cover code (OCC), according to one or more example embodiments;

[0016] FIG. 5 illustrates a flow diagram of an example method for managing orthogonal cover code (OCC), according to one or more example embodiments;

[0017] FIG. 6 illustrates a diagram of example components of a system for implementing one or more example embodiments; and

[0018] FIG. 7 illustrates a diagram of an example of implementation environment in which systems and / or method, described herein, may be implemented.DETAILED DESCRIPTION

[0019] The following detailed description of example embodiments refers to the accompanying drawings. The present disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the present disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to at least one of the embodiments in the present disclosure. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part). Further, the order of one or more operations may be switched, as long as these modifications may not affect the resulting scope of the present disclosure.

[0020] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, software, or a combination of hardware and software.The actual specialized control hardware or software code used to implement these systems and / or methods should not limit their implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0021] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, the particular combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Even if a dependent claim directly depends on only one claim, the present disclosure may indicate that the dependent claim is dependent on other claims in the claim set.

[0022] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” (in other words, nouns not mentioned in the plural) are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B],” “[A] and / or [B],” or “at least one of [A] or [B]” are to be understood as including only A, only B, or both A and B. Further still, where only one item is intended, the term “one” or similar language is used.

[0023] Expressions such as “at least one processor,” where configured to implement a plurality of operations, execute a plurality of instructions, etc., are to be understood as a singleprocessor implementing the plurality of operations, etc., or each of plural processors implementing at least some (but not necessarily all) of the plurality of operations, etc.

[0024] Reference throughout this specification to “one embodiment,” “an embodiment,” “non-limiting exemplary embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present solution. Thus, the phrases “in one embodiment”, “in an embodiment,” “in one non-limiting exemplary embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0025] Further, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more example embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the present disclosure can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0026] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0027] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, the Open Radio AccessNetwork (0-RAN) Alliance standard organization, and the like. For instance, the terms “OCC”, “CFO”, “PRB”, “SINK”, “UCI”, “HARQ”, “SR”, “CSI”, “PUSCH”, “PUCCH”, “NTN”, and the like, as well as the associated features and operations, are to be interpreted as consistent with those specified in one or more technical specifications, unless described otherwise.

[0028] Further, example embodiments of the present disclosure may apply to any suitable network elements in any suitable telecommunications system, such as a 4G LTE system, 5G system, a 6G system, and the like, without departing from the scope of the present disclosure.

[0029] As described above, the OCC may refer to a coding technique that enables the uplink transmission to be multiplexed with other uplink transmissions from other UEs to the same base station, thereby mitigating interference and improving overall network performance in scenarios where multiple UEs are transmitting simultaneously to the same base station.

[0030] In the related art, there are no defined solutions on how to implement the OCC with non-terrestrial network (NTN) deployments, which introduces various variables and challenges that are not present in typical terrestrial network (TN) deployments.

[0031] In particular, there are no clearly defined solutions on how to enable dynamic grouping and regrouping of UEs into particular OCC groups based on the supported OCC lengths, while considering factors such as Doppler shift, carrier frequency offset (CFO), signal to interference noise ratio (SINR), and traffic level.

[0032] More specifically, while the deployment of OCC-based uplink multiplexing requires UEs to indicate their support for OCC length (e.g., length 2, length 4, etc.), there are no clearly defined capability signaling for OCC, making it challenging for networks to dynamically allocate physical resource blocks (PRBs) to OCC-capable UEs. Without proper signaling,networks may inefficiently allocate non-OCC resources to OCC-capable UEs, causing inefficiencies in resource allocation and scheduling decisions.

[0033] Further, OCC performance can degrade by a significant amount (e.g., up to 1 dB) if differential CFO among UEs within the same OCC group exceeds a particular value (e.g., 200 Hz). In this regard, since CFO effects are more pronounced in NTN due to Doppler shifts, it is desirable to enable networks to group UEs based on CFO characteristics. Without such a mechanism, OCC multiplexing may fail to achieve its expected gains in NTN deployments.

[0034] Furthermore, the deployment of OCC-based uplink multiplexing may introduce complexities in medium access control (MAC) scheduling and hybrid automatic repeat request (HARQ) retransmission handling. A key concern may include the consideration of whether the HARQ retransmissions should maintain the same OCC index assignment or whether adaptive OCC group reassignment should be permitted. Given that NTN link conditions fluctuate due to Doppler effects and beam switching, maintaining fixed OCC assignments for retransmissions may not always be optimal. There is also no existing MAC scheduling mechanism that dynamically optimizes OCC group assignment based on real-time link conditions, nor inter-beam OCC scheduling mechanism which may limit the spectral efficiency benefits of OCC multiplexing in NTN.

[0035] Further still, the uplink control information (UCI) handling may be a critical issue in OCC-based multiplexing. Given that uplink PRB availability is limited in NTN, physical uplink control channel (PUCCH) and OCC-physical uplink shared channel (PUSCH) may overlap, requiring a mechanism to determine whether the UCI should be prioritized on the PUCCH or multiplexed onto PUSCH. Several solutions have been considered including: (1) dropping UCIwhen it overlaps with OCC-PUSCH, which may lead to excessive retransmissions and HARQ inefficiencies; (2) prioritizing PUCCH transmission over OCC-PUSCH, which ensures reliable UCI transmission but reduces the spectral efficiency of OCC-based PUSCH; and (3) multiplexing UCI onto OCC-PUSCH, allowing simultaneous control and data transmission but increasing scheduling complexity. Here, given that NTN uplink has limited retransmission opportunities due to long propagation delays, dropping UCI as in (1) is not a viable solution, and simple PUCCH prioritization as in (2) also reduces efficiency, necessitating an optimized multiplexing approach as in (3). However, the handling of UCI multiplexing in OCC-based uplink transmission remains undefined, leading to potential inefficiencies in scheduling and control signaling.

[0036] In view of the above, NTN deployments may struggle to achieve the full potential of OCC-based multiplexing.

[0037] Accordingly, system, methods, devices, and the like, provided in the example embodiments of the present disclosure automatically manage orthogonal cover code (OCC).

[0038] According to example embodiments, the system may include a base station. The base station may be configured to receive, from a plurality of user equipment (UEs), a status notification specifying an orthogonal cover code (OCC) length associated with the respective UE. The base station may also be configured to assign each of the plurality of UEs to one of a plurality of OCC groups based on the OCC length associated with the respective UE, such that OCC lengths of all UEs in a particular OCC group are same. The base station may also be configured to allocate physical resource blocks (PRBs) to the plurality of UEs based on an OCC group assigned to the respective UE.

[0039] Ultimately, example embodiments of the present disclosure automatically manage orthogonal cover code (OCC), which may enable effective assignments of UEs to appropriate OCC groups within NTN deployments.

[0040] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure.

[0041] Further descriptions of the features, components, configuration, operations, and implementations of the system of the present disclosure, according to one or more embodiments, are provided in the following.Example System Architecture

[0042] FIG. 1 illustrates a block diagram of an example system configuration 100 for managing orthogonal cover code (OCC) in a network, according to one or more example embodiments.

[0043] As illustrated in FIG. 1, system configuration 100 may include a base station 110 and a plurality of user equipment (UEs) 120,130,140,150 although it is contemplated that the system architecture may include more / fewer components than illustrated, and / or may be configured in a different manner, without departing from the scope of the present disclosure. For instance, while the example of FIG. 1 shows four UEs (first UE 120, second UE 130, third UE 140, and fourth UE 150), the present disclosure is not limited thereto and may include any number ofUEs.

[0044] The base station 110 may include an apparatus, a system, a platform, a module, or the like, which may be configured to perform one or more operations or actions for managingorthogonal cover code (OCC) in a network. Example operations performable by the base station 110 for managing orthogonal cover code (OCC) are described below with reference to FIG. 2 to FIG. 5.

[0045] According to example embodiments, the base station 110 may include base stations in a network, such as a cell (e.g., super cell, a macro cell, a small cell, a femto cell, a pico cell, etc.), a node (e.g., a NodeB, an eNodeB (eNB), a gNodeB (gNB), etc.), a radio unit (RU) under radio access network (RAN), a distributed unit (DU) under radio access network (RAN), a centralized unit (CU) under radio access network (RAN), a carrier, a component carrier, a sector, and the like.

[0046] Each of the plurality of UEs 120,130,140,150 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), a SIM-based device, or a similar device.

[0047] According to example embodiments, each of the plurality of UEs 120,130,140,150 may implement an orthogonal cover code (OCC) to an uplink data transmitted to the base station 110. The OCC may refer to a coding technique that enables uplink data transmitted from one UE to be multiplexed with other uplink data transmitted from other UEs to the base station 110.

[0048] More specifically, the OCC may refer to multiple sets of binary sequences that are orthogonal with each other and that their inner product is equal to zero. A particular set of binary sequences (OCC code) may include a string of positively or negatively signed numbers, which may be utilized to encode transmission data (e.g., uplink data) from a particular UE.

[0049] Here, a frequency spectrum available for transmissions to the base station 110 may be divided into multiple sub-channels (sub-carriers), where each of the sub-channels may be assigned a particular OCC code. Such configuration may enable multiple UEs to transmit their uplink data to the same base station simultaneously over different sub-channels without interfering with each other.

[0050] In this regard, the OCC code may have a particular length, which may be any number, such as OCC length 2, OCC length 4, and the like.

[0051] For example, the plurality of UEs 120,130,140,150 may implement and support OCC code with OCC length 4. In this regard, the first UE 120 may be assigned with OCC code [1,1, 1,1], the second UE 130 may be assigned with OCC code [1,-1, 1,-1], the third UE 140 may be assigned with OCC code [1,1, -1,-1], and the fourth UE 150 may be assigned with OCC code [- 1.1.1,-1], Here the OCC codes [1,1, 1,1], [1,-1, 1,-1], [1,1, -1,-1], and [-1,1, 1,-1] are orthogonal to each other with inner product equal to zero.

[0052] Accordingly, the first UE 120, the second UE 130, the third UE 140, and the fourth UE 150 may encode their uplink data with OCC codes [1,1, 1,1], [1,-1, 1,-1], [1,1, -1,-1], and [- 1.1.1,-1] respectively when transmitting the uplink data to the base station 110. In this regard, the base station 110 may separate and decode the uplink data from the first UE 120, the second UE 130, the third UE 140, and the fourth UE 150 by correlating the received uplink data with the respective assigned OCC code. Here, the orthogonality property may ensure that interference from different signals is minimized, such that the uplink data may be transmitted simultaneously and reliably without interfering with each other.

[0053] According to example embodiments, different UEs may implement and support different OCC length.

[0054] For example, the first UE 120 and the second UE 130 may implement and support OCC code with OCC length 2, while the third UE 140 and the fourth UE 150 may implement and support OCC code with OCC length 4. In this regard, the first UE 120 may be assigned with OCC code [1,1], the second UE 130 may be assigned with OCC code [1,-1], the third UE 140 may be assigned with OCC code [1,1, -1,-1], and the fourth UE 150 may be assigned with OCC code [-1,1, 1,-1], Here the OCC codes [1,1] and [1,-1] are orthogonal to each other with inner product equal to zero, while the OCC codes [1,1,- 1,-1] and [-1,1,1,-!] are orthogonal to each other with inner product equal to zero.

[0055] According to example embodiments, each of the plurality of UEs 120,130,140,150 may implement the OCC via any kind of modulation schemes, such as frequency-division multiplexing (FDM), orthogonal frequency-division multiplexing (OFDM), and the like. Here, for FDM-based OCC, each sub-channel may be allocated a separate frequency band, where the OCC codes may be used to encode the uplink data on each sub-channel. For OFDM-based OCC, the frequency band may be divided into multiple narrow sub-carriers, where each sub-carrier may be assigned the OCC code.

[0056] Further, the specific binary sequences of the OCC code may be generated using any appropriate methods, techniques, tools, and the like. For example, mathematical techniques, such as Walsh-Hadamard codes, Golay codes, and the like may be utilized to generate the binary sequences of the OCC code.

[0057] In view of the above, the base station 110 may allocate physical resource blocks (PRBs) to the plurality of UEs 120,130,140,150 based on the associated OCC codes. For example, the base station 110 may allocate one PRB for every two UEs with OCC length 2 (i.e., two UEs per PRB), and / or may allocate one PRB for every four UEs with OCC length 4 (i.e., four UEs per PRB).

[0058] According to example embodiments, each of the plurality of UEs 120,130,140,150 may transmit an uplink control information (UCI) to the base station 110. The UCI may include control information / signals transmitted in the uplink direction, which may include one or a combination of hybrid automatic repeat request (HARQ) acknowledge (ACK) / negative acknowledge (NACK), scheduling request (SR), and channel state information (CSI). It is understood that the HARQ ACK / NACK may refer to the ACK / NACK responses for downlink data under HARQ, the SR may refer to a request for uplink resource / schedule, and the CSI may refer to the measurement associated with downlink channel condition.

[0059] According to example embodiments, the UCI may be transmitted to the base station 110 via physical uplink control channel (PUCCH).

[0060] According to example embodiments, the UCI may be transmitted to the base station 110 via physical uplink shared channel (PUSCH) by multiplexing the UCI on the PUSCH in accordance with the OCC code.

[0061] According to example embodiments, the plurality of UEs 120,130,140,150 and the base station 110 may be communicatively coupled with each other over a non-terrestrial network (NTN) environment.

[0062] It is understood that the NTN environment may refer to a wireless communication network environment that utilizes uncrewed aircraft systems (UAS) to facilitate communications between various network elements of the network. In particular, the UAS may be utilized to carry a base station or a relay node above the ground at the Earth’s orbit (e g., low earth orbit, medium earth orbit, geostationary earth orbit, highly elliptical orbiting, etc.), where the base station / relay node may act as a link (e.g., satellite link) between various network elements. The UAS may include, for example, high altitude platforms (HAPS), satellites, and the like.

[0063] In this regard, according to example embodiments, the plurality of UEs 120,130,140,150 and the base station 110 may communicate with each other through the base station / relay node on the UAS above the ground at the Earth’s orbit.Example Operations for Managing OCC in the Present Disclosure

[0064] In the following, several example operations are performable by the system of one or more example embodiments of the present disclosure are described with reference to FIG. 2 to FIG. 5.

[0065] FIG. 2 illustrates a flow diagram of an example method 200 for managing orthogonal cover code (OCC), according to one or more example embodiments. One or more operations in method 200 may be performed by the system of one or more example embodiments of the present disclosure. The system may be configured to manage orthogonal cover code (OCC).

[0066] According to example embodiments, the system may include a base station. More specifically, according to example embodiments, the base station may include a gNodeB. It is noted that, while the below descriptions are provided from the perspective of the base station, thepresent disclosure is not limited thereto and may encompass corresponding operations from the perspective of the UE.

[0067] As illustrated in FIG. 2, at operation S210, the system may be configured to receive a status notification. The status notification may be received from a plurality of user equipment (UEs).

[0068] According to example embodiments, the status notification may specify an orthogonal cover code (OCC) length associated with the respective UE of the plurality of UEs. The OCC length associated with the respective UE of the plurality of UEs may include the OCC length that is supported by the respective UE of the plurality of UEs.

[0069] For example, the system may receive a status notification from a first UE specifying that the OCC length supported by the first UE is OCC length 2, a status notification from a second UE specifying that the OCC length supported by the second UE is OCC length 2, a status notification from a third UE specifying that the OCC length supported by the third UE is OCC length 4, and a status notification from a fourth UE specifying that the OCC length supported by the fourth UE is OCC length 4.

[0070] According to example embodiments, the status notification may also specify a carrier frequency offset (CFO) associated with the respective UE of the plurality of UEs. The CFO may refer to an offset between a carrier frequency at the transmitter of a signal (e.g., base station) and a carrier frequency at the receiver of the signal (e.g., UE).

[0071] For example, the system may receive a status notification from the first UE specifying that the CFO associated with the first UE (an offset between a carrier frequency at the base station and a carrier frequency at the first UE) is 150Hz, a status notification from the secondUE specifying that the CFO associated with the second UE is 190Hz, a status notification from the third UE specifying that the CFO associated with the third UE is 500Hz, and a status notification from the fourth UE specifying that the CFO associated with the fourth UE is 250Hz.

[0072] According to example embodiments, the system and the plurality of UEs may be communicatively coupled with each other over a non -terrestrial network (NTN) environment.

[0073] According to example embodiments, the status notification may be received via radio resource control (RRC) signaling, where the OCC length, CFO, and the like associated with a UE may correspond to an RRC parameter.

[0074] According to example embodiments, the status notification may include a UE capability notification indicating the UE’s capabilities associated with OCC group assignments, such as the OCC length supported by the UE, the capability for the UE to be assigned / reassigned to a particular OCC group, etc. The method then proceeds to operation S220.

[0075] At operation S220, the system may be configured to assign each of the plurality of UEs to one of a plurality of OCC groups.

[0076] According to example embodiments, each of the plurality of UEs may be assigned to one of the plurality of OCC groups based on the OCC length associated with the respective UE, such that OCC lengths of all UEs in a particular OCC group are same.

[0077] For example, if the OCC length supported by the first UE and the second UE is OCC length 2 and the OCC length supported by the third UE and the fourth UE is OCC length 4, the system may assign the first UE and the second UE to a first OCC group of the plurality of OCC groups and assign the third UE and the fourth UE to a second OCC group of the plurality of OCC groups. In this regard, the first OCC group may be characterized by being associated with OCClength 2, while the second OCC group may be characterized by being associated with OCC length 4.

[0078] According to example embodiments, each of the plurality of UEs may be assigned to one of the plurality of OCC groups based on the CFO associated with the respective UE such that a CFO differential between any two UEs within a particular OCC group is less than a threshold. It is noted here that the CFO differential may refer to the difference between two CFOs. Further, the threshold may be predefined by a user (e.g., network operator).

[0079] For example, the threshold may be predefined as 200Hz. If the CFO associated with the first UE is 150Hz, the CFO associated with the second UE is 190Hz, the CFO associated with the third UE is 500Hz, and the CFO associated with the fourth UE is 250Hz, the system may assign the first UE, the second UE and the fourth UE to a first OCC group of the plurality of OCC groups and assign the third UE to a second OCC group of the plurality of OCC groups. Here, the CFO differential between any two UEs within the first OCC group is less than 200Hz (the CFO differential between the first UE and the second UE is 40Hz, the CFO differential between the first UE and the fourth UE is 100Hz, and the CFO differential between the second UE and the fourth UE is 60Hz).

[0080] In further another example, the system may assign the first UE and the second UE to a first OCC group of the plurality of OCC groups, assign the third UE to a second OCC group of the plurality of OCC groups, and assign the fourth UE to a third OCC group of the plurality of OCC groups. In this regard, the first OCC group may be characterized by being associated with OCC length 2 where the CFO differential between any two UEs within the first OCC group is less than 200Hz (the CFO differential between the first UE and the second UE is 40Hz), the secondOCC group may be characterized by being associated with OCC length 4 where the CFO differential between any two UEs within the second OCC group is less than 200Hz (the third UE is the only one UE in the second group and thus there are no CFO differential), and the third OCC group may be characterized by being associated with OCC length 4 where the CFO differential between any two UEs within the second OCC group is less than 200Hz (the fourth UE is the only one UE in the third group and thus there are no CFO differential). It is noted here that, if the third UE and the fourth UE are assigned to the same OCC group, the CFO differential between the third UE and the fourth UE may exceed the threshold (i.e., 250Hz).

[0081] According to example embodiments, each of the plurality of UEs may be assigned to one of the plurality of OCC groups via MAC signaling feature (i .e., CFO-aware UE clustering MAC scheduling feature). The method then proceeds to operation S230.

[0082] At operation S230, the system may be configured to allocate physical resource blocks (PRBs) to the plurality of UEs based on an OCC group assigned to the respective UE.

[0083] According to example embodiments, the system may allocate one PRB for every two UEs with OCC length 2 (i.e., inter-slot OCC for OCC length 2 with two UEs per PRB). According to example embodiments, the system may allocate one PRB for every four UEs with OCC length 4 (i.e., inter-slot OCC for OCC length 4 with four UEs per PRB).

[0084] For example, if the first OCC group is associated with OCC length 2 and the second OCC group is associated with OCC length 4, the system may allocate one PRB for every two UEs in the first group (e.g., the first UE and the second UE) and allocate one PRB for every four UEs in the second group (e.g., the third UE and the fourth UE).

[0085] According to example embodiments, the PRBs may be allocated to the plurality of UEs based on the OCC group assigned to the respective UE through multiplexing using any appropriate methods, techniques, tools, and the like. For example, with inter-slot OCC for OCC length 4, Hadamard sequences may be utilized to multiplex up to four UEs per PRB. In another example, intra-symbol pre-discrete Fourier transform (DFT) OCC for OCC length 4, may be utilized as a multiplexing technique. In further another example, a combination of inter-slot OCC with intra-symbol OCC may be utilized.

[0086] In this regard, the plurality of UEs may utilize the allocated PRBs to transmit uplink data to the system (base station) through multiplexing in accordance with the assigned OCC group.

[0087] Accordingly, the above processes enable effective assignments of UEs to appropriate OCC groups within NTN deployments.

[0088] In particular, the above processes may enable UE capability signaling for OCC-based uplink multiplexing, thereby providing support for any OCC lengths (e.g., OCC length 2, OCC length 4, etc.), allowing the network to allocate PRBs efficiently, as well as providing CFObased grouping capability indicators, enabling more efficient UE clustering for OCC scheduling.

[0089] Further, the above processes may enable UEs to be grouped into OCC clusters (OCC groups) based on their CFOs to reduce interference and improve decoding reliability.

[0090] FIG. 3 illustrates a flow diagram of an example method 300 for managing orthogonal cover code (OCC), according to one or more example embodiments. One or more operations in method 300 may be performed by the system of one or more example embodiments of the present disclosure. The system may be configured to manage orthogonal cover code (OCC).

[0091] According to example embodiments, the system may include a base station. More specifically, according to example embodiments, the base station may include a gNodeB. It is noted that, while the below descriptions are provided from the perspective of the base station, the present disclosure is not limited thereto and may encompass corresponding operations from the perspective of the UE.

[0092] According to example embodiments, method 300 may be performed after each of the plurality of UEs is assigned to one of the plurality of OCC groups. For example, method 300 may be performed after each of the plurality of UEs is assigned to one of the plurality of OCC groups operation as described above in relation to operation S220 and the PRBs are allocated to the plurality of UEs based on the OCC group assigned to the respective UE as described above in relation to operation S230 of method 200.

[0093] As illustrated in FIG. 3, at operation S310, the system may be configured to determine channel conditions associated with the plurality of OCC groups.

[0094] The channel conditions may include any kind of conditions, statuses, and the like associated with the plurality of OCC groups. According to example embodiments, the channel conditions may include at least one of: Doppler shift, CFO, signal to interference noise ratio (SINR), and traffic level.

[0095] The Doppler shift, also known as Doppler effect, may refer to the change of frequency of a signal experienced by the receiver of the signal (e.g., base station) as the transmitter of the signal (e g., UE) moves relative to the receiver of the signal within a particular OCC group.

[0096] The CFO may refer to an offset between a carrier frequency at the transmitter of a signal (e.g., UE) and a carrier frequency at the receiver of the signal (e.g., base station) within a particular OCC group, as described above in relation to method 200.

[0097] The SINR may refer to a ratio between a signal and a background noise measured by the receiver of the signal (e.g., base station) within a particular OCC group.

[0098] The traffic level may refer to an amount of traffic within a particular OCC group.

[0099] It is noted here that the system may determine the channel conditions using any appropriate methods, techniques, tools, and the like. The method then proceeds to operation S320.

[0100] At operation S320, the system may be configured to reassign a particular UE of the plurality of UEs from one group to another group of the plurality of OCC groups.

[0101] In particular, according to example embodiments, the plurality of UEs may include a first UE, which may be assigned to an initial OCC group of the plurality of OCC groups. In this regard, at operation S320, the system may be configured to reassign the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups.

[0102] According to example embodiments, the first UE may be reassigned from the initial OCC group to the updated OCC group of the plurality of OCC groups based on the channel conditions.

[0103] For example, the first UE may initially be assigned to the initial OCC group during operation S220 in method 200, where PRBs are allocated to the first UE based on the initial OCC group assigned to the first UE during operation S230 in method 200. Then, at a later time, the first UE may move to a different location, causing the Doppler effect and changes to the CFO associated with the UE. In this regard, during operation S310, the system may determine that the initial OCCgroup now contains a CFO differential that exceeds the threshold. Accordingly, the system may reassign the first UE from the initial OCC group to the updated OCC group during operation S320, where after the reassignments, the CFO differentials in the initial OCC group and the updated OCC group are within the threshold.

[0104] In another example, the first UE may initially be assigned to the initial OCC group during operation S220 in method 200, where PRBs are allocated to the first UE based on the initial OCC group assigned to the first UE during operation S230 in method 200. Then, during operation S310, the system may determine that the traffic level of the initial OCC group is high (e.g., exceeding certain threshold), while the traffic level of the updated OCC group is low. Accordingly, the system may reassign the first UE from the initial OCC group to the updated OCC group during operation S320.

[0105] According to example embodiments, the first UE may be configured to perform hybrid automatic repeat request (HARQ) retransmission based on the updated OCC group.

[0106] For example, the first UE may transmit a data packet (i.e., uplink data) to the system based on the initial OCC group, where the system may fail to decode the data packet and transmit HARQ NACK back to the first UE. In this regard, during operation S310, the system may determine that the SINR of the initial OCC group is low (e.g., below certain threshold), while the SINR of the updated OCC group is high. Accordingly, the system may reassign the first UE from the initial OCC group to the updated OCC group during operation S320, where the first UE may then retransmit the data packet (i.e., perform HARQ retransmission) to the system based on the updated OCC group. Here, since the updated OCC group has higher SINR than the initial OCCgroup, there may be a higher chance that the system is able to successfully receive and decode the data packet.

[0107] According to example embodiments, the first UE may be reassigned from the initial OCC group to the updated OCC group of the plurality of OCC groups further based on HARQ failure rates.

[0108] For example, the first UE may transmit a data packet to the system based on the initial OCC group, where the system may fail to decode the data packet and transmit HARQ NACK back to the first UE. In this regard, during operation S310, the system may determine that the SINK of the initial OCC group is low (e.g., below certain threshold), while the SINK of a first updated OCC group and a second updated OCC group are high. Here, the first updated OCC group may have a high HARQ failure rate, while the second updated OCC group may have a low HARQ failure rate. Accordingly, the system may reassign the first UE from the initial OCC group to the second updated OCC group during operation S320, where the first UE may then retransmit the data packet (i.e., perform HARQ retransmission) to the system based on the second updated OCC group. Here, since the second updated OCC group has higher SINR than the initial OCC group and lower HARQ failure rate than the first updated OCC group, there may be a higher chance that the system is able to successfully receive and decode the data packet.

[0109] According to example embodiments, the system may reassign the first UE from the initial OCC group to the updated OCC group by: selecting a target OCC group from among the plurality of OCC groups based on the channel conditions; and reassigning the first UE from the initial OCC group to the selected target OCC group. Here, the selected target OCC group may correspond to the updated OCC group discussed above.

[0110] In this regard, according to example embodiments, the target OCC group may be selected from among the plurality of OCC groups based on the channel conditions in accordance with a reassignment policy. The reassignment policy may define a policy for selecting a particular OCC group to reassign a particular UE to (e.g., a policy specifying when a UE should be reassigned, which OCC group should the particular UE be reassigned to, etc.) For example, the reassignment policy may define a particular SINR threshold, where any UE with SINR below the particular SINR threshold should be reassigned. In certain implementations, the reassignment policy may also specify a policy for selecting a particular OCC group to reassign a particular UE to in relation to HARQ retransmission (i.e., HARQ adaptation policy), allowing HARQ retransmission to be switched to a different OCC group as described above.

[0111] According to example embodiments, the first UE may be reassigned from the initial OCC group to the updated OCC group via MAC control signaling. For example, the system (e.g., gNodeB) may specify and indicate when a UE should be reassigned in a particular MAC signaling field. Further, according to example embodiments, the first UE may be reassigned from the initial OCC group to the updated OCC group based on MAC scheduling policies, which may be predefined to optimize OCC-based multiplexing for NTN uplink.

[0112] According to example embodiments, the first UE may be reassigned from the initial OCC group to the updated OCC group based on the channel conditions in accordance with a particular procedure (e.g., a quality of service (QoS)-based OCC reassignment procedure).

[0113] According to example embodiments, the system may also implement a traffic-aware scheduler that detects traffic congestion and optimizes OCC assignments accordingly. According to example embodiments, the system may also implement an adaptive CFO trackingsystem that monitors CFOs associated with the plurality of UEs, and reassigns the plurality of UEs to the most appropriate OCC groups.

[0114] According to example embodiments, the system may be configured to store and track OCC group assignments and reassignments dynamically.

[0115] Accordingly, the above processes enable effective reassignments of UEs to appropriate OCC groups within NTN deployments based on various factors.

[0116] In particular, the above processes may enable HARQ scheduling for NTN, where OCC group reassignments may be adaptively performed for HARQ retransmissions based on channel conditions. More specifically, instead of retransmitting within the same OCC group, HARQ retransmission may be dynamically switched to a more optimal OCC group based on channel conditions.

[0117] Further, the above processes may also enable real-time OCC group adjustments based on traffic demand, where, instead of static OCC groups, the UE may be reassigned to different OCC groups in real-time based on traffic patterns and fluctuations.

[0118] FIG. 4 illustrates a flow diagram of an example method 400 for managing orthogonal cover code (OCC), according to one or more example embodiments. One or more operations in method 400 may be performed by the system of one or more example embodiments of the present disclosure. The system may be configured to manage orthogonal cover code (OCC).

[0119] According to example embodiments, the system may include a base station. More specifically, according to example embodiments, the base station may include a gNodeB. It is noted that, while the below descriptions are provided from the perspective of the base station, thepresent disclosure is not limited thereto and may encompass corresponding operations from the perspective of the UE.

[0120] According to example embodiments, method 400 may be performed after each of the plurality of UEs is assigned to one of the plurality of OCC groups. For example, method 400 may be performed after each of the plurality of UEs is assigned to one of the plurality of OCC groups operation as described above in relation to operation S220 and the PRBs are allocated to the plurality of UEs based on the OCC group assigned to the respective UE as described above in relation to operation S230 of method 200.

[0121] As illustrated in FIG. 4, at operation S410, the system may be configured to determine beam movement predictions associated with the plurality of UEs.

[0122] The beam movement prediction may refer to a prediction associated with beam movement of a particular UE of the plurality of UEs (i.e., movement from one beam to an adjacent beam). More specifically, for example, beam movement prediction may refer to a prediction of movements of a particular UE before a beam switch occurs.

[0123] According to example embodiments, the beam movement prediction may be determined using a machine learning (ML) model.

[0124] The ML model may include any kind of machine learning (ML) / artificial intelligence (Al) model, configured to recognize various kinds of data associated with UEs, and to determine an appropriate beam movement prediction based on the data (e.g., when a particular UE will switch beams). Further, the ML model may be trained using any appropriate methods to recognize various kinds of data associated with UEs, such as supervised learning, unsupervised learning, reinforcement learning, and the like. Furthermore, the ML model may utilize anyappropriate decision algorithms to determine an appropriate beam movement prediction, such as regression, neural networks, random forest, k-means clustering, Q-table, and the like. The method then proceeds to operation S420.

[0125] At operation S420, the system may be configured to reassign a particular UE of the plurality of UEs from one group to another group of the plurality of OCC groups.

[0126] In particular, according to example embodiments, the plurality of UEs may include a first UE, which may be assigned to an initial OCC group of the plurality of OCC groups. In this regard, at operation S420, the system may be configured to reassign the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups.

[0127] According to example embodiments, the first UE may be reassigned from the initial OCC group to the updated OCC group of the plurality of OCC groups based on the determined beam movement predictions.

[0128] For example, the first UE may initially be assigned to the initial OCC group during operation S220 in method 200, where PRBs are allocated to the first UE based on the initial OCC group assigned to the first UE during operation S230 in method 200. Then, during operation S410, the system may predict the movement of the first UE between beams, and then accordingly prereassign the UE to the updated OCC group before the beam switch occurs.

[0129] In this regard, the system may be configured to implement OCC group coordination between adjacent beams to ensure that the first UE may receive a consistent OCC assignment postswitch.

[0130] According to example embodiments, the first UE may be reassigned from the initial OCC group to the updated OCC group based on the determined beam movement predictions inaccordance with a particular procedure (i.e., a beam transition-induced OCC reallocation procedure).

[0131] According to example embodiments, the status notification (i.e., UE capability notification) described above in relation to operation S210 in method 200 may also indicate the UE’s capabilities associated with inter-beam OCC scheduling.

[0132] Accordingly, the above processes enable effective reassignments of UEs to appropriate OCC groups within NTN deployments based on various factors.

[0133] In particular, the above processes may enable inter-beam scheduling for NTN, where OCC group reassignments may be adaptively performed based on beam movement predictions.

[0134] FIG. 5 illustrates a flow diagram of an example method 500 for managing orthogonal cover code (OCC), according to one or more example embodiments. One or more operations in method 500 may be performed by the system of one or more example embodiments of the present disclosure. The system may be configured to manage orthogonal cover code (OCC).

[0135] According to example embodiments, the system may include a base station. More specifically, according to example embodiments, the base station may include a gNodeB. It is noted that, while the below descriptions are provided from the perspective of the base station, the present disclosure is not limited thereto and may encompass corresponding operations from the perspective of the UE.

[0136] According to example embodiments, method 500 may be performed after each of the plurality of UEs is assigned to one of the plurality of OCC groups. For example, method 500 may be performed after each of the plurality of UEs is assigned to one of the plurality of OCCgroups operation as described above in relation to operation S220 and the PRBs are allocated to the plurality of UEs based on the OCC group assigned to the respective UE as described above in relation to operation S230 of method 200.

[0137] In this regard, according to example embodiments, the plurality of UEs may include a first UE that is assigned to an initial OCC group of the plurality of OCC groups.

[0138] As illustrated in FIG. 5, at operation S510, the system may be configured to determine priorities associated with hybrid automatic repeat request (HARQ) acknowledge (ACK) / negative acknowledge (NACK), scheduling request (SR), and channel state information (CSI) of an uplink control information (UCI) associated with the first UE.

[0139] In particular, the UCI may include control information / signals transmitted in the uplink direction from a UE (e.g., the first UE) to the system (e.g., base station), which may include one or a combination of the HARQ ACK / NACK, SR, and CSI. It is understood that the HARQ ACK / NACK may refer to the ACK / NACK responses for downlink data under HARQ, the SR may refer to a request for uplink resource / schedule, and the CSI may refer to the measurement associated with downlink channel condition.

[0140] For example, the system may determine that the HARQ ACK / NACK has a high priority, that the SR has a medium priority, and that the CSI has a low priority.

[0141] According to example embodiments, the priorities associated with HARQ ACK / NACK, SR, and CSI may be determined based on data associated with the network (e.g., network congestion), and / or data associated with the first UE (e.g., signal quality between the first UE and the base station, type of the first UE, etc.)

[0142] According to example embodiments, the priorities associated with HARQ ACK / NACK, SR, and CSI may be determined in accordance with a predefined rules (i.e., prioritybased UCI multiplexing rules) specifying what should be the priorities of the HARQ ACK / NACK, SR, and CSI based on various factors (e.g., network congestion, signal quality between the first UE and the base station, type of the first UE, etc.)

[0143] According to example embodiments, the priorities may be determined at a MAC level. The method then proceeds to operation S520.

[0144] At operation S520, the system may be configured to transmit the determined priorities.

[0145] The determined priorities may be transmitted to the first UE.

[0146] According to example embodiments, the determined priorities may be transmitted via MAC signaling. The method then proceeds to operation S530.

[0147] At operation S530, the system may be configured to receive the UCI multiplexed onto OCC-physical uplink shared channel (PUSCH).

[0148] The UCI multiplexed onto the OCC-PUSCH may be received from the first UE based on the determined priorities and the initial OCC group.

[0149] For example, in response to receiving the priorities from the system where the HARQ ACK / NACK has a high priority, the SR has a medium priority, and the CSI has a low priority, the first UE may prioritize transmitting the UCI including the HARQ ACK / NACK first over transmitting the UCI including the SR and CSI. Accordingly, if the first UE needs to send the HARQ ACK / NACK and the CSI to the system (e.g., base station) at a particular time, the first UE may transmit the UCI including the HARQ ACK / NACK to the system first, and then transmitanother UCI including the CSI to the system. Here, both of the UCI may be multiplexed onto the OCC-PUSCH based on the initial OCC group (which the first UE is assigned to).

[0150] According to example embodiments, the above operations S510 to S530 may be performed for each of the plurality of UEs.

[0151] For example, the system may determine that the HARQ ACK / NACK has a high priority, that the SR has a medium priority, and that the CSI has a low priority for the first UE, and determine that the HARQ ACK / NACK has a medium priority, that the SR has a high priority, and that the CSI has a low priority for the second UE during operation S510. Then, the system may transmit the determined priorities to the respective UEs during operation S520.

[0152] In this regard, for example, if the first UE needs to send the HARQ ACK / NACK and the SR to the system (e.g., base station) at a particular time, the first UE may transmit the UCI including the HARQ ACK / NACK to the system first, and then transmit another UCI including the SR to the system (since the HARQ ACK / NACK has a higher priority than then SR for the first UE). Here, both of the UCI may be multiplexed onto the OCC-PUSCH based on the OCC group which the first UE is assigned to. On the other hand, if the second UE needs to send the HARQ ACK / NACK and the SR to the system (e.g., base station) at a particular time, the second UE may transmit the UCI including the SR to the system first, and then transmit another UCI including the HARQ ACK / NACK to the system (since the HARQ ACK / NACK has a lower priority than then SR for the second UE). Here, both of the UCI may be multiplexed onto the OCC-PUSCH based on the OCC group which the second UE is assigned to.

[0153] According to example embodiments, the system may also be configured to define UCI repetition across OCC transmissions and transmit the defined UCI repetition to the first UE.

[0154] According to example embodiments, the system may also be configured to implement an ML-based priority assignment that dynamically classifies UCI packets based on urgency and transmission success probability.

[0155] According to example embodiments, the status notification (i.e., UE capability notification) described above in relation to operation S210 in method 200 may also indicate the UE’s capabilities associated with prioritization of HARQ ACK / NACK, SR, and CSI in the UCI, as well as the UE’s capabilities associated with UCI multiplexing on PUSCH.

[0156] Accordingly, the above processes enable hybrid UCI prioritization for OCC-based PUSCH, allowing for reordering of UCI transmissions based on various factors. This may ensure that HARQ ACK / NACK is prioritized over CSI while maintaining spectral efficiency. The above may also define conditions for multiplexing CSI onto PUSCH.Various Aspects of Embodiments

[0157] In view of the above, example embodiments of the present disclosure may enable effective assignments of UEs to appropriate OCC groups within NTN deployments.

[0158] Example embodiments of the present disclosure may also provide enhancements in key areas such as capability signaling, scheduling, HARQ retransmissions, and control information handling to ensure seamless deployment in NTN-specific conditions.

[0159] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0160] Some embodiments may relate to a system, a method, and / or a computer readablemedium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer readable medium and executable by at least one processor (and / or may include at least one processor). The computer readable medium may include a computer-readable non-transitory storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out operations.

[0161] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0162] Computer readable program instructions described herein can be downloaded torespective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0163] Computer readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a standalone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0164] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0165] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0166] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer readable media according to various embodiments. In this regard, each block in the flowchart orblock diagrams may represent a microservice(s) module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0167] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code-it being understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0168] One or more components of the system of the example embodiments (e.g., base station, etc.), as well as the operations associated therewith (e.g., one or more operations in FIG. 2 to FIG. 5, etc.), may be implemented in one or more systems, devices, or hardware components,such as one or more servers, and the like. In the following, descriptions of a system in which the systems or components of the example embodiments may be implemented are provided. It is contemplated that one or more operations or methods described above with reference to FIG. 1 to FIG. 5 may be performed by the system. For instance, the one or more operations or methods may be performed by at least one processor of the system upon executing machine-readable instructions or computer-readable instructions stored in a memory or a storage component of the system.

[0169] FIG. 6 illustrates an embodiment of a system 600 for implementing one or more example embodiments. As shown in FIG. 6, the system 600 includes a processor 610, a memory 620, a storage component 630, an input component 640, an output component 650, a communication interface 660, and a bus 670.

[0170] The processor 610, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 610 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and one or more single core processors, a distributed processing system, or the like. The processor 610 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0171] Memory 620 includes a non-transitory computer readable medium. Memory 620 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 610. The memory 620 comprises machine-readable instructions which are executable by the processor 610. Thesemachine-readable instructions when executed by the processor 610 causes the processor 610 to perform one or more method steps of an embodiment described herein.

[0172] Storage component 630 stores information and / or software related to the operation and use of the system 600. For example, storage component 630 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0173] Input component 640 is configured to receive information, such as user input. For example, the input component 640 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 640 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0174] Output component 650 is configured to provide output information from the system 600. For example, the output component 650 may be, but not limited to, a display, a speaker, an instruction device to an external device, and / or one or more light-emitting diodes (LEDs).

[0175] Communication interface 660 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 660 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the system 600 and other devices. In other words, the standard of the communication interface 660 is not limited.

[0176] The bus 670 acts as an interconnect between the processor 610, the memory 620, the storage component 630, the input component 640, the output component 650, and the communication interface 660 of the system 600. The bus 670 may include a wired interconnection or a wireless interconnection.

[0177] The number and arrangement of components shown in FIG. 6 are provided as an example. In practice, system 600 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 6. Additionally, or alternatively, a set of components (e.g., one or more components) of system 600 may perform one or more functions described as being performed by another set of components of system 600. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of system 600 in communication with one another.

[0178] Further, according to example embodiments, the system 600 may include one or more elements from the system architecture described above in relation to FIG. 1. For example, the system 600 may include the base station.

[0179] In the present disclosure, specific tasks may be performed using AI / ML (Artificial Intelligence / Machine Learning) models. An AI / ML model is a model generated using one or more Al technologies, one or more ML algorithm or both, and generates output data based on input data. This output data is used to perform tasks. Tasks performed using AI / ML models include those generally referred to as intellectual tasks, such as classification, prediction, natural language processing, etc.

[0180] Although Al and ML are explained separately, ML is a technology included in Al. In ML, instead of being explicitly programmed for a specific task, systems can improve theirperformance over time by identifying patterns and making inferences from training data. Typically, the generation of ML models includes data collection, model training, and model inference. Data collection involves gathering and preprocessing data to be used for training and inference. Model training involves developing and validating models using the collected data. Model inference involves applying the trained models to new data to generate new output data and perform tasks.

[0181] Machine learning includes various types of learning methods such as supervised learning, unsupervised learning, reinforcement learning, semi-supervised learning, self-supervised learning, transductive learning, transfer learning, meta learning, and the like. These types of learning methods can be appropriately selected according to the embodiments. Unless otherwise specified, the application of types not mentioned in this description is not precluded. Additionally, the structure of ML models may vary depending on the embodiments and learning methods, and is not limited to the methods disclosed. Furthermore, ML includes deep learning, which uses models that include neural networks. Deep learning models may include, for example, deep neural networks (DNNs), convolutional neural networks (CNNs), etc.

[0182] It should be noted that the AI / ML models presented hereinafter are examples and are not limited to the illustrated AI / ML models. They can be modified or altered by using different Al or ML algorithms. The configuration of the neural network is not limited to the configuration disclosed in the present disclosure and can be modified.

[0183] FIG. 7 is a diagram of an example of implementation environment 700 in which systems and / or method, described herein, may be implemented. The implementation environment 700 includes a UE (User equipment) 710, a service environment 720, and a network 730. The service environment 720 include one or more sub-environments 721. To illustrate this, FIG. 7shows, for convenience, examples of a 1st sub-environment 721-1, a 2nd sub-environment 721-2, and an N-th sub-environment 721-N (where N is any natural number).

[0184] The UE 710 is connected to the network 730, and the network 730 is connected to the service environment 720. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 710 and the service environment 720 are connected via the network 730.

[0185] The UE 710 is a device that communicates with the service environment 720. The UE 710 receives information from the service environment 720 and / or sends information to the service environment 720. Also, the UE 710 may generate and / or store information to be transmitted, as necessary. Also, the UE 710 may store and / or process information that is received, as necessary.

[0186] The example figure 7 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device,” “terminal,” “terminal device,” “communication device,” and “communication terminal” can be used interchangeably with the term “UE.”

[0187] For example, the UE 710 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device.

[0188] The service environment 720 is an environment that communicates with the UE 710 to provide one or more services. The service environment 720 receives information from the UE 710 and / or sends information to the UE 710. Also, the service environment 720 may generateand / or store information to be transmitted, as necessary. Also, the service environment 720 may store and / or process information that is received, as necessary. For example, the service environment 720 may provide computing resources as one of the services. It should be noted that the service is not limited to being provided to the UE; it may also be provided to devices other than the UE. For example, based on communication from the UE, the service may perform processes such as anomaly detection or traffic analysis and notify the results to a predetermined destination.

[0189] The example figure 7 refers to the “service environment”. The term "service environment" is used to refer to the broader context within which services operate. For example, cloud environments, platforms, computing systems, network systems, and cloud systems generally represent the environments in which services are conducted, and these are included within the "service environment." However, the "service environment" is not limited to these examples. Additionally, the specific types of environments within the "service environment" are not restricted. For instance, cloud environments and cloud systems can be categorized as private cloud, public cloud, hybrid cloud, or multi-cloud, all of which are included within the "service environment.”

[0190] The one or more services provided by the service environment 720 is not specifically limited and can be adjusted according to the embodiments. For example, the services may include a service that provides information to the UE 710, a service that stores information from the UE 710, or a service that performs processing based on information from the UE 710 and returns the results of the processing.

[0191] In an embodiment, the Service Environments 720 may also provide computing resources as the service. The computing resources can be hardware resources and / or softwareresources. For example, applications, processors, memory, and storage can be included in the provided computing resources. Each computing resource can communicate with other computing resources via wired connections, wireless connections, or a combination of wired and wireless connections.

[0192] The provided computing resources can be actual resources (also referred to as physical resources) and / or virtual resources. Furthermore, means of virtualization for virtual resources can be selected as appropriate. That is, in this disclosure, the use of adjectives such as "Virtual" or "Virtualized" to describe names does not imply that they are virtualized by a specific means of virtualization. For example, “virtual machine” refers to software that operates like an actual computer, realized through means of virtualization, and it is not intended to exclude those realized by specific means of virtualization such as Hypervisors or Containers. Conversely, when means of virtualization such as Hypervisors or containers are mentioned in this disclosure, it is merely cited as a general method of implementation. It should also be interpreted that embodiments implemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0193] The service environment 720 includes one or more devices, such as servers and network devices, which provide services or perform processes. The placement of these devices within the service environment 720 can be determined as appropriate. Additionally, if the service environment 720 includes one or more sub-environments 721, the placement of devices can be determined based on predetermined policies for each sub-environment 721. For example, devices related to the first service may be placed in the 1st sub-environment 721-1, and devices related to the second service may be placed in the 2nd sub-environment 721-2. In another example, devicesexpected to have a higher load than a predetermined threshold may be placed in the 1st subenvironment 721-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 721-2. In this way, specific devices can be placed in specific sub -environments 721. Conversely, each sub-environment 721 can be specialized for a particular purpose.

[0194] In an embodiment, all processes executed in a single service may run within a single service environment, or in multiple service environments. Multiple processes executed in a single service could be provided by different service environments.

[0195] The network 730 is a network that exchanges information between the UE 710 and the service environment 720. The network 730 includes one or more wired and / or wireless networks.

[0196] For example, the network 730 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, a non-terrestrial network (NTN), and / or a combination of these or other types of networks.

[0197] The network 730 can be a part of a network. For example, in a 5G network that includes a RAN, a transport network, and a core network, the network 730 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 720could be in the core network, in which case the network 730 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0198] The number and arrangement of devices and networks shown in FIG. 7 are provided as an example. It should be understood that any changes that may be implemented by those skilled in the art, such as the addition or rearrangement of well-known devices or networks at the time of implementation, are included in this disclosure.

[0199] Various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: A system that may include a base station that may be configured to: receive, from a plurality of user equipment (UEs), a status notification specifying an orthogonal cover code (OCC) length associated with the respective UE; assign each of the plurality of UEs to one of a plurality of OCC groups based on the OCC length associated with the respective UE, such that OCC lengths of all UEs in a particular OCC group are same; and allocate physical resource blocks (PRBs) to the plurality of UEs based on an OCC group assigned to the respective UE.Item [2]: The apparatus according to item [1], wherein the status notification may further specify a carrier frequency offset (CFO) associated with the respective UE, and wherein each of the plurality of UEs may be assigned to one of the plurality of OCC groups further based on the CFO associated with the respective UE such that a CFO differential between any two UEs within a particular OCC group is less than a threshold.Item [3]: The apparatus according to one of items [l]-[2], wherein the plurality of UEs may include a first UE that may be assigned to an initial OCC group of the pluralityof OCC groups, and wherein the system may be further configured to: determine channel conditions associated with the plurality of OCC groups, wherein the channel conditions may include at least one of: Doppler shift, CFO, signal to interference noise ratio (SINK), and traffic level; and reassign the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups based on the channel conditions.Item [4]: The apparatus according to item [3], wherein the first UE may be configured to perform hybrid automatic repeat request (HARQ) retransmission based on the updated OCC group.Item [5]: The apparatus according to one of items [l]-[4], wherein the plurality of UEs may include a first UE that may be assigned to an initial OCC group of the plurality of OCC groups, and wherein the system may be further configured to: determine beam movement predictions associated with the plurality of UEs; and reassign the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups based on the beam movement prediction.Item [6]: The apparatus according to one of items [l]-[5], wherein the plurality of UEs may include a first UE that may be assigned to an initial OCC group of the plurality of OCC groups, and wherein the system may be further configured to: determine priorities associated with hybrid automatic repeat request (HARQ) acknowledge (ACK) / negative acknowledge (NACK), scheduling request (SR), and channel state information (CSI) of an uplink control information (UCI) associated with the first UE; transmit, to the first UE, the determined priorities; and receive, from the first UE, the UCI multiplexed onto OCC-physical uplink shared channel (PUSCH) based on the determined priorities and the initial OCC group.Item [7]: The apparatus according to one of items [l]-[6], wherein the base station and the plurality of UEs may be communicatively coupled with each other over a nonterrestrial network (NTN) environment.Item [8]: A method that may include: receiving, from a plurality of user equipment (UEs), a status notification specifying an orthogonal cover code (OCC) length associated with the respective UE; assigning each of the plurality of UEs to one of a plurality of OCC groups based on the OCC length associated with the respective UE, such that OCC lengths of all UEs in a particular OCC group are same; and allocating physical resource blocks (PRBs) to the plurality of UEs based on an OCC group assigned to the respective UE.Item [9]: The method according to item [8], wherein the status notification may further specify a carrier frequency offset (CFO) associated with the respective UE, and wherein each of the plurality of UEs may be assigned to one of the plurality of OCC groups further based on the CFO associated with the respective UE such that a CFO differential between any two UEs within a particular OCC group is less than a threshold.Item

[0010] : The method according to one of items [8]-[9], wherein the plurality of UEs may include a first UE that may be assigned to an initial OCC group of the plurality of OCC groups, and wherein the method may further include: determining channel conditions associated with the plurality of OCC groups, wherein the channel conditions may include at least one of: Doppler shift, CFO, signal to interference noise ratio (SINK),and traffic level; and reassigning the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups based on the channel conditions.Item

[0011] : The method according to item

[0010] , wherein the first UE may be configured to perform hybrid automatic repeat request (HARQ) retransmission based on the updated OCC group.Item

[0012] : The method according to one of items [8]-[l 1], wherein the plurality of UEs may include a first UE that may be assigned to an initial OCC group of the plurality of OCC groups, and wherein the method may further include: determining beam movement predictions associated with the plurality of UEs; and reassigning the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups based on the beam movement prediction.Item

[0013] : The method according to one of items [8]-

[0012] , wherein the plurality of UEs may include a first UE that may be assigned to an initial OCC group of the plurality of OCC groups, and wherein the method may further include: determining priorities associated with hybrid automatic repeat request (HARQ) acknowledge (ACK) / negative acknowledge (NACK), scheduling request (SR), and channel state information (CSI) of an uplink control information (UCI) associated with the first UE; transmitting, to the first UE, the determined priorities; and receiving, from the first UE, the UCI multiplexed onto OCC-physical uplink shared channel (PUSCH) based on the determined priorities and the initial OCC group.Item

[0014] : The method according to one of items [8]-

[0013] , wherein the method may be performed by a base station that may be communicatively coupled to the plurality of UEs over a non-terrestrial network (NTN) environment.Item

[0015] : A non-transitory computer-readable recording medium that may have recorded thereon instructions executable by a system to cause the system to perform a method including: receiving, from a plurality of user equipment (UEs), a status notification specifying an orthogonal cover code (OCC) length associated with the respective UE; assigning each of the plurality of UEs to one of a plurality of OCC groups based on the OCC length associated with the respective UE, such that OCC lengths of all UEs in a particular OCC group are same; and allocating physical resource blocks (PRBs) to the plurality of UEs based on an OCC group assigned to the respective UE.Item

[0016] : The non-transitory computer-readable recording medium according to item

[0015] , wherein the status notification may further specify a carrier frequency offset (CFO) associated with the respective UE, and wherein each of the plurality of UEs may be assigned to one of the plurality of OCC groups further based on the CFO associated with the respective UE such that a CFO differential between any two UEs within a particular OCC group is less than a threshold.Item

[0017] : The non-transitory computer-readable recording medium according to one of items

[0015] -

[0016] , wherein the plurality of UEs may include a first UE that may be assigned to an initial OCC group of the plurality of OCC groups, and wherein the method may further include: determining channel conditions associated with the plurality of OCC groups, wherein the channel conditions may include at least one of: Doppler shift, CFO,signal to interference noise ratio (SINR), and traffic level; and reassigning the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups based on the channel conditions.Item

[0018] : The non-transitory computer-readable recording medium according to item

[0017] , wherein the first UE may be configured to perform hybrid automatic repeat request (HARQ) retransmission based on the updated OCC group.Item

[0019] : The non-transitory computer-readable recording medium according to one of items

[0015] -

[0018] , wherein the plurality of UEs may include a first UE that may be assigned to an initial OCC group of the plurality of OCC groups, and wherein the method may further include: determining beam movement predictions associated with the plurality of UEs; and reassigning the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups based on the beam movement prediction.Item

[0020] : The non-transitory computer-readable recording medium according to one of items

[0015] -

[0019] , wherein the plurality of UEs may include a first UE that may be assigned to an initial OCC group of the plurality of OCC groups, and wherein the method may further include: determining priorities associated with hybrid automatic repeat request (HARQ) acknowledge (ACK) / negative acknowledge (NACK), scheduling request (SR), and channel state information (CSI) of an uplink control information (UCI) associated with the first UE; transmitting, to the first UE, the determined priorities; and receiving, from the first UE, the UCI multiplexed onto OCC-physical uplink shared channel (PUSCH) based on the determined priorities and the initial OCC group.

[0200] It is understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.Various Aspects of Embodiments

[0201] 3GPP TSG RAN WG2 #129 R2-NTN Uplink capacity

[0202] Agenda Item: 8.8.3

[0203] Source: Rakuten Mobile

[0204] Title: Discussion on NR-NTN Uplink Capacity / Throughput Enhancement

[0205] Document for: Discussion

[0206] Introduction

[0207] With the evolution of OCC-based uplink multiplexing in NR-NTN, RANI has reached agreements on various aspects of this technique, setting the foundation for spectral efficiency improvements. As per Rakuten Mobile’s understanding, while OCC multiplexing provides notable gains, its integration into RAN2 protocols requires enhancements in key areas such as capability signaling, scheduling, HARQ retransmissions, and control information handling to ensure seamless deployment in NTN-specific conditions.

[0208] Summary of RANI Agreements Relevant to RAN2, RANI has confirmed the following OCC techniques.

[0209] Inter-slot OCC for OCC length 2, enabling multiplexing of up to 2 UEs per PRB.

[0210] Inter-slot OCC for OCC length 4, using Hadamard sequences to multiplex up to 4 UEs per PRB.

[0211] Intra-symbol pre-DFT OCC for OCC length 4, as an alternative multiplexing technique.

[0212] Combination of inter-slot OCC with intra-symbol OCC, which remains under further study.

[0213] Additionally, RANI has concluded that:

[0214] No changes to TBS calculation or rate matching are required for OCC-based PUSCH.

[0215] RV cycling will use a fixed RV value within each OCC group, while cycling across groups is under discussion.

[0216] CFO grouping is assumed to be feasible at the network level without specification impact, but the performance impact of large differential CFO (e.g., 400 Hz) remains a concern.

[0217] While these agreements establish the feasibility of OCC-based multiplexing, RAN2 must address protocol-level implications, particularly in:

[0218] UE capability signaling and OCC configuration updates for dynamic scheduling.

[0219] Handling of UCI transmission when PUCCH and OCC-PUSCH overlap.

[0220] HARQ and scheduling optimizations for OCC retransmissions.

[0221] Inter-beam OCC scheduling in NTN scenarios.

[0222] This contribution analyzes open RAN2 aspects and proposes enhancements aimed at ensuring efficient operation of OCC-based uplink multiplexing in NTN environments.

[0223] Discussion

[0224] 2.1 UE Capability Signaling for OCC-Based Uplink Multiplexing

[0225] The deployment of OCC-based uplink multiplexing requires UEs to indicate their support for OCC length 2 and OCC length 4. However, existing NR NTN specifications do not define explicit capability signaling for OCC, making it challenging for networks to dynamically allocate PRBs to OCC-capable UEs. Without proper signaling, networks may inefficiently allocate non-OCC resources to OCC-capable UEs, reducing system efficiency.

[0226] Furthermore, CFO (Carrier Frequency Offset) grouping is a critical requirement for OCC performance in NTN. RANI discussions have highlighted that OCC performance can degrade by up to 1 dB if differential CFO among UEs exceeds 200 Hz. Since CFO effects are more pronounced in NTN due to Doppler shifts, a signaling mechanism is required to enable networks to group UEs based on CFO characteristics. Without such a mechanism, OCC multiplexing may fail to achieve its expected gains in NTN deployments.

[0227] Observation 1:

[0228] Current NR NTN specifications do not define explicit UE capability signaling for OCC support, leading to inefficiencies in resource allocation and scheduling decisions.

[0229] Proposal 1:

[0230] RAN2 may consider defining new UE capability indicators in RRC signaling (TS 38.331) to specify:

[0231] Support for OCC length 2 and OCC length 4, allowing networks to allocate PRBs efficiently.

[0232] A dynamic OCC configuration update procedure, allowing networks to modify OCC assignments based on real-time link conditions.

[0233] Optional CFO-based grouping capability indicators, enabling more efficient UE clustering for OCC scheduling.

[0234] 2.2 Handling of Uplink Control Information (UCI) in OCC-Based Transmission

[0235] UCI transmission handling is a critical issue in OCC-based multiplexing. Given that uplink PRB availability is limited in NTN, PUCCH and OCC-PUSCH may overlap, requiring a mechanism to determine whether UCI should be prioritized or multiplexed onto PUSCH.

[0236] RANI has explored multiple options for handling UCI-PUSCH conflicts, but no definitive approach has been adopted. The primary options under consideration include:

[0237] Dropping UCI when it overlaps with OCC-PUSCH, which may lead to excessive retransmissions and HARQ inefficiencies.

[0238] Prioritizing PUCCH transmission over OCC-PUSCH, which ensures reliable UCI transmission but reduces the spectral efficiency of OCC-based PUSCH.

[0239] Multiplexing UCI onto OCC-PUSCH, allowing simultaneous control and data transmission but increasing scheduling complexity.

[0240] Given that NTN uplink has limited retransmission opportunities due to long propagation delays, dropping UCI is not a viable solution. However, simple PUCCH prioritization also reduces efficiency, necessitating an optimized multiplexing approach.

[0241] Observation 2:

[0242] The handling of UCI in OCC-based uplink transmission remains undefined, leading to potential inefficiencies in scheduling and control signaling.

[0243] Proposal 1 : UCI Multiplexing Mechanism for OCC-PUSCH

[0244] Define UCI repetition across OCC transmissions for robustness.

[0245] Specify a priority framework for HARQ-ACK, SR, and CSI at the MAC level (TS 38.321).

[0246] Introduce RRC signaling (TS 38.331) to indicate UE support for UCI multiplexing on PUSCH.

[0247] Proposal 2a: Hybrid UCI Multiplexing Scheme

[0248] Ensure HARQ-ACK is prioritized over CSI feedback.

[0249] Define conditions for multiplexing CSI feedback onto PUSCH.

[0250] Introduce MAC signaling to configure UCI handling behavior .

[0251] 2.3 HARQ and Inter-Beam OCC Scheduling for NTN

[0252] The introduction of OCC-based multiplexing introduces complexities in scheduling and HARQ retransmission handling. A key concern is whether HARQ retransmissions should maintain the same OCC index assignment or whether adaptive OCC group reassignment should be permitted. Given that NTN link conditions fluctuate due to Doppler effects and beam switching, maintaining fixed OCC assignments for retransmissions may not always be optimal.

[0253] Additionally, there is no existing MAC scheduling mechanism that dynamically optimizes OCC group assignment based on real-time link conditions. This gap in standardization means that NTN deployments may struggle to achieve the full potential of OCC-based multiplexing unless RAN2 explicitly defines scheduling frameworks that incorporate dynamic OCC reassignment.

[0254] Observation 3:

[0255] OCC-based uplink transmission lacks clear HARQ retransmission and MAC scheduling guidelines. Additionally, inter-beam OCC scheduling remains undefined, which may limit the spectral efficiency benefits of OCC multiplexing in NTN.

[0256] Proposal 3: Dynamic OCC Scheduling Framework

[0257] Enable adaptive OCC group reassignment for HARQ retransmissions based on channel conditions.

[0258] Define MAC scheduling policies to optimize OCC-based multiplexing for NTN uplink.

[0259] Introduce MAC control signaling for real-time OCC adjustments based on traffic demands.

[0260] Conclusion

[0261] In this contribution, we discussed about the aspects related to the selection of the OCC techniques to improve uplink capacity / throughput and our proposals and observations are summarized as following:

[0262] 1. Adaptive OCC Group Reassignment for HARQ Retransmissions

[0263] Proposal Basis: OCC-based uplink lacks defined HARQ retransmission rules. Current mechanisms may cause inefficiencies if retransmissions are fixed to the same OCC index.

[0264] Dynamic OCC Group Switching for HARQ — > Instead of retransmitting within the same OCC group, HARQ retransmissions dynamically switch to a more optimal OCC group based on link conditions (e.g., Doppler, CFO, SINR).

[0265] Stage-2 (RAN2 Contribution):

[0266] Introduce a HARQ adaptation policy in TS 38.321 allowing retransmissions to switch to a different OCC group.

[0267] Define new MAC signaling fields that allow the gNB to indicate when a UE should change its OCC group for retransmissions.

[0268] Stage-3 (Implementation Aspects):

[0269] Extend HARQ feedback processing to track OCC group assignments dynamically.

[0270] Implement scheduling policies that factor in historical HARQ failure rates for OCC reassignment.

[0271] 2. Beam -A ware OCC Scheduling for NTN

[0272] OCC assignments in NTN should consider beam transitions, but no inter-beam OCC scheduling mechanisms exist.

[0273] Preemptive Beam-Aware OCC Reassignment — The gNB predicts UE movement between beams and preassigns a new OCC group before a beam switch occurs.

[0274] Stage-2 (RAN2 Contribution):

[0275] Define a Beam Transition-Induced OCC Reallocation Procedure in TS 38.321.

[0276] Introduce UE capability signaling (TS 38.331) to indicate support for inter-beam OCC scheduling.

[0277] Stage-3 (Implementation Aspects):

[0278] Develop an Al-based beam prediction model that estimates when a UE will switch beams.

[0279] Implement OCC group coordination between adjacent beams to ensure a UE receives a consistent OCC assignment post-switch.

[0280] 4. Hybrid UCI Prioritization Mechanism for OCC-Based PUSCH

[0281] Proposal Basis: OCC multiplexing requires a UCI prioritization strategy, ensuring HARQ-ACK takes precedence over CSI while maintaining spectral efficiency.

[0282] Dynamic UCI Prioritization Algorithm A mechanism that reorders UCI transmissions based on network congestion, signal quality, and UE type.

[0283] Stage-2 (RAN2 Contribution):

[0284] Define priority-based UCI multiplexing rules in TS 38.321.

[0285] Introduce UE capability indicators in TS 38.331 to specify UCI multiplexing preferences.

[0286] Stage-3 (Implementation Aspects):

[0287] Implement a machine-learning-based priority assignment that dynamically classifies UCI packets based on urgency and transmission success probability.

[0288] 4. Real-Time OCC Adjustment Based on Traffic Demand

[0289] Proposal Basis: Current OCC group assignments are static, leading to inefficiencies when traffic demand fluctuates.

[0290] Dynamic OCC Reallocation Based on QoS — Instead of pre-assigned OCC groups, an intelligent scheduling mechanism reallocates UEs in real time based on traffic patterns.

[0291] Stage-2 (RAN2 Contribution):

[0292] Introduce MAC control signaling (TS 38.321) to allow gNB to modify OCC groups dynamically.

[0293] Define a QoS-based OCC reassignment procedure in TS 38.331.

[0294] Stage-3 (Implementation Aspects):

[0295] Implement a traffic-aware scheduler that detects congestion and optimizes OCC allocations accordingly.

[0296] 5. CFO-Based UE Clustering for OCC Scheduling

[0297] Proposal Basis: OCC performance degrades when UEs have large differential CFOs. A clustering mechanism can improve scheduling efficiency.

[0298] Carrier Frequency Offset (CFO)-Based UE Grouping for OCC A mechanism that groups UEs into OCC clusters based on their CFO to reduce interference and improve decoding reliability.

[0299] Stage-2 (RAN2 Contribution):

[0300] Introduce CFO-aware UE clustering as a new MAC scheduling feature in TS 38.321.

[0301] Define new RRC parameters in TS 38.331 for CFO-based OCC grouping support.

[0302] Stage-3 (Implementation Aspects):

[0303] Implement an adaptive CFO tracking system that monitors UE frequency offsets and reassigns them to the most appropriate OCC groups.

[0304] References

[0305] RP -234078, RANP#102, “Non-Terrestrial Networks (NTN) for NR Phase 3”

[0306] RP -241659, RANP#104, “Non-Terrestrial Networks (NTN) for NR Phase 3”

[0307] 3 GPP RAN1#117 chairman notes

[0308] Annex

[0309] RAN1#118-bis meeting agreements

[0310] Working assumption

[0311] For the normative phase,

[0312] Support OCC length 2 with inter-slot OCC to multiplex up to 2 UEs.

[0313] Support OCC length 4 with one of the following OCC techniques

[0314] Option 1 : Inter-slot with OCC length 4 to multiplex up to 4 UEs.

[0315] Option 2: Intra-symbol pre-DFT OCC with OCC length 4 to multiplex up to 4 UEs.

[0316] Option 3 : Combination of Inter-slot OCC with OCC length 2 and intra-symbol pre-DFT OCC with OCC length 2 to multiplex up to 4 UEs.

[0317] Note l:

[0318] At least consider 8 slots, 16 slots, and 20 slots for VoIP with BLER 2% target, with 1 RB, 2 RBs when comparing Option 1, Option 2, and Option 3. Companies can additionally report on 4 slots at least for 2 RBs.

[0319] Option 2 assumes TBoMS, FFS Option 3 assumes TBoMS

[0320] Note 2: as part of the working assumption, it is assumed that there would be separate UE capabilities for OCC length 2 and OCC length 4, where UE capability for OCC length 2 is a prerequisite for UE capability for OCC length 4.

[0321] Conclusion

[0322] For TBS calculation and rate matching for OCC with PUSCH, for inter-slot OCC in the working assumption of RAN1#118bis :

[0323] for inter-slot OCC for OCC length 2 and for inter-slot OCC for OCC length 4 in option 1 in the working assumption of RANl#118bis

[0324] No change in determination of TBS

[0325] No change for rate matching

[0326] Agreement

[0327] For RV cycling for OCC with PUSCH

[0328] For inter-slot OCC for OCC length 2 and for inter-slot OCC for OCC length 4 in option 1 in the working assumption of RAN1#118bis

[0329] Same RV value is used in one OCC group (i.e., OCC length applied to N slots).

[0330] FFS: RV cycling can be additionally used across OCC groups

[0331] Agreement

[0332] For OCC sequence for OCC with PUSCH:

[0333] For OCC length 2, re-use orthogonal sequence [1 1; 1 -1]

[0334] RAN1#118 meeting agreements

[0335] Agreement

[0336] At least one of the OCC techniques when PUSCH repetitions are used will be specified:

[0337] Inter-slot time-domain OCC with OCC length 2

[0338] Inter-slot time-domain OCC with OCC length 2 and 4

[0339] Intra-symbol pre-DFT-s OCC (comb-like structure as in PUCCH format 4) with OCC length 2

[0340] Intra-symbol pre-DFT-s OCC (comb-like structure as in PUCCH format 4) with OCC length 2 and 4

[0341] Note: combination of techniques is not precluded

[0342] PUSCH repetition Type B is not considered

[0343] Conclusion

[0344] Multiplexing of 8 UEs with PUSCH OCC is not discussed in RANI until the work for multiplexing of less than 8 UEs has been completed.

[0345] RAN1#117 meeting agreements

[0346] Conclusion [RAN1#117]

[0347] OCC with PUSCH can support at least multiplexing of 2 or 4 UEs and achieve up to 2 or 4 times capacity gains respectively, when repetitions are used.

[0348] Note: the actual gain may be less due to e.g. intra / inter cell interference.

[0349] Agreement [RAN1 117]

[0350] For the normative phase, at least one of the OCC techniques will be specified:

[0351] Inter-slot time-domain OCC with PUSCH repetition Type A with OCC length 2 or 4

[0352] Inter-symbol(s) time domain OCC with OCC length 2 or 4

[0353] Intra-symbol pre-DFT-s OCC (comb-like structure as in PUCCH format 4) with OCC length 2 or 4

[0354] FFS Combination of OCC techniques including multiplexing of 8 UEs

[0355] FFS Use of OCC techniques with TBoMS

[0356] FFS Backward compatibility with non-Rel-19 UEs

[0357] RANl#116-bis meeting agreement

[0358] Agreement

[0359] Support OCC for PUSCH in Rel-19 NRNTN:

[0360] At least PUSCH with Type A repetition

[0361] FFS PUSCH without Type A repetition for intra-symbol and / or inter-symbol cases

[0362] At least code length 2 or 4, FFS code length 8

[0363] FFS: number of RBs

[0364] Potential OCC techniques listed below are for further down-selection:

[0365] Inter-slot time-domain OCC with PUSCH repetition Type A

[0366] Inter-symbol(s) time domain OCC

[0367] Intra-symbol pre-DFT-s OCC (comb-like structure as in PUCCH format 4)

[0368] Combinations of OCC techniques

[0369] TBoMS for OCC techniques is FFS

[0370] Agreement

[0371] RANI to at least further study the potential specification aspects on OCC techniques:

[0372] TBS calculation / Rate matching

[0373] UCI multiplexing

[0374] RV cycling across repetitions

[0375] Frequency hopping, e.g. intra / inter slot

[0376] OCC indication / configuration

[0377] Power control

[0378] FFS others aspects

[0379] RAN1#116 meeting agreement

[0380] Agreement

[0381] Adopt the table below for assumptions for Evaluation parameters for link level evaluation in NR NTN UL capacity and throughput enhancements.

[0382] Agreement

[0383] Adopt the table below for assumptions for modelling impairments for link level evaluation in NR NTN UL capacity and throughput enhancements.

[0384] Agreement

[0385] Adopt the table below for assumptions for KPIs for link level evaluation in NR NTN UL capacity and throughput enhancements.

[0386] Agreement

[0387] Adopt the table below for assumptions for Evaluation parameters for link level evaluation in NR NTN UL capacity and throughput enhancements.

[0388] Agreement

[0389] Adopt the table below for assumptions for modelling impairments for link level evaluation in NR NTN UL capacity and throughput enhancements.

[0390] Agreement

[0391] Adopt the table below for assumptions for KPIs for link level evaluation in NR NTN UL capacity and throughput enhancements.

Claims

What is claimed is:

1. A system comprising:a base station configured to:receive, from a plurality of user equipment (UEs), a status notification specifying an orthogonal cover code (OCC) length associated with the respective UE;assign each of the plurality of UEs to one of a plurality of OCC groups based on the OCC length associated with the respective UE, such that OCC lengths of all UEs in a particular OCC group are same; andallocate physical resource blocks (PRBs) to the plurality of UEs based on an OCC group assigned to the respective UE.

2. The system according to claim 1 , wherein the status notification further specifies a carrier frequency offset (CFO) associated with the respective UE, and wherein each of the plurality of UEs is assigned to one of the plurality of OCC groups further based on the CFO associated with the respective UE such that a CFO differential between any two UEs within a particular OCC group is less than a threshold.

3. The system according to claim 1, wherein the plurality of UEs comprises a first UE that is assigned to an initial OCC group of the plurality of OCC groups, and wherein the system is further configured to:determine channel conditions associated with the plurality of OCC groups, wherein the channel conditions comprise at least one of: Doppler shift, CFO, signal to interference noise ratio (SINK), and traffic level; andreassign the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups based on the channel conditions.

4. The system according to claim 3, wherein the first UE is configured to perform hybrid automatic repeat request (HARQ) retransmission based on the updated OCC group.

5. The system according to claim 1, wherein the plurality of UEs comprises a first UE that is assigned to an initial OCC group of the plurality of OCC groups, and wherein the system is further configured to:determine beam movement predictions associated with the plurality of UEs; and reassign the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups based on the beam movement prediction.

6. The system according to claim 1, wherein the plurality of UEs comprises a first UE that is assigned to an initial OCC group of the plurality of OCC groups, and wherein the system is further configured to:determine priorities associated with hybrid automatic repeat request (HARQ) acknowledge (ACK) / negative acknowledge (NACK), scheduling request (SR), and channel state information (CSI) of an uplink control information (UCI) associated with the first UE;transmit, to the first UE, the determined priorities; andreceive, from the first UE, the UCI multiplexed onto OCC-physical uplink shared channel (PUSCH) based on the determined priorities and the initial OCC group.

7. The system according to claim 1, wherein the base station and the plurality of UEs are communicatively coupled with each other over a non-terrestrial network (NTN) environment.

8. A method comprising:receiving, from a plurality of user equipment (UEs), a status notification specifying an orthogonal cover code (OCC) length associated with the respective UE;assigning each of the plurality of UEs to one of a plurality of OCC groups based on the OCC length associated with the respective UE, such that OCC lengths of all UEs in a particular OCC group are same; andallocating physical resource blocks (PRBs) to the plurality of UEs based on an OCC group assigned to the respective UE.

9. The method according to claim 8, wherein the status notification further specifies a carrier frequency offset (CFO) associated with the respective UE, and wherein each of the plurality of UEs is assigned to one of the plurality of OCC groups further based on the CFO associated with the respective UE such that a CFO differential between any two UEs within a particular OCC group is less than a threshold.

10. The method according to claim 8, wherein the plurality of UEs comprises a first UE that is assigned to an initial OCC group of the plurality of OCC groups, and wherein the method further comprises:determining channel conditions associated with the plurality of OCC groups, wherein the channel conditions comprise at least one of: Doppler shift, CFO, signal to interference noise ratio (SINR), and traffic level; andreassigning the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups based on the channel conditions.

11. The method according to claim 10, wherein the first UE is configured to perform hybrid automatic repeat request (HARQ) retransmission based on the updated OCC group.

12. The method according to claim 8, wherein the plurality of UEs comprises a first UE that is assigned to an initial OCC group of the plurality of OCC groups, and wherein the method further comprises:determining beam movement predictions associated with the plurality of UEs; and reassigning the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups based on the beam movement prediction.

13. The method according to claim 8, wherein the plurality of UEs comprises a first UE that is assigned to an initial OCC group of the plurality of OCC groups, and wherein the method further comprises:determining priorities associated with hybrid automatic repeat request (HARQ) acknowledge (ACK) / negative acknowledge (NACK), scheduling request (SR), and channel state information (CSI) of an uplink control information (UCI) associated with the first UE;transmitting, to the first UE, the determined priorities; andreceiving, from the first UE, the UCI multiplexed onto OCC-physical uplink shared channel (PUSCH) based on the determined priorities and the initial OCC group.

14. The method according to claim 8, wherein the method is performed by a base station that is communicatively coupled to the plurality of UEs over a non-terrestrial network (NTN) environment.

15. A non-transitory computer-readable recording medium having recorded thereon instructions executable by a system to cause the system to perform a method comprising:receiving, from a plurality of user equipment (UEs), a status notification specifying an orthogonal cover code (OCC) length associated with the respective UE;assigning each of the plurality of UEs to one of a plurality of OCC groups based on the OCC length associated with the respective UE, such that OCC lengths of all UEs in a particular OCC group are same; andallocating physical resource blocks (PRBs) to the plurality of UEs based on an OCC group assigned to the respective UE.

16. The non-transitory computer-readable recording medium according to claim 15, wherein the status notification further specifies a carrier frequency offset (CFO) associated with the respective UE, and wherein each of the plurality of UEs is assigned to one of the plurality of OCC groups further based on the CFO associated with the respective UE such that a CFO differential between any two UEs within a particular OCC group is less than a threshold.

17. The non-transitory computer-readable recording medium according to claim 15, wherein the plurality of UEs comprises a first UE that is assigned to an initial OCC group of the plurality of OCC groups, and wherein the method further comprises:determining channel conditions associated with the plurality of OCC groups, wherein the channel conditions comprise at least one of: Doppler shift, CFO, signal to interference noise ratio (SINR), and traffic level; andreassigning the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups based on the channel conditions.

18. The non-transitory computer-readable recording medium according to claim 17, wherein the first UE is configured to perform hybrid automatic repeat request (HARQ) retransmission based on the updated OCC group.

19. The non-transitory computer-readable recording medium according to claim 15, wherein the plurality of UEs comprises a first UE that is assigned to an initial OCC group of the plurality of OCC groups, and wherein the method further comprises:determining beam movement predictions associated with the plurality of UEs; and reassigning the first UE from the initial OCC group to an updated OCC group of the plurality of OCC groups based on the beam movement prediction.

20. The non-transitory computer-readable recording medium according to claim 15, wherein the plurality of UEs comprises a first UE that is assigned to an initial OCC group of the plurality of OCC groups, and wherein the method further comprises:determining priorities associated with hybrid automatic repeat request (HARQ) acknowledge (ACK) / negative acknowledge (NACK), scheduling request (SR), and channel state information (CSI) of an uplink control information (UCI) associated with the first UE;transmitting, to the first UE, the determined priorities; andreceiving, from the first UE, the UCI multiplexed onto OCC-physical uplink shared channel (PUSCH) based on the determined priorities and the initial OCC group.

Images