Message routing through data communication networks

Abstract

A mechanized system distributing the access, test and communication functions to the point of testing, typically the centralized switching facility serving the telephone loops and equipment to be tested. Computer (200) stores information about each subscriber loop in the geographical area served by a system. Front-end computers (220,221) interact with computer (200) to retrieve pertinent data regarding loops to be tested. Each switching facility in an area includes a loop testing system (e.g., 160) that implements the required functions. The communication functions residing in front-end computers (220,221) and loop testing systems (160,161) are coupled via a data communication network (140) in a manner that allows any front-end computer to communicate with any loop testing system. Users of the system control access and test from consoles having the capability of establishing independent communication paths over the national dial network for interactive tests on loops accessed through standard test trunks. Microprocessor-based circuitry is utilized for numerous system tasks such as signal generation, digital signal processing and controlling sensitive analog measurements. Signal generation includes digital generation of analog waveforms. Signal processing techniques incorporate various digital filters to analyze sample sequences derived from, for example, dial pulses and coin telephone signals. Sensitive analog measurements of loop characteristics are effected with a magnetic current detector that operates over broad current and frequency ranges. Frequency dependent measurements are converted to DC using synchronous demodulation techniques to enhance resolution.

Claims

What is claimed is:

1. In a distributed data communication network for use in a telephone or general data transmission system, a method comprising the steps of

dynamically allocating a return path through said network for each message traversing said network from a message source coupled to said network,

storing a plurality of most recent return paths associated with said source in a message receiver,

transmitting return information to each said message from said receiver over the return path associated with said message, and

if said information is blocked by said network, alternatively transmitting said information over another of said recent return paths.

2. In a data communication system for use in telephone or general transmission networks (140) for transmitting messages between a request computer (e.g., 220) and a response computer (e.g., 14001) connected by a plurality of dynamically allocated paths through said system, each of said messages, upon reception at said response computer, having an identififer (LOGICAL ID) indicative of the logical location of the requesting computer within said system and the path (`up.sub.-- route`) selected for traversing said system, a method comprising the steps of

(A) storing in said response computer a preselected number of the recent paths associated with said identifier,

(B) transmitting a response message over the path selected for traversing said system as determined by the contents of the corresponding request message, and

(C) if step (B) is unsuccessful, alternatively routing said response message over one of said most recent paths.

3. In a data communication system for use in telephone or general transmission networks (140) for transmitting messages between a plurality of request computers (220,221) and a response computer (e.g., 14001), each of said request computers and said response computer being connected by a plurality of dynamically allocated paths, each of said messages, upon arriving at said response computer, having an identifier (LOGICAL ID) indicating the corresponding one of said request computers and the path (`up.sub.-- route`) utilized to traverse said system, a methoc comprising the steps of

storing in said response computer, for each of said messages, a predetermined number of the most recently used paths associated with each said identifier,

sending a response message corresponding to a request message over the path utilized to traverse said system as determined by the contents of said request message, and

upon a transmission failure of said response message, alternatively routing said response message over one of said recently used paths.

4. In a data communication network for use in a telephone or general data transmission system (140) for transmitting messages between originating computers (220,221), each with a logical identifier, and a terminating computer (e.g., 14001), a method comprising the steps of

augmenting each of said messages with a field (LOGICAL ID) containing said identifier indicating the particular originating computer,

dynamically allocating a path (`down.sub.-- route`) through said network as determined by information stored in said originating computer,

transmitting each augmented message over said path,

compiling information (`up.sub.-- route`) to determine a return path as each augmented message traverses said network,

extracting, at said terminating computer, said return path and storing a predetermined number of the most recent ones of said return paths associated with each said identifier,

sending a response corresponding to said each augmented message over said return path, and

upon blockage of said return path, alternatively routing said response over one of said recent ones of said paths.

5. In combination with a distributed data communication network for use in a telephone or general data transmission system linking a message source with a message receiver, circuitry comprising

means (1401-1412, 1421-1468) for dynamically allocating a return path through said network for each message traversing said network from said source,

means (14001-14096) for storing a plurality of the most recent return paths associated with said source in said receiver,

means (14001-14096) for transmitting information for each said message over the return path associated with said each said message, and

means (14001-14096) for alternatively transmitting said information over another of said recent return paths upon a blockage by said network of said return path associated with said each said message.

Description

REFERENCE TO A MICROFICHE APPENDIX

This application contains a set of microfiche appendices, designated A through C, listing programs incorporated in the testing system comprising the subject matter of this disclosure. The total number of microfiche is 16 and the total number of frames is 923.

CROSS-REFERENCE TO RELATED APPLICATIONS

The following U.S. applications, which are assigned to the same assignee as the instant application and filed concurrently therewith, have related subject matter. Certain portions of the system, processes and circuitry herein disclosed are inventions of the below named inventors as defined by the claims in the following patent applications:

(1) "Mechanized Testing of Subscriber Facilities", Ser. No. 399,177 of H. Rubin, since issued as U.S. Pat. No. 4,446,341 on May 1, 1984;

(2) "Data Communication Network", Ser. No. 399,186 of C. L. Coleman-H. Rubin; now U.S. Pat. No. 4,562,436

(3) "Networks for Data Communication", Ser. No. 399,187 of H. Rubin;

(4) "Parallel Bus Protocol", Ser. No. 399,171 of N. R. Fildes;

(5) "System for Accessing and Testing Subscriber Loops", Ser. No. 399,185 of H. Rubin, since issued as U.S. Pat. No. 4,438,298 on Mar. 20, 1984;

(6) "Switching Network for Interactive Access and Testing of Subscriber Loops", Ser. No. 399,188 of H. Rubin, since issued as U.S. Pat. No. 4,467,147 on Aug. 21, 1984;

