Generic Templates for TMN Case Representation Alexandre Moraes Ramos1, João Bosco da Mota Alves2 and Simone Pereira dos Santos3 1
Universidade do Vale do Itajaí - CES VII, Curso Ciências da Computação, Rod. SC.407, Km.04, Cep 88122-000 - São José/SC , Fone/Fax: +55 48 281-1500
[email protected] 2 Universidade Federal de Santa Catarina, Curso de Pós-Graduação em Engenharia de Produção, Curso de Pós-Graduação em Ciência da Computação, Cx Postal 476 - Cep 88040900 - Florianópolis/SC, Tel +55 48 2319738, Fax +55 48 2319770, UFSC BR
[email protected] 3 Universidade Federal de Santa Catarina, Curso de Pós-Graduação em Ciência da Computação, Cx Postal 476 - Cep 88040-900 - Florianópolis/SC, Tel +55 48 2319738, Fax +55 48 2319770, UFSC BR
[email protected]
Abstract. The Telecommunication Management Network (TMN) provides an environment for interfacing a telecommunication network with computer systems in order to provide different management functions focused on the basic operations, administration and maintenance aspects. However, a great effort has been made to improve the TMN quality and efficiency. New technologies are required. In order to ease support tools development for the TMN Model, CBR approach has been integrated to the TMN Model. To guarantee a transparent integration, this paper proposes generic templates for TMN case representation.
1
Introduction
In order to ease the integrated applications development of telecommunications network management, the International Telecommunications Union (ITU) has agreed upon a common model to depict management in a communications environment. The main framework of this model is based on work originally undertaken by the British Telecommunications team, known as the Telecommunication Management Network (TMN) Model and now widely accepted. The TMN Model is an organized structure that provides standards to interconnect several types of telecommunications support system, creating the concept of "Telecommunications Network Management" through the recommendation M.3010 [1]. One of the fundamentals problems confronting users with different network management standards, TMN Model inclusive, is how to manage? These standards identify and describe what must be managed, which are the functional requirements of the management, the properties of the logical and physical resources that are able to be managed, etc. However, these standards do not clearly specify or describe what to do, how to do, how to manage, how to solve and how to control network problems.
Currently, a significant part of the management actions are based on individual experiences accumulated by professionals through years of practice in this area. This "experimential knowledge" [2], based on individual's experiences on making decisions and solving problems, is fundamental for management activities in telecommunications network environment. However, this sort of knowledge is very personal. It only exists in the network manager’s minds and is neither formalized, nor available in management models or tools. This turns the experimential knowledge un-(re)usable, and also impedes its standard introduction in development environments of TMN applications. In order to make the reuse of telecommunication network management experiences operational; we propose an approach integrating CBR to standard TMN, [3]. This approach was defined to ease support tools development to the decision process in the TMN environment. The CBR paradigm is a cognition model that makes use of experimential knowledge to problem solving and learning. It reuses experiences collected in old problems to solve new situations. As part of this approach, a case framework was defined to add management cases to the TMN Model. The management cases contain management practical information that are useful to the management activities. The management information in TMN Model are specified through the standard generic templates that uses Abstract Syntax Notation One (ASN.1), standardized by ISO [4]. As a result, the CBR-TMN integration model proposed, also provides generic templates and adopts the ASN.1 notation to represent and specify TMN cases, facilitating their integration and compatibility with the TMN applications. In this article, we focus on the description of the generic templates developed for the TMN case representation. An introduction to the TMN Model is in section 2. In section 3, there is an overview on the integration model of CBR with TMN. In section 4, the generic templates definition are presented and are illustrated through an example of the usage of these templates in section 5. Conclusions and future works are discussed in section 6.
2
TMN Model
The telecommunications network is a distributed environment, involving information exchange between management processes. In the management association, the involved application processes can assume two possible roles: manager or agent. Playing the manager role, the application processes issues operations requests on managed resources and receives notifications corresponding to the various events. In the agent role, the application process performs the management operations over the managed resources and answers to the requests of the managing processes. The managed resources are modeled as managed objects in a Management Information Base (MIB) (Fig. 1).
Agent Application
Manager Application
MIB Management Operations
Manager role
Notifications
Agent role
Managed Objects
Fig. 1. TMN Model
Inside the TMN Model there are three basic aspects that might be considered apart in the planning and design of the network management applications[1]: Functional Model: it is represented by a set of functional blocks, where each one executes specific functions related to the transport and processing of the information management; Physical Model: it must provide flexibility to customize it to different topologies of the managed networks and to have it as the prerequisite of the many administration organizational structures; Information Model: it models the information required for the network management systems. The Information Model purpose is to give structure to the management information conveyed externally by systems management protocols and to model management aspects of the related resources (e.g. switch). The Information Model makes use of object-oriented design principles. They are applied to the specification of management information. It is structured in terms of managed objects, which are abstractions of resource properties that are relevant to the management. For example, consider that it is a requirement to manage a hypothetical line card in a switch. The line card is a physical resource that exists to support call-processing activities. In developing the information model for network management system, only the information about line card, which is relevant to the management, is modeled representing a managed object. Managed objects are distinguished through their associated properties: attributes, actions, operations, notifications and behavior. Managed objects that share the same definition are instances of the same managed object class. However, without a standard representation technique, different designers may specify models through a great variety of ways ranging from using a formal description language, pseudocode, or text. This obviously leads to difficulties in interpretation and implementation of the models. As part of the TMN standards, the ITU defined a technique called Guidelines for the Definition of Managed Object (GDMO) [5]. The GDMO provides templates that use Abstract Syntax Notation One (ASN.1) for the specification of components of a management information model. The template consists of key words describing the
semantics and the ASN.1 notation describing the syntax of the management information. In addition to guarantee the compatibility, the TMN information model describes the existing relationships between managed object classes through the hierarchies structure of inheritance, containment and naming [6]. A collection of instances belonging to different object classes form a repository. In the case of network management, this repository is referred to as the Management Information Base (MIB). The MIB is an abstract view of managed network resources and it contains information for operation, administration and maintenance (OAM) activities of telecommunications networks. However, these information are very restricted for an efficient management. The actual decision making process in TMN requires more than the OAM information.
3
Integrating CBR to TMN
The TMN Model identifies and describes what must be managed, which are the functional requirements of the management, the properties of the logical and physical resources that are able to be managed, etc. However, respecting the independence of each user, it does not clearly specify how to solve a management problem. Experimential knowledge can substantially support network management activities. It can describe how the tasks can be performed, how the goals can be reached, how the telecommunications resources can be managed. Therefore, (re)using experimential knowledge can prevent the repetition of past failures and guide the solution of occurred ones, improving TMN applications quality and efficiency. CBR appears to be an optimal approach to operationalize the representation and reuse of experimential knowledge in TMN standards. The integration of CBR into the TMN Model aims at adding value, easing support tools development to the decision process in the TMN environment. The primary components of the integration model are Functional Framework and Case Framework. The Functional Framework describes the functionality required for to reuse the experimential knowledge. It is represented by a set of functional blocks, where each one executes specific functions related to the reasoning process in CBR. It includes mechanisms to retrieve, reuse, revise and retain experiences. The Case Framework makes use of object-oriented design principles. It describes essential elements of a case representation for the experimental knowledge. It provides templates that use ASN.1 notation to specify components of a management information model. The template consists of key words to describe the semantics and the ASN.1 notation describes the syntax of the management information. The management cases provide an abstraction for the implicit knowledge, based upon management experiences. An experience may be represented by one or more cases. Management Cases can exist: to set equipment; to set network; to set switch; to set management applications; to implement pro-active management; to prevent failures; to establish security policies; to allocate resources; to implement
management systems; to implant quality systems; to model management information; etc. The management cases are stored in a database, called Management Case Base MCB that is added to TMN Model, as shown in Fig.2. To ease the indexing mechanisms, storage and retrieve, the management cases are grouped in class and the relationship of these classes are defined through the Management Case Tree (MCT) structure (Fig.3). Manager Application
Agent Application
TMN Experimential Knowledge
Management Operations
MIB
Notifications
Managed Objects
MCB
TMN Experimential Knowledge
Management Case
CBR Application Fig. 2. Integrating CBR to TMN Framework
Cases
Faults
Configuration
Planning
Configuration Configuration System Equipment
Switch
Routers
Fig. 3. Management Case Tree
Modeling
Security
4
TMN Case Representation
The initial task in developing a CBR application is to define a suitable language for the knowledge representation [7]. A knowledge representation language is used to represent all the information relative to a particular application domain. It defines the basic terms used to describe the cases. However, if the language is underconstrained, then the case can misinterpret the nature of the experimential knowledge. On the other hand, if the language is overconstrained, it can become overly precise and restrictive, then the case can not express its significance. Thus, it is not easy to define an ideal case language for a CBR application, which is very closely related to the domain application. The generic templates, defined in the Case Framework, provide a common set of tools and a common notation for the representation of various aspects of a TMN management case. These generic templates define the constructs that each template should contain and the order in which the constructs should appear within each template. There are generic templates for management case class definitions, package definitions, action definitions, attribute definitions, etc. The ASN.1 notation [4] used to represent the cases (e.g. [ ]; < >; |; etc.) is the same used to describe management information in TMN Model. It aims to identify and to register all elements of a case, so they can be translated in a transparent way to any sort of implementation. The great advantage is this notation is open standard and different machines can share information independently of communications platforms. So, if the cases can be represented by ASN.1, different TMN applications and environments can share this represented knowledge. 4.1
Management Case Class Template
The management case class template contains one or more constructs used for management case class definition. The generic template structure for case classes has the format as presented in Fig. 4: The MANAGEMENT CASE CLASS construct includes a class name, which may be used to refer to the class in CBR system. This is achieved by registration of an object identifier value, which identifies the management case class definition. The DERIVED FROM construct identifies a management case class it has been derived from; i.e.; a management case class which is the immediate superclass. The CHARACTERIZED BY construct defines the case characteristics. These are used to model the case relevant information. This construct allows one or more packages to be included in the management case class definition. The key words: CONTEXT, PROBLEM, SOLUTION, ADAPTATION and OUTCOME identify the package type that has to be included.
The INDEXES construct is used as secondary indexes. The main index to store and
retrieve is the class object identifier. Nevertheless, inside the class, the cases can be indexed by other attributes according to the functionality of the CBR system. The REGISTERED AS construct provides a globally unique identifier for the class definition.
MANAGEMENT CASE CLASS
[DERIVED FROM
];
[CARACTERIZED BY
[ PACKAGE-CONTEXT]; [ PACKAGE-PROBLEM]; [ PACKAGE-SOLUTION]; [ PACKAGE-ADAPTATION]; [ PACKAGE-OUTCOME];
] [INDEXES REGISTRED AS
[]*]; ;
Fig. 4. Generic Template for Case Classes Definition
4.2
The Package Types
The characteristics of a managed case class are defined in terms of context, problem, solution, adaptation and outcome. In order to provide variations among cases, the concept of "package" has been introduced. A package is a collection of characteristics (behavior, attributes and actions (Fig.5). These are different package types due to specific nature of experimential knowledge: The PACKAGE-CONTEXT describes the relevant aspects in the case The PACKAGE-PROBLEM defines what problem needed to be solved, including any other descriptive information about the situation relevant to achieving the goal. The PACKAGE-SOLUTION provides the derived solution and the reasoning steps that were made on the way to the solution. The PACKAGE-ADAPTATION provides a way of guiding adaptation of an old solution, describing the adjustments applied to the old solution in order to fit the current problem. The PACKAGE-OUTCOME specifies the results of carrying out the solution and describes the expectation about the outcome.
PACKAGE-TYPE
[BEHAVIOUR
;]
[ATTRIBUTES
[,]*;]
[ACTIONS
REGISTRED AS
[,]*;]
;
Fig. 5. Generic Template for Package Definition
The PACKAGE TYPE identifies the type of package, i.e. PACKAGE-PROBLEM
or PACKAGE-SOLUTION, etc. The BEHAVIOUR construct allows the behaviour (semantics) associated with the
package to be completely described. The behaviour can define: - The semantics of the attributes, actions, etc. - The response to solutions being presented on the management case; - The circumstances under which, actions were performed; - The reasoning applied in adaptation process; - The action functionality when it is applied; etc. The ATTRIBUTES construct allows attributes to be included in the package definition. The ACTIONS construct identifies the actions applied in problem solving. The REGISTERED AS construct provides a globally unique identifier for the package definition and registers, packages, attributes, actions, behaviour, etc. The ATTRIBUTES, ACTIONS and BEHAVIOUR templates are based on GDMO [5].
5
Applying the Generic Template
In this sense, any telecommunications equipment manufacturer company or management solutions supplier or, even, experienced network managers can create their MCB, using generic templates for management case class definitions. It allows to add value to a product or even to deal freely as a support tool for telecommunications networks management activity. However, to guarantee the development of open systems using this MCB, it must be used only standard generic templates and only one MCT. This guarantees that, all MCB developers and CBR support applications, use the same templates with mandatory attributes, creating and standardizing any new additional attributes according to each open system needs. They also guarantee that everyone uses standards primary indexes to index cases. These indexes are determined according to the standardized classes previously defined in the MCT. New case classes may be created and added to standard MCT.
For example, to display a case base for a certain switch configuration, central fictitious model TR2301, for different environments. When modeling and displaying the knowledge concerning the switch (TR2301 model), new case classes will be created and each distinct knowledge regarding the switch, or either, the experiences on optimization and configuration, under different aspects, will be defined as case classes instances. For better knowledge modeling, it may be necessary to add many classes MCT. The manufacturer of a switch, TR2301 model, creates and standardizes a switch_TR2301 class, adding to the MCT standard (Fig. 6). A case representation of switch_TR2301 class is shown in Fig.7.
Cases
Faults
Configuration
Configuration Equipment
Switch
Planning
Modeling
Security
Configuration System
Routers
switch_TR2301
Switch_TR2301 Case
switch_TR2301 MANAGEMENT CASE CLASS Switch DERIVED FROM swithccontext PACKAGE-CONTEXT; CARACTERIZED BY switchproblem PACKAGE-PROBLEM; switchsolution PACKAGE-SOLUTION; environment-switchcontext; INDEX {TR2301CaseClass 01}; REGISTRED AS Fig. 6. Management Case Base
switch_TR2301 MANAGEMENT CASE CLASS Switch DERIVED FROM swithccontext PACKAGE-CONTEXT; CARACTERIZED BY switchproblem PACKAGE-PROBLEM; switchsolution PACKAGE-SOLUTION; environment-switchcontext; INDEX {TR2301CaseClass 01}; REGISTRED AS switchcontext ATTRIBUTES
PACKAGE-CONTEXT; constraints-switchcontext environment-switchcontext
BEHAVIOUR behaviour-switchcontext BEHAVIOUR DEFINED AS ! The voice service requires priority 4! ; ; REGISTRED AS switchproblem ATTRIBUTES
{TR2301Package-Context 01}; PACKAGE-PROBLEM; model objectname goal errorcause
BEHAVIOUR behaviour-switchproblem BEHAVIOUR DEFINED AS ! The problem arises after Server 3 installation. The voice service and data service response time increased! ; ; REGISTRED AS {TR2301Package-Problem 01}; switchsolution PACKAGE-SOLUTION; reset-switch-action; ACTIONS BEHAVIOUR Behaviour-switchsolution BEHAVIOUR DEFINED AS ! The reset-solution-action was performed! ; ; {TR2301Package-Solution 01}; REGISTRED AS Fig. 7. Case Representation
Sub-classes can be added, such as: switch_Configuration_TR2301; switch_Failure_TR2301; switch_Modeling_TR2301; etc. After defining classes, the switch case base can be added to the equipment and be sold itself as a market differential, and get better price quotation in the market. The switch users may choose to purchase the case base or not. Buying it, the switch cases are added to clients' MCB, through the specific driver for each client database type.
These cases will be available for the client CBR system, developed by the clients themselves or even by solution providers, and integrated to the TMN management platforms, similar to the information modeling process for TMN platforms.
6
Conclusions
CBR has been showing to be efficient for different areas and types of applications in practice [8], with a great potential for management support in communications environment. Many tools and management solutions are available in the market adding extra modules of knowledge holding different information of the MIBs. However, these are solutions particular to a specific owner and do not reflect standards. The model here considered is basic to increase the potential of TMN management environments, following the open systems philosophy, independent from manufacturers, suppliers, etc. It is not an owner solution. In contrast to similar solutions available in market, CBR is being introduced in a standardized and compatible way with TMN Model. Another advantage is the use of ASN.1 notation for management case description. It is a standard formal notation that allows the importing of MCB in a clear way by any database, independently of the manufacturer and the environment system. Thus, a new path for TMN management market solutions is being created: TMN support applications based on experimential knowledge.
7
References
1. CCITT M.3010 - Principles for a Telecommunications Management Network (TMN), 1992. 2. Gresse von Wangenheim, C., et. al., Case Base Reasoning Approach to Reuse of th Experimential Knowledge in Software Measurement Programs, In Proceedings of 6 German, Workshop on CBR, Berlin, 1998. 3. Ramos, A. M., et. al., Integrating Case Base Reasoning to Telecommunications Management Network, to be published. 4. CCITT Rec. X.208 - Information Processing Systems - Open Systems Interconnection Specification of Abstract Syntax Notation One (ASN1), 1988. 5. CCITT Rec. X.722 - Information Technology - Open Systems Interconnection - Structure of Management Information: Guidelines for the Defnition of Managed Objects, 1992. 6. CCITT Rec. X.720 - Information Technology - Open Systems Interconnection - Structure of Management Information: Management Information Model, 1992. 7. Lewis, L., Managing Computer Networks: a case base reasoning approach, London, Artech House Publishers, 1995. 8. Watson, I., Applying Case Base Reasoning: Techniques for Enterprise Systems, San Francisco, Morgan Kaufmann Publishers, 1997.
