In some embodiments, recommendation component 114 can comprise an A.I. and/or M.L. model that can be trained (e.g., via supervised and/or unsupervised techniques) to perform the above or below-described functions using historical training data comprising various context conditions that correspond to various augmented network optimization operations. In this example, such an A.I. and/or M.L. model can further learn (e.g., via supervised and/or unsupervised techniques) to perform the above or below-described functions using training data comprising feedback data, where such feedback data can be collected and/or stored (e.g., in memory) by the Recommendation component 114. In this example, such feedback data can comprise the various instructions described above/below that can be input, for instance, to a system herein, over time in response to observed/stored context-based information.

A.I./M.L. components herein can initiate an operation(s) associated with a based on a defined level of confidence determined using information (e.g., feedback data). For example, based on learning to perform such functions described above using feedback data, performance information, and/or past performance information herein, a recommendation component 114 herein can initiate an operation associated with determining various thresholds herein (e.g., a motion pattern thresholds, input pattern thresholds, similarity thresholds, authentication signal thresholds, audio frequency thresholds, or other suitable thresholds).

In an embodiment, the recommendation component 114 can perform a utility-based analysis that factors cost of initiating the above-described operations versus benefit. In this embodiment, the recommendation component 114 can use one or more additional context conditions to determine various thresholds herein.

To facilitate the above-described functions, a recommendation component 114 herein can perform classifications, correlations, inferences, and/or expressions associated with principles of artificial intelligence. For instance, the recommendation component 114 can employ an automatic classification system and/or an automatic classification. In one example, the recommendation component 114 can employ a probabilistic and/or statistical-based analysis (e.g., factoring into the analysis utilities and costs) to learn and/or generate inferences. The recommendation component 114 can employ any suitable machine-learning based techniques, statistical-based techniques and/or probabilistic-based techniques. For example, the recommendation component 114 can employ expert systems, fuzzy logic, support vector machines (SVMs), Hidden Markov Models (HMMs), greedy search algorithms, rule-based systems, Bayesian models (e.g., Bayesian networks), neural networks, other non-linear training techniques, data fusion, utility-based analytical systems, systems employing Bayesian models, and/or the like. In another example, the recommendation component 114 can perform a set of machine-learning computations. For instance, the recommendation component 114 can perform a set of clustering machine learning computations, a set of logistic regression machine learning computations, a set of decision tree machine learning computations, a set of random forest machine learning computations, a set of regression tree machine learning computations, a set of least square machine learning computations, a set of instance-based machine learning computations, a set of regression machine learning computations, a set of support vector regression machine learning computations, a set of k-means machine learning computations, a set of spectral clustering machine learning computations, a set of rule learning machine learning computations, a set of Bayesian machine learning computations, a set of deep Boltzmann machine computations, a set of deep belief network computations, and/or a set of different machine learning computations.

Turning now to FIG. 2, there is illustrated a diagram 200 of exemplary reporting period recommendation generation (e.g., via the recommendation component 114) in accordance with one or more embodiments described herein. In various embodiments, the recommendation component 114 can predict minimum supported reporting period (e.g., in output 206) and/or recommended reporting periods (e.g., in output 206), for instance, for registered E2 nodes (e.g., RAN 136). Input 202 to the ML model 204 can comprise, for instance, resource utilization data (e.g., applicable to the RAN 136) and/or xApp 132 requirement data. The minimum reporting period can indicate the highest granularity at which an E2 node (e.g., RAN 136) can report data. The recommended reporting period can indicate the most energy efficient granularity for the respective E2 node. In one or more embodiments, the recommendation component 114 can trigger, for instance, O1 messages from the SMO 124 to configure E2 nodes (e.g., RAN 136) with an updated reporting period recommendation (e.g., utilizing resource utilization data and/or xApp requirements data) (e.g., via the recommendation component 114). Such recommendations can be generated (e.g., via the recommendation component 114) periodically, for instance, to update the E2 Node (e.g., RAN 136) recommended periods.

