CA2246741A1 - Network management system - Google Patents

Abstract

A system and method for managing a telecommunication network. The system and method employs a network management architecture that provides an overlay in which network management functions are performed. The network management architecture (100) includes a workstation function (102) that provides a graphical user interface (GUI) (108) for a user to interact with an object model of the physical telecommunication network, a telecommunication network management subsystem (104) that provides an object model of the network including the object models of network equipment and connectivity between the equipment, a database subsystem (106) that stores "current" and "future" views of the network, and an object request broker (103) that translates object from a first object-oriented paradigm to a second object-oriented paradigm for use by the GUI (108). The network management architecture facilitates network design by determining network performance metrics.

Description

W O g7/31451 PCT~US97/02673 Network Management System ~ackground of the lnvention .

Field of t*e Inventwn The present invention relates generally to telec-~l.. ir~tions ll~Lwol~.
More particularly, the present invention relates to m~n~ging a teleco.-.. ir~tions network co~ g diverse network elements conforming to a variety of teleco.. l~.. ic~tions protocols.

RPlnt~7 A7~
As teleco...."~ tions networks become more complex, telecoll,lllunication network service providers require increasingly capable network management systems. The network management systems face substantial hurdles to acceptance by network service providers. One such hurdle is that the network management systems have to manage n~wol~
comprised of network equipments that comply with a variety of interface standards. An example of such an interface standard is the well-known common management interface protocol (CMIP). Not only must a telecol~ lunications network management system manage diverse network elements, but it must also manage network growth and/or mo-lifir~tion.
Conventional teleco....-.~ on neLwolh m~n~geml-nt systems do not provide a mechanism for representing the physical network in an efficient ma~ eL to facilitate network design and m~int~n~nre. Nor do they ~c~eq -~t~ly provide for representing a physical network's evolution to a new configuration.
Moreover as the networks become more capable telecn,..,-.-.~ tion services providers are faced with increased service demand. Increased service ~ 25 demand, in turn, requires increased co-.~ -ic~tion ~andwidth. To meet the increased co-~".~-ir~tinn bandwidth requirements, many service providers have turned to optical co."",-",ic~tions. In response to the increased dern~n~l for WO 97/31451 PCTrUS97/OZ673 optical teleco.,~ .."ie~tions equipment, a number of vendors have entered the marketplace. To allow telecvllll,~ tions network designers to connect equipments from various vendors togetner into a heterogenous fiber optic telec~lllll--llllic~tions networks, synchronization (also referred to as timing)interconnectivity standards had to be developed. One such standard is the Synchronous Optical NETwork ~SONET). An overview of SONET can be found in JOHN BELLAMY, DIGITAL TELEPHONY, 403-26 (John Wiley & Sons, Inc. 1991), hereby incorporated by reference.
A SONET network distributes synch,o~ alion in the SONET optical signal rate. To do so, a source clock produces an electrical timing signal to bedistributed. The source clock is an ~ emely stable clock. Such a clock is generally referred to as a Stratum-1 source. A Stratum-1 source is a highly reliable timing source (having a free running inaccuracy on the order of one part in 10~
The electrical timing signal feeds a frequency multiplier in a SONET
CIn;~I~1. The frequency multiplier multiplies the timing signal to genelal~
a derived SONET optical signal rate. The SONET tr~n~mitter transmits data to a SONET receiver at the derived optical signal rate. The SONET receiver extracts the derived optical rate. The SONET receiver divides the extracted optical rate by the multiplication factor applied by the frequency multiplier toproduce the distributed electrical timing signals.
SONET equipment can adapt to network e~ lel~L failure by modifying tne ~,y~lclllonization topology of the network. However, such modification may cause problems in the rçsl-lting network synchl:o~ ion topology. For example, the modification can result in timing loops and loss of traceability toa Stratum-1 source. Modern networks ensure traceability of timing back to a Stratum-1 source to ensure timing stability. A timing loop occurs when a particular piece of timing equipment is referred to more than once in a particular path. A path connects a source of timing to a user of timing. A
timing loop can result in the complete loss of a particular path. This is because WO 97~1451 PCTrUS97102673 the path's timing continually tries to catch itself, eventually clllmin~ting in the loss of syncl~o~ alion. Thus, it is desirable to design a telecu,.,...-..,ic~tir~ns network that does not have timing loops, and that has traceability back to Stratum-l. Moreover, as a teleco...l"l...ir~tinns network reconfigures itself toS cil-;ulllv~lll network failures, the restored configuration must avoid timing loops and m~int~in Stratum-l traceability.
Whatisrequiredthereforeis ateleco...~ l.-ic~tions networkmanagement system to aid in the design and m~int--n~nre of a robust teleco.. l.~ir~tions network. The system should be capable of m~n~ging diverse network equipments co~ g to a variety of interface standards. The system should also be able to determine the current state of a network, restore it to a state satisfying various engineering design guidelines. The network management system should be flexible enough to allow upgrades (i.e., addition of new equipment and changes in network topology) without violating the engineering design guidelines.

Summary of the Invention The present invention is directed to a system and method for m~n~ging a telecomm--nic~tions network. The system and method employs a network management architecture that provides an overlay in which network management functions are performed. The network management archittoct -re includes a workstation function subsystem that provides a graphical user interface (GUI), a teleco".,..l.~-ir~tions management network (TMN) Sul)~y~L~
a database subsystem, and an object request broker (ORB). Using the GUI, a user (e.g., a Il~Lw~3lh designer) can interact with an object model of the physical telecommunications network. The TMN subsystem provides an object model ~ of the teleco~n.,ll~nir~tions network. The current configuration of the managed network is referred to as a "current" view. The object model can represent a configuration of the network projected to some future date. The projected W O 97/31451 PCTrJS97/02673 configuration of the managed network is referred to as a "future" view. The database sub~y~em stores records that are used to construct "current" and "future" views of the network. The ORB maps objects from a first object-oriented paradigm to a second object-oriented paradigm for use by the GUI.
One aspect of the present invention is a novel network management architecture that provides sufficient flexibility to allow for management of a modern telecollll.l-...i~tions network. The telecomml7ni~ti-)ns network can contain diverse network equipments that conform to differing co".".~ ications protocols. The network management architecture contains a management ~ lmalion base. The management ~l~ol~llalion base collL~il~ a run-time object model of the teleco-llllll-~-ic~tions network. The run-time model can l~)l~;:S
the projected configuration of the network at some future date.
The run-time object model generally conforms to the T~IN standard.
Because the TMN standard does not a~leqll~t~ly model the physical connectivity of the network (e.g., path traces between network elements), the present invention includes extensions to the conventional TMN object models. The extensions to conventional TMN object models allow the present invention to more realistically model and display the teleco,,,,,,ll,,,cations network. Thus,the software architecture stores an object model representation of the physical network. The stored object model representation represents the current configuration of the network or the configuration of the network projected to some future date. In this specification, an object model ~e~ies~ ion of a teleco.,-lllll,-~r~tions network is also referred to as an object store or a workset.
The present invention also provides a workset manager. The workset manager interacts with a database having records that are used to construct various network configuratiorls. By so interacting, the workset manager provides the desired run-time model of the network to the TMN subsystem.
Using a network management architecture designed according to a preferred embodiment of the present invention, a network cltosignt-r can simulate the behavior of the network to proposed modifications of the network.

