Enhanced transceiver (TRX) control

Abstract

Example embodiments of the present disclosure relate to enhanced transceiver (TRX) control. According to example embodiments, a Radio Unit (RU) may be configured to: receive, from an RU Controller, a control command associated with a TRX array. The control command may include information associated with a configuration of the TRX array and information associated with an applicable time window defining a valid period of the configuration. Accordingly, the RU may be configured to apply the configuration specified in the control command according to the applicable time window, thereby changing the TRX array from a default configuration to the configuration specified in the control command during the applicable time window.

Description

ENHANCED TRANSCEIVER (TRX) CONTROLCROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to Indian Provisional Patent Application No.202541004886, filed with the Indian Patent Office on January 21, 2025, the entire contents of which are incorporated herein by reference.TECHNICAL FIELD

[0002] The present disclosure relates to enhanced transceiver (TRX) control.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] A telecommunications network is constituted of multiple network entities that communicate and interoperate with each other through signaling exchanges. For instance, a network may include a transceiver (TRX) that transmits and receives radio signals, thereby communicatively coupling a user equipment (UE) to the network. The control of TRX (“TRX control” herein) is an important aspect of network management, in order to conserve energy consumption, increase energy efficiency, optimize resource utilization, and maintain network reliability.SUMMARY

[0005] Example embodiments of the present disclosure provide systems, methods, and the like, that effectively and efficiently enhance TRX control in a telecommunication network.

[0006] According to example embodiments, a Radio Unit (RU) may be configured to: receive, from an RU Controller, a control command associated with a TRX array, wherein the control command may include information associated with a configuration of the TRX array and information associated with an applicable time window defining a valid period of the configuration; and apply the configuration specified in the control command according to the applicable time window, thereby changing the TRX array from a default configuration to the configuration specified in the control command during the applicable time window.

[0007] According to example embodiments, a method may include: receiving, from an RU Controller, a control command associated with a TRX array, wherein the control command may include information associated with a configuration of the TRX array and information associated with an applicable time window defining a valid period of the configuration; and applying the configuration specified in the control command according to the applicable time window, thereby changing the TRX array from a default configuration to the configuration specified in the control command during the applicable time window.

[0008] According to example embodiments, a non-transitory computer-readable recording medium may recorded thereon instructions executable by a device to cause the device to perform a method including: receiving, from an RU Controller, a control command associated with a TRX array, wherein the control command may include information associated with a configuration of the TRX array and information associated with an applicable time window defining a valid period of the configuration; and applying the configuration specified in the control command according to the applicable time window, thereby changing the TRX array from a default configuration to the configuration specified in the control command during the applicable time window.

