Autonomous network, controller and method

Abstract

A controller for an autonomous network includes a processor executing configurable and replaceable modules in an interconnected manner to form a controller component comprising: a measurement component that collects measurement data regarding at least one controlled element under the control of the controller, an analysis component that processes the collected measurement data to obtain a current state of the at least one controlled element, a decision component that determines an action to take with respect to the at least one controlled element based on the obtained current state, and an action component that executes the determined action with respect to the at least one controlled element by effecting a change in the operation and / or configuration of the at least one controlled element.

Description

[Background technology]

[0001] Networking and communication systems have a profound impact on our daily lives. This impact is expected to grow in the near future due to the expected expansion of automotive, wearable, and other Internet-of-Things (IoT) related applications. This massive transformation relies on advances in communication networks that are growing in complexity to understand and / or manage. [Brief explanation of the drawings]

[0002] Various aspects of the present disclosure will be better understood from the following detailed description when read in conjunction with the accompanying drawings, in which: It should be noted that, according to standard industry practice, various features are not drawn to scale. In fact, the dimensions of various features may be arbitrarily increased or decreased for clarity of discussion.

[0003] [Figure 1] FIG. 1 is a schematic block diagram of a controller for an autonomous network according to some embodiments. [Figure 2] FIG. 1 is a schematic block diagram of a section of an autonomous network according to some embodiments. [Figure 3] 1 shows a schematic block diagram of some of the portions of a controller deployed in a controller deployment according to some embodiments. [Figure 4] FIG. 1 is a schematic block diagram of portions of an autonomous network in an online trial for controller deployment according to some embodiments. [Figure 5] 1 is a flowchart of a method in an autonomous network according to some embodiments. [Figure 6] FIG. 1 is a schematic block diagram of a traffic load balancing section of an autonomous network for a CDN according to some embodiments. [Figure 7] 1A-1D are schematic block diagrams of various configurations of measurement components according to some embodiments. [Figure 8]FIG. 1 is a schematic block diagram of an example computer hardware configuration according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0004] The following disclosure provides many different embodiments or examples for implementing different features of the provided subject matter. Specific examples of components, values, operations, materials, arrangements, etc. are described below to simplify the disclosure. Of course, these are merely examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, etc. are also contemplated. For example, in the following description, forming a first feature above or on a second feature may include embodiments in which the first and second features are formed in direct contact with each other, or may include embodiments in which an additional feature is formed between the first and second features such that the first and second features are not in direct contact with each other. Additionally, the present disclosure may repeat reference numerals and / or letters in various examples. This repetition is for brevity and clarity and does not in itself dictate a relationship between the various embodiments and / or configurations discussed.

[0005] One approach to addressing the challenges that emerge with rapidly growing and / or complex communication networks is to make the networks autonomous: autonomous networks are configured to deal with and adapt to unexpected events and / or improve and adapt themselves to future challenges, for example, by incorporating new technologies as they become available, with little or no human intervention.

[0006] Some embodiments enable realizing an autonomous network by configuring controllers from configurable and replaceable modules, interconnecting the controllers in a system hierarchy graph where higher-level controllers are configured to control and / or deploy lower-level controllers, and performing online trials to evaluate the deployed controllers. In at least one embodiment, the configurable and replaceable modules facilitate modification, optimization, or deployment of controllers, for example, by replacing one or more existing modules with different, equivalent modules and / or different instances of existing modules. In one or more embodiments, controller optimization / deployment and / or online trials are configured to be performed at runtime, allowing the autonomous network to address emerging challenges and / or adapt to new technologies. Other advantages of various embodiments are also described herein.

[0007] FIG. 1 is a schematic block diagram of a controller 100 for an autonomous network according to some embodiments.

[0008] Controller 100 includes multiple interconnected controller components (also referred to as phases or stages). In the example configuration of FIG. 1, the multiple controller components include measurement component 110, analysis component 120, decision component 130, and action component 140. Each controller component includes multiple interconnected modules. For example, measurement component 110 includes source module 111, sink module 112, and one or more intermediate modules 115 and 116 connected between source module 111 and sink module 112. Similarly, analysis component 120, decision component 130, and action component 140 include source modules 121, 131, and 141, sink modules 122, 132, and 142, and intermediate modules 125, 135, and 145 between the source and sink modules. In at least one embodiment, a sink module of a controller component can be directly connected to a source module of the same controller component. As indicated by the arrows between the controller components in Figure 1, the controller components 110, 120, 130, 140 are interconnected in a loop such that the sink module of a previous controller component in the loop is connected to the source module of the next controller component, and the source module of the next controller component (i.e., the next phase) is given access to the output from the sink module of the previous controller component (i.e., the previous phase). A detailed description of the requirements for each controller component (i.e., each phase), along with any additional requirements derived from the modules present in this next phase, is provided by a controller specification (described herein).For example, sink module 112 of measurement component 110 is connected to source module 121 of analysis component 120, sink module 122 of analysis component 120 is connected to source module 131 of decision component 130, sink module 132 of decision component 130 is connected to source module 141 of action component 140, and sink module 142 of action component 140 is connected to source module 111 of measurement component 110. In at least one embodiment, the loop of the controller component is a recognition control loop as described herein. The number and / or manner in which the various modules in each controller component 110, 120, 130, 140 of FIG. 1 are exemplary. Other arrangements are within the scope of various embodiments, for example, as described with respect to FIG. 3.

[0009] Controller 100 includes at least one memory (not shown in FIG. 1) and at least one processor (not shown in FIG. 1) coupled to the at least one memory, as described with respect to the computer hardware configuration in FIG. 8, for example. In at least one embodiment, one or more other components of the computer hardware configuration are also included in controller 100. The described modules 111, 112, 115, 116, 121, 122, 125, 131, 132, 135, 141, 142, 145 interconnected within each controller component 110, 120, 130, 140 or throughout controller 100 are configurable and replaceable modules contained within at least one memory of controller 100. Controller components 110, 120, 130, 140 are configured by at least one processor of controller 100, as the at least one processor executes the modules in an interconnected manner. For example, in at least one embodiment, modules 111, 115, 116, and 112 are interconnected at run time, similar to how dynamic link libraries (DLLs) are interconnected at run time, by at least one processor executing the modules that make up measurement component 110. In at least one embodiment, modules are interconnected at load time. In at least one embodiment, some controller components of controller 100, or the entire controller 100, are implemented by a processor. In further embodiments, at least one controller component of controller 100 is implemented by several processors that are connected or distributed over a network.

[0010] As previously mentioned, the modules that make up the controller component of controller 100 are configurable and replaceable modules that are configured to be selected and interconnected in various combinations to meet specific needs. Such modules are further replaceable in at least one embodiment to allow for easy modification or evolution of controller 100. An example of a configurable and replaceable module configuration is provided with respect to module 115 of measurement component 110 in controller 100.

[0011] A configurable and replaceable module, such as module 115 , comprises a software section 150 and corresponding configuration information 160 .

[0012] The software section 150 represents the operating logic of the module 115 and includes one or more executable codes 152, one or more parameters 154, and an application programming interface (API) 156. The executable code 152 represents the logical operations of the module 115, and at least one processor of the controller 100 executes the executable code 152 to perform the logical operations of the module 115. The parameters 154, such as a wait time before a timeout, are used by the at least one processor of the controller 100 to initialize and / or configure the logical operations of the executable code 152. The API 156 enables interaction with the module 115. In at least one embodiment, the API 156 includes a unique ID (UID) that uniquely identifies the module 115 from other modules and one or more dependencies that specify functions corresponding to the logical operations of the executable code 152.

[0013] Configuration information 160 includes meta-information including interface descriptions 162, input descriptions 164 of capabilities required by module 115, and output descriptions 166 of capabilities provided by module 115. In at least one embodiment, the purpose of configuration information 160 is to ensure functionally correct configuration of modules.