_5_ Modifications include adding, removing, or rh~nging the configuration of network elements, as well as modifying the topology of the telec~J~ llir~tit ns n~lwolk. By sim~ ting mo~lifir~tions to the network conftguration, a network designer can study the effect of a proposed network configuration prior to physical implementation. Modifications can be made incrementally, e.g., to monitor the progress of a proposed plan of upgrade to the teleco-lll..ll~ir~tions network. The object models can be stored and indexed according to project (plan of llelw("k modification) and/or date (network configuration at some time in the future).
The network management arrllitect. lre includes a ~l~t~hace subsystem that provides long-terrn storage of records that are used to construct "current"and "future" views of the telecol--,l,~ ir~tions ll~Lwulk. Access to the ~l~t~h~e is provided by a set of database procedures that provide a standard tl~t~h~e interface to the ~l~t~h~e sub~y~Lelll.
The network management architechlre also includes a workstation subsystem. The workstation suhsystem provides a graphical user interface (GUI). The GUI allows a network designer to perform network management fu~ctions by providing the network designf~r with access to the run-time object model representations of the telecol-,,,,l.,~ir~tions network. The GUI includes 2û additional capabilities for implov,llg the display of the network to a user. The additional capabilities include reducing screen clutter, displaying linked topological and topographical views, and network zooming.
The present invention also provides teleco~ -u.lic~tion network management functions. One such management function is the design of synclllo,~i~a~ion diskibution in a teleco.. lll.. ~-ir~tions network. The design of synchronization distribution includes loop detection, kaceability~ diversity assurance, and selection table initi~li7~tion.
~ Traceability refers to determining the source of a particular network col l " ", . ~ tion. According to a plere~d embodiment of the present invention,traceability is provided through extensions to the TMN standard. In the context W O 97/31451 PCTrUS97/02673 of the synchronization, the present invention allows a network designer to assure that a given ll~lwolk configuration assures traceability to a highly reliable timing signal source.
Loop detection analysis detersnines whether a particular network element appears in a particular co~ ir~tion~s distribution path more than once. The presence of a loop in a synchl:ol~alion path of a telec~ ir~lion nelwolk can result in severely degraded network p~lro,~ llce.
Diversity refers to providing di~r~ lL paths for cn.. 1., l lir~tion between a particular source and a particular destination of a co.llllllll~ tion signal. In the context of the present invention, diversity means minimi7ing the number of common network elements in dirrel~llL paths between the source and clçstin~tinn of a comml-nic~tion signal. The present invention provides for diverse c-~llll..l-l.ir~tif~n paths bc:~eell c~ llic~tions sites. By doing so, the present invention ~rlh~nces the robustness of the network to network failures. That is, the network can restore itself in the event of a failure by :iwi~ lg to a working path.
Priority in the context of the present invention is related to network restoration. The present invention incorporates a novel priority scheme to prevent needless, and potentially harmful, switchovers between network 2Q e~lui~ cnt having essçnfi~lly the same ~lrulmance characteristics. The novel priority scheme assigns equal priority levels to equipments for which no mutual switchover is desired.
Another aspect of the present invention uses the software archit~-ch~re to manage synch~ lion distribution in a SONET/SDH telecomml-nications network. The telecommunications network includes timing network elements and SONET network elements that derive their timing from the timing network elements. The system extracts requisite data from the physical telecomml-ni-~tions network to build an object model l~r~,se~ tion of the network, thereby modeling synchronization paths ~-tween the various equipments included in the network. The object model replese~ Lion is stored CA 0224674l l998-08-l7 W O 97/3L451 PCTrUS97/02673 in a management information base (MIB) contained in the TMN subsystem.
The fl~t~h~e can be modified corresponding to changes in the telec~ ,....-ie~tions network. The system provides a GUI through which a ll~Lw~lk ~lecign~r interacts with the object modeL representation to manage the telecomml-nic~tions network.
Further fealules and advantages of the invention, as well as the structure and operation of various embo-l;..~r~ of the invention, are described in detail below with reference to the accolnpa"yi,lg drawings. In the drawings, like reference numbers generally in-lic~tf~ identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears iS in(lir.~te-l by the digit(s) to the left of the two rightmost digits in the corresponding reference number.

Brief Description of the Figures The present invention will be described with Ler~,e,lce to the accompanying drawings, wherein:
FIG. lA is a llcLwolh management archit~ctllre for telecommlmirz~tions network management according to a pl~r~ d embodiment of the present invention.
FIG lB is a network management system illustrated according to the TMN standard.
FIG. 2A is a TMN-compliant object model repres~nt~ti~ n of a network.
FIG. 2B is a CORBA-compliant class hierarchy for representing of a network.
FIGs. 3A-C illustrate mapping from a TMN-compliant object to a CORBA-compliant object.
FIG. 4 is a diagram of interfaces according to a preferred embodiment of the present invention.
FIGs. 5A-D illustrate linked topological and topographical network views.

W O 97/31451 PCTrUS97/02673 FIG. 6 illustrates a simple timing distribution chain in a telecomm-lnic~tions network.
FlGs. 7A and 7B illustrate two types of selector switches 140 and 146 used in SONET lleLwolh elements.
FIGs. 8A-C are resource priority assignments for a selector switch in a SONET network element.
FIG. 9A is a flowchart for interpreting a selection table Cont~ining priority values.
FIG. 9B is a flowchart for ~.c.~igning priorities to data paths to carry data streams.
FIG. 10 is a flowchart for simlll~ting the synchronization topology of a telecomml-nic~tions network using the teaching of the present invention.

Detailed Descripfion of the Preferred Embodiments Table of Contents I. Network Management AlchiLecLul~ for Remote Management of a Telecol.. ,.. l.. -i~tions Network ........................................ 10 II. Human-Machine Interface (HMI) .................................. 24 III. GUI ........................................................... 26 IV. Network Management Functions and Pe-r(~ lce Metrics ............ 31 V. Synchroni7~tion Distribution Management ......................... 36 VI. Network Simulation ............................................. 46 I. Network Management Architecture for Remote Management of a Telecommunications Network One aspect of the present invention provides a teleco.. ~ ir~tions 2~ lletwulk management system with the capability to design, sim~ t~, and modify the topology of a teleco..~ tit)ns network. In this specification, a telec-,--~,----llir~tions network is ~ltern~t~ly referred to as a network. Using the CA 0224674l l998-08-l7 W O 97/31451 PCTrUS97/02673 _g present invention, a network engineer can ~im~ tr and evaluate a particular ll~Lwulk topology, prior to physically modifying the topology of the network.
This is accomplished by performing network management functions on an ~ object store representation (described below) of the telecomml-nir~tions S n~;Lwulk. An object store representation is a run-time object-oriented model of the physical telecol."l.l.~-ic~tions network.
A network management architrct--re 100 for management of a telecommllnic~tions network according to a ~lt;r~..ed embodiment is illustrated in FIG. lA. The network management architpchlre 100 contains a network engin~eTing workstation (NEWS) 101 and a database subsystem 106. The ~l~t~h~e ~ub~7y~7Lt:lll 106 is coupled to the NEWS via ~t~ba~e procedures 118.
The network m~n~gmrnt archit~ct~re 100 can optionally include a network provisioning workstation (NPWS) 107 coupled to the NEWS 101 via the ~l~t~kace procedures 118.
The NEWS 101 includes a workstation function (WSF~ subsystem 102, an object request broker (ORB) 103, and a teleco~ .lllllir~tions management network (TMN) subsystem 104. The WSF 102 is coupled to the ORB 103 via a data co"""ll"ic~tions network (DCN~ 111 (DCNs are described below). In the preferred embodiment, the TMN sub~y.,Lelll 104 is coupled to the ORB 103 via a teleco",lll.. llir~ti(>ns management ll~Lwolh object-oriented interface (TMN-OOI) 105. The TMN subsystem 104 is also coupled to a telecol.ll.lu~-ir~tions network 150. The telec~ll"..l.l-ir~ti-)ns network 150 is managed by the network management architecture 100. The TMN subsystem 104 coupling to the network 150 is through a DCN 930 via a co. . " ". . I~ic~tions management interface protocol (CMIP) compliant interface 121. One such CMIP-compliant interface is the well-known common management interface switch element (CMISE) interface.
In the preferred embodiment, the TMN subsystem 104, the database subsystem 106, and the ORB 103 are executed on a single platform. It would be a~al~llL to those skilled in the art, however, that other implementations are W O 97/31451 PCT~US97/02673 possible. For example, each subsystem 102, 104, and 106, and the object broker 103 can execute on a separate computing platform.
The NEWS 101 serves to aid in designing the syncl~ol~Lion distribution plan for a network. Specifically, the NEWS enables the selection of viable, diverse, loop-free paths for timing distribution, restoration, and monitoring. The NEWS 101 performs simulations of the behavior of a proposed network to discover we~knPs~es in the synchronization distribution plan. Such sim~ tion is described below in Section VI. The sim~ tions can include scenarios wherein particular network equipments or collllllu~ications links are sim~ te~ to have failed. In this manner, a network designer can observe the behavior of the ~im~ tion to predict the behavior of the physical network 150.
The WSF sub~y~Lelll 102 is coupled to the ORB 103 through a DCN
111. The WSF subsystem 102 contains a graphical user interface (GUI) 108 and a view controller 110. The GUI 108 provides a user-friendly interface for a neLwolk ~lesignpr. Using the GUI 108, the network designer makes requests to the rPm~in-lPr of the system to perform network management fi~n~ tion~. The GUI 108 also displays results of the requests made by the network ~le~i~nf~r.
As described below, the GUI 108 contains L.~ul"les to increase the utility of the displayed results to the network ~l~Si~nPr.
According to a ~lefelled embodiment of the present invention, an Object Request Broker (ORB) 103 is included in the NEWS 101. The ORB
103 permits a more generic interl~re 113 to an object model. The object model is equivalent to the run-time TMN model contained in the MIB 117. In the plt;rell~d embodiment, generic interface 113 is a CORBA-compliant interface, and the equivalent object model is a COR~BA-compliant object model. Example of such a CORBA-compliant interface include the well-known SOM and DSOM
interfaces by IBM Corp. The use of the ORB 103 allows ~or low cost, non-TMN-compliant wo~ ions to p~lrOllll the functions ntoces~ry to accomplish engineering functions. One such engineering function is synchl-o~ ion CA 0224674l l998-08-l7 W O 97/31451 PCT~US97/02673 distribution planning. As depicted by connection 130, a workstation can generally access the TMN domain 116 through a CORBA-compliant interface rendered by the ORB 103. The specific workstation 132 used in the NEWS
101 can access the ORB 103 through a DCN 111. Other NEWS workstations 134 can access the same ORB 103 via a connection through the DCN 111.
The view controller 110 provides an interface bc~lwt~ l the GUI 108 and the ORB 103. The view controller 110 translates ll~Lw~lk management requests from the GUI 108 into CORBA-compliant object requests. The CORBA-compliant object requests are llA~ P-1 to the ORB ~03 over the interface 113. The view controller 110 also tr~n~ tes C~ORBA-compliant result data tr,.n~mittP~l from the ORB 103 over the interface 113 into display data that is usable by the GUI 108 so that it can be displayed to a .~eLwolh designer.
An example of a TMN-compliant object is illustrated in FIG. 2A. It would be a~al~nl to those skilled in the art that the object ~e~l.,s~llled in FIG.
2A conforms with standard TMN objects (as defined in the IllLe,llational Telec(~lll",llllic~tion Union (ITU) M.3xxx Series Recommendations), with the exception of the syncNetworkManager 202, the pathTraceContoller 204, the pathTrace 206, and the objectsInPath 208. The syncNetworkManager 202 contains the overall l~ lk configuration. One syncNetworkManager 202 is il1!;1;~ r~ for each subnetwork in the network 150. The pathTraceController 204 detPi "~ .os a path between two elements. The pathTrace 206 is a single path that connects a given pair of network elements. The objectsInPath 208 contains a list of illlel ~/e~ g objects (representing other network elements), in a particular path between a given pair of network elements.
There is another deviation from standard TMN object model in the pl~r~ d embodiment that deserves note. The trail class in standard TMN does not provide a mech~ni~m whereby trails can be contained within a trail. This ~ presents a problem when trying to model SONET networks. This is because although SONET links, lines, and sections are most readily modeled by the TMN trail class, SONET links, lines, and sections can contain one another.

CA 0224674l l998-08-l7 W O 97/31451 PCT~US97/02673 -~2-That is, a SONET link can contain one or more SONET lines. Moreover, a SONET line can contain one or more SONET sections. Such modeling was not possible in standard TMN.
To overcome this problem, the plefelled embodiment uses a trail class S that has been modified from the TMN standard. The modified trail class isillustrated in FIG. 3A. Referring to FIG. 3A, the modified trail class 306 has three child classes: an s~hT,ink class 308, an s~hT,inf class 310, and an s-lh~Section class 312. The stlhT,;nk class 308, sllhT~in~ class 310, and s-ih.~ection class 312 each have the structure required to allow cont~inm~ont~ of the aL)pro~liate classes. Thus, the s~lhT,ink class 308 can contain line objectsand the sdhLine 310 can contain section ob3ects. Such cont~inment is not available in the TMN standard because the standard trail class does not provide for cont~inm~nt of trail objects.
FIG, 2B illustrates a class hierarchy for a CORBA-compliant object representation of a teleco~".. ,l.l-ic~tions network, Referring to FIG. 2B, the classes of the CORBA-compliant object are explained. The sornf MCollectible 202 class is the base class for all the other classes in FIG. 2B. The somf MCoIlectible class 202 allows for all other classes to exist in the memory of a procç~ing system, for exarnple, in the form of a linked list or similar data structure. The nsTop class 204 is a base class for all of the network object model object classes. The nsTop class 204 contains functionality for creation and deletion of distributable network object model objects on both client and server sides. The nsTop class 204 also implements general security and authorization functions that are common to all classes lower in the hierarchy.
The nsLatLong class 206 represents an item of latitude and longih~-~e data. The nsTMNOOIThread Class 208 m~int~in.c a c--nn~ction between a CORBA-compliant object model and a corresponding TMN-compliant object model.
The nsTMNOOIThread class 208 can contain an object refe~cllce or "handle"
that allows a CORBA-compliant object model and a corresponding TMN-compliant object model to commnnicalt~,. The nsDName class 210 holds a WO 9~/3145~ PCTrUS97/02673 unique distinguished name for an ob~ect in accordance with TMN standards.
The nsGeoLink class 212 and the nsGeoNode class 214 handle graphical rendering of c(3.l~ unications links and co" " ~ ti--ns equipments for picse.lLaLion on, for example. a geographical map.
The nsDBTop class 216 and its child classes (nsProject class 218, nsTSGPlan class 220, and nsSyncPlan 222) are included for practical reasons to store project and plan information in the database 120. An instance of the nsProject class 218 holds a list of locations that are involved in a given project.
The nsTSGPlan class 220 contains a list of all timing signal generators ~TSGs) for each of several locations. The nsSycnPlan class 222 is essentially a name placeholder to identify a particular syncl2l-o~ aLion pian. Instances of the nsProJect class 218 and the nsSyncPlan class 222 can contain multiple in~t~nres of one another.
The nsPerci~t~nre class 224 handles local persistent data. Such data includes, for example, user ~l~r~rellces.
The nsTMNTop class 226 is a base class for all COR~A classes that have counterparts in the TMN class hierarchy (described in FIG. 2A). In keeping with the TMN concept of having a unique distinguished name for every TMN object, the nsTMNTop class 226 attaches an nsDName class 210 to each instantiation of a CORBA class. The nsLink class 228 is analogous to the TMN link class. When inst~nti~ted, the nsLink class 228 represents a particular c~ ;ons link in a managed network. The nsLocations class 229 is analogous to the well-known TMN location class.
The remainder of the classes derived from the nsTMNTop 226 substantially correspond to similar classes in the TMN class hierarchy.
However, there are a few notable exceptions. The nsManagedElement class 230 is further divided into two child classes: the nsSyncNetworkElement class 232 and the sdhNE class 234. The nsPriList class 236 represents the priority list for the switching selector table contained in a network equipment. As described above, the switching selector table selects which of a plurality of W O 97/31451 PCTrUS97/02673 timing reference signals to use. The nsNetworkManager class 238 provides general services for operation of the NEWS 101 on the CORBA side. This function can include creation, inct~nti~tion, and deletion of worksets.
By llld~il~g objects from TMN-compliant objects to CORBA-compliant S objects, the object broker 103 provides the interface between the TMN
subsystem 104 and the WSF sub~.y~L~m 102. It would be a~ale.ll to those skilled in the art that the object broker of the present invention can be clpcign~
to map between any two object protocols. Thus, the present invention is not limited to mapping TMN-compliant objects to CORBA-compliant objects.
Rather, the present invention can be used to interface other object domains.
FIGs. 3A-C depict the mapping of relationships between inst~ntizltPc~
classes in the CORBA domain and those in the TMN domain. In the l-lert;llcd embodiment this mapping is pelr~ led by the ORB 103.
In FIG. 3A, an instance of the nsTMNOOIThread Class 208 in the CORBA domain establishes and m~int~ins a connection with an OOIProxyAgent class 302 in the TMN domain. The nsTMNOOIThread 208 Class establishes the connection. The nsTMNOOIThread class 208 then m~int~;ns a handle that is npcess~ry for subsequent use of the established connection. All subsequent co~ 1ions between the CORBA object model and the TMN object model are achieved through this connection, and further, must involve an nsTMNOOIThread class 208 function to obtain the correct handle.
A conventional approach for llla~lg two object class hierarchies to one another is to arrange the two class hierarchies similarly in terrns of lineage and functionality. Then each inct~nre of a class in one hierarchy can m~int~in a pointer to reference its coullL~ al~ object in the other hierarchy. For example,in the well-known model-view-controller paradigm, a division is made between classes that replesell~ a data model and classes that are used to gr~3phic~ly render the data model. The data model is a hierarchy of classes that can manipulate data in memory. The view hierarchy contain,s functions for CA 0224674l l998-08-l7 W O 97/314~1 PCT~US97/02673 displaying data. Each model and its corresponding view in~t~n~e m~int~in pointers or l~r~l~nces to each other. If the data model in~t~nre changes state, it calls upon the corresponding view model instance to change its graphical - appearance. If a user acts upon the graphical represçnt~tioll, the view in.~t~n~e may notify the data model to change its state. If a user simply moves the graphical representation without otherwise altering its state, then the view instance can operate without calling any functions in the corresponding data instance.
Thus, to map a TMN-compliant object model to a CORBA-compliant object model, the conventional approach teaches building a CORBA class hierarchy in the same fashion as the established TMN class hierarchy. Then provision is made for each CORBA object to m~inf~in a reference to its counterpart in the TMN obiect model. Referring to FIGs. 3B and 3C, many of the CORBA objects depicted therein accomplish the ~c~lellce by cont~ining 1~ a distinguished name for their TMN counterpart. Normally, a function invoked within a CORBA object would simply involve calling a similar function in the corresponding TMN object that is identified by the distinguished name.
Passing a TMN distinguished name allows the TMN domain to readily access the desired object from the function cali.
Although the co~lvt;l~Lional model-view-controller design works well for some object mappings, other object mappings are best accommodated by a dirr~re"l scheme. The present invention realizes several advantages by te~ching novel approaches to mapping from object domain to another.
One novel approach to mapping is the use of a dictionary class in the CORBA-domain. This is illustrated in FIG. 3A. For example, the nsNetworkManager class 238 contains exactly one locationDictionary class 304.
The locationDictionary class 304 contains a list of entries. Each entry m~trh~s ~ a TMN object's distinguished name with a pointer to a CORBA-domain ob~ect.
The entries can be retrieved by a single function call in the TMN domain. The single function call requests a list of all locations. Upon invoking this single W O97/31451 PCT~US97/02673 function call, the TMN-compliant object model searches through all the objects in a TMN-compliant object models hierarchy to derive and return the requested list. The other dictionary classes illustrated in the CORBA-compliant model are populated by a similar procedure.
S The use of a ~lir.ti~)n~ry class on the CORBA side provides practical advantages in performance and flexibility. For example, in many cases an activity on the CORBA-compliant object model is directed at a subset of all the locations. By using a CORBA domain dictionary to "shadow" the TMN list of locations, a query function on the CORE~A domain side can effectively derive a subset of locations from the locationDictionary class 304. Having done so, further processing on the CORBA side can then extract the distinguished name for each entry. Then, ~ p~ TMN calls are made by passing the extracted distinguished name to the TMN side. This method can be considerably faster than ~1elP1~ lg the locations subset on the TMN side. An additional advantage in this approach is that a workstation developer who must interface with the CORBA-compliant object model is not burdened with having to understand or write instructions to iterate through the TMN-compliant objects.
A further adv~ntage of this approach is that some function applied to objects on the CORBA domain side should not be allowed to affect a similar function upon corresponding objects on the TMN domain side. For example, it is desirable that a "create" or "delete" function on the CORBA domain side cause local creation or deletion of CORBA objects, but not have an equivalent effect on the TMN domain side.
Another novel approach in the CORBA-TMN mapping of the present invention is that the CORBA-compliant object model classes ~o not have a hierarchy that mirrors the TMN-compliant object model hierarchy. Tn~te~-l, the CORBA-compliant object model classes are granular enough to conform to the TMN-compliant object model. Thus, if a TMN-compliant object model changes, the CORBA-compliant object model can continue to operate without being redesigned. This overcomes a problem with the convention~l model-view CA 0224674l l998-08-l7 W O 97/31451 PCTrUS97102673 approach wherein changes in the TMN-compliant object model class hierarchy would often require rearranging the corresponding CORBA-compliant object model hierarchy.
Referring back to FIG. 1, the TMN sub~y~Lelll 104 is an object-oriented S processing environment for mo~ hlg and m~n~ginE a network. The TMN
:jUhSy~ 104 consists of a TMN domain 116 and a workset m~n~ger 114. The TMN domain 116 can receive event notifications, such as alarm in~ir~tiQns~
directly from managed N~s via the DCN 127. The TMN domain 116 can also request information from remote NEs. These functions allow the TMN domain 116 to m~int~in an accurate representation of the configuration and state of themanaged network 150.
The workset manager 114 coordinates the storage and retrieval of wolh~eL~ from a fl~t~ha~e 120. A workset is a set of data that is used to createa TMN-object model of the managed network as it ~;ullcllLly exists and/or of the managed lleLwu k as it is projected to exist at a particular date in the future.
In general, the ~l~t~h~e 120 stores numerous records 136 relating to the current state and topology of the managed network. This information allows the network management architechlre 100 to create a "current" view of the network. A "current" view model represents the network as it is ~;u~lcl~Lly configured.
In the plef~ d emborlim~nt, the records 136 can also store inf~-- " ~ ion relating to future projections of topology, equipments, and configurations within the managed network. Such information allows the network management architect lre iûû to create "future" views of the managed network for a user. A "future" view model represents the network as it is projected to exist at some future date.
"Future" views can be used to ~imnl~t~ a variety of mc)flifir~tions to the "current" view including the addition of equipment to and the deletion of equipment from the telecommllni~tions network, and modifications of the configuration of existing network equipment. For example, to create "future"

CA 0224674l l998-08-l7 WO 97131451 PCTrUS97/02673 view for the addition of a new piece of equipment to the telecc"~"",l.-ications ll~Lwulk model, the neLwolh rlecignPr creates a new record in the database 120 describing the equipment. The workset manager 114 can then use the new record to create a workset incorporating the new equipment model into the S ll~wol~ model. The network designer can then cimlTl~t.o network operation to ~et~nnine the effect of the mo-lifir~tion on the telecf~,--",...~ic~tinn.c network 15Q
model without having to physically rnodify the telecommllnic~tions network 150.
The records 136, stored in the database 120, can be added or modified ~lltom~t;cally by the network management system. Alternatively, the records 136 can be created or modified by a h~man network design engineer who has specific knowledge about current or planned aspects of the managed neLwolh.
All ~cecces to the ~l~t~h~.ce 120 are ~elru,llled through a single set of ~l~t~h~ce procedures 118. The database procedures 118 m.~ te ~rcecsec to the data.
The database procedures 118 also assure integrity of the ~t~h~ce 120. Thus, the workset manager 114 interfaces to the database 120 through the ~l~t~hzlce procedures 118 via a standard database query format. Such a ll~t~h~ce query format, for example, is the well-known structured query language (SQL).
The workset manager directs the compilation of worksets 138 in accordance with illr,l-llalion contained in the records 136. In a prerelled embodiment, each workset 138 is a.cl-lmin~tion of all ~l~t~h~ce records that describe the Il~Lwolh up to and including a particular date. For this reason, unique worksets 138 are indexed by the date to which they pertain.
The TMN domain 116, the workset manager 114, the ~tzlh~.ce 2~ procedures 118, and the ~1~t~k~ce 120 are considered to be part of the "network management layer" (NML). The NML is defined in the TMN standard.
In addition to the NEWS 101, other management systems or workstations 140 can use these same components of the NML. For example, a network provisioning wolk~LaLion (NPWS) 107 can be coupled to the ~l~t~h~ce procedures 118 to provide access to the database 120. In a preferred W O 97/31451 PCTrUS97/02673 emboflim~nt, the NPWS 107 ~cesse,c the ~l~t~h~se 120 to assign network traffic - to available paths within the managed network 150. The other workstations 140 can access the ~l~t~h~e procedures through an interface 142. In the ~rer~ d embo-l;m~qnt, the interface 142 is implemented using the well-hnown SQLNET by Oracle Corp. In an alternative preferred embodiment, the interface 142 is implemented using the well-hnown standard database access control language (DBACL~. Alternatively, a Hyper-Text Marhup Language translator 141 can convert the database procedures interface into a well-hnown Hyper-Text Markup Language (EITML) interface 144. Using the HTML
interface 144 remote, low-cost worhstations, such as wvlh~lation 143, can gain at least limited access to data relating to the managed network 150. In TMN
terminology, the other wol~tions 140 and 143, and the NPWS 107 are considered to be part of the "service management layer" (SML). The SML is defined in the TMN standard.
The TMN domain 116 also contains a management information base (MIB) 117. Although there are several possible MIBs in a system ~iesign~d according to a TMN standard, the particular MIB 117 of interest is a run-time TMN object model. The workset manager 114 creates the run-time TMN
object model from a particular workset 138. Thus, the MIB 117 is a TMN
object model, extended as described above, that can represent either a "~;UilC:llL" view or a "future" view of the managed ll~Lwolh 150. The MIB 117 is specifically used by the NEWS 101.
To accomplish some desired network management functions, various wolk~ations would normally access the TMN domain 116, and perhaps the MIB 117, through either a CMIP-compliant interface 142 or a TMN Object-Oriented Interface (TMN-OOI) 105. These interfaces require that the workstations be equipped with speci~lc hal.lwale, software, or Op~l~Lillg systems that may incur expenses or inconvenience. In addition, any wvl~lions ~at use the TMN-OOI must m~int~in version compatibility with the particular TMN doma;n 116.

-~0-The n~Lwu~k management architt~ctllre 100 described above, however, provides increased flexibility over existing systems beeause is allows access tothe run-time TMN model of the network by platforms that are not TMN-compliant. For example, the ORB 103 can cu~ ic~tlo with non-TMN
S compliant systerns. In such a case, the ORB 103 must include mappings from the TMN-compliant domain to the non-TMN-compliant domain. In the preferred embodiment, the non-TMN-compliant domain is the CORBA ~lc)m~in Moreover, the workset manager 114 can be modifled to allow access to legacy systems. Legacy systems are generally considered to be existing systems that do not support industry standard client interfaces such as CMIP, CORBA, or SQL interfaces. Legacy systems include many traditional l,laillrlallle applications as well as midrange and personal computer applications.
FIG. lB illustrates the structure of the NEWS 101 as an operations system as defined by the TMN standard. Referring to FIG. lB a network 150 to be m~n~ge~l is ~~resellted as groups of timing signal gelle-d~ol~ (TSGs) 152,156 and groups of network elements (NEs) 154, 158. TSGs and NEs are diccll~ced below. The TSGs 152 and NEs 154 are directly conn~cte~l to a data co~ lications network ~DCN) 127. A lleLwolh management system (NMS) 170 according to the preferred embodiment of the present invention is also shown conn~octe~l to the DCN 127. The managed network components ean interface to the NMS 170 by using a standardized data comm~lnir~tions protocol, such as a CMIP-compliant protocol (as described above). In the r~ d embodiment, the NEWS 101 is irnpl~ ~ in the NMS 170. Other operations systems 164, 166 are also shown connected to the DCN 127. The other operations systems 164, 166 can also co.. ~."~ te with the managed network elements in a similar manner as the NMS 170.
Within the managed network 150, other groups of TSGs 156 and NEs 158 are connected to a separate DCN 160. The DCN 160 is u nn-oc~-l through a mediation device 162 to the DCN 127. This indirect connection of the TSGs 3Q 156 and NEs 158 to the DCN 127 can be used where the TSGs 156 and NEs CA 0224674l l998-08-l7 W O 97/31451 PCT~US97/02673 158 are not equipped to comml-nicate using the same protocols as the NMS
170. In such a case, the mecli~tion device 162 translates among protocols, thereby allowing diverse equipments to cu,.,~ ir~te with the NMS 170. As ~ would be ~~ clll to those skilled in the art, another practical reason for using the indirect connection is to provide coverage for a large number of elements over shared colllll....-ir~tions facilities.
The network management architect~lre 100 was described in terms of coupling through DCNs. A DCN provides a mechanism for tr~n~mitting information heLw~ell two remote points. In the context of the present invention,lQ the DCN can be either a ll~Lwulk or a single conduit. For example, in the case of the DCN 127, if a particular NE is CMIP-compliant, then the DCN 127 with respect to that particular NE can be simply a direct coupling. Although there are several separate DCNs depicted in FIGs. lA and lB, it would be a~l,al~.lL
to those skilled in the art that some of the DCNs can overlap or be combined.
In a DCN that uses a multi-layer protocol, even the diverse interfaces shown can be implemented through the same physical network for practical reasons.

II. Human-Machine Interface (HMI) The human-m~hin~ interface (HMI) of the present invention is unique in the field of telecommunications n~Lwulk synchronization management.
2Q Referring to Fig. 4, the HMI of the present invention is described. In the HMI
of the present invention, an application, such as the WSF lQ2, co.l..-....-ie~tes with the rem~in-ler of the system over an "f" interface 450. An "f" interface is standard TMN terminology for a common interface to attach to a particular application. CORBA-compliant interface 113 is an exarnple of an "f" interface.
The "f" interface 450, in turn, connects to various support platfo~ns via "g"
interfaces 452a-d and 454. A "g" interface is standard TMN terminology for a graphical interface. GUI 108 is an example of a "g" interface.

In the present invention, there are preferably two broad classes of "g"
interfaces. The first class of "g" interfaces includes "g" interface 452a, whichcan be further divided into "g" interfaces 452b-d (described below). The "g"
interfaces 452b-d connect a particular application to high-end and midrange user platforms. The second broad class of "g" interfaces is "g" interface 454.
The "g" int~rf~e 454 connects a particular application to low-end user platforms using the well-known Hyper Text Markup Language (HTML).
For example, the "g" interface 452b can be c~>nnrcted to a high-end user platform that supports the well-known UNIX/AIX operating system. Such a high-end user platform can be, for example, a high-end workstation that is capable of running the WSF 102 at or near real-time. Such capability can be required by a network design engineer res~ollsil)le for de~ignin~ and m~int~ining the teleco~ ;r~tions network. The high-end system is relatively expensive.
The "g" interfaces 452c-d can be, for example, connPcted to a rnid-range user platform. Such a platform can be capable of supporting the well-known OS2 or Windows 32-bit operating systems. In the present invention, the mid-range user platform is used by a user that requires frequent access to the ~im~ tion capabilities of the present invention, but does not require the power of a high-end user platform. ~or example, a mid-range co~ uL~r platform could interface to the network management archit~ ctllre 100 through the CORBA-compliant interface 130.
The "g" interface 454 provides an inexpensive me~h~ni~m for widespread distribution of the services provided by the present invention. This is because the user platform supporting the ~g" interface 454 does not have to support exrcllting the application and the associated colnL)ulillg requile~,lenl~. -Users of such a low-end platform include remote users that require infrequent access to the telecommllnir-~ti~n~ network models stored in the object stores inthe database 120. The low-end user platforrn preferably ~rcçsses a particular application using the well-known HTML. Referring to FIG. 1, interface 144 provides an HTML interface to the telecc".",.".,i~tit-ns network models stored in the fi~t~h~ce 120. As a result, low-end user platforrns are less costly and more easily supported than high-end and mid-range user platforms.
In the ~l~r~lled embodiment, the HTML interface is generated by an HTML translator 141. The HTML translator 141 preferably has a browser (e.g. the well-known Netscape Browser) for providing a GUI for a low-end user. The advantage of using the aforementioned distributive procecsing m-oçh~nism offered by the "g" interface 454 is the reduced cost and complexity of the low-end user platform.

III. GUI
The GUI 108 provides the graphical interface to the teleco."",.~,~ir~tions ll~Lwolh object models stored in the (l~t~b~e 120. A llullll)el of features havebeen incorporated in the GUI 108 to improve its presentation and overall usefulness to network designers and m~int~inPrs.
One feature is the presentation of object-oriented linked topological and topographical views of the telecol",lllllliç~tions network. The linked topological and topographical views are useful for d~tel~ ~illg diversity in the telecommllni~tions network. Moreover, the linked topological and topographical views can be used to verify that a particular restoration configuration satisfies various engineering gni~ltolin~s.
FIGs. ~A-D illustrate the linked topographical and topological views.
FIGs. 5A-D illustrate a telecoLL....unications network having 8 interconnected sites A-G. FIG. 5A illustrates a topographical view. In the FIGs 5A-D there are three general classes of sites. Source sites are sources of commnnir~tions.
Sink sites are users of co.. ---~ tions. Intervening sites are used to provideconnectivity between source and sink sites. For example, to transmit a communication from site A to site H, the commnnic ~tions must pass through site G. Thus, site A is the source site, site H is the sink site, and site G is the l ve~ lg site. As described above, the path information is contained in the extensions to the standard TMN model according to the preferred embo-limf nt As can be seen in FIG. 5A, the topographical view ~l~;selll~ the physical interconnectivity between the sites A-G. For example, there is a physical link 501 that connects sites A and B. Likewise, there is a physical link 502 that connects sites A and C. While, FIG. ~A presents the physical configuration of the sites A-G in the telec().. l.. ir~tions network, FIG. 5A does not illustrate the logical connections between the sites, that is what sites are actually configured to co~ ic~te with one another.
FIG. 5B illustrates a topological view of the sites A-G in the telecommllnic~tions network. The topological view provides a view of the logical connections among the sites A-G. That is, the topological view illustrates the connections between sites according to the object models stored in the ~i~t~b~e 120. The topological view is possible due to the connectivity extensions to the TMN standard discussed above. Note that the topological view intlit~to,.~ a logical link 512 between sites A and H. According to FIG. 5Athere is no physical link between sites A and ~. Therefore, assuming no errors, there must be an intervening sites to make the connection between sites ~ and H. In this example, site G is the intervening site. Thus, the logical connection 512 includes physical links 503 and 508.
The present invention includes a third view, the logical view. The logical view of the teleco~ ic~tinns network illustrates interconnectivity between particular portion of the network. For example, in the ~l~rc;lled embodiment, the logical view of the teleco.. lir~tions network illustrates the connectivity for a particular site, logical link, and/or physical link of the network. In the p~erell~d embodiment, the user selects the portion of the teleco~,...l.,-ic~ti-)ns network for which a logical view is displayed using a selection device, e.g., a well-known COlll~u~l mouse. Upon the user's selection, a display, as illustrated in FIG. SC. is presented. Using the logical WO 97131451 PCT~US97/02673 view of the network, a user can readily det~rmin~ the logical connectivity of a particular portion of the teleco.n~ ic~tions network.
FIG. 5D illustrates a rer~Lellce table that stores associations of sink, ~ source, and intervening sites. The reference table can be stored in memory.
S The reference table provides a convenient storage format for the connectivity of the telecu--------l-ications n~L~olk. The reference table is optional because all of the required information is incorporated in the records 136 in the c~t~h~e 120.
~rrors can occur if changes are made to the physical configuration of the neLw~lk without corresponding updates made to the ~1~t~ha~e. For example, the database can in-lic~t~ that there is no connection between two sites.
However, the MIB 117 can inrli~tt- that the physical network in~lie~t.os that such a connection exists. In the preferred embodiment, the physical network is taken as the true representation. In the ~ rt;ll~d embodiment, a consistency check can be performed to deL~ e is the MIB 117 differs from the ~l~t~b~e 120. The consistency check can be automatic or m~ml~lly invoked. Any differences between the MIB 117 and the worksets in the ~l~t~b~e 120 are resolved in favor of the MIB 117.
As discussed above, the multiple views provided by the (:~UI facilitate network restoration and diversity assurance. Restoration refers to repairing failed network services. Using the various views provided by the present invention, the network designer can predict where proposed implementations of the telecommunications network are likely to fail. The designer can also monitor self-restoration capabilities of the telec~ ",....~ic~ti- ns network. In the ~ led embodiment, the topological and topographical views hi~hlight failed portions of the network. This is described in more detail below.
The multiple views also facilitate meeting any diversity requirements ~ imposed by l~lw~Jlk design protocols. Diversity refers to providing more than one path of co"l.-.l.llir~tion between two sites while minimi7ing the number of common elements in the paths. By doing so, the network can restore itself in -W O 97/31451 PCTrUS97/02673 the event of a failure in one of the paths by switching in one of the other paths.
Using the selection feature, a ll~Lwolh designer can view the co~ ecLi~ity of any portion of the network as illustrated in ~IG. 5C~. The designer can then determine if diversity requirements are met.
S Due to the complexity of ll~lwolk topology, the user views can become cluttered. This results from the limited size and resolution of the display devices on which the user views are displayed. The GUI 108 of the present invention provides additional features to reduce the clutter on the screen.
One method for reducing the clutter is that the GUI 108 allows the user to zoom in or zoom out in the lleLwolh view. The zoom in provides more detail to the network engineer. The zoom out allows the network enginPer to see more of the network, but in reduced detail. In a p,er~lled embodiment, the zoom level is ~u~ollla~ic. Moreover, the detail illustrated in the zoomed view is adjusted dependent on the zoom level.
The GUI 108 also provides scalable icons. The scalable icons l~ sellL
various sites or equipments in the teleco~ ications network. The present invention scales the icons as the l~ wolk engineer zooms in (more [let~ view of the network) or zooms out (less detailed view of the network) when displaying the llelwulk. In this manner, the scalable icons retain their relative 2~) size to the network portion displayed on the network engineer's screen. This alleviates the problem of icon growth or shrinkage as the ~e~wo~k engineer zooms in or out when displaying various portions of the network.
The GUI 108 also contains a "cluster controller." The "cluster controller" determines whether too many network elements are overlapped, thereby presenting a confusing display to the network engineer. I~ such a condition is ~letrctr~l~ the "cluster controller" groups the overlapping networkelements together. The "cluster controller" then represents the grouping as a "cluster element" on the network engineer's display screen. The screen provides an in~lir~t~r that a given element is a "cluster element." The network engineer can zoom in on a "cluster element" to see the detail contained therein.

W O 971314~1 PCTrUS97/02673 The "cluster controller" function can be automatic. That is, the system can determine whether too many elements are overlapped. If the system determines that too many elements are overlapped, it autom~tir~lly creates a "cluster element" of the overlapped network elements. The d~Lt~ ation can be uased on a default value Or a user selecta'vle overlap racior.
The "cluster controller" function can also be manual. That is, the lleLwolk engineer can select an area of the network to reduce to a scalable icon.
Any network elements falling within the selected area are grouped together and represented by a "cluster element. "
The GUI 108 also includes "pseudo-points" on a line. Due to the limited resolution and size of the display device, lines, representing sepalat~
conduits in a network, may appear so closely on the display device that they appear to form a common conduit. "Pseudo points" allow a line to be represented by a point, having no signifi~ ~nre to the network, other than to move the line to make it more distinct. Thus, the "pseudo points" can be used to redraw the line for clarity, while identifying the true path of the line.
The present invention also employs an alarm focus mechanism in the GUI 108. When an alarm is generated by the teleco,.",lll~-ications network being m~n~ge-l, the system determines the area of the network that is affected.
If a portion of the physical network has failed, the failed portion can be determined by co-,llllllllic:~tion with the physical network through the CMIP
interface 121. If a simnl~ti~-n (e.g., "future" view) in~1ic:~t~s a failure, the~imnl~tion incli~tes which part of the network has failed.
The affected regions of the telec-""",.l,lic~tions network are automatically displayed to a network engineer on the GUI 108. That is, the present invention provides a zoomed in display scoped to the affected region of the ll~Lwo~k. Moreover, the affected region is in~lic~te~l on the overall network display by a small "reference window" ontlining the affected region of the network.

W O 9713145~ PCT~US97/~2673 The same m~çh~ni~m for displaying affected regions of the network is applied on a project basis against the workset manager 114. With respect to each project, the affected region of the network is displayed to the network engineer on the GUI 108. Thus, if a change in one region affects another S region, the network eng;nlo~r sees all regions affected. In this manner, the present invention makes a network engineer aware of which parts of the teleco~ ullications network a proposed design will affect.

IV. Network Management Functions and Performance Metrics Another aspect of the present invention is the p~lfbllllance of network management functions. One such network management function is ~esigning synchronization distribution in a telecoll~ .l.ir~ti~ns network. Desi~ning ~yncl~ aLion distribution according to a preferred embodiment of the present invention assures that a particular network configuration s~ti~fi-os various engineering guidelines. Such gl~ lin~s include elimin~tion of loops, 1~ traceability assurance, diversity assurance. A network loop is a connection of network equipments having the same starting and ending piece of equipment.
Loop detection refers to dete.,..illil.g the occurrence of a unique piece of network equipment more than once in a network path. Traceability requires that a particular ~l~stin~tion of synchronization be traceable to a Stratum-1 source. Diversity refers to the ability of the network to route c-).. l~llllllir~tions signals across multiple paths having the same source and destination, such that the number of common elements between diverse paths is l~lillillli~Pcl Moreover, the present invention calculates metrics to aid in performing the design functions. As described below, a Q-metric is cum~ tive quality metric that in~ tes the quality of cc~llllllllnic~ion for a given path in a network. The Q-metric depends on the physical characteristics of equipments in the path.
- Although described below in the context of network synchronizationmanagement, it would be apparent to those skilled in the art that the W O 97131451 rcTrusg7/o management functions and perform~nre metrics are applieable to management of a teleco,~ .nic~tions network in general. For example, diversity considerations can be used in any network requiring ~lt~rn~te ~l~stin~tion pathsto improve the robustness of the network's ability to restore itself. Likewise, S the Q-metrie ean be used to c~lr~ te a partieular path's e(JIllllll~ ions quality in any network model. In the context of network synchLol~dlion m~n~em~nt, a cu,l""u,"cation signal is a synchronization signal or timing signal.
As described above, the present invention allows the performance of a management function for m~n~gin~ the sync~unization distribution in a teleeommunieations network to assure that eertain engineering guidelines are s~ticfie~.
One engineering guideline is to provide a loop-free network topology.
Loops oeeur when a partieular fl~stin~tion network element beeomes its own source, usually as a result of topology ehange. This ean be detrimental to network performanee. For example, in network synehronization signifir~nt degradation of network performanee is likely to result if a synchronization signal destination eloek is the same as the synch~ ~dtion signal souree clock.
This is beeause the synchl~,ni~tion signal rlestin~tion cloek will attempt to align to the phase of its source, thereby modifying its output. This is refleeted backat the input, r~sllltin~ in additional, cllm~ tiveaLL~ to align its phase until significant deviation in output frequency occurs. The frequency deviation causes degraded service and eventually failure of the synchronized components in the network. To prevent such occurrences, the present invention provides the capability for the loop detection in a telecu"ll"ll"ic~tions network.
Loop detection analysis comprises tracing a eomml-ni~tion signal distribution to d~Le~ e whether a partieular network element is using its own output signal as a reference intput. If a partieular element uses its own outputas a reference input, then there is a loop, and the network engineer is alerted to its presence.

W O 97/31451 PCT~US97/02673 Network elements can be tagged with a unique identifil~ti~-n number in a well-known manner. Thus, the loop detection process traces a network co".,...."it~tion path to ~l~oterrninP if a particular identific~tion number appears twice, thereby indicating the presence of a network loop.
In the context of n~Lwulk syncl~Lo~ Lion management, loop ~l~tection is alternately referred to as timing loop Aet~cti-ln. When performing timing loop detection, network synchl-o~ lion elements are analyzed to determine if any loops are present. Network syncl~l-,l~i~Lion elements include any network elements responsible for network synchronization. Network synchronization elements, like network elements in general, can be tagged with a unique identification number in a well-known manner.
A second e~in~?ering guideline is assuring traceability. Traceability refers to a telecol"-",--~ tion llGLw~lk management system's ability to trace the ~1estin~tion of a c~.- .. . ,l l, .il~tion signal its source. In the ~ler~,lled embo-limf nt, the engineering guideline for traceability is back to a Stratum-1 source.
In the ~ltr~ d embodirnent, traceability is implemented in the context o~network synchl~ni~a~ion management. In this context, the co..,,~ ic~tion si~nal traced is the synchl-o~ Lion signal. In the ~l~rell~d embodiment, each user of timing must be traceable back to two primary reference sources (PRSs).
In the preferred embodiment the PRSs are Stratum-1 lefe.ellces. The system l.lol~ilols tr~e~hility by looking at the synchluni~Lion path for a particular user of timing, from the user to its timing source. The ~)lerelled embodiment requires at least two paths of PRS traceability to provide re~lllnrl~nry for quicker restoration to Stratum-1 traceability in the event of a failure of a Stratum-1 source connection In the L)lerell~d embo~limf?nt, synclllv~ inn network design occurs in three phases: (1) primary traceability to Stratum-1, (2) restoration traceability to Stratum-1, and (3) monitoring. Each PRS is directly, bi-directionally c~lnn~cted to another PRS across the network. These connections provide two functions. In the normal operating mode, each PRS monitors the other for CA 0224674l l998-08-l7 W O 97/31451 PCT~US97/02673 phase and frequency stability. In a degraded mode (e.g., when one of the PRSs loses stability), the monitored connection from the second PRS is used as an alternate reference source to restore traceability to Stratum-l. Both restoration and monitoring are thus accomplished by the same bi-directional connection.
In a similar manner, the synchronization distribution network is designed so that each SRS has reference connections to two different PRSs.
The SRS is monitored by at least one other PRS or SRS, generally one of its source PRSs. SRSs can also receive Stratum-l traceable reference sources from inte~nP~ te SRSs, following the general rules for hierarchical distribution and divt:l~iLy (dis~;ussed below~. The three design phases for SRSs generally occur sequentially.
Connections used for monitoring need not be diverse from the paths of the reference connections. The monitoring capability allows the network synchronization management system to know the performance of reference connections (the combination of the timing source and SONET connection) When referenced to the syllcl~o-,i~lion topology m~int~in~rl by the synchrolliG~lion management system, this monitoring p~lroll-lance information is used to identify degrading or failing network components quickly and generate requests for corrective action. These requests may be automated 2û actions taken by the network, notification to support technicians, or both.
Once paths having Stratum-l traceability have been defined, the network engineer can use the Q-metric (described below) to determine a priority order (described below) for the paths. That is, the network engineer can determine which path is the primary path, and which path is to be used in the event of a failure of the pl i.llaly path.
A third engineering guideline is providing diversity of network paths.
Once the telecommunications nc~Lwolh management system has determined all paths between a particular source and destination of timing, it performs a "diversity" analysis. The diversity analysis chooses paths so as to l--i,.i..-i,~ the number of comrnon network elements between them.

W O97/314SI PCT~US97/OZ673 A Q-metric is a measure of the quality of a particular path for distributing timing to a particular site. More specifically the Q-metric is a measure of the c17m~ tive phase disruption of i-~ ve~ g network elemt~nt~ in a synchlol~Lion path. Without such a metric, a network engin~er is left with little more than a guess as to which synchronization path is most probably the best. In the plerc;lled embodiment of the present invention, the Q-metric is modeled as:
Q = (q(mile~) ~rq( RE) +q(Line Timed Device)) * q(line), where:
Q is the Q-metric metric, q(miles3 is an empirically determined value corresponding to the degradation of synchronization per mile of optical fiber, q(LRE) is an empirically ~ie~ d value corresponding to ~ie.gr~ tion caused by regeneration elements along a synchronization path.
q(Line Timed Device) is a value corresponding to the accuracy of a timing source, e.g. a timing signal generator, and q(line) is an e~lui~mell~ "slack" factor that can be used to account for equipment and m~mlf~cturer degradations, e.g., optical aging.

The Q-metric can be derived for any synchronization path in a telec~ tion network. A network engineer can use the Q-metric to de~ e the best path from among several alternatives. Thus, use of the Q-metric prevents the often trial-and-error method of conventional synchronization distribution methods.
The Q-metric has 2 ~d(lition~l uses. The first use is to predict the pelr~ ance of a particular path in the n.,;wolk. The second use is to compare the predicted performance with actual performance to identify potential problems where failures are likely to occur in the network.

W O 97/31451 PCTrUS97/02673 The Q-metric as defined above can be customized. That is, a customer can adjust the various pa~ ,t~ of the Q-metric to account for other network phenomena. For exarnple, the customer can adjust the Q-metric parameters to account for synchronization topology, rather than line, effects.
Diversity considerations have higher priority than Q-metrics. That is, a path having a high Q-metric, but having an unfavorable diversity analysis is not chosen over a path having a lower Q-metric but a favorable diversity analysis. The reason is that diversity is a measure of a teleco~"~ ic~tions network's ability to repair itself in the event of a failure or degradation, whereas the Q-metric predicts performance degradation.

V. Synchronization Distribution Management Because the network management architecture 100 stores a logical representation of the physical network in the MIB 117, the network management archit~chlre 100 contains the information required to perform the management functions and calculate the performance metric discussed above.
In the preferred embo~lim~ont, the network management archit~ctl~re 100 is used to manage network synchronization, including timing distribution, timing restoration, and timing modi~lcation. As previously described, the network in which the present invention executes has SONET network elements (SNEs), timing signal generators (TSGs), and other network equipments.
FIG. 6 illustrates a simple timing distribution chain in a teleco,."-,l,nir~tions network. The timing distribution chain comprises two tirning signal generators (TSGs) 602, 608 and two SONFT network elements (SNEs) 604, 606. TSG 602 is coupled to SNE 604 via electrical connections 610a and 610b. In the preferred embodiment, the electrical connections 610a and 610b form a re~ ntl~nt pair 610. Similarly, TSG 608 is coupled to SNE
606 via electrical connections 614a and 614b. Electrical connections 614a and 614b can be a paired connection, but in general are not. The SNEs are CA 0224674l l998-OX-l7 W O 97/314SI PCTrUS97/02673 optically coupled by at least one optical connection 612. Optical connection 612 can be any optical connection including, for example, fiber optic cable.
The TSGs 602 and 608 provide timing signals to various network equipments, e.g., n~Lwoll~ e(lui~ 620. Network e~luiyln~ 620 can be one or more units of telec~ tions network equipment that require synchl-oln~aLion. The timing signals produced by TSGs 602 and 608 are electrical signals. In the preferred embodiment, these electrical signals ~;ol~fv to the well-known Digital Signal 1 (DS1) standard. The DS1 standard defines electrical signals having a 1.544 Mbit/s data rate.
In the preferred embodiment, timing signals are gt;ll~ d by oscillators in the TSGs 602 and 608. The quality, i.e., accuracy, of the timing signals generated by the TSGs 602 and 608 are defined according to Stratum-N
standards. For example, TSGs satisfying Stratum-1 requ.,~lllell~ have an accuracy of le-11 and TSGs satisfying Stratum-2 re(luhc:lllellLs have an accuracy of 1.6e-8. In the preferred embodiment, TSGs satisfying Stratum-1 requirements are (lesign~t~-l plilnaly re~erence sources (PRSs). TSGs satisfyingStratum-2 requirements are de.~ign~te-l secondary reference sources (SRSs). In the preferred embodiment, a PRS provides a reference for SRS timing signal generation. That is a PRS serves as a master clock reference to which an SRS
oscillator is locked.
Referring to FIG. 6, distribution of timing in a telecommnnic~tions network is explained. TSG 602 generates timing signal conforming to the DS1 standard. The timing signal so generated is to be distributed to the network e~ ".,~ 620. To carry a tirning signal conforming to the DSl standard, the DS1 tirning signal is tr~n~mi1te-l to the SNE 604 on lines 610a and 610b of the recl-~n-l~nt pair 610. The SNE 604 chooses one of the DS1s of the re(ll-n~l~nt pair 610 to transmit to the SNE 606. A selector switch 640 (discussed below with reference to FIG. 7A) selects the DS1 timing signal from line 610a or line 610b. The timing signal is used to generate the optical carrier rate. The optical signal stability is derived from oscillator 632 in the SNE 604. The CA 0224674l l998-08-l7 W O 97/31~51 PCTrUS97/02673 oscillator 632 drives an optical frequency generator (not shown). A selector switch 642 ((1iccns~ed below with lc~lcllce to F~G. 7B) in the SNE 606 selects the optical L~ ).c-~-ic~ion path 612. The SNE 606 generates the DSl timing signal from the incoming optical signal rate. The DSl timing signal so generated provides a lerclcllce to TSG 608. Using this reference, oscillator 636 in TSG 608 genelale~ a timing signal for network equipment 620. In this manner, the timing signal generated in TSG 602 is distributed to the network equipment 620 over the optical connection 612.
FIG. 7A illustrates a selector switch 640 in SNE 604. A similar selector switch 644 is located in SNE 606. Selector switches 640 and 644 are used to transmit timing signals over the optica} connections 612, 613, 615, and 617. The selector switch choqses one of a plurality of timing inputs to the SNE
606. FIG. 7A illustrates 8 such inputs: 2 electrical DSl inputs, 2 line side optical inputs and 4 "drop" side (tributary) optical inputs. Line side inputs and drop side inputs are well known in the art. The selector switch 640 includes a selector element 702 that is capable of selecting any of the timing inputs. The output of selector element 702 provides a reference to the oscillator 632. In the cfellcd embodiment, the oscillator 632 generates the optical frequency for tr~ncmiccion across all optical connections 612, 613, 615, and 617.
FIG. 7B illustrates selector switch 646 in SNE 606. A similar selector switch 642 is located in SNE 604. Selector switches 642 and 646 are used to receive timing signals from the optical connections 612, 613, 615, and 617.
The selector switch 642 preferably includes 2 selector elements 704a and 704b.
The selector elements can independently choose any of the inputs 612, 613, 615, and 617. In the ~lcfeLlcd embodiment, a DS1 timing signal is generated from the selected input. In other words, the selector element 704a selects an optical input e.g., 612 from which a DSl timing signal is generated. The electrical signal so generated is output from the SNE 606 on line 614a.
Likewise, the selector element 704b selects an optical input from which a DSl CA 0224674l l998-08-l7 W O 97/31451 PCTrUS97/02673 timing signal is generated. The electrical signal so ~,enelaL~d is output from the SNE 606 on line 614b.
In general, the selector switch settings are network synchronization topology dependent. That is, there is generally no default state for the selector switches. Thus, the seIector switches in an SNE must be set prior to using the SNE to distribute synchlo~ ation. The selector switches 640, 642, 644, and 646 can be initi~li7~d by a net~vork engineer. For example, in the timing distribution chain illustrated in FIG. ~, the selector switch 640 is initially set to select one of the DS1 eIectrical inputs 610a or 610b from TSG 602.
~ltern~tively, the selector switches can be ini~i~li7~1 autom~ti~ y by using a network management system (NMS) (described below).
The selector switches are remotely prograrnmable. The programmable nature of the selector switches provides high flexibility for timing distribution in a telecol""~ ic~tions network. That is during the operation of the telecommllni~tions network, a particular SNE's selector switch set up can be modified. For example, the selector position can be modified to substitute a TSG for a failed TSG to which the selector switch was originally connected.
Each SNE typically includes three or four selector switches, such as selector switches 640 and 642. A telecommllnir~tions network can have 6000 to 12000 or more SNEs. It is readily ~ a.ellL that the combinations of SNEs, each having multiple selector switches, to provide for different timing distribution paths is enormous.
Moreover, the SNEs are generally intelligent eqllipme~t. This intelligence enables an SNE to cause the selector to move to a different position in the event of a failure of a network synchronization connection or element.
That is, the intelligence allows the SNEs 604 and 606 to reconfigure themselves ~i.e., change selector positions according to a preflet~rmin~l priority) in the event of timing signal failure.
To manage the flexibility innerent in the ~.wilchhlg capabilities of the SNEs and TSGs, the management system of the present invention is required.

W O 97/31451 PCT~US97/~2673 As described above, the present invention models the SNEs and TSGs as object-oriented pro~ """i~g language objects according to the TMN standard.
The modeled objects are created from records 136 that are stored in the ~l~t~b~e ~20.
Another aspect of the present invention relates to network restoration management. As described above, SONET equipment generally does not require a separate, cle~lic~t~d co~ ullications line to carry synchluni~tion information from one site to an adjacent site because SONET links carry recoverable timing information as an inherent quality of the tr~n~miftto-l traffic bearing signals. Each SNE requiring timing generally can choose from among several incoming signals (see timing inputs in FIG. 7A) to accomplish synchlollizalion with other timing lefel~nces in the telecomml-ni~tions nelwulk. A selector switch, such as illustrated in FIG. 7A, is used to select the incoming signal from which to derive timing information.
In sum, a typical network site is conn~ct~l to many scattered adjacent sites by a mllltit~l~le of cn~ tions links. Each of the links carries a digital signal that can be used as the basis for local timing synchronization. To best assure synchronization across a large network, the timing signal generator within each site should select an incoming signal that has the closest traceability to a PRS somewhere in the network. In the event of a failure affecting the integrity of the selected syncll-ulfi~ation path, a given network site must select an alternate synchronization path that is traceable to a PRS.
Furthermore, given two synchronization paths of equal traceability to a PRS, a network site should not switch nnn~cess~rily among tne two synchronization sources. This is because every instance of switching entails a - risk of generating phase transients which can affect traffic integrity. Such phase transients can be a particularly serious problem because it may affect thetiming of numerous outgoing signals to which other sites are phase-locked. A
single timing transient, therefore, may ripple and spread throughout the network.

W O 97/31451 PCT~US97102673 One situation that can give rise to such unnecessary switching is as follows. Within a given network site, a clock selects an incoming signal A
from which to derive synchlul~iGalion. For illustrative purposes, assume that the inrornin~ signal A comes from an SRS (i.e., the incoming signal A is once removed from the network PRS). Then, due to network failure, the incoming signal A is interrupted. The network site cloc~c then picks an ~Itern~te h~coll~ g signal B upon which to ~yllcl~ . While slightly risky (due to the switching from the incoming signal A to the alternate incoming signal B) the switchover from the incoming signal A to the alternate incoming signal B is preferable to allowing the local clock to drift. Thus, the switchover is tiee-m~l n~ceSS~ry, Now assume that the alternate incoming signal B also has second-level traceability, and is essentially equivalent to the incoming signal A. Thus, whenthe incoming signal A is eventfully restored, the local clock would not benefit by reverting back to the incoming signal A. However, conventional systems, which assign a fixed order of preference among incoming signals, do revert back to the incoming signal A. As a result, conventional systems needlessly risk a phase transient in the network as the timing signal reverts back to the original incoming signal.
Another aspect of the present invention elimin~s the risk of a phase transient by using a table of selection priorities contained in each network element that is capable of syncll- oll~ation switching (i.e., capable of selecting a source of synchronization). In the preferred embodiment, each network equipment that is capable of synchronization switching stores a priority table.
The priority table contains priority values that assist in selecting the preferable available incoming signal. The priority values can be ~c~c ignP-1 so as to prevent nnn~?ce,~s~ry :jWi~chillg among signals of equal validity and traceability.
Application of the priority tables of the present invention is explained with reference to Figs. 8A-C. In FIC~s. 8A-C, the "E"n are electrical DSl inputs and the "O"n are optical inputs. Referring to FIG. 8A, a priority table W O 97/31451 PCTrUS97/02673 is shown that maps c~nrli~:3t~ synchronization inputs to an arbitrary assigned priority number. In this discussion, lower priority values inrlic~te greater pl~;r~lcllce. Greater preference can in-lic~t~d, for example, closer traceability to a PR~. The c~n~ t~o inputs in the table of FIG. 8A are analogous to the S recovered synchronization signals from the timing inputs in FIG. 7A.
By the ~c.cignm~nt of priority values as illustrated in FIG. 8A, an order of ~ler~lcllce is established. The order of plere~ ce favors ~wiLI;hillg to source El whenever possible. If a failure occurs that renders El in~cec~ible, the source E2 will be selected as the syl,dllol~i~Lion input. Detecting and locatingfailures within the networl~, and co~ -ic~ting the related failure and restoration indications is well-known to those skilled in the art. When Elis restored, the synch.:ol~lion input is (imm~ ~ly) switched back to El. I'his characteristic is referred to as "revertive" switching.
FIG. 8B contains a different ~c.cignment of priority values to selector switch positions. The dirr~le~ cc;~nm~nt causes a different switching behavior. In particular, the inputs El and E2 both have a priority value of zero. According to the priority table in FIG. 8B, if Elis selected and later fails, switching takes place to select E2 as the alLelllaLi~re synchronization source. In contrast to the priority ~c;cignm~ nt set forth in FIG. 8A, subsequent restoration of E1 does not trigger a switchover back to E1 from E2. Because E1 and E2 are equally desirable synchlul~ lion references, there is no reason to switch unless E2 fails at some later time. In this case El and E2 are said tobe "non-revertive" with respect to one another.
FIG. 8C illustrates a further variation using the priority tables to control topology. The priority ~csignm~nt in the priority table of FIG. 8C shows that (a) order of priority is independent of the input decign~tor, (b) any arrangement of priorities can be ~ccign~d, and (c) any number of non-revertive strata can beestablished by the proper assignment of priority values in the priority table.
Using the table illustrated in FIG. 8C, if inputs El, E2, 01, and 02 are unavailable, then the synchronization input is 03. If input 02 is then restored, W O 97/31451 PCT~US97/02673 no switching occurs because 02 and 03 are non-revertive with respect to one another in the table of FIG. 8C. If either E1 or E2 is restored, then switching takes place from 03 to E1 or E2, depending upon which of E1 and E2 is restored first. If all four of the original failures (E1, E2, C~1, and 02) are S suddenly restored simnlt~n~ously~ the input O1 is imm~ tely selected as the input syllcl~oni~a~ion source.
It would be ~al~:,lL to those skilled in the art that the table entries can take the form of hard-wired logic, read-only-memory (ROM) contents, or writable memory or storage data collle~ downloaded or asserted by an external neLwulk control elem~nt Fultll~lln le, the priority table contents can be altered or otherwise modulated or illl~lLJlel~d according to signals traversing the inter-site links themselves.
FIG. 9A is a flowchart 900 for hlLel~,reLing the priority table to accomplish the foregoing logical functions in accordance with the preferred embodiment. A process according to the flo~hal ~ 900 can be used to control the input selector switch 702 in FIG. 7A.
The inL~ Lillg process of the fiowchart 900 begins in step 902. In step 902, the process performs a single e~min~tion of the functional status of the inputs. Based on the ex~min~tion, the process makes a decision as to which input should be selected. This process can be triggered periodically to accomplish polling mode operation.
In step 904, the process identifies which of the inputs is ~;ul~ Lly selected as the synclll-o~ tion source. Using the priority table, the process also determines the priority value associated with the currently selected input.In step 906, all properly functioning inputs are reviewed to assess whether any candidate input has a lower priority value than the ~;ullelllly selected input. If a c~n~ input is found which is functioning properly and has a lower priority value than the currently selected input. Otherwise, if in step 906, no other functioning inputs are found to have lower priority than the -W O 97~314~1 PC~US97/0~673 currently selected input, the process continues in step 910. In step 910 the process terminates without initi~ting any switching action.
While the priority as~ignm~ont aspect of the present invention has been described in the context of directing ~yl~chlo~ alion selections within network S sites, the priority assignment feature is applicable to a variety of similar problems elsewhere in comml-ni~tions network control and in other fields.
For example, a common problem often encountered is that there are several data streams that need to be commlmir~t~o~l over a finite number of available paths. Assume that each data stream totally consumes a single path.
Also assume that, for robustness, there are a more paths than data streams.
Thus, there are spares that can be used if other paths fail. The paths can be assigned as resources according to, for example, the priority assignm~nt scheme in FIG. 8C. Each path, therefore is mapped to a corresponding priority value. The availability indicator for each path is defined to be true whenever the path is functioning properly, and is not already occupied by a data stream.
Referring to FIG. 9B, a flowchart for using the priority assignm~nt scheme of the present invention to assign priorities to available paths over which data streams are tr~n~mitted. Step 920 begins the process by looking through a list of data streams and making decisions about how to assign the datastreams to available paths. In step 922, one such data stream is selected as thecontext for processing in steps 924 through 928. If the data stream is not already ~.csign~d to a path, the priority is assumed to be a high positive valuegreater than any of the entries in the priority table.
In step 926, all of the paths that are in-lie~t~d to be available are evaluated to see if any of them have a lower priority value than is already ~ign~d to the data stream as determined in step 924. If a path with a lower priority value is found, then in step 928, the data stream is assigned to whichever available path has the lowest priority value. It is also implied that in step 928, that the newly assigned path receives an availability indicator of WO 97~1451 PCTrUS97/02673 false, whereas the previously a~eign~cl path; if any, is returned to "available"status.
In step 930, the process signifies the completion of a decision involving a single data stream. If the process, in step 928, determines that all data S streams to be ~sign~d have been subjected to the process, then execution termin~tf?~ in step 932. Otherwise, if in step 930, the process det~,.l.i.les that other data streams must be processed, then execution resumes at step 922 to select one of the rem~ining unprocessed data streams.
Applying the present invention to assignment tasks of this nature provides a m~h~nicm for establishing both priority and revertive/non-revertive relationships among dirr~.e~L selections. Moreover, during an execution of the process depicted by flowchart 918, if ~e availability in~ic~tors are all set to true and the data streams to be ~ign~l are processed in a particular sequence, the process can assign the most important data to the most desirable paths.

VI. Network Simulation FIG. 10 is a flowchart depicting a process by which the NEWS 101 creates a suitable synchronization distribution plan for a given network. The process can be undertaken in response to a Synchronization Service Request (SSR). An SSR is a notification that lists the TSGs and SNEs for which a synchlo~ tion plan must be designed. The SSR also specifies a particular date for which a data representation of the .leLw~lk is assembled. As described above, the date can correspond to a projected network configuration in the future. Thus, the data representation can include both the "current" view and one or more "future" views of the network. A network designer can invoke the process illustrated in l~IG. 10 to review or modify a network design.
Alternatively, the NEWS 101 can autom~ lly perform the process illustrated in FIG. 10 whenever the network reconfigures itself to accomplish restoration following a network failure.

W O 97/31451 PCTrUS97/02673 The process begins in step 1002. In step 1002, SSRs are received into a queue. The N~WS 101 .sim~ t~s the network as it will exist at some point in time by creating a run-time object model. As described above, the run-time object model is based upon a workset residing in the database 120. Each workset residing in the ~l~t~h~e is associated with a particular date and L~ sents the present andtor future state of the network. Each workset is a composite of numerous records in the database describing the present and planned configuration of parts of the network.
In step 1004, the NEWS 101 determines whether a workset that can adequately represent the network projected to exists as of the latest date specified in the SSRs exists in the database 120. If no such a workset is found in step 1004, then in step 1006 the workset manager 114 composes the required wo}kset from those records in the ~l~t~ace that precede the date specified by the SSRs. The records in the d~t~h~e 120 that are used to compose the required workset can reflect both current ~"current" view) and projected ("future view) network hlr~ alion. The current information is m~int~in~d by direct connection to the existing network through the TMN subsystem 104.
The process continues in step 1008, wherein an applicable workset has been found or constructed. In step 1008, a runtime object model is created based upon the applicable workset.
In step 1010, a particular SSR presented in the input queue in step 1002 is select~d for inclusion into an initial ~yllcllrol~i~Lion design. in step 1012, the process decides which of many available signals will be connected to the synchronization selector switch for each network or timing generator that has synchronization switching capabilities. In a ~ d embodiment, the process, in step 1012 also assigns the contents of the selection table to implement a desired synclll o~ aLion ~wilchil1g logic for each network el~m~ n~ and TSG thatsupports the use of a switch selection table. The connections and selection table entries determine, for example, which primary synchronization source signal a given TSG will use under normal conditions. Other such assignments can WO 97131451 PCTrUS97/02673 d~ P which alternate synchro~ ation signal can be used as a refe,t;llce if a portion of the network fails. The alternate synchl o~ lion signal is referred to as the restoration synchronization signal. Other connections can pelro~.~l a monitoring function, whereby some TSGs are coln~aled against others. In a ~l~rel,~d embodiment, the selection tables can contain priority numbers. The priority number controls revertive switching behavior according to the scheme described in Section V.
In one embodiment, a human network designer ~lÇ~ s the selection of port ~CciEnmentc in step 1012. In this embodiment, it is preferable to aid the designer by presenting some mekics that measure the desirability of c~n~ tP
sync~ ~i~Lion signals. One such metric useful in selecting synchroni7~ti~ n signals is the Q-metric described in Section V. Another useful metric is a measure of the relative path diversity among the selected patns.
While a human designer can implement reasonable connections, it is further contemplated that the selection and review of ç~n~ tP syncllloni~Lion paths can be similarly impl~mentP~ by an automatic or semi-automatic process.
The automatic or semi~ tom~tic process can operate, for example, as a data manipulating process with the NEWS 101.
In step 1014, the process determines if all queued SSRs have been included in the initial design. If there are more SSRs, the processing resumes at step 1010 to satisfy any rem~ining SSRs in the initial design. If step 1014 finds that an initial design has processed all SSRs, then a network simulation is executed in step 1016.
As is well known to those skilled in the art, the simulation step 1016 typicaIly involves the in~ "~ data objects that model the physical network, execlltin~ the simulation to allow the data objects to cim~ tf~ the behavior of actual network elements, and recording the state of the objects at increments ofsimlll~te~l time.
-W O 97/31451 PCTrUS97102673 l~uring the ~im~ tion, the ~im~ tor can continuously observe the data model for compliance with engineering guidelines. In the pler~lled embodiment, the engineering guidelines include the requirements that:

a) each SNE must be provided with a primary timing l~relellce input with traceability to a Stratum-l reference source;
b) each SNE must be provided with at least one restoration reference input with traceability to a Stratum-1 reference source;
c) primary and restoration timing paths must be physically diverse;
d) each SNE must be monitored by at least one other SNE;
e) each SNE in the hierarchy may only receive reference from an SNE
of equal or greater stratum level; and fl no SNE in the nc~lw~ can provide reference timing to itself ~i.e., no timing loops).

The process continues in step 1018. In step 1018, the si~nulation results are evaluated to determine the robustness of the design and its adherence to theabove engineering guidelines.
The process then continues in step 1020. In step 1020, the process d~L~ es whether the cimlll~tion results from steps 1016 and 1018 in~lir~t~ an adequate synchronization topology. If the simulation results are deemed to meet robustness criteria, then the process completes in step 1024. In step 1024,the synchronization plan is released for use as being a viable design.
Otherwise, if in step 1020, the sim--l~trd network is found to be inadequate, the eLw~lh is effectively rede~ignrrl by ch~nging port assignments, and the process repeats in step 1016 by starting a new simulation.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary W O 97/31451 PCTrUS97/02673 embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims (16)

What Is Claimed Is:

1. A system to manage a telecommunications network having network equipment, comprising:
a telecommunication management network (TMN) subsystem to store a run-time object model representation of the telecommunications network equipment;
a data base subsystem coupled to said telecommunications management network subsystem to provide long-term storage for records describing the network equipment and connectivity between the network equipment from which the said run-time object model representation of the telecommunications network is constructed;
a workstation coupled to said TMN subsystem on which to operate a graphical user interface (GUI) that provides a graphical representation of said run-time object model representation, and further provides access to said run-time object model representation, and on which to perform at least one network management function; and a translator coupled to said workstation and said telecommnnications management network subsystem to translate said object model representation into a form that is usable by said GUI.

2. The system as recited in claim 1, further comprising:
a first workset containing a "current" view of the network, wherein said first workset is stored in said database subsystem; and a workset manager coupled to said TMN subsystem to create a second workset from records stored in said database subsystem, wherein said second workset is stored in said database subsystem and said second workset represents a "future"view of the network.

3. The system as recited in claim 1 further comprising a view controller coupled to said GUI and to said translation device to accept a request from saidGUI and to convert said request into a command understandable by said translator to manipulate said run-time object model representation, and further to accept a results of any object model manipulation for transmission to said view controller, said view controller converting said result into said useable form for display on said GUI.

4. The system as recited in claim 3, further comprising a common management interface protocol (CMIP) interface, said run-time object model representation created from information extracted from the telecommumications network over said CMIP interface, and stored in a manner consistent with the TMN standard, but having extensions thereto for representing particular connections between the network equipment in the network.

5. The system as recited in claim 4, wherein said translator is an object request broker (ORB).

6. The system as recited in claim 5, wherein said ORB translates an object from the TMN standard, and the extensions thereto, to a common object request broker architecture (CORBA) standard compliant representation.

7. The system as recited in claim 2, wherein said at least one "future" view is indexed according to date.

8. The system as recited in claim 2, wherein said at least one "future" view is indexed according to project.

9. The system as recited in claim 1, wherein said GUI presents linked topographical and topological representations of the telecommunications network.

10. The system as recited in claim 4, wherein said particular connections are line, link, and section connections in a SONET or SDH network.

11. A method for managing a telecommunications network having a plurality of network elements comprising the steps of:
modeling the network in an object oriented-programming language using object models to create a run-time object model of the telecommunications network;
storing the run-time object model in a telecommunications management network subsystem;
providing access to the model via a graphical user interface (GUI);
translating from the object model representation stored in the management information base to a representation useable by the (GUI.

12. The method as recited in claim 11, wherein said run-time object model is modeled in accordance with the telecommunications management network (TMN) standard, but having extensions thereto to represent particular network element connections.

13. The method as recited in claim 12, further comprising the step of:
extracting information required to build said run-time object model representation across a common management interface protocol (CMIP) compliant interface;
translating said object model representation to be compliant with the common object request broker architecture (CORBA) standard; and providing run-time object model information to said GUI across a CORBA-compliant interface.

14. The method as recited in claim 11, further comprising the steps of:
modifying said run-time object model in accordance with a desired configuration of the telecommunications network at some point in the future to create a "future" view of the network; and storing said "future" view as a workset in said database.

15. The method as recited in claim 14, further comprising the step of indexing said "future" view according to date.

16. The method as recited in claim 14, further comprising the step of indexing said "future" view according to project.