FIG. 3 is a diagram 300 of exemplary flexible xApp 132 subscriptions in accordance with one or more embodiments described herein. It is noted that xApps 132 can support different reporting periods on requested KPIs. When a reporting period update is configured on an E2 node (e.g., RAN 136): (1) a configuration update is sent (e.g., via the communication component 116) through E2 to the near-RT RIC (e.g., controller 128), (2) the xApp framework 134 manages subscribed xApps 132 to trigger subscription changes for xApps 132 for which requested periods are no longer supported, and (3) the RAN 136 can utilize the recommended and minimum available reporting periods. A longer reporting period can impact performance of the xApp 132. However, this trade-off optimizes the subscriptions to ensure the E2 node (e.g., RAN 136) can continue supporting the subscriptions of a plurality of xApps 132.

FIG. 4 is a diagram 400 of exemplary ML model training 402 (e.g., of an ML model 204) in accordance with one or more embodiments described herein. The ML model 204 can be trained, for instance, by utilizing data collected from the E2 nodes (e.g., RAN 136) and the subscribing xApps 132. In this regard, the ML model 204 can be trained using (1) CPU Utilization on E2 nodes (e.g., RAN 136), (2) available RAM on E2 nodes (e.g., RAN 136), (3) xApp 132 requirements (e.g., requested reporting periods), and/or (4) historical subscription data (e.g., accepted and/or revised subscription requests). In various embodiments, the ML model training 402 can take place on a non-RT RIC 126 (e.g., in a corresponding, dedicated rApp). It is noted that the foregoing can utilize data collected by the host SMO 124. Alternatively, the ML model training 402 can be performed offline, for instance, using data collected from multiple networks, and then deployed onto an rApp for prediction.

FIG. 5 is a diagram of an exemplary process flow 500 in accordance with one or more embodiments described herein. At 502, the SMO 124 can configure the controller 128 and/or E2 Node (e.g., RAN 136). This can comprise setting (e.g., via the SMO 124) initial recommended reporting periods for the E2 Node KPIs, as well as onboarding xApps 132 on the controller 128. At 504, the E2 Node (e.g., RAN 136) can register with the controller 128, identifying all the KPIs that the controller 128 can subscribe on and the recommended and minimum reporting periods of each, and connect to the controller 128. The xApps 132 deployed on the controller 128 can determine the recommended reporting periods and adjust accordingly, for instance, before subscribing on the KPIs. At 506, the SMO 124 can subscribe to E2 node (e.g., RAN 136) resource KPIs, which can track one or more elements such as CPU and/or RAM usage applicable to the RAN 136. At 508, the SMO 124 can onboard one or more xApps 132. At 510, one or more xApps can subscribe on periodic data for specific KPIs. At 512, the RAN 136 can determine if periodicities and/or KPIs are acceptable. In this regard, the RAN 136 can determine whether the periodicities fall within a defined acceptable range. At 514, the RAN 136 can send a subscription success message to the controller 128 (e.g., if within the defined acceptable range), and KPI data can begin to flow periodically. At 516, if the load on the E2 Node (e.g., RAN 136) were to drastically fluctuate, the ML model 204 in the SMO 124 can adjust the recommended and/or minimum reporting periods of the KPIs in the E2 Node (e.g., RAN 136). For example, corresponding network traffic can spike during a rush hour traffic. At 518, updated resource KPIs can be sent from the RAN 136 to the SMO 124. At 520, the recommendation component 114 (e.g., via the ML model 204) can calculate a reporting period applicable to the xApp 132. At 522, the SMO 124 can send the adjusted reporting periods to the RAN 136. At 524, the RAN 136 can send the configuration update to the controller 128, for instance, to adjust respective subscriptions accordingly. At 526, the controller 128 and/or an xApp 132 can send the adjusted subscription to the RAN 136.