[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 a generic system configuration, according to one or more example embodiments;

[0012] FIG. 2 illustrates a diagram of an example O-RAN-based system configuration, according to one or more example embodiments;

[0013] FIG. 3 A and FIG. 3B each illustrates a diagram of an example system configuration for establishing NETCONF sessions via M-Plane interface, according to one or more example embodiments;

[0014] FIG. 4 illustrates a diagram of an example method for managing a configuration of a TRX array, according to one or more example embodiments;

[0015] FIG. 5 illustrates a diagram of an example method for applying multiple configurations to a TRX array, according to one or more example embodiments;

[0016] FIG. 6 illustrates a diagram of an example use case for managing a configuration of a TRX array, according to one or more example embodiments;

[0017] FIG. 7 illustrates a diagram of an example use case for applying a plurality of configurations of a TRX array, according to one or more example embodiments;

[0018] FIG. 8 illustrates a diagram of an example method for providing a notification message, according to one or more example embodiments;

[0019] FIG. 9 illustrates a diagram of an example method for deactivating an applied configuration based on a deactivation command, according to one or more example embodiments;

[0020] FIG. 10 illustrates a diagram of an example device in which one or more example embodiments may be implemented;

[0021] FIG. 11 illustrates a diagram of an example environment in which systems, devices, and / or methods, according to one or more example embodiments, may be implemented; and

[0022] FIG. 12 and FIG. 13 each illustrates a call flow, according to one or more example embodiments.DETAILED DESCRIPTION

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

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

[0025] 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 directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

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

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

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

[0029] In addition, the terms “transceiver array” or “TRX array” described herein may include any antenna array that includes a transmitter (tx) antenna (or tx array), a receiver (rx) antenna (or rx array), or a combination thereof. Thus, the terms “transceiver array,” “TRX array,” “antenna array,” “tx array,” “rx array,” and the like may be used interchangeably, unless explicitly described otherwise.

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

[0031] 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 Open Radio Access Network (O-RAN) Alliance, the 3rd Generation Partnership Project (3 GPP)standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, and the like. For instance, the terms “TRX,” “RU,” “RU Controller,” “M-Plane,” “NETCONF,” “YANG Module,” “RPC,” “CU,” “DU,” “SMO ,” “Near RT RIC,” and the like, as well as the associated features, operations, interfaces, and messages (e.g., edit-config command, mplane-trx-control-ant-mask-update notification, etc.) involved therein, may be interpreted as consistent with those specified in one or more technical specifications, unless being described otherwise.

[0032] As described above, TRX control is an important aspect in a telecommunication network. In this regard, the concept of implementing TRX control via the Management Plane (M-Plane) interface is introduced in the related art. Specifically, TRX control that is controlled via M-Plane (“M-Plane controlled TRX control” herein) leverages signaling and messaging over the M-Plane interface, allowing a Radio Unit (RU) Controller to command an RU to apply changes in the mask configuration of the underlying antennas (“antenna mask configuration” herein). Accordingly, the RU may selectively control and manage (e.g., activate, deactivate, etc.) one or more of the associated antenna elements or arrays (e.g., transmitter arrays, receivers arrays, etc.) organized as TRX arrays. Namely, the RU may receive a control command from the RU Controller via the M-Plane interface, and then apply the configuration (e.g., TRX array antenna mask configuration) specified in the control command, thereby achieving M-Plane controlled TRX control. Nevertheless, as detailed in the following, there is room for enhancing the TRX control in the related art.

[0033] Specifically, in the related art, TRX control is implemented such that an RU receives a control command from an associated RU Controller and then applies the configuration defined in the control command to one or more TRX arrays (or one or more portions of a TRXarray) for an undefined period of time until a subsequent control command is received by the RU. In this regard, since there is no specific mechanism or feature that enables the RU Controller to specify a duration during which a particular antenna mask configuration remains valid or applicable, when the RU Controller needs to change the antenna mask on the same TRX array(s) (e.g., change the TRX array(s) to another configuration, revert the TRX array(s) to the original configuration, etc.), the RU Controller is required to issue multiple control commands at different times, and the RU is required to receive multiple control commands and apply different antenna mask configurations at different times. This not only results in significant signaling overhead, low energy efficiency, and suboptimal network resource utilization, but the application of multiple antenna mask configurations may not be precisely and accurately executed with specific time durations, due to potential network delay, processing time required by the RU, asynchronous characteristics of M-Plane signaling that results in variation in control command transmission and execution, and the like.

[0034] Furthermore, in the related art, the mechanism for the RU to send notification messages to the RU Controller after receiving a control command is not clearly defined or standardized. Although the concept of sending a notification message to the RU Controller is introduced, the specific operations (e.g., when the notification message should be sent, etc.) remain ambiguous. This lack of detail and standardized mechanism can lead to different implementations by various vendors, resulting in inconsistent behavior across devices. On the other hand, because there are multiple ways to control a TRX array, the lack of standardized procedures for notification further complicates the process. For instance, different RUs may choose to send notifications at different stages (e.g., after receiving the control command, after a reset, after the complete application of the configuration, etc.), leading to interoperability issues and suboptimal networkresource management. This variability can increase signaling overhead and reduce the overall energy efficiency of the network, as the RU Controller may have to manage multiple asynchronous messages and uncertain timing of configuration changes.

[0035] In addition, in the related art, when the RU Controller needs to restore a TRX array to its default or original configuration, the RU Controller may send, to the associated RU, a control command that typically includes an antenna mask with all ones. However, such an approach is suboptimal for several reasons. First, if the RU Controller needs to restore the configuration of multiple TRX arrays, the RU Controller may need to determine and specify the original configuration for each array individually, which can be cumbersome and error-prone. Secondly, if the control command is not accurate (e.g., an incorrect antenna mask is included in the control command, etc.), the TRX array may be configured with an unintended setting rather than reverting to its original default state.

[0036] Example embodiments of the present disclosure, as described in the following, provide devices, systems, methods, and the like, that effectively and efficiently enhance the TRX control in the telecommunication network, and ultimately address the shortcomings of the related art systems and methods.

[0037] Specifically, example embodiments implement new messages, attributes, and parameters, which supplement those specified for the TRX control in the current version of technical specifications provided by standard organizations like the O-RAN Alliance and 3GPP. For instance, according to one or more example embodiments, a control command may include information associated with both configuration of a TRX array and an applicable time window defining a valid period of the configuration. Accordingly, the RU Controller may include information of multiple configurations associated with one or more TRX arrays in one controlcommand, and the RU may receive the control command and automatically apply the multiple configurations in a sequential manner according to the respective applicable time window.

[0038] Further, example embodiments also clarify various conditions where the RU shall provide a notification message to the RU Controller. Specifically, according to one or more example embodiments, the RU may restart the TRX array upon applying or changing the configuration of the TRX array, and then provide the notification message to the RU Controller thereafter. Additionally or alternatively, the RU may deactivate the TRX array carrier associated with the TRX array (e.g., change the [tr]x-array-carrier from ACTIVE state to INACTIVE state), and then reactivate the TRX array carrier after a period of time (e.g., change the [tr]x-array-carrier from INACTIVE state to ACTIVE state), thereby ensuring that the configuration of the TRX array is effective applied. In another example embodiments where restarting the TRX array and / or the TRX array carrier is not required, the RU may send the notification to the RU Controller after applying or changing the configuration of the TRX array.

[0039] Furthermore, example embodiments implement a dedicated deactivation command to command or instruct the RU to deactivate a configuration applied to a TRX array, instead of using a full control command as in the related art. This deactivation command includes an index array name associated with the applied configuration, enabling the RU to determine which portion of TRX array should be restored to its default configuration, without requiring the RU Controller to specify the entire antenna mask of the TRX array. Accordingly, the deactivation command of example embodiments is simpler and lighter in terms of signaling overhead and processing. In addition, since the RU is designed to process the deactivation command appropriately, issuing such a command is a more effective and reliable method for reverting the TRX array to the default configuration.

[0040] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure. 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 and Configurations

[0041] FIG. 1 illustrates a diagram of a generic system configuration 100, according to one or more example embodiments. As illustrated in FIG. 1, the system configuration 100 includes a Radio Unit (RU) 110, an RU Controller 120, and a Transceiver (TRX) array 130.

[0042] Specifically, the RU 110 may contain or manage the TRX array 130. The TRX array 130 may include multiple TRXs 130-1 to 130-N (where N is any natural number), each of which may include an antenna component for transmitting and / or receiving signals. According to example embodiments the TRXs 130-1 to 130-N may include one or more transmitter (Tx) antennas, one or more receiver (Rx) antennas, or a combination thereof. In this regard, the terms “TRX array” described herein may refer to a combination of a receiver array and a transmitter array, and may be used interchangeably with terms like “antenna array,” “[tr]x-array,” “Tx array,” “Rx array,” and the like.

[0043] The RU Controller 120 may be communicatively coupled to the RU 110 via a respective interface. As further described below, the RU Controller 120 may include a Distributed Unit (DU) and / or a Service Management and Orchestration (SMO) component. In an Open Radio Access Network (O-RAN)-based network, the RU 110 may include an O-RAN RU (O-RU), and the RU Controller 120 may include at least one of: an O-RAN DU (O-DU), an SMO, an O-RAN Central Unit (O-CU), and a Near-Real -Time (Near-RT) RAN Intelligent Controller (RIC).

[0044] Generally, the RU Controller 120 may provide a control command to the RU 110 to control the TRX array 130. Specifically, the control command may be associated with the TRX array 130 and may include information associated with a configuration of the TRX array (e.g., antenna bitmask, antenna bitmask index, etc.) and information associated with an applicable time window (e.g., start time, end time, etc.) defining a valid period of the configuration. In some example implementations, the control command may include a Remote Procedure Call (RPC) command, such as an edit-config RPC command as defined in one or more standard specifications (e.g., 0-RAN.WG4.MP, etc ). According to example embodiments, the RU Controller 120 may configure the control command according to a policy, command, instruction, and the like, received from one or more upstream components. For instance, assuming that the RU Controller 120 is an O-DU, the RU Controller 120 may receive a policy and / or a control configuration from an SMO (via an 01 interface) and configure the configuration of the TRX array based on the received policy (e.g., applying the control configuration received from the SMO once a condition defined in the policy is satisfied, etc.). Additionally or alternatively, the RU Controller 120 may receive a command from a Near RT RIC (via an E2 interface) and configure the configuration of the TRX array based on the received command.

[0045] The RU 110, upon receiving the control command from the RU Controller 120, may apply the configuration specified in the control command according to the applicable time window, thereby changing the TRX array 130 from a default configuration to the configuration specified in the control command.

[0046] According to example embodiments, the control command may include information associated with multiple configurations of one or more TRX arrays. For instance, the control command may include information associated with a first configuration and a secondconfiguration of the TRX array 130. In this regard, the applicable time window may include a first start time and a first end time associated with the first configuration, and a second start time and a second end time associated with the second configuration. As another example, the control command may include information associated with a first configuration(s) associated with a first TRX array and a second configuration(s) associated with a second TRX array, while each of the first configuration(s) and the second configuration(s) has an applicable time window (e.g., start time, end time, etc.) associated therewith. Accordingly, the RU Controller 120 may include the information of multiple configurations of one or more TRX arrays in one control command and provide the control command to the RU 110. Upon receiving the control command, the RU 110 may automatically and sequentially apply the first configuration and the second configuration, according to the respective applicable time window. For instance, if the second start time of the second configuration starts immediately after the first end time of the first configuration, the RU 110 may apply the second configuration as soon as the first configuration is deactivated. As another example, if the second start time starts after a period of time has elapsed from the first end time (e.g., the first end time is 2AM while the second start time is 3AM, etc.), the RU 110 may apply the second configuration after the period of time has elapsed (e.g., deactivate the first configuration at 2AM and apply the second configuration at 3AM, etc.). Further descriptions of example operations associated therewith are provided below with reference to FIG. 5.

[0047] According to example embodiments, upon applying the configuration specified in the control command, the RU 110 may be configured to provide a notification message to the RU Controller 120. For instance, the RU 110 may determine a timing for providing the notification message, such as: providing the notification message after a reset or restart operation, providing the notification message immediately after applying the configuration specified in the controlcommand, and the like. In some example implementations, upon determining the timing of sending the notification message, the RU 110 may (but not necessarily) inform the RU Controller 120 regarding the same. Accordingly, the RU 110 may provide the notification message according to the determined timing. In some other embodiments, the RU 110 may follow a predefined schema or mechanism to provide the notification message. For instance, the predefined schema / mechanism may be consistent and standardized across all RUs implemented in the network, and information of such predefined schema / mechanism is shared with the RU Controller 112. According to example embodiments, the RU 110 may reset or restart the TRX array (or the RU 110 may restart itself and / or all TRX arrays managed thereby, in some example implementations). Additionally or alternatively, the RU may deactivate one or more TRX array carriers associated with the TRX array and then reactivate the TRX array carrier(s) after a period of time. Accordingly, upon resetting or restarting the TRX array and / or deactivating and reactivating the TRX array carrier, the RU 110 may provide the notification message to the RU Controller. Further descriptions of operations associated therewith are provided below with reference to FIG. 8. In some example implementations, the notification, may include a mplane-trx-control-ant-mask-update notification as defined in one or more standard specifications (e.g., 0-RAN.WG4.MP, etc.).

[0048] According to example embodiments, upon applying the configuration specified in the control command, the RU 110 may be configured to receive a deactivation command from the RU Controller 120. Subsequently, the RU 110 may deactivate the applied configuration based on the deactivation command, thereby reverting the TRX array to the default configuration. The RU 110 may receive the deactivation command from the RU Controller 120 before the end time of the applied configuration, thereby enabling the deactivation of the applied configuration prior to the end time.

[0049] In this regard, the deactivation command described herein may refer to a simple, lightweight command dedicated to the deactivation of the applied configuration. Compared to the control command in the related art (which includes full configuration of the antenna mask of the TRX array), the deactivation command of the example embodiments includes information specific to the applied configuration, such as an index array name that defines the portion of the TRX array to which the configuration is applied. Accordingly, by leveraging the deactivation command, the RU 110 may determine which portion of the TRX array should be restored to its default configuration, without requiring the RU Controller 120 to specify the entire antenna mask of the TRX array as in the related art. Accordingly, the deactivation command of example embodiments is simpler and lighter in terms of signaling overhead and processing. In addition, since the RU is designed to process the deactivation command appropriately, issuing such a command is a more effective and reliable method for reverting the TRX array to the default configuration.

[0050] According to example embodiments, the RU Controller 120 may provide one deactivation command executable by the RU 110 to deactivate one or more configurations applied to one or more TRX arrays. For instance, the RU Controller 120 may provide one deactivation command to instruct the RU 110 to deactivate multiple configurations applied to the same TRX array, to deactivate a configuration applied to multiple TRX arrays, and the like. Alternatively, the RU Controller 120 may send multiple deactivation commands with corresponding index arraynames to the RU 110, thereby enabling the RU 110 to deactivate the applied configuration for multiple TRX arrays. According to example embodiments, the deactivation command may include an RPC command, and may thus be referred to as a “deactive-trx-control RPC”.

[0051] According to example embodiments, system configuration 100 in FIG. 1 may be based on Open RAN (O-RAN) architecture. FIG. 2 illustrates a diagram of an example O-RAN-based system configuration 200, according to one or more example embodiments.

[0052] As illustrated in FIG. 2, the system configuration 200 may include an O-RAN Radio Unit (O-RU 210), a TRX Array 230 that includes a plurality of TRX antennas 230-1 to 230-N (where N is a natural number), an O-RAN Distributed Unit (O-DU) 221, a Near-Real -Time (Near-RT) RAN Intelligent Controller (RIC) 222, a Service Management Orchestrator (SMO) component 223, and an O-RAN Central Unit (O-CU) 224. The O-RU 210 and TRX array 230 may be an example of the RU 110 and TRX array 130 in FIG. 1, respectively. The O-DU-221, Near-RT RIC 222, SMO 223, and O-CU 224 are example O-RAN components that may be utilized or implemented as an RU Controller (e.g., RU Controller 120). It is contemplated that one or more of the components 221-224 may also be utilized or utilized as the RU Controller in any other suitable network architecture. For instance, in a 3GPP -based network (which may or may not be O-RAN-based), a DU and / or SMO may also be utilized as the RU Controller, without departing from the scope of the present disclosure.

[0053] As illustrated in FIG. 2, each of the components 221 to 224 may communicate, directly and / or indirectly via a respective interface, with the O-RU 210, thereby instructing or guiding the O-RU 210 in controlling the TRX array 230. Specifically, the O-DU 221 may directly communicate with the O-RU 210 via an Open Fronthaul (O-FH) interface, such as an O-FH Control (C) Plane interface, an O-FH User (U) Plane interface, an O-FH Synchronization (S) Plane interface, and / or an O-FH Management (M) Plane interface. Further, the SMO 223 may directly communicate with the O-RU via an O-FH interface (e.g., an M-Plane interface) and / or an 01 interface. In addition, the O-CU 224 may communicatively couple to O-RU 210 viacommunicating with the O-DU 221 through an Fl interface. Similarly, the Near-RT RIC 222 may communicatively couple to the O-RU 210 via communicating with the O-DU 221 through an E2 interface and / or with the O-CU 224 through the E2 interface. Each of the components 221 to 224 may provide a control command (e.g., RPC command, etc.) to the O-RU to configure the underlying TRX array 230.

[0054] According to example embodiments, one or more of the components 221 to 224 in FIG. 2 may communicate with the O-RU 210 via one or more Network Configuration Protocol (NETCONF) sessions established therebetween. Generally, the O-RU 210 may host or implement a NETCONF server, while the RU Controller (e.g., O-DU 221, Near-RT RIC 222, SMO 223, and / or O-CU 224) may host or implement a NETCONF client. Accordingly, whenever the RU Controller would like to provide a control command (e.g., NETCONF RPC command, etc.) to the O-RU 210, the NETCONF client of the RU Controller may establish a communication session with the NETCONF server of the O-RU 210, and then communicate with the O-RU 210 therethrough.

[0055] According to example embodiments, the NETCONF session may, but not necessarily, be established via the M-Plane interface. FIG. 3A and FIG. 3B each illustrates a diagram of an example system configuration for establishing NETCONF sessions via the M-Plane interface, according to one or more example embodiments. Specifically, FIG. 3A illustrates a diagram of an example system configuration 301 for establishing NETCONF sessions based on a hierarchical M-Plane Model, while FIG. 3B illustrates a diagram of an example system configuration 302 for establishing NETCONF sessions based on a hybrid M-Plane Model. Examples in FIG. 3A and FIG. 3B include an RU 310, a DU 321, and an SMO 323, each of whichmay (but not necessarily) be similar to the O-RU 210, 0-DU 221, and SMO 223 in FIG. 2, respectively.

[0056] Referring first to FIG. 3 A, in the hierarchical M-Plane model, the RU 310 may be managed directly by one RU Controller and managed indirectly by one or more RU Controllers. In the example configuration 301 of FIG. 3A, the RU 310 is managed directly by the DU 321 and managed indirectly by the SMO 323. Specifically, the DU 321 may include a NETCONF Client 321-1 that communicates with a NETCONF Server 311 of the RU 310 and a NETCONF Server 321-2 that communicates with a NETCONF Client 323-1. Accordingly, the DU 321 may directly manage the RU 310 by communicating or signaling via a NETCONF session established between the NETCONF Client 321-1 of the DU 321 and NETCONF Server 311 of the RU 310. Additionally, the SMO 323 may indirectly manage the RU 310 by communicating or signaling via a NETCONF session established between the NETCONF Client 323-1 of the SMO 323 and NETCONF Server 321-2 of the DU 321, and accordingly the DU 321 may utilize the NETCONF session established between the NETCONF Client 321-1 and NETCONF Server 311 to forward the signal / message provided by the SMO 323.

[0057] According to example embodiments, the example configuration 301 may be implemented when one RU Controller (e g., DU 321) is implemented as the main or central management entity while another RU Controller (e.g., SMO 323) is implemented as the supplemental management entity. Example configuration 301 may be effective and efficient in providing centralized management of the RU 310.

[0058] Referring next to FIG. 3B, in the hybrid M-Plane model, the RU 310 may be managed directly by multiple RU Controllers, in addition to or in alternative to the indirect management provided by other RU Controlled s). In the example configuration 302 of FIG. 3B,the RU 310 may be managed directly by the DU 321 and managed indirectly by the SMO 323, as described above with reference to FIG. 3 A. In addition, the RU 310 may also be managed directly by the SMO 323. Specifically, The SMO 323 may directly communicate with the RU 310 via a NETCONF session established between the NETCONF Client 323-1 of the SMO 323 and the NETCONF Server 311 of the RU 310.

