Clarification of ambiguities in reports

Abstract

The present disclosure is related to network nodes and methods for clarifying ambiguities in reports. A method at a first network node comprises: receiving, from a second network node, a report associated with a reporting network node, wherein the reporting network node is the second network node or a third network node; and determining, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the reporting network node during a reporting period corresponding to the report.

Description

CLARIFICATION OF AMBIGUITIES IN REPORTSTechnical Field

[0001] The present disclosure is related to the field of telecommunications, and in particular, to network nodes and methods for clarifying ambiguities in reports.Background

[0002] With the commercial operation of 5th Generation (5G) telecommunication standard, Customer Service Providers (CSPs) are facing enormous challenges. Traditional operation and maintenance methods struggle to cope with the unprecedented scale, intricate network structure, escalating network traffic, and diverse dynamic business demands of 5G, impeding the advancement and efficiency enhancement of 5G applications. Artificial intelligence (AI) has seen rapid development in recent years and has found successful applications across various traditional industries. Integrating AI into 5G networks can substantially augment network automation and autonomy, transitioning from manual network configurations to intelligent, self-optimizing networks. This evolution is pivotal for facilitating the commercial deployment and iterative updates of 5G and future telecommunication technologies.

[0003] AI presents various use cases, including AI-driven Coverage Planning, Dynamic Beamforming, Self-Optimizing Network (SON) , Predictive Maintenance, Dynamic Spectrum Allocation, and User Experience-driven Energy Optimization. Large-scale AI models offer substantial opportunities for the telecommunications industry, fostering enhanced customer experiences, optimized network operations, innovative service offerings, and reinforced security measures.

[0004] However, training AI models for these use cases poses several challenges, such as ensuring data quality and quantity, safeguarding data privacy and security, navigating the complexity of network dynamics, facilitating continuous learning and adaptation, among others. Overcoming these challenges demands a multidisciplinary approach, combining expertise in machine learning, data engineering, cybersecurity, and domain-specific knowledge of the telecommunications industry. By surmounting these obstacles, telecommunication companies can unleash the full potential of AI applications to drive innovation, efficiency, and competitiveness in their operations.

[0005] In O-RAN. WG1. NESUC-R003-v02.00, which is the Network Energy Saving Use Cases Technical Report released by Open Radio Access Network (O-RAN or ORAN) Work Group 1 (WG1) and which is incorporated herein by reference in its entirety, the Machine Learning (ML) has been clearly defined with two options:

[0006] 1. Option 1: Non-Real Time (Non-RT) RAN Intelligent Controller (RIC) Deployment.

[0007] This option will allocate decision making, Model Training at the non-RT RIC, which is located at Service Management and Orchestration framework (SMO) (e.g., the SMO 100 shown in Fig. 1) . Referring to Table 1 (which is also the Table 5.2.1.3-2 from O-RAN. WG1. NESUC-R003-v02.00) , power consumption reports are collected by SMO in non-real-time manner, i.e., at intervals of 15 minutes, considering the SMO requirement to connect simultaneously with thousands of gNB s. With power consumption information, AI / ML could be correctly trained.

[0008] Table 1: AI / ML Model Training

[0009] 2.Option 2: Near-RT RIC Deployment.

[0010] Different from Option 1, the decision making is done at Near-RT RIC (e.g., Near-RT RIC 110 shown in Fig. 1) in Option 2. However, as shown by Table 2 (which is also the Table 5.2.2.3-2 from O-RAN. WG1. NESUC-R003-v02.00) , Option 2 still requires that the power consumption reports are collected by SMO in non-real-time manner at intervals of 15 minutes, to train AI / ML model correctly.

[0011] Table 2: AI / ML Model Training

[0012] In the existing 3rd Generation Partnership Project (3GPP) system design, several measurement methods are defined to report equipment status, including Cumulative Counter (CC) , Status Inspection (SI) , Gauge, Discrete Event Registration (DER) , Object Mapping (OM) , and externally defined collection methods. These methods require accuracy in measurements, encompassing representation of all occurrences, consistency in period timing for the same two events, and adherence to measurement collection periods. NEs (Network Elements) or Virtualized Network Function Manager (VNFM) can employ these measurement methods to collect data for ML model training and improvement.Summary

[0013] The current approach in both ORAN and 3GPP systems involves non-real-time data collection, with information reported to Network Management (NM) at predetermined intervals (e.g., every 900 seconds in the current 3GPP network system) .

[0014] Nevertheless, the non-real-time and long period power consumption report method is unable to capture the Radio Unit (RU) behavior when energy saving commands, whose execution period is neither same as nor synchronized with the power measurement reporting period, are dynamically changed, leading to imprecise RU status and related data.

[0015] This can lead to the transmission of inaccurate information to decision-making nodes such as Network Management (NM) or E2 Nodes, impacting the performance of AI models trained on incomplete or incorrect datasets.

[0016] To address or at least partially alleviate one or more of the above issues, some embodiments of the present disclosure are provided.

[0017] According to a first aspect of the present disclosure, a method at a first network node is provided. The method comprises: receiving, from a second network node, a report associated with a reporting network node, wherein the reporting network node is the second network node or a third network node; and determining, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the reporting network node during a reporting period corresponding to the report. Further, some other embodiments of the first aspect will be provided in the Detailed Description below.

[0018] According to a second aspect of the present disclosure, a first network node is provided. The first network node comprises: a processor; a memory storing instructions which, when executed by the processor, cause the first network node to: receive, from a second network node, a report associated with a reporting network node, wherein the reporting network node is the second network node or a third network node; and determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the reporting network node during a reporting period corresponding to the report. In some embodiments, the instructions, when executed by the processor, cause the first network node to further perform any of the methods of the first aspect.

[0019] According to a third aspect of the present disclosure, a method at a second network node is provided. The method comprises: transmitting, to a first network node, a report associated with a reporting network node, such that the first network node is enabled to determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the reporting network node during a reporting period corresponding to the report. In some embodiments, the reporting network node is the second network node or a third network node. Further, some other embodiments of the third aspect will be provided in the Detailed Description below.

[0020] According to a fourth aspect of the present disclosure, a second network node is provided. The second network node comprises: a processor; a memory storing instructions which, when executed by the processor, cause the second network node to: transmit, to a first network node, a report associated with a reporting network node, such that the first network node is enabled to determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the reporting network node during a reporting period corresponding to the report. In some embodiments, the reporting network node is the second network node or a third network node. In some embodiments, the instructions, when executed by the processor, cause the second network node to further perform any of the methods of the third aspect.

[0021] According to a fifth aspect of the present disclosure, a method at a third network node is provided. The method comprises: transmitting, to a second network node, a report associated with the third network node to be forwarded by the second network node to a first network node, such that the first network node is enabled to determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the third network node during a reporting period corresponding to the report. Further, some other embodiments of the fifth aspect will be provided in the Detailed Description below.

[0022] According to a sixth aspect of the present disclosure, a third network node is provided. The third network node comprises: a processor; a memory storing instructions which, when executed by the processor, cause the third network node to: transmit, to a second network node, a report associated with the third network node to be forwarded by the second network node to a first network node, such that the first network node is enabled to determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the third network node during a reporting period corresponding to the report. In some embodiments, the instructions, when executed by the processor, cause the third network node to further perform any of the methods of the fifth aspect.

[0023] According to a seventh aspect of the present disclosure, a computer program comprising instructions is provided. The instructions, when executed by at least one processor, cause the at least one processor to carry out any of the methods of any of the first aspect, the third aspect, and the fifth aspect.

[0024] According to an eighth aspect of the present disclosure, a carrier containing the computer program of the seventh aspect is provided. In some embodiments, the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0025] According to a ninth aspect of the present disclosure, a telecommunication system is provided. The telecommunication system comprises: a first network node of the second aspect; and a second network node of the fourth aspect and / or a third network node of the sixth aspect.

[0026] With some embodiments of the present disclosure, at least one of following advantages may be provided:

[0027] - Flexibility: By supporting multiple information reporting modes (e.g., Mode A and Mode B as described below) , the solution allows for flexibility in adapting to different network environments and requirements. This flexibility ensures that the system can accommodate various operational scenarios effectively.

[0028] - Optimized Resource Management: The inclusion of timers in Mode A allows for precise control over power-saving functions, enabling efficient resource management. This helps in optimizing energy usage and prolonging the lifespan of network components, leading to cost savings and improved sustainability.

[0029] - Enhanced Decision-Making: By providing detailed information on power-saving status changes and execution, the solution facilitates more informed decision-making by the central management entities (e.g., SMO / rApp) . This enables them to better understand the network′sperformance and make timely adjustments as needed.

[0030] - Adaptive Operation: The ability to select the most suitable reporting mode based on network conditions allows for adaptive operation, ensuring optimal performance under varying  circumstances. This adaptability enhances the system′sresilience and responsiveness to dynamic changes in the network environment.

[0031] - Improved Communication: The clear communication protocol between the RU, Distributed Unit (DU) , and SMO / rApp streamlines the process of mode selection and information exchange. This promotes efficient collaboration and coordination among different network elements, leading to smoother operation and troubleshooting.

