SSB-less scell operation in a network

Abstract

Provided are apparatus, method, and device for automatically perform SSB-Less SCell operations. According to example embodiments, the system may include a non-RT RIC configured to implement at least one rApp; where the rApp may be configured to: configure, based on one or more network conditions, at least one policy, wherein the at least one policy may define one or more trigger conditions for a secondary cell (SCell) to stop transmitting a synchronization signal block (SSB) to a user equipment (UE); and control, via at least a distributed unit (DU), transmission of the SSB from the SCell to the UE based on the at least one policy.

Description

SSB-LESS SCELL OPERATION IN A NETWORKCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 554,336, filed with the U.S. Patent Office on February 16, 2024, the entire contents of which are incorporated herein by reference.FIELD

[0002] The present disclosure relate to a SSBdess SCell operation in a telecommunication 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] In order to enhance the performance of a telecommunication network, various features and mechanisms have been introduced. Among others, one or more technical specifications provided by one or more standard organizations, such as the technical specification provided by the 3rd Generation Partnership Project (3GPP) standard organization (e g., Release 18, etc.), have described the concepts and mechanisms related to Carrier Aggregation (CA).

[0005] In particular, a user equipment (UE) configured with Carrier Aggregation (CA) may be communicatively coupled to a plurality of serving cells, which comprises one primary cell (PCell) and one or more secondary cells (SCell). The primary cell serves as a main point ofcommunication between the UE and a base station, while the secondary cell provides additional radio resources / bandwidth to the UE on top of the primary cell. In order for the UE to communicate with the PCell and SCell, a Synchronization Signal Block (SSB) may be received and processed by the UE to synchronize and connect to the PCell and SCell.SUMMARY

[0006] Example embodiments of the present disclosure automatically perform SSB-Less SCell operations. As such, example embodiments of the present disclosure allow for prevention of unnecessary transmission of the SSB by the SCell to the UE, which subsequently prevents unnecessary waste of energy and resources and improves energy saving.

[0007] According to example embodiments, a system is provided. The system may include a non-RT RIC configured to implement at least one rApp; where the rApp may be configured to: configure, based on one or more network conditions, at least one policy, wherein the at least one policy may define one or more trigger conditions for a secondary cell (SCell) to stop transmitting a synchronization signal block (SSB) to a user equipment (UE); and control, via at least a distributed unit (DU), transmission of the SSB from the SCell to the UE based on the at least one policy.

[0008] According to example embodiments, a method is provided. The method may include: configuring, by an rApp based on one or more network conditions, at least one policy, wherein the at least one policy may define one or more trigger conditions for a secondary cell (SCell) to stop transmitting a synchronization signal block (SSB) to a user equipment (UE); and controlling, by the rApp via at least a distributed unit (DU), transmission of the SSB from the SCell to the UE based on the at least one policy.

[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 including: configuring, by an rApp based on one or more network conditions, at least one policy, wherein the at least one policy may define one or more trigger conditions for a secondary cell (SCell) to stop transmitting a synchronization signal block (SSB) to a user equipment (UE); and controlling, by the rApp via at least a distributed unit (DU), transmission of the SSB from the SCell to the UE based on the at least one policy.

[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 diagram of an example Synchronization Signal Block (SSB);

[0013] FIG. 2 illustrates an example system architecture, according to one or more example embodiments;

[0014] FIG. 3 illustrates a flow diagram of an example method for performing SSB-Less SCell operation, according to one or more embodiments;

[0015] FIG. 4 illustrates a flow diagram of an example method for controlling the transmission of the SSB from the SCell to the UE, according to one or more embodiments;

[0016] FIG. 5A illustrates a flow sequence of an example use case for controlling the transmission of the SSB, according to one or more embodiments;

[0017] FIG. 5B illustrates a flow sequence of an example use case for controlling the transmission of the SSB, according to one or more embodiments;

[0018] FIG. 6A illustrates a flow sequence of an example use case for controlling the transmission of the SSB, according to one or more embodiments;

[0019] FIG. 6B illustrates a flow sequence of an example use case for controlling the transmission of the SSB, according to one or more embodiments; and

[0020] FIG. 7 illustrates a diagram of example components of a device for implementing one or more example embodiments.DETAILED DESCRIPTION

[0021] 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 inpart). Further, the order of one or more operations may be switched, as long as these modifications may not affect the resulting scope of the invention.

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

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

[0024] 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 oneof [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.

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

[0026] 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 Access Network (0-RAN) Alliance standard organization, and the like. For instance, the terms “SSB”, “SCell”, “PCell”, “rApp”, “xApp”, “Al interface”, “E2 interface”, “Fl interface”, 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.

[0027] Further, although some embodiments of the present disclosure may be described herein with reference specific components of 5G system, it can be understood that the scope of the present disclosure should not be limited thereto. Specifically, example embodiments of the present disclosure may also apply to any suitable network elements in any suitable telecommunication system, such as a 4G LTE system, a 6G system, and the like, without departing from the scope of the present disclosure.

[0028] A radio access network (RAN) is an important component in a telecommunications system, as it connects end-user devices (or user equipment) to other parts of the network. The RANincludes a combination of various network elements (NEs) that connect end-users to a core network. Traditionally, hardware and / or software of a particular RAN is vendor specific.

[0029] With the evolvement in telecommunication network technologies, The RAN may be disaggregated into multiple nodes or entities. Specifically, the RAN functions may be disaggregated into multiple logical nodes or entities, such as a central unit (CU), a distributed unit (DU), and a radio unit (RU). The CU may be a logical node for hosting Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers of the RAN. The DU may be a logical node hosting Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. A single DU may host or serve multiple network cells formed by multiple RUs. The RU may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to a DU. In this regard, a network cell may correspond to one or more radio units responsible for providing wireless coverage and signal transmission within the network cell. To this end, since the disaggregated entities have open protocols and interfaces between them, they can be developed by different vendors.

[0030] In this regard, the mechanisms and procedures for user equipment (UE) cell search under Carrier Aggregation (CA) have been described in one or more 3 GPP technical specifications (e g., Release 18, etc.). Generally, cell search is a procedure by which the UE acquires time and frequency synchronization of a cell and detects a Cell ID of that cell in order to connect to that cell. The time and frequency synchronization and Cell ID may be acquired based on a Primary Synchronization Signal (PSS), Secondary Synchronization Signal (SSS), and Physical Broadcast Channel (PBCH) in a Synchronization Signal Block (SSB). It may be understood thatSynchronization Signal Block and Synchronization Signal and Physical Broadcast Channel (PBCH) Block may refer to a same element.

[0031] FIG. 1 illustrates a diagram of an example Synchronization Signal Block (SSB) 100. The x-axis of the diagram may define the length of Orthogonal Frequency-Division Multiplexing (OFDM) symbol, while the y-axis of the diagram may define the length of subcarriers.

[0032] As illustrated in FIG. 1, the SSB 100 may include a PSS 110, SSS 120, and PBCH 130, which comprises PBCH 132, PBCH 134, PBCH 136, and PBCH 138, and may span across subcarrier number 0 to 239 and OFDM symbol number 0 to 3.

[0033] The PSS 110 may occupy one symbol (i.e., 0) and 127 subcarriers (i.e., 56 to 182). Similarly, the SSS 130 may occupy one symbol (i.e., 2) and 127 subcarriers (i.e., 56 to 182). The PBCH 130 may occupy three symbols and 240 subcarriers. In particular, PBCH 132 and PBCH 134 may each occupy one symbol and 240 subcarriers (i.e., 1, 0 to 239 and 3, 0 to 239 respectively), while PBCH 136 and PBCH 138 may each occupy one symbol and 48 subcarriers (i.e., 2, 0 to 47 and 2, 192 to 239 respectively).

[0034] In some implementations, the SSB 100 may be broadcasted by a primary cell (PCell) and one or more secondary cells (SCell) of the UE, where the UE may receive the SSB 100 from the PCell and the one or more SCell to synchronize and connect to the PCell and one or more SCell. In view of the above, the SSB enables the UE to synchronize and connect to the PCell and one or more SCell.

[0035] Nevertheless, in the related art, the SSB for the SCell may be broadcasted at all times or be broadcasted during the times when the SCell is not required by the UE, which may unnecessarily waste energy and resources. For instance, if the PCell has already transmitted itsSSB and is already connected to the UE when there is low traffic and the PCell is already carrying most of the traffic, transmission of the SSB by the SCell may unnecessarily waste energy and resources.

[0036] Accordingly, system, methods, devices, and the like, provided in the example embodiments of the present disclosure performs SSB-less SCell operations, where transmission of the SSB from the SCell to the UE is controlled.

[0037] According to example embodiments, in order to perform SSB-Less SCell operation, an rApp may configure at least one Al policy defining one or more trigger conditions for a secondary cell (SCell) to stop transmitting a synchronization signal block (SSB) to a user equipment (UE), and may transmit such Al policy to an xApp. Further, the xApp may then receive the at least one Al policy and may control transmission of the SSB from the SCell to the UE based on the at least one Al policy.

[0038] Ultimately, example embodiments of the present disclosure automatically perform SSB-less SCell operations, which allows for prevention of unnecessary transmission of the SSB by the SCell to the UE, and subsequently prevents unnecessary waste of energy and resources and improves energy saving.

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

[0040] 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

[0041] FIG. 2 illustrates an example system architecture, according to one or more example embodiments. As illustrated in FIG. 2, the system architecture may include at least one Service Management and Orchestration (SMO) framework 210 that includes at least one non-real- time RAN Intelligent Controller (Non-RT RIC) 220, at least one near-real-time RIC (Near-RT RIC) 230, at least one O-RAN Centralized Unit (O-CU) 240, at least one O-RAN Distributed Unit (O-DU) 250, a plurality of O-RAN Radio Units (O-RUs) 260-1 to 260-3, and at least one O-Ran Cloud (O-Cloud) 270. The components may be communicatively coupled to another component(s) within the system architecture via a respective interface(s).

[0042] 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, in some implementations, the system architecture may further include an open evolved NodeB (O-eNB) that is communicatively coupled to the SMO framework 210 and the Near-RT RIC 230, the system architecture may include a plurality of O- DUs 250 each of which is communicatively coupled to the O-CU 240, the O-CU 240 may be disaggregated into the O-CU control plane (O-CU-CP) and the O-CU user plane (O-CU-UP), and the like.

[0043] The RAN functions in the system may be controlled and optimized by at least one RIC. The RIC may be a software-defined component that implements modular applications to facilitate the multivendor operability, as well as to automate and optimize RAN operations. As shown in FIG. 2, the RIC may be divided into two types, i.e., the Non-RT RIC 220 and the Near-RT RIC 230. In the following, descriptions of the Non-RT RIC 220 are provided, followed by the descriptions of the Near-RT RIC 230.

[0044] The Non-RT RIC 220 may refer to a logical function within the SMO framework 210 that drives the content carried across the Al interface to enable non-real-time control and optimization of RAN elements and resources. The Al interface may refer to a logical interface between the Non-RT RIC 220 and the Near-RT RIC 230, which enables the Non-RT RIC 220 to provide policy-based guidance (objective, resource) to the Near-RT RIC 230 and enables the Near- RT RIC 230 to provide one or more feedbacks to the Non-RT RIC 220 to monitor the status of one or more policies.

[0045] In some example, implementations, the Non-RT RIC 220 may be the control point of a non-real-time control loop and may operate on a timescale greater than 1 second within the SMO framework 210. The functionalities of the Non-RT RIC 220 may include, for example, providing policy-based guidance and enrichment across the Al interface, performing data analytics, Artificial Intelligence / Machine Learning (A 1 / M I.) models training and inference for RAN optimization, and / or recommending configuration management actions. As further described below, the Non-RT RIC 220 may access or communicate with other SMO framework functionalities or components via Al interface, 01 interface, 02 interface, and one or more interfaces associated with one or more open fronthaul planes.

[0046] According to example embodiments, the functionalities of the Non-RT RIC 220 may be implemented through at least one modular, Non-RT RIC application, such as the rApp 221. The rApp 221 may leverage the functionalities available in the SMO framework 210 and / or the Non-RT RIC 220 to provide value added services related to RAN operation and optimization, suchas policy management, radio resource management, data analytics, and providing enrichment information. In some implementations, the Non-RT RIC 220 may implement a plurality of rApps221.

[0047] According to example embodiments, the Non-RT RIC 220 may include a Non-RT RIC framework that may be configured to provide or implement one or more services to the rApp 221 through R1 interface. The R1 interface may refer to an open logical interface between the rApp 221 and the Non-RT RIC framework. The R1 interface supports the exchange of data or information, as well as the collection and delivery of data between the rApp 221 and the Non-RT RIC framework. The one or more services, which may also be referred to as “R1 services” herein, may include policy management services, service registration and discovery services, authentication and authorization services, AI / ML workflow services, RAN OAM-related services, Al related services, and 02 related services. The R1 interface allows multi-vendor rApps to manage or add the R1 services, and facilitate inter-connection between rApps and Non-RT RIC framework supplied by different vendors.

[0048] According to example embodiments, the rApp 221 may be configured to manage one or more policies that are provided to the Near-RT RIC 230 over the Al interface. Said policies may be referred to as “Al policies” herein, and are declarative policies that contain statements on policy objectives and policy resources applicable to one or more network nodes (e.g., one or more UEs, one or more network cells, etc.). Specifically, the one or more Al policies may consist of a scope identifier and one or more policy statements. The scope identifier may represent what the policy statements are to be applied on (e.g. UEs, QoS flows, or cells). The policy statements may define the goals or objectives of the policy and may include information associated with policyobjectives and policy resources. In an example, the Al policies may include Quality of Service (QoS) requirements and Energy Saving (ES) requirements, specifying, for example, new QoS Class Identifier (QCI) parameters that the xApp 231 should follow / utilize, and energy saving aggressiveness. By including the policy objectives in the policy statements, the quality of experience can be optimized for UEs or QoS flows that are identified either explicitly by, for example, a UE identifier or a QoS identifier, or implicitly by, for example, a group identifier from which the Near-RT RIC 230 can deduce a set of UEs. On the other hand, by including the policy resources in the policy statements, UEs can be configured to avoid certain cells and / or the radio network can be optimized in specific areas.

[0049] The rApp 221 (or the Non-RT RIC framework within the Non-RT RIC 220) may provide the one or more Al policies to the Near-RT RIC 230, thereby providing guidance to the Near-RT RIC 230 towards one or more objectives or goals defined in the RAN intent. The RAN intent may refer to the high-level operational or business goal(s) to be achieved by the RAN, which may be defined by one or more desired service level agreements (SLAs) that the RAN is to fulfill for all users or for a subset of users in a given area over at least a predefined period of time.

[0050] According to example embodiments, the rApp 221 may be configured to perform one or more policy management operations to provision and manage one or more Al policies in the Near-RT RIC. Specifically, the rApp 221 may be configured to create, update and delete one or more Al policies in the Near-RT RIC. For instance, the rApp 221 may query the presence, content and run-time status of one or more Al policies in the Near-RT RIC. In some example embodiments, the rApp 221 may manage the one or more Al policies to include information associated with transmission of the SSB. For example, the rApp 221 may determine, based on oneor more requirements (e.g., quality of service (QoS) requirement(s), energy saving requirement(s), etc.), guidance for SSB-less SCell operations (e.g., one or more trigger conditions, which network cell should implement the SSB-less SCell operations, which radio access technology (RAT) should be implemented, which frequency layer should be utilized, what should be the cell list priority, which UEs should be allowed to connect to the network cell that implements the SSB-less SCell operations, etc.). Accordingly, the rApp 221 may include the information of the guidance into the one or more Al policies, and then provide the one or more Al policies to the Near-RT RIC 230 via the Al interface.

[0051] According to example embodiments, the rApp 221 may be configured to receive, from the Near-RT RIC via the Al interface, one or more feedback associated with one or more Al policies (“Al policy feedback” herein). Similarly, the rApp 221 may be configured to receive one or more observables (e.g., events, counters, etc.) provided by the O-CU 240, the 0-DU 250, and / or one or more of the O-RUs 260 over the 01 interface. Accordingly, the rApp 221 maybe configured to continuously (or periodically) manage the one or more Al policies based on the Al policy feedback(s) and / or the observables provided over the 01 interface. For instance, the rApp 221 may continuously (or periodically) evaluate the impact or effectiveness of the one or more Al policies towards the fulfillment of the RAN intent and then configure or update the one or more Al policies accordingly. In this regard, by utilizing the Al policy feedback and / or the observability over 01, the Non-RT RIC 220 (or the rApp 221 implemented therein) can determine whether or not the SSB-less SCell operations achieve one or more QoS requirements and / or one or more energy saving requirements, and then manage the one or more Al policies based thereon, thereby enabling the Near-RT RIC 230 to optimize the network resources for a single UEs or for group of UEs.

[0052] By way of example, based on determining that a QoS requirement in a specific area is not satisfied or have a possibility of being violated, the rApp 221 may modify SSB-less SCell operations in said area, such that more SSB is transmitted by one or more SCells (e.g., reduces the time / conditions when an SCell does not transmit the SSB, etc.) and increases availability of network resources (e.g., bandwidth, network capacity, etc.) to improve the network performance (e.g., reduces latency, increases throughput, etc.) and to meet the QoS requirement. As another example, based on determining that an energy saving requirement in a specific area is not satisfied or have a possibility of being violated, the rApp 221 may modify SSB-less SCell operations in said area, such that less SSB is transmitted by one or more SCells (e.g., increases the time / conditions when an SCell does not transmit the SSB, etc.) and increases the energy saving opportunities in said area to meet the energy saving requirement.

[0053] In addition to the communication with the Near-RT-RIC 230 via the Al interface, the SMO framework 210 (as well as the Non-RT R1C 220 and / or the rApp 221 implemented therein) may communicate with the O-CU 240, the O-DU 250, and the O-RU(s) 260 via the 01 interface. In this regard, the 01 interface may refer to a logical interface between the SMO framework 210, the Near-RT RIC 230, the O-CU 240, the O-DU 250, and the O-RU(s) 260, which enables the SMO framework 210 (as well as the Non-RT RIC 220 and the rApp 221 implemented therein) to provide Fault, Configuration, Accounting, Performance, and Security (FCAPS) and other management operations, such as network monitoring, network discovery, and the like, to the Near-RT RIC 230, the O-CU 240, the O-DU 250, and / or the O-RU(s) 260. Additionally, the 01 interface enables the Near-RT RIC 230, the O-CU 240, the O-DU 250, and / or the O-RU(s) 260 to provide information or observable(s) that may be utilized by the Non-RT RIC 220 (or the rApp221) to manage the Al policy(s), to train one or more AI / ML models, and the like. According to example embodiments in which the O-eNB is included in the system architecture, the SMO framework may be communicatively coupled to the O-eNB via the 01 interface

[0054] Further, the SMO framework 210 (as well as the Non-RT RIC 220 and / or the rApp 221 implemented therein) may communicate with the O-Cloud 270 via the 02 interface. In this regard, the 02 interface may refer to a logical interface between the SMO framework 210 and the O-Cloud 270, which may be a collection of physical RAN nodes that host the Non-RT RIC 220, the Near-RT RIC 230, the O-CU 240, and the 0-DU 250, the supporting software components (e.g., the operating systems and runtime environments), and the SMO framework 210 itself. In other words, the SMO framework 210 may manage the O-Cloud 270 from within, and the 02 interface may be the interface between the SMO framework 210 and the O-Cloud 270 it resides in. Through the 02 interface, the SMO framework 210 (as well as the Non-RT RIC 220 and / or the rApp 221 implemented therein) may provide infrastructure management services (IMS) and deployment management services (DMS) for the O-Cloud 270.

[0055] Furthermore, the SMO framework 210 (as well as the Non-RT RIC 220 and / or the rApp 221 implemented therein) may communicate with the O-RU(s) 260 via an open fronthaul (O-FH) management plane (M-Plane) interface. In this regard, the O-FH M-Plane may enable the SMO framework 210 (as well as the Non-RT RIC 220 and / or the rApp 221 implemented therein) to perform one or more FCAPS operations on the O-RU(s) 260.

[0056] Next, the descriptions of the Non-RT RIC 230 are provided. The Near-RT RIC 230 may refer to a logical function that enables near-real-time control and optimization of RAN elements and resources. For instance, the Near-RT RIC 230 may provide the near-real-time controland optimization via fine-grained (e.g., UE basis, Cell basis) data collection and actions over the E2 interface. In some example, implementations, the Near-RT RIC 230 may operate on a timescale between 10 milliseconds and 1 second and may be coupled with the O-CU 240 and the O-DU 250 via the E2 interface. The Near-RT RIC 230 may use the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) over a near-real-time control loop.

[0057] According to example embodiments, the Near-RT RIC 230 may monitor, suspend / stop, override, and control the E2 nodes (e.g., O-CU 240, O-DU 250, etc.) via one or more Al policies. For example, the Near-RT RIC 230 may receive the one or more Al policies from the Non-RT RIC 220 (or the rApp 221 implemented therein) and then configure or set one or more policy parameters associated with the one or more Al policies on activated functions of the E2 nodes. Further, the Near-RT RIC 230 may host one or more applications, such as the xApp 231, to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, and the like.

[0058] In this regard, the xApp 231 may consist of one or more microservices, which may be independent of the Near-RT RIC 230 and may be provided by any third party. The E2 interface enables a direct association between the xApp 231 and other RAN functionalities (e.g., O-CU 240, O-DU 250, etc.), thereby enabling the xApp 231 to provide information or data to the RAN functionalities for further utilization. According to example embodiments, the Near-RT RIC 230 may consist of multiple xApps 231 and a set of platform functions that are commonly used to support the specific functions hosted by the multiple xApps 231. In this regard, the Near-RT RIC platform may communicate with the xApp(s) 231 via one or more application programminginterfaces (APIs). Further, the Near-RT RIC platform may be configured to route Al policy management messages to the registered xApps based on Al policy type and operator policies.

[0059] According to example embodiments, the Near-RT RIC 230 may implement the xApp 231 to configure one or more parameters associated with S SB-less SCell operations and then provide the one or more configured parameters associated with SSB-less SCell operations to the O-CU 240, the 0-DU 250, and / or one or more of the O-RUs 260. According to example embodiments, the xApp 231 may be configured to adjust or configure any one or more parameters associated with cell search and SSB, such as any one or more parameters associated with cell search and SSB defined in one or more 3 GPP technical standards.

[0060] According to example embodiments, the xApp 231 may be configured to adjust or configure one or more of the above-described parameters and optimize said one or more parameters according to the current Al policy(s) and the current network condition(s) (e.g., load, energy consumption, etc.), thereby providing controlling latency and throughput that fulfills the QoS requirement(s) and / or the energy saving requirement(s).

[0061] According to example embodiments, the xApp 231 may be configured to perform, based on the one or more adjusted or configured parameters, one or more control operations such as handling mobility handover (HO), performing traffic steering optimization to optimize performance, maintaining QoS targets, creating and modifying sleeping periods, guiding switching of PCell and SCell based on one or more conditions (e.g., traffic prediction and load), and the like. By way of example, the xApp 231 may be configured to monitor a specific type of UE (e g., Release- 18 network energy saving (NES) capable UE, non-NES capable UE, etc.), and then steerthe specific type of UE (e.g., non-NES capable UE, etc.) out of a cell before configuring the cell to apply SSB-less SCell operations.

[0062] According to example embodiments, the xApp 231 may be configured to perform the one or more control operations via the E2 interface. For instance, the xApp 231 may be configured to perform 0-DU E2 control and send one or more associated commands to the 0-DU 250. Accordingly, the 0-DU 250 may control the associated O-RU(s) or cell(s) to switch on or off SSB-less SCell operations. As another example, the xApp 231 may be configured to perform O- CU E2 control, where the O-CU 240 may send the one or more associated commands to the O- DU 250, and the O-DU 250 may then control the associated O-RU(s) or cell(s) to switch on or off SSB-less SCell operations. Accordingly, the 0-DU 250 may in the end shape the E2 control and policy, and the transmission of the SSB on the SCell may in the end be controlled by the 0-DU 250.

[0063] Next, the descriptions of the O-CU 240, the O-DU 250, and the O-RU 260 are provided. Generally, the O-CU 240, the 0-DU 250, and the O-RU 260 may constitute abase station, such as a gNodeB (gNB) of 5G NR or a node in Next Generation Radio Access Network (NG- RAN), an Evolved Node B (eNodeB) of a 4G LTE network, a base station of a 6G network, and the like.

[0064] The communication between the O-CU 240 and the 0-DU 250 may be performed via an Fl interface, while the communication between the O-DU 250 and the O-RU 260 may be performed via one or more O-FH Control (C), User (U), Synchronization (S), and Management (M) plane interfaces. In some implementations, the C, U, and S planes may be consolidated and referred to as the “CUS-plane”. According to example embodiments, the system may include aplurality of O-DUs 250, and the O-CU 240 may be communicatively coupled to the plurality of O-DUs via the Fl interface. Similarly, the system may include a plurality of O-RUs 260, and the 0-DU 250 may be communicatively coupled to the plurality of O-RUs via one or more of the O- FH C / U / S / M plane interfaces.

[0065] According to example embodiments, the O-CU 240 and the O-DU 250 may be defined in software form and may be deployed in one or more network nodes. For instance, the O- CU 240 and the O-DU 250 may be deployed in one or more servers in the form of virtualized network function (VNF), containerized and / or cloud-native function (CNF), and the like. According to example embodiments, the O-CU 240 and the O-DU 250 may be deployed in the same network node (e.g., same server) and / or may be located at a similar geographical location (e.g., be deployed in different servers in the same data center). According to example embodiments, the O-CU 240 and the O-DU 250 may be deployed in different network nodes and / or may be located at different geographical locations. For instance, the O-CU 240 may be deployed in one or more central servers (i.e., servers in one or more central data centers), and the O-DU 250 may be deployed in one or more edge servers (i.e., servers in one or more edge data centers).

[0066] The O-DU 250 may receive radio signals from an end user (via one or more UEs and one or more cells) and may provide operation or support for lower layers of protocol stacks (e g., RLC layer, MAC layer, Physical Layer, etc.) accordingly. As an example, the O-DU 250 may perform one or more scheduling operations. The O-CU 240 may communicatively couple the O-DU 250 to a core network (e.g., 4G Evolved Packet Core (EPC) network, 5G Core network, etc.) and may receive the radio signals from the O-DU 250, thereby providing operation or support for higher layers of protocol stacks (e.g., PDCP layer, RRC layer, etc.) accordingly.

[0067] Further, a single O-DU 250 may host or serve multiple network cells formed by multiple O-RUs 260. According to example embodiments, the O-DU 250 may implement various radio technologies, such as massive multiple-input multiple-output (MIMO), beamforming, and the like, to optimize radio communication among the multiple cells and the O-CU 240. In some implementations, the O-DU 250 may concurrently host or serve hundreds (e.g., 512, etc.) of cells at a time.

[0068] The O-RU(s) 260 may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to the O-DU 250. In this regard, a network cell described herein may correspond to one or more radio units responsible for providing wireless coverage and signal transmission within the network cell. The network cell may include a macro cell, a micro cell, a pi co cell, a femto cell, and / or any other suitable type of network cell. Each of the cells may have an associated coverage area, in which at least one O-RU 260, at least one antenna system, and any other suitable type of transport network element (TNE), may be deployed therein. According to example embodiments, one or more of the cells may be configured with SSB-Less SCell operations.

[0069] According to example embodiments, the O-CU 240 may be configured to control the SSB-Less SCell operations implementations or settings in the associated cell. In some example embodiments, the O-CU 240 may handle mobility handover (HO), perform traffic steering optimization (e.g., steering traffic between the PCell and SCell), maintain QoS targets, create and modify sleeping periods (e.g., periods when a cell is turned off), guide switching of PCell and SCell (e.g., determining which cells should be PCell and SCell) based on one or more conditions (e.g., traffic prediction and load), and the like. By way of example, the O-CU 240 may beconfigured to monitor a specific type of UE (e.g., Release-18 network energy saving (NES) capable UE, non-NES capable UE, etc.), and then steer the specific type of UE (e.g., non-NES capable UE, etc.) out of a cell before configuring the cell to apply SSB-less SCell operations.

[0070] According to example embodiments, the 0-DU 250 may be configured to control or instruct the associated O-RU(s) via one or more of the O-FH C / U / S / M plane interfaces. For instance, the 0-DU 250 may instruct the O-RU(s) 260 to enter the sleep mode via the O-FH C / U / S plane interfaces. On the other hand, the capability exchange between the O-DU 250 and the O- RU(s) 260 may be performed via the O-FH M-plane interface. As an example, the O-RU(s) 260 may inform the 0-DU 250 of the amount of time it requires to maintain in the sleep mode in order to save an amount of energy, and the 0-DU 250 may instruct the O-RU(s) 260 to stop transmission of a SSB to a UE mode for a longer time to save more energy when one or more conditions are satisfied (e.g., when the network traffic in the O-RU(s) 260 is below a threshold, etc.)

[0071] In view of the above, example embodiments of the present disclosure allow for prevention of unnecessary transmission of the SSB by the SCell to the UE, which subsequently prevents unnecessary waste of energy and resources and improves energy saving.Example Operations for Performing SSB-Less SCell Operation in the Present Disclosure

[0072] 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. 3.

[0073] FIG. 3 illustrates a flow diagram of an example method 300 for performing SSB- Less SCell operation, according to one or more 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 control transmission of the SSB.

[0074] According to example embodiments, the system may include at least a Non-RT RIC configured to implement at least one Non-RT RIC Application (rApp), and a near-real-time (Near-RT) RIC configured to implement at least one Near-RT RIC Application (xApp).

[0075] As illustrated in FIG. 3, at operation S310, the system may be configured to configure at least one policy. The at least one policy may be configured by the rApp and may define one or more trigger conditions for a secondary cell (SCell) to stop transmitting a synchronization signal Block (SSB) to a user equipment (UE). According to example embodiments, the one or more trigger conditions may include one or more of a time of a day, performance of a cell (e.g., PCell, SCell, and the like), and traffic volume of a cell, but it may be understood that the one or more trigger conditions are not limited thereto and may include any conditions related to performance and energy saving statuses of a cell (e.g., related to the QoS and ES requirements, and the like).

[0076] Further, the at least one policy may be configured based on one or more network conditions. According to example embodiments, the one or more network conditions may include one or more of traffic load, energy consumption, number of PCell, and number of SCell, but it may be understood that the one or more network conditions are not limited thereto and may include any conditions related to statuses and configuration of the network. According to example embodiments, the at least one policy may be configured based on one or more of Quality of Service (QoS) requirements and Energy Saving (ES) requirements. According to example embodiments, the SCell may include an inter-band SCell.

[0077] According to example embodiments, the at least one policy may further define one or more trigger conditions for the SCell to stop transmitting a system information block 1 (SIB 1)to the UE. The SIB 1 may refer to an information block containing cell access related information, such as public land mobile network (PLMN) identity list, tracking area code (TAC), cell identity, and the like.

[0078] According to example embodiments, the rApp may be configured to configure the at least one policy using an Artificial Intelligence (Al) / Machine Learning (ML) model, based on at least one of: user mobility patterns, service type requirements, and interference levels to improve overall network performance. According to example embodiments, the AI / ML model may be trained to optimize SSB transmission for energy savings, and may be capable of predicting low- traffic periods, adjusting transmission power, and shutting down unnecessary SSB transmissions to conserve energy. The method then proceeds to operation S320.

[0079] At operation S320, the system may be configured to control transmission of the SSB from the SCell to the UE. The transmission of the SSB may be controlled by the rApp via at least a distributed unit (DU). Further, the transmission of the SSB may be controlled based on the at least one policy.

[0080] According to example embodiments, the rApp may be communicatively coupled to the DU via an R1 interface and an 01 interface, and the rApp may be configured to control the transmission of the SSB via the DU, the R1 interface, and the 01 interface.

[0081] According to example embodiments, the rApp may be communicatively coupled to a control unit (CU) via an R1 interface and an 01 interface, where the CU may be communicatively coupled to the DU via an Fl interface. Accordingly, the rApp may be configured to control the transmission of the SSB via at least the CU, the DU, the R1 interface, the 01 interface, and the Fl interface.

[0082] In view of the above, according to example embodiments, the at least one policy may be similar to the Al policy described above in relation to FIG. 2 but is not being provided through an Al interface.

[0083] According to example embodiments, the non-RT RIC (which implements the rApp) may be communicatively coupled to a near-real-time (near-RT) RIC that may be configured to implement at least one near-RT RIC Application (xApp) via an Al interface, where the near-RT RIC (or the xApp implemented therein) may be communicatively coupled to at least the DU via an E2 interface. In this regard, the rApp may be configured to control the transmission of the SSB by providing the at least one policy to the xApp via the Al interface. Subsequently, the xApp may be configured to: receive the at least one policy from the rApp via the Al interface; and control, via at least the DU and the E2 interface, the transmission of the SSB from the SCell to the UE based on the at least one policy. In view of the above, according to example embodiments, the at least one policy may be similar to the Al policy described above in relation to FIG. 2.

[0084] According to example embodiments, the transmission of the SSB may be controlled by determining a cell different from the SCell to transmit the SSB to the UE when the SCell is not transmitting the SSB to the UE. According to example embodiments, the transmission of the SSB may be controlled by controlling the SCell to transmit a simplified SSB to the UE when the SCell is not transmitting the SSB to the UE.

[0085] According to example embodiments, the rApp and / or the xApp may be further configured to control, via at least the DU, transmission of the SIB 1 from the SCell to the UE based on the at least one policy.

[0086] According to example embodiments, the rApp and / or the xApp may be configured to dynamically adjust SSB transmission in response to real-time AI / ML model predictions, utilizing continuous learning from network data to enhance decision-making accuracy and efficiency.

[0087] According to example embodiments, the transmission of the SSB may be controlled by detecting the one or more trigger conditions, and stopping transmission of SSB from the SCell to the UE in response to detecting the one or more trigger conditions. According to example embodiments, the transmission of the SSB may be further controlled by determining, based on the at least one policy, one or more of which network cell should implement the S SB-less SCell operations, which radio access technology (RAT) should be implemented, which frequency layer should be utilized, and what should be the cell list priority. Examples of operations for controlling the transmission of the SSB from the SCell to the UE are described below with reference to FIG. 4.

[0088] According to example embodiments, the system may be configured to select appropriate cells for SSB-less operation based on a number of UE supporting Release 18 SSB-less operation. According to example embodiments, the cells may be selected by the Non-RT RIC (or the rApp implemented therein) or the Near-RT RIC (or the xApp implemented therein). According to example embodiments, the cells may be selected by identifying cells with high density of UE supporting Release 18 SSB-less operation, and evaluating performance metrics of cells including signal strength, traffic load, and Quality of Service (QoS) requirements.

[0089] According to example embodiments, the Near-RT RIC (or the xApp implemented therein) may be configured dynamically adjust a cell selection for SSB-less operation in real-timebased on fluctuating network conditions and UE mobility patterns. According to example embodiments, the Non-RT RIC (or the rApp implemented therein) may be configured to periodically update policies for the cell selection based on network performance feedback.

[0090] Upon performing operation S320, the method 300 may be ended or be terminated. Alternatively, method 300 may return to operation S310, such that the at least one processor may be configured to repeatedly perform, for at least a predetermined amount of time, the configuring the at least one policy (at operation S310) and the controlling the transmission of the SSB (at operation S320).

[0091] Accordingly, the above processes allow for prevention of unnecessary transmission of the SSB by the SCell to the UE, which subsequently prevents unnecessary waste of energy and resources and improves energy saving.Example Operations for Controlling the Transmission of the SSB from the SCell to the UE in the Present Disclosure

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

[0093] FIG. 4 illustrates a flow diagram of an example method 400 for controlling the transmission of the SSB from the SCell to the UE, according to one or more embodiments. One or more operations of method 400 may be part of operation S320 in method 300, and may be performed by the system of one or more example embodiments of the present disclosure. According to example embodiments, one or more operations of method 400 may be performed by the rApp and / or the xApp.

[0094] As illustrated in FIG. 4, at operation S410, the system may be configured to detect one or more trigger conditions. The one or more trigger conditions may be for a secondary cell (SCell) to stop transmitting a synchronization signal Block (SSB) to a user equipment (UE) defined in at least one policy as described above in relation to method 300. The method then proceeds to operation S420

[0095] At operation S420, in response to detecting the one or more trigger conditions, the system may be configured to stop transmission of the SSB from the SCell to the UE. The method then proceeds to operation S430.

[0096] At operation S430, the system may be configured to determine a method to obtain the SSB of the SCell for the UE. According to example embodiments, the system may be configured to determine a method to obtain the SSB of the SCell for the UE based on the at least one policy.

[0097] According to example embodiments, the at least one policy may specify one or more methods for obtaining the SSB of the SCell for the UE when the SCell is not transmitting the SSB to the UE. Accordingly, the system may be configured to determine a method to obtain the SSB of the SCell for the UE by selecting one of the one or more methods specified in the at least one policy. According to example embodiments, the system may be configured to determine a method to obtain the SSB of the SCell for the UE by selecting a combination of the one or more methods specified in the at least one policy.

[0098] According to example embodiments, the one or more methods may include one or more of a separate cell SSB transmission method, a simplified SSB transmission method, and a prediction method, but it may be understood that the one or more methods are not limited theretoand may include any methods that allow the UE to obtain the SSB of the SCell when the SCell is not transmitting the SSB.

[0099] According to example embodiments, the separate cell SSB transmission method may include determining a cell different from the SCell to transmit the SSB to the UE when the SCell is not transmitting the SSB to the UE, and transmitting the SSB from the cell different from the SCell to the UE. According to example embodiments, the cell different from the SCell may be determined based on the at least one policy.

[0100] According to example embodiments, the simplified SSB transmission method may include configuring a simplified SSB, and transmitting the simplified SSB from the SCell to the UE. The simplified SSB may include the SSB that is transmitted with simplified signal transmission. The simplified signal transmission may include any form of modification to the signal transmission, such that the transmission incur less energy.

[0101] According to example embodiments, the prediction method may include transmitting an instruction from the PCell to the UE to predict information included in the SSB based on the PCell.

[0102] According to example embodiments, the at least one policy may further specify one or more selection conditions associated with the one or more methods, where the system may be configured to select one of the one or more methods based on the one or more selection conditions.

[0103] For example, the prediction method may be applicable only for co-located PCell and SCell and inter-band CA for FR1 frequency range, where it is possible for the UE to predict / assume that the SCell may have similar Signal to Noise Ratio (SNR), Reference Signal Received Power (RSRP), and the like. Accordingly, the prediction method may be associated withthe above conditions, where the system may select the prediction method only if the above conditions are met.

[0104] Accordingly, the UE may obtain time / frequency synchronization information as well as other information included in the SSB when the SCell is not transmitting the SSB to the UE.

[0105] In view of the above, according to example embodiments, the SCell may not be shut down when the SCell is not transmitting the SSB to the UE, where the SSB may still be obtained for the SCell. Accordingly, the above allows fast activation (and deactivation) of the SCell when sudden and large amount of traffic occurs in the network, while also ensuring that information included in the SSB (e.g., Automatic Gain Control (AGC), etc.) are received by the UE and requirements, such as the requirements for measurements reported via Layer 1 (LI) and Layer 3 (L3), are satisfied. The method then proceeds to operation S440.

[0106] At operation S440, the system may be configured to perform the determined method. It may be understood that the at least one policy may include any additional information and data necessary to perform the determined method.

[0107] According to example embodiments, one or more of operations S310 to S320 (i.e., SSB-Less SCell operations), including operations S410 to S440, may be performed once the UE is synchronized with a PCell, where the SSB may only be transmitted from the PCell when the SSB is not transmitted from the SCell to the UE.

[0108] According to example embodiments, the system may include any additional mechanism for the UE and / or a gNB to trigger normal SSB transmission (and / or reference signal) on the SCell for fast access, where an on-demand uplink triggering signal can be received eitherat the SCell or a cell different from the SCell. According to example embodiments, the system may additionally transmit Random Access Channel (RACH) from the SCell to the UE.

[0109] According to example embodiments, the system may be configured to also determine which UEs from among a plurality of UEs connected to the network should connect to a network cell that implements S SB-less SCell operations.

[0110] In particular, in the relate art, all UEs are typically connected to the cell according to the signal parameters (e.g., signal quality, signal strength, etc.). However, not all UEs are capable of benefiting from the SSB-less SCell operations which involves temporarily suspending transmission of the SSB from a SCell to a UE. In this regard, if said UEs are connected to the cells that are configured with SSB-less SCell operations, said UEs may simply experience higher latency and lower throughput.

[0111] As such, according to example embodiments, the system may be configured to determine which UEs should connect to a network cell that implements SSB-less SCell operations, and may then perform operations S310 to S320 for such UEs.

[0112] FIG. 5A illustrates a flow sequence of an example use case for controlling the transmission of the SSB, according to one or more embodiments. As shown in FIG. 5A, the flow sequence may involve an rApp 521, an xApp 531, and a DU 550. The rApp 521, the xApp 531, and the DU 550 may be similar to the rApp 221, the xApp 231, and the DU 250 described above in relation to FIG. 2. Further, one or more operations in FIG. 5A may involve or may be part of one or more operations described above with reference to FIG. 3 and FIG. 4. For instance, step 1 in FIG. 5 A may be similar to operations S310 in FIG. 3, while steps 2 to 5 in FIG. 5 A may be part of operation S320 in FIG. 3 and one or more operations S410 to S440 in FIG. 4.

[0113] At step 1, the rApp 521 may configure a policy, in the similar manner as described above in relation to operation S310 in method 300.

[0114] At step 2, the rApp 521 may provide the policy to the xApp 531. According to example embodiments, the rApp 521 may provide the policy to the xApp 531 via the Al interface.

[0115] At step 3, the xApp 531 may determine SSB transmission control. In particular, the xApp 531 may determine how to control the transmission of the SSB from the SCell to the UE based on the policy. For example, the xApp 531 may detect one or more trigger conditions and determine that the transmission of the SSB from the SCell to the UE should be stopped.

[0116] At step 4, the xApp 531 may generate control commands. The control commands may include commands to be transmitted to the DU 550 in order to carry out the determined SSB transmission control. For example, the xApp 531 may generate command for the DU 550 to stop transmission of the SSB from the SCell to the UE.

[0117] At step 5, the xApp 531 may provide the generated control command to the DU 550. Accordingly, the DU 550 may be controlled based on the generated control command. For example, in response to receiving the generated command for the DU 550 to stop transmission of the SSB from the SCell to the UE, the DU 550 may stop transmission of the SSB from the SCell to the UE. According to example embodiments, the xApp 531 may provide the generated control command to the DU 550 via the E2 interface.

[0118] FIG. 5B illustrates a flow sequence of an example use case for controlling the transmission of the SSB, according to one or more embodiments. The flow sequence in FIG. 5B may be similar to the flow sequence in FIG. 5A, but without involvement of the xApp 531. In particular, the rApp 521 may configure the policy at step 1, as well as determine the SSBtransmission control at step 2, generate control command at step 3, and transmit the generated control command to the DU 550 at step 4. The rApp 521 may provide the generated control command to the DU 550 via the R1 and 01 interfaces.

[0119] According to example embodiments, as explained above, the transmission of the SSB may be controlled via a control unit (CU), the DU, the E2 interface, and an Fl interface.

[0120] FIG. 6A illustrates a flow sequence of an example use case for controlling the transmission of the SSB, according to one or more embodiments. As shown in FIG. 6A, the flow sequence may involve an rApp 621, an xApp 631, a CU 640, and a DU 650. The rApp 621, the xApp 631, the CU 640, and the DU 650 may be similar to the rApp 221, the xApp 231, the CU 240, and the DU 250 described above in relation to FIG. 2. Further, one or more operations in FIG. 6A may involve or may be part of one or more operations described above with reference to FIG. 3 and FIG. 4. For instance, step 1 in FIG. 6A may be similar to operations S310 in FIG. 3, while steps 2 to 6 in FIG. 6A may be part of operation S320 in FIG. 3 and one or more operations S410 to S440 in FIG. 4.

[0121] At step 1, the rApp 621 may configure a policy, in the similar manner as described above in relation to operation S310 in method 300.

[0122] At step 2, the rApp 621 may provide the policy to the xApp 631. According to example embodiments, the rApp 621 may provide the policy to the xApp 631 via the Al interface.

[0123] At step 3, the xApp 631 may determine SSB transmission control. In particular, the xApp 631 may determine how to control the transmission of the SSB from the SCell to the UE based on the at least one policy. For example, the xApp 631 may detect one or more triggerconditions and determine that the transmission of the SSB from the SCell to the UE should be stopped.

[0124] At step 4, the xApp 631 may provide the determined SSB transmission control to the CU 640. According to example embodiments, the xApp 631 may provide the generated control command to the CU 640 via the E2 interface.

[0125] At step 5, the CU 640 may generate control commands. The control commands may include commands to be transmitted to the DU 650 in order to carry out the determined SSB transmission control. For example, the CU 640 may generate command for the DU 650 to stop transmission of the SSB from the SCell to the UE.

[0126] At step 6, the CU 640 may provide the generated control command to the DU 650. Accordingly, the DU 650 may be controlled based on the generated control command. For example, in response to receiving the generated command for the DU 650 to stop transmission of the SSB from the SCell to the UE, the DU 650 may stop transmission of the SSB from the SCell to the UE. According to example embodiments, the CU 640 may provide the generated control command to the DU 550 via the Fl interface.

[0127] FIG. 6B illustrates a flow sequence of an example use case for controlling the transmission of the SSB, according to one or more embodiments. The flow sequence in FIG. 6B may be similar to the flow sequence in FIG. 6A, but without involvement of the xApp 631. In particular, the rApp 621 may configure the policy at step 1, as well as determine the SSB transmission control at step 2, and provide the determined SSB transmission control to the CU 640 at step 3. The rApp 621 may provide the determined SSB transmission control to the CU 640 via the R1 and 01 interfaces.Various Aspects of Embodiments

[0128] According to example embodiments, transmission of the SSB by the SCell to the UE may be automatically controlled, which prevents unnecessary waste of energy and resources and improves energy saving.

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

[0130] Some embodiments may relate to a system, a method, and / or a computer readable medium 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.

[0131] 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 erasableprogrammable 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.

[0132] Computer readable program instructions described herein can be downloaded to respective 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.

[0133] 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 programminglanguage 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), or programmable 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.

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

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