[0014] The described configurations of the configurable and replaceable modules are examples. Other configurations of the configurable and replaceable modules are within the scope of various embodiments. In at least one embodiment, the configuration of the configurable and replaceable modules does not require any particular technology choice in either the software used, the overall operational purpose, or the scope of the modules. This is comparable to the concept of determining the size and scope of software modules in an application. In at least one embodiment, one or more of the configurable and replaceable modules that make up the controller 100 are provided by a user. In some embodiments, one or more of the configurable and replaceable modules that make up the controller 100 are auto-generated or software-generated.

[0015] In some embodiments, modules rely on the existence and / or description of APIs, such as API 156, provided by other modules to be connected to or substituted for each other. The API allows modules to be configured together, programmatically or automatically, to create a controller component or an entire controller. For example, the same API may be provided by multiple different modules. For example, an audio codec with voice encoding capabilities may provide an encoding API with an optional tag, lossless, corresponding to, for example, a lossless Free Lossless Audio Codec (FLAC) module, or an optional tag, lossy, corresponding to, for example, a lossy MP3 module. The optional tag indicates whether decoding the encoded output returns bit-wise identical input data. In some embodiments, a globally unique API specification combined with the optional tag constitutes a "contract" for configurability and interoperability, ensuring that a module requesting a specific API can utilize any module with the same given API. Modules with the same API are substitutable or interchangeable for each other. In a further example, the same module may have different instances corresponding to different parameters, such as parameters 154, inputs to the module, etc. Such instances of the same module with different parameters are also substitutable or interchangeable. In at least one embodiment, one or more dependencies exposed through a module's API define conditions or requirements that must be provided by other target modules to which this module is connected. In programming terms, such connections are represented, for example, by pointers to objects that provide the necessary APIs or by Remote Procedure Call (RPC) functions on a remote host. In the example configuration of Figure 1, module 116 can be connected downstream from module 115 if the dependencies defining the inputs (requirements) in module 116's API match the dependencies defining the outputs (provisions) in module 115's API 156.

[0016] Further examples are provided below for three configurable and replaceable modules with the following descriptions appearing through the API of each of the three modules. [Table 1]

[0017] As shown above, by using a description language to specify each module's capabilities, configurable parameters, and interface, each of the three modules can be uniquely identified by a unique ID, i.e., "LowPassFilter," "HighPassFilter," and "FLAC," respectively. The remainder of each module's description defines the capabilities it provides, its requirements, and the allowable ranges of its configuration parameters. The allowable ranges describe the range of values ​​each configuration parameter can take and / or the set of possible parameter values. For example, the module "LowPassFilter" provides codecs and filters, requires a codec, and accepts configuration parameters in the ranges "0..9, 1..100, {5, 7, 9}." The module "LowPassFilter" can be connected downstream of the module "HighPassFilter" (as described with reference to Figure 3) because the dependency (codec) defining the input (requirements) of the module "LowPassFilter" matches the dependency (also codec) defining the output (provides) of the module "HighPassFilter."

[0018] In at least one embodiment, by having each module provide a standard description, such as configuration information 160, equivalent but different modules or module instances can be programmatically interchangeable. For example, a compression module configured for a web server can be reused in a logging system as long as the module descriptions are compatible. This module reuse is an advantage in at least one embodiment.

[0019] In some embodiments, in the context of a measurement component 110 receiving measurement data as described herein, descriptions of sensors providing measurement data to the measurement component 110 are provided so that the measurement component 110 can understand the associated sensors or the sensor data provided. There are two types of sensor descriptions. The first type of sensor description is similar to the module description described above and relates to a symbolic description of the sensor, such as a thermistor, packet probe, or energy meter, and the type of data they generate, such as temperature in degrees Celsius, packet loss, or joules. Sensor developers provide this information through specifications. One or more embodiments support classification of sensor types and data, enabling other sensor network and / or IoT efforts to classify both sensor types and data by problem domain in order to utilize the right tool for the right job. By describing sensors using a standard description similar to a module, at least one embodiment achieves one or more of the following advantages: sensors from one domain can be reused in other domains; equivalent but different sensors can be interchangeable; classification can guide the process of configuring “good” modules; and classification can facilitate automation of the process of aggregating measurement data and subsequent reuse of that aggregation among similar sensor classes. The second type of description concerns the inference of meaning from raw sensor data, where the use of taxonomy combined with ontology allows these relationships to be inferred.

[0020] In the example configuration of FIG. 1 , controller components 110, 120, 130, and 140 are interconnected in a loop that is a cognitive control loop, also referred to in some embodiments as an autonomous control loop or a cognitive cycle. In such a cognitive control loop, measurement component 110 is configured to collect measurement data regarding at least one controlled element under the control of controller 100. Analysis component 120 is configured to process the collected measurement data to obtain a current state of the at least one controlled element. Decision component 130 is configured to determine an action to take with respect to the at least one controlled element based on the obtained current state. Action component 140 is configured to execute the determined action with respect to the at least one controlled element in the real world. The action involves a change in the behavior or configuration of the at least one controlled element.

[0021] In at least one embodiment, a cognitive control loop is a consideration for achieving autonomy. A cognitive control loop, as described herein, is executed by controller 100 to control, evaluate, or optimize the operation or configuration of controlled elements, including hardware devices, other controllers in an autonomous network, and sections or domains of an autonomous network. In at least one embodiment, the size and scope of the controller's 100 control or optimization task is defined by a user. In some embodiments, the cognitive control loop comprises machine learning techniques such as Q-learning, supervised learning, semi-supervised learning, unsupervised learning, deep learning, deep reinforcement learning, etc. In some embodiments, at least one memory of controller 100 further includes a knowledge base 190 accessible by at least one of controller components 110, 120, 130, 140, containing a history of previous choices and corresponding results used in machine learning or optimization. In at least one embodiment, knowledge base 190 is shared among multiple controllers in an autonomous network described herein and stored in one or more memories as described herein.

[0022] For example, controlled elements under the control of controller 100 include hardware devices connected to controller 100 via network 170. In the context of a communications network, examples of hardware devices controllable by controller 100 include, but are not limited to, base stations, antennas, transceiver circuitry, content storage, servers, routers, etc. Measurement data 171 received by measurement component 110 via source module 111 includes data regarding the operation of the hardware devices, including, but not limited to, antenna orientation, transmit power, allocatable or in-use resources, beam shape, traffic, number of requests, available storage, etc. In at least one embodiment, measurement component 110 of controller 100 is configured to further receive measurement data 173 regarding the hardware devices, such as temperature, and / or the environment 180 in which controller 100 operates. While the term “sensor data” is used to describe information provided to measurement component 110, not all such information need be collected using sensors. For example, certain information regarding the operation of the hardware devices, such as transmit power or antenna tilt, can be obtained or inferred from control commands at the hardware devices without requiring sensors to collect it. As another example, sensor data includes data obtained via a module of measurement component 110 that accesses historical data in a network information database, such as knowledge base 190. In this description, "sensor data" is also referred to as "telemetry."

[0023] Analysis component 120 analyzes the measurement data collected by measurement component 110 to determine whether the operation of the hardware equipment meets predetermined criteria, such as a predetermined quality of service level. In response to a determination by analysis component 120 that the predetermined criteria are not met by the current operation of the hardware equipment, decision component 130 determines an action to take to improve the current operation of the hardware equipment, for example, by adjusting the tilt angle of an antenna. Action component 140 then executes the action determined by decision component 130, for example, by sending a command 175 to the hardware equipment instructing the hardware equipment to adjust the antenna tilt angle. In some embodiments, action component 140 also sends information about the action taken to measurement component 110 for use in the next control cycle. This completes the recognition control loop.

[0024] If the operation of the hardware equipment is not improved or optimized after several control cycles (e.g., as recognized through history in knowledge base 190), decision component 130 decides to replace the hardware equipment, and action component 140 issues a command to perform the replacement. For example, action component 140 instructs the base station to use another antenna instead of the current antenna or to send a request to a maintenance center to replace the current antenna.

