1
`
`GOOGLE-1021
`Google Inc. v. Micrografx LLC
`IPR2014-00532
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 1 of 18
`
`5,726,979
`
`8—
`
`42m
`
`.32
`
`.32
`
`.Em
`
`oo—
`
`wm<m<h<c
`
`:memmzm
`
`
`
`28
`
`$8
`
`335x8
`
`mo—
`
`2
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 2 of 18
`
`5,726,979
`
`02
`
`zoo
`
`3
`
`

`

`US. Patent
`
`9
`
`f
`
`5,726,979
`
`sI
`
`
`
`
`
`20:50..menace“58058385zozuuzzoo
`
`wzzhzooIEEa%mz_<._.zooB=obcoumS¢£8
`
`
`
`
`
`wzsfizooa@528gmM$8mywz.<._.zooszEoomz_<._.zoo
`
`V2932«8
`
`fozucnsm8332
`
`
`
`xmoEmz.0:
`
`22.58
`
`-$55imwngé
`
`l.
`
`.mmoccziozozgxm
`
`.mnw2558
`
`mmEzE/m:
`Mm2_<._.zoo852.:memum:mum:
`
`
`tmm:
`
`Egomcozogsfi
`
`2.0;92“
`
`:8as$8
`
`85:58
`
`8N”gag
`
`5.0:
`
`25wow
`
`5.915%”?
`
`4
`
`
`
`
`
`
`
`

`

`US. Patent
`
`M
`
`hS
`
`n104
`
`5,726,979
`
`8NNNcoioimmcm,858?.ofSNmmomaflu
`l—ESEE?a
`
`{{unchéoozzhmc
`
`aiH
`
`mum
`
`
`
`wemummmmnm
`
`
`
`
`
`mEoEuaBquzm:#83223:Bmocozfiofimzé
`
`%
`
`tumNnN
`
`<38520553552
`
`38%..252mN.OI
`
`.‘1
`
`:5E5w:
`
`Now
`
`2928.60:
`
`2.8
`
`4
`
`:NamENanE8“
`
`4
`
`
`
`moccflgefimc85%:EE98:32.II
`
`NE
`
`5
`
`
`
`
`
`

`

`U
`
`a
`
`m
`
`M
`
`0
`
`S
`
`5,726,979
`
`a355
`
`1,s855m.ngmxmiss”.
`
`a;obeuomEmzo=<oo._mzo=<oo._co:5::82
`
`
`
`.8»,$8392
`
`mcozoomgum
`
`3mzofimwn2mamas”.man4$2:50:05::mmamas”.
`%982058503
`
`92:5559.5.
`
`mNonnow
`
`PaxSH20<x350E82ng2$9.228805.82%:
`
`maaEozfozuzUmE822mg2$885$an
`
`an
`
`zE
`
`
`
`mzofiommmzmamm
`
`
`
`mxz:mzmabm
`
`
`
`mmz:mzmzbm
`
`ég<m.o_.._
`
`6
`
`
`
`
`
`

