CA2192371A1 - Apparatus for managing a telecommunications network - Google Patents
Apparatus for managing a telecommunications networkInfo
- Publication number
- CA2192371A1 CA2192371A1 CA002192371A CA2192371A CA2192371A1 CA 2192371 A1 CA2192371 A1 CA 2192371A1 CA 002192371 A CA002192371 A CA 002192371A CA 2192371 A CA2192371 A CA 2192371A CA 2192371 A1 CA2192371 A1 CA 2192371A1
- Authority
- CA
- Canada
- Prior art keywords
- messages
- rules
- message
- network
- alarm
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0062—Provisions for network management
- H04Q3/0075—Fault management techniques
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13503—Indexing scheme relating to selecting arrangements in general and for multiplex systems object-oriented systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13521—Indexing scheme relating to selecting arrangements in general and for multiplex systems fault management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13545—Indexing scheme relating to selecting arrangements in general and for multiplex systems monitoring of signaling messages, intelligent network
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
A network manager for a telecommunications network has a communications stack (50) for receiving messages from the telecommunications network relating to the network elements. These messages are supplied to a message processor (52). In the message processor (52), each message is identified and parsed according to a set of rules which are established before the network manager is in operation receiving messages from the network. After each message has been identified and parsed, it is processed according to a second set of rules which can be established and modified while the network manager is in use receiving messages. The second set of rules are established from a set of prototype rules. These rules permit the user to specify a wide range of operations that can be preformed on the messages. For example, messages of specified types can be correlated, other messages can be forwarded to specified destinations, and certain messages can cause further messages to be generated. Messages can be forwarded, for example, to a configuration manager (54) or a fault manager (56) and further messages can be sent to equipment which is external of the network manager.
Description
i;0~06/96 14:31 u.\, \ '\24832.dgc 2l 92371 APPARATUS FOR r~Al~'A~LNG A TEI FCOMMUNICATIONS NFTWORK
This invention relates to an apparatus for managing a telecommunicatjons network and also to a method of operating such an apparatus.
Such an apparatus receives messages relating to the operation of elements of the telecommunications network which it is managing. It is desirable to process such messages in an a,uplu,ùlia~ manner before passing them on to other uulll,uol1~llL:, of the apparatus.
Apparatuses for managing telecommunications networks are discussed in 10 the following two articles.
1. INTERNATIONAL SWITCHING SYMPOSIUM 1992 Session C1, Paper 2 vol. 1, 25 October 1992 YOKOHAMA JP
pages 65 - 69, XP 000337618 SEVCIK, 'Adaptable TMN: A new dimension in practical network management 2. GLOBECOM'92 vol. 1, 6 December 1992 ORLANDO US
pages 560 564, XP 000357845 LIN ET AL. 'A framework for learning and inference in network ",a,~ag~ "L' The first of these articles focuses on Q3 interfaces, User Interfaces and application structures. The second article describes the use of an expert system in 25 network Illallàldalllal,L apparatus.
According to this invention, there is provided an apparatus for managing a telecommunications network including:
means for receiving messages relating to the operation of elements of the telecommunications network;
first means for processing said messages, said first means being arranged to process said messages in accordance with a first set of rules which are e~LdLl;~lled before the apparatus is in use receiving messages, said first set of A~IENDED SHEET
106196 14:31 _ ~, ` '\24832.d~c 21 92371 ` `
rules including rules for identifying messages according to their type, the types of messages including alarm messages;
second means for processing said messages, said second means being arranged to receive said messages after processing by the first message 5 processing means, said second message processing being arranged to process said messages in accordance with a second set of rules, said second set of rules including rules for operating an alarm message; and means for permitting a user of the apparatus to establish and modify rules which are used by the second processing means while the apparatus is in use 10 receiving messages.
By providing first means for processing said messages in accordance with a set of rules which are established before the apparatus is in use, the messages can be subjected to basic operations including identification according to their type without involvement by the user, and by providing a second means for processing 15 the messages in dl.c~lddllce with rules which are established or modified by the user, the user is provided with the opportunity, while the apparatus is in use, to make the apparatus process the messages, including alarm messages, in ac~,."dance with rules which meet the user's requirements.
According to a second aspect of this invention, there is provided a method 20 of operating an apparatus for managing a telecommunications network, said apparatus Col ~ y .
means for receiving messages relating to the operation of elements of the telecommunications network;
first means for processing said messages; and second means for processing said messages, said second means being arranged to receive said messages after processing by said first message processing means;
said method comprising the steps of:
supplying a first set of rules for processing messages to said first 30 processing means before said apparatus is in use receiving messages, said first set of rules includes rules for identifying messages according to their type, the types of messages including alarm messages; and AMENuED SHEET
2n~'08/96 14:31 ~.\, \ ~\24832.doc b~ g and modifying a second set of rules for processing messages while said apparatus is in use receiving messages, said second set of rules being supplied to said second message processing means, said second set of rules including rules for operating an alarm messages;
This invention will now be described in more detail, by way of example, with reference to the drawings in which:
Figure 1 is a block diagram of some of the cur~,uo,~"~ of a telecommunications network, a network manager and service managers for managing the network;
Figure 2 is a block diagram of some of the components of the network manager;
Figure 3 is a block diagram of the components of a message processor which embodies this invention and forms part of the network manager of Figure 2;Figure 4 is a llitlldlullical tree of the identification and parsing rules which15 are applied by the message processor to messages received by the network manager;
Figure 5 shows an alternative configuration of some of the cu,,,~ù,~,,L:, of the network manager; and Figure 6 shows another alternative ~"~I"~",el~l of some of the 20 I.Olll,OUll~ of the network manager.
Referring now to Figure 1, there is shown a telecommunications network 10 which may be, for example, a local area network or a wide area network, or a telecommunications network belonging to a public telecommunications company which is used to provide public and/or private telecommunications services.
The telecommunications network 10 is formed from individual network elements, some of which are indicated by reference numerals 12, 14 and 16.
Multiplexers, switches, bridges and gateways are examples of such elements.
Some of the network elements are managed by element managers. The element managers for network elements 12 and 14 are indicated, respectively, by reference 30 numerals 18, 20.
The telecommunications network 10 is managed by a network manager 30 and three service managers 32, 34 and 36. Element managers and some individual network elements, for example element managers 18, 20 and network element 16, rD SHEEr '2~1/06196 ~4:31 ~ 24832.dOC
~ q237~ '' of the telecommunications network 10 send messages to the network manager 30 over a telecommunications link 38, which may be, for example, an X.25 communications link. The messages relate to the operation of the individual elements of the network. The network manager 30 uses the messages to monitor 5 the operating state of the network 10. The network manager 30 sends messages to the service managers 32, 34 and 36. The messages sent to each of the service managers 32, 34, 36 relate to the operation of the elements of the network 10 which are relevant to the service provided by the service manager. These messages are lldll:,llliL~dd over a communications link 40. The network manager 10 30 also sends messages relating to the operation of the elements of the network to other equipment, for example a facsimile machine 42 and a pager 44.
Each of the service managers 32, 34 and 36 manages a particular service.
For example, in the case of a telecommunications network belonging to a public telecommunications company, the service manager 32 may manage voice 15 communications over private circuits and the service manager 34 may manage the provision of data channels in private circuits. Although Figure 1 shows, by way of illustration, only three service managers, in general, a service manager may be provided for each individual service provided by a telecommunications network.
The service managers 32, 34 and 36 send messages over the telecommunications 20 link 40 to network manager 30 relating to services required by customers of the network 10. The network manager 30 sends messages over the communications link 38 to the network 10 to configure the network 10 to meet the customers requirements.
Each of the service managers 32, 34 and 36 and the network manager 30 25 is an example of apparatus for managing the network 10.
Each of the network manager 30 and service managers 32, 34, 36 has a database for storing details of the elements of the network 10. These details are stored in what is known as an object-oriented environment. In a database which operates in an object-oriented environment, details of the parameters of each reai 30 world object, for example a network element, are stored in a data structure known as a software object. Thus, in the databases of the network and service managers, each software object models a particular real world object in the form of a network element. Data on network elements may be LlGII:>IIIjLLdd according to h;`~ L ~ J~
'231106/96 14:31 ~ ' '\74832.doc 21 9~31~ `
various protocols. In the present example, the data is Ll c~ iLL~ using the Common Management Information Services ~CMIS). In the present example, three types of CMIS messages are used and these are m SET, m EVENTREPORT and m_GET. An m_SET message is used to request a database to set the value of a 5 particular parameter of a particular object to a particular value. An m GET
message is used to request a database to provide the value of a particular parameter of a particu~ar object. An m EVENTREPORT message is used to provide a notification of a particular event. Examples of such events are the change in the value of a particular attribute of a particular network element or an alarm.
The general construction of network managers and service managers is known to those skilled in the art. A network manager or a service manager takes the form of a computer provided with d,u~JIu,oli~L~ software. A software packagefor a network manager or a service manager may be obtained from a supplier and then configured to meet the needs of the user of the network manager or service 15 manager. An example of such a software package is the one known as NetExpert available from Object Systems Integrators Inc. Some of the components of the network manager 30 will now be described with reference to Figure 2.
Referring now to Figure 2, the network manager 30 includes a communications stack 50 for receiving CMIS messages from, and sending CMIS
20 messages to, the telecommunications network 10, a message processor 52, a configuration manager 54 and a fault manager 56, a network database 58, a communications stack 60 for sending CMIS messages to, and receiving CMIS
from, the service mana~qers 32, 34 and 36, and a communications stack 62 for sending messages to other equipment such as the facsimile machine 42 or the 25 pager 44.
The communications stack 50 is ,t~ ,ol1:,ible for handling CMIS messages and for converting these messages between a form for L~ siul~ along communications link 38 and a form which is suitable for use with the network manager 30. A suitable software package for handling CMIS messages is available 30 from British Telecommunications plc and a suitable software package for converting the messages into and out of a form suitable for Ll~llal~ iull on communications link 38 is available from Retix Corporation of Sainta Monica, California, USA. The communications stack 60 is similar to the communications AMEI~DED SHEET
~106196 1.4:31 ~ 24832.doc 2 ~ 923 7 1 stack 50. The communications stack 62 takes a form which is cl ,u~u~olicl~ for the equipment to which it sends messages.
The message processor 52 is arranged to process the messages received from the network 10. The message processor 52 embodies this invention and will 5 be described in more detail below.
The network database 58 stores a model of the configuration of the network 10 including details of the operational state of each network element.
The network database 58 in the present example takes the form of the well known Oracle Database.
The configuration manager 54 is responsible for modifying parameter values stored in network database 58 in d-,-,ulddll(.e with m_SET and m_ EVENTREPORT messages from the network 10 and also servicing m_ GET
requests, The configuration manager 54 is also ~,UuI~aibld for instructing configuration chang;ds of the network 10 in response to requests from the service 15 managers 32, 34 and 36.
The fault manager 56 is responsible for processing alarm messages from the network 10 and for diagnosing the underlying faults which give rise to thesemessages.
Thus, the configuration manager 54 and the fault manager 56 are each 20 l~auullaible for managing i"rur"lc~iu~ received by the network manager 30 and so each of these is also an information manager.
Referring now to Figure 3, there are shown the uu~ uollellLa of the message processor 52. These comprise a store 70, a first message processing component 72, a second message procassing component 74, a database 76 for 25 storing a first set and a second set of rules which are used, respectively, in the first and the second message processing components, a data loader 78 for the database 76, a user interface 80 and a set of prototype rules 82 which are made available to the user interface 80.
The store 70 receives messages from the communications stack 50 and 30 stores the messages in a queue. Each message is stored in the store 70 with an identification tag. The store 70 suppliea- a copy of each message in turn to thefirst mesâage processing c,û""ùulle"~ 72 while retaining the original massage in the queue.
A,~1ENOED SH~Er ~2!JI06196 14:31 ~ J;24832.doc 219~37~
In the first message processing component 72, each message is identified to determine what type of message it is and then it is parsed to extract the relevant information from it. The i Idll~iril.d~iull and parsing is performed ina~.culddllcd with a set of predefined rules which are loaded into the first message 5 processing component 72 before the network manager 30 is in use receiving messages. The set of predefined rules is the first set of rules mentioned above.These predefined rules cannot be changed by the user while the network manager is in use receiving messages from the network 10.
The predefined rules for identifying messages according to their type and 10 parsing the infarmation from them are illustrated in Figure 4. Each message, in the present example, is either an m SET, m_EVENTREPORT or m_GET message. In the ide"Liric,,~ion stage, each message is identified as belonging to one of these three types.
If the message is an m_ SET message, it is parsed to determine the 15 identifier for the object, the name of the attribute of the object and the new value of that attribute contained within the message. Similarly, if it is an m_ GET
message, it is parsed to determine the identifier of the object and name of the attribute whose value is required.
If a message is an m_ EVENTREPORT message, a further stage of 20 ide"~iri-,~,Liul, is performed to determine the type of event which is being reported.
In the present example, each event is either a change in an attribute value, an alarm or an instruction to enrol a new object. If the event is a change in attribute value, the message is parsed to determine the identifier of the object, the name of the attribute and the new value. If the event is a request to enrol a new object, 25 the message is parsed to determine the identifier for that object and the values of its attributes.
If the message is an alarm, the message is parsed to determine the severity of the alarm, the type of the alarm and the type of problem to which the alarm relates. For example, the type of alarm may be a lldllSIll;D~;oll alarm and, 30 where the type of alarm is a ~Id~ iUII alarm, the type of problem may be a framing error.
In the second message processing component 74, the illru""l,Liul. of each message received from the first message processing ~.u""ucn~,lt 72 is processed in FD S~E~
,2~,/06/9d 14:31 u.\, ~ 4832.doc 21 9237~
~,COI dc~ I..e with a set of rules~ This set of rules is the second set of rulesmentioned above~ This set of rules can be established and modified by the user of the network manager 30 while the network manager 30 is in use receiving messages from the network 10. If the user does not establish any rules, then the5 second message processing component 74 processes the information of each message in accordance with a set of default rules~
As will be explained in more detail below, each rule e~cLl;~l,ed by the user is derived from a set of prototype rules. Six exemplary prototype rules are set out in Table 1 below~
~hL~
1~ For alarm from (object) if duplicate alarm received within (interval) then discard duplicate alarm~
2. For alarm from (object1 if clear received within (interval) then discard alarm~
This invention relates to an apparatus for managing a telecommunicatjons network and also to a method of operating such an apparatus.
Such an apparatus receives messages relating to the operation of elements of the telecommunications network which it is managing. It is desirable to process such messages in an a,uplu,ùlia~ manner before passing them on to other uulll,uol1~llL:, of the apparatus.
Apparatuses for managing telecommunications networks are discussed in 10 the following two articles.
1. INTERNATIONAL SWITCHING SYMPOSIUM 1992 Session C1, Paper 2 vol. 1, 25 October 1992 YOKOHAMA JP
pages 65 - 69, XP 000337618 SEVCIK, 'Adaptable TMN: A new dimension in practical network management 2. GLOBECOM'92 vol. 1, 6 December 1992 ORLANDO US
pages 560 564, XP 000357845 LIN ET AL. 'A framework for learning and inference in network ",a,~ag~ "L' The first of these articles focuses on Q3 interfaces, User Interfaces and application structures. The second article describes the use of an expert system in 25 network Illallàldalllal,L apparatus.
According to this invention, there is provided an apparatus for managing a telecommunications network including:
means for receiving messages relating to the operation of elements of the telecommunications network;
first means for processing said messages, said first means being arranged to process said messages in accordance with a first set of rules which are e~LdLl;~lled before the apparatus is in use receiving messages, said first set of A~IENDED SHEET
106196 14:31 _ ~, ` '\24832.d~c 21 92371 ` `
rules including rules for identifying messages according to their type, the types of messages including alarm messages;
second means for processing said messages, said second means being arranged to receive said messages after processing by the first message 5 processing means, said second message processing being arranged to process said messages in accordance with a second set of rules, said second set of rules including rules for operating an alarm message; and means for permitting a user of the apparatus to establish and modify rules which are used by the second processing means while the apparatus is in use 10 receiving messages.
By providing first means for processing said messages in accordance with a set of rules which are established before the apparatus is in use, the messages can be subjected to basic operations including identification according to their type without involvement by the user, and by providing a second means for processing 15 the messages in dl.c~lddllce with rules which are established or modified by the user, the user is provided with the opportunity, while the apparatus is in use, to make the apparatus process the messages, including alarm messages, in ac~,."dance with rules which meet the user's requirements.
According to a second aspect of this invention, there is provided a method 20 of operating an apparatus for managing a telecommunications network, said apparatus Col ~ y .
means for receiving messages relating to the operation of elements of the telecommunications network;
first means for processing said messages; and second means for processing said messages, said second means being arranged to receive said messages after processing by said first message processing means;
said method comprising the steps of:
supplying a first set of rules for processing messages to said first 30 processing means before said apparatus is in use receiving messages, said first set of rules includes rules for identifying messages according to their type, the types of messages including alarm messages; and AMENuED SHEET
2n~'08/96 14:31 ~.\, \ ~\24832.doc b~ g and modifying a second set of rules for processing messages while said apparatus is in use receiving messages, said second set of rules being supplied to said second message processing means, said second set of rules including rules for operating an alarm messages;
This invention will now be described in more detail, by way of example, with reference to the drawings in which:
Figure 1 is a block diagram of some of the cur~,uo,~"~ of a telecommunications network, a network manager and service managers for managing the network;
Figure 2 is a block diagram of some of the components of the network manager;
Figure 3 is a block diagram of the components of a message processor which embodies this invention and forms part of the network manager of Figure 2;Figure 4 is a llitlldlullical tree of the identification and parsing rules which15 are applied by the message processor to messages received by the network manager;
Figure 5 shows an alternative configuration of some of the cu,,,~ù,~,,L:, of the network manager; and Figure 6 shows another alternative ~"~I"~",el~l of some of the 20 I.Olll,OUll~ of the network manager.
Referring now to Figure 1, there is shown a telecommunications network 10 which may be, for example, a local area network or a wide area network, or a telecommunications network belonging to a public telecommunications company which is used to provide public and/or private telecommunications services.
The telecommunications network 10 is formed from individual network elements, some of which are indicated by reference numerals 12, 14 and 16.
Multiplexers, switches, bridges and gateways are examples of such elements.
Some of the network elements are managed by element managers. The element managers for network elements 12 and 14 are indicated, respectively, by reference 30 numerals 18, 20.
The telecommunications network 10 is managed by a network manager 30 and three service managers 32, 34 and 36. Element managers and some individual network elements, for example element managers 18, 20 and network element 16, rD SHEEr '2~1/06196 ~4:31 ~ 24832.dOC
~ q237~ '' of the telecommunications network 10 send messages to the network manager 30 over a telecommunications link 38, which may be, for example, an X.25 communications link. The messages relate to the operation of the individual elements of the network. The network manager 30 uses the messages to monitor 5 the operating state of the network 10. The network manager 30 sends messages to the service managers 32, 34 and 36. The messages sent to each of the service managers 32, 34, 36 relate to the operation of the elements of the network 10 which are relevant to the service provided by the service manager. These messages are lldll:,llliL~dd over a communications link 40. The network manager 10 30 also sends messages relating to the operation of the elements of the network to other equipment, for example a facsimile machine 42 and a pager 44.
Each of the service managers 32, 34 and 36 manages a particular service.
For example, in the case of a telecommunications network belonging to a public telecommunications company, the service manager 32 may manage voice 15 communications over private circuits and the service manager 34 may manage the provision of data channels in private circuits. Although Figure 1 shows, by way of illustration, only three service managers, in general, a service manager may be provided for each individual service provided by a telecommunications network.
The service managers 32, 34 and 36 send messages over the telecommunications 20 link 40 to network manager 30 relating to services required by customers of the network 10. The network manager 30 sends messages over the communications link 38 to the network 10 to configure the network 10 to meet the customers requirements.
Each of the service managers 32, 34 and 36 and the network manager 30 25 is an example of apparatus for managing the network 10.
Each of the network manager 30 and service managers 32, 34, 36 has a database for storing details of the elements of the network 10. These details are stored in what is known as an object-oriented environment. In a database which operates in an object-oriented environment, details of the parameters of each reai 30 world object, for example a network element, are stored in a data structure known as a software object. Thus, in the databases of the network and service managers, each software object models a particular real world object in the form of a network element. Data on network elements may be LlGII:>IIIjLLdd according to h;`~ L ~ J~
'231106/96 14:31 ~ ' '\74832.doc 21 9~31~ `
various protocols. In the present example, the data is Ll c~ iLL~ using the Common Management Information Services ~CMIS). In the present example, three types of CMIS messages are used and these are m SET, m EVENTREPORT and m_GET. An m_SET message is used to request a database to set the value of a 5 particular parameter of a particular object to a particular value. An m GET
message is used to request a database to provide the value of a particular parameter of a particu~ar object. An m EVENTREPORT message is used to provide a notification of a particular event. Examples of such events are the change in the value of a particular attribute of a particular network element or an alarm.
The general construction of network managers and service managers is known to those skilled in the art. A network manager or a service manager takes the form of a computer provided with d,u~JIu,oli~L~ software. A software packagefor a network manager or a service manager may be obtained from a supplier and then configured to meet the needs of the user of the network manager or service 15 manager. An example of such a software package is the one known as NetExpert available from Object Systems Integrators Inc. Some of the components of the network manager 30 will now be described with reference to Figure 2.
Referring now to Figure 2, the network manager 30 includes a communications stack 50 for receiving CMIS messages from, and sending CMIS
20 messages to, the telecommunications network 10, a message processor 52, a configuration manager 54 and a fault manager 56, a network database 58, a communications stack 60 for sending CMIS messages to, and receiving CMIS
from, the service mana~qers 32, 34 and 36, and a communications stack 62 for sending messages to other equipment such as the facsimile machine 42 or the 25 pager 44.
The communications stack 50 is ,t~ ,ol1:,ible for handling CMIS messages and for converting these messages between a form for L~ siul~ along communications link 38 and a form which is suitable for use with the network manager 30. A suitable software package for handling CMIS messages is available 30 from British Telecommunications plc and a suitable software package for converting the messages into and out of a form suitable for Ll~llal~ iull on communications link 38 is available from Retix Corporation of Sainta Monica, California, USA. The communications stack 60 is similar to the communications AMEI~DED SHEET
~106196 1.4:31 ~ 24832.doc 2 ~ 923 7 1 stack 50. The communications stack 62 takes a form which is cl ,u~u~olicl~ for the equipment to which it sends messages.
The message processor 52 is arranged to process the messages received from the network 10. The message processor 52 embodies this invention and will 5 be described in more detail below.
The network database 58 stores a model of the configuration of the network 10 including details of the operational state of each network element.
The network database 58 in the present example takes the form of the well known Oracle Database.
The configuration manager 54 is responsible for modifying parameter values stored in network database 58 in d-,-,ulddll(.e with m_SET and m_ EVENTREPORT messages from the network 10 and also servicing m_ GET
requests, The configuration manager 54 is also ~,UuI~aibld for instructing configuration chang;ds of the network 10 in response to requests from the service 15 managers 32, 34 and 36.
The fault manager 56 is responsible for processing alarm messages from the network 10 and for diagnosing the underlying faults which give rise to thesemessages.
Thus, the configuration manager 54 and the fault manager 56 are each 20 l~auullaible for managing i"rur"lc~iu~ received by the network manager 30 and so each of these is also an information manager.
Referring now to Figure 3, there are shown the uu~ uollellLa of the message processor 52. These comprise a store 70, a first message processing component 72, a second message procassing component 74, a database 76 for 25 storing a first set and a second set of rules which are used, respectively, in the first and the second message processing components, a data loader 78 for the database 76, a user interface 80 and a set of prototype rules 82 which are made available to the user interface 80.
The store 70 receives messages from the communications stack 50 and 30 stores the messages in a queue. Each message is stored in the store 70 with an identification tag. The store 70 suppliea- a copy of each message in turn to thefirst mesâage processing c,û""ùulle"~ 72 while retaining the original massage in the queue.
A,~1ENOED SH~Er ~2!JI06196 14:31 ~ J;24832.doc 219~37~
In the first message processing component 72, each message is identified to determine what type of message it is and then it is parsed to extract the relevant information from it. The i Idll~iril.d~iull and parsing is performed ina~.culddllcd with a set of predefined rules which are loaded into the first message 5 processing component 72 before the network manager 30 is in use receiving messages. The set of predefined rules is the first set of rules mentioned above.These predefined rules cannot be changed by the user while the network manager is in use receiving messages from the network 10.
The predefined rules for identifying messages according to their type and 10 parsing the infarmation from them are illustrated in Figure 4. Each message, in the present example, is either an m SET, m_EVENTREPORT or m_GET message. In the ide"Liric,,~ion stage, each message is identified as belonging to one of these three types.
If the message is an m_ SET message, it is parsed to determine the 15 identifier for the object, the name of the attribute of the object and the new value of that attribute contained within the message. Similarly, if it is an m_ GET
message, it is parsed to determine the identifier of the object and name of the attribute whose value is required.
If a message is an m_ EVENTREPORT message, a further stage of 20 ide"~iri-,~,Liul, is performed to determine the type of event which is being reported.
In the present example, each event is either a change in an attribute value, an alarm or an instruction to enrol a new object. If the event is a change in attribute value, the message is parsed to determine the identifier of the object, the name of the attribute and the new value. If the event is a request to enrol a new object, 25 the message is parsed to determine the identifier for that object and the values of its attributes.
If the message is an alarm, the message is parsed to determine the severity of the alarm, the type of the alarm and the type of problem to which the alarm relates. For example, the type of alarm may be a lldllSIll;D~;oll alarm and, 30 where the type of alarm is a ~Id~ iUII alarm, the type of problem may be a framing error.
In the second message processing component 74, the illru""l,Liul. of each message received from the first message processing ~.u""ucn~,lt 72 is processed in FD S~E~
,2~,/06/9d 14:31 u.\, ~ 4832.doc 21 9237~
~,COI dc~ I..e with a set of rules~ This set of rules is the second set of rulesmentioned above~ This set of rules can be established and modified by the user of the network manager 30 while the network manager 30 is in use receiving messages from the network 10. If the user does not establish any rules, then the5 second message processing component 74 processes the information of each message in accordance with a set of default rules~
As will be explained in more detail below, each rule e~cLl;~l,ed by the user is derived from a set of prototype rules. Six exemplary prototype rules are set out in Table 1 below~
~hL~
1~ For alarm from (object) if duplicate alarm received within (interval) then discard duplicate alarm~
2. For alarm from (object1 if clear received within (interval) then discard alarm~
3~ For alarm from (object) if alarm severity is (severity) and alarm type is (alarm type) and problem type is (problem type) then (action).
4, For alarm from (object) if alarm severity is (severity) and alarm type is (alarm type) and problem type is (problem type) then copy alarm to (destination) .
5. If (number) of alarms received within one hour, issue a warnin3 to (destination) .
6. If message type is (mcssage type) then send message to (destination)~
In the first two exemplary prototype rules set out above, the user specifies the network element or object from which the alarm is received and also the timeinterval. When a user has e~c,Ll;~ed an actual rule using the first prototype rule 30 of Table 1, where a second alarm is received from the specified object within the specified time interval, the second or duplicate alarm is discarded. In order toachieve this, the second message processing component 74 instructs the store 70 to discard the alarm~ Thus, rules which follow the first prototype rule correlate ';~ ''`;~D S
iD:1106/96 14:31, \, '. ~24832.doc 2~ 9237tj duplicate alarms and one of the functions of the second message processing Cù~ Jull~llL 74 is to correlate alarms. Where a user has established a rule following the second prototype rules set out above, if an alarm from a specifiedobject is followed by a clear for that alarm for that object within a specified time 5 interval, then the original alarm is discarded.
When d:~dLI;sllillU a rule which follows the third prototype rule above, the user specifies the network element or object, the severity of the alarm, the type of alarm and type of problem and the action which is to be taken. The action might be to increment a counter until it reaches a threshold and then to issue a warning 10 to the fault manager 56. Thus, when such a rule is in use, each time an alarm is received from the specified object having the specified severity, alarm type andproblem type, the counter is il~ dlllcd until it reaches its threshold and then a warning is issued to the fault manager 56.
When establishing a rule which follows the fourth prototype rule as set out 15 above, the user specifies the network element or object, the alarm severity, alarm type and problem type as well as the destination. The destination might be, for example, pager 44. Then, when such a rule is in use and an alarm is received from the specified object having the specified alarm type and problem type, the second message processing uon~pu~ 74 instructs the store 70 to copy the alarm to the 20 pager 44. The store 70 would also be instructed to discard the alarm.
When following the fifth prototype rule set out above, the user specifies the number of alarms and the destination for the warning. Then, when such a ruleis in use, if the specified number of alarms are received within one hour, a warning is issued to the de~i,,c,Lio,, which might be, for example, the fault manager 56.
When ebLc,L';Jlli,,u, a rule which follows the sixth prototype rule set out above, the user specifies the message type and also the destination. The de~Li,,c,~io,~ might be the service manager 32. Then, when such a rule is in use, if a message of the specified type is received, the second message processing uu"lpollel~ 74 instructs the store 70 to send it to the servicd manager 32.
The store 70 is ~u5~d~ led to discard each alarm after a preset period if it has not been discarded before this time.
~1106l96 14:31 u.~ \74892.doc 2' 9237~ .:
~o As indicated in Figure 3, output messages from the other ColllpOIlall~:, of the network manager 30 can be transmitted to the network 10 from the communication stack 50.
The predefined rules are illustrated by block 84 in Figure 3. Before the 5 network manager 52 is in use, these predefined rules 84 are loaded by the dataloader 78 into the database 76. From the database 76, they are loaded into the first message processing component 72 when the network manager 30 is being initialised immediately before use. There is no facility for the user to change the rules while the network manager 30 is in use.
When the network manager 30 is in use, the prototype rules 82 can be retrieved by the user interface 80 and presented to the user for dsLcb,;~llilly new rules. Each new rule can then be loaded by the data loader 78 into the database 76 where it is stored. The rule is also loaded by the database 76 into the second message processing component 74. If the network manager 30 is subsequently 15 shut down, the rules in the database 76 for use in the second message processing ,,u",po,1~"~ 74 are loaded into the second message processing component when the network manager is initialised before being used again. The user is also able to retrieve a rule belonging to the second set of rules from the database 76 and tomodify it. The modified rule is then returned to the database 76 and also to the20 second message processing ~,u"~,uune"~ 74.
The alla~ ldll~ of the message processor 52 shown in Figure 3 is suitable for an àllallyclllt~ where messages are received from a telecommunications network in only one protocol, in the present example CMIS.
However, modification is required where messages are received in more than one 25 protocol as each protocol requires its own set of rules for identifying and parsing messages. Referring now to Figure 5, there is shown a mûdification to the message processor 52 which is suitable for receiving messages in two protocols.
The arrangement of Figure 5 includes the communications stack 50 for receiving CMIS messages, the store 70, first message processing component 72 30 and the second message processing cul~u.al~ellL 74. Although not shown, there is also provided the database 76, data loader 78 and user interface 80. The al,al~9c:llldllt of Figure 5 also includes a communications stack 90 for receiving message in the Simple Network Management Protocol (SNMP). The messages AM~I~'DED SH~ET
06196 l4:31 u.~ 24a3~ c 21 ~371 1, from the communications stack 90 are passed to a store 92 which supplies copies of the messages to a first message processing component 94. The first message processing component 94 is generally similar to the first message processing pO~ L 72 and receives a set of rules for identifying and parsing the messages 5 from the database 76. However, this set of rules is d~ ll),lJlidLd for SNMP
messages. After identifying and parsing each message, the first message processing component 94 passes it to the second message processing component 74.
Referring now to Figure 6, there is shown a modification to the network 10 manager 52 in which there are provided three message processors 100, 102, 104, each of which is generally sirrlilar to the message processor 52 and which are arranged in a cascaded manner. The dl~d,l~d",e"L shown in Figure 6 includes the communications stack 50 for receiving CMIS messages and also the configuration manager 54 and the fault manager 56. There is also included a communications 15 stack 106 for receiving SNMP messages.
The three message processors 100, 102 and 104 can conveniently have a shared database containing their sets of rules which receives the rules in turn from a common data loader. The communication stack 50 passes messages to the message processor 100 and some of the messages from the message processor 20 100 are sent to configuration manager 54 and some to the message processor 104. The communications stack 106 supplies messages to the message processor 102 and messages from the message processor 102 are all supplied to the message processor 104. The message processor 104 sends messa~qes to bath the configuration manager 54 and the fault manager 56 and also to external equipment25 such as the pager 44.
Each of the service managers 32, 34, 36 may be provided with a message processor which is generally similar to the message processor 52 but which is provided with rules which are djJIIl ,UlidLC to the service manager.
AME~ ED SHEE~
In the first two exemplary prototype rules set out above, the user specifies the network element or object from which the alarm is received and also the timeinterval. When a user has e~c,Ll;~ed an actual rule using the first prototype rule 30 of Table 1, where a second alarm is received from the specified object within the specified time interval, the second or duplicate alarm is discarded. In order toachieve this, the second message processing component 74 instructs the store 70 to discard the alarm~ Thus, rules which follow the first prototype rule correlate ';~ ''`;~D S
iD:1106/96 14:31, \, '. ~24832.doc 2~ 9237tj duplicate alarms and one of the functions of the second message processing Cù~ Jull~llL 74 is to correlate alarms. Where a user has established a rule following the second prototype rules set out above, if an alarm from a specifiedobject is followed by a clear for that alarm for that object within a specified time 5 interval, then the original alarm is discarded.
When d:~dLI;sllillU a rule which follows the third prototype rule above, the user specifies the network element or object, the severity of the alarm, the type of alarm and type of problem and the action which is to be taken. The action might be to increment a counter until it reaches a threshold and then to issue a warning 10 to the fault manager 56. Thus, when such a rule is in use, each time an alarm is received from the specified object having the specified severity, alarm type andproblem type, the counter is il~ dlllcd until it reaches its threshold and then a warning is issued to the fault manager 56.
When establishing a rule which follows the fourth prototype rule as set out 15 above, the user specifies the network element or object, the alarm severity, alarm type and problem type as well as the destination. The destination might be, for example, pager 44. Then, when such a rule is in use and an alarm is received from the specified object having the specified alarm type and problem type, the second message processing uon~pu~ 74 instructs the store 70 to copy the alarm to the 20 pager 44. The store 70 would also be instructed to discard the alarm.
When following the fifth prototype rule set out above, the user specifies the number of alarms and the destination for the warning. Then, when such a ruleis in use, if the specified number of alarms are received within one hour, a warning is issued to the de~i,,c,Lio,, which might be, for example, the fault manager 56.
When ebLc,L';Jlli,,u, a rule which follows the sixth prototype rule set out above, the user specifies the message type and also the destination. The de~Li,,c,~io,~ might be the service manager 32. Then, when such a rule is in use, if a message of the specified type is received, the second message processing uu"lpollel~ 74 instructs the store 70 to send it to the servicd manager 32.
The store 70 is ~u5~d~ led to discard each alarm after a preset period if it has not been discarded before this time.
~1106l96 14:31 u.~ \74892.doc 2' 9237~ .:
~o As indicated in Figure 3, output messages from the other ColllpOIlall~:, of the network manager 30 can be transmitted to the network 10 from the communication stack 50.
The predefined rules are illustrated by block 84 in Figure 3. Before the 5 network manager 52 is in use, these predefined rules 84 are loaded by the dataloader 78 into the database 76. From the database 76, they are loaded into the first message processing component 72 when the network manager 30 is being initialised immediately before use. There is no facility for the user to change the rules while the network manager 30 is in use.
When the network manager 30 is in use, the prototype rules 82 can be retrieved by the user interface 80 and presented to the user for dsLcb,;~llilly new rules. Each new rule can then be loaded by the data loader 78 into the database 76 where it is stored. The rule is also loaded by the database 76 into the second message processing component 74. If the network manager 30 is subsequently 15 shut down, the rules in the database 76 for use in the second message processing ,,u",po,1~"~ 74 are loaded into the second message processing component when the network manager is initialised before being used again. The user is also able to retrieve a rule belonging to the second set of rules from the database 76 and tomodify it. The modified rule is then returned to the database 76 and also to the20 second message processing ~,u"~,uune"~ 74.
The alla~ ldll~ of the message processor 52 shown in Figure 3 is suitable for an àllallyclllt~ where messages are received from a telecommunications network in only one protocol, in the present example CMIS.
However, modification is required where messages are received in more than one 25 protocol as each protocol requires its own set of rules for identifying and parsing messages. Referring now to Figure 5, there is shown a mûdification to the message processor 52 which is suitable for receiving messages in two protocols.
The arrangement of Figure 5 includes the communications stack 50 for receiving CMIS messages, the store 70, first message processing component 72 30 and the second message processing cul~u.al~ellL 74. Although not shown, there is also provided the database 76, data loader 78 and user interface 80. The al,al~9c:llldllt of Figure 5 also includes a communications stack 90 for receiving message in the Simple Network Management Protocol (SNMP). The messages AM~I~'DED SH~ET
06196 l4:31 u.~ 24a3~ c 21 ~371 1, from the communications stack 90 are passed to a store 92 which supplies copies of the messages to a first message processing component 94. The first message processing component 94 is generally similar to the first message processing pO~ L 72 and receives a set of rules for identifying and parsing the messages 5 from the database 76. However, this set of rules is d~ ll),lJlidLd for SNMP
messages. After identifying and parsing each message, the first message processing component 94 passes it to the second message processing component 74.
Referring now to Figure 6, there is shown a modification to the network 10 manager 52 in which there are provided three message processors 100, 102, 104, each of which is generally sirrlilar to the message processor 52 and which are arranged in a cascaded manner. The dl~d,l~d",e"L shown in Figure 6 includes the communications stack 50 for receiving CMIS messages and also the configuration manager 54 and the fault manager 56. There is also included a communications 15 stack 106 for receiving SNMP messages.
The three message processors 100, 102 and 104 can conveniently have a shared database containing their sets of rules which receives the rules in turn from a common data loader. The communication stack 50 passes messages to the message processor 100 and some of the messages from the message processor 20 100 are sent to configuration manager 54 and some to the message processor 104. The communications stack 106 supplies messages to the message processor 102 and messages from the message processor 102 are all supplied to the message processor 104. The message processor 104 sends messa~qes to bath the configuration manager 54 and the fault manager 56 and also to external equipment25 such as the pager 44.
Each of the service managers 32, 34, 36 may be provided with a message processor which is generally similar to the message processor 52 but which is provided with rules which are djJIIl ,UlidLC to the service manager.
AME~ ED SHEE~
Claims (9)
1. An apparatus for managing a telecommunications network including:
means for receiving messages relating to the operation of elements of the telecommunications network;
first means for processing said messages, said first means being arranged to process said messages in accordance with a first set of rules which are established before the apparatus is in use receiving messages, said first set ofrules including rules for identifying messages according to their type, the types of messages including alarm messages;
second means for processing said messages, said second means being arranged to receive said messages after processing by the first message processing means, said second message processing being arranged to process said messages in accordance with a second set of rules, said second set of rules including rules for operating an alarm message; and means for permitting a user of the apparatus to establish and modify rules which are used by the second processing means while the apparatus is in use receiving messages.
means for receiving messages relating to the operation of elements of the telecommunications network;
first means for processing said messages, said first means being arranged to process said messages in accordance with a first set of rules which are established before the apparatus is in use receiving messages, said first set ofrules including rules for identifying messages according to their type, the types of messages including alarm messages;
second means for processing said messages, said second means being arranged to receive said messages after processing by the first message processing means, said second message processing being arranged to process said messages in accordance with a second set of rules, said second set of rules including rules for operating an alarm message; and means for permitting a user of the apparatus to establish and modify rules which are used by the second processing means while the apparatus is in use receiving messages.
2. An apparatus as claimed in claim 1, in which said second set of rules includes rules for correlating alarm messages.
3. An apparatus as claimed in claim 1 or claim 2, further including:
at least one means for managing information relating to the telecommunications network; and means for sending messages to equipment which is external to said apparatus;
said second message processing means being arranged to forward said messages, on a selective basis, to said at least one means for managing information and equipment which is external to said apparatus.
at least one means for managing information relating to the telecommunications network; and means for sending messages to equipment which is external to said apparatus;
said second message processing means being arranged to forward said messages, on a selective basis, to said at least one means for managing information and equipment which is external to said apparatus.
4. An apparatus as claimed in claim 3, in which said second message processing means is arranged to generate new messages and to transmit new messages to said at least one means for managing information and to equipment which is external to said apparatus.
5. An apparatus as claimed in any one of the preceding claims, further including a store for storing messages received from said message receiving means, said store being arranged to supply received messages to said first message processing means.
6. An apparatus as claimed in claim 5, in which said store is arranged to store each message while a copy of it is processed by said first and second message processing means, said second processing means being arranged to instruct the store to forward and discard messages.
7. An apparatus as claimed in any one of the preceding claims, further including:
a database for storing said first set of rules and said second set of rules, said database being arranged to load said first set of rules into said first message processing means and said second set of rules into said second message processing means, a set of prototype rules for said second set of rules, a user interface which has access to said set of prototype rules, and a data loader forloading rules from said user interface into said database, said data loader alsobeing arranged to load a set of predefined rules which form said first set of rules into said database before the apparatus is in use receiving messages, said set of prototype rules, said user interface, said data loader and said database providing said means for permitting a user of the apparatus to establish and modify the rules which are used by the second message processing means.
a database for storing said first set of rules and said second set of rules, said database being arranged to load said first set of rules into said first message processing means and said second set of rules into said second message processing means, a set of prototype rules for said second set of rules, a user interface which has access to said set of prototype rules, and a data loader forloading rules from said user interface into said database, said data loader alsobeing arranged to load a set of predefined rules which form said first set of rules into said database before the apparatus is in use receiving messages, said set of prototype rules, said user interface, said data loader and said database providing said means for permitting a user of the apparatus to establish and modify the rules which are used by the second message processing means.
8. A method of operating an apparatus for managing a telecommunications network, said apparatus comprising:
means for receiving messages relating to the operation of elements of the telecommunications network;
first means for processing said messages; and second means for processing said messages, said second means being arranged to receive said messages after processing by said first message processing means;
said method comprising the steps of:
supplying a first set of rules for processing messages to said first processing means before said apparatus is in use receiving messages, said first set of rules includes rules for identifying messages according to their type, the types of messages including alarm messages; and establishing and modifying a second set of rules for processing messages while said apparatus is in use receiving messages, said second set of rules being supplied to said second message processing means, said second set of rules including rules for operating an alarm messages;
means for receiving messages relating to the operation of elements of the telecommunications network;
first means for processing said messages; and second means for processing said messages, said second means being arranged to receive said messages after processing by said first message processing means;
said method comprising the steps of:
supplying a first set of rules for processing messages to said first processing means before said apparatus is in use receiving messages, said first set of rules includes rules for identifying messages according to their type, the types of messages including alarm messages; and establishing and modifying a second set of rules for processing messages while said apparatus is in use receiving messages, said second set of rules being supplied to said second message processing means, said second set of rules including rules for operating an alarm messages;
9. A method as claimed in claim 8, in which a set of prototype rules are provided for establishing individual ones of said second set of rules.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9415301.2 | 1994-07-29 | ||
| GB9415301A GB9415301D0 (en) | 1994-07-29 | 1994-07-29 | Apparatus for managing a telecommunications network |
| PCT/GB1995/001753 WO1996004755A1 (en) | 1994-07-29 | 1995-07-25 | Apparatus for managing a telecommunications network |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2192371A1 true CA2192371A1 (en) | 1996-02-15 |
Family
ID=10759063
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002192371A Abandoned CA2192371A1 (en) | 1994-07-29 | 1995-07-25 | Apparatus for managing a telecommunications network |
Country Status (6)
| Country | Link |
|---|---|
| EP (1) | EP0772942A1 (en) |
| JP (1) | JPH10503630A (en) |
| AU (1) | AU3083495A (en) |
| CA (1) | CA2192371A1 (en) |
| GB (1) | GB9415301D0 (en) |
| WO (1) | WO1996004755A1 (en) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI104032B (en) * | 1996-06-27 | 1999-10-29 | Ericsson Telefon Ab L M | Method for telecommunications network fault management and telecommunication system |
| US7107612B1 (en) * | 1999-04-01 | 2006-09-12 | Juniper Networks, Inc. | Method, apparatus and computer program product for a network firewall |
| GB2372667B (en) | 2001-02-21 | 2003-05-07 | 3Com Corp | Apparatus and method for providing improved stress thresholds in network management systems |
| GB2372673B (en) | 2001-02-27 | 2003-05-28 | 3Com Corp | Apparatus and method for processing data relating to events on a network |
| GB2372672B (en) | 2001-02-27 | 2003-04-30 | 3Com Corp | Network management apparatus and method for processing events associated with device reboot |
| GB2372671B (en) | 2001-02-27 | 2003-04-30 | 3Com Corp | Processing network events to reduce the number of events to be displayed |
| CN100438423C (en) * | 2002-08-06 | 2008-11-26 | 华为技术有限公司 | Telecommunication equipment fault information managing method |
-
1994
- 1994-07-29 GB GB9415301A patent/GB9415301D0/en active Pending
-
1995
- 1995-07-25 AU AU30834/95A patent/AU3083495A/en not_active Abandoned
- 1995-07-25 CA CA002192371A patent/CA2192371A1/en not_active Abandoned
- 1995-07-25 JP JP8506289A patent/JPH10503630A/en active Pending
- 1995-07-25 EP EP95926448A patent/EP0772942A1/en not_active Withdrawn
- 1995-07-25 WO PCT/GB1995/001753 patent/WO1996004755A1/en not_active Application Discontinuation
Also Published As
| Publication number | Publication date |
|---|---|
| GB9415301D0 (en) | 1994-09-21 |
| AU3083495A (en) | 1996-03-04 |
| WO1996004755A1 (en) | 1996-02-15 |
| EP0772942A1 (en) | 1997-05-14 |
| JPH10503630A (en) | 1998-03-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6484200B1 (en) | Distinguished name scoping system for event filtering | |
| US6070188A (en) | Telecommunications network management system | |
| US6603396B2 (en) | Method and apparatus for distributed object filtering | |
| DE10354906B4 (en) | Interactive two-way collaboration in process control systems | |
| US5822569A (en) | Data storage device | |
| DE69932567T2 (en) | Redundant call processing | |
| JPH0973423A (en) | Snmp/osi management gateway device | |
| CA2345117A1 (en) | Interface system for integrated monitoring and management of network devices in a telecommunications network | |
| EP0661891B1 (en) | An apparatus for managing an element manager for a telecommunications switch | |
| US6222827B1 (en) | Telecommunications network management system | |
| WO1995023469A1 (en) | A data storage device | |
| CA2192371A1 (en) | Apparatus for managing a telecommunications network | |
| US20020042847A1 (en) | Method for a network management system for processing event information, as well as management object, discriminator object and managed object for it | |
| CN1370373A (en) | Payphone management system | |
| US7047295B1 (en) | Generic alignment method in a multimanager environment | |
| CN112583622B (en) | Method and system for reporting fault event information | |
| DE60302042T2 (en) | Network maintenance | |
| Ueda et al. | Implementation of the TMN to a highly reliable distributed switching node | |
| US20020042848A1 (en) | Method of providing services in a network management system having an open system architecture and also a service object, a request object and a request manager therefor | |
| EP0963077A2 (en) | Node and link representation of network services | |
| CN101272270B (en) | Method and device for multiple network management systems sharing advanced alarm regulation | |
| CN101599860B (en) | Method for handling alerts by means of a management network comprising several levels in a communication system | |
| Sugarbroad | An OSI-based interoperability architecture for managing hybrid networks | |
| JP2002519874A (en) | Method and communication system for processing state information with a management network having multiple management levels | |
| GB2308780A (en) | Telecommunications network management |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |