WO2012084763A1

WO2012084763A1 - Method for controlling telecommunication network

Info

Publication number: WO2012084763A1
Application number: PCT/EP2011/073165
Authority: WO
Inventors: George Koudouridis
Original assignee: Huawei Technologies Sweden Ab
Priority date: 2010-12-23
Filing date: 2011-12-19
Publication date: 2012-06-28
Also published as: EP2656545A1

Abstract

The invention provides a method of controlling a telecommunications network, the network comprising at least one communicating entity, the method characterized in that control may be applied at entity level/layer, at network level/layer or management level/layer, the level/layer forming a communication unit, a control unit and an information unit wherein the control unit exercises layered control, and the information unit provides access to layered information pertinent to layered control.

Description

METHOD FOR CONTROLLING TELECOMMUNICATION NETWORK Technical field

The invention relates to telecommunication technique, particularly relates to a method for controlling telecommunication network.

Background

Telecommunication networks vary in the architecture and organization.

Summary

Brief description of the drawings

Figure 1 illustrates Functional Architecture of the Cognitive Engine

Figure 2 illustrates Operation of the cognitive engine for control.

Figure 3 illustrates Functional Control Architecture.

Figure 4 illustrates Vertical Control Flow.

Figure 5 illustrates Horizontal Control Flow.

Figure 6 illustrates Knowledge Access Flow.

Figure 7 illustrates Control Order Alternatives.

Figure 8 illustrates Control Cardinality and hierarchy.

Figure 9 illustrates Physical control deployment. Detailed description

Generalised Architecture for control of communication entities

The proposed architecture is applicable for control of any communication node or communication device. These nodes and devices will be referred as communication entities or entities for brevity. The control may be full or partial, i.e., some (at least one) functions of an entity are controlled as compared to a control over all entity's functions. Controlled entities and controlled functions are referred to as managed entities.

Managed entities are controlled and configured by managing entities or management entities.

Functional anatomy of the cognitive cycle function

Figure 1 depicts a Cognitive Engine consisting of four Units, optimisation, sensing/monitoring, configuration/decision and interaction Unit. The Units share a common knowledge base which, depending on type of CE contains the high-level policies and/or rules learnt from previous decisions.

The Optimisation Functional Unit

The Optimisation Functional Unit deals with the optimisation of all models, functional units and optimal control of policies with regards to the managed entity and the environment it operates in. The unit analyses and continuously evaluates the result of previous actions and tries to learn from the evaluation. Furthermore, it combines and analyses information from the Knowledge Base together with information from newly received information from the Interaction Functional Unit and the Sensing/Monitoring Unit. It reasons on various possible actions and forwards them to the

Configuration/Decision Unit.

Learning is the process in which the system collects contextual data, policies, and decision-making results generated from the execution of the learning and

self-optimisation algorithms in order to build knowledge which will be used to improve future decision-making and enable the system to operate proactively. Reasoning is the process in which the system identifies and classifies system states based on patterns and correlations derived from observed parameters and actions, performance metrics and collected statistics.

Sensing/Monitoring Functional Unit The Sensing/Monitoring Unit sense and monitor observable parameters and collect short-term and long-term statistics on parameter values and performance

measurements (information observing operation). It also uniquely identifies the state of the environment, the managed entity and the neighbouring managed entity and defines it accurately and in a concise way (information processing operation).

Monitoring can be done by means of communication based on protocol interactions and/or by means of sensing. Different types of sensors, e.g. light sensors, radio receivers, temperature sensors, movement sensors monitor the node's environment are examples of manage entities that perform sensing and report their information to the Sensing/Monitoring Unit via the Interaction Unit. Configuration/Decision Functional Unit

The Configuration/Decision Unit deals with the process in which certain algorithms are executed (and evaluated) periodically or on certain events/triggers and their outcome will be enforced in terms of managed entities reconfigurations. Based on information from the Sensing/Monitoring Unit and the Optimisation Unit the Configuration/Decision Unit decides on sequel actions. For its decisions it takes into account information collected from the managed entity and managed entity environment where the unit resides as well as information reported from other managed entities.

The Interaction Functional Unit The Interaction Functional Unit deals with interaction modelling for negotiation and communication of decisions and execution/effectuation of selected actions and it provides the interface to external nodes. It collects information about the states and capabilities of surrounding managed entities along with possible actions they intend to take and forwards its own decisions and the actions which it plans to take. Execution of actions is then the process of the actual reconfiguration of the managed entity in order to achieve a specific target. The Knowledge Base Unit