`

`US. Patent
`
`Mar. 10, 1993
`
`Sheet 6 of 18
`
`5,726,979
`
`iocaiionDiciionary
`
`229
`
`’
`
`0
`
`OOI cmise services
`
`managedElemeniDiciionary
`
`O
`
`230
`
`nsManagedEiemeni
`A
`
`’
`
`OOI cmise services
`return Iisiofequipmeni
`/
`
`
`
`managedElemeni
`
`request iisi of equipment
`
`equipmeniDiciionary
`
`232
`
`nsSyncNeiworkElemeni
`0
`
`235
`
`nsPrioriiyLisi
`
`234
`
`nsSDHNeiworkEiemeni
`
`
`
`
`
`
`OOI cmise services
`
`00i cmise services
`
`OOI cmise services
`
`CORBA
`
`FIG. SB
`
`7
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 7 of 18
`
`5,726,979
`
`equipmentDictionory
`
`O
`
`nsEquipment
`
`00! cause servrces
`
`A
`
`A
`
` services
`
`
`
`nsEquipmentHolder
`
`equipmentHolder
`
`nsCircu'rtPack
`
`services
`
`linkDictionury
`
`.
`
`228
`
`308
`
`OOI cmlse servrces “
`
`OOI cmise services
`
`lineDictionary
`
`6 .
`
`sectionDictionary
`
`.
`nsSectronTr
`
`OOI cmise services
`
`.
`,
`sectronTraIl
`
`FIG.3C
`
`CW
`
`TMN
`
`8
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 8 of 18
`
`5,726,979
`
`Application
`
`HTML
`
`454
`
`452C
`
`UNIX/AIX
`
`Windows 32
`
`
`
`082
`
`FIG.4
`
`9
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 9 of 18
`
`5,726,979
`
`508
`
`H '
`
`
`
`FIG. SB
`
`10
`
`10
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 10 of 18
`
`5,726,979
`
`Hz_m5:mmz4”EmozEHfimm x_E.<2
`
`Hz_mbzmmmm“Emozzoflmm
`
`
`
`45.92....ozcfldm
`
`8..x2:
`
`
`
`uz.mbzmmm
`
`
`
`.2291;ozzomdm
`
`
`
`”2.$582
`
`8—x2:
`
`.2063
`
`Hz_mpgzmmmo”Emozzomdm
`
`
`
`._<o_oo._ozzbmzmm
`
`nz_mfizmmmm20:82on
`
`.228.—ozzomdm
`
`
`"2.
`
`2.381N.zozomzzoo
`
`8.0:
`
`11
`
`11
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 11 of 18
`
`5,726,979
`
`Io.._m.._momooIm
`
`*288228
`
`
`
`xii:zozomzzoogmmfiamfi
`
`
`
`mag—82%;;,momaom
`
`mmtmmEm
`
`and:
`
`<<<<QQDLLJOOOO
`
`12
`
`12
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 12 of 18
`
`5,726,979
`
`606
`
`646
`
`608
`
`Equipment
`
`620
`
`Network
`
`FIG. 6
`
`13
`
`13
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 13 of 18
`
`5,726,979
`
`
`
`.5:.255
`
`Illlllll
`
`S..2...
`
`use;
`
`£35
`
`38
`
`14
`
`14
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 14 of 13
`
`5,726,979
`
`
`
`SignalFlow
`
`FIG.TB
`
`15
`
`15
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 15 of 13
`
`5,726,979
`
`Resource
`
`Priority
`
`FIG. 8A
`
`Resource
`
`Priority
`
`
`
`FIG. 83
`
`Priority
`
`Resource
`
`E2
`
`01
`
`02
`
`03
`
`04
`
`paramo—
`
`FlG. 8C
`
`16
`
`16
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 16 of 18
`
`5,726,979
`
`902
`
`
`
`GET PRIORITY VALUE OF
`CURRENTLY SELECTED SYNCH SOURCE
`(ASSUME PRIORITY=INFINITY IF NO
`FUNCTIONAL SYNCH SOURCE
`IS CURRENTLY SELECTED.)
`
`
`
`
`
`
`
`904
`
`
`
`906
`
`IS THERE A FUNCTIONAL SYNCH
`SOURCE WITH LOWER PRIORITY?
`
`
`
`YES
`
`SWITCH TO FUNCTIONAL SYNCH
`SOURCE WITH LOWEST PRIORITY
`
`
`
`
`900
`
`FIG.9A
`
`17
`
`17
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 17 of 18
`
`5,726,979
`
`920
`
`START
`
`SELECT A DATA STREAM
`TO BE PROCESSED
`
`922
`
`
`
`GET PRIORITY VALUE OF
`
`
`CURRENTLY ASSIGNED PATH
`
`
`(ASSUME PRIORITY=INFINITY
`
`
`IF NO PATH ASSIGNED)
`
`
`
`924
`
`926
`
`
`
` IS THERE AN
`
`AVAILABLE PATH
`
`WITH A LOWER PRIORITY VALUE
`THAN THE PRESENTLY ASSIGNED
`PATH?
`
`
`
`NO
`
`
`
`
`
`
`
`
`ASSIGN DATA STREAM TO
`
`AVAILABLE PATH WITH LOWEST
`
`PRIORITY VALUE
`
`
`
`N0
`
`
`
`
`
`
`ALL DATA STREAM
`PROCESSED?
`
`
`YES
`
`918 /
`
`930
`
`932
`
`18
`
`18
`
`