[0136] 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 or block 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.

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

[0138] FIG. 7 illustrates an example embodiment of a system 700 for implementing one or more example embodiments. As shown in FIG. 7, the system 700 may include a processor 710, a memory 720, a storage component 730, an input component 740, an output component 750, a communication interface 760, and a bus 770.

[0139] The processor 710, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 710 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 710 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.

[0140] Memory 720 includes a non-transitory computer readable medium. Memory 720 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 710. The memory 720comprises machine-readable instructions which are executable by the processor 710. These machine-readable instructions when executed by the processor 710 causes the processor 710 to perform one or more method steps of an embodiment described herein.

[0141] Storage component 730 stores information and / or software related to the operation and use of the system 700. For example, storage component 730 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.

[0142] Input component 740 is configured to receive information, such as user input. For example, the input component 740 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 740 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

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

[0144] Communication interface 760 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 760 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 700 and other devices. In other words, the standard of the communication interface 760 is not limited.

[0145] The bus 770 acts as an interconnect between the processor 710, the memory 720, the storage component 730, the input component 740, the output component 750, and the communication interface 760 of the system 700. The bus 770 may include a wired interconnection or a wireless interconnection.

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

[0147] Further, according to example embodiments, the system 700 may include one or more elements from the system architecture described above in relation to FIG. 2. For example, the system 700 may include at least the Non-RT RIC configured to implement at least one Non- RT RIC Application (rApp), and a near-real-time (Near-RT) RIC configured to implement at least one Near-RT RIC Application (xApp).

