WO1997041657A1 - Procede et dispositif pour emuler un reseau de sous-repartition numerique - Google Patents

Procede et dispositif pour emuler un reseau de sous-repartition numerique Download PDF

Info

Publication number
WO1997041657A1
WO1997041657A1 PCT/US1997/007799 US9707799W WO9741657A1 WO 1997041657 A1 WO1997041657 A1 WO 1997041657A1 US 9707799 W US9707799 W US 9707799W WO 9741657 A1 WO9741657 A1 WO 9741657A1
Authority
WO
WIPO (PCT)
Prior art keywords
emulator
network
dxc
mcs
control
Prior art date
Application number
PCT/US1997/007799
Other languages
English (en)
Inventor
John V. Mclain, Jr.
James D. Dellinger
Original Assignee
Mci Communications Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US08/641,458 external-priority patent/US5809286A/en
Priority claimed from US08/641,461 external-priority patent/US5867689A/en
Priority claimed from US08/641,460 external-priority patent/US5850536A/en
Priority claimed from US08/641,459 external-priority patent/US5748617A/en
Application filed by Mci Communications Corporation filed Critical Mci Communications Corporation
Priority to AU30615/97A priority Critical patent/AU3061597A/en
Publication of WO1997041657A1 publication Critical patent/WO1997041657A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/2254—Arrangements for supervision, monitoring or testing in networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/26—Arrangements for supervision, monitoring or testing with means for applying test signals or for measuring
    • H04M3/28—Automatic routine testing ; Fault testing; Installation testing; Test methods, test equipment or test arrangements therefor
    • H04M3/32—Automatic routine testing ; Fault testing; Installation testing; Test methods, test equipment or test arrangements therefor for lines between exchanges
    • H04M3/323—Automatic routine testing ; Fault testing; Installation testing; Test methods, test equipment or test arrangements therefor for lines between exchanges for the arrangements providing the connection (test connection, test call, call simulation)