FIG. 6 is a flow chart for a process 600 associated with dynamic node key performance indicator reporting in an ORAN, in accordance with one or more embodiments described herein. It is noted that the xApp 132 priority ID/level can be assigned (e.g., via a system 102) during xApp 132 onboarding in the SMO 124. In this regard, some xApps can require strict reporting periods, for instance, to maintain critical functionalities. At 602, a new xApp 132 subscription request is received by the RAN 136 (e.g., via the communication component 116). The xApp 132 can send an E2 message with the subscription request and/or the xApp priority ID/level. At 604, the priority ID/level can be determined (e.g., via the priority component 118). In various embodiments, such a priority ID/level can be comprised in configuration data applicable to a corresponding xApp 132. If at 604, the priority level/ID is determined (e.g., via the priority component 118) not to comprise a defined high priority (e.g., NO at 604), the configured recommendations at the E2 node (e.g., RAN 136) can be utilized to support the subscription request (e.g., at 608). If at 604, the priority level/ID is determined (e.g., via the priority component 118) to comprise a defined high priority (e.g., YES at 604), then the E2 node (e.g., RAN 136) can accept the subscription request regardless, and the recommended reporting period can be bypassed (e.g., at 606) (e.g., via the bypass component 120). At 610, resource overflow (e.g., network degradation such as packet drop, overheating of system, near maximum utilization of CPU and/or RAM, etc.) can be determined (e.g., via the resource component 110). It is noted that such degradation can lead to degradation across an entire corresponding network. If the E2 node (e.g., RAN 136) can support the new xApp 132 without any degradation in the xApps (e.g., NO at 610), then there does not exist a need to update the reporting period to accommodate additional allocated resources for the priority xApp. If the E2 node (e.g., RAN 136) cannot support the new xApp without any degradation in the xApps (e.g., YES at 610), an update is triggered at 612 to update (e.g., via the recommendation component 114) the frequency of the reporting period of an xApp (e.g., with lower priority). The updated (e.g., lower priority) xApp will follow another suitable approach, if needed.

FIG. 7 is a block flow diagram for a process 700 associated with dynamic node key performance indicator reporting in an ORAN, in accordance with one or more embodiments described herein. At 702, the process 700 can comprise determining (e.g., via the resource component 110) resource utilization of a network node (e.g., RAN 136). At 704, the process 700 can comprise determining (e.g., via the request determination component 112) a requested reporting period of a key performance indicator, applicable to the network node (e.g., RAN 136), requested by an xApp 132 of a radio access network intelligent controller 128. At 706, the process 700 can comprise, using a reporting model (e.g., ML model 204) generated using machine learning based on past resource utilization, other than the resource utilization, and past reporting periods, other than the requested reporting period, generating (e.g., via the recommendation component 114) a reporting period recommendation applicable to the network node (e.g., RAN 136) and the extended application (xApp 132)

FIG. 8 is a block flow diagram for a process 800 associated with dynamic node key performance indicator reporting in an ORAN, in accordance with one or more embodiments described herein. At 802, the process 800 can comprise determining (e.g., via the resource component 110) resource utilization of an E2 network node (e.g., RAN 136). At 804, the process 800 can comprise determining (e.g., via the request determination component 112) a requested reporting period of a key performance indicator, applicable to the E2 network node (e.g., RAN 136), requested by an extended application (e.g., xApp 132) of a radio access network intelligent controller 128. At 806, the process 800 can comprise, using a reporting model (e.g., ML model 204) generated using machine learning based on past resource utilization, other than the resource utilization, and past reporting periods, other than the requested reporting period, determining (e.g., via the recommendation component 114) a recommended reporting period applicable to the E2 network node (e.g., RAN 136) and the extended application (e.g., xApp 132).

FIG. 9 is a block flow diagram for a process 900 associated with dynamic node key performance indicator reporting in an ORAN, in accordance with one or more embodiments described herein. At 902, the process 900 can comprise determining, by a radio access network intelligent controller comprising a processor (e.g., via the resource component 110), resource utilization of a network node (e.g., RAN 136). At 904, the process 900 can comprise determining, by the radio access network intelligent controller (e.g., via the request determination component 112), a requested reporting period of a key performance indicator, applicable to the network node (e.g., RAN 136), requested by extended application (e.g., xApp 132) associated with the radio access network intelligent controller 128. At 906, the process 900 can comprise, using a reporting machine learning model (e.g., ML model 204) generated using artificial intelligence based on past resource utilization, other than the resource utilization, and past reporting periods, other than the requested reporting period, generating, by the radio access network intelligent controller (e.g., via the recommendation component 114), recommendation data representative of a reporting period recommendation applicable to the network node (e.g., RAN 136) and the extended application (e.g., xApp 132).

