MXPA98006793A - Handling system - Google Patents

Abstract

The present invention relates to a system and method for managing a telecommunications network. The system and method employ a network management architecture that provides a deployment where network management functions are to be 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 telecommunications network management system (104) that provides a model object of the network that includes the object models of the network equipment and the connectivity between the equipment, a database system (106) that stores the "current" views and "future" of the network and an object request broker (103) that transfers the object of a first object-oriented paradigm to a second object-oriented paradigm, to be used by the GUI (108). The network management architecture facilitates the design of the network by determining the performance metric of the network.

Description

NETWORK MANAGEMENT SYSTEM V - BACKGROUND OF THE INVENTION Field of the Invention 5 The present invention relates generally to telecommunications networks. More particularly, the present invention relates to the management or monitoring of a telecommunications network containing various network elements that conform to a variety of telecommunications protocols.

Related Technology As telecommunication networks become increasingly complex, service providers of the telecommunications network require an increasing capacity in their network management systems. Network management systems face considerable barriers in the acceptance by network system providers. One of these barriers is that the The network management system has to manage networks comprised of network equipment that comply with a variety of interface standards. An example of an interface standard is the well-known Common Management Information Protocol (CMIP). The network management systems of telecommunications must not only handle various elements P151S / 98MX network, but also must handle the growth and / or modification of the network. Conventional telecommunications network management systems do not provide a mechanism to represent the physical network in an efficient way that facilitates the maintenance and design of the network. Nor do they adequately provide the representation of a physical evolution of the network to a new configuration. In addition, as networks become more capable telecommunications services, providers are faced with an increasing demand for the service. The increasing demand for the service requires, in turn, a greater communication bandwidth. To meet the requirements of a greater communication width, many service providers have resorted to optical communications. In response to the increasing demand for optical telecommunications equipment, many vendors have entered the market. To allow telecommunication network designers to connect equipment from multiple vendors together in a heterogeneous fiber optic telecommunications network, interconnectivity synchronization standards (also referred to as timing) must be developed. One of these standards is the Synchronous Optical Network (SONET Synchronous Optical Networks). An overview of SONET can be found in the P1516 / 98MX book JOHN BE LAMY, DIGITAL TELEPHONY, 403-26 (John Wiley &Sons, In. 1991), which is incorporated herein by reference. A SONET network distributes synchronization to the optical signal rate SONET. To do so, a source clock produces an electrical timing signal that will be distributed. The source clock is an extremely stable clock. This clock is usually referred to as the Stratum-1 source. A Stratum-1 source is a fairly reliable timing source (which has an inaccuracy of free run of the order of one part in 10). The electrical timing signal is fed to a frequency multiplier on a SONET transmitter. The frequency multiplier multiplies the timing signal to generate a derived SONET optical signal rate. The SONET transmitter transmits data to a SONET receiver at the derived optical signal rate. The SONET receiver extracts the derived optical speed. The SONET receiver divides the extracted optical speed between the multiplication factor applied by the frequency multiplier to produce the distributed electrical timing signals. The SONET device can adapt to the failure of the network equipment by modifying the synchronization topology of the network. However, this modification may cause problems in the topology resulting from synchronization of P1516 / 98MX network. For example, the modification may result in loops or timing circuits and loss of the possibility of tracking to a Stratum-1 source. Modern networks ensure the possibility of tracking the backward timing to a Stratum-1 source to ensure the stability of the timing. A circuit or timing loop occurs when a particular piece of timing equipment is referred to more than one particular path. A path connects to a timing source with a timing user. A timing circuit can result in the complete loss of a particular path, this is because the timing of the trajectory continuously tries to reach itself, eventually culminating in the loss of synchronization. In this way, we want to design a telecommunications network that does not have timing circuits and that has backtracking capabilities to the Stratum-1. In addition, as the telecommunications network reconfigures itself to avoid network failures, the established configuration must bypass the timing circuits and maintain the tracking capability of the Stratum-1. What is required is, therefore, a telecommunications network management system to help the P1516 / 98MX design and maintenance of a rugged telecommunications network. The system must be capable of handling various network equipment that conforms to a variety of interface standards. The system must also be able to determine the current state of the network, restore it to a state that satisfies various engineering design guidelines. The network management system must be flexible enough to allow updates (ie the addition of new equipment and changes to the network topology) without violating the engineering design guidelines.

SUMMARY OF THE INVENTION The present invention is directed to a system and method for the management of a telecommunications network. The system and the method employ a network management architecture that provides a deployment in which network management functions are developed. The network management architecture includes a workstation function subsystem that provides a graphical user interface (GUI), a telecommunications network management subsystem (TMN), a database subsystem, and a messenger (known simply as as ORB -Object Request Broker- program designed to transparently manage communication and operation between local objects and P1516 / 98MX away). Using the GUI, a user (eg, a network designer) can interact with an object model of the physical telecommunications network. The TMN subsystem provides a model object of the telecommunications network. The current configuration of the managed network is referred to as the "current" panorama. The object model can represent a configuration of the network projected to a certain future date. The projected configuration of the managed network is called the "future" scenario. The database subsystem stores records that are used to build the "current" and "future" panoramas of the network. The ORB correlates the objects from a first object-oriented paradigm to a second object-oriented paradigm, to be used by the GUI. One aspect of the present invention is a novel network management architecture that provides sufficient flexibility to allow handling of a modern telecommunications network. The telecommunications network can contain various network equipment that conform to different communication protocols. The network management architecture contains a database of management information. The administration information base contains a run-time object model of the telecommunications network. The kind of P151S / 98MX run time may represent the projected configuration of the network at a certain future date. The run-time run time object model in general conforms to the TMN standard. Since the TMN standard does not adequately model the physical connectivity of the network (e.g. tracks or traces of path between network elements), the present invention includes extensions to conventional TMN object models. Extensions to conventional TMN object models allow the present invention to have a more realistic model and deploy the telecommunications network. In this way, the software architecture stores a representation of the model object of the physical network. The representation of the stored object model represents the current configuration of the network or the configuration of the network projected towards a certain future date. In this specification, a network model representation of a telecommunications network also refers to an object store or a work equipment. The present invention also provides an administrator or work team manager. The work team administrator interacts with a database that has records that are used to build various network configurations. By interacting in this way, the work team administrator provides the P1516 / 98MX d desired model of run time from the network to the TMN subsystem. 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. The modifications include adding, removing or changing the configuration of the 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 configuration before the physical implementation. Modifications can be made in increasing amounts, for example, to monitor the progress of a proposed plan to up the communications network. The object models can be stored and indexed according to the project (network modification plan) and / or (network configuration at a certain time in the future). The network management architecture includes a base subsystem that provides storage of long-term records that are used to build "current" and "future" panoramas of the telecommunications network. Access to the base is provided by a set of base procedures that provide a standard base interface to the base subsystem. :? 15ie / 98MX The network management architecture also includes ur. workstation subsystem. The workstation subsystem provides a graphical user interface (GUI). The GUI allows a network designer to perform network management functions by providing the network designer with access to model representations of run time object of the telecommunications network. The GUI includes additional skills to improve the deployment of the network to a user. Additional skills include reducing screen noise suppression, displaying linked topological and topographic views, and extending the network. The present invention also provides telecommunication network management functions. One of these management functions is the design of the distribution of: synchronization in a telecommunications network. The design of the synchronization distribution includes loop or circuit detection, tracking capability, diversity assurance, and selection box initialization. Tracing capability refers to the determination of the source of a particular network communication. According to a preferred embodiment of the invention, the tracking capability is provided through: extensions to the TMN standard. In the context of P1516 / 98 X synchronization, the present invention allows a network designer to ensure that a specific network configuration ensures the tracking capability towards a reliable timing signal source. The loop or loop detection analysis determines whether a particular network element appears in a communication distribution path more than once. The presence of a circuit in a synchronization path of a telecommunication network can result in a fairly degraded network performance. Diversity refers to providing different paths for communication between a particular source and a particular destination of a communication signal. In the context of the present invention, the diversity means decreases the number of common network elements in different paths, between the source and the destination of a communication signal. The present invention provides various communication paths between communication sites. In doing so, the present invention improves the resistance of the network to faults. In other words, the network can also be reset in the event of a failure by switching to a work path. The priority in the context of the present invention relates to the restoration of the network. The present invention incorporates a novel scheme of P1516 / 98MX priority to avoid unnecessary and potentially harmful changes or switching between network equipment that has essentially the same performance characteristics. The new priority scheme assigns equal priority levels to equipment for which no change or switching is desired. Another aspect of the present invention uses the software architecture to handle the timing distribution in a SONET / SDH telecommunications network. The telecommunications network includes timing network elements and SONET network elements that derive their timing from the timing network elements. The system extracts the required data from the physical telecommunications network to build a representation of the model object of the network, thus modeling the synchronization trajectories between various equipment included in the network. The representation of the object model is stored in a management information base (MIB) contained in the TMN subsystem. The database can be modified correspondingly to changes in the telecommunications network. The system provides a GUI through which a network designer interacts with the representation of the object model for the management of the telecommunications network. Other features and advantages of P1S16 / 98MX invention as well as the structure and operation of various embodiments of the invention are described in more detail below in relation to the accompanying drawings. In the drawings, the numbers indicated are generally retained, when a similar function is presented and / or when structurally similar elements are involved. The drawings in which an element appears for the first time are indicated by the numbers to the left of the two numbers to the right in the corresponding reference number.