`

`US. Patent
`
`Mar. 10, 1998
`
`Sheet 18 of 18
`
`5,726,979
`
`START—SYNC SERVICE
`REQUESTS(SSR'5)
`IN OUEUE
`
`‘90-’-
`
`1 004
`
`/
`
`N0
`DOES APPLICABL
`
`WORKSET ALREADY
`
`EXIST?
`
`
`1 006
`
`CREATE APPLICABLE
`WORKSET FROM
`DATABASE RECORDS
`
`CREATE OBJECT MODEL IN
`MEMORY BASED ON
`APPUCABLE WORKSET
`
`1008
`
`SELECT SSR TO BE
`INCLUDED IN SYNC PLAN
`
`
`
`
`DESIGN NETWORK —
`FOR ALL SWITCHED SYNC ELEMENTS:
`
`— ASSIGN CONNECTIONS
`
`T0 SWITCHED PORTS
`—ASSIGN SELECTION LISTS
`T0 IMPLEMENT SWITCH LOGIC
`
`"“0
`
`1012
`
`
`
`
`
`
`
`
`
`
`
`ALL SSR’s PROCESSED?
`
`YES
`
`RUN NETWORK SIMULATION
`
`EVALUATE SIMULATION RESULTS
`
`
`
`1 022
`
`1 020
`
`1024
`
`
`
`
`IS DESIGN
`REDESIGN NETWORK —
`MODIFY PORT
`ADEQUATELY
`
`ASSIGNMENTS
`ROBUST?
`
`YES
`
`RELEASE SYNCH PLAN
`
`FIG. 1 0
`
`19
`
`19
`
`