[0025] In a further example, the controlled elements under the control of controller 100 include other controllers in an autonomous network as described herein. In at least one embodiment, a cognitive control loop is executed by controller 100 to control, optimize, or evaluate the operation or configuration of the other controllers under its control. If decision component 130 determines that corrective action should be taken, action component 140 instructs or causes the other controllers under its control to change their operation or configuration. A change in the operation of the other controllers under its control, in at least one embodiment, involves a change in the operation of hardware devices directly or indirectly controlled by the other controllers. A change in the configuration of the other controllers under its control, in at least one embodiment, is effected by changing the configuration of the modules or controller graphs to which the modules in the other controllers under its control are interconnected, for example, as in the controller deployment described herein.

[0026] In some embodiments, each controller element 110, 120, 130, 140 operates on a time scale independent of the others. For example, sensing by measurement component 110 is a continuous process, while analysis by analysis component 120 occurs ad hoc to interpret collected data. Decisions by decision component 130 are periodic or triggered by changes or events in the environment and / or controlled elements, and actions by action component 140 are responsive to the decisions.

[0027] Here, each controller element is a configuration of modules interconnected according to a controller graph. Examples of various configurations and / or graphs for implementing the same controller component are provided with respect to FIG. 3. The controller 100 is visualized as a unidirectional graph (controller graph) for each controller component in the recognition loop. Each node in this controller graph represents one module instance. The root of this controller graph is a sink module (e.g., 112, 122, 132, 142) that responds to the required input of the next controller component in the recognition loop. The purpose of the sink modules (e.g., 112, 122, 132, 142) is to ensure that each controller component (e.g., 110, 120, 130, 140) provides everything needed for the next controller component (e.g., 120, 130, 140, 110) in the controller 100. In at least one embodiment, at least one sink module (eg, 112, 122, 132, 142) is a mirror image of the corresponding source module (eg, 121, 131, 141, 111).

[0028] As described herein, a module may have any number of dependencies (i.e., APIs defined in the module description), and the vertices in the controller graph represent these dependencies. However, the structure of the controller graph is not fixed. Arbitrarily complex graphs are possible, as the dependencies of each module instance (node) guide the construction of the subgraph starting at that node.

[0029] Creation of controller configurations from scratch, rearrangement, substitution, and manipulation through reconfiguration allow some embodiments to adapt to both new and changing situations. While the example configuration in FIG. 1 depicts controller 100 as including four interconnected controller components embodying the measurement, analysis, decision, and action stages, at least one embodiment could implement controller 100 as a single configuration. However, the described configuration of four controller components facilitates understanding (human and machine) and reduces the state space of potential modular configurations. In at least one embodiment, a user-defined utility function provides a metric for measuring the suitability or utility of a controller. Specific utility functions are provided below as examples with respect to FIG. 6. Other utility functions and / or configurations involving automatic generation of utility functions are not excluded. In at least one embodiment, a controller's utility function is described in the controller specification or included in its software. In at least one embodiment, a utility function is included in at least one of the configurable and replaceable modules that comprise the controller.

[0030] Additionally, in some embodiments, all controller components share access to persistent knowledge through knowledge base 190. This configuration facilitates understanding of previous choices and corresponding outcomes, changing system states, and synchronization across different update periods. In at least one embodiment, the knowledge to be stored varies by specific controller and is available to different controllers when applicable. In at least one embodiment, the knowledge storage results in a consistent, distributed data storage.

[0031] FIG. 2 is a schematic block diagram of a section of an autonomous network 200 according to some embodiments. The section of autonomous network 200 in FIG. 2 is a control plane comprising multiple controllers. Autonomous network 200 further comprises hardware devices controlled by operational controllers of the controllers illustrated in FIG. 2. For simplicity, the hardware devices are not shown in FIG. 2. Examples of hardware devices are described herein and include, but are not limited to, base stations, antennas, transceiver circuitry, content storage, servers, routers, etc. Furthermore, the control plane in FIG. 2 is an example of a specific use case for traffic shaping and antenna tilt optimization. Other arrangements of controllers and / or other use cases are within the scope of various embodiments.

[0032] In at least one embodiment, each controller in autonomous network 200 has a configuration as described with respect to FIG. 1. The multiple controllers in autonomous network 200 are interconnected in a system hierarchy graph, as illustrated in FIG. 2. The system hierarchy graph shown is an example. Other system hierarchy graphs are within the scope of various embodiments. The multiple controllers in autonomous network 200 include at least one operation controller (OC) and at least one deployment controller (EC). An OC is configured to control changes in the operation of at least one controlled element below the OC in the system hierarchy graph. For example, an OC is configured to control a hardware device (not shown in FIG. 2) or another OC. An EC is configured to control the configuration of at least one controlled element below the EC in the system hierarchy graph. For example, an EC is configured to control a hardware device (not shown in FIG. 2) or another controller that is an EC or an OC.

[0033] In the example configuration of FIG. 2, an autonomous network 200 includes ECs 210, 220, 222, 230, 232, 240, 242, and 244, and OCs 250, 252, 260, 262, 272, 272, and 274. Control performed by an EC is referred to as deployment control. Control performed by an OC is referred to as operational control. An OC that directly controls hardware devices is referred to as a local OC. An OC that controls other OCs is referred to as a global OC. An EC that controls a local OC is referred to as a local EC. An EC that controls a global OC is referred to as a global EC. The global and local ECs are controlled by a meta EC, which is controlled by a master EC 210 at the highest level of the system hierarchy graph of FIG. 2.

[0034] In at least one embodiment, the system hierarchy graph illustrated in Figure 2 is adaptive and includes a hierarchy of controllers that is defined at runtime. As previously mentioned, the controllers in autonomous network 200 include two different types of controllers within the same hierarchy: one type is an EC for enabling deployment, and the other type is an OC for operational tasks.

[0035] An EC is configured to determine when and how to deploy controllers in subgraphs below it in the system hierarchy graph. Each EC is configured to define its own dependencies in its corresponding software section (similar to 150 in FIG. 1). That is, each EC defines the type (EC or OC) and number (number of OCs, number of ECs) of controllers it requires in its immediate layer or subgraph, either in software as described herein or directly in its corresponding controller description. In at least one embodiment, this is implemented through a special API dependency exposed through the EC's API. This special API dependency returns specifications or configurations for each of the controllers to be instantiated on the layer or subgraph immediately below the current EC. For example, global EC 230 is configured to determine when and how to deploy global OC 250 and has a special API dependency that returns the specifications for global OC 250 on the layer or subgraph immediately below global EC 230. As another example, the meta EC 220 is configured to determine when and how to deploy the global EC 230 and the local ECs 240, 242, and has one or more special API dependencies that return specifications for each of the global EC 230 and the local ECs 240, 242 in the layer or subgraph immediately below the meta EC 220. In at least one embodiment, an EC is configured to have the freedom, exposed through a special API dependency in its API, to determine how to compute its utility function based on the utility functions of one or more ECs or OCs in its immediate subordinates, i.e., its immediate subgraph. In at least one embodiment, an EC is configured to have the additional freedom, exposed through a further special API dependency in its API, to determine when its subordinate subgraphs should change, i.e., when to add or remove a subordinate controller, or when to reconfigure or restructure a subordinate controller.In at least one embodiment, the EC is configured to apply independently deployed OCs, for example, on a data center-by-data center, region-by-region, or globally basis, compare the results, and determine which approach is most efficient, as measured by the EC's utility function.

[0036] On the other hand, OCs are configured to control network elements (hardware devices) and other OCs. OCs are not configured to affect the system hierarchy graph of autonomous network 200 or the deployment process of autonomous network 200. OCs can be controlled by both other OCs and ECs. For example, local OC 262 is operationally controlled by global OC 250 and configurationally controlled by local EC 242. In some embodiments, ECs control the configuration of controllers below the EC (and the hierarchy branches, subgraphs below the EC), and OCs direct the operation of their direct (subordinate) OCs and / or controlled elements (e.g., hardware devices).

[0037] In the example configuration of FIG. 2, the autonomous network 200 is configured to handle both traffic shaping and antenna tilt optimization. For traffic shaping, a global OC 250 determines high-level weightings for each location, and two local OCs 260, 262 shape traffic according to the global weightings. These OCs 250, 260, 262 are independently deployed by corresponding local or global OCs 230, 240, 242. For antenna tilt, all three local OCs 270, 272, 274 are deployed by a single local EC 244 and are operationally controlled by the global OC 252. The global OC 252 is deployed by the global OC 232. All global and local ECs for traffic shaping and antenna tilt optimization, respectively, are deployed through corresponding meta ECs 220, 222, which are deployed by the master EC 210.