[0148] 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 non-RT RIC configured to implement at least one rApp; where the rApp may be configured to: configure, based on one or more network conditions, at least one policy, wherein the at least one policy may define one or more trigger conditions for a secondary cell (SCell) to stop transmitting a synchronization signalblock (SSB) to a user equipment (UE); and control, via at least a distributed unit (DU), transmission of the SSB from the SCell to the UE based on the at least one policy.Item [2]: The system according to item [1], wherein the rApp may be communicatively coupled to the DU via an R1 interface and an 01 interface, and wherein the rApp may be configured to control the transmission of the SSB via the DU, the R1 interface, and the 01 interface.Item [3]: The system according to one of items

[0001] -[2], wherein the rApp may be communicatively coupled to a control unit (CU) via an R1 interface and an 01 interface, wherein the CU may be communicatively coupled to the DU via an Fl interface, and wherein the rApp may be configured to control the transmission of the SSB via at least the CU, the DU, the R1 interface, the 01 interface, and the Fl interface.Item [4]: The system according to one of items [l]-[3], wherein the at least one policy may further defines one or more trigger conditions for the SCell to stop transmitting a system information block 1 (SIB 1) to the UE, and wherein the rApp may be further configured to control, via at least the DU, transmission of the SIB 1 from the SCell to the UE based on the at least one policy.Item [5]: The system according to one of items [l]-[4], wherein the rApp may be configured to configure the at least one policy using an Artificial Intelligence (Al) / Machine Learning (ML) model based on at least one of: user mobility patterns, service type requirements, and interference levels to improve overall network performance.Item [6]: The system according to item [5], wherein the AI / ML models may be trained to optimize SSB transmission for energy savings, and may be capable of predictinglow-traffic periods, adjusting transmission power, and shutting down unnecessary SSB transmissions to conserve energy.Item [7]: The system according to one of items [l]-[6], wherein the non-RT RIC may be communicatively coupled to a near-real-time (near-RT) RIC that may be configured to implement at least one near-RT RIC Application (xApp) via an Al interface, wherein the near-RT RIC may be communicatively coupled to at least the DU via an E2 interface, wherein the rApp may be configured to control the transmission of the SSB by providing the at least one policy to the xApp via the Al interface, and wherein the xApp may be configured to: receive the at least one policy from the rApp via the Al interface; and control, via at least the DU and the E2 interface, the transmission of the SSB from the SCell to the UE based on the at least one policy.Item [8]: The system according to item [7], wherein the xApp may be configured to dynamically adjust SSB transmission in response to real-time Al / ML model predictions, utilizing continuous learning from network data to enhance decision-making accuracy and efficiency.Item [9]: The system according to one of items [7]-[8], wherein the non-RT RIC or the near-RT RIC may be configured to select appropriate cells for SSB-less operation based on a number of UE supporting Release 18 SSB-less operation by: identifying cells with high density of UE supporting Release 18 SSB-less operation; and evaluating performance metrics of cells including signal strength, traffic load, and Quality of Service (QoS) requirements.Item