The cognitive engine is supported and realised by means of knowledge stored in a Knowledge Base consisting of facts and rules describing the models required for the realisation of the cognitive engine. The Knowledge Base can be a functional unit of its own or maintained and communicated between functional units as depicted in Figure 1.

Operation of Cognitive Engine for Control

Figure 2 Operation of the cognitive engine for control

As depicted in Figure 2, a control engine independent of the domain it executes it consists of two processes: (i) situation recognition process (SRP) and (ii) the decision and Actuation process (DAP).

Situation/state recognition process - The situation (or state) recognition process is performed by means of the monitoring unit assisted by the interaction/communication unit and the optimisation unit. At any layer of abstraction the monitoring unit monitors relevant parameters and metrics. A situation at any one time is characterised by the specific values these parameters and metrics have with at that time. In their simplest form situations may be described by means of enumeration of all possible

parameter/metrics-value combinations. For continuous parameters that would be intractable and requires quantization or fuzzyfication of parameters' value range. By means of situation analysis and learning, as performed by the optimisation unit, situations can be identified by means of parameter correlations and parameter value patterns. A situation described by means of CE alone is only partial if it doesn't include interacting CEs' situation, operation settings and functions. The reason is that some of the parameter values are directly or indirectly attributed to the actions of other interacting and interfering CEs. The role of the interaction unit is to facilitate the exchange of information/knowledge with neighbouring CEs and/or non-CE entities. The interaction unit allows CEs to collaborate by exchanging information and knowledge that will assist them to better identify a unique environment situation that each one alone fails to recognise by means of the monitoring unit only. To this end exchanging information derived by the situation recognition process implements collaborative CEs.

Decision and Actuation process - Given the situation at anyone time DAP decides what to do i.e., what action should be taken. This action selection decision is performed by the configuration/decision unit. In general, an action can be of two types: execution or interaction. Execution of an action corresponds to a specific configuration of the underlying controlled lower-level CE or managed entity. Interaction with other CEs towards a common decision implies cooperation mechanisms that facilitate independent CEs to reach an agreement on a joint action. Reaching agreements can be done by means of negotiations, auctions, distributed-problem solving and other coordination techniques. Informally, coordination can be regarded as the process by which the individual decisions of the CEs result in good joint decisions for the group. This is the role of the interaction unit in the decision and actuation process. Agreeing on a joint action implies coordinating CEs. By means of statistics and learning or other machine intelligence techniques as implemented by the optimisation unit a CE may learn an optimal set of actions for each recognised situation (for a given purpose). In case of interactions optimisation also include the learning of an optimal negotiation strategy.

The Control Architecture

A CE-equipped entity or CE-equipped node (CN) consists of a Knowledge and information unit and a cognitive control unit both structured in three possible CE layers of different layers of abstraction ranging from a macroscopic level covering the whole network towards a microscopic level covering one node.

A control architecture as described above consists of two parts: (i) a layered control and (ii) a layered model.

• Layered Control: The architecture is described by different levels of control abstraction where each level adds a specific control aspect ranging from self-management, self-organising and self-configuring operation. Layers appear in a specific order where lower layers are controlled by higher layers. • Layered model: The knowledge base is also layered maintaining for the controlling layers information relevant to their scope of control. Each layer effectively restricts the control of the lower layers.

Modular Layered architecture: Higher control layers are not a necessity for lower control layers to operate. Each control layer has access to a specific model of the knowledge base; namely the portion that corresponds to its layers control operation. Each control layer may also have access to the common domain knowledge and the common facts reflecting on the actual situation/state where the CE is situated. Any intermediate layer can be omitted without impact on the operation of the control architecture.

Figure 3 depicts the architecture which is consisting of three units: (i) Cognitive Control Unit (performing control), (ii) Knowledge and Information Unit (maintaining information and models for control operation and optimisation) and (iii) a

Communication Interface Unit (facilitating the communication with managed entities and external entities either to perform control or to exchange information).

Figure 3 Functional Control Architecture Cognitive Control Unit

A complete cognitive control unit that implements the proposed control architecture comprises three layers which from bottom to top are: the configuration layer (CCL), the Organisation Control layer (OCL) and the management Control layer (MCL).

