APPARATUS FOR MANAGING A TELECOMMUNICATIONS NETWORK

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: 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.

Inventors: MCADAM DOUGLAS WILLIAM, SHENTON PETER GORDON, STRANG CHRISTOPHER JOHN, MCADAM, DOUGLAS, WILLIAM, SHENTON, PETER, GORDON, STRANG, CHRISTOPHER, JOHN
Applicants: BRITISH TELECOMM, MCADAM DOUGLAS WILLIAM, SHENTON PETER GORDON, STRANG CHRISTOPHER JOHN, BRITISH TELECOMMUNICATIONS PUBLIC LIMITED COMPANY, MCADAM, DOUGLAS, WILLIAM, SHENTON, PETER, GORDON, STRANG, CHRISTOPHER, JOHN
Application year: 1995
Main classification: H04Q3
IPC codes: G06F13, H04M3, H04Q3