(7) "Stored Program Controller", Ser. No. 399,175 of H. Rubin;

(8) "Programmable Tester for Measuring Network Characteristics", Ser. No. 399,172 of H. Rubin, since issued as U.S. Pat. No. 4,459,436 on July 10, 1984;

(9) "Programmable Network Tester with Data Formatter", Ser. No. 399,184 of K. B. Kemper-H. Rubin now U.S. Pat. No. 4,525,789.

(10) "Programmable Gain Amplifier", Ser. No. 399,183 of K. B. Kemper;

(11) "Digital Signal Generator", Ser. No. 399,176 of H. Rubin; now U.S. Pat. No. 4,525,795.

(12) "Magnetic Current Sensor", Ser. No. 399,182 of K. B. Kemper; now U.S. Pat. No. 4,536,706.

(13) "Magnetic Current Sensor with Offset and Load Correction", Ser. No. 399,174 of J. M. Brown-K. B. Kemper, since issued as U.S. Pat. No. 4,516,070 on May 7, 1985;

(14) "Magnetic Differential Current Sensor", Ser. No. 399,173 of J. M. Brown, since issued as U.S. Pat. No. 4,517,513 on May 14, 1985;

(15) "Digital Filtering with Monitored Settling Time", Ser. No. 399,189 of H. Rubin;

(16 ) "Dial Pulse Measurement Circuitry", Ser. No. 399,181 of H. A. Miller, since issued as U.S. Pat. No. 4,501,003 on Feb. 19, 1985;

(17) "Coin Telephone Measurement Circuitry", Ser. No. 399,178 of H. A. Miller; now U.S. Pat. No. 4,590,583.

(18) "Dual-port Random Access Memory Arrangement", Ser. No. 399,179 of H. C. Bond-E. H. McFadden-H. A. Miller.

TABLE OF CONTENTS

Technical Field

Background of the Invention

Summary of the Invention

Brief Description of the Drawing

Detailed Description

1.: THE MECHANIZED LOOP TESTING (MLT) ARCHITECTURE

2.: MLT IMPLEMENTATION

2.1: Data Communication Network (DCN)

2.1a: Structure

2.1b: Message Routing

2.1c: Software Design

2.1d: Software Operation

2.2: Loop Testing System (LTS)

2.2a: Structure

2.2b: LTS Operation

2.2.1: LTS Controller

2.2.1a: Access Request Processing

2.2.1a.1: Regular Test Access and MDF Trunk Access

2.2.1a.2: Interactive Access Request Processing

2.2.1a.3: Callback Access Processing

2.2.1b: Test Request Accessing

2.2.1c: LTS Requests

2.2.1d: LTS Controller Circuitry

2.2.2: Port Controller

2.2.3: Precision Measurement Unit (PMU)

2.2.3a: Digital Signal Generator (DSG)

2.2.3b: Magnetic Current Sensor

2.2.3c: Signal Processing

2.2.3d: PMU Controller

2.2.4: LTS Circuits For Establishing Loop Connections

2.3: Front End (FE) System

3.: MLT CIRCUITRY AND PROGRAMS

3.1: DCN Implementation

3.1.1: Circuitry

3.1.2: DCN Programs

3.2.1: LTS Controller Implementation

3.2.1a: LTS Main Controller Circuitry

3.2.1b: LTS Universal Memory

3.2.1c: LTS Serial Data Line Interface

3.2.1d: LTS Programs

3.2.1e: Test Sequences

3.2.2: Port Controller Implementation

3.2.3: PMU Implementation

3.2.3a: DSG Circuitry

3.2.3a.1: DSG Software Considerations

3.2.3a.2: DSG Hardware Considerations

3.2.3b: Magnetic Current Sensor Circuitry

3.2.3c: Digital Processing and Control

3.2.3d: Digital Processing Considerations

3.2.4: Loop Connection Circuitry

3.3: FE System Considerations

TECHNICAL FIELD

This invention relates generally to testing of telecommunication facilities such as telephone loops provided over multipair cables and, more particularly, to a stored program control system which directs a network of distributed processors to access and measure the facilities.

BACKGROUND OF THE INVENTION

In order to test telephone loops, whether for fault diagnosis, preventive maintenance purposes or even to compile statistical information about loop characteristics, three basic functions are required, namely: access, test and communication. These three basic functions can readily be identified for any manual or automatic testing system. For instance, within each system, there are mechanisms for gaining control of a loop to be tested, for connecting to it and for directing appropriate testing activities. Moreover, a two-way communication path exists between testing personnel or equipment interfaces so that selected test activities may be initiated, coordinated and the results collected for analysis. Oftentimes, an automated central controller determines the testing pattern and analyzes results via interpretive algorithms.

One such computer-based system has been described in an article entitled "The Evolution of the Automated Repair Service Bureau with Respect to Loop Testing", published in the Conference Record of the International Symposium on Subscriber Loops and Services, March 1978, pages 64-68 as authored by O. B. Dale. The Automated Repair Service Bureau (ARSB), which supports loop maintenance operations, includes the following maintenance functions: receiving trouble reports from customers; trouble report tracking; generating management reports; and real-time loop testing and fault diagnosis. Thus, within the ARSB framework, there is provided a rapid, convenient method for testing and analyzing test results automatically at the time of customer contact as well as on demand during repair procedures.