In order to provide additional context for various embodiments described herein, FIG. 10 and the following discussion are intended to provide a brief, general description of a suitable computing environment 1000 in which the various embodiments of the embodiment described herein can be implemented. While the embodiments have been described above in the general context of computer-executable instructions that can run on one or more computers, those skilled in the art will recognize that the embodiments can be also implemented in combination with other program modules and/or as a combination of hardware and software.

Generally, program modules include routines, programs, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the various methods can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, minicomputers, mainframe computers, Internet of Things (IoT) devices, distributed computing systems, as well as personal computers, hand-held computing devices, microprocessor-based or programmable consumer electronics, and the like, each of which can be operatively coupled to one or more associated devices.

The illustrated embodiments of the embodiments herein can be also practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

Computing devices typically include a variety of media, which can include computer-readable storage media, machine-readable storage media, and/or communications media, which two terms are used herein differently from one another as follows. Computer-readable storage media or machine-readable storage media can be any available storage media that can be accessed by the computer and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable storage media or machine-readable storage media can be implemented in connection with any method or technology for storage of information such as computer-readable or machine-readable instructions, program modules, structured data, or unstructured data.

Computer-readable storage media can include, but are not limited to, random access memory (RAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD), Blu-ray disc (BD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, solid state drives or other solid state storage devices, or other tangible and/or non-transitory media which can be used to store desired information. In this regard, the terms “tangible” or “non-transitory” herein as applied to storage, memory, or computer-readable media, are to be understood to exclude only propagating transitory signals per se as modifiers and do not relinquish rights to all standard storage, memory or computer-readable media that are not only propagating transitory signals per se.

Computer-readable storage media can be accessed by one or more local or remote computing devices, e.g., via access requests, queries, or other data retrieval protocols, for a variety of operations with respect to the information stored by the medium.

Communications media typically embody computer-readable instructions, data structures, program modules or other structured or unstructured data in a data signal such as a modulated data signal, e.g., a carrier wave or other transport mechanism, and includes any information delivery or transport media. The term “modulated data signal” or signals refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in one or more signals. By way of example, and not limitation, communication media include wired media, such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.

With reference again to FIG. 10, the example environment 1000 for implementing various embodiments of the aspects described herein includes a computer 1002, the computer 1002 including a processing unit 1004, a system memory 1006 and a system bus 1008. The system bus 1008 couples system components including, but not limited to, the system memory 1006 to the processing unit 1004. The processing unit 1004 can be any of various commercially available processors. Dual microprocessors and other multi-processor architectures can also be employed as the processing unit 1004.

The system bus 1008 can be any of several types of bus structure that can further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The system memory 1006 includes ROM 1010 and RAM 1012. A basic input/output system (BIOS) can be stored in a non-volatile memory such as ROM, erasable programmable read only memory (EPROM), EEPROM, which BIOS contains the basic routines that help to transfer information between elements within the computer 1002, such as during startup. The RAM 1012 can also include a high-speed RAM such as static RAM for caching data.

The computer 1002 further includes an internal hard disk drive (HDD) 1014 (e.g., EIDE, SATA), one or more external storage devices 1016 (e.g., a magnetic floppy disk drive (FDD) 1016, a memory stick or flash drive reader, a memory card reader, etc.) and an optical disk drive 1020 (e.g., which can read or write from a disk 1022 such as CD-ROM disc, a DVD, a BD, etc.). While the internal HDD 1014 is illustrated as located within the computer 1002, the internal HDD 1014 can also be configured for external use in a suitable chassis (not shown). Additionally, while not shown in environment 1000, a solid-state drive (SSD) could be used in addition to, or in place of, an HDD 1014. The HDD 1014, external storage device(s) 1016 and optical disk drive 1020 can be connected to the system bus 1008 by an HDD interface 1024, an external storage interface 1026 and an optical drive interface 1028, respectively. The interface 1024 for external drive implementations can include at least one or both of Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 1394 interface technologies. Other external drive connection technologies are within contemplation of the embodiments described herein.