WO1996004755A1 - Apparatus for managing a telecommunications network - Google Patents

Apparatus for managing a telecommunications network Download PDF

Info

Publication number
WO1996004755A1
WO1996004755A1 PCT/GB1995/001753 GB9501753W WO9604755A1 WO 1996004755 A1 WO1996004755 A1 WO 1996004755A1 GB 9501753 W GB9501753 W GB 9501753W WO 9604755 A1 WO9604755 A1 WO 9604755A1
Authority
WO
WIPO (PCT)
Prior art keywords
messages
rules
message
network
message processing
Prior art date
Application number
PCT/GB1995/001753
Other languages
French (fr)
Inventor
Peter Gordon Shenton
Christopher John Strang
Douglas William Mcadam
Original Assignee
British Telecommunications Public Limited Company
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
Application filed by British Telecommunications Public Limited Company filed Critical British Telecommunications Public Limited Company
Priority to AU30834/95A priority Critical patent/AU3083495A/en
Priority to JP8506289A priority patent/JPH10503630A/en
Priority to CA002192371A priority patent/CA2192371A1/en
Priority to EP95926448A priority patent/EP0772942A1/en
Publication of WO1996004755A1 publication Critical patent/WO1996004755A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/0016Arrangements providing connection between exchanges
    • H04Q3/0062Provisions for network management
    • H04Q3/0075Fault management techniques
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13503Indexing scheme relating to selecting arrangements in general and for multiplex systems object-oriented systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13521Indexing scheme relating to selecting arrangements in general and for multiplex systems fault management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13545Indexing scheme relating to selecting arrangements in general and for multiplex systems monitoring of signaling messages, intelligent network