[0038] In at least one embodiment, the purpose of creating a hierarchy of OCs is to separate local decisions that may require fast responses from more deliberate global decisions that may be implemented more slowly. For example, a single base station controller (local OC) may be configured to quickly decide to adjust its antenna tilt based on the number and conditions of connected devices, while a global OC may obtain feedback from many local OCs and provide more general policy decisions at greater temporal granularity. Higher and lower level OCs may be configured to collaborate to solve some use cases, for example, through solving optimization problems or being deployed by ECs to do so. Whether a dedicated controller is used to oversee lower level controllers (or hardware devices) or to utilize a shared controller depends on various design factors, such as the specific application, controller configuration, and deployment outcomes. The embodiments described herein provide sufficient flexibility to accommodate various design factors.

[0039] The hierarchical ordering of ECs often allows some embodiments to apply different deployment approaches depending on the task at hand and the operating environment on which the optimization or adaptation strategy depends. For example, an optimization strategy for resource allocation in an input data center may differ from a regional strategy (different time scales, explicit assignment of weights to devices per application group, etc.). The mapping of master ECs to subordinate ECs follows a similar logic.

[0040] In some embodiments, one or more description languages ​​for describing modules and / or sensors described herein can be used to describe controllers. The description languages ​​enable functional configuration and semantics to be derived from sensor data. Such languages ​​provide a standardization layer that allows a system to programmatically understand and reason about the functional building blocks (e.g., modules and / or controllers) and sensors provided. Additionally, in at least one embodiment, the description language allows for the addition of one or more new or evolving controllers or hierarchies (e.g., controller subgraphs) by setting constraints on the controllers and / or controller hierarchy branches (e.g., controller subgraphs) and / or corresponding utility functions.

[0041] In at least one embodiment, the description language also sets constraints that guide which controllers should be present in the autonomous network 200 for a particular application or function. As described with respect to Figure 1, each controller comprises multiple controller components or phases, such as measure, analyze, decide, and act phases. Connections between the controller components or phases are provided through corresponding source and sink modules of each controller component or phase.

[0042] Like the modules, each controller in the embodiment has a respective API, software (code), and one or more dependencies or requirements. The requirements are described in a description language and are exposed through the API. An example of a description language for describing constraints or requirements that are applied to the OCs and ECs for load balancing and are exposed through the OC and EC APIs is provided below. [Table 2]

[0043] In the load balancing example above, the OC has a unique ID "LoadBalancer" and multiple requests "ReqOutputs" for the measurement, analysis, decision, and action phases, respectively. The request for the measurement phase includes link statistics "LinkStats," device resource statistics "MachineResourceStats," query statistics "QueryStats," and load balancing performance statistics "LBPerfStats." The request for the analysis phase includes net load per second "NetLoadPerSecond," device load per second "MachineLoadPerSecond," queries per second "QPS," query success rate "QuerySuccessRatio," and query latency score per second "QueryLatencyScorePerSecond." The request for the decision phase includes link weights "LinkWeights" and device weights "MachWeights." The request for the action phase includes Domain Name System (DNS) weight assignments "DNSWeightAssignments" and device job assignments "MachJobAssignments." The OC's utility function, "Utility," is "Product(QPS, QuerySuccessRatio, QueryLatencyScore)," i.e., the product of "QPS," "QuerySuccessRatio," and "QueryLatencyScore." In at least one embodiment, the OC executes a recognition loop to solve an optimization problem to optimize its utility function. If the value of the utility function is within a predetermined target range, the OC does not make adjustments to controlled elements, such as the content server and / or DNS, as described with reference to FIG. 6. On the other hand, if the value of the utility function is outside the predetermined target range, the OC alters the operation of controlled elements, for example, by modifying "DNSWeightAssignments" and / or "MachJobAssignments," so that the value of the utility function falls within the predetermined target range.

[0044] Continuing with the load balancing example above, the EC is "LoadBalancerEvoCtlr" and is responsible for deploying two different load balancing OCs (lower-level controllers), both of type "LoadBalancer." The EC has a special API dependency or request, "ReqControllers," denoted as "LoadBalancer(2)," that specifies the type of lower-level controllers in the layer or subgraph immediately below the EC (i.e., "LoadBalancer") and the number of lower-level controllers of each controller type (i.e., "2"). The EC also has multiple requests, "ReqOutputs," for the measurement, analysis, decision, and action phases, respectively. The request for the measurement phase includes statistics for the lower-level controllers, "LoadBalancerStats(2)," and environment statistics, "EnvironmentStats," indicating whether environmental characteristics have changed. The request for the analysis phase includes a utility function, "ControllerUtility(2)," for the two lower-level controllers and "EnvironmentStats," indicating information extracted from environmental statistics, such as whether the current temperature is high or low. The request for the decision phase includes "ControllerPlans(2)" which indicates the particular controller that has not yet been instantiated. The request for the action phase includes the configurations of the subordinate controllers, "LoadBalancer(0)" and "LoadBalancer(1)," i.e., "ControllerComposition(LoadBalancer(0))" and "ControllerComposition(LoadBalancer(1))," respectively. As described herein, the configuration of each subordinate controller includes not only the number and type of modules, but also the manner in which the modules are interconnected to form the controller (e.g., the controller graph). The utility function of the EC, "Utility," is the average of the utility functions of the two subordinate controllers, denoted as "Avg(ControllerUtility(2))." In at least one embodiment, the EC executes a recognition loop to solve an optimization problem to optimize its utility function.If the value of the utility function is within a predetermined target range, the EC makes no adjustments to the underlying controller, i.e., OC "LoadBalancer." On the other hand, if the value of the EC's utility function is outside the predetermined target range, the EC changes the configuration, i.e., the specifications or configuration of at least one of the underlying controllers, so that the value of the EC's utility function falls within the predetermined target range. In at least one embodiment, the EC optimizes its utility function for deployment or for creating a new controller.

[0045] While in the above examples, the required outputs for each controller were explicitly specified, the required inputs are obtained directly from the configuration requirements that provide the required outputs. In at least one embodiment, these input requirements also lead to additional output requirements for previous phases. Furthermore, while in the above examples the EC utility function used to evaluate all subordinate controllers was specified directly in the EC specification, in at least one embodiment the EC utility function may be specified in the EC software.

[0046] In at least one embodiment, advantages of autonomous network 200 include not only the ability to adapt the behavior of controlled network entities but also the ability to evolve itself. Specifically, as described with respect to FIG. 1, a controller in autonomous network 200 configures itself from available configurable and replaceable modules by selecting a new or existing instance of a configurable and replaceable module that provides a dependency for a node (module instance) already in the controller graph and "plugging" (inserting or adding) the selected new or existing instance into the dependency "slot." This process continues until all dependencies for all modules in the controller are satisfied. In at least one embodiment, the final request "layer" in this controller graph is interpreted as a mirror image of the sink module of the previous controller component, i.e., provided by a source module that provides all data made available by the previous controller component in the recognition loop.

[0047] 3 includes schematic block diagrams of some of the deployed controller portions in a controller deployment according to some embodiments. The deployed controller is an EC or OC in the autonomous network 200. The controller performing this controller deployment is the EC that controls the deployed controller. For example, the deployed controller is the OC 260, and the controller performing this controller deployment is the EC 240.

[0048] In FIG. 3 , the set of all potentially valid controllers—i.e., all valid configurations of module instances, such as candidate modules 303-311—and those configurations define a search space 300 explored by EC 240 during the controller deployment process of OC 260. The search space or domain 300 of all valid configurations is represented by all possible paths (controller graphs) through all available modules from source module 301 to sink module 302 in FIG. 3 . EC 240 is configured to identify and utilize one or more or any possible solutions within search domain 300 to instantiate a controller. As a result, two valid controller configurations 320 and 330 are obtained. The valid controller configurations 320 and 330 differ in the interconnected modules and / or the configuration of the controller graphs to which the modules are interconnected. Note that valid controller configuration 320 includes connections between modules “LowPassFilter” and “HighPassFilter” based on the corresponding dependency relationships described above. The two identified valid controller configurations 320, 330 are designated as candidates for subsequent online trials, as described with respect to FIG.

