METHOD AND SYSTEM FOR MANAGING TELECOMMUNICATION NETWORK APPARATUSES

[0001] The solution disclosed in this document generally relates to telecommunication networks, such as mobile radio communication networks, like cellular networks.

[0002] More specifically, the solution disclosed in this document concerns a method and a system for managing apparatuses of a telecommunication network.

[0003] Nowadays, a significant obstacle to the management of telecommunication networks by their operators resides in that the networks use proprietary network apparatuses, developed and commercialized by a few manufacturers. For the purposes of the present description, the expression “network apparatus” is to be intended to cover not only physical network apparatuses (comprised of hardware and software), such as telecommunication network nodes (e.g., an eNodeB of an LTE/LTE-A, 5G cellular network), but, more generally, any telecommunication network functionality, including software-implemented tools).

[0004] Such network apparatuses, despite having to comply with the existing standards in the field of the telecommunications (like the standards developed by the 3^rd Generation Partnership Project—3GPP—for 2G, 3G, 4G, 5G networks), implement proprietary functionalities and expose proprietary management interfaces, both of which are under the discretion of the manufacturers. Thus, the operators of the telecommunication networks need to purchase and use proprietary management systems/tools, made available by the network apparatuses manufacturers. This increases the burden on the operators of the telecommunication networks, in terms of complexity and costs of the telecommunication network management system.

[0005] Generally, the management policies of the network apparatuses of a telecommunication network depend on a number of factors, such as:

• • [0006] the functionalities of the network apparatuses: for example, in a telecommunication network there are several types of network nodes, and each network node type comprises network nodes that perform a specific function in the network architecture (e.g.: access network nodes, core network nodes, transport network nodes); the specific function of a network node determines its general functionality, the interfaces it exposes to other network nodes, and thus the specific management aspects of that network node;
  • [0007] the available management interfaces of the network apparatuses: every network apparatus exposes some interfaces towards the apparatuses/functionalities of the telecommunication network management system, and such exposed interfaces, despite having in some respects to comply with the existing standards, are proprietary of the network apparatuses manufacturers;
  • [0008] the policies of update of the software of the network apparatuses.

[0009] This situation causes several problems from the point view of the management to be operated by the telecommunication network operator, such as:

• • [0010] high management costs: the telecommunication network management system needs to be constantly updated, to fit the requirements of the apparatuses purchased from the network apparatuses manufacturers (usually, during time, the exposed interfaces change and the management tools evolve);
  • [0011] inefficient management policies: the heterogeneity of the network apparatuses and of the interfaces they expose makes it necessary to develop different management systems and procedures depending on the kind of network apparatus, e.g. network node to be managed; dependence of the network management on the network management tools.

[0012] In Hadjiantonis, A. M., Malatras, A., Pavlou, G. “A context-aware, policy-based framework for the management of MANETs”, Proceedings of the Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'06) 0-7695-2598-9/06, a hybrid approach is proposed, employing a hierarchical and distributed organizational model for MANET (Mobile Ad-hoc NETwork) management. A policy-based network management (PBNM) approach is adopted, together with context awareness, and a system architecture is presented that is capable of effectively managing a MANET.

[0013] In Longo, L., Barrett, S. “A context-aware approach based on self-organizing maps to study web-users' tendencies from their behaviour”, Proceedings of the 1^st International Workshop on ContextAware Middleware and Services affiliated with the 4th International Conference on Communication System Software and Middleware COMSWARE 2009 CAMS 09, ACM Press, pp. 12-17, an approach to web content is presented, based on Kohonen mapping, used to generate a topological model of users' behaviour over web-pages. Each web-document can thus be represented as a semantic map built by adopting unsupervised techniques where similar users' behaviour are mapped close together, with identification of information stability emerging as a by-product of the identification of similarity in user activity over content. In the proposed model, the more similar the outputs of the map for each user who has endorsed a web-page, the more the web site is considered current or in context with changing information.

[0014] In US 2014/0317041 a method and a system are disclosed for providing a context awareness based networking operation in smart ubiquitous networks. A network entity is provided with a networking operation that enables dynamically acquiring context information from various sources (for example, an end user, an end user device, a network, a service, and a content) in smart ubiquitous networks, processing, that is, analysing and deducing related information in the acquired context information, and thereafter, controlling and managing the network depending on the recognized context.

[0015] In general terms, the Applicant has tackled the problem of overcoming, or at least attenuating, the problems outlined in the foregoing, so as to simplify the management of a telecommunication network by the network operator.

[0016] More particularly, the Applicant has found a solution which implements mechanisms which make the telecommunication network itself capable of understanding what is going on with its apparatuses and to consequently act to enforce management policies, without having to devise costly and inefficient heterogeneous network management systems.

[0017] The solution disclosed in this document is aimed at the management of a network apparatus, independently of how it is constructed and in a way that is independent of the specific context in which the network apparatus operates.

[0018] The Applicant has understood that the network apparatus management functions are primarily concerned with (but not limited to):

• • [0019] the configuration of the network apparatus (configuration of parameters that, directly or indirectly, affect the behaviour of the network apparatus);
  • [0020] the evaluation of the performance of the network apparatus;
  • [0021] the detection of faults in the network apparatus and the management thereof (aimed at possibly solving the faults).

[0022] Based on this understanding, the Applicant has devised a solution which is able to accomplish the above-listed functions (as well as other functions) by adapting to the specific operating context of a target network apparatus (i.e., the network apparatus to be managed).

