WO2022258181A1

WO2022258181A1 - Enabling intent driven cognitive autonomous networks

Info

Publication number: WO2022258181A1
Application number: PCT/EP2021/065607
Authority: WO
Inventors: Anubhab BANERJEE; Stephen MWANJE
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2021-06-10
Filing date: 2021-06-10
Publication date: 2022-12-15

Abstract

There are provided measures for enabling intent driven cognitive autonomous networks. Such measures exemplarily comprise receiving network demand information indicative of a network related demand, wherein said network demand information includes context information for said network related demand and parameter information for said network related demand, assigning said network related demand a network demand type of a plurality of network demand types based on said network demand information, and deciding on implementation measures for achieving said network related demand based on said assigned network demand type.

Description

Title

Enabling intent driven cognitive autonomous networks

Field

Various example embodiments relate to enabling intent driven cognitive autonomous networks. More specifically, various example embodiments exemplarily relate to measures (including methods, apparatuses and computer program products) for realizing enabling intent driven cognitive autonomous networks.

Background

The present specification generally relates to cognitive autonomous networks (CAN) in 5G (radio access) networks (RAN) and other (future) generations of wireless/mobile networks, and more particularly to the use of intents in network management automation.

Figure 6 shows a schematic diagram of an example of a system environment with signaling variants, and in particular illustrates an example overview of a cognitive network automation system.

CAN is a network automation system which has capability to manage network operations using network automation functions (NAF) or cognitive functions (CF). These CFs are controlled by a coordinator function which is called the Controller. NAFs can be guided by a network objectives manager, which may set target(s) for the NAFs depending on operator goals. Usually, the operator goals are specific targets to be achieved under particular conditions. Owing to the complexity of networks, there is always push for more automation and abstraction. One recent approach in relation to the abstraction is the use of intents. This approach, i.e., the measures following this approach, may be termed intent-based networking (IBN).

The intent is a flexible abstract way of specifying a required outcome/goal by a consumer (for example, the operator) without specifying exactly how the required outcome/goal should be achieved. Examples of operator goals considered as an operator intent are given below. The exact method of achieving a specified intent is left to an intent fulfillment system (IFS) offering an intent service.

Specified intents can vary from simple intents that can be fulfilled with a single command to a specific network object to very complex intents that include multiple network nodes and several commands on several network objects.

Examples of intents include:

- Collect/get carrier aggregation statistics for all cells in city X,

- Restrict/deny handovers (HO) of high mobility users to small cells,

- Allow load balancing to a cell Y or to small cells or to only urban cells, and

- Rehome a base station from controller A to controller B.

Figure 7 shows a schematic diagram of an example of a system environment with signaling variants, and in particular illustrates an example overview of an intent-driven network management system (IDNMS).

As shown in Figure 7, the IDNMS may include an intent specification platform (ISP) responsible for capturing and formatting the intent, as well as the intent fulfilment system which then fulfils the formal intent. The consumer may interact with the IDNMS through interfaces defined by Standards Development Organizations (SDO) (e.g. legacy control operations for backwards compatibility, GUI, command line interface, etc.).

The intent specification platform may provides a formal intent, which is then input to the IFS.

The formal intent provided by the ISP may have a format as illustrated below.

Verb: a_verb;

Object: a_network_object;

Context { contextl : contextl_value context2: context2 value

}

Parameters { parameterl : para meter l_va I ue parameter : parameter2_value

}

Namely, an intent from the mobile network operator (MNO) can contain any finite set of actions, which need to be executed by the NAFs. An intent from the MNO can be in any structure and does not have a fixed set of rules.

The ISP parses the intent and converts it to the structure of a formal intent having a format (see above) expected by the IFS.

Although a formal intent has a defined structure, it is still open however how the formal intent may be actually fulfilled. For example, if an operator intent is "increase throughput in cell X", there are a lot of ways to fulfill the intent: (i) by increasing downlink transmit power (TXP), (ii) by changing remote electrical tilt (RET), (iii) by changing both TXP and RET. CAN provides means to manage different network optimizations using CFs. Usually, different CFs are designed to focus on optimizing different objectives, and the (CAN) Controller is assigned to resolve any conflicts that arise among the CFs. These CFs can also be configured to behave in a certain way by setting particular constraints or performance targets. However, currently there is not any function which does this task - configuring the CFs (or CAN in general) based on an intent from MNO.

From the CAN perspective, an intent could be implemented by the Controller, by a CF, or both. However, as mentioned above, a formal intent does not contain any information for whom it is intended or by whom it should be executed.

Hence, the problem arises that an operator's intent, being converted into a formal intent having a format expected by the IFS or not, does not lead to fulfilling the intents through NAFs provided in a network automation system as illustrated in Figure 6. In fact, the concrete problem arises that, as the formal intent does not contain any information for whom it is intended or by whom it should be executed, any deduction of these information, i.e., for whom the formal intent is intended or by whom the formal intent should be executed, is not arranged for.

Hence, there is a need to provide for enabling intent driven cognitive autonomous networks.

Various example embodiments aim at addressing at least part of the above issues and/or problems and drawbacks.

Various aspects of example embodiments are set out in the appended claims. According to an exemplary aspect, there is provided a method comprising receiving network demand information indicative of a network related demand, wherein said network demand information includes context information for said network related demand and parameter information for said network related demand, assigning said network related demand a network demand type of a plurality of network demand types based on said network demand information, and deciding on implementation measures for achieving said network related demand based on said assigned network demand type.

According to an exemplary aspect, there is provided a method of a controller entity controlling at least one cognitive function entity, the method comprising receiving at least one of a first instruction including information on actions to be implemented in relation to a network related demand and a second instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented in relation to said network related demand, verifying said actions to be implemented or said action suggestions, and if, as a result of said verifying, a conflict is determined transmitting information indicative of that at least one of said actions to be implemented or at least one of said or said action suggestions raise a conflict.

According to an exemplary aspect, there is provided an apparatus comprising receiving circuitry configured to receive network demand information indicative of a network related demand, wherein said network demand information includes context information for said network related demand and parameter information for said network related demand, assigning circuitry configured to assign said network related demand a network demand type of a plurality of network demand types based on said network demand information, and deciding circuitry configured to decide on implementation measures for achieving said network related demand based on said assigned network demand type. According to an exemplary aspect, there is provided an apparatus of a controller entity controlling at least one cognitive function entity, the apparatus comprising receiving circuitry configured to receive at least one of a first instruction including information on actions to be implemented in relation to a network related demand and a second instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented in relation to said network related demand, verifying circuitry configured to verify said actions to be implemented or said action suggestions, and transmitting circuitry configured to, if, as a result of said verifying, a conflict is determined, transmit information indicative of that at least one of said actions to be implemented or at least one of said or said action suggestions raise a conflict.