[0059] According to example embodiments, the example configuration 302 may be implemented when multiple RU Controllers (e.g., DU 321 and SMO 323) can concurrently manage the RU 310. Example configuration 301 may be effective and efficient in providing granular control of the RU 310, while increasing the flexibility and reliability of the network since multiple RU Controllers may concurrently manage the RU 310.

[0060] It is contemplated that the configurations in FIG. 3A and FIG. 3B are merely examples of possible implementation for establishing NETCONF sessions via various M-Plane models, and the scope of the present disclosure is not limited thereto. Specifically, the DU 321 and / or SMO 323 in FIG. 3 A and FIG. 3B may be replaced by any other type of RU Controller (e.g., CU / O-CU, Near-RT RIC, etc.), without departing from the scope of the present disclosure.

[0061] In view of the above, example embodiments provide systems, configurations, devices, and the like, that effectively and efficiently enhance TRX control in a telecommunication network. Specifically, the systems and devices of example embodiments include the information associated with an applicable time window of a TRX array configuration in a control command, thereby enabling the RU to automatically and sequentially apply the configuration according to the applicable time window. Such a feature is particularly useful in implementing multiple configurations of one or more TRX arrays, since the RU Controller can simply specify the intendedconfigurations and the associated implementation timing in one control command, thereby ensuring that configurations are automatically and precisely applied during the intended periods.

[0062] Further, systems and devices of example embodiments also implement clear and specific mechanisms and features for sending a notification message to the RU Controller, thereby enhancing the network’s reliability and interoperability, particularly when the network involves multiple RUs from different vendors. In addition, systems and devices off example embodiments also utilize a dedicated deactivation command to restore the default configuration of a TRX array, thereby simplifying the process (by without requiring the RU Controller to determine and specify the default configuration for each TRX array, etc.). Further, since the deactivation command is more lightweight and less error-prone, example embodiments may ensure that the default configuration of the TRX array (particularly when multiple TRX arrays are involved) is restored consistently and efficiently.Example Methods, Operations., and Use Cases

[0063] As described above with reference to FIG. 1 to FIG. 3B, the RU and RU Controller may interoperate and perform one or more methods and operations to enhance TRX control in a telecommunication network. Several example methods and operations, as well as example use cases associated therewith, are described below with reference to FIG. 4 to FIG. 9. One or more features, parameters, and operations associated with FIG. 4 to FIG. 9 may be similar to those described above with reference to FIG. 1 to FIG. 3B, thus redundant descriptions associated therewith may be omitted below for conciseness.