[0023] The Applicant has understood that the specific operating context of a target network apparatus is characterized by, inter alia:

• • [0024] the availability of interfaces, exposed by the target network apparatus, which are useful for the management thereof, particularly for performing the above-listed functions of configuration, performance evaluation and fault detection and management;
  • [0025] the availability of information sources which are useful for characterizing the operating environment in which the target network apparatus operates;
  • [0026] the availability of information sources which are useful for characterizing the behaviour of the target network apparatus (i.e., the actions performed by the target network apparatus during its operating life).

[0027] The solution disclosed herein, depending on the (full or partial) availability of the above-mentioned interfaces and information sources, is able to build a behavioural model of the target network apparatus. Such behavioural model is structured so as to correlate pieces of information of different kinds about the target network apparatus (information directly obtained from the target network apparatus, information obtained through the interfaces it exposes, information indirectly inferred from the available information sources). Particularly, the network apparatus behavioural model correlates the following three types of information about the target network apparatus:

• • [0028] information relating to the behaviour of the target network apparatus (e.g., actions of acceptance/deny of new resource requests coming from another network apparatus);
  • [0029] information relating to variables which are significant for inferring the internal state of the target network apparatus (e.g., the level of use of the resources available to the target network apparatus);
  • [0030] information relating to the environment in which the target network apparatus operates (e.g., the frequency of requests of resources that other network functions send to the target network apparatus).

[0031] In greater detail, the solution disclosed herein is directed to a network management method and system (management apparatus, management software, a mix of both) that operates/is configured to be able to perform the following actions:

• • [0032] collecting information indicative of the internal state of the target network apparatus; for example, such internal state information may relate to: the load level of the target network apparatus, the number of active connections, the number of available resources, etc.;
  • [0033] collecting information indicative of the behaviour of the target network apparatus, i.e. information about the actions, observable from outside the target network apparatus, which the latter performs during its normal operation. Information of this kind can be:
    • [0034] collected passively, by observing the behaviour of the target network apparatus (e.g. by means of suitable probes, which can for example be the user equipment of the users);
    • [0035] collected actively, i.e. by stimulation of actions by the management system;
  • [0036] collecting information indicative of the operating context of the target network apparatus (e.g., information about the network traffic offered to the target network apparatus).

[0037] Based on the collected information, the management system:

• • [0038] builds a behavioural model of the target network apparatus. The behavioural model is built by defining a mathematical, logical/functional model of the target network apparatus;
  • [0039] manages the target network apparatus exploiting the generated behavioural model thereof. In particular, the management system can for example make management decisions for the target network apparatus and deploy them in two ways:
    • [0040] direct mode: by configuring the internal operating variables of the target network apparatus through the exposed interfaces thereof (if available);
    • [0041] indirect mode: by configuring other network apparatuses belonging to the same network subsystem as the target network apparatus and which expose interfaces that make them more easily accessible by the management system.

[0042] The management of the target network apparatus can be actuated by the network management system either automatically (SON—Self-Organizing Network) or manually (by intervention of a human operator).

[0043] According to an aspect of the solution disclosed in this document, there is proposed a method of managing a network apparatus of a telecommunication network, wherein the network apparatus does not expose management interfaces sufficient to allow managing at least one operational parameter thereof of interest for the managing.

[0044] The method comprises:

• • [0045] collecting data about the network apparatus to be managed by making requests to the network apparatus to be managed and to at least one other network apparatus (F^nc, F^c) in operating relationships with the network apparatus to be managed;
  • [0046] based on the collected data, generating a behavioral model of the network apparatus to be managed, the behavioral model being an inferred logical and mathematical model of the behavior of the network apparatus to be managed with respect to the operational parameter thereof of interest for the managing, and
  • [0047] managing the network apparatus to be managed exploiting the generated behavioral model thereof.

[0048] Preferably, said collecting information comprises generating stimuli for the network apparatus to be managed and collecting data indicative of the observed reactions thereof to the generated stimuli.

[0049] Preferably, said collecting data indicative of the observed reactions comprises collecting data from user equipment of the telecommunication network.

[0050] Said at least one other network apparatus may include at least one network apparatus that exposes management interfaces configured to provide, upon interrogation, data relating to its own internal state and that, being in operating relationship with the network functionality to be managed, has got and can provide data useful to define an operating context of the network functionality to be managed.

[0051] For example, the collected data may comprise one or more among:

• • [0052] data, obtained from said at least one other network apparatus and sufficient to generate the behavioral model of the target network apparatus to be managed, that the network apparatus to be managed provides to said at least one other network apparatus;
  • [0053] data, obtained directly from the network apparatus to be managed, that are not sufficient to generate the behavioral model thereof;
  • [0054] data, obtained from said at least one other network apparatus, that are not sufficient to generate the behavioral model thereof.

[0055] Said generating the behavioral model of the network apparatus to be managed may for example comprise classifying the collected data in data classes, said data classes comprising:

• • [0056] a first class of data indicative of the context in which the network apparatus to be managed operates;
  • [0057] a second class of data indicative of the internal state of the network apparatus to be managed;
  • [0058] a third class of data indicative of actions performed by the network apparatus to be managed.

[0059] Said first class of data may for example include one among: a geographical location of the network apparatus to be managed, an indication of the type of the neighboring network apparatuses in the neighborhood of the network apparatus to be managed, an indication of frequency plan(s) of the neighboring network apparatuses.

