Enhancement on cell DTX / DRX mechanisms

Abstract

Example embodiments of the present disclosure relate to the enhancement on cell Discontinuous Transmission (DTX) / Discontinuous Reception (DRX) mechanisms. According to example embodiments, a system may include a non-real-time (Non-RT) radio access network intelligent controller (RIC). The Non-RT RIC may be configured to: configure at least one policy that defines a configuration of a cell DTX / DRX and provide the configured policy to at least one of: a near-real-time (Near-RT) RIC, an open radio access network (O-RAN) central unit (O-CU), and an O-RAN distributed unit (O-DU).. The policy may be executable by at least one of: the Near-RT RIC, the O-CU, and the O-DU, to thereby implement the cell DTX / DRX.

Description

ENHANCEMENT ON CELL DTX / DRX MECHANISMSCROSS 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 and Trademark Office on February 16, 2024, the entire contents of which are incorporated herein by reference.TECHNICAL FIELD

[0002] The present disclosure relates to the enhancement on cell Discontinuous Transmission (DTX) / Discontinuous Reception (DRX) mechanisms.BACKGROUND

[0003] The information disclosed in this background section is only for the 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 of Discontinuous Transmission (DTX) and Discontinuous Reception (DRX) for network energy saving. A network cell that is connected to a user equipment (UE) may be configured with DTX and / or DRX (may be collectively referred toas “cell DTX / DRX” herein) for energy-saving purposes. Similarly, the UE may also be configured with UE DRX for energy-saving purposes.SUMMARY

[0005] Example embodiments of the present disclosure provide systems, apparatuses, methods, and the like, that enhance cell DTX / DRX mechanisms.

[0006] According to example embodiments, a system may include a non-real-time (Non- RT) radio access network intelligent controller (RIC). The Non-RT RIC may be configured to: configure at least one policy that defines a configuration of a cell Discontinuous Transmission (DTX) / Discontinuous Reception (DRX) and provide the configured policy to at least one of: a near-real-time (Near-RT) RIC, an open radio access network (O-RAN) central unit (O-CU), and an O-RAN distributed unit (O-DU). The policy may be executable by at least one of the Near-RT RIC, the O-CU, and the O-DU, to thereby implement the cell DTX / DRX.

[0007] According to example embodiments, a method may include: configuring at least one policy that defines a configuration of a cell DTX / DRX and providing the configured policy to at least one of: a Near-RT RIC, an O-CU, and an O-DU. The policy may be executable by at least one of the Near-RT RIC, the O-CU, and the O-DU, to thereby implement the cell DTX / DRX.

[0008] According to example embodiments, a non-transitory computer-readable recording medium may have recorded thereon instructions executable by a system to cause the system to perform a method. The method may include: configuring at least one policy that defines a configuration of a cell DTX / DRX and providing the configured policy to at least one of: a Near- RT RIC, an O-CU, and an O-DU. The policy may be executable by at least one of the Near-RT RIC, the O-CU, and the O-DU, to thereby implement the cell DTX / DRX.

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

[0010] 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:

[0011] FIG. 1 illustrates a diagram of example cell DTX / DRX cycles;

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

[0013] FIG. 3 illustrates a flow diagram of an example method for enhancing cell DTX / DRX mechanisms, according to one or more example embodiments;

[0014] FIG. 4 illustrates a flow diagram of an example method for configuring at least one policy, according to one or more example embodiments;

[0015] FIG. 5 illustrates a flow diagram of an example method for configuring at least one cell DTX / DRX parameter, according to one or more example embodiments;

[0016] FIG. 6 illustrates a flow sequence of an example use case for implementing the cell DTX / DRX via an O-CU, according to one or more example embodiments;

[0017] FIG. 7 illustrates a flow sequence of an example use case for implementing the cell DTX / DRX via an O-DU, according to one or more example embodiments; and

[0018] FIG. 8 illustrates an embodiment of a device which may implement one or more example embodiments of the present disclosure.DETAILED DESCRIPTION

[0019] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above 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 one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part).

[0020] 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 limited to the described implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0021] Even though particular combinations of features are disclosed in the claims and / or in the specification, these 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. Although each dependent claim listed below may directlydepend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

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

[0023] 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 “DTX”, “DRX”, “rApp”, “xApp”, “Al interface”, “E2 interface”, “01 interface”, “02 interface”, “Fl interface”, “MOI”, “E2SM-CCC”, “MAC CE”, “PDCCH”, “Al policy”, and the like, as well as the associated features and operations, may be interpreted as consistent with those specified in one or more technical specifications

[0024] Furthermore, it is contemplated that the terms “cell DTX / DRX” described herein are intended to specify that the “DTX / DRX” is associated with a network cell. In this regard, it can be understood that although some example embodiments may be described herein with reference to “cell DTX / DRX”, said example embodiments may be similarly applied to “cell DTXand cell DRX”, only “cell DTX”, or only “cell DRX”, without departing from the scope of the present disclosure.

[0025] 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. Specifically, the RAN includes a combination of various network elements (NEs) that connect end-users to a core network. Traditionally, the hardware and / or software of a particular RAN is vendor-specific.

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

[0027] On the other hand, the mechanisms and procedures for Discontinuous Transmission(DTX) and Discontinuous Reception (DRX) have also been described in one or more technical specifications (e g., 3GPP Release-18, etc.) Generally, DTX and DRX are designed to optimizethe power consumption of a network node (e g., a network cell, a user equipment (UE), etc.) by allowing the network node to periodically enter sleep mode and wake-up mode according to predefined cycles.

[0028] For instance, by configuring a cell with DTX / DRX, the cell can enter into sleep mode for a period of time, and then wake up to transmit and / or receive data thereafter. Specifically, when the cell is configured with cell DTX / DRX, the cell can get into sleep mode for a period of time and then wake up again to transmit / receive data (if any), which in turn effectively reduces the power consumption of the cell. The cell configured with cell DTX / DRX may periodically repeat the entering of sleep mode and wake-up mode, and a cycle of such phenomena may be referred to as a “cell DTX / DRX cycle”.

[0029] FIG. 1 illustrates a diagram of examples of the cell DTX / DRX cycle. As illustrated in FIG. 1, a DTX / DRX cycle may define the periodic repetition of an “active duration” followed by a “non-active duration”. The x-axis of the diagram may define the length of the cell DTX / DRX cycles (e.g., in ms, etc.), while the y-axis of the diagram may define the level of energy or power consumption when the cell turns on during the active duration. During the “active duration”, a cell configured with the cell DTX / DRX can be turned on and then enter the wake-up mode, thereby transmitting / receiving data or information (if any). Conversely, during the “non-active duration”, the cell can be turned off and enter the sleep mode.

[0030] In some implementations, a user equipment (UE) may be provided or configured with the cell DTX / DRX pattern. Further, the cell DTX pattern and the cell DRX pattern can be configured and activated / deactivated separately. For instance, the cell DTX / DRX can be activated / deactivated by radio resource control (RRC) signaling (e.g., RRC Reconfiguration Message, etc.) and / or layer 1 (LI) signaling (e.g., LI group common signaling via Media AccessControl (MAC) Control Element (CE), etc.) The configuration (e g., active duration, non-active duration, cycle parameters, etc.) may be common between cell DTX and cell DRX, when both the cell DTX and cell DRX are configured or activated.

[0031] When cell DTX is configured and activated, the UE does not monitor the physical downlink control channel (PDCCH) and / or the Semi-Persistent Scheduling (SPS) occasions during the cell DTX non-active duration. On the other hand, when cell DRX is configured and activated, the UE does not transmit on configured grant (CG) resources or transmit a scheduling request (SR) during the cell DRX non-active duration. In this regard, the “active duration” of the cell DTX / DRX cycle may define the duration that the UE waits to receive PDCCH(s) or SPS occasion(s) and to transmit SR or CG.

[0032] During the “active duration”, the transmission / reception of PDCCH, SPS, CG, Scheduling Request (SR), periodic and semi-persistent CSI report, and the like, are not impacted for the purpose of network energy saving. During the “non-active duration”, the cell configured with cell DTX / DRX can enter into the wake-up mode (with the radio frequency (RF) module, such as the amplifiers, turned on, etc.) and can determine whether or not there is any data for transmission and / or reception. If the cell detects data for transmission and / or reception, the cell may stay awake and start the data transmission and / or reception. On the other hand, if the cell does not detect any data for transmission and / or reception within the active duration, the cell may enter into sleep mode during the non-active duration. In some implementations, during the non-active duration, instead of disabling all transmission / reception, the cell may disable particular transmission / reception, thereby providing limited transmission / reception. For example, the cell may be configured such that no transmission and / or reception of particular periodic signals and / orchannels (e.g., common channel s / signals, UE-specific signal s / channels, etc.) is enabled during the non-active duration.

[0033] According to example embodiments, the UE may be configured with DRX and be provided the cell DTX / DRX configuration (or information associated therewith). Accordingly, the UE may adjust or align the UE DRX configuration based on the cell DTX / DRX configuration. Further, the aforesaid cell DTX / DRX features (e.g., not monitoring PDCCH during non-active durations, not transmitting SR during non-active durations, etc.) may only be applicable to the UE when the UE is in RRC CONNECTED state, which may not impact Random Access procedure, synchronization signal block (SSB) transmission, paging, and system information broadcasting. For instance, once the base station (e.g., gNB) recognizes that there is a specific event (e g., an emergency call, a public safety-related service, Multimedia Priority Service (MPS), Mission Critical Service (MCS), etc.), the base station may release, deactivate, or disable the cell DTX / DRX at the configured cell, ensure that there is no impact on the associated service and that there is at least partial overlapping between UE’s connected mode DRX on-duration and cell DTX / DRX active duration, thereby ensuring that the UE and the network have the ability for emergency wake up to accommodate emergency call scenarios.