BRIEF DESCRIPTION OF THE DRAWINGS OR FIGURES The present invention will be described in relation to the accompanying drawings, wherein: Figure IA is a network management architecture for the management of telecommunication networks according to the embodiment of the present invention . Figure IB is a network management system illustrated according to the TMN standard. Figure 2A is a representation of the object model that complies with TMN, of a network. Figure 2B is a class hierarchy that complies with CORBA, to represent a network. Figures 3A-C illustrate a mapping or mapping of an object that meets TMN to an object that meets P15I6 / 98MX with CORBA. Figure 4 is an interface diagram according to the preferred embodiment of the present invention. Figures 5A-D illustrate linked topographic and topological network views. Figure 6 illustrates a simple timing distribution chain in a telecommunications network. Figures 7A and 7B illustrate two types of selector switches 140 and 146 used in the SONET network elements. Figures 8A-C are resource priority assignments for a selector switch in a SONET network element. Figure 9A is a flow chart for interpreting a selection box containing priority values. Figure 9B is a flowchart for assigning priorities to the data paths to carry data streams. Figure 10 is a flow diagram for simulating the synchronization topology of a telecommunications network using the teachings of the present invention.

P1516 / 98MX DETAILED DESCRIPTION OF THE PREFERRED MODALITIES INDEX I. Network Management Architecture for the Remote Management of a Telecommunication Network 14 II. Human-Machine Interface (HMI) 36 III. GUI 39 IV. Network Management and Performance Metric Functions 48 V. Synchronization Distribution Management 58 SAW . Network Simulation 74 I. Network Management Architecture for the Remote Management of a Telecommunication Network One aspect of the present invention provides a telecommunications network management system with the ability to design, simulate and modify the topology of a telecommunications network. In this description, a telecommunications network is alternatively also referred to as a network. By using the present invention, a network engineer can similar and evaluate a particular network topology, before physically modifying the topology of the network. This is achieved by developing network management functions in an object store representation (described below) of the telecommunications network. An object store representation is an object-oriented time-of-run model P: L516 / 98 X of the physical telecommunications network. A network management architecture 100 for managing a telecommunications network according to a preferred embodiment is illustrated in Figure IA. The network management architecture 100 contains a network engineering workstation (NEWS) 101 and a database subsystem 106. The database subsystem 106 is coupled to the NEWS by means of database procedures 118. The network management architecture 100 may optionally include a network proportion workstation (NEWS) 107 coupled to the NEWS 101 by the database procedure 118. The NEWS 101 includes a workstation function subsystem 102. (WSF), a messenger (ORB) 103 and a telecommunication network management (TMN) subsystem 104. The WSF 102 is coupled to the ORB 103 via a data communications network (DCN) 111 (the DCN is described below). In the preferred embodiment, the TMN subsystem 104 is coupled to the ORB 103 via an object oriented interface (TMN-OOI) 105 of the telecommunications management network. The TMN subsystem 104 is also coupled to a telecommunications network 150. The telecommunications network 150 is managed by the network management architecture 100. The TMN subsystem 104 is coupled to the network 150 through a DCN 930 by a :? 1516 / 98MX interface 121 that complies with the communication management interface protocol (CMIP). One of these interfaces that complies with the CMIP is a well-known management interface, which represents a well-known common management interface change element (CMISE). 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 evident to those with expertise in this field that other implementations can be made. For example, each subsystem 102, 104 and 106, and the ORB messenger 103 can be executed on a separate computing platform. The NEWS 101 is used to help design the synchronization distribution plan for a network. Specifically, the NEWS allows the selection of loop-free, diverse and viable trajectories for the timing, reset and monitoring distribution. The NEWS 101 develops simulations of the behavior of a proposed network to discover the weakness in the synchronization distribution plan. This simulation is described below in Section VI. The simulations can include scenarios in which the communications links or particular network equipment are simulated in a failed state. In this way, the network designer can observe the behavior of the simulation for P: .516 / 98 X predict the behavior of the physical network 150. The subsystem WSF 102 is coupled to the ORB 103 through a DCN 111. The subsystem WSF 102 contains a graphical user interface (GUI) 108 and a controller of observation 110. The GUI 108 provides an user-friendly interface for the user, for a network designer. Using the GUI 108, the network designer makes requests to the rest of the system for the performance of network management functions. The GUI 108 also displays results of the request made by the network designer. As already described, GUI 108 contains routines to increase the use of the results displayed to the network designer. According to a preferred embodiment of the present invention, an ORB 103 messenger is included in the NEWS 101. The ORB 103 allows a more generic interface 113 with an object model. The object model is equivalent to a run time TMN model contained in the MIB 117. In the preferred embodiment, the? Jenary interface 113 is an interface that complies with CORBA and the equivalent object model is an object model that meets with CORBA. The example of this CORBA-compliant interface includes the well-known SOM and DSOM interfaces of IBM Corp. The use of ORB 103 allows workstations below cost that do not comply P1516 / 98MX TMN perform the necessary functions to achieve engineering functions. One of these engineering functions is the planning of synchronization distribution. As illustrated by the connection 130, a workstation can generally access the TMN domain 116 through an interface that complies with CORBA, provided by 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 through a connection through the DCN 111. The observation controller 110 provides an interface between the GUI 108 and the ORB 103. The controller Observation 110 moves network management requests from GUI 108 to object requests that comply with CORBA. The object requests that comply with CORBA are transmitted to the ORB 103 on the interface 113. The observation controller 110 also transfers the resulting data that complies with CORBA transmitted from the ORB 103, on the interface 113, to displayed data that is useful by the GUI 108 so that they can be deployed to a network designer. An example of an object that complies with TMN is illustrated in Figure 2A. It will be evident to those with expertise in this field that the object represented in the P1516 / 98MX Figure 2A complies with standard TMN objects (as defined by the International Telecommunication Union (ITU) M.3xxx Recommendations with the exception of syncNetworkManager 202, pathTraceController 204, PathTrace 206, and objectsInPath 208. syncNetworkManager 202 contains all network configuration A syncNetworkManager 202 instantiated in each subnet of network 150. PathTraceController 204 determines a path within the two elements PathTrace 206 is a single path that connects a specific pair of network elements The objectsInPath 208 contains a list of intervening objects (representing other elements of the network), in a particular path between a specific pair of network elements There is another deviation from the standard TMN object model in the preferred mode that is worth worth mentioning.The class of track in the standard TMN does not provide a mechanism by which the tracks can be c ontenidas within a track. This presents a problem when trying to model SONET networks. This is because although SONET links, lines and sections are easily modeled by the TMN track class, SONET links, lines and sections can contain each other. In other words, a SONET link can contain one or more SONET lines. In addition, a SONET line may contain one or more sections P1516 / 98MX SONET. This modeling is not possible in the standard TMN. To solve this problem, the preferred mode uses a track class that has been modified by the TMN standard. The modified track class is illustrated in Figure 3A. Referring to Figure 3A, the modified track class 306 has three child classes: a sdhLink class 308, a sdhLine class 310 and a sdhSection class 312. The sdhLink class 308, the sdhLine class 310 and the sdhSection class 312 have, each one, the structure required to allow them to contain the appropriate classes. In this way, the sdhLink class 308 can contain line objects and the sdhLine 310 can contain section objects. This containment is not available for the TMN standard since the standard track or trail class does not provide containment of track objects. Figure 2B illustrates a class hierarchy for a representation of an object that complies with CORBA in a telecommunications network. Referring to Figure 2B, the classes of the objects that comply with CORBA are explained. The somf_MCollectible class 202 is the base class for all the other classes in Figure 2B. The somf_MCollectible class 202 allows all other classes to exist in the memory of a processing system, for example, in the form of a similar data structure or linked list. The nsTop 204 class is P1516 / 98MX a base class for all object classes of network object model. The nsTop 204 class contains functions for the creation and cancellation of distributable network object model objects in both the client and the server. The nsTop 204 class also implements general security and authorization functions that are common to all lower hierarchy classes. The class nsLatLong 206 represents a data item of latitude and longitude. The class nsTMNOOIThread 208 maintains a connection between an object model that complies with CORBA and a corresponding object model that complies with TMN. The nsTMNOOIThread 208 class can contain an object reference or "latch" that allows the object model that complies with CORBA and an object model that complies with the corresponding TMN to communicate. The nsDName 210 class retains a unique distinguished name for an object according to the TMN standards. The nsGeoLink 212 class and the nsGeoNode 214 class handle communications link graphics and communications equipment to be presented on a geographic map, for example. The class nsDBTop 216 and its child classes (class nsProjet 218, nsTSGPlan 220, and nsSyncPlan 222) are included for practical reasons to store project and plan information in database 120. An example of class nsProjet 218 retains a list from P1516 / 98MX locations that are involved in a specific project. The TSGPlan 220 class contains a list of all the synchronization signal generators (TSGs) for each of the various locations. The nsSyncPlan 222 class is essentially a name keeper to identify a particular synchronization plan. The examples of class nsProjet 218 and class nsSyncPlan 222 can contain several instances of each other. The nsPersistance 224 class handles local persistent data. This data includes user preferences, for example. The class nsTMNTop 226 is a basic class of all CORBA classes that has counterparts in the hierarchy of the TMN class (described in Figure 2A). By retaining the TMN concept of having a unique distinguished name for all TMN objects, the nsTMNTop class 226 joins an nsDName 210 class to each instantiation of a CORBA class. The nsLink 228 class is analogous to the link class TMN. Upon instantiation, the nsLink class 228 represents a particular communications link in a managed network. The nsLocations class 229 is analogous to the well-known TMM location class. The rest of the classes derived from nsTMNTop 226 correspond essentially to the similar classes of the hierarchy of the TMN class. However, there are some P15] S / 98MX as many notable exceptions. The nsManagedElement class 230 is further divided into two daughter 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 already described, the switch selector table selects which of the plurality of timing reference signals to be used. The nsNetworkManager 238 class provides general services for the operation of NEWS 101 on the CORBA side. This function can include: create, instantiate and cancel work teams. When mapping objects from objects that comply with TMN to objects that comply with CORBA, 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 subject corridor of the present invention could be designed to map or correlate between any of the two object protocols. Therefore, the present invention is not limited to the mapping or mapping of objects that comply with TMN to objects that comply with CORBA. The present invention can however be used for the interface to other object domains. Figures 3A-C illustrate mapping or correlation P15: .6 / 98MX between the classes presented instantaneously in the CORBA domain and those in the TMN domain. In the preferred embodiment this correlation is performed by ORB 103. In Figure 3A, an occurrence of the nsTMNOOIThread 208 class in the CORBA domain establishes and maintains a connection to an OOIProxyAgent 302 class in the TMN domain. The nsTMNOOIThread 208 class establishes the connection. The class nsTMNOOIThread 208 then maintains a handle that is necessary for the 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, in addition, must involve a function nsTMNOOIThread 208 class to obtain a correct latch. A conventional approach for the mapping of two object class hierarchies to each other is to arrange the two class hierarchies similarly in terms of lineage and functionality. Then, each occurrence of a class in a hierarchy can keep a pointer referring to the counterpart object in the other hierarchy. In the well-known paradigm of the model-observation-controller, a division is made between the classes that represent a model of data and classes that are used to make the data model graphically. The data model is a hierarchy of classes that can manipulate data P1516 / 98MX in memory. The observation hierarchy contains functions for data deployment. Each model and its corresponding appearance keeps pointers or references related to each other. If the appearance of the data model changes state, it requires the appearance of the corresponding observation model to change its graphic appearance. If a user acts on the graphical representation, the observation occurrence can notify that the data model changes its state. If a user simply moves the graphical representation without otherwise altering the state, then the observation occurrence can operate without requiring any function in the corresponding data occurrence. In this way, to correlate an object model that complies with TMN or an object model that meets CORBA, the conventional approach shows the construction of a CORBA class hierarchy in the same way that the TMN class hierarchy is established. Subsequently, each CORBA object is made to retain a reference with its counterpart in the TMN object model. Referring to Figures 3B and 3C, much of the CORBA objects illustrated there achieve the reference, containing a distinguishing name for its counterpart TMN. Normally, a function invoked within a CORBA object will simply involve calling a similar function in the TMN object P1516 / 98MX that is identified by the distinguished name. Passing the distinguished name TMN allows the TMN domain to have easy access to the desired object from the requirement of the function. Although the conventional model-observation-controller works well for some object maps or mappings, other object mappings are better adapted to a different scheme. The present invention achieves several advantages by showing new approaches for mapping or mapping from one object domain to another. A novel object for mapping or correlation is the use of a dictionary class in the CORBA domain. This is illustrated in Figure 3A. For example, the class nsNetworkManager 238 contains exactly one class lccationDictionary 304. The class locationDictionary 304 contains a list of entries. Each entry matches a distinguished name of the TMN object with a pointer to a CORBA domain object. The entries can be retrieved by the single function requirement in the TMN domain. The requirement of a single function requires a list of all locations. By invoking this single-function requirement, the object model that complies with TMN searches through all objects in a hierarchy of object models that comply with TMN to derive and P1516 / 98MX return the requested list. The other dictionary classes illustrated in the model that complies with CORBA, are populated with a similar procedure. The use of a dictionary class on the CORBA side provides practical advantages in performance and flexibility. For example, in many cases an activity in an object model that complies with CORBA is directed to a subset of all the locations. By using a CORBA domain dictionary to "shadow" the TMN list of locations, an interrogation function on the CORBA domain side can effectively derive a subset of locations from the locationDictionary class 304. Having done this, additional processing on the CORBA side can Then extract the distinguished name for each entry. Subsequently, the appropriate TMN requirements are made by passing the distinguished name extracted to the TMN side. This method can be considerably faster than determining the subset of locations on the TMN side. An additional advantage of this approach is that a workstation developer that must interface with the object model that complies with CORBA, does not have to bother having to understand or write instructions and iterate through the objects that TMN complies with. . An additional advantage of this approach is that P1516 / 98MX some function applied to the objects in the CORBA domain will not be able to affect a similar function in the corresponding objects on the side of the TMN domain. For example, you want a "create" or "cancel" function on the CORBA domain side to cause the creation or cancellation of the CORBA objects, but not have an equivalent effect on the TMN domain side. Another novel approach in the CORBA-TMN correlation of the present invention is that object model classes that comply with CORBA do not have a hierarchy that resembles the object model hierarchy that complies with TMN. In contrast, object model classes that comply with CORBA are sufficiently granular to conform to the object model that complies with TMN. In this way, if an object model that complies with TMN changes, the object model that complies with CORBA can continue to operate without being redesigned. This solves a problem with the conventional model-observation approach, where changes in the hierarchy of the object model class that complies with TMN would normally require the arrangement of the corresponding object model hierarchy that corresponds to CORBA. Returning to Figure 1, the TMN subsystem 104 is an object-oriented processing environment for monitoring and managing a network. The TMN 104 subsystem P1516 / 98 X consists of a TMN domain 116 and a work team administrator or administrator 114. The TMN 116 domain can receive notifications of events, for example alarm indications, directly from the NEs handled, by the DCN 127. The TMN 116 domain can also request information from remote NEs. These functions allow the TMN domain 116 to retain an accurate representation of the configuration and state of the network 150 being administered. The network equipment administrator 114 coordinates the storage and retrieval of work equipment from a data base 120. A work equipment is a data set that is used to create a TMN object model of the network under management, as it currently exists and / or the network managed as projected will exist on a particular date in the future. In general, the database 120 stores several registers 136 that relate to the current state and topology of the managed network. This information allows the network management architecture 100 to create a "current" observation of the network. A "current" observation model represents the network as it is currently configured. In the preferred embodiment, registers 136 may also store information that is related to P1516 / 98MX future projections of topology, equipment and configurations within the managed network. This information allows the network management architecture 100 to create "future" observations of the managed network for a user. A "future" observation model represents the network as it is projected to exist at a future date. The "future" observation can be used to simulate a variety of "current" observation modifications, including the addition of equipment to the telecommunications network and the cancellation of telecommunications equipment, and modifications to equipment configuration of existing network. For example, to create a "future" observation for the addition of a new piece of equipment to the telecommunications network model, the network designer creates a new record in the database 120 that describes the equipment. The work team administrator 114 can then use the new record to create a work team that incorporates the new equipment model into the network model. The network designer can then simulate the network operation to determine the effect of the modification of the telecommunications network 150, without having to physically modify the network 150. The registers 136, stored in the database 120, can be added or modified automatically P1S1S / 98MX by the network management system. Alternatively, records 136 can be created or modified by a human network design engineer, who has specific knowledge about the current or planned aspects of the managed network. All accesses to database 120 are made through a single set of database procedures 118. Database procedures 118 are involved in accessing the data. The database procedures 118 also ensure the integrity of the database 120. In this way, the administrator of the work team 114 interfaces the database 120 through the database procedures 118, by means of a standard database query format. This database query format, for example, is the well-known structured query language (SQL). The work team administrator directs the compilation of the work teams 138 according to the information contained in the registers 136. In a preferred embodiment, each work team 138 is a culmination of all the database records that describe the network until a particular date and even on that date. For this reason, unique work teams 138 are indexed by the date to which they belong. The TMN 116 domain, the computer administrator of P1516 / 98MX work 114, the database procedures 118 and the database 120 are considered as part of the network management layer (NML). The NML is defined by the TMN standard. In addition to the NEWS 101, other systems or management workstations 140 may use the same components as the NML. For example, a network providing workstation (NPWS) 107 may be coupled to the database procedures 118 to provide access to the database 120. In a preferred embodiment, the NPWS 107 accesses the database 120 to assign network traffic to paths available within the managed network 150. The other work stations 140 can access the base procedures of d = .tos through an interface 142. In the preferred embodiment, the interface 142 is implemented using the known SQLNET from Oracle Corp. In a preferred alternative mode, the interface 142 is implemented using the well-known standard database access control language (DBACL). Alternatively, an HTML language translator 141 can convert the interface of the database procedures into an interface 144 of the well-known HTML language. Using the remote HTML interface 144, low-cost workstations, for example workstation 143, can obtain P15 6 / 98MX at least limited access to data related to the managed network 150. In the TMN terminology, the other work stations 140 and 143, and the NPWS 107 are considered as part of the "management layer". services "(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 designed according to a TMN standard, the particular MIB 117 of interest is a TMN time-of-run object model. The work team administrator 114 creates the run time TMN object model from a particular work team 138. In this way, the MIB 117 is a TMN object model, extended as described above, which can represent either a "current" observation or a "future" observation of the managed network 150. The MIB 117 is specifically used by the NEWS 101. To achieve some desired network management functions, several workstations will normally have access to the TMN domain 116 and perhaps to the MIB 117, either through an interface 142 that complies with CMIP or a TMN object-oriented interface (TMN-OOI) 105. These interfaces require that workstations be equipped with hardware, software or specific operating systems that can represent expenses or P15 6 / 98MX inconveniences. In addition, any workstation using the TMN-OOI must maintain version compatibility with the particular TMN 116 domain. The network management architecture 100 described above, however, provides greater flexibility over existing systems since it allows access to the TMN network run time model through platforms that do not comply with TMN. For example, ORB 103 can communicate with systems that do not comply with TMN. In this case, the ORB 103 must include mappings of the domain that complies with TMN to the domain that does not comply with TMN. In the preferred mode, the domain that does not comply with TMN is the CORBA domain. In addition, the network equipment manager 114 can be modified to allow access to the legacy systems. Legacy systems are generally considered existing systems that do not support standard customer interfaces in the industry, such as CKIP, CORBA or SQL, as interfaces. Legacy systems include many traditional mainframe applications as well as personal and midrange applications. Figure IB illustrates the structure of the NEWS 101 as an operating system as defined by the TMN standard. Referring to Figure IB, a network 150 to be administered is represented as groups of timing signal generators (TSGs) 152, 156 and groups of P15I6 / 98 X work elements (NEs) 154, 158. The TSGs and NEs are discussed below. The TSGs 152 and NEs 154 are connected directly to a data communications network (DCN) 127. A network management system (NMS) 170 according to the preferred embodiment of this invention is also shown connected to the DCN 127. The Managed network components can interface with the NMS 170 using a standardized data communications protocol, for example a protocol that complies with CMIP (as described above). In a preferred embodiment, the NEWS 101 is implemented in the NMS 170. Other operating systems 164, 166 are also shown connected to the DCN 127. The other operating systems 164, 166 may also communicate with the network elements administered in a similar way that the NMS 170. Within the administered network 150, other TSGs 156 and NEs 158 groups are connected to a separate DCN 160. The DCN 160 is connected through a mediation device 162 to the DCN 127. This indirect connection of the TSGs 156 and the NEs 158 to the DCN 127 can be used when the TSGs 156 and the NEs 158 are not equipped to communicate using the same protocols as the NMS 17 D. In this case, the mediation device 162 translates between the protocols, thus allowing the various equipment to communicate with the NMS 170. As will be evident P1SX6 / 98MX for those with expertise in this field, other practical reasons for using the indirect connection is to provide coverage for a large number of elements over shared communications facilities. The network management architecture 100 was described in terms of coupling through DCNs. A DCN provides a mechanism to transmit information between two remote points. In the context of the present invention, the DCN can be either a network or a single conduit. For example, in the case of the DCN 127, if a particular NEP complies with CMIP, then the DCN 127 relative to the particular NEP may simply be a direct link. Although there are several separate DCNs illustrated in Figures IA and IB, it will be apparent to those with skill in this field that some of the DCNs may overlap or merge. In a DCN that uses a multilayer protocol, even the various interfaces shown can be implemented through the same physical network for practical reasons.