[0060] Said second class of data may for example include one among: an indication of the load level of the network apparatus to be managed, an indication of the resources used by the network apparatus to be managed, an indication of the available resources of the network apparatus to be managed.

[0061] Said third class of data may for example include one among: an indication of acceptance or denial of new requests of resources; an indication of occupation of new resources depending on the load level; an indication of directions of hand-overs.

[0062] In embodiments of the method, said generating the behavioral model of the network apparatus to be managed may comprise classifying the collected data in categories of variables, said categories of variables comprising:

• • [0063] observable status variables, including data related to the internal status of the network apparatus to be managed that can be directly observed or inferred;
  • [0064] controllable variables, including data related to parameters that can be set in order to push the network apparatus to be managed to execute a function;
  • [0065] behavior variables, including data related to functionalities that the network apparatus to be managed can execute.

[0066] Said behavioral model of the network apparatus to be managed may for example comprise a finite-state machine representative of the network apparatus to be managed.

[0067] According to another aspect of the solution disclosed in this document, there is proposed a system for managing a network apparatus (F^nc_T) of a telecommunication network, wherein the network apparatus to be managed does not expose management interfaces sufficient to allow managing at least one operational parameter thereof of interest for the managing.

[0068] The system comprises:

• • [0069] a data collector configured for collecting data about the network apparatus to be managed by making requests to the network apparatus to be managed and to at least one other network apparatus in operating relationships with the network apparatus to be managed;
  • [0070] a behavioral model builder configured for generating, based on the collected data, a behavioral model of the network apparatus to be managed, the behavioral model being an inferred logical and mathematical model of the behavior of the network apparatus to be managed with respect to the operational parameter thereof of interest for the managing, and
  • [0071] a manager configured for managing the network apparatus to be managed exploiting the generated behavioral model thereof.

[0072] Preferably, said data collector is further configured for generating stimuli for the network apparatus to be managed and collecting data indicative of the observed reactions thereof to the generated stimuli.

[0073] Preferably, said behavioral model builder is configured for classifying the collected data in categories of variables, said categories of variables comprising:

• • [0074] observable status variables, including data related to the internal status of the network apparatus to be managed that can be directly observed or inferred;
  • [0075] controllable variables, including data related to parameters that can be set in order to push the network apparatus to be managed to execute a function;
  • [0076] behavior variables, including data related to functionalities that the network apparatus to be managed can execute.

[0077] Preferably, said behavioral model builder is configured for generating a finite-state machine representative of the network apparatus to be managed.

[0087] Making reference to FIG. 1, an exemplary, simplified scenario of a telecommunication network useful to understand the applicability of the solution disclosed herein is shown.

[0088] The circles in FIG. 1 schematically represent telecommunication network apparatuses, to be intended to cover not only physical network apparatuses, but more generally “network functionalities”. A network functionality is an operating network entity that can be implemented as an ad-hoc system or as a suitably programmed general-purpose system, localized or virtualized/distributed. A “network functionality” can for example be a telecommunication network node, but it should be intended as encompassing also other network apparatuses, or parts of apparatuses, or combination of apparatuses.

[0089] Reference F^nc_T (“Non-collaborative target functionality”) denotes the network apparatus to be managed (“target”), and which is assumed not to provide to the exterior enough information regarding its internal state or its way of operating in response to its time-varying configuration parameters (for this reason, it is qualified as “non-collaborative”). For example, in case the Non-collaborative target functionality F^nc_T is a mobile telecommunication network node (e.g., an eNodeB), it may happen that the Non-collaborative target functionality F^nc_T does not provide information about its load level, and/or about the value of a load threshold thereof exploited by the Non-collaborative target functionality F^nc_T for the Admission Control procedure (a validation process where a check is performed before a connection is established to see if current apparatus resources are sufficient for the proposed connection). The Non-collaborative target functionality F^nc_T is the exemplary target of the operations of the solution herein disclosed.

[0090] Reference F_O (“Observing functionality”) denotes the network “management system” according to an embodiment of the solution disclosed herein, having the task of monitoring the Non-collaborative target functionality F^nc_T in order to build a behavioural model of it and then to manage the Non-collaborative target functionality F^nc_T by exploiting the generated behavioural model. To this purpose, the Observing functionality F_O:

• • [0091] collects information and data useful for building the behavioural model of the Non-collaborative target functionality F^nc_T (possibly also by actively stimulating the generation of the data, useful to generate the behavioural model, by the Non-collaborative target functionality F^nc_T or by other network functionalities, as described shortly below);
  • [0092] builds the behavioural model of the Non-collaborative target functionality F^nc_T, with the level of approximation allowed by the acquired data for the behaviour of interest;
  • [0093] takes the necessary actions for managing the Non-collaborative target functionality F^nc_T, using the generated behavioural model.

[0094] Reference F^c (“Collaborative functionality”) denotes a network apparatus that can provide (e.g., to the Observing functionality F_O) information about its own internal state and that, by interacting with the Non-collaborative target functionality F^nc_T, has got and can provide (this is why it is qualified as “collaborative”) direct or indirect information useful (to the Observing functionality F_O) to define the operating context of the Non-collaborative target functionality F^nc_T.