Definitions

  • This invention relates to an apparatus for managing a telecommunications 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 appropriate manner before passing them on to other components of the apparatus.
  • 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; 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; 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.
  • the messages can be subjected to basic operations without involvement by the user, and by providing a second means for processing the messages in accordance 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 in accordance with rules which meet the user' s requirements.
  • a method of operating an apparatus for managing a telecommunications network 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; 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.
  • Figure 1 is a block diagram of some of the components 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
  • FIG. 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 hierarchical tree of the identification and parsing rules which are applied by the message processor to messages received by the network manager;
  • Figure 5 shows an alternative configuration of some of the components of the network manager.
  • Figure 6 shows another alternative arrangement of some of the components of the network manager.
  • 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 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, 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 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 transmitted over a communications link 40.
  • the network manager 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.
  • the service manager 32 may manage voice communications over private circuits and the service manager 34 may manage the provision of data channels in private circuits.
  • 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 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 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 real 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 transmitted according to various protocols. In the present example, the data is transmitted 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.
  • CMIS Common Management Information Services
  • An m_SET message is used to request a database to set the value of a 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 particular 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.
  • a network manager or a service manager takes the form of a computer provided with appropriate software.
  • a software package for 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 manager.
  • An example of such a software package is the one known as NetExpert available from Object Systems Integrators Inc.
  • the network manager 30 includes a communications stack 50 for receiving CMIS messages from, and sending CMIS messages to, the telecommunications network 10, a message processor 52, a configuration manager 34 and a fault manager 56, a network database 58, a communications stack 60 for sending CMIS messages to, and receiving CMIS from, the service managers 32, 34 and 36, and a communications stack 62 for sending messages to other equipment such as the facsimile machine 42 or the pager 44.
  • the communications stack 50 is responsible for handling CMIS messages and for converting these messages between a form for transmission along communications link 38 and a form which is suitable for use with the network manager 30.
  • a suitable software passage for handling CMIS messages is available from British Telecommunications pic and a suitable software package for converting the messages into and out of a form suitable for transmission on communications link 38 is available from Retix Corporation of Sainta Monica, California, USA.
  • the communications stack 60 is similar to the communications stack 50.
  • the communications stack 62 takes a form which is appropriate 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 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 accordance with m_SET and m_EVENTREPORT messages from the network 10 and also servicing m GET requests.
  • the configuration manager 54 is also responsible for instructing configuration changes of the network 10 in response to requests from the service 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 these messages.
  • the configuration manager 54 and the fault manager 56 are each responsible for managing information received by the network manager 30 and so each of these is also an information manager.
  • FIG. 3 there are shown the components of the message processor 52. These comprise a store 70, a first message processing component 72, a second message processing component 74, a database 76 for 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 stores the messages in a queue. Each message is stored in the store 70 with an identification tag. The store 70 supplies a copy of each message in turn to the first message processing component 72 while retaining the original message in the queue.
  • 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 identification and parsing is performed in accordance with a set of predefined rules which are loaded into the first message 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.
  • Each message in the present example, is either an m_SET, m_EVENTREPORT or m_GET message.
  • each message is identified as belonging to one of these three types.
  • the message is an m_SET message, it is parsed to determine the 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.
  • a message is an m__EVENTREPORT message
  • a further stage of identification is performed to determine the type of event which is being reported.
  • 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, the message is parsed to determine the identifier for that object and the values of its attributes.
  • 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.
  • the type of alarm may be a transmission alarm and, where the type of alarm is a transmission alarm, the type of problem may be a framing error.
  • the information of each message received from the first message processing component 72 is processed in accordance with a set of rules.
  • This set of rules is the second set of rules mentioned 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 the second message processing component 74 processes the information of each message in accordance with a set of default rules.
  • each rule established by the user is derived from a set of prototype rules.
  • Six exemplary prototype rules are set out in Table 1 below.
  • the user specifies the network element or object from which the alarm is received and also the time interval.
  • the second or duplicate alarm is discarded.
  • the second message processing component 74 instructs the store 70 to discard the alarm.
  • rules which follow the first prototype rule correlate duplicate alarms and one of the functions of the second message processing component 74 is to correlate alarms.
  • 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 to the fault manager 56.
  • the counter is incremented until it reaches its threshold and then a warning is issued to the fault manager 56.
  • the user When establishing a rule which follows the fourth prototype rule as set out 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.
  • the second message processing component 74 instructs the store 70 to copy the alarm to the pager 44.
  • the store 70 would also be instructed to discard the alarm.
  • the user specifies the number of alarms and the destination for the warning. Then, when such a rule is in use, if the specified number of alarms are received within one hour, a warning is issued to the destination which might be, for example, the fault manager 56.
  • the user When establishing a rule which follows the sixth prototype rule set out above, the user specifies the message type and also the destination. The destination 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 component 74 instructs the store 70 to send it to the service manager 32.
  • the store 70 is programmed to discard each alarm after a preset period if it has not been discarded before this time.
  • output messages from the other components 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 network manager 52 is in use, these predefined rules 84 are loaded by the data loader 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.
  • the prototype rules 82 can be retrieved by the user interface 80 and presented to the user for establishing 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 shut down, the rules in the database 76 for use in the second message processing component 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 to modify it. The modified rule is then returned to - li ⁇
  • the arrangement of the message processor 52 shown in Figure 3 is suitable for an arrangement where messages are received from a telecommunications network in only one protocol, in the present example CMIS.
  • modification is required where messages are received in more than one protocol as each protocol requires its own set of rules for identifying and parsing messages.
  • Figure 5 there is shown a modification 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 and the second message processing component 74. Although not shown, there is also provided the database 76, data loader 78 and user interface 80.
  • the arrangement of Figure 5 also includes a communications stack 90 for receiving message in the Simple Network Management Protocol (SNMP).
  • SNMP Simple Network Management Protocol
  • the messages 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 component 72 and receives a set of rules for identifying and parsing the messages from the database 76. However, this set of rules is appropriate for SNMP messages.
  • the first message processing component 94 passes it to the second message processing component 74.
  • FIG 6 there is shown a modification to the network manager 52 in which there are provided three message processors 100, 102, 104, each of which is generally similar to the message processor 52 and which are arranged in a cascaded manner.
  • the arrangement shown in Figure 6 includes the communications stack 50 for receiving CMIS messages and also the configuration manager 54 and the fault manager 56.
  • 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 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 messages to both the configuration manager 54 and the fault manager 56 and also to external equipment 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 appropriate to the service manager.

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