In order that the subject matter of the present invention may be elucidated, it is important to elaborate on the ARSB architecture and the capabilities of the above-mentioned testing arrangement within this architecture. The information presented by this overview is set forth in the above-mentioned reference as well as in an article entitled "Automation of Repair Service Bureau", Conference Publication No. 137 of the International Symposium on Subscriber Loops and Services, May, 1976 as authored by R. L. Martin. FIG. 1 indicates that the conventional ARSB comprises a tree-like structure with four major levels. At Level 1 of the tree is a data storage computer (200) which maintains a master data base of up to five million customer line records; the information on these records includes data as to equipment terminating the loop, loop composition, customer telephone number, and so forth. Level 2 is composed of an array of front end (FE) computers (220,221), each of which manages the bulk of the trouble report processing for about 500,000 lines. The users of the system, typically maintenance and craft personnel of the telephone company deploying the ARSB, interact with the system at this level. Level 3 is an array of control computers (240,241) that control access and testing and provide analysis of test results. Level 4 comprises loop testing frames (250,251) which perform the loop accesses and actual test measurements via test trunk connections to switching machines located in geographically-dispersed central offices.

Test requests from users are received and supervised by the FE computers and then performed by algorithms in the control computers and circuitry in the loop testing frames. The tests conducted are based on adaptive algorithms that compose test scripts in real time as a function of the electrical characteristics of the customer's equipment in the idle state. The data used are extracted from the data storage computer and then provided by the FE computers at the time the test request is generated. As testing on a customer's loop proceeds, the test script is continually being revised to reflect the knowledge of the loop which has been gained from the test results. The final test results and analysis are formatted for display to the user by the requesting FE computer. Varying levels of display detail, based on the technical sophistication of the user, are provided.

The loop testing subsystems of the ARSB were arranged to provide an area-based (about 1 million loops) system in order to expedite its introduction and mitigate cost to users. As a result, not all of the testing functions of the standard pre-ARSB facility, known as the Local Test Desk (LTD), were incorporated. For instance, the LTD continued to be used for interactive testing between testers at the LTD and field repair craft. The loop testing subsystem could not be utilized to maintain a connection to the loop under test for a prolonged duration, nor could field repair personnel be guided through a series of steps to diagnose, locate and correct a fault. In short, the loop subsystem was effective only in screening troubles and performing pre-dispatch and post-dispatch testing. Also, not every type of terminal equipment could be tested. For instance, coin telephone features were precluded from testing. Moreover, because the LTD operated within the same environment as the ARSB, the LTD was considered a backup during temporary outages of ARSB so there was no need for redundancy or fail-soft operation in the testing system. Finally, the area-oriented system was not cost effective for single wire centers serving only a few thousand lines.

With the above background, the significant limitations and deficiencies of the conventional ARSB testing system, including those emphasized above, may be summarized as follows: (1) no interactive testing capability with field craft personnel nor customers; (2) inability to test coin telephone stations including such conditions as off-normal totalizers, stuck coin conditions, coin collect and coin return circuitry, and loop-ground resistance; (3) impossible to test and talk over the same test connection; (4) no single- and double-sided resistive fault sectionalization capability; (5) no ability to apply metallic or longitudinal pair identification tones; and (6) no capability to control and monitor concurrent testing operations from a single work station.

Besides the ARSB approach, numerous other automated, but less complex, approaches have been employed to effect loop testing. Typically these have focussed on specialized problem areas, such as rapid-scan procedures to verify the accuracy and quality of splicing operations or simplified checks on easily quantifiable loop parameters like loop insulation resistance or loop impedance at a given frequency for preventive maintenance purposes.

Other automated approaches, with a sophistication comparable to the ARSB approach, have been developed for the purpose of diagnostic testing. One representative prior art system is disclosed in U.S. Pat. No. 4,139,745 issued to Ashdown et al on Feb. 13, 1979. Broadly speaking, the system comprises control means having a programmed digital computer and associated memory, a line test network, at least one user station and an interface for interconnecting these elements and one or more telephone exchanges and the plurality of telephone lines extending from such exchanges.

The line test network is responsive to the digital computer and includes means for generating a plurality of signals for a test cycle. During a cycle, besides DC and noise measurements, AC signals are applied to the three-wire line comprising the tip-ring-ground conductors and longitudinal and metallic response signals are measured. The responses are utilized to provide an indication of the capacitive load across the line which, in turn, may be translated to produce parameters indicative of, for example, line length, type of termination and possible line faults.

However, this prior art system possesses the same shortcomings and limitations summarized above with respect to the ARSB. Moreover, since the system is not comprised of a data base for storing information about line composition, adaptive testing and interpretation of results in view of line configuration information is precluded. In addition, although may users may have access to the system, each testing operation is basically sequential and there is no suggestion that access and testing operations on many different lines within one exchange may be occurring concurrently.

It is clear from a perusal of the prior art portion of the ARSB set forth in FIG. 1 that each grouping of test trunks is served by only one FE computer. In the event of a FE computer outage, the Local Test Desk could, temporarily, satisfy user test requests. However, such reliance reduces system throughput and is inappropriate in a fully automated testing environment. Such a shortcoming is obviated in an architecture that allows a plurality of FE computers to access any particular trunk.

To mitigate these and similar shortcomings, some distributed computer systems require that a cluster of controlling minicomputers communicate with remote entities that typically include microprocessor-based subsystems. However, when the number of such remote entities become large, a significant amount of minicomputer processing time must be devoted to these communication needs, and throughput is again reduced.

Also, packet switching networks may be used advantageously in some situations, but delay times through such networks and the cost of additional remote circuitry can render these solutions unattractive.