[0095] Reference F^nc (“Non-collaborative functionality”) denotes a network apparatus that does not provide information about its internal state and that interacts with the Non-collaborative target functionality F^nc_T; the Non-collaborative functionality F^nc may or may not have, but in any case it does not provide (for this reason it is qualified as “non-collaborative”), direct or indirect information useful to define the context of the Non-collaborative target functionality F^nc_T.

[0096] Through the interfaces between the network apparatuses, in addition to the parametrization allowed and accepted by each network apparatus (i.e., in addition to the set of control parameters that a certain network apparatus, e.g. the Non-collaborative target functionality F^nc_T, exposes and that can be modified exploiting one or more functionalities made available by that network apparatus), it is possible to make requests to gain knowledge about the network apparatus internal state (i.e., even if a network apparatus does not expose certain pieces of information, it is possible to infer some of them by exploiting the exposed control parameters); depending on the level of collaboration thereof, a network apparatus may or may not respond to the received requests (or the answer that the network apparatus provides may not contain useful information for the management system). The requests to a certain network apparatus, e.g. the Non-collaborative target functionality F^nc_T, can be made either directly or indirectly, passing through one or more intermediate network apparatuses.

[0097] FIG. 2 schematically shows, in terms of some functional blocks, the Observing functionality F_O or management system 200 according to an exemplary embodiment of the solution disclosed herein.

[0098] The management system 200 essentially comprises a data acquisition function (data collector) 205, a behavioral model builder function 210 and a management function (manager) 215. The data acquisition function 205, the behavioral model builder function 210 and the management function 215 can be implemented in hardware, in software (by programming a general-purpose or dedicated data processor, possibly distributed, to execute a computer program) or partly in hardware and partly in software.

[0099] The data acquisition function 205 is devoted to collect information and data useful to allow the management system 200 to build a behavioral model of a target network apparatus to be managed, in the example the Non-collaborative target functionality F^nc_T. The data acquisition function 205 comprises an observation function 220 and a stimulation function 225: the observation function 220 is configured to collect data by simple, passive observation of the telecommunication network 217 (exploiting network probes, e.g. user equipment); the stimulation function 225 is configured to generate and inject into the network 217 stimuli for the target network apparatus to be managed, and the observation function 220 then acquires the consequent responses.

[0100] The data acquired by the data acquisition function 205 are stored, for example in a database 230 of the management system 200.

[0101] The behavioral model builder function 210 exploits the data acquired by the data acquisition function 205 and stored in the database 230 to build a behavioral model of the Non-collaborative target functionality F^nc_T. The behavioral model builder function 210 includes a data classifier function 235 and a behavioral model inference function 240.

[0102] In an embodiment of the solution disclosed herein, the behavioral model builder function 210 builds the behavioral model of the Non-collaborative target functionality F^nc_T as follows.

[0103] The data classifier function 235 is configured to classify the data (taken from the database 230) in data classes.

[0104] The behavioral model inference function 240 is configured to take the data classified by the data classifier function 235 and infer and build a behavioral model 245 of the Non-collaborative target functionality F^nc_T.

[0105] The management function 215 is configured to exploit the behavioral model 245 for managing the Non-collaborative target functionality F^nc_T.

[0106] In an embodiment of the solution herein disclosed, the management system 200 operates as described herebelow, making reference to the flowchart 300 of FIG. 3.

[0107] The data acquisition function 205 of the management system 200 collects and stores information, data about the target network apparatus to be managed (block 305). Particularly, the data acquisition function 205 is configured to acquire several kinds of data, either by simple, passive observation of the telecommunication network 217 (by the observation function 220), or possibly by injection into the network 217 of stimulations for the target network function to be managed (stimulation function 225) and then observing (by the observation function 220) the reactions to the injected stimuli.

[0108] The data acquired by the data acquisition function 205 can be:

[0109] a) Direct and complete data I_DC: a target network apparatus to be managed may provide, either upon simple observation or upon stimulation, the information necessary to the management system 200 for managing the target network apparatus to be managed; in this case, the target network apparatus to be managed cannot be qualified as a non-collaborative target functionality (like instead is, in the example considered herein, the Non-collaborative target functionality F^nc_T) and there is no need to build a behavioural model of it.

[0110] b) Indirect and complete data I_IC: the target network apparatus to be managed, in the example the Non-collaborative target functionality F^nc_T, may provide, by simple observation (observation function 220) or upon stimulation (by the stimulation function 225) and observation (observation function 220), information (useful to the management system 200 to build a behavioral model thereof) to a neighboring network apparatus being a Collaborative functionality F^c. The latter provides the information to the management system 200.

[0111] c) Direct and incomplete data I_DI: these are data that may be provided directly by the Non-collaborative target functionality F^nc_T to the management system 200, through simple observation (observation function 220) or upon stimulation (by the stimulation function 225) and observation (observation function 220), but the data provided are not complete in their typology or do not provide an exhaustive response for the purpose of determining the behavioral model of the Non-collaborative target functionality F^nc_T. For example, in response to a request of telling which is the current load level, the Non-collaborative target functionality F^nc_T may provide a value expressed as a percentage, which in itself does not indicate which are the residual load capabilities in absolute value, whereas when requested to provide information about how many more users the Non-collaborative target functionality F^nc_T can still accept, the Non-collaborative target functionality F^nc_T may not provide an answer.

