INTENT SPECIFICATION FOR AUTOMATED CONTROL OF COMMUNICATION

NETWORKS

TECHNICAL FIELD

At least some embodiments relate to an apparatus and a method for intent specification for automated control of communication networks.

In particular, at least some embodiments relate to Cognitive Autonomous Networks (CAN) in 5G (radio access) networks and other (future) generations of wireless/mobile networks and specifically, the use of intents in managing networks.

BACKGROUND

Owing to the complexity of networks, there is always push for more automation and abstraction. One recent solution for the abstraction is through the use of intents in what may be termed Intent-Based Networking (IBN). Therein, the network should be able to respond to user's or operator's intents without the user/operator specifying the technical details of how his intended outcome may be realized. There has been, however, no clear description of how the intent system is structured to implement this desired outcome.

Reference [1] proposes an intent refinement process with a chatbot that is trained using machine learning to capture intents from Google® assistant to assist non-expert users to configure their home networks. Mobile communication networks are however very complex to use a simple chatbot. A more comprehensive intent capture platform is required.

LIST OF REFERENCES

[1] Arthur Selle Jacobs, Ricardo Jose Pfitscher, Ronaldo Alves Ferreira, Lisandro Zambenedetti Granville, "Refining Network Intents for Self-Driving Networks", in Proceedings of ACM SIGCOMM 2018 Workshop on Self-Driving Networks, Budapest, Hungary, August 24, 2018 (SelfDN Ί8). [2] Jorgensen, Niels Terp Kjeldgaard, Daniela Laselva, and Jeroen Wigard. "On the potentials of traffic steering techniques between HSDPA and LTE." 2011 IEEE 73rd Vehicular Technology Conference (VTC Spring). IEEE, 2011.

LIST OF ABBREVIATIONS

5G Fifth Generation

CAN Cognitive Autonomous Networks

CLI Command Line Interface

GUI Graphical User Interface

IBN Intent-Based Networking

IoT Internet of Things

SON Self-Organizing Network

SUMMARY

At least some embodiments aim at overcoming the above drawbacks.

According to at least some embodiments, an apparatus and a method for defining, specifying and capturing a user or operator intent for automated control of communication networks are provided.

According to at least some aspects, an apparatus, a method and a non- transitory computer-readable storage medium are provided as specified by the appended claims.

In the following, example embodiments and example implementations will be described with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 shows a schematic diagram illustrating an intent specification platform according to at least some embodiments. Fig. 2 shows a schematic diagram illustrating a traffic steering feature or SON function.

Fig. 3 shows a schematic diagram illustrating the intent specification platform according to at least some embodiments, when used for traffic steering.

Fig. 4 shows a schematic block diagram illustrating a configuration of a control unit in which examples of embodiments are implementable.

DESCRIPTION OF THE EMBODIMENTS

In the following, example embodiments and example implementations of an intent specification apparatus and an intent specification method will be described.

1. Outline of Example Embodiments

According to at least some embodiments, the intent specification apparatus and the intent specification method are capable of defining, specifying and capturing intents, e.g. user or operator intents, for automated control of communication networks.

According to at least some embodiments, the intent specification apparatus and the intent specification method are implemented by an intent specification platform (ISP) 110 illustrated in Fig. 1.

According to at least some embodiments, the intent specification apparatus and the intent specification method specify, using a syntax, an intent regarding control of a communication network, wherein the syntax comprises at least a control object of the communication network and a verb which indicates what action to do with the control object.

According to at least some embodiments, the syntax further comprises at least one of: a context and one or more parameters, wherein the context and the one or more parameters indicate with what parameters and under what conditions the action is to be done.

For example, the syntax for specifying network control intents (e.g. network management intents) captures what needs to be done, where, with what parameters and under what conditions it should be done.

According to at least some embodiments, the intent specification apparatus and the intent specification method extract, based on the syntax, the intent from at least one of value entries or statements.

For example, the ISP 110 provides for objects for submitting intents - either explicitly as a dictionary of field/value entries or implicitly from some statements.