Figure 3 above depicts a network node employing all three instances of CEs, each one implementing a different control layer, that is, a Management CE (MCE), an

Organisation CE (OCE) and a Configuration CE (CCE). All CEs maintain their own parts of knowledge model and state information in the Knowledge base. They also communicate with the managed entities via the communication Interface unit. A description is as follows:

• The management control layer corresponds to a higher-level implementing its own Knowledge model and interfaces towards lower-level CEs and managed entities. It performs high-level reasoning related network management. It operates on set of rules which controls and directs the lower-level CEs towards given a set of objectives (as indicated/instructed by the domain

authority/operator). Each objective corresponds to a unique set of rules that maps to a utility function. Changing objectives requires a change in the set of applicable rules or a change of the utility function. This is done either manually by an operator or by means of learning where the set of rules for a given objective are evaluated and refined. This MCE implements the

self-management automation paradigm where co-management with other MCEs is possible via the communication unit. Management-associated information, models and knowledge are stored in and accessed from the Management Knowledge Layer.

The organisation control layer implements cooperation that embodies various forms of adaptive and/or SON algorithms. At this level OCEs aim at configuring networks and/or coordinating the configuration of nodes in an optimal way in order to serve the objectives imposed by the higher-layer management MCE. The knowledge base maintained by OCE differs from the lower-layer CCE in the sense that rules are expressing joint OCE actions. It implements cooperative strategies and coordination techniques expressed in terms of e.g., game-theory, distributed decision making, distributed problem solving etc. Cooperation and coordination is realised by means of negotiations, joint action/configuration decisions and/or configuration instructions via the Communications unit. Organisation-associated information, models and knowledge are stored in and accessed from the Organisation Knowledge Layer.

The configuration control layer implements a node that controls the operation of an underlying managed entity e.g., RRM, eNB etc. The CCE implementing this layer relies on its interactions with the managed entity it controls via its execution unit in order to monitor the environment it's situated in and make independent decisions. The knowledge base maintained by this CCE differs from the higher-layer OCE in the sense that rules are expressing individual actions only for the managed entity. It implements an independent decision making CCE that collaborates with other CEs by means of information exchange via its communication unit. Joint actions and coordination with other managed entities requires the higher control layer. Configuration-associated information, models and knowledge are stored in and accessed from the Configuration Knowledge Layer.

Figure 3 depicts the proposed layered control architecture and an example of bottom-up control flow with upward control request propagation. Events at the managed entity (1) are received by CCE MU (2) and recognised resulting into an activation of the CCE DU (3). Upon action selection CCE DU communicates the action decision (14) to the CCE IU execution unit which commands the managed entity via the Communication Interface Actuator (15). If the CCE DU fails to find an optimal action it requests activation of the OCE MU (5) via the OCE IU (4). OCE MU activates (6) OCE DU that decides on a action configuration (12) which is effectuated via the OCE IU (13). Similarly if no suitable action can be identified by OCE DU the control propagation moves upward activating (7) MCE MU and performing the steps (8),(9),(10),(11) of the cognition cycle.

The above layered control architecture is also designed for a top-down control with downward control/configuration propagation. The top-down control consists mainly of steps from (10) to (15) . Optional control steps are further described in a subsequent section.

Knowledge and Information Unit