Definitions

  • the present invention pertains to data communication networks, such as long-distance telecommunication networks. More specifically, the present invention relates to testing network monitoring and/or control systems.
  • a communication network serves to transport information among a number of locations.
  • the information is usually presented to the network in the form of frequency-domain or time-domain electrical signals representing any combination of telephony, video, or computer data in a variety of analog and/or digital formats.
  • a typical communication network has various physical sites, called nodes, interconnected by information conduits, called "links." Each link serves to carry data from one node to another node. Individual nodes contain equipment for combining, separating, transforming, conditioning, multiplexing/ de-multiplexing, and/or routing data.
  • Digital cross-connect switches are often provided at a site or node to switch traffic, electrically or optically, to an alternative link to alleviate congestion, avoid a link failure, or fulfill any other network configuration or restoration order.
  • a central monitoring and/or control system (MCS) communicates with each node.
  • MCS monitors and controls digital cross-connect switching at nodes to route data through the network according to well-known network management and restoration techniques.
  • the MCS is further responsible for dynamically establishing and breaking down logical trunk or channel connections between DXC nodes to provide dedicated point-to-point paths for customers.
  • the role of the MCS in a communication network for purposes of
  • network management i.e. traffic monitoring, control, and restoration
  • traffic monitoring i.e. traffic monitoring, control, and restoration
  • a typical network can include hundreds or more nodes having digital cross-connect switching capability.
  • Each digital cross-connect switch node often has many network node control links and ports.
  • Each node control link in turn supports multiple communication sessions between the node and the MCS regarding audit and status states, alarms, network outages, etc.
  • To use an actual digital cross-connect network in a test environment to fully-test an MCS is impractical and cost-prohibitive.
  • the behavior of a telecommunication switching network has not been fully emulated to test a MCS.
  • Network behavior has not been emulated on any scale to test an MCS, especially in an environment where processing power is limited as in a personal computer system.
  • DXC 1/0 networks are used primarily for dynamic call setup and breakdown to provide such telecommunications services as a Virtual Private Line.
  • a DXC 1/0 node is a switching device used in telecommunications networks primarily to switch DS-0 trunks (also called channels) on incoming DS-1 ports to certain outgoing DS-1 ports, based on commands it receives from an external control system. DXC 1/0 nodes also generate alarms, which are triggered when a trunk is knocked out-of-service due to a network outage, such as a fiber cut.
  • An MCS is called upon to issue channel level commands (i.e. grow/de- grow, connect/dis-connect, and cross-connect commands) to set up paths through provisioned ports in a DXC 1/0 network.
  • the MCS still continues to monitor and respond to alarms from the DXC 1/0 nodes. This provides an important commercial advantage by allowing a customer to utilize a personal dedicated line for a call without incurring the expense of buying a permanent private line.
  • Communication between the MCS and a digital cross-connect network having hundreds or more network node control links needs to be emulated in the presence and absence of selected network failures and in the presence and absence of dynamically configured trunk connections.
  • digital cross-connect network behavior be emulated substantially in parallel with the processing of dynamic user-inputs and/or MCS commands identifying selected network node and trunk configurations (including dynamic port provisioning and path configuration), failures, and/or normalizations.
  • an MCS be fully tested inexpensively using a personal computer which emulates network behavior and responds to user and/or MCS inputs identifying selected network node and trunk configurations (including dynamic port provisioning and path configuration), failures, and/or normalizations.
  • OS Computer operating systems
  • MS-DOS from Microsoft Co ⁇ oration
  • PC-DOS from IBM Corporation
  • CPU Central Processor Unit
  • More sophisticated operating systems such as OS/2 from IBM and System 7.0+ for Macintosh applications, are known as multi-tasking operating systems. This is because they allow the central processor to process tasks from multiple applications in a given interval of time. They do this by managing control of the processor. Although the processor itself is single-threaded and can only perform one task at a time, control of the processor is transferred from one application to another automatically by the operating system.
  • Cooperative multi ⁇ tasking places control of which task the CPU processes within each application. An application must first relinquish control of the CPU before processing can be transferred to another application. If an application doesn't relinquish control, it effectively steals CPU time from another application.
  • Pre-emptive multi-tasking places complete control of which task the CPU processes within the operating system. In this way, CPU load balancing among various applications is more closely controlled. However, it requires storing context data pertaining to the task that processing is being transferred from, and retrieving that data when processing returns to that task. This data may be stored in random access memory, if enough is available; otherwise main memory or any type of remote media storage (i.e. virtual memory, hard disk, CD-ROM, optical disk, and/or tape drives). Storing and retrieving task data (known as swapping) with a computer's hard disk can be very time-consuming.
  • Time-consuming CPU operations such as servicing multiple external interface units and/or executing lengthy program steps, need to be completed more efficiently.
  • Multiple external interface units and/or CPU-intensive routines need to be serviced in manner simulating multi-tasking without the overhead and delays encountered in existing co-operative and pre-emptive multi-tasking systems.
  • each external user When multiple external user inputs are present, each external user must perceive that a processor is continuously servicing its corresponding external interface unit. Idle CPU time needs to be minimized.
  • the present invention provides a computer-implemented method and apparatus for emulating a digital cross-connect switch (DXC) network to fully test a telecommunication network monitoring and/or control system (MCS).
  • DXC digital cross-connect switch
  • MCS telecommunication network monitoring and/or control system
  • An advance in the ability to fully test an MCS is obtained by emulating the behavior of a digital cross-connect switching network in the presence and absence of dynamically selected network node configurations, trunk connections, failures, and/or normalizations.
  • Solicited and unsolicited communication between the MCS and a DXC network emulator of the present invention is emulated to match actual communication between the MCS and a DXC network in the presence and absence of selected network node configurations, inter-DXC trunk connections, failures, and/or normalizations.
  • emulator messages are generated which emulate solicited and unsolicited messages sent from DXC nodes to an MCS in the presence and absence of selected network node configurations, failures, and/or normalizations.
  • the content and protocol of the emulator messages matches the response and alarm messages which are generated by actual DXC nodes.
  • emulator messages for an enabled network control link are sent over a corresponding emulator control link. In this way, the communication between each DXC node and the MCS over respective network node control links is emulated.
  • Further features of the present invention for emulating a digital cross- connect network to test an MCS include simulated multi-tasking and user- interface control options.
  • the DXC emulator switches between servicing MCS inputs and user-inputs to substantially simulate multi-tasking and provide sub-second response. These switches are transparent to the user and the MCS which perceive the emulator to be servicing MCS communication and user- inputs continuously and in parallel.
  • Emulator control options entered through the user-interface include: dynamic node configuration, outage script creation, outage script selection, normalization/clear alarms, audit, and viewing a communication log, trace log, and a real time message display. Node failure, trunk failure, and equipment failure (including partial failures such as selected logical trunk failures), are emulated.
  • Different types of digital cross-connect switching networks and systems are emulated on a personal computer with sub-second response to test an MCS including DXC 3/3 networks, hybrid DXC 3/1 and 3/3 networks, and/or DXC 1/0 networks.
  • a communication module communicates to the MCS over emulator primary and secondary control links using a substantially identical communication protocol as the emulated DXC network.
  • emulator primary and secondary control links represent respective network node primary and secondary control links for each DXC node being emulated.
  • Configuration data is stored in emulator memory and updated during the emulator operation to represent the behavior of the emulated DXC network.
  • Topology data which describes the current and/or baseline topology of the emulated DXC network is also stored in emulator memory.
  • the configuration data among other things, records, enabled or disabled node control links.
  • the topology data among other things, speeds generation of navigation displays, outage scripts, and responses to MCS audits.
  • An intelligence module includes a simulated multi ⁇ tasking controller for switching control between a control-link servicer and a user-interface servicer.
  • An emulator processor controls the sending of solicited and unsolicited emulator messages.
  • An emulator message generator generates the emulator messages based on configuration data and/or topology data identifying DXC node responses to MCS commands and alarms.
  • An emulator link selector further determines enabled network node control links for DXC nodes from the configuration data.
  • emulator messages are generated which emulate solicited and unsolicited messages sent from DXC nodes to an MCS in the presence and absence of selected network node and trunk configurations, failures, and/or normalizations.
  • the content and protocol of the emulator messages matches the response and alarm messages which are generated by actual DXC nodes.
  • Node failure and trunk failure (including partial failures such as selected logical trunk failures) are emulated.
  • the topology data traces logical trunks, also called channels, through adjacent DXC nodes. Additional DXC nodes and/or trunks can be added or deleted from the topology data during pre-processing or emulator operation to test different postulated network designs. Detailed knowledge of intermediate site and equipment within the emulated DXC network is not necessary. Partial or logical trunk outages can still be emulated by generating appropriate near-side port alarms at adjacent DXC nodes facing the emulated trunk failure.
  • a third embodiment is provided for emulating a dynamically configured
  • the topology data traces logical trunks, also called channels, through adjacent DXC nodes.
  • the topology data further includes port provision data identifying the allocation of channels for cross- connected ports at DXC nodes. Additional DXC nodes and/or trunks can be added or deleted from the topology data during pre-processing or emulator operation to test different postulated network designs.
  • the topology data can be updated in response to MCS channel level commands (i.e. grow/de-grow, connect/dis-connect, and cross-connect commands) to set up paths through provisioned ports in the emulated DXC network. Detailed knowledge of intermediate site and equipment within the emulated DXC network is not necessary. Partial or logical trunk outages can still be emulated by generating appropriate near-side port alarms at adjacent DXC nodes facing the emulated trunk failure.
  • the present invention further provides a computer-implemented method and apparatus for performing multiple computer program tasks in a pseudo- parallel fashion which simulates multi-tasking.
  • Program modules for carrying out the multiple tasks are programmed to switch control between tasks.
  • Relatively long, time-consuming program modules contain calls to transfer processor control to shorter program modules which await servicing.
  • these calls are strategically inserted after one or more partial logic units of work in a long program module.
  • the results of the shorter program module are then made available sooner. Control returns to the relatively long program module before a delay is perceived.
  • multiple computer tasks are performed efficiently in a pseudo-parallel order which reduces idle CPU time and while maintaining the perception of continuous multi-tasking to external users.
  • a method and apparatus for servicing multiple external interface units in a pseudo-parallel order simulating multi-tasking is provided.
  • An application program services each of these external interface unit through calls strategically inserted in respective program modules.
  • Relatively long program modules contain calls to transfer system control to shorter program modules which need servicing. These calls are strategically inserted in a long program module after one or more partial logic units of work have been completed.
  • a check is first made to determine whether servicing of another external interface unit with a short program module is required. If servicing is required, then control is transferred to execute the short program module.
  • the short program module further contains strategically programmed calls to return system control to the long program module before an external user can notice the interruption in the servicing of the external interface unit driven by the long program module.
  • the calls can be inserted in the short program module after a complete logic unit of work (for relatively quick tasks) or after one or more partial logical units of work (for longer tasks).
  • a simulated multi-tasking routine is used to switch control between a user-interface module and a communication module.
  • the user-interface module services user-inputs through a keyboard and/or mouse device and application outputs through a printer and/or display.
  • the communication module services communications received and sent over a communication link.
  • Significant CPU efficiencies are realized, as hundreds of external devices can be serviced by one CPU. Larger applications can be run on smaller, less expensive CPUs, thereby, extending the useful life of existing platforms. Idle CPU time, such as the delays which arise from waiting for user keyboard inputs or printer outputs, is significantly reduced while still conveying the perception of multi-tasking to external users.
  • a method and apparatus for executing lengthy computer program steps and relatively short computer program steps in a pseudo- parallel order simulating multi-tasking is provided.
  • Relatively long program modules i.e. lengthy computations or logic paths, such as complex spreadsheet operations or nested conditional branching operations
  • These calls are strategically inserted in a long program module after one or more partial logic units of work have been completed.
  • the short program module further contains strategically programmed calls to return system control to the long program module before any suspension of the first long program module is adversely noticed.
  • the calls can be inserted in the short program module after a complete logic unit of work (for relatively quick tasks) or after one or more partial logical units of work (for longer tasks).
  • the transfer of system control is determined by the application programmers, and therefore allows processing time per task to be managed more closely than with cooperative multi -tasking.
  • the state of each task is recorded within local and global parameters. This eliminates the need for disk-swapping that is required for pre-emptive multi-tasking, and therefore enables task processing to proceed quicker than with pre-emptive multi-tasking.
  • system control transfer is optimized, automatic and based on programmed source code. This eliminates unnecessary delays introduced into the program that are caused by a process checking for input from an external source and/or waiting until the input is received before proceeding to the next task.
  • the present invention provides simulated multi-tasking via application programming, it can be operated on either a single-tasking or multi ⁇ tasking operating system. Since the simulated multi-tasking routine is programmed into the application rather than the operating system, it is also portable among different types of operating systems.
  • FIGS 1 A and 1 B are block diagrams showing selected nodes of a digital cross-connect (DXC) network coupled to a Monitoring and Control System (MCS).
  • Figure 2 is a functional diagram of a DXC Network Emulator according to the present invention showing logical connectivity of emulated nodes to the MCS being tested.
  • DXC digital cross-connect
  • MCS Monitoring and Control System
  • Figure 3 is a block diagram of an DXC Network Emulator architecture according to the present invention.
  • Figure 4 is a flowchart illustrating overall DXC Network Emulator operation according to the present invention.
  • Figure 5 is a flowchart illustrating the operation of an Intelligent Commands and Responses routine in more detail.
  • Figure 6 is a flowchart illustrating the operation of an User-Interface routine in more detail.
  • Figure 7A is a screen display used in a DXC 3/3 network emulator example of the present invention for navigation through a configuration file .
  • Figure 7B is a screen display of a configuration file as in Figure 7A further showing a pull-down menu of DXC emulator control options.
  • Figure 8 is flowchart illustrating the operation of one DXC emulator control option for creating an outage script emulating a network outage.
  • Figures 9, 10, 1 1, and 12 are screen displays used in an example of the present invention for creating an outage script according to the process of Figure 8.
  • Figure 13 is flowchart illustrating the operation of another DXC emulator control option for selecting an outage script to emulate a network outage.
  • Figures 14 and 15 are screen displays used in an example of the present invention for selecting and executing an outage script according to the process of Figure 13.
  • Figure 16 is flowchart illustrating the operation of another DXC emulator control option for clearing alarms to emulate a network normalization.
  • Figures 17 and 18 are screen displays used in an example of the present invention for clearing alarms according to the process of Figure 16.
  • Figure 19 is a screen display used in an example of the present invention illustrating the operation of another DXC emulator control option for auditing the emulated network node port configuration.
  • Figures 20, 21, and 22 are screen displays used in an example of the present invention.
  • Figure 20 illustrates the operation of another DXC emulator control option allowing navigation through a communication log file.
  • Figure 21 illustrates the operation of another DXC emulator control option allowing navigation through a trace log file.
  • Figure 22 illustrates the operation of another
  • DXC emulator control option allowing navigation through a real-time message display.
  • Figure 23 A is a screen display used in a hybrid DXC 3/3-3/1 network emulator example of the present invention for navigation through a configuration file.
  • Figure 23B is a screen display of a configuration file as in Figure 23A further showing a pull-down menu of DXC emulator control options.
  • Figure 24 is flowchart illustrating the operation of one DXC emulator control option for creating an outage script emulating a network outage.
  • Figures 25 and 26 are screen displays used in an example of the present invention for creating an outage script according to the process of Figure 24.
  • Figure 27 is flowchart illustrating the operation of another DXC emulator control option for selecting an outage script to emulate a network outage.
  • Figures 28 and 29 are screen displays used in an example of the present invention for selecting and executing an outage script according to the process of Figure 27.
  • Figure 30 is flowchart illustrating the operation of another DXC emulator control option for clearing alarms to emulate a network normalization.
  • Figures 31 and 32 are screen displays used in an example of the present invention for clearing alarms according to the process of Figure 30.
  • Figure 33 is a screen display used in an example of the present invention illustrating the operation of another DXC emulator control option for auditing the emulated network node port configuration.
  • Figures 34, 35, and 36 are screen displays used in an example of the present invention.
  • Figure 34 illustrates the operation of another DXC emulator control option allowing navigation through a communication log file.
  • Figure 35 illustrates the operation of another DXC emulator control option allowing navigation through a trace log file.
  • Figure 36 illustrates the operation of another
  • DXC emulator control option allowing navigation through a real-time message display.
  • Figure 37A is a screen display used in a DXC 1/0 network emulator example of the present invention for navigation through a configuration file .
  • Figure 37B is a screen display of a configuration file as in Figure 37A further showing a pull-down menu of DXC emulator control options.
  • Figure 38 is flowchart illustrating the operation of one DXC emulator control option for creating an outage script emulating a network outage.
  • Figures 39 and 40 are screen displays used in an example of the present invention for creating an outage script according to the process of Figure 38.
  • Figure 41 is flowchart illustrating the operation of another DXC emulator control option for selecting an outage script to emulate a network outage.
  • Figures 42 and 43 are screen displays used in an example of the present invention for selecting and executing an outage script according to the process of Figure 41.
  • Figure 44 is flowchart illustrating the operation of another DXC emulator control option for clearing alarms to emulate a network normalization.
  • Figures 45 and 46 are screen displays used in an example of the present invention for clearing alarms according to the process of Figure 44.
  • Figures 47A and 47B are screen displays used in an example of the present invention illustrating the operation of another DXC emulator control option for auditing the emulated network node configuration including channels allocated through cross-connected ports.
  • Figures 48, 49, and 50 are screen displays used in an example of the present invention.
  • Figure 48 illustrates the operation of another DXC emulator control option allowing navigation through a communication log file.
  • Figure 49 illustrates the operation of another DXC emulator control option allowing navigation through a trace log file.
  • Figure 50 illustrates the operation of another DXC emulator control option allowing navigation through a real-time message display.
  • Figure 51 is a block diagram of a computer architecture for simulating multi-tasking according to the present invention.
  • Figure 52 is a flowchart illustrating a simulated multi-tasking process.
  • Figure 53A and 53B show a program implementation of the simulated multi-tasking process.
  • Figure 54 is a flow chart illustrating an example of simulated multi- tasking carried out in response to particular external user inputs.
  • the present invention provides a computer-implemented method and apparatus for emulating a digital cross-connect network to fully test a telecommunication network monitoring and control system (MCS). Both the communication between each digital cross-connect switching node and the MCS and the behavior of a digital cross-connect switching network are emulated in the presence and absence of selected network configurations (including node and/or trunk configurations), failures, and/or normalizations. Sub-second responses
  • topology data traces logical trunks, also called channels, through adjacent DXC nodes.
  • the topology date further includes port provision data identifying the allocation of channels for cross-connected ports at DXC nodes. Additional DXC nodes and/or trunks can be added or deleted from the topology data during pre-processing or emulator operation to test different postulated network designs.
  • the topology data can be updated in response to MCS channel level commands (i.e. grow/de-grow, connect/dis ⁇ connect, and cross-connect commands) to set up paths through provisioned ports in the emulated DXC network.
  • MCS channel level commands i.e. grow/de-grow, connect/dis ⁇ connect, and cross-connect commands
  • digital cross-connect switch network refers to any type of communication network having at least some nodes which include digital cross-connect switches. These digital cross-connect switches can switch network data electrically or optically through multiple ports. Any type of network data and format can be switched at each node by providing known multiplexers and/or light conversion elements. For example, each node can switch time-domain signals at different bit rates in any of DSO to DS4 type formats and/or OC-1 to OC-198 formats.
  • a DXC 3/3 network refers to a DXC network which includes a plurality of DXC 3/3 nodes for switching high-speed DS3 data signals.
  • a DXC 3/3 - 3/1 network refers to a hybrid DXC network which includes a plurality of DXC 3/3 nodes for switching high-speed DS3 data signals and a plurality of DXC 3/1 nodes for switching low-speed DS1 and/or high-speed DS3 data signals.
  • a DXC 1/0 network refers to a DXC network which includes a plurality of DXC 1/0 nodes for switching low-speed DSO and/or DS 1 data signals.
  • DXC digital cross- connect switch network
  • DSC Digital Access and Cross-Connect System
  • BB-DXC broadband digital cross-connect
  • slow-switch slow-switch
  • nailed-up switch channel switch
  • channel switch Digital cross-connect switch capability found in system components such as Tl multiplexers is also covered by the terms digital cross- connect network and DXC as used herein.
  • Monitoring and Control System refers to a centralized system or a remote system feeding to a central system, which communicates with individual switching nodes of the digital cross-connect network to monitor and/or control network operations such as real-time network restoration, dynamic configuration, private line service, load balance and traffic flow.
  • the MCS can communicate with a controller to control digital cross- connect switching and/or can communicate with a digital cross-connect switch directly.
  • MCS Monitoring and/or Control System
  • OSS Operaational System Support
  • RTR Real Time Restoration Software
  • a Partial Logical Unit of Work is an elementary logical process within a program, such as a program module for servicing an external interface or any other computer task.
  • a Complete Logical Unit of Work (CLUW) consists of an entire logical process in a program, such as a program module servicing on an external interface or any other complete task.
  • One or more PLUWs can constitute a single CLUW.
  • External interfaces provide data communication between external interface units (including multiple instances thereof, i.e. multiple printers) and a CPU.
  • the external interface units can include, but are not limited to, any I/O type of peripheral device (i.e. a keyboard, mouse, trackball, joystick, and display unit), a data communication link, network link, or an external application program.
  • the present invention is described in the example environment of a computer which fully tests an MCS product in the presence and absence of selected network failures prior to installation by emulating a digital cross-connect network.
  • Different types of digital cross-connect networks are emulated including a DXC 3/3 network, hybrid DXC 3/1 and 3/3 network, and/or a DXC 1/0 network. Description in these terms is provided for convenience only. It is not intended that the invention be limited to application in this example environment. In fact, after reading the following description, it will become apparent to a person skilled in the relevant art how to implement the invention in alternative environments.
  • the present invention for simulating multi-tasking is described in the example environment of personal computer application program modules for servicing multiple external interfaces or other CPU-intensive computer tasks. Description in these terms is provided for convenience only. It is not intended that the invention be limited to application in this example environment. In fact, after reading the following description, it will become apparent to a person skilled in the relevant art how to implement the invention in alternative computer programming applications, systems, and environments. Since the invention provides a fundamental method of developing software applications, an infinite number of examples exist that make use of the present invention.
  • FIG. IA shows a block diagram of an example digital cross-connect switching network (DXC) 100 being emulated according to the present invention.
  • DXC digital cross-connect switching network
  • the DXC network 100 communicates with an MCS 104 through network control links 108.
  • DXC network 100 comprises a DXC 3/3 network, a hybrid DXC 3/3 and 3/1 network, a DXC 1/0 network, or any other type of communication switching network can be emulated according to the present invention.
  • DXC network 100 consists of a plurality of DXC switching nodes A to N.
  • nodes A, B, and N with digital cross-connect switching capability are shown for simplicity. In general, any number of nodes can be included.
  • long-distance communication carriers employ hundreds and even thousands of switching nodes within a local, regional, national, or global digital cross-connect network.
  • Each node is interconnected to other nodes through transmission links, also called inter-DXC trunks or channels 102-106.
  • an inter-DXC trunk 102 links nodes A and B
  • an inter-DXC trunk 104 links nodes B and N
  • an inter-DXC trunk 106 links nodes A and N.
  • Each of these inter-DXC trunks 102-106 can consist of one or more physical and/or logical trunks and extend to other nodes (not shown).
  • Each inter-DXC logical trunk 102-106 can transport electrical, optical, microwave, radio, and/or satellite data signals.
  • copper wire, coaxial cable, optical fiber, broadcast systems, and/or satellites can be used as the physical medium for one or more transmission links.
  • Nodes can be interconnected through inter-DXC trunks and links according to mesh, ring, point-to-point, star, tandem, multi-level hierarchies or any other type of network topology design. Connectivity among the various nodes by inter-DXC trunks may take on a multitude of configurations (physical and logical), depending on the needs of the network. Inter-DXC trunks can further include intermediate sites and/or terminal equipment (not shown in Figure IA). These sites serve primarily as points of traffic termination and redirection of transmission routes. Different types of communication equipment are typically attached at intermediate sites along a trunk, such as: remote terminals, computers, servers, routers, repeaters, private networks (e.g.
  • FIG. 1 shows an example of intermediate sites 102a through 102n provided along inter-DXC trunk 102 representing terminal equipment.
  • DXC 3/3 systems which carry a greater volume of data to multiple users at faster bit rates typically involve many intermediate sites and equipment.
  • MCS 104 is responsible for real-time restoration of network traffic.
  • the MCS 104 can also be used to dynamically establish and breakdown logical path connections.
  • Such logical path connections can consist of one or more inter-DXC trunks connected in series through the DXC network 100. This operation is more common in hybrid DXC 3/3 and 3/1 networks, and especially in DXC 1/0 networks as part of an enhanced private line service.
  • each switching node A, B, and N includes a digital cross-connect switch 101 and a controller 103.
  • a digital cross-connect switch 101 For simplicity, only a 2 X 2 digital cross-connect switch 101 is shown which effectively switches data between two ports on each side of the switch. The number of ports, however, can be much greater depending upon the particular application and the available electrical and optical switch technology.
  • ports which can support traffic are provisioned. Each provisioned port can support one or more logical inter-DXC trunks or channels.
  • Controllers 103 can each consist of hardware, custom logic, and/or software implemented on a computer, processor, micro-processor, or other type of processing and control system.
  • Each controller 103 controls the switching of a respective digital cross-connect switch 101 and communicates with the MCS 104, i.e. a central office.
  • the MCS 104 i.e. a central office.
  • at least one primary network control link 108 A and a redundant secondary network control link 108b is provided to ensure reliable communication between each respective switching node A to N and the MCS 104 as shown.
  • Fault processing can be included in each controller 103 to monitor the state of the switch 101 and to determine and report any link failures affecting a respective node.
  • the fault processing and monitoring functionality of the controllers 103 can be inco ⁇ orated into the MCS 104; however, this can be impractical in larger distributed networks.
  • Controllers 103 at nodes A and B communicate status information with each other through a highly-reliable off-band digital communication network (DCN) 120 according to known protocol, i.e. X.25. For example, if data traffic typically sent from node A does not reach node B, a loss-of-signal message can be generated by controller
  • DCN off-band digital communication network
  • controllers 103 at node B indicating loss-of-signal at node B.
  • the controller 103 at node A likewise can generate an alarm if an acknowledgment of the receipt of data by node B is not received.
  • controllers 103 can communicate with each other through an off-band DCN 120 to confirm fault detection. Reliable alarm messages are then sent from either or both of the controllers 103 at nodes A and
  • the separate DCN network 120 and the processing to confirm fault detection by the controllers 103, as in a Distributed Restoration Algorithm (DRA), is clearly optional.
  • DCA Distributed Restoration Algorithm
  • a digital cross- connect network being emulated need not have a separate DCN 120 linking controllers 103 as all intelligence can be inco ⁇ orated into the MCS 104.
  • Status messages are generated by controllers 103 and sent to MCS 104 to indicate, acknowledge, or confirm a link or node state including idle, active, inactive, or detected fault states.
  • an alarm message indicating the link failure is ultimately sent from either or both of the controllers 103 at nodes A and B to the MCS 104.
  • the digital cross-connect switch 101 at node A is then switched by controller 103, in response to MCS 104 commands, to direct traffic along a different physical and/or logical inter-DXC trunk 106, thereby, avoiding the link failure X.
  • the MCS 104 commands can be originated at a central monitoring and/or control system, a local node test console, or a remote test unit.
  • Monitoring and Control System (MCS) 104 provides the intelligence to the network 100 via monitoring and control of the DXC nodes A to N.
  • MCS 104 monitors and controls the DXC nodes A to N via network control links 108 which connect the MCS 104 to each node.
  • network control links 108 which connect the MCS 104 to each node.
  • These network control links which are standard communication channels, are connected to the MCS 104 via a Link A 106a for primary control links and Link B 106b for secondary control links.
  • Link A 106a and Link B 106b represent data termination equipment needed to connect the communication channels in links 108a and 108b to a computer supporting the MCS 104.
  • a redundant MCS (not shown) is often connected to Links 106a and 106b as a back-up or watchdog in the event of MCS 104 failure.
  • DXC Network Emulator for Testing a MCS is often connected to Links 106a and 106b as a back-up or watchdog in the event of MCS 104 failure.
  • FIG. 2 there is shown a simplified functional diagram of a DXC Emulator 200 according to the present invention which emulates behavior of a DXC network to test an MCS.
  • the emulated DXC network can include, for example, the DXC network 100 described earlier with respect to Figures 1 A and
  • the Emulator 200 is connected to an MCS 104 through two bi-directional communications links, that is, primary and secondary emulator control links 208a and 208b.
  • the primary emulator control link 208a bridges MCS Link A-2 106a and Emulator Link A- 1 206a.
  • the secondary emulator control link 208b bridges MCS Link B-2 106b and Emulator Link B-l 206b.
  • the primary emulator control link 208a and the secondary emulator control link 208b are simply multiplexed extensions emulating the primary and secondary network node control links 108a and 108b respectively at each DXC node A - N. Data can be transmitted over each of these emulator control links
  • 208a and 208b in any standard data communications protocol such as X.25, TCP, IP, Frame-Relay, ATM, SMDS, Ethernet, FDDI, ISDN, SDLC, BISDN, and any other LAN or WAN data link protocol. See, e.g. Martin J. and Mos J., TCP/IP Networking: Architecture, Administration, and Programming (Prentice Hall: New Jersey 1994), pages 6-8, inco ⁇ orated by reference herein.
  • An X.25 packet protocol and associated virtual logic circuits are used in a preferred embodiment to allow reliable multiplexing and logical routing of MCS and emulator messages.
  • emulator control links 208a and 208b are shown. As would be apparent to one skilled in the art, greater numbers of links can be accommodated by expanding a communications port to increase the volume and rate of data flow between the MCS and the Emulator. For example, 16 emulator control links corresponding to eight pairs of primary and secondary control links.
  • Emulator 200 further includes Emulated Network Data 210 representing the behavior of the DXC network 100 being emulated.
  • the Emulator 300 includes four primary modules: Communications Module 320, User-Interface Module 330, Data Access Module 340, and an Intelligence Module 350. Each module 320 to
  • 350 can be implemented as software, firmware, hardware, or any combination thereof.
  • Communications Module 320 manages communication between the Emulator 300 and the MCS 104.
  • the Communications Module 320 manages the primary and secondary emulator control links 208a and 208b, monitors incoming MCS messages and outgoing emulator messages, and provides the necessary communications protocol and collision prevention.
  • Logical routers 321a and 321b multiplex/de-multiplex messages sent and received by the Emulator 300 over the primary and secondary emulator control links 208a and 208b.
  • User Interface Module 330 manages a user-interface 315 through which external users can access, navigate and control the Emulator 300.
  • the user-interface 315 can consist of any standard PC I/O component such as a keyboard, mouse, and/or display screen.
  • a graphical user-interface (GUI) can be used.
  • An extended ASCII graphics interface encompassing an extended ASCII character set is preferred to quicken response.
  • Data Access Module 340 manages data access (input and/or retrieval) to a memory unit 310 and any stored outage scripts 313.
  • memory unit 310 stores a configuration data file 311 and selected topology data files 312.
  • the configuration data file 311 contains configuration data in various data fields representing the behavior of the DXC network being emulated to test MCS 104. Parameters that are modified during Emulator 300 execution are saved to this file.
  • An example configuration data file 311 (RTR CONF. DAT) and its constituent data fields is described further with respect to Figure 7A.
  • the topology files 312 contain current and/or baseline topology data representing selected aspects of the topology of the emulated DXC network 100 to facilitate emulator navigation and control. For example, to emulate a DXC 3/3 network these topology data files 312 contain data pertaining to DXC nodes interconnectivity, equipments and/or sites between DXC nodes, DXC ports, and logical trunks traversing the DXC nodes. Specific examples of topology files 312
  • these topology data files 312 contain data pertaining to DXC nodes interconnectivity, DXC ports, and logical trunks traversing the DXC nodes.
  • topology files 312 ADJACENT.DAT, TRUNKS,DAT, AUDIT.DAT, and MASTER.DAT
  • each of their data fields as used to emulate a flexible DXC 3/3 and 3/1 network topology
  • Figures 24 to 26 and 33 Specific examples of topology files 312 (ADJACENT.DAT, TRUNKS.DAT, AUDIT.DAT, and MASTER.DAT), and each of their data fields, as used to emulate a dynamically configured DXC 1/0 network topology at the channel level, are discussed below with respect to the Emulator operation ( Figures 38 to 40, 47A, and 47B).
  • Custom flat-files 311 and 312 are used which allow fast data retrieval by Data Access Module 340 averaging less than one millisecond per data return. Databases and other memory arrangements can be also used.
  • the configuration data 311 and topology data 312 can be stored in one or more database files and accessed using a standard database module and database application package.
  • memory unit 310 can consist of cache memory, main memory, magnetic storage, optical storage, disk, tape, and/or any other type of media storage device and memory hierarchy.
  • An Intelligence Module 350 provides the intelligent processing of the Emulator 300 and interfaces with each of the other three modules 320, 330, and 340.
  • Intelligence module 350 includes a control link servicer module 351 , a user- interface servicer module 352, a simulated multi-task controller module 353, an Emulator processor 354, an emulator message generator module 355, and an emulator link selector module 356.
  • each of these modules 320 to 350 represent software applications which can be executed by a personal computer processor.
  • Emulator 300 can be executed on any computer system.
  • a stand-alone personal computer (PC) system is preferred, however, as such platforms are relatively inexpensive and widely available.
  • the Emulator 300 can be run on an IBM-compatible PC with an Intel-486, 66-MHZ processor, 8MB RAM, 80MB Hard-disk drive, an OS/2 Operating system, a Super VGA monitor, and a Microsoft compatible mouse with a 7.04 driver.
  • An Eicon X.25 communications card was used.
  • these PC hardware requirements are illustrative. Faster processors, increased memory arrangements, and higher resolution displays can be used to improve performance. Likewise, inexpensive slower processors and hardware can be used.
  • each of these Emulator modules 320 to 350 to emulate a DXC network (including, but not limited to, a DXC 3/3 network) to test a MCS in the presence and absence of network failure (trunk, site, and/or equipment failure) is now described further with reference to Figures 4 to 22.
  • a DXC network including, but not limited to, a DXC 3/3 network
  • each of these Emulator modules 320 and 350 to emulate a DXC network with a flexible topology (including, but not limited to, a DXC 3/3
  • Flexible network topology data is used to allow the MCS operation to be tested against different node and/or trunk connections.
  • each of these Emulator modules 320 to 350 to emulate a dynamically configured DXC network (including, but not limited to, a DXC 1/0 network) to test a MCS in the presence and absence of network failure (node and/or trunk failure) is now described further with reference to Figures 4 to 6 and
  • Flexible network topology data at the channel level is used to allow the MCS operation to be tested against different node and/or trunk connections.
  • Dynamic path configurations are emulated in response to MCS commands by setting up and breaking down corresponding inter-DXC trunks or channels in the topology data.
  • FIG 4 shows a flowchart of the overall end-to-end operation of the DXC Emulator 300. This overall operation, as described herein, is run under the general control of the Intelligence Module 350, and in particular Emulator processor 354.
  • Emulator processor 354 runs a pre-processing routine to create an initial network configuration data file 31 1 and the topology data files 312 to be used by the Emulator 300. Pre-processing routines can also be run periodically to update network configuration and baseline topology data.
  • step 402 data representing the topology of the DXC network 100 being emulated is retrieved from any of three sources: an external data source, the Monitoring and Control System 104 (assuming connectivity established), and manual input from a user through user-interface
  • MCS 104 can identify how a DXC network is physically provisioned.
  • Grow/de- grow commands can identify which ports within each DXC node are installed or equipped for link communication.
  • Manual input from a user can be used to dynamically configure a planned network design or private line service, or to change a portion of the network for the purpose of running test cases.
  • the topology data 312 traces trunk data through adjacent nodes, nodes and/or trunks can be added (or deleted) without detailed knowledge of intermediate site and equipment and other topology details. In this way, different combinations of network node and/or trunks are easily set up to test the MCS.
  • Various flat-file access routines parse and process initial data into corresponding data fields in the configuration file 311 and topology data files 312.
  • the Emulator processor 354 draws selected data needed by the Emulator 300 from data fields of a main external database representing the complete network information and inserts the data into corresponding data fields to form the configuration file 31 1 and topology files 312.
  • a user starts the DXC Emulator 300 to initiate operation.
  • the user can be presented with a display of the main configuration file 311.
  • Two log files (communication log and a trace log) are also created, if not already created in the pre-processing routine of step 402.
  • the communications log file (named COMMLOG.DAT) records all messages received and sent by the emulator.
  • the message log file (named TRACELOG.DAT) records all error messages and transaction return codes created during Emulator 300 execution.
  • the Emulator 300 offers the option to run in Demo Mode (step 406). If the user opts to run the Emulator in Demo Mode, the Emulator processor 354 proceeds to step 410.
  • Demo Mode the Emulator has no connectivity to the MCS 104.
  • the Emulator 300 operates using data from the configuration and topology data files and from user input as described below, but it does not receive or respond to commands from the MCS 104.
  • an internal X.25 driver can be used to generate predetermined MCS- type message traffic to send to the Communication module 320 for demonstration or training pu ⁇ oses. If a Demo Mode is not selected, the Emulator 300 establishes connectivity with the MCS 104 (step 408).
  • Status messages can be sent back and forth between the MCS 104 and the communication module 320 to confirm the establishment of connectivity. Once connectivity is verified by the Emulator processor 354 and/or Communications Module 320, the Emulator can receive and respond to commands from the MCS 104 (step 410).
  • the Emulator 300 receives commands from the MCS 104.
  • MCS commands are communicated through communication module 320 to the Intelligence Module 350.
  • MCS commands are detected and processed by Emulator processor 354 when the control-links are serviced by control link servicer 351.
  • Emulator processor 354 works with Emulator message generator 355 and Emulator message link selector 356 to send intelligent solicited and unsolicited responses back to the MCS 104 which emulate actual responses (or lack thereof) over network node control links 108a, 108b in the DXC network 100 being emulated.
  • the Emulator 300 allows for user interaction to perform tasks such as modifying the configuration of the emulated DXC nodes A to N, modifying the architecture of the DXC network 100, creating an outage, and/or clearing an outage.
  • user-interface servicer 353 services the user-interface
  • Emulator 300 user inputs for navigation and control of the Emulator 300 are communicated through user-interface module 330 to the Emulator processor 354 of Intelligence Module 350. Both of these steps 410 and 412 in the operation of Emulator 300, are described further below with respect to a specific user-interface example.
  • step 416 operation of the Emulator 300 stops (step 416).
  • the Emulator 300 can be run 7 days a week, 24 hours a day to allow extensive MCS testing and evaluation.
  • steps 410 and 412 are carried out in a pseudo-parallel fashion to simulate multi-tasking.
  • control is passed between tasks supporting step 410 and step 412 to optimize overall application execution time.
  • the switching between tasks in steps 410 and 412 is performed sufficiently quickly as to be transparent to the user and the MCS 104.
  • Simulated multi-tasking further enables the Emulator to accurately emulate the behavior of an entire DXC network consisting of hundreds of nodes (and node control links) by providing sub-second responses to a MCS under test.
  • Sub-second response means messages can be formulated by the Emulator 300 in milliseconds, i.e. approximately 0 to 13 milliseconds. The emulator messages further arrive at the MCS in less a second, and usually within milliseconds, i.e. approximately 10-100 milliseconds, depending upon X.25 communication transit delays.
  • Sub-second response for the user-interface means the Emulator 300 responds to a user-input in less than a second and typically within milliseconds, i.e. 10-250 milliseconds.
  • the simulated multi-task controller 353 switches control between the control-link servicer 351 and the user-interface servicer 352 according to a simulated multi-tasking routine.
  • This routine consists of four logical procedures:
  • Service control links (2) Check user interface, (3) If user input detected, service user interface, and (4) Switch from servicing the user-interface to service control links but return to servicing the user-interface such that the switch to servicing control links is substantially imperceptible or at least not inconvenient to the user.
  • this simulated multi-tasking routine is programmed into respective program modules in the control-link servicer 351 and the user-interface server 352.
  • simulated multi ⁇ task controller 353 switches control to control link servicer 351 to service control links 208a, 208b.
  • Emulator processor 354 detects and responds to any incoming messages from the MCS 104.
  • the simulated multi-task controller 353 checks to determine whether a user-input has been received (i.e. stored in a buffer).
  • the simulated multi-tasking controller switches control to user-interface servicer 352 to service user-input(s), that is, begin executing a corresponding user-interface program module. Only one partial logical unit of work is executed at a time to service the user-input. After each partial logical unit of work is performed in the user- interface code, controller 353 returns to servicing MCS control links. In this way, the MCS 104 does not perceive the Emulator 300 to be unresponsive. A partial logic unit of work is then completed in the servicing of the MCS links before control switches back to complete execution of another user-interface code partial logic unit of work. In this way, the user does not perceive a delay by the Emulator in processing user-inputs.
  • Simulated multi-task controller 353 transfers control from the painting of the screen after a partial logic of unit of work has been done by the user-interface servicer 352 toward servicing user-inputs. For example, after half of the screen pixel data is displayed, the simulated multi-task controller 353 switches control back to the control-link servicer 351 to service the control links. Control returns quickly to the user-interface servicer 352 to complete the painting of the screen.
  • the simulated multi-task controller 353 switches between tasks in such a short time interval, i.e. less than a millisecond, that external user(s) do not notice the interruption, and therefore perceive multi-tasking. In fact, this routine is performed faster than the native operation of either a single- or multi-tasking operating system (OS). Note the simulated multi-tasking routine may be run on either a single-tasking OS or a multi -tasking OS. In sum, simulated multi-tasking is executed frequently throughout the operation of the Emulator 300, and is performed with sufficient speed (subsecond response) as to be transparent to the user and to the MCS 104. Thus, to the user it appears as if the Emulator 300 is dedicated to the tasks required in responding to the user input.
  • OS multi-tasking operating system
  • FIG. 5 provides a detailed breakdown of the Intelligent Commands and Responses process (step 410).
  • the Emulator 300 services all emulated control links 108a, 108b between each emulated DXC node A to N and the MCS 104. To emulate an actual DXC network 100, this servicing of control links 108 must be performed continuously. For example, to emulate a typical DXC network 100, this servicing of control links 108 must be performed continuously. For example, to emulate a typical
  • DXC 3/3 network communications for several hundred control links 108a, 108b must be checked in a manner that the user perceives to be simultaneous to other tasks that the Emulator 300 must perform, such as respond to user inputs and provide screen displays.
  • communications for several hundred control links 108a, 108b must be checked in a manner that the user perceives to be simultaneous to other tasks that the Emulator 300 must perform, such as respond to user inputs and provide screen displays.
  • a simulated multi-tasking routine is conducted as described herein.
  • step 504 the Emulator processor 354 determines if any incoming commands from the MCS 104 have been found, i.e. placed in a buffer. If there are no incoming commands from the MCS 104, then this sub-process ends with step 520 and returns to the main process depicted in Figure 4. In step 506, Emulator processor 354 detects an incoming MCS command.
  • the MCS command is received over an emulator control link 208, and is intended for a particular DXC node.
  • These commands are defined by the particular types of vendors' DXC switches in use, and can be easily programmed into the Emulator 300.
  • the RTRCONF.DAT file includes a data field DXC Revision for identifying a specific command message set suitable for each respective DXC node depending upon the vendor. Examples of MCS commands which can be included in a message set in a preferred embodiment are:
  • Session Connect Establish communications session via control link
  • Session Connect Establish communications session via control link Channel Keep Alive: Verify the target DXC is able to communicate Initialization: Instruct the DXC as to the type of communication circuit
  • Alarm Audit Solicit status of DXC alarms (per port)
  • Configuration Status Solicit status of DXC node configuration
  • Cross Connect Command the DXC to redirect traffic
  • step 506 after receiving an incoming MCS command, the Emulator processor 354 (or communication module 320) logs the command in its communications log file, i.e. COMMLOG.DAT 510. For completeness, every command received from the MCS 104 and every response sent to the MCS 104 is logged in this file.
  • the file is designed to wrap around itself at the end-of-file mark, so it never needs to be reset. This enables the Emulator 300 to be run continuously on a 7x24 basis, without ever having to be shut down or restarted.
  • the Emulator processor 354 formulates an intelligent response to the MCS command which emulates the response or lack of response of the emulated DXC network to the incoming MCS command.
  • Emulator 300 emulates both (1) the content of messages sent from the emulated DXC nodes and (2) the enabling or disabling of network node control links 108a, 108b at the respective DXC nodes.
  • Emulator message generator 355 reads the particular MCS command and identifies a corresponding response having a content identical to the content used by a DXC node in the emulated DXC network 100 to which the MCS message is addressed.
  • Emulator message generator 355 reads the incoming MCS message and determines the DXC node to which it is addressed.
  • a message set is looked up for the particular DXC node in the configuration file 311.
  • a specific emulator message is then generated from the message set which corresponds to the received MCS commands.
  • the response messages that a particular DXC is capable of sending are specified in the message set. Thus, the content of these responses are identical to actual responses used by specific types of vendors' DXC nodes.
  • emulator message generator 355 can generate a Session Connected response. Likewise, if a Channel
  • emulate message generator 355 generates a Keep Alive response.
  • the emulator message generator 355 sometimes must look up or update configuration data 311 and/or topology data 312. For example, if an alarm audit message is received, the Emulator must also query the topology data file 312, to generate a response identifying the solicited port alarm status for the emulated DXC node. Similar checks are made of the configuration data 311 and/or topology data 312 when grow/de-grow, configuration status or connection audit messages are received.
  • Emulator processor 354 When MCS commands for controlling the DXC network are received, such as reconfiguring the nodes, Emulator processor 354 further updates the configuration database 31 1 and/or topology data 312 to reflect the control as appropriate. The Emulator message generator 355 then responds with a confirmation, or with a reason that the control was not implemented, such as a requested connection was not in-service. In addition, to emulating the content of DXC network node responses, the
  • Emulator 300 further determines if this response is to be transmitted to the MCS 104 to emulate communication by the DXC network over enabled network node control links 108a, 108b (step 514).
  • emulator link selector 356 queries the configuration database 31 1 to determine if the primary control link 108a or the secondary control link 108b to the MCS
  • data fields Active 1, Active 2 in the RTRCONF.DAT file 311 contain information on whether the respective emulated network control links 108a, 108b at a particular DXC node being emulated are enabled. If either link is enabled (i.e. a 1 bit is in the Active 1 or Active 2 data field), then the Emulator link selector 356 instructs the Emulator processor 354 to send the response from emulator message generator 355 to the MCS 104 (step 516).
  • step 518 outgoing responses are logged in the communications file, i.e. COMMLOG.DAT 510.
  • the sub-process ends with step 520 and returns to the main process depicted in Figure 4.
  • step 514 the Emulator link selector 356 determines a response cannot be transmitted, the sub-process ends with step 520 and returns to the main process depicted in Figure 4.
  • FIG. 6 shows an example of the User Interface Routine (step 412) in more detail.
  • the user is first presented with a number of user- interface options. These options allow a user to generate user-inputs to navigate and control Emulator 300 operation (steps 602 to 616).
  • the User-Interface Routine ends (step 620).
  • Each of these steps 601 to 616 is described further with respect to three user-interface examples corresponding to Figures 7A to 22, Figures 23A to 36, and Figures 37A to 50.
  • a display of the main configuration data file 311 is provided.
  • Figures 7A and 7B show an example of a display 700 of selected contents of a main configuration data file 311 representing a DXC 3/3 network in a preferred embodiment of the present invention.
  • the display 700 includes a button bar having a pull-down option menu 705 and a pull-down help menu 720. To reduce the size of the display window and improve processing speed, only nine different data fields 730 are typically displayed at a time as shown in Figure 7A. Scroll bars 735, 736 allow a user to scroll through the displayed data file 31 1.
  • the user can input and/or modify any of the displayed configuration data in one or more of the data fields 730.
  • the user can dynamically configure the DXC nodes and their interconnection in the DXC network being emulated (step 602).
  • these modifications can include: enabling / disabling control links, enabling / disabling entire DXC 3/3 nodes, enabling / disabling certain DXC 3/3 ports, enabling / disabling interconnecting equipment, trunks, or sites, changing DXC 3/3 node i.d., changing all response codes given by a particular DXC 3/3, corrupting response code data, clearing alarm conditions, changing message sets (changing vendor model type and/or model revision of a DXC 3/3).
  • standard point-click type of mouse and cursor movements (such as clicking and double-clicking) are used to navigate and dynamically input the above DXC node configuration modifications into the data fields 730.
  • sequence number data field (Seq. Num.) indicates an internal emulator count of the DXC nodes being emulated. Highlighting a row indicates a selected DXC Node.
  • FIG. 7A row 1 has been highlighted indicating the DXC node having a seq.num. 1 is selected.
  • the Transmit field is ON indicating the DXC node 1 emulates a transmitting DXC node which responds to MCS messages and sends unsolicited messages such as alarms. Moving a cursor to this location and clicking a mouse button enables a user to toggle the Transmit field data to OFF, thereby, simulating a completely off-line DXC node. This is useful to observe the polling behavior of the MCS 104.
  • Link A and Link B each have an up arrow indicating that the primary and secondary network control links 108a, 108b being emulated are both enabled for the DXC node 1.
  • the column header shows what type of information is communicated over each of the four virtual circuits per link in the X.25 protocol: A (Alarm), C (Command/Control), S (Status), and M (Man- Machine Interface).
  • the individual circuits are either logically or physically connected to the MSC (indicated by an "O") or not logically or physically connected (indicated by a "1" or a vertical bar) depending upon the connection of the Emulator 300 to the MCS 104.
  • Link A and Link B fields also indicate whether the respective simulated network control links for each DXC node are enabled.
  • the Link A and Link B fields are set during pre-programming and updated in response to an outage script or dynamic user-inputs to the Link A (ACSM) and Link B (ACSM) fields. Clicking or double-clicking either of the Link A (ACSM) or Link B (ACSM) fields enables or disables that respective network node control link being emulated.
  • Clicking at a Cmd RC receive field allows the user to set the type of Response Code that will be returned for all MCS messages and commands received for the selected DXC node 1.
  • the response code can be entered by the user or selected from a separate pop-up display window displaying the available Response code choices.
  • the following Response Code Table lists an example of a set of response codes and their descriptions which can be used:
  • the Emulator 300 automatically determines the appropriate response code for a MCS message based on the corresponding message set data. Otherwise, the Emulator 300 returns the users- specified response code message. Additional response codes can be used depending upon the behavior of the DXC nodes being emulated.
  • Changing a Corrupt Response field from "NO” to "YES” allows the user to corrupt data in all response messages sent for the selected DXC node. This allows the Emulator 300 to further test the response of the polling MCS 104 when receiving bad data from a DXC node.
  • the specific messages sent by a DXC node in response to MCS messages vary depending upon the DXC vendor, model, and revision.
  • the Message Set Data field (now shown) identifies a particular response message set for a specific DXC revision.
  • the number of message sets varies depending upon the different types of DXC nodes and revisions being emulated.
  • the message set values for this data field are typically set for each DXC node during pre-programming.
  • a dynamic configuration capability allowing values to be entered by the user or selected from a separate pop-up display window listing the available Message Set value choices can be provided.
  • Dynamic node configuration is also provided for selecting and changing data values found in the DXC Node and DTE data fields.
  • Changing the DXC Node (or Node ID) data field value allows the user to change the node identification number of the selected DXC node in the emulated DXC network 100.
  • the DTE data can be changed to ensure that the DTE address used by the Emulator 300 for a selected DXC node matches that the DTE address on the MCS 104 computer, i.e. a VAX address.
  • Two other configuration data fields 730, Card and DXC type, are preferably set during pre-programming as they are not often changed during a particular MCS test run.
  • the Card value identifies another specific communications card through which the Communications module 320 sends messages for a selected DXC node.
  • the DXC nodes are divided between the communication cards for load balancing and to improve emulator response.
  • the DXC type field identifies the type of DXC node, i.e. DXC 3/3, DXC 3/1 , and DXC 1/0 node. Changing the DXC type data field value allows the user to simulate a different DXC node type. Of course, it might be necessary to propagate this change in DXC type to other data fields such as the Message Set.
  • DXC name In a further preferred example of the present invention, clicking the cursor on the DXC name causes a series of windows to be displayed. These windows allow a user to identify and select adjacent DXC nodes, trunks, site, and/or equipment to emulate the presence and absence of a network failure. See Figures 9 to 12. These displays are described with respect to the creation of an outage script as shown in Figure 8.
  • step 604 the user can create an outage script file 313 that specifies an outage condition. This file can then be run (as specified later in reference to step 606) to emulate the network's response to an outage condition. This same file can also be run, subsequent to an outage emulation and under a normalization option (step 608), to normalize the network and clear the alarms that were triggered in response to the outage.
  • step 822 the user selects a DXC 3/3 node from the main configuration data 311. This can be done by selecting a DXC name data field from a configuration data display 700 shown in Figure 7A.
  • step 824 the user is then presented with a display 900 of all DXC 3/3 nodes that are adjacent to the selected node as shown in Figure 9.
  • the adjacent node data composing screen display 900 are quickly obtained from the topology data 312, i.e. an ADJACENT.DAT file generated during pre-processing routine 402 as described earlier.
  • the ADJACENT.DAT file can have a hub
  • DXC, Adjacent DXC, and DXC Type data fields to correlate hub DXC node data with associated adjacent DXC nodes according to the specific network topology being emulated.
  • step 826 the user selects an adjacent DXC node as indicated by the highlight 910.
  • the user is then presented with a display 1000 of all sites represented by named squares that are intermediate to the two selected DXC nodes, as indicated in step 828.
  • Intermediate site data is preferably obtained from a pre-processed Topology data file 312, such as a SITE2DXC.DAT file having a DXC-DXC and a site data field listing intermediate sites between any two adjacent DXC nodes.
  • step 830 the user selects one square representing the link between two sites from the display 1000.
  • step 832 all pieces of equipment connected between these two selected sites are listed in a display 1100.
  • This equipment represents the physical connection between the two sites, such as a fiber optic transmission system.
  • the equipment between two sites data can be drawn quickly from the topology data 312.
  • an EQPTRK.DAT data file having data fields (site pair, site code, Equipment and status) can be used to generate display 1 100.
  • the status of the equipment piece can be Assigned, Open, Patched and/or Restored.
  • step 836 the user selects a one, several, or all equipment pieces between the two sites to simulate a network failure.
  • a check mark is displayed next to any disabled equipment; a square indicates functioning equipment.
  • an outage script can be created by pressing the save button 11 10.
  • the process proceeds to step 842 with an assumption of a complete equipment failure affecting all logical traffic-bearing and non-traffic bearing trunks carried by the disabled equipment (step 836).
  • Equipment failures do not necessarily break communication over all logical trunks.
  • a display 1200 of the logical trunks (or channels) supported by a piece of equipment disabled is shown (step 838).
  • this information can be obtained from a Trunk data field in the EQPTRK.DAT which lists trunks carried between two sites through each equipment piece.
  • the user selects one or more of the displayed logical trunks to simulate a network failure, that is an outage condition of the selected logical trunks (step 840).
  • This process of disabling one or more logical trunks is then repeated for each piece of disabled equipment selected in step 834 before proceeding to step 842.
  • the Emulator processor 354 queries configuration data 31 1 and/or topology data 312 with the selected disabled trunks to identify all DXC 3/3 nodes that the selected trunks traverse.
  • any pre-processed topology file 312 which correlates trunks and nodes directly connected to the trunks such as a master system file (MASTER.DAT), or a custom inter-DXC trunk and node topology file can be used.
  • a MASTER.DAT file can list all topology data extracted by trunk number including equipment status (Assigned, Open, Patched, Restoration), site code, equipment name, port (port numbers), and port status relative to a break (i.e. near-side port, far-side port, or break).
  • equipment status Assigned, Open, Patched, Restoration
  • site code equipment name
  • port port numbers
  • port status relative to a break i.e. near-side port, far-side port, or break.
  • the Emulator processor 354 identifies all the near-side ports that are used by each DXC node to support the selected trunks.
  • Topology data 312 such as a master system file (MASTER.DAT) or a custom DXC 3/3 node and near-side port file.
  • MASTER.DAT master system file
  • DXC 3/3 node and near-side port file only the near-side ports of each supporting DXC 3/3 node will generate an alarm in response to the outage.
  • the near ⁇ side port is defined as the port facing the path towards the point of outage.
  • an outage script file can be a data file having respectively data fields for DXC name, DXC port, Trunk and Alarm message data.
  • Alarm messages can be provided in human-readable or non-human readable format.
  • Outage Script Creation ends (step 848) and returns to the User Interface process in Figure 6.
  • This outage script can be selected later during Emulator operation to simulate the corresponding outage condition ( Figure 13) or to normalize the emulated DXC network ( Figure 16). Normalization is the process of removing the outage and clearing alarms that were triggered by the outage condition.
  • 606-6166 can be input by a user through the pull-down Options menu 705.
  • Each of the steps 606-616 is described in sequence with respect to a corresponding pull-down option 706-716.
  • FIG. 13 shows the routine triggered by selecting the outage control option.
  • Figure 14 shows an example outage selection display 1400 which lists all available outage scripts (step 1302).
  • Figure 15 shows a selected outage script display 1500.
  • step 1304 the user selects a script, i.e. the highlighted outage script 1410, and runs the script by pressing the Run button 1420.
  • Emulator processor i.e. the highlighted outage script 1410
  • the configuration data 31 1 and/or topology data 312 is updated, where necessary, to identify DXC nodes, ports, trunks, equipment, or control links impacted by the outage (step 1305).
  • further Emulator operations in steps 410 and 412 will access topology data 312 and configuration data 311 which has been updated to reflect the outage condition saved in the selected outage script file.
  • the Emulator 300 emulates DXC network behavior to test an MCS 104 during an outage condition as well.
  • Alarm messages contained in the outage script file are generated (step 1306). These alarm messages, can be output to an outage script display 1500 as they are processed (step 1308).
  • the outage script display 1500 shows the following for each alarm: the selected DXC name, port, trunk showing an alarm, and the alarm message data.
  • the alarm messages can be provided in human- readable or non-human readable format. In one human-considerate feature of the present invention, binary alarm message data is converted to ASCII characters
  • step 1312 these alarm messages are then sent by the Emulator processor 354 to the MSC 104 for each DXC node near-side port identified in the outage script.
  • the alarm messages are sent unsolicited to the MCS 104 or solicited in the case of an alarm audit.
  • emulator link selector 356 further checks the current configuration data 311 for corresponding DXC nodes, i.e. Transmit, LinkA, LinkB, Active 1, and/or Active 2 data fields (step 1310). In this way, alarm messages representing trunk and/or equipment failure are only sent for transmitting DXC nodes having enabled control links A and/or B (108a, 108b).
  • the Outage script selection 606 routine ends in step 1314 and returns to step 620.
  • step 608 the user can emulate normalization of a DXC network.
  • This routine 608 for normalizing the emulated DXC network, or in other words, clearing the alarms, can be initiated by selecting the CLEAR ALARM option 708 from the pull-down menu 705.
  • Figure 16 shows the routine 608 triggered by selecting the outage control option.
  • a Clear Alarms selection display 1700 lists all available outage scripts (step 1602).
  • the user selects a script, i.e. the highlighted outage script 1710, and runs the script by pressing the Run button 1720.
  • Emulator processor 354 then executes the selected outage script file.
  • configuration data 31 1 and/or topology data 312 is updated where necessary to clear alarms and enable any disabled ports, trunks, equipment, or control links associated with the outage. In this way, further Emulator operations in steps 410 and 412 will access topology data 312 and configuration data 311 which is updated to reflect the normalization of an outage condition imparted from the selected outage script file.
  • step 1606 clear alarm messages drawn from the outage script file are generated. These clear alarm messages can be output to an outage alarm display 1800 as they are processed (step 1608).
  • the display 1800 shows the following for each cleared alarm: the selected DXC name, port, trunk showing a cleared alarm, and the cleared alarm message data.
  • simulated multi-tasking allows MCS commands to be serviced transparently in a pseudo-parallel fashion during execution of a normalization control option 708.
  • Clear alarm messages are then sent by the Emulator processor 354 to the MCS 104 for each DXC node near-side port identified in the selected outage script.
  • the alarm message are sent unsolicited to the MCS 104 or solicited in the case of an alarm audit by the MCS (step 1612). Before alarms are sent to the
  • emulator link selector 356 further checks the current configuration data 311 for corresponding DXC nodes, i.e. Transmit, LinkA, LinkB, Active 1, and/or Active 2 data fields (step 1610). In this way, clear alarm messages representing trunk and/or equipment normalization are only sent for transmitting DXC nodes having enabled control links A and/or B ( 108a, 108b).
  • 608 routine then ends in step 1614 and returns to step 620.
  • control options can be input by selecting respective options 710-716 in the pull-down menu 705.
  • the Audit display window 1900 is displayed when the Audit option 710 is selected (step 610). This display allows the user to see the current set of port parameters that the Emulator 300 is using to simulate each DXC node such as: site code, communication port and cross-connect port numbers, a broadcast port number, X.25 status, alarm type, and cross-connect configuration status.
  • the port data composing screen display 1900 is quickly obtained from the topology data 312, i.e. data fields in the AUDIT.DAT file generated during pre-processing routine 402 as described earlier. These data values can be dynamically changed through selections made at the user-interface 315 to more fully stress the MCS 104 with different combinations of data and test case scenarios.
  • One or more of the DXC node ports can be manually-selected to audit alarm generation. Pressing the transmit alarm button 1920 generates alarm messages for all ports marked for sending unsolicited alarms. For example, in Figure 19, during auditing, an alarm type 019 is sent for the selected DSC node port 1910 (DSC 01, Port 3).
  • the View Communication Log display window 2000 is displayed when the View Comm. Log option 712 is selected (step 612).
  • This display allows the user to see the COMMLOG.DAT file 510 during emulator operation for monitoring emulator and/or MCS performance and trouble-shooting.
  • This communication log contains in temporal sequence all incoming MCS messages and out-going Emulator messages. In the example shown in Figure 20, the following information is kept for each message: time which message was logged, DXC name, Port (port number on which the message was sent or received), Ckt (type of message sent i.e. unknown, alarm, control/command, audit, MMI), C/R (C represents incoming MCS command; R represents outgoing response), and the actual message.
  • the View Trace Log display window 2100 is displayed when the View Trace Log option 714 is selected (step 614).
  • This display allows the user to see a trace log, i.e. a TRACELOG.DAT file, during emulator operation for monitoring emulator and/or MCS performance and trouble-shooting.
  • the trace log contains in temporal sequence messages written to the trace log by the Emulator during program execution. The time at which messages are logged is recorded in milliseconds.
  • the View Real Time Message Display window 2200 displays incoming and outgoing messages like the Communication Log except the newly-logged data is scroll-displayed in real-time (step 616). This display allows the user to monitor and trouble-shoot emulator and/or MCS performance in real-time during emulator operation.
  • FIG. 23A and 23B show an example of a display 2300 of selected contents of a main configuration data file 31 1 representing a DXC 3/3 and 3/1 network in a preferred embodiment of the present invention.
  • the display 2300 includes a button bar having a pull-down option menu 2305 and a pull-down help menu 2320.
  • a button bar having a pull-down option menu 2305 and a pull-down help menu 2320.
  • Scroll bars 2335, 2336 allow a user to scroll through the displayed data file 311.
  • the user can input and/or modify any of the displayed configuration data in one or more of the data fields 2330.
  • the user can dynamically configure the DXC nodes and their interconnection in the DXC network being emulated (step 602).
  • these modifications can include: enabling / disabling control links, enabling / disabling entire DXC nodes (3/3 and/or 3/1), enabling / disabling certain DXC ports, enabling / disabling interconnecting equipment, trunks, or sites, changing DXC node i.d., changing all response codes given by a particular DXC, corrupting response code data, clearing alarm conditions, changing message sets (changing vendor model type and/or model revision of a DXC 3/3 or 3/1).
  • These changes can be saved as an update to the configuration data file 31 1 or under a different configuration filename, thereby permitting the user to load a particular configuration at any time. This allows the user to run test scenarios and perform assessments on certain network designs.
  • the sequence number data field indicates an internal emulator count of the DXC nodes being emulated.
  • Highlighting a row indicates a selected DXC Node.
  • row 1 has been highlighted indicating the DXC node having a seq.num. 1 is selected.
  • the Transmit field is ON indicating the DXC node 1 emulates a transmitting DXC node which responds to MCS messages and sends unsolicited messages such as alarms.
  • Moving a cursor to this location and clicking a mouse button enables a user to toggle the Transmit field data to OFF, thereby, simulating a completely off-line DXC node. This is useful to observe the polling behavior of the MCS 104.
  • Link A and Link B each have an up arrow indicating that the primary and secondary network control links 108a, 108b being emulated are both enabled for the DXC node 1.
  • the column header shows what type of information is communicated over each of the four virtual circuits per link in the X.25 protocol: A (Alarm), C (Command/Control), S (Status), and M (Man- Machine Interface).
  • the individual circuits are either logically or physically connected to the MCS (indicated by an "O") or not logically or physically connected (indicated by a "1 " or a vertical bar) depending upon the connection of the Emulator 300 to the MCS 104.
  • Link A and Link B fields also indicate whether the respective simulated network control links for each DXC node are enabled.
  • the Link A and Link B fields are set during pre-programming and updated in response to an outage script or dynamic user-inputs to the Link A (ACSM) and Link B (ACSM) fields. Clicking or double-clicking either of the Link A (ACSM) or Link B (ACSM) fields enables or disables that respective network node control link being emulated.
  • Clicking at a Cmd RC receive field allows the user to set the type of Response Code that will be returned for all MCS messages and commands received for the selected DXC node 1.
  • the response code can be entered by the user or selected from a separate pop-up display window displaying the available Response code choices.
  • the following Response Code Table lists an example of a set of response codes and their descriptions which can be used:
  • the Emulator 300 automatically determines the appropriate response code for a MCS message based on the corresponding message set data. Otherwise, the Emulator 300 returns the users- specified response code message. Additional response codes can be used depending upon the behavior of the DXC nodes being emulated.
  • Changing a Corrupt Response field from "NO” to "YES” allows the user to corrupt data in all response messages sent for the selected DXC node. This allows the Emulator 300 to further test the response of the polling MCS 104 when receiving bad data from a DXC node.
  • the specific messages sent by a DXC node in response to MCS messages vary depending upon the DXC vendor, model, and revision.
  • the Message Set Data field (now shown) identifies a particular response message set for a specific
  • the number of message sets varies depending upon the different types of DXC nodes and revisions being emulated.
  • the message set values for this data field are typically set for each DXC node during pre-programming.
  • a dynamic configuration capability allowing values to be entered by the user or selected from a separate pop-up display window listing the available Message Set value choices can be provided.
  • Dynamic node configuration is also provided for selecting and changing data values found in the DXC Node and DTE data fields. Changing the DXC Node (or Node ID) data field value allows the user to change the node identification number of the selected DXC node in the emulated DXC network
  • the DTE data can be changed to ensure that the DTE address used by the Emulator 300 for a selected DXC node matches that the DTE address on the MCS 104 computer, i.e. a VAX address.
  • Two other configuration data fields 2330, Card and DXC type, are preferably set during pre-programming as they are not often changed during a particular MCS test run.
  • the Card value identifies another specific communications card through which the Communications module 320 sends messages for a selected DXC node.
  • the DXC nodes are divided between the communication cards for load balancing and to improve emulator response.
  • DXC type field identifies the type of DXC node, i.e. DXC 3/3, DXC 3/1, and DXC 1/0 node. Changing the DXC type data field value allows the user to simulate a different DXC node type (i.e. DXC 3/3 and/or DXC 3/1). Of course, it might be necessary to propagate this change in DXC type to other data fields such as the Message Set.
  • a user can select the DXC name data field to enter or change the DXC name.
  • clicking the cursor on the DXC name causes a series of windows to be displayed. These windows allow a user to identify and select adjacent DXC nodes and trunks to emulate the presence and absence of a network failure. See Figures 25 to 26. These displays are described with respect to the creation of an outage script as shown in Figure 24.
  • step 604 the user can create an outage script file 313 that specifies an outage condition. This file can then be run (as specified later in reference to step 606) to emulate the network's response to an outage condition. This same file can also be run, subsequent to an outage emulation and under a normalization option
  • step 608 to normalize the network and clear the alarms that were triggered in response to the outage.
  • step 2422 the user selects a DXC node from the main configuration data 31 1. This can be done by selecting a DXC name data field from a configuration data display 2300 shown in Figure 23A.
  • step 2424 the user is then presented with a display 2500 of all DXC 3/3 and 3/1 nodes that are adjacent to the selected node as shown in Figure 25.
  • the adjacent node data composing screen display 2500 are quickly obtained from the topology data 312, i.e. an ADJACENT.DAT file generated during pre-processing routine 402 as described earlier.
  • the ADJACENT.DAT file can have a hub DXC, Adjacent DXC, and Node ID data fields to correlate hub DXC node data with associated adjacent DXC nodes according to the specific network topology being emulated.
  • step 2426 the user selects an adjacent DXC node as indicated by the highlight 2510.
  • the user is then presented with a display 2600 of all logical trunks (or channels) between two adjacent DXC nodes, as indicated in step 2428.
  • steps 2436 and 2440 the user selects a one, several, or all logical trunks between the two DXC nodes to simulate a network failure along the logical trunks (traffic bearing or non-traffic bearing).
  • a check mark is displayed next to any disabled logical trunk; a square indicates functioning logical trunks. Pressing
  • ALL button 2620 automatically marks all logical trunks between the selected DXC nodes as disabled.
  • an outage script can be created by pressing the save button 2610. The process then proceeds to steps 2442 to 2446 to formulate an outage script file corresponding to the selected disabled trunks between two adjacent DXC nodes.
  • the Emulator processor 354 queries configuration data 311 and/or topology data 312 with the selected disabled trunks to identify all DXC 3/3 and/or DXC 3/1 nodes that the selected trunks traverse. Any pre-processed topology file 312 which correlates trunks and nodes directly connected to the trunks, such as the TRUNKS. DAT for adjacent DXC nodes.
  • a master topology file i.e. MASTER.DAT file, can also be accessed which lists all topology data extracted by inter-DXC trunk number including equipment status (Assigned, Open, Patched, Restoration), DXC Name, site code, equipment name, port (port numbers), and port status relative to a break (i.e. near-side port, far-side port, or break).
  • the Emulator processor 354 identifies all the near-side ports that are used by each DXC node to support the selected trunks. Again, this data is most quickly obtained from Topology data 312, such as a master system file (MASTER.DAT) or a custom DXC node and near-side port file. In this preferred example, only the near-side ports of each supporting DXC 3/3 or DXC 3/1 node will generate an alarm in response to the outage. Assuming that each DXC node has two ports for each logical trunk (one incoming and one outgoing), the near-side port is defined as the port facing the path towards the point of outage.
  • This 'script' is a file that indicates which link in the network has been broken, which
  • DXC ports e.g. the near-side ports facing any selected equipment and/or logical trunk failure
  • an outage script file can be a data file having respectively data fields for DXC name, DXC port, Trunk and Alarm message data.
  • Alarm messages can be provided in human-readable or non-human readable format.
  • Outage Script Creation ends (step 2448) and returns to the User Interface process in Figure 6.
  • This outage script can be selected later during Emulator operation to simulate the corresponding outage condition (Figure 27) or to normalize the emulated DXC network ( Figure 30). Normalization is the process of removing the outage and clearing alarms that were triggered by the outage condition.
  • FIG. 6 shows a user interface for a user through the pull-down Options menu 2305.
  • Each of the steps 606-616 is described in sequence with respect to a corresponding pull-down option 2306-2316.
  • the user can simulate a DXC network failure to test the MCS 104 by selecting an OUTAGE option (step 606, pull-down option 2306).
  • Figure 27 shows the routine triggered by selecting the outage control option.
  • Figure 28 shows an example outage selection display 2800 which lists all available outage scripts (step 2702).
  • Figure 29 shows a selected outage script display 2900.
  • step 2704 the user selects a script, i.e. the highlighted outage script 2810, and runs the script by pressing the Run button 2820.
  • Emulator processor 354 then executes the selected outage script file.
  • the configuration data 311 and/or topology data 312 is updated, where necessary, to identify DXC nodes, ports, trunks, or control links impacted by the outage (step 2705).
  • further Emulator operations in steps 410 and 412 will access topology data 312 and configuration data 311 which has been updated to reflect the outage condition saved in the selected outage script file.
  • the Emulator 300 emulates DXC network behavior to test an MCS 104 during an outage condition as well.
  • Alarm messages contained in the outage script file are generated (step 2706). These alarm messages, can be output to an outage script display 2900 as they are processed (step 2708).
  • the outage script display 2900 shows the following for each alarm: the selected DXC name, port, trunk showing an alarm, and the alarm message data.
  • the alarm messages can be provided in human- readable or non-human readable format. In one human-considerate feature of the present invention, binary alarm message data is converted to ASCII characters (i.e. groups of lower and higher order bits are converted into respective ASCII characters for display). Hundreds or even thousands alarm messages are sometimes associated with an outage. Simulated multi-tasking allows MSC commands to be serviced while alarm message are executed.
  • step 2712 these alarm messages are then sent by the Emulator processor 354 to the MSC 104 for each DXC node near-side port identified in the outage script.
  • the alarm messages are sent unsolicited to the MCS 104 or solicited in the case of an alarm audit.
  • emulator link selector 356 further checks the current configuration data 31 1 for corresponding DXC nodes, i.e. Transmit, LinkA, LinkB, Active 1 , and/or Active 2 data fields (step 2710). In this way, alarm messages representing trunk and/or equipment failure are only sent for transmitting DXC nodes having enabled control links A and/or B (108a, 108b).
  • the Outage script selection 606 routine ends in step 2714 and returns to step 620.
  • step 608 the user can emulate normalization of a DXC network.
  • This routine 608 for normalizing the emulated DXC network, or in other words, clearing the alarms, can be initiated by selecting the CLEAR ALARM option 2308 from the pull-down menu 2305.
  • Figure 30 shows the routine 608 triggered by selecting the outage control option.
  • a Clear Alarms selection display 3100 lists all available outage scripts (step 3002).
  • the user selects a script, i.e. the highlighted outage script 3110, and runs the script by pressing the Run button 3120.
  • Emulator processor 354 then executes the selected outage script file.
  • configuration data 31 1 and/or topology data 312 is updated where necessary to clear alarms and enable any disabled nodes, ports, trunks, and/or control links associated with the outage.
  • further Emulator operations in steps 410 and 412 will access topology data 312 and configuration data 311 which is updated to reflect the normalization of an outage condition imparted from the selected outage script file.
  • clear alarm messages drawn from the outage script file are generated. These clear alarm messages can be output to an outage alarm display 1800 as they are processed (step 3008).
  • the display 3200 shows the following for each cleared alarm: the selected DXC name, port, trunk showing a cleared alarm, and the cleared alarm message data.
  • simulated multi-tasking allows MCS commands to be serviced transparently in a pseudo-parallel fashion during execution of a normalization control option 2308.
  • Clear alarm messages are then sent by the Emulator processor 354 to the MCS 104 for each DXC node near-side port identified in the selected outage script.
  • the alarm message are sent unsolicited to the MCS 104 or solicited in the case of an alarm audit by the MCS (step 3012).
  • emulator link selector 356 Before alarms are sent to the MCS 104, emulator link selector 356 further checks the current configuration data 31 1 for corresponding DXC nodes, i.e. Transmit, LinkA, LinkB, Active 1, and/or Active 2 data fields (step 3010). In this way, clear alarm messages representing trunk and/or equipment normalization are only sent for transmitting DXC nodes having enabled control links A and/or B (108a, 108b).
  • the Clear Alarms selection 608 routine then ends in step 3014 and returns to step 620.
  • FIG. 23 B four other emulator control options can be input: audit (step 610), view communication log (step 612), view trace log (step 614), and view Real-Time message display (step 616).
  • the control options can be input by selecting respective options 2310-2316 in the pull-down menu 2305.
  • the Audit display window 3300 is displayed when the Audit option 2310 is selected (step 610). This display allows the user to see the current set of port parameters that the Emulator 300 is using to simulate each DXC node such as: site code, communication port and cross-connect port numbers, X.25 status, alarm type, and cross-connect configuration status. Broadcast ports and other node port information can be added depending upon a particular network application.
  • the port data composing screen display 3300 is quickly obtained from the topology data 312, i.e. data fields in the AUDIT.DAT file generated during pre-processing routine 402 as described earlier. These data values can be dynamically changed through selections made at the user-interface 315 to more fully stress the MCS 104 with different combinations of data and test case scenarios.
  • One or more of the DXC node ports can be manually-selected to audit alarm generation. Pressing the transmit alarm button 3320 generates alarm messages for all ports marked for sending unsolicited alarms. For example, in Figure 33, during auditing, an alarm type 019 is sent for the selected DXC node port 3310 (DXC 01, Port 3).
  • the View Communication Log display window 3400 is displayed when the View Comm. Log option 2312 is selected (step 612). This display allows the user to see the COMMLOG.DAT file 510 during emulator operation for monitoring emulator and/or MCS performance and trouble-shooting.
  • This communication log contains in temporal sequence all incoming MCS messages and out-going Emulator messages. In the example shown in Figure 34, the following information is kept for each message: time which message was logged,
  • the View Trace Log display window 3500 is displayed when the View Trace Log option 2314 is selected (step 614).
  • This display allows the user to see a trace log, i.e. a TRACELOG.DAT file, during emulator operation for monitoring emulator and/or MCS performance and trouble-shooting.
  • the trace log contains in temporal sequence messages written to the trace log by the Emulator during program execution. The time at which messages are logged is recorded in milliseconds.
  • the View Real Time Message Display window 3600 displays incoming and outgoing messages like the Communication Log except the newly-logged data is scroll-displayed in real-time (step 616). This display allows the user to monitor and trouble-shoot emulator and/or MCS performance in real-time during emulator operation.
  • a display of the main configuration data file 311 is provided.
  • Figures 37A and 37B show an example of a display 3700 of selected contents of a main configuration data file 311 representing a dynamically configured DXC 1/0 network in a preferred embodiment of the present invention.
  • the display
  • 3700 includes a button bar having a pull-down option menu 3705 and a pull ⁇ down help menu 3720.
  • a pull-down option menu 3705 and a pull ⁇ down help menu 3720.
  • Scroll bars 3735, 3736 allow a user to scroll through the displayed data file 311.
  • the user can input and/or modify any of the displayed configuration data in one or more of the data fields 3730.
  • the user can dynamically configure the DXC nodes and their interconnection in the DXC network being emulated (step 602).
  • these modifications can include: enabling / disabling control links, enabling / disabling entire DXC nodes, enabling / disabling certain DXC ports, enabling / disabling interconnecting equipment, trunks, or sites, changing DXC node i.d., changing all response codes given by a particular DXC, corrupting response code data, clearing alarm conditions, changing message sets (changing vendor model type and/or model revision of a DXC 1/0 node).
  • These changes can be saved as an update to the configuration data file 31 1 or under a different configuration filename, thereby permitting the user to load a particular configuration at any time. This allows the user to run test scenarios and perform assessments on certain network designs.
  • standard point-click type of mouse and cursor movements (such as clicking and double-clicking) are used to navigate and dynamically input the above DXC node configuration modifications into the data fields 3730.
  • sequence number data field (Seq. Num.) indicates an internal emulator count of the DXC nodes being emulated. Highlighting a row indicates a selected DXC Node.
  • FIG 37A row 1 has been highlighted indicating the DXC node having a seq. num. I is selected.
  • the Transmit field is ON indicating the DXC node 1 emulates a transmitting DXC node which responds to MCS messages and sends unsolicited messages such as alarms. Moving a cursor to this location and clicking a mouse button enables a user to toggle the Transmit field data to OFF, thereby, simulating a completely off-line DXC node. This is useful to observe the polling behavior of the MCS 104.
  • Link A (ACS 12345678) and Link B (ACS 12345678) data fields each have an up arrow indicating that the primary and secondary network control links 108a, 108b being emulated are both enabled for the DXC node 1.
  • the column header (ACS 12345678) shows what type of information is communicated over each of the eleven virtual circuits (supporting 22 communication sessions per link) in the X.25 protocol: three binary links (A (Alarm), C (Command/Control), and S (Status)) and eight Man-Machine Interface virtual links 1 to 8.
  • the individual circuits are either logically or physically connected to the MCS (indicated by an "O") or not logically or physically connected (indicated by a "1 " or a vertical bar) depending upon the connection of the Emulator 300 to the MCS
  • Link A Clicking or double-clicking either of the Link A (AC SI 2345678) or Link B (ACS 12345678) fields enables or disables that respective network node control link being emulated.
  • Link A and Link B fields also indicate whether the respective simulated network control links for each DXC node are enabled.
  • Clicking at a Cmd RC receive field allows the user to set the type of Response Code that will be returned for all MCS messages and commands received for the selected DXC node 1.
  • the response code can be entered by the user or selected from a separate pop-up display window displaying the available Response code choices.
  • the following Response Code Table lists an example of a set of response codes and their descriptions which can be used:
  • the Emulator 300 automatically determines the appropriate response code for an MCS message based on the corresponding message set data. Otherwise, the Emulator 300 returns the users- specified response code message. Additional response codes can be used depending upon the behavior of the DXC nodes being emulated.
  • Changing a Corrupt Response field from "NO” to "YES” allows the user to corrupt data in all response messages sent for the selected DXC node. This allows the Emulator 300 to further test the response of the polling MCS 104 when receiving bad data from a DXC node.
  • the specific messages sent by a DXC node in response to MCS messages vary depending upon the DXC vendor, model, and revision.
  • the Message Set Data field (now shown) identifies a particular response message set for a specific DXC revision.
  • the number of message sets varies depending upon the different types of DXC nodes and revisions being emulated.
  • the message set values for this data field are typically set for each DXC node during pre-programming.
  • a dynamic configuration capability allowing values to be entered by the user or selected from a separate pop-up display window listing the available Message Set value choices can be provided.
  • Dynamic node configuration is also provided for selecting and changing data values found in the DXC Node and DTE data fields. Changing the DXC Node (or Node ID) data field value allows the user to change the node identification number of the selected DXC node in the emulated DXC network 100.
  • the DTE data can be changed to ensure that the DTE address used by the
  • Emulator 300 for a selected DXC node matches that the DTE address on the MCS 104 computer, i.e. a local or remote VAX address.
  • Two other configuration data fields 3730, Card and DXC type are preferably set during pre-programming as they are not often changed during a particular MCS test run.
  • the Card value identifies another specific communications card through which the Communications module 320 sends messages for a selected DXC node.
  • the DXC nodes are divided between the communication cards for load balancing and to improve emulator response.
  • the DXC type field identifies the type of DXC node, i.e. DXC 3/3, DXC 3/1, and
  • DXC 1/0 node Changing the DXC type data field value allows the user to simulate a different DXC node type (i.e. DXC 1/0). Of course, it might be necessary to propagate this change in DXC type to other data fields such as the Message Set. Finally, a user can select the DXC name data field to enter or change the
  • DXC name In a further preferred example of the present invention, clicking the cursor on the DXC name causes a series of windows to be displayed. These windows allow a user to identify and select adjacent DXC nodes and trunks to emulate the presence and absence of a network failure. See Figures 39 to 40. These displays are described with respect to the creation of an outage script as shown in Figure 38.
  • step 604 the user can create an outage script file 313 that specifies an outage condition. This file can then be run (as specified later in reference to step 606) to emulate the network's response to an outage condition. This same file can also be run, subsequent to an outage emulation and under a normalization option (step 608), to normalize the network and clear the alarms that were triggered in response to the outage.
  • step 3822 the user selects a DXC node from the main configuration data 311. This can be done by selecting a DXC name data field from a configuration data display 3700 shown in Figure 37A.
  • step 3824 the user is then presented with a display 3900 of all DXC 3/3 nodes that are adjacent to the selected node as shown in Figure 39.
  • the adjacent node data composing screen display 3900 are quickly obtained from the topology data 312, i.e. an ADJACENT.DAT file generated during pre-processing routine 402 as described earlier.
  • the ADJACENT.DAT file can have a hub DXC, Adjacent DXC, and Node ID data fields to correlate hub DXC node data with associated adjacent DXC nodes according to the specific network topology being emulated.
  • step 3826 the user selects an adjacent DXC node as indicated by the highlight 3910.
  • the user is then presented with a display 4000 of all logical trunks (or channels) between two adjacent DXC nodes, as indicated in step 3828.
  • steps 3836 and 3840 the user selects a one, several, or all logical trunks between the two DXC nodes to simulate a network failure along the logical trunks (traffic bearing or non-traffic bearing).
  • a check mark is displayed next to any disabled logical trunk; a square indicates functioning logical trunks. Pressing ALL button 4020 automatically marks all logical trunks between the selected
  • an outage script can be created by pressing the save button 4010. The process then proceeds to steps 3842 to 3846 to formulate an outage script file corresponding to the selected disabled trunks between two adjacent DXC nodes.
  • the Emulator processor 354 queries configuration data 31 1 and/or topology data 312 with the selected disabled trunks to identify all DXC 1/0 nodes that the selected trunks traverse. Any pre-processed topology file 312 can be accessed which correlates trunks and nodes directly connected to the trunks, such as the TRUNKS.DAT for adjacent DXC nodes.
  • a master topology file i.e.
  • MASTER.DAT file can also be accessed which lists all available topology data extracted by inter-DXC trunk number including equipment status (Assigned, Open, Patched, Restoration), DXC Name, site code, equipment name, port (port numbers), and port status relative to a break (i.e. near-side port, far-side port, or break).
  • equipment status Assigned, Open, Patched, Restoration
  • DXC Name site code
  • equipment name equipment name
  • port port numbers
  • port status relative to a break i.e. near-side port, far-side port, or break.
  • the Emulator processor 354 identifies all the near-side ports that are used by each DXC node to support the selected trunks. Again, this data is most quickly obtained from Topology data 312, such as a master system file (MASTER.DAT) or a custom DXC node and near-side port file. In this preferred example, only the near-side ports of each supporting DXC 1/0 node will generate an alarm in response to the outage. Assuming that each DXC node has two ports for each logical trunk (one incoming and one outgoing), the near-side port is defined as the port facing the path towards the point of outage.
  • Topology data 312 such as a master system file (MASTER.DAT) or a custom DXC node and near-side port file.
  • MASTER.DAT master system file
  • the near-side port is defined as the port facing the path towards the point of outage.
  • an outage script file can be a data file having respectively data fields for DXC name, DXC port, Trunk and Alarm message data.
  • Alarm messages can be provided in human-readable or non-human readable format.
  • This outage script can be selected later during Emulator operation to simulate the corresponding outage condition ( Figure 41 ) or to normalize the emulated DXC network ( Figure 44). Normalization is the process of removing the outage and clearing alarms that were triggered by the outage condition.
  • step 606-616 can be input by a user through the pull-down Options menu 3705.
  • Each of the steps 606-616 is described in sequence with respect to a corresponding pull-down option 3706-3716.
  • the user can simulate a DXC network failure to test the MCS 104 by selecting an OUTAGE option (step 606, pull-down option 3706).
  • Figure 41 shows the routine triggered by selecting the outage control option.
  • Figure 42 shows an example outage selection display 4200 which lists all available outage scripts (step 4102).
  • Figure 43 shows a selected outage script display 4300.
  • the user selects a script, i.e.
  • Emulator processor 354 then executes the selected outage script file.
  • the configuration data 311 and/or topology data 312 is updated, where necessary, to identify DXC nodes, ports, trunks, or control links impacted by the outage (step 4105).
  • further Emulator operations in steps 410 and 412 will access topology data 312 and configuration data 311 which has been updated to reflect the outage condition saved in the selected outage script file.
  • the Emulator 300 emulates DXC network behavior to test an MCS 104 during an outage condition as well. Alarm messages contained in the outage script file are generated (step 4105).
  • alarm messages can be output to an outage script display 4300 as they are processed (step 4108).
  • the outage script display 4300 shows the following for each alarm: the selected DXC name, port, trunk showing an alarm, and the alarm message data.
  • the alarm messages can be provided in human- readable or non-human readable format. In one human-considerate feature of the present invention, binary alarm message data is converted to ASCII characters (i.e. groups of lower and higher order bits are converted into respective ASCII characters for display). Hundreds or even thousands alarm messages are sometimes associated with an outage. Simulated multi-tasking allows MSC commands to be serviced while alarm message are executed.
  • step 41 12 these alarm messages are then sent by the Emulator processor 354 to the MSC 104 for each DXC node near-side port identified in the outage script.
  • the alarm messages are sent unsolicited to the MCS 104 or solicited in the case of an alarm audit.
  • emulator link selector 356 further checks the current configuration data 31 1 for corresponding DXC nodes, i.e. Transmit, LinkA, LinkB, Active 1, and/or Active 2 data fields (step 4110). In this way, alarm messages representing trunk and/or equipment failure are only sent for transmitting DXC nodes having enabled control links A and/or B (108a, 108b).
  • the Outage script selection 606 routine ends in step 4114 and returns to step 620.
  • step 608 the user can emulate normalization of a DXC network.
  • This routine 608 for normalizing the emulated DXC network, or in other words, clearing the alarms, can be initiated by selecting the CLEAR ALARM option 3708 from the pull-down menu 3705.
  • Figure 44 shows the routine 608 triggered by selecting the outage control option.
  • a Clear Alarms selection display 4500 lists all available outage scripts (step 4402).
  • the user selects a script, i.e. the highlighted outage script 4510, and runs the script by pressing the Run button 4520.
  • Emulator processor 354 then executes the selected outage script file.
  • configuration data 311 and/or topology data 312 is updated where necessary to clear alarms and enable any disabled nodes, ports, trunks, and/or control links associated with the outage.
  • further Emulator operations in steps 410 and 412 will access topology data 312 and configuration data 31 1 which is updated to reflect the normalization of an outage condition imparted from the selected outage script file.
  • step 4406 clear alarm messages drawn from the outage script file are generated. These clear alarm messages can be output to an outage alarm display 1800 as they are processed (step 4408).
  • the display 4600 shows the following for each cleared alarm: the selected DXC name, port, trunk showing a cleared alarm, and the cleared alarm message data.
  • simulated multi-tasking allows MCS commands to be serviced transparently in a pseudo-parallel fashion during execution of a normalization control option 3708.
  • Clear alarm messages are then sent by the Emulator processor 354 to the MCS 104 for each DXC node near-side port identified in the selected outage script.
  • the alarm message are sent unsolicited to the MCS 104 or solicited in the case of an alarm audit by the MCS (step 4412).
  • emulator link selector 356 further checks the current configuration data 311 for corresponding DXC nodes, i.e. Transmit, LinkA, LinkB, Active 1, and/or Active 2 data fields (step 4410). In this way, clear alarm messages representing trunk and/or equipment normalization are only sent for transmitting DXC nodes having enabled control links A and/or B (108a, 108b).
  • the Clear Alarms selection 608 routine then ends in step 1414 and returns to step 620.
  • step 610 four other emulator control options can be input: audit (step 610), view communication log (step 612), view trace log (step 614), and view Real-Time message display (step 616).
  • the control options can be input by selecting respective options 3710-3716 in the pull-down menu 3705.
  • the Audit display window 4700 is displayed when the Audit option 3710 is selected (step 610). This display allows the user to see the current set of port parameters that the Emulator 300 is using to simulate each DXC node (identified by a site code, i.e.
  • the port provision data is further described below with respect to Figure 47B.
  • the port data composing screen display 4700 is quickly obtained from the topology data 312, i.e. data fields in the AUDIT.DAT file generated during pre ⁇ processing routine 402 as described earlier. These data values can be dynamically changed through selections made at the user-interface 315 to more fully stress the MCS 104 with different combinations of data and test case scenarios.
  • one or more of the DXC node ports can be manually-selected to audit alarm generation.
  • a Send data field can be added to track selected ports. Pressing a transmit alarm button (not shown) then generates alarm messages for all ports marked for sending unsolicited alarms.
  • Broadcast ports and other node port information can be also added depending upon a particular network application.
  • each DXC port can support respective one or more channels.
  • each cross-connect port can support its own corresponding one or more channels.
  • the Emulator 300 updates topology data 312, i.e. AUDIT.DAT file, to emulate different arrangements of provisioned channels in the ports for testing MCS response.
  • Figure 47B further shows an example of the Audit Database
  • CrossConnected Channels display screen 4750 The display screen 4750 pops up when either the Start Channel Number or Total Channel Number field is clicked (4710) for a selected port (0003) and cross-connect port (0044). This screen 4750 shows how the communication and cross-connect ports (0003, 0044) are provisioned and which channels out of a total of 24 channels (1-24) are cross- connected.
  • Channels 1 to 2 and 11 to 19 are marked XX to signify that these channels have not been provisioned, i.e. not equipped for links, and thus are unavailable for any port cross-connection.
  • Channels 3 to 10 of port 0033 are cross-connected with channel numbers 14 to
  • ports 21 of port 0044 respectively. This reflects the information in row 1710 identifying a start channel number of 3 and a total of eight provisioned channels.
  • channels 20 to 24 of port 0003 cross-connect to channels 3 to 7 respectively of port 0044 (see row 4712).
  • all of the 24 channels of port 0003 are either not provisioned (marked XX) or are provisioned and cross-connected to port 0044 channels.
  • a port can have channels crossed to one or more other cross-connect ports. For example, channels 10 to 12 of port 044 as indicated by an underscore are physically provisioned, but are cross-connected to a port other than port 0003.
  • the View Communication Log display window 4800 is displayed when the View Comm. Log option 3712 is selected (step 612). This display allows the user to see the COMMLOG.DAT file 510 during emulator operation for monitoring emulator and/or MCS performance and trouble-shooting.
  • This communication log contains in temporal sequence all incoming MCS messages and out-going Emulator messages. In the example shown in Figure 48, the following information is kept for each message: time which message was logged, DXC name, Port (port number on which the message was sent or received), Ckt (type of message sent i.e. unknown, alarm, control/command, audit, MMI), C/R (C represents incoming MCS command; R represents outgoing response), and the actual message.
  • the View Trace Log display window 4900 is displayed when the View Trace Log option 714 is selected (step 614).
  • This display allows the user to see a trace log, i.e. a TRACELOG.DAT file, during emulator operation for monitoring emulator and/or MCS performance and trouble-shooting.
  • the trace log contains in temporal sequence messages written to the trace log by the
  • Emulator during program execution The time at which messages are logged is recorded in milliseconds.
  • the View Real Time Message Display window 5000 displays incoming and outgoing messages like the Communication Log except the newly-logged data is scroll-displayed in real-time (step 616). This display allows the user to monitor and trouble-shoot emulator and/or MCS performance in real-time during emulator operation.
  • DXC Network Type DXC Network Type
  • DXC 3/3 different types of digital cross-connect networks are emulated including DXC 3/3, DXC 3/3 and 3/1, and/or DXC 1/0 networks.
  • a DXC 3/3 network was primarily described with respect to Figures 7 A to 22. If different types of nodes are being emulated in a hybrid DXC network, the DXC node type field, DXC Type, included in the configuration data file 311 and topology data files 312 identifies more than one node type. If DXC 3/1 or DXC 1/0 nodes are emulated, the MCS 104 is also more likely to be involved in dynamic configuration to establish and breakdown private lines.
  • the MCS 104 is also more likely to be involved in restoration. More rigid topologies, as in a DXC 3/3 network can, be emulated to further test MCS restoration. Intermediate site and equipment carrying the logical trunks between DXC nodes can be stored and updated in the Emulator topology data 312.
  • a flexible DXC 3/3 and 3/1 network was primarily described with respect to Figures 23 A to 36.
  • the Emulator topology data 312 traces logical trunks through adjacent DXC 3/3 and/or 3/1 nodes. Partial or total trunks outages are emulated. Even without complete path topology data, dynamic trunk connections are emulated in response to user and/or MCS commands.
  • a DXC 1/0 network with dynamically configured paths established through channel level commands and port provisioning was primarily described with respect to Figures 37A to 50.
  • the Emulator topology data 312 traces logical trunks through adjacent DXC 1/0 nodes and provisions cross-connected port channels. Partial or total trunks outages are emulated. Even without complete path topology data, dynamic inter-DXC trunk (i.e. channel) connections are emulated in response to user and/or MCS commands. Simulated Multi-Tasking
  • Figure 51 shows a functional block diagram of an example personal computer system architecture 5100 for servicing multiple external interfaces 5170, 5180 according to the present invention.
  • Figure 52 shows a simulated multi-tasking routine 5200 as used in the present invention.
  • Figure 53 shows examples of program modules for servicing respective external interface units.
  • Figure 54 shows a specific example illustrating the operation of the present invention.
  • a CPU 5110 is responsible for executing application 5105 and servicing multiple external interfaces including a user- interface 5170 and a data communication interface 5180.
  • a user-interface servicer 5120 services the user-interface 5170.
  • a simulated multi-task controller 5140 switches control between the user-interface servicer 5120 and communication link servicer 5130 in a pseudo-parallel fashion to simulate multi ⁇ tasking.
  • the user-interface 5170 example includes a mouse 5172, keyboard 5174, printer 5176, and a video display 5178.
  • the communication interface 5180 includes an in-bound communication link 5182 and an out-bound communication link 5184.
  • any external interface unit and multiple instances thereof can be used, including any peripheral input device (such as a joystick, tablet, stylus, light pen, and touch screen), I/O device, and/or network link can be used to provide communication between the CPU 5110 and any external user.
  • the in-bound and out-bound communication links 5182, 5184 can be configured as one or more physical and/or logical links for uni -directional and/or bi-directional data flow.
  • a user-interface module 5150 is coupled between the CPU 51 10 and the user-interface 5170.
  • a communication module 5160 is coupled between the CPU
  • the user-interface module 5150 manages data communication between the peripheral external interface units 5172-5178 and the CPU 5110.
  • the communication module 5130 manages data communication between the communication link(s) 5182, 5184 and the CPU 51 10 including providing a standard data communication protocol (i.e.
  • CPU Interface buffers are provided for storing and queuing user-inputs sent to the CPU 5110.
  • a mouse input buffer 5152 holds peripheral inputs from the mouse 5172. These mouse inputs can include mouse button information (click/double-click of a left, center, and right mouse button), movement information (drag, drag distance and/or speed), or any other type of mouse action.
  • a keyboard input buffer 5154 holds peripheral inputs received from the keyboard 5174. These keyboard inputs can include characters, keystrokes, combinations of keystrokes, or any other type of keyboard action.
  • a communication input buffer 5162 holds in-bound communication message(s) received over the communication link 5182.
  • CPU Interface Buffers 5155, 5157 can also be provided for the printer 5176 and Video Display 5178.
  • Application Interface buffers are provided for storing and queuing messages generated by the CPU 5110 during execution of the application 5105 to be sent to the external interfaces 5170, 5180.
  • a printer output buffer 5156 queues print data to be sent to printer 5176.
  • a video display output buffer 5158 queues display data to be sent to the video display 5178.
  • Application buffers 5151 , 5153 for the mouse and keyboard can also be included. Any of the above CPU interface buffers and the Application interface buffers can be arranged in a CPU cache memory, main memory, hard disk or any other type of media storage device.
  • User-interface servicer 5120 and communication link servicer 5130 access respective program modules (5122-5128 and 5132-5134) for servicing each of the external interface units (5172-5178 and 5182-5184) under the control of the simulated multi-task controller 5140.
  • a mouse module 5122 services the mouse 5172.
  • a keyboard module 5124 services the keyboard 5174.
  • a printer module
  • a video display module 5128 services the video display 5178.
  • Communication input module 5132 and communication output module 5134 service the in-bound and out-bound communication links 5182 and 5184 respectively.
  • User-interface servicer 5120, communication link servicer 5130, simulated multi-task controller 5140, and their constituent program modules (5122-5128 and 5132-5134) can be implemented through software, firmware, hardware, or any combination thereof.
  • the simulated multi-task controller 5140 switches control between the user-interface servicer 5120 and communication link servicer 5130 according to a simulated multi-tasking routine.
  • Figure 52 shows a general simulated multi-tasking routine 5200 according to the present invention. Though described with respect to program modules for servicing external interfaces, this simulated multi-tasking routine 5200 applies broadly to simulating multi-tasking between any two computer-implemented tasks.
  • a specific program implementation of the simulated multi-tasking routine is further shown in Figures 53 A and 53B for use in computer system 5100 of Figure 51.
  • Figure 54 shows an example of the operation of simulated multi ⁇ tasking in response to specific user-inputs, namely, the entering of a keyboard PRINT command.
  • control switch calls are inserted after selected partial logical units of work (PLUWs) in one or more external interface program modules which serve respective first and second external interface units.
  • PLUWs partial logical units of work
  • control switch calls are inserted in program modules which take a relatively long-time to process. For example, program modules which wait for a user-input or process a large amount of data can take longer than other program modules involving relatively quick data manipulation and/or instruction processing by a CPU.
  • These control switch calls further tell the simulated multi-task controller 5140 to switch control to service any other external interface unit having a relatively short CLUW time.
  • Overall application processing time is optimized as the second external interface, such as user-interface 5170, communication interface 5180 or any other type of computer interface, is serviced quicker and available sooner for further processing.
  • Step 5210 is usually performed as part of a pre-processing routine. Steps 5220-5250 are then carried out during execution of the application 5105 to simulate multi-tasking. In this way, multiple external interfaces are serviced in a pseudo-parallel fashion nearly simultaneously with sub-second response. As used herein, sub-second response includes millisecond and even nanosecond CPU response times to the external interface units.
  • the simulated multi-task controller 5140 checks a first external interface to determine whether servicing of any first external interface unit is needed. Servicing is needed if data is present in any corresponding buffer for the first interface units, i.e. a CPU Interface input buffer or an application output buffer. A buffer can be checked directly for data. Alternatively, any other indicator such as a flag or semaphore can be checked to determine whether servicing is needed.
  • the simulated multi-task controller 5140 executes a first program module corresponding to the particular external interface unit having data in its application or CPU interface buffer. One or more PLUWs of the first program module are executed until a switch control call is read (step 5223) or until the first program module is completed (step 5227). When a switch control call to the second interface is read, the simulated multi- task controller checks to see if the second interface needs servicing (step 5224).
  • servicing is needed if data is found in a corresponding buffer for tiie second external interface units.
  • the simulated multi-task controller temporarily halts the execution of the first program module, and switches control to service the second external interface (step 5225).
  • One or more PLUWs of the second program module are then executed (step 226).
  • a CLUW is completed when the second interface unit can be serviced in a much quicker duration than a CLUW for the first external interface unit serviced at step 5222.
  • the simulated multi-task controller then returns control back to servicing the first external interface (step 5222).
  • One or more further PLUWs are executed in the first program module until another switch control call is read (step 5223) or the first program module to completed (step 5227).
  • the placement of the switch control calls after one or more PLUWs in each of the first and second program modules is predetermined to optimize the overall execution time of the first and second program modules in servicing first and second external interfaces. Both of the first and second external interfaces are serviced quickly and efficiently in a manner simulating multi-tasking but without the overhead incumbent in multi ⁇ tasking operating systems.
  • the simulated multi-tasking controller 5140 proceeds to similarly check a second interface to determine whether any second interface unit needs servicing (step 5230). As in step 5225, servicing is needed when data is found in a corresponding buffer for the second external interface units. If the second external interface does need servicing, it is serviced quickly by executing one or more PLUW(s) (for longer tasks) or a CLUW (for shorter tasks) (steps 5232 and 5234). Idle CPU time is reduced as the task required to service the second interface can be completed rapidly without waiting for the first external interface to be fully serviced.
  • step 5230 After the second external interface has been checked (step 5230) and serviced if necessary (step 5234), a decision is made at step 5240 on whether to continue operation by returning to step 5220 or ending the operation (step 5250).
  • Figures 53A and 53B the functionality of a simulated multi-tasking routine 5300 is pre-programmed into an application program 5305, program modules for checking the external interfaces (5310, 5312, 5316, 5320, 5324, 5330, 5332, and 5336), and program modules for servicing the external interfaces when necessary (5314, 5318, 5322, 5326, 5334, and 5338).
  • Figure 53 A shows two program modules 5310 and 5320 for servicing a first external interface (user- interface 5170) and a second external interface (communications interface 5180).
  • the program module 5310 is programmed to check and service each user-interface peripheral unit, if necessary (steps 5312 to
  • the program module 5320 is programmed to check and service each communication interface peripheral unit (steps 5332-5338).
  • the simulated, multi-tasking routine 5300 either returns to step 5310 or ends simulated multi-tasking processing at step 5350.
  • one or more partial logical units of work are identified for each complete logical unit of work CLUW in the program modules (5314, 5318, 5322, 5326, 5334, and 5338).
  • PLUWs partial logical units of work
  • moving twenty lines of display data or less to the video CPU Interface buffer 5157 constitutes a selected PLUW in the video display module 5314.
  • Moving a block of twenty lines to the printer CPU Interface buffer 5155 is a selected PLUW for the print module 5326.
  • Each of these PLUWs can be made longer or shorter as needed depending on the specific external interface unit operation and the perceptions of corresponding external users.
  • the tasks of the mouse module 5322, communication in module 5334, and communication out module 5338 can be completed relatively quickly by a CPU 5110. Therefore, the entire CLUW is performed by the respective user- interface service 5120 and communication link servicer 5130 without interruption.
  • Control switch calls are inserted after a selected partial logical unit(s) of work (PLUW) in the video display program module 5314, keyboard program module 5318, and print module 5326. These control switch calls switch control to service communication module 5334, if necessary.
  • Figure 54 shows an example of a simulated multi-tasking process 5400 carried out in response to specific external user-inputs, namely a PRINT command entered through a keyboard.
  • the user input can be the click of a mouse, a word spoken into a voice recognition device, or any other type of user-input.
  • the pre-programmed application program 5305 is being executed in CPU 5110 as the user types on the keyboard 5174.
  • the communication interface 5180 may have already been checked and serviced many times by executing communication program modules (5330-5338).
  • step 5410 the simulated multi-task controller 5140 switches control to user-interface servicer 5120 which begins to execute the user-interface check modules (5310-5326).
  • the video application output buffer 5158 is checked for data (video display program check 5312). No data is found, so the video display program module 5314 for displaying video data is not executed.
  • step 5412a the keyboard 5174 is checked (keyboard program check
  • keyboard routine 5326 executes keyboard routine 5326 and performs the first PLUW to move the character "P" from the keyboard CPU interface buffer 5154 to the keyboard application buffer 5153.
  • step 5414a the communication link servicer 5140 executes the communication-in program module 5334.
  • the communications module in step 5414a executes very quickly, perhaps in a matter of a few milliseconds. Keyboard entry from a human is much slower, and it may take several seconds to complete an entire command, such as a "PRINT" command.
  • the call to the communications module 5414a...5414g is programmed into the source code to execute after each single character of user input from the keyboard (PLUW).
  • PLUW the first character of the command
  • the communication link servicer 5130 does not wait for a response before proceeding to the next task. Therefore, in step 5414a, when the Communications program module 5334 has cycled once, a user-interface check (not shown) can be made to determine whether the next user input, i.e. the next keyboard character has been entered. When another user-input is not yet present in a appropriate buffer, the communication module 5334 is repeated. In this way, the external communication interface units continue to be serviced by the Communications module 5334 without waiting for the next user input. Indeed, the simulated multi-tasking controller 5140 in executing program 5305 spends only a minimum amount of time checking buffers for user inputs; this time is short enough to not be perceived by the external communication interface 5180 as an interruption in processing.
  • step 5414a when the communications module 5334 is completed and a second keyboard character "R" is detected, the simulated multi-tasking controller 5140 returns control to the user-interface 5120 to accept user input(s)
  • step 5412b the user-interface servicer 5120 then executes keyboard routine 5326 and performs the first PLUW to move the character "R" from the keyboard CPU interface buffer 5154 to the keyboard application buffer 5153.
  • keyboard routine 5326 the user-interface servicer 5120 executes keyboard routine 5326 and performs the first PLUW to move the character "R" from the keyboard CPU interface buffer 5154 to the keyboard application buffer 5153.
  • step 5414b the communication link servicer 5140 executes the communication program module 5334.
  • the simulated multi-task controller 5140 then switches control between the user-interface servicer 5120 and the communication interface servicer 5130 to carry out steps 5412c-5412e and steps 5414b-5414d as described above with respect to steps 5412a and 5414a.
  • both the user-interface 5170 and the communication interface 5180 (which can include hundreds of devices and communication sessions) are serviced under the control of the simulated multi-task controller 5140 in a pseudo-parallel manner that optimizes the overall application execution time and gives the perception to all external users that each external interface 5170, 5180 is being serviced in parallel without interruption.
  • step 5412e the program 5305 then calls printer module 5126, which begins printing a selected PLUW, i.e. a first print block of twenty lines (step 5416a).
  • printer module 5126 begins printing a selected PLUW, i.e. a first print block of twenty lines (step 5416a).
  • the simulated multi-task controller 5140 switches control to service the communications interface 5180 by executing the communication-in program module 5334 if necessary (step 5414e). After the communication module 5334 has executed, the simulated multi-tasking controller 5140 switches control back to the user-interface servicer 5120 to continue printing second print block 2 (step 5416b). Control continues to be swapped between the external interface units in steps 5414f, 5416c, and 5414g.
  • step 5414g the program 5305 returns to where it was when it first checked for user input (step 5410). Alternatively, the program 5305 can return to service external user inputs and/or application outputs at the communication interface 5180. The program 5305 proceeds to step 5420, where any of a variety of tests may be executed to determine whether to continue or end processing (step 5430).
  • the first program module When a call from one program module to another program module is made, the first program module must leave itself in a known state. At a minimum, this state must be at the completion of a PLUW, as a PLUW is the most elementary process that is performed by the CPU. Data indicating this state may be kept in a set of local or global parameters. If no other module needs to know what state that module is in, then that module records its state in a set of local parameters (readable only by that module). If one or more other modules require knowledge of that module's state, then that module records its state in a set of global parameters (readable by entire program).
  • step 5416a the user-interface servicer 5120 executes the print module 5126 which prints the first block of the report by executing one or more PLUWs.
  • the user-interface servicer 5120 executes the print module 5126 records its present state in a set of local parameters, i.e. an instruction pointer.
  • step 5416b When control returns in step 5416b to the user-interface servicer 5120 to continue executing the print module 5126, the present state of the print module 5126 is known and can resume printing at print block 2.
  • the present invention provides simulated multi-tasking that su ⁇ asses the performance of true multi-tasking for many applications. It is well- suited for applications that must emulate the continual operation of physical devices, in that it allows multiple CPU-intensive functions to be executed transparently without being noticed by users and peripheral systems.
  • the content and number of PLUWs that are to be executed in one program module before performing a transfer to another module is determined by the programmer based on the amount of time required to execute each PLUW and the amount of time that the program can afford to give to one task and still maintain the perception of multi-tasking to the external users.
  • the programmer can tune application processing to address certain tasks at certain times, and thereby control the multi-tasking features of the program.
  • the programmer can ensure that no unnecessary delays are introduced into processing in the form of waiting for a particular response.
  • the program can check for an input or response, and if none are found, proceed without waiting to the next PLUW of another task. This eliminates unnecessary delays and enhances the perception of transparent multi-tasking.
  • a further advantage over a true multi-tasking environment, and in particular over a pre-emptive multi-tasking operating system, is that time- consuming disk swapping is not required. Recording the state of a program module after a PLUW has been executed in simpler than storing context data (i.e. an instruction pointer and intermediate operational data) as done in conventional pre-emptive interrupt-based multi-tasking schemes.
  • context data i.e. an instruction pointer and intermediate operational data
  • Process "A”, i.e. a computer program segment, is to perform the computation on the complex Equation "A"
  • Process "B” is to perform the computation on the simple Equation "B”.
  • Control switches between servicing process A and process B until process B is complete steps 1 to 4).
  • the results of Process B are then presented at the end of 8 seconds (step 4).
  • Process A continues to be serviced in steps 5 to 7.
  • the results of Process A are presented at the end of 20 seconds (step 7).
  • Equation A which was submitted first and took a total of 16 seconds to compute (steps 1, 3, 5, 6, 7), would be presented at the end of 16 seconds.
  • Equation B which was submitted second and took a total of 4 seconds to compute (steps 2 and 4), would be presented at the end of 20 seconds, since it would have to wait for the completion of Equation A.
  • the requester of Equation B can process the results and prepare for subsequent action while the results of Equation A are being computed. In this way, the overall application execution time for performing and presenting the results from both processes A and B is optimized.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procédé et dispositif pour émuler un réseau de sous-répartition numérique (DXC) pour tester intégralement le système de surveillance et de gestion d'un réseau de télécommunication (MSC) (208). La communication et le comportement d'un réseau de sous-répartition numérique sont émulés en présence ou en l'absence de configurations sélectionnées (noeuds et/ou jonction), de défaillances et/ou de normalisations (210) liées au réseau. Les données relatives à la configuration représentent le comportement actuel des noeuds DXC (311). Les données topologiques représentent la topologie du réseau émulé (312). Les données topologiques peuvent être mises à jour en réponse à des commandes formulées au niveau des voies MCS (p. ex. les commandes extension/réduction (grow/de-grow), connexion/déconnexion (connect/disconnect) et interconnexion (cross-connect) ) pour former des itinéraires entre les ports prévus dans le réseau DXC émulé. Des options pour simuler un fonctionnement multitâche et pour effectuer un contrôle dynamique d'une interface usager sont également proposés (353). Un procédé et un dispositif informatiques desservent des interfaces externes multiples de manière pseudo-parallèle, simulant le fonctionnememt multitâche (350).
PCT/US1997/007799 1996-05-01 1997-05-01 Procede et dispositif pour emuler un reseau de sous-repartition numerique WO1997041657A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU30615/97A AU3061597A (en) 1996-05-01 1997-05-01 Method and apparatus for emulating a digital cross-connect switch network

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US08/641,458 US5809286A (en) 1996-05-01 1996-05-01 Method and apparatus for emulating a dynamically configured digital cross-connect switch network
US08/641,461 US5867689A (en) 1996-05-01 1996-05-01 Method and apparatus for emulating a digital cross-connect switch network using a flexible topology to test MCS network management
US08/641,460 1996-05-01
US08/641,459 1996-05-01
US08/641,460 US5850536A (en) 1996-05-01 1996-05-01 Method and system for simulated multi-tasking
US08/641,461 1996-05-01
US08/641,459 US5748617A (en) 1996-05-01 1996-05-01 Method and apparatus for emulating a digital cross-connect switch network
US08/641,458 1996-05-01

Publications (1)

Publication Number Publication Date
WO1997041657A1 true WO1997041657A1 (fr) 1997-11-06

Family

ID=27505237

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1997/007799 WO1997041657A1 (fr) 1996-05-01 1997-05-01 Procede et dispositif pour emuler un reseau de sous-repartition numerique

Country Status (2)

Country Link
AU (1) AU3061597A (fr)
WO (1) WO1997041657A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999033208A1 (fr) * 1997-12-19 1999-07-01 Alcatel Usa Sourcing, L.P. Systeme et procede de gestion centrale de fonctions de commutation
EP0948219A2 (fr) * 1998-04-02 1999-10-06 Lucent Technologies Inc. Méthode pour créer et modifier des bases de données similaires et dissimilaires
CN109891424A (zh) * 2017-01-30 2019-06-14 谷歌有限责任公司 在不披露特定识别信息的情况下建立标识符之间的链接
WO2022167719A1 (fr) * 2021-02-04 2022-08-11 Elisa Oyj Test de système de commande de réseau

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5226041A (en) * 1991-02-21 1993-07-06 International Business Machines Corporation Method for efficiently simulating the dynamic behavior of a data communications network
US5396616A (en) * 1993-06-15 1995-03-07 Xerox Corporation System for emulating multi-tasking pipelines in a single tasking environment
US5410586A (en) * 1992-04-10 1995-04-25 Mci Communications Corporation Method for analyzing an IDNX network
US5557795A (en) * 1993-06-15 1996-09-17 Xerox Corporation Pipelined image processing system for a single application environment
US5600632A (en) * 1995-03-22 1997-02-04 Bell Atlantic Network Services, Inc. Methods and apparatus for performance monitoring using synchronized network analyzers

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5226041A (en) * 1991-02-21 1993-07-06 International Business Machines Corporation Method for efficiently simulating the dynamic behavior of a data communications network
US5410586A (en) * 1992-04-10 1995-04-25 Mci Communications Corporation Method for analyzing an IDNX network
US5396616A (en) * 1993-06-15 1995-03-07 Xerox Corporation System for emulating multi-tasking pipelines in a single tasking environment
US5557795A (en) * 1993-06-15 1996-09-17 Xerox Corporation Pipelined image processing system for a single application environment
US5600632A (en) * 1995-03-22 1997-02-04 Bell Atlantic Network Services, Inc. Methods and apparatus for performance monitoring using synchronized network analyzers

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999033208A1 (fr) * 1997-12-19 1999-07-01 Alcatel Usa Sourcing, L.P. Systeme et procede de gestion centrale de fonctions de commutation
US6128321A (en) * 1997-12-19 2000-10-03 Alcatel Usa Sourcing, L.P. System and method for centrally-managing switching functions
EP0948219A2 (fr) * 1998-04-02 1999-10-06 Lucent Technologies Inc. Méthode pour créer et modifier des bases de données similaires et dissimilaires
EP0948219A3 (fr) * 1998-04-02 2000-09-06 Lucent Technologies Inc. Méthode pour créer et modifier des bases de données similaires et dissimilaires
CN109891424A (zh) * 2017-01-30 2019-06-14 谷歌有限责任公司 在不披露特定识别信息的情况下建立标识符之间的链接
CN109891424B (zh) * 2017-01-30 2023-07-18 谷歌有限责任公司 在不披露特定识别信息的情况下建立标识符之间的链接
WO2022167719A1 (fr) * 2021-02-04 2022-08-11 Elisa Oyj Test de système de commande de réseau

Also Published As

Publication number Publication date
AU3061597A (en) 1997-11-19

Similar Documents

Publication Publication Date Title
US5809286A (en) Method and apparatus for emulating a dynamically configured digital cross-connect switch network
US5748617A (en) Method and apparatus for emulating a digital cross-connect switch network
US5867689A (en) Method and apparatus for emulating a digital cross-connect switch network using a flexible topology to test MCS network management
US5276679A (en) Method for maintaining channels and a subscriber station for use in an ISDN system
US6266695B1 (en) Telecommunications switch management system
US6714217B2 (en) System and method for providing a graphical user interface to, for building, and/or for monitoring a telecommunication network
US6295518B1 (en) System and method for emulating telecommunications network devices
US6181679B1 (en) Management of packet transmission networks
US5889954A (en) Network manager providing advanced interconnection capability
US6247052B1 (en) Graphic user interface system for a telecommunications switch management system
EP0724804B1 (fr) AUTOCOMMUTATEUR à PROTOCOLES RESEAU ET SERVICES DE COMMUNICATIONS PROGRAMMABLES
US6192361B1 (en) Full group privileges access system providing user access security protection for a telecommunications switching system
JPH07107114A (ja) 遠隔オフィスネットワーク用システムとその通信方法
EP0377395A2 (fr) Equilibrage de charge d'un serveur
US5848244A (en) System and method for time-based real-time reconfiguration of a network
CN106685733A (zh) 一种fc‑ae‑1553网络快速配置与自动化测试方法
CA2221579A1 (fr) Controle d'un reseau de communication
US6434611B1 (en) System and method for message-based real-time reconfiguration of a network by broadcasting an activation signal to activate a new connection configuration
US20080159506A1 (en) Network element provisioning and event simulation in a communications network
EP0358408A2 (fr) Réseau intelligent
CA2221765A1 (fr) Controle d'un reseau de communication
WO1997041657A1 (fr) Procede et dispositif pour emuler un reseau de sous-repartition numerique
JP2000048026A (ja) デ―タベ―ス内でデ―タを検索する方法
CA2221527A1 (fr) Controle d'un reseau de communication
Kheradpir et al. Real-time management of telephone operating company networks: Issues and approaches

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA JP MX

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: JP

Ref document number: 97539297

Format of ref document f/p: F

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA