WO1998013998A1

WO1998013998A1 - A system and method for providing shared resources to test platforms

Info

Publication number: WO1998013998A1
Application number: PCT/US1997/017281
Authority: WO
Inventors: Kevin W. Rand
Original assignee: Mci Communications Corporation
Priority date: 1996-09-26
Filing date: 1997-09-26
Publication date: 1998-04-02
Also published as: US5838766A; AU4596697A

Abstract

A test system (199) for testing a plurality of switches (170, 180, 190). A test platform (110, 120, 130, 140) requests the resources required for performing a test. A central configuration queue manager (CQM-100) determines whether the requested resources are available and allocates the resources to the test platform (110, 120, 130, 140). However, some resources may be allocated in a blocking mode. That is, subsequent commands requesting such an allocated resource are queued until the resource is released/availabe. An example of a resource which may be allocated in blocking mode is a connection to a switch (170, 180, 190) from a test platform (110, 120, 130, 140). Other resources may be allocated in a non-blocking mode. An example of a resource which may be allocated in a non-blocking mode is an operator services trunk.

Description

A System and Method for Providing Shared Resources to Test Platforms

Background of the Invention

Field of the Invention The present invention relates generally to the field of telecommunications, and more particularly to a system and method for providing shared resources to test platforms.

Related Art

Telecommunications equipment and services are often tested prior to being deployed into commercial environments Commercial environments include network elements (e.g., switches) from various manufacturers These network elements may further include varying revisions of software A goal of the testing process prior to deployment is to identify and resolve any potential problems in providing network services The problems may include, for example, compatibility problems between newly developed network elements and/or software

An organization may employ several test platforms to perform several tests in parallel on several switches Examples of such switches include an AXE switch from Ericsson, Inc., and a DEX switch from DSC Communications Corporation A test platform may require several resources to perform a test For example, test platforms may require connections to several switches to send commands corresponding to a test and to gather results of the test

Generally, providing dedicated resources to each test platform is often impractical due to cost and manageability considerations For example, connecting 30 test platforms to 50 switches would require 1500 (i e , 5 X 10) dedicated connections It may be cost prohibitive to provide the large number of wires/trunks required for such dedicated connections It may also be quite onerous to manage efficiently the large number of wires/trunks

Some of the resources may be shared by several test platforms to decrease the aggregate number of resources provided in a test environment However, sharing resources may present new problems. For example, a shared resource may need to be allocated to a test platform before the test platform can utilize the resource An inefficient scheme of allocation of shared resources may result in undue delays in completing the performance of a test, which may be unacceptable

Therefore, what is needed is a system and method of efficiently providing the shared resources to test platforms in a test environment

Summary of the Invention

The present invention is described in the context of a system in which a plurality of switches are tested The system comprises a first test platform for performing a first test, and a second platform for performing a second test Both the first platform and the second platform require a shared resource to perform the respective tests The first test platform sends a first command requesting the shared resource and the second platform then sends a second command requesting the shared resource.

The present invention includes a manager for receiving the first command and then the second command The manager allocates the shared resource to the first platform, and then allocates the shared resource to the second platform upon the occurrence of a condition The test platforms perform the respective tests upon being allocated the resource The condition comprises receiving a resource release command from the first test platform. The manager of the present invention maintains a queue for the shared resource, and queues the second command in the queue until the resource release command is received.

The test system further comprises a cross connect coupled to the first test platform by a first test trunk and to the second test platform by a second test trunk The cross connect is also connected to a switch by a switch trunk The cross connect provides a connection between the switch and one of the two test platforms by connecting the corresponding test trunk to the switch trunk The resources managed by the manager includes such a connection to the switch

The manager of the present invention further comprises a storage for storing information indicative of which ports of the cross-connect are connected to the switch trunk and the test trunks. A resource management module examines the information stored in the storage to determine which ports are to be connected to provide the connection requested by the commands, and sends a connect command to the cross-connect to cause the cross-connect to to connect the ports

The condition upon which the shared resource is allocated to the second test platform includes specifying that access to the shared resource is to be provided in a non-blocking mode When the shared resource may be accessed in a non-blocking mode, the manager deallocates the resource from the first test platform and allocates the resource to the second test platform upon receiving the second command.

In a preferred embodiment of the present invention, the first command sent by the first test platform specifies whether subsequent requests to the shared resource are to be processed in a non-blocking mode. If the first command requests the resource in non-blocking mode, the manager deallocates the resource from the first test platform upon receiving a command request for the resource from the second test platform The first test platform is reallocated the shared resource after the second test platform sends a resource release command