[0112] d) Indirect and incomplete data I_II: these are data that the Non-collaborative target functionality F^nc_T does not provide directly when requested, but that can be found, or inferred, deduced, by means of a request to a Collaborative functionality F^c interacting with the Non-collaborative target functionality F^nc_T. For example, these data may be related to the number of hand-overs performed between the Non-collaborative target functionality F^nc_T and the Collaborative functionality F^c for user terminals having active connections: a response to a request of this piece of information coming from the management system 200 and received at all the network apparatuses in the neighborhood of the Non-collaborative target functionality F^nc_T enables the management system 200 to build a model of the level of load of the Non-collaborative target functionality F^nc_T.

[0113] e) Initially unknown and incomplete data I_NNI: these are data that are not available to any one of the network apparatuses, and must therefore be collected by the management system 200, for example by:

[0114] e1) Passive observation (tracing), carried out by the observation function 220, of the behavior of the Non-collaborative target functionality F^nc_T: the observation function 220 of the management system 200 observes the actions performed by the Non-collaborative target functionality F^nc_T, for example exploiting probes located at the network interfaces that concern the Non-collaborative target functionality F^nc_T, to observe actions of admission control or hand-over.

[0115] e2) Active observation of the behavior of the Non-collaborative target functionality F^nc_T: by having the stimulation function 225 generate external stimuli (e.g., generating ad-hoc offered traffic for the Non-collaborative target functionality F^nc_T) the management system 200 causes changes of context and observes (through the probes located at the network interfaces) the consequent behavior of the Non-collaborative target functionality F^nc_T.

[0116] The collected data are stored in the database 230 (block 305).

[0117] The data classifier function 235 of the behavioral model builder function 210 is configured to classify the data (taken from the database 230) in data classes (block 310). For example, the collected data can be classified in the following three classes 313:

[0118] i) Context data: information about the context in which the Non-collaborative target functionality F^nc_T operates. For example, in the case of a mobile telecommunications network, the context data may include: the geographical location of the Non-collaborative target functionality F^nc_T (this information is for example useful to determine the degree of urbanization of the geographic area served by the Non-collaborative target functionality F^nc_T); the type of the neighboring network apparatuses in the neighborhood of the Non-collaborative target functionality F^nc_T; the frequency plan(s) of the neighboring network apparatuses;

[0119] ii) Internal state data: information about the internal state of the Non-collaborative target functionality F^nc_T, for example: the load level, the used resources, the available resources;

[0120] iii) Undertaken actions data: information about the actions that the Non-collaborative target functionality F^nc_T undertakes, for example: acceptance or denial of new requests of resources (the resources requests can be stimulated by the normal operation of the Non-collaborative target functionality F^nc_T or by the (stimulation function 225 of the) management system 200); occupation of new resources depending on the load level; directions of the hand-overs.

[0121] In particular, the data classifier function 235 classifies the collected data stored in the database 313 in three categories of variables:

• • [0122] Observable status variables Vs: these are pieces of information related to internal status of the target functionality (target node) and are for example: a load level of the target functionality; an active cell number of the target functionality. The observable status variables Vs can be directly observed or inferred by the Observing functionality F_O;
  • [0123] Controllable variables Vc: these are pieces of information related to parameters that it is possible to set in order to push the target functionality (target node) to execute a functionality, like for example: a load threshold; provided traffic load;
  • [0124] Behavior variables Vb: these are pieces of information related to functionalities that the target functionality (target node) can execute, as an example: an Inter-Frequency Hand-Over (e.g., to offload a network cell); a frequency switch off (to reduce power consumption).

[0125] Such a classification of the collected and stored data in the above three categories of variables Vs, Vc and Vb is useful to define inferred internal states (related to target functionality) and relations among them. As schematically shown in the state-transition diagram depicted in FIG. 4, the generic status Stat1, Stat2, StatN of the target functionality is defined by a corresponding set of observable variables Vs related to the target functionality. The generic behavior Behav A, Behav B, Behav C, Behav D, Behav E of the target functionality is defined by a corresponding set of behavior variables Vb. Each behavior of the target functionality is a function of the initial status Stat1, Stat2, StatN, of the final status Stat1, Stat2, StatN and of a corresponding set of controllable variables Vc.

[0126] The behavioral model builder function 210 then assesses whether the collected data relating to the target network apparatus to be managed include Direct and complete data I_DC: (decision block 315).

[0127] In the affirmative case (exit branch Y of decision block 315), the target network apparatus to be managed is considered to be collaborative and there is no need for the management system 200 to build a behavioral model thereof. The target network apparatus can be managed by the management system 200 exploiting the interfaces already exposed by the target network apparatus (block 325).

[0128] In the negative case (exit branch N of decision block 315), the target network apparatus is non-collaborative (as in the example here considered of the Non-collaborative target functionality F^nc_T) and cannot be managed exploiting the interfaces already exposed by the target network apparatus: a behavioral model of the target network function to be managed needs to be built by the management system 200.

[0129] The management system 200 assesses whether the collected data are sufficient to build a behavioral model of the Non-collaborative target functionality F^nc_T (block 330).

[0130] In the negative case (exit branch N of decision block 330), the management system 200 needs to collect more information about the Non-collaborative target functionality F^nc_T: the operation flow returns to block 305.

[0131] In the affirmative case (exit branch Y of decision block 330), the behavioral model inference function 240 exploits the classified data 313 to infer and build (synthetize) a behavioral model 245 of the Non-collaborative target functionality F^nc_T (block 335).

[0132] Depending on the level of completeness of collected data regarding the Non-collaborative target functionality F^nc_T, the behavioral model 245 can be limited to model the behavior of the Non-collaborative target functionality F^nc_T as far as one or some configuration parameters of interest are concerned (i.e., the behavioral model 245 needs not to be a complete, full behavioral model of the Non-collaborative target functionality F^nc_T).

[0133] In particular, the behavioral model inference function 240 correlates the collected and stored data, arranged in the three categories of observable status variables Vs, controllable variables Vc and behavior variables Vb in order to build a state-transition diagram (inferred state-transition diagram, like that depicted in FIG. 4) which represents the behavioral model of the target functionality. Such inferred state-transition diagram can be used to:

• • [0134] define a current internal status of the target functionality (for example Stat1 in FIG. 4);
  • [0135] determine which possible behaviors the target functionality will be able to execute (for example the behaviors Behav. A and Behav. B);
  • [0136] determine which is the most suitable status for the target functionality to reach (in the example of FIG. 4 there are three possibilities: status Stat1, status Stat2 or status StatN). This allows the selection of the behavior that the target functionality should execute;
  • [0137] define the controllable variables Vc in order to push the target functionality to execute the selected behavior.

[0138] Once the behavioral model 245 has been generated, the management function 215 exploits the behavioral model 245 for managing the Non-collaborative target functionality F^nc_T (block 325).

[0139] In particular, in an embodiment of the solution disclosed herein the management function 215 is configured to operate as follows.

[0140] Firstly, the management function 215 identifies how to manage the Non-collaborative target functionality F^nc_T. Three ways of managing the Non-collaborative target functionality F^nc_T are possible:

• • [0141] by direct action: the configuration parameter values regarding the Non-collaborative target functionality F^nc_T defined exploiting the behavioral model 245 are directly sent to the Non-collaborative target functionality F^nc_T (through one of the exposed interfaces thereof);
  • [0142] by indirect action: the configuration parameter values regarding the Non-collaborative target functionality F^nc_T defined exploiting the behavioral model 245 are indirectly sent to the Non-collaborative target functionality F^nc_T through neighbouring network apparatuses being collaborative functionalities, like the Collaborative functionality F^c;
  • [0143] by induced action: the behaviour of the Non-collaborative target functionality F^nc_T is inferred through changes of the behaviour of neighbouring network apparatuses being collaborative functionalities (like the Collaborative functionality F^c).

[0144] Then, the management function 215 derives suitable values for the configuration parameters regarding the Non-collaborative target functionality F^nc_T.

[0145] In particular, making reference to the schematic state-transition diagram of FIG. 5, the behavioral model is used by the management function 215 to control the behavior of the Non-collaborative target functionality F^nc_T by using the controlling variables Vc in order to set its internal status (such an internal status being one of the inferred internal statuses making up the behavioral model).

[0146] The management function 215 then ascertains and controls the actions undertaken by the Non-collaborative target functionality F^nc_T (block 340) and, if necessary, the behavioral model 245 can be corrected, or a new behavioral model can be built (dash-and-dot arrow in FIG. 3).

[0147] The data acquisition function 205 can collect the information useful to build the behavioral model once, periodically or continuously as time goes by (“streaming mode”).

[0148] The phase of generation of the behavioral model of the Non-collaborative target functionality F^nc_T is a continuous process, which involves collecting new information from the observed functions and introduce some modifications to an already generated behavioral model if it is needed.

[0149] In the following, an exemplary use case of the solution disclosed herein is described.

[0150] The scenario of the exemplary use case considers as a Non-collaborative target functionality F^nc_T a network node N^nc_T of an access network (e.g., a Radio Access Network—RAN—of a mobile telecommunication network, such as an eNodeB of an LTE/LTE-A cellular network). It is assumed that the target network node N^nc_T is receiving several service requests. Such service requests are approaching a level at which, in the past, an observing network node N_O (being the Observing functionality F_O of FIG. 1, i.e. the management system 200 having the function of managing the mobile telecommunication network) has observed that the network node N^nc_T has activated an additional radio carrier (and it is assumed that the network operator of the mobile telecommunication network wishes to avoid, as far as possible, this kind of reactions in an energy-saving perspective). The observing network node N_O, not being able to modify the internal load threshold of the target network node N^nc_T (because the latter is non-collaborative), decides to reconfigure the network subsystem to which the target network node N^nc_T belongs and in which it operates, causing part of the network traffic to be transferred to a neighboring network node in the neighborhood of the target network node N^nc_T.

[0151] In greater detail, let it be assumed that the target network node N^nc_T has two carriers available, only one of which (first carrier) is active until the metric that measures the resources occupation of the first carrier does not trespass a certain threshold, e.g. 80% of the first carrier resources. When the resources occupation threshold is trespassed, the second carrier of the target network node N^nc_T is activated, and part of the network node incoming traffic starts being moved to the second carrier. Let it also be assumed that another non-collaborative network node N^nc which does not collaborate with the observing network node N_O operates in the same geographical area as the target network node N^nc_T and a collaborative network node N^c operates in a boundary geographical area and is capable of serving network traffic.

[0152] Step 1: the observing network node N_O collects configuration data about the target network node N^nc_T.