[0010] : The system according to one of items [7]-[9], wherein the near-RT RIC may be configured dynamically adjust a cell selection for SSB-less operation in real-time based on fluctuating network conditions and UE mobility patterns, and the non-RT RIC may be configured to periodically update policies for the cell selection based on network performance feedback.Item

[0011] : The system according to one of items

[0001] -

[0010] , wherein the rApp may be configured to control the transmission of the SSB from the SCell to the UE by: detecting the one or more trigger conditions; and stopping transmission of SSB from the SCell to the UE in response to detecting the one or more trigger conditions.Item

[0012] : The system according to one of items [1]-

[0011] , wherein the rApp may be configured to control the transmission of the SSB from the SCell to the UE by determining a cell different from the SCell to transmit the SSB to the UE when the SCell is not transmitting the SSB to the UE.Item

[0013] : The system according to one of items [1]-

[0012] , wherein the rApp may be configured to control the transmission of the SSB from the SCell to the UE by controlling the SCell to transmit a simplified SSB to the UE when the SCell is not transmitting the SSB to the UE.Item

[0014] : The system according to one of items [1]-

[0013] , wherein the one or more trigger conditions may include one or more of a time of a day, performance of a cell, and traffic volume of a cell.Item

[0015] : The system according to one of items [1]-