Resources which may be accessed in non-blocking mode includes an operator services trunk originating from a non-bridging switch The first and second commands specify to which of a plurality of bridging switches the operator service trunk is to point. To allocate the bridging switch to a test platform, the manager automatically logs on to the non-bridging switch to change configuration on the non-bridging switch to have the operator services trunk point to the bridging switch as specified by a command from the test platform

As a shared resource is dynamically allocated to test platforms, the resource may be optimally utilized

Due to optimal utilization of resources, the aggregate amount of time to complete the performance a set of tests may be minimized

As a test platform requesting a shared resource may specify that the shared resource is to be allocated in blocking mode, and as all subsequent commands are forced to wait until the test platform releases the shared resource, the present invention enables test systems to optionally have exclusive control of shared resources while performing a test

By providing for non-blocking access to a shared resource, the resource may not be tied to a test platform while the resource is not being use

Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

Brief Description of the Figures

The present invention will be described with reference to the accompanying drawings, wherein:

FIG 1 is a block diagram of a test system including several test platforms for testing a plurality of switches,

FIG 2 is a block diagram illustrating an operator service call,

FIG 3 is a block diagram showing a non-bridging switch pointing to a bridging switch to service an operator service call,

FIG 4 is a diagram illustrating the information maintained by a configuration queue manager in allocating an operator services trunk to test platforms,

FIG 5 illustrates a queue structure maintained by a configuration queue manager for allocating shared resources in accordance with the present invention,

FIG 6 is a flow-chart illustrating the steps performed by a test system in one embodiment of the present invention; and

FIG 7 is a block diagram of a configuration queue manager (CQM) illustrating the components therein in accordance with the present invention Detailed Description of the Preferred Embodiments

FIG 1 is block diagram illustrating a test system 199 comprising four test platforms AOSMl 110, AOSM2 120, AOSM3 130 and AOSM4 140, configuration queue manager (CQM) 100, digital cross connect (DXC) 125, trunk network 160, CQM connection network 150, and three switches RES 1 170, RES6

180 and RES9 190. Each switch 170, 180 and 190 is shown connected to DXC 125 by three pairs of switch trunks (e.g , RES1 170 is connected to DXC 125 by switch trunks 112-114 and 122-124) Each test system 1 10, 120, 130, and 140 is shown connected to DXC 125 by a pair of test trunks (135, 145, 155, 195 and 165, 175, 185, 196) CQM 100 is connected to DXC 125 by command bus 105, and to RES1 170 by communication path 1 15

The system and method of allocating a resource of the present invention is described mostly with reference to AOSMl 110 and switch RES1 170 However, it should be understood that the description is applicable to other switches 120 and 130, and other test platforms 120 and 130 In a preferred embodiment of the present invention, a resource usually refers to one of the switch trunks 1 12-1 14, 122-124, 132-134 , 142-144, 152-154 and 162- 164 or an operator services trunk from RES1 170 in trunk network 160 As will be explained, these resources are shared by test platforms 110, 120, 130, and 140, and are thus dynamically allocated in accordance with the present invention

To perform a test, AOSMl 110 determines all the resources required for performing a test and requests CQM 100 to allocate the resources CQM 100 determines whether the requested resources are available, allocates the available resources to AOSMl 110, and sends a message to AOSMl 110 indicating that the resources are allocated. AOSMl 110 performs the test and then releases the allocated resources.

However, while performing the test, AOSMl 110 waits for any messages indicating that an allocated resource has been de-allocated (i.e., allocated to some other test system), in which case AOSMl 1 10 waits until the resource is reallocated. CQM 100 of the present invention sends the corresponding deallocation and re-allocation messages to AOSMl 110. CQM 100 de-allocates and re-allocates resources which are designated for non-blocking access as further explained below.

The present invention provides an option according to which a resource may be given non-blocking access to new command requests. If a request for such a resource is received from a test platform (AOSM2 120) when the resource is already allocated to second test platform (AOSMl 110), the resource is released from the second test platform (AOSMl 110), and provided to the test platform (AOSM2 120) requesting the resource. Once AOSM2 120 releases the resource,

CQM 100 re-allocates the resource to the second test platform (AOSMl 110) so that AOSMl 1 10 may continue with the test.

As the resources are allocated dynamically (i.e., when a resource is needed) to a test and released upon completion of the test, the resources of the present invention are utilized optimally. Such an optimal utilization of the resources usually results in a decrease in the overall amount of time required to perform a set of tests. This reduction in time allows test system 1 9 to handle a greater volume of tests.

By providing a non-blocking access to some of the resources, the present invention achieves further efficiency in performing tests. Resources which are likely to be used only for short durations but in many tests, are suitable for designation for non-blocking access. Each component of test system 199 is now explained in further detail The method of the present invention is then explained with reference to FIG. 6.