According to an exemplary aspect, there is provided an apparatus comprising at least one processor, at least one memory including computer program code, and at least one interface configured for communication with at least another apparatus, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform receiving network demand information indicative of a network related demand, wherein said network demand information includes context information for said network related demand and parameter information for said network related demand, assigning said network related demand a network demand type of a plurality of network demand types based on said network demand information, and deciding on implementation measures for achieving said network related demand based on said assigned network demand type.

According to an exemplary aspect, there is provided an apparatus of a controller entity controlling at least one cognitive function entity, the apparatus comprising at least one processor, at least one memory including computer program code, and at least one interface configured for communication with at least another apparatus, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform receiving at least one of a first instruction including information on actions to be implemented in relation to a network related demand and a second instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented in relation to said network related demand, verifying said actions to be implemented or said action suggestions, and if, as a result of said verifying, a conflict is determined transmitting information indicative of that at least one of said actions to be implemented or at least one of said or said action suggestions raise a conflict.

According to an exemplary aspect, there is provided a computer program product comprising computer-executable computer program code which, when the program is run on a computer (e.g. a computer of an apparatus according to any one of the aforementioned apparatus-related exemplary aspects of the present disclosure), is configured to cause the computer to carry out the method according to any one of the aforementioned method- related exemplary aspects of the present disclosure.

Such computer program product may comprise (or be embodied) a (tangible) computer-readable (storage) medium or the like on which the computer- executable computer program code is stored, and/or the program may be directly loadable into an internal memory of the computer or a processor thereof.

Any one of the above aspects enables an efficient analysis of formal intents and deduction and determination of addressees of measures to achieve the formal intents and instructions for these addressees to achieve the formal intent to thereby solve at least part of the problems and drawbacks identified in relation to the prior art.

By way of example embodiments, there is provided enabling intent driven cognitive autonomous networks. More specifically, by way of example embodiments, there are provided measures and mechanisms for realizing enabling intent driven cognitive autonomous networks.

Thus, improvement is achieved by methods, apparatuses and computer program products enabling/realizing enabling intent driven cognitive autonomous networks.

Brief description of the drawings

In the following, the present disclosure will be described in greater detail by way of non-limiting examples with reference to the accompanying drawings, in which

Figure 1 is a block diagram illustrating an apparatus according to example embodiments,

Figure 2 is a block diagram illustrating an apparatus according to example embodiments,

Figure 3 is a block diagram illustrating an apparatus according to example embodiments,

Figure 4 is a schematic diagram of a procedure according to example embodiments,

Figure 5 is a schematic diagram of a procedure according to example embodiments,

Figure 6 shows a schematic diagram of an example of a system environment with signaling variants,

Figure 7 shows a schematic diagram of an example of a system environment with signaling variants, Figure 8 shows a schematic diagram of an example of a system environment with signaling variants according to example embodiments,

Figure 9 is a block diagram alternatively illustrating an apparatus according to example embodiments,

Figure 10 is a schematic diagram alternatively illustrating a procedure according to example embodiments,

Figure 11 (Figures 11A and 11B) shows a schematic diagram of signaling sequences according to example embodiments, and

Figure 12 is a block diagram alternatively illustrating apparatuses according to example embodiments.

The present disclosure is described herein with reference to particular non limiting examples and to what are presently considered to be conceivable embodiments. A person skilled in the art will appreciate that the disclosure is by no means limited to these examples, and may be more broadly applied.

It is to be noted that the following description of the present disclosure and its embodiments mainly refers to specifications being used as non-limiting examples for certain exemplary network configurations and deployments. Namely, the present disclosure and its embodiments are mainly described in relation to 3GPP and/or O-RAN specifications being used as non-limiting examples for certain exemplary network configurations and deployments. As such, the description of example embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples, and does naturally not limit the disclosure in any way. Rather, any other communication or communication related system deployment, etc. may also be utilized as long as compliant with the features described herein.

Hereinafter, various embodiments and implementations of the present disclosure and its aspects or embodiments are described using several variants and/or alternatives. It is generally noted that, according to certain needs and constraints, all of the described variants and/or alternatives may be provided alone or in any conceivable combination (also including combinations of individual features of the various variants and/or alternatives).

According to example embodiments, in general terms, there are provided measures and mechanisms for (enabling/realizing) enabling intent driven cognitive autonomous networks.

As illustrated by Figure 6, the network automation system has capabilities to manage a network using NAFs, which are controlled by the (CAN) Controller and can be guided by a network objectives manager (NOM) that sets the targets for the NAFs depending on operator goals. However, the network automation system illustrated in Figure 6 does not provide means for fulfilling the intents through these NAFs.

Thus, example embodiments provide means to execute intents using such a system that already implements NOFs with a coordination function, i.e., provide ways of fulfilling operator intents using existing NAFs (CFs in CAN).

In particular, according to example embodiments, a formal intent is translated and sent to the designated entities so that the tasks, specified in the intent, are eventually performed.

Example embodiments are summarized below. Namely, according to example embodiments, an intent-driven network automation function orchestrator (INAFO) is provided that translates a formal intent into the actions of NAFs and the coordinator (Controller in CAN). The INAFO takes a formal intent as its input, processes it internally, and produces triggers for relevant entities at its output.

Figure 8 shows a schematic diagram of an example of a system environment with signaling variants according to example embodiments, and in particular illustrates an example overview of the interaction between the INAFO according to example embodiments and the network automation system.

An intent from the MNO can be of many types and needs to be executed by different entities in the network. Example embodiments relate to CAN only. Accordingly, example embodiments provide an intent driven orchestrator for CAN focusing only to those intents which can be executed by the Controller or the CFs in the CAN. Hence, according to example embodiments, the INAFO identifies the intents executable by the CAN (either by CFs or by the Controller).

Within CAN, an intent is either directly executed or needs to be further processed for execution by CFs. For example, an intent like "set TXP of cell X at 45 dBm" can be directly executed by the Controller, whereas an intent like "increase throughput of cell X by adjusting RET" needs to be executed by the coverage and capacity optimization (CCO) but not the Controller. Hence, after one of these types of intents is received from the MNO and converted into a formal intent, according to example embodiments, a decision is made on how and by whom the intent is to be executed. In particular, according to example embodiments, the INAFO processes the formal intent, generates action(s) out of it, decides where the action(s) is/are to be sent for execution, and configures the CFs if necessary.