[0032] Some embodiments of the present disclosure offer a comprehensive approach for information reporting in network infrastructure, addressing various operational challenges and enabling more efficient and effective management of resources.Brief Description of the Drawings

[0033] The foregoing and other features of the present disclosure will become more fully apparent from the following description and appended claims, taken in conjunction with the accompanying drawings. Understanding that these drawings depict only several embodiments in accordance with the disclosure and therefore are not to be considered limiting of its scope, the disclosure will be described with additional specificity and detail through use of the accompanying drawings.

[0034] Fig. 1 is a diagram illustrating an exemplary telecommunication network in which network nodes may be operated according to an embodiment of the present disclosure.

[0035] Fig. 2A and Fig. 2B are diagrams illustrating exemplary scenarios where ambiguous reports are provided.

[0036] Fig. 3 is a diagram illustrating exemplary ambiguous reports that cannot be distinguished by the receiving network nodes.

[0037] Fig. 4A and Fig. 4B are diagrams illustrating different exemplary power consumptions and Key Performance Indicator (KPI) impacts associated with different ambiguous reports shown in Fig. 3, respectively.

[0038] Fig. 5A through Fig. 5F are diagrams illustrating how ambiguous reports are clarified according to some embodiments of the present disclosure.

[0039] Fig. 6 is a diagram illustrating an exemplary procedure for report mode selection according to an embodiment of the present disclosure.

[0040] Fig. 7 is a flow chart illustrating an exemplary method at a first network node according to an embodiment of the present disclosure.

[0041] Fig. 8 is a flow chart illustrating an exemplary method at a second network node according to an embodiment of the present disclosure.

[0042] Fig. 9 is a flow chart illustrating an exemplary method at a third network node according to an embodiment of the present disclosure.

[0043] Fig. 10 schematically shows an embodiment of an arrangement which may be used in network nodes according to an embodiment of the present disclosure.Detailed Description

[0044] Hereinafter, the present disclosure is described with reference to embodiments shown in the attached drawings. However, it is to be understood that those descriptions are just provided for illustrative purpose, rather than limiting the present disclosure. Further, in the following, descriptions of known structures and techniques are omitted so as not to unnecessarily obscure the concept of the present disclosure.

[0045] Those skilled in the art will appreciate that the term “exemplary” is used herein to mean “illustrative, ” or “serving as an example, ” and is not intended to imply that a particular embodiment is preferred over another or that a particular feature is essential. Likewise, the terms “first” and “second, ” and similar terms, are used simply to distinguish one particular instance of an item or feature from another, and do not indicate a particular order or arrangement, unless the context clearly indicates otherwise. Further, the term “step, ” as used herein, is meant to be synonymous with “operation” or “action. ” Any description herein of a sequence of steps does not imply that these operations must be carried out in a particular order, or even that these operations are carried out in any order at all, unless the context or the details of the described operation clearly indicates otherwise.

[0046] Conditional language used herein, such as ″can, ″ ″might, ″ ″may, ″ ″e.g., ″ and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and / or states. Thus, such conditional language is not generally intended to imply that features, elements and / or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and / or states are included or are to be performed in any particular embodiment. Also, the term ″or″ is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term ″or″ means one, some, or all of the elements in the list. Further, the term ″each, ″ as used herein, in addition to having its ordinary meaning, can mean any subset of a set of elements to which the term ″each″ is applied.

[0047] The term “based on” is to be read as “based at least in part on. ” The term “one embodiment” and “an embodiment” are to be read as “at least one embodiment. ” The term “another embodiment” is to be read as “at least one other embodiment. ” Other definitions, explicit and implicit, may be included below. In addition, language such as the phrase ″at least one of X, Y and Z, ″ unless specifically stated otherwise, is to be understood with the context as  used in general to convey that an item, term, etc. may be either X, Y, or Z, or a combination thereof.

[0048] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limitation of example embodiments. As used herein, the singular forms “a” , “an” , and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof. It will be also understood that the terms “connect (s) , ” “connecting” , “connected” , etc. when used herein, just mean that there is an electrical or communicative connection between two elements and they can be connected either directly or indirectly, unless explicitly stated to the contrary.

[0049] Of course, the present disclosure may be carried out in other specific ways than those set forth herein without departing from the scope and essential characteristics of the disclosure. One or more of the specific processes discussed below may be carried out in any electronic device comprising one or more appropriately configured processing circuits, which may in some embodiments be embodied in one or more application-specific integrated circuits (ASICs) . In some embodiments, these processing circuits may comprise one or more microprocessors, microcontrollers, and / or digital signal processors programmed with appropriate software and / or firmware to carry out one or more of the operations described above, or variants thereof. In some embodiments, these processing circuits may comprise customized hardware to carry out one or more of the functions described above. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

[0050] Although multiple embodiments of the present disclosure will be illustrated in the accompanying Drawings and described in the following Detailed Description, it should be understood that the disclosure is not limited to the disclosed embodiments, but instead is also capable of numerous rearrangements, modifications, and substitutions without departing from the present disclosure that as will be set forth and defined within the claims.

[0051] Further, please note that although the following description of some embodiments of the present disclosure is given in the context of O-RAN, the present disclosure is not limited thereto. In fact, as long as clarification of ambiguities in reports is involved, the inventive concept of the present disclosure may be applicable to any appropriate communication architecture, for example, to Global System for Mobile Communications (GSM)  / General Packet Radio Service (GPRS) , Enhanced Data Rates for GSM Evolution (EDGE) , Code Division Multiple Access (CDMA) , Wideband CDMA (WCDMA) , Time Division -Synchronous CDMA (TD-SCDMA) ,  CDMA2000, Worldwide Interoperability for Microwave Access (WiMAX) , Wireless Fidelity (Wi-Fi) , Long Term Evolution (LTE) , 5G New Radio (NR) , etc. Therefore, one skilled in the arts could readily understand that the terms used herein may also refer to their equivalents in any other infrastructure. For example, the term “terminal device” used herein may refer to a UE, a mobile device, a mobile terminal, a mobile station, a user device, a user terminal, a wireless device, a wireless terminal, an Internet of Things (IoT) device, a vehicle, or any other equivalents. For another example, the term “network node” used herein may refer to a base station, a base transceiver station, an access point, a hot spot, a NodeB (NB) , an evolved NodeB (eNB) , a gNB, a network element, a network node, a network function, an access network (AN) node, or any other equivalents.

[0052] Fig. 1 is a diagram illustrating an exemplary telecommunication network 10 in which network nodes may be operated according to an embodiment of the present disclosure. Although the telecommunication network 10 is a network defined in the context of O-RAN, the present disclosure is not limited thereto. In some other embodiments, the network 10 may comprise additional nodes, less nodes, or some variants of the existing nodes shown in Fig. 1. For example, in a network with the 5G architecture, some entities (e.g., a gNB-CU-CP, a gNB-CU-UP, an Operation, Administration, and Maintenance (OAM) server) may perform the same or similar functions as those (e.g., O-CU-CP 120, O-CU-UP 125, SMO 100) shown in Fig. 1. For another example, in a network with a mixed O-RAN / 5G architecture, some of its entities may be same as those shown in Fig. 1, and others may be different.

[0053] Fig. 1 provides a high-level view of the O-RAN architecture. It shows that the interfaces -A1, O1, Open Fronthaul (FH) M-plane, and 02 -connecting SMO (Service Management and Orchestration) framework 100 to O-RAN Network Functions and to O-Cloud 145. As depicted in this figure, the O-Cloud 145 may include the O-Cloud Notification interface which is available for the relevant O-RAN Network Functions (NFs) (e.g., Near-RT RIC 110, O-CU-CP 120, O-CU-UP 125, and O-DU 130) to receive O-Cloud related notifications.

[0054] As shown in Fig. 1, all O-RAN NFs, except O-RU 135, may be managed via the O1 interface to the authorized SMO framework (e.g., SMO 100 shown in Fig. 1) . The O1 interface may expose management services for the O-RAN NFs that are managed individually or together. The Open Fronthaul M-plane interface, between SMO 100 and O-RU 135, may support the O-RU management in hybrid mode. O-RAN NFs instantiated on the O-Cloud 145 may utilize the APIs exposed by the Accelerator Abstraction Layer (AAL) .

[0055] The Near-RT RIC 110 shown in Fig. 1 may provide RAN analytics information services via the Y1 service interface. These services can be consumed by Y1 consumers 115 after mutual authentication and authorization by subscribing to or requesting the RAN analytics information  via the Y1 service interface. Y1 consumers 115's role can be played by entities which are within a Public Land Mobile Network (PLMN) trusted domain. Y1 consumers 115 outside the PLMN trusted domain may use Y1 services in a secure manner via an exposure function, e.g., as in 3GPP TS 23.501, Clause 5.20, which is incorporated herein by reference in its entirety.

[0056] Within the logical architecture of O-RAN as shown in Fig. 1, the radio side may include Near-RT RIC 110, O-CU-CP 120, O-CU-UP 125, O-DU 130, and O-RU 135. The E2 interface may connect O-eNB 140 to Near-RT RIC 110. Although not shown in this figure, O-eNB 140 may support O-DU 130 and O-RU 135 with an Open Fronthaul interface between them. The Near-RT RIC 110 shown in Fig. 1 may support the Y1 service interface towards Y1 consumers 115.