`

`1
`NETWORK MANAGEMENT SYSTEM
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`55
`
`The present invention relates generally to telecommuni-
`cations networks. More particularly. the present invention
`relates to managing a telecommunications network contain—
`ing diverse network elements conforming to a variety of
`telecommunications protocols.
`2. Related Art
`As telecommunications networks become more complex.
`telecommunication 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
`networks 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 (CMlP). Not only must a telecommuni-
`cations network management system manage diverse net-
`work elements. but it must also manage network growth
`andt'or modification. Conventional telecommunication net-
`work management systems do not provide a mechanism for
`representing the physical network in an efficient manner to
`facilitate network design and maintenance. Nor do they
`adequately provide for representing a physical network’s
`evolution to a new configuration.
`Moreover as the networks become more capable telecom-
`munication services providers are faced with increased
`service demand. Increased service demand. in turn. requires
`increased communication bandwidth. To meet the increased
`communication bandwidth requirements. many service pro
`viders have turned to optical communications. In response to
`the increased demand for optical
`telecommunications
`equipment. a number of vendors have entered the market-
`place. To allow telecommunications network designers to
`connect equipments from various vendors together into a
`heterogenous fiber optic telecommunications networks. syn-
`chronization (also referred to as timing) interconnectivity
`standards had to be developed One such standard is the
`Synchronous Optical NEIWork (SONET). An overview of
`SONET can be found in Jornv BELLAMY. DIGITAL
`'IELE’HONY, 403—26 (John Wiley & Sons. Inc. 1991). hereby
`incorporated by reference.
`A SONE'I‘ network distributes synchronization in the
`SON'ET optical signal rate. To do so. a source clock pro—
`duces an electrical
`timing signal to be distributed. The
`source clock is an extremely stable clock. Such a clock is
`generally referred to as a Stratum-l 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 SONE'I‘ transmitter. The frequency multiplier multiplies
`the timing signal to generate a derived SONET optical signal
`rate. The SONET transmitter transmits data to a SONEF
`receiver at the derived optical signal rate. The SONET
`receiver extracts the derived optical rate. The SONEI‘
`receiver divides the extracted optical rate by the multipli—
`cation factor applied by the frequency multiplier to produce
`the distributed electrical timing signals.
`SONETI‘ equipment can adapt to network equipment fail-
`ure by modifying the synchronization topology of the net-
`work. However. such modification may cause problems in
`the resulting network synchronization topology. For
`
`20
`
`5 .726.979
`
`2
`
`example. the modification can result in timing loops and loss
`of traceability to a 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 par-
`ticular piece of timing equipment is referred to more than
`once in a particular path. Apath connects a source of timing
`to a user of timing. Atiming loop can result in the complete
`loss of a particular path. This is because the path's timing
`continually tries to catch itself. eventually culminating in the
`loss of synchronization. Thus.
`it is desirable to design a
`telecommunications network that does not have timing
`loops. and that has traceability back to Stratum-l. Moreover.
`as a telecommunications network reconfigures itself to cir-
`cumvent network failures. the restored configuration must
`avoid timing loops and maintain Stratum-l traceability.
`What is required therefore is a telecommunications net-
`work management system to aid in the design and mainte-
`nance of a robust telecommunications network. The system
`should be capable of managing diverse network equipments
`conforming 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 vio-
`lating the engineering design guidelines.
`
`SUMMARY OF THE INVENTION
`
`The present invention is directed to a system and method
`for managing a telecommunications network. The system
`and method employs a network management architecture
`that provides an overlay in which network management
`functions are performed. The network management archi-
`tecture includes a workstation function subsystem that pro-
`vides a graphical user interface (GUI). a telecommunica-
`tions management network (TMN) subsystem. a database
`subsystem. and an object request broker (ORB). Using the
`GUI. a user (e.g.. a network designer) can interact with an
`object model of the physical telecommunications network.
`The TMN subsystem provides an object model of the
`telecommunications network The current configuration of
`the managed network is referred to as a “current" view. The
`object model can represent a configuration of the Ironwork
`projected to some future date. The projected configuration of
`the managed network is referred to as a “future” view. The
`database subsystem 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 suflicient flexibility
`to allow for management of a modern telecommunications
`network. The telecommunications network can contain
`diverse network equipments that conform to diifering com—
`munications protocols. The network management architec-
`ture contains a management information base. The manage-
`ment information base contains a run-time object model of
`the telecommunications network. The run—time model can
`represent the projected configuration of the network at some
`future date.
`
`The run—time object model generally conforms to the
`TMN standard. Because the TMN standard does not
`adequately 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
`
`20
`
`