Example embodiments are specified in more detail. Figure 1 is a block diagram illustrating an apparatus according to example embodiments. The apparatus may be a network node or entity 10 such as a network automation function orchestrator entity (e.g. an INAFO) comprising a receiving circuitry 11, an assigning circuitry 12, and a deciding circuitry 13. The receiving circuitry 11 receives network demand information indicative of a network related demand. Here, said network demand information includes context information for said network related demand and parameter information for said network related demand. The assigning circuitry 12 assigns said network related demand a network demand type of a plurality of network demand types based on said network demand information. The deciding circuitry 13 decides on implementation measures for achieving said network related demand based on said assigned network demand type. Figure 4 is a schematic diagram of a procedure according to example embodiments. The apparatus according to Figure 1 may perform the method of Figure 4 but is not limited to this method. The method of Figure 4 may be performed by the apparatus of Figure 1 but is not limited to being performed by this apparatus.

As shown in Figure 4, a procedure according to example embodiments comprises an operation of receiving (S41) network demand information indicative of a network related demand, wherein said network demand information includes context information for said network related demand and parameter information for said network related demand, an operation of assigning (S42) said network related demand a network demand type of a plurality of network demand types based on said network demand information, and an operation of deciding (S43) on implementation measures for achieving said network related demand based on said assigned network demand type.

Figure 2 is a block diagram illustrating an apparatus according to example embodiments. In particular, Figure 2 illustrates a variation of the apparatus shown in Figure 1. The apparatus according to Figure 2 may thus further comprise determining circuitry 21, subjecting circuitry 22, forwarding circuitry 23, returning circuitry 24, analyzing circuitry 25, acknowledging circuitry 26, selecting circuitry 27, specifying circuitry 28, and/or transmitting circuitry 29.

In an embodiment at least some of the functionalities of the apparatus shown in Figure 1 (or 2) may be shared between two physically separate devices forming one operational entity. Therefore, the apparatus may be seen to depict the operational entity comprising one or more physically separate devices for executing at least some of the described processes.

According to a variation of the procedure shown in Figure 4, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of determining ability for addressing said network related demand based on said network demand information, and, if, as a result of said determining, said ability is acknowledged, an operation of subjecting said network related demand to said assigning and said deciding, and, if, as a result of said determining, said ability is not acknowledged, at least one of an operation of forwarding said network demand information towards a network entity responsible for addressing network related demands and an operation of returning said network demand information towards an origin of said network demand information.

According to a variation of the procedure shown in Figure 4, exemplary details of the determining operation are given, which are inherently independent from each other as such. Such exemplary determining operation according to example embodiments may comprise an operation of analyzing whether said context information includes at least one context entry defining a network control parameter or a network metric, an operation of analyzing whether said parameter information includes at least one parameter entry defining a network control parameter or a network metric, and an operation of acknowledging said ability, if, as a result of said analyzing, said context information includes said at least one context entry defining a network control parameter or a network metric and/or said parameter information includes said at least one parameter entry defining a network control parameter or a network metric.

According to a variation of the procedure shown in Figure 4, exemplary details of the assigning operation (S42) are given, which are inherently independent from each other as such. According to such variation, said plurality of network demand types includes a first network demand type. Such exemplary assigning operation (S42) according to example embodiments may comprise an operation of selecting said first network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network control parameter, and said parameter information includes no parameter entry, an operation of selecting said first network demand type, if said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network control parameter, and said context information includes no context entry, and an operation of selecting said first network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network control parameter, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network control parameter.

According to a variation of the procedure shown in Figure 4, exemplary details of the assigning operation (S42) are given, which are inherently independent from each other as such. According to such variation, said plurality of network demand types includes a second network demand type. Such exemplary assigning operation (S42) according to example embodiments may comprise an operation of selecting said second network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network metric, and said parameter information includes no parameter entry, an operation of selecting said second network demand type, if said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network metric, and said context information includes no context entry, and an operation of selecting said second network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network metric, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network metric.

According to a variation of the procedure shown in Figure 4, exemplary details of the assigning operation (S42) are given, which are inherently independent from each other as such. According to such variation, said plurality of network demand types includes a third network demand type. Such exemplary assigning operation (S42) according to example embodiments may comprise an operation of selecting said third network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network control parameter, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network metric, and an operation of selecting said third network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network metric, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network control parameter.

According to a variation of the procedure shown in Figure 4, exemplary details of the deciding operation (S43) are given, which are inherently independent from each other as such. Such exemplary deciding operation (S43) according to example embodiments may comprise an operation of specifying, if said third network demand type is assigned, at least one cognitive function entity and a controller entity controlling said at least one cognitive function entity, first actions to be implemented by said at least one cognitive function entity, and second actions to be implemented by said controller entity, an operation of transmitting, towards said at least one cognitive function entity, a first instruction including information on said first actions, an operation of transmitting, towards said controller entity, a second instruction including information on said second actions, and an operation of transmitting, towards said controller entity, a third instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented.

According to a variation of the procedure shown in Figure 4, exemplary details of the deciding operation (S43) are given, which are inherently independent from each other as such. Such exemplary deciding operation (S43) according to example embodiments may comprise an operation of specifying, if said second network demand type is assigned, at least one cognitive function entity and a controller entity controlling said at least one cognitive function entity, and actions to be implemented by said at least one cognitive function entity, an operation of transmitting, towards said at least one cognitive function entity, a first instruction including information on said actions, and an operation of transmitting, towards said controller entity, a second instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented.

According to a variation of the procedure shown in Figure 4, exemplary details of the deciding operation (S43) are given, which are inherently independent from each other as such. Such exemplary deciding operation (S43) according to example embodiments may comprise an operation of specifying, if said first network demand type is assigned, a controller entity controlling at least one cognitive function entity, and actions to be implemented by said controller entity, and an operation of transmitting, towards said controller entity, an instruction including information on said actions.

According to a variation of the procedure shown in Figure 4, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of receiving information indicative of that at least one of said implementation measures raise a conflict.

According to a variation of the procedure shown in Figure 4, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of transmitting, towards an origin of said network demand information, an indication that said network related demand raises said conflict.

Figure 3 is a block diagram illustrating an apparatus according to example embodiments. The apparatus may be a network node or entity 30 such as a controller entity controlling at least one cognitive function entity (e.g. a CAN controller) comprising a receiving circuitry 31, a verifying circuitry 32, and a transmitting circuitry 33. The receiving circuitry 31 receives at least one of a first instruction including information on actions to be implemented in relation to a network related demand and a second instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented in relation to a network related demand. The verifying circuitry 32 verifies said actions to be implemented or said action suggestions. The transmitting circuitry 33 transmits, if, as a result of said verifying, a conflict is determined, information indicative of that at least one of said actions to be implemented or at least one of said or said action suggestions raise a conflict. Figure 5 is a schematic diagram of a procedure according to example embodiments. The apparatus according to Figure 3 may perform the method of Figure 5 but is not limited to this method. The method of Figure 5 may be performed by the apparatus of Figure 3 but is not limited to being performed by this apparatus.