According to at least some embodiments, the intent specification apparatus comprises a first user interface for inputting the value entries or statements.

For example, the ISP 110 comprises interfaces 114 (which are also referred to as first user interface in this description) and mechanisms for submitting intents, e.g. GUI 101, CLI 102, means for inputting a text string 103 and/or means for inputting an audio command 104.

According to at least some embodiments, the intent specification apparatus and the intent specification method classify the intent into at least one of the following states: a first state indicating that the intent is declared, a second state indicating that the intent is declared and comprises execution logic for the execution of the intent by the communication network, a third state indicating that the intent is declared, comprises the execution logic and can be executed by the communication network, and a fourth state indicating that the execution logic of the intent is under execution in the communication network. For example, the first state indicates that the intent is classified as declared, i.e. the intent is listed but does not comprise execution logic. The second state indicates that the intent is classified as defined. In the second state, the intent has execution logic. The third state indicates that the intent is classified as being supported, i.e. the intent can be executed. The fourth state indicates that the intent is classified as being active, i.e. the intent is deployed to network or is under execution.

According to at least some embodiments, the intent specification apparatus and the intent specification method acquire attributes from a storing unit storing the attributes, wherein the attributes are usable for specifying the intent.

According to at least some embodiments, the intent specification apparatus and the intent specification method define an intent based on the syntax and create execution logic for the intent.

For example, the storing unit stores an intent-attributes database or catalog of candidate objects, verbs, etc., which can be used for specifying the intent.

According to at least some embodiments, the storing unit is implemented by an intent catalog or database 120 shown in Fig. 1. In the example of Fig. 1, an intent catalog interface 116 is provided between the intent catalog or database 120 and the ISP 110.

According to at least some embodiments, the intent specification apparatus comprises the storing unit.

According to at least some embodiments, the intent specification apparatus and the intent specification method are used to identify a list of supported intents. According to at least some embodiments, the intent specification apparatus comprises a second user interface for querying the storing unit for associations between at least one of verbs, contexts, parameters and control objects.

For example, the second user interface allows a user to query the intent catalog or database 120 for supported verbs, contexts and parameters for a given control object or vice-versa. For example, the second user interface is part of the first user interface 114.

According to at least some embodiments, the intent specification apparatus comprises a first interface, and the intent specification apparatus and the intent specification method acquire, via the first interface, at least one of the control object and the attributes from a network management apparatus of the communication network.

For example, the first interface is an interface (not shown in Fig. 1) to network management systems to read managed (e.g. controlled) objects and attributes.

For example, the ISP 110 provides for mechanisms (e.g. parsers) 111 for recognizing and parsing user input for implicit intents into a network management intent, i.e. identifying the different fields in the input string/audio in line with the defined syntax. According to at least some embodiments, the input is received from different user interfaces 114 and mechanisms including CLI 102, GUI 101 (e.g. drop downs). The parsers 111 parse the input to identify the different intent-related fields therein that match the defined syntax.

According to at least some embodiments, to specify an intent comprises mechanisms for declaring and/or creating intents by using or extending the list of candidate objects, verbs, parameters and contexts in the intent catalog or database 120 and by combining attributes to create an intent.

According to at least some embodiments, the intent specification apparatus and the intent specification method check, based on rules defining the syntax, correctness and completeness of the intent that has been specified.

For example, the ISP 110 comprises a mechanism 112 for enforcing syntax rules and checking for correctness and completeness of the specified intent. For example, the checking for correctness and completeness includes checks on whether the specified verb is supported, the object is supported for the verb or the required attributes (context, parameters, ...) are included. According to an example implementation, the syntax enforcement mechanism 112 is partly used to parse the intent for correctness and completeness.

According to at least some embodiments, the intent specification apparatus and the intent specification method authenticate a user for the right to execute the intent.

For example, the ISP 110 comprises an authenticator 113 to authenticate a user for the right to execute a specific intent. According to an example implementation, the authentication is extended to include the right to execute the intent for specific attributes of the intent.