[0034] In view of the above, cell DTX / DRX enables the network to conserve energy consumption by enabling the cell to periodically enter sleep mode while allowing the UE(s) to transmit data and / or monitor the PDCCH / SPS occasions on a periodic basis. Nevertheless, in the related art, the cell DTX / DRX patterns or configurations (e.g., length of the cell DTX / DRX cycle, length of the active duration, etc.) are configured by the operator of the network and are static, thus the cell DTX / DRX patterns or configurations may not be optimal. For instance, the cell configured with a long non-active duration of cell DTX / DRX may experience high network traffic, whichmay in turn affect the network performance of the cell. On the other hand, the cell may be configured with a non-active duration that is shorter than it can be, which may in turn waste the opportunity to converse energy during low network traffic.

[0035] Further, in the related art, all UEs are typically connected to the cell according to the signal parameters (e.g., signal quality, signal strength, etc.), without taking into consideration whether or not the cell is configured with cell DTX / DRX. In this regard, since the cell DTX / DRX involves temporarily suspending transmission and receiving of data or information, the cell DTX / DRX may conserve energy with a tradeoff of latency and throughput. While the cell DTX and the cell DRX are designed to balance power saving with maintaining reasonable latency and throughput, not all UEs are capable of benefiting from the cell DTX / DRX. For instance, since cell DTX / DRX are introduced in one or more specific technical specifications (e.g., Release-18), if the UEs manufactured before the one or more specific technical specifications (e.g., non-Release-18 UEs) are connected to the cells that are configured with DTX / DRX, said UEs may simply experience higher latency and lower throughput without being able to leverage the advantages of the cell DTX / DRX.

[0036] Furthermore, in the related art, the type of cell is not taken into consideration during the configuration of the cell DTX / DRX. Accordingly, although some of the cells may be powered by renewable energy, the cell DTX / DRX configuration for said cells may not be optimal. For example, cells powered by solar or wind energy may miss opportunities to extend DTX / DRX cycles during surplus energy periods. In addition, in the related art, the configuration of the cell DTX / DRX does not take into consideration of the user mobility. For instance, a handover procedure may be required when a user may move from a cell to a target cell, but the target cell isturned off right before / during the handover procedure due to the cell DTX / DRX configuration, which in turn affects the handover procedure and may eventually result in service disruption.

[0037] In this regard, example embodiments of the present disclosure provide a system, a method, a device, and the like, for enhancing the cell DTX / DRX mechanisms. Specifically, example embodiments dynamically manage or configure the cell DTX / DRX configurations according to, for example, real-time (or near real-time) network conditions (e.g., network traffic, load, throughput, etc.) and network requirements (e.g., energy saving requirements, quality of service (QoS) requirements, type of energy source associated with the cell, handover requirement, etc.) Further, example embodiments monitor the capability of the UEs and automatically steer the UEs to and from a network cell according to the capability of the UEs. Furthermore, example embodiments provide several approaches for implementing the cell DTX / DRX according to the dynamically configured cell DTX / DRX configurations.

[0038] 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. Further descriptions of the features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.Example System Architecture

[0039] FIG. 2 illustrates an example system architecture, according to one or more example embodiments. As shown 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 0-RAN Centralized Unit (O-CU) 240, at least one 0-RAN Distributed Unit(O-DU) 250, a plurality of 0-RAN Radio Units (O-RUs) 260-1 to 260-3, and at least one O-RAN Cloud (O-Cloud) 270. These components may be communicatively coupled to one another within the system architecture via a respective interface(s).

[0040] 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 O-CU control plane (O-CU-CP) and O-CU user plane (O-CU-UP), and the like.

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

[0042] 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 and monitor the status of one or more policies.

[0043] 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 (AI / ML) 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 the Al interface, 01 interface, 02 interface, and one or more interfaces associated with one or more open fronthaul planes.

[0044] 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, such as policy management, radio resource management, data analytics, and providing enrichment information. In some implementations, the Non-RT RIC 220 may implement a plurality of rApps 221. In this regard, it is contemplated that the Non-RT RIC may implement one or more rApps to perform one or more operations described herein.

[0045] 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 an 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 service, 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 interconnection between rApps and Non-RT RIC framework supplied by different vendors.

[0046] According to example embodiments, the Non-RT RIC 220 (or the rApp 221 implemented therein) may be configured to manage one or more policies that are provided (or to be provided) to the Near-RT RIC 230 over the Al interface, and / or may be configured to manage one or more policies that are provided (or to be provided) to the O-CU 240 and / or the O-DU 250 via the 01 interface. Said policies are declarative policies that contain statements on policy objectives and policy resources applicable to one or more network nodes (e.g., one or more RAN nodes, one or more UEs, one or more network cells, etc.) Specifically, the one or more 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 policy objectives and policy resources. According to example embodiments, one or more policies described herein may be similar to the “Al policy” defined in one or more technical specifications.

[0047] In some example implementations, one or more of the policies may include one or more quality of service (QoS) requirements (e.g., packet delay budge, throughput, etc.)one or more energy saving (ES) requirements (e.g., 20%, etc.), one or more handover requirements (e.g., handover triggers, handover execution procedure, etc.), one or more network requirements / conditions (e.g., network load condition, network traffic, etc.), and / or any othersuitable information. In some example embodiments, the policy may specify, for example, new QoS Class Identifier (QCI) parameters that the Near-RT RIC 230 (or the xApp 231 implemented therein) should follow / utilize, energy saving aggressiveness, and the like. Further, the one or more policies may also define which cell(s) should implement the cell DTX / DRX, which type of UE(s) should connect to the cell implementing the cell DTX / DRX, and how specifically the cell DTX / DRX should be implemented.

[0048] 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. The Non-RT RIC 220 (or the rApp 221 implemented therein) may provide the one or more policies to the Near-RT RIC 230, the O-CU 240, and / or the O-DU 250, thereby providing guidance to the Near-RT RIC 230 / O-CU 240 / O-DU 250 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.

[0049] According to example embodiments, the Non-RT RIC 220 (or the rApp 221 implemented therein) may be configured to perform one or more policy management operations to provide and manage one or more policies in the Near-RT RIC 230, in the O-CU 240, and / or in the O-DU 250. Specifically, the Non-RT RIC 220 (or the rApp 211 implemented therein) may be configured to create, update, and delete one or more policies in the Near-RT RIC 230 / O-CU240 / O-DU 250. According to example embodiments, the Non-RT RIC 220 (or the rApp 221 implemented therein) may manage the one or more policies to include or manage information associated with cell DTX / DRX.

[0050] For example, the Non-RT RIC 220 (or the rApp 221 implemented therein) may obtain information of one or more requirements (e.g., QoS requirement(s), energy saving requirement s), handover requirement(s), network requirement s), etc.) Said information may be pre-defined by the network operator and pre-stored in one or more storage mediums associated with or accessible by the Non-RT RIC 220 (or the rApp 221 implemented therein), may be obtained or determined by the Non-RT RIC 220 (or the rApp 221 implemented therein) during operation, and / or may be managed by other system like a business support system (BSS).

[0051] According to example embodiments, the Non-RT RIC 220 (or the rApp 221 implemented therein) may determine, based on the one or more requirements, at least one guidance for implementing the cell DTX / DRX (e.g., which cell should implement the cell DTX / DRX, which radio access technology (RAT) should be implemented, which frequency layer should be utilized, which type of UEs should be allowed to connect to the cell that implements the cell DTX / DRX, etc.) Accordingly, the Non-RT RIC 220 (or the rApp 221 implemented therein) may include the information of the implementation guidance into the one or more policies, and then provide the one or more configured policies to the Near-RT RIC 230 via the Al interface, to the O-CU 240 via the 01 interface, and / or to the 0-DU 250 via the 01 interface. According to example embodiments, the Non-RT RIC 220 (or the rApp 221 implemented therein) may update one or more of the provided policies to include the information of the implementation guidance. Additionally or alternatively, the Non-RT RIC 220 (or the rApp implemented therein) may create a new policy that includes the information of the implementation guidance.

[0052] According to example embodiments, the Non-RT RIC 220 (or the rApp 221 implemented therein) may be configured to configure or adjust at least one policy by configuring or adjusting a periodicity of a DTX / DRX cycle (or a periodicity of the cell DTX / DRX), a length of the DTX / DRX cycle (or a length of the cell DTX / DRX), and / or an activation duration of the DTX / DRX cycle (or an activation duration of the cell DTX / DRX).

[0053] In some example implementations, the Non-RT RIC 220 (or the rApp 221 implemented therein) may be configured to configure or adjust a plurality of policies. In this case, the Non-RT RIC 220 (or the rApp 221 implemented therein) may determine a priority level of each of the plurality of policies based on, for example, an energy-saving requirement (e.g., energy efficiency, type of energy source, etc.), a QoS requirement, a handover requirement, a network condition (e.g., network load condition, etc.), and the like. By way of example, the Non-RT RIC 220 (or the rApp 221 implemented therein) may evaluate which of the plurality of policies can contribute more to energy-saving, can achieve or improve QoS, can improve handover success rate, can balance the network load, and the like, and then assign the priority level to the plurality of policies based thereon. Accordingly, the Non-RT RIC 220 (or the rApp 221 implemented therein) may configure the plurality of policies based on the respective priority level (e.g., policy(s) with a higher priority level will be configured first, following by policy(s) with a lower priority level, etc.)