As shown in Figure 5, a procedure according to example embodiments comprises an operation of receiving (S51) at least one of a first instruction including information on actions to be implemented in relation to a network related demand and a second instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented in relation to a network related demand, an operation of verifying (S52) said actions to be implemented or said action suggestions, and, if, as a result of said verifying, a conflict is determined, an operation of transmitting (S53) information indicative of that at least one of said actions to be implemented or at least one of said or said action suggestions raise a conflict.

In an embodiment at least some of the functionalities of the apparatus shown in Figure 4 may be shared between two physically separate devices forming one operational entity. Therefore, the apparatus may be seen to depict the operational entity comprising one or more physically separate devices for executing at least some of the described processes.

Example embodiments summarized and specified above are explained in more specific terms.

That is, in other words, according to example embodiments, the INAFO processing may consist of three sequential steps. As such, the INAFO according to example embodiments may include three corresponding modules. However, the INAFO according to example embodiments is not limited to three sequential steps and three corresponding modules. Namely, according to example embodiments, one or more processing steps may be executed by one single module. On the other hand, the INAFO according to example embodiments does not necessarily have to execute all three sequential steps, and is in particular not limited to the mentioned three sequential steps.

Figure 9 is a block diagram alternatively illustrating an apparatus according to example embodiments, and in particular illustrates the internal modules of the INAFO according to example embodiments.

As a first of the sequential steps, according to example embodiments, the INAFO (the corresponding module thereof) identifies supported intents, i.e., identifies whether the received intents are supported. In particular, according to example embodiments, as soon as the INAFO receives a formal intent, the INAFO checks whether the intent is valid for the CAN, i.e., whether the intent can be executed by the Controller or by CFs. In the present specification, the corresponding module of the INAFO is referred to as Intent Identifier.

As a second of the sequential steps, according to example embodiments, the INAFO (the corresponding module thereof) classifies (received) intents. In particular, according to example embodiments, after the Intent Identifier has identified that a formal intent is executable by the CAN, the INAFO classifies the intent based on its content to a type of intents. In the present specification, the corresponding module of the INAFO is referred to as Intent Classifier.

As a third of the sequential steps, according to example embodiments, the INAFO (the corresponding module thereof) makes decisions regarding addressee and instructions. In particular, according to example embodiments, after classification of an intent is done (by the Intent Classifier module), based on the type of the intent, the INAFO takes subsequent actions like sending specific commands to the Controller or CFs or both. Certainly, according to example embodiments, beforehand, the INAFO decides on the subsequent actions based on the type of the intent and the content of the intent. In the present specification, the corresponding module of the INAFO is referred to as Intent Decision Maker.

A corresponding workflow of the INAFO according to example embodiments is explained with reference to Figure 10 being a schematic diagram alternatively illustrating a procedure according to example embodiments.

In detail, as is illustrated in Figure 10, as soon as the INAFO receives an intent at its input, the Intent Identifier decides whether the intent is relevant. If the intent is not relevant, the Intent Identifier may send the intent back to the consumer or may forward the intent to another IFS.

If the intent is relevant, the Intent Identifier forwards the intent to the Intent Classifier.

The Intent Classifier checks the content and categorizes the intent. After that, the Intent Classifier forwards the information to the Intent Decision Maker.

The Intent Decision Maker decides on and sends, based on the intent type, appropriate instructions to the Controller and/or the CFs.

If any contradiction arises between CFs or the Controller, the Controller informs the Intent Decision Maker about the conflicts.

Upon receipt of information on such conflicts, the INAFO returns the intent to the intent-driven network management (IDNM) service consumer with information on how and where the contradiction arises.

If no contradiction arises between CFs or the Controller, the processing ends for the received intent.

Intent Identifier - Identification of a formal intent executable by CAN

In CAN, different CFs are assigned for optimizing different key performance indicators (KPI) (for example, CCO optimizes cell coverage and capacity, MRO optimizes handover performance, etc.). These CFs continuously monitor the environment for external factors (like number of connected UEs, UE mobilities) and propose changes to the Controller when the external factors change. The Controller makes the proposed changes in the network. Sometimes, multiple CFs can propose changing the same parameter (like both MRO and MLB can propose to change the cell individual offset (CIO) at the same time) but by a different amount. In such cases, it is the responsibility of the Controller to resolve the conflicts among the CFs and to find a good compromise.

From the working principle of CAN, thus, only the intents which deal with KPIs and/or network control parameters, can be executed by CAN. All other types of intents cannot be executed by CAN, for example, executing intents like "restart gNb", "decommission 2G cell", are beyond the capability of CAN. Hence, according to example embodiments, after receiving a formal intent, the INAFO (the Intent Identifier module thereof) identifies whether the intent can be executed by CAN.

A formal intent in a structure as illustrated above can be of many types based on the information the formal intent contains. In effect, all intents have a verb and an object which is one or multiple managed object instances (MOI), so the different types of intents are differentiated based on the information content of the parameter and context fields.

Based on the content in parameter and context fields, according to example embodiments, the INAFO (the Intent Identifier module thereof) identifies whether a formal intent can be executed by the CAN.

Here, according to example embodiments, the INAFO (the Intent Identifier module thereof) follows using the logic of Rule 1 presented below:

Rule 1: "At least one of either the context and/or parameter entries for the specific intent must be a network control parameter or a defined network metric like a KPI."

Rule 1 may be represented by the following pseudo-code: if