[0064] For descriptive purposes, the methods and operations may be mainly described as being performed by one or more specific network entities or components, although it can be understood that, in actual implementations, another related network entity(s) may performsimilar / related operations, without departing from the scope of the present disclosure. For instance, an operation of the RU receiving a control command from the RU Controller may suggest or indicate an operation of the RU Controller sending a control command to the RU, and the like.

[0065] According to example embodiments, one or more operations of an RU may be implemented in one or more devices or hardware components. For instance, the RU (or one or more associated operations) may be implemented in a device that includes a processor and a memory storage (or any other suitable storage mediums), wherein the memory storage may include computer-executable instructions which, when being executed by the processor, cause the processor to perform one or more operations of the RU.

[0066] FIG. 4 illustrates a diagram of an example method 400 for managing a TRX array (e.g., TRX array 130 / 230, etc.), according to one or more example embodiments. The operations in method 400 may be performed or implemented by an RU (e.g., RU 110 / 310, 0-RU 210, etc.) or a device that implements the RU.

[0067] Referring to FIG. 4, at operation S410, the RU may be configured to receive, from an RU Controller, a control command associated with a TRX array. The RU Controller may include at least one of: a DU (e.g., 0-DU 221, DU 321, etc.), an SMO (e.g., SMO 223, SMO 323, etc ), a CU (e.g., O-CU 224), and a Near-RT RIC (e.g., Near-RT RIC 222).

[0068] According to example embodiments, the RU may be configured to receive the control command by establishing a NETCONF session with the RU Controller via an M-Plane interface, and then receiving the control command from the RU Controller during the NETCONF session.

[0069] According to example embodiments, the RU may be configured to expose or advertise the associated capability to support energy saving by disabling some or all of theassociated antenna array elements. For instance, the RU may expose or advertise its ability to control the underlying TRX array via standardized M-Plane signaling using NETCONF session and / or Yet Another Next Generation (YANG) module (e.g., whether the RU supports the feature of MPLANE-TRX CONTROL in its o-ran-wg4. feature. yang YANG module, etc.). If this feature is supported, the RU Controller may, during the startup of the RU, establish a NETCONF session with the RU to retrieve TRX control capability information and parameters via one or more YANG module operations (e.g., o-ran-uplane-conf.yang, etc.). In some example implementations, the TRX control capability information and parameters may be categorized into the transmitter (tx) array-associated capability information and parameters, and the receiver (rx) array-associated capability information and parameters. For instance, the tx array-associated capability information and parameters may include an mplane-trx-control-txarr-capability-info container in the o-ran-uplane-conf.yang YANG module, and may include information that defines the capability of the RU in supporting TRX control for each underlying tx-array. On the other hand, the rx array-associated capability information and parameters may include a mplane-trx-control-rxarr-capability-info container in the o-ran-uplane-conf.yang YANG module, and may include information that defines the capability of the RU in supporting TRX control for each underlying rx-array. The TRX control capability information and parameters of the RU enable the RU Controller to determine the appropriate TRX control configurations and provide the control command accordingly. Further, by leveraging features and mechanisms associated with NETCONF and YANG, the exposure of RU capability information may be standardized, thereby ensuring interoperability across different RUs provided by different vendors.

[0070] According to example embodiments, the control command may include information associated with a configuration of the TRX array and information associated with anapplicable time window (may also be referred to as an “applicable-time-window” herein) defining a valid period of the configuration.

[0071] For instance, the control command may include an RPC edit-config command that includes the following parameters: array-name defining the TRX array, antenna-bitmask that indicates which antenna elements of the TRX array (e.g., tx antenna, rx antenna, etc.) should be activated or deactivated, antenna-bitmask-index that serves as an index to reference to a specific antenna mask configuration, and applicable-time-window that specifies the valid period of the configuration. The applicable-time-window parameter supplements the RPC edit-config command (which only includes array-name, antenna-bitmask, and antenna-bitmask-index in the standard specification(s)) and may be used to associate the start time and end time for which the specific TRX Control configuration is valid. This parameter may help the RU Controller (e.g., DU, etc.) in configuring the RU to apply different TRX Control antenna masks, along with their corresponding valid durations, to various antenna arrays. In some example implementations, if the applicable-time-window parameter is set to zero and the RU Controller (e.g., DU) configures the specific TRX Control configuration, it may be applicable for an undefined time period. Accordingly, by introducing the new parameter of applicable time window, the RU Controller may have the option to specify the duration for which a particular TRX control configuration is applicable or valid, thereby enabling the RU Controller to set a duration or valid period for each TRX Control configuration when the RU Controller would like to instruct the RU to sequentially apply multiple TRX Control configurations at a respective, specific time duration.

[0072] Several example configurations of TRX antenna mask configuration, of which the information may be included in the control command, are described in the following. Specifically, the TRX antenna mask configuration may be defined in a control command (e.g., RPC edit-configcommand, etc.) using an associated YANG parameter (e.g., [tr]x-array-antenna-mask-config),according to the capability information and parameter advertised or exposed by the RU.

[0073] For example, if the RU advertises or exposes mplane-supported-trx-control-maskslist to the RU Controller, the RU Controller may provide an RPC edit-config command toconfigure a specific antenna mask value (e.g., by specifying a given atenna-bitmask-index alongwith the applicable time window for the [tr]x-array using the YANG parameter [tr]x-array-antenna-mask-config). A non-limiting example of a configuration of a 32-bit tx antenna mask byspecifying the antenna-index, which may be defined in a control command (e.g., RPC edit-configcommand, etc.), is illustrated in Table 1 below.Table 1: Example Configuration of TX Antenna Mask<tx-array-antenna-mask-config><array-name> tx-array-1 < / array-name><antenna-bitmask-index> 1 < / antenna-bitmask-index>< applicable -time -window> 1 < / applicable-time-window>< start-time> 1 < / start-time>< end-time> 1 < / end-time>< / tx-array-antenna-mask-config>

[0074] As another example, if the RU does not advertise or expose mplane-supported-trx-control-masks list to the RU Controller, the RU Controller may provide an RPC edit-configcommand to configure a specific antenna bitmask value along with the applicable time windowfor the [tr]x-array using the YANG parameter [tr]x-array-antenna-mask-config. A non-limitingexample of a configuration of a 32-bit tx antenna mask by specifying the antenna-bitmask, whichmay be defined in a control command (e.g., RPC edit-config command, etc.), is illustrated in Table2 below.Table 2: Example Configuration of TX Antenna Mask<tx-array-antenna-mask-config><array-name> tx-array-1 < / array-name><antenna-bitmask >1111111100000000000000001111111 l< / antenna-bitmask >< applicable -time -window> 1 < / applicable-time-window>< start-time> 1 < / start-time>< end-time> 1 < / end-time>< / tx-array-antenna-mask-config>

[0075] In both example configurations of above Tables 1 and 2, theapplicable-time-window parameter supplements the standard configurations or parameters byspecifying how long the particular TRX control configuration remains valid. This allows the RUController to schedule different configurations sequentially, optimizing resource use and energyefficiency.

[0076] Referring still to FIG. 4, upon receiving the control command from the RUController, at operation S420, the RU may be configured to apply the configuration specified inthe control command according to the applicable time window, thereby changing the TRX arrayfrom a default configuration to the configuration specified in the control command during theapplicable time window.

[0077] FIG. 6 illustrates a diagram of an example use case 600 for managing aconfiguration of a TRX array, according to one or more example embodiments. In this exampleuse case, the RU applies a configuration associated with a TRX array (e.g., an antenna bitmask) toa TRX array, thereby changing the TRX array from a default configuration to the defaultconfiguration specified in the control command.

[0078] As illustrated in FIG. 6, a TRX array 610 may include four portions 610-1 to 610- 4, each of which may consist of a plurality of TRX antennas (e.g., tx antennas, rx antennas, or a combination thereof). An antenna bitmask 620 may include a binary representation of which each of the plurality of TRX antennas in the four portions 610-1 to 610-4 may be activated or deactivated. Each bit in the antenna bitmask 620 corresponds to a specific TRX antenna, i.e., “1” indicates that the TRX antenna may be activated (or turned on), and “0” indicates that the TRX antenna may be deactivated (or turned off). The RU may utilize the antenna bitmask 620 to selectively activate or deactivate different portions of the TRX array 610. In example use case 600, the RU applies the antenna bitmask 620 to the TRX array 610, thereby changing or transitioning the TRX array from the default configuration 610 to a new configuration 630 (which is specified by the antenna bitmask 620 contained in the control command).

[0079] According to example embodiments, the control command may include information associated with multiple configurations of one or more TRX arrays. For instance, the control command may include multiple antenna bitmasks or antenna bitmask indexes associated with one or more TRX array(s). In this regard, each of the multiple configurations may have an applicable time window associated therewith. Accordingly, the RU may sequentially and automatically apply the configuration to the associated TRX array, according to the associated applicable time window.

[0080] FIG. 5 illustrates a diagram of an example method 500 for applying multiple configurations to a TRX array, according to one or more example embodiments. One or more operations of method 500 may be part of operation S420 in method 400. Thus, it can be understood that the operations of method 500 may also be performed by an RU (or a device associated therewith), and the RU has received a control command from the RU Controller prior toperforming method 500. For descriptive purposes, it may be assumed that the control command includes information associated with a first configuration and a second configuration of a TRX array, the first configuration may have a first start time and a first end time associated therewith while the second configuration may have a second start time and a second end time associated therewith.

[0081] Referring to FIG. 5, at operation S510, the RU may be configured to apply the first configuration based on determining the first start time. Specifically, upon receiving the control command (at operation S410), the RU may continuously (or periodically) monitor a timing information (e.g., based on an internal clock, receiving scheduling information, etc.). Accordingly, based on determining that the current time matches the first start time, the RU may apply the first configuration to the TRX array. This may include, for example, activating or deactivating one or more portions (e.g., a tx antenna, an rx antenna, etc.) of the TRX array according to the control command (e.g., a configuration such as antenna bitmask or antenna bitmask index, etc.).

[0082] At operation S520, the RU may be configured to deactivate the applied first configuration based on determining the first end time. Specifically, upon applying the first configuration, the RU may continue to monitor or track the timing information. Accordingly, based on determining that the current time matches the first end time, the RU may deactivate the applied first configuration. This include, for example, reverting to the default configuration, thereby ensuring that the first configuration does not persist beyond the valid period.

[0083] At operation S530, the RU may be configured to apply the second configuration based on determining the second start time. Specifically, following the deactivation of the first configuration, the RU may continue to monitor or track the timing information. Accordingly, based on determining that the current time matches the second start time, the RU may apply the secondconfiguration to the TRX array, in a similar manner as operation S510. According to example embodiments the second start time starts immediately after the first end time. In some other example embodiments, the second start time starts after a period of time has elapsed from the first end time.

[0084] At operation S540, the RU may be configured to deactivate the applied second configuration based on determining the second end time. Specifically, upon applying the second configuration, the RU may continue to monitor or track the timing information. Accordingly, based on determining that the current time matches the second end time, the RU may deactivate the applied second configuration, in a similar manner as operation S520.

[0085] FIG. 7 illustrates a diagram of an example use case 700 for applying a plurality of configurations of a TRX array, according to one or more example embodiments. Generally, in this example use case, the RU sequentially applies a first configuration and a second configuration to the TRX array, according to the respective applicable time window.

[0086] As described above with reference to FIG. 5, the first configuration may be defined in a control command and may have an applicable time window, such as a first start time and a first end time, associated therewith. Similarly, the second configuration may be defined in the same control command and may have an applicable time window, such as a second start time and a second end time, associated therewith.

[0087] In this regard, based on determining the first start time associated with the first configuration, the RU may apply the first configuration to the TRX array, thereby changing the TRX array from a default configuration 710 to the first configuration 720. Accordingly, based on determining the first end time associated with the first configuration and / or the second start time associated with the second configuration, the RU may apply the second configuration to the TRXarray, thereby changing the TRX array from the first configuration 720 to the second configuration 730. In this regard, the RU may directly apply the second configuration to the TRX array and change the TRX array from the first configuration 720 to the second configuration 730, or may first deactivate the first configuration 720 to return to the default configuration 710 and then apply the second configuration to change the TRX array from the default configuration 710 to the second configuration 730.

[0088] In view of the above, the RU Controller may include information of multiple configurations of one or more TRX arrays in one control command and provide the control command to the RU, thereby enabling the RU to automatically and sequentially apply each of the multiple configurations at the specific timing.

[0089] According to example embodiments, upon applying the configuration specified in the control command, the RU may be configured to provide a notification message to the RU Controller. According to example embodiments, the RU may notify all notification subscribers (e.g., the RU Controller, a user such as a network manager that has subscribed to the RU, etc.) that the configuration specified in the control command (e.g., [tr]x-array specific commanded mask or antenna mask index) has been applied, using a mplane-trx-control-ant-mask-update notification.

[0090] FIG. 8 illustrates a diagram of an example method 800 for providing a notification message, according to one or more example embodiments. One or more operations of method 800 may be performed by the RU, upon applying a configuration specified in a control command provided by the RU Controller (e g., upon performing operation S420 in method 400, upon performing operations S510 and / or S530 in method 500, etc.).

[0091] Referring to FIG. 8, at operation S810, the RU may be configured to apply, to a TRX array, a configuration specified in a control command. This operation may be similar tooperation S420 in method 400, operation S510 in method 500 and / or operation S530 in method 500. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0092] Upon performing operation S810, method 800 may proceed to optional operation S820, or may proceed to operation S830. At operation 820, the RU may be configured to deactivate one or more TRX array carriers associated with the TRX array (e g., change the [tr]x-array-carrier from ACTIVE state to INACTIVE state), and then reactivate the TRX array carrier(s) after a period of time (e.g., change the [tr]x-array-carrier from INACTIVE state to ACTIVE state), thereby ensuring that the configuration of the TRX array is effective applied. According to example embodiments, in addition to or in alternative to deactivating and reactivating the TRX array carrier(s), the RU may be configured to restart or reset the TRX array. In some example implementations, the RU may be configured to restart or reset itself and / or all TRX arrays associated therewith. The restarting operation may be needed in some scenarios in order to ensure that the newly applied configuration becomes effective. For instance, in certain RU designs, multiple [tr]x-array-carriers may be mapped to a single [tr]x-array. In this case, if the TRX control configuration is applied to such a [tr]x-array, the RU may require a restart and the [tr]x-array-carriers may need to be re-activated to ensure the requested TRX control configuration is successfully applied and become active. In some other scenarios, the restarting operation may not needed. For instance, in certain RU designs, a [tr]x-array-carrer may be mapped to more than one [tr]x-array. In this case, if the TRX control configuration is applied to one of these [tr]x-array, the RU may not require to restart since the [tr]x-array carrier may not be impacted. In view of the above, operation S820 is an optional operation (and thus be illustrated in dotted lines in FIG. 8) and whether to perform operation S820 is decided by the RU based on the actual implementation requirements.

[0093] At operation S830, the RU may be configured to provide a notification message to the RU Controller. According to example embodiments, the RU may send a notification to the RU Controller (and any other notification subscribers) using an asynchronous notification (e.g., a mplane-trx-control-ant-mask-update notification, etc.).

[0094] According to example embodiments, upon applying the configuration specified in the control command, the RU may be configured to receive a deactivation command from the RU Controller and deactivate the applied configuration accordingly. For instance, the RU may deactivate the applied configuration during the applicable time window or valid period of the configuration (i.e., before the end time of the applied configuration).

[0095] FIG. 9 illustrates a diagram of an example method 900 for deactivating an applied configuration based on a deactivation command, according to one or more example embodiments. One or more operations of method 900 may be performed by the RU, upon applying a configuration specified in a control command provided by the RU Controller (e.g., upon performing operation S420 in method 400, upon performing operations S510 and / or S530 in method 500, etc.). Further, one or more operations of method 900 may be performed by the RU, upon providing a notification message to the RU Controller (e.g., upon performing operation S830 in method 800, etc.)

[0096] Referring to FIG. 9, at operation S910, the RU may be configured to apply, to a TRX array, a configuration specified in a control command. This operation may be similar to operation S420 in method 400, operation S510 in method 500, and / or operation S530 in method 500. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0097] At operation S920, the RU may be configured to receive, from the RU Controller, a deactivation command. According to example embodiments, this operation may be triggered viasending a notification message to the RU Controller (e.g., similar to operation S830 in method 800). For instance, upon receiving the notification message, the RU Controller may determine or decide to deactivate the applied configuration during the applicable time window (e.g., before the end time), and may thus provide the deactivation command to the RU.

[0098] According to example embodiments, the deactivation command may include an RPC command (e.g., deactivate-trx-control RPC) that includes an index of the name of the TRX array (e.g., array-name) to which the configuration is applied. According to example embodiments where multiple TRX arrays have been applied with the TRX control configuration (at operation S910), the deactivation command may include one deactivation command that includes a plurality of indexes of the array name of the associated TRX arrays. Alternatively, the deactivation command may include a plurality of deactivation commands (e.g., multiple deactivate-trx-control RPCs), each with its corresponding array -name index.