According to at least some embodiments, the intent specification apparatus comprises a second interface and the intent specification apparatus and the intent specification method receive credentials fitting the intent via the second interface.

For example, at least part of the interfaces 101-104, 114 are used as the second interface for submitting credentials fitting the selected intent. According to at least some embodiments, the intent specification apparatus comprises a third interface and the intent specification apparatus and the intent specification method send a first message via the third interface.

For example, the ISP 110 comprises, as the third interface, an intent specification interface 115 for exchanging information with an intent fulfillment system 130 e.g. to send an intent for execution to the intent fulfillment system 130 or to receive reports on the success of the execution from the intent fulfillment system 130.

According to at least some embodiments, the first message includes a request for executing the intent.

According to at least some embodiments, the intent specification apparatus and the intent specification method receive a second message via the third interface.

According to at least some embodiments, the second message comprises an indication of a result of execution of the intent and optionally a reason for the result.

According to at least some embodiments, the second message comprises execution logic for the intent.

According to at least some embodiments, the intent specification apparatus comprises a third user interface, and the intent specification apparatus and the intent specification method send a third message via the third user interface.

According to at least some embodiments, the third user interface comprises at least part of the interface 114, 101-104. According to at least some embodiments, the third message comprises a request for a response from the user regarding a syntax problem.

According to at least some embodiments, the third message comprisea response on a result of an execution of the intent and optionally a reason for the result.

For example, the first and third messages are sent by the ISP 110 to fulfil the different aspects of the intent specification. Among these are messages sent to the intent fulfillment system 130 via the intent specification interface 115 e.g. to execute the intent, and to the user, e.g. using the interfaces 114, e.g. for response regarding syntax problems, or responses on the success /failure of intent execution with the respective reason where applicable.

For example, the second and fourth messages are received by the ISP 110 to fulfil the different aspects of the intent specification. Among these are messages received from the intent fulfillment system 130 via the intent specification interface 115, regarding the success /failure of intent execution with the respective reason where applicable.

2. Detailed Description of Example Embodiments and Example Implementations

2.1 Definitions according to at least some embodiments An intent is a statement of what one entity (e.g. an operator) wishes to have fulfilled. It does not state or in any way indicate how such desired outcomes can or should be fulfilled, i.e., the intent is the reasoning behind a goal or objective that then can be achieved by undertaking some actions.

According to at least some embodiments, a basic intent is specified as: do something to something given some conditions and using some parameters. Examples of basic intents, as statement that the operator can invoke, include the following: 1. Restrict/deny Handovers of high mobility users to small cells.

2. Undo previous command.

3. Allow load balancing to cell c /small cells/ only urban cells.

4. Collect Carrier Aggregation statistics for all cells in xyz city.

As can be seen from the examples, an intent is identified by four fields - a verb, an object, a set of contexts and one or more parameters. The "verb" represents the action that the user or operator wishes to be accomplished.

In the examples above, the verbs are "restrict/deny", "undo", "allow", and "collect". The object is the network entity to which that verb must be applied, and such object may be physical, hardware, software or even logical. In the examples, the objects are "handover", "command", "load balancing" and "Carrier Aggregation statistics" respectively. The contexts represent the information of interest to the fulfillment system, which information may change the way the intent is fulfilled. In the examples above, the contexts include "high mobility users" "small cells", "urban cells", and "city xyz". Finally, the parameters are those attributes related to the object that may be useful for fulfilling the specific intent. Both contexts and parameters are optional since not all intents will require them. Moreover, it may not always be easy to distinguish the contexts and parameters. For example, according to at least some embodiments, "high mobility" is also considered an input parameter for the "deny handovers" intent.

Note also that basic intents can also be high-level intents that require many low commands to be fulfilled. Examples of such high-level intents are:

1. Instantiate a network slice for client ABC to support IoT traffic in xyz city.

2. Increase network-wide energy savings by at least 5%.