[0054] According to example embodiments, the Non-RT RIC 220 (or the rApp 221 implemented therein) may be configured to adjust or configure the policy(s) by implementing at least one AI / ML model, such as a regression model, a classification model, a clustering model, a time series analysis model, a deep learning model, and the like. Specifically, the Non-RT RIC 220 (or the rApp 221 implemented therein) may be configured to implement the AI / ML model (s) topredict an optimal cell DTX / DRX configuration (e.g., optimal periodicity of the DTX / DRX cycle or the cell DTX / DRX, optimal length of the DTX / DRX cycle or the cell DTX / DRX, optimal active duration of the DTX / DRX cycle or the cell DTX / DRX, etc.) based on, for example, historical network data (e.g., historical network traffic, historical network performance, etc.), trends (e.g., data usage trend, network traffic trend, service usage trend, etc.), and the like. Accordingly, the Non-RT RIC 220 (or the rApp 221 implemented therein) may then configure the policy(s) based on the predicted optimal cell DTX / DRX configuration.

[0055] According to example embodiments, the Non-RT RIC 220 (or the rApp 221 implemented therein) may be configured to adjust or configure the policy(s) based on the type of energy resource utilized in powering the associated cell(s). For instance, the Non-RT RIC 220 (or the rApp 221 implemented therein) may determine, from among a plurality of cells, a cell that is powered by a renewable energy (e.g., solar, wind, geothermal heat, etc.), and then configure the policy(s) to adjust the cell DTX / DRX configuration associated with the determined cell that is powered by the renewable energy. In this way, the Non-RT RIC 220 (or the rApp 221 implemented therein) may utilize data or information associated with the renewable energy to optimize the DTX / DRX operations in the cell(s) that is powered by the renewable energy, thereby enhancing overall energy efficiency.

[0056] According to example embodiments, in addition to configuring the policy(s), the Non-RT RIC 220 (or the rApp 221 implemented therein) may determine (e.g., monitor, calculate, etc.) an amount of energy-saving achieved through the cell DTX / DRX implemented based on the configured / adjusted policy(s), and then report the determined amount of energy-saving to a management system (e.g., a central management system, a network operating system, a network management system, etc.) for further optimization, utilization, planning, and the like.

[0057] According to example embodiments, the Non-RT RIC 220 (or the rApp 221 implemented therein) may be configured to receive, from the Near-RT RIC 230 / O-CU 240 / O-DU 250 via the respective interface, one or more feedbacks associated with one or more provided policies (“policy feedback” herein). Similarly, the Non-RT RIC 220 (or the rApp 221 implemented therein) may be configured to receive one or more observables (e.g., events, counters, etc.) from the O-CU 240, the O-DU 250, and / or one or more of the O-RUs 260 over the 01 interface (“01 observable” herein). The policy feedback(s) and the 01 observable(s) may define or associate with the impact or effectiveness of the current policy(s) in the implementation of the cell DTX / DRX.

[0058] Accordingly, the Non-RT RIC 220 (or the rApp 221 implemented therein) may be configured to continuously (or periodically) manage the one or more policies based on the policy feedback(s) and / or the 01 observables, in view of the one or more requirements (e.g., QoS requirement, energy saving requirement, handover requirements, network conditions, etc.) For instance, the Non-RT RIC 220 (or the rApp 221 implemented therein) may continuously (or periodically) evaluate the impact or effectiveness of the one or more policies towards the fulfillment of the RAN intent and then configure or update the one or more policies accordingly. In this regard, by utilizing the 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 cell DTX / DRX configuration(s) achieve one or more requirements (e.g., QoS requirements, energy saving requirements, handover requirements, etc.) and then manage the one or more policies based thereon. In this way, the Non-RT RIC 220 (or the rApp 221 implemented therein) may dynamically configure the one or more policies according to the network status / requirements and then provide the configured policy(s) to the Near-RT RIC 230 / O-CU 240 / O-DU 250, thereby enabling the Near-RT RIC 230 / O-CU 240 / O-DU 250 to dynamically configure one or more parameters associated with the cell DTX / DRX and optimize the network resources for a single UEs or group of UEs.

[0059] By way of example, based on determining that a QoS requirement in a specific area is not satisfied or has a possibility of being violated, the Non-RT RIC 220 (or the rApp 221 implemented therein) may reduce the number of cells implementing the cell DTX / DRX in said area, thereby increasing 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.

[0060] As another example, based on determining that an energy-saving requirement in a specific area is not satisfied or has a possibility of being violated, the Non-RT RIC 220 (or the rApp 221 implemented therein) may increase the number of cells implementing the cell DTX / DRX in said area, thereby increasing the energy saving opportunities in said area to meet the energy saving requirement. The Non-RT RIC 220 (or the rApp 221 implemented therein) may configure the policy(s) to include such information, so that the Near-RT RIC 230 / O-CU 240 / O-DU 250 may utilize said information to configure the associated parameter(s).

[0061] 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 RIC 220 and / or the rApp 221 implemented therein) may communicate with the Near-RT RIC 230, the O-CU 240, the 0-DU 250, and / or 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 / or 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, networkdiscovery, and the like, to theNear-RT RIC 230, the O-CU 240, the 0-DU 250, and / or the O-RU(s) 260. Additionally, the 01 interface enables the Near-RT RIC 230, the O-CU 240, the 0-DU 250, and / or the O-RU(s) 260 to provide information or observable(s) that may be utilized by the Non- RT RIT 220 (or the rApp 221) to manage the policy(s), to train one or more AI / ML models, and the like. According to 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 and the O-eNB may be communicatively coupled to the Near-RT RIC 230 via an E2 interface.

[0062] According to example embodiments, the Non-RT RIC 220 (or the rApp 221 implemented therein) may be configured to periodically (or continuously) update the policy(s) based on at least one network performance metric (e.g., network energy consumption, latency, throughput, signal quality, packet loss, etc ), and then provide the updated policy(s) to at least one of the Near-RT RIC 230 (via the Al interface), the O-CU 240 (via the 01 interface), and the O- DU 250 (via the 01 interface).

[0063] 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, 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 221implemented therein) may provide infrastructure management services (IMS) and deployment management services (DMS) for the O-Cloud 270.

[0064] Furthermore, the SMO framework 210 (as well as the Non-RT RIC 220 and / or the rApp 221 implemented therein) may also 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.

[0065] Next, the descriptions of the Near-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 near-real-time control and 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.

[0066] 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.) based on one or more policies. For example, the Near-RT RIC 230 may receive the one or more 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 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 QoS optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, and the like.

[0067] 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, 0-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 programming interfaces (APIs). Further, the Near-RT RIC platform may be configured to route policy management messages to the registered xApps based on policy type and operator policies. Furthermore, it is contemplated that the Near-RT RIC 230 may be configured to implement the xApp 231 to perform one or more operations described herein.

[0068] According to example embodiments, the Near-RT RIC 230 (or the xApp 231 implemented therein) may be configured to adjust or configure one or more parameters associated with cell DTX / DRX and then provide the one or more configured cell DTX / DRX parameters to the O-CU 240, the 0-DU 250, and / or one or more of the O-RUs 260. For instance, the Near-RT RIC 230 (or the xApp 231 implemented therein) may be configured to dynamically adjust or configure the cell DTX / DRX parameter(s) in real-time based on the policy(s) received from the Non-RT RIC 220 (or the rApp 221 implemented therein) and / or one or more real-time information, such as the real-time user mobility pattern, the real-time network traffic condition, and the like.

[0069] According to example embodiments, the Near-RT RIC 230 (or the xApp 231 implemented therein) may be configured to adjust or configure one or more of the following parameters:• A parameter associated with the configuration of the cell DRX / DTX. This parameter may define the configuration settings for DTX and DRX, and may include specific parameters like DTX / DRX cycle length, on-duration / active duration timer for DTX / DRX, and the like. This parameter may be referred to as the “DTX or DRX Config” parameter and may have a structure (“Struct”) parameter type.• A parameter associated with one or more cells to which the cell DRX / DTX is applicable or is to be implemented. Said cells may be referred to as “target cells”, and this parameter may include a list of cell identifiers (IDs) of the target cells. Thus, this parameter may also be referred to as the “targetCelllds” parameter.• A parameter associated with the activation of the cell DRX / DTX. This parameter may dictate whether to activate or deactivate the cell DTX / DRX configuration for one or more specified cells. This parameter may be referred to as the “activationTrigger” parameter or the “deactivationTrigger” parameter and may have an enumeration (“Enum”) parameter type (e.g., ‘Activate’, ‘Deactivate’).• A parameter associated with Downlink Control Information (DCI) format for signaling cell DTX / DRX settings or configurations to the associated RAN nodes. This parameter may be referred to as the “dciFormatForDTXDRX” parameter and may have an Enum parameter type (e.g., ‘Format2_9’).• A parameter associated with the timing of the Al policy, including start time, end time, and periodicity of the DTX / DRC configuration. For example, based on this parameter, a CU and / or a DU may determine that within a minute / ms, apolicy should be executed or provided. This parameter may be referred to as the“policyTiming” parameter and may have a Struct parameter type.• A parameter associated with one or more energy saving objectives. This parameter may define objective(s) or target(s) for energy saving, which may include metrics like reduced power consumption target(s), specific performance indicator(s), and the like. This parameter may be referred to as the “energySavingObjectives” parameter and may have a Struct parameter type.