With the development of microprocessors, which function autonomously, it becomes feasible to decentralize switching functions and thereby offload many controller computer communication activities to the actual point of switching. Such an arrangement is discussed in U.S. Pat. No. 4,285,037 issued to H. Von Stetten on Aug. 18, 1981; this disclosure is selected as representative of numerous distributed processor switching networks configured for intercomputer communication. In these networks, all distributed processors, generally microprocessors, are connected to one another via a common bus. Communication of messages in the transmitting and receiving directions occurs between the processors in the form of information blocks having address information. A central clock is provided under whose control respective processors are cyclically connected for the emission of an information block and all other processors are connected to the common data bus in the receiving mode. Only the receiver having the specified address then receives the desired message. The processors comprising the system receive information from and transmit messages to associated peripheral or interface devices. For instance, some processors may be coupled to terminals or memories, whereas other processors may connect to communication lines having different baud rate capabilities.

The major shortcomings of such an arrangement include the utilization of a common bus which precludes alternative routing in case of a bus failure and the sequencing procedure allowing only one bus talker at a time. During peak message transfer periods, such an allocation procedure could lead to blocking situations with concomitant throughput delays.

Also, the standard communication sequences between a sender and receiver over a bus are usually replete with segments of no activity on the bus. For instance, after the sender transmits a message, the receiver computes a check word while the sender remains idle. The receiver then returns an acknowledge/negative acknowledge status message. Once the transmitted message is accepted, the sender then determines the next activity while the receiver is now inactive. Techniques have been devised to improve the efficiency of transmission in this simple sender-receiver situation. One such improvement utilizes the time the sender is idle (during check word computation) to effect a determination of the next activity.

The inefficiency is magnified in the situation of a talker communicating with many listeners. During the period in which one receiver is computing a check word, the remaining receivers are idle. If a retransmission is necessary, the inefficiency is compounded. Part of the difficulty occurs because the accept-reject status of a total message is also formulated as a message and returned over the data leads of the bus. Moreover, in situations exemplified by the MLT system, wherein the message propagate time is of the same order as a check word computation, the sender is idle for a significant portion of each transmission activity. This is in contrast to the situation wherein the messages are considerably longer than the check word computations, so the percentage of time the sender is idle is small.

As alluded to above in the summary of ARSB deficiencies, automated testing of coin telephone systems has, in the past, presented severe implementation problems because of the special nature of the coin equipment. Other special loop situations, such as analysis of dial pulses or measurement of nonlinear devices like thermistors, have also presented basically insurmountable implementation difficulties with conventional automated test procedures and equipment. Fortuitously, however, technological advances recently occurred which now make it possible to solve these problems and difficulties. Advances in microcomputing, digital signal processing and measurement technology have provided the motivation for the development of versatile digital signal generators and digital analysis techniques, including digital filtering, which produce rapid and accurate measurements. Unfortunately, however, the majority of subscriber line to be tested are still analog in nature and parameters of interest relate to the frequency-dependent characteristics of the lines. Therefore, a suitable transponder for interfacing the analog lines to the sophisticated digital processing techniques is still a fundamental necessity.

One such transponder arrangement developed for sensitive line current measurements is disclosed in U.S. Pat. No. 4,274,051 issued to J. Condon on June 16, 1981. The invention set forth in this reference utilizes a pair of magnetic structures to produce an output signal when the current on the loop is other than zero. However, because the line currents undergoing measurement with this arrangement were large in magnitude, the errors caused by differences in the hysteresis characteristics between structures were negligible and could be ignored. Such errors, particularly when measuring differential currents, prove to be critical and require compensation to insure accuracy and resolution over the broad operating range expected of the transponder in the digital processing environment.

SUMMARY OF THE INVENTION

In accordance with the illustrative embodiment of the present invention, a data communication network devised for routing high-level messages between a plurality of control computers and numerous response computers utilizes a multitier microprocessor structure and internal interconnecting bus arrangement that provides two alternative paths between the input and output ports of the network. To maintain this degree of redundancy between the remotely located control computers and the data network itself, each control computer supports two independent, dynamically allocated paths which terminate on the network input ports. A unique logical identifier is associated with each computer and this identifier is stored in a header portion of each message compiled and transmitted by a particular control computer. Each microprocessor in the last tier serving as the output of the network extracts the identifier as well as information about the primary return path as stored in the header. The primary path is dynamically compiled as the message traverses the network. Each logical identifier and a plurality of the most recently used paths associated with each identifier are stored in each last tier microcomputer. The primary path is utilized on a first attempt to return a response message and, upon a path failure or blockage, one of the plurality of most recently used paths is selected as an alternative route.

The invention is set forth with particulaity in the appended claims. An understanding of this invention may be obtained with reference to the following detailed description taken in conjunction with the accompanying drawing.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 indicates the architectural arrangement of one conventional automated testing system and, in accordance with an alternative embodiment of the present invention, an arrangement for integrating the distributed Merchanized Loop Testing (MLT) system within the conventional system to expand test capabilities.

FIG. 2 depicts, in overview fashion, a block diagram of the major components comprising the stand-alone Mechanized Loop Testing system, as well as the interconnections among these components.

FIG. 3 depicts a three-tier multiprocessor realization of the Data Communication Network (DCN) shown in block diagram form in FIG. 2.

FIG. 4 illustrates the internal bus structures of the connection matrix and the connection arrays of the DCN.

FIG. 5 shows the flag-field pattern for a representative conventional high level data link protocol and, in particular, the location of the INFORMATION field within the pattern.

FIG. 6 indicates the composition of the INFORMATION field in terms of HEADER parameters and DATA bytes utilized by the MLT system in message routing, loop access and loop test.

FIGS. 7, 8 and 9 show the microcomputer software architecture, in pictorial form, for tiers 1, 2 and 3, respectively, of the DCN. These illustrations are pictorial in the sense that they indicate a logical situation in terms of the number of copies of software utilized to implement the various system tasks.

FIG. 10 depicts the priority of execution of tasks within any of the microcomputers of the DCN. Both the initialization execution (top portion of FIG. 10) and execution with external event interrupts are illustrated.