The knowledge and Information Unit is a knowledge base of facts and rules. In general the set of facts and rules may represent represents (i) a model of the system, (ii) a model of the environment in which the knowledge possessing entity interacts in (including other entities and entities' models), (iii) a model of the entity itself including its capabilities, objectives, roles, functions, utilities and actions or (iv) any combination thereof. Facts are represented by parameter-value pairs that build up a model of the environment and the-self i.e., the owner of the facts and the knowledge-base. Facts are used to represent information about

- Monitoring Parameters e.g.,

o the radio environment incl. load, interference etc

o KPIs i.e., performance metrics

- Discovery Parameters o neighbouring entities and neighbouring entities capabilities, state etc - Configuration parameters o Configuration settings e.g., transmitted power settings, etc Rules are represented by parameter-value implications of

premise-implies-conclusion-given-constraints (If <premise> given <constraints> then <conclusion>) type. A premise and a constraint may be a rule or a (conjunction of) fact(s), typically of monitoring types. A conclusion can be a rule or a (conjunction of) fact(s), typically of configuration type. Rules may apply for all values of parameters of a subset of values as defined by numerical operators ==, =<, =>, <,>,!= etc. Rules may imply rules or facts.

The facts and rules may represent (i) domain knowledge, (ii) Situation Knowledge and (iii) Control Knowledge (knowledge categories).

• Domain Knowledge maintains models, facts and rules of the environment laws e.g., radio propagation models, etc. , models of the system dynamics, models of entity operations

• Situation knowledge maintains all the facts and information describing current situation/state of the system such as current network topology, propagation characteristics, traffic load etc.

• Control knowledge maintains models, rules and facts specific to the operation of the cognitive control unit.

The horizontal categorisation reflects on the layered architecture consisting of

• A management knowledge layer

• A organisation knowledge layer

• A configuration knowledge Layer

Each one maintained by the corresponding layer in the control unit. Higher-layers of knowledge have access to the information, models and knowledge of the lower layers.

Communication Interface Unit

The Communication Interface Unit provides the primitives for the CE to communicate and execute its decisions. It consists of three elements: - A sensor unit that is connected to the underlying managed entity, e.g., sensor element, RRM function, e B etc., to receive input and respond to triggering events from the managed entity.

- An actuator unit that translates the control and configuration decisions to interface primitives that can be handled by the managed entity.

- A communicator unit that provides the communication primitives for communication with other CE. The communication primitives correspond to a unified communication language that can be used between any two CEs to exchange information and control signalling.

Typically Sensor and Actuator units are invoked by the execution unit of the interaction unit, whilst the communicator unit is invoked by the

cooperation/communication unit.

Control Flow

In this section the flow of the control is described. Vertical Inter-layer Control Flow

The operation of the control layer is defined by the operation of the cognitive Engine implementing monitor-recognise-decide-interact cognitive loop. The basic characteristic of the design of the layered architecture is that control operation is unified and that lower layers and functions are treated alike i.e., it makes conceptually no difference if the lower level is a control layer itself or the controlled function. Similarly it makes no difference if the higher layer controlling is another control layer or a system administrator.

Figure 4 Vertical Control Flow

A description of the vertical control flow is as follows: By means of input or control messages received by the Monitoring Unit (MU) from the lower control layer DU or function (2), (9) via the Interaction Unit (IU) (1) the control layer recognizes a specific situation or its distance from the target state. Assisted by the Optimisation Unit (OU) for an analysis of the constraints for the perceived situation (3) it invokes the

Configuration /Decision Unit (DU) to decide on a proper action i.e., a proper configuration of the underlying managed entity or lower-level control layer (4). The identification of an optimal configuration may be in assistance with the optimisation unit (5). The configuration is then communicated to (6) and effectuated via the Execution part of the Interaction Unit (7), (10). Typically in case of highest layer (i.e., management layer) an interaction with the upper layer MU (9) and DU (10) (in the figure denoted as MUi₊i and DUi₊i respectively) corresponds to an interaction with the managing entity, i.e., the system administrator and/or policy manager, via a consol rather an interaction with the higher layer's MU and DU. Interaction upwards with a console or downwards with a managed entity is possible by anyone of the control layers.

Optionally, the DU of a higher layer may also control the MU of a lower layer by configuring its monitoring operation (12) via the IU (13), (11). Other optional control flows include the ability of the DUi to signal to the MUi of the same layer about the quality and/or accuracy of the recognition of a system state (14). In general, the proposed control architecture allows for interactions to be initiated/terminated by/to any unit in the CE.

An action/configuration/control execution is performed by the execution part of the interaction unit which invokes the actuator function of the Communication Interface unit. If the receiver is a lower-layer CE then the actuator invokes the sensor function of the Communication Interface unit of the lower layer. If the receiver is a managed entity then the actuator invokes the appropriate action in the Application Programming Interface (API) of the entity.

Horizontal Intra-layer Control Flow

Figure 5 Horizontal Control Flow

Figure 5 above illustrates the inter-layer coordination of control or management, typically at organisation or management level respectively. It depicts the horizontal flow of control between two control layers of two independent

cooperative/coordinating/collaborative CEs. A description of the control flow for the z^'th layer is as follows: Upon the recognition by CE_X of a state of its underlying DUxi.₁ or function/device (2) via IUxi-i, MUxi activates DUxi (3) to determine a proper action (4). If such an optimal action can be taken locally the DUxi effectuates it via IUxi (5) by configuring DUxi-i or underlying managed entity. If an optimal action requires coordination with another CE_y then MUyi is notified (7) via IUxi and IUyi (6). MUyi activates DUyi (8) which either configures its underlying control layer/managed entity accordingly (10) or decides the initiation of a negotiation with CE_X (9) via IUxi and IUyi (11) which is performed interactively by steps (2),(3),(4),(6),(7),(8),(9) and (11). Upon agreement DUxi and DUyi configure their managed entities or DUxi-i (5) and DUyi-i (10) respectively via IUxi and IUxi-i for CE_X and IUyi and IUyi-i for CE_y In general, the proposed control architecture allows for interactions to be

initiated/terminated by/to any unit (and/or managed entity e.g., (12)) between the two CEs.

The proposed architecture also allows simpler forms for collaboration by means of information exchange only and without coordination of action, typically at configuration control level. In this case (illustration of steps omitted) CEx may request information from CEy, MUyi as instructed by DUyi may convey information back to MUxi. Actions can then be decided based on this information by DUxi without acti on/ configurati on coordinati on .

An action/configuration/control coordination/collaboration request is performed by the communication part of the interaction unit which invokes the communicator function of the Communication Interface unit. The communicator function of the sender sends a message to the communicator function of the Communication Interface unit at the receiver end which propagates to the CE by invoking the communicator function of the Communication Interface unit.

Knowledge Access Flow

In this section the flow of the control is described. The term knowledge comprises all information, incl. data, models, facts, rules, functions etc., necessary to perform optimal control.

Figure 6 Knowledge Access Flow Figure 6 depicts the information access flow which in general can be divided in a (i) vertical information/knowledge access and an (ii) horizontal information/knowledge access. Information and the derived from it knowledge is here referred to as knowledge. In general each layer has access to its corresponding knowledge layer and through it also has access to lower knowledge layers. Within the same knowledge layer all knowledge categories have access to each other. Knowledge access implies the ability to read, write or read and write in the knowledge base. Typically an operator obtains access to the knowledge base either directly by means of a console operated by a system administrator or via its corresponding control layer. Model and policy conflicts are identified by the reasoning function of the optimisation unit and alarmed to the operator via consol. Operator may enforce policies by access to the knowledge base.

Vertical Knowledge Access Flow

Vertical knowledge access refers to the access rights of the higher knowledge to read, write, read and write in the knowledge base of the lower layers.

The knowledge within each layer differs in the parameters and models maintained. Typically higher layer consists of knowledge aggregation describing the dynamics of the network in case of management layer or neighbouring network in case of organisation layer. At the configuration layers the parameters describing the actions and senses of the individual managed entity without consideration. To derive higher layer models lower layer models are inspected and used as input for the derivation of higher level models. The derivation is performed by means of interactions between the layers following the control flow steps and the optimisation, monitoring, decision and interaction unit operations.

Horizontal Knowledge Access Flow

Horizontal knowledge access refers to the access rights within the layer and between the Knowledge an information unit and the cognitive control unit.

The knowledge within each layer is read and written by the cognitive control unit. Its functional unit within the cognitive cycle can contribute to the knowledge acquisition and model derivation in any of the knowledge categories in the Knowledge and information unit. This knowledge becomes accessible to all other functional units of the cognitive cycle. Control Deployment

Layers appear in a specific order where lower layers are controlled by higher layers. Higher control layers are not a necessity for lower control layers to operate. Any intermediate layer can be omitted without impact on the operation of the control architecture. More specifically Figure 1-6 below shows control order alternatives.

Figure 7 Control Order Alternatives

At every layer of control each higher-layer CE may control one or more lower layers CEs. The control cardinality and hierarchy is depicted in figure 1-7 below. Figure shows that any layer CE can control one or more lower layer CEs or managed entities and can cooperate with an arbitrary number of CEs at the same level- This allows for a hierarchical control architecture that allows for various control structures as depicted on the right side of the figure.

Figure 8 Control Cardinality and hierarchy

Finally figure 9 depicts the mapping alternatives of the control layers deployment in and among physical nodes.

Figure 9 Physical control deployment

Claims

1. A method of controlling a telecommunications network, the network comprising at least one communicating entity, the method characterized in that control may be applied at entity level/layer, at network level/layer or management level/layer, the level/layer forming a communication unit, a control unit and an information unit wherein

the control unit exercises layered control, and

the information unit provides access to layered information pertinent to layered control.

2. The method according to claim 1, wherein the communication unit provides primitives to communicate and execute control or configuration of a cognitive method or entity.

3. The method according to claim 1, wherein the communicating entity is a managed entity and wherein an upper level/layer controls a lower level/layer, where the upper and lower levels/layers is one of

a management layer,

a organisation layer, and

a configuration layer,

where the various layers are ordered from upper to lower according to their order of mentioning, or

a communicating entity

by employing a cognitive method.

4. The method according to claim 3, wherein the method is controlled by an upper control layer according to a cognitive method or a management console, wherein the information unit provides knowledge necessary for control layer cognitive cycle including knowledge of corresponding information layer building on lower information layer wherein control is performed in either upward (from lower to upper layer) or downward (from upper to lower layer) control request propagation.

5. A cognitive method comprising

sensing/monitoring; optimising;

configuring/deciding;

interacting;

characterized by

state recognition processing; and

decision and actuation processing,

wherein the state recognition processing comprises at least one of

sensing/monitoring system state;

interacting with another cognitive method; and

learning system state classification.

6. The cognitive method according to claim 5, wherein the decision and actuation processing comprises at least one of

configuration decision;

cooperation/negotiation with other cognitive methods for coordinated configuration; and

learning efficient control.

7. The cognitive method according to claim 6, wherein the method is applied to at least one of

management control layer;

organisation control layer; and

configuration control layer.

8. A cognitive method according to claim 5, comprising controlling a telecommunications network management level/layer corresponding to a upper level/layer implementing its own knowledge and information model and interfaces towards lower level/layer cognitive method and entities, wherein it performs network management by operating on a set of rules which controls and directs a lower-level/layer cognitive method or managed entity towards a given set of objectives (as indicated/instructed by the domain authority/operator), wherein each objective corresponds to a unique set of rules that maps to a utility function implying that changing of objectives requires a change in the set of applicable rules or a change of the utility function.

9. The method according to claim 8, wherein the changing of objectives is done manually by an operator, or

by means of learning, where the set of rules for a given objective are evaluated and refined,

the method implementing a self-management automation paradigm where co-management with other network management cognitive methods is possible through exchange of management-associated knowledge via a communication unit providing primitives to communicate and execute control or configuration of a cognitive method or entity, wherein the management-associated knowledge comprises, which is stored and accessed from the cognitive method of controlling a telecommunications network management.

10. A cognitive method according to claim 5 comprising controlling a telecommunications network organisation level/layer implementing cooperation that embodies various forms of adaptive and/or SON algorithms, the cognitive method comprising network configuration and/or coordinating configuration of nodes in order to serve in accordance with objectives imposed by upper-level/layer management cognitive methods.

11. The method according to claim 10, wherein the method implements cooperative strategies and coordination techniques expressed in terms of at least one of game-theory,

distributed decision making,

distributed problem solving,

distributed learning, and

cooperative learning,

wherein cooperation and coordination is realised by means of negotiations, joint action/configuration decisions or configuration instructions exchanged with other cognitive organisation methods by means of a communication unit providing primitives to communicate and execute control or configuration of a cognitive method or entity.

12. The method according to claim 11, wherein the method comprises organisation-associated knowledge, which is stored and accessed from the organisation cognitive method.

13. A cognitive method according to claim 5 of controlling a telecommunications network configuration level/layer implementing a node that controls the operation of an underlying managed entity, e.g. RRM, eNB, the method comprising interactions with the managed entity it controls via its execution unit in order to monitor the environment in which it is situated and make independent decisions.

14. The cognitive method according to claim 13, comprising information exchange with another cognitive method and making one or more independent decisions based on exchanged information.

15. The method according to claim 13, wherein the method comprises configuration-associated knowledge which is stored and accessed from the configuration cognitive method.

16. A cognitive method of controlling a telecommunications network, where higher cognitive methods implementing higher control layers are not a necessity for cognitive methods at lower control layers to operate, wherein intermediate cognitive methods can be omitted.

17. A method of knowledge access flow comprising information transfer according to level/layer-specific models depending on lower level/layer information.

18. The method according to claim 17, wherein the information is based on statistics.

19. The method according to claim 17, wherein the knowledge comprises at least on of

one or more rules;

one or more facts;

one or more entity capability models; one or more network system models; one or more radio environment models; one or more parameters;

one or more function;

one or more roles;

one or more relations.