[0153] In particular, the observing network node N_O requests to the target network node N^nc_T how many carriers it has available: no response is received from the target network node N^nc_T (being non-collaborative). Then, the observing network node N_O requests to the target network node N^nc_T the level of occupation of resources which, when reached, causes the activation of the second carrier (the above-mentioned load threshold): again, no response is received from the target network node N^nc_T. It is pointed out that “no response is received” is to be intended as encompassing several possible situations: for example, the parameter that the observing network node N_O would need to know is not included in the parameters that the proprietary management interface exposed by the target network node N^nc_T can provide; or, the response that is provided to the observing network node N_O by the target network node N^nc_T cannot be directly used by the observing network node N_O because it is expressed in a semantic that is not known to the observing network node N_O; or, the response provided by the target network node N^nc_T does not contain a significant value (e.g., “nil”).

[0154] Step 2: the observing network node N_O collects information about the state, the behavior and the operating environment of the target network node N^nc_T:

• • [0155] the observing network node N_O asks to the target network node N^nc_T which is the occupation of resources thereof: the target network node N^ncT responds with a value expressed as a percentage, which is a relative value and does not indicate the actual amount of resources still available at the target network node N^nc_T;
  • [0156] then, the observing network node N_O asks to the other non-collaborative network node N^nc how many requests of Inter-Frequency Hand-Over (IF HO) in a given time interval the non-collaborative network node N^nc has received from the target network node N^nc_T: no response is provided by the non-collaborative network node N^nc;
  • [0157] then, the observing network node N_O asks to the collaborative network node N^c how many requests of IF HO the collaborative network node N^c has received from the target network node N^nc_T: the collaborative network node N^c responds by providing a number, which has a meaning and is useful for the observing network node N_O;
  • [0158] then, the observing network node N_O asks to the collaborative network node N_c to report the measures performed by the user equipment served by the collaborative network node N^c;
  • [0159] then, the observing network node N_O requests to probes (e.g., user terminals) present in the mobile telecommunication network to provide information about the carriers related to the target network node F^nc_T.

[0160] Preferably, the observing network node N_O performs this step (step 2) repeatedly, even more preferably periodically, in order to be able to track the evolution of the mobile telecommunication network (or at least of the managed network subsystem made up by the target network node N^nc_T, the non-collaborative network node N^nc and the collaborative network node N^c) and to regularly update the behavioral model of the target network node N^nc_T.

[0161] The observing network node N_O builds a data structure with the data collected in the previous phase.

[0162] For example, the data structure can take the form of a table in which the collected data are arranged as in the exemplary table below:

	Observable status variables	Behavior variables	Controlled variables
status	Vs	Vb	Vc
Status 1	Vs1: Percentage of resource occupation	Vb1: Number of	Vc1: IF HO threshold in
	of NncT = medium	activated carriers = 1	order to modify the
	Vs2: Number of carriers activated by		number of users
	NncT = 1		accessing NncT = high
	Vs3: Number of IF HO requests from Nc =
	low
Status 2	Vs1: Percentage of resource occupation	Vb1: Number of	Vc1: IF HO threshold in
	of NncT = high	activated carriers = 2	order to modify the
	Vs2: Number of carriers activated by		number of users
	NncT = 2		accessing NncT = low
	Vs3: Number of IF HO requests from Nc =
	high

[0163] The internal statuses of the target network node N^nc_T which are relevant for the considered use case (and which the observing network node N_O has to infer) are two, and are denoted as Status 1 and Status 2 in the table. The table contains two rows, one row for each internal status of the target network node N^nc_T inferred by observing network node N_O.

[0164] For each row, i.e. for each inferred internal status Status 1 and Status 2, corresponding values of the relevant observable status variables Vs, behavior variables Vb and controllable variables Vc are reported in columns of the table.

[0165] In particular, the observable status variables Vs include: the percentage (medium or high) of resource occupation of the target network node N^nc_T (variable Vs1); the number of carriers (1 or 2) activated by the target network node N^ncT (variable Vs2); and the number (low or high) of requests Inter-Frequency Hand-Overs (IF HO) received from the collaborative network node N^c (variable Vs3). The behavior variables Vb include the number (1 or 2) of activated carriers (variable Vb1). The controllable variables Vc include the threshold (low or high) of IF HOs to be set in order to modify the number of users accessing the target network node N^nc_T (variable Vc1).

[0166] The behavioral model created by the observing network node N_O is schematized by the state-transition diagram shown in FIG. 6.

[0167] The behavioral model is then used by the observing network node N_O to optimize the managed network subsystem (made up by the target network node N^nc_T, the non-collaborative network node N^nc and the collaborative network node N^c).

[0168] In case the target network node N^nc_T is in the status 1 the observing network node N_O does not modify the network configuration, otherwise the observing network node N_O will modify the value of the controllable variable Vc (IF HO threshold) setting it at a low level value: in this way the number of users executing IF HO procedure will increase and the load level of the target network node N^nc_T will decrease, causing the turn off of the second carrier.

[0169] In other words, when the observing network node N_O perceives that the level of load of the target network node N^nc_T approaches the threshold percentage P_s (say, the threshold percentage P_s less a security margin), then the observing network node N_O may react and do the following.

[0170] The observing network node N_O asks to the collaborative network node N^c which is its percentage of occupation of resources; if the percentage of occupation of resources of the collaborative network node N^c is below a predetermined threshold, then the observing network node N_O lowers the threshold of the HO of the collaborative network node N^c towards the target network node N^nc_T, in order to transfer the users served by the target network node N^nc_T and located at the borders of the served area (cell) thereof towards the collaborative network node N^c. If the collaborative network node N^c becomes in turn overloaded, then the observing network node N_O may act on the threshold of the HO of the collaborative network node N^c towards the non-collaborative network node N^nc.