FIG. 11 depicts, in block diagram form, a realization of the Loop Testing System (LTS) shown pictorially in FIG. 2.

FIG. 12 illustrates the DATA bytes in the INFORMATION field for the regular or main distributing frame access request message as routed through the LTS of FIG. 11.

FIG. 13 illustrates the contents of an interactive request message when both a loop access and a talk path to the Maintenance Center are to be established.

FIG. 14 depicts the message returned from the port controller of FIG. 11 in response to an access request message.

FIG. 15 illustrates those DATA bytes extracted from the message format of FIG. 13 which are then utilized by the TCD task of the LTS controller of FIG. 11 to establish the actual callback path.

FIG. 16 is a depiction of the message format for a test request.

FIG. 17 depicts, in block diagram form, the circuitry comprising one Precision Measurement Unit (PMU) of FIG. 11.

FIG. 18 is a more detailed representation of the PMU controller, AC-DC source generator and digital signal processing portions of the block diagrams of FIG. 17.

FIG. 19 illustrates the arrangement of memory bytes to realize the accumulator of the digital signal generator within the AC-DC source generator of FIG. 17.

FIG. 20 is a diagram, partly in schematic and partly in block form, showing one implementation of the source applique of FIG. 17.

FIG. 21 indicates essential portions of magnetic current sensor circuitry of the detector portion of FIG. 17 whereby loop currents are transformed to equivalent voltages.

FIG. 22 depicts the processing circuitry of the detector of FIG. 17 utilized to filter and scale the equivalent voltages.

FIG. 23 shows a block diagram representation of the measurement processor of FIG. 17.

FIG. 24 indicates the manner in which FIGS. 18, 20, 22 and 23 may be arranged to form a composite representation of FIG. 17.

FIG. 25 indicates that the PMU task provides data to specify which of the many possible test requests is to be selected and, accordingly, appropriate parameters are passed to the measurement cycle controller.

FIG. 26 depicts the sequencing of the measurement cycle controller for each configuration of PMU circuitry.

FIG. 27 illustrates the switch matrices comprising the equipment access network of FIG. 17 as well as the arrangement of various access and test circuits of FIG. 17 at the ports of the equipment access network.

FIG. 28 indicates that: a tier 1 device in the DCN is composed of the circuitry depicted in FIGS. 29 and 30; a tier 2 interface is formed from the circuitry of FIGS. 29 and 30; and a tier 3 circuit comprises the circuitry of FIGS. 29, 32 and 33.

FIG. 29 is a block diagram representation of the CPU circuitry utilized by the three tiers of the DCN.

FIG. 30 is a block diagram illustration of the serial-input, parallel-output communication circuitry of a tier 1 device.

FIG. 31 is a representation in block diagram form of the parallel-to-parallel communication circuitry of a tier 2 interface.

FIG. 32 depicts the parallel-input portion of a tier 3 circuit in block diagram form, whereas FIG. 33 shows the serial-output portion of each tier 3 circuit.

FIGS. 34 through 36 and 38 through 41 are schematics of the various subsystems comprising the CPU circuit of FIG. 29 and include, respectively: the reset circuitry; the interrupt structure; the microcomputer-based processor; address buffer; random access memory; address decoder; and timer, buffer and circuitry identifier arrangements.

FIG. 37 is a timing diagram indicating the levels of the ports of the microcomputer relative to the input clock.

FIG. 42 depicts the signal leads comprising the three external busses and the internal bus shown in FIG. 29

FIGS. 43 through 48 are schematics of the different subsystems comprising the serial-to-parallel portion of a tier 1 device shown in FIG. 30 and include, respectively: read-only memory; talker/listener/controller interface; direct memory access circuits with accompanying data buffer; data link protocol interfaces with associated buffer; and chip select circuitry.

FIGS. 49 through 53 are schematics of the subsystems cooperating to form the parallel-to-parallel portion of a tier 2 interface shown in FIG. 31 and include, respectively: talker/listener interface; direct memory access circuitry; and chip select circuitry.

FIGS. 54 and 55 are schematics of the serial output portion and the programmable interval timer portion, respectively, of a tier 3 circuit shown diagrammatically in FIG. 33.

FIG. 57 is a depiction of the interconnection between a controller and listener explicitly setting forth the serial poll register contents and the major/minor addressing capability of the general purpose bus.

FIG. 58 indicates that: the LTS controller of FIG. 11 is comprised of the circuitry depicted in FIGS. 59, 69 and 72; the port controller of FIG. 11 is a composite of the circuitry shown in FIGS. 59, 69 and 81; the PMU controller of FIG. 17 is formed from the circuitry illustrated in FIGS. 59 and 69; and the digital signal processing circuitry of FIG. 17 is depicted by the block diagram of FIG. 110.

FIG. 59 is a block diagram representation of the CPU circuitry utilized to implement either the LTS main controller, port main controller or the PMU main controller.

FIGS. 60 through 68 are schematics of the different modules forming the basic main controller as depicted by FIG. 59 and include, respectively: the microprocessor and its associated controller as well as bus buffers; timer and bus adapter; bus controller and associated buffers as well as system reset; system oscillator and clock divider; and two types of random access memory.

FIG. 65 depicts the signal leads comprising the external and internal busses shown in FIG. 60.

FIGS. 66 through 68 indicate the memory allocation, including those bank-switched portions, for the LTS controller, the port controller and PMU controller, respectively.

FIG. 69 is a block diagram of the universal memory board which indicates that FIG. 70 provides the schematic diagrams for the data transceiver, address buffer and decoder as well as the bank selector portions of the universal memory whereas FIG. 71 provides the arrangement of memory devices.