I. Man-Machine Interface (HMI) The human-machine interface (HMI) of the present invention is unique in the field of telecommunications network synchronization management. With reference to Figure 4, the HMI of the present invention P1516 / 98MX is described. In the HMI of this invention, an application, for example WSF 102, communicates with the rest of the system over an "f" interface 450. An "f" interface is a standard TMN terminology for a common interface that joins a particular application. The interface 113 that complies with CORBA is an example of an "f" interface. The interface "f" 450 is connected in turn to various support platforms through the "g" interfaces 452a-d and 454. A "g" interface is the 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 the "g" interface 452a, which can further be divided into the "g" 452b-d interfaces (described below). The "g" 452b-d interfaces connect a particular application to the mid-range and upper-end user platforms. The second broad class of "g" interfaces is the "g" interface 454. The "g" interface 454 connects a particular application to the lower-end user platforms, using the well-known HTML language. For example, the "g" interface 452b can be connected to a higher-end user platform that supports the well-known UNIX / AIX operating system.

P15I6 / 98MX Elsta upper end user platform can be, for example, an upper end workstation that is capable of running the WSF 102 in real time or almost in real time. This capability may be required by a network designer engineer responsible for designing and maintaining the telecommunications network. The upper end system is relatively expensive. The "g" interfaces 452c-d may, for example, be connected to a mid-range user platform. This platform may be able to support well-known operating systems OS2 or Windows 32-bit. In the present invention, the mid-range user platform is used by a user who acquires frequent access to the simulation capabilities of the present invention, but who does not require the power of an upper-end user platform. For example, a mid-range computer platform could interface with the network management architecture 100 through the 130 interface that complies with CORBA. The "g" interface 454 provides a cheap mechanism for the broad distribution of the services provided by the present invention. This is because the user platform that supports the "g" interface 454 does not have to support the execution of the application and the associated computing requirements. The users P1! S16 / 98 X of this low-end platform include remote users that require infrequent access to the telecommunications network models stored in the object stores in the database 120. The lower-end user platform of preference access to a particular application that uses the already known HTML. Referring to Figure 1, the interface 144 provides an HTML interface to the telecommunications network models stored in the database 120. As a result, end-user platforms are less expensive and can be more easily supported than platforms. of mid-range and upper-end user. In the preferred embodiment, the HTML interface is generated by an HTML translator 141. The HTML translator 141 preferably has a browser-browser (for example the well-known Netscape Browser) to provide a GUI for a low-end user. The advantage of using the aforementioned distributive processing mechanism offered by the "g" interface 454 is the low cost and low complexity of the low end user platform.