AOSMl 110 may comprise a conventional computer system programmed to generate command requests and to perform tests in accordance with the present invention. To perform a test, AOSMl 110 first determines the resources required for the test. The resources required may be indicated by a program implementing a test on AOSMl 110. AOSMl 1 10 then sends command requests to CQM 100 on CQM connection network 150. Each command request indicates a resource required for the test. In a preferred embodiment, commands for all resources required for performing a test may be included in a single packet.

As noted above, the requested resources include connections to an originating switch and a terminating switch. An originating switch may be a first switch in a series of switches which provide a circuit connection to serve, for example, a telephone voice call. The circuit may span several intermediate trunks and intermediate switches. A termination switch may be the last switch which connects the call to a receiving party/device. However, in the test environment of the present invention, while testing any two switches in a circuit path, an earlier switch (i.e., closer to the first switch) in the circuit connection path may be treated as an originating switch and a later switch (i.e., farther from the first switch) in the circuit connection as a termination switch.

AOSMl 110 is shown connected to an originating test trunk 135 and a termination test trunk 165. For illustration purposes, AOSMl 110 is assumed to have requested RES1 170 as an originating switch and RES9 190 as a termination switch To satisfy the requests, originating test trunk 135 is to be connected to one of originating switch trunks 112- 114 of RES 1 170, and terminating test trunk

165 is to be connected to one of terminating test trunks 591, 592 and 593 of RES9 190. DXC 125 performs the required connections under the control of CQM 125 as will be explained later The resources required in a preferred embodiment may also include an Operator service trunk'. An operator service trunk, as relevant to the present invention, is explained with reference to FIGS. 2 and 3. With reference to FIG 2, switch 200 receives an operator service call (e.g., collect call) from a caller 210 and connects the call to automatic call distributor (ACD) 260 over line 240 ACD

260 may connect the call to one of the operators available to service the call over one of the lines 270, 275, 280 and 285. An operator receives the call, determines the telephone number of a receiving party (for example, by speaking to the caller), and dials the number over line 250. Once receiver 220 receives the call and agrees to accept the call, the operator establishes a connection between caller 210 and receiver 220. Caller 210 may then continue to communicate directly to receiver 220

A bridging switch differs from a non-bridging switch in the manner in which an operator services call stays connected during a period caller 210 communicates with receiver 220. If switch 200 is a bridging switch, switch 200 bridges the two connections 240 and 250 internally, and connects the calls directly without having ACD 260 in the middle of the connection The bridging is shown as a dotted line 230 in FIG 2 Once the call is bridged, the trunks (or channels in the trunks) corresponding to 240 and 250 are released from the bridged call, and are available to service subsequent operator service calls Hence, trunks 240 and

250 of a bridging switch may not be tied for the entire duration of the operator assisted call, i.e., during a period when caller 210 talks to the receiver 220

Trunks 240 and 250 may be expensive and it is therefore desirable that operator service calls be bridged.

On the other hand, if switch 200 is a non-bridging switch, the call stays connected over trunks 240 and 250 during the entire duration of the operator service call. The call may not be bridged internally within switch 200. To avoid tying up trunks 240 and 250 during an operator service call, a bridging switch may point a trunk to a bridging switch as further illustrated in FIG. 3 In FIG 3, for the purpose of explanation, RES 1 170 is assumed to be a 'non-bridging switch' such as a DEX-600E switch available from DSC Communications Corporation, and RES9 190 is assumed to be a 'bridging switch' such as a DMS-250 switch available from Nortel (Northern Telecom) Corporation To handle operator service calls more efficiently, non-bπdgmg switch RE SI 170 may point an operator service trunk 310 to bridging switch RES9 190 Operator service trunk 310 may be included in trunk network 160 of FIG 1

By pointing the operator service trunk 310 to RES9 190, RES l 170 forwards all operator services calls to RES9 190 As RES9 190 is a bridging switch, trunks such as 240 and 250 of FIG 2 may not be tied-up during the entire duration of an operator service call However, an operator services trunk may point to only one bridging switch Therefore, if an operator services trunk is pointing to a switch other than a desired bridging switch, a test may need to wait until the operator services trunk becomes available to be pointed to the desired bridging switch In the present invention, such an operator service trunk is treated as a resource which is allocated among different tests

Continuing with the description of components of test system 199 with reference to FIG 1, DXC 125 receives connect commands from CQM 100 and provides the specified connections between test platforms 1 10, 120, 130, 140 and switches 170, 180, 190 DXC 125 may be one of several commercially available (e g , available from DSC Communications Corporation) digital cross connect switches DXC 125 may be capable of connecting any test trunk to any switch trunk as specified by a connect command received from CQM 100