FIG. 72 is a block diagram of the data line interface associated with the LTS controller of FIG. 58.

FIGS. 73 through 75 are schematics of the subcomponents comprising the data line interface of FIG. 72 and include, respectively: read-only memory and random access memory realizations as well as address decoding for these memories; synchronous data link protocol controller and associated clock; and reset and data buffer circuitry.

FIG. 76 is a block diagram representation of circuitry arranged to effect a measurement of loop balance.

FIG. 77 incorporates both schematic and block diagram illustrations to indicate the procedure for measuring metallic noise in LOOP, RING ground and TIP ground start central offices.

FIG. 78 indicates an arrangement for detecting a single frequency tone on a subscriber loop.

FIG. 79 presents circuitry for rotary dial analysis.

FIG. 80 is a representation of a circuit utilized to test for receiver off-hook conditions.

FIG. 81 is a block diagram of the port interface associated with the port controller of FIG. 58; this diagram indicates that circuit details relating to the address decoder are given in FIG. 82 whereas FIG. 83 presents random access memory realizations.

FIG. 84 is a block diagram depiction of circuitry comprising the AC portion of the source generator of FIG. 18.

FIG. 85 is a more detailed representation of one AC reference signal generator depicted in FIG. 84.

FIG. 86 is a structure chart indicating the calling linkages among the various processes, output functions and subroutines comprising the programs of the AC generators of FIG. 84.

FIGS. 87 and 91 are flow charts for the RESET process and the DATA ACCEPT subroutine depicted in FIG. 86, whereas FIGS. 88 through 90 provide the flow chart for the NMI process.

FIG. 92 illustrates the data transfer sequence for a variable byte count relating to providing information to the Sequence Single Frequency output function.

FIG. 93 depicts the bit weights to be assigned to the hexidecimal data values for digital signal generation.

FIG. 94 indicates the number and order of transmission of bytes for the various output functions of the source generator.

FIG. 95 is a flow chart of the program implementing the Single Frequency output function.

FIG. 96 is a recasting of FIG. 20 in view of the circuit details presented for the source generator.

FIG. 97 is a flow diagram for the SINCOS subroutine.

FIGS. 98 and 99, in combination, present the flow chart for the Sequence Multifrequency function.

FIGS. 100 through 103 are flow charts for, respectively, Convert Frequency, Zero, T-ON and T-OFF subroutines of the source generator.

FIG. 104 is a memory map for the various software routines utilized to implement the source generator of FIG. 17.

FIG. 105 combines the circuitry of FIGS. 20 and 21 which allow a full elucidation of the operation of the magnetic current sensor circuitry.

FIGS. 106 and 107 present a portion of major saturation hysteresis loop for two magnetic structures implementing a current sensor for matched and mismatched conditions, respectively.

FIG. 108 is a diagram indicating the sequence of operations, as well as their relative timing, for generating a pair of data samples in the measurement processor of FIG. 11.

FIG. 109 depicts circuitry implementing a programmable gain amplifier for autoranging during a measurement cycle.

FIG. 110 is a block diagram of the digital signal processor depicted with reference to the PMU circuitry of FIG. 58.

FIGS. 111 through 114 are schematics of the different subcomponents comprising the digital signal processor of FIG. 110 and they indicate, respectively: random access memory and read-only memory implementations; the dual-port RAM and demultiplexing circuitry to interface the PMU controller to the programmable signal processor of FIGS. 112 and 114; and address decoding circuitry.

FIG. 115 shows the architectural arrangement for the special purpose signal processor implementing the down-loaded signal processing techniques.

FIG. 116 illustrates the boundary alignment for the various registers and busses comprising processor of FIG. 115.

FIGS. 117, 118 and 119 depict the flow diagram of a program for digital filtering DC signals and thereby determine the settled DC values for one to six synchronously demodulated channels.

FIGS. 120 through 123 depict the flow diagram of a program for analyzing coil phone tone bursts in order to test a coin totalizer.

DETAILED DESCRIPTION

1. The Mechanized Loop Testing (MLT) Architecture

The overriding architectural consideration employed in the MLT system is to distribute the access, test and communication functions as closely as possible to the point of testing, which generally is the centralized switching facility serving the subscriber loops to be tested. The deployment of such a distributed architecture minimizes data flow in the system, increases testing accuracy and expands test capabilities.

To place in perspective the description that follows, FIG. 1 illustrates, in overlay fashion, one arrangement for integrating the distributed MLT system within the framework of the ARSB system discussed in the Background Section. In this depiction, it is clear that one embodiment of the MLT system serves as an adjunct to the testing system described earlier. However, the illustrative embodiment of the present invention is best elucidated as a stand-alone system and this arrangement is shown in FIG. 2.

FIG. 2 depicts, in overview fashion, a block diagram of an illustrative embodiment of the MLT architecture arranged in accordance with the present invention. Data storage computer 200 stores information about each subscriber loop existing in the area to be served by the MLT system. For instance, typical types of information accessible in computer 200 include the composition of the subscriber loop, office equipment, outside plant equipment and terminating equipment associated with each loop.

The area served by a MLT system generally encompasses a number of geographically-dispersed wire centers 150 and 151 containing switching machines 170 and 171, respectively. Individual subscriber loops 180, . . . , 183, with associated customer equipment 190, . . . , 193, respectively, are served by wire centers 150,151 and connect to switching machines 170,171. Each wire center 150 or 151 served by the MLT system contains a collocated microprocessor-based Loop Testing System (LTS), 160 or 161, respectively, that also implements access, test and communication capabilities (shown pictorially as components of each LTS 160 or 161 in FIG. 2). The access portion of each LTS 160,161 is arranged with circuitry for establishing a transmission connection, under control of FE computers 220,221, over the national dial network, that is, the Direct Distance Dialing (DDD) network, via facilities 932 and 933 emanating from wire centers 150 and 151, respectively. Switching machines 170, 171 are accessible from LTS 160,161 via test trunks 940,941, respectively.

Front-end (FE) computers 220,221 interact with storage computer 200 to retrieve pertinent data regarding subscriber loops to be tested. Since FE computers 220 and 221 are not necessarily collocated with computer 200, data links 900 and 901, respectively, are provided for intercomputer communication. Direct communication between FE computers 220,221 is accomplished via Parallel Communication Link (PCL) 210 and interposed busses 910,911, respectively.

The communication functions that reside in each LTS 160,161 and in each FE computer 220,221 are coupled via Data Communication Network (DCN) 140. DCN 140 allows any one of FE computers 220,221 to communicate with any LTS 160,161 in any wire center 150,151 served by the MLT system. DCN 140 is also a microprocessor-based distributed processing machine that offloads communication processing for all FE computers 220,221.

The architecture depicted in FIG. 2 allows any FE computer 220,221 to test any customer loop 180, . . . , 183 within the area served by the MLT system. To demonstrate this, the following describes, again in overview fashion, the operation of the illustrative embodiment of the MLT system.

A loop test is typically generated by a request from repair service bureau personnel, typically a maintenance administrator. This user has a console 230,231 with an input/output device, e.g., a keyboard and cathoderay tube (CRT), for interfacing to a FE computer 220,221 via data links 912,913, respectively; the console also includes circuitry 235,236 for communicating over the DDD network via conventional facilities 914 and 915. Several types of CRT masks are available to enable the user to input data (e.g., a telephone number to be tested) and receive output (e.g., test results) from the MLT system. When the user determines a subscriber loop is to be tested, an MLT program resident on FE computer 220 or 221 requests that certain data base information be retrieved from storage computer 200 relating to the characteristics of a loop 180, . . . , or 183 to be tested. This information is utilized by an application process resident on FE computer 220 or 221 that initiates accessing of the loop and then guides loop testing. The application process may contain, for instance, an adaptive loop testing algorithm or it may contain commands to implement interactive test control and other functions similar to that performed with manual testing.

Because of the processing capability available in the microcomputers of LTS 160,161, only high level commands are generated by FE computers 220,221. The first command requests LTS 160 or 161 to access a specified telephone number and, if interactive testing is required, the command also provides the telephone number of the circuitry at the user's console so a callback path may be established. The message compiled by the appropriate FE computer 220 or 221 to implement the command and transmitted over outgoing data line 920 or 921 contains a message field having a parameter that identifies which LTS data link 930 or 931 is to be utilized for intercomputer communication. Any message, including the first one, is routed from FE computer 220 or 221 to DCN 140 via incoming data links 920 or 921 and, after appropriate parsing and reassembly of the message, from DCN 140 to the preselected LTS 160 or 161 via outgoing data link 930 or 931. When access is completed, the response is rerouted through data link 930 or 931, DCN 140 and data link 920 or 921 to the FE computer 220 or 221 that requested the access. Subsequent message transactions that occur between FE computer 220 or 221 and LTS 160 or 161 involve high level requests for tests to be performed, followed by detailed responses containing raw test data (e.g., the amount of current that was measured on loop wires 180, . . . or 183 when a particular source was applied to the loop by LTS 160 or 161). These transactions may be prefaced with oral communications between the maintenance administrator at console 230,231 and the customer serviced by the loop or field craft personnel at a location along the loop. These communications are transacted over DDD callback path and are generally utilized in the interactive test mode to establish appropriate conditions on the loop for test purposes. For example, a craftperson may be requested to short the loop so a DC resistance measurement may be effected. The last request made by FE computer 220 or 221 is to have LTS 160 or 161 disconnect from loop 180, . . . or 183 under test. The number of loops that may be accessed simultaneously at any LTS site and the number of simultaneous tests that may be in progress at a given LTS are discussed in the sequel.

The above overview shows the basic design philosophy of the MLT system and illustrates one distributed processing approach to loop testing. Hardware and software functions are partitioned so that system complexity is reduced to the point where basically independently designed and maintained modules interact via high level commands. The following section describes the individual modules or components of the MLT system in somewhat more detail, but basically still in overview fashion, from both a hardware and software perspective. After this, another pass through each component will complete the detailed description.

2. MLT Implementation

2.1 Data Communication Network (DCN)

2.1a Structure

As indicated in FIG. 2 and alluded to in the foregoing discussion, DCN 140 is structured to route messages between any FE computer 220,221 and any LTS 160,161. The illustrative embodiment of DCN 140 to be described allows from one to twelve FE computers to exchange data with up to seven hundred and sixty eight (768) Loop Testing Systems. (This capacity is determined by anticipated user needs; the total capacity of the architecture of DCN 140, without bus extenders, is actually 1568 data links or, equivalently 1568 Loop Testing Systems.)

FIG. 3 shows a three-tiered multiprocessor realization of DCN 140. Tier 1 serial-in, parallel-out devices 1401, . . . , 1412 are arranged to accept incoming data links 9201, . . . , 9224 on a two data link-per-device basis. For instance, device 1401 in tier 1 interconnects to data links 9201 and 9202. Incoming data links 9201, . . . , 9224 originate from FE computers 220,221 of FIG. 2. In fact, internal data link 9201 is the same link identified as external data link 920, as depicted in FIG. 3. A similar identification may be made between links 921 and 9224.