In these examples, the verbs "instantiate" and "increase" are respectively applied to the objects "network slice" and "energy savings" for the respective contexts "city xyz" and "network wide" with the parameters "IoT traffic" and "5% energy consumption". According to at least some embodiments, a compound intent is compiled as a combination of multiple basic intents using logical conjunctions such as 'AND', 'OR', 'NOT'.

A candidate intent is an intent that has been designed and whose logic has been implemented in the system and as such can be executed when needed.

2.2 Syntax according to at least some embodiments

Corresponding to the definition above, the structure of the basic intent is a hash function similar to that shown in Expression (1) below:

(1)

Verb: a_verb;

Object: a_network_object;

Context { context"!: context1_value context"!: context1_value

}

Parameters { parameter"!: parameter1_value parameter"!: parameter1_value

}

The function has four entries with the keys as verb, object, context and parameters. The value for the verb is a single entry while the object (e.g. control object) comprises one or a plurality of network objects that are manageable (e.g. controllable). The values for both context and parameters are hash functions, where the keys are respectively contexts and parameters applicable to the specific combination of verb and object. The values for each entry in the context and parameter hash functions comprise at least one of a single value, an array or a hash function depending on the specific entry.

2.3 Intent modes in the storing unit, e.g. the intent catalog or data base According to at least some embodiments, the ISP 110 assumes that there exists a storing unit, e.g. an intent catalog or data base 120, which contains a list of all intents and their respective attributes.

According to at least some embodiments, the intent catalog or data base 120 contains a list of candidate objects and attributes which can be used to define intents. According to at least some embodiments, the list is populated by the list of managed objects read from network management systems. According to at least some embodiments, an interface (aforementioned first interface) is implemented from the network management systems to either the ISP 110 or to the intent catalog or database 120 through which the list of managed objects can be read.

According to at least some embodiments, the intents in the intent catalog or database 120 are identified by a unique identifier called the "intent identifier", the intent name and a corresponding execution logic or execution graph, as shown in Table 1 below. According to at least some embodiments, the intent catalog or database 120 also includes users or user groups with the rights to execute specific intents (referred to as Execution rights in Table 1).

The intent catalog or database 120 also includes the activity status (referred to as Status in Table 1) of the different intents which indicates the extent to which the intent can be executed or not. As described above, according to at least some embodiments, the status of the intent is classified and changed to one of the modes: declared, defined, supported and active. An intent is classified as declared in case it is listed in the intent catalog or database 120 but does not necessarily have the required execution logic.

An intent is classified as defined in case the corresponding execution logic has been defined and if needed the intent can be executed.

An intent is classified as supported in case the intent can be executed; otherwise, it cannot be executed. It follows that a supported intent has both been declared and defined.

An intent is classified as active in case the intent has been deployed to the network and the corresponding execution logic is under execution e.g. by the network functions and processes module 140 illustrated in Fig. 1.

According to at least some embodiments, the intent attributes are either explicitly defined in full, i.e., there is no ambiguity allowed in the intent catalog or database 120 which implies that a new intent should be defined if the same task as for an existing intent needs to be accomplished with a different context. To avoid explicitly listing the intents in full within the intent catalog or database 120, an alternative approach is to only list relations among combinations of objects/verbs and combinations of contexts and parameters that are supported for each object-verb pair. This allows the user to define an intent on the fly by combining the required attributes. According to at least some embodiments, this is achieved using a context/parameter "regex" language or by including a sub-catalog for contexts.

2.4 User vocabulary and interfaces according to at least some embodiments According to at least some embodiments, the ISP 110 supports the following user vocabulary regarding intents:

Declare/create intent, which will add the corresponding entry to the intent catalog or database 120. Define intent, which, according to at least some embodiments, describes an execution logic to be implemented by the intent fulfillment system 130.

Change intent's mode to any of the modes {declared, defined, supported, active or otherwise}.

Query the intent catalog or database 120 for attributes for a specific intent.

Fulfil/execute a specific intent.