[0070] Additionally or alternatively, the Near-RT RIC 230 (or the xApp 231 implemented therein) may be configured to adjust or configure one or more parameters defined in one or more 3 GPP technical standards or specifications, such as the following:• cellDTRX-DCI-config: This parameter may include the configuration of new DCI format 2 9 for activation and / or deactivation of cell DTX / DRX configuration of one or more multiple serving cells. In some implementations, this parameter may include parameters associated with radio network temporary identifier (RNTI), such as cellDTRX-RNTI, and parameters associated with DCI, such as sizeDCI-2-9 and positionlnDIC-cellDTRX.• dci-Format2-9: This parameter, if configured, enables the UE to monitor the DCI format 2 9 with cyclic redundancy check (CRC) scrambled by the cellDTRX- RNTI.• cellDTRX-RNTI: This parameter configures the RNTI value for scrambling CRC of DCI format 2 9 for activating and / or deactivating cell DTX / DRX and / or network energy saving (NES) mode for conditional handover (CHO) indication.• sizeDCI-2-9: This parameter configures the size of the DCI format 2 9.• positionlnDCI-cellDTRX: This parameter configures the starting bit position of an information block corresponding to cell DTX / DRX operation and / or NED mode for CHO indication for the serving cell of DCI format 2 9. This parameter may be configured or adjusted individually per cell of a subset of serving cell(s).

[0071] According to example embodiments, the Near-RT RIC 230 (or the xApp 231 implemented therein) may be configured to adjust or configure one or more of the above-described parameters based on one or more real-time (or near-real-time) information. For example, the Near- RT RIC 230 (or the xApp 231 implemented therein) may determine, based on the real-time (or near-real-time) user mobility pattern, whether or not a handover is required when a user is moving from an adjacent cell to a target cell. Accordingly, based on determining that the handover is required, the Near-RT RIC 230 (or the xApp 231 implemented therein) may configure the cell DTX / DRX parameter(s) associated with the target cell according to at least one handover requirement. In this example, the Near-RT RIC 230 (or the xApp 231 implemented therein) may coordinate with the adjacent cell(s), such as the target cell(s), to optimize the DTX / DRX settings, thereby ensuring seamless handovers and minimal service disruption.

[0072] According to example embodiments, the Near-RT RIC 230 (or the xApp 231 implemented therein) 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 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).

[0073] According to example embodiments, the Near-RT RIC 230 (or the xApp 231 implemented therein) may determine, based on the policy(s) provided by the Non-RT RIC 220, atleast one cell associated with policy(s), and then determine, from among a plurality of cell DTX / DRX parameters, the to be configured cell DTX / DRX parameter(s) that is associated with the at least one associated cell. Accordingly, the Near-RT RIC 230 (or the xApp 231 implemented therein) may adjust the associated cell DTX / DRX parameter(s) based on the policy(s).

[0074] According to example embodiments, the Near-RT RIC 230 (or the xApp 231 implemented therein) 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, and the like. By way of example, the Near-RT RIC 230 (or the xApp 231 implemented therein) 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 steer the specific type of UE (e.g., non-NES capable UE, etc.) out of a cell before configuring the cell to apply or implement the cell DTX / DRX.

[0075] According to example embodiments, the Near-RT RIC 230 (or the xApp 231 implemented therein) may be configured to perform the one or more control operations via the E2 interface. For instance, the Near-RT RIC 230 (or the xApp 231 implemented therein) may be configured to perform O-DU E2 control by handling the cell states transition and UE mobility to prepare for cell switching off / on according to the cell DTX / DRX configurations and then send one or more associated commands to the O-DU 250. Accordingly, the O-DU 250 may control the associated O-RU(s) or cell(s) to switch from and / or switch to the DTX / DRX. As another example, the Near-RT RIC 230 (or the xApp 231 implemented therein) may be configured to perform O- CU E2 control by instructing the O-CU 240 to handle the cell state transition and UE mobility to prepare for cell switching off / on according to the cell DTX / DRX configurations. Accordingly, theO-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 from and / or switch to DTX / DRX.

[0076] According to example embodiments, the Near-RT RIC 230 (or the xApp 231 implemented therein) may be configured to perform one or more operations via the E2 interface to implement the cell DTX / DRX to the associated cell(s). In some example embodiments, the Near-RT RIC 230 (or the xApp 231 implemented therein) may provide the configured cell DTX / DRX parameter(s) to the O-CU 240 via the E2 interface, and the O-CU 240 may generate, based on the configured cell DTX / DRX parameter(s), a command (or any other suitable type of message or signal) for instructing the O-DU 250 to implement the cell DTX / DRX on the associated cell(s) (“implementation command” herein). The implementation command may include information of a target cell to which the cell DTX / DRX should be implemented and information of cell DTX / DRX configurations (e.g., DTX / DRX cycle, active duration, non-active duration, activation / deactivation timing, etc.) Subsequently, the O-CU 240 may provide the implementation command to the O-DU 250 via an Fl interface, and the O-DU 250 may implement the cell DTX / DRX to the associated cell(s) according to the implementation command. Additionally or alternatively, the Near-RT RIC 230 (or the xApp 231 implemented therein) may be configured to generate the implementation command and then provide the same to the O-DU 250 via the E2 interface. In this case, the O-DU 250 may receive the implementation command from the xApp 231 (in addition to or in alternative to receiving the implementation command from the O-CU 240), and then implement the cell DTX / DRX to the associated cell(s) according to the implementation command.

[0077] 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 O-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.

[0078] The communication between the O-CU 240 and the O-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 embodiments, the system may include a plurality 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 O-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.

[0079] 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 CU 212 and the DUs 214-216 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 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).

[0080] 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. As an example, the O-CU 240 may provide one or more cell DTX / DRX configurations to the O-DU 250 and / or the O-RU(s) 260 via RRC signaling.

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

[0082] 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 bedeployed therein. According to embodiments, one or more of the cells may be configured with cellDRX and / or cell DTX.

[0083] According to example embodiments, the O-CU 240 may be configured to receive one or more cell DTX / DRX parameters from the xApp 231 via the E2 interface, and then utilize the cell DTX / DRX parameter(s) to control the cell DTX / DRX implementations or settings in the associated cell(s). In some example embodiments, the O-CU 240 may configure at least one managed object instance (MOI) via E2 service model-cell configuration and control (E2SM-CCC) to forward the intent of switching DTX / DRX of cells.

[0084] Further, the O-CU 240 may optionally handle the cell states transition and UE mobility to prepare for cell switching DTX / DRX (e.g., on / off of the cell), and eventually send a command to the 0-DU 250 such that the 0-DU 250 may control or instruct the associated O-RU(s) or cell(s) to switch to and / or from the DTX / DRX. Additionally or alternatively, the cell states transition and UE mobility may be handled by the Near-RT R1C 230 (or by the xApp 231 implemented therein), and the 0-DU 250 may receive the command therefrom and then control or instruct the associated O-RU(s) or cell(s) to switch to and / or from the DTX / DRX.

[0085] 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 0-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 O-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 stay in DTX / DRXmode for a longer time to save more energy when one or more conditions is satisfied (e.g., when the network traffic in the O-RU(s) 260 is below a threshold, etc.)

[0086] In view of the above, example embodiments of the present disclosure utilize the Non-RT RIC 220 and the Near-RT RIC 230 to dynamically manage the cell DTX / DRX configurations. Specifically, the Non-RT RIC 220 may implement the rApp 221 to dynamically configure one or more Al policies which defines which network cell(s) should implement the cell DTX / DRX and which type of UE should connect to the cell(s) implementing the cell DTX / DRX, while the Near-RT RIC 230 may implement the xApp 231 to dynamically configure one or more cell DTX / DRX parameters. Accordingly, the xApp 231 may implement the cell DTX / DRX (e.g., via the O-CU 240 and / or the O-DU 250) according to the configured cell DTX / DRX parameters, thereby enhancing the cell DTX / DRX mechanisms.Example Operations for Providing Enhancement on Cell DTX / DRX Mechanisms

[0087] Example embodiments of the present disclosure provide a system that perform one or more operations to provide enhancement on cell DTX / DRX mechanisms. In some example implementations, the system may include at least one Non-RT RIC (e.g., Non-RT RIC 220) configured to implement at least one rApp (e.g., rApp 221) and at least one Near-RT RIC (e.g., Near-RT RIC 230) configured to implement at least one xApp (e g., xApp 231), while one or more operations described herein may be performed by the Non-RT RIC (or the rApp associated therewith) and / or the Near-RT RIC (or the xApp associated therewith). According to example embodiments, the system may further include at least one O-CU (e.g., O-CU 240), at least one O- DU (e.g., O-DU 250), and / or at least one O-RU (e.g., O-RU 260), and one or more operations described herein may be further performed by one or more of the O-CU, the O-DU, and the O-RU.Further, one or more components of the system (e.g., Non-RT RIC / rApp, Near-RT RIC / xApp, O-CU, O-DU, etc.) may be implemented by one or more hardware components, and one or more operations described herein may be performable by said one or more hardware components. Specifically, in some example embodiments, the system may include at least one processor and at least one memory storage storing computer-readable instructions for implementing one or more components of the systems and / or one or more operations associated therewith. In this case, one or more operations described herein may be performed by the at least one processor, upon executing the computer-readable instructions stored in the at least one memory storage.