Tier 3 parallel-in, serial-out processing circuits 14001, . . . , 14096 are arranged to provide outgoing data links 93001, . . . , 93768 on an eight data links-per-circuit basis. Outgoing data links 93001, . . . , 93768 terminate on LTS's 160,161 of FIG. 2. In fact, internal data link 93001 is the same link identified as external link 930, as depicted in FIG. 3. A similar identification may be made between links 931 and 93768.

Tier 2 parallel-in, parallel-out processing interfaces 1421, . . . , 1468 serve to interconnect first tier devices 1401, . . . , 1412 and third tier circuits 14001, . . . , 14096 by means of connecting arrays 141, . . . , 144 and connection matrix 145, shown in block form in FIG. 3. FIG. 4 depicts the actual arrangement of arrays 141, . . . , 144 and matrix 145.

With reference to FIG. 4, array 141 (arrays 142, 143 and 144 are substantially the same as array 141) comprises three similar, but independent busses 14121, 14122 and 14123. Each of these busses 14121, 14122, 14123 implements, in the preferred embodiment, the General Purpose Interface Bus (GPIB) protocol. This protocol is defined in IEEE Standard 488-1978 "Digital Interface for Programmable Instrumentation," a well-known standard in the art of digital communication. Matrix 145, comprising forty-eight similar, but independent busses 145501, 145502, . . . , 145548, also utilizes the GPIB protocol. The interconnections of the various busses are arranged to provide modularity and fail-soft operation of DCN 140, as now explained.

The twelve tier 1 devices 1401, . . . , 1412 of FIG. 3 are partitioned into groups of three devices-per-group. For instance, the first group contains devices 1401, 1402 and 1403. The circuit elements representing these devices have been labeled `1`, `2`, and `3`, respectively, within the pictorial representation of each element. Thus, device 1401 has been designated with a `1`, device 1402 with a `2` and so forth. The numbers below `1`, `2` and `3` in each pictorial representation, that is, `0`, `1` and `2`, are indicative of the logical addresses to be associated with the actual element numbers. These logical designations will be utilized to describe information flow through DCN 140. With the above terminology, it is clear that the second group of devices contains devices 1404, 1405 and 1406; these are actually the fourth (`4`), fifth (`5`) and sixth (`6`) devices having logical designations `0`, `1` and `2`. Any actual designation (A.sub.1) can be converted to a logical designation (L.sub.1) via the relation L.sub.1 =mod (A.sub.1 -1, 3).

In the arrangement of FIG. 3, there are four groups of devices. The devices in each group serve as inputs to a corresponding connecting array 141, . . . , or 144. For instance, devices 1401, 1402 and 1403 of the first group are associated with array 141. Each device in tier 1 controls a unique means for transmitting information to and from its associated connecting array. For example, device 1401 controls transmission means 14101, which typically implements the GPIB protocol.

Up to twelve tier 2 interfaces may be added per tier 1 group, and this maximum is shown in FIG. 3. Since there are four groups and twelve interfaces per group, a total of forty-eight interfaces are present in the architecture of FIG. 3. These interfaces are designated 1421, 1422, . . . , 1468 and correspond to actual interfaces `1` through `48`, respectively. Actual interface designations (A.sub.2) also have logical designations (L.sub.2) `0` through `11` determined by the relation L.sub.2 =mod (A.sub.2 -1, 12).

Each tier 2 interface has three input busses and generates an independent output bus. For instance, interface 1421 is served by busses 14104, 14105 and 14106 and controls bus 14501 on its output. The protocol on these busses is typically the GPIB. The input busses originate from one of the connecting arrays 141, . . . , 144 and the output bus terminates on connection matrix 145.

With the above description, the interconnection provided by arrays 141, . . . , 144 may be described according to the following tables.

                  TABLE I
    ______________________________________
    Array 141
    Bus         Connects to busses
    ______________________________________
    14101       14104, 14107, 14110
    14102       14105, 14108, 14111
    14103       14106, 14109, 14112
    ______________________________________


              TABLE II
    ______________________________________
    Array 142
    Bus         Connects to busses
    ______________________________________
    14201       14204, 14207, 14210
    14202       14205, 14208, 14211
    14203       14206, 14209, 14212
    ______________________________________


              TABLE III
    ______________________________________
    Array 143
    Bus         Connects to busses
    ______________________________________
    14301       14304, 14307, 14310
    14302       14305, 14308, 14311
    14303       14306, 14309, 14312
    ______________________________________


              TABLE IV
    ______________________________________
    Array 144
    Bus         Connects to busses
    ______________________________________
    14401       14404, 14407, 14410
    14402       14405, 14408, 14411
    14403       14406, 14409, 14412
    ______________________________________

    ______________________________________
    bit    15      14     13    12   11    10   9    8
    position
    value  0       0      0     0    0     0    0    0
    bit    7       6      5     4    3     2    1    0
    position
    value  0       1      1     1    1     0    0     0.
    ______________________________________

    ______________________________________
    bit      7     6       5   4     3   2     1   0
    position
    value    --    --      0   1     0   0     1    1.
    ______________________________________

    ______________________________________
    (i)      Routing Algorithm for Task 0 and Task 1:
             if (`down --circuit --type` = DCN --1){
             pass message to local ADMINISTRATION
             task;
             }
             else { destination = bits 6, 7, 8 and 9
             of `down --route`;
             set `up --route` bits 4 and 5;
             pass message to PARALLEL OUTPUT
             task;
             }
    (ii)     Routing Algorithm for Task 2:
             if (`up --circuit --type` = DCN --1){
             pass message to local ADMINISTRATION
             task;
             }
             else { if (`up --route` bits 4, 5 = 00 {
             pass message to SERIAL DATA 0;
               }
             else { pass message to SERIAL
             DATA 1;
               }
             }
    ______________________________________