[0057] As also shown in Fig. 1, the management side may include SMO Framework 100 containing a Non-RT-RIC function 105. The O-Cloud 145, on the other hand, may be a cloud computing platform comprising a collection of physical infrastructure nodes that meet O-RAN requirements to host the relevant O-RAN NFs (such as Near-RT RIC 110, O-CU-CP 120, O-CU-UP 125, and O-DU 130 etc. ) , the supporting software components (such as Operating System, Virtual Machine Monitor, Container Runtime, etc. ) , and the appropriate management and orchestration functions.

[0058] As shown in Fig. 1, the O-RU 135 may provide the Open Fronthaul M-Plane interface to authorized O-DU (e.g., O-DU 130 shown in Fig. 1) in hierarchical mode, or to authorized O-DU and SMO (e.g., SMO 100 shown in Fig. 1) in hybrid mode.

[0059] As mentioned earlier, the non-real-time and long period power consumption report method (e.g., the methods discussed with reference to Table 1 and Table 2) is unable to capture the RU behavior when energy saving commands, whose execution period is neither same as nor synchronized with the power measurement reporting period, are dynamically changed, leading to imprecise RU status and related data. This can lead to the transmission of inaccurate information to decision-making nodes such as NM or E2 Nodes (e.g., Near-RT RIC 110, O-DU 130, etc. ) , impacting the performance of AI models trained on incomplete or incorrect datasets.

[0060] Further, in the context of Option 1 mentioned above, SMO (e.g., SMO 100 shown in Fig. 1) may face challenges in distinguishing changes in power-saving status (e.g., sleep mode or SM) within a reporting period. Consequently, SMO 100 may obtain inaccurate information from the reports, resulting in the generation of wrong ML model. An exemplary scenario where a change of power-saving status occurs within an RU reporting period is shown in Fig. 2A.

[0061] As shown in Fig. 2A, an RU (e.g., O-RU 135 shown in Fig. 1) may send its reports to SMO (e.g., SMO 100 shown in Fig. 1) and / or DU (e.g., O-DU 130 shown in Fig. 1) at the end of each reporting period, e.g., RU Report #N, RU Report #N+1, RU Report #N+2, etc., and each  report may contain information or data collected during the corresponding reporting period. As also shown in Fig. 2A, the reports may be transmitted from RU to DU via the Open FH M-Plane interface, and then optionally to SMO via the O1 interface. However, the ambiguity issue also arises in the case where the reports are transmitted from RU to SMO via the Open FH M-plane directly.

[0062] As also shown in Fig. 2A, the SMO and / or the DU may instruct the RU to enter into a specific power saving mode, e.g., by transmitting a Power Saving Start command. Similarly, when the transmission is initiated by SMO, the transmission of the Power Saving Start command may be performed directly from SMO to RU or indirectly from SMO to RU via DU. Such a power saving mode change may be a change from a power saving mode to another power saving mode with a different sleep depth, or from a no-sleep mode to a power saving mode or vice versa.

[0063] Referring back to Fig. 2A, the SMO and / or the DU instruct RU to switch its power saving mode from Sleep Mode 1 (SM1) to Sleep Mode 2 (SM2) during RU's reporting period #N+1. In such a case, the RU report #N+1 containing the information / data collected during the reporting period #N+I involve information / data collected for RU in different power saving modes. However, SMO and / or DU are not aware of such an ambiguity (or a mix of RU information / data in multiple power saving modes) in the RU report #N+I because there is no information in the RU report #N+I per se or anywhere else from which the ambiguity can be identified.

[0064] Moreover, with Option 2, the situation of incorrect information becomes more severe. DU (e.g., O-DU 130 shown in Fig. 1) may directly alter the power-saving status multiple times within a single reporting period. Given the limitations of the legacy reporting solution, such detailed information cannot be accurately reflected in the reports, rendering these reports ambiguous. An exemplary scenario where multiple changes of power-saving status occur within an RU reporting period is shown in Fig. 2B.

[0065] Similar to Fig. 2A, SMO and / or DU instruct RU to switch its power saving mode from SM1 to SM2 during the RU's reporting period #N+1. After that, DU further instruct RU to switch its powering saving mode from SM2 to SM3 (e.g., for a deeper sleep) . In such a case, the RU report #N+1 containing the information / data collected during the reporting period #N+1 involve information / data collected for RU in different power saving modes (e.g., SM1, SM2, SM3) . Similar to Fig. 2A, SMO and / or DU are not aware of such an ambiguity in the RU report #N+1.

[0066] Furthermore, the current implementation defines Report Output Periods (ROPs) (or reporting periods) with 15-minute intervals, each containing 900 seconds of data. However, this  method lacks time sequence information, rendering it unable to differentiate between different power-saving scenarios. As a result, critical details such as MIMO sleep switch information and execution time sequence are missing. Fig. 3 is a diagram illustrating exemplary ambiguous reports that cannot be distinguished by the receiving network nodes.

[0067] As shown in Fig. 3, a cumulative counter, pmMimoSleepTime, which is defined in the current standard, cannot reflect differences in RU behaviors for difference cases. For example, all three cases shown in Fig. 3 have the same value of 450 seconds for the cumulative counter. However, for Case 1, the first half of the ROP corresponds to a period during which MIMO sleep is on, while the second half of the ROP corresponds to a period during which MIMO sleep is off. By contrast, for Case 2, the first half of the ROP corresponds to a period during which MIMO sleep is off, while the second half of the ROP corresponds to a period during which MIMO sleep is on; for Case 3, the middle half of the ROP corresponds to a period during which MIMO sleep is on, while periods on both ends correspond to periods during which MIMO sleep is off.

[0068] RU will behave differently for these different cases. Fig. 4A and Fig. 4B show the different behaviors in term of power consumption and the KPI impacts when they have the same pmMimoSleepTime Counters. The current cumulative counter approach fails to reflect these differences accurately. In other words, an ML / AI model that is trained based on such information for one case (e.g., Case 1) may not correctly handle another case (e.g., Case 3) .

[0069] There is a problem with missing power-saving status updates when the RU executes or changes the power-saving status midway through each data reporting period. This issue, combined with the non-realtime reporting method, leads to ambiguous results that can mislead AI decision-making models during training, potentially resulting in incorrect power-saving decisions.

[0070] Besides the example of pmMimoSleepTime, other information such as the following also face similar issues:

[0071] Configuration Management (CM) Data: sleepEndTime, sleepEndTimeApplied, sleepMode, sleepPowerControl, sleepStartTime, sleepStartTimeApplied, sleepState, switchDownMonitorDurTimer, switchDownPrbThreshold, switchDownRrcConnThreshold, switchUpMonitorDurTimer, switchUpPrbThreshold, switchUpRrcConnThreshold;

[0072] Performance Management (PM) Data: pmPrbUsedMimoLayersDlDistr, pmPrbUsedMimoLayersUlDistr, pmPrbUtilDlDistr, pmPrbUtilUlDistr.

[0073] These information also suffer from the same problem of not accurately reflecting time-sequence information due to the reliance on cumulative counting methods. This issue may extend beyond the MIMO sleep function to all counters related to hysteresis ON / OFF states,  where changes within a reporting period cannot be precisely captured, leading to ambiguous or inaccurate reports.

[0074] In some embodiments, an ambiguous report means one or more of following issues: this report does not contain the precise radio status; only a part of the data / information is correct; and it cannot distinguish the difference between variant status. In some embodiments, an unambiguous report means that this report includes fully correct radio status and related information. In some embodiments, an ambiguous report may be a report containing data collected in more than one of operating states (e.g., more than one of power saving states) for a corresponding reporting network node (e.g., RU) during a reporting period corresponding to the report. In some embodiments, an unambiguous report may be a report containing data collected in only one operating state (e.g., only one power saving state) for a corresponding reporting network node (e.g., RU) during a reporting period corresponding to the report.

[0075] To address or at least partially alleviate one or more of the above issues, some embodiments of the present disclosure are provided.

[0076] In some embodiments, two alternative modes of new information reporting mechanism are introduced to address the ambiguity of power consumption measurement.

[0077] - Mode A or the Active Timer Mode, utilizes predefined timers within Radio Units (RUs) , helping the SMO / rAPP to resolve power consumption report ambiguity. In some embodiments, these timers may be transmitted alongside capability reports and managed autonomously by SMO.

[0078] - Mode B or the Real-time Monitoring Mode, involves real-time monitoring and reporting of power-saving status changes by RUs, providing more precise information at the cost of increased computational and storage demands.

[0079] In some embodiments, two modes may be selected by SMO / rApp according to RU capability and / or its own computation cost (e.g., when RU could support both modes) .