[0014] , wherein the at least one policy may be configured based on one or more of Quality of Service (QoS) requirements and Energy Saving (ES) requirements.Item

[0016] : A method that may include: configuring, by an rApp based on one or more network conditions, at least one policy, wherein the at least one policy may define one or more trigger conditions for a secondary cell (SCell) to stop transmitting a synchronization signal block (SSB) to a user equipment (UE); and controlling, by the rApp via at least a distributed unit (DU), transmission of the SSB from the SCell to the UE based on the at least one policy.Item

[0017] : The method according to item

[0016] , wherein the controlling the transmission of the SSB from the SCell to the UE may include: detecting the one or more trigger conditions; and stopping transmission of SSB from the SCell to the UE in response to detecting the one or more trigger conditions.Item

[0018] : The method according to one of items

[0016] -

[0017] , wherein the controlling the transmission of the SSB from the SCell to the UE may include determining a cell different from the SCell to transmit the SSB to the UE when the SCell is not transmitting the SSB to the UE.Item

[0019] : The method according to one of items

[0016] -

[0018] , wherein the controlling the transmission of the SSB from the SCell to the UE may include controlling the SCell to transmit a simplified SSB to the UE when the SCell is not transmitting the SSB to the UE.Item

[0020] : The method according to one of items

[0016] -