Switches 170, 180, and 190 are connected by several service trunks shown together as trunk network 160 The service trunks generally carry data traffic corresponding to, for example, telephone voice calls The service trunks include operator services trunks from non-bridging switches Each switch 170, 180, 190 is connected to DXC 125 by several pairs of switch trunks One of the two trunks in each pair is designated as an originating test trunk (1 12-1 14, 132-134, and 152- 154), and the other a terminating test trunk (122-124, 142-144, and 162-164)

In a preferred embodiment, the number of pairs from each switch 170, 180, and 190 is less than the number of test platforms Test system 199 of FIG

1 is shown with four test systems 1 10, 120, 130 and 140, while each switch is shown connected to DXC 125 by three pairs of test trunks Thus, the test trunks are shared by test systems 1 10, 120, 130, and 140

The operation of CQM 100 is now explained in detail with reference to FIG 7 FIG 7 is a block diagram of CQM 100 including transaction queuing module 710, global memory 720, resource management module 730, and storage 740 A broad overview of the operation of the components is provided first Detailed description of operation of each component of CQM 100 is then provided

Generally, transaction queuing module 710 receives a packet over CQM connection network 150 and separates the command requests in the packet Global memory 720 stores the command requests and information pertaining to queues and status for the resources managed by CQM 100 Resource management module 730 determines the availability of resources and allocates the available resources Systems monitor 750 enables the display of the status of various resources on a display In addition, an operator may modify the configurations by manually entering commands using systems monitor 750 Storage 740 stores mapping information indicating which port of DXC 125 is connected to which test trunk or which switch trunk Each component of CQM 100 is now described in detail

Transaction queuing module 710 receives a packet including command requests for resources via CQM connection network 150, separates the commands in the packet, and sends the commands over command bus 712. The command requests include data specifying, for example, whether the request is for a connection or for an operator services trunk The command also includes data relevant to the type of request. For example, if the request is for a connection, the command specifies an origination trunk and a termination trunk If the request is for an operator services trunk, the command specifies a bridging switch and a non- bridging switch, and whether the trunk is to be allocated in a blocking mode or non-blocking mode.

In one embodiment, transaction queuing module 710 includes a parser to examine the data received from a test platform and to generate equivalent commands The parser may determine the resources required for processing each command request For example, a command request may request a connection from RES 1 170 to AOSMl 110 The command request may require at least two resources, i.e., a test trunk from RES 1 170 to DXC 125 and a switch trunk from DXC 125 to AOSMl 110 The parser accordingly determines that the two resources are required for processing the command request The parser may generate multiple sub-commands that correspond to each command However, in the present application such sub-commands are also referred to as command requests as some of the functions of the parser may be implemented in the test platforms itself The implementation of such a parser will be apparent to one skilled in the relevant art from the description provided herein

Global memory 720 receives command requests over bus 712 from transaction queuing module 710, and stores the command requests The information stored in global memory includes information corresponding to status of each resource as explained below with reference to FIG 4 One embodiment of CQM 100 is implemented on a DEC (Digital Equipment Corporation) machine which allows multiple processing entities to be executing in parallel Such entities may include processes, threads etc By storing all the information in global memory 720, the embodiment enables several parallel executing entities to perform corresponding tasks in parallel For example, systems monitor 750 may be performing a display function in parallel while resource management module 730 allocates resources. Additional modules (for example, for network management) may be easily added without modifying other parts of the software due to such storing in global memory 720. Also, if a configuration requires additional resources, multiple threads may execute in parallel to allocate the resources in parallel. Such parallel processing may result in faster response time in allocating the resources required for a configuration

Global memory 720 also stores information indicative of the status of each resource as will be explained now with reference to FIG 4 FIG 4 illustrates an example status data element 400 which is associated with each resource Status field 410 indicates whether the resource is idle or busy or queued An idle status indicates that the resource is not presently allocated to any test platform A busy status indicates that the resource has been allocated to a test platform, but it has not yet been released by the test platform A queued status implies not only that the corresponding resource is allocated, but also that there are additional commands requesting the resource

Owner field 420 specifies the test platform to which the resource is allocated Type field 430 specifies whether the resource is allocated for blocking or non-blocking access In one embodiment, the type is specified when a test platform requests a resource, and the type field 430 is set to the specified type when the resource is allocated to the test platform All subsequent requests for the resource are processed according to the type specified If the type is blocking access, the resource is unavailable for subsequent requests until the resource is released

Control field 440 indicates the processing entity identification (e.g., thread ID) which allocated the resource The field may also specify whether the resource has been manually allocated by an operator using, for example, resource monitor 750 Link field 450 specifies a link (e.g., a pointer) to an associated resource The links together specify a path of the resources allocated The link field for the resource last in the chain may be set to a value such as NULL to indicate the end of the chain. All the resources in a chain together specify the configuration for the test that is using the resources in the chain. Link field 450 is useful to determine all the resources allocated for a configuration, and such a feature may be used, for example, in the management of resources using resource monitor 750. The use of field 460 depends upon the specific resource Type If the resource is an operator services trunk, field 460 stores a value indicative of the bridging switch to which the operator service is presently pointing to