[0080] In some embodiments, a novel approach is proposed to address ambiguity in power-saving information reporting. In some embodiments, some components and steps may include: 1. Introduction of two distinct information reporting modes: Mode A (Active Timer Mode) and Mode B (Real-time Monitoring Mode) , providing flexibility and adaptability in handling different types of power-saving data; 2. Utilization of predefined timers within Radio Units (RUs) to mitigate ambiguity in power-saving information transmission, ensuring accurate reporting of power-saving activities and operations; 3. Real-time monitoring and reporting of power-saving status changes by RUs in Mode B, offering more precise information while considering the increased computational and storage demands. These components and steps may  address or at least partially alleviate the problem of ambiguous power-saving information reporting.

[0081] With some embodiments of the present disclosure, at least one of following advantages may be provided:

[0082] - Flexibility: By supporting multiple information reporting modes (e.g., Mode A and Mode B as described below) , the solution allows for flexibility in adapting to different network environments and requirements. This flexibility ensures that the system can accommodate various operational scenarios effectively.

[0083] - Optimized Resource Management: The inclusion of timers in Mode A allows for precise control over power-saving functions, enabling efficient resource management. This helps in optimizing energy usage and prolonging the lifespan of network components, leading to cost savings and improved sustainability.

[0084] - Enhanced Decision-Making: By providing detailed information on power-saving status changes and execution, the solution facilitates more informed decision-making by the central management entities (SMO / rApp) . This enables them to better understand the network′sperformance and make timely adjustments as needed.

[0085] - Adaptive Operation: The ability to select the most suitable reporting mode based on network conditions allows for adaptive operation, ensuring optimal performance under varying circumstances. This adaptability enhances the system′sresilience and responsiveness to dynamic changes in the network environment.

[0086] - Improved Communication: The clear communication protocol between the RU, Distributed Unit (DU) , and SMO / rApp streamlines the process of mode selection and information exchange. This promotes efficient collaboration and coordination among different network elements, leading to smoother operation and troubleshooting.

[0087] Some embodiments of the present disclosure offer a comprehensive approach for information reporting in network infrastructure, addressing various operational challenges and enabling more efficient and effective management of resources.

[0088] To resolve power consumption measurement ambiguity issue, some embodiments of the present disclosure introduce two information reporting modes. In some embodiments, either Mode A or Mode B is used, for example, when only one of them is supported by RU / DU / SMO while the other is not supported by at least one of RU / DU / SMO. In some other embodiments, the two modes can be used together (for example, in an alternative manner) when both of the modes are supported. For example, sometimes Mode A is used, and sometimes Mode B is used, e.g., depending on the capabilities and / or loads of SMO / DU / RU.

[0089] Mode A: Active Timer Mode

[0090] In some embodiments, RU (e.g., O-RU 135 shown in Fig. 1) may report several timer settings to SMO (e.g., SMO 100 shown in Fig. 1) and / or DU (e.g., O-DU 130 shown in Fig. 1) , which could help DU / SMO to handle ambiguity. In this mode, several timers may be defined for the power saving functions:

[0091] signifies the maximum commencement timer for sleep mode (SM) #n or SM n. RU assures that the activation operation for power-saving (SM n) can be completed within this timeframe.

[0092] signifies the maximum cessation timer for SM n. RU ensures that the power-saving function can halt or be stopped within this timeframe.

[0093] These two timers are associated with a specific SM n.

[0094] In some embodiments, regarding to the no-sleep case, it may be considered as the initial sleep mode (SM0: where the timers associated therewith are 0) . In some embodiments, for the sleep mode changes from an old SM to a new SM, the total transition time may be calculated as

[0095] For example, when the sleep mode of RU is changed from SM 0 (or the no-sleep mode) to SM 1, then the transition time may be calculated as:

[0096] For another example, when the sleep mode of RU is changed from SM 1 to SM 2, then the transition time may be calculated as:

[0097] For yet another example, when the sleep mode of RU is changed from SM 2 to SM 0, then the transition time may be calculated as:

[0098] In some embodiments, these two timers can be determined from Lab / Factory tests utilizing the distribution measurement results. In some embodiments, these two timers may be stored in the RU according to its capabilities and transmitted along with the RU capability report to SMO / DU. In some embodiments, the values of these timers may vary among different RUs and / or power-saving functions.

[0099] In some embodiments, instead of reporting timer settings, RU may report or indicate, to SMO and / or DU, a table of transition times between SMs, which could also help DU / SMO to handle ambiguity. An exemplary Table 3 of transition times may be provided below.

[0100] Table 3: Transitions times

[0101] For a mode change, RU / DU / SMO may look up in Table 3 to find a corresponding transition time directly, rather than a calculation of Further, a transition time provided in Table 3 could be shorter than that derived from the timer based calculation. This is because, for example, when a radio chain in RU is required to be turned off in both SM 1 and SM 2, the radio chain may be kept in the off state during the change from SM 1 to SM 2, resulting in a shorter transition time than that is calculated from the timer based calculation, which suggests that the change from SM 1 to SM 2 is implemented by switching from SM 1 to SM 0 and then from SM 0 to SM2 and therefore the radio chain is turned on and then turned off.

[0102] Next, some exemplary cases in Mode A will be described in details with reference to Fig. 5A through Fig. 5E. For ease of understanding, only two power saving modes / statuses / states are discussed with reference to Fig. 5A through Fig. 5D, that is, SM 0 (or no-sleep mode or RU Power Saving Off) and SM 1 (or SM or RU Power Saving On) . However, the present disclosure is not limited thereto. In some other embodiments, the method shown in Fig. 5A through Fig. 5D are also applicable to embodiments with more than two modes involved.

[0103] In some embodiments, RU may transmit the data at the conclusion of each reporting period. Thus, both DU and SMO / rApp may receive the report #N during the reporting period #N+1. In some embodiments, SMO may send the power saving start command or DU may directly decide to execute power saving. They may issue the command at any time without being constrained by the reporting periods.

[0104] In some embodiments, RU may receive the power saving start command and RU may start to enter the requested power saving mode. In some embodiments, RU may incur a predetermined time cost (Power Saving Start timer ) or Power Saving Stop timer  ) ) which correlates with sleep depth, RU hardware, and / or software implementation, etc. Since there are only two power saving modes are discussed here and one of them is no-sleep mode,  and are shown as Tstart_SM and Tstop_SM, respectively in Fig. 5A through Fig. 5D, and they can be used interchangeably, respectively.

[0105] As shown in Fig. 5A, in the RU Report #N+1, RU may have more than one power saving mode, resulting in an ambiguous report #N+1. However, this ambiguity can be identified by SMO and / or DU by using the timers. In some embodiments, DU and / or SMO may calculate the power saving start command sent time + or power saving stop command sent time + (e.g., as shown in Fig. 5A and Fig. 5B) . In some embodiments, DU and / or SMO may calculate the power saving change indication received time -  (e.g., as shown in Fig. 5C and Fig. 5D) .

[0106] There may be following cases:

[0107] - Case 1: Power Saving Command (Start or Stop) + or does not transcend the boundary between reporting periods.

[0108] - Case 2: Power Saving Command (Start or Stop) + or transcends the boundary between reporting periods.

[0109] - Case 3: Power saving change indication received time - does not transcend the boundary between reporting periods.

[0110] - Case 4: Power saving change indication received time - transcends the boundary between reporting periods.

[0111] Next, the four cases will be discussed in detail with reference to Fig. 5A through Fig. 5D, respectively.

[0112] Case 1: Power Saving Command (Start or Stop) + or does not transcend the boundary between reporting periods.

[0113] As shown in Fig. 5A, DU / SMO may send a Power Saving Command (e.g., a power saving start command) to RU in the reporting period #N+1. In such a case, DU / SMO may determine that the report #N+1 is an ambiguous report by determining that a time interval defined by the time when the command is sent and the time plus is located only within the reporting period #N+1.

[0114] Similarly, DU / SMO may send a Power Saving Command (e.g., a power saving stop command) to RU in the reporting period #N+3. In such a case, DU / SMO may determine that the report #N+3 is an ambiguous report by determining that another time interval defined by the time when the command is sent and the time plus is located only within the reporting period #N+3.

[0115] In some embodiments, when any of such intervals is overlapped with a reporting period, then the report corresponding to this reporting period is an ambiguous report. On the other hand, the reports #N and #N+2 are unambiguous reports because their corresponding reporting periods are not overlapped with any of such intervals.

[0116] Case 2: Power Saving Command (Start or Stop) + or transcends the boundary between reporting periods.

[0117] As shown in Fig. 5B, DU / SMO may send a Power Saving Command (e.g., a power saving start command) to RU in the reporting period #N. In such a case, DU / SMO may determine that both the reports #N and #N+1 are ambiguous reports by determining that a time interval defined by the time when the command is sent and the time plus is located not only within the reporting period #N but also within the reporting period #N+1 (in other words, the interval transcends the boundary between the reporting periods #N and #N+1) . In some embodiments, when such an interval is overlapped with two or more reporting periods, then the reports corresponding to these reporting periods are all ambiguous reports.

[0118] Further, similar to Fig. 5A, DU / SMO may send a Power Saving Command (e.g., a power saving stop command) to RU in the reporting period #N+3. In such a case, DU / SMO may determine that the report #N+3 is an ambiguous report by determining that another time interval defined by the time when the command is sent and the time plus is located only within the reporting period #N+3.

[0119] On the other hand, the report #N+2 is an unambiguous report because its corresponding reporting period is not overlapped with an of such intervals.

[0120] Case 3: Power saving change indication received time - does not transcend the boundary between reporting periods.

[0121] In this case, RU may autonomously change its power saving mode. In some embodiments, RU may modify its power saving mode due to RU limitations, such as low temperature, reliability impact, etc. In some embodiments, RU may decide whether to exit the power saving mode (e.g., from SM 1 to SM 0) or transition to different power saving states (e.g., from SM1 to SM 2) . In some embodiments, following any changes in power saving function states, RU may report its status change.

[0122] As shown in Fig. 5C, RU may send a Power Saving Change Indication to DU / SMO in the reporting period #N+2 after it changes its power saving mode. In such a case, DU / SMO may determine that the report #N+2 is an ambiguous report by determining that a time interval defined by the time when the indication is received and the time minus is located only within the reporting period #N+2 (in other words, the interval does not transcend the boundary between the reporting periods #N+2 and #N+3) . In some embodiments, when such an interval is overlapped with a reporting period, then the report corresponding to this reporting period is an ambiguous report. On the other hand, the report #N+3 is an unambiguous report because its corresponding reporting period is not overlapped with such an interval.

[0123] Further, similar to Fig. 5B, DU / SMO may send a Power Saving Command (e.g., a power saving start command) to RU in the reporting period #N. In such a case, DU / SMO may determine that the reports #N and #N+1 are ambiguous reports by determining that another time interval defined by the time when the command is sent and the time plus is located not only within the reporting period #N but also within the reporting period #N+1.

[0124] Case 4: Power saving change indication received time - transcends the boundary between reporting periods.

[0125] Similar to Case 3, RU may autonomously change its power saving mode and send an indication to DU / SMO.

[0126] As shown in Fig. 5D, RU may send a Power Saving Change Indication to DU / SMO in the reporting period #N+3 after it changes its power saving mode. In such a case, DU / SMO may determine that both the reports #N+2 and #N+3 are ambiguous reports by determining that a time interval defined by the time when the indication is received and the time minus is located not only within the reporting period #N+3 but also within the reporting period #N+2 (in other words, the interval transcends the boundary between the reporting periods #N+2 and #N+3) . In some embodiments, when such an interval is overlapped with more than one reporting period, then the reports corresponding to these reporting periods are all ambiguous reports. On the other hand, none of the reports #N through N+3 is an unambiguous report because all of their corresponding reporting periods are overlapped with such intervals (including the interval defined for the power saving start command sent in the reporting period #N and the interval defined for the power saving change indication sent in the reporting period N+3) .

[0127] Fig. 5E shows a case where more than two power saving modes are involved. As shown in Fig. 5E, assuming RU is in SM 0 before the reporting period #N+1, DU / SMO may send a Power Saving Command (e.g., a power saving start command for SM 1) to RU in the reporting period #N+1. In such a case, DU / SMO may determine that the report #N+1 is an ambiguous report by determining that a time interval defined by the time when the command is sent and the time plus  (or when ) is located only within the reporting period #N+1. Similarly, DU / SMO may send a Power Saving Command (e.g., another power saving start command for SM 2, which also means a power saving stop command for SM 1) to RU in the reporting period #N+3. In such a case, DU / SMO may determine that the report #N+3 is an ambiguous report by determining that another time interval defined by the time when the command is sent and the time plus is located only within the reporting period #N+3.

[0128] Although the timer-based approach is discussed above, the present disclosure is not limited thereto. In some other embodiments, a table-based approach may be used alternatively or  additionally. For example, DU / SMO may determine that the report #N+3 is an ambiguous report by determining that a time interval defined by the time when the command is sent and the time plus in the table (e.g., Table 3) is located only within the reporting period #N+3.

[0129] In some embodiments, after determining whether or not a report is ambiguous, DU / SMO may have several options, including abandoning an ambiguous report, directly using the ambiguous information (e.g., with a label indicating that it is ambiguous) to train the ML, etc.

[0130] Mode B: Real-time Monitoring Mode

[0131] In Mode B, RU may actively monitor and store the relative power saving status information during each reporting period. In some embodiments, within the report, RU may include the duration of the power saving status (sleep mode) and / or any changes in information. In some embodiments, ifthere is a change in the power saving status, RU may detect the same and label a corresponding report as a Sleep Mode Change Report. In some embodiments, RU may additionally record the execution information of the power saving status and / or its corresponding changes.

[0132] In some embodiments, DU / SMO / rApp may receive the report with an ambiguous marker (e.g., a dedicated bit in each report) and / or detailed execution information. In some embodiments, SMO / rApp may subsequently determine how to proceed further.

[0133] Mode B necessitates higher storage and computation costs within RU, as well as increased message transmission between different network elements. However, it does provide more precise information regarding power saving status changes, which can assist ML / AI in making more accurate decisions post-model training.

[0134] Fig. 5F shows how ambiguous reports are clarified in Mode B according to an embodiment of the present disclosure. As shown in Fig. 5F, a report may contain a marker or some information that indicates whether it is an ambiguous report. For example, the RU report #N+1 may contain a dedicated bit indicating that it is an ambiguous report, and therefore DU / SMO may identify it so. Further, the report may contain detailed information about the durations of each involved power saving mode, such that DU / SMO may be enabled to distinguish information collected in one power saving mode (e.g., SM Status A) from information collected in another power saving mode (e.g., SM Status B) as shown in Fig. 5F.

[0135] Although two modes are described above, the present disclosure is not limited thereto. In some other embodiments, one or more additional modes may be supported by RU, and / or one or both of Modes A and B need not to be supported by RU.

[0136] Mode Capability Report &Mode Selection

[0137] In some embodiments, during RU startup, RU may report its supported information reporting mode capabilities. In some embodiments, RU may additionally include the timer / table  information in the capabilities when Mode A is supported. In some embodiments, DU / SMO / rApp may select one of the modes, and then send an indication / request to RU to execution selected mode.

[0138] Fig. 6 is a diagram illustrating an exemplary procedure for report mode selection according to an embodiment of the present disclosure. The procedure may begin with RU startup. After RU startup, RU 135 (e.g., O-RU 135 shown in Fig. 1) may report, at step S605, its supported information report mode (s) , which comprise at least one of:

[0139] - Supporting Mode A, and including / indicating the mode A timers and / or table;

[0140] - Supporting Mode B;

[0141] - Supporting both modes, and including / indicating the mode A timers and / or table;

[0142] - Supporting none of the modes (e.g., by not sending this message or by not indicating support for any mode) , meaning that RU is working under legacy mode.

[0143] At step S605, DU 130 (e.g., O-DU 130 shown in Fig. 1) may receive the RU′sinformation regarding the supported report mode and transmit it to SMO / rApp 100 (e.g., SMO 100 shown in Fig. 1) at step S610. SMO / rApp 100 may evaluate the available modes, decide which mode to use, and then send the selected mode message to DU 130 at step S615. DU 130 may receive the selected mode and forward it to RU 135 at step S620. At step S625, RU 135 may initiate data collection according to the selected mode. At steps S630 through S645, RU may report the information at the designated report interval to DU 130 and / or SMO / rApp 100.

[0144] Fig. 7 is a flow chart of an exemplary method 700 at a first network node according to an embodiment of the present disclosure. The method 700 may be performed at a network node (e.g., the SMO 100 or the O-DU 130 shown in Fig. 1, or the SMO 100 or the DU 130 shown in Fig. 6) for clarifying ambiguities in reports. The method 700 may comprise steps S710 and S720. However, the present disclosure is not limited thereto. In some other embodiments, the method 700 may comprise more steps, less steps, different steps, or any combination thereof. Further the steps of the method 700 may be performed in a different order than that described herein. Further, in some embodiments, a step in the method 700 may be split into multiple sub-steps and performed by different entities, and / or multiple steps in the method 700 may be combined into a single step.

[0145] The method 700 may begin at step S710 where the first network node may receive, from a second network node, a report associated with a reporting network node. In some embodiments, the reporting network node may be the second network node or a third network node.

[0146] At step S720, the first network node may determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the reporting network node during a reporting period corresponding to the report.

[0147] In some embodiments, the operating states may comprise at least one of: a no-sleep state, in which the reporting network node is operated with full capacity; and one or more power saving (PS) states, in each of which the reporting network node is operated with a corresponding PS level. In some embodiments, the step of determining whether or not the report is an ambiguous report may comprise: determining whether the reporting network node is operated in a single operating state or in two or more operating states during the reporting period. In some embodiments, the step of determining whether or not the report is an ambiguous report may further comprise at least one of: determining that the report is not an ambiguous report in response to determining that the reporting network node is operated in a single operating state during the reporting period; and determining that the report is an ambiguous report in response to determining that the reporting network node is operated in two or more operating states during the reporting period. In some embodiments, the step of determining whether the reporting network node is operated in a single operating state or in two or more operating states during the reporting period may comprise at least one of: determining a first time, wherein the first time is the time when the first network node triggers the reporting network node to initiate a transition of its operating state for the last time before the report is received by the first network node; determining a second time, wherein the second time is the time when a message indicating a transition, which is autonomously initiated and completed by the reporting network node, is received by the first network node for the last time before the report is received by the first network node; and determining a third time, wherein the third time is the time when a message indicating a transition, which is autonomously initiated and completed by the reporting network node, is first received by the first network node after the report is received by the first network node.