[0049] In at least one embodiment, valid controller configurations 320 and 330 are identified based on the same utility function of the existing OC 260. As a result, the valid controller configurations 320 and 330 are candidates for the deployed controller of the OC 260. In a further embodiment, the valid controller configurations 320 and 330 are identified based on a utility function that is different from the utility function of the existing OC 260. As a result, the valid controller configurations 320 and 330 are candidates for the new controller because the different utility functions indicate different targets (or objectives) for performance or operational optimization. For example, while the current utility function of the OC 260 is aimed at optimizing load balancing, a different utility function is aimed at optimizing cost, resulting in a different new controller. For simplicity, the terms "deployed controller" and "new controller" are used synonymously unless otherwise specified.

[0050] In at least one embodiment, the EC 240 is configured to evaluate the in-service performance of the OC 260 and the performance of the identified valid controller configurations 320, 330 during online trials using the same utility function of the EC 240. If, based on the evaluation by the EC 240, one or more of the identified valid controller configurations 320, 330 is found to provide better performance than the OC 260 (e.g., a higher value of the utility function of the EC 240), the better-performing identified valid controller configuration 320 or 330 is included as a new controller in the controller repository for use by other ECs or other autonomous networks and / or for use by the EC 240 in place of the OC 260.

[0051] In at least one embodiment, the ECs 240 are themselves controlled or evaluated by other ECs, such as the meta EC 220. For example, the meta EC 220 uses its own utility function to evaluate how quickly and / or accurately the ECs 240 can explore the search space 300 and identify effective controller configurations, such as 320 and 330. In the example configuration in FIG. 3 , the number of all possible paths (controller graphs) and all available modules is limited for illustrative purposes. In some embodiments in real-world operation, the search space 300 is large, including hundreds, thousands, or more of possible paths and available modules. The ECs 240 are configured to use a search algorithm to explore such a large search space 300 and identify effective controller configurations. The search algorithm may be included, for example, in one of the configurable and replaceable modules that make up the EC 240. If the meta EC 220 determines through its utility function that the search time and / or accuracy of the search algorithm used by the EC 240 to search the search space 300 is unacceptable, the meta EC 220 is configured to change the configuration of the EC 240, for example, by changing the module containing the current search algorithm to another module containing a different search algorithm, and re-evaluate the performance of the deployed ECs, for example, through online trials as described herein. In at least one embodiment, due to the large size of the search space 300, there is a trade-off between the speed at which the EC 240 searches the search space 300 and the accuracy of the points in the search space 300 (e.g., valid controller configurations) found by the EC 240. The meta EC 220 is configured to solve an optimization problem to arrive at an optimal solution, i.e., an optimal configuration of the EC 240 that enables the EC 240 to search the search space 300 with both acceptable search time and accuracy. The control or deployment of the described ECs by other higher-level ECs is an example. Other configurations are also within the scope of various embodiments.

[0052] In addition to the controller deployment described with respect to Figure 3, another aspect of autonomous network 200 according to some embodiments includes hierarchical deployment. In contrast to controller deployment, which involves changing the configuration of modules and the controller graph in which the modules are interconnected in the controllers, hierarchical deployment involves changing the configuration of controllers and the system hierarchical graph in which the controllers are interconnected in the deployed autonomous network.

[0053] In at least one embodiment, each EC is configured to determine how the subgraphs of controllers below it in the system hierarchy graph are configured at runtime. Thus, configuring controllers in the system hierarchy graph is an iterative process. The root of the system hierarchy graph, i.e., the master EC 210, is first instantiated and queried about its intentions regarding the configuration of the subgraphs below it. Corresponding controller instances for the subgraphs below the master EC are then instantiated at the master EC's request. The same process continues iteratively for all subordinate ECs. As previously mentioned, OCs do not have the freedom to choose their dependencies at runtime; instead, in at least one embodiment, the OC's dependency graph is obtained via an administrator-defined specification.

[0054] If, as a result of recognition loop control, the EC decides to change the configuration of a managed subgraph, the configuration method described above is applied only to that subgraph.

[0055] The set of all potentially valid system hierarchy graphs or subgraphs constitutes the search space that is explored by the corresponding EC in the evolution process. In some situations, due to the excessive overhead of exploring all valid graphs through instantiation, an iterative exploration process is used according to some embodiments. In at least one embodiment, full instantiation of each controller just to determine the hierarchy is not necessary; instead, only modules that provide the required APIs and dependencies are instantiated.

[0056] FIG. 4 is a schematic block diagram of a portion of an autonomous network 400 in an online trial for controller deployment according to some embodiments.

[0057] Autonomous network 400 corresponds to autonomous network 200, but with the addition of attempt manager 420. Attempt manager 420 comprises at least one memory (not shown in FIG. 4) and at least one processor (not shown in FIG. 4) coupled to the at least one memory, for example, as described with respect to the computer hardware configuration in FIG. 10. In some embodiments, attempt manager 420 is a process separate from the controller of autonomous network 400.

[0058] In the scenario of FIG. 4 , controller 100 is an EC configured to deploy OC 410. As described with respect to FIG. 2 , one or more configurable and replaceable modules for deploying OC 410 are obtained from module repository 409. In some embodiments, module repository 409 is stored in at least one memory of controller 100. In one or more embodiments, module repository 409 is stored on a shared storage device accessible by one or more other controllers in autonomous network 400. One or more configurable and replaceable candidate modules suitable for deployment of OC 410 are retrieved from module repository 409 by controller 100. While FIG. 3 describes a controller deployment example in which the complete controller graph from source module to sink module is deployed, one or more embodiments may deploy only a section, such as a subgraph, of the controller graph of OC 410. In at least one embodiment, controller deployment involves replacing existing modules in a deployed subgraph of OC 410 with different instances of the same module or with different configurable and replaceable modules and / or modifying the subgraph or controller graph of OC 410. Controller 100 uses candidate modules retrieved from module repository 409 to construct all possible paths for the deployed controller graph or subgraph and indicates one or more valid configurations as corresponding one or more deployed controllers, as described with respect to FIG.

[0059] The deployed controllers are then sent to trial manager 420 for online trials for evaluation. The reason for this online trial is that the ability to programmatically deploy controllers allows, in some embodiments, the automatic generation of large numbers of new or deployed controllers. Online trials are performed to understand the usefulness or suitability of these new or deployed controllers for application in several domains of control.

[0060] In at least one embodiment, the trial manager 420 is configured to perform online trials as online trial-and-error trials in a multi-tiered approach to trials. First, a new or deployed controller is subjected to a sanity check 421 to ensure that it does not contain a logical error. For example, a new or deployed controller that attempts to use a non-existent optical sensor module contains a logical error. In at least one embodiment, the use of a taxonomy and an ontology assists in this sanity check 421.

[0061] The new or deployed controllers are then tested in simulation 422 to initially assess their utility using a utility function, e.g., as described herein. Several simulation tools are available as indicators of potential success or immediate failure. Based on this information, trial manager 420 is configured to ultimately determine whether the new or deployed controller will proceed to the next stage, where it will be gradually tested in a real production network, such as a real communications network. For network trials, trial manager 420 is configured to limit the scope (physical and temporal) of the new or deployed controller to be tested, gradually expanding it based on the measured (or assessed) utility function of the new or deployed controller.

[0062] While overseeing the trial trials of a new or deployed controller, the trial manager 420 may be configured to coordinate different ongoing trials. This is a consideration in situations where there are multiple ECs or master ECs requesting online trials of a newly deployed controller. Intuitively, it may seem impossible to run all online trials simultaneously due to the risk of conflicts and false availability if the trials interfere with each other. Additionally, there are risks of instability, interference in high-gain operation, test priorities, etc. Because communication networks are large interconnected systems, interference is inevitable. However, the trial manager 420 is configured to limit this, for example, by functioning as or including a scheduler 423, a resource allocator 425, and / or a trial independence guarantor 424.