[0099] At operation S930, the RU may be configured to deactivate the applied configuration based on the deactivation command, thereby reverting the TRX array to the default configuration. For instance, assuming that in the default configuration, all array-elements of the TRX array are enabled, the deactivation command may include index array-name associated with the array-element (e.g., tx antenna, rx antenna, etc.) that has been deactivated at operation S910. Accordingly, at operation S930, the RU may deactivate the applied configuration by re-activating the associated array-element(s), such that all array-elements of the TRX array may be enabled. Similarly, if the TRX array includes multiple TRX arrays, the RU may deactivate the applied configuration for the multiple TRX arrays, thereby allowing them to be restored to the original or default configuration.

[0100] In view of the above, example embodiments provide methods and operations that effectively and efficiently enhance TRX control in a telecommunication network Specifically, method and operations in FIG. 4 may be automatically implemented by an RU to apply a configuration to a TRX array according to an associated applicable time window. Further, method and operations in FIG. 5 may be automatically implemented by the RU to apply multiple configurations to the TRX array in a sequential manner, according to the respective applicable time window. Furthermore, method and operations of FIG. 8 may be automatically implemented by the RU to determine the appropriate timing for providing the notification message to the RU Controller. In addition, method and operations in FIG. 9 may be automatically implemented by the RU to efficiently deactivate one or more applied configurations associated with one or more TRX arrays. Ultimately, example embodiments may efficiently and effectively reduce the signaling overhead in TRX control, enable the precise implementation of a control operation (e.g., applying a configuration, sending a notification message, deactivating an applied configuration, etc.) at the intended timing, optimize the network resources in TRX control, thereby enhancing the TRX control in the telecommunication network.

[0101] It is contemplated that, the methods, operations, advantages, and significances described above with reference to FIG. 4 to FIG. 9 are merely examples and the scope of the present disclosure should not be limited thereto. Specifically, one or more operations in FIG. 4 to FIG. 9 may be performed differently, less or additional operations may be involved, the messages or commands involved therein may include less or additional parameters, additional advantages may be achieved, and the like, without departing from the scope of the present disclosure. Further, it is contemplated that one or more of the above-described parameters, messages, and the like, maybe consistent with those specified in one or more standard specifications (e.g., O-RAN.WG4.MP), with additional parameters, attributes, and mechanisms supplemented thereto.Examples of Device

[0102] One or more components of the example embodiments (e.g., RU, RU Controller, etc ), as well as the operations associated therewith, may be implemented in one or more devices or hardware components. For instance, one or more components / operations of the network entity may be implemented in one or more devices like a server(s), and the like.

[0103] In the following, descriptions of a device in which the example embodiments may be implemented are provided. It is contemplated that one or more features, operations, and methods described above may be performed by the device. For instance, the one or more operations or methods associated with an RU may be performed by at least one processor of the device upon executing machine-readable instructions or computer-readable instructions stored in a memory or a storage component of the device.

[0104] FIG. 10 illustrates an embodiment of a device 1000. As shown in FIG. 10, the device 1000 may include a processor 1010, a memory 1020, a storage component 1030, an input component 1040, an output component 1050, a communication interface 1060, and a bus 1070.

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

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

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

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

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

[0110] Communication interface 1060 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 1060 can be a wired connection, a wireless connection, or a combinationof wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 1000 and other devices. In other words, the standard of the communication interface 1060 is not limited.[oni] The bus 1070 acts as an interconnect between the processor 1010, the memory 1020, the storage component 1030, the input component 1040, the output component 1050, and the communication interface 1060 of the device 1000. The bus 1070 may include a wired interconnection or a wireless interconnection.

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

[0113] Example embodiments of the present disclosure may be implemented in any suitable type of environment. In the following, an example environment (in which the example embodiments may be implemented) is described.

[0114] FIG. 11 illustrates a diagram of an example environment 1100 in which systems and / or methods, described herein, may be implemented. The implementation environment 1100 includes a UE (User equipment) 111, a service environment 1120, and a network 1130. The service environment 1120 includes one or more sub-environments 1121. To illustrate this, FIG. 11 shows,for convenience, examples of a 1st sub-environment 1121-1, a 2nd sub-environment 1121-2, and an N-th sub-environment 1121-N (where N is any natural number).

[0115] The UE 1110 is connected to the network 1130, and the network 1130 is connected to the service environment 1120. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 1110 and the service environment 1120 are connected via the network 1130.

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

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

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

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

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

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

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

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

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

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

[0126] The network 1130 is a network that exchanges information between the UE 1110 and the service environment 1120. The network 1130 includes one or more wired and / or wireless networks.

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

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

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

[0130] As described above, example embodiments efficiently and effectively enhance TRX control in a telecommunication network. Among others, example embodiments introduces new parameters, attributes, mechanisms, and features that supplement and enhance the TRX control as defined in one or more standard specifications. As a non-limiting example, example embodiments supplement and enhance the M-Plane controlled TRX control as defined in at least one technical specification associated with the O-RAN Alliance (e.g., O-RAN.WG4.MP), as detailed blow (the supplementations and enhancements provided by example embodiments are presented in bold):- TRX control via M-Plane messages may be used to achieve energy saving through disabling one or more 0-RU array elements for a defined or undefined period of time. Specifically, example embodiments.- For M-Plane TRX control the node contains two lists tx-array-antenna-mask-config and rx-array-antenna-mask-config, one each for specifying tx-array and rx-array configuration for TRX control respectively. The list is indexed using array-name and contains parameters antenna-bitmask, antenna-bitmask-index, and applicable- time-window. These three parameters per tx-array and rx-array list entry may be used by the O-RU controller to perform TRX Control The applicable-time-window parameter shall be used to associate the start-time and end-time for which the specific TRX Control configuration is valid. This parameter may help the O-DU in configuring the O-RUto apply the different TRX Control antenna masks, along with their corresponding valid time durations, to various antenna arrays. If the applicable-time-window is set to zero and O-DU configures the specific TRX Control configuration, it may be applicable for an undefined time period- Potential use cases:• SMO could provide policy to O-DU (O-RU Controller), where O-DU shall request O-RU to apply / activate the TRx control configurations at different point of time.• O-DU (O-RU Controller) sends an RPC edit-config to O-RU to apply more than one TRx Control configuration (antenna-bitmask-index and / or antennabit-mask or simply antenna-bit-mask) at different point of time.• There is an use case where DU wants to tell the RU that apply maskl from tO to tO+x, and then apply mask2 from tO+x to tO+y, and so on and so forth. And after every application of the mask by the O-RU, the O-DU is informed. And it is the responsibility of the O-DU to send all Os as the bf weight before and after the transition time. Multiple serial antenna masks be sent in a single m- plane command.• One m-plane message is required to activate the RF channel reconfiguration, and another is required to deactivate it (or set it to default). If a timer was associated with it, once the TO+x is over, the O-RU would reset to default value. And it is the responsibility of the O-DU to send all Os as the bf weight before and after the transition time.• If time duration is not supported, any transition from one mask to anothermask, or from one mask to default will just be another m-plane message, without requiring any “reset”. And 1’s and 0’s are absolute values, and not relative to the current existing mask.• For example, O-DU may send single RPC edit-config command to activate several TRx Control configurations at different point of time, by providing the valid time duration for each TRx Control configuration.• O-RU send a “mplane-trx-control-ant-mask-update” notification to the O-DU in the current supported m-plane, where notification sent.- In summary:1. Time duration of applicability of the mask enables:i. Multiple serial masksii. Not requiring a reset signal from O-DU to O-RU at the end of timeduration2. Notification from O-RU to O-DU when the mask transition is successfully applied.- For the case where the O-RU advertises mplane-supported-trx-control-masks list, RPC edit-config shall be used to configure a specific antenna mask value by specifying a given antenna-bitmask-index without configuration reset and carrier / O-RU restart along with the applicable-time-window for the [tr]x-array using the YANG parameter [tr]x- array-antenna-mask-config.- Configuration reset refers to the case, where switching from one antenna (TRx) control mask to another would require a reset to default configuration.Carrier restart refers to the case, where a system restart is required for the O-RU toadopt or to apply the specific antenna (TRX) control mask.EXAMPLE 1 : configuration of a given 32-bit tx antenna mask by specifying the antenna-index:<tx-array-antenna-mask-config><array-name> tx-array-1 < / array-name><antenna-bitmask-index> 1 < / antenna-bitmask-index>< applicable-time-window> 1 < / applicable-time-window>< start-time> 1 < / start-time>< end-time> 1 < / end-time>< / tx-array-antenna-mask-config>- For the case where the O-RU does not advertise mplane-supported-trx-control-masks listfor a given [tr]x-array, the RPC edit-config shall be used to configure a specific antenna¬bitmask value without configuration reset and carrier / O-RU restart along with the applicable-time-window for the [tr]x-array using the YANG parameter [tr]x-array- antenna-m ask-confi g.- Configuration reset refers to the case, where switching from one antenna (TRx) control mask to another would require a reset to default configuration.- Carrier restart refers to the case, where a system restart is required for the O-RU to adopt or to apply the specific antenna (TRX) control mask.- EXAMPLE 2: configuration of a 32-bit tx antenna mask is shown below:<tx-array-antenna-mask-config><array-name> tx-array-1 < / array-name><antenna-bitmask >1111111100000000000000001111111 l< / antenna-bitmask > < applicable-time-window> 1 < / applicable-time-window>< start-time> 1 < / start-time>< end-time> 1 < / end-time>< / tx-array-antenna-mask-config>- Because updating an antenna mask via M-Plane is an asynchronous operation, the 0-RU shall notify all notification subscribers that the [tr]x-array specific commanded mask or antenna mask index has been applied, using the mplane-trx-control-ant-mask-update notification as detailed in the Figure 20.3.2.3-1 In this process, one or more than one of the following operations may be performed:(1) When the O-DU sends an RPC command to the O-RU to apply a specific TRX Control configuration, the O-RU may undergo a reset or restart to ensure the newly applied configuration becomes effective. Once the configuration is successfully applied and activated, the O-RU may send the mplane-trx-control- ant-mask update notification to inform the O-DU of the successful activation of the requested TRX Control configuration.(2) When the O-DU sends an RPC command to apply a specific TRX Control configuration for a given antenna array Qtrjx-array) in the O-RU, which is mapped to a specific [tr]x-array-carrier, this may result in the deactivation and subsequent activation of the corresponding [tr]x-array-carrier. In such cases, the O-DU must send an «edit-config» RPC to configure the [tr]x-array-carrier as INACTIVE or ACTIVE, as the endpoints of the [tr]x-array-carrier may be affected when the associated [tr]x-array is turned off.(3) In certain O-RU designs, a [tr]x-array-carrier may be mapped to more than one [tr]x-array. If a TRX Control configuration is applied to one of these [tr]x-arrays, the [tr]x-array-carrier may or may not be impacted, depending on the specific design. In such cases, the O-RU and / or the [tr]x-array-carrier may not require deactivation, activation, or a reset to ensure the requested TRX Control configuration from the O-DU is successfully activated.(4) In certain O-RU designs, multiple [tr]x-array-carriers may be mapped to a single [tr]x-array. If a TRX Control configuration is applied to such a [tr]x-array, the O-RU may require a reset, and the [tr]x-array-carries may need to be deactivated and re-activated to ensure the requested TRX Control configuration from the O- DU is successfully applied and becomes active.(5) The O-RU may send a notification to the O-DU upon completing the activation of a specific TRX Control configuration, following one of the approaches described above.(6) When the O-RU controller (e.g., DU, etc.) sends an RPC command to configure a specific TRX Control configuration, the O-RU may apply the configuration based on its vendor-specific design. However, the O-DU may observe that the O-RU undergoes a reset or restart, or the O-DU may need to deactivate and reactivate the affected [tr]x-array-carriers before receiving the mplane-trx-control-ant- mask-update notification. This notification confirms the successful activation of the requested TRX Control configuration, which was initiated by the O-DU through the RPC <[tr]x-array-antenna-mask-config> command.(7) The O-DU (acting as the O-RU controller) should be aware of the activation statusof the specific TRX Control configuration in the O-DU.- The O-DU shall send the deactivate-trx-control RPC, including an index array-name, to deactivate the specific TRX Control configuration (i.e., antenna-bitmask) in the O- RU. This shall ensure that the O-RU is configured back to the original antenna array configuration for the specified antenna array, with all array-elements enabled. Additionally, the O-DU may send the multiple deactivate-trx-control RPCs with corresponding indexes array-name to the O-RU to deactivate the TRX Control configuration for more than one antenna arrays, allowing them to be restored to their original antenna array configuration, meaning all array-elements are enabled.