III. GUI The GUI 108 provides the graphic interface towards P1516 / 98MX the telecommunication network object models stored in the database 120. Several peculiarities have been incorporated into the GUI 108 to improve its presentation and global utility for the designers and those in charge of maintaining the network. A particular feature is the presentation of the topographic and topological observations linked to object for the telecommunications networks. The linked topological and topographic observations are useful for determining diversity in the telecommunications network. In addition, linked topological and topographic observations can be used to verify that a particular restoration configuration satisfies several engineering guides. Figures 5A-D illustrate the linked topological and topographic observations. Figures 5A-D illustrate a telecommunication network having 8 interconnected sites A-G. Figure 5A illustrates a topographical observation. In Figures 5A-D, there are three general classes of sites. Source sites that are sources of communications. Collector sites that are communications users. The sites involved are used to provide connectivity between the source and collector sites. For example, to transmit a communication from site A to site H, communication must pass to P: .516 / 98 X through site G. In this way, site A is the source site, site H is the collector site and site G is the intervening site. As described above, the path information is contained in the extensions to the standard TMN model according to the preferred embodiment. As can be seen in Figure 5A, topographic observation presents the physical interconnectivity between sites A-G. For example there is a physical link 501 connecting to sites A and B. Similarly, there is a physical link 502 connecting sites A and C. Meanwhile, Figure 5A represents the physical configuration of the AG sites in the telecommunications network, Figure 5A does not illustrate the logical connections between the sites, that is, how the sites are actually configured to communicate with each other. Figure 5B illustrates the topological observation of the A-G sites in the telecommunications network. The topological observation provides an observation of the logical connections between the A-G sites. That is, the topological observation illustrates the connections between the sites according to the object models stored in the database 120. The topological observation is possible due to the extensions of connectivity with the TMN standard discussed above. Note that the topological observation PI516 / 98MX indicates a logical link 512 between sites A and H. According to Figure 5A there is no physical link between sites A and H. Therefore,, assuming there are no errors, there must be an intervention site to make the connection between sites A and H. In this example, site G is the intervening site. Therefore, logical connection 512 includes physical links 503 and 508. The present invention includes a third observation, logical observation. The logical observation of the telecommunications network illustrates the: interconnectivity between particular portions of the network. For example, in the preferred embodiment, the logical observation of the telecommunications network illustrates the connectivity for a particular site, the logical link, and / or the physical link of the network. In the preferred embodiment, the user selects the portion of the telecommunications network for which a logical observation is deployed using a selection device, for example the well-known mouse -mouse- of the computer. During user selection, a display such as the one illustrated in Figure 5C is presented. By using the observation of the network, a user can easily determine the logical connectivity of a particular portion of the telecommunications network. Figure 5D illustrates a reference frame that P3? 16/98 X stores collector, source and intervention sites associations. The reference frame can be stored in memory. The reference frame provides a convenient storage format for the telecommunications network connectivity the reference frame is optional since all the required information is incorporated into the records 136 in the database 120. Errors can occur if changes are made in the physical configuration of the network without corresponding updates to the database. For example, the database may indicate that there is no connection between two sites. However, MIB 117 may indicate that the physical network indicates that that connection exists. In the preferred embodiment, the physical network is taken as the true representation. In the preferred embodiment, a consistency check can be performed to determine if the MIB 117 differs from the database 120. The consistency check can be invoked either automatically or manually. Any difference between the MIB 117 and the work teams in the database 120 is resolved in favor of the MIB 117. As discussed above, the various observations provided by the GUI facilitate the restoration of the network and the assurance of diversity. The restoration refers to the repair of services E1516 / 98MX failed network. Using the various observations provided by the present invention, the network designer can predict where the proposed implementations of the telecommunications network are likely to fail. The designer can also monitor skills of self-restoration of the telecommunications network. In the preferred modality, topological and topographical observations show highlighted portions of the network. This is described in more detail below. Multiple views or observations also make it easier to comply with the diversity requirements imposed by network design protocols. Diversity refers to providing more than one communication path between two sites while minimizing the number of common elements in the trajectories. By doing so, the network can reset itself in case of a failure in one of the trajectories, changing one of the other trajectories. The use of the particularity of selection, makes a network designer can observe the connectivity of any portion of the network as illustrated in Figure 5C. The designer can then determine if the diversity requirements are met. Due to the complexity of the topology of the P1516 / 98MX network, user observations can become noise. This is the result of the resolution and limited size of the deployment devices in which the views for the user are displayed. The GUI 108 of the present invention provides additional features to reduce noise on the screen. One method for reducing noise is that the GUI 108 allows the user to expand or decrease the observation of the network. The extension is provided to give more detail to the network engineer. The extension allows the network engineer to see more of the network, but in a minor detail. In a preferred embodiment, the level of extension is automatic. In addition, the detail illustrated in the enlarged view is adjusted depending on the level of magnification. The GUI 108 also provides scalable icons.