[0171] The operations that the observing network node N_O performs in respect of the target network node N^nc_T are performed on all the neighboring nodes in the neighborhood thereof (the collaborative network node N^c and non-collaborative network node N^nc), thereby the observing network node N_O can build a complex data structure regarding both the state and the behaviors of every network node of the managed network subsystem, and the state relationships and the behaviors between the network nodes. This knowledge becomes the basis for performing configurations and optimizations that do not affect independently the network nodes of the managed subsystem, but on the contrary are correlated actions.

[0172] Reference is made to a scenario similar to that described in connection with Use case 1. In the case now considered the target (non-collaborative) network node N^nc_T is assumed to be able to communicate some of its internal performance parameters, but the resource optimization algorithm implemented by the target network node N^nc_T is unknown to the observing network node N_O. In the considered scenario there are some (at least one) collaborative network nodes N^c in the neighborhood of the target network node N^nc_T: these collaborative network nodes N^c are able to communicate their internal status (in particular, their internal load level) and some kind of interactions between them and the target network node N^nc_T (e.g., HO events).

[0173] The goal of the observing network node N_O is to control the target network node N^nc_T and its neighbor network nodes in order to optimize the provided level of Quality of Service (QoS level).

[0174] The behavioral model builder function 210 collects the configuration parameters of the collaborative network nodes N^c and their internal status (load levels and provided QoS level). After that, the behavioral model builder function 210 sets the levels of IF HO in the collaborative network nodes N^c toward target network node N^nc_T in order to increase the level of load of the target network node N^nc_T, and collects significant data regarding how the Radio Resource Management (RRM) algorithm of the target network node N^nc_T works (for example: the types of HOs executed, varying HO thresholds and QoS level).

[0175] A mapping table is created, linking the internal load level (e.g., in terms of number of users) of the target network node N^nc_T and of its neighbor nodes to the related action (inter-node HO events and provided QoS level).

[0176] Each internal status will be characterized by certain values for the observable status variable “level of load” (in this case the behavior of the target network node N^nc_T will depend on its internal status and on the status of the neighbor nodes), as shown in FIG. 7, where the level of load for the target network node derived by information from its neighbored collaborative nodes is depicted.

[0177] The observing network node N_O builds a data structure with the data collected in the previous phase. For example, the data structure can take the form of a table in which the collected data are arranged as in the exemplary table below:

			Controllable status
	Status variables	Behavior variables	variables
Status	Vs	Vb	Vc
Status 1	Vs1: NncT load	Vb1: number of HO	Vc1: NncT outcoming HO
	level = low	events toward	threshold = high
		neighbor nodes =
		low
	Vs2: neighbor	Vb2: number of HO	Vc2: neighbor HO
	node load	events from	threshold = high
	level = low	neighbor nodes =
		low
		Vb3: level of QoS	Vc3: service priority =
		per user = high	untouched
Status 2	Vs1: NncT load	Vb1: number of HO	Vc1: NncT outcoming HO
	level = low	events toward	threshold = low
		neighbor nodes =
		low
	Vs2: neighbor	Vb2: number of HO	Vc2: neighbor HO
	node load	events from	threshold = medium
	level = high	neighbor nodes =
		high
		Vb3: level of QoS	Vc3: service priority =
		per user =	modified
		medium/low
Status 3	Vs1: NncT load	Vb1: number of HO	Vc1: NncT outcoming HO
	level = high	events toward	threshold = high
		neighbor nodes =
		high
	Vs2: neighbor	Vb2: number of HO	Vc2: neighbor HO
	node load	events from	threshold = high
	level = high	neighbor nodes =
		high
		Vb3: level of QoS	Vc3: service priority =
		per user = low	modified

[0178] The internal statuses of the target network node N^nc_T which are relevant for the considered use case (and which the observing network node N_O has to infer) are three, and are denoted as Status 1, Status 2 and Status 3 in the table. The table contains three rows, one row for each internal status of the target network node N^nc_T inferred by observing network node N_O.

[0179] For each row, i.e. for each inferred internal status Status 1, Status 2 and Status 3, corresponding values of the relevant observable status variables Vs, behavior variables Vb and controllable variables Vc are reported in columns of the table.

[0180] In particular, the observable status variables Vs include: the load level of the target network node N^nc_T (variable Vs1); and the load level of the neighbor network nodes (variable Vs2). The behavior variables Vb include: the number of HO events toward neighbor network nodes (variable Vb1); the number of HO events from neighbor network nodes (variable Vb2); and the level of QoS per user (variable Vb3). The controllable variables Vc include the threshold of HOs outcoming from the target network node N^nc_T (variable Vc1); the threshold of HOs of the neighbor network nodes (variable Vc2); and the service priority (variable Vc3).

[0181] The behavioral model created by the observing network node N_O is schematized by the state-transition diagram shown in FIG. 8.

[0182] Based on the above described behavioral model, when the target node is in Status 3 (high level of load) and the observing network node N_O wants to avoid the generation of an increased number of HOs towards the neighbor nodes (variable Vb1), the observing network node N_O can reduce the service priority associated to some user equipment (variable Vc3) so that the throughput can be reduced.