[0131] In addition to the above, example embodiments also supplement several call flows that enhance the M-Plane controlled TRX control as defined in at least one technical specification associated with the O-RAN Alliance (e.g., O-RAN.WG4.MP).

[0132] For instance, FIG. 12 illustrates an example call flow 1200 that illustrates the operations of M-plane controller TRX control configuration, according to one or more example embodiments. As illustrated in FIG. 12, the NETCONF Server (e.g., O-RU) may or may not advertise mplane-supported-trx-control-masks list. If the NETCONF Server (e.g., O-RU) advertises the mplane-supported-trx-control-masks list, the NETCONF Client (e.g., O-RU Controller) may provide a control command (e.g., RPC edit-config) that includes information of antenna-bitmask-index to the NETCONF Server (e.g., O-RU). If the NETCONF Server (e.g., 0-RU) does not advertise the mplane-supported-trx-control-masks list, the NETCONF Client (e.g., O-RU Controller) may provide a control command (e.g., RPC edit-config) that includes information of antenna-bitmask to the NETCONF Server (e.g., O-RU). Accordingly, the NETCONF Server (e.g., O-RU) may implement the configuration (e.g., antenna bit-mask(s)specified in the control command), and then provide a notification message (e.g., mplane-trx-control-ant-mask-update) to the NETCONF Client (e.g., O-RU Controller).

[0133] As another example, FIG. 13 illustrates an example call flow 1300 of an example use case, according to one or more example embodiments. In this example use case, the O-RU Controller is an O-DU that communicatively coupled to an MnS Consumer (e.g., another O-RU Controller such as an SMO, etc.) and a Near-RT RIC, and may receive policy, command, instruction, and the like, therefrom to configure or control the configuration of the TRX array (e.g., TRx Control configuration). For instance, the O-DU may receive a policy from the MnS Consumer (e.g., the SMO) via the 01 interface and configure the configuration of the TRX array (e.g., portion of the TRX array, applicable time window, etc.) based thereon. Additionally or alternatively, the O-DU may receive a control command from the Near-RT RIC via the E2 interface and configure the configuration of the TRX array based thereon. Accordingly, the O-DU may send a control command (e.g., RPC edit-config) to the O-RU via the M-Plane interface (e.g., a NETCONF session established via the M-Plane interface). The control command may include information of multiple configurations associated with the TRX array at different points of time. Accordingly, the O-RU may send a notification message (e.g., mplane-trx-control-ant-mask-update notification) to the O-DU in the currently supported M-plane.

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

[0135] 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 frompractice of the implementations.

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

[0137] The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), 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 afiber-optic cable), or electrical signals transmitted through a wire.

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

[0139] Computer-readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages.

[0140] 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 ServiceProvider). 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.

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

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

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

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

[0145] 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 Radio Unit (RU) configured to: receive, from an RU Controller, a control command associated with a transceiver (TRX) array, wherein the control command comprises information associated with a configuration of the TRX array and information associated with an applicable time window defining a valid period of the configuration; and apply the configuration specified in the control command according to the applicable time window, thereby changing the TRX array from a default configuration to the configuration specified in the control command during the applicable time window.Item [2]: The RU according to item [1], further configured to: provide, to the RU Controller and upon applying the configuration specified in the control command, a notification message.Item [3]: The RU according to one or more of items

[0001] -[2], further configured to: receive, from the RU Controller and upon applying the configuration specified in the control command, a deactivation command; and deactivate, based on the deactivation command, the applied configuration thereby reverting the TRX array to the default configuration.Item [4]: The RU according to one or more of items [l]-[3], wherein the control command comprises information associated with a first configuration of the TRX array and a second configuration of the TRX array, wherein the applicable time window comprises a first start time and a first end time associated with the first configuration, and a second start time and a second end time associated with the second configuration, and wherein the RU is configured to apply the configuration by: based on determining the first start time, applying the first configuration; uponapplying the first configuration, based on determining the first end time, deactivating the applied first configuration; upon deactivating the first configuration, based on determining the second start time, applying the second configuration; and upon applying the second configuration, based on determining the second end time, deactivating the second configuration.Item [5]: The RU according to item [2], wherein the RU is configured to provide the notification message by: upon applying the configuration specified in the control command, deactivating a TRX array carrier associated with the TRX array; upon deactivating the TRX array carrier, reactivating the TRX array carrier after a period of time; and upon reactivating the TRX array carrier, providing the notification message to the RU Controller.Item [6]: The RU according to item [3], wherein the TRX array comprises a plurality of TRX arrays.Item [7]: The RU according to one or more of items [l]-[6], wherein the RU comprises an Open Radio Access Network (O-RAN) RU (O-RU), and wherein the RU Controller comprises at least one of: an O-RAN Distributed Unit (O-DU) and a Service Management Orchestrator (SMO).Item [8]: The RU according to item [7], wherein the RU Controller comprises the O-DU, and wherein the configuration of the TRX array is configured by the RU Controller based on at least one of: a policy received from an SMO, a control configuration received from the SMO, and a control command received from a Near-RT RIC.Item [9]: The RU according to item [4], wherein the second start time starts immediately after the first end time.Item