The scalable icons represent several sites or equipment in the telecommunications network. The present invention scales the icons as the broad network engineer (more detailed view of the network) or reduces (less detailed view of the network) the deployment of the network. In this way, the scalable icons retain their relative size with respect to the portion of the network displayed on the network engineer's screen. This decreases the problem of icon growth or shrinkage as the network engineer expands or decreases the deployment of P1516 / 98MX several portions of the network. GUI 108 also contains a "cluster controller". The "cluster controller" determines if there are too many elements in the network overlapped, thus presenting a confusing display for the network engineer. If this condition is detected, the "cluster controller" groups the overlapping network elements together. The "grouping controller" then represents the grouping as a "grouped element" on the network engineer's deployment screen. The screen provides an indicator that a specific element is a "grouped element". The network engineer can expand a "grouped element" to see in detail what is contained in it. The function of "cluster controller" can be automatic. That is, the system can determine if there are too many overlapping elements. If the system determines that there are effectively too many overlapping elements if the system determines that there are indeed too many overlapping elements, it automatically creates a "clustered element" of the overlapping network elements. The determination may be based on a default value or an overlap factor selectable by the user. The function of, "grouping controller" can be manual. That is, the network engineer can P151S / 98MX select an area of the network to reduce it to a scalable icon. Any network elements that fall within the selected area are grouped together and are represented by a "grouped element". The GUI 108 also includes "pseudo-point" in a line. Due to the limited size and resolution of the deployment device, the lines, which represent separate conduits in a network, may appear so close to each other in the deployment device, that they appear to form a common conduit. The "pseudo points" allow a line to be represented by a point, which has no significance for the network other than moving the line to make it more distinctive. In this way, the "pseudo points" can be used to redraw the line for reasons of 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 telecommunications network being administered, 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 communication with the physical network through the CMPI interface 121. If a simulation (eg "future" view) indicates a failure, the simulation indicates that part of the the network has failed.

P1516 / 98MX The affected regions of the telecommunications network are automatically deployed to a network engineer in the GUI 108. That is, the present invention provides an extension in the deployment, directed tos the affected region of the network. In addition, the affected region is indicated in the global deployment of the network with a small "reference window" that delineates the affected region of the network. The same mechanism for the deployment of networked regions is applied based on a project against the work team administrator 114. With respect to each project, the affected region of the network is deployed to the network engineer over the GUI 108 In this way, if a change in one region affects another region, the network engineer sees all affected regions. In this way, the present invention makes a network engineer a of which parts of the telecommunications network will be affected by a proposed design.