[0088] In the following, several example operations performable by the system of the present disclosure, according to one or more example embodiments, are described with reference to FIG. 3 to FIG. 7. One or more operations and parameters described herein may involve or may be similar to those described above with reference to FIG. 2. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0089] FIG. 3 illustrates a flow diagram of an example method 300 for enhancing cell DTX / DRX mechanisms, according to one or more example embodiments. Referring to FIG. 3, at operation S310, at least one policy is being configured. Specifically, in this operation, the Non-RT RIC (or the rApp implemented therein) may be configured to configure or adjust the at least one policy. As described above with reference to FIG. 2, the at least one policy may define which cell should implement cell DTX / DRX and which type of UE should connect to the cell implementing the cell DTX / DRX. Further, the at least one policy may include a configuration of the cell DTX / DRX, such as a periodicity of the DTX / DRX cycle (or a periodicity of the cell DTX / DRX), a length of the DTX / DRX cycle (or a length of the cell DTX / DRX), and / or an active duration of the DTX / DRX cycle (or an active duration of the cell DTX / DRX). The policy(s) is executable by a Near-RT RIC, an O-CU, and / or an O-DU to implement the cell DTX / DRX.

[0090] According to example embodiments, the Non-RT RIC (or the rApp implemented therein) may be configured to configure or adjust the policy by configuring at least one of a periodicity of the DTX / DRX cycle (or a periodicity of the cell DTX / DRX), a length of the DTX / DRX cycle (or a length of the cell DTX / DRX), and / or an active duration of the DTX / DRX cycle (or an active duration of the cell DTX / DRX).

[0091] According to example embodiments, the Non-RT RIC (or the rApp implemented therein) may be configured to configure or adjust a plurality of policies. In this case, the Non-RT RIC (or the rApp implemented therein) may be configured to configure or adjust the plurality of policies by determining a priority level of each of the plurality of policies, based on an energysaving requirement, a QoS requirement, a handover requirement, and / or a network condition, and then configuring the plurality of policies based on the respective priority level.

[0092] According to example embodiments, the Non-RT RIC (or the rApp implemented therein) may be configured to configure or adjust the policy(s) by: implementing at least one AI / ML model to predict an optimal cell DTX / DRX configuration based on historical network data and trends, and then configuring the policy(s) based on the predicted optimal cell DTX / DRX configuration.

[0093] According to example embodiments, the Non-RT RIC (or the rApp implemented therein) may be configured to configure or adjust a policy according to the type of energy resource of the associated cell. For instance, the Non-RT RIC (or the rApp implemented therein) may determine, from among a plurality of cells, a cell that is powered by a renewable energy, and then configure the policy to adjust a cell DTX / DRX configuration associated with the determined cell. Further example operations for configuring the policy(s) are described below with reference toFIG. 4.

[0094] Upon configuring the policy, the method 300 may proceed to operation S320, at which the Non-RT RIC (or the rApp implemented therein) may be configured to provide the at least one configured policy to at least one of: a Near-RT RIC (or an xApp implemented therein), an O-CU, and an 0-DU. For instance, the Non-RT RIC (or the rApp implemented therein) may be configured to provide the policy to the Near-RT RIC (or the xApp implemented therein) via an Al interface. On the other hand, the Non-RT RIC (or the rApp implemented therein) may be configured to provide the policy to the O-CU and / or the O-DU via an 01 interface.

[0095] According to example embodiments, the Non-RT RIC (or the rApp implemented therein) may be configured to periodically update the policy(s) based on at least one network performance metric, and then provide the updated policy to the Near-RT RIC, the O-CU, and / or the 0-DU.

[0096] Upon receiving the policy(s) from the Non-RT RIC (or the rApp implemented therein), the Near-RT RIC, the O-CU, and / or the O-DU may be configured to utilize the policy and perform one or more operations based thereon. For instance, the Near-RT RIC (or the xApp implemented therein) may be configured to configure or adjust at least one cell DTX / DRX parameter based on the policy and a real-time (or near-real-time) information. The real-time (or near-real-time) information may include one or more of: a real-time (or near-real-time) user mobility pattern and a real-time (or near-real-time) network traffic condition. As described above with reference to FIG. 2, the at least one cell DTX / DRX parameter may include one or more of: a parameter associated with the configuration of the cell DRX / DTX, a parameter associated with one or more cells to which the cell DRX / DTX is applicable or is to be implemented, a parameter associated with the activation of the cell DRX / DTX, a parameter associated with downlink control information (DCI) format for signaling the cell DTX / DRX configuration, a parameter associatedwith the timing of the at least one policy (e.g., Al policy, etc.), and a parameter associated with one or more energy saving objectives. Additionally or alternatively, the at least one cell DTX / DRX parameter may include one or more parameters defined in one or more 3 GPP technical standards or specifications, such as cellDTRX-DCI-config parameter, dci-Format2-9 parameter, cellDTRX- RNTI parameter, sizeDCI-2-9 parameter, positionlnDCI-cellDTRX parameter, and the like.

[0097] According to example embodiments, the Near-RT RIC may be configured to configure or adjust the cell DTX / DRX parameter(s) by: determining, based on the real-time (or near-real-time) information (e.g., real-time user mobility pattern etc.), whether or not a handover is required when a user is moving from an adjacent cell to a target cell; and based on determining that the handover is required, configuring at least one cell DTX / DRX parameter associated with the target cell according to at least one handover requirement. Example operations associated with the Near-RT RIC configuring the at least one cell DTX / DRX parameter are described below with reference to FIG. 5.

[0098] According to example embodiments, the Near-RT RIC (or the xApp implemented therein) may be configured to implement, via at least one of the O-CU and the O-DU, the cell DTX / DRX to at least one cell based on the at least one configured cell DTX / DRX parameter. Example operations for implementing the cell DTX / DRX via the O-CU are described below with reference to FIG. 6, and example operations for implementing the cell DTX / DRX via the O-DU are described below with reference to FIG. 7.

[0099] In some example implementations, the Non-RT RIC (or the rApp implemented therein) may be configured to determine an amount of energy-saving achieved through the cell DTX / DRX implemented based on the configured policy(s), and then report the determined amount of energy-saving to, for example, a management system.

[0100] Referring next to FIG. 4, which illustrates a flow diagram of an example method 400 for configuring at least one policy, according to one or more example embodiments. One or more operations of method 400 may be part of the operation S310 of method 300 in FIG. 3, and may be implemented by a Non-RT RIC (or a rApp implemented therein).

[0101] At operation S410, the Non-RT RIC (or the associated rApp) may be configured to obtain information associated with at least one of: a QoS requirement, an energy saving requirement, a handover requirement, and a network condition. The QoS requirement, the energy saving requirement, and / or the handover requirement may be configured by the network operator (e.g., configured based on SLA, etc.) and provided to the Non-RT RIC (or the rApp implemented therein). In this case, the information associated with the QoS requirement, the energy saving requirement, and / or the handover requirement may be stored in one or more storage mediums associated with the Non-RT RIC (e.g., a memory storage of a server in which the Non-RT RIC is implemented, etc.), and the Non-RT RIC (or the associated rApp) may be configured to retrieve said information from the one or more storage mediums at operation S410. On the other hand, the information associated with the network condition may be determined or collected by the Non-RT RIC (or the rApp implemented therein). Alternatively or additionally, information associated with the QoS requirement, the energy saving requirement, the handover requirement, and / or the network condition may be managed by other system (e.g., a business support system (BSS), etc.) In this case, the Non-RT RIC (or the associated rApp) may be configured to retrieve said information from said other system at operation S410.

[0102] At operation S420, the Non-RT RIC (or the associated rApp) may be configured to obtain information associated with the implementation of the cell DTX / DRX. Specifically, theNon-RT RIC (or the associated rApp) may obtain the information associated with theimplementation of the cell DTX / DRX from at least one of the Near-RT RIC, the O-CU, and the O-DU. For instance, the Non-RT RIC (or the associated rApp) may obtain, from the Near-RT RIC via the Al interface, one or more policy feedbacks associated with the impact or effectiveness of the configured policy(s) in the implementation of the cell DTX / DRX. Additionally or alternatively, the Non-RT RIC (or the associated rApp) may obtain, from the O-CU and / or the O-DU via the 01 interface, one or more observables (e.g., events, network status, etc.) associated with the impact or effectiveness of the configured policy(s) in the implementation of the cell DTX / DRX.

[0103] It is contemplated that operations S410 and S420 may be performed in any suitable sequences, without departing from the scope of the present disclosure. For instance, operation S410 and S420 may be performed concurrently, operation S410 may be performed prior to operation S420, operation S420 may be performed prior to operation S410, and the like.

[0104] Upon performing operations S410 and S420, the method 400 may proceed to operation S430, at which the Non-RT RIC (or the associated rApp) may be configured to determine, based on the obtained information, at least one guidance for implementing the cell DTX / DRX. The at least one implementation guidance may include one or more of information of a network cell (e.g., cell ID, cell type, etc.) that should implement the cell DTX / DRX, information of the type of UE (e.g., device model, manufacturing years, supported technical specification version, etc.) that is allowed to connect to the network cell that implements the cell DTX / DRX, information of RAT (e.g., modulation and coding scheme (MCS), transmission timing, etc.) that should be utilized for implementing the cell DTX / DRX, and information of the frequency layer (e.g., carrier frequency, channel bandwidth) that should be utilized for implementing the cell DTX / DRX.

[0105] Upon determining the at least one guidance for implementing the cell DTX / DRX, the method 400 may proceed to operation S440, at which the Non-RT RIC (or the associated rApp)may be configured to include the at least one guidance into at least one policy. According to embodiments, the at least one policy is previously provided to the Near-RT RIC, the O-CU, and / or the O-DU. In this case, the Non-RT RIC (or the associated rApp) may update the at least one policy to include the determined at least one guidance. Additionally or alternatively, the Non-RT RIC (or the associated rApp) may create a new policy that includes the determined at least one guidance.