[0010] : The RU according to item [4], wherein the second start time starts after a period of time has elapsed from the first end time.Item

[0011] : A method comprising: receiving, from an RU Controller, a control command associated with a transceiver (TRX) array, wherein the control command comprises information associated with a configuration of the TRX array and information associated with an applicable time window defining a valid period of the configuration, and applying the configuration specified in the control command according to the applicable time window, thereby changing the TRX array from a default configuration to the configuration specified in the control command during the applicable time window.Item

[0012] : The method according to item

[0011] , further comprising: providing, to the RU Controller and upon applying the configuration specified in the control command, a notification message.Item

[0013] : The method according to one or more of items

[0011] -

[0012] , further comprising: receiving, from the RU Controller and upon applying the configuration specified in the control command, a deactivation command; and deactivating, based on the deactivation command, the applied configuration thereby reverting the TRX array to the default configuration.Item

[0014] : The method according to one or more of items

[0011] -

[0013] , wherein the control command comprises information associated with a first configuration of the TRX array and a second configuration of the TRX array, wherein the applicabletime window comprises a first start time and a first end time associated with the first configuration, and a second start time and a second end time associated with the second configuration, and wherein the applying the configuration comprises: based on determining the first start time, applying the first configuration; upon applying the first configuration, based on determining the first end time, deactivating the applied first configuration; upon deactivating the first configuration, based on determining the second start time, applying the second configuration; and upon applying the second configuration, based on determining the second end time, deactivating the second configuration.Item

[0015] : The method according to item

[0012] , wherein the providing the notification message comprises: upon applying the configuration specified in the control command, deactivating a TRX array carrier associated with the TRX array; upon deactivating the TRX array carrier, reactivating the TRX array carrier after a period of time; and upon reactivating the TRX array carrier, providing the notification message to the RU Controller.Item

[0016] : The method according to item

[0013] , wherein the TRX array comprises a plurality of TRX arrays.Item

[0017] : The method according to one or more of items

[0011] to

[0016] , wherein the RU comprises an Open Radio Access Network (O-RAN) RU (O-RU), and wherein the RU Controller comprises at least one of: an O-RAN Distributed Unit (O-DU) and a Service Management Orchestrator (SMO).Item

[0018] : The method according to item

[0017] , wherein the RU Controller comprises the O-DU, and wherein the configuration of the TRX array is configured by the RUController based on at least one of: a policy received from an SMO, a control configuration received from the SMO, and a control command received from a Near-RT RIC.Item

[0019] : The method according to item

[0014] , wherein the second start time starts immediately after the first end time.Item

[0020] : A non-transitory computer-readable recording medium having recorded thereon instructions executable by a device to cause the device to perform a method comprising: receiving, from an RU Controller, a control command associated with a transceiver (TRX) array, wherein the control command comprises information associated with a configuration of the TRX array and information associated with an applicable time window defining a valid period of the configuration; and applying the configuration specified in the control command according to the applicable time window, thereby changing the TRX array from a default configuration to the configuration specified in the control command during the applicable time window.

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

AMENDED CLAIMSreceived by the International Bureau on 19 May 2026 (19.05.2026). What is claimed is:

1. A method comprising :disabling one or more array elements in a Transceiver (TRX) in a Radio Unit (RU) by using a Transceiver controller (TRX controller) via a message from a Radio Unit controller (RU controller); andsaving energy of the RU through the disabling the one or more array elements, wherein:the TRX controller supports a parameter related to a duration; andthe one or more array elements remain disabled at least during the duration indicated by the parameter.

2. The method according to claim 1, wherein:the message includes a control command associated with the TRX;the control command comprises information associated with a configuration of the one or more array elements and information associated with an applicable time window defining a valid period of the configuration; andthe configuration specified in the control command is applied according to the applicable time window, thereby changing the one or more array elements from a default configuration to the configuration specified in the control command during the applicable time window.

3. The method according to claim 2, further comprising:providing, to the RU Controller and upon applying the configuration specified in the control command, a notification message.

4. The method according to claim 2, further comprising:receiving, from the RU Controller and upon applying the configuration specified in the control command, a deactivation command; anddeactivating, based on the deactivation command, the applied configuration thereby reverting the one or more array elements to the default configuration.

5. The method according to claim 2, wherein:the control command comprises information associated with a first configuration of the one or more array elements and a second configuration of the one or more array elements;the applicable time window comprises a first start time and a first end time associated with the first configuration, and a second start time and a second end time associated with the second configuration; andthe applying the configuration comprises:based on determining the first start time, applying the first configuration;upon applying the first configuration, based on determining the first end time, deactivating the applied first configuration;upon deactivating the first configuration, based on determining the second start time, applying the second configuration; andupon applying the second configuration, based on determining the second end time, deactivating the second configuration.

6. The method according to claim 3, wherein the providing the notification message comprises:upon applying the configuration specified in the control command, deactivating a carrier associated with the one or more array elements;upon deactivating the carrier, reactivating the carrier after a period of time; andupon reactivating the carrier, providing the notification message to the RU controller.

7. The method according to claim 4, wherein:the RU comprises a plurality of TRXs; andone or more array elements in at least one of the plurality of TRXs are disabled.

8. The method according to claim 1, wherein:the RU comprises an Open Radio Access Network RU (O-RU); and the RU Controller comprises at least one of: an Open Radio Access Network Distributed Unit (O-DU) and a Service Management and Orchestration (SMO).

9. The method according to claim 8, wherein:the RU Controller comprises the O-DU; andthe configuration is configured by the RU Controller based on at least one of: a policy received from the SMO, a control configuration received from the SMO, and a control command received from aNear-RT RIC.

10. The method according to claim 5, wherein the second start time starts immediately after the first end time.

11. A Radio Unit (RU) configured to:disable one or more array elements in a Transceiver (TRX) by using a Transceiver controller (TRX controller) via a message from a Radio Unit controller (RU controller); andsave energy by disabling the one or more array elements, wherein:the TRX controller supports a parameter related to a duration; andthe one or more array elements remain disabled at least during the duration indicated by the parameter.

12. The RU according to claim 11, wherein:the message includes a control command associated with the TRX;the control command comprises information associated with a configuration of the one or more array elements and information associated with an applicable time window defining a valid period of the configuration; andthe configuration specified in the control command is applied according to the applicable time window, thereby changing the one or more array elements from a default configuration to the configuration specified in the control command during the applicable time window.

13. The RU according to claim 12, further configured to:provide, to the RU Controller and upon applying the configuration specified in the control command, a notification message.

14. The RU according to claim 12, further configured to:receive, from the RU Controller and upon applying the configuration specified in the control command, a deactivation command; anddeactivate, based on the deactivation command, the applied configuration thereby reverting the one or more array elements to the default configuration.

15. The RU according to claim 12, wherein:the control command comprises information associated with a first configuration of the one or more array elements and a second configuration of the one or more array elements;the applicable time window comprises a first start time and a first end time associated with the first configuration, and a second start time and a second end time associated with the second configuration; andthe RU is configured to apply the configuration by:based on determining the first start time, applying the first configuration;upon applying the first configuration, based on determining the first end time, deactivating the applied first configuration;upon deactivating the first configuration, based on determining the second start time, applying the second configuration; andupon applying the second configuration, based on determining the second end time, deactivating the second configuration.

16. The RU according to claim 13, wherein:the providing the notification message comprises:upon applying the configuration specified in the control command, deactivating a carrier associated with the one or more array elements;upon deactivating the carrier, reactivating the carrier after a period of time; andupon reactivating the carrier, providing the notification message to the RU controller.

17. The RU according to claim 14, wherein:the RU comprises a plurality of TRXs; andone or more array elements in at least one of the plurality of TRXs are disabled.

18. The RU according to claim 11, wherein:the RU comprises an Open Radio Access Network RU (O-RU); and the RU Controller comprises at least one of: an Open Radio Access Network Distributed Unit (O-DU) and a Service Management and Orchestration (SMO).

19. The RU according to claim 18, wherein:the RU Controller comprises the O-DU; andthe configuration is configured by the RU Controller based on at least one of: a policy received from the SMO, a control configuration received from the SMO, and a control command received from aNear-RT RIC.

20. The RU according to claim 15, wherein the second start time starts immediately after the first end time.

Images