According to at least some embodiments, the intent vocabulary is submitted via a multiplicity of user interfaces 114. A simple interface is the Command Line Interface (CLI) 102 where the user specifies the intent in a predefined language that allows the intent to be interpreted. According to at least some embodiments, the language specifies the ordering of the terms, e.g. in a way closer to imperative English language, for example,

"do a_verb to an_object given/when/in some_context(s) using some_parameter( s)".

According to at least some embodiments, the language is less close to human language and only captures the critical terms. For the statement "do a_verb to an_object given/when/in some_context(s) using some_parameter(s)" , the equivalent CLI statement using a delimiter <d> e.g. a tab, space, or otherwise is:

”a_verb <d> an_object <d> some_context(s) <d> some_parameter(s)"

Another user interface is the Graphical User Interface (GUI) 101 which allows the user to select the fields of interest for the specific intent. According to at least some embodiments, the GUI 101 also is connected to the intent fulfillment system 130 (which connection is not shown in Fig. 1) so that it already filters the provided option and offers only those that are applicable, e.g. presents only the candidate contexts and parameters that are allowed for a specific verb-object combination. According to at least some embodiments, the user intent is submitted as text, e.g. through a text file of any format, via interface 103. There are multiple options through which the ISP 110 can parse (e.g. using parsers 111) or learn to parse the text, among them are topic modelling and natural language processing.

According to at least some embodiments, the user intent is submitted as an audio command, using interface 104, which the ISP 110 parses (e.g. using parsers 111) to create the intent object.

According to at least some embodiments, the ISP 110 contains a database (e.g. the intent catalog or database 120) of candidate objects and verbs as well as contexts and parameters which can be combined by the user to specify a candidate intent.

According to at least some embodiments, the intent catalog or database 120 is part of the ISP 110.

2.5 Intent specification interface 115 according to at least some embodiments

The outcome of the ISP 110 is the candidate intent submitted to the intent fulfillment system 130 through the intent specification interface 115. The candidate intent is submitted as the filled-out hash function equivalent to Expression (1).

According to at least some embodiments, the ISP 110 supports intent execution in a multi-vendor environment, i.e. where the full intent platform is not necessarily from one vendor. For this purpose, the intent specification interface 115 is configured to ensure that an intent can be specified on the ISP 110 of one vendor and executed on another vendor's intent fulfillment system 130. According to at least some embodiments, the ISP 110 queries the intent fulfillment system 130 via the intent specification interface 115 to determine whether execution logic for a particular intent exists. According to at least some embodiments, the ISP 110 then updates the intent catalog or database 120 accordingly.

According to at least some embodiments, the intent fulfillment system 130 indicates via the intent specification interface 115 the presence of execution logic.

According to at least some embodiments, the fulfillment system 130 sends a description of the execution logic in form of a graph of actions to be executed or network functions to be called, via the intent specification interface 115.

According to at least some embodiments, the ISP 110 queries the intent fulfillment system 130 via the intent specification interface 115 to determine if that intent can be fulfilled, even when it is already known that the logic exists. According to at least some embodiments, the ISP 110 then updates the intent catalog or database 120 accordingly.

According to at least some embodiments, the ISP 110 requests for the execution/fulfillment of a specific intent via the intent specification interface 115.

According to at least some embodiments, the intent fulfillment system 130 reports about the degree of success or failure of a request to execute/fulfil a specific intent, via the intent specification interface 115.

2.6 Intent catalog interface 116 according to at least some embodiments

According to at least some embodiments, the ISP 110 has an interface to the intent catalog or database 120. Over this interface, the ISP 110 is configured to perform at least one of the following: add new intents to the intent catalog or database 120 after they have been declared; change the status of intents to declared, defined, supported or active; change the declaration of an intent by changing specific fields of the intent; and query an intent or specific field of the intent.

According to at least some embodiments, the intent catalog or database 120 sends a report on a specific intent over the intent catalog interface 116, including reports of specific values of that intent's dictionary.

According to at least some embodiments, the intent catalog or database 120 is contained within the ISP 110 in which case the intent catalog interface 116 is internal to the ISP 110.