IV Network and Metric Management Functions Performance Another aspect of the present invention is the performance of network management functions. One of the functions of network management is to design the distribution of P1516 / 98MX synchronization in a telecommunications network. Designing the timing distribution according to a preferred embodiment of the present invention ensures that a particular network configuration satisfies several engineering guidelines, these guidelines include the elimination of loops or circuits, the assurance of the possibility of tracking and the assurance of diversity. A loop or network circuit is a connection of network equipment that has the same piece of equipment at the start and end. Loop or circuit detection refers to the determination of the occurrence of a single piece of network equipment more than once in a network route. The tracking capability requires that a particular synchronization destination be traced back to a Stratum-1 source. Diversity refers to the ability of the network to route communication signals across multiple routes that have the same source and the same destination, so that the number of common elements between different paths is minimized. In addition, the present invention calculates the metric to aid in the performance of the design functions. As described below, the metric Q is the cumulative quality metric that indicates the quality of communication for a specific route in a network. The Q metric depends on the physical characteristics of the equipment in the PX516 / 98MX trajectory. Although described below in the context of network synchronization management, it will be evident to those with expertise in this field that the management functions and the performance of the metrics apply to the management of a telecommunications network in general. For example, diversity considerations can be used in any network that requires alternate destination paths to improve the robustness or resistance of the network's ability to re-establish itself. Similarly, the Q metric can be used to calculate a particular path communication quality in any network model. In the context of network synchronization management, a communication signal is a synchronization signal or a timing signal. As already described, the present invention loses the performance of a management function for the administration of synchronization distribution in a telecommunications network in order to ensure that certain engineering guides are satisfied. An engineering guide is to provide a network topology free of loops or circuits. The loop or circuit occurs when a particular target network element becomes its own source, usually as a highlight of the change in the topology. This could be P1516 / 98MX detrimental to the performance of the network. For example, in network synchronization, degradation in network performance is very likely to result if a synchronization signal destination clock is the same as the synchronization signal source clock. This is because the synchronization signal destination clock will try to align to stay in phase with its source, thus modifying its output. This is reflected back into the input, resulting in additional cumulative attentives to align its phase until a significant deviation in the output frequency occurs. The frequency deviation causes a degraded service and eventually the failure of the components synchronized in the network. To prevent this from happening, the present invention provides the ability to detect the loop or circuit in a telecommunications network. The loop detection analysis comprises tracking the distribution of a communication signal to determine if a particular network element is using its own output signal as a reference input. If a particular element uses its own output as a reference input, then a loop or circuit exists and the network engineer receives an alert of its presence. Network elements can be marked with a P151S / 98MX unique identification number in a well-known way. In this way, the loop or loop detection process tracks a network communication path to determine if a particular identification number appears twice, thus indicating the presence of a loop or network circuit. In the context of network synchronization management, the detection of the loop or circuit is alternatively referred to as timing loop detection. When the detection of a timing loop is performed, the network synchronization elements are analyzed to determine if any loop or circuit is present. Network synchronization elements include any element responsible for network synchronization. Network synchronization elements, like network elements in general, can be marked with a unique identification number in a well-known manner. A second engineering guide is to ensure the possibility of tracking. The possibility of tracking refers to the ability of a telecommunications network management system to trace the destination of a communication signal and its source. In the preferred embodiment, the engineering guide for traceability is returned to a Stratum-1 source. In the preferred modality, the possibility of PI516 / 98 X trace is instrumented in the context of network synchronization management. In this context, the tracked communication signal is the synchronization signal. In the preferred embodiment, each synchronization user must be traced backward to two primary reference sources (PRSs). In the preferred embodiment, the PRSs are Stratum-1 references. The system monitors the tracking capability by observing the synchronization path for a particular user of timing, from the user to his timing source. The preferred mode requires at least two PRS tracking paths to provide redundancy for faster re-establishment to the possibility of Stratum-1 tracking, in the event of a connection to the Stratum-1 source being failed. In the preferred embodiment, the design of the synchronization network is presented in three phases: (1) possibility of primary tracking to Stratum-1, (2) possibility of traceback to Stratum-1 and (3) monitoring. Each PRS is connected directly and bi-directionally to another PRS through the network. These connections provide two functions. In the normal operating mode, each PRS monitors the other in terms of phase stability and frequency. In a degraded mode (for example when one of the PRSs loses stability), the monitored connection P1516 / 98MX from the second PRS is used as an alternate reference source to restore the possibility of tracking to Stratum-1. The restoration and monitoring are therefore achieved by the same bidirectional connection. In a similar way, 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, in general one of its source PRSs. SRSs can also receive Stratum-1 traceable reference sources from intermediate SRSs, following the general rules of hierarchical distribution and diversity (discussed below). The three design phases for SRSs are presented in general in a sequential manner. The connections used for monitoring do not need to be different from the reference connection paths. The monitoring capability allows the network synchronization management system to know the performance of the reference connections (the combination of the timing source and the SONET connection). When referring to the synchronization topology maintained by the synchronization management system, this information monitoring performance is used to identify degraded or failing network components, quickly and to generate requests for P1516 / 98MX corrective action. These requests can be automatic actions taken by the network, notifications to technical support, or both. Once the trajectories having Stratum-1 traceability have been defined, the network engineer can use the metric Q (described below) to determine a priority order (described below) for the trajectories. That is, the network engineer can determine which path is the primary path and which path is to be used in case of a primary path failure. A third engineering guide is to provide diversity of network trajectories. Once the telecommunications network management system has determined all the routes between a particular source and the timing destination, it performs a "diversity" analysis. The diversity analysis selects routes in order to minimize the number of common network elements among them. A metric Q is a measure of the quality of a particular path to distribute the timing to a particular site. More specifically, the metric Q is a measure of the cumulative phase disruption of network elements intervening in a synchronization path. Without this metric, the network engineer alone .P1516 / 98MX has a little more than a chance to guess which synchronization path is most likely the best. In the preferred embodiment of the present invention, the metric Q is modeled as: Q = (q (thousands) + q (LRE) + q (Line Timed Device)) * q (line), where: Q is the metric Q , q (thousands) is an empirically determined value that corresponds to the degradation of synchronization per fiber optic mile. q (LRE) is an empirically determined value corresponding to the degradation caused by the regeneration elements along a synchronization path. q (Line Timed Device) is a value that corresponds to the precision of a timing source, for example a timing signal generator, and q (line) is a factor of "capacity" of equipment that can be used to take into account the degradations of the equipment and the manufacturer, for example optical aging. The metric Q can be derived from any synchronization path in a telecommunications network. A network engineer can use the Q metric to determine the best route among several alternatives. In this way, the use of the metric Q avoids the method PL516 / 98 X often used trial and error, in conventional synchronization distribution methods. The Q metric has 2 additional uses. The first use is to predict the performance of a particular route in the network. The second use is to compare the predicted performance with the current performance to identify potential problems when network failures are likely to occur. The metric Q as defined before, can be designed individually. That is, a client can adjust the various parameters of the metric Q to take into account other phenomena of the network. For example, the client can adjust the parameters of metric Q to take into account the synchronization topology instead of line effects. Diversity considerations have a higher piriority than the metric Q. That is, a trajectory that has a high metric Q but that has an unfavorable diversity analysis is not selected with respect to a trajectory that has a low Q metric but a diversity favorable. The reasons that diversity is a measure of the ability of the telecommunications network to repair itself in case of failure or degradation, while the Q metric predicts performance degradation.