`

`5.726.979
`
`3
`models allow the present invention to more realistically
`model and display the telecommunications network. Thus.
`the software architecture stores an object model represen-
`tation 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
`representation of a telecommunications 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 configu-
`rations. By so interacting. the workset manager provides the
`desired run-time model of the network to the TMN sub-
`system. Using a network management architecture designed
`according to a preferred embodiment of the present
`invention. a network designer can simulate the behavior of
`the network to proposed modifications of the network.
`Modifications include adding. removing. or changing the
`configuration of network elements. as well as modifying the
`topology of the telecommunications network. By simulating
`modifications to the network configuration. a network
`designer can study the effect of a proposed network con-
`figuration prior to physical implementation. Modifications
`can be made incrementally. e.g.. to monitor the progress of
`a proposed plan of upgrade to the telecommunications
`network. The object models can be stored and indexed
`according to project (plan of network modification) and/or
`date (network configuration at some time in the future).
`The network management architecture includes a data-
`base subsystem that provides long-term storage of records
`that are used to construct “current” and “future” views of the
`telecommunications network. Access to the database is
`provided by a set of database procedures that provide a
`standard database interface to the database subsystem
`The network management architecture also includes a
`workstation subsystem. The workstation subsystem pro-
`vides a graphical user interface (GUI). The GUI allows a
`network designer to perform network management functions
`by providing the network designer with access to the run-
`time object model representations of the telecommunica-
`tions network. The GUI includes additional capabilities for
`improving the display of the network to a user. The addi-
`tional capabilities include reducing screen clutter. displaying
`linked topological and topographical views. and network
`zooming.
`The present invention also provides telecommunication
`network management functions. One such management
`function is the design of synchronization distribution in a
`telecommunications network. The design of synchronization
`distribution includes loop detection. traceability. diversity
`assurance. and selection table initialization.
`
`Traceability refers to determining lhe somce of a particu-
`lar network communication. According to a preferred
`embodiment of the present invention. traceability is pro-
`vided through extensions to the TMN standard. In the
`context of the synchronization. the present invention allows
`a network designer to assure that a given network configu-
`ration assures traceability to a highly reliable timing signal
`source.
`
`Loop detection analysis determines whether a particular
`network element appears in a particular communication’s
`distribution path more than once. The presence of a loop in
`a synchronization path of a telecommunication network can
`result in severely degraded network performance.
`Diversity refers to providing different paths for commu-
`nication between a particular source and a particular desti-
`
`10
`
`15
`
`35
`
`45
`
`SD
`
`55
`
`4
`nation of a communication signal. In the context of the
`present invention. diversity means minimizing the number
`of common network elements in different paths between the
`source and destination of a communication signal. The
`present invention provides for diverse communication paths
`between communications sites. By doing so. the present
`invention enhances the robustness of the network to network
`failures. That is. the network can restore itself in the event
`of a failure by switching 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 equipment having
`essentially the same performance 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
`architecture to manage synchronization distribution in a
`SONET/SDH telecommunications network. The telecom-
`munications network includes tinting network elements and
`SONEI‘ network elements that derive their timing from the
`timing network elements. The system extracts requisite data
`from the physical telecommunications network to build an
`object model representation of the network. thereby model—
`ing synchronization paths between the various equipments
`included in the network. The object model representation is
`stored in a management information base (MIB) contained
`in the TMN subsystem. The database can be modified
`corresponding to changes in the telecommunications net-
`work. The system provides a GUI through which a network
`designer interacts with the object model representation to
`manage the telecommunications network.
`Further features and advantages of the invention. as well
`as the structure and operation of various embodiments of the
`invention. are described in detail below with reference to the
`accompanying drawings. In the drawings. like reference
`numbers generally indicate identical. functionally similar.
`and/or structurally similar elements. The drawing in which
`an element first appears is indicated by the digjt(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 reference to
`the accompanying drawings. wherein:
`FIG. 1A is a network management architecture for tele-
`communications network management according to a pre-
`ferred embodiment of the present invention.
`FIG. 1B is a network management system illustrated
`according to the TMN standard.
`FIG. 2A is a TMN-compliant object model representation
`of a network.
`FIG. 2B is a CORBA-compliant class hierarchy for rep-
`resenting of a network.
`FIGS. 3A—C illustrate mapping from a TMN-compliant
`object to a CORBA-compliant object.
`FIG. d is a diagram of interfaces according to a preferred
`embodiment of the present invention.
`FIGS. SA—D illustrate linked topological and topographi—
`cal network views.
`
`FIG. 6 illustrates a simple timing distribution chain in a
`telecommunications network.
`FIGS. 7A and 7B illustrate two types of selector switches
`140 and 146 used in SONET network elements.
`
`FIGS. 8A—C are resource priority assignments for a
`selector switch in a SONEI‘ network element.
`
`21
`
`21
`
`

`

`5 .726.979
`
`5
`FIG. 9A is a flowchart for interpreting a selection table
`containing priority values.
`FIG. 9B is a flowchart for assigning priorities to data
`paths to carry data streams.
`FIG. 10 is a flowchart for simulating the synchronization
`topology of a telecommunications network using the teach—
`ing of the present invention.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`Table of Contents
`
`1. Network Management Architecture for Remote Manage-
`ment of a Telecommunications Network
`II. Human-Machine Interface (HMI)
`lIL GUI
`
`IV. Network Management Functions and Performance Met-
`ncs
`
`V. Synchronization Distribution Management
`VI. Network Simulation
`1. Network Management Architecture for Remote Manage-
`ment of a Telecormnunications Network
`One aspect of the present invention provides a telecom-
`munications network management system with the capabil-
`ity to design. simulate. and modify the topology of a
`telecommunications network. In this specification. a tele-
`communications network is alternately referred to as a
`network. Using the present invention. a network engineer
`can simulate and evaluate a particular network 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 telecommunications network. An object store
`representation is a run—time object-oriented model of the
`physical telecommunications network.
`A network management architecture 100 for management
`of a telecorrununications network according to a preferred
`embodiment is illustrated in FIG. 1A. The network man-
`agement architecture 100 contains a network engineering
`workstation (NEWS) 101 and a database subsystem 106.
`The database subsystem 106 is coupled to the NEWS via
`database procedures 118. The network management archi—
`tecture 100 can optionally include a network provisioning
`workstation (NPWS) 107 coupled to the NEWS 101 via the
`database procedures 118.
`The NEWS 101 includes a workstation function (WSF)
`subsystem 102. an object request broker (ORB) 103. and a
`telecommunications management network (TMN)
`sub-
`system 104. The WSF 102 is coupled to the ORB 103 via a
`data communications network (DCN) 111 (DCNs are
`described below). In the preferred embodiment. the 'I'MN
`subsystem 104 is coupled to the ORB 103 via a telecom-
`munications management network object-oriented interface
`(TMN-001) 105. The TMN subsystem 104 is also coupled
`to a telecommunications network 150. The telecommunica-
`tions network 150 is managed by the network management
`architecture 100. The TMN subsystem 10:1 coupling to the
`network 150 is through a DCN 930 via a communications
`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 apparent to those skilled in
`the art. however. that other implementations are possible.
`
`10
`
`15
`
`25
`
`30
`
`35
`
`45
`
`55
`
`65
`
`22
`
`6
`
`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 synchro-
`nization 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 weaknesses in the synchro-
`nization distribution plan. Such simulation is described
`below in Section VI. The simulations can include scenarios
`wherein particular network equipments or communications
`links are simulated to have failed. In this manner. a network
`designer can observe the behavior of the simulation to
`predict the behavior of the physical network 150.
`The WSF subsystem 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
`network designer. Using the GUI 108. the network designer
`makes requests to the remainder of the system to perform
`network management functions. The GUI 108 also displays
`results of the requests made by the network designer. As
`described below. the GUI 108 contains routines to increase
`the utility of the displayed results to the network designer.
`According to a preferred embodiment of the present
`invention. an Object Request Broker (ORB) 103 is included
`in the NEWS 101. The OR]?- 103 permits a more generic
`interface 113 to an object model. The object model
`is
`equivalent to the run-time TMN model contained in the MIB
`117. In the preferred embodiment. generic interface 113 is a
`CORBA-compliant
`interface. and the equivalent object
`model is a CORBA-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 for low cost. non-'I'MN-compliant work-
`stations to perform the functions necessary to accomplish
`engineering functions. One such engineering function is
`synchronization distribution planning. As depicted by con-
`nection 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 between the
`GUI 108 and the ORB 103. The view controller 110 trans—
`lates network management requests from the GUI 108 into
`CORBA-compliant object requests. The CORBA-compliant
`object requests are transmitted to the ORB 103 over the
`interface 113. The view controller 110 also translates
`CORBA—oompliant result data transmitted 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 network
`designer.
`An example of a ”PLAN-compliant object is illustrated in
`FIG. 2A. It would be apparent to those skilled in the art that
`the object represented in FIG. 2A conforms with standard
`TMN objects (as defined in the International Telecommu-
`nication 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 network configuration. One syncNetworkMan—
`aga 202 is instantiated for each subnetwork in the network
`150. The pathTraceController 204 determines a path
`between two elements. The path'Itace 206 is a single path
`
`22
`
`

`

`5 .726979
`
`7
`that connects a given pair of network elements. The
`objectsInPath 208 contains a list of intervening 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 preferred embodiment that deserves note. The
`trail class in standard TMN does not provide a mechanism
`whereby trails can be contained within a trail. This presents
`a problem when trying to model SONEI‘ networks. This is
`because although SONEI‘ links. lines. and sections are most
`readily modeled by the TMN nail class. SONET links. lines.
`and sections can contain one another. That is. a SON'ET link
`can contain one or more SONEI‘ lines. Moreover. a SONET
`line can contain one or more SONET sections. Such mod-
`eling was not possible in standard TMN.
`To overcome this problem. the preferred embodiment
`uses a trail class that has been modified from the TMN
`standard The modified trail class is illustrated in FIG. 3A.
`Referring to FIG. 3A. the modified trail class 306 has three
`child classes: an sdhLink class 308. an sdhLine class 310.
`and an sthection class 312. The sdhLink class 308. sdhLine
`class 310. and sthection class 312 each have the structure
`required to allow containments of the appropriate classes.
`Thus. the sdhLink class 308 can contain line objects and the
`sdhLine 310 can contain section objects. Such containment
`is not available in the TMN standard because the standard
`trail class does not provide for containment of trail objects.
`FIG. 23 illustrates a class hierarchy for a CORBA-
`cornpliant object representation of a telecommunications
`network. Referring to FIG. ZB. the classes of the CORBA—
`compliant object are explained The somLMCollectible
`202 class is the base class for all the other classes in FIG. 2B.
`The somf__MCollectible class 202 allows for all other
`classes to exist in the memory of a processing system. for
`example. 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 net-
`work 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 longitude data. The ns'I‘MNOOlThread Class
`208 maintains a connection between a CORBA-compliant
`object model and a corresponding TMN-compliant object
`model. The ns'IWOOII‘hread class 208 can contain an
`object reference or “handle” that allows a CORBA-
`compliant object model and a corresponding TMN—
`compliant object model to communicate. The nsDName
`class 210 holds a unique distinguished name for an object in
`accordance with TMN standards. The nsGeoLink class 212
`and the nsGeoNode class 214 handle graphical rendering of
`communications links and communications equipments for
`presentation 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 (I‘SGs) for each of several locations. The
`nsSycnPlan class 222 is essentially a name placeholder to
`identify a particular synchronization plan. Instances of the
`nsProject class 218 and the nsSyncPlan class 222 can
`contain multiple instances of one another.
`The nsPersistanoe class 224 handles local persistent data.
`Such data includes. for example. user preferences.
`
`8
`The nsTMNTop class 226 is a base class for all CORBA
`classes that have counterparts in the TMN class hierarchy
`(described in FIG. 2A). In keeping with theTMN 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 instantiated. the
`nsLink class 228 represents a particular communications
`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 excep-
`tions. The nsManagedElement class 230 is further divided
`into two child classes: the nsSyncNetworkElement class 232
`and the sthE 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 tithing 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.
`instantiation. and deletion of worksets.
`By mapping objects from TMN-compliant objects to
`CORBA-oompliant objects. the object broker 103 provides
`the interface between the TMN subsystem 104 and the WSF
`subsystem 102. It would be apparent to those skilled in the
`art that the object broker of the present invention can be
`designed to map between any two object protocols. Thus. the
`present invention is not limited to mapping 'I'It/[Nwompliant
`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
`instantiated classes in the CORBA domain and those in the
`TMN domain. In the preferred embodiment this mapping is
`performed by the ORB 103.
`In FIG. 3A. an instance of the ns'I‘MNOOl'I‘hread Class
`208 in the CORBA domain establishes and maintains a
`connection with an OOIProxyAgent class 302 in the TMN
`domain. The nsTMNOOIThread 208 Class establishes the
`connection. The nsTMNOOl'I‘hread class 208 then main.
`tains a handle that is necessary for subsequent use of the
`established connection. All subsequent communications
`between the CORBA object model and the TMN object
`model are achieved through this connection. and further.
`must involve an nsTMNOOII‘hread class 208 function to
`obtain the correct handle.
`A conventional approach for mapping two object class
`hierarchies to one another is to arrange the two class
`hierarchies similarly in terms of lineage and functionality.
`Then each instance of a class in one hierarchy can maintain
`a pointer to reference its counterpart object in the other
`hierarchy. For example. in the well-known model~view-
`controller paradigm. a division is made between classes that
`represent a data model and classes that are used to graphi—
`cally render the d