For an efficient memory utilization, one embodiment of global memory 720 uses a compressed bit map for storing such information That is, each bit in a byte may be used to indicate the status of a corresponding resource and a program is designed to properly interpret the bits The program may be implemented in software, hardware, firmware or the combination of the like

Continuing with the description of the modules of FIG 7, resource management module 730 processes the command requests stored in global memory 720. To process the commands for a requested configuration, resource management module 730 first determines whether all the required resources are available If all the resources are available, resource management module 730 allocates the requested resources While allocating a resource, resource management module 730 updates status data element 400 for each resource allocated Link fields 460 of all the resources together indicate configuration provided as a result of the allocation

If a resource is not available, resource management module 730 places the resource request command in a queue corresponding to the resource until the resource becomes available for allocation to the command After allocating all the resources, resource management module 730 sends a message on CQM connection network 150 to the test platform performing the test indicating that the resources have been allocated

Resource management module 730 may deallocate a resource from a test platform if the resource is specified for non-blocking access Field 440 specifies whether the resource is specified for blocking or non-blocking access. In one embodiment, the operator services trunks may be specified for non-blocking access Thus, if resource management module 730 receives a request for an operator services trunk from a new test system when the trunk is allocated to another test system, resource management module 730 deallocates the trunk from the other system, places the other system in a queue for the trunk, and allocates the trunk to the new system Once the new system releases the trunk, the trunk is reallocated to the other system placed in the queue

While allocation and deallocation, the fields of status data element 400 are modified to indicate the status of the resources For example, link fields 460 may be updated to indicate that a resource has been deallocated from the configuration for the test State field 420 is updated to indicate that the corresponding resource is queued with the test platform (or a command request therefore) which has been deallocated the resource Owner field 420 is set to indicate the new test platform which has been allocated the resource Upon reallocation, the fields of status data element 400 are again updated to indicate that the resource is allocated to the test platform which has been placed in the queue

The manner in which CQM 100 processes command requests for an operator services trunk is explained first, followed by the explanation of processing for commands for connections to the switches 170, 180, and 190

As already explained with reference to FIGS 2 and 3, each operator services trunk may point to only one bridging switch Resource management module 730 maintains a queue for each operator services trunk (such as shown in FIG. 5 but with a single server in a preferred embodiment). When an operator service trunk is unavailable and the trunk is specified for blocking access, the command requests received are queued in a corresponding operator services trunk queue. An operator services trunk is unavailable if it is allocated to a test platform and the test platform has not yet released the trunk However, if the trunk is unavailable but specified for non-blocking access, the trunk is de-allocated from a test system from a test platform that is presently allocated the trunk, and then the trunk is allocated to another test system sending the new command. Resource management module 730 sends a message to the test system from which the trunk has been de-allocated, and places a request for the de-allocated test system in the queue for the trunk

In a preferred embodiment, the command requests in the queue are serviced in a first-come-first-serve model well known in the art That is, when an operator services trunk becomes available, the trunk is allocated to the command which has been waiting the longest period in the queue Such command is then deleted from the queue.

To allocate an operator service trunk to a test system sending a command, resource management module 730 changes the configuration of the trunk on the bridging switch from which it originates To change the configuration of the operator services trunk to point to RES9 190, resource management module 730 logs on to RES 1 170 using path 115 and sends commands to cause the operator services trunk to point to RES9 190 In a preferred embodiment, resource management module 730 may use well-known tools such as scripts to log on to RES 1 170 and reconfigure the operator services trunk direction

After configuring an operator services trunk from non-bridging switch

(RES 1 170) to point to bridging switch (RES9 190), resource management module 730 updates the field of status data element 400 to indicate the change in status for the bridging switch 190 Specifically, field 460 is updated to store a value indicative of the new bridging switch RES9 190. Field 420 indicates the test platform which is presently allocated the operator services trunk. Field 430 indicates whether the operator services trunk is presently allocated for blocking or non-blocking access. Field 440 indicates an identification of a processing entity (e.g., thread ID) which allocated the bridging switch.

In one embodiment, a test system specifies in the corresponding command request whether the operator services trunk is required with blocking or non- blocking access Accordingly, when the test system is allocated the operator services trunk, field 430 is set to indicate blocking or non-blocking access Thus, if field 430 indicates blocking access, all subsequently received new commands for the operator services trunk are placed in the corresponding queue If field 430 indicates non-blocking access, a subsequent command may cause the operator services trunk to be de-allocated from the present test platform indicated in field 420