2.7 Declaring a new candidate intent according to at least some embodiments

According to at least some embodiments, a new candidate intent is created or declared by specifying a combination of verb, object, contexts and parameters. According to at least some embodiments, this involves extending the list of candidate verbs, objects, contexts and parameters in the intent catalog or database 120. When declared, the ISP 110 adds the corresponding intent to the intent catalog or database 120 and, as default, marks it as undeclared. Undeclared in this case implies that the fields may be incomplete, if some of the necessary parameters are not specified. According to at least some embodiments, the operator then explicitly changes the status to declared if all fields are deemed complete. Alternatively, according to at least some embodiments, the ISP 110 asks the fulfillment system 130 if the intent can be fulfilled in which case the ISP 110 changes the status to declared and defined if given a positive response, otherwise it leaves it as undeclared. According to at least some embodiments, the context and parameters fields are not always included in an intent declaration and the declared intent may still be parsed as complete for as long as a corresponding execution logic has been defined and the intent has been confirmed as implementable by the intent fulfillment system 130.

2.8 Intent Fulfillment / request execution according to at least some embodiments

When the intent is first created, the supported field is marked unknown.

The first time an intent is requested to be fulfilled, the ISP 110 checks if the intent is supported. If not the ISP 110 queries the intent fulfillment system 130 via the intent specification interface 115 if the intent fulfillment system 130 can execute the intent. Regardless of the received response, the ISP 110 updates the intent catalog or database 120 accordingly, but if the intent fulfillment system 130 responds negatively, the ISP 110 indicates to the operator that the intent is not supported and cannot be fulfilled.

If the intent is supported or it has been executed before, the ISP 110 requests the intent fulfillment system 130 to fulfill the request to which the intent fulfillment system 130 will respond with the degree of success or failure after the execution.

2.9 Intent completeness and correctness according to at least some embodiments

For the input intent, the ISP 110 checks, e.g. using module 112, that the submitted hash object matches the defined syntax for submitting intents, i.e. that the required fields and their respective values are submitted. According to at least some embodiments, the ISP 110 logs the candidate intent with a timestamp and optionally an automatically generated identifier. The ISP 110 also checks, e.g. using module 112, to ensure the correctness of the values submitted for the respective fields of the intent. According to at least some embodiments, first, the module 112 checks if the specified verb is supported and in particular if the verb is supported for the specified object. The module 112 also checks whether the required attributes (i.e. the contexts, and parameters) are included in the intent specification and that the included values are supported for the verb-object combination.

According to at least some embodiments, this correctness checking is done when an intent has been defined, but it will generally be required to be done before executing an intent, in which case the request for executing the intent is only sent if the intent is found to have been correctly submitted.

2.10 Authentication according to at least some embodiments According to at least some embodiments, the ISP 110 tracks either within the intent catalog or database 120 or separately, the list of users or user groups that are allowed to execute specific intents. According to at least some embodiments, the ISP 110 takes a user's credentials and checks, e.g. using the authenticator 113, if that user is allowed to execute a particular intent by matching those credentials against those users that are allowed to execute the specific intent. According to at least some embodiments, the check also is run against specific attributes of the intent e.g. to confirm if a particular intent can be executed with particular context or parameters.

According to at least some embodiments, the ISP 110 either takes the credentials that have already been submitted when the user first logs into the intent system, or the ISP 110 specifically requests the user for their credentials after the user has requested for the specific intent to be executed.

2.11 ISP user messages according to at least some embodiments To fulfill user requests, according to at least some embodiments, the ISP 110 sends at least one of the following messages across the ISP user interface(s) 101-104, 114:

- Request for user authentication.

- Notifications for granted or denied access and the reasons as may be applicable.

- Notification that a specified intent is either not defined or not supported.

- Responses to queries on the structure or attributes of intents for specific objects.

- Notifications that a specified intent is either incorrect or incomplete.

- Notifications on the success of failure of a user request and any reasons as may be applicable.