[0063] In some embodiments, the trial independence ensurer 424 ensures that trials are performed independently of each other, because a fair comparison of the performance of different controllers depends on the controllers being evaluated in a context that does not give any of them an unfair advantage. In at least one embodiment, the trial independence ensurer 424 ensures that trials are meaningful and represent real-world operating environments. For example, in a trial, a messaging protocol running over Transmission Control Protocol (TCP) is evaluated against another protocol that uses User Datagram Protocol (UDP) using a utility metric (utility function) based on throughput, delay, and reliability. As long as the trial is performed over a reliable transport without packet loss or reordering, UDP has an unfair advantage due to its low overhead (no three-way handshake and small header size). However, once the transport becomes unreliable due to changes in the environment or the impact of other concurrent trials on the transport layer, TCP's ability to guarantee retransmission and request for input packets may put it in an advantageous position. The trial independence ensurer 424 is configured to ensure that trial setup for one controller does not affect other trial setups for other controllers.

[0064] In an online trial, the new or deployed controller under test, its parameter configuration, utility function, current trial range, and results are collected, and one or more of this information is stored in the trial repository 426 of the trial manager 420 for later reference and / or learning. The results are used by the trial manager 420 of the requesting EC, i.e., either the controller 100, to determine whether the new or deployed controller under trial should replace the existing controller 410. Based on the information provided, the controller 100 and / or trial manager 420 can infer potential conflicts in the trial.

[0065] 5 is a flowchart of a method 500 in an autonomous network according to some embodiments. In at least one embodiment, the method 500 is performed by the autonomous network 400 described with respect to FIG.

[0066] In operation 505, the OC controls hardware devices or other OCs below it in the system hierarchy graph of the autonomous network, as described with respect to FIG.

[0067] In operation 525, the EC controls and deploys existing controllers below it in the system hierarchy graph, as described with respect to Figure 3. For example, in operation 530, a number of configurable and replaceable candidate modules are identified, for example, as described with respect to modules 303-311 in Figure 3. In operation 535, multiple different configurations in which various candidate modules are interconnected to complete sections of the controller graph are identified, as described with respect to controller configurations 320, 330 in Figure 3. In operation 540, the configurations of the candidate modules obtained in operation 535 are output as the controllers to be deployed, as described with respect to Figure 4.

[0068] In operation 545, the deployed controller is subjected to an online trial to determine whether the existing controller can be replaced by any of the multiple deployed controllers, as described with respect to FIGURE 4. For example, the online trial may include a sanity check in operation 550, a simulation in operation 555, and a network trial in operation 560. In at least one embodiment, if any of the sanity checks, simulations, or network trials fail, the deployed controller is determined to be unsuitable to replace the existing controller. If the online trial indicates that the deployed controller is suitable to replace the existing controller, the EC performing the controller deployment is configured to implement the replacement and / or make the deployed controller available to other ECs in the autonomous network.

[0069] An example of an autonomous network according to some embodiments will be described in the context of a CDN. A content delivery network (CDN) geographically distributes content and provides services to customers and end users to improve latency, throughput, availability, and resilience. Once focused on improving download and streaming performance through caching, CDNs now offer many additional services, such as mobile content acceleration, content transcoding, Distributed Denial of Service (DDoS) attack protection, and web application firewalls. Through increased compute capabilities, CDNs are transforming into mobile edge compute providers. By their very nature, CDNs must ensure high availability (resilience) in the event of failure and provide over-provisioning services to handle spikes in demand. In some situations, simply providing content at multiple locations does not necessarily ensure that the load is evenly or optimally distributed among the different locations. Some considerations for optimizing CDN performance include traffic load balancing, compute load balancing, and content placement. Each of these aspects can be improved by an autonomous network according to one or more embodiments.

[0070] FIG. 6 is a schematic block diagram of a traffic load balancing section 600 of an autonomous network for a CDN according to some embodiments.

[0071] Historically, clients accessed content and services via the transport layer, which routes them to a single server hosting the destination IP address. When the same content is served from multiple locations, this approach is no longer sufficient. Static assignments are inherently suboptimal because user demand fluctuates and, in some cases, can become erratic. To address this issue, some embodiments provide a dynamic, DNS-based approach where the approximate delay from each IP range to each serving location is known, and each Point of Presence (PoP) is assigned its own IP range.

[0072] In the example configuration in Figure 6, the traffic load balancing section 600 of the autonomous network comprises a global OC in the form of a controller 610 (also referred to as "global OC 610") configured to distribute weights for each of PoPs 620, 630, 640 (e.g., content servers for each area 1-3) and provide services (AD) to a distributed anycast DNS server 650. The controller 610 has a configuration corresponding to the controller 100. The DNS server 650 corresponds to a controlled element or hardware device under the control of the controller 610. The weights for each of the PoPs 620, 630, 640 are distributed to the DNS server 650 via an update 660. The DNS server 650 then reports via telemetry 670 the number of responses for each (service, PoP) pair that it sent during the previous cycle. Similarly, PoPs 620, 630, and 640 report ingress and egress link loads, service utilization rates, and capacity to the controller 610 via telemetry 680. Furthermore, the controller 610 has information about the priority, such as the importance or usefulness, of each Service AD, as well as its delay and bandwidth requirements. A client 601 sends a query for content (at least one of the Service ADs) to a DNS server 650 via link 605. Based on the service requested by the client and the weights for each of the PoPs 620, 630, and 640 provided by the controller 610, the DNS server 650 redirects the client 601 to one or more appropriate PoPs 620, 630, and 640. The client 601, redirected by the DNS server 650, accesses one or more PoPs 620, 630, and 640 via one or more links 602, 603, and 604 to receive the requested service.

[0073] Example requirements that global OC 610 is configured to meet are detailed in Table 1 (Table 3). Based on these requirements, modules are specified in Table 2 (Table 4) from which global OC 610 is configured. For each module in Table 2, a corresponding description in the specification language of its capabilities and interfaces is provided. An example set of module configurations for the measurement phase of global OC 610 is shown in FIG. 7A. Not all of the listed modules are uniquely associated with the task of traffic load balancing. Each of the sensing modules is also usable by the CDN health monitoring controller. Thus, module reuse is an advantage in at least one embodiment.

[0074] Table 1: Example of Controller Component (Phase) Requests (Outputs) for Global OC610 [Table 3]

[0075] Table 2: Example of modules per controller component (phase) [Table 4]

[0076] Using this information, the traffic load balancing section 600 obtains the basic input for generating and deploying a controller for the CDN traffic load balancing task. By using the analysis and measurement component, the controller 610 can understand how its actions (i.e., weightings) will affect service operations in the current environmental context. The decision component of the controller 610 can then decide how to modify the weights communicated to the DNS server 650 by the action component of the controller 610.

[0077] The utility function provides a means of understanding how well the overall weightings match the current conditions of the network. Below is an example utility function:

number

[0078] An EC is provided to design and redesign (deploy) the global OC 610. The EC is not only configured to ensure that the global OC 610 achieves the goal of efficient traffic load balancing, but also finds new / deployed OCs based on available modules that may outperform the existing global OC 610. Current and historical data from the network, a classification of the environment, a current blueprint of the global OC 610, and a definition of the usability of the global OC 610 are used by the EC. In this example, the EC makes decisions over a period of time as suggested by historical data. A list of example EC modules is shown in Table 3 (Table 5). This list is not exhaustive.

[0079] Table 3: EC modules for traffic load balancing [Table 5]

[0080] If the global OC 610 cannot perform the task of a given situation effectively enough, as determined by the measured or estimated utility function, the EC is configured to decide to replace it with another existing or new OC. If the situation changes and a different controller performs better than the current controller under the new conditions, the EC is configured to replace the OC again. If no OC with sufficient performance is found, the EC is configured to generate a new controller configuration.