By allowing a test system requesting the operator services trunk to specify blocking or non-blocking modes, the present invention enables a test itself to make the determination whether the test needs guaranteed access until the test releases the operator services trunk. Also, if a test is not designed to properly work with deallocation of an operator services trunk in the middle of the test, the corresponding command requests may specify that the trunk is needed in a blocking mode. By default, the present invention allocates operator services trunks in blocking mode to ensure backward compatibility with tests that may not be designed for non-blocking access

After completion of a test, resource management module 730 receives a command from global memory 720 which indicates that the resources allocated to the test may be released and allocated to other test platforms Resource management module 730 modifies status data 400 to indicate that the operator services trunk is not being used by AOSMl 1 10 (assuming AOSMl 1 10 completed performing the test). Such modification may entail deleting an identifier for AOSMl 110 from the owner field 420. If no more command requests are waiting in the queue for the corresponding resource, state field 410 is set to indicate that the resource is idle If resources are waiting, resource management module 730 allocates the resource to the test platform sending the command in the queue according to a first come first serve basis. If additional commands are waiting for the resource, state field 410 remains in Queued status, or else status field 410 is set to busy status.

A test system thus allocated the operator services trunk may be one which was earlier de-allocated the trunk Upon receiving a corresponding re-allocation message, the test system may resume with the test if it was waiting for the operator services trunk to be reallocated. However, if the test was not waiting for the operator services trunk, the test system may simply change an internal variable to indicate that the operator service trunk is now again allocated.

The manner in which resource management module 730 processes the command requests in relation to establishing connections between test platforms 1 10, 120, 130, 140 and switches 170, 180 and 190 is now explained In general, CQM 100 first determines whether any of the switch trunks are available for connection to the test platform, determines the ports on DXC 125 for the available switch trunks and the test trunks of the test platform, and then sends connect commands to DXC 125 to provide the requested connection. The operation of CQM 100 in providing the desired connection is described in further detail now

Resource management module 730 maintains a queue (shown as 500 in

FIG 5) in global memory 720 to queue all requests to originating trunks of a switch, and another queue to queue all requests to terminating trunks of the switch Assuming AOSMl 1 10 sends a command requesting a connection to origination trunk of RES 1 170 and a termination trunk of RES9 190, the command may be placed in two queues, i e , in a queue for switch trunks 1 12-1 14 of RES 1 170 and in another queue for switch trunks 162-164 of RES9 190

The switch trunks may be allocated in a first come first serve basis well known in the art As each queue is processed by multiple testing trunks, a single queue multiple server model (also well known in the art) is employed Each test platform 110, 120, 130, 140 sends a command releasing a switch trunk once the test using the trunk is completed Accordingly the released switch trunk is available to serve the next command request (i e , the command waiting for longest time) in queue 500, 1 e , the command or test platform next in queue 500 is allocated the released switch trunk

To determine which of the ports of DXC 125 are to be connected to provide the connection requested by a command, CQM 100 maintains one or more tables (or maps) indicating which ports (of DXC 125) are coupled to which switch/test platform The data for the maps is stored in storage 740 Thus, if a switch trunk or test trunk is moved to a different port on DXC 125, a user need only change the data on storage 740 Resource management module 730 examines the map to determine which ports are to be connected to achieve the desired connection

After determining which ports in DXC 125 are to be connected, resource management module 730 sends connect commands on RS-232 line 105 to connect the corresponding ports In the above example in which AOSMl 110 is assumed to send a command requesting a connection to origination trunk of RES 1 170 and a termination trunk of RES9 190, a first connect command causes DXC 125 to connect AOSMl 110's origination trunk 135 to RES1 170 as shown by a dotted line CQM 100 then sends another connect command to DXC 125 to cause test trunk 165 to be connected to switch trunk 591 (dotted line connection not shown) The specific format of connect commands sent is dependant on the implementation of DXC 125 After allocation of the trunk, the status data element 400 of the trunk is also updated Owner field 420 is set to a value indicative of AOSMl 110 in the above example Type field 430 is always blocking in one embodiment State field

410 is set to busy once the trunk is allocated Link field 460 and control field 450 are explained above

Once all the resources required for a test are available and allocated, resource management module 730 sends a message on CQM connection network 150 to the test platform performing the test The message indicates that the requested resources have been allocated In response, the test platform begins running the test After the test is complete, the test platform releases any shared resources as explained above

However, if any of the requested resources for a test is unavailable, a preferred embodiment of the present invention does not allocate any of the requested resources Resource management module 730 places the command request (including a test platform identification) in a queue corresponding to the unavailable resource, and sends a message to the requesting test platform indicating which of the resources have been unavailable, and how many members are ahead in the corresponding queue Once such an unavailable resource becomes available, resource management module 730 allocates the resource to the test platform first in the queue, and indicates to the test platform that the resource is allocated to the test platform