[0019] , wherein the one or more trigger conditions may include one or more of a time of a day, performance of a cell, and traffic volume of a cell.Item

[0021] : The method according to one of items

[0016] -

[0020] , wherein the at least one policy may be configured based on one or more of Quality of Service (QoS) requirements and Energy Saving (ES) requirements.Item

[0022] : 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: configuring, by an rApp based on one or more network conditions, at least one policy, wherein the at least one policy may define one or more trigger conditions for a secondary cell (SCell) to stop transmitting a synchronization signal block (SSB) to a user equipment (UE); and controlling, by the rApp via at least a distributed unit (DU), transmission of the SSB from the SCell to the UE based on the at least one policy.Item

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

[0022] , wherein the controlling the transmission of the SSB from the SCell to the UE may include: detecting the one or more trigger conditions; and stopping transmission of SSB from the SCell to the UE in response to detecting the one or more trigger conditions.Item

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

[0022] -

[0023] , wherein the controlling the transmission of the SSB from the SCell to the UE may include determining a cell different from the SCell to transmit the SSB to the UE when the SCell is not transmitting the SSB to the UE.Item

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

[0022] -

[0024] , wherein the controlling the transmission of the SSB from the SCell to the UE may include controlling the SCell to transmit a simplified SSB to the UE when the SCell is not transmitting the SSB to the UE.Item

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