[0148] In some embodiments, when the first time is determined, the step of determining whether the reporting network node is operated in a single operating state or in two or more operating states during the reporting period may further comprise: determining whether or not the reporting period is at least partially overlapped with a first time interval, which is defined by the first time and the first time plus a corresponding time offset and during which the transition is expected to be completed. In some embodiments, when the second time and / or the third time is determined, the step of determining whether the reporting network node is operated in a single operating state or in two or more operating states during the reporting period may further comprise at least one of:determining whether or not the reporting period is at least partially overlapped with a second  time interval, which is defined by the second time minus a corresponding time offset and the second time and during which the transition is completed; and determining whether or not the reporting period is at least partially overlapped with a third time interval, which is defined by the third time minus a corresponding time offset and the third time and during which the transition is completed.

[0149] In some embodiments, the step of determining whether the reporting network node is operated in a single operating state or in two or more operating states during the reporting period may further comprise at least one of: determining that the reporting network node is operated in a single operating state during the reporting period in response to determining that the reporting period is at least partially overlapped with none of the first time interval, the second time interval, and the third time interval; and determining that the reporting network node is operated in two or more operating states during the reporting period in response to determining that the reporting period is at least partially overlapped with at least one of the first time interval, the second time interval, and the third time interval.

[0150] In some embodiments, a time offset may be selected from a group comprising at least one of: one or more first time offsets, each of which corresponds to a transition from a no-sleep state to a corresponding PS state; one or more second time offsets, each of which corresponds to a transition from a corresponding PS state to a no-sleep state; and one or more third time offsets, each of which corresponds to a transition from a corresponding PS state to another corresponding PS state. In some embodiments, a third time offset corresponding to a transition from a first PS state to a second PS state may be equal to the sum of a second time offset corresponding to a transition from the first PS state to a no-sleep state and a first time offset corresponding to a transition from the no-sleep state to the second PS state.

[0151] In some embodiments, the method 700 may further comprise: receiving, from the second network node or the third network node, a message indicating one or more time offsets. In some embodiments, the report may further indicate whether or not the report is an ambiguous report. In some embodiments, the step of determining whether or not the report is an ambiguous report may comprise at least one of: determining that the report is an ambiguous report in response to the report indicating that the report is an ambiguous report; and determining that the report is not an ambiguous report in response to the report indicating that the report is not an ambiguous report. In some embodiments, the report may indicate at least one of: one or more operating states in which the reporting network node is operated during the reporting period; one or more durations, each of which is associated with a corresponding one of the one or more operating states; and an indicator indicating whether the reporting network node changes its operating state during the reporting period. In some embodiments, the method 700 may further comprise at least  one of: receiving, from the second network node or the third network node, a first message indicating a reporting capability of the reporting network node; determining a reporting mode to be applied by the reporting network node based on at least a reporting capability of the reporting network node; and transmitting, to the second network node or the third network node, a second message indicating a reporting mode to be applied by the reporting network node.

[0152] In some embodiments, a reporting mode may be selected from a group comprising at least one of: a first reporting mode in which a report, by itself, does not indicate whether or not it is an ambiguous report; and a second reporting mode in which a report, by itself, indicates whether or not it is an ambiguous report. In some embodiments, a reporting capability may indicate at least one of: supporting the first reporting mode; supporting the second reporting mode; supporting both of the first reporting mode and the second reporting mode; and supporting none of the first reporting mode and the second reporting mode. In some embodiments, when the first message indicates that the first reporting mode is supported, the first message may further indicate one or more time offsets used by the first network node to determine whether or not a report is an ambiguous report.

[0153] In some embodiments, a Service Management and Orchestration (SMO) may be hosted at the first network node, a Distributed Unit (DU) may be hosted at the second network node, and a Radio Unit (RU) may be hosted at the third network node. In some embodiments, an SMO may be hosted at the first network node, and an RU may be hosted at the second network node. In some embodiments, a DU may be hosted at the first network node, and an RU may be hosted at the second network node.

[0154] Fig. 8 is a flow chart of an exemplary method 800 at a second network node according to an embodiment of the present disclosure. The method 800 may be performed at a network node (e.g., the O-DU 130 orthe O-RU 135 shown in Fig. 1, orthe DU 130 orthe RU 135 shown in Fig. 6) for clarifying ambiguities in reports. The method 800 may comprise a step S810. However, the present disclosure is not limited thereto. In some other embodiments, the method 800 may comprise more steps, different steps, or any combination thereof. Further the steps of the method 800 may be performed in a different order than that described herein. Further, in some embodiments, a step in the method 800 may be split into multiple sub-steps and performed by different entities, and / or multiple steps in the method 800 may be combined into a single step.

[0155] The method 800 may begin at step S810 where the second network node may transmit, to a first network node, a report associated with a reporting network node, such that the first network node is enabled to determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the reporting  network node during a reporting period corresponding to the report. In some embodiments, the reporting network node may be the second network node or a third network node.

[0156] In some embodiments, the report may be generated at the second network node when the second network node is the reporting network node. In some embodiments, the report may be received from the third network node when the third network node is the reporting network node. In some embodiments, the operating states may comprise at least one of: a no-sleep state, in which the reporting network node is operated with full capacity; and one or more power saving (PS) states, in each of which the reporting network node is operated with a corresponding PS level.

[0157] In some embodiments, the method 800 may further comprise: transmitting, to the first network node, a message indicating one or more time offsets to be used by the first network node to determine whether or not a report is an ambiguous report. In some embodiments, a time offset may be selected from a group comprising at least one of: one or more first time offsets, each of which corresponds to a transition from a no-sleep state to a corresponding PS state; one or more second time offsets, each of which corresponds to a transition from a corresponding PS state to a no-sleep state; and one or more third time offsets, each of which corresponds to a transition from a corresponding PS state to another corresponding PS state. In some embodiments, a third time offset corresponding to a transition from a first PS state to a second PS state may be equal to the sum of a second time offset corresponding to a transition from the first PS state to a no-sleep state and a first time offset corresponding to a transition from the no-sleep state to the second PS state.

[0158] In some embodiments, the report may further indicate whether or not the report is an ambiguous report. In some embodiments, the report may indicate at least one of: one or more operating states in which the reporting network node is operated during the reporting period; one or more durations, each of which is associated with a corresponding one of the one or more operating states; and an indicator indicating whether the reporting network node changes its operating state during the reporting period. In some embodiments, the method 800 may further comprise at least one of: transmitting, to the first network node, a first message indicating a reporting capability of the reporting network node; and receiving, from the first network node, a second message indicating a reporting mode to be applied by the reporting network node.

[0159] In some embodiments, a reporting mode may be selected from a group comprising at least one of: a first reporting mode in which a report, by itself, does not indicate whether or not it is an ambiguous report; and a second reporting mode in which a report, by itself, indicates whether or not it is an ambiguous report. In some embodiments, a reporting capability may indicate at least one of: supporting the first reporting mode; supporting the second reporting  mode; supporting both of the first reporting mode and the second reporting mode; and supporting none of the first reporting mode and the second reporting mode. In some embodiments, when the first message indicates that the first reporting mode is supported, the first message may further indicate one or more time offsets used by the first network node to determine whether or not a report is an ambiguous report. In some embodiments, a Service Management and Orchestration (SMO) may be hosted at the first network node, a Distributed Unit (DU) may be hosted at the second network node, and a Radio Unit (RU) may be hosted at the third network node. In some embodiments, an SMO may be hosted at the first network node, and an RU may be hosted at the second network node. In some embodiments, a DU may be hosted at the first network node, and an RU may be hosted at the second network node.

[0160] Fig. 9 is a flow chart of an exemplary method 900 at a third network node according to an embodiment of the present disclosure. The method 900 may be performed at a network node (e.g., the O-RU 135 shown in Fig. 1 orthe RU 135 shown in Fig. 6) for clarifying ambiguities in reports. The method 900 may comprise a step S910. However, the present disclosure is not limited thereto. In some other embodiments, the method 900 may comprise more steps, different steps, or any combination thereof. Further the steps of the method 900 may be performed in a different order than that described herein. Further, in some embodiments, a step in the method 900 may be split into multiple sub-steps and performed by different entities, and / or multiple steps in the method 900 may be combined into a single step.

[0161] The method 900 may begin at step S910 where the third network node may transmit, to a second network node, a report associated with the third network node to be forwarded by the second network node to a first network node, such that the first network node is enabled to determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the third network node during a reporting period corresponding to the report.

[0162] In some embodiments, the report may be generated at the third network node. In some embodiments, the operating states may comprise at least one of: a no-sleep state, in which the third network node is operated with full capacity; and one or more power saving (PS) states, in each of which the third network node is operated with a corresponding PS level.