Continuing again with the detailed description the modules included in CQM 100, resource monitor 750 enables an operator to verify the status of different resources In one embodiment, a graphical user interface is used in resource monitor 750 to display the status of various resources Using resource monitor 750, an operator may modify status data element 400 for different resources Such a feature enables the operator to change information to correspond to any unforeseen circumstances For example, if a test aborts in the middle before releasing a resource, the operator may manually change the entries in memory 720 to make the resource available to subsequent tests

The operation of various components in test system 199 is summarized again with reference to the flow-chart of FIG 6 For clarity, the flow-chart is explained with reference to AOSMl 110 The process begins in step 610, where

AOSMl 110 determines the resources required for conducting a test The resources generally include connections to an originating switch and a connection to a termination switch, and possibly an operator services trunk as explained above However, it will be appreciated that other resources required for performing a test may also be included by one skilled in the art by using the description provided in the present application

In step 690, AOSMl 110 sends a packet to CQM 100 requesting all the resources required for performing a test In step 630, CQM 100 determines whether the required resources are available as explained above with reference to FIGS 1, 4, 5, and 7 If all the required resources are available, CQM 100 allocates each required resource to AOSMl 110 in step 640 as also explained above with reference to FIGS 1, 4, 5, and 7 In step 640, CQM 100 sends a resources allocated message to AOSMl 1 10

In response to a resource allocated message, AOSMl 1 10 begins performing the test with the allocated resources in step 652 Before using a resource which may be deallocated, AOSMl 1 10 checks whether the resource (e g , operator services trunk) is de-allocated in step 654 If the resource is deallocated, AOSMl 110 waits for re-allocation of the resource, and continues performing the test in step 663

If the resource is determined not to have been de-allocated in step 654,

AOSMl 170 continues performing the test in step 663 In step 668, AOSMl 170 tests whether the test is completed AOSMl 170 repeats steps 654-668 until the test is completed AOSMl 170 then sends a message to CQM 100 to release the allocated resources

In step 680, CQM 100 checks whether other test platforms 120 or 130 are waiting for any of the released resources If any test platforms are waiting for a released resource, and if the released resource is the only resource the waiting test platform is waiting for, CQM 100 allocates the resources in step 640 for the waiting work platform

If CQM 100 determines that a required resource is unavailable in step 630, CQM 100 sends a resource unavailability message to AOSMl 1 10 in step 685, and places AOSMl 1 10's request in a queue corresponding to the unavailable resource CQM 100 waits for the resource to be available in step 680

It will thus be appreciated that CQM 100 serves as a central platform for dynamically allocating all the resources required by test platforms 110, 120, 130 for performing a test The resources may be accessed in non-blocking mode (e g , operator services trunk) or blocking mode (connections between switches and test platforms in one embodiment) The present invention further provides additional connections (e.g , bus 115 of FIG 1) for CQM 100 to perform any configuration changes to the resources (e g , RES! 170 of FIG 1)

Resources which are used for a short duration but by many tests (or multiple times within a test with long intervals in between), are normally requested for allocation in a non-blocking mode. Such a resource is not tied to any test platform, but is available for allocation for other test platforms if required Thus, a resource may be utilized more efficiently, thereby decreasing the aggregate amount of time in performing a set of tests

As the resources are allocated just prior to the performance of a test and released upon completion of the test, the resources may be optimally utilized, thereby resulting in a further decrease in overall time required for completing the tests. By allocating a resource only if all resources required for a test are available, test system 199 may avoid deadlock problems known in the art.

It will be further appreciated that various modifications can be made to the embodiments described above by one skilled in the art by reading the description provided herein without departing from the scope and spirit of the present invention. For example, test system 199 may be modified such that a single computer system may allow performance of several tests in parallel. Each of such tests may be implemented to run in parallel by using, for example, a process for each test In such a case, each test platform 1 10, 120, 130 and 140 may refer to such a process running a test

Thus, while various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation Thus, the breadth and scope of the present invention should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

What Is Claimed Is:

1. A test system comprising: a plurality of switches including a bridging switch and a non-bridging switch, wherein an operator services trunk originates from the non-bridging switch; a test platform for performing a test on said bridging switch and said non- bridging switch, said test platform being coupled to a pair of test trunks comprising a first test trunk and a second test trunk, said test platform sending a first command requesting a connection to each of the bridging switch and the non- bridging switch, and a second command requesting that the operator services trunk point to the bridging switch, the second command further specifying that the bridging switch be allocated in a non-blocking mode; a cross-connect coupled to said test platform by the pair of test trunks, the cross-connect also being connected to each of the plurality of switches by a switch trunk; and a manager coupled to said cross connect and said test platform, said manager receiving the first command and the second command from said test platform, the manager determining whether the switch trunks connected to said bridging switch and said non-bridging switch are available, said manager sending a plurality of connect commands to said cross-connect to connect said switch trunks to said pair of test trunks, said manager allocating the operator services trunk to said test platform by configuring the operator services trunk to point to the bridging switch to process the second command, wherein said cross-connect connects said switch trunk coupled to said bridging switching to said first test trunk, and said switch trunk coupled to said non-bridging switching to said second test trunk in response to said plurality of connect commands, wherein said manager allocates said bridging switch to said test platform in a non-blocking mode such that the manager allocates the bridging switch to a second test bridge in response to a third command from a second test platform, and wherein said test platform performs the test after the manager completes processing the first command and the second command.