(context == "" and parameter == "network control parameter"), or (context = = "" and parameter = = "KPI"), or (context == "network control parameter" and parameter == or (context == "network control parameter" and parameter == "network control parameter"), or

(context == "network control parameter" and parameter == "KPI"), or (context = = "KPI" and parameter

(context == "KPI" and parameter == "network control parameter"), or (context = = "KPI" and parameter = = "KPI") then intent can be fulfilled by the CAN and forwarded to the Intent Classifier else return a message to the user that this intent cannot be fulfilled by the CAN

After the INAFO identifies an intent that can be executed by CAN, the INAFO categorizes the intent into different types and takes subsequent actions based on the category, as follows

Intent Classifier, Intent Decision Maker - Categorization and deriving actions

Even though INAFO takes intents with certain content, according to example embodiments, based on the entity by which the intent is to be executed, the INAFO (the Intent Classifier module thereof) further categorizes the intents, since different decisions or actions are required for each category of intents.

According to example embodiments, separate decisions are derived for each of three intent types. The types are identified by evaluating the logic of Rules 2 to 4 presented below:

Rule 2: "Either the intent parameters and intent context are defined on a network control parameter while the other is not defined or both are defined on a network control parameter." Rule 3: "Either the intent parameters and intent context are defined on a network metric like a KPI while the other is not defined or both are defined on a network metric like a KPI." Rule 4: "One of either the intent parameters or the intent context is defined on a network control parameter while the other is defined on a network metric like a KPI."

Here it is noted that in the present specification, a KPI is taken as an example of a network metric. However, the present principles are not limited to the application of KPIs but instead, according to example embodiments, any kind of network metrics may be considered.

The categories corresponding to the Rules 2 to 4 may be grouped as described below and described in the subsequent subsections:

Type 1 intents

Type 1 intents are those characterized by one of three cases: (i) context is empty and parameters are defined on network control parameters, (ii) parameter is empty and contexts are defined on network control parameters, and, (iii) both context and parameter are defined on network control parameter. As Type 1 intent contains only network control parameters, the INAFO (the Intent Decision Maker module thereof) decides on measures executed only by the Controller.

6.3.2. Type 2 intents

Type 2 intents are those characterized by one of three cases: (i) context is empty and parameters are defined on KPIs, (ii) parameter is empty and contexts are defined on KPIs, and, (iii) both context and parameter are defined on KPIs.

To execute a Type 2 intent, the INAFO (the Intent Decision Maker module thereof) first identifies the CFs which are responsible for managing the KPIs. After that, the INAFO (the Intent Decision Maker module thereof) decides on and sends instructions to those CFs to take specific actions (increase, keeping constant or decrease) on their KPIs. At the same time, the INAFO (the Intent Decision Maker module thereof) decides on and sends instructions to the Controller to make all the changes in the network as proposed by those particular CFs.

In case there is a contradiction between actions, according to example embodiments, the Controller informs INAFO about the contradiction.

For example, considering an intent where both context and parameter are defined: "make throughput 3.5 Mbps in cell X without increasing interference". In this case, both CCO and inter-cell interference coordination (ICIC) suggests some actions on TXP and RET to the Controller. If the actions on TXP and/or RET are conflicting, then, according to example embodiments, the Controller flags this intent as a contradicting intent and reports it back to INAFO with information on type and details of the conflict.

Type 3 intents

Type 3 intents are those characterized by one of two cases: (i) parameters are defined on network control parameters and contexts are defined on KPIs, and, (ii) parameters are defined on KPIs and contexts are defined on network control parameters.

Type 3 intent contains both KPIs and network control parameters. Accordingly, the INAFO (the Intent Decision Maker module thereof) decides on measures executed by both CFs and the Controller. Hence, the INAFO (the Intent Decision Maker module thereof) gives instructions to both CFs and the Controller.

According to example embodiments, the INAFO (the Intent Decision Maker module thereof) decides on and sends instructions to those CFs to take specific actions (increase, keeping constant or decrease) on their KPIs. Before that, the INAFO (the Intent Decision Maker module thereof) first identifies the CFs which are responsible for managing the KPIs. At the same time, the INAFO (the Intent Decision Maker module thereof) decides on and sends two types of instructions to the Controller: (i) take instructed actions on network control parameters, and, (ii) make all the changes in the network as proposed by those particular CFs.

In case there is a contradiction between actions, according to example embodiments, the Controller informs INAFO about the contradiction. In particular, in case of conflicts, according to example embodiments, the Controller flags this intent as a contradicting intent and reports it back to INAFO with information on type and details of the conflict.

Interfaces of INAFO

After the categorization of a formal intent is done, INAFO conveys the messages to responsible entities (CF(s) and the Controller). For each type of intent, what instructions a CF and the Controller receives is listed below:

Thus, according to example embodiments, the INAFO (the Intent Decision Maker module thereof) is configured to send one type of messages to CF(s), namely the instructions to take necessary actions to fulfill the KPI requirement as specified in the intent.

Further, according to example embodiments, the INAFO (the Intent Decision Maker module thereof) is configured to send two types of messages to the Controller, namely (i) the instruction to take instructed actions on network control parameters, and (ii) the instruction to take actions as suggested by particular CF(s). Hence, according to example embodiments, interfaces allowing such messaging on the CAN side and on the network side are provided.

Here, it is noted that according to example embodiments, interfaces existing in CFs and the Controller (CAN side) are properly (re)used.

According to further example embodiments, interfaces in the Controller allowing the Controller to inform the INAFO about contradictions present in an intent are provided.

Figure 11 (Figures 11A and 11B) shows a schematic diagram of signaling sequences according to example embodiments, and in particular illustrates an example of an INAFO end-to-end workflow and interactions with the IDNMS consumer and the CAN system. More specifically, Figure 11 illustrates a detailed flow of the INAFO and its interactions with the other entities. Specifically, it highlights the decision and interfaces as well as the messages that are exchanged depending on the decisions taken for the different intent types. Here, it is noted that Figure 11B is a continuation of Figure 11A.

In step 1 of Figure 11, according to example embodiments, the IDNM service consumer requests from the INAFO to execute an intent.

In step 2 of Figure 11, according to example embodiments, the INAFO checks whether the intent is in the INAFO's scope. In other words, according to example embodiments, Rule 1 as discussed above is executed.

If, as a result of step 2, it is decided that the intent is not in the INAFO's scope, step 3 (and optionally step 4) is executed.

In step 3 of Figure 11, according to example embodiments, the INAFO reports to the IDNM service consumer that the intent was not in the INAFO's scope. In step 4 of Figure 11, according to example embodiments, optionally, e.g. dependent on whether the INAFO interfaces to other IFSs, the INAFO instructs another IFS to execute the intent.

If, as a result of step 2, it is decided that the intent is in the INAFO's scope, the subsequent steps are executed as explained.

In step 5 of Figure 11, according to example embodiments, the INAFO evaluates Rules 2, 3, and 4 as discussed above.

If, as a result of step 5, Rule 2 passes, step 6 is executed.

In step 6 of Figure 11, according to example embodiments, the INAFO instructs the controller to configure the network control parameters.

If, as a result of step 5, Rule 3 passes, steps 7.1 and 7.2 are executed.

In step 7.1 of Figure 11, according to example embodiments, the INAFO configures the CFs with targets, priorities, etc.

In step 7.2 of Figure 11, according to example embodiments, the INAFO instructs the controller to follow the action suggestions from the CFs.

If, as a result of step 5, Rule 4 passes (e.g. Rule 4 as default), steps 8.1 and 8.2 are executed.

In step 8.1 of Figure 11, according to example embodiments, the INAFO instructs the controller to configure the network control parameters and to follow the action suggestions from the CFs.

In step 8.2 of Figure 11, according to example embodiments, the INAFO configures the CFs with targets, priorities, etc. Steps 8.3 and 8.4 may be optionally executed subsequently to steps 7.1 and 7.2 or subsequently to steps 8.1 and 8.2 (i.e. both in case Rule 3 and in case Rule 4 passes).

In step 8.3 of Figure 11, according to example embodiments, the controller reports execution success/failure, e.g. that the target was achieved or that an action raised conflicts.

In step 8.4 of Figure 11, according to example embodiments, the INAFO performs an evaluation with respect to a possibility of contradiction heretofore, the INAFO may utilize/analyze any foregoing report indicating that an action raised conflicts.

If, as a result of step 8.4, a contradiction is detected, step 9 is executed.

In step 9 of Figure 11, according to example embodiments, the INAFO informs the IDNM service consumer with e.g. an error indication that the submitted intent has contradictions.

As a result of the principle behind the above discussed example embodiments, the job of an MNO is made much easier. Previously, the MNO had to set different parameters to different values until its target was satisfied. With the help of the INAFO according to example embodiments, the MNO can simply write its target as a simple command and the INAFO according to example embodiments would take care of the execution.

The above-described procedures and functions may be implemented by respective functional elements, processors, or the like, as described below.

In the foregoing exemplary description of the network entity, only the units that are relevant for understanding the principles of the disclosure have been described using functional blocks. The network entity may comprise further units that are necessary for its respective operation. However, a description of these units is omitted in this specification. The arrangement of the functional blocks of the devices is not construed to limit the disclosure, and the functions may be performed by one block or further split into sub-blocks.

When in the foregoing description it is stated that the apparatus, i.e. network entity (or some other means) is configured to perform some function, this is to be construed to be equivalent to a description stating that a (i.e. at least one) processor or corresponding circuitry, potentially in cooperation with computer program code stored in the memory of the respective apparatus, is configured to cause the apparatus to perform at least the thus mentioned function. Also, such function is to be construed to be equivalently implementable by specifically configured circuitry or means for performing the respective function (i.e. the expression "unit configured to" is construed to be equivalent to an expression such as "means for").

In Figure 12, an alternative illustration of apparatuses according to example embodiments is depicted. As indicated in Figure 12, according to example embodiments, the apparatus (network entity) 10' (corresponding to the network entity 10) comprises a processor 121, a memory 122 and an interface 123, which are connected by a bus 124 or the like. Further, according to example embodiments, the apparatus (network entity) 30' (corresponding to the network entity 30) comprises a processor 125, a memory 126 and an interface 127, which are connected by a bus 128 or the like, and the apparatuses may be connected via link 129, respectively.

The processor 121/125 and/or the interface 123/127 may also include a modem or the like to facilitate communication over a (hardwire or wireless) link, respectively. The interface 123/127 may include a suitable transceiver coupled to one or more antennas or communication means for (hardwire or wireless) communications with the linked or connected device(s), respectively. The interface 123/127 is generally configured to communicate with at least one other apparatus, i.e. the interface thereof. The memory 122/126 may store respective programs assumed to include program instructions or computer program code that, when executed by the respective processor, enables the respective electronic device or apparatus to operate in accordance with the example embodiments.

In general terms, the respective devices/apparatuses (and/or parts thereof) may represent means for performing respective operations and/or exhibiting respective functionalities, and/or the respective devices (and/or parts thereof) may have functions for performing respective operations and/or exhibiting respective functionalities.

When in the subsequent description it is stated that the processor (or some other means) is configured to perform some function, this is to be construed to be equivalent to a description stating that at least one processor, potentially in cooperation with computer program code stored in the memory of the respective apparatus, is configured to cause the apparatus to perform at least the thus mentioned function. Also, such function is to be construed to be equivalently implementable by specifically configured means for performing the respective function (i.e. the expression "processor configured to [cause the apparatus to] perform xxx-ing" is construed to be equivalent to an expression such as "means for xxx-ing").

According to example embodiments, an apparatus representing the network entity 10 comprises at least one processor 121, at least one memory 122 including computer program code, and at least one interface 123 configured for communication with at least another apparatus. The processor (i.e. the at least one processor 121, with the at least one memory 122 and the computer program code) is configured to perform receiving network demand information indicative of a network related demand, wherein said network demand information includes context information for said network related demand and parameter information for said network related demand (thus the apparatus comprising corresponding means for receiving), to perform assigning said network related demand a network demand type of a plurality of network demand types based on said network demand information (thus the apparatus comprising corresponding means for assigning), and to perform deciding on implementation measures for achieving said network related demand based on said assigned network demand type (thus the apparatus comprising corresponding means for deciding).

According to further example embodiments, an apparatus representing the network entity 30 (e.g. a controller entity controlling at least one cognitive function entity) comprises at least one processor 125, at least one memory 126 including computer program code, and at least one interface 127 configured for communication with at least another apparatus. The processor (i.e. the at least one processor 125, with the at least one memory 126 and the computer program code) is configured to perform receiving at least one of a first instruction including information on actions to be implemented in relation to a network related demand and a second instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented in relation to a network related demand (thus the apparatus comprising corresponding means for receiving), to perform verifying said actions to be implemented or said action suggestions (thus the apparatus comprising corresponding means for verifying), and to perform transmitting, if, as a result of said verifying, a conflict is determined, information indicative of that at least one of said actions to be implemented or at least one of said or said action suggestions raise a conflict (thus the apparatus comprising corresponding means for transmitting).

For further details regarding the operability/functionality of the individual apparatuses, reference is made to the above description in connection with any one of Figures 1 to 11, respectively.

For the purpose of the present disclosure as described herein above, it should be noted that

- method steps likely to be implemented as software code portions and being run using a processor at a network server or network entity (as examples of devices, apparatuses and/or modules thereof, or as examples of entities including apparatuses and/or modules therefore), are software code independent and can be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved;

- generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the embodiments and its modification in terms of the functionality implemented;

- method steps and/or devices, units or means likely to be implemented as hardware components at the above-defined apparatuses, or any module(s) thereof, (e.g., devices carrying out the functions of the apparatuses according to the embodiments as described above) are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components;

- devices, units or means (e.g. the above-defined network entity or network register, or any one of their respective units/means) can be implemented as individual devices, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, unit or means is preserved;

- an apparatus like the user equipment and the network entity /network register may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution/being run on a processor; - a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example.

In general, it is to be noted that respective functional blocks or elements according to above-described aspects can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device.

Generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present disclosure. Devices and means can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to a skilled person.

Software in the sense of the present description comprises software code as such comprising code means or portions or a computer program or a computer program product for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium such as a computer-readable (storage) medium having stored thereon a respective data structure or code means/portions or embodied in a signal or in a chip, potentially during processing thereof.

The present disclosure also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable.

In view of the above, there are provided measures for enabling intent driven cognitive autonomous networks. Such measures exemplarily comprise receiving network demand information indicative of a network related demand, wherein said network demand information includes context information for said network related demand and parameter information for said network related demand, assigning said network related demand a network demand type of a plurality of network demand types based on said network demand information, and deciding on implementation measures for achieving said network related demand based on said assigned network demand type.

Even though the disclosure is described above with reference to the examples according to the accompanying drawings, it is to be understood that the disclosure is not restricted thereto. Rather, it is apparent to those skilled in the art that the present disclosure can be modified in many ways without departing from the scope of the inventive idea as disclosed herein.

List of acronyms and abbreviations

3GPP Third Generation Partnership Project

CAN cognitive autonomous network

CCO coverage and capacity optimization

CF cognitive function

CIO cell individual offset

HO handover

IBN intent-based networking

ICIC inter-cell interference coordination

IDNM intent-driven network management

IDNMS intent-driven network management system

IFS intent fulfillment system INAFO intent-driven network automation function orchestrator ISP intent specification platform KPI key performance indicator MNO mobile network operator MOI managed object instance NAF network automation function NOM network objectives manager O-RAN open radio access network RAN radio access network RET remote electrical tilt SDO Standards Development Organization

TXP transmit power

Claims

1. A method comprising receiving network demand information indicative of a network related demand, wherein said network demand information includes context information for said network related demand and parameter information for said network related demand, assigning said network related demand a network demand type of a plurality of network demand types based on said network demand information, and deciding on implementation measures for achieving said network related demand based on said assigned network demand type.

2. The method according to claim 1, further comprising determining ability for addressing said network related demand based on said network demand information, and if, as a result of said determining, said ability is acknowledged, the method further comprises subjecting said network related demand to said assigning and said deciding, and if, as a result of said determining, said ability is not acknowledged, the method further comprises at least one of forwarding said network demand information towards a network entity responsible for addressing network related demands, and returning said network demand information towards an origin of said network demand information.

3. The method according to claim 2, wherein in relation to said determining, the method further comprises analyzing whether said context information includes at least one context entry defining a network control parameter or a network metric, analyzing whether said parameter information includes at least one parameter entry defining a network control parameter or a network metric, and acknowledging said ability, if, as a result of said analyzing, said context information includes said at least one context entry defining a network control parameter or a network metric and/or said parameter information includes said at least one parameter entry defining a network control parameter or a network metric.

4. The method according to any of claims 1 to 3, wherein said plurality of network demand types includes a first network demand type, and in relation to said assigning, the method further comprises selecting said first network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network control parameter, and said parameter information includes no parameter entry, selecting said first network demand type, if said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network control parameter, and said context information includes no context entry, and selecting said first network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network control parameter, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network control parameter.

5. The method according to any of claims 1 to 4, wherein said plurality of network demand types includes a second network demand type, and in relation to said assigning, the method further comprises selecting said second network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network metric, and said parameter information includes no parameter entry, selecting said second network demand type, if said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network metric, and said context information includes no context entry, and selecting said second network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network metric, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network metric.

6. The method according to any of claims 1 to 5, wherein said plurality of network demand types includes a third network demand type, and in relation to said assigning, the method further comprises selecting said third network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network control parameter, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network metric, and selecting said third network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network metric, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network control parameter.

7. The method according to claims 6, wherein in relation to said deciding, the method further comprises specifying, if said third network demand type is assigned, at least one cognitive function entity and a controller entity controlling said at least one cognitive function entity, first actions to be implemented by said at least one cognitive function entity, and second actions to be implemented by said controller entity, transmitting, towards said at least one cognitive function entity, a first instruction including information on said first actions, transmitting, towards said controller entity, a second instruction including information on said second actions, and transmitting, towards said controller entity, a third instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented.

8. The method according to any of claims 5 to 7, wherein in relation to said deciding, the method further comprises specifying, if said second network demand type is assigned, at least one cognitive function entity and a controller entity controlling said at least one cognitive function entity, and actions to be implemented by said at least one cognitive function entity, transmitting, towards said at least one cognitive function entity, a first instruction including information on said actions, and transmitting, towards said controller entity, a second instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented.

9. The method according to any of claims 4 to 8, wherein in relation to said deciding, the method further comprises specifying, if said first network demand type is assigned, a controller entity controlling at least one cognitive function entity, and actions to be implemented by said controller entity, and transmitting, towards said controller entity, an instruction including information on said actions.

10. The method according to any of claims 1 to 9, further comprising receiving information indicative of that at least one of said implementation measures raise a conflict.

11. The method according to claim 10, further comprising transmitting, towards an origin of said network demand information, an indication that said network related demand raises said conflict.

12. A method of a controller entity controlling at least one cognitive function entity, the method comprising receiving at least one of a first instruction including information on actions to be implemented in relation to a network related demand and a second instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented in relation to said network related demand, verifying said actions to be implemented or said action suggestions, and if, as a result of said verifying, a conflict is determined transmitting information indicative of that at least one of said actions to be implemented or at least one of said or said action suggestions raise a conflict.

13. An apparatus comprising receiving circuitry configured to receive network demand information indicative of a network related demand, wherein said network demand information includes context information for said network related demand and parameter information for said network related demand, assigning circuitry configured to assign said network related demand a network demand type of a plurality of network demand types based on said network demand information, and deciding circuitry configured to decide on implementation measures for achieving said network related demand based on said assigned network demand type.

14. The apparatus according to claim 13, further comprising determining circuitry configured to determine ability for addressing said network related demand based on said network demand information, and subjecting circuitry configured to, if, as a result of said determining circuitry, said ability is acknowledged, subject said network related demand to said assigning circuitry and said deciding circuitry, and at least one of forwarding circuitry configured to, if, as a result of said determining circuitry, said ability is not acknowledged, forward said network demand information towards a network entity responsible for addressing network related demands, and returning circuitry configured to, if, as a result of said determining circuitry, said ability is not acknowledged, return said network demand information towards an origin of said network demand information.

15. The apparatus according to claim 14, further comprising analyzing circuitry configured to analyze whether said context information includes at least one context entry defining a network control parameter or a network metric, and to analyze whether said parameter information includes at least one parameter entry defining a network control parameter or a network metric, and acknowledging circuitry configured to acknowledge said ability, if, as a result of said analyzing, said context information includes said at least one context entry defining a network control parameter or a network metric and/or said parameter information includes said at least one parameter entry defining a network control parameter or a network metric.

16. The apparatus according to any of claims 13 to 15, wherein said plurality of network demand types includes a first network demand type, and the apparatus further comprises selecting circuitry configured to select said first network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network control parameter, and said parameter information includes no parameter entry, select said first network demand type, if said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network control parameter, and said context information includes no context entry, and to select said first network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network control parameter, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network control parameter.

17. The apparatus according to any of claims 13 to 16, wherein said plurality of network demand types includes a second network demand type, and the apparatus further comprises selecting circuitry configured to select said second network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network metric, and said parameter information includes no parameter entry, select said second network demand type, if said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network metric, and said context information includes no context entry, and to select said second network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network metric, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network metric.

18. The apparatus according to any of claims 13 to 17, wherein said plurality of network demand types includes a third network demand type, and the apparatus further comprises selecting circuitry configured to select said third network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network control parameter, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network metric, and to select said third network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network metric, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network control parameter.

19. The apparatus according to claims 18, further comprising specifying circuitry configured to, if said third network demand type is assigned, specify at least one cognitive function entity and a controller entity controlling said at least one cognitive function entity, first actions to be implemented by said at least one cognitive function entity, and second actions to be implemented by said controller entity, and transmitting circuitry configured to transmit, towards said at least one cognitive function entity, a first instruction including information on said first actions, transmit, towards said controller entity, a second instruction including information on said second actions, and to transmit, towards said controller entity, a third instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented.

20. The apparatus according to any of claims 17 to 19, further comprising specifying circuitry configured to, if said second network demand type is assigned, specify at least one cognitive function entity and a controller entity controlling said at least one cognitive function entity, and actions to be implemented by said at least one cognitive function entity, and transmitting circuitry configured to transmit, towards said at least one cognitive function entity, a first instruction including information on said actions, and to transmit, towards said controller entity, a second instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented.

21. The apparatus according to any of claims 16 to 20, further comprising specifying circuitry configured to, if said first network demand type is assigned, specify a controller entity controlling at least one cognitive function entity, and actions to be implemented by said controller entity, and transmitting circuitry configured to transmit, towards said controller entity, an instruction including information on said actions.

22. The apparatus according to any of claims 13 to 21, further comprising receiving circuitry configured to receive information indicative of that at least one of said implementation measures raise a conflict.

23. The apparatus according to claim 22, further comprising transmitting circuitry configured to transmit, towards an origin of said network demand information, an indication that said network related demand raises said conflict.

24. An apparatus of a controller entity controlling at least one cognitive function entity, the apparatus comprising receiving circuitry configured to receive at least one of a first instruction including information on actions to be implemented in relation to a network related demand and a second instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented in relation to said network related demand, verifying circuitry configured to verify said actions to be implemented or said action suggestions, and transmitting circuitry configured to, if, as a result of said verifying, a conflict is determined, transmit information indicative of that at least one of said actions to be implemented or at least one of said or said action suggestions raise a conflict.

25. An apparatus comprising at least one processor, at least one memory including computer program code, and at least one interface configured for communication with at least another apparatus, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform: receiving network demand information indicative of a network related demand, wherein said network demand information includes context information for said network related demand and parameter information for said network related demand, assigning said network related demand a network demand type of a plurality of network demand types based on said network demand information, and deciding on implementation measures for achieving said network related demand based on said assigned network demand type.

26. The apparatus according to claim 25, wherein the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform determining ability for addressing said network related demand based on said network demand information, and if, as a result of said determining, said ability is acknowledged, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform subjecting said network related demand to said assigning and said deciding, and if, as a result of said determining, said ability is not acknowledged, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform at least one of forwarding said network demand information towards a network entity responsible for addressing network related demands, and returning said network demand information towards an origin of said network demand information.

27. The apparatus according to claim 26, wherein in relation to said determining, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform analyzing whether said context information includes at least one context entry defining a network control parameter or a network metric, analyzing whether said parameter information includes at least one parameter entry defining a network control parameter or a network metric, and acknowledging said ability, if, as a result of said analyzing, said context information includes said at least one context entry defining a network control parameter or a network metric and/or said parameter information includes said at least one parameter entry defining a network control parameter or a network metric.

28. The apparatus according to any of claims 25 to 27, wherein said plurality of network demand types includes a first network demand type, and in relation to said assigning, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform selecting said first network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network control parameter, and said parameter information includes no parameter entry, selecting said first network demand type, if said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network control parameter, and said context information includes no context entry, and selecting said first network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network control parameter, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network control parameter.

29. The apparatus according to any of claims 25 to 28, wherein said plurality of network demand types includes a second network demand type, and in relation to said assigning, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform selecting said second network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network metric, and said parameter information includes no parameter entry, selecting said second network demand type, if said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network metric, and said context information includes no context entry, and selecting said second network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network metric, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network metric.

30. The apparatus according to any of claims 25 to 29, wherein said plurality of network demand types includes a third network demand type, and in relation to said assigning, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform selecting said third network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network control parameter, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network metric, and selecting said third network demand type, if said context information includes at least one context entry, and each of said at least one context entry defines a respective network metric, and said parameter information includes at least one parameter entry, and each of said at least one parameter entry defines a respective network control parameter.

31. The apparatus according to claims 30, wherein in relation to said deciding, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform specifying, if said third network demand type is assigned, at least one cognitive function entity and a controller entity controlling said at least one cognitive function entity, first actions to be implemented by said at least one cognitive function entity, and second actions to be implemented by said controller entity, transmitting, towards said at least one cognitive function entity, a first instruction including information on said first actions, transmitting, towards said controller entity, a second instruction including information on said second actions, and transmitting, towards said controller entity, a third instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented.

32. The apparatus according to any of claims 29 to 31, wherein in relation to said deciding, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform specifying, if said second network demand type is assigned, at least one cognitive function entity and a controller entity controlling said at least one cognitive function entity, and actions to be implemented by said at least one cognitive function entity, transmitting, towards said at least one cognitive function entity, a first instruction including information on said actions, and transmitting, towards said controller entity, a second instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented.

33. The apparatus according to any of claims 28 to 32, wherein in relation to said deciding, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform specifying, if said first network demand type is assigned, a controller entity controlling at least one cognitive function entity, and actions to be implemented by said controller entity, and transmitting, towards said controller entity, an instruction including information on said actions.

34. The apparatus according to any of claims 25 to 33, wherein the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform receiving information indicative of that at least one of said implementation measures raise a conflict.

35. The apparatus according to claim 34, wherein the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform transmitting, towards an origin of said network demand information, an indication that said network related demand raises said conflict.

36. An apparatus of a controller entity controlling at least one cognitive function entity, the apparatus comprising at least one processor, at least one memory including computer program code, and at least one interface configured for communication with at least another apparatus, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform: receiving at least one of a first instruction including information on actions to be implemented in relation to a network related demand and a second instruction indicative of that action suggestions from said at least one cognitive function entity are to be implemented in relation to said network related demand, verifying said actions to be implemented or said action suggestions, and if, as a result of said verifying, a conflict is determined transmitting information indicative of that at least one of said actions to be implemented or at least one of said or said action suggestions raise a conflict.

37. A computer program product comprising computer-executable computer program code which, when the program is run on a computer, is configured to cause the computer to carry out the method according to any one of claims 1 to 11 or 12.

38. The computer program product according to claim 37, wherein the computer program product comprises a computer-readable medium on which the computer-executable computer program code is stored, and/or wherein the program is directly loadable into an internal memory of the computer or a processor thereof.