P1516 / 98MX V. Synchronization Distribution Management As the network management architecture 100 stores a logical representation of the physical network in the MIB 117, the network management architecture 100 contains the information required to perform the management functions and calculate the performance metric described above. In the preferred embodiment, the network management architecture 100 is used to manage network synchronization, includtimdistribution, timreset, and timmodification. As already described, the network in which the present invention is executed has SONET network elements (SNEs), timsignal generators (TSGs) and other network equipment. Figure 6 illustrates a se timdistribution chain in a telecommunications network. The timdistribution chain comprises two timsignal generators (TSGs) 602, 608 and two SONET network elements (SNEs) 604, 606. TSG 602 is coupled to SNE 604 by electronic connections 610a and 610b. In the preferred embodiment, electrical connections 610a and 610b form a redundant pair 610. Similarly, TSG 608 is coupled to SNE 606 via electrical connections 614a and 614b. The electrical connections 614a and 614b may be a paired connection, but in general they are not. The SNEs are P1516 / 98MX optically coupled by, at least one optical connection 612. The optical connection 612 can be any optical connection includ for example, fiber optic cable. The TSGs 602 and 608 provide timsignals to various network equipment, for example network equipment 620. The network equipment 620 may be one or more units of telecommunications network equipment that requires synchronization. The timsignals produced by TSGs 602 and 608 are electrical signals. In the preferred embodiment, these electrical signals conform to the well-known Digital Signal 1 (DSl) standard. The DSl standard defines electrical signals that have a data rate of 1.544 Mbit / second. In the preferred embodiment, the timsignals are generated by oscillators in the TSGs 602 and 608. The quality, ie the precision, of the timsignals generated by the TSGs 602 and 608 is defined accordto the Stratum-N standards. . For example, TSGs satisfy the requirements Stratum-1 hava precision of le-11 and TSGs satisfies the requirements Stratum-2 havan accuracy of 1.6e-8. In the preferred embodiment, TSGs satisfy the Stratum-1 requirements that are designated primary reference sources (PRSs). TSGs that meet Stratum-2 requirements are designated secondary reference sources (SRSs). In the preferred embodiment, a PRS P1516 / 98MX provides a reference for the generation of SRS timsignal. That is, a PRS serves as a reference master clock to which the SRS oscillator is locked. With reference to Figure 6, the timdistribution in a telecommunications network is explained. The TSG 602 generates a timsignal that conforms to the DSl standard. The timsignal generated in this form is to be distributed to the network equipment 620. To carry a timsignal conformto the DSl standard, the timsignal DSl is transmitted to the SNE 604 on the lines 610a and 610b of the pair redundant 610. The SSNE 604 selects one of the DSls of the redundant pair 610 to be transmitted to the SNE 606. A selector switch 640 (discussed below in relation to Figure 7A) selects the timsignal DSl of the line 610a or the line 610b. The timsignal is used to generate the optical carrier speed. The stability of the optical signal is derived from the oscillator 632 in the SNE 604. The oscillator 632 drives an optical frequency generator (not shown). A selector switch 642 (discussed below in relation to Figure 7B) in the SNE 606 selects the optical transmission path 612. The SNE 606 generates the timsignal DSl from the incomoptical signal rate. The P1516 / 98MX DSL timing signal. generated in this way provides a reference to TSG 608. Using this reference, oscillator 636 in TSG 608 generates a timing signal for network equipment 620. In this form, the timing signal generated in TSG 602 is distributed to the equipment of network 620 over optical connection 612. Figure 7A illustrates a selector switch 640 in SNE 604. A selector switch 644 is located in SNE 606. Selector switch 640 and 644 are used to transmit timing signals over optical connections 612, 613 , 615 and 617. The selector switch selects one of a plurality of timing inputs to the SNE 606. Figure 7A illustrates 8 of these inputs: 2 electrical DSI inputs, 2 side optical line inputs and 4 side optical inputs of "" drop "(tributary). Line side entrances and side fall entrances 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 oscillator 632. In the preferred embodiment, oscillator 632 generates the optical frequency for transmission through all optical connections 612, 613, 615 and 617. Figure 7B illustrates a selector switch 646 P1516 / 98MX in SNE 606. A similar selector switch 642 is located in SNE 604. The selector switches 642 and 646 are used to receive timing signals from the optical connections 612, 613, 615 and 617. The selector switch 642 of FIG. preference includes 2 selector elements 704a and 704b. The selector elements can independently select any of the inputs 612, 613, 615 and 617. In the preferred embodiment, a timing signal DSl is generated from the selected input. In other words, the selector element 704a selects an optical input, for example 612, from which a timing signal DS1 is generated. The electrical signal generated in this form leaves SNE 606 on line 614a. Similarly, the selector element 704b selects an optical input from which a timing signal DSl is generated. The electrical signal? Terminated in this form leaves SNE 606 on line 614b. In general, the settings of the selector switch are dependent on the network synchronization topology. That is, in general there is no default state, for the selector switches. In this way, the selector switches in an SNE must be pre-adjusted before using the SNE to distribute the synchronization. The selector switches 640, 642, 644 and 646 can be initialized by a network engineer. By P1516 / 98MX example, in the timing distribution chain illustrated in Figure 1, the selector switch 640 is initially set to select one of the electrical inputs DSl, 610a or 610b from TSG 602. Alternatively, the selector switch can be initialized automatically using a network management system (NMS) (described below). The selector switch is programmable remotely. The programmable nature of the selector switches provides high flexibility for the timing distribution in a telecommunications network. That is, during the operation of the telecommunications network, a particular SNE selector switch setting can be modified. For example, the position of the selector can be modified to replace a TSG with a failed TSG, to which the selector switch was originally connected. Each SNE typically includes three or four selector switches, for example, selector switches 640 and 642. A telecommunications network may have 6000 to 12000 or more SNEs. It is readily apparent that the combinations of the SNEs, which have multiple selector switches to provide different timing distribution paths, are enormous. In addition, the SNEs in general are equipment P1516 / 98MX smart. This intelligence allows an SNE to cause the selector to move to a different position, in case of a failure of a network synchronization element or connection. That is, the intelligence allows the SNEs 604 and 606 to reconfigure themselves (for example changing the selector positions according to a predetermined priority) in case of a timing signal failure. To manage the flexibility inherent in the switching capabilities of the SNEs and TSGs, the management system of the present invention is required. As already described, the present invention models SNEs and TSGs as object-oriented programming language objects, according to the TMN standard. The modeled objects are created from registers 136 which are stored in the database 120. Another aspect of the present invention relates to network restoration management. As already described, the SONET equipment generally does not require a separate dedicated or dedicated communications line to carry the synchronization information from one site to an adjacent site, since the SONET links carry the retrievable timing information as an inherent quality of the signals that carry transmitted traffic. Each SNE that requires timing in general can P1516 / 98MX is selected from among several incoming signals (eg timing inputs in Figure 7A) to achieve synchronization with other synchronization references in the telecommunications network. A selector switch, such as that illustrated in Figure 7A, is used to select the incoming signals from which the timing information is derived. In summary, the typical network site connects to many adjacent sites scattered by a multitude of communication links. Each of the links carries a digital signal that can be used as the basis for local timing synchronization. To ensure better synchronization through a large network, the synchronization signal generator within each site must select an incoming signal that has the traceability closest to a PRS, somewhere in the network. In the event of a failure affecting the integrity of the entire selected synchronization path, a specific network site must select an alternate synchronization route that is trace back to a PRS. In addition, two specific synchronization paths of equal tracking capability to a PRS on a network site should not be unnecessarily switched between two synchronization sources. This is because every time a switch is encouraged, there is a risk of generating P1516 / 98 X transient phase changes that can affect traffic integrity. These transient phase changes can be a particular serious problem since they can affect the timing of several outgoing signals to which other sites are engaged in phase. A single transient timing change can, therefore, cause noise and disperse through the network. A situation that can cause this unnecessary switching is as follows. Within a specific network site, a clock selects an incoming signal A, from which the synchronization is derived. For illustrative purposes, suppose that the incoming signal A comes from an SRS (i.e. the incoming signal A is removed once from the PRS network). Then, due to a fault in the network, the incoming signal A is interrupted. The network site clock then picks up an alternating incoming signal B on which it is synchronized. Although this is a bit risky (due to the switching of the incoming signal A to the incoming signal alternate B) the change of the incoming signal A towards the incoming alternating signal B is preferable to allowing the local clock to scroll. In this way, the change is considered necessary. Now suppose that the incoming signal alternates B also has a second level of traceability, and is essentially equivalent to the incoming signal A. In this P1516 / 98MX, when the incoming signal A is eventually reset, the local clock will not benefit by returning the incoming signal A. However, conventional systems that assign a fixed order of preference between incoming signals, if they return to the incoming signal A As a result, conventional systems unnecessarily risk a transient phase shift in the network as the timing signal returns to the original incoming signal. Another aspect of the present invention eliminates the risk of a transient phase change using a selection priority table contained in each network element that is capable of synchronization switching (i.e. capable of selecting a synchronization source). In the preferred embodiment, each network equipment that is capable of synchronization switching stores a priority frame. The priority box contains priority values that help select the preferred available incoming signal. Priority values can be assigned in order to avoid unnecessary switching between signals of equal validity and traceability. The application of the priority frames of the present invention is explained in relation to Figures 8A-C. In Figures 8A-C, the "E" n are DSl entries P1516 / 98MX electrical and the "0" n are optical inputs. Referring to Figure 8A, a priority frame is shown which correlates the candidate synchronization entries with an arbitrarily assigned priority number. In this analysis, lower priority values indicate greater preference. A higher preference can be indicated, for example, for a traceability closer to a PRS. The candidate entries in the frame of Figure SA are analogous to the synchronization signals recovered from the timing inputs in Figure 7A. By assigning priority values as illustrated in Figure 8A, an order of preference is established. The order of preference favors the switching to the source when possible. if a fault occurs that makes El inaccessible, source E2 will be selected as the synchronization input. Failures of detection and location within the network and communication of the related fault and restoration indications are well known to those skilled in the art. When it is reset, the synchronization input is returned (immediately) to El. This characteristic is referred to as "reversed" switching. Figure 8B contains a different allocation of priority values towards switch positions P1516 / 98 X selector. The different assignments cause a different switching behavior. In particular, the inputs El and E2 both have a priority value of zero. According to the priority box in Figure 8B, if El is selected and subsequently fails, switching is performed to select E2 as the alternative synchronization source. On the contrary to the priority assignment established in Figure 8A, the subsequent reset of El does not activate a backward switch to El from E2. Since El and E2 are equally desirable synchronization references, there is no reason to switch them unless E2 fails at a later time. In this case, El and E2 are said to be "not reversed" with respect to each other. Figure 8C includes an additional variation using the priority boxes to control the topology. The priority assignment in the priority box of Figure 8C shows that: (a) the order of priority is independent of the input designator; (b) any arrangement of priorities may be assigned; and (c) any number of non-reverted strata can be established by appropriate values of priority assignment in the priority frame. Using the chart illustrated in Figure 8C, if the inputs El, E2, 01 and 02 are not available, then the synchronization input P1516 / 98MX is 03. If input 02 is reset then, no switching occurs since 02 and 03 are not reversed with respect to each other, in the box of Figure 8C. If either El or E2 is reset, then the switch from 03 to El or E2 is made, depending on which of El and E2 is reset first. If the four original faults (El, E2, 01 and 02) are suddenly reset simultaneously, input 01 is immediately selected as the input synchronization source. It will be evident to those with expertise in this field that the entries of the tables may take the form of a physical cabling logic, a read-only memory (ROM) content or a write-capable memory or a storage data content. that have been loaded or determined by an external network control element. In addition, the content of the priority table can be altered or modulated or interpreted according to the signals that cross the inter-site links themselves. Figure 9A is a flow diagram 900 for interpreting the priority frame in order to achieve the above logical functions according to the preferred embodiment. A process according to the flow diagram 900 can be used to control the input selector switch 702 in Figure 7A.

P1516 / 98MX The process of interpreting the flowchart 900 starts at step 902. In step 902, the process developed a single examination of the functional status of the inputs. Based on the examination, the process makes a decision on which entry should be selected. This process can be activated periodically to achieve the operation in polling mode. In step 904, the process identifies which of the inputs is currently selected as the synchronization source. Using the priority box, the process also determines the priority value associated with the currently selected entry. In step 906, all properly functioning entries are checked to determine whether any candidate entry has a lower priority value than the currently selected entry. If a candidate entry is found to be functioning properly and has a priority value lower than the currently selected entry. Otherwise, if in step 906 no other operation input has a lower priority value than the currently selected input, the process continues in step 910. In step 910 the process ends without initiating any switching action. While the priority assignment aspect of the present invention has been described in the P1516 / 98MX context of directing synchronization selections within network sites, the particularity of priority assignment is applicable to a variety of similar problems elsewhere in the control of the communication network and in other fields. For example, a common problem that is usually encountered is that there are several streams of data that need to communicate over a finite number of available trajectories. Let us suppose that each data stream totally consumes a single trajectory. Also suppose that, to give rigidity or robustness, there are more trajectories than data streams. Therefore, there are replacement parts that can be used if other routes fail. The routes can be assigned as sources according to for example the priority assignment scheme of Figure 8C. Each route is therefore correlated to a corresponding priority value. The availability indicator for each route is defined as true if the route is working properly and is not already occupied by a data stream. Referring to Figure 9B, the flow chart using the priority assignment scheme of the present invention for assigning priorities to available routes over which the data streams are transmitted. Step 920 starts the process looking at a P 516 / 98MX list of data streams and making decisions about how to allocate data streams to available routes. In step 922, one of these data streams is selected as the context for the processing in steps 924 to 928. If the data stream is not already assigned to a route, the priority is assumed with a high positive value greater than any of the inputs in the priority box. In step 926, all routes indicated as available are evaluated to see if one of them has a lower priority value that is already assigned to the data stream, as determined in step 924. If a route with a The lower priority value is found, then in step 928, the data stream is assigned to any available route that has the lowest priority value. It is also implicit in step 928 that the newly assigned route receives a false availability indicator, while the previously assigned route, if any, returns to the "available" condition. In step 930, the process means completing a decision that involves a simple data stream. If the process of step 928 determines that all data streams to be assigned have been subjected to the process, then execution ends in step 932.