[0022] -

[0025] , wherein the one or more trigger conditions may include one or more of a time of a day, performance of a cell, and traffic volume of a cell.

[0149] It can be 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.

Claims

What is claimed is:

1. A system comprising: a non-real-time (non-RT) Radio Access Network Intelligent Controller (RIC) configured to implement at least one non-RT RIC Application (rApp), wherein the rApp is configured to: configure, based on one or more network conditions, at least one policy, wherein the at least one policy defines one or more trigger conditions for a secondary cell (SCell) to stop transmitting a synchronization signal block (SSB) to a user equipment (UE); and control, via at least a distributed unit (DU), transmission of the SSB from the SCell to the UE based on the at least one policy.

2. The system according to claim 1, wherein the rApp is communicatively coupled to the DU via an R1 interface and an 01 interface, and wherein the rApp is configured to control the transmission of the SSB via the DU, the R1 interface, and the 01 interface.

3. The system according to claim 1 , wherein the rApp is communicatively coupled to a control unit (CU) via an R1 interface and an 01 interface, wherein the CU is communicatively coupled to the DU via an Fl interface, and wherein the rApp is configured to control the transmission of the SSB via at least the CU, the DU, the R1 interface, the 01 interface, and the Fl interface.

4. The system according to claim 1, wherein the at least one policy further defines one or more trigger conditions for the SCell to stop transmitting a system information block 1 (SIB 1) to the UE, and wherein the rApp is further configured to control, via at least the DU, transmission of the SIB 1 from the SCell to the UE based on the at least one policy.

5. The system according to claim 1, wherein the rApp is configured to configure the at least one policy using an Artificial Intelligence (Al) / Machine Learning (ML) model based on at least one of: user mobility patterns, service type requirements, and interference levels to improve overall network performance.

6. The system according to claim 5, wherein the AI / ML models are trained to optimize SSB transmission for energy savings, and are capable of predicting low-traffic periods, adjusting transmission power, and shutting down unnecessary SSB transmissions to conserve energy.

7. The system according to claim 1, wherein the non-RT RIC is communicatively coupled to a near-real-time (near-RT) RIC that is configured to implement at least one near-RT RIC Application (xApp) via an Al interface, wherein the near-RT RIC is communicatively coupled to at least the DU via an E2 interface, wherein the rApp is configured to control the transmission of the SSB by providing the at least one policy to the xApp via the Al interface, and wherein the xApp is configured to: receive the at least one policy from the rApp via the Al interface; andcontrol, via at least the DU and the E2 interface, the transmission of the SSB from the SCell to the UE based on the at least one policy.

8. The system according to claim 7, wherein the xApp is configured to dynamically adjust SSB transmission in response to real-time AI / ML model predictions, utilizing continuous learning from network data to enhance decision-making accuracy and efficiency.

9. The system according to claim 7, wherein the non-RT RIC or the near-RT RIC is configured to select appropriate cells for SSB-less operation based on a number of UE supporting Release 18 SSB-less operation by: identifying cells with high density of UE supporting Release 18 SSB-less operation; and evaluating performance metrics of cells including signal strength, traffic load, and Quality of Service (QoS) requirements.

10. The system according to claim 7, wherein the near-RT RIC is configured dynamically adjust a cell selection for SSB-less operation in real-time based on fluctuating network conditions and UE mobility patterns, and the non-RT RIC is configured to periodically update policies for the cell selection based on network performance feedback.

11. The system according to claim 1, wherein the rApp is configured to control the transmission of the SSB from the SCell to the UE by:detecting the one or more trigger conditions; and stopping transmission of SSB from the SCell to the UE in response to detecting the one or more trigger conditions.

12. The system according to claim 1, wherein the rApp is configured to control the transmission of the SSB from the SCell to the UE by determining a cell different from the SCell to transmit the SSB to the UE when the SCell is not transmitting the SSB to the UE.

13. The system according to claim 1, wherein the rApp is configured to control the transmission of the SSB from the SCell to the UE by controlling the SCell to transmit a simplified SSB to the UE when the SCell is not transmitting the SSB to the UE.

14. The system according to claim 1, wherein the one or more conditions include one or more of a time of a day, performance of a cell, and traffic volume of a cell.

15. The system according to claim 1, wherein the at least one policy is configured based on one or more of Quality of Service (QoS) requirements and Energy Saving (ES) requirements.

16. A method comprising: configuring, by an rApp based on one or more network conditions, at least one policy, wherein the at least one policy defines one or more trigger conditions for a secondary cell(SCell) to stop transmitting a synchronization signal block (SSB) to a user equipment (UE); and controlling, by the rApp via at least a distributed unit (DU), transmission of the SSB from the SCell to the UE based on the at least one policy.

17. The method according to claim 16, wherein the controlling the transmission of the SSB from the SCell to the UE comprises: detecting the one or more trigger conditions; and stopping transmission of SSB from the SCell to the UE in response to detecting the one or more trigger conditions.

18. The method according to claim 16, wherein the controlling the transmission of the SSB from the SCell to the UE comprises determining a cell different from the SCell to transmit the SSB to the UE when the SCell is not transmitting the SSB to the UE.

19. The method according to claim 16, wherein the controlling the transmission of the SSB from the SCell to the UE comprises controlling the SCell to transmit a simplified SSB to the UE when the SCell is not transmitting the SSB to the UE.

20. The method according to claim 16, wherein the one or more trigger conditions include one or more of a time of a day, performance of a cell, and traffic volume of a cell.

21. The method according to claim 16, wherein the at least one policy is configured based on one or more of Quality of Service (QoS) requirements and Energy Saving (ES) requirements.

22. A non-transitory computer-readable recording medium having recorded thereon instructions executable by a system to cause the system to perform a method comprising: configuring, by an rApp based on one or more network conditions, at least one policy, wherein the at least one policy defines one or more trigger conditions for a secondary cell (SCell) to stop transmitting a synchronization signal block (SSB) to a user equipment (UE); and controlling, by the rApp via at least a distributed unit (DU), transmission of the SSB from the SCell to the UE based on the at least one policy.

23. The non-transitory computer-readable recording medium according to claim 22, wherein the controlling the transmission of the SSB from the SCell to the UE comprises: detecting the one or more trigger conditions; and stopping transmission of SSB from the SCell to the UE in response to detecting the one or more trigger conditions.

24. The non-transitory computer-readable recording medium according to claim 22, wherein the controlling the transmission of the SSB from the SCell to the UE comprises determininga cell different from the SCell to transmit the SSB to the UE when the SCell is not transmitting the SSB to the UE.

25. The non-transitory computer-readable recording medium according to claim 22, wherein the controlling the transmission of the SSB from the SCell to the UE comprises controlling the SCell to transmit a simplified SSB to the UE when the SCell is not transmitting the SSB to the UE.

26. The non-transitory computer-readable recording medium according to claim 22, wherein the one or more trigger conditions include one or more of a time of a day, performance of a cell, and traffic volume of a cell.

Images