Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
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 ` `
2
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
21 92371 -
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~ ''
4
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~ `
5
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~
7
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
9
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~