P2516 / 98MX otherwise, if in step 930 the process determines which other data streams should be processed, then execution ends in step 922 to select one of the remaining unprocessed data streams. Applying this invention to assignment tasks of this nature provides a mechanism for establishing both priority relationships and reverse / non-revert relationships between different selections. In addition, during an execution of the process illustrated in flow chart 918, if the availability indicators are all set to "true" and the data streams to be allocated are processed in a particular sequence, the process can allocate the data most important to the most desirable routes.

SAW. Network Simulation. Figure 10 is a flow chart illustrating a process by which NEWS 101 creates a synchronization distribution plan suitable for a specific network. The process can be performed in response to a synchronization service (SSR) request. An SSR is a notification that lists the TSGs and SNEs for which the synchronization plan must be designated. The SSR also specifies a particular date for which a data representation of the network is assembled. As already P1516 / 98MX described, the data may correspond to a network configuration projected in the future. In this way, the representation of the data can include both a "current" observation and one or more "future" observations of the network. A network designer can invoke the process illustrated in Figure 10 to revise or modify a network design. Alternatively, the NEWS 101 can automatically perform the process illustrated in Figure 10, when the network reconfigures itself to achieve reestablishment after a network failure. The process starts in step 1002. In step 1002, the SSRs are received in a row. The NEWS 101 simulates the network as it will exist at a certain point in time, creating an object model of run time. As described above, the run time object model is based on a work team resident in database 120. Each work team resident in the database is associated with a particular date and represents the current state and / or future of the network. Each work team is composed of several records in the database that describe the current and planned configurations of parts of the network. In step 1004, the NEWS 101 determines whether a work team that can adequately represent the network projected to exist as of the last date PL516 / 98MX specified in the SSRs, there is the database 120. If this work team is not found in step 1004, then in step 1006 the work team administrator 114 combines the required work team from the records in the database that precede the date specified by the SSRs. The records in the database 120 that are used to combine the required work equipment can reflect both current network information ("current" observation) and projected ("future" observation). The current information is maintained by direct connection to the existing network through the TMN subsystem 104. The process continues in step 1008, where an applicable work team has been found or constructed.

In step 1008, a run time object model is created based on the applicable work equipment. In step 1010, a particular SSR presented in the entry row in step 1002 is selected to be included in an initial synchronization design. In step 1012, the process decides which of the many available signals will be connected to the synchronization selector switch for each network or to the timing generator having synchronization switching abilities. In a preferred embodiment, the process of step 1012 also allocates the contents of the selection box to implement a switching logic of P1516 / 98MX desired synchronization for each network element and TSG that supports the use of a switching selection box. The entries in the selection box and the connections determine, for example, which primary synchronization source signal will use a specific TSG under normal conditions of use. Other of these assignments can determine which alternate synchronization signal can be used as a reference, if a portion of the network fails. The alternate synchronization signal is also referred to as a reset synchronization signal. Other connections can perform a monitoring function, whereby some TSGs are compared against others. In a preferred embodiment, the selection boxes may contain priority numbers. The priority number controls the reverse switching behavior according to the scheme described in Section V. In one embodiment, a human network designer makes the selection of port assignments in step 1012. In this mode, it is preferred to help the designer presenting some metrics that measure the desired degree of candidate timing signals. One of these useful metrics in the selection of synchronization signals is the Q metric described in Section V. Another useful metric is a measure of the relative path diversity among the selected routes.

E1516 / 98MX While a human designer can implement reasonable connections, it is further contemplated that the selection and review of the candidate synchronization routes can be implemented similarly by an automatic or semi-automatic process. The automatic or semi-automatic process may work, for example, as a data manipulation process with the NEWS 101. In step 1014, the process determines whether all the SSRs in a row have been included in the initial design. If there are more SSRs, processing ends in step 1010 to satisfy any remaining 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 with skill in this field, simulation step 1016 typically involves the appearance of objects data that model the physical network, executing the simulation to allow data objects to simulate the behavior of current network elements and record the state of objects in simulated time increments. During the simulation, the simulator can continuously observe the data model regarding compliance with the engineering guides. In the preferred embodiment, the engineering guides include the requirements E151S / 98MX: a) each SNE must be provided with a primary timing reference input with tracking capability to a Stratum-1 reference source; b) each SNE must be provided with at least one reset reference entry with tracking capability to a Stratum-1 reference source; c) The primary timing and reset routes must be physically diverse; d) each SNE must be monitored with at least one other SNE; e) each SNE in the hierarchy can only receive reference from an SNE of equal or greater level of stratum; and f) no SNE in the network can provide reference timing itself (ie there can be no loops or timing circuits). The process continues in step 1018. In step 1018, the simulation results are evaluated to determine the strength of the design and its compliance with the previous engineering guides. The process then proceeds to step 1020. In step 1020, the process determines whether the simulation results of step 1016 and 1018 indicate a suitable synchronization topology. If the simulation results P1516 / 98MX is considered to meet the resistance criteria (robustness), then the process is completed in step 1024. in step 1024, the synchronization plan is released to be used as a viable design. Otherwise, if in step 1020 the simulated network turns out to be inadequate, the network is effectively redesigned by changing the port assignments and the process is repeated in step 16 starting with a new simulation. While several embodiments of the present invention have been described above, it will be understood that these have been presented only as examples and not as limitations. Therefore, the spirit and scope of this invention should not be limited by any of the exemplary embodiments described above but will be defined only according to the following claims and their equivalents.

P151S / 98MX

Claims (16)

1. NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and, therefore, the content of the following CLAIMS is claimed as property: 1. A management system of a telecommunications network that has network equipment, which comprises: a telecommunication management network (TMN) subsystem for storing a model object object of run time of the telecommunications network equipment; a database subsystem coupled to the telecommunications management network subsystem to provide a long-term storage of the records describing the network equipment and the connectivity between the network equipment from which the representation of the network was constructed. run-time object model of the telecommunications network; a workstation coupled to the TMN subsystem in which a graphical user interface is operated (GUI) which provides a graphical representation of the representation of the run time object model and which also provides access to the run time object model representation, and in which at least one run function is performed. network management; Y P1516 / 98MX a translator coupled to the workstation and the telecommunications management network subsystem to translate the representation of the object model into a form that is useful for the GUI. The system according to claim 1, further comprising: a first work equipment containing a "current" observation of the network, wherein the first work equipment is stored in the database subsystem; and a work team administrator coupled to the TMN subsystem to create a second work team from the records stored in the database subsystem, where the second work team is stored in the database subsystem and the Second work team represents a "future" observation of the network. The system according to claim 1, further comprising an observation controller coupled to the GUI and the translator device to accept a request from the GUI and to convert the request into an understandable command by the translator, in order to manipulate the representation of the run time object model and accept, in addition, the results of any manipulation of the object model, for transmission to the controller. P1516 / 98MX observation, the observation controller converts the result into a useful way to be displayed in the GUI. The system according to claim 3, further comprising a common management interface protocol (CMIP) interface, the representation of the work run object model created from the information extracted from the telecommunications network on the interface CMIP, and stored in a manner consistent with the TMN standard, but having extensions to it to represent particular connections between the network equipment in the network. The system according to claim 4, wherein the translator is an ORB messenger. The system according to claim 5, wherein the ORB translates an object from the TMN standard and the extensions thereto into a representation that complies with the common architecture standard of the ORB messenger (CORBA). The system according to claim 2, wherein the at least one "future" observation is indexed according to the date. The system according to claim 2, wherein the at least one "future" observation is indexed according to the project. The system according to claim 1, wherein the GUI represents topographical representations and P151S / 98MX linked topological telecommunications network. The system according to claim 4, wherein the particular connections are line, link and section connections in a SONET or SDH network. 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 that uses object models to create a time object model of run of the telecommunications network; storing the run time object model in a telecommunication management network subsystem; provide access to the model through a graphical user interface (GUI); translate from the object model representation stored in the management information base to a useful representation for the GUI. The method according to claim 11, wherein the run time object model is modeled according to the telecommunication management network (TMN) standard, but having extensions thereto to represent element connections of particular networks. PL516 / 98MX 13. The method according to claim 12, further comprising the step of: extracting information required to construct a run time object model representation through an interface that complies with the common management interface protocol ( CMIP); translate the representation of the object model that will comply with the common ORB messenger architecture standard (CORBA) and provide run time object model information to the GUI, through the CORBA-compliant interface. The method according to claim 11, further comprising the step of: modifying the run time object model according to a desired configuration of the telecommunications network, at some point in the future, to create a "future" observation " of the network; and store the "future" observation as a work team in the database. 15. The method according to claim 14, further comprising the step of indexing the "future" observation according to the date. 16. The method according to claim 14, comprising the step of indexing the "future" observation according to the project. P1516 / 98 X