[0106] Referring next to FIG. 5, which illustrates a flow diagram of an example method 500 for configuring at least one cell DTX / DRX parameter, according to one or more example embodiments. One or more operations of method 500 may be implemented by a Near-RT RIC (or an xApp implemented thereby).

[0107] At operation S510, the Near-RT RIC (or the associated xApp) may be configured to determine at least one cell associated with at least one configured policy (e.g., policy configured at operation S310, etc.) According to example embodiments in which the Near-RT RIC (or the associated xApp) has previously received a policy, the Near-RT RIC (or the associated xApp) may compare the previous policy with the at least one configured policy to determine the differences therebetween, and then determine the at least one associated cell therefrom. According to example embodiments in which the at least one configured policy is newly created by the Non-RT RIC (or the associated rApp), the Near-RT RIC (or the associated xApp) may determine the at least one associated cell based on the information of the cell (e.g., cell ID, etc.) included in the at least one configured policy.

[0108] Accordingly, at operation S520, the Near-RT RIC (or the associated xApp) may be configured to determine, from among a plurality of cell DTX / DRX parameters, at least one cell DTX / DRX parameter associated with the at least one associated cell. For instance, the Near-RTRIC (or the associated xApp) may determine which cell DTX / DRX parameter(s) should be configured or adjusted according to the at least one configured policy.

[0109] Subsequently, at operation S53O, the Near-RT RIC (or the associated xApp) may be configured to adjust, based on the at least one configured policy, the at least one associated cell DTX / DRX parameter. For instance, in order to implement the cell DTX / DRX in a cell at a specific timing as required by the at least one configured policy, the Near-RT RIC (or the associated xApp) may adjust the parameter associated with the activation of the cell DTX / DRX (e.g., timing to send the activation trigger, etc.) according to the specific timing. The Near-RT RIC (or the associated xApp) may adjust other suitable parameters (e.g., parameter associated with the periodicity of the cell DTX / DRX, length of the DTX / DRX cycle, etc.) in a similar manner.

[0110] Next, example operations of several use cases for enhancing the implementation of the cell DTX / DRX are described with reference to FIG. 6 and FIG. 7.

[0111] Referring first to FIG. 6, which illustrates a flow sequence of an example use case for implementing the cell DTX / DRX via an O-CU, according to one or more example embodiments. As illustrated in FIG. 6, this example use case involves the Non-RT RIC 220, the Near-RT RIC 230, the O-CU 240, and the 0-DU 250, each of which may be similar to those described above with reference to FIG. 2. Further, one or more operations in FIG. 6 may involve or may be part of one or more operations described above with reference to FIG. 3 to FIG. 5. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0112] Referring to FIG. 6, at step 1, the Non-RT RIC 220 (or the associated rApp) may be configured to configure at least one policy. This step may be similar to operation S310 in FIG.3 and may involve operations S410 to S440 in FIG. 4. Subsequently, at step 2, the Non-RT RIC 220 (or the associated rApp) may provide the at least one configured policy to the Near-RT RIC230 (or the associated xApp) via the Al interface. Accordingly, at step 3, the Near-RT RIC 230 (or the associated xApp) may be configured to adjust or configure at least one cell DTX / DRX parameter. This step may be similar to operation S320 in FIG. 3 and may involve operations S510 to S530 in FIG. 5.

[0113] Upon configuring the at least one cell DTX / DRX parameter, at step 4, the Near-RT RIC 230 (or the associated xApp) may provide the at least one configured cell DTX / DRX parameter to the O-CU 240 via the E2 interface. Accordingly, at step 5, the O-CU 240 may generate, based on the at least one configured cell DTX / DRX parameter, a command (or any other suitable type of message or signal) for instructing the 0-DU 250 to implement the cell DTX / DRX on the associated cell(s). The command may include information of a target cell to which the cell DTX / DRX should be implemented and information of cell DTX / DRX configurations (e.g., periodicity, DTX / DRX cycle, active duration, non-active duration, activation / deactivation timing, etc.) Subsequently, at step 6, the O-CU 240 may provide the implementation command to the O- DU 250 via an Fl interface. In this regard, the 0-DU 250 may implement the cell DTX / DRX to the associated cell(s) according to the implementation command.

[0114] Referring next to FIG. 7, which illustrates a flow sequence of an example use case for implementing the cell DTX / DRX via the 0-DU, according to one or more example embodiments. Steps 1 to 3 in FIG. 7 may be similar to steps 1 to 3 in FIG. 6. The flow sequence in FIG. 7 is different from the flow sequence in FIG. 6 in that, in FIG. 7, the command for implementing the cell DTX / DRX are generated and provided by the Near-RT RIC 230 (or the associated xApp), instead of the O-CU 240. In this regard, the Near-RT RIC 230 (or the associated xApp) may generate the implementation command (at step 4) and then provide the implementationcommand to the O-DU 250 via the E2 interface (at step 5). Accordingly, the O-DU 250 may implement the cell DTX / DRX to the associated cell(s) according to the implementation command.

[0115] 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. Further, one or more additional / alternative operations may be performed without departing from the scope of the present disclosure. For instance, as described above with reference to FIG. 2, the Near-RT RIC 230 (or the associated xApp) may also be configured to perform one or more control operations, such as handling of cell state transition, steering of UEs according to the UE type, and the like, via the E2 interface.

[0116] To this end, example embodiments of the present disclosure may provide one or more operations for enhancing the cell DTX / DRX mechanisms. Specifically, example embodiments provide operations for dynamically configuring the policy(s) and the cell DTX / DRX parameter(s), as well as operations for implementing the cell DTX / DRX according to the configured parameter(s). Ultimately, the energy saving opportunity in the network can be optimized, while ensuring that the network performances (e.g., latency, throughput) can be maintained within a certain level (e.g., QoS requirement, etc.)Examples of Hardware Components

[0117] One or more components of the system of the example embodiments (e.g., Non-RTRIC 220, Near-RT RIC 230, etc.), as well as the operations associated therewith (e.g., one or more operations in FIG. 2 to FIG. 7, etc.), may be implemented in one or more devices or hardware components, such as one or more servers, and the like. In the following, descriptions of a device in which the example embodiments may be implemented are provided.

[0118] FIG. 8 illustrates an embodiment of a device 800. As shown in FIG. 8, the device800 may include a processor 810, a memory 820, a storage component 830, an input component 840, an output component 850, a communication interface 860, and a bus 870.

[0119] The processor 810, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 810 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like. The processor 810 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.

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

[0121] Storage component 830 stores information and / or software related to the operation and use of the device 800. For example, storage component 830 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.

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

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

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

[0125] The bus 870 acts as an interconnect between the processor 810, the memory 820, the storage component 830, the input component 840, the output component 850, and the communication interface 860 of the device 800. The bus 870 may include a wired interconnection or a wireless interconnection.

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

[0127] It is contemplated that the example embodiments described hereinabove are merely examples of possible embodiments of the present disclosure, and are not intended to limit or restrict the scope of the present disclosure.

[0128] Specifically, 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.

[0129] Some example embodiments may relate to a device, 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.

[0130] 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 computerdiskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), electrically erasable programmable read-only memory (EEPROM), 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.

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

[0132] 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 anycombination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages.

[0133] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone 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 thefunction / 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 devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices 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 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 limited to the implementations. Thus, the operation and behavior of the systems and / or methods were 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.

[0138] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: A system including: a non-real-time (Non-RT) radio access network intelligent controller (RIC) configured to: configure at least one policy, wherein the policy may define a configuration of a cell Discontinuous Transmission (DTX) / Discontinuous Reception (DRX), and wherein the policy may be executable by at least one of: a near-realtime (Near-RT) RIC, an open radio access network (0-RAN) central unit (O-CU), and an 0-RAN distributed unit (0-DU), to implement the cell DTX / DRX; provide the configured policy to at least one of: the Near-RT RIC, the O-CU, and the O-DU.Item [2] : The system according to item

[0001] , wherein the Non-RT RIC may be further configured to: periodically update the policy based on at least one network performance metric; and provide the updated policy to at least one of: the Near-RT RIC, the O-CU, and the O-DU.Item [3]: The system according to any one of items [l]-[2], wherein the Non-RT RIC may configure the policy by: implementing at least one artificial intelligence (AI) / machine learning (ML) model to predict an optimal cell DTX / DRX configurationbased on historical network data and trends; and configuring the policy based on the predicted optimal cell DTX / DRX configuration.Item [4]: The system according to any one of items [l]-[3], wherein the at least one policy may include a plurality of policies, and wherein the Non-RT RIC may configure the policy by: determining a priority level of each of the plurality of policies, based on at least one of: an energy-saving requirement, a quality of server (QoS) requirement, a handover requirement, and a network condition; and configuring the plurality of policies based on the respective priority level.Item [5]: The system according to any one of items [l]-[4], wherein the Non-RT RIC may configure the policy by: implementing at least one artificial intelligence (AI) / machine learning (ML) model to predict an optimal cell DTX / DRX configuration based on historical network data and trends; and configuring the policy based on the predicted optimal cell DTX / DRX configuration.Item [6]: The system according to any one of items [l]-[5], wherein the Non-RT RIC may configure the policy by: determine, from among a plurality of cells, a cell that is powered by a renewable energy; and configuring the policy to adjust a cell DTX / DRX configuration associated with the determined cell.Item [7]: The system according to any one of items [l]-[6], wherein the Non-RT RIC may be further configured to: determine an amount of energy-saving achieved through the cell DTX / DRX implemented based on the configured policy; and report, to a management system, the determined amount of energy-saving.Item [8]: The system according to amy one of items [l]-[7], wherein the Non-RT RIC may be configured to provide the policy to the Near-RT RIC via an Al interface,wherein the system may further include the Near-RT RIC and the Near-RT RIC may be configured to: configure at least one cell DTX / DRX parameter based on the policy and a real-time information, wherein the real-time information may include at least one of: a realtime user mobility pattern and a real-time network traffic condition.Item [9]: The system according to item [8], wherein the Near-RT RIC may configure the cell DTX / DRX parameter by: determining, based on the real-time user mobility pattern, whether or not a handover is required when a user is moving from an adjacent cell to a target cell; and based on determining that the handover is required, configuring at least one cell DTX / DRX parameter associated with the target cell according to at least one handover requirement.Item

[0010] : The system according to any one of items [l]-[9], wherein the Non-RT RIC may be configured to provide the policy to at least one of the O-CU and the O-DU via an 01 interface.Item

[0011] : The system according to any one of items [l]-

[0010] , wherein the Non-RT RIC may configure the policy by: obtaining information associated with at least one of: a QoS requirement, an energy saving requirement, a network condition, and a handover requirement; obtaining, from at least one of the Near-RT RIC, the O-CU, and the O-DU, information associated with the implementation of the cell DTX / DRX; determining, based on the obtained information, at least one guidance for implementing the cell DTX / DRX; and including the information of the at least one guidance into the policy.Item

[0012] : The system according to any one of items [8]-[9], wherein the Near-RT RIC may configure the at least one cell DTX / DRX parameter by: determining, from among a plurality of cells, at least one cell associated with the policy; determining, from among aplurality of cell DTX / DRX parameters, at least one cell DTX / DRX parameter associated with the associated cell; and adjusting, based on the policy, the at least one associated cell DTX / DRX parameter.Item

[0013] : The system according to any one of items [8], [9], and

[0012] , wherein the at least one cell DTX / DRX parameter may include one or more of: a parameter associated with the configuration of the cell DRX / DTX, a parameter associated with one or more cells to which the cell DRX / DTX is applicable, a parameter associated with the activation of the cell DRX / DTX, a parameter associated with downlink control information (DCI) format for signaling the cell DTX / DRX configuration, a parameter associated with the timing of the policy, and a parameter associated with one or more energy saving objectives.Item

[0014] : The system according to item

[0011] , wherein the information of the at least one guidance may include one or more of: information of a cell that should implement the cell DTX / DRX, information of the type of UE that is allowed to connect to the cell that implements the cell DTX / DRX, information of radio access technology (RAT) that should be utilized for implementing the cell DTX / DRX, and information of the frequency layer that should be utilized for implementing the cell DTX / DRX.Item

[0015] : The system according to any one of items [8], [9],

[0012] , and

[0013] , wherein the system may further include the O-CU; wherein the Near-RT RIC may be communicatively coupled to the O-CU via an E2 interface; wherein the Near-RT RIC may be configured to implement the cell DTX / DRX by providing the at least one configured cell DTX / DRX parameter to the O-CU via the E2 interface; wherein the O-CU may be configured to generate, based on the at least one configured cell DTX / DRX parameter, a command for instructing the O-DU to implement the cell DTX / DRX on the at least onecell; and wherein the O-CU may be configured to provide the command to the O-DU via an Fl interface.Item

[0016] : The system according to any one of items [8], [9],

[0012] , and

[0013] , wherein the Near-RT RIC may be communicatively coupled to the O-DU via an E2 interface; wherein the Near-RT RIC may be configured to implement the cell DTX / DRX by: generating, based on the at least one configured cell DTX / DRX parameter, a command for instructing the O-DU to implement the cell DTX / DRX on the at least one cell; and providing the command to the O-DU via the E2 interface.Item

[0017] : A method including: configuring at least one policy, wherein the policy may define a configuration of a cell Discontinuous Transmission (DTX) / Discontinuous Reception (DRX), and wherein the policy may be executable by at least one of: a near-realtime (Near-RT) radio access network intelligent controller (RIC), an open radio access network (O-RAN) central unit (O-CU), and an O-RAN distributed unit (O-DU), to implement the cell DTX / DRX; and providing the configured policy to at least one of the Near-RT RIC, the O-CU, and the O-DU.Item

[0018] : The method according to item

[0017] , further includes: periodically updating the policy based on at least one network performance metric; and providing the updated policy to at least one of the Near-RT RIC, the O-CU, and the O-DU.Item

[0019] : The method according to any one of items

[0017] -

[0018] , wherein the configuring the policy may include: configuring at least one of: a periodicity of a cell DTX / DRX cycle, a length of the DTX / DRX cycle, and an active duration of the DTX / DRX cycle.Item

[0020] : The method according to any one of items

[0017] -

[0019] , wherein the at least one policy may include a plurality of policies, and wherein the configuring the policy may include: determining a priority level of each of the plurality of policies, based on at least one of: an energy-saving requirement, a quality of server (QoS) requirement, a handover requirement, and a network condition; and configuring the plurality of policies based on the respective priority level.Item

[0021] : The method according to any one of items

[0017] -

[0020] , wherein the configuring the policy may include: implementing at least one artificial intelligence (AI) / machine learning (ML) model to predict an optimal cell DTX / DRX configuration based on historical network data and trends; and configuring the policy based on the predicted optimal cell DTX / DRX configuration.Item

[0022] : The method according to any one of items

[0017] -

[0021] , wherein the configuring the policy may include: determining, from among a plurality of cells, a cell that is powered by a renewable energy; and configuring the policy to adjust a cell DTX / DRX configuration associated with the determined cell.Item

[0023] : The method according to any one of items

[0017] -

[0022] , further includes: determining an amount of energy-saving achieved through the cell DTX / DRX implemented based on the configured policy; and reporting, to a management system, the determined amount of energy-saving.Item

[0024] : The method according to any one of items

[0017] -

[0023] , further includes: configuring at least one cell DTX / DRX parameter based on the policy and a real-time information, wherein the real-time information may include at least one of: a real-time user mobility pattern and a real-time network traffic condition.Item

[0025] : The method according to item

[0024] , wherein the configuring the cell DTX / DRX parameter may include: determining, based on the real-time user mobility pattern, whether or not a handover is required when a user is moving from an adjacent cell to a target cell; and based on determining that the handover is required, configuring at least one cell DTX / DRX parameter associated with the target cell according to at least one handover requirement.Item

[0026] : The method according to any one of items

[0017] -

[0025] , wherein the providing the policy may include: providing the policy to the Near-RT RIC via an Al interface.Item

[0027] : The method according to any one of items

[0017] -

[0026] , wherein the providing the policy may include: providing the policy to at least one of the O-CU and the O-DU via an 01 interface.Item

[0028] : The method according to any one of items

[0017] -

[0027] , wherein the configuring the policy may include: obtaining information associated with at least one of: a QoS requirement, an energy saving requirement, a network condition, and a handover requirement; obtaining, from at least one of the Near-RT RIC, the O-CU, and the 0-DU, information associated with the implementation of the cell DTX / DRX; determining, based on the obtained information, at least one guidance for implementing the cell DTX / DRX; and including the information of the at least one guidance into the policy.Item

[0029] : The method according to any one of items

[0024] -

[0025] , wherein the configuring the cell DTX / DRX parameter may include: determining, from among a plurality of cells, at least one cell associated with the policy; determining, from among a plurality of cell DTX / DRX parameters, at least one cell DTX / DRX parameter associatedwith the associated cell; and adjusting, based on the policy, the at least one associated cell DTX / DRX parameter.Item

[0030] : The method according to any one of items

[0024] ,

[0025] , and

[0029] , wherein the at least one cell DTX / DRX parameter may include one or more of: a parameter associated with the configuration of the cell DRX / DTX, a parameter associated with one or more cells to which the cell DRX / DTX is applicable, a parameter associated with the activation of the cell DRX / DTX, a parameter associated with downlink control information (DCI) format for signaling the cell DTX / DRX configuration, a parameter associated with the timing of the policy, and a parameter associated with one or more energy saving objectives.Item

[0031] : The method according to item

[0028] , wherein the information of the at least one guidance may include one or more of: information of a cell that should implement the cell DTX / DRX, information of the type of UE that is allowed to connect to the cell that implements the cell DTX / DRX, information of radio access technology (RAT) that should be utilized for implementing the cell DTX / DRX, and information of the frequency layer that should be utilized for implementing the cell DTX / DRX.Item

[0032] : The method according to any one of items

[0024] ,

[0025] ,

[0029] , and

[0030] , further includes: generating, based on the at least one configured cell DTX / DRX parameter, a command for instructing the O-DU to implement the cell DTX / DRX on the at least one cell; and providing the command to the O-DU.Item

[0033] : A non-transitory computer-readable recording medium having recorded thereon instructions executable by a system to cause the system to perform a method including: configuring at least one policy, wherein the policy may define a configurationof a cell Discontinuous Transmission (DTX)ZDiscontinuous Reception (DRX), and wherein the policy may be executable by at least one of: a near-real-time (Near-RT) radio access network intelligent controller (RIC), an open radio access network (O-RAN) central unit (O-CU), and an O-RAN distributed unit (O-DU), to implement the cell DTX / DRX; and providing the configured policy to at least one of the Near-RT RIC, the O-CU, and the O-DU.Item

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

[0033] , wherein the method may further include: periodically updating the policy based on at least one network performance metric; and providing the updated policy to at least one of the Near-RT RIC, the O-CU, and the O-DU.Item

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

[0033] -