2. A test system for testing a plurality of switches, said test system comprising: a first test platform for performing a first test, and a second platform for performing a second test, wherein both of said first platform and said second platform require a shared resource to perform the first test and the second test respectively, said first test platform sending a first command requesting the shared resource and the second platform then sending a second command requesting the shared resource; and a manager for receiving the first command and then the second command, said manager allocating the shared resource to said first platform, and then allocating the shared resource to the second platform upon the occurrence of a condition, wherein said first platform and said second platform perform the first test and the second test respectively upon being allocated the shared resource.

3. The test system of claim 2 wherein the condition comprises receiving a resource release command from the first test platform.

4. The test system of claim 3, wherein said manager maintains a queue for the shared resource, and queues the second command in the queue until the resource release command is received.

5. The test system of claim 4, further comprising a cross connect, wherein said cross connect is coupled to said first test platform by a first test trunk and to said second test platform by a second test trunk, said cross connect also being connected to one of said switches by a switch trunk, said cross connect providing a connection between said one said switches and one of the two test platforms by connecting the test trunk to the switch trunk, and wherein said resource comprises the connection

6 The test system of claim 5 wherein the queue is managed according to a first come first serve scheme

7 The test system of claim 6, wherein said manager further comprises a storage for stoπng information indicative of which ports of said cross- connect are connected to the switch trunk and the test trunks, a resource management module for examining the information stored in the storage to determine which ports are to be connected to provide the connection requested by the commands, the resource management module sending a connect command to said cross-connect to cause said cross-connect to provide the desired connections

8 The test system of claim 7, wherein said manager further comprises a memory for storing information corresponding to the queue

9 The test system of claim 2 wherein the condition comprises specifying that access to the shared resource is to be provided in a non-blockmg mode, wherein said manager deallocates the resource from the first test platform and allocates the resource to the second test platform upon receiving the second command

10 The test system of claim 9 wherein said first command specifies that access to the shared resource is to be provided in non-blocking mode

11 The test system of claim 10 wherein said manager maintains a queue for the shared resource, and wherein the manager places the first command in said queue upon deallocation of the shared resource 12 The test system of claim 1 1 wherein said second test platform sends a release command to release the shared resource, and wherein the manager reallocates the shared resource to said first test platform upon receiving the release command

13 The test system of claim 12 wherein said resource is an operator services trunk originating from a non-bridging switch and pointing to a bridging switch, and wherein the non-bridging switch and the bridging switch are comprised in said plurality of switches

14 The test system of claim 13 further comprising a means to enable said manager to automatically log on to said non-bridging switch to change configuration on said non-bridging switch to have said operator services trunk point to said bridging switch

15 A method of performing a plurality of tests comprising a first test and a second test, wherein a shared resource is required for performing both of the first test and the second test, the method comprising the steps of sending from a first test platform a first command requesting the shared resource, sending from a second test platform a second command requesting the shared resource, receiving the first command and then the second command in a manager, allocating the shared resource to the first test platform in response to receiving the first command, allocating the shared resource to the second test platform upon the occurrence of a condition, performing the first test using the shared resource allocated, and performing the second test using the shared resource allocated 16 The method of claim 15 wherein the condition comprises receiving a resource release command from the first test platform

17 The method of claim 16 wherein the resource comprises a connection to a switch, and wherein the step of allocating the shared resource to the first platform further comprises the steps of determining the ports on a cross-connect which are connected to a test trunk from the first test platform and a switch trunk from the switch, and sending a connect command to the cross-connect to cause the cross- connect the ports corresponding to the test trunk and the switch trunk to provide the desired connection

18 The method of claim 15 wherein the condition comprises specifying that the shared resource can be accessed in non-blocking mode, and wherein the method further comprises the steps of deallocating the shared resource from the first test platform, receiving a release resource command from the second test platform, and reallocating the shared resource to the first test platform after receiving the release resource command

19 The method of claim 14 wherein the step of allocating further comprises sending a connect command to a cross connect, wherein the cross connect dynamically connects the test platform to the switch in response to the connect command