[0163] In some embodiments, the method 900 may further comprise: transmitting, to the second network node, a message indicating one or more time offsets to be used by the first network node to determine whether or not a report is an ambiguous report. In some embodiments, a time offset may be selected from a group comprising at least one of: one or more first time offsets, each of which corresponds to a transition from a no-sleep state to a corresponding PS state; one or more second time offsets, each of which corresponds to a transition from a corresponding PS state to a  no-sleep state; and one or more third time offsets, each of which corresponds to a transition from a corresponding PS state to another corresponding PS state. In some embodiments, a third time offset corresponding to a transition from a first PS state to a second PS state may be equal to the sum of a second time offset corresponding to a transition from the first PS state to a no-sleep state and a first time offset corresponding to a transition from the no-sleep state to the second PS state.

[0164] In some embodiments, the report may further indicate whether or not the report is an ambiguous report. In some embodiments, the report may indicate at least one of: one or more operating states in which the third network node is operated during the reporting period; one or more durations, each of which is associated with a corresponding one of the one or more operating states; and an indicator indicating whether the third network node changes its operating state during the reporting period. In some embodiments, the method 900 may further comprise at least one of: transmitting, to the second network node, a first message indicating a reporting capability of the third network node; and receiving, from the second network node, a third message indicating a reporting mode to be applied by the third network node.

[0165] In some embodiments, a reporting mode may be selected from a group comprising at least one of: a first reporting mode in which a report, by itself, does not indicate whether or not it is an ambiguous report; and a second reporting mode in which a report, by itself, indicates whether or not it is an ambiguous report. In some embodiments, a reporting capability may indicate at least one of: supporting the first reporting mode; supporting the second reporting mode; supporting both of the first reporting mode and the second reporting mode; and supporting none of the first reporting mode and the second reporting mode. In some embodiments, when the first message indicates that the first reporting mode is supported, the first message may further indicate one or more time offsets used by the first network node to determine whether or not a report is an ambiguous report. In some embodiments, a Service Management and Orchestration (SMO) may be hosted at the first network node, a Distributed Unit (DU) may be hosted at the second network node, and a Radio Unit (RU) may be hosted at the third network node.

[0166] Fig. 10 schematically shows an embodiment of an arrangement which may be used in network nodes according to an embodiment of the present disclosure. Comprised in the arrangement 1000 are a processing unit 1006, e.g., with a Digital Signal Processor (DSP) or a Central Processing Unit (CPU) . The processing unit 1006 may be a single unit or a plurality of units to perform different actions of procedures described herein. The arrangement 1000 may also comprise an input unit 1002 for receiving signals from other entities, and an output unit 1004 for providing signal (s) to other entities. The input unit 1002 and the output unit 1004 may be arranged as an integrated entity or as separate entities.

[0167] Furthermore, the arrangement 1000 may comprise at least one computer program product 1008 in the form of a non-volatile or volatile memory, e.g., an Electrically Erasable Programmable Read-Only Memory (EEPROM) , a flash memory and / or a hard drive. The computer program product 1008 comprises a computer program 1010, which comprises code / computer readable instructions, which when executed by the processing unit 1006 in the arrangement 1000 causes the arrangement 1000 and / or the network nodes in which it is comprised to perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 5A through Fig. 9 or any other variant.

[0168] The computer program 1010 may be configured as a computer program code structured in computer program modules 1010A and 1010B. Hence, in an exemplifying embodiment when the arrangement 1000 is used in a first network node, the code in the computer program of the arrangement 1000 includes: a module 1010A configured to receive, from a second network node, a report associated with a reporting network node, wherein the reporting network node is the second network node or a third network node; and a module 101 OB configured to determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the reporting network node during a reporting period corresponding to the report.

[0169] Additionally or alternatively, the computer program 1010 may be configured as a computer program code structured in a computer program module 1010C. Hence, in an exemplifying embodiment when the arrangement 1000 is used in a second network node, the code in the computer program of the arrangement 1000 includes: a module 1010C configured to transmit, to a first network node, a report associated with a reporting network node, such that the first network node is enabled to determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the reporting network node during a reporting period corresponding to the report. In some embodiments, the reporting network node may be the second network node or a third network node.

[0170] Additionally or alternatively, the computer program 1010 may be configured as a computer program code structured in a computer program module 101 OD. Hence, in an exemplifying embodiment when the arrangement 1000 is used in a third network node, the code in the computer program of the arrangement 1000 includes: a module 1010D configured to transmit, to a second network node, a report associated with the third network node to be forwarded by the second network node to a first network node, such that the first network node is enabled to determine, based on at least the report, whether or not the report is an ambiguous  report containing data collected in more than one of operating states for the third network node during a reporting period corresponding to the report.

[0171] The computer program modules could essentially perform the actions of the flow illustrated in Fig. 5A through Fig. 9, to emulate the network nodes. In other words, when the different computer program modules are executed in the processing unit 1006, they may correspond to different modules in the network nodes.

[0172] Although the code means in the embodiments disclosed above in conjunction with Fig. 10 are implemented as computer program modules which when executed in the processing unit causes the arrangement to perform the actions described above in conjunction with the figures mentioned above, at least one of the code means may in alternative embodiments be implemented at least partly as hardware circuits.

[0173] The processor may be a single CPU (Central processing unit) , but could also comprise two or more processing units. For example, the processor may include general purpose microprocessors; instruction set processors and / or related chips sets and / or special purpose microprocessors such as Application Specific Integrated Circuit (ASICs) . The processor may also comprise board memory for caching purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may comprise a computer readable medium on which the computer program is stored. For example, the computer program product may be a flash memory, a Random-access memory (RAM) , a Read-Only Memory (ROM) , or an EEPROM, and the computer program modules described above could in alternative embodiments be distributed on different computer program products in the form of memories within the network nodes.

[0174] The present disclosure is described above with reference to the embodiments thereof. However, those embodiments are provided just for illustrative purpose, rather than limiting the present disclosure. The scope of the disclosure is defined by the attached claims as well as equivalents thereof. Those skilled in the art can make various alternations and modifications without departing from the scope of the disclosure, which all fall into the scope of the disclosure.

Claims