APPARATUS FOR MANAGING A TELECOMMUNICATIONS NETWORK
This invention relates to an apparatus for managing a telecommunications 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 appropriate manner before passing them on to other components of the apparatus.
According to one aspect of 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 established before the apparatus is in use receiving 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; 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.
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 without involvement by the user, and by providing a second means for processing the messages in accordance 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 in accordance with rules which meet the user' s requirements. According to a second aspect of this invention, there is provided 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; 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.
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 components 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 hierarchical tree of the identification and parsing rules which are applied by the message processor to messages received by the network manager;
Figure 5 shows an alternative configuration of some of the components of the network manager; and
Figure 6 shows another alternative arrangement of some of the components 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 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, 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 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 transmitted over a communications link 40. The network manager 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 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 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 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 real 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 transmitted according to various protocols. In the present example, the data is transmitted 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 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 particular 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 appropriate software. A software package for 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 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 messages to, the telecommunications network 10, a message processor 52, a configuration manager 34 and a fault manager 56, a network database 58, a communications stack 60 for sending CMIS messages to, and receiving CMIS from, the service managers 32, 34 and 36, and a communications stack 62 for sending messages to other equipment such as the facsimile machine 42 or the pager 44.
The communications stack 50 is responsible for handling CMIS messages and for converting these messages between a form for transmission along communications link 38 and a form which is suitable for use with the network manager 30. A suitable software passage for handling CMIS messages is available from British Telecommunications pic and a suitable software package for converting the messages into and out of a form suitable for transmission on communications link 38 is available from Retix Corporation of Sainta Monica, California, USA. The communications stack 60 is similar to the communications stack 50. The communications stack 62 takes a form which is appropriate 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 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 accordance with m_SET and m_EVENTREPORT messages from the network 10 and also servicing m GET requests. The configuration manager 54 is also responsible for instructing configuration changes of the network 10 in response to requests from the service 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 these messages.
Thus, the configuration manager 54 and the fault manager 56 are each responsible for managing information 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 components of the message processor 52. These comprise a store 70, a first message processing component 72, a second message processing component 74, a database 76 for 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 stores the messages in a queue. Each message is stored in the store 70 with an identification tag. The store 70 supplies a copy of each message in turn to the first message processing component 72 while retaining the original message in the queue.
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 identification and parsing is performed in accordance with a set of predefined rules which are loaded into the first message 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 parsing the information 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 identification 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 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 identification 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, 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 transmission alarm and, where the type of alarm is a transmission alarm, the type of problem may be a framing error.
In the second message processing component 74, the information of each message received from the first message processing component 72 is processed in accordance with a set of rules. This set of rules is the second set of rules mentioned 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 the 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 established by the user is derived from a set of prototype rules. Six exemplary prototype rules are set out in Table 1 below.
able 1
1. For alarm from (object) if duplicate alarm received within (interval) then discard duplicate alarm. 2. For alarm from (object) 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 warning to (destination).
6. If message type is (message 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 time interval. When a user has established an actual rule using the first prototype rule 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 to achieve this, the second message processing component 74 instructs the store 70 to discard the alarm. Thus, rules which follow the first prototype rule correlate duplicate alarms and one of the functions of the second message processing component 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 specified object is followed by a clear for that alarm for that object within a specified time "interval, then the original alarm is discarded.
When establishing 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 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 and problem type, the counter is incremented 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 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 component 74 instructs the store 70 to copy the alarm to the 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 rule is in use, if the specified number of alarms are received within one hour, a warning is issued to the destination which might be, for example, the fault manager 56.
When establishing a rule which follows the sixth prototype rule set out above, the user specifies the message type and also the destination. The destination 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 component 74 instructs the store 70 to send it to the service manager 32. The store 70 is programmed to discard each alarm after a preset period if it has not been discarded before this time.
As indicated in Figure 3, output messages from the other components 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 network manager 52 is in use, these predefined rules 84 are loaded by the data loader 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 establishing 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 shut down, the rules in the database 76 for use in the second message processing component 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 to modify it. The modified rule is then returned to - li ¬
the database 76 and also to the second message processing component 74.
The arrangement of the message processor 52 shown in Figure 3 is suitable for an arrangement 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 protocol as each protocol requires its own set of rules for identifying and parsing messages. Referring now to Figure 5, there is shown a modification 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 and the second message processing component 74. Although not shown, there is also provided the database 76, data loader 78 and user interface 80. The arrangement of Figure 5 also includes a communications stack 90 for receiving message in the Simple Network Management Protocol (SNMP). The messages 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 component 72 and receives a set of rules for identifying and parsing the messages from the database 76. However, this set of rules is appropriate 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 manager 52 in which there are provided three message processors 100, 102, 104, each of which is generally similar to the message processor 52 and which are arranged in a cascaded manner. The arrangement 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 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 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 messages to both the configuration manager 54 and the fault manager 56 and also to external equipment 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 appropriate to the service manager.

Claims

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; 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; 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, 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.
3. An apparatus as claimed in claim 2, 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.
4. An apparatus as claimed in any one of the preceding claims, in which said first set of rules includes rules for identifying messages according to their type.
5. An apparatus as claimed in any one of the preceding claims, in which said second set of rules includes rules for correlating messages.
6. 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.
7. An apparatus as claimed in claim 6, 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.
8. 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 for loading rules from said user interface into said database, said data loader also being 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.
9. 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; 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.
10. A method as claimed in claim 9, in which a set of prototype rules are provided for establishing individual ones of said second set of rules.
PCT/GB1995/001753 1994-07-29 1995-07-25 Apparatus for managing a telecommunications network WO1996004755A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
AU30834/95A AU3083495A (en) 1994-07-29 1995-07-25 Apparatus for managing a telecommunications network
JP8506289A JPH10503630A (en) 1994-07-29 1995-07-25 Equipment for managing telecommunication networks
CA002192371A CA2192371A1 (en) 1994-07-29 1995-07-25 Apparatus for managing a telecommunications network
EP95926448A EP0772942A1 (en) 1994-07-29 1995-07-25 Apparatus for managing a telecommunications network

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
WO1996004755A1 true WO1996004755A1 (en) 1996-02-15

Family

ID=10759063

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB1995/001753 WO1996004755A1 (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)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997050209A1 (en) * 1996-06-27 1997-12-31 Telefonaktiebolaget Lm Ericsson (Publ) A method for fault control of a telecommunications network and a telecommunications system
GB2372671A (en) * 2001-02-27 2002-08-28 3Com Corp Processing network events to reduce the number of events to be displayed
US6633230B2 (en) 2001-02-21 2003-10-14 3Com Corporation Apparatus and method for providing improved stress thresholds in network management systems
US7016955B2 (en) 2001-02-27 2006-03-21 3Com Corporation Network management apparatus and method for processing events associated with device reboot
CN100438423C (en) * 2002-08-06 2008-11-26 华为技术有限公司 Telecommunication equipment fault information managing method
US7673035B2 (en) 2001-02-27 2010-03-02 3Com Corporation Apparatus and method for processing data relating to events on a network
US7774836B1 (en) * 1999-04-01 2010-08-10 Juniper Networks, Inc. Method, apparatus and computer program product for a network firewall

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"Advanced management of telecommunications networks", ELECTRICAL COMMUNICATION, vol. 65, no. 1, ROMFORD GB, pages 52 - 59, XP000264669 *
AIDAROUS ET AL.: "Service management in Intelligent Networks", IEEE NETWORK: THE MAGAZINE OF COMPUTER COMMUNICATIONS, vol. 4, no. 1, NEW YORK US, pages 18 - 24, XP000113852 *
FELDKHUN ET AL.: "Towards an Integrated Management System for hetereogeneous network environments", MILCOM '88, SESSION 46, PAPER 1, vol. 3, 23 October 1988 (1988-10-23), SAN DIEGO US, pages 867 - 876, XP000012323 *
LIN ET AL.: "A framework for learning and inference in network management", GLOBECOM '92, vol. 1, 6 December 1992 (1992-12-06), ORLANDO US, pages 560 - 564, XP000357845 *
SEVCIK: "Adaptable TMN: A new dimension in practical network management", INTERNATIONAL SWITCHING SYMPOSIUM 1992, SESSION C1, PAPER 2, vol. 1, 25 October 1992 (1992-10-25), YOKOHAMA JP, pages 65 - 69, XP000337618 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997050209A1 (en) * 1996-06-27 1997-12-31 Telefonaktiebolaget Lm Ericsson (Publ) A method for fault control of a telecommunications network and a telecommunications system
US7774836B1 (en) * 1999-04-01 2010-08-10 Juniper Networks, Inc. Method, apparatus and computer program product for a network firewall
US6633230B2 (en) 2001-02-21 2003-10-14 3Com Corporation Apparatus and method for providing improved stress thresholds in network management systems
GB2372671A (en) * 2001-02-27 2002-08-28 3Com Corp Processing network events to reduce the number of events to be displayed
GB2372671B (en) * 2001-02-27 2003-04-30 3Com Corp Processing network events to reduce the number of events to be displayed
US7010588B2 (en) 2001-02-27 2006-03-07 3Com Corporation System using a series of event processors for processing network events to reduce number of events to be displayed
US7016955B2 (en) 2001-02-27 2006-03-21 3Com Corporation Network management apparatus and method for processing events associated with device reboot
US7673035B2 (en) 2001-02-27 2010-03-02 3Com Corporation Apparatus and method for processing data relating to events on a network
CN100438423C (en) * 2002-08-06 2008-11-26 华为技术有限公司 Telecommunication equipment fault information managing method

Also Published As

Publication number Publication date
JPH10503630A (en) 1998-03-31
AU3083495A (en) 1996-03-04
EP0772942A1 (en) 1997-05-14
CA2192371A1 (en) 1996-02-15
GB9415301D0 (en) 1994-09-21

Similar Documents

Publication Publication Date Title
US6373383B1 (en) Method and apparatus for policy-based alarm notification in a distributed network management environment
US6070188A (en) Telecommunications network management system
US6603396B2 (en) Method and apparatus for distributed object filtering
US5896440A (en) System and method for providing a unified communications link between divergent communication networks
US5822569A (en) Data storage device
US20020004828A1 (en) Element management system for heterogeneous telecommunications network
JPH0973423A (en) Snmp/osi management gateway device
EP1116121A1 (en) Interface system for integrated monitoring and management of network devices in a telecommunications network
US5960178A (en) Queue system and method for point-to-point message passing having a separate table for storing message state and identifier of processor assigned to process the message
EP0661891B1 (en) An apparatus for managing an element manager for a telecommunications switch
US6222827B1 (en) Telecommunications network management system
AU678701B2 (en) A data storage device
EP0772942A1 (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
US7047295B1 (en) Generic alignment method in a multimanager environment
US5966713A (en) Method for determining the contents of a restoration log
EP1146688B1 (en) Execution sets for generated error - logs
US6137801A (en) Telecommunication switching system administrative and management tools
US20030093486A1 (en) CIM gateway for supervising and controlling telecommunications transport networks
WO1997024835A1 (en) Telecommunications network management method
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
Ueda et al. Implementation of the TMN to a highly reliable distributed switching node
KR100441892B1 (en) Apparatus and method for integrally managing subscriber for CO-LAN
KR100205032B1 (en) Subordination network career data administrating method in bdcs
US7003557B1 (en) Method and system for racing control of operations in system management

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AM AT AU BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU IS JP KE KG KP KR KZ LK LR LT LU LV MD MG MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TT UA UG US UZ VN

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE MW SD SZ UG AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1995926448

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2192371

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 1997 765887

Country of ref document: US

Date of ref document: 19970107

Kind code of ref document: A

WWP Wipo information: published in national office

Ref document number: 1995926448

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 1995926448

Country of ref document: EP