MXPA96005772A - A network element in a telecomunicac network - Google Patents

A network element in a telecomunicac network

Info

Publication number
MXPA96005772A
MXPA96005772A MXPA/A/1996/005772A MX9605772A MXPA96005772A MX PA96005772 A MXPA96005772 A MX PA96005772A MX 9605772 A MX9605772 A MX 9605772A MX PA96005772 A MXPA96005772 A MX PA96005772A
Authority
MX
Mexico
Prior art keywords
network element
resources
application
network
managed
Prior art date
Application number
MXPA/A/1996/005772A
Other languages
Spanish (es)
Other versions
MX9605772A (en
Inventor
Blau Staffan
Eneroth Goran
Carlsund Peter
Original Assignee
Ellemtel Utvecklings Ab
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from SE9402053A external-priority patent/SE9402053D0/en
Priority claimed from SE9500078A external-priority patent/SE503021C2/en
Application filed by Ellemtel Utvecklings Ab filed Critical Ellemtel Utvecklings Ab
Publication of MX9605772A publication Critical patent/MX9605772A/en
Publication of MXPA96005772A publication Critical patent/MXPA96005772A/en

Links

Abstract

The present invention relates to an operational support network for the operation and maintenance of a telecommunication network comprising an operations system and a data communication network, the operation system controls the telecommunication network through the network of data communication, the telecommunication network includes at least one network element that has means to carry out at least two functions of the network element that each provides an application of the telecommunication network, the medium comprises of the hardware and software resources including application-specific resources and resources common to various applications, each network element has a software management view layer that provides an interface where the network element of the operations system appears as consisting of a number of managed objects that represent resources and functions of the network element and that are used by the operating system for managing a respective resource and a function of the network element in relation to the execution of the network element function, characterized in that the managed objects of at least one network element have names organized in various tree structures hierarchical, all managed objects representing application-specific resources that are distributed in application-specific tree structures, one for each application, and managed objects representing common resources that are contained in a tree structure.

Description

"A NETWORK ELEMENT IN A TELECOMMUNICATION NETWORK" TECHNICAL FIELD OF THE INVENTION According to a first aspect, the present invention relates to an operational support network for the operation and maintenance of a telecommunication network containing an operations system and a data communication network, through which the system of operations controls the telecommunication network. The telecommunication network includes at least one network element having, on the one hand, at least two network element functions that each provide an application in the telecommunication network and, on the other hand, resources in the form of hardware and software. The resources are used to carry out the functions of the network element and include application-specific resources and resources common to several applications. * Each network element includes an administration view layer consisting of software and providing an interface outward where the network element of the operations system appears as consisting of a number of managed objects representing the resources and functions of the network. network element. The managed objects are used by the operations system to administer a respective resource and a function of the network element in relation to carrying out the operation of a function of the network element. In accordance with the second to fourth aspects, The invention relates to a telecommunication network of the class identified above, a network element of the class identified above, and a method for organizing the software in this network element, - respectively. According to a fifth aspect, the invention relates to a network element in a telecommunication network that provides a number of different types of service. The network element supports several applications of the telecommunication network and contains system resources and management information software that includes administration information "*" * application-specific and administration information for system resources common to applications. The information software of The administration is available to an operations system to manage system resources when they are to be used. By the application of the concept used in the foregoing it is meant here generally 5 something of what is placed on top of a product platform consisting of resources of the infrastructure of a telecommunication system. As an example, the different telecommunication functions such as usual telephony, mobile telephony such as GSM or NMT, broadband telephony, etc. can be mentioned.
DESCRIPTION OF THE RELATED TECHNIQUE The telecommunications networks of today are large and the number of resources in the networks is increasing. Networks provide a wide variety of services and network equipment is often purchased from different vendors. Operators of the network use a variety of different operating systems to control their networks. Each vendor's team often has its own operating system and the different services in the network are controlled in different ways, which results in high costs for operation and maintenance. One way to reduce costs for network operators has been to develop an international standard for the way in which telecommunication networks will be managed in a uniform and efficient manner from a network of operating systems. For this purpose, a standard called TMN (Telecommunications Administration Network) has been suggested. The size of a TMN network can vary from a simple connection between an operations system and a network element, to a whole network of operating systems that control a large telecommunications network. The TMN standard has been developed by an organization called ITU-TS (International Telecommunication Union for Telecommunication Standardization) and the bases are described in its recommendation M.3010. The recommendations of ITU-TS in turn are based on the recommendations of the international standard suggested by the international organization called ISO (International Organization for Standardization). The TMN recommendations suggested so far do not clearly state how to organize management information into network elements that support several "normal" applications. There are certain application-specific rules that organize the name of the administration information, ie the managed objects, in a hierarchical tree with the root of the tree consisting of a managed object called the Management Element, which is defined in ITU-T Recommendation M.3100 Number. Until now, this object administered below will be called ME.d M.
By means of the concept of "managed object" is meant herein and hereinafter the same object administered in the TMN recommendations. Managed objects related to applications are said to be able to exist together in the same "administration information tree", hence named as MIB (Management Information Base). "However, there is also At least three different application recommendations specifying their own root objects for the management information tree, these are SDH (Synchronous Digital Hierarchy), ATM cross-connection (Asynchronous Transfer Mode) and N-ISDN (Call Forwarding) (Network Digital Narrow Band Integrated Services.) Each one specifies its own administration information tree with its own root object, that is, a single case of the aforementioned ME class, or a subclass of it. will be supported on the same physical network element should be possible to support a network element in more than one information tree In U.S. Patent Number 5,062,038, U.S. Patent Number 5,063,501, U.S. Patent Number 5,063,502, U.S. Patent No. 5,063,503, and U.S. Pat. ,063,504, there are described systems including one or more infrastructures that are used by processes carried out in a processor. The infrastructures include tree structures.
COMPENDIUM Generally, the invention is based on the knowledge that the following reasoning was important to lead to a solution to the above problems. As can be seen from the point of view of the administration of the network, it is imaginable with two scenarios different for the management of the network elements of multiple applications, for example, in the same f "" administration manages all the different applications provided by the network element, and that one or more of the applications is administered by a separate administration. In the scenario mentioned last, the administration information for the different applications must be separated into different NIBs, since each administration must only manage its own 5 managed objects. Also, the authorization of "access rights then in this case will be automatically associated with the domain of the managed objects that correspond to the one that is going to be administered by each separate administration, since the certification supervision is carried out in relation to the establishment of the communication between an operations system and a network element, and since the certification is obtained for a certain MIB that is identified with the name of the root object, that is, ME.In the first scenario it is possible that the administration does not require separation of certification of management information in different MIBs because the administration manages all applications.In this case, however, it is still often practical to structurally have management information clearly separated for different applications. personal, for example, may have previous experience knowledge of different administration. There may be an expert on the administration of an ATM application and another N-ISDN expert. One consequence of supporting separate management information trees for different applications is that the management information for the internal system resources shared by the applications, such as the resources of the general calculation system, the operating systems, the equipment physical, etc. must either be part of one of the application-specific MIBs or a separate MIB is needed to manage these resources Based on the above-mentioned reasoning there is a general object of the invention to indicate a new method for managing more of an administration information tree in the same physical network element, that is, more than one MIB. In this connection, certain problems that relate to the hierarchical organization of the managed objects that exist in the network element must be resolved. This hierarchical organization is used to translate names of the managed object that is used in operations ordered by a central operations system in the telecommunication network to a network element, up to an identity of the internal object for identity of the managed object in the infrastructure of the element of network. There is an additional object in this communication to provide a solution to the problem of how to organize the view of the naming of the MIB in a network element, in order to be able to simply combine and add different applications.Still one object is to indicate the manner in which the structure of the infrastructure and its MIB in the different domains of information separate one for each separate application each with its own MIB. A still further object is to indicate the manner of naming externally, that is, from a system of operations, the different MIBs of a network element. Another object is to indicate a network element with a separate MIB for the infrastructure. An additional object is to indicate the way to name the relationships between the objects managed in the different MIBs. Still a further object is to indicate a network element that is flexible enough to be able to solve the problems in relation to the naming / management due to the fact that different network operators may wish to have an organization different from the infrastructure. According to the invention, the above objects and others that will appear more clearly below have been achieved in the operational support network, the telecommunication network and the network element identified above in accordance with the first to the third Aspects, respectively, and since the managed objects of at least one network element "have names organized in various structures of the hierarchical tree, all the organized objects represent application-specific resources that are distributed in the structures of an application-specific tree, one for each application and the managed objects that represent common resources that are contained in a common tree structure The method for organizing the software into a network element, in accordance with the fourth aspect, comprises the steps of organizing the names of the objects managed in various structures of the hierarchical tree by distributing all Managed objects that represent application-specific resources in the structures of the application-specific tree, one for each application, and place the managed objects that represent the common resources in a common tree structure. In the network element according to the fifth aspect, the names that identify the parts of all the administration information are organized into several application-specific administration information bases, each in the form of a respective hierarchical tree structure.
BRIEF DESCRIPTION OF THE DRAWINGS The invention will now be described more clearly below with reference to the modalities shown in the accompanying drawings, wherein Figures 1 to 12 are intended to illustrate generally the TMN standard which can be said to form one of the basic principles for and to subsequently elucidate the described embodiments of the invention, wherein Figure 1 shows an example of a telecommunication network in accordance with TMN, Figure 2 illustrates schematically the division of a network element included in Figure 1 In the administration layer and a resource layer, Figure 3 schematically illustrates an example of the way in which an operations system manages a resource through an administration object representing the resource, Figures 4 to 6 schematically illustrate the different examples of how managed objects can represent resources and other objects, La Figu ra 7 shows an example of hardware included in a simple network element that can be included in the telecommunication network according to Figure 1, Figure 8 shows the view of the management object of the network element according to Figure 7, with different functional relationships between the managed objects, Figure 9 illustrates an administration information tree consisting of managed objects included in the administration layer in Figure 8, Figure 10 is a view illustrating the communication and interaction between a system of operations and a network element, Fig. 11 is a view intended to illustrate a logic model of a telecommunication network of the kind shown in Fig. 1, Fig. 12 is intended to illustrate different groupings of application-specific administration information of various applications in a telecommunication element. network that will share the common internal system resources, Figure 13 is a view illustrating the implementation in a first embodiment of the network element according to the invention, Figure 14 is a view similar to the Figure illustrating the communication and interaction between an operations system and the managed objects included in the network element according to Figure 13, Figure 15 is a view illustrating the design of a second mode of the network element in accordance with the invention, Figure 16 illustrates the location of so-called support objects in the example according to Figure 13.
DETAILED DESCRIPTION OF THE MODALITIES As a first introduction to the following description of the embodiments of the invention, and since these modalities for practical reasons are mainly based on the application of the invention in a TMN environment, a number of terms and concepts will be more closely described. this respect with reference to Figures 1 to 11. However, as it will appear later, the use of the invention is not restricted to this environment, but may be manifested as comprising all environments based on the international ISO standard. Figure 1 schematically shows a scenario 102 of the network of operations in accordance with TMN for a telecommunication network 104. Subsequently, the manner in which two subscribers 106 and 108 are interconnected through the network elements in the form of a first exchange 110 to which the subscriber 106 is a member, a first transmission system 112, a transit exchange 114, are indicated. a second transmission system 116 and a second exchange 118 to which the subscriber 108 belongs. The operation network 102 contains two operations systems 120 and 122 that through a data communication network 124 and an interface 126 of Q3 as they communicate with the elements 110 to 118 in the telecommunication network. Q3 is a normalized physical interface between two TMN building blocks, such as the network element and the operations system. It consists of two parts, for example, a management protocol and a management information model visible in the interface. For a clearer description of the Q interface, reference is made to ITU recommendation number M.3010. A local operations system 128 communicates directly with the exchange 108 through the interface 126. The interface 126, Q3 through which the operation systems such as 120, 122 and 128 see the telecommunication network 104 in TMN, it is a standardized data communication interface where all types of network equipment can be managed in accordance with the uniform principles. The interface Q3 defines both the object-oriented information model of the network elements 110 to 118, the communication protocol between the operation systems 120, 122 and the network elements 110 to 118. Referring to Figure 2, a network element 202 schematically illustrated is divided into the management view layer 5 204 and a resource layer 206. Of the operating system designated here 208, only the administration view layer 204 is visible. The outward management view layer 204 presents a view that appears as a collection of managed objects 210 that can be administered from the operating system 208 through the Q3 interface. The managed objects are defined with respect to the way in which the network element will appear for a maintenance technician. There are 5 standardized managed objects for most applications. Consequently, a maintenance technician will know everything "" "about when the network elements of the different vendors are controlled The resource layer 206 is the actual implementation 0 of the functionality of the network element 202. The resources are designed for the best features of the system. Execution and consumption of memory are examples of the characteristics that must be taken into account when implementing the resource layer.
As an example, Figure 3 shows the manner in which resource 302 is administered, the arrow 308 from an operations system 310 through a managed object 312 that represents, the arrow 314 and the resource 302. The administered object 312 then acts as an "interface" to the operations system. A managed object can not store any data, but all the data belongs to the resources. There is not necessarily a 1 to 1 mapping between managed objects and resources. Several managed objects can be implemented as a resource, see Figure 4, where two managed objects 402 and 404 represent and each provide their administration view of a resource 406. One reason for implementing the two objects managed as a resource is to achieve best features of the application. The more complicated managed objects could be implemented as a combination of resources such as in Figure 5, which shows a managed object 502 representing a combination of three resources 504, 506 and 508. A managed object can also represent other managed objects to raise the level of abstraction, for example, Figure 6, wherein one object 602 administered represents, arrow 604 and 606, two other "objects 608 and 610, respectively, object 608 then represents a resource 612, and object 610 represents two resources 614 and 616. The operations support functions can then be implemented in the higher managed object 602 5 instead of in an operations system In Figure 7, the hardware of a single network element 702 is shown, which here it can be assumed that corresponds, eg, to the local exchange 110 in Figure 1.
The network element 702 includes a switch 704 to which two processors 706 and 708 are connected. To the switch 704, a subscriber 710 is connected, which can be imagined as being the same as the subscriber 106 in Figure 1, through the circuit 712 of the subscriber line. The network element 702 has a connection to the rest of the network through the line terminal 714, which is communicated through a / - link 716 of PCM. This simple network element can be administered from a system 718 connected to the processor 706, which corresponds to the system 120 of operations in Figure 1. Figure 8 shows only the administration layer of the network element in Figure 7 and designates 802, the operating system being designated 804. More specifically, the management layer 802 consists of managed objects that are named with class names and respective cases in Figure 8. In the administration layer 802, the subscriber 710 in Figure 7 is represented by a case 7273000 of a managed subscriber 806 object of the class. The object 806 through which the subscriber data in the resource layer can be obtained, has the status of "connected with" a case 11 in a managed object 808 of the subscriber line of the class, which can reach the data of line connection. More specifically, this object represents the line between the subscriber and the line circuit 712 in Figure 7. The talk channels on the PCM link 716 in Figure 7 are represented by each case of an object 810 of the line main class. In the network element there are two main lines shown as being connected to an output address, while three main lines are connected with an input address. This is represented by an "output" case of an object 812 in the class path, and an "input" case respectively of an object 814 of the same class. The rest of the main lines in the PCM link are not used in the network element 702. The data of a managed object is specified as attributes. An attribute of a managed object can correspond to a persistently stored attribute of - * an resource object, but it can also be calculated in an algorithm that obtains the attributes of several resource objects. The resource data can also be stored in the file system or in the hardware registers. A managed object of the 'main line, can v.gr., have the following attributes: line principalld, state and miRuta. In this case, all three attributes correspond to the attributes in the same resource object. The operations that can be carried out in a managed object are: create and delete the case of a managed object, obtain and graduate that reads and writes respectively a value of the attribute, requests of action of a managed object to carry out a task. Actions are used when the operation is more complicated than just obtaining or grading an attribute value for a managed object. Actions involve the managed object as a whole but may also indirectly involve other managed objects. A managed object can also send notifications and inform the operating system that an event has occurred in the network element. An alarm condition is an example of a notification, notifications are also used for other purposes eg to load the data and traffic statistics, when a long period of time is required to carry out an action. The return value of the action can mean that the task has been started, then the result of the action is sent as a notification, and managed objects can have associative relationships with other managed objects. The main lines, eg, can be members of a route Associative relations are specified as attributes In the network element disclosed in the foregoing with reference to Figures 7 and 8, there are several main lines. All of them have the same attributes, actions and notifications. In object-oriented terms, there are cases of a main class line of the managed object. The collection of all managed object cases created in a work item is called the MIB administration information base. The management information base is an abstract concept and should not be confused with a base of the physical data that is used to persistently store the data within a system. In some network elements, there is a large number of managed objects. In order to be able to search for a specific managed object and navigate through all managed object cases created in a network element, there needs to be a graded naming structure for managed objects so that all objects get unique names. The standard recommends the appointment based on all the names of the managed object that are organized as a tree, also called MIT (Management Information Tree). The relationships that make up MIT are called name binding relationships. In Figure 9, the MIT for the example described above with reference to Figures 7 and 8 have been shown, assuming that the network element 702/902 is part of the ISDN network. Each managed object gets a case name when it is created. All managed objects that are "children" of the same managed object must have different case names. The case name does not need to be unique within the managed system, but two managed objects can have the same case name as long as they have different "parents".
Each managed object also has a name that is used to uniquely identify the same within the entire managed system, called a DN distinguished name. The distinguished name starts from a level below the root object of the MIT and ends with the case name of the managed object. In appearance it looks a lot like a name in the UNIX full path. As an example, the distinguished name of the main case lines of the managed object line can be written as follows: DN =. { Route = Entry route / Main line = Main lines 5.}. The communication between the operating systems and the network elements is defined in the Q3 interface. The standards recommend how to reach and operate the managed objects of a system of operations. In addition, the standards recommend how managed objects should inform the operations system about events in the network element. An operational support function in the operation system manipulates the objects managed in the network element through a specific agent function in the network element. The interaction between the operations support function and the agent function is shown schematically in Figure 10. The operations system designated 1002 in Figure 10 is the administration system and the designated network element 1004 is the managed system. The operations support function is designated 1006, the function of the agent 1008, the managed objects 1010 and the resources representing the latter are designated 1012. For the operating system 1006 and network element 1004 it appears as consisting of a number of objects managed, ie, the objects 1010. This summarizes and for the operations system 1006 only the view of the network element 1004 is indicated at 1014. The operations support function 1006 initiates contact with the agent function 1008 by establishing an association of communication with the function of the agent. This association can be considered as a communication link between the two systems. When the association has been established, the operations support function and the agent function can communicate with each other. The operations support function 1006 manipulates the managed objects 1010 by displaying their distinguished name and using defined operations (create, delete, set, obtain and action) which are indicated by the arrow 1016. The managed objects 1010 generate information, notifications, which can be be sent as event reports, arrow 1018 to the operations system. In the figure, the arrows 1020 indicate the communication of the function 1008 of the agent with the objects 1010 and the arrows 1022 indicate the relations between the objects 1010 and the resources 1012 represented by them. The function 1008 of the agent handles communication to the operations systems 1002, creates, deletes the managed objects on demand and finds - by means of the name of the managed object included in a demand of operation - the case of the managed object being searched. For this purpose, the agent function has information related to the association between the distinguished name and an internal identifier of the system for the managed object that has been created. The agent's function also maintains information related to allowing name bindings in the name tree and creates only - ~ * an object if the class identity and the desired name are in agreement with the one that is allowed. The 1008 function of the agent also contains a function 1024 of command / operation interpretation in the form of an algorithm that receives and analyzes the messages of the operations system in relation to the previously described and through the function of the agent carries out the function to manipulate the managed objects and " It also handles the execution of the operations necessary for this purpose, as an additional introduction to the following description of the modalities of the invention., now also follows a brief presentation of still a description model on which this description is based. As mentioned above, a telecommunication network provides a large number of different types of services. Examples are: bearer services, telecommunication services, supplementary services, etc. With reference to the example shown in Figure 11, these services are frequently described with respect to a logical model of the network, which consists of a number of logical network planes, each plane including the functions of the network element related to a network area. different service. Each logical network can therefore be said to represent a specific view of the application of the physical network and its network elements. In Figure 11, the functions of the network element are shown as including in the plane 1102 the physical networks, in the plane 1104 the transport networks, in the plane 1106 the telecommunication service networks, in the plane 1108 signal networks and in the 1110 plane, the network services inteligents.
Figure 11 further includes an operations support network 1112 which is shown very schematically as including the operations systems 1114. The operating systems 1114 communicate through a data communication network 1116 and an inaccessibility Q3 with the telecommunication system, which represents the plans 1102 to 1110. The plane 1102 is shown as including, as an example, a number of network elements 1118 to 1124. In each network element, the application-specific network element functions are indicated by filled ovals. The network element 1118, which can eg be imagined to correspond to a transit center in the telecommunication network in question, is therefore shown as including the functions 1126 and 1128 of the network element providing the services 1130 of N-ISDN and 1132 B-ISDN services (broadband ISDN) in plane 1106, and a function 1134 of the network element providing ATM transfer services 1136 in plane 1104. Network element 1118 in addition supports, through a function 1138 of the network element, a signal point 1140 SS # 7 (Signal System 7 - according to the ITU-T standard) in the 1108 plane, due to the fact that ISDN uses the SS 7 network.
Another example of this network element for several applications could be a local switch in Figure 11 schematically illustrating the functions of the network element of the three network elements 1120, 1122 and 1124, respectively, and that by means of the latter provides GSM- and ISDN services as well as SDH cross-connect services. In Figure 12, the management view layer of the network element is shown in addition to a alternatively, in the direction of arrow XII in Figure 10, wherein the administered objects have more generally been replaced by different groupings of administration information. The Figure shows in a more specific way the way in which a layer 1202 of administration view of a network element, a first specific administration information 1204 Application "**" *, e.g., of N-ISDN, and a second application-specific information 1206, e.g., B-ISDN, share common infrastructure management resources 1208.
Management information 1204 is shown as using a first and a second infrastructure management resources 1210 and 1212, respectively, while administration information 1206 also utilizes the second infrastructure management resource 1212 and a third resource 1214 of infrastructure. infrastructure administration. In accordance with one of the aspects of the invention and with reference generally to the previous Figures, in particular to Figures 1, 2, 11 and 12, a network element of the kind proposed herein, e.g. , 1118 in Figure 11, can be defined as including at least two network element functions, v.gr, 1126 and 1128 in Figure 11, and internal resources in the form of hardware and software. Each of the network elements provides an application, e.g., 1130 and 1132 in Figure 11, in the telecommunication system where they are included. The resources are used in connection with the execution of the functions of the network element. They include application-specific resources and resources common to various applications. The network element is reinforced, in addition to the resource layer, by an administration view layer, e.g., 210 in Figure 2 or 1202 in Figure 12, in the form of managed objects having access to the information in the resource layer. The managed objects represent the resources and are used for program-controlled administration, v.gr, by means of the operating systems 1114 in Figure 11, of the respective resource during the use of the resource in connection with the execution of an element function of network.
A network element of the precisely defined class is, in accordance with an essential particularity of the invention and as it will appear more clearly by means of the description of the modalities that will be presented next, the administration information distributed through several separate administration information structures, the MIBs. More specifically, all the application-specific administration information is distributed in the application-specific information structures, that is, the MIBs, one for each application, and the administration information representing the common resources, are included in one. common management information structure, that is, the MIB. A first embodiment of the invention is shown in Figure 13. In the management view layer 1302 of a network element that includes the administration information for two different applications 1304 and 1306, respectively, and the management information for the resources 1308 of the infrastructure. Administration information is achieved through the cases of managed objects shown here for reasons of clarity only with a number of ovals in the respective administration information set 1304 to 1308. Each year of games 1304, 1306, 1308 of management information forms its own MIB 1310, 1312 and 1314, respectively. Each of the MIBs 1310, 1312, 1314 has a root object shown in the form of a ME 1316, 1318 and 1320, respectively, of the class defined in recommendation M.3100 of the ITUT-T- of the objects • administered ME, which has been previously indicated, or a subclass of this. The characterization for ME is that, as the only attribute has the name of a corresponding collection of management information, that is, the MIB. This name has the form AEtitle (Application Entity Title) with an addition for the name of the case, in accordance with OSI ACSE (Service Element of Association Control). Corresponding to this, the name of the respective tree in the example shown is AEtitle-x, • "AEtitle-y and AEtitle-z, respectively, where x, y and z represent the name of the case, Each of the trees 1310, 1312 and 1314 has its own reference point 1322, 1324 and 1326 of q3, respectively, in the administration layer and the tree is identified in the ACSE protocol by the protocol stack Q3 with an application-specific AEtitle. By reference point q3, it is meant here that it is seen through the operating system of the MIB in the Q3 interface.
With reference to the foregoing description by means of Figure 10, in the manner in which the interaction between the operation support function 1006 and the agent function 1008 is performed, a modification of the element is shown in Figure 14. 1004 of network in Figure 10. From this modification, the way in which the operating system in the case according to Figure 13 by means of the agent function can reach the objects included in the respective administration trees in the Figure 13. In Figure 14, the network element is designated 1402 and the function of the agent 1404. In addition, the MIBs 1310 and 1312 with the case names x and y, respectively, are indicated at 1406. The resources represented by the supplied objects included in the MIBs are indicated at 1408. The agent 1404 contains the information of the naming tree for the MIBs included in Figure 13, as an example indicated at 1410 and 1412 for the MIBs 1310 and 1312 In 1414 a corresponding command / operation interpreter is displayed. A second embodiment of the invention is shown in Figure 15. In the management element layer 1502 of the network element, the administration information for two different applications 1504 and 1506, respectively, and the administration information for resources 1508 of the Infrastructure are included. The administration information is reached through the cases of the administration objects that are also shown here for reasons of clarity only with a number of ovals in the game 1504 to 1508 of respective information. Each of the administration information sets 1504, 1506, 1508 forms a respective MIB, the game 1514 in a MIB 1510 and the games 1506 and 1508 in a common MIB 1512. Each of the MIBs 1510 and 1512 has a root object shown in the form of an ME 1516 and 1518, respectively, of the class of managed objects defined in recommendation M.3100 of the ITUT-T or a subclass thereof. . Each of the trees 1510 and 1512 has its own reference point q3, the 1522 and 1524, respectively, in the administration layer, and the tree is identified in the ACSE layer of the protocol stack Q3 with the specific title of application AEtitle-x and -y, respectively. In Figures 13 and 15 the inter-MIB ratios within a network element are further indicated by double arrows 1328, 1330 and 1528, respectively. The two embodiments of the invention described above have important advantages.
They are adapted to standards where different MIBs require different class definition for their specification of the root management object. It is possible to perform authentication control for each MIB during the establishment of an administration association. The first mode, according to Figure 13, has the advantage. in relation to the second one in accordance with Figure 15, it is possible to carry out authentication control separately to manage the resources of the infrastructure. As it has become evident from the foregoing, each separate application-specific MIB has as its root object a managed object of a specific specialization (that is, for each market / or application) of the class of managed objects ME, which is included in the normal M.3100 recommendation . Each application, therefore, has its own reference point q3 and the MIB of it is identified in the ACSE layer of the protocol stack Q3 with an application-specific AEtitle. Consequently, also the authentication control is carried out for each MIB during the establishment of the management communication association between an operations system and the network element.
If the managed objects representing the resources of the infrastructure are placed in a separate MIB, such as 1314 in Figure 13, this administration object is also enumerated by a separate case of the class of ME managed objects. This implies that also the MIB of the system infrastructure is identified in the Q3 protocol with its own AEtitle, and the specific authentication of the MIB takes place during the establishment of a communication association. When there are different MIBs in a network element, such as in Figures 13 and 15, there is a need to support the existence of inter-MIB relationships within a network element, that is, the relationships between the management objects in a network element. the different MIBs in network element, for example, arrows 1328 and 1330 in Figure 13 and an arrow 1528 in Figure 15. This is eg the case when one of the applications offers its services to the other applications . Two possible solutions for this object are conceivable. In accordance with a solution, inter-MIB relationships within a network element are represented by an attribute with a global network "distinguished name". This, however, requires coordination of the appointment between all network elements and all operating systems, that is, Singular root names globally. However, this is not often supported by the networks of today. The other solution, which may be preferable because it is easy to implement, implies that the inter-MIB relationships within a network element are represented with an attribute that is not only referring to the "distinguished name" for the case of the object inside. of a MIB, but also an AEtitle, which uniquely identifies the other MIB as seen from the operations system. If there are requirements to support the "sphere of action-and-filtration" (operations on more than one object at a time) that covers more than one application in a network element, eg, carrying out the " sphere of action-and-filtering "through both data of the GSM subscriber- and N-ISDN, these specific applications must be specified within the same MIB, assuming that there is no special support for scanning through the operating systems. of the various MIBs. If it is acceptable for administrations to have to explicitly divide this activity into two separate activities, separate MIBs can be used for each application. Also, it would be quite possible within a network element to have a mediation function for specific multi-MIB operations.
Here, the administration of the so-called support objects in a network element containing several applications will be made known more clearly. More specifically, there is the issue of managed objects that offer general administration support that is not needed for the usual function of telecommunication services. These administration objects are often needed in all applications and are usually referred to as "support objects" in the normal recommendations. "For example, there are the classes of Administration Operations Program, Registration, Sales Dispatch Discriminator (EFD), State Change Record, Object Creation Record, Alarm Record, Alarm Serial Assignment Profile, etc. Managed objects of these classes can be included in each specific application MIB, see for example Figure 15. that Figure 15 illustrates the same situation as Figure 13, the same reference characters have been used in Figure 15 to designate the same elements, with the exception that in Figure 15, the first fifteen figures replace the corresponding figures 13 in Figure 13, to indicate which Figure they belong to.
Figure 16 which specifies in each of the three MIBs 1610, 1612 and 1614, respectively, the class record in a managed object 1642, 1644 and 1646, the EFD class in a managed object 1648, 1650, and 1652, and the alarm record class in a managed object 1654, 1656, and 1658. Support objects created in an administration association will result in managed objects with binding of name to ME being the root of the MIB for the association in question. When discriminators are created (in the Registry or in EFD), the managed object cases in question are identified with locally distinguished names which implies that the reference can only be made to cases of the objects managed in the same MIB. Since the degree of the discriminator specification can at most identify the objects managed in the same MIB, as the object of EFD resides in it, it is not possible to centralize the location of the support objects used by the MIBs of application, that is, they can not be placed in a common central MIB. This is due to the fact that none of the objects managed in the other MIBs can be reached since the root of the local distinguished name is the ME for this MIB.
The administration of the equipment in relation to a network element with more than one MIB will now be discussed more clearly. A network element comprises separate pieces of equipment, such as, for example, cabinets, sub-grids, circuit boards, power packs, fans, etc. Each separate unit of equipment is usually represented by a managed object of the M.3100 equipment class or the subclass derived from it. This is in order to be able to manage, for example, the alarm indication of the equipment, the repair of equipment, the improvement of equipment in collections of equipment, etc. In a network element with many MIBs all the managed objects of the equipment must be placed in one and in the same MIB, the infrastructure MIB of the system, if there is this separate infrastructure MIB regardless of the specific hardware that is provided by a unit of equipment specific. Basically there are two aspects of team management that motivate this, as will be discussed below. The first aspect has to do with the administration of separate pieces of physical equipment.
If the managed objects of different equipment units were to be distributed among the different MIBs, then it would not be possible to carry out, within the same administration association, the action / filtration wax operations that cover all the installed equipment. Having the managed objects of equipment in the different MIBs would be particularly confusing from the point of view of repair and improvement of the equipment, if the corresponding units of equipment are installed in the same cabinet / sub-grid. Basic to the second aspect is that it should be possible for different applications to share the use of physical equipment. It must be quite common, in a case of multiple MIBs, that the managed objects of the different application MIBs have dependent relationships with respect to the same managed objects of the equipment. Determining the managed object of application that depends on a managed object of the specific equipment is sometimes a matter purely of configuration / resource allocation. A special example of this is sharing the central processing resources. This equipment must be administrated taking into account all the application-specific processing. Therefore, in a multiple MIB network element, this equipment must consist of a MIB common to all applications. Actually there are several reasons for all the managed objects of the team to remain in this common MIB, ignoring those applications that use the hardware of the equipment during the operating time. A specific reason is, for example, that in a distributed processing environment, the managed objects of the processing environment depend on the same resources of the equipment as are the managed objects of applications. Likewise, managed objects from the distributed processing environment often have more complicated inter-relationships with the equipment, and they have the managed objects of the applications. Therefore, it is convenient to place all the objects of the equipment together with the managed objects of the operating system in the same MIB, as shown in Figure 13. What actually makes this possible, is that the managed objects of the equipment do not normally include information for the administration of real functions or supported by hardware. In most cases, this is better managed and is still required by some application rules that are to be administered, through the application-specific managed objects that remain in the application MIBs. For example, the MIB of an application can include managed objects for the termination points (communication end points), which at the time of operation correspond to the specific line-hardware-interface that is provided by different equipment units. Nevertheless, there is rarely a good reason for managed objects for the real-interface-hardware line in the equipment unit. Any management association between the managed objects of the computer and the managed application objects instead is handled better through the relationship attributes in any of the objects of the computer or in special resource allocation / association objects. To be able to see the reverse association, the normal application managed objects with relation can be extended with association attributes towards the objects of the equipment (respectively towards the resource association objects). This principle of separation of hardware aspects of computer management and administration of aspects of hardware application is currently general, not taking into account whether a network element contains one or more MIBs.

Claims (12)

R E I V I N D I C A C I O N E S;
1. An operations support network for the operation and maintenance of a telecommunication network comprising an operations system and a data communication network, the operation system controls the telecommunication network through the data communication network, the telecommunication network includes at least one network element having means to carry out at least two functions of the network element that each provides an application of the telecommunication network, the medium comprises of hardware and software resources including application-specific resources and resources common to several applications, each network element has a software management view layer that provides an interface where the network element of the operations system appears as consisting of a number of managed objects that represent resources and functions of the network element and that are used by the operations system for ad administering a respective resource and a function of the network element in relation to the execution of the network element function, characterized in that the managed objects of at least one network element have names organized in several hierarchical tree structures, representing all managed objects Application-specific resources that are distributed in application-specific tree structures, one for each application, and managed objects that represent common resources that are contained in a common tree structure.
2 . A telecommunication network that includes at least one network element that has a means to carry out at least two functions of the network element that each provides an application of the telecommunication network, the medium comprises hardware and software resources that include application-specific resources and resources common to several applications, each network element has a software management view layer that provides an interface where the network element of an operations system appears as consisting of a number of managed objects , which represent resources and functions of the network element and which are used to manage a respective resource and a function of the network element in relation to the execution of a function of the network element, characterized in that the managed objects of at least one network element has names organized in various hierarchical tree structures, all objects managed they represent application-specific resources that are distributed in the application-specific tree structures, one for each application, and the managed objects represent common resources that are contained in a second common tree structure.
3. A network element included in a telecommunication network and having a means to carry out at least two functions of the network element that each provides an application of the telecommunication network, the medium comprising hardware and software resources including application-specific resources and resources common to various applications, the network element has a software management view layer that provides an interface where the network element from an operations system appears as consisting of a number of managed objects, which represent the resources and functions of the network element and which are used by the operations system to manage a respective resource and a function of the network element in relation to the execution of a function of the network element, characterized in that the objects managed elements of the network element have names organized in several hierarchical tree structures representing or all managed objects, application-specific resources that are distributed in application-specific tree structures, one for each application, and managed objects represent common resources that are contained in a common tree structure.
4. A method for structuring the software into a network element included in a telecommunication network and having a means to carry out at least two functions of the network element which each provides an application of the telecommunication network, the means comprises hardware and software resources including application-specific resources and resources common to various applications, the network element has a software management view layer that provides an interface where the network element of an operations system appears as consisting of of a number of managed objects, which represent resources and functions of the network element and which are used by the operations system to manage a respective resource and a function of the network element in relation to the execution of a function of the network element, characterized in that names of managed objects are organized in various structures of the hierarchical tree d distributing all managed objects that represent application-specific resources in application-specific tree structures, one for each application, and placing managed objects that represent common resources in a common tree structure.
5. A network element in a telecommunication network that provides a number of different types of services, the network element supports different telecommunication network applications and contains system resources and management information software that includes the specific management information of application and administration information for the system resources common to the applications, the management information software is available to an operations system to manage the system resources when they are going to be used, characterized in that names that identify parts are organized of all the administration information in several application-specific administration information bases each in the form of a respective hierarchical tree structure.
6. A network element according to claim 5, characterized in that also, the administration information for common resources is handled by a separate tree itself.
7. A network element according to claim 5, characterized in that the administration information for common resources is administered by the same tree, as an application-specific information. A network element according to any of claims 5 to 7, characterized in that the administration information tree for the application-specific information has a root object in the form of a managed object of a specific class of objects administered or a subclass thereof, the managed object being the only attribute that has the name of the corresponding administration information tree. 9. A network element according to claim 8, characterized in that the administration information tree for common system resources also has a root object in the form of a managed object of the specific class of managed objects, or a subclass of them. 10. A network element according to any of claims 5 to 9, characterized by relationships between the objects managed in different management information trees. 11. A network element according to claim 10, characterized in that the relationships between the cases of the managed object are represented by an attribute with a globally distinguished name. 12. A network element according to claim 10, characterized in that the relationships between the cases of the administered object in different administration information trees are represented by an attribute that, as seen from the operations system, refers both to the singular name of the administration tree for the case of the object in the respective administration information tree and identifies the other administration information tree.
MXPA/A/1996/005772A 1994-06-13 1996-11-22 A network element in a telecomunicac network MXPA96005772A (en)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
SE9402053-4 1994-06-13
SE9402053A SE9402053D0 (en) 1994-06-13 1994-06-13 Methods and apparatus for telecommunications
SE9500078-2 1995-01-11
SE9500078A SE503021C2 (en) 1994-06-13 1995-01-11 Operating support networks for a telecommunications network comprising network elements, telecommunications networks comprising network elements, network elements and ways of structuring software in a network element
PCT/SE1995/000712 WO1995034975A1 (en) 1994-06-13 1995-06-13 A network element in a telecommunication network

Publications (2)

Publication Number Publication Date
MX9605772A MX9605772A (en) 1998-05-31
MXPA96005772A true MXPA96005772A (en) 1998-10-23

Family

ID=

Similar Documents

Publication Publication Date Title
US5696697A (en) Network element in a telecommunication network
US5799153A (en) Telecommunication system
US5764955A (en) Gateway for using legacy telecommunications network element equipment with a common management information protocol
EP1175753B1 (en) Telecommunications network resource handling arrangement and method
CA2535440C (en) System architecture method and computer program product for managing telecommunication networks
US6385650B1 (en) Arrangement and method relating to information managing systems
CA2132364A1 (en) Multi-network management
Popescu-Zeletin et al. ‘Y’distributed application platform
MXPA96005772A (en) A network element in a telecomunicac network
Deliverable Overall Concepts and Principles of TINA
KR20010046981A (en) Resource configuration device in ATM networks and Resource configuration management method thereof
Pavlou Telecommunications management network: a novel approach towards its architecture and realisation through object-oriented software platforms
EP1088424A2 (en) Network management
Mills An OSCA™ architecture characterization of network functionality and data
Aidarous et al. Subnetwork management and TMN in an evolving network
Liang et al. Two-dimensional modeling in TMN: a systems approach
An et al. TMN-based intelligent network number portability service management system using CORBA
Raatikainen Recent Developments in Telecommunications Software Architectures
Wolland An introduction to TMN
Sevcik Pitfalls and Merits of OSI/CMISE Solutions in Real-world TMN
Kantola Adapting management of DX 200 switching system into TMN object model
SECTOR et al. ITU-Tm. 3100
KR20020087538A (en) Method for supplying information of managed object in Telecommunication Management Network System
SECTOR et al. IT5 Tm. 3100
Deak Introducing Intelligent Networks into the PSTN