1.A method (700) at a first network node (100, 130) , the method (700) comprising:receiving (S710) , from a second network node (130, 135) , a report associated with a reporting network node (135) , wherein the reporting network node (135) is the second network node (130, 135) or a third network node (135) ; anddetermining (S720) , based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the reporting network node (135) during a reporting period corresponding to the report.2.The method (700) of claim 1, wherein the operating states comprise at least one of:- a no-sleep state, in which the reporting network node (135) is operated with full capacity; and- one or more power saving (PS) states, in each of which the reporting network node (135) is operated with a corresponding PS level.3.The method (700) of claim 1 or 2, wherein the step of determining whether or not the report is an ambiguous report comprises:determining whether the reporting network node (135) is operated in a single operating state or in two or more operating states during the reporting period,wherein the step of determining whether or not the report is an ambiguous report further comprises at least one of:determining that the report is not an ambiguous report in response to determining that the reporting network node (135) is operated in a single operating state during the reporting period; anddetermining that the report is an ambiguous report in response to determining that the reporting network node (135) is operated in two or more operating states during the reporting period.4.The method (700) of claim 3, wherein the step of determining whether the reporting network node (135) is operated in a single operating state or in two or more operating states during the reporting period comprises at least one of:determining a first time, wherein the first time is the time when the first network node (100, 130) triggers the reporting network node (135) to initiate a transition of its operating state for the last time before the report is received by the first network node (100, 130) ;determining a second time, wherein the second time is the time when a message indicating a transition, which is autonomously initiated and completed by the reporting network node (135) , is received by the first network node (100, 130) for the last time before the report is received by the first network node (100, 130) ; anddetermining a third time, wherein the third time is the time when a message indicating a transition, which is autonomously initiated and completed by the reporting network node (135) , is first received by the first network node (100, 130) after the report is received by the first network node (100, 130) .5.The method (700) of claim 4, wherein when the first time is determined, the step of determining whether the reporting network node (135) is operated in a single operating state or in two or more operating states during the reporting period further comprises:determining whether or not the reporting period is at least partially overlapped with a first time interval, which is defined by the first time and the first time plus a corresponding time offset and during which the transition is expected to be completed.6.The method (700) of claim 4 or 5, wherein when the second time and / or the third time is determined, the step of determining whether the reporting network node (135) is operated in a single operating state or in two or more operating states during the reporting period further comprises at least one of:determining whether or not the reporting period is at least partially overlapped with a second time interval, which is defined by the second time minus a corresponding time offset and the second time and during which the transition is completed; anddetermining whether or not the reporting period is at least partially overlapped with a third time interval, which is defined by the third time minus a corresponding time offset and the third time and during which the transition is completed.7.The method (700) of any of claims 4 to 6, wherein the step of determining whether the reporting network node (135) is operated in a single operating state or in two or more operating states during the reporting period further comprises at least one of:determining that the reporting network node (135) is operated in a single operating state during the reporting period in response to determining that the reporting period is at least partially overlapped with none of the first time interval, the second time interval, and the third time interval; anddetermining that the reporting network node (135) is operated in two or more operating states during the reporting period in response to determining that the reporting period is at least partially overlapped with at least one of the first time interval, the second time interval, and the third time interval.8.The method (700) of any of claims 1 to 7, wherein a time offset is selected from a group comprising at least one of:- one or more first time offsets, each of which corresponds to a transition from a no-sleep state to a corresponding PS state;- one or more second time offsets, each of which corresponds to a transition from a corresponding PS state to a no-sleep state; and- one or more third time offsets, each of which corresponds to a transition from a corresponding PS state to another corresponding PS state.9.The method (700) of claim 8, wherein a third time offset corresponding to a transition from a first PS state to a second PS state is equal to the sum of a second time offset corresponding to a transition from the first PS state to a no-sleep state and a first time offset corresponding to a transition from the no-sleep state to the second PS state.10.The method (700) of any of claims 1 to 9, further comprising:receiving, from the second network node (130, 135) or the third network node (135) , a message indicating one or more time offsets.11.The method (700) of any of claims 1 to 10, wherein the report further indicates whether or not the report is an ambiguous report,wherein the step of determining whether or not the report is an ambiguous report comprises at least one of:determining that the report is an ambiguous report in response to the report indicating that the report is an ambiguous report; anddetermining that the report is not an ambiguous report in response to the report indicating that the report is not an ambiguous report.12.The method (700) of any of claims 1 to 11, wherein the report indicates at least one of:- one or more operating states in which the reporting network node (135) is operated during the reporting period;- one or more durations, each of which is associated with a corresponding one of the one or more operating states; and- an indicator indicating whether the reporting network node (135) changes its operating state during the reporting period.13.The method (700) of any of claims 1 to 12, further comprising at least one of:receiving, from the second network node (130, 135) or the third network node (135) , a first message indicating a reporting capability of the reporting network node (135) ;determining a reporting mode to be applied by the reporting network node (135) based on at least a reporting capability of the reporting network node (135) ; andtransmitting, to the second network node (130, 135) or the third network node (135) , a second message indicating a reporting mode to be applied by the reporting network node (135) .14.The method (700) of any of claims 1 to 13, wherein a reporting mode is selected from a group comprising at least one of:- a first reporting mode in which a report, by itself, does not indicate whether or not it is an ambiguous report; and- a second reporting mode in which a report, by itself, indicates whether or not it is an ambiguous report.15.The method (700) of claim 14, wherein a reporting capability indicates at least one of:- supporting the first reporting mode;- supporting the second reporting mode;- supporting both of the first reporting mode and the second reporting mode; and- supporting none of the first reporting mode and the second reporting mode.16.The method (700) of claim 14 or 15, wherein when the first message indicates that the first reporting mode is supported, the first message further indicates one or more time offsets used by the first network node (100, 130) to determine whether or not a report is an ambiguous report.17.The method (700) of any of claims 1 to 16, wherein a Service Management and Orchestration (SMO) is hosted at the first network node (100) , a Distributed Unit (DU) is hosted at the second network node (130) , and a Radio Unit (RU) is hosted at the third network node (135) , orwherein an SMO is hosted at the first network node (100) , and an RU is hosted at the second network node (135) , orwherein a DU is hosted at the first network node (130) , and an RU is hosted at the second network node (135) .18.A first network node (100, 130, 1000) comprising:a processor (1006) ;a memory (1008) storing instructions which, when executed by the processor (1006) , cause the first network node (100, 130, 1000) to:receive, from a second network node (130, 135) , a report associated with a reporting network node (135) , wherein the reporting network node (135) is the second network node (130, 135) or a third network node (135) ; anddetermine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the reporting network node (135) during a reporting period corresponding to the report.19.The first network node (100, 130, 1000) of claim 18, wherein the instructions, when executed by the processor (1006) , cause the first network node (100, 130, 1000) to further perform any of the methods (700) of claims 2 to 17.20.A method (800) at a second network node (130, 135) , the method (800) comprising:transmitting (S810) , to a first network node (100, 130) , a report associated with a reporting network node (135) , such that the first network node (100, 130) is enabled to determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the reporting network node (135) during a reporting period corresponding to the report,wherein the reporting network node (135) is the second network node (130, 135) or a third network node (135) .21.The method (800) of claim 20, wherein the report is generated at the second network node (135) when the second network node (135) is the reporting network node (135) .22.The method (800) of claim 20 or 21, wherein the report is received from the third network node (135) when the third network node (135) is the reporting network node (135) .23.The method (800) of any of claims 20 to 22, wherein the operating states comprise at least one of:- a no-sleep state, in which the reporting network node (135) is operated with full capacity; and- one or more power saving (PS) states, in each of which the reporting network node (135) is operated with a corresponding PS level.24.The method (800) of any of claims 20 to 23, further comprising:transmitting, to the first network node (100, 130) , a message indicating one or more time offsets to be used by the first network node (100, 130) to determine whether or not a report is an ambiguous report.25.The method (800) of any of claims 20 to 24, wherein a time offset is selected from a group comprising at least one of:- one or more first time offsets, each of which corresponds to a transition from a no-sleep state to a corresponding PS state;- one or more second time offsets, each of which corresponds to a transition from a corresponding PS state to a no-sleep state; and- one or more third time offsets, each of which corresponds to a transition from a corresponding PS state to another corresponding PS state.26.The method (800) of claim 25, wherein a third time offset corresponding to a transition from a first PS state to a second PS state is equal to the sum of a second time offset corresponding to a transition from the first PS state to a no-sleep state and a first time offset corresponding to a transition from the no-sleep state to the second PS state.27.The method (800) of any of claims 20 to 26, wherein the report further indicates whether or not the report is an ambiguous report.28.The method (800) of any of claims 20 to 27, wherein the report indicates at least one of:- one or more operating states in which the reporting network node (135) is operated during the reporting period;- one or more durations, each of which is associated with a corresponding one of the one or more operating states; and- an indicator indicating whether the reporting network node (135) changes its operating state during the reporting period.29.The method (800) of any of claims 20 to 28, further comprising at least one of:transmitting, to the first network node (100, 130) , a first message indicating a reporting capability of the reporting network node (135) ; andreceiving, from the first network node (100, 130) , a second message indicating a reporting mode to be applied by the reporting network node (135) .30.The method (800) of any of claims 20 to 29, wherein a reporting mode is selected from a group comprising at least one of:- a first reporting mode in which a report, by itself, does not indicate whether or not it is an ambiguous report; and- a second reporting mode in which a report, by itself, indicates whether or not it is an ambiguous report.31.The method (800) of claim 30, wherein a reporting capability indicates at least one of:- supporting the first reporting mode;- supporting the second reporting mode;- supporting both of the first reporting mode and the second reporting mode; and- supporting none of the first reporting mode and the second reporting mode.32.The method (800) of claim 30 or 31, wherein when the first message indicates that the first reporting mode is supported, the first message further indicates one or more time offsets used by the first network node (100, 130) to determine whether or not a report is an ambiguous report.33.The method (800) of any of claims 20 to 32, wherein a Service Management and Orchestration (SMO) is hosted at the first network node (100) , a Distributed Unit (DU) is hosted at the second network node (130) , and a Radio Unit (RU) is hosted at the third network node (135) , orwherein an SMO is hosted at the first network node (100) , and an RU is hosted at the second network node (135) , orwherein a DU is hosted at the first network node (130) , and an RU is hosted at the second network node (135) .34.A second network node (130, 135, 1000) comprising:a processor (1006) ;a memory (1008) storing instructions which, when executed by the processor (1006) , cause the second network node (130, 135, 1000) to:transmit, to a first network node (100, 130) , a report associated with a reporting network node (135) , such that the first network node (100, 130) is enabled to determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the reporting network node (135) during a reporting period corresponding to the report,wherein the reporting network node (135) is the second network node (130, 135, 1000) or a third network node (135) .35.The second network node (130, 135, 1000) of claim 34, wherein the instructions, when executed by the processor (1006) , cause the second network node (130, 135, 1000) to further perform any of the methods (800) of claims 21 to 33.36.A method (900) at a third network node (135) , the method (900) comprising:transmitting (S910) , to a second network node (130, 135) , a report associated with the third network node (135) to be forwarded by the second network node (130, 135) to a first network node (100, 130) , such that the first network node (100, 130) is enabled to determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the third network node (135) during a reporting period corresponding to the report.37.A third network node (135, 1000) comprising:a processor;a memory storing instructions which, when executed by the processor, cause the third network node (135, 1000) to:transmit, to a second network node (130, 135) , a report associated with the third network node (135, 1000) to be forwarded by the second network node (130, 135) to a first network node (100, 130) , such that the first network node (100, 130) is enabled to determine, based on at least the report, whether or not the report is an ambiguous report containing data collected in more than one of operating states for the third network node (135, 1000) during a reporting period corresponding to the report.38.A computer program (1010) comprising instructions which, when executed by at least one processor (1006) , cause the at least one processor (1006) to carry out the method (700, 800, 900) of any of claims 1 to 17, 20 to 33, and 36.39.A carrier (1008) containing the computer program (1010) of claim 38, wherein the carrier (1008) is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.40.A telecommunication system (10) , comprising:a first network node (100, 130) of claim 18 or 19; anda second network node (130, 135) of claim 34 or 35 and / or a third network node (135) of claim 37.

Images