Correspondingly, according to at least some embodiments, the IPS 110 is able to receive and act on at least one of the following messages received e.g. via the interfaces 101-104, 114:

Requests to create, define, query or fulfil an intent.

User authentication details including for example a username and a password.

2.12 ISP intent execution related messages according to at least some embodiments

According to at least some embodiments, to fulfill an intent, the ISP 110 sends at least one of the following messages across the intent specification interface 115:

Requests to define or revise the execution logic for a specific intent. Request to execute a specific intent.

Notifications for granted or denied access and the reasons as may be applicable.

According to at least some embodiments, correspondingly, the IPS 110 is able to receive and act on the following messages received e.g. via the intent specification interface 115: Notifications on the success of failure of a specific request and any reasons as may be applicable.

2.13 Advantages

The ISP 110 allows network operators to create and run their intents without having to specify the details on how those intents should be fulfilled. The ISP 110 allows intents specified on one vendor's system to be executed or fulfilled on another vendor's system using a simple interface between the two systems.

2.14 Example Application

As example application of the ISP 110, the operator wishes to adjust Traffic Steering (TS) characteristics and/ or behaviour (see reference [2] for a discussion on TS). This example assumes that there are other automation functions alongside TS, including energy saving, carrier aggregation, etc., as indicated by block 140 in Fig. 3 to be described later on.

The traffic steering feature, as summarized by Fig. 2, is very complicated, so it is a good candidate for intent based network control operations. The operator may wish to readjust the traffic steering behaviour without looking into the specific details and options of the traffic steering feature(s). The configuration options are too many and complicated, so the intent-based control should abstract the complexity and simplify the operator actions through the intent system (i.e. the combination of the ISP 110 and some intent fulfillment system 130).

In general, traffic steering related intents rely on multiple automation/SON or network functions as represented by Fig. 3. It is noted that in Fig. 3 similar reference signs are used to refer to elements similar to those shown in Fig. 1. In particular, the intent fulfillment system 130 comprises traffic steering intent execution logic. Network functions and processes 140 comprise energy savings, carrier aggregation, traffic steering, load balancing and handover optimization. For example, three traffic steering-related intents are defined and utilized:

1) In a city's dense urban central business district the interest is to allow for specifying very strict outcomes.

2) For a rural environment, it is desired to empty a specific traffic layer to allow for energy savings to deactivate those cells.

3) Semi urban environment on the other hand requires a flexible TS regime, i.e., where the TS behavior is adjustable to allow for multiple compromises.

For example, the corresponding TS related intents, respectively called Urban_TS, ESM_TS and Flexible_TS, then are described as follows:

1. Urban_TS: Enforce very strict traffic steering regime that ensures that the load is always balanced to within less than 5% difference between two traffic layers.

2. Energy saving TS (ESM_TS): Empty cell layer z of any traffic.

3. Flexible_TS: Revise TS behavior to reduce effects on mobility performance by amount x%.

According to at least some embodiments, given the above description, example specifications according to the vocabulary of the ISP 110 for the three intents are as described by Table 2: As shown in Table 2, the action in the first row is "declaration" of the intents Urban_TS, ESM_TS and Flexible_TS.

In the second row of Table 2, the action is "fulfill/execute" in which the declared intents Urban_TS, ESM_TS and Flexible_TS are executed by the network functions and processes of block 140, in particular the network functions and processes with respect to traffic steering of block 140, based on the traffic steering intent execution logic of the intent fulfillment system 130.

Now reference is made to Fig. 4, illustrating a simplified block diagram of a control unit 10 that is suitable for use in practicing at least some of the embodiments.

According to at least some embodiment, the control unit 10 implements at least one of hardware, software and firmware of the above-described intent specification apparatus and intent specification method.

The control unit 10 comprises processing resources (e.g. processing circuitry) 11, memory resources (e.g. memory circuitry) 12 and interfaces (e.g. interface circuitry) 13, connected via a link 14. At least some embodiments are implemented by the memory resources 12 storing a program which is executable by the processing resources 11.