[0081] Next, trial-and-error trials were performed to verify whether the newly deployed controller would actually do a better job than other existing controllers at balancing traffic load under current conditions. "Better" was defined as providing a higher utility function value when measured using the same utility function as the current controller. First, sanity checks were performed to ensure the integrity of the new controller. Sanity checks ensured that all actions the controller could request were restricted to the load balancing domain and that actions were not taken in other domains. Other checks ensured that the new controller could proceed without running into so-called deadlock situations. Second, simulations were used to verify that the new controller performed as expected. For example, once the new controller was instantiated in a sandbox environment and provided with recorded sensor data, request logs for the period during which the new weights were applied were used to evaluate how the weight changes made by the new controller affected the actual load balancing, and utility function values ​​for these changes were calculated. Furthermore, it was verified that sudden changes and fluctuations in assignments that could move large amounts of traffic from one location to another were infrequent or nonexistent. Third, the new controller is gradually rolled out in the network (starting with low-impact areas or less critical services for a limited time). If performance is poor, it is reverted to its pre-trial state before the end of the allotted trial period. Otherwise, the trial is extended for more critical areas and services. These stages are fully automated by the EC and / or trial management.

[0082] 7A-7D are schematic block diagrams of first through fourth configurations 710A-710D of measurement components according to some embodiments. In at least one embodiment, the measurement components correspond to the measurement components of controller 610 described with respect to FIG. 6.

[0083] In FIG. 7A, a first configuration 710A of the measurement component includes four source modules 711, 712, 713, and 714 corresponding to the modules for the measurement phase listed in Table 2, an aggregation module 715, and a sink module, or reporting module 716. The source modules 711, 712, 713, and 714 are configured to receive measurement data from various sources, such as telemetry 670 and 680 in FIG. 6. The aggregation module 715 is configured to aggregate the various measurement data for the reporting module 716. The sink module, or reporting module 716, is connected to a source module 721 of the next phase, or analysis component 720, to provide the aggregated measurement data to the analysis component 720. The reporting module 716 is further configured to exchange data with the knowledge base 190.

[0084] 7B-7D show second through fourth configurations 710B-710D of the measurement component in the deployed or new controller generated by the EC based on the first configuration 710A. For simplicity, the analysis component 720 and knowledge base 190 are not shown in FIGS. 7B-7D.

[0085] The second configuration 710B of measurement components in Figure 7B includes the same modules as Figure 7A but is interconnected differently: two source modules 711, 712 are connected to an aggregation module 715, while the other two source modules 713, 714 are connected directly to a reporting module 716.

[0086] A third configuration 710C of measurement components in Figure 7C includes most of the modules of Figure 7A except for an aggregation module 715. Because of the absence of the aggregation module 715, all source modules 711, 712, 713, 714 are directly connected to a reporting module 716.

[0087] The fourth configuration 710D of the measurement components in Figure 7D is similar to the second configuration 710B in Figure 7B, except that the two source modules 711, 714 are omitted. Configurations 710A-710D are examples, and other configurations are within the scope of various embodiments. In at least one embodiment, the measurement components are deployed from one of configurations 710A-710D to another, for example, depending on the deployment of a controller with the measurement components or a decision phase of the EC responsible for control.

[0088] In some embodiments, the concept of cognitive loops enables interaction and collaboration between multiple independently designed control and optimization tasks. Controller hierarchy allows these tasks to be integrated in a holistic manner, with higher-level cognitive loops supervising, controlling, and evolving their subordinates. Evolution is achieved through appropriate cognitive, learning, and / or optimization strategies. This online evolution is enabled by functional configuration and trial evaluation. Functional configuration allows some embodiments to compose novel and unique controllers on their own using small functional building blocks (modules). These controllers are not limited to controlling and improving the operation of the network infrastructure, but also modify and improve the architecture and functionality of the control system itself at runtime. Furthermore, some embodiments enable seamless incorporation of new technologies and research findings as they become available. Trial deployment allows some embodiments to test and validate the actual performance of these autonomously deployed controllers in a real network. By combining one or more or all of these techniques, some embodiments can achieve truly autonomous control and optimization in a generative manner.

[0089] 8 is a block diagram of example computer hardware 800 according to some embodiments. The computer hardware 800 is configurable to operate as a controller and / or attempt manager as described herein. The computer hardware 800 includes at least one hardware processor 802 and at least one non-transitory computer-readable storage medium or memory 804. In at least one embodiment, the computer hardware 800 further includes a bus 808, an input / output (I / O) interface 810, and / or a network interface circuit 812.

[0090] The processor 802 is configured to execute computer program code, such as configurable and replaceable modules in the storage medium 804, to cause the computer hardware 800 to perform some or all of the processes and / or methods described. In one or more embodiments, the processor 802 comprises a central processing unit (CPU), a multiprocessor, a distributed processing system, an application specific integrated circuit (ASIC), and / or other suitable processing unit.

[0091] The storage medium 804 is encoded with (i.e., stores) computer program code, i.e., configurable and replaceable modules 806, executed by the processor 802, among other things. In one or more embodiments, the storage medium 804 comprises an electronic, magnetic, optical, electromagnetic, infrared, and / or semiconductor system (or apparatus or device). For example, the storage medium 804 includes semiconductor or solid-state memory, magnetic tape, floppy disk, random access memory (RAM), read-only memory (ROM), rigid magnetic disk, and / or optical disk. In one or more embodiments using an optical disk, the storage medium 804 includes a CD read-only memory (CD-ROM), a CD read / write (CD-R / W), and / or a digital video disk (DVD).

[0092] I / O interface 810 includes input devices, output devices, and / or combined input / output devices to allow a user and / or external circuits / equipment to interact with computer hardware 800. Input devices include, for example, a keyboard, keypad, mouse, trackball, trackpad, touch screen, and / or cursor keys for communicating information and commands to processor 802. Output devices include, for example, a display, printer, voice synthesizer, etc. for conveying information to a user.

[0093] The network interface circuitry 812 is connected to a network 814 so that the processor 802 and the storage medium 804 can connect to other devices via the network 810. The network interface circuitry 804 includes wireless network interfaces such as BLUETOOTH, WIFI, and WIMAX, and wired network interfaces such as ETHERNET, USB, and IEEE-1364.

[0094] In some embodiments, some or all of the described processes and / or methods are implemented as a stand-alone software application for execution by a processor. In some embodiments, some or all of the described processes and / or methods are implemented as a software application that is part of an additional software application. In some embodiments, some or all of the described processes and / or methods are implemented as a plug-in to a software application.

[0095] The described methods and algorithms include example operations, but are not necessarily required to be performed in the order presented. Operations may be added, substituted, reordered, and / or deleted where appropriate, in accordance with the spirit and scope of the disclosed embodiments. Embodiments that combine different features and / or different embodiments are within the scope of the disclosure and will be apparent to those skilled in the art after reading this disclosure.

[0096] In some embodiments, a controller for an autonomous network comprises at least one memory containing a plurality of configurable and replaceable modules, and at least one processor coupled to the at least one memory and configured to execute the plurality of modules in an interconnected manner to form a controller component comprising: a measurement component configured to collect measurement data regarding at least one controlled element under the control of the controller, an analysis component configured to process the collected measurement data to obtain a current state of the at least one controlled element, and a decision component configured to determine an action to take with respect to the at least one controlled element based on the obtained current state; and an action component configured to perform the determined action with respect to the at least one controlled element by effecting a change in at least one of the behavior of the at least one controlled element and the configuration of the at least one controlled element.

[0097] In some embodiments, an autonomous network comprises a plurality of controllers interconnected in a system hierarchy graph, each of the plurality of controllers comprising at least one memory including a plurality of configurable and replaceable modules, and at least one processor coupled to the at least one memory and configured to execute the plurality of modules in an interconnected manner to perform an action on at least one controlled element based on measurement data on at least one controlled element under the control of each controller in accordance with the controller graph, the plurality of controllers comprising at least one operation controller (OC) configured to perform an action by effecting a change in the operation of the at least one controlled element, and at least one deployment controller (EC) configured to perform an action by effecting a change in the configuration of the at least one controlled element.