[0034] , wherein the configuring the policy may include: configuring at least one of: a periodicity of a cell DTX / DRX cycle, a length of the DTX / DRX cycle, and an active duration of the DTX / DRX cycle.Item

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

[0033] -

[0035] , wherein the at least one policy may include a plurality of policies, and wherein the configuring the policy may include: determining a priority level of each of the plurality of policies, based on at least one of: an energy-saving requirement, a quality of server (QoS) requirement, a handover requirement, and a network condition; and configuring the plurality of policies based on the respective priority level.Item

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

[0033] -

[0036] , wherein the configuring the policy may include: implementing at least one artificial intelligence (AI) / machine learning (ML) model to predict an optimalcell DTX / DRX configuration based on historical network data and trends; and configuring the policy based on the predicted optimal cell DTX / DRX configuration.Item

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

[0033] -

[0037] , wherein the configuring the policy may include: determining, from among a plurality of cells, a cell that is powered by a renewable energy; and configuring the policy to adjust a cell DTX / DRX configuration associated with the determined cell.Item

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

[0033] -

[0038] , wherein the method may further include: determining an amount of energy-saving achieved through the cell DTX / DRX implemented based on the configured policy; and reporting, to a management system, the determined amount of energy-saving.Item

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

[0033] -

[0039] , wherein the method may further include: configuring at least one cell DTX / DRX parameter based on the policy and a real-time information, wherein the real-time information may include at least one of: a real-time user mobility pattern and a real-time network traffic condition.Item

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

[0040] , wherein the configuring the cell DTX / DRX parameter may include: determining, based on the real-time user mobility pattern, whether or not a handover is required when a user is moving from an adjacent cell to a target cell; and based on determining that the handover is required, configuring at least one cell DTX / DRX parameter associated with the target cell according to at least one handover requirement.Item

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

[0033] -

[0041] , wherein the providing the policy may include: providing the policy to the Near-RT RIC via an Al interface.Item

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

[0033] -

[0042] , wherein the providing the policy may include: providing the policy to at least one of the O-CU and the O-DU via an 01 interface.Item

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

[0033] -

[0043] , wherein the configuring the policy may include: obtaining information associated with at least one of: a QoS requirement, an energy saving requirement, a network condition, and a handover requirement; obtaining, from at least one of the Near-RT RIC, the O-CU, and the 0-DU, information associated with the implementation of the cell DTX / DRX; determining, based on the obtained information, at least one guidance for implementing the cell DTX / DRX; and including the information of the at least one guidance into the policy.Item

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

[0040] -

[0041] , wherein the configuring the cell DTX / DRX parameter may include: determining, from among a plurality of cells, at least one cell associated with the policy; determining, from among a plurality of cell DTX / DRX parameters, at least one cell DTX / DRX parameter associated with the associated cell; and adjusting, based on the policy, the at least one associated cell DTX / DRX parameter.Item

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

[0040] ,

[0041] , and

[0045] , wherein the at least one cell DTX / DRX parameter may include one or more of: a parameter associated with the configuration of the cellDRX / DTX, a parameter associated with one or more cells to which the cell DRX / DTX is applicable, a parameter associated with the activation of the cell DRX / DTX, a parameter associated with downlink control information (DCI) format for signaling the cell DTX / DRX configuration, a parameter associated with the timing of the policy, and a parameter associated with one or more energy saving objectives.Item

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

[0044] , wherein the information of the at least one guidance may include one or more of information of a cell that should implement the cell DTX / DRX, information of the type of UE that is allowed to connect to the cell that implements the cell DTX / DRX, information of radio access technology (RAT) that should be utilized for implementing the cell DTX / DRX, and information of the frequency layer that should be utilized for implementing the cell DTX / DRX.Item

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

[0040] ,

[0041] ,

[0045] , and

[0046] , wherein the method may further include: generating, based on the at least one configured cell DTX / DRX parameter, a command for instructing the 0-DU to implement the cell DTX / DRX on the at least one cell; and providing the command to the 0-DU.

[0139] 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: configure at least one policy, wherein the policy defines a configuration of a cell Discontinuous Transmission (DTX) / Discontinuous Reception (DRX), and wherein the policy is executable by at least one of: a near-real-time (Near-RT) RIC, an open radio access network (O-RAN) central unit (O-CU), and an O- RAN distributed unit (O-DU), to implement the cell DTX / DRX; and provide the configured policy to at least one of the Near-RT RIC, the O-CU, and the O-DU.

2. The system according to claim 1, wherein the Non-RT RIC is further configured to: periodically update the policy based on at least one network performance metric; and provide the updated policy to at least one of the Near-RT RIC, the O-CU, and the O-DU.

3. The system according to claim 1, wherein the Non-RT RIC configures the policy by:configuring at least one of a periodicity of a cell DTX / DRX cycle, a length of the DTX / DRX cycle, and an active duration of the DTX / DRX cycle.

4. The system according to claim 1, wherein the at least one policy comprises a plurality of policies, and wherein the Non-RT RIC configures the policy by: determining a priority level of each of the plurality of policies, based on at least one of: an energy-saving requirement, a quality of server (QoS) requirement, a handover requirement, and a network condition; and configuring the plurality of policies based on the respective priority level.

5. The system according to claim 1, wherein the Non-RT RIC configures the policy by: implementing at least one artificial intelligence (AI) / machine learning (ML) model to predict an optimal cell DTX / DRX configuration based on historical network data and trends; and configuring the policy based on the predicted optimal cell DTX / DRX configuration.

6. The system according to claim 1, wherein the Non-RT RIC configures the policy by:determining, from among a plurality of cells, a cell that is powered by a renewable energy; and configuring the policy to adjust a cell DTX / DRX configuration associated with the determined cell.

7. The system according to claim 1, wherein the Non-RT RIC is further configured to: determine an amount of energy-saving achieved through the cell DTX / DRX implemented based on the configured policy; and report, to a management system, the determined amount of energysaving.

8. The system according to claim 1, wherein the Non-RT RIC is configured to provide the policy to the Near-RT RIC via an Al interface, wherein the system further comprises the Near-RT RIC and the Near-RT RIC is configured to: configure at least one cell DTX / DRX parameter based on the policy and a real-time information, wherein the real-time information comprises at least one of: a real-time user mobility pattern and a real-time network traffic condition.

9. The system according to claim 8, wherein the Near-RT RIC configures the cell DTX / DRX parameter by: determining, based on the real-time user mobility pattern, whether or not a handover is required when a user is moving from an adjacent cell to a target cell; and based on determining that the handover is required, configuring at least one cell DTX / DRX parameter associated with the target cell according to at least one handover requirement.

10. The system according to claim 1, wherein the Non-RT RIC is configured to provide the policy to at least one of the O-CU and the O-DU via an 01 interface.

11. A method comprising: configuring at least one policy, wherein the policy defines a configuration of a cell Discontinuous Transmission (DTX) / Discontinuous Reception (DRX), and wherein the policy is executable by at least one of: a near-real-time (Near-RT) radio access network intelligent controller (RIC), an open radio access network (0-RAN) central unit (O-CU), and an 0-RAN distributed unit (O-DU), to implement the cell DTX / DRX; and providing the configured policy to at least one of the Near-RT RIC, the O-CU, and the O-DU.

12. The method according to claim 11, further comprises: periodically updating the policy based on at least one network performance metric; and providing the updated policy to at least one of the Near-RT RIC, the O-CU, and the O-DU.

13. The method according to claim 11, wherein the configuring the policy comprises: configuring at least one of: a periodicity of a cell DTX / DRX cycle, a length of the DTX / DRX cycle, and an active duration of the DTX / DRX cycle.

14. The method according to claim 11, wherein the at least one policy comprises a plurality of policies, and wherein the configuring the policy comprises: determining a priority level of each of the plurality of policies, based on at least one of: an energy-saving requirement, a quality of server (QoS) requirement, a handover requirement, and a network condition; and configuring the plurality of policies based on the respective priority level.

15. The method according to claim 11, wherein the configuring the policy comprises:implementing at least one artificial intelligence (AI) / machine learning (ML) model to predict an optimal cell DTX / DRX configuration based on historical network data and trends; and configuring the policy based on the predicted optimal cell DTX / DRX configuration.

16. The method according to claim 11, wherein the configuring the policy comprises: determining, from among a plurality of cells, a cell that is powered by a renewable energy; and configuring the policy to adjust a cell DTX / DRX configuration associated with the determined cell.

17. The method according to claim 11, further comprises: determining an amount of energy-saving achieved through the cell DTX / DRX implemented based on the configured policy; and reporting, to a management system, the determined amount of energy-saving.

18. The method according to claim 11, further comprises: configuring at least one cell DTX / DRX parameter based on the policy and a real-time information, wherein the real-time informationcomprises at least one of: a real-time user mobility pattern and a real-time network traffic condition.

19. The method according to claim 18, wherein the configuring the cell DTX / DRX parameter comprises: determining, based on the real-time user mobility pattern, whether or not a handover is required when a user is moving from an adjacent cell to a target cell; and based on determining that the handover is required, configuring at least one cell DTX / DRX parameter associated with the target cell according to at least one handover requirement.

20. 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 at least one policy, wherein the policy defines a configuration of a cell Discontinuous Transmission (DTX) / Discontinuous Reception (DRX), and wherein the policy is executable by at least one of: a near-real-time (Near-RT) radio access network intelligent controller (RIC), an open radio access network (O-RAN) central unit (O-CU), and an O-RAN distributed unit (O-DU), to implement the cell DTX / DRX; and providing the configured policy to at least one of the Near-RT RIC, the O-CU, and the O-DU.

Images