The terms "connected," "coupled," or any variant thereof, mean any connection or coupling, either direct or indirect, between two or more elements, and, according to at least some embodiments, encompass the presence of one or more intermediate elements between two elements that are "connected" or "coupled" together. The coupling or connection between the elements can be physical, logical, or a combination thereof. As employed herein two elements are considered to be "connected" or "coupled" together by the use of one or more wires, cables and printed electrical connections, as well as by the use of electromagnetic energy, such as electromagnetic energy having wavelengths in the radio frequency region, the microwave region and the optical (both visible and invisible) region, as non-limiting examples.

Further, as used in this application, the term "circuitry" refers to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and

(b) to combinations of circuits and software (and/or firmware), such as (as applicable): (i) to a combination of processor(s) or (ii) to portions of processor(s)/software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

(c) to circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present.

This definition of "circuitry" applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term "circuitry" would also cover an implementation of merely a processor (or multiple processors) or portion of a processor and its (or their) accompanying software and/or firmware. The term "circuitry" would also cover, for example and if applicable to the particular claim element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in server, a cellular network device, or other network device.

According to an aspect, an intent specification apparatus is provided. The apparatus comprises means for specifying, using a syntax, an intent regarding control of a communication network, wherein the syntax comprises at least a control object of the communication network and a verb which indicates what action to do with the control object. According to at least some embodiments, the syntax further comprises at least one of: a context and one or more parameters, wherein the context and the one or more parameters indicate with what parameters and under what conditions the action is to be done.

According to at least some embodiments, the apparatus further comprises means for extracting, based on the syntax, the intent from at least one of value entries or statements.

According to at least some embodiments, the apparatus further comprises a first user interface for inputting the value entries or statements.

According to at least some embodiments, the apparatus further comprises means for classifying the intent into at least one of the following states: a first state indicating that the intent is declared, a second state indicating that the intent is declared and comprises execution logic for the execution of the intent by the communication network, a third state indicating that the intent is declared, comprises the execution logic and can be executed by the communication network, and a fourth state indicating that the execution logic of the intent is under execution in the communication network.

According to at least some embodiments, the apparatus further comprises means for acquiring attributes from a storing unit storing the attributes, wherein the attributes are usable for specifying the intent.

According to at least some embodiments, the apparatus further comprises the storing unit.

According to at least some embodiments, the apparatus further comprises means for storing the intent into the storing unit. According to at least some embodiments, the apparatus further comprises a second user interface for querying the storing unit for associations between at least one of verbs, contexts, parameters and control objects.

According to at least some embodiments, the apparatus further comprises a first interface, and means for acquiring, via the first interface, at least one of the control object and the attributes from a network management apparatus of the communication network.

According to at least some embodiments, the apparatus further comprises means for checking, based on rules defining the syntax, correctness and completeness of the intent that has been specified.

According to at least some embodiments, the apparatus further comprises means for authenticating a user for the right to execute the intent.

According to at least some embodiments, the apparatus further comprises a second interface, and means for receiving credentials fitting the intent via the second interface.

According to at least some embodiments, the apparatus further comprises a third interface to an intent fulfillment apparatus for implementing execution logic of the intent, and means for sending a first message via the third interface.

According to at least some embodiments, the first message includes a request for executing the intent.

According to at least some embodiments, the apparatus further comprises means for receiving a second message via the third interface.

According to at least some embodiments, the second message comprises: an indication of a result of execution of the intent and optionally a reason for the result, and/or execution logic for the intent.

According to at least some embodiments, the apparatus further comprises means for defining an intent based on the syntax and creating execution logic for the intent.

According to at least some embodiments, the apparatus further comprises a third user interface, and means for sending a third message via the third user interface, wherein the third message comprises: a request for a response from the user regarding a syntax problem, and/or a response on a result of an execution of the intent and optionally a reason for the result.

It is to be understood that the above description is illustrative and is not to be construed as limiting. Various modifications and applications may occur to those skilled in the art without departing from the true spirit and scope of as defined by the appended claims.