[0098] According to some embodiments, a method for operating an autonomous network is provided. The network includes a plurality of controllers interconnected in a system hierarchy graph. Each of the plurality of controllers, which may be an operational controller (OC) or a deployment controller (EC), includes at least one memory containing a plurality of configurable and replaceable modules, and at least one processor connected to the at least one memory and configured to execute the plurality of modules in an interconnected manner. The method includes controlling, by the OC, a hardware device or another OC below it in the system hierarchy graph, and controlling and deploying, by the EC, an existing controller below it in the system hierarchy graph. The deploying includes identifying a number of configurable and replaceable candidate modules that can be configured to complete a section of the controller graph of the existing controller, determining a plurality of different configurations in which various candidate modules are interconnected to complete the section of the controller graph, and outputting a plurality of deployed controllers, each corresponding to one of the plurality of configurations. The method further includes, by a trial manager, performing an online trial to determine whether the existing controller can be replaced by any of the plurality of deployed controllers.

[0099] The foregoing has outlined features of some embodiments to provide a better understanding of aspects of the present disclosure. Those skilled in the art will appreciate that this disclosure may be used as a basis for designing or modifying other processes and structures to carry out the same purposes and / or achieve the same advantages of the embodiments described herein. Those skilled in the art will recognize that such equivalent constructions do not depart from the spirit and scope of the present disclosure, and that various changes, substitutions, and alterations can be made without departing from the spirit and scope of the present disclosure.

Claims

1. at least one memory containing a plurality of configurable and replaceable modules; at least one processor coupled to the at least one memory and configured to execute a plurality of modules in an interconnected manner to form a controller component; Equipped with The controller component is a measurement component configured to collect measurement data relating to a controlled element, which is at least one hardware device under the control of the controller; an analysis component configured to analyze the collected measurement data based on predetermined criteria to obtain a current state of the at least one controlled element; a decision component configured to determine an action to be taken with respect to at least one controlled element so as to satisfy the predetermined criterion based on the obtained current state not satisfying the predetermined criterion; an action component configured to execute the determined action with respect to the at least one controlled element by sending instructions to the at least one controlled element that effect a change in the behavior of the at least one controlled element and / or the configuration of the at least one controlled element; A controller for an autonomous network comprising:

2. The controller of claim 1 , wherein each of the controller components comprises an interconnected module of a plurality of modules.

3. Each interconnected module of the controller component comprises at least a source module and a sink module directly or indirectly connected to the source module; A source module of one controller component is connected to a sink module of another controller component; The controller of claim 2 .

4. each of the plurality of modules having an application programming interface (API); The API is: a unique ID that uniquely identifies the module among a plurality of modules; Dependencies defining at least the inputs and outputs of the modules; Equipped with Two modules among a plurality of modules are connectable if a dependency defining an input in the API of one module matches a dependency defining an output in the API of the other module. A controller according to any one of claims 1 to 3.

5. Each of the plurality of modules code executable by at least one processor to perform the logical operations of the module; parameters used by the at least one processor to initialize and configure the logical operations; Meta information including a description of at least one API, input or output of the module; Further comprising at least one of The controller of claim 4 .

6. 6. The controller of claim 1, wherein at least one processor is configured to perform at least one of replacing one of the interconnected modules with another configurable and replaceable module and changing connections between the interconnected modules in response to instructions corresponding to actions determined and performed by another controller.

7. 7. A controller according to claim 1, wherein the at least one memory is accessible by the at least one controller component and further comprises a knowledge base containing previous selections and corresponding results.

8. 8. A controller as claimed in any preceding claim, wherein the controller components are configured to jointly execute cognitive control loops to optimise the operation of at least one controlled element and / or the configuration of at least one controlled element.

9. a plurality of controllers interconnected in a system hierarchy graph; Each of the plurality of controllers at least one memory containing a plurality of configurable and replaceable modules; at least one processor connected to at least one memory and configured to execute, in response to a controller graph, a plurality of modules in an interconnected manner below each controller in the system hierarchy graph to perform an action on at least one controlled element based on measurement data on at least one controlled element under the control of the controller; Equipped with Multiple controllers can be at least one motion controller (OC) configured to perform an action by sending instructions to at least one controlled element that effect a change in the motion of the controlled element; at least one deployment controller (EC) configured to perform an action by sending instructions to at least one controlled element that cause a change in the configuration of said controlled element; Equipped with Autonomous network.

10. The at least one controlled element under the control of the at least one OC includes at least one of another OC and a hardware device under the at least one OC in a system hierarchy graph; At least one controlled element under the control of at least one EC includes at least one of another controller and a hardware device under the at least one EC in a system hierarchy graph; The network of claim 9.

11. the at least one controlled element under the control of the at least one EC includes other controllers below the at least one EC in a system hierarchy graph; At least one EC is configured to perform an action with respect to the other controller by performing at least one of a controller expansion of the other controller and a hierarchy expansion of a subgraph under the at least one EC in a system hierarchy graph. The network of claim 10.

12. Controller expansion is replacing one of the interconnected modules in the other controller with a different instance of the same module or a different configurable and replaceable module; changing the controller graph of said other controller; Including at least one of The network of claim 11.

13. The hierarchy expansion is replacing the other controller with a different controller; Making a change in a subgraph under at least one EC; Including at least one of The network of claim 12.

14. For each of the multiple controllers, each of a plurality of configurable and replaceable modules interconnected in each of said controllers includes an application programming interface (API); The API is: a unique ID that uniquely identifies the module among a plurality of modules; Dependencies defining at least the inputs and outputs of the modules; Equipped with Two modules among a plurality of modules are connectable if a dependency defining an input in the API of one module matches a dependency defining an output in the API of the other module. A network according to any one of claims 9 to 13.

15. the EC is configured to control one or more further controllers in a subgraph below the EC in the system hierarchy graph; The EC has at least one special dependency that is exposed through the API of the EC's source module; an EC is configured to define at least one special dependency relationship to indicate the number and type of said one or more further controllers, whether a controller expansion of said one or more further controllers is possible, and whether a hierarchical expansion of subgraphs under said EC is possible; The network of claim 14.

16. 16. The network of any of claims 9 to 15, wherein at least one processor of each of the plurality of controllers is configured to execute a plurality of interconnected modules to execute a cognitive control loop that optimizes at least one of the operation of the at least one controlled element and the configuration of the at least one controlled element.

17. 1. A method of operating an autonomous network comprising a plurality of controllers interconnected in a system hierarchy graph, comprising: Each of the plurality of controllers, which may be an operational controller (OC) or a deployment controller (EC), comprises at least one memory including a plurality of configurable and replaceable modules, and at least one processor connected to the at least one memory and configured to execute the plurality of modules in an interconnected manner; The method is: Controlling hardware devices or other OCs below it in the system hierarchy graph by the OC; Controlling and evolving existing controllers below in the system hierarchy graph by the EC; Equipped with the unfolding comprises identifying a number of configurable and replaceable candidate modules that can be configured to complete a section of the controller graph; determining a plurality of different configurations in which the various candidate modules are interconnected to complete the section of the controller graph; and outputting a plurality of unfolded controllers, each corresponding to one of the plurality of configurations; performing, by a trial manager, an online trial to determine whether the existing controller can be replaced by any of a plurality of deployed controllers; Further provided with For each of a plurality of deployed controllers, the online attempt comprises: a sanity check to determine whether the deployed controller contains any logical errors; Simulation to evaluate the usefulness of the deployed controller by using a usefulness function; a network trial in which the trial manager initially limits the physical and / or temporal range of the deployed controllers and gradually increases the physical and / or temporal range based on the measured or estimated usefulness of the deployed controllers; A method of operating an autonomous network, including any of the following:

18. and coordinating, by an attempt manager, multiple online attempts initiated by multiple ECs deploying other controllers in the network; the coordinating includes at least one of resource allocation and scheduling; 18. The method of claim 17.

19. Each of the configurable and replaceable candidate modules has an application programming interface (API); The API is: a unique ID that uniquely identifies the candidate module; a dependency relationship defining at least an input and an output of the candidate module; Equipped with a plurality of configurations for completing a section of the controller graph are determined by interconnecting the candidate modules if the dependencies defining the inputs in the API of the candidate modules match the dependencies defining the outputs in the API of the other candidate modules; 19. The method of claim 17 or 18.

Images