ARONTS Instruction Manual

This section describes the purpose of originating calls remotely to test a network, and the features of the Automated Remote Origination Network Test System (ARONTS).

1.1 How to Use This Manual

All users of the test system should read sections 1, 2, 3, 4, and 5. These sections describe the overall test process. The program menus are self-explanatory. Section 6 covers the use of these options and should be read if any difficulty arises in using the programs, or if the screen explanations are not found to be comprehensive enough for the individual operator. Advanced users who wish to customize the test system for differing dialing patterns and construct new tests should refer to section 7. System administrators who need to use the Control Computer for other purposes, change the Control Computer to another, or reinitialize the system software must read section 8. Section 9 gives a detailed description of the test system internals.

1.2 The Purpose of Remote Origination Testing

Conventional network testing is conducted by placing test calls from a centralized test point to all terminating points. This method is well suited to parametric tests. Connectivity assessments are made by checking that test calls reach the intended termination. One-way access circuits place an insurmountable obstacle in front of centralized test call origination for the purpose of connectivity checks. This can be viewed from the perspective of the local telephone company, and from the viewpoint of the long-haul carrier. In either application, it is also desirable to be able to independently make test calls and verify billing output from the associated switching system: ARONTS provides this ability.

Local Telephone Company

The local operating company (Telco) accepts dialed digits from its subscribers on the line-side of its Central Office (CO) switches, makes decisions regarding the type of call, and routes the customer to an error message, another local subscriber, or out of the Telco's network into one of many long distance carriers through the trunk side of the CO. This process is referred to as translation. The complex decision tree can only be tested (independently from the CO internal diagnostics) by originating calls from the line side of the CO. Conventionally, dedicated foreign exchange (FX) lines are brought from every CO to a centralized testing location, permitting call origination equivalent to that of subscribers located in the CO's exchange.

The quantity of FX lines increases if various classes of service are to be tested. Single party, coin, presubscriptions to different long distance carriers, and other distinguishing characteristics makes it impractical to actually test each of the possibilities by transporting one of each of these line types to a centralized point by FX circuit.

Complicating the test situation is the fact that the telecommunications networks presently possess a much richer selection of service offerings than traditionally available in the industry, by orders of magnitude. Translations are handled by complex software systems -- it is well known that side effects are not at all uncommon in such sophisticated computers. A change can be made in one portion of the call handling process, and some feature not believed to be at all related to the change may be affected. Massive outages have recently occurred in the networks of very large carriers; these are characterized by the increasing difficulty of even tracking down what the circumstances were that led to the difficulty. The inevitable movement of complex software systems into the telephone network brings with its mixture of new options and call handling abilities a growing need to test and monitor the systems, particularly when a new software revision is loaded.

Older analog CO's not controlled through complex software, while limited in ability to add service enhancements, at least remain consistent once the installation is proved out. Many of these offices have been replaced with modern digital CO's; the rest will eventually disappear. As more CO's are modernized, the quantity of cutovers to software upgrades and improvements, which is a continuous process, grows as well.

ARONTS is a tool to create automated scripts of test calls for translation verification. It is a centralized test system which accesses remote points in order to originate calls into the line side of the CO under test. Once a test script is prepared for each CO location, the same test run can be executed with a minimal amount of manual labor-- and should be done every time a new software load is installed in the CO.

Long Distance Carrier

From the interexchange carrier's (IXC) perspective, connectivity testing falls into two categories: access via the Telco; and network routing. The subscriber places a call through his Telco; it is the Telco's responsibility to send the call to the IXC. If this access is not performed properly, every participant suffers: the subscriber's call does not go through; the Telco does not collect access charges from the IXC; and the IXC receives no revenue for the aborted call. The direct economic loss, while difficult to quantify, is definite; and the indirect economic loss which results from the customer's loss of confidence and good faith regarding the IXC is of serious concern. It can prove devastating in an arena where the customer is constantly bombarded with high-powered advertising from many carriers aimed at capturing subscribers from competitors; and while it may be intellectually ironic that a subscriber "switches" to another IXC because the Telco made a mistake and did not route the call correctly, the effect is the same as if the IXC had caused the problem.

An example of this is 800 service offerings. The end user makes an 800 call through his local operating company. The Telco translates the called number by its exchange and determines which IXC is to handle the call. The Telco then routes the call to the IXC's point of presence (POP) within the Local Access and Transport Area (LATA). There is no independent means to test this translation by the Telco; calls must actually be placed within the area where the Telco makes the IXC determination to verify the proper translation-- generally at the Access Tandem.

Should the Telco route the call to the proper IXC, the call may still be blocked due to lack of available lines within the trunk group connecting the IXC to the Access Tandem. This is a dynamic problem which is only evident during periods of heavy traffic.

Call failures are particularly devastating for 800 service. Many 800 callers are responding to advertising and may call on a whim. Should the call not go through, the caller may simply forget about the call, and the advertiser (the IXC's customer) never receives either the call or a complaint. The whole purpose of the service is to make it as easy as possible to place a call, removing all pressure from the caller. Other more persistent callers may wish to place another call directly to the customer, but don't know the non-800 telephone number, and cannot. In both cases, the customer may never know about the loss of calls, and therefore not make a complaint to the IXC, making it impossible to resolve the problem. Additionally, 800 service is partitioned by each Telco to determine the proper IXC; and the determination is made by the called number rather than the calling number (ANI) which is used for extraction of presubscriber information. Since only 800 calls (and only some of those) are affected by this type of translation error, the end user is less likely to observe the problem and notify his Telco.

Independent from the problem of verifying access to the IXC's network from the Telco is the need to verify the IXC's internal routing and call connection times. Centralized testing from a single point of origin can exercise all points of a network between that point and any reachable terminating point. Generally, once a network is accessed, any terminating location can be reached with the suitable selection of a telephone number. If, for example, a network consists of a star configuration, where all calls are passed to a central switch and routed from that terminus, it is possible to test all outgoing circuits connected to the switch. If the circuits are all truly two-way in nature, testing a set of lines in the outbound direction can provide some degree of functional testing of the inbound calls.

Distributed switching networks pose a more difficult testing situation. Calls are transferred between switching centers dynamically, and the actual path traversed by a single call depends upon the call's point of origin. It is possible to embed special routing codes into particular test numbers which force fixed routes to be taken. Depending upon how accurately these forced calls emulate actual call switching based on real traffic distribution, test results may or may not be reliable estimators of network statistics.

For the reasons of one-way circuits from the Telco, distributed routing, and questionable network emulation models, it is desirable for the IXC to be able to test its network by placing calls which originate from many different locations. ARONTS is a tool which supplies this capability, and permits testing the actual existing network under real dynamic conditions.

1.3 ARONTS Features

ARONTS is designed to assist network analysts and technicians in determining the operational state of a telephone switching system. It is intended to do the following:

Detect incorrect translation tables
Find dynamic trunk blockage
Measure call placement times

Simultaneous test calls are made on as many as 48 test center telephone lines; while these lines are the source of the test calls, the actual test number is dialed from a remote location-- the test center lines are used to reach the remote location in order to place the test call itself. Figure 1 shows the network test configuration.

Figure 1: ARONTS Network
Figure 1

Multiple originating points are used to place test calls; these points are referred to as Sites, and may be of several different types. Options are provided to create a site database and define the operational parameters for each site individually. Existing data files can be imported into ARONTS' database.

A set of Test Numbers and Dialing Registers are used to test the network. These telephone numbers terminate in 1004 Hz milliwatt test tones. Each number is handled in a different manner by the network system routing, and in general they terminate in different end offices. Successful calls traverse the network and return the milliwatt tone. All dialing patterns can be accommodated, including international calling, calling card 0+ calls, dial-up services, and reoriginated calls.

The time between the dialing of the last digit of the test number and the detection of the milliwatt tone is measured for each test call to determine the call placement time. These calls are recorded to permit the extraction of Wait Time averages and standard deviations. The Wait Time average is used for comparison against network design goals, and the standard deviation is used as a measure of call placement consistencies.

Test call results are categorized as: Milliwatt (successful); SIT; DTMF; Busy; Reorder; Ring; Voice; and Timed Out. SIT tones are Special Information Tones which generally precede taped messages. These are sent by the Telco for situations such as incorrect dialing or blocked trunks. Some IXC's also generate these tones for network blockage. Call rejection DTMF tones sent by the IXC due to network blockage or other errors are captured and used to segregate the calls blocked by the network.

A schedule is used to control testing. A Telco or IXC switch can be routined with this list of defined test calls, or continuous testing via time scheduling (Operation Tables) intended to search for trunk blockages and measure network statistics can be done.

A monitor speaker and front panel selector switch allow the user to monitor the calls in progress, with related screen displays. Specific tests can be ordered by the system operator on demand, amidst the scheduled tests. Provision is made for manually assisted test calls. An external telephone is used to monitor the test call, which ARONTS places automatically; the disposition of

the test is determined by the human operator, who enters a DTMF result code for the test. ARONTS logs the call without the necessity of manual paper shuffling. These test calls are generally used to verify that the correct carrier's Operator (0-, 00-)-- or Information (411) and Repair (611) services-- are properly reached. The number of simultaneous manually assisted calls can be as many as the number of ARONTS ports.

The system may also be used with direct connection to a CO or IXC switch via loop or ground start (optional) interfaces on the line side, or loop reverse battery interface (optional) to the trunk side of the switch. This last option permits testing with trunk protocols: wink signaling and MF tone generation, for testing Feature Group D access circuits.

The test system creates a variety of statistical reports. Report outputs can be imported into graphical packages for presentation. Often-used reports are easily made into custom canned reports, accessible with a single keystroke. A Failure Log records call detail on every failed (or, if requested, successful) call, including the precise DTMF or SIT tone sequence received and the connect (or failure) time. A user defined output file can be created containing test call detail for use in billing comparison, or import into spreadsheet or database packages for custom analysis.

ARONTS may be accessed for monitoring and control from a remote location via modem.

2. SYSTEM ELEMENTS

This section describes the basic hardware and software pieces which together constitute the Automated Remote Origination Network Test System.

2.1 Hardware Components

The test center consists of two hardware components: the Control Computer and the Test Module. Field locations contain Remote Test Sets described in section 3.2.

Control Computer

The Control Computer is an IBM-compatible PC. The computer is equipped with the following: a hard disk drive; a high density floppy disk drive; a parallel printer port; a serial interface on Com1; a modem on Com2; a minimum of 640k RAM; and MS-Dos.

The Control Computer handles all high-level system tasks. These include making the determination of which sites to test at a particular time; deciding which test numbers to use for each call; selection of appropriate command sequences to place different types of test calls; interfacing with the Test Module through the Com1 serial port; handling remote access of the entire system through the modem on the Com2 serial port; test result collection and logging; database creation and modification; and report generation.

Test Module

The Test Module connects with the Control Computer through a single RS-232 serial interface, and handles up to 48 telephone lines. Each test line connects to a line coupler which is in turn connected to a Tone Controller. The Tone Controller generates and detects the various required signals: DTMF, 1004 Hz, SIT, busy, reorder and ringback tones, and voice; regulates call timing parameters; and makes Wait Time measurements.

The line couplers are supervised by Coupler Controllers. These handle the on- and off-hook statuses of the lines and monitor for loss of loop current. The Test Module itself is controlled by a Master Controller. This board communicates with the Control Computer, and with the Coupler and Tone Controllers through an internal parallel communications channel.

The Test Module requires 2-wire DTMF capable loop start lines. Connection is through a standard RJ21X interface. One or two cables come out of the box terminated with 50-pin jacks. Circuit #1: tip/ring = pins 26/1; circuit #2: tip/ring = pins 27/2; etc. Circuit #25 (pins 50/25) is the line selected by the front panel switch, and may be connected to a butt set or equivalent for monitoring and manual assist testing. If more than one manual assist position is desired, the additional butt sets are paralleled with the port lines at the RJ21X connector, with a 200 2-watt resistor in series. A standard non-electronic telephone instrument can be used in place of a butt set if a 1f 400 volt nonpolarized capacitor is placed in series, with a Talk/Monitor switch shorting out the capacitor in Talk position.

Figure 2 shows a block diagram of a 12-port Test Module. See section 9 for a detailed description of the Test Module.

Figure 2: Test Module

2.2 Software Elements

The Control Computer executes a set of programs to accomplish the various required tasks. These individual programs are transparent to the user; they are automatically called when the operator selects an option from the Main Menu. All programs and data files are manipulated by the control software so that it is not necessary for the user to be acutely aware of the individual elements; nevertheless, it is helpful for the operator's general comprehension of the system to have an overall knowledge of the various software pieces.

Upon powerup or system reset ({Control} + {Alt} + {Delete} keys simultaneously depressed) the computer boots up and executes a command file initializing various parameters. The test program directory is selected and a batch file immediately executes which performs further initialization, and sends control to the Main Menu program. This menu program offers system utilities and a path to the other testing programs. When the particular program terminates, control is returned to the menu program. An option is available in that screen to permit exit to the Operating System. If this is selected, ARONTS relinquishes control of the Control Computer directly to the user. This option should only be selected by computer literate operators.

Files

There are a number of data files manipulated by the programs. The user rarely deals directly with these files through Dos.

Setup File: Setup.Dat contains all of the information controlled by the System Setup option from the Main Menu. Upon entry to the program, the entire file is read, and the user views and modifies this internal copy of the file. Upon exit, the file is updated if so selected by the user.

Site Information File: Sites.Dat contains all of the information specific to the sites other than the Notes, and is controlled by the Site Information option from the Main Menu. Information is read from and written to this file on a site-by-site basis while in the Site Information View/Modify program.

Site Notes File: Notes.Dat contains the site Notes information, and is controlled by the Site Information option from the Main Menu. Information is read from and written to this file on a site-by-site basis while in the Site Information View/Modify program.

Test Number Statistics File: ResultsT.Dat contains information regarding the number of test calls, the average Wait Time, and the standard deviation of the Wait Time for successful tests, and peg counts for each of the unsuccessful call result types, broken down by test number. The file is updated when testing, and reports are generated from it through the Test Analysis Main Menu option.

Site Statistics File: ResultsS.Dat contains information regarding the number of test calls, the average Wait Time, and the standard deviation of the Wait Time for successful tests, and peg counts for each of the unsuccessful call result types, broken down by site number. The file is updated when testing, and reports are generated from it through the Test Analysis Main Menu option.

Failure Log File: Log.Dat contains the failures (or successes and failures if requested) detected during testing. It is read (and cleared) by the Failure Log Main Menu option as well as the Test Sites program.

Test Schedule File: TestSked.Dat contains all of the information controlled by the Test Schedule option from the Main Menu. Upon entry to the program, the entire file is read, and the user views and modifies this internal copy of the file. Upon exit, the file is updated if so selected by the user.

Test Definitions File: Test_Def.Dat contains all of the Test Definition information specific to the sites, and is controlled by the Test Definitions option from the Main Menu. Information is read from and written to this file on a site-by-site basis while in the Test Definitions View/Modify program.

Test Numbers File: TestNums.Dat contains all of the test numbers, controlled by the Test Numbers option from the Main Menu. Upon entry to the program, the entire file is read, and the user views and modifies this internal copy of the file. Upon exit, the file is updated if so selected by the user.

Dialing Registers File: DialRegs.Dat contains all of the Dialing Registers, controlled by the Dialing Registers option from the Main Menu. Upon entry to the program, the entire file is read, and the user views and modifies this internal copy of the file. Upon exit, the file is updated if so selected by the user.

Module Commands File: Module.Dat contains all of the commands sent to the Test Module at the start of the Test Sites option from the Main Menu. This file is viewed and modified (not generally necessary for the user) by the Module Commands option from the Main Menu. Upon entry to the program, the entire file is read, and the user views and modifies this internal copy of the file. Upon exit, the file is updated if so selected by the user.

LEC Data File: LEC.Dat contains all of the LEC names, controlled by the LEC Names option from the Main Menu. Upon entry to the program, the entire file is read, and the user views and modifies this internal copy of the file. Upon exit, the file is updated if so selected by the user.

CO Descriptions File: CO_Desc.Dat contains all of the CO descriptions, controlled by the CO Descriptions option from the Main Menu. Upon entry to the program, the entire file is read, and the user views and modifies this internal copy of the file. Upon exit, the file is updated if so selected by the user.

State Names File: States.Dat contains all of the State names, controlled by the State/Country option from the Main Menu. Upon entry to the program, the entire file is read, and the user views and modifies this internal copy of the file. Upon exit, the file is updated if so selected by the user.

File Notes File: FileNote.Dat is the scratchpad provided by the File Maintenance option from the Main Menu.

Archive Files: TestSked.ZIP, Test_Def.ZIP, TestNums.ZIP, DialRegs.ZIP, and Module.ZIP are the compressed archives handled by the File Maintenance option from the Main Menu.

Custom Menu File: Custom.Bat is the Dos batch program file modifiable by the end user, and activated by the Custom Menu option from the Main Menu.

Canned Report Files: Any filenames selected to store keystrokes for use with the Analysis program, used by the Custom Menu option from the Main Menu.

Listing File: Printer.Txt is created by all programs when listings are requested.

Statistics Export File: D:\Report\Analyze.Txt is created by the Analysis program for export to graphics packages.

Output File: D:\Report\RawData.Txt contains user defined test call detail, and is created when testing. It is used by billing comparison programs or for export into spreadsheet or database packages for custom analysis.

Offloaded Files: Printer.Exe, Analyze.Exe, and RawData.Exe are self-extracting files placed in the directory \Aronts on floppy disks for transfer to other computers.

Resume File: Resume.Dat is created upon exit from testing, and read upon entry to testing when the Resume Testing option is selected from the Main Menu.

Program Files: *.Exe and *.Bat filenames.

File Handling While Testing

The Test Lines Main Menu option selects the testing program. Upon startup, various data files are read into memory. The Failure Log and RawData Output files are appended on a call-by-call basis. The files are not closed until the program terminates, so should power be turned off in the middle of the tester program, it is possible that the last records of these files would not have been written. For this reason, the program should always be exited by menu option.

The Results files are updated in different ways at differing times. Upon releasing a Site, the updated results totals for that Site are written to the ResultsS file. The updated results by test number are written whenever one of two conditions is met: a maximum number of test calls (nominally 500) have produced results; or a maximum period of time (nominally 1 hour) has elapsed. The results are written to ResultsT for every test number at that time. Should the power be turned off in the middle of the program, the results by site number are accurate up to the tests performed from the sites currently active on the system; and the results by test numbers are accurate up to the last time that update was performed. The data should be self-consistent as long as the power was not lost during the precise instant when the file was being written.

3. TEST CALL PLACEMENT

This section describes the logical progression ARONTS uses to place test calls. The selection of control files, order of accessing sites, and individual test call handling are discussed. The purpose of this section is to detail the parameters and related decisions which lead to the determination of how and when calls are made. File data structures relevant to these decisions are identified. The usage of actual program menus to implement these processes is discussed in section 6, and specific test construction is addressed in section 7.

3.1 File Versions

ARONTS always uses the current version of each data file (with the one exception of the Test Definition option, discussed in section 3.3). All current file versions have a Dos filename extension of DAT. The Test Schedule, Test Definitions, Test Numbers, Dialing Registers, and Module Commands (current) files can be archived with version numbers. Previously created files stored in the archives can be retrieved and made current. The above five files can be used in any combination of version numbers. Once the selected archived files are made current, the version numbers are transparent to all decisions (with the one exception noted above). The other files contain information which are not test dependent-- the data is related to the current status of locations and equipment, which should constantly be kept updated.

3.2 Sites

The test call origin points are referred to as Sites. In general, ARONTS first accesses a remote site, and then places a test call from that point of origin. Tests may also be conducted directly from the ARONTS telephone lines: in this case, the ARONTS location is designated to be a site as well. Each Site has the following parameters specified: Site Number, Master Site Number, Local Exchange Carrier, Zone, Access Number, Access Register, Central Office Type, Site Type, Notes, Status, Shared Status, Conforming Status, State, LATA, Site CLLI, Tandem CLLI, and Originating Number(s). If the Site Type is RTS-1, the additional parameters of Test Code, Program Code, and 8- or 16-line units are present. If the Site Type is Coded Hot Shoe, the additional parameters of Access Code and Authorization Code are present.

The Site Number is assigned for reference purposes. It ranges from the value 1 to a maximum number of sites the software has been configured for, nominally 500. The files can be configured for a maximum of 25,000 sites. It is recommended that this configuration be kept to a maximum which is reasonably expected to be needed, as it keeps the file sizes down and increases system speed. The files can be expanded to handle a larger number of sites should this become necessary. When configured at the maximum of 25,000 sites, approximately 11 megabytes of disk storage is used for the ARONTS program and data files.

The Master Site Number provides a means to group sites together which are accessed from the same point, or cannot be accessed simultaneously for any reason. ARONTS does not access more than one member of a Master Site group at a time. The Master Site Number can be any number within the range of valid site numbers, but normally is the actual Site Number of one of the sites in that group. For example, if Site Numbers 10-15 are in a single group, they each could be assigned Master Site Numbers of 10, indicating the first site in the Master Site group.

The Local Exchange Carrier (LEC) designates the telephone operating company covering the site location. Up to 9,999 LECs can be used, but an option is provided to reduce the maximum LEC number for speedier operation. This number can be changed by the user at any time without file reconfiguration.

The Zone can be used as a time zone, or a way to group sites for testing during different time periods. Options are provided to designate testing of sites within a specified time zone during each hour of the day. This is intended to be used to facilitate busy hour testing, permitting East, Central, Mountain, and Pacific time zone sites to be scanned during their respective peak traffic periods.

The Access Number is the telephone number used to reach the site. This is a bare telephone number, without any leading 1's or other dialing pattern dependent digits. This number can be either a domestic or an international type. Domestic telephone numbers are always 10-digits in length, and are separated into area code, exchange, and station fields for display. International numbers are from 1- to 12-digits in length, and are separated into two groups of 2-digits and one trailing group of 8-digits for display. These groupings have no purpose other than visual display clarity-- no ARONTS decisions are based upon the digit separators.

The Access Register is a Dialing Register (section 3.5) which contains information as to how to dial the Access Number from the ARONTS location. It contains information such as wait for dialtone, dial 1 + 10-digits, or simply 7-digits for locally accessible sites, and trailing commands necessary to become authorized to use the site for call origination.

The Central Office Type designates the type of switching system used in the CO. It may include information regarding software revision versions, as well as whether it is a digital or analog switch, etc. The purpose of this field is to permit a simple command to be given to test all sites subtending CO's of a particular type and software revision, without the necessity of manually compiling a list of such locations.

The Conforming Status is either Conforming or NonConforming. This field further describes information which, while deducible from the CO Type, makes it simpler to be able to test all conforming or nonconforming CO's without manually determining which CO types conform to Equal Access and which do not.

The Status is either Activated or Deactivated, and is used to enable or disable testing from the site. The State field is a 2-character field used to designate the state, province, or country of the remote site; the LATA field contains the Local Access and Transport Area number of the site; and the Site and Tandem CLLI fields contain an 11-character CLLI code.

Notes provides four 50-character lines of text which can be used for any purpose desired. Information such as contact people, office numbers, addresses, etc. can be placed into this area for reference purpose. ARONTS does not use this text for any decisions.

The Shared Status is either Shared or UnShared. RTS-1 sites can share incoming and outgoing lines with other systems (such as a PBX or a key telephone system). If the incoming access line is shared, the RTS-1 must be programmed to answer after several rings to permit the other equipment to answer first during business hours. It is therefore necessary to skip these sites for testing during business hours (and cannot be used for busy hour testing). Setting these locations to Shared permits these sites to be skipped during specified hours. Primarily intended for RTS-1 sites, this field can be used for Hot Shoe sites as well.

The Originating Number(s) is/are the ANI of the actual outgoing lines at the remote sites used to originate test calls. RTS-1 sites provide multiple outgoing lines per site, while Hot Shoe sites provide a single outgoing line. This field is used for two purposes: ARONTS can be set to access sites with a given area code (and exchange) of originating lines; and the complete originating number can be recorded in files used to compare test calls against billing records pulled from the CO switch, which contain the ANI of the outgoing test line.

The Site Type is either RTS-1, Hot Shoe, or Coded Hot Shoe.

RTS-1 Sites

MetroTel's Remote Test Set, model RTS-1, is used at remote locations to permit call origination using standard telephone lines. Two or more lines are required. To access the set, one of the lines is dialed; the RTS-1 answers the call and accepts a test or program code. It provides a method to place a test call remotely with regeneration of DTMF digits at the remote site: after accessing, ARONTS commands the RTS-1 to place the call; the RTS-1 seizes an outgoing line, waits for dialtone, and redials the requested test number.

To knock the call down, ARONTS sends an appropriate code; the RTS-1 hangs up the outgoing line and waits for another command from ARONTS. In this fashion, ARONTS can choose to make as many test calls as desired once the remote RTS-1 has been accessed. The unit also provides a timeout option should the call not terminate as expected.

Remote Test Sets may be of any size (up to 56 test lines), and equipped with firmware version 2.1 to permit automated access of the part. Each Site Number can accommodate two modules (16 lines); sites with more lines than this are broken down into several Site Numbers, all with the same Master Site Number. If every line connected to the RTS-1 is required for use as an outgoing test line (there is no dedicated access line), more than one Site Number is assigned to the unit (with the same Master Site Number). This permits two different access numbers to be used to call the box, so that every line connected can be used to place test calls.

The Test and Program Codes assigned to the RTS-1's are entered into these ARONTS site fields. The site can be designated as a 1- or 2-module RTS-1 (8- or 16-lines).

RTS-1 sites provide greater capability through faster testing and local regeneration of DTMF tones. The units keep track internally of several peg counts, and ARONTS reads this information upon access.

Simple Hot Shoe Sites

A Simple Hot Shoe site is a location which provides a new dialtone after answering a standard telephone call. This second dialtone can be used to place calls. Naturally, these sites must be restricted in some fashion so that test or 800 (or at least non-toll) numbers only can be reached to prevent unauthorized abuse.

The protocol used to place test calls from these locations is to dial the access number, wait for a dialtone, and dial the test number. To disconnect the call, the originating line from the test center must be released. To place additional test calls the entire process is repeated.

Coded Hot Shoe Sites

A Coded Hot Shoe site is a location within the access tandem which provides a new dialtone after answering a standard telephone call, and is further protected by an Authorization Code and an Access Code. The Authorization Code is used to provide security, and the Access Code is used to select an end office connected to the tandem for test call origination.

The protocol used to place test calls from these locations is to dial the access number, wait for a dialtone, enter the Authorization Code, wait for dialtone, dial the Access Code, and dial the test number. To disconnect the call, the originating line from the test center must be released. To place additional test calls the entire process is repeated.

3.3 Test Schedule

The current Test Schedule specifies which sites are to be accessed for testing, how ARONTS ports are partitioned, which Test Definitions version is to be used (section 3.6), and the mode of testing to be used (routining or operation tables).

Partitions

ARONTS ports may be grouped into up to four different Partitions. While testing is being performed, each partition operates according to its own particular setting. For each partition, the Test Schedule defines: the ports belonging to each partition; the set of sites to be accessed; a Test Definitions file version to be used; and whether Routining or Operation Tables are to be utilized.

The sites to be tested can be specified by combinations of restrictions made on the fields in the Site file (section 3.2). This can be as simple as: test all Activated sites; test sites 3, 10, and 12; test all Conforming CO's; or test all sites in LATA 123-- or it may a complex requirement such as: test all sites in the range of 400-900 which are in territory served by LEC's 23, 87, or 234, and have originating NPA/NXX's of (301)/363, (410)/833, (312)/xxx, (408)/946, or (913)/791, are served by DMS-100, Step by Step, or Crossbar CO switches, are in Maryland, Kansas, California, Illinois, or Missouri, are in LATA's 45, 87, or 233, have Site CLLI codes which match BALxxxxxxxx or SANFxxxxxxx, have Tandem CLLI codes which match other masks, and are RTS-1 locations which are not shared. This example may have no actual matches; only a few of the field specifications are generally used at one time.

Routining

If Operation Tables are not specified for use within a partition, that partition operates in a Routining mode. In this mode, a set of tests is performed on a given set of sites, and it is deemed important for each of those tests to be executed until some type of result is obtained. This mode is useful for translation testing of new CO switches, switches upgraded with software revisions, or validation of billing, as several examples. When Routining (a CO, tandem, or IXC switch), the number of Repetitions for each test may also be specified (for that partition). Specifying more than one repetition is helpful when analyzing the test log: if a test fails once, but works other times, the problem may lie in trunking overload, alternate route choices, weak tone generator/detector common equipment, or other variable quantities. If the same test fails on every occurrence, the problem is most likely a static translation error (or an unsuitable test). Tests are not repeated until every test has been conducted on all selected sites for the prior repetition-- the repeated tests are spread out over a greater length of time than if they were repeated before going on to other tests.

Operation Tables

A partition can be set up to use Operation Tables instead of Routining. The purpose of this mode is primarily to scan a group of sites for dynamic connection problems. Inadvertent translation errors, trunk blockage, and alternate route selection errors can be detected in this manner. This mode of operation can also be used to gather averages on end-to-end connection times under actual, not simulated or modeled, conditions. These results are viewed more from a statistical point of view than an individual test basis, although any existing translation errors are certainly detected if they are exercised. Busy hour testing is most effectively performed in this operating mode.

Repetitions are not stated when using Operation Tables; testing is continuous. Which sites are to be accessed (of those picked for use in the partition) and how many consecutive tests are to be performed for each site changes on an hourly basis. The procedure works as follows:

The date is checked to determine if it is a holiday
If it is not a holiday, the day-of-week is checked
One of eight Operation Tables is picked: Sunday-Saturday, or Holiday
The hour of day is checked
The entry in the selected Operation Table for the current hour is used

Each entry specifies: a (time) Zone, or All Zones; whether to skip Shared sites; and the maximum number of consecutive tests to perform from each site. Typical usage is to perform one test during busy hour for each time Zone, in the attempt to check trunking from as many sites as possible in the limited time period, and to skip Shared sites during business hours.

When Operation Tables are being used, if a site is unavailable, or a test cannot be performed (because of a collision with other tests simultaneously being conducted on other ARONTS ports), these tests and sites are simply skipped. However, the sites selected are accessed in a cyclical manner, so that site repetitions do not occur until all other selected sites have been tried. Similarly, the tests defined for a particular site are handled cyclically, so that each time a site is accessed, the specified number of tests performed begin at the test after the last one conducted in the most recent access of that site.

One partition can be conducting Busy Hour testing with Operation Tables while another partition is handling Routining for static translation verification, with the same or different sets of sites. The types of tests to be performed may be different, so it is possible to specify a Test Definitions version number for each partition (each partition may have a different set of tests to perform, even for the same sites).

3.4 Test Numbers

Once a site has been accessed, a test is conducted by placing a call to a Test Number. These numbers are defined in a Test Number file, which contains bare telephone numbers, without any leading 1's or other dialing pattern dependent digits. The numbers can be of either domestic or international types. Domestic telephone numbers are always 10-digits in length, and are separated into area code, exchange, and station fields for display. International numbers are from 1- to 12-digits in length, and are separated into two groups of 2-digits and one trailing group of 8-digits for display. These groupings have no purpose other than visual display clarity-- no ARONTS decisions are based upon the digit separators. Up to 3,000 Test Numbers can be defined per version of the Test Number file, and are referenced by numbers in the range of 1-3,000.

Most telephone numbers specify a single circuit termination, making it impossible to place more than one simultaneous call to the same number. ARONTS keeps track of the numbers in use on all ports, so that a Test Number in use on one port for one site causes that Test Number to be excluded from use on other ports and sites. Test Numbers which can have multiple simultaneous usage (and therefore terminate to a trunk group), such as 411 or trunked milliwatt circuits, can be marked as such. Test Numbers marked as Multiple are not excluded from simultaneous access on more than one ARONTS port.

3.5 Dialing Registers

Structures which state the dialing pattern used to place a telephone call with a given telephone number are referred to as Dialing Registers. These registers contain information such as wait for dialtone, dial 1 + 10-digits for toll calls, 0 + 10-digits for credit card calls, 7-digits for local calls, and trailing commands indicating what type of response to look for (such as a milliwatt tone). They are used either to access a site or to place a test call once the remote site has been accessed. Detailed descriptions of Dialing Register contents are found in sections 7.3 and 9.4.

Dialing Registers are referred to by number, in the range 1-500. Associated with each Dialing Register are four fields: Call Code, Out Line, Expected, and Continue.

A register's Call Code is a 3-character category of the test call type. This can be used as an equivalent to the numeric AMA call codes, when matching of billing files against test call files is being done, or for any other type of post-processing analysis of test call detail output. ARONTS uses this field only for display and logging purposes.

The Out Line specifies the output line number on which the test call is being placed at the remote site. Tests made from Hot Shoe sites should have the Out Line set to 1 (there is only one line available). Tests made from RTS-1 sites should have the Out Line in the ranges of 11-18 and 21-28. The first digit refers to the RTS-1 module number and the second digit the line number on that RTS-1 module. ARONTS uses this field as a pointer to the Originating Numbers stored in the Site file to find the actual Originating Number used in each test call for display and logging purposes. This field is associated with Dialing Registers because the codes to access particular RTS-1 lines must be contained within the Dialing Register itself.

The Expected field indicates to ARONTS what type of criteria to apply to the result of the test. If set to None, the call is made without either logging the test or accumulating statistics on the test result. If the Expected field is set to RTS-1, the call is being used to set parameters on the RTS-1, and an affirmative RTS-1 acknowledgement is expected. These calls result in either a Success or DTMF output, and are logged, but do not accumulate statistics (which are intended to be used for actual test calls). If the Expected field is set to Milliwatt, the test call is supposed to reach a 1004 Hz milliwatt number, and if so, is logged as a Success. Other categories which may result are: SIT (special information tone), DTMF, Busy, Reorder, Ringing, and Voice. These results are logged and accumulated in the Statistics files (section 4.2). If the Expected field is set to Manual DTMF, the test call is supposed to be monitored by a technician/operator who listens to the test result and enters a DTMF code specifying the result of the test. A DTMF code of 000 tells ARONTS to log the test as a Success; any other code is recorded as an error with the DTMF code included in the log for reference purposes. The code can be used to differentiate between a variety of incorrect results. These calls do not accumulate statistics. (The time it takes to reach a determination is included in the log output.)

An additional category for all Expected types is that of Time Out: if this occurs on any test call, the call is logged and statistics accumulated no matter what the Expected setting. Logging and the determination of the test result are covered in section 4.1. Independent from the Expected field setting, the contents of the Dialing Register must contain the appropriate commands to accomplish the discrimination between various test termination possibilities desired.

The Continue field permits a Dialing Register to be "chained" to another Dialing Register. This can be used for two purposes: longer Dialing Registers and dependent tests. Dialing Registers are constrained to a character length of 100 digits (when expanded, section 7.3). If it is necessary to construct a Dialing Register which is longer than this limit, the first register should have its Expected field set to None and its Continue field set to the number of the Dialing Register which is being used to continue the (single) test. There is no limit to the number of linked Dialing Registers, but it is recommended that it be kept to the minimum necessary. The last register in the sequence should have its Expected field set to the desired result, with all predecessor registers set to None.

Dependent tests are tests in which it is necessary to first accomplish some action in order to reach the state where it is possible to make the desired test. An example of this is call reorigination. Typically, these calls work as follows: either a 0+ credit card call is made, or a call to an 800-number followed by an authorization code and dialed number is made. In both cases, an actual complete call is accomplished (for test purposes to a milliwatt number). While the call is in progress, a long DTMF # returns the caller to a prompt to place a subsequent telephone call, without reentering credit card or authorization numbers. In order to be able to test the reorigination feature, it is first necessary to place the original call; this is done by the first Dialing Register. That register is then Continued with another register which contains the codes to send a long DTMF # and redial the test number. In these cases, both Dialing Registers should have their Expected fields set to Milliwatt, so that the progress of the test call can be logged. If the first register's Expected field is set to None, the call proceeds the same except that the first test result is not logged.

3.6 Test Definitions

The Test Schedule specifies which sites are to be accessed for testing. The Site file contains static information regarding the site itself and how to access it. A separate file contains Test Definitions which state which Test Numbers and Dialing Registers are to be used once a site is accessed. The Test Definitions file contains a separate list of Test Numbers and Dialing Registers for each individual site. A description of the information for a single site number follows.

Five Groups of test calls are provided, numbered from 1 to 5. Each Group contains: a Dialing Register used to place the test call; the total number of Dialing Registers used to place the test calls; and a list of Test Numbers for use with those Dialing Registers.

More than one Dialing Register is used to place repetitive calls to the same Test Numbers for primarily two purposes: testing on different RTS-1 outgoing lines; and placing identical calls using different 10xxx IXC selection codes. As a first example, if there are four types of CO lines in which the list of Test Numbers should terminate properly, located on RTS-1 lines 14 through 17, and Dialing Registers 114 through 117 reflect these dialing codes, then the Test Definition specifies Dialing Register 114 with the number of tests set to 4. ARONTS starts with the stated Dialing Register. After placing calls to all listed Test Numbers with that register (in this example, 114), it advances to the next consecutive register (115) and repeats the test calls to all listed Test Numbers. In this case, the same test calls result on all four RTS-1 outgoing lines. A second example has the consecutive Dialing Registers identical except for varying 10xxx codes, so the test calls are repeated for every IXC indicated within a Dialing Register. This can be executed with either RTS-1 or Hot Shoe sites.

The list of Test Numbers used within a Group can contain up to 100 different Test Numbers, constrained to a range of 100. (In other words, the largest number minus the smallest number must be no greater than 100.) If a Test Number outside this range is required, it is put into a different Group.

If more than five Groups are required, the Continue Test Definition field is used to continue with a complete Test Definition for a different site number. This subsequent site number should be unassigned to an actual site, or it would not be possible to enter Test Definitions for that site. (Although it is possible to have versions of Test Definitions which address fewer sites with more complex, continued entries.) The Test Definition Continue field is completely separate from, and is not related to, the Dialing Register Continue field.

The Test Definitions file is the only data file which does not necessarily use the current file version. The Test Schedule for each partition specifies either the current version, or an explicit Test Definition version number. This permits different tests to be performed on identical sites on different ARONTS partitions. Each partition may be assigned to test different service offerings. Although different Test Definitions can be used on each partition, all partitions use the current versions of the other files: most notably, the Test Number and Dialing Register files. These files must contain a superset of all Test Numbers and Dialing Registers for the various Test Definitions used simultaneously.

3.7 Setup Parameters

ARONTS provides the ability to vary system wide Setup parameters. The number of ports and telephone lines connected to the hardware can be specified, along with the maximum LEC and Test Numbers (sections 3.2, 3.4). The RawData output file (section 4.4) can be turned on or off, and fields defined for that and a Report file (section 4.3). RTS-1 information collection can be enabled or disabled (section 4.2). Successful tests can be marked for logging (section 4.1). A credit card number and a secret authorization code can be entered to simplify usage within Dialing Registers (section 7.3) and keep these sensitive codes protected. Passwords can be changed as authorized ARONTS users fluctuate.

3.8 Site Access

When site testing is begun, ARONTS starts a process of finding site matches according to the specifications contained in the Test Schedule partitions. As site matches are found, they are assigned to ARONTS ports by partition, and access calls are made. Calculation of site matches continues until all site numbers have been checked.

The number of sites scheduled for Routining multiplied by the number of Repetitions specified for each respective partition is displayed (as calculated). Partitions using Operation Tables are not included, as they are continuous. The number of sites completed is updated when all defined tests for a site are finished. Only site completions for partitions for which Routining is specified are counted for display. As a result, when the completed sites reaches the scheduled sites, all Routined tests have been completed-- but partitions using Operation Tables continue testing.

If testing is stopped prior to all scheduled tests being completed, and the Resume Testing option is selected, ARONTS picks up where it left off as far as site access is concerned. All defined tests for each site accessed are performed, even if some had been completed in the previous run; but previously completed sites are not reaccessed (for that Repetition iteration).

Partitions set for Operation Tables access the first matching site past the last which was completed in previous Operation Table tests for any partition. If this next scheduled site is in use on any ARONTS port, it is simply skipped. It is also skipped if the Master Site number for the potential next site is the same as the Master Site number of any site in use on any ARONTS port.

Partitions set for Routining access the first matching site found which is not in use on any ARONTS port, and does not have the same Master Site number as any other site in use on any ARONTS port. The sites may not be accessed in numerical order because sites are inaccessible due to usage in other partitions, or identical Master Site numbers are encountered. All matching sites are completed in a partition for a particular Test Schedule Repetition iteration before those same sites are reaccessed for the next iteration. Near the end of accessing the last few sites within a partition, all ARONTS ports may not be filled for a short period of time while the last few sites are completed. When a Repetition iteration is completed, the ports in the partition are freed for new accesses.

Once a site is accessed, it remains accessed until all defined tests have been completed. Hot Shoe sites are reaccessed for every test call until all tests are finished.

ARONTS makes up to three successive attempts to access a site-- if none are successful, the failure is logged and the site is skipped.

3.9 Test Number Selection

After a site has been accessed, ARONTS makes decisions as to which Test Number/Dialing Register pairs are used to place test calls. In general, the ordering for such tests is as follows:

Test Definition

Group

Dialing Register

Test Number

Barring any collisions, this means that all listed Test Numbers for Group 1 of the first Test Definition (that of the Site Number) are used from lowest number to highest number with the Dialing Register specified for Group 1. When the last Test Number is finished, the Dialing Register is incremented (assuming that more than one is specified), and the same group of Test Numbers is used again from lowest to highest. When the last Dialing Register for the Group is completed, the next Group in the Test Definition is used in the same fashion. When the last Group is finished, the next Test Definition is used (assuming that it is continued). This process repeats until all Test Numbers are used with all specified Dialing Registers of the last Group of a Test Definition which is not continued. Tests are conducted in partitions using Operation Tables in precisely this order; whenever a Test Number not marked for Multiple use is encountered which is in use on another ARONTS port, that particular test is simply skipped.

Test selection behavior is somewhat different in partitions which are Routining. If no collisions are encountered, the ordering is as stated above. When an unavailable Test Number is encountered, it not simply skipped; instead, the first Test Number found in any Group of the current Test Definition which is available is used with its first corresponding Dialing Register. When the last Test Number in a Group is finished, the next Dialing Register for that Group is selected. The Dialing Registers have no bearing upon which Test Numbers are selected; however, the next Dialing Register in a particular Group is not used until all Test Numbers have been used for the current Dialing Register. When all Dialing Registers have been used with all Test Numbers in all Groups in a current Test Definition, the next Test Definition is fetched; operation continues identically until the last Test Definition is completed.

Routining makes it possible for no Test Numbers to be available at a certain time for a particular Site and port. Should this occur, ARONTS places that site and port into the Paused state; no tests are issued for that site until a Test Number becomes available due to being relinquished by another site and port.

RTS-1 sites remain connected to ARONTS until all defined tests have been completed. If the RTS-1 site is lost for some reason ARONTS reaccesses the site. Hot Shoe sites are reaccessed for every test call until all tests are finished. ARONTS makes up to three successive attempts to reaccess a site-- if none are successful, the failure is logged and the site is skipped.

3.10 Specific Tests

ARONTS normally places calls according to the Test Schedule. Provision is made, however, for a test to be conducted immediately by operator command. This may be desired in order to monitor a test aurally which failed in a previous automated execution; or a reported problem has supposedly been corrected and a quick verification of proper operation is wanted. Two types of Specific Tests can be made: perform one test using a specified Test Number/Dialing Register pair for a specified Site; or perform all tests defined in the current Test Definition for a specified Site. In both cases, it is first necessary to access the desired Site.

When a Specific Test is requested, ARONTS first determines if that Site is currently accessed on any port. If it is, the test in progress on that port is first completed, and then the requested Specific Test begins. If the Site is not accessed at the time, ARONTS waits for any port to become available. In order to accelerate this process, if all ports are otherwise occupied, new tests are not initiated on any ARONTS port; the first port which completes its current test releases its Site, making the port idle. The Site which was effectively dumped (gracefully) is not marked as completed (if Routining). That site will eventually be reaccessed and all tests executed (the same as if testing had been terminated and subsequently resumed). If the dumped Site's partition is using Operation Tables, no special action is taken with regard to the dumped Site.

If a single Specific Test was conducted and the Site was already active, when the Specific Test is completed the port returns to its scheduled operation. If the Site was accessed just to perform the Specific Test, it is released and the port freed for the next site access.

If a Specific Test is performed requesting all defined tests, the Test Definitions file version of the partition in which the test port is located is utilized for those tests.

If only a Specific Test is desired without other scheduled tests automatically being performed, two simple mechanisms can be used to do so: a previously created single partition Test Schedule with no matches can be retrieved (after archiving the current Test Schedule if it had been modified); or, if the last time testing was done, Operation Tables were not used, and all tests were completed, the Resume Testing option results in no automatic tests, since no scheduled tests remain. A good Test Schedule which guarantees no matches has one site entered into the Site match list, and both Activated and DeActivated set to No. This eliminates ARONTS' searching all available sites for matches; only the one site entered is checked (and not matched).

3.11 Module Commands

A Module Commands file is used to initialize the Test Module prior to beginning a test session. It is not generally necessary for the end user to deal with this information. If special circumstances require changes to the default settings, a thorough understanding of section 9.3 is essential.

Included in the Module Commands are four Dialing Registers which are used automatically by ARONTS software. These can be altered to modify operation.

Dialing Register A is used to command RTS-1's to transmit their peg counts; B is used to command RTS-1's to hang up; C programs a delay for RTS-1's when a port is Paused; and D is used to regain control of an RTS-1 if the conclusion of a test call does not achieve the RTS-1 prompt. This last situation is most likely to occur if a strong voice recording follows a SIT tone sequence, or if only a voice recording results from the test call: in these cases, it is possible for the voice to interfere with ARONTS' release circuit command (###). The default register D effectively regains control of the remote unit in seconds.

The above four Dialing Registers have no correlation with the numbered Dialing Registers 1-500 accessible to the end user. Every time a numbered register is used, that information is temporarily (automatically) stored into the Test Module's register Z, and used for that action only.

4. REPORTING

This section describes the mechanisms ARONTS provides to obtain and analyze test call results. The use of failure logs, built-in analysis tools, and data export to other analysis packages are discussed. The purpose of this section is to detail the types of information which is recorded and the ways in which it can be manipulated. Elemental programming tools relevant to these goals are detailed. The usage of actual program menus to implement these processes is discussed in section 6.

4.1 Failure Log

Every test call placed with a Dialing Register with any Expected field other than None can potentially add an entry to the Failure Log. When each test call ends, a Log Code is assigned to the test dependent upon the type of result. If the setup parameters call for logging of failures only, log codes in the range 101-199 are added to the log; if the setup parameters call for logging of successful and unsuccessful tests, log codes in the range 100-199 are added to the log. The log is primarily intended to be a Failure Log, corresponding to the first situation; out of the thousands of test calls made, only the ones which require attention are logged as further action required. When routining, and recording only failures, when the session is completed, all scheduled tests have been completed successfully except for the ones recorded in the Failure Log; note that some codes indicate an entire Site was skipped. A good reason to log successful in addition to unsuccessful tests is to verify operation the first time a new Test Definition is run; every test call is recorded. Once the Test Definition is verified for accuracy, subsequent runs can be made logging failures only.

The Failure Log can be displayed and printed either while testing is in progress, or from the Main Menu. The former ability is provided mainly to permit the user to quickly monitor the progress of testing without halting that testing. It is also possible to have the system "beep" on every addition to the Failure Log to alert the operator of test failures.

When the Failure Log is called up from the Main Menu, an option is provided to extract from it log entries restricted to a single Site Number. This may be used if multiple site testing is being performed, but different individuals are responsible for correcting problems at different sites-- separate display and printout can be made for the site selected.

The Failure Log contains all pertinent information relevant to the test in question, and can be displayed on screen or printed out in several ways. DTMF digits received are included in the log entry, as well as SIT codes. These codes are detailed in section 6.5.2, along with a listing of Log Codes.

4.2 Test Analysis

Test call statistics are collected independently from test call detail recordation in the Failure Log. All test calls (other than those made with Dialing Registers with an Expected field of None) which achieve any type of result update two files: Site Statistics, and Test Number Statistics. These two files keep call statistics broken down by Site and Test Number, respectively. Peg counts of Milliwatt, DTMF, SIT, Busy, Reorder, Voice, Ringing, and Time Out are kept. In addition, the average and standard deviation of the time required to reach successful milliwatt signals are included. This can be used as a quality measure for connect time, and comparisons by originating location (Site) and terminating location (Test Number) are easily retrievable.

The statistics files can be zeroed to begin a new data collection set when necessary. The Analysis program provides the ability to extract individual Site and Test Number statistics, as well as totalling categories of sites for average combined results. For example, connect times can be compared after conglomeration over all sites grouped by type of Central Office.

Site statistics are also retained regarding the number of times each site has been accessed by ARONTS, unsuccessful access attempts, and for RTS-1 sites, access information retrieved from the remote unit itself at its last ARONTS access.

4.3 Canned Reports and Custom Analysis

The previous section mentions some types of reports which can be produced with interactive use of the Analysis program. Certain types of reports may be desired on a repetitive basis. These reports differ among ARONTS users, so the software provides a means for each ARONTS user to simply create any desired "canned" report. The canned reports can be created either from the Dos command line or from the Custom Menu. After a canned report is created, it can be run from the Custom Menu. A report referred to as Report #1 can be created from the Dos command line with the following Dos command (from within the \Aronts directory):

C:\Aronts> Analysis Create Report.001

Any valid Dos filename can be used in place of Report.001. The normal Analysis package runs; the desired report should be created interactively. When the Analysis program is exited, the file Report.001 is created. To run the newly created report from the Dos command line:

C:\Aronts> Analysis Execute Report.001

The above procedures assume that a printout was requested by the canned report. It is also possible to "can" an analysis session up to a particular point, and return control to the user. This is done by creating a report as above, up to the point where the desired screen display is achieved, and then typing ^Z. The report file is ended at that point. When the report is executed, it stops at that same point with the desired screen display.

The Main Menu provides an option for a Custom Menu. This is simply a Dos batch file which is easily changed by the end user to serve whatever purposes desired. Single keystroke execution of previously created canned reports is the major intended use. For example, canned reports which create a listing can be run without any screen display at all from within the Custom Menu with the following invocation in the batch file:

Analysis Execute Report.001 > Nul

The result is a specialized report automatically coming out of the printer with a single keystroke request.

The batch file makes use of program utilities WriteScr, GetInput, and RemoteOp. These programs provide the ability to write to particular places on the screen, including display attributes; get single-character input; and test whether the system is under remote operation. These programs work whether the system is under local or remote control. Other non-ARONTS programs and utilities may be included inside the custom batch file, but they will not operate via remote control unless they use the Dos Standard Input and Output. Creation of custom menus is covered in more detail in section 6.5.

Import of Statistics into Graphics Programs

The Analysis program can create an output file containing the same types of information as is created for visual examination, but formatted for interface with other packages. This report file resides in the Dos directory D:\Report with filename Analyze.Txt, and is a pure ASCII file. This file can be exported to any spreadsheet, database, or graphical analysis package to permit custom graphs, charts, and other report formats to be made. This can be performed manually at the Dos prompt, or incorporated into the Custom Menu. A canned report can command the Analysis program to create the Analyze.Txt file, which can then be followed by appropriate batch commands to import the file into other programs and output a specialized graph without additional user input. Setup parameters specify the exact format of this output file. See sections 6.4.1 and 6.5 for more detail.

4.4 RawData Usage

In addition to the Failure Log and the statistics files, a separate output file can be created containing test call detail. This output file resides in the Dos directory D:\Report with filename RawData.Txt, and is a pure ASCII file. Setup parameters specify the exact format of this output file, and Log Codes which act as a filter for file creation: records are only written for test results which match a user specified list of Log Codes.

RawData.Txt can be used for billing comparison purposes. Billing records extracted from a CO or tandem switch containing the records for the test calls can be compared with another program against the RawData.Txt file created by ARONTS.

Specialized analysis beyond the built-in ARONTS capabilities can be done using any desired database program by importing RawData.Txt. Section 6.4.1 discusses the file formats.

5. UTILITY FUNCTIONS

This section describes several utility functions ARONTS provides to facilitate ease of operation. File maintenance features, import of data from other databases, and remote operation are discussed.

5.1 File Maintenance

The current Test Schedule, Test Definitions, Test Numbers, Dialing Registers, and Module Commands files can be given version numbers and stored in the archives, and previously stored file versions can be retrieved from the archives under the File Maintenance Menu option. A notepad is available on-line under File Notes which can be used to document the uses of the various versions of each file type. Other File Maintenance options are with regard to backing up and retrieving ARONTS files to and from floppy disks.

Floppy drives A: and B: (if B exists) can be used to format disks from the menu preparatory to usage. Several Offload provisions are present to remove files from the ARONTS Control Computer for transfer to another MS-Dos machine for processing. The Analyze.Txt and RawData.Txt files (sections 4.2, 4.4) can be copied to floppy disk by menu command. A listing file, Printer.Txt, also may be offloaded. Many of the ARONTS menus offer a List option. All List options create the file Printer.Txt (overwriting the last listing). If the printer is placed on-line prior to requesting a listing, the specified output (Printer.Txt file) is automatically sent to the printer. The Printer.Txt file is created whether the printer is on- or off-line. The File Maintenance option to Offload Printer.Txt can be used to extract the most recent print file no matter if it were previously printed or not. This can be used to print the report on another system and printer, or to transfer the report to another location via electronic mail without the necessity of handling paper and using facsimile equipment.

The Offload option places the appropriate files in a directory on the floppy disk, \Aronts, with filenames of Printer.Exe, Analyze.Exe, and RawData.Exe. These are self-extracting compressed files. The printer file can be transferred to the target computer system by issuing the command:

A:\Aronts\Printer

on the target machine with the current directory set to the location where Printer.Txt is to be placed. If the disk drive is not A: it should be replaced with the appropriate drive letter; the other two files are handled in the same manner with Analyze or RawData replacing the Printer command.

Backup/Retrieve options display all ARONTS data files, their size, date of last revision, and whether the file was changed since its last backup. Menu options permit file backup and retrieval, automatically compressing and expanding files. File splitting with multiple disk handling ensures that backups can be made no matter what size the file.

Section 6.5.3 covers these menu options in more detail.

5.2 Other Menu Utilities

Simple Main Menu options are provided to Terminate Print Job, which is used to stop a listing mistakenly sent to the printer; Wipe RawData, which deletes the RawData.Txt output file; Zero Statistics, which clears the statistics files; Revise Date, Hour/Minute Change, and Exit to Dos.

5.3 Remote Access

The Control Computer can be accessed with a remote data terminal through an internal modem. Remote access can be initiated when the system is in the Main Menu or is Testing. Once remote control is achieved, all menu options can be utilized. This permits remote control of all ARONTS functions. The modem does not answer the line if the Control Computer is performing any other function (including sitting at the Operating System).

Local Effects

When a remote user dials the modem on the Control Computer (in the Main Menu or Testing Lines), a message pops up on the bottom line of the screen stating that remote access is being attempted. While this message is present, the local user cannot control the computer. If the attempt is unsuccessful, the message disappears, and normal operation resumes.

Once remote access is established, the display screen clears and displays a message stating that remote control is in effect. If the local user wishes to override the remote accessor, the modem telephone line should be disconnected; within a short period of time the console is restored.

Remote Location

The remote user must use an ANSI terminal or communications package operating in the ANSI mode. Asynchronous modem speeds of 300, 1200, and 2400 bits per second may be used, with 8 data bits, no parity, and 1 stop bit. The remote user must dial the modem line, and when prompted, enter a password. Two chances are given to do so successfully. If more than seven seconds elapse between password characters, a timeout occurs, and the communications attempt is aborted.

Once access is validated, all menu options can be accessed. The Main Menu and Test Sites Master Display show an additional option: Hang Up Modem. This option is used to return control to the local user. If modem carrier is lost accidentally, the remote user should call back in and hang up through the menu option.

The arrow keys function identically to local use. The special function keys are not available on an ANSI terminal. The following control characters replace the displayed keyboard character instructions:

Key	Remote Replacement
Escape Insert Delete Page Up Page Down Home End	^A ^B Rubout ^R ^Y {Up Arrow} {Down Arrow}

Communications packages may be set to map these keys to the above control codes, making remote operation identical to local operation.

5.4 LoadSite

Much of the ARONTS data entry requirements involve setting up the Site file through the Site Information menu item. If an existing MS-Dos database is available with information on some of these fields, it can be imported into the ARONTS structures with the utility program, LoadSite.Exe. A text file must first be created from the existing database and used as follows.

LoadSite is used to read an input file to modify Sites.Dat and Notes.Dat. It creates an output file which can be used to verify that the input file was syntactically correct and that the appropriate fields have successfully been written. Invocation from Dos is:

C:\Aronts> LoadSite < inputfile > outputfile

Standard MS-Dos input and output is used, so the program may be exercised with a simple LoadSite. Doing so causes input to be directed from the keyboard, and output verification goes to the screen. When used with files, the input and output files are ASCII text files. Each line in the file specifies one field of one site record to be updated. All parameters on the line are separated by one or more spaces. However, the output file contains only one space separating the fields, so if a simple compare operation is to be performed, the separators in the input file should be one space as well. Each line contains three entries: the site number, the field number, and the field data:

123 16 12

In this case, field 16 for site #123 is written with value 12 (Lata 12). When complete, the Dos command:

C:\Aronts> Comp inputfile outputfile

can be used for verification. The sample files LoadSite.In and LoadSite.Out can be examined for illustration.

The fields are as follows:

1: Master Site
2: LEC #
3: Zone
4: Access Number
5: Access Register
6: CO #
7: Site Type
8: Activated/Deactivated
9: Notes Line #1
10: Notes Line #2
11: Notes Line #3
12: Notes Line #4
13: Shared/Unshared
14: Conforming/NonConforming
15: State Name
16: Lata
17: Site CLLI
18: Tandem CLLI
19: Originating Number

Fields #4 and #19 are telephone numbers, and must be 12 digits enclosed in double quotes. Domestic numbers should have the first two digits as spaces, followed by the 10-digit telephone number. For example, " 4109361212" represents (410) 936-1212. International numbers must begin at the first spot and be filled with trailing spaces to make up a total of 12 digits. For example, "123456789 ". Originating numbers (field #19) for RTS-1's are stored as line #11.

The Site Type (field #7) consists of the values 1-4, as follows:

1: One module RTS-1
2: Two module RTS-1
3: Simple HotShoe
4: Coded HotShoe

Fields #8, #13, and #14 consist of the values 0 and 1. 1 corresponds to True (Activated, Shared, Conforming) and 0 corresponds to False (DeActivated, UnShared, NonConforming).

Fields #9-#12 are 50 characters enclosed in double quotes.

Field #15 is a two-character state name enclosed in double quotes, and fields #17 and #18 are eleven-character CLLI codes enclosed in double quotes. Upper and lower case entry is possible with each of these three fields, but are converted to all upper case in the site file as well as the output check file.

6. MENU OPERATION

The user is shown display screens providing information as to what actions can be performed. In all cases, each valid keystroke is shown on the screen. It either appears as a Bold character, or is enclosed in curly brackets, such as {Enter}. Some screens show the option: {Arrows}. The {Up}, {Down}, {Left}, and {Right} arrow keys are used to move the reverse video option on the screen. In some cases, only the Up/Down or Left/Right arrows are used. The {Left Arrow} key is distinct from the {Backspace} key. The two {Enter} keys are treated identically. Upper and lower case characters are indistinguishable. The Num Lock key on the right side of the keyboard controls whether the keys in the right hand keypad function as numbers (if the Num Lock key is illuminated) or as arrow or function keys. It is preferable to leave the Num Lock on, as the special keys are available immediately next to the keypad. Invalid keys generate an alert beep.

If a printer is connected and is on-line, any currently displayed screen can be printed by depressing the Print Screen key. Separate menu options are available for printing larger amounts of information at one time. All such list options create the file Printer.Txt, and print it if the printer is on-line. To prepare a listing for transfer to another computer system, the list option is used with the printer off-line, and the file copied through the File Maintenance menu.

The program menus are intended to be succinctly self-explanatory to those generally familiar with ARONTS parameters and structures, covered in earlier sections. A description of the screen options is supplied here as further explanation. The screen displays printed in this manual are samples only; information is representative of the field contents, not real data. The reproduction reductions make it more difficult to pick out the bold characters depicting valid keys than on the video monitor; these are clearly evident as bright characters when executing the software. The printed screens use black characters on white paper-- the actual screens display white characters on a dark background. Reverse fields are black characters on a white background on the video monitor, and the opposite in these reproductions.

6.1 Main Menu

The Main Menu (Screen #1) automatically appears after system reset and reappears when the selected option is complete. The upper right corner of the display shows the current date and time. Should the date or time be incorrect, utility options can be used to make corrections. The free space on drives C and D is also shown. If the Control Computer is not used for any purpose other than ARONTS, free space on Drive C should not change significantly except when new file versions are stored in the archives. The Failure Log and the printer output file are the only variable length files on this drive, and should routinely be cleared. The printer file is cleared on each listing. Drive D contains the ASCII output file, and can grow large if this option is left active and not wiped out periodically.

Screen 1
Screen #1

The Main Menu options (Screen #1) are grouped into five categories: Operations, Database, Test Configuration, Specialized, and Utilities. To select an option, the single key displayed in bold is entered.

6.2 Operations

The operations section is used to test sites, resume previously interrupted testing, and exit the ARONTS environment.

6.2.1 Test Sites

The testing operation is selected by Main Menu option Test Sites. This program communicates with the Test Module, placing commands to access sites and call test numbers; and collects the resulting call disposition information. Upon selection, an initialization screen is displayed, and an option to pause by depressing the {Space} bar is offered. For normal operation, no keystrokes are necessary. If a pause is initiated, an option appears prompting for another keystroke to proceed. The Module Commands are next transmitted to the Test Module. If there is a problem with the commands or the Test Module, execution halts where the problem is detected, and the user is prompted for a keystroke to return to the Main Menu. After successful initialization, if a pause had initially been ordered, another pause is made after sending the Module Commands, with a prompt to begin testing. The Master Display appears.

Screen 2
Screen #2

Master Display

The Master Display (Screen #2) shows the current status of the Test Module. Every port is presented. The port letter (A-L) appears in the Prt column. If there is more than one partition, the partition number appears to the left of the port letter. If a site is currently being called or accessed, the site number is shown in the Site column. If a site has been successfully accessed, and a test is in progress, the Test Number appears in the # column. The status of the test call is then shown to the right of the Test Number. This displays Testing while a response is awaited. The display briefly flashes Passed, DTMF, SIT, Busy, Reorder, Ringing, Voice, or Timed Out when a test is complete and a result is available. Hanging Up briefly appears when a site is released; other displays are Calling, Idle, Not Present, Disabled, Failed, and Paused.

The number of scheduled sites to be tested, multiplied by the number of repetitions ordered for routined partitions, is shown. Partitions using Operation Tables are not counted. This scheduled number updates as ARONTS scans all necessary site data, searching for matches according to the selection criteria specified in the Test Schedule. The number of completed sites is also shown. The cumulative count for each test result (from the last time the statistics was cleared) is displayed. These numbers update as test results arrive.

The current time and date are shown at the lower left of the display. The Operation Table for the Test Schedule currently in use is displayed after the date: this is either the day of the week, or Holiday. The current zone specified in that Operation Table (or All) is displayed, followed by the number of Calls per Site. If shared sites are to be skipped, Skip appears after the number of calls per site. This information is updated as the time changes. If all partitions are routining, this information is not significant. The Failure Log entries are shown on the right, or None is displayed. This increases as failures are detected. The bottom line shows all keyboard options.

Once an option is selected and further information is required, a 10 second timeout is in place for the subsequent keystrokes. If a timeout occurs, the Master Display reappears.

Screen #3

Display One

The Display One option is used to zoom in on a single port in order to reveal additional information. Screen #3 is displayed. The last cage and port displayed are shown; to change the cage, 1, 2, 3, or 4 is entered; to change the port, a letter in the range A-L is entered. After selection of the cage and port, {Enter} switches to the Display One Screen (Screen #4).

Screen #4

The cage and port displayed are shown at the left of the screen. If the port is being used to call or access a site, information about the site is displayed. This includes the information available from the Site Information Main Menu option, and the One Site option from the Test Analysis utility. This data is for all calls which have occurred previously. The information is dynamically updated as test results come in. The access and test status is shown near the bottom of the screen. Once the site has been accessed, and a test number has been assigned to the call, the test number and dialing register data appear.

When the test is completed, the test results flash on the bottom line. Normally, the next test call or site access immediately begins. If it is desired to peruse the test results in real time, prior to the completion of the test, the {Space} key can be used to activate a freeze type of operation. This causes the bottom options line to change as shown in Screen #4. After activation, when a test is completed, the results are displayed and an alert beep is generated. The test results are held for 60 seconds. Another {Space} immediately releases the held test results, and testing continues. Entering double {Space}'s releases the held test result, and places the next test into freeze mode as well. If it is desired to hold the test results longer than one minute, the {Enter} key can be depressed periodically to reset the 60 second timer.

{Escape} exits the Display One screen and returns to the Master Display.

Screen #5

Specific Test

A Specific Test can be selected from the Master Display. Screen #5 is displayed. The last site and test number specifically requested are shown, and the Site field is depicted in reverse video. A different site number can be entered ({Page Down} is used to clear the field). To change the test number desired, the reverse video field is swapped to the Register and Test Number fields with the {Arrow} keys. If All tests are to be performed from that site, A is used; it is not necessary to enter a register or test number. When the site, register, and test numbers are as desired, the test begins with the depression of {Enter}. To abort and not perform a specific test, {Escape} is used.

When the specific test begins, the Display One screen is automatically called up; if the site requested is already accessed on any ARONTS port, that port is displayed; when the test in progress is completed, the specific test begins. If the site requested is not active on any port, port 4L is displayed. The first port which completes a test: releases its site; is assigned to the test; calls the requested site; and is selected for display. In either situation the Hold Test option is activated.

Failures

Selecting the Log option from the Master Display performs the same display of the current Failure Log as described in section 6.6.2, except that the option to restrict display to a particular site is not offered. The log entries are up-to-date. A 10 second keystroke timer is put into place, however; an additional option ({Enter}) is provided to reset the timer periodically to prevent the Failure Log from disappearing, and the Master Display replacing it.

Display Communications

The Communications Master Display option is used to monitor transmissions between the Control Computer and the Test Module. This is intended for diagnostic purposes; however, this may be displayed for informational purposes. Because the RTS-1 and Coded Hot Shoe codes, as well as credit card and secret authcode data are shown in this intrasystem communication, a password is required to activate the display.

Characters received from the Test Module are shown in reverse video. Upon entry, six lines of previous communications are displayed prior to showing current communications. New communications are augmented with {logcodes} as testing progresses. Further diagnostic ability is available by activating Direct Communications. This option should not be utilized, as it halts test call processing and gives the user direct control of the Test Module. Once activated, {Delete} is used to return to the Display Communications screen.

{Escape} exits to the Master Display.

Screen #6

Quit Testing

Selecting Quit Testing from the Master Display exhibits Screen #6. A choice of quitting Immediately or to Finish Tests in Progress is available. The latter option is recommended. To abort the quit request, {Escape} is used.

If Finish Tests in Progress is selected, the Master Display appears with a note that tests are being finished up. No new tests are issued; and RTS-1's are commanded to disconnect (preferable to simply hanging up, which Immediately does). Reselecting Quit Testing and aborting with {Escape} removes the exit request.

When quitting, files are updated and the Main Menu reappears.

6.2.2 Resume Testing

The Resume Testing Main Menu option is identical to Test Sites, except that the site accesses are not re-computed-- data is utilized from the last test run to continue testing with a minimum of repeated tests. Tests completed in the last run for a site which was active are repeated if all scheduled tests for that site were not completed for that repetition number.

6.2.3 Exit to DOS

The Main Menu option Exit to DOS leaves the controlled ARONTS environment and places the user directly at the operating system level. Confirmation (Yes/No) is required. This option should be used cautiously.

6.3 Database

Items in this category are not test dependent. Information is related to the site locations themselves.

Screen #7

6.3.1 Site Information

Selecting Site Information from the Main Menu displays Screen #7. Sites are numbered in the range 1 through 25,000 (maximum value for the individual system is shown in the Setup menu). Information for consecutive site numbers can be scanned with the + and - keys, or a particular site number selected with the Site# field. Initially the reverse video field displayed is Site#; the {Arrow} keys are used to move this to the field to be changed. Master# is used for sites which cannot be accessed while another member of the Master group is being used.

The LEC# is the number of the Local Exchange Carrier (section 6.3.2), and may be entered if known; or the text may be entered into the LEC Name field. If the latter option is used, the name must match an LEC definition (upper/lower case not significant). LEC information is optional.

Zone is the time zone (optional). The Access Number is the number used to call the site. It may be omitted for testing directly from ARONTS ports. Reg is the Dialing Register number used with the Access Number to reach the site; it is mandatory.

The CO# is the number of the type of Central Office (section 6.3.3), and may be entered if known; or the text may be entered into the CO Description field. If the latter option is used, the name must match a CO definition (upper/lower case not significant). CO information is optional.

Below Site# and Master# is the type of site: RTS-1, Simple Hot Shoe, or Coded Hot Shoe. {Space} rotates through these three types. The next field is either Activated or DeActivated; {Space} toggles the field. Textual information can be stored regarding the site under Notes. These four lines are not used by ARONTS in any way-- they are intended to eliminate the necessity of keeping a separate paper logbook of site contact personnel, addresses, maintenance telephone numbers, etc.

The next field is either Shared or UnShared; {Space} toggles the field. This is used to bypass sites marked as shared during business hours. The next field is either Conforming or NonConforming; {Space} toggles the field, which is provided to ease the selection of sites by a basic CO parameter (independent from the CO description).

State is the 2-character state, province, or country name defined under the State/Country Main Menu option (section 6.3.4). Upper/lower case is insignificant; this field is optional. LATA is a 4-digit Lata number, or any numeric reference number desired (such as might be used for global breakdowns); it is optional.

Site and Tandem CLLI codes are 11-character fields which may be used in the conventional sense, or as any text field in which matching is to be performed. Characters are converted and stored as upper case after entry. These fields (and the Originating Number) can be matched on a character-by-character basis for site selection, and are optional.

The Originating Number(s) area shows a single number for Hot Shoe sites (Screens #9, #13), or numbers for each of the RTS-1 lines. Single-module RTS-1's (8 lines) permit the last eight digits in each originating number to differ (useful if more than one exchange is served at the CO); two-module RTS-1's (16 lines) permit the last four digits to differ. Should a site be equipped with a larger RTS-1 unit, the site information is split into multiple site numbers, each with the same Master number.

Originating Numbers and the Access Number can be domestic or international types; this is changed by {T}{Enter}. Domestic numbers must contain 10 numeric digits; international numbers can contain 1-12 numeric digits. Screen #11 shows international numbers.

Screen #8

An additional option, 8/16, appears at the bottom of the screen when the Originating Numbers field is displayed in reverse video for RTS-1 sites. This toggles the site between 8- or 16-line RTS-1 units. Screen #8 shows a 16-line site. Originating Numbers are optional; however, for single module RTS-1's, a number must be entered into line #11 if lines #12-#14 are used, and into line #15 if lines #16-#18 are used; and for two module RTS-1's, a number must be entered into line #11 if any of the lines are used.

Data entry for each of the fields which do not simply toggle or rotate between all available values begins with entry of a {Space}. Changing the Site# field does not change the site number of a selected site record to another number; it retrieves the record of the newly selected site. This moves to a different site number in the same fashion as the + and - keys increment and decrement the site displayed.

Field Editing

Screen #8 shows data entry for Notes. Initially, the first note line is shown in reverse video; {Enter} advances to lines #2-#4. Three lines of edit key instructions are shown at the bottom of the screen. These same instructions are shown for many of the information entry screen fields. While in edit mode, the {Left Arrow} and {Right Arrow} keys are used to position the cursor beneath a character to be changed. {Home} positions the cursor to the leftmost spot, and {End} places the cursor at the rightmost spot. {Delete} erases the character above the cursor and moves all subsequent characters to the left one position. {Backspace} deletes the character to the left of the cursor position and moves all characters from the cursor position to the end to the left one spot. The {Backspace} and {Left Arrow} keys perform distinctly different operations. {Page Down} erases the entire field, and {Page Up} restores the entire field to what it was prior to making any changes in the line. Any other key (except {Insert}, {Escape}, and {Enter}) adds the new character to the field. Initially the edit line utility is in Typeover mode; any new characters entered replace the character above the cursor. To add characters within the line without overwriting existing characters, {Insert} is first depressed. This places the system into Insert mode; any new characters typed first move all existing characters from the cursor position to the end (- 1) to the right one position; the new character is placed in the emptied spot; the last character of the field is lost. When in Insert mode, depressing {Insert} changes the system back to Typeover mode; the edit instructions show the current Insert/Typeover mode. A changed field is recorded with the {Enter} key. Aborting with {Escape} automatically restores the field to its original (just as if {Page Up} were entered) and exits the Notes option.

Screen #9

RTS-1 and Coded Hot Shoe sites have codes which can be displayed and entered. Initially, these sensitive fields are hidden (Screen #7). Exercising the Codes option shown at the bottom of the screen displays those codes after successful entry of a password; this is shown in Screen #8. Once authorized for codes usage, the codes can be instantly hidden or redisplayed with the Codes key (o). RTS-1 sites show Test and Program Codes; Coded Hot Shoe sites (Screen #9) show Access and Authorization Codes.

A Clone option is available to copy information from one site number to another. The site containing the source information is first displayed, and Clone is then selected. A Site Selector Menu appears:

Screen #10

Site Selector Menu

The Site Selector Menu is used to enter information which matches fields of sites to be chosen for some purpose, in this case to be cloned to. Most of the site fields are shown. Each of these ten fields may have up to eight entries. If a field has no entries, as is the case for the Tandem CLLI field in Screen #10, that field has no bearing on the matching decision. If a field has at least one entry, the matched site must match at least one of those entries for selection. The example of Screen #10, although ridiculous, serves as an illustration.

Only site numbers 6, 7, 321, 456, 32, 67, 82, and 99 can possibly be selected. Although the meaning of site selection for the site field is the same as for the other fields, in practice it has a unique difference: it reduces the scan time necessary to locate matches. ARONTS goes directly to the records of the listed sites, and checks the remaining fields. If there are no entries in the Site# column, ARONTS searches all site records in the indicated range. This is relatively quick for several hundred sites, but may take a minute or two for 25,000 sites. If ARONTS is configured for a large number of sites, and the site numbers are known in advance, it is desirable to place them in the Site# match column for this reason.

The illustration shows Master numbers of 54, 32, and 56. The matching site must have one of these Master values. This field is useful to change or locate all sites of a particular Master number; for instance, to deactivate and reactivate all such sites should the site become inaccessible, and subsequently repaired.

LEC numbers 1-5 are specified in the example; typically only one value is entered. The field may be entered with either the LEC reference number, or the actual name. The Zone must be 1-4, or 10, in this example.

The Originating Number refers to the first originating number (11) for RTS-1 sites. This field, and the CLLI fields, function differently from the other match columns. The entry is interpreted as a mask: every character other than {Space} used in the match field must match; character positions corresponding to spaces (displayed as x's) are wildcards, and need not match. The most common usage of this feature for the Originating Number field is to match all sites with a given set of Area Codes, or Area Code and Exchange (NPA/NXX). The illustration depicts a match for all of area code 301, and the specific exchange (212)321-xxxx. Another case is matching a given NXX for any area code: (xxx) 976-xxxx. This entry matches any 976 originating number. The unusual example (415) xxx-1234 matches any exchange in the 415 area code with the last four digits 1234. The last entry in the example matches any international number beginning with 12 34 5.

CO types 1-4 are specified in the example. The field may be entered with either the CO reference number, or the actual description. This is most useful for selecting types of CO's for testing in the Test Schedule (section 6.4.2).

The State field matches states Maryland, Virginia, California, and New Hampshire; the country United Kingdom; and province British Columbia. LATAs 234, 543, and 1000 are required.

The Site CLLI field has three sample masks: the first matches any site with Site CLLI beginning with CHCGIL; the second beginning with BAL; and the third with a last character of 0. This feature can be used to match individual cities. The Tandem CLLI field is handled in the same way.

There are nine Yes/No fields describing site characteristics; if set to Yes, sites with that characteristic are included in the selection process. A single No which matches a potential site causes that site to be rejected. Many combinations result in no possible matches: RTS-1, Simple, and Coded Hot Shoe sites all set to No; Conforming and NonConforming both set to No; Shared and UnShared both set to No; and Activated and DeActivated both set to No. Note that it is important to include DeActivated sites when cloning site information to site numbers which have not yet been activated; they can be activated in this way if the Activated field itself is cloned.

An overall range of site numbers is specified by First Site and Last Site. ARONTS restricts its match scan to those records. The default is all valid site numbers. It is useful when cloning information to new site records. For example, if site #100 is a master site for site numbers 101-109, after site #100 information has been entered, it can be cloned to sites 101-109 by setting the First Site to 101 and the Last Site to 109; making all of the Yes/No options Yes; and leaving the remaining fields empty. Subsequent to the clone operation, individual changes can be made to the newly created records.

The Site Selector Menu provides a mechanism to select sites based on many fields-- a match occurs if: each of the ten 8-entry columns matches at least one column entry, or if the column has no entries; none of the No fields match; and the site is in the range defined by First and Last Site. Entries are made by moving the reverse video field to the desired location with the {Arrow} keys, and entering {Space}. A column can be exited (from the edit field mode) with {Escape}; or automatically when the eighth field is entered. When the Site Selector is as desired, {Escape} exits the screen.

Screen #11

Screen #11 appears when the Clone to Site Selector Menu is left. At this point, no changes have occurred. Cloning can be aborted with {Escape}. The entire site record can be cloned to all selected sites with the Clone All option. Individual fields can be cloned one at a time by using the {Arrows} to move the reverse video field to the desired field, and selecting Clone Field. The example shows the Reg field ready to be cloned. All fields to be copied can be handled by using the {Arrows} and Clone Field repetitively; it is not necessary to exit and reenter the Clone option.

The Search option on the main site display (Screen #9) calls up a site selector menu identical to that of Screen #10 (other than the title). When the selection option is completed, Screen #12 appears. Next Match retrieves information for the first site that matches; this may be repeated to view all matching locations. A quick count of matches is available with Fast Count. The number of matches is shown at the right, and the site number scanned is shown at the left (not shown in Screen #12). The Scan and Count option displays site information for matches as they are found. Codes turns codes display on and off. {Escape} exits the Search mode.

Screen #12

The matching information set up in the Site Selector Menu is retained while in the Site Information program. This permits selection criteria to be set up with the Search option and verified with Next Match or Fast Count. Subsequently, the Clone (or List) option may be exercised with the selection criteria remaining the same as that of the immediately previous Search.

Screen #13

The List option on the main site display (Screen #9) calls up a site selector menu identical to that of Screen #10 (other than the title). When the selection option is completed, Screen #13 appears. Selecting either List Without Codes or List With Codes creates a listing file of the matching sites, and prints it if the printer is on-line. {Escape} exits the List mode. Listing #1 provides a sample.

Listing #1

To store changes made in site information, the Write command is issued from the main site display (Screen #9). No actual changes are made to the displayed site until the record is explicitly written. Cloned sites are written as part of that operation. If a change is made to a site field, not written, and an option is requested which would cause the changes to be lost (clone, list, search, +, -, change site number, {Escape}), a warning is presented so indicating: if Continue Anyway is assented to with a Yes response, the changes are lost.

{Escape} from the main site display (Screen #9) returns to the Main Menu.

6.3.2 LEC Names

Screen #14

Valid names for Local Exchange Carriers are handled with Main Menu option, LEC Names. Screen #14 is displayed. LEC's are numbered from 1-9999; fewer may be accessible as defined in Setup parameters (section 6.4.1). Fifteen characters are available, and may be entered utilizing upper and lower case. Subsequent reference is case insensitive. The Next option can be used to browse through screens of entries. Page is used to select a particular LEC number (on a different screen) for display; the LEC number is requested, and the display is updated with the screen containing the desired carrier.

The reverse video field is moved with the {Arrows}. When the field to be changed is so marked, {Space} calls up Edit Mode for the specified entry. ARONTS does not permit a duplicate entry to be made (except when cloned). {Enter} records the change, and advances to the next entry; {Escape} exits Edit Mode and aborts any changes made to the current field.

Clone requests starting and ending LEC Numbers to be cloned to; the current LEC is copied to the selected range. This is for use when a set of LEC Names are similar, and several characters need only be changed to distinguish between them.

Listing #2

Find searches for an LEC Number, given an LEC Name. List creates a listing over a specified range of LEC Numbers; empty names are automatically skipped. Listing #2 is an example.

Screen #15

{Escape} returns Screen #15. No changes made in the session are recorded until the Exit Retaining All Changes option is requested. The other options are self-explanatory.

6.3.3 CO Descriptions

Screen #16

Valid descriptions of Central Office types are handled with Main Menu option, CO Descriptions. Screen #16 is displayed. CO's are numbered from 1-255. Ten characters are available, and may be entered utilizing upper and lower case. Subsequent reference is case insensitive. Operation is identical to LEC Names (section 6.3.2). Listing #3 is a sample printout.

Listing #3

6.3.4 State/Country Names

Screen #17

Valid descriptions of state, province, and country names are handled with Main Menu option, State/Country. Screen #17 is displayed. Items are numbered from 1-255. Two characters are available, and may be entered utilizing upper and lower case. Subsequent reference is case insensitive. Operation is identical to LEC Names (section 6.3.2). Listing #4 is a sample printout.

Listing #4

6.4 Test Configuration

Items in this category are used to define tests and configure the system. Each of the six menu items address their respective files. There is only one setup file. The rest of this group of menu options operate on the current version of the respective file; these can be altered through File Maintenance (section 6.6.8).

6.4.1 System Setup

Screen #18

Selecting System Setup from the Main Menu displays Screen #18. Current parameters and options are presented. A reverse video field depicts the field which can be modified with {Space}. The {Arrows} are used to move the field as desired.

Cages is used to change the number of ports the Test Module is equipped for. There may be from 1 to 4 cages of line cards, each housing 12 cards.

The number of Sites is merely displayed; this cannot be altered with the program. The number of LEC's and Test Numbers can be modified; both files always contain their maximum numbers of entries: 9999 and 3000, respectively. However, by limiting the maximum usable number, entry errors are reduced (an error alert beep occurs if an attempted field entry is out of the specified range); and the time required to read and write the files by the various programs is reduced.

A parameter can be set to collect RTS-1 information or to bypass this polling when RTS-1 sites are accessed. If enabled, ARONTS reads: the number of Test Mode accesses; the number of Program Mode accesses; the number of Access Failures; and the number of Access Answers from the remote unit. It is recommended that this be left activated. If turned off, this site information for RTS-1 sites is not updated, and the values extracted from Test Analysis (section 6.6.1) is inaccurate. The only reason to disable the polling is to reduce the access time by 10-15 seconds. {Space} toggles this parameter.

A parameter can be set to log successes and failures, or just failures when tests are made. The normal setting is to log failures only. Logging successful tests can create a huge (no longer failure) log unless testing is minimal. This has two major purposes: new Test Definitions can be checked the first time run to verify that all intended tests are conducted; and it may be desirable to have a positive test output for every test conducted when switch routining. This also supplies the Wait Time for individual successful Milliwatt tests; the statistics are updated independently from this Log option. {Space} toggles this parameter.

A credit card or calling card number can be entered with {Space} when this field is displayed in reverse video. After password entry, a maximum of 30 numeric digits is permitted. This number is accessible from Dialing Registers, which automatically strip out any blanks in the number. A secret authcode used for dialup service access is handled in the same way, except that a maximum of 10 numeric digits is permitted.

ARONTS uses passwords to protect access to the RTS-1 Access and Program codes, Coded Hot Shoe Authorization and Access codes (as knowledge of these permits unlimited call privileges for calls emanating from the remote location), credit card and secret authcode numbers, and remote access permission. Nine different passwords are available-- they all serve the same function. Upon delivery, the passwords are: PASS1, PASS2, PASS3, PASS4, PASS5, PASS6, PASS7, PASS8, and PASS9. The Change Password option is used to alter these passwords. To do so, the option is selected with {Space} and one of the current passwords entered. A prompt for the new password appears, with a request to repeat the new password. If the two new entries are identical, the change is accepted. Passwords are upper/lower case insensitive, and can be of any length greater than or equal to one character. The {Enter} key is used to terminate a password entry. Corrections (such as using the {Backspace} key) cannot be made when entering a password.

Screen #19

The Enable/Disable Lines option displays Screen #19. This is used to enable and disable individual lines on the Test Module. Entries for ports in cages beyond the number of line card cages selected in the previous screen have no effect on system operation. Disabling a line prevents the line from being used for test calls. Ports which do not have functioning telephone test lines attached should be disabled. To change the enable/disable status of a line, the reverse video field is moved to the port desired with the {Arrow} keys, and the {Space} key used to toggle the port status. To finish, {Escape} is depressed.

Screen #20

The Output file, RawData.Txt, is created or appended if an output file number is specified. {Space} from this field results in Screen #20. All File Descriptors previously created are shown, numbered from 1 to 15. The desired File Descriptor number is entered, followed by {Enter} to select that filetype. The Report output file, Analyze.Txt, is selected in the same fashion; an option to have none is not permitted.

Screen #21

Selecting File Descriptors from Screen #18 results in Screen #20; after a file number is selected, Screen #21 appears, which is used to define the type of ASCII output file to be created. Each of 29 separate fields can be turned on or off by entry of *; a * to the left of the field name indicates that that information will be recorded. Records are written in the exact order shown in this screen. Each field included in the record can be preceded with two characters, and terminated with two characters. Special character conversions are shown in the Screen. Most of the delimiters in this example place a space followed by " in front of the data, and ", behind the data. This results in records of the form "data", "data", "data". The record ends with a carriage return and line feed in this example, which results in a data record as follows:

"11/12/91", "15:23:36", " 3013639999", "0345", "CHCGILCLCG1", "IL", " 8005551234", "105", {c/r}{lf}

The screen display shows the number of characters each field contains, such as 5n for the site number, which indicates five numeric digits; or 3c for the call code, indicating three characters. Others appear just with the number of digits, such as 11. The field is reached with the {Arrows}, and changed with {Space}.

Screen #22

Selecting Log Codes from Screen #21 produces Screen #22. This specifies which Log Codes will produce a new record in the Output file. Any combination of codes from 1-255 may be chosen. The above example creates records only for successful test calls.

Screen #23

File Descriptors can be used for Output or Report files. The previous descriptor (Screen #21) is for a RawData.Txt file (output). In order to use a file descriptor for a Report file, R is utilized from Screen #21 to change to a Report definition; it can be toggled back with another R. Screen #23 shows a Report type descriptor. Most fields are the same as those displayed or listed from Test Analysis (section 6.6.1): statistics or data. The Record Type is the character used to create the report in that program. The Number is either the Test Number or the Site Number, depending upon which report option is selected. The Site Type is the same as defined under LoadSite (section 5.4). Matches shows the number of sites matched in reports which use a Site Selector Menu.

When all data has been changed in the Setup View/Modify program, {Escape} from Screen #18 exits to a screen similar to Screen #15. No Setup changes are recorded unless this screen is exited retaining all changes.

6.4.2 Test Schedule

Screen #24

Selecting Test Schedule from the Main Menu goes to Screen #24. The reverse video field can be moved with the {Arrows} between Holiday Selection, Operation Tables, and each Partition #. {Space} activates a new screen for each.

Screen #25

Requesting Holiday Selection from Screen #24 displays Screen #25. This permits marking any collection of days of each month as a holiday (activating a separate Operation Table). To add or remove a day of a particular month from that month's holiday list, the reverse video field is moved to the desired month with the {Up Arrow} and {Down Arrow} keys, and {Space} depressed. A request pops up for the day of that month to change; the desired date is entered, followed by {Enter}. If that day is not in the holiday list, it is added; if it is already in the list, it is removed. The submenu is exited with {Escape}.

Screen #26

Selecting Operation Tables from Screen #24 brings up Screen #26. The tables for the desired day of the week or holiday are retrieved by moving the reverse video field to the desired spot with the {Up Arrow} and {Down Arrow} keys and depressing {Enter}, displaying Screen #27.

Screen #27

The Calls/Site, Zone, and Shared statuses are shown for each hour of the day. The entry of interest is reached by moving the reverse video field with the {Arrow} keys. The Calls/Site, Zone, and Shared fields are modified by depressing the appropriate bold face character. Zone numbers in the range of 1 through 255 are acceptable. To permit calls to all zones, the All zones option is selected. When a field is changed, that same field is copied to all hour entries later than the selected hour. In this fashion, starting at the earliest hour and progressing to the latest hour for changes makes it possible to enter only the hours where changes take place. {Escape} exits to Screen #26, from which other tables may be selected. {Escape} from Screen #26 exits to Screen #24.

Screen #28

Selecting one of the Partitions from Screen #24 provides Screen #28. This is the Site Selector Menu (section 6.3.1) which determines which sites are to be accessed for the particular Test Module partition. Four alterable fields are present beyond that of the previous discussion.

Use Op Tables can be set to Yes or No. If set to No, the partition is in Routining mode, and the Repetitions field can be set to 1-255; otherwise, Continuous operation is automatic. The Test Definition File version number can be specified; if set to all blank, the current Test Definition file is used. The first port in the partition is displayed; it cannot be changed (it is the next port above the last of the prior partition). The Last Port can be set to any port not less than the first port. If a greater partition number had previously been defined, and the Last Port of the previous partition is changed past the Last Port of the later partition, exit is not permitted from this screen. The Last Port must temporarily be set to a valid value; the later partition's Last Port set to 4L; and the prior partition's Last Port then set to the desired value. Partitions end when Last Port 4L is reached. {Escape} from this menu returns to Screen #24.

When all data has been changed in the Test Schedule View/Modify program, {Escape} from Screen #24 exits to a screen similar to Screen #15. No Test Schedule changes are recorded unless this screen is exited retaining all changes.

6.4.3 Test Definitions

Screen #29

Selecting Test Definitions from the Main Menu yields Screen #29. This shows the same information as Site Information. At this point, the + and - keys may be used to scan through adjacent sites. Any other key provides Screen #30.

Screen #30

Different sites can be selected with +, -, and by {Space} when the Site field is current. View returns to Screen #29. The Continue With field can be modified to chain to another Test Definition. The Test Group can be rotated through values between 1 and 5 with {Space} when that field is current. The Consecutive Tests, Register, and Test Numbers fields are tied to the Test Group, and can be modified for each Group.

A Dialing Register number can be entered, and the information pertinent to that register is displayed for reference purposes. The number of Consecutive Tests can be set; a value of 1 indicates that tests are to be conducted with the listed Dialing Register only. A value greater than 1 causes the tests to be repeated with the next consecutive Dialing Register until the number of Consecutive Tests requested has been performed for each Test Number, all of which are listed.

Selecting Zero clears all Test Numbers from the displayed Test Group; nothing else is changed. Entering {Space} when the Test Number field is current results in a screen similar to Screen #22; a range of Test Numbers may be entered for change. Only Test Numbers in a range of 100 may be entered for a single Test Group. Selecting Numbers displays the actual Test Numbers on a separate screen, as shown in Screen #31:

Screen #31

Screen #32

Selecting Search from Screen #30 produces the Test Definition Search Site Selector Menu of Screen #32. This is identical to the Site Selector Menu used in the Site Information program (section 6.3.1) with the addition of four fields: Test #, Continue With, Continued From, and Registers. These fields provide ranges for matching against the associated entries in the Test Definitions. The primary use of these fields is to find Test Definitions which use particular Test Numbers or Dialing Registers; if any of the Test Groups in a site's Test Definition matches these fields, the site is selected. Similarly, the Continue With and Continued From parameters can be used to find sites whose Test Definitions are chained to or from a specified site. Clone and List use the identical Site Selector Menu. Search and Clone operate exactly the same as the Site Information program.

Screen #33

After {Escape} from the Test Definition List Site Selector Menu, Screen #33 appears. Two options are available: List, and List With Test Numbers. The first option lists the Test Numbers reference number, but not the actual dialed number, which the latter option does (and creates a lengthier report). The result is Listing #5:

Listing #5

The Write option operates the same as that option in the Site Information program; nothing is actually changed in a site's Test Definition until that site is written. Protection against accidental loss is provided. {Escape} from Screen #30 returns to the Main Menu.

6.4.4 Test Numbers

Screen #34

Selecting Test Numbers from the Main Menu displays Screen #34. Operation is nearly identical to the LEC Names, CO Description, and State/Country Main Menu items (sections 6.3.2-6.3.4). The Type option changes the Test Number between domestic and international format (section 6.3.1). Test Numbers which can be dialed simultaneously from more than one port are marked with *; a * toggles this parameter. List produces Listing #6:

Listing #6

6.4.5 Dialing Registers

Screen #35

Selecting Dialing Registers from the Main Menu displays Screen #35. The fields are modified by using the {Arrows} to move the reverse video to the desired spot, and depressing {Space}. The Expected field rotates between Milliwatt, RTS-1, Manual DTMF, and None. The Call Code can be set to any three characters; the Out Line should be 1 for Hot Shoe tests, and 11-18 for test calls on RTS-1 Module 1, and 21-28 for test calls on RTS-1 Module 2. If the Dialing Register continues, that next Dialing Register number is placed into the Continue With field. Entering {Space} while located at the Reg field permits the entire Dialing Register contents to be defined. Next advances to the next page of Dialing Registers; Page selects the screen for any specified Dialing Register; and Clone copies the current Dialing Register to a range of Dialing Registers. List requests a range of Dialing Registers; only registers with nonblank entries are listed, as shown in Listing #7. {Escape} returns an exit screen similar to Screen #15. No Dialing Register changes are recorded unless this screen is exited retaining all changes.

Listing #7

6.4.6 Module Commands

Screen #36

Selecting Module Commands from the Main Menu displays Screen #36. The Top, Bottom, Next Page, and Previous Page options are used to display the desired page of module commands. The line to be edited is selected by moving the reverse video line with the {Up Arrow} and {Down Arrow} keys (after displaying the desired page), and depressing {Space}. The edit field instructions are displayed. After any desired changes are made, {Enter} advances to the next line; {Escape} returns the screen to the original options.

A line can be moved to another position by selecting the line to be moved with the motion options, and selecting Move. After so doing, repositioning to the line above the line shown in reverse video, and depressing {Enter}, moves the line. The Copy line option works in the same way. A line is deleted with Delete.

New lines are added by positioning to the bottom, where an empty line always appears. After entry, the Move option is used to reposition it.

A {-R} after a command causes ARONTS to expect an acknowledgement from the Test Module; {-1} through {-9} causes a delay of that number of seconds, with no acknowledgement expected.

{Escape} exits to a screen similar to Screen #15.

6.5 Custom Menu

Screen #37

The Custom Menu can be changed by the end user to personalize ARONTS to the specific environment. A sample display is shown in Screen #37. A Dos Batch File, Custom.Bat, defines the menu. Batch programming for this task is relatively simple; if the user is not familiar with this technique, it should not be too difficult to tailor the application as desired by closely following the sample batch file. Any ASCII based text editor can be used to create or modify the batch file; or the command:

C:\Aronts> VMFile Custom.Bat

can be used to edit the file (section 6.4.6). A sample file is supplied as Listing #8.

Listing #8

Five utility programs are provided: WriteScr, GetInput, RemoteOp, RestKeys, and MapKeys. GetInput and RemoteOp return values to the batch file in the ErrorLevel variable. RemoteOp determines if ARONTS is currently being controlled remotely through the modem. It is important to determine this in the Custom Menu in order to prevent a remote user from unintentionally accessing a program which cannot work over the modem. Built-in ARONTS programs automatically operate in the local or remote modes; many other programs will not. Upon arrival in the batch file, the Dos Standard Input and Standard Output is used; any program which utilizes these I/O channels properly will work remotely. Programs which directly access the video display or keyboard cannot function; if control is transferred to such a program, the remote user loses control of ARONTS, and a local user must intervene. Directly after a call to RemoteOp, if ErrorLevel = 1, the system is under remote control; if ErrorLevel = 0, the system is under local control. All programs or utilities placed into the Custom Menu which cannot be used remotely should be protected from attempted access by testing with RemoteOp.

ARONTS maps keys for compatibility with ANSI control sequences. Some programs will not operate with the mapping in place; the program RestKeys can be called prior to the usage of such programs, which restores keys to their original function. It is not necessary to map them back prior to exit from the Custom Menu. However, if "canned" reports are to be used (section 4.3), the keys must be mapped when Analysis is called; MapKeys can be used to do so.

WriteScr provides a convenient method to write messages on the display screen. Syntax is:

WriteScr Row Column Attribute Message Message Message

Row and Column specify the starting screen location for the message: 1,1 is the upper left; 24,1 is the bottom left (ANSI terminals have 24, not 25 rows); 1,80 is the upper right; and 24,80 is the bottom right. Attributes are: Clear, clear the screen; Normal; Reverse; Underline; Bold; and KBlink. Any number of spaces between message words are displayed as one space, and leading spaces in front of the first message word and trailing spaces behind the last message word are not displayed. The special character ~ represents a {Space} to permit accurate display control.

GetInput provides single-character input; the command line includes a list of valid entry keys, which may be separated by spaces, or not, as desired. Input is case insensitive. GetInput does not exit until one of the valid keys is depressed; invalid inputs generate an alert tone. On return, ErrorLevel contains the number corresponding to the position of the character input. Special characters refer to certain keys: ~ = {Space}; ` = {Escape} (left single quote, left of 1 on the keyboard); and ' = {Enter} (right single quote, right of ; on the keyboard). It is a quirk of Dos that ErrorLevel must be tested from highest value down to lowest value; the sample listing demonstrates proper testing. Sophisticated menus can present many screens, calling other batch files and programs; however, the intended use is to produce canned reports and automatic import of Analyze.Txt into graphical presentation packages.

6.6 Utilities

Options in this category relate to reports, files, or system maintenance.

6.6.1 Test Analysis

Screen #38

Selecting Test Analysis from the Main Menu displays the top half of Screen #38. Information gleaned from the Results Files can be retrieved in a variety of ways.

Statistics by Test Number

The Overall Average option (bottom of Screen #38) displays statistical information averaged over all calls. Successful tests shows the number of Milliwatt calls, the average Wait Time to achieve Milliwatt, and the standard deviation of the Wait Time. The standard deviation is useful to determine the consistency of the Wait Time. A random variable with a normal distribution is expected to have 68% of its samples fall within the range of one standard deviation above and below the average value. For example, the data for Successful Tests in Screen #38 shows an average Wait Time of 7.46 seconds, with a standard deviation of 1.90 seconds. It is therefore expected that 68% of all successful test calls had Wait Times fall within the range of 5.56 to 9.36 seconds. The unsuccessful categories show the number of tests of each result type.

Test result statistics for one particular test number are retrieved with the One Test Number option; the user is prompted for the desired Test Number. The List Report and List Wide options (under Statistics by Test Number) print a report for all Test Numbers with non-zero entries, and the totals. List Wide includes the actual dialed Test Numbers, requires a wide printer (or compressed print), and is shown in Listing #9:

Listing #9

Statistics by Site Number

Statistics by Site Number options produce the same statistical information as Statistics by Test Number for a different group of tests. The One Site option requests a single site number, and statistics are displayed for tests originating from that one site, shown in Screen #39. It also shows Site Data.

Screen #39

Selected Totals permits total combined statistics for a selected set of sites to be produced; a Site Selector Menu identical to that of Section 6.3.1 is utilized; after exiting that menu with {Escape}, Screen #40 is displayed. This permits, for example, totalling statistics for East Coast sites (zone #1), or Central Office types.

Screen #40

The List Report option produces a Site Selector Menu which is used to set parameters determining which sites' statistics are to be listed. Listing #10 is the report generated. Verbose Report produces a listing which includes Site Information, Site Statistics, and Site Data.

Listing #10

Site Data

The One Site option requests a single site number, and data for that site is displayed (along with Statistics, Screen #39). Computer Accesses is the number of times the site was successfully accessed by ARONTS. No Response is the number of times the site was not successfully accessed after an attempt was made. Lost Tests are tests which cannot be read due to various circumstances-- not skipped while Routining-- these tests are eventually repeated until logged.

RTS-1 sites show additional information retrieved from the RTS-1 during the most recent access (assuming the Setup parameter is set to Collect RTS-1 Information, Section 6.4.1). Answers is the number of times the RTS-1 answered an incoming ring; Failures is the number of times the RTS-1 answered an incoming ring and timed out waiting for a Test or Program Code; Test Mode is the number of times the RTS-1 was placed into Test Mode; and Program Mode is the number of times the RTS-1 was placed into Program Mode. As these last four totals are stored by the RTS-1 with three digit accuracy, and considering the large number of Test Mode accesses by ARONTS, the Answers and Test Mode numbers overflow in practice.

Selected Totals permits this same data to be totalled for a selected set of sites; a Site Selector Menu appears, followed by Screen #41.

Screen #41

The List Report option provides a Site Selector Menu; a report is generated for the specified sites, shown in Listing #11. The Verbose Report option is the same listing as that under Statistics by Site Number, which includes Site Information, Site Statistics, and Site Data.

Listing #11

File Output

Selecting File Output changes the mode of operation to create a Report Output File instead of displaying or listing requested reports. Initially, the Report File Descriptor specified in Setup is selected (section 6.4.1); {:} can be used to scroll through the 15 predefined Report File Descriptors to select a different one. In this mode, any of the Test Analysis options may be exercised-- however, records are appended to Analyze.Txt instead of making a listing file or displaying information. Screen #42 results.

Screen #42

Section 6.4.1 describes the file created. This option is intended to be used in conjunction with "canned" reports (section 4.3), so that the file output is automatically selected, type of data chosen, file created, program exited, and data file fed into a graphical display package automatically from a batch command file. If the Analysis program is run with the Create or Execute command line option, the initial File Descriptor is preset to #1 no matter what the Setup parameter is; this permits canned reports to select a File Descriptor independently from the Setup parameter; should that parameter be changed, the canned report continues to use the proper File Descriptor.

{Escape} from the main Test Analysis display (Screen #38) returns to the Main Menu.

6.6.2 Failure Log

Screen #43

Selecting Failure Log (keystroke L) from the Main Menu displays Screen #43. The character L chooses the Entire Log for use; two L's from the Main Menu can be used to access the entire log rapidly. The log functions can be restricted to a single site number if desired-- permitting separate listings of test failures to be made from a combined multi-site Test Schedule. After the entire log is selected, or the site to be investigated is entered, Screen #44 appears:

Screen #44

The Top option is used to return to the start of the log, and + and - scan the log forward and backward by page. Bottom goes directly to the last log entry; this is used to check the most recent additions to the log while tests are being performed. The entire Failure log is listed, containing the same information as displayed in Screen #44, with the List option. Wide creates an expanded listing requiring a 132 column printer, shown in Listing #12 (text version). Details displays a screen identical to that shown while testing from the Display One option (Screen #4). The log is deleted (after Yes/No verification) with the Clear option. The Failure Log is intended to be used as a short term report of problems, to be listed or noted and then cleared. If long term information is desired, the RawData.Txt output file option should be used. The Clear option has no practical use if the log is entered restricting the entries to a specific site; this creates a temporary log file for use within the Failure Log program (Clear deletes that temporary file, not the actual log file in that situation).

Each log entry shows the Site; Test Number; Dialing Register; cage and line of the Test Module used for the test call; date and time; a log code; and a description of the failure. DTMF failures report the DTMF digits received.

SIT results show the Special Information Tones received in a 6-digit code. SIT tones consist of a sequence of three consecutive tones. The first tone is one of two possible frequencies, and is recorded as tone 1 or 2; the middle tone is one of two different possible frequencies, and is recorded as tone 3 or 4; and the last tone is always a fixed frequency, recorded as tone 5. Each of the three tones can be of two different durations; this is recorded as * (short) or # (long) after each tone digit. Bellcore Feature Specification Document, titled "Special Information Tones (SITs) FSD No. 20-06-0500", details this information. However, the local Telco should be consulted regarding an interpretation of the tone sequences received, as in practice the specifications are not necessarily followed.

Recorded Tone Number	Frequency	Which Tone
1 2 3 4 5	913.8 Hz 985.2 Hz 1370.6 Hz 1428.5 Hz 1776.7 Hz	1 1 2 2 3

Recorded Tone Duration	Length
* #	274 milliseconds 380 milliseconds

The Failure Log display exits to the Main Menu with {Escape}; it automatically exits after clearing the log as well.

Failure Log options available from the Main Menu are also provided inside the Testing program (section 6.2.1), with the exception of the ability to restrict log entries to a single site. Table I supplies a description of Log Codes; codes 200 and above are reserved for diagnostic purposes.

Table I: Log Code Descriptions

Log
Code

Description

0
1
2
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130

System Startup
Immediate Shutdown by Operator
System Shutdown, Finished Up Tests
Recalled Site
Calling Site, Specific Test
Calling Site
Passed
DTMF Received
SIT received
RTS-1 Timed Out
Local line lost dialtone, Hot Shoe Call
No Response from Hot Shoe, DF 2
Hot Shoe Test Timeout
Unable to read RTS info
Local line lost dialtone, RTS Call
No Response from RTS, DF x
Improper RTS access response, DF x
Unable to read RTS info, DF x
Lost RTS test call, DF x
Lost loop current calling site
Lost loop current during test call
Lost loop current while hanging up site
RTS call with premature DTMF
Improper billing code field
Busy
Reorder
Ring
Voice
Invalid Dialing Register
ARONTS telephone line bad, failed
Too many linked Test Definitions
RTS-1 response not A, B, or D
Unable to access site
ARONTS RTS-1 timeout
Lost loop current while paused
Dialtone
Manual DTMF code

6.6.3 Terminate Print Job

The Terminate Print Job option in the Main Menu is used to kill any printing previously sent to the line printer. Report printing is buffered to permit continued operation of the screen menus while long print jobs are simultaneously handled. This option requests verification (Yes/No) and terminates the job.

6.6.4 Wipe RawData File

The test call detail output file RawData.Txt can be deleted with the Main Menu, Wipe RawData File option. The current size of the file is shown on the menu line. Verification of this request is done in two stages: Yes is required for both prompts.

6.6.5 Zero Statistics

The Results files can be initialized with the Main Menu, Zero Statistics option. This clears all information; reports extracted using the Test Analysis Main Menu option will subsequently be from new test call data. Verification is done in two stages: Yes is required for both prompts.

6.6.6 Revise Date

The Main Menu, Revise Date option, is used to change the calendar date. The current date is redisplayed at the bottom of the display screen; if no change is desired, {Enter} can be depressed. A new date must be entered in MM/DD/YY format, followed by {Enter}.

6.6.7 Hour/Minute Change

The Main Menu Hour/Minute Change option is used to update the system time. The current time is redisplayed at the bottom of the display screen; if no change is desired, {Enter} can be depressed. A new time is entered in HH:MM:SS format, followed by {Enter}. The seconds need not be entered, by using HH:MM.

6.6.8 File Maintenance

Screen #45

Selection of Main Menu option File Maintenance produces Screen #45. The reverse video field is moved to the desired action with the {Arrows}. The Offload options are used to compress an ARONTS text file from the hard disk, and place it on a floppy disk in self-extracting form. The floppy disk is placed into either drive, and {Space} entered to pull off the appropriate file: Printer.Txt, Analyze.Txt, or RawData.Txt. (Screen #45 shows different options because the Offload item is not selected.) The files are compressed and written to the floppy with an Exe extension in a directory, \Aronts. If the directory is not present, it is created. The printer file is retrieved on another computer by setting the current directory to the location where the file is to be stored, and entering the command: A:\Aronts\Printer. The other files are handled similarly; if the floppy drive on the recipient machine is B:, the A: in the command is replaced with B:. This option does not disturb other files on the floppy.

More than one file of the same type can be offloaded to the same floppy disk. For example, the printer file can be offloaded to the same floppy repetitively; different reports can be created, and the printer file offloaded after each report creation. ARONTS checks the files on the floppy disk: if there are not any existing printer files, the file is stored (after extraction) as Printer.Txt; if that file is already present, a serial number is created for the new file. In this manner, Printer.001, Printer.002, etc. are automatically created (and all such files are stored in the one self-extracting file, Printer.Exe). When extracted on the recipient computer, each file is created from the one compressed file.

If the offloaded file does not fit on the disk inserted, but will fit on an empty disk, the user is prompted to try again with a fresh disk. If the file cannot fit on the size disk used, the file is broken into pieces and stored on multiple disks. The disks need not be formatted other than the first; and all files are destroyed in the floppy's root directory. It is necessary to note the order in which the disks are created. To transfer the large file to another system, the directory \Aronts must be created on the target machine's hard drive; the first disk inserted into floppy drive A:; and the command Restore A: C: given. B: can be substituted for A:, and D: can be substituted for C: if appropriate. The user is prompted for each disk in the set. When complete, the files can be extracted from the compressed form by issuing the command C:\Aronts\RawData from the directory where the RawData file is to be placed. Analyze or Printer can be handled similarly.

Floppy disks must be formatted before they are usable. If new disks are to be placed into duty, the Format option can be used to accomplish this. The floppy is placed into the appropriate drive, and {Space} entered after selecting either Format A: or Format B:. The format operation destroys all information on the floppy disk. Once a disk is formatted, the Offload or Backup options can be utilized.

Five archives are displayed at the bottom of the screen. Each shows: the version number of the current file; if the file has been modified since it was last stored in the archive; and the date of the last change to the file version. The current version may be stored into the archive by selecting Archive. A prompt requests the version number to store it under. If the specified version number is already in the archive, a second prompt asks for verification to overwrite the previous version. If such permission is not given, the Modified attribute may show unmodified even though it was not stored.

A file version is extracted from the archive by selecting Retrieve. If the current version has been modified and not archived, a warning is given; the user may abort or continue (and lose the changes to the current version). Choosing Directory supplies a list of the versions available of the currently selected filetype. Zero initializes the current version of the specified file; this is used to start from scratch when creating a new version. If the current version has been modified and not archived, a warning is given; the user may abort or continue.

File Notes provides an on-line mechanism to keep track of the uses of each file version; ARONTS does not use this internally. A sample usage is shown in Screen #46. Operation is identical to Module Commands (section 6.4.6).

{Escape} from Screen #45 exits and returns to the Main Menu.

Screen #46

Backup/Retrieve Options

Selecting Backup/Retrieve from Screen #45 results in the menu of Screen #47. Data files, archives, and programs are shown. In addition to the modified attribute and date of last change, the file size (in bytes) is displayed. The files in the example screen are for an ARONTS system set up for 500 sites.

Screen #47

In order to Backup a system file to a floppy disk, the (formatted) disk is placed into either drive, and Backup selected. Retrieve performs the same operation in reverse -- a previously backed up file is extracted from the floppy disk, and overwrites the existing file on the hard disk. A directory of either floppy disk is available by selection of Floppy Directory.

Backups should be performed periodically in order to safeguard the information in the system. It also can be used to save a particularly interesting Failure Log prior to clearing it, if desired. Keeping all files safely copied makes it possible to transfer the data to a different PC, or to retransfer data back to the original system's hard disk should some event cause data loss. The File Maintenance Backup/Retrieve screen prominently displays the files which require backups.

The larger files are automatically compressed prior to performing a backup. A request to back a file up to floppy has several possible outcomes. If a disk is not inserted into a floppy drive, or the disk is not formatted, nothing is done. If there is sufficient remaining room on the floppy for the particular file chosen for backup, it is copied. If insufficient space exists, but the size of the floppy disk is such that a clean disk can hold the requested file, the user is prompted to try again with a new disk; no change is made on the first attempt. Programs can only be backed up to a high density floppy disk (> 1 mByte). All other files which are larger than the size of the floppy disk used are broken into smaller fragments and stored in multiple disk sets. A prompt informs the user approximately how many disks are necessary. Multiple disk copying does not require disks past the first to previously be formatted; and all files in the root directory are destroyed. Disks must be consecutively marked in this situation so that they can be submitted in the same order when retrieved. If a multiple disk backup is interrupted (by removing the floppy, ^Break, or disk error) the Modified attribute may incorrectly show unmodified.

{Escape} from Screen #47 returns to Screen #45.

7. TEST CONSTRUCTION

There are many possible ways to construct tests with ARONTS. This section gives direction to the process of assembling test schemes, with examples for assistance.

7.1 Versions

File versions permit many different test scenarios to be constructed, archived, and retrieved when needed. It is recommended that the Test Numbers and Dialing Registers files not be given multiple versions except for very special test cases, where it is not likely that multiple partition operation is needed. Although it is possible to construct independent sets of Test Definitions/Test Numbers/Dialing Registers files which operate in trios, doing so effectively limits ARONTS to one partition. If many Test Definitions versions use the same Test Numbers and Dialing Registers files, up to four Test Definitions can be used in test partitions simultaneously.

Test Definitions versions should segregate testing into Milliwatt, Manual DTMF, and RTS-1 Programming groups. Should reprogramming of RTS-1 parameters be needed, the particular parameter can be placed into a Dialing Register which is allocated (always) to the RTS-1 command. The Test Definitions file version archived for RTS-1 control can be made current, a Test Schedule prepared to match all RTS-1 sites (or retrieved from the archive), and the test run performed.

Similarly, Test Definitions using Manual DTMF tests should not contain any other type of test. This has two effects: personnel monitoring test calls need not waste time monitoring completely automatic tests, nor have the possibility of incorrectly intruding on tests (and ruining them) which do not require human assistance; and the Manual DTMF Test Definitions file version can be given its own partition so that personnel can monitor that partition while other test ports are occupied placing test calls that can be handled by machine.

Test Definitions versions directing test calls to Milliwatt tones may be given their own port partition in combination with any other type of test.

Although Test Definitions should be broken down into these minimum three groups, it may be desirable in some cases to further subdivide these categories. A prime example is Manual DTMF tests. These typically are test calls which are intended to terminate to particular operators, long distance networks, or specific voice recordings. If the tests are divided into groups based upon the destination, it makes it much easier for the person monitoring the test call to make a quick determination as to the success or failure of the particular test. For example, a Test Definition can be created which includes all test calls to AT&T operators; another to MCI operators; another to C&P operators; and another to a recorded voice message in Switzerland. Assume that four people are assigned to the test process. Each of these Test Definitions can be given a one port partition, and the four people assigned to those ports.

Person #1 need only be told that if the call reaches AT&T, to say "Testing, Thank you" and enter DTMF digits 000 (recorded as a Success). A list of DTMF codes can be assigned to the other possibilities, and if the wrong operator is reached, the tester can quickly enter the appropriate code according to that list: say 001 if MCI is reached, 002 if Sprint is reached, etc. In this way, the testing personnel need only keep in mind what is expected, and if incorrect termination occurs, enter one of several discriminating codes. The Failure Log then provides a record of who the incorrect operator was, in addition to pass or fail.

Similarly, the second and third testers enter the Success code if their assigned operators are reached; the same codes for incorrect operators can be used. An alternative method is to have each person simply enter the DTMF code according to the operator reached; this eliminates the necessity of breaking the Test Definitions files down into separate versions according to operators expected. However, there are two drawbacks to doing so: the Failure Log must be inspected and the individual tests classified manually as Success or Fail by checking if the recorded DTMF code corresponds to the expected result; and secondly, it is easier psychologically to make a quick determination while monitoring a test call if it is known in advance what is expected.

Person #4 in the above example enters 000 if the Swiss recording is reached; and perhaps some other predefined DTMF codes breaking the incorrect result down by the type of failure.

Certain files do not have versions; these are not intended to vary by test scenario. However, should a circumstance occur where it is desired to temporarily change one of these files for a particular test set, the file can be backed up to floppy disk using the File Maintenance menu; the file changed and used; optionally backed up to a different floppy disk for later use; and the file retrieved from the first floppy disk, restoring the file to its original form. This does not take long to execute, and can be done without going to the Dos prompt.

7.2 Test Definitions

Test Definitions can be created in a simplistic sense by assigning each individual test its own Group. One Dialing Register and one Test Number can be specified, with the number of Tests set to one. This method works if the type of testing is fairly limited, but quickly becomes unmanageable for comprehensive test sets. This technique is limited to five actual tests per Test Definition, and a large number of Continued Test Definitions is the most likely result. A more efficient scheme organizes the tests into logical sequences.

Test Number Assignment

Each Test Definition Group can refer to Test Numbers in a range of 100. It is therefore desirable to assign Test Numbers in ranges such that numbers most likely to be tested together (with the same dialing pattern) are consecutive. Suppose that a particular Site is to be tested for proper call routing. The (milliwatt) test calls are generally grouped into three categories: 1 + 10 digits; 1 + 7 digits; and 7 digits. The first category is inter Area Code, inter Lata, toll calls. These numbers are essentially reachable from any site in the same fashion, with the only exceptions being the sites where the terminating test number happens to be near the site. These global test numbers are going to be called from every site, with some numbers excluded on a site-by-site basis. As an example, assign Test Numbers 1-100 to this category.

The second above category consists of intra Area Code calls. There are probably several Test Numbers to be called from sites within their Area Code, and these numbers are different in every Area Code. Suppose that the sites of interest are located in 12 different Area Codes. Test Numbers 101-110 can be assigned to Area Code wide tests for the first Area Code; 111-120 to the second Area Code; until Test Numbers 211-220 are assigned to the twelfth Area Code.

The third above category consists of local calls. There are probably several Test Numbers to be called from sites within their local calling areas, and these numbers may be different in every calling area. Suppose that the sites of interest are located in 100 different local calling areas. Test Numbers 1001-1010 can be assigned to local calling area tests for the first calling area; 1011-1020 to the second calling area; until Test Numbers 1991-2000 are assigned to the 100^th calling area.

Assume that Dialing Register 10 handles 1 + 10-digit calls for RTS-1 sites; Dialing Register 20 handles 1 + 10-digit calls for Hot Shoe sites; Dialing Register 30 handles 1 + 7-digit calls for RTS-1 sites; Dialing Register 40 handles 1 + 7-digit calls for Hot Shoe sites; Dialing Register 50 handles 7-digit calls for RTS-1 sites; and Dialing Register 60 handles 7-digit calls for Hot Shoe sites.

In this example, the Test Definition for all sites allocates Group 1 to the first category, Group 2 to the second category, and Group 3 to the third category. All RTS-1 sites specify Test Numbers 1-100 with Dialing Register 10; this can be entered once, and cloned to all RTS-1 sites. Similarly, all Hot Shoe sites specify Test Numbers 1-100 with Dialing Register 20.

The next step is to handle the area code specific changes. For the first area code, the Test Numbers in Group 1 with that area code are removed; and Test Numbers 101-110 are specified in Group 2 with Dialing Register 30 for RTS-1 sites, and Dialing Register 40 for Hot Shoe sites. This Test Definition is then cloned to all sites with the same area code (first for RTS-1 sites, second for Hot Shoe sites). This is repeated for all area codes.

The last step is to handle the local calling area specific changes. For the first calling area, the Test Numbers in Group 2 with that calling area are removed; and Test Numbers 1001-1010 are specified in Group 3 with Dialing Register 40 for RTS-1 sites, and Dialing Register 50 for Hot Shoe sites. This Test Definition is then cloned to all sites with the same calling area (first for RTS-1 sites, second for Hot Shoe sites). This is repeated for all calling areas.

The above process accomplishes the minimum amount of data entry, since the differences are cloned to compatible groups. The resulting Test Definitions file tests all appropriate Test Numbers with only three Groups per definition. It is also helpful to archive the Test Definition at each of the three points above, so that it is possible to go backwards and redo the definitions at later stages (which indeed do overwrite some of the previous entries) without starting at the beginning, should an error be made and cloned to a large number of sites.

Dialing Register Assignment

There are instances where the same Test Number can be dialed in a variety of ways, and testing of each is required. Three examples are: different physical lines; different IXC's; and methods of dialing.

The Test Definition permits consecutive Dialing Registers to be used to repeat test calls for all Test Numbers listed in the Group. By placing appropriate Dialing Registers in numerical order it is possible to greatly enhance the coverage of a Test Definition.

The first example involves testing different test lines connected to RTS-1's. These may be of different classes of service, such as single party, coin, etc., or may be presubscribed to different carriers. The dialing method may differ between them. However, Dialing Registers can be created which handle the appropriate dialing pattern for each, including the code to select the appropriate RTS-1 outline. It is assumed that the RTS-1's are deployed in a uniform fashion so that the outline numbers correspond to the same classes of service. If outlines 13, 14, 15, and 18 are to be tested, then Dialing Register 10 can be created to place a 1 + 10-digit call on RTS-1 outline 13; Dialing Register 11 can be created to place a 1 + 10-digit call on RTS-1 outline 14; Dialing Register 12 can be created to place a 1 + 10-digit call on RTS-1 outline 15; and Dialing Register 13 can be created to place a 1 + 10-digit call on RTS-1 outline 18. Similarly, Dialing Registers 30-33 can be set for 1 + 7-digit calls, and Dialing Registers 50-53 set for 7-digit calls.

The second example involves testing different 10xxx codes. The same Test Number is to be dialed with a 10288 prefix to verify AT&T connection, and repeated with a 10222 prefix to verify MCI connection. Dialing Register 14 can be created with the 10288 prefix, and Dialing Register 15 with the 10222 prefix. Similarly, Dialing Registers 24 and 25 can be created for Hot Shoe calls. If desired, the same idea can be applied to the 1 + 7-digit registers.

The third example involves testing different methods of dialing. Dialing Register 16 can be created to command RTS-1's to dial at the fast DTMF speed (10 digits per second); Dialing Register 17 can be created to command RTS-1's to dial at the slow DTMF speed (5 digits per second); and Dialing Register 18 can be created to command RTS-1's to rotary pulse dial. Similarly, Hot Shoe Dialing Registers can be programmed to fast DTMF dial and slow DTMF dial (from ARONTS directly); pulse dialing is not possible with these sites.

The above examples assigned consecutive Dialing Registers to various types of tests which can be repeated with the same Test Numbers, varying some parameter on each repetition. With this organization, all that need be done to activate these multiple tests is to specify the number of consecutive tests in the Test Definition. This example, which combines more tests than would most likely be desired in one Test Definition version, could set the number of tests in Group 1 for RTS-1 sites to 9. This would cause Test Numbers 1-100 (with the subsequent exclusions) to be dialed nine different times: the first four with different RTS-1 outlines; the next two forcing AT&T and MCI connection; and the last three dialing fast and slow DTMF, followed by rotary pulse.

Much of the above entries can be handled by cloning, restricting matches to various area codes, area codes + exchanges, and site type. After the Test Definition is prepared in this manner, individual differences in sites (such as lack of certain lines on RTS-1 units) can be entered, customizing the definition to the exact situation.

7.3 Dialing Registers

This section deals with construction of Dialing Registers to handle different types of calls. The complete definition of nonsubstitution Dialing Register commands is in section 9.4; this section is included primarily to describe substitution commands and to present examples of commonly used structures.

Dialing Registers can be as long as 79 actual characters and 100 characters after the substitution commands are expanded. Spaces are transparent, and are placed only to make the information more understandable to the viewer. Upper and lower case is significant.

Dialing Registers are used for two completely separate functions: to access a site, and place test calls. In general, there are a small number necessary to access sites, and potentially a large number required to make actual tests.

7.3.1 Substitution Dialing Register Commands

There are six Dialing Register commands for which the Control Computer substitutes digits prior to sending the command to the Test Module:

ax: Access Number tx: Test Code, Access Code px: Program Code, Authorization Code nx: Test Number c: Credit Card Number s: Secret Authcode

Each of these are lower case letters; those followed with an x must be appended with a single numeric digit, or *. If a numeric digit x = 1-9 is used, the last x digits of the specified field are used; for x = 0, the last 10 digits of the specified field are used; and for x = *, all of the digits of the specified field are used. The t and p codes represent the Test Code and Program Code for RTS-1 sites, and the Access Code and Authorization Code for Coded Hot Shoe sites.

7.3.2 Access Registers

Typical Dialing Registers used to access the various types of sites are:

1: W1 1a* W1 WB WD 2: W1 1a* W1 p* W1 P50 t* WB WD 3: W1 1a* W#0130 Q #t* W#0103 Q 0245 W#0103 Q WB WD 4: W1 WB WD 5: W1 1a7 W#0130 Q #t* W#0103 Q 0245 W#0103 Q WB WD 6: W1 a7 W#0130 Q #t* W#0103 Q 0245 W#0103 Q WB WD

All registers used to access a site must end with WB WD, and leave the site in a mode in which it is prepared to accept a dialing command.

Register 1 above is used for Simple Hot Shoe sites: it waits for local (ARONTS test line) dialtone (W1); dials 1; dials the entire access number (for domestic 1 + 10-digit calls); waits for the Hot Shoe dialtone (W1); clears the area used to record information later on (WB); and transfers the call from the Test Module to the ARONTS Control Computer (WD).

Register 2 above is used for Coded Hot Shoe sites: it waits for local (ARONTS test line) dialtone (W1); dials 1; dials the entire access number (for domestic 1 + 10-digit calls); waits for the Hot Shoe dialtone (W1); changes the default DTMF dialing speed to one per second (P50); sends the entire Authorization Code (t*); clears the area used to record information later on (WB); and transfers the call from the Test Module to the ARONTS Control Computer (WD).

Register 3 above is used for RTS-1 sites: it waits for local (ARONTS test line) dialtone (W1); dials 1; dials the entire access number (for domestic 1 + 10-digit calls); waits for the RTS-1 Access Prompt (W#0130, wait up to 30 seconds for one DTMF digit); pauses a quarter second (Q); sends DTMF #; sends the entire RTS-1 Test Code (t*); waits for the RTS-1 Test Prompt (W#0103); pauses a quarter second (Q); commands the RTS-1 to utilize a 45 second timeout on all subsequent test calls (0245); waits for another Test Prompt (W#0103); pauses a quarter second (Q); clears the area used to record information later on (WB); and transfers the call from the Test Module to the ARONTS Control Computer (WD).

Registers 5 and 6 are identical to register 3 except that they access RTS-1 sites requiring 1 + 7-digits and 7-digits to reach the site location.

Register 4 above is used to place test calls directly from the ARONTS telephone lines: it waits for local (ARONTS test line) dialtone (W1); clears the area used to record information later on (WB); and transfers the call from the Test Module to the ARONTS Control Computer (WD).

The Access Register for each site is set to the appropriate Dialing Register. Potentially, three different Dialing Registers can be required for each of the three Site Types, in order to access: long distance sites (1 + 10-digits); nearby sites (1 + 7-digits); and local sites (7-digits). These nine access registers plus one required for direct tests from ARONTS lines makes a total of ten access registers for most situations. Dedicated networks may have additional dialing codes in order to reach special circuits; these may be handled with additional access registers. The RTS-1 access registers may require the timeout command to be removed for credit card calls (see below), and if RTS-1 commands are to be issued, the Test Code can be replaced with the Program Code, or as is shown in a later example, left as is.

7.3.3 Test Call Registers

Dialing Registers used to place test calls are configured to permit a smooth progression from the completion of an access register to dialing an actual number. Registers used to place test calls for Hot Shoe sites begin with whatever actual dialing pattern is desired; those used to place calls with RTS-1 sites use a beginning portion to command the RTS-1 to place the test call. Either type then continues with a portion dedicated to detecting the test result, and differs for Expected results of Milliwatt, RTS-1, and Manual DTMF. RTS-1 test registers continue with a portion used to terminate the test call and return to the Test Prompt. Some call types add special instructions after the initial dialing.

Test Register =
[RTS-1 command]
(Dialing Pattern)
[RTS-1 command end]
[Special instructions]
(Detection part)
[RTS-1 call termination]
(Completion part)

Examples of RTS-1 commands are:

1: Q 22 (Dialing Pattern) A# WC10AE 2: Q 28 (Dialing Pattern) A# WC10AE 3: Q 223 (Dialing Pattern) A# WC10AE 4: Q 34 (Dialing Pattern) A# WC10AE 5: Q 46 (Dialing Pattern) # MS08

The first example pauses a quarter second (Q); sends DTMF 22, the RTS-1 command to DTMF redial a number at 10 digits per second on outline #2; the dialing pattern to be redialed; the DTMF digit A; the command terminator #; and a command to wait up to 10 seconds to receive the DTMF digit A (WC10AE). The A is used as a simple method for ARONTS to be notified when the redialing has been completed; ARONTS does not continue on to the Detection part until the A has been received, which does not affect the line dialing.

The second example is the same except that outline #8 is selected. These two examples are for single module RTS-1's, which do not require a Module digit in order to identify a line. Example 3 is for a 2-module RTS-1, and it places a test call on outline #3 of module #2. Example 4 commands the RTS-1 to slow DTMF dial on outline #4 (single module RTS-1). The last example pulse dials on outline #6. An eight second delay (MS08) is appended as a compromise so that ARONTS timing does not begin too early; some time is required to pulse dial a number, and there is no indication to ARONTS when the number has completed dialing.

The detection part tells ARONTS to begin looking for the call termination, and is of one of the following types:

Milliwatt: WB W*4530 RTS-1: WB W#T0103 DTMF Code: WB W#T0345 MS05

The Milliwatt code indicates to look for Milliwatt, SIT, Busy, Reorder, Ringing, Voice, or 4 DTMF digits, or less than 4 DTMF digits if 5 seconds elapse after the last one; and to look for these tones up to 30 seconds. The RTS-1 code indicates to wait up to 3 seconds (03) to receive 1 (01) DTMF digit, and to time how long it takes to get the response (T). This code comes after an RTS-1 command, so a Test or Program Prompt is expected as an acknowledgment. The DTMF (manual) code is similar, except that it is programmed to wait up to 45 seconds to receive 3 digits. A 5 second delay is placed after the DTMF detection to give the user time to place the monitor telephone on-hook, so that when the test call is complete, ARONTS can control the line without interference from the monitor phone (it may be hanging up the line).

The RTS-1 call termination is WQ35 ###, which waits up to 35 seconds for quiet (the milliwatt tone to interrupt) prior to sending ### to the RTS-1 to release the test call.

The completion part is WD for Hot Shoe calls and WE03 W0 for RTS-1 calls. The former transfers control to the Control Computer, and the latter waits up to 3 seconds for the RTS-1 to exit (and send a DTMF Test or Program Prompt). The W0 generates a failure for the case when the RTS-1 does not respond to the initial call termination command.

It is not usually necessary to change the above pieces of Test Dialing Registers, other than to set the timeout delays and RTS-1 outline numbers as desired. The dialing pattern portion requires matching to the desired type of test call.

Simple Dialing Patterns

The dialing pattern portion of the Dialing Register just states how the call is to be dialed. Examples are:

1 + 10-digits: 1 n*, 1 n0 1 + 7-digits: 1 n7 7-digits: n7 0 + 10-digits: 0 n*, 0n0 0 + 7-digits: 0 n7 0- : 0 International: 011 n* Service calls: n3

The 0+, 0-, and service calls may require a detection part of Manual DTMF, and the 0+ may be used in conjunction with a special instruction to handle credit card calling; this section is limited to a discussion of the dialing pattern portion. The service call example assumes that the service numbers are placed into the last three digits of the Test Number, such as: (000)000-0411 or (000) 000-0611. Two complete Dialing Registers for an RTS-1 are:

Q 32 1 n* A# WC10AE WB W*4530 WQ30 ### WE03 W0
Q 32 n3 A# WC10AE WB W#T0345 MS05 WQ30 ### WE03 W0

The second example uses a Manual DTMF Code. An example for a Hot Shoe:

1 n* WB W*4530 WD

Dial-up Services

Some types of services offer calling after first dialing an access number, receiving a second dialtone, and entering an authorization code. The code is entered into ARONTS from the Setup options as the Secret Authcode. Examples of its use are:

5551234 W3 s S n* 1 800 5551234 W2 s S 1 n* 1 n* W3 s S 1 800 5554321

The first example uses 555-1234 as a local access number; waits for precise dialtone (W3 does not false on ringback tone, while W1 might); sends the Secret Authcode (s); pauses one second (S); and dials the entire (10-digit) Test Number without a leading 1. The second example dials an 800 access number and waits for 400 Hz "ready" tone (W2); sends the authcode; pauses one second; and dials 1 + the 10-digit Test Number. The last example uses the Test Number as the service access number; inserts a leading 1; waits for a second dialtone; sends the authcode; pauses one second; and dials a fixed 10-digit terminating number with a leading 1.

Credit Card Calling

0+ test calls can return a "bong" tone, afterwhich a credit card number is expected. The bong signal may be detected in several ways. In many cases it contains a DTMF #; this can be detected with a WC command. If the DTMF digit is not present, or if the signal loss is too great to reliably detect the #, a general purpose energy detector can be used with the WT command. No matter how the tone is detected, if it has an embedded #, the RTS-1's must not be programmed to time out on test calls (the 02xx) command. When this RTS-1 option is invoked, the test call is terminated with a single # in addition to ###. The result is that the bong commands the RTS-1 to hang up the call. This can be addressed in two ways: the simplest is to remove the 02xx from the RTS-1 access Dialing Register when credit card calling is being performed; the second method is to have the credit card Dialing Register command the RTS-1 to remove the timeout and restore it when the test call has completed. The latter method requires a considerable number of digits and generally requires continued Dialing Registers.

The credit card number is entered into ARONTS from the Setup options. Examples of its use are:

WC30#E SS c MS04 WT302222102 SS c MS04

These codes are placed after the dialing pattern (0+) and before the detection part as the Special Instructions. The first example waits up to 30 seconds to receive a DTMF #; pauses 2 seconds to be sure that the tone is clear; sends the credit card number (c); and pauses 4 seconds. The last pause is necessary because in many credit card calls, before the call is actually placed, the carrier places a short voice message similar to, "Thank you for using carrier X". If the W* command is active at this point, it may detect the voice and stop the test as a voice detection. The last pause must be long enough to ensure that this message is skipped, but not so long that the connect time statistics are skewed, or possibly even a response tone is missed.

The second example uses an energy detector instead of a DTMF detector. An added advantage of this is should the bong go undetected, after several seconds usually a voice message appears prompting the user to enter a credit card number. The energy detect will trip on the voice, and the call successfully placed. The above example is set to look for approximate 800 Hz energy which lasts for a duration of 0.2 seconds.

Call Reorigination

Some services offer a call reorigination feature. Dialup services and credit card calls often fall into this category. The reorigination feature itself can be tested by continuing Dialing Registers: the first register places a call as previously discussed, and it is handled as normal; that register is continued with another Dialing Register which sends the reorigination command and digits sufficient to place a second call. This process can be repeated if necessary. A dialup service example is:

Q32 18005551234 A# WC10AE WT302222102 SS s SS n* WB W*4530 WD

set to Expect Milliwatt and Continue with:

WQ30 M3#SSM0 SSSS n* WB W*4530 WQ30 ### WE03 W0

which is also set to Expect Milliwatt. These are complete Dialing Registers for use with RTS-1's. The first register commands the RTS-1 to slow DTMF dial an 800 service access number; wait up to 30 seconds for a tone or voice prompt (no ringing allowed); pause 2 seconds; enter an authcode; pause 2 seconds; send the Test Number; detect the Milliwatt; log the test result (WD) and continue with the next Dialing Register. The second register waits for the Milliwatt to drop off (WQ30); sends a 2-second DTMF # to cancel the call through the service and reoriginate a second call; a 4 second pause to receive the prompt; send the (same) Test Number; detect the Milliwatt; and the standard RTS-1 call termination exit sequence.

A credit card RTS-1 example is exactly the same, except that the first call is placed as a 0+ number with a credit card code:

Q32 0 n*A# WC10AE WC30#E SS c MS04 WB W*4530 WD
WQ30 M3#SSM0 SSSS n* MS04 WB W*4530 WQ30 ### WE03 W0

For Hot Shoe sites, this would be:

0 n* WC30#E SS c MS04 WB W*4530 WD
WQ30 M3#SSM0 SSSS n* MS04 WB W*4530 WD

A dial-up service Hot Shoe test pair is:

18005551234 WT302222102 SS s SS n* WB W*4530 WD
WQ30 M3#SSM0 SSSS n* WB W*4530 WD

RTS-1 Programming

ARONTS can be used to access RTS-1 units expressly for the purpose of changing parameter settings. If the Access Register is modified to use the Program Code instead of the Test Code by:

W1 1a* W#0130 Q #p* W#0103 Q WB WD

then program instructions can replace Test calls:

75215 WB W#T0103 Q WD

and in the above example, the RTS-1 is programmed for an Overall Time per session of 15 minutes.

If the Access Register is not changed (still using the Test, not Program Code), then the Dialing Register used to change parameters (Test call register) can be set to exit Test Mode and enter Program Mode, followed by the intended command:

Q01 W#0106 Q #p* W#0103 Q 75215 WB W#T0103 Q WD

The Test registers are set to expect RTS-1 responses. Additional programming functions can be added by Continuing the register to another with more commands, such as:

741 8732# 8732# WB W#T0103 Q WD

which changes the Test Code to 8732. After changing the Test or Program Code this way, the new codes must be placed into the proper fields in Site Information.

It is a safer procedure to reserve use of the RTS-1 Program Code to those instances when it is required; erroneous programming is prevented by using the Test Code for normal test calls.

Trunk Testing

ARONTS is oriented towards originating test calls from remote locations, but it also can place test calls directly from its test lines. Section 7.3.2 gives an access register for such use. The site type should be Simple Hot Shoe. These test call Dialing Registers are identical to Hot Shoe equivalents. If ARONTS is connected through a trunk interface rather than a line side interface on a CO or IXC switch, it can be used to test the CO directly. Equipped with a loop reverse battery interface (optional equipment), it can be programmed to generate Feature Group D originating calls directly to an IXC switch:

W5 *00 3015551234# *n0# W5 WB W*4530 WD

ARONTS waits for a Start Wink and initiates MF output mode (W5); sends KP (*); sends 00 as the II code (identified party); sends the ANI as (301)555-1234; sends ST (#); sends KP (*); sends a 10-digit Test Number (n0); sends ST (#); waits for an Acknowledgement Wink (W5); and waits for the call to be terminated to a Milliwatt signal. When trunk connections are used, the Access Register should simply be WB WD.

In similar fashion, other Feature Group tests can be constructed.

8. COMPUTER CONFIGURATION

The Control Computer hard disk drive is organized into several directories and logical drives. If a change of the Control Computer is desired, or disk reinitialization required, the hard drive must be set up for the ARONTS environment. This can be done as follows:

1. The backup disk labelled System should be placed into Drive A:, and the computer reset.

2. When booting has completed, the following commands should be entered if the hard disk requires reformatting:

A:> Format C: /s /v
A:> Format D: /v3. The system disk should be copied:

A:> XCopy *.* C: /s /e

4. After removing the floppy disk, the computer should be rebooted, and the following commands issued:

C:> Cd \Aronts C:> Md D:\Report

5. After inserting the current Programs disk into Drive A: (or B:, changing A: below to B:), the following command should be issued:

C:> XCopy A:\Aronts

6. Using the current backup disk with the Setup.Dat file in Drive A: (or B:, changing A: below to B:), the following command should be given:

C:> Copy A:\Aronts\Setup.Dat

7. These commands should be entered:

C:> Copy AutoExec.Bat \ C:> Copy Config.Sys \ C:> InitLog

8. The Test Module must be connected to a serial port at COM1:.

9. A modem must be present at COM2:. If not, the line in Menu.Bat

Set MODEM=COM2

should be changed to:

Set MODEM=COMX

The simple text editor VMFile can be used to do so by:

C:> MapKeys C:> VMFile Menu.Bat

10. The computer should be rebooted without a disk inserted.

11. After going directly to File Maintenance, all files should be Retrieved from the most recent backup disks.

(This step-by-step procedure is given rather than using an installation batch file to permit omission of selected steps if the situation so dictates.)

9. TEST MODULE

The Test Module can be configured in sizes from 1 to 48 ports. The module consists of three subsystems: telephone line couplers; Tone Controllers; and a control system. The line couplers interface the telephone lines with the tone units. The Tone Controllers handle all tone generation and reception. The control system is actually a distributed network of microprocessors, performing the following functions: interfacing with the control signals from the couplers to carry out the supervisory activities of ring and hangup detection and control of on- and off-hook conditions; provision of DTMF and SIT tone encoders and decoders, dial tone, ready tone, and milliwatt tone detectors and generators; preprocessing of test generation sequences (access number, test code, line identification, and test numbers) and postprocessing of test results (success/failure, release connection, log off); and interfacing with the Control Computer through a serial line. It is the function of the controller to perform all duties of ARONTS with the exception of actual test sequencing and result logging-- these are the functions of the Control Computer. This section describes how the Test Module operates; commands and options included here are not necessarily exercised by the Control Computer in the ARONTS environment.

9.1 Typical Operation

The Control Computer preloads the Test Module with dialing registers which do not change from test to test (QS commands). For each site access and ARONTS line, the Control Computer assembles a dialing register specifying how that site is to be called, from the access register in the Site Information record. The Computer then stores this expanded access register as dialing register Z (temporarily) and commands the Test Module to place the call, specifying the outgoing telephone line, related Tone Controller, and dialing register Z (XTQ command). The Test Module then takes the line off-hook (seizes the line). The Tone Controller is allocated to the call; register Z is transferred to the Tone Controller's internal memory; and it executes the commands contained in that dialing register.

When the operation is complete, the Tone Controller notifies the Master Controller, and the Master Controller notifies the Control Computer by sending a $. The Computer reads all information collected regarding this call, and determines the next test which is to be made. A test dialing register is constructed for that particular call from the register contained in the Test Definitions file; the Computer then stores this expanded test register as dialing register Z (temporarily) and commands the Test Module to make the test call (XC command). Register Z is transferred to the Tone Controller's internal memory, and it executes the commands contained in that dialing register. The Tone Controller dials the test call, and then monitors the call.

When complete, the Tone Controller commands the RTS-1 to terminate the test call, and the Control Computer is notified with another $. The Control Computer reads all of the pertinent information on the test call, and continues with all test calls scheduled for that location. When all calls are finished, a dialing register is specified which terminates the session with the RTS-1 (hangup command, 00), and the session is ended (with an XK command) by hanging up the outgoing line. Hot Shoe calls are similar, but are hung up after each test call with an XK command. The above actions take place for all lines simultaneously, each Tone Controller handling its own tasks independently.

9.2 Communications Protocols

The Test Module communicates with the Control Computer with serial asynchronous characters. This consists of the standard start bit, eight data bits, and one stop bit. The speed is switch selectable, nominally set to 9600 baud. For ease of diagnosis and simple monitoring, communication is through printing ASCII characters, available from a standard keyboard. Lower and upper case letters are distinct. Two forms of communication take place: notification, and interaction.

Notification symbols can be transmitted from the Test Module to the Computer when an appropriate condition occurs, without being requested by the Computer. These provide notification of some condition which requires action. These conditions, and the corresponding characters, are:

$ call action complete, requires next command
@ Hangup: a line has lost loop current
D Dialing failure: an expected tone has not been received
* An incoming call has been answered (only if enabled)

For each of the four notification symbols, if the proper response is not received from the Computer, they are indefinitely repeated at twenty second intervals. Other than for notification of these four conditions, no communications are ever initiated by the Test Module.

The Computer initiates interactive communications. A sequence of characters of variable length, sent by the Computer, commands the Test Module. These commands produce a response from the Test Module; however, no more than a single character is sent by the Test Module to the Computer for each request. The controller responds with ? if an undefined command is received from the Computer (syntax error). Receipt of notification symbols by the Computer must be handled by certain required interactive commands. These are as follows:

$, D -- any X command
@, * -- G, P, and r

These commands must be used to cancel the twenty second repetition of the associated notification symbol. It is expected that prior to these commands for the $ and D, additional commands will be issued by the Computer. These are:

$ -- W, G and P, and either R or B
D -- G, P, and DF

Upon transmission of $, D, @, and *, the current call status is set; this is cleared after the required command is received. The current call group and port are set to the port affected.

Twenty-six dialing sequence registers, labeled A-Z, are available for outgoing calls. These dialing registers are loaded from the Computer, and can be read back. In addition to the standard DTMF, MF, and SIT tones, special codes may be embedded within the dialing sequences for such purposes as wait for dial tone.

The telephone ports are organized into sides, groups, and ports. There are two sides, side 1 and side 2. The telephone lines are broken down into groups of 12 ports; there can be a maximum of 2 groups on each side. Side 1 groups are labelled as a-b, and Side 2 groups are labelled as A-B. There are 12 telephone ports per group, labelled A-L.

Should the Test Module detect a command syntax error, it waits until no characters have been received from the Computer for a half second interval, then sends ?, and waits for a new command. The maximum length of time between characters in one command sequence is five seconds; if this limit is exceeded, it is treated as a syntax error. Notification characters are not sent until a half second has elapsed from the last Test Module response without any further requests from the Computer (the r command is used to defeat this delay).

9.3 External Communications Protocols

The interactive commands listed in this section are protocols which have use outside of the Test Module. They are used between the Test Module and Computer, and directly with a terminal for diagnostic action.

9.3.1 Summary of Interactive Command Protocols

Initialization Commands

I*--Initialize all 
IL--Initialize Lines 
IRNG--Initialize RiNG status 
I$Y--Initialize $$$$$$$$$ to Yes 
I$N--Initialize $$$$$$$$$ to No 
ITxxxxxxxx--Initialize Time 
INDAxyz--Initialize Don't Answer line xy to z 
INIGxyz--INitialize IGnore disconnect on line xy to z 
IMARKPxyz--Initialize MARK Port xy to type z 
INDCxyzz...zX--INitialize Direct Connection port xy 
INLTIMxyzzz--INitialize Line TIMe x for linetype y to zzz 
INACxyz--INitialize Area Code to xyz 
IN10XXX#x--INitialize 10XXX# option to x 
INDR--INitialize Dialing Registers 
INMODULEx--INitialize MODULE name to x 
IHxyz--Initialize Holding length of register x to yz 
IEWxyz--Initialize Enter Wait type x to yz seconds 
IDWxyz--Initialize Dialing Wait type x to yz seconds 
IBPxyz--Initialize BeeP type x to yz beeps 
IP--Initialize all Pointers 
IN0+x--INitialize 0+ dialing to collect authcode 
INTCFAILxyz--INitialize Tone Controller xy FAIL to z 
IDLETCt--IDLE Tone Controller t 




Fast Commands 
R--Read auth./travel code, telephone number, billing code 
B--read Billing code 
T--read Time 
G--read Group of current call 
P--read Port of current call 
W--determine Which Tone Controller is assigned current call 




Continue (Xfer) Call Commands 
XK--Xfer current call to Kill 
XH--Xfer current call to Hold 
XW--Xfer current call to Wait for billing code 
XCz--Xfer current call to dialing register z 
XD--Xfer of current call is Done 
XMQxy--Xfer current call for xy More digits Quietly 
XMDxy--Xfer current call for xy more digits with Dialtone 
XFGDW--Xfer current call to Wait for billing code, Feature GroupD 


(The above X commands cancel "$" or "D") 
XOCxy--Xfer Old Call on group x, port y, to Current status 
XQxyz--Xmt (transmit) to group x, port y, seQuence z 
XTQtxyz--Xmt seQuence using specific Tone Controller 






Dialing Sequence Commands 
QSxyy...yX--seQuence Store x as yy...y 
Q#xx...xX--seQuence store telephone # (number) as xx...x 
QAUTHxx...xX--seQuence store Authorization code as xx...x 
QT#txx...xX--Q#, specific Tone Controller 
QTAtxx...xX--QAUTH, specific Tone Controller 
QRx--seQuence x Read 




Special Commands 
LMxy--Line Make group x, port y 
LBxy--Line Break group x, port y 
LHxyz--Line Hook group x, port y to state z 
LWxy--Line Wink group x, port y 
AC--determine AC power line status 
DF--determine which Dial tone wait Failed 
r--ready for notification character 




Control Commands 
SIZE--obtain Test Module system SIZE 
MODULE--obtain MODULE name 
QTONE--obtain number of Tone Controllers in system 
LOCK--LOCK out controller from serial line 
UNLOCK--UNLOCK controller from lock command 
DELAYxy--DELAY 2xy ms after output for multiple charac ters 
STATUS, status--print current system STATUS 
SAVE--SAVE parameters 
LOAD--LOAD parameters 
DRDISP--Dialing Register DISPlay 
SAFE--place the switch into a SAFE mode 
UNSAFE--place the switch into an UNSAFE mode 
DEBUG, debug--enter DEBUG monitor program 
MCRDaaaa--ReaD Master Controller address aaaa 
SLFTST--have the Master Controller test itself 
LOKCM--LOcK access to restricted CoMmands 
UNLCM--UNLock access to restricted CoMmands 




Restricted Commands 
INTOTALS--INitialize TOTALS to 0 
INPORTSTATS--INitialize all PORT STATisticS 
DISPSTATSxy--DISPlay port STATisticS 
DISPDCxy--DISPlay Direct Connect authorization codes 
INIT--INITialize entire system 
CALL--CALL a subroutine previously written into memory 
MCWRaaaadd--WRite data dd at Master Controller address aaaa 
COMMbbndd...dd--COMMunicate with board bb (n dd bytes) 
MBUFC--Clear input BUFfers on 16 Tone Controllers (Matrix Test)

9.3.2 Interactive Command Protocols

Initialization Commands 

Command: Initialize all 
Code: I* 
Response: R 
Function: Effectively the same as performing all of the following commands:
IL; IRNG; I$N; IH106; IH210; IH305; IEW115; IEW250; IEW305; IEW410; IEW563;
IEW663; IDW104; IDW230; IDW330; IBP101; IBP202; IBP303; IP; IN10XXX#2;
DELAY00; IN0+0, INLTIM6, LOKCM. Also kills all current processes. 

Command:Initialize Lines 
Code: IL 
Response: R 
Function: Hang up all lines. 

Command: Initialize RiNG status 
Code: IRNG 
Response: R 
Function: Dump the record of all pending unanswered calls. 

Command: Initialize $$$$$$$$$ to YES 
Code: I$Y 
Response: R 
Function: Answer incoming calls. 

Command: Initialize $$$$$$$$$ to No 
Code: I$N 
Response: R 
Function: Stop answering incoming calls. 

Command: Initialize Time 
Code: ITxxxxxxxx (x=0-9) 
Response: R 
Function: Set clock to xxxxxxxx seconds. 

Command: INitialize Don't Answer 
Code: INDAxyz (x = a-p, A-P; y = A-L, X; z = 0, 1) 
(or xy = S1, S2, SX) 
Response: R 
Function: Don't answer incoming calls on specified ports if z=1, or
resume answering incoming calls if z=0. The group is x and the port is
y; if y=X, then all ports (A-L) of the specified group are affected. If
xy=S1 or S2 then an entire side (1 or 2) is affected. If xy=SX then all
ports are affected. 

Command: INitialize IGnore disconnects 
Code: INIGxyz 
Response: R 
Function: Syntax identical to INDA. If z=1 then ignore disconnect signals,
and if z=0 resume looking for disconnects. 

Command: Initialize MARK Ports 
Code: IMARKPxyz (x, y as INDA; z = 0-6) 
Response: R 
Function: Mark the affected port(s) with linetype z. Linetype 0, station
loop; 1, Feature Group A Loop Start; 2, Feature Group A Ground Start/Ring
Detect; 3, Feature Group A Ground Start/Tip Ground Detect; 4, Feature Group
B No ANI; 5, Feature Group B ANI; 6, Feature Group D. 

Command: INitialize Direct Connection 
Code: INDCX or INDCxyzz...zX (x=a-p, A-P, z = 0-9) 
Response: R 
Function: Predefine incoming ports with specific authorization codes.
Port xy will not request an authorization code from the user, but will
assume the code zz...z is to be used. One to eight digits may be entered.
The command INDCX clears all previously stored INDC commands. 

Command: INitialize Line TIMes 
Code: INLTIMxyzzz (x=0-5; y=0-6, 8; zzz = 000-255) 
or INLTIM6 
Response: R 
Function: Initialize time x for linetype y to zzz/10 seconds. Time 0
is Ringing Detect Time; 1, Ring Loss Time; 2, Disconnect Time; 3, On-Hook
Guard Time; 4, Disconnect Ignore Time on Origination; 5, Disconnect Ignore
Time on Answer. INLTIM6 sets all linetype times to the default values shown
below. 
Upon reset in the switch mode, the following times are preloaded:

Time

Linetype

  0    1    2    3    4    5    6

0

1

2

3

4

5

 0.1  0.5  0.5  0.5  0.3  0.3  0.3

 0.2  6.0  6.0  0.2  0.2  0.2  0.2

 0.5  0.2  0.5  0.5  0.2  0.2  0.2

 0.0  2.0  2.0  2.0  0.4  0.4  0.4

25.5 20.0 20.0 20.0 20.0 20.0 20.0

 0.3  0.3  0.3  0.3  0.3  0.3  0.3

Table entries are in seconds. Setting Time 0 to 000 corresponds to 25.6 seconds. 

Command: INitialize Area Code 
Code: INACxyz (x, z = 0-9; y = 0, 1) 
Response: R 
Function: Set the default area code to xyz. Used when 7 digits are received
in an MF field in the Tone Controllers. The 7 digit field is changed to
a 10 digit field. 

Command: INitialize 10XXX# option 
Code: IN10XXX#x (x = 0-3) 
Response: R 
Function: Set the mode of operation for Feature Group D 10XXX# (cut-through).
If x=0, exit immediately with the telephone number field empty; x=1, go
to first ready tone and look for an authorization code and telephone number;
x=2, provide ready tone and look for a telephone number, retaining the
MF ANI information as the authorization code field (unless ** is used to
dump the ANI); x=3, hang up the call and handle with an @ (if in switch
mode). 

Command: INitialize Dialing Registers 
Code: INDR 
Response: R 
Function: Clear all Dialing Registers. 

Command: INitialize MODULE name 
Code: INMODULEx (x = any character) 
Response: R 
Function: Name the module with character x. Read back by the MODULE
command. 

Command: Initialize Holding lengths 
Code: IHxyz (x = 1-3; yz = 00-63) 
Response: R 
Function: Initialize the number of digits to hold in each entry field.
The authorization code field is set by x = 1; the telephone number field
is set by x = 2; the billing code field is set by x = 3. 

Command: Initialize Enter Wait 
Code: IEWxyz (x = 1-6; yz = 00-63) 
Response: R 
Function: set TIMEx to yz seconds. TIME1 sets the maximum time permitted
between digits to enter the travel code, authorization code, and telephone
number. TIME2 sets the maximum total allotted time for the same. TIME3
sets the maximum time permitted between digits to enter the billing code.
TIME4 sets the maximum total allotted time for the same. TIME5 sets the
maximum time permitted between digits to enter digits requested by XMQ
or XMD. TIME6 sets the maximum total allotted time for the same. 

Command: Initialize Dialing Wait time 
Code: IDWxyz (x = 1-3; yz = 00-63) 
Response: R 
Function: Initialize waiting time for Wx in dialing sequence register
to yz seconds. 

Command: Initialize BeeP 
Code: IBPxyz (x = 1-3; yz = 00-63) 
Response: R 
Function: Set the number of acknowledgement beeps to yz after authorization
code for x = 1; after telephone number for x = 2; after billing code for
x = 3. 

Command: Initialize Pointers 
Code: IP 
Response: R 
Function: Initialize R, B, T, and QR read pointers. 

Command: INitialize 0+ dialing 
Code: IN0+x (x = 0,1) 
Response: R 
Function: For x=1, dump the ANI information for 0+ calls, supply a ready
tone, accept an authorization code, and exit (retaining the called number).
For x=0, exit normally. 

Command: INitialize Tone Controller FAIL status 
Code: INTCFAILxyz (xy = 01-63, z = 0,1) 
Response: R X if not available 
Function: Fail (z=1) or unfail (z=0) Tone Controller xy. The first Tone
Controller is 01. 

Command: IDLE Tone Controller 
Code: IDLETCt (t = ! - ~) 
Response: R X if not present 
Function: Abort any activity for Tone Controller t and release from
table. 


Fast Commands 

Command: Read user entry digit 
Code: R 
Response: 0-9,A-D, *, #, T, N, M, X 
Function: Read a digit entered by the user marked as the current call.
Receipt of "$" initializes the read pointer to the first digit,
and each consecutive read advances to the next entry. The first digits
read are the authorization code; optionally followed by a "T"
and the travel code; followed by an "N" and the telephone number;
optionally followed by an "M" and the billing code (a "T"
at the end of the billing code signifies that a time-out occurred); ended
with "X", afterwhich the entire sequence may be repeated. For
MF receiving operations, "#" stands for the ST pulse; "A"
for the ST' pulse; "B" for the ST2' pulse; and "C"
for the ST3' pulse. Summarized as: 
aa...a(Ttt...t)Nnn...n(Mbb...b(T))X, where aa...a is the authorization
code of length specified by the IH1 command; tt...t is the travel code
of maximum length one less than the authorization code length; nn...n is
the requested telephone number of maximum length specified by the IH2 command;
bb...b is the billing code of maximum length specified by the IH3 command.
The fields enclosed within () are optional. The "M" at the start
of the billing code stands for "More". If there is no current
call, just an "X" is sent. 

Command: read Billing code 
Code: B 
Response: 0-9, A-D, T, X 
Function: Functions identically to the "R" command, except
that reads start at the billing code field. A "T" at the end
of the billing code prior to the "X" signifies that a time-out
occurred. The command will cycle back to the start of the billing code
after the "X" is received. Summarized as: bb...b (T)X. If no
billing code has yet been entered, but a time-out has not yet occurred,
only an "X" is sent. If there is no current call, just an "X"
is sent. 

Command: read Time 
Code: T 
Response: 0-9, X 
Function: Read a digit from the real-time clock. Consecutive reads will
send consecutive digits, from the most significant digit to the least significant
digit. When all eight digits have been read, "X" is sent, afterwhich
the next "T" command starts at the first digit. 

Command: read Group of current call 
Code: G 
Response: a-p, A-P, X 
Function: The group of the current call is sent: a-p for SIDE1, A-P
for SIDE2, and "X" if there is no current call. 

Command: read Port of current call 
Code: P 
Response: A-L, X 
Function: The port of the current call is sent; "X" if there
is no current call. 

Command: determine Which Tone Controller used for current call 
Code: W 
Response: !-_ x if no current call 
Function: One of the possible 63 Tone Controllers is identified. See
Tone Controller chart.

Continue (Xfer) Call Commands 

Command: Xfer current call to Kill 
Code: XK 
Response: R X if there is no current call 
Function: Abort the current call by hanging it up. 

Command: Xfer current call to Busy 
Code: XB 
Response: R X if there is no current call 
Function: Place the current call on busy tone. 

Command: Xfer current call to Hold for better outlet 
Code: XH 
Response: R X if there is no current call 
Function: Postpone processing of this call, and remove it from the current
call status. Used to delay transferring the call in the hope that a better
outlet becomes available shortly. 

Command: Xfer current call to Wait for billing code 
Code: XW 
Response: R X if there is no current call 
Function: Postpone processing of this call, and remove it from the current
call status. Used to wait for a billing code for authorization codes requiring
them. 

Command: Xfer Feature Group D to Wait for billing code 
Code: XFGDW 
Response: R X if no current call 
Function: Provide BEEP2 beeps followed by a ready tone to the user,
wait for billing code, and provide BEEP3 beeps if maximum digits or * received.

Command: Xfer Current call 
Code: XCz (z = A-Z) 
Response: R X if there is no current call 
Function: Continue the current call using dialing sequence z. 

Command: Xfer current call to Done status 
Code: XD 
Response: R X if there is no current call 
Function: Stop the "$" repetition, and remove from the current
call status. This is to be used when the LM and CM commands are directly
used to handle the current call. 

Command: Xfer current call for More digits Quietly 
Code: XMQxy (xy = 01-20) 
Response: R X if no current call 
Function: Wait for xy more digits to be entered, and then notify with
a "$"; less digits appended with a "*" will force the
"$". These digits overwrite the billing code, and the "B"
command should be used to read the xy digits upon notification. Timeout
according to IEW5 and IEW6 will also force the "$", and a "T"
prior to the "X" will indicate the time-out. 

Command: Xfer current call for More digits with Dial tone 
Code: XMDxy (xy = 01-20) 
Response: R X if no current call 
Function: Identical to XMQ except that a new dial (400 Hz ready) tone
is supplied until the first digit is entered. 


(The above "X" commands cancel "$" or "D")



Command: Xfer Old call to Current status 
Code: XOCxy (x = a-p, A-P; y = A-L) 
Response: $ if completed 
N if no call holding on specified port 
X if there is already a current call 
Function: The call previously put on hold via XH on group x, port y
is made the current call. 

Command: Xmit seQuence 
Code: XQxyz (x = a-p, A-P; y = A-L; z = A-Z) 
Response: R X if no Tone Controller is available 
Function: Transmit dialing sequence z to group x, port y. 

Command: Xmit seQuence using specific Tone Controller


Code: XTQtxyz (t = !-~; x = a-p, A-P, y = A-L; z = A-Z) 
Response: R 
X if that Tone Controller is not present and idle 
Function: Transmit dialing sequence z using Tone Controller t. See Tone
Controller chart. Take group x, port y off-hook. 


Dialing Sequence Commands 

Command: seQuence Store 
Code: QSxyy...yX (x = A-Z; y = command) 
Response: R 
Function: Store yy...y as dialing sequence x. For registers A-Y, maximum
sequence length is 54 characters; for Z, 100 characters. See section 9.4
for command syntax. 

Command: seQuence store telephone # 
Code: Q#xxx...xX (x = 0-9) 
Response: R X if no current call 
Function: Replace the telephone number holding register with the specified
sequence. Used to replace shortened speed dial requests with actual telephone
numbers; acts on the current call. 

Command: seQuence store AUTHorization code 
Code: QAUTHxx...xX (x = 0-9, *, #, A-D) 
Response: R X if no current call 
Function: Replace the authorization code holding register with the specified
sequence. 

Command: seQuence store telephone #, specific Tone Controller 
Code: QT#txxx...xX (x = 0-9, t = !-~) 
Response: R 
X if Tone Controller not (present and idle) 
Function: Replace the telephone number holding register with the specified
sequence in the specified Tone Controller. 

Command: seQuence store Authorization code, specific Tone Controller


Code: QTAtxx...xX (x = 0-9, *, #, A-D, t = !-~) 
Response: R 
X if Tone Controller not (present and idle) 
Function: Replace the authorization code holding register with the specified
sequence in the specified Tone Controller. 

Command: seQuence Read 
Code: QRx (x = A-Z) 
Response: y (y as in QS) X after last character read 
Function: Read back dialing sequence x. A read command issued after
the last character has already been read will result in an "X"
response, afterwhich the next read will start at the beginning of the sequence.


Special Commands 

Command: Line Make connection 
Code: LMxy (x = a-p, A-P; y = A-L) 
Response: R 
Function: Place group x, port y off-hook. 

Command: Line Break connection 
Code: LBxy (x = a-p, A-P; y = A-L) 
Response: R 
Function: Place group x, port y on-hook. 

Command: Line Hook 
Code: LHxyz (x = a-p, A-P; y = A-L; z = 0, 1) 
Response: R 
Function: Place group x, port y off-hook for z=1, or on-hook for z=0.
xy can take on any of the values specified in INDA. 

Command: Line Wink 
Code: LWxy (x = a-p, A-P; y = A-L) 
Response: R 
Function: Wink port xy. The port must be of linetype 4, 5, or 6, and
must be in Ring Detect or Done Wink status. 

Command: determine AC power line status 
Code: AC 
Response: P if power is Present 
F if power is Failed 
Function: Check on power status. 

Command: Dialing Failure 
Code: DF 
Response: 0-9, R X if no current call 
Function: Return the number of the W command which failed in a dialing
register. If a reject tone was encountered, the response is R. 

Command: ready for notification character 
Code: r 
Response: none 
Function: Cancel the 0.5 second requirement between the last command
and the next notification character. 


Control Commands 

Command: obtain Test Module system SIZE 
Code: SIZE 
Response: A-P, X 
Function: Determine the highest group letter which can be used on SIDE1
or SIDE2. "X" indicates system failure. 

Command: determine MODULE identifier 
Code: MODULE 
Response: Character prestored via INMODULE command 
Function: Read back module character. 

Command: obtain number of Tone Controllers in system 
Code: QTONE 
Response: !-_ x if none 
Function: The number of Tone Controllers is supplied, where ! is one
and _ is 63. See Tone Controller chart. 

Command: LOCK out controller from serial line 
Code: LOCK 
Response: R if no current call 
X if there is a current call 
Place the controller into a standby condition--it will ignore all inputs
except the UNLOCK command, and will initiate no outputs. Intended to be
used to control other RS-232 devices paralleled with controller. Can only
be executed when there is no pending current call. 

Command: UNLOCK controller from lock command 
Code: UNLOCK 
Response: R 
Function: Exit from LOCK command. 

Command: DELAY after output for multiple characters


Code: DELAYxy (xy = 00-99) 
Response: R 
Function: Wait 2xy milliseconds after outputting characters for any
command which sends more that one character between requests. 

Command: Print current system STATUS 
Code: STATUS 
Response: Detailed display of current status 
Function: Status report for debugging. Gives the SC size, CC size, TIME,
last DF, current group, port, and TC, and for each active TC its RST line,
current operating mode, input and output ports. Also shows accumulated
XC, XB, and XK commands. 

Command: SAVE parameters 
Code: SAVE 
Response: R 
Function: Parameters stored in the coupler and Tone Controllers are
stored in the Master Controller. Tone Controller parameters are taken from
the first available Tone Controller, while Coupler Controller information
is individually stored. Saves parameters associated with: INDA, INIG, IH,
IEW, IDW, IBP, INAC, IN10XXX#, and IMARKP commands. 

Command: LOAD parameters 
Code: LOAD 
Response: R 
Function: Parameters previously stored in the Master Controller from
all Coupler Controllers and the first Tone Controller are loaded back into
all coupler and Tone Controllers. Overwrites all parameters associated
with: INDA, INIG, IH, IEW, IDW, IBP, INAC, IN10XXX#, and IMARKP commands.

Command: Dialing Register DISPlay 
Code: DRDISP 
Response: Display of all nonempty Dialing Registers 
Function: Produce a convenient display of all registers 

Command: place the switch into a SAFE mode 
Code: SAFE 
Response: R 
Function: Overrides the ability to execute any command, except for the
following: DISPSTATS, DISPDC, STATUS, DRDISP, MODULE, SLFTST, SAFE, UNSAFE.
Any other command will give a response of "X" if attempted after
issuing the SAFE command. System reset clears this condition (by an automatic
execution of the UNSAFE command). 

Command: place the switch into an UNSAFE mode 
Code: UNSAFE 
Response: R 
Function: Cancel a previously issued SAFE command. 

Command: enter DEBUG monitor program 
Code: DEBUG 
Response: DEBUG Monitor Program 
Function: Enter the debugger. 
* B XY xy (xy = 00-FF or x = <cr>) 
Select the board to be accessed via the A and C commands. The board
address is xy. 
* A addr RD wr (RD) 
Read [and write] address addr; instead of wr, space or . will
advance one address; - will back up one address; any other nonhex character
will return to the *. After writing, the data will be displayed if read
back differently from written. 
* C addr AF=af BC=bc DE=de HL=hl 
Call the address as a subroutine after loading the registers. If <CR>
is given for af, register requests are omitted. 

Command: ReaD Master Controller address aaaa 
Code: MCRDaaaa (aaaa = 0000-FFFF) 
Response: 00-FF 
Function: Read the Master Controller's internal memory.

Command: have the Master Controller perform a SeLFTeST 
Code: SLFTST 
Response: 00 if all OK 
FF if ROM error 
dd = 01-FE if RAM error in block ddOO-ddFF 
Function: Perform a checksum test on ROM and exercise all RAM locations
in Master Controller. 

Command: LOck access to restricted CoMmands 
Code: LOKCM 
Response: R 
Function: Prohibit access to restricted commands. 

Command: UNLock access to restricted CoMmands 
Code: UNLCM 
Response: R 
Function: Enable access to restricted commands. Extend the parameter
timeout from 5 to 30 seconds. 


Restricted Commands 
All Restricted Commands will give Response: X if UNLCM has not previously
been executed. 

Command: INitialize TOTALS 
Code: INTOTALS 
Response: R X if in locked mode 
Function: Clear the Calls Connected, Calls Busied, and Calls Killed
totals (displayed with STATUS) to 0. Totals incremented by the XC, XB,
and XK commands, respectively. 

Command: INitialize PORT STATistics 
Code: INPORTSTATS 
Response: R X if in locked mode 
Function: Initializes all port statistics: number of calls, cumulative
seconds, and most recent call duration. 

Command: DISPlay port STATisticS 
Code: DISPSTATSxy, xy as in INDA 
Response: X if in locked mode 
Function: Show the number of calls, cumulative seconds, and most recent
call duration for each specified port. 

Command: DISPlay Direct Connect authorization codes 
Code: DISPDCxy, xy as in INDA command 
Response: X if in locked mode 
Function: Displays internally stored direct connect authorization codes
over the range of specified ports. Ports without any codes are not displayed.
Example: DISPDCSX will display all such codes on the entire switch. Control
S and control Q can be used to stop/start the display. 

Command: INITialize entire system 
Code: INIT 
Response: R 
Function: Attempt to do everything a hardware reset does. 

Command: CALL a subroutine at A700H 
Code: CALL 
Response: none 
Function: A simple call to a subroutine previously loaded into RAM in
the Master Controller. 

Command: WRite data in Master Controller 
Code: MCWRaaaadd (aaaa = 0000-FFFF, dd = 00-FF) 
Response: dd = 00-FF 
Function: Modify Master Controller RAM memory contents and read back
data. 

Command: COMMunicate with boards other than the Master Controller 
Code: COMMbbndd...dd (bb = board address, 
n = 1-F, dd = 00-FF) 
Response: 00-FF X if no response from board. 
Function: Send n data bytes dd to board address bb, and give returned
response. 

Command: Clear input BUFfers on Tone Controllers 
Code: MBUFC 
Response: R 
Function: Clear the input buffers on Tone Controllers BM through EP.
Used prior to the MT or MNT command.

9.4 Dialing Register Syntax

Dialing registers A-Y may contain up to 54 digits; register Z 
may contain up to 100 digits. The default transmit mode is DTMF output.  

Dialing Register = (Action)(Action)...(Action)

Action = 0-9, *, #, A, B, C, D
     Transmit a tone or tone pair. The tone(s) sent are dependent
upon the present Mode. If in M0 (DTMF) or M1 (MF) transmit 
modes, send dual tones for the prescribed on and off durations. 
If in M3 (DTMF) or M4 (MF) transmit modes, send dual tones, leave 
tones on, and proceed to the next action in the dialing register with 
no delay (add delay commands and an M command to turn tone off). 
If in SIT transmit mode (M2), send a single tone for digits 1-6, 
and immediately progress to the next action in the dialing register. Codes 
* and # appended to one of the preceding digits delays the specified 
amount of time, then turns the tone off. A turns the tone off with no 
delay. For example, 1*3#5* sends 913.8 Hz for 274 ms, 1370.6 Hz 
for 380 ms, and 1776.7 Hz for 274 ms. There are no pauses between 
the three tones. Any of the delay parameters (Q, S, MD, MS) can 
be used in conjunction with A to construct nonstandard sequences.

Transmit Mode

DTMF (M0)	MF (M1)	SIT (M2)
1 2 3 4 5 6 7 8 9 0 * # A B C D	1 2 3 4 5 6 7 8 9 0 KP ST ST' ST2' ST3' ---	913.8 Hz 985.2 Hz 1370.6 Hz 1428.5 Hz 1776.7 Hz 1003 Hz --- --- --- --- 274 ms & off 380 ms & off Off --- --- ---

Action = T
     Send the last Ten digits of the telephone number field.

Action = V
     Send the last seVen digits of the telephone number field.

Action = Q
     Pause a quarter second.

Action = S
     Pause one second.

Action = M0
     Turn off any tones being transmitted and set transmit mode to standard
DTMF output.

Action = M1
     Turn off any tones being transmitted and set transmit mode to standard
MF output.

Action = M2
     Turn off any tones being transmitted and set transmit mode to SIT tone
output.

Action = M3
     Turn off any tones being transmitted and set transmit mode to DTMF output
with no delay. For example, M3#SSM0S5551212 sends a 2-second DTMF
#, pauses one second, and sends 555-1212 at the standard DTMF rate.

Action = M4
     Turn off any tones being transmitted and set transmit mode to MF output
with no delay.

Action = MDdd
     Delay dd milliseconds, dd=01-99. If dd=00, delay 100 milliseconds.

Action = MSdd
     Delay dd seconds, dd=00-99.

Action = M*wwwwxyyyyz
     Send one or two programmable tone(s). Tone 1 frequency parameter is
wwww, tone 2 frequency parameter is yyyy. Frequency of tone = 1789772/(tone
parameter). Tone 1 level is x, tone 2 level is z. If level = 0, tone is
off; 1, transmit at approximately -15 dBm; 2, transmit at approximately
-3 dBm.

Action = Pxx
     Set on and off times for DTMF tones to xx0 milliseconds, xx=01-99 (example:
P12 sets the on and off time to 120 milliseconds, taking 240 milliseconds
to send the digit). Also set DTMF transmit mode.

Action = W0
     Force a dialing failure.

Action = W1
     Wait up to IDW1 seconds to receive a constant precise dialtone for one
second; set DTMF transmit mode M0.

Action = W2
     Wait up to IDW2 seconds to receive a constant 400 Hz ready tone for
three seconds; set DTMF transmit mode M0.

Action = W3
     Wait up to IDW3 seconds to receive a constant precise dialtone for three
seconds; set DTMF transmit mode M0.

Action = W4
     Wait up to IDW1 seconds to receive a constant 400 Hz ready tone for
one second; set DTMF transmit mode M0.

Action = W5
     Wait up to 10 seconds to receive a wink; set MF transmit mode M1.

Action = WSdxy, d=0-9, *, #, A-D, Q
     Wait for DTMF splashback tone d; wait up to y seconds to receive a precise
dialtone or d; if time elapses, reject (fail); when the dialtone terminates,
wait up to y seconds to receive d; if d is received, reject; if not, accept
(go on to next action); if 4x seconds elapse overall, reject. If x=Q, then
simply wait y seconds to receive d; if received, reject; if not, accept.

Action = WB
     Clear the billing code field and reset the "B" pointer.

Action = WD
     Exit the dialing register and generate a $.

Action = WQdd
     Wait up to dd seconds for quiet at 1000 Hz; if energy remains, generates
a dialing failure.

Action = WEdd
     Wait up to dd seconds to exit. If no DTMF digit is received by timeout,
continue in the dialing register. If a digit is received, add to the billing
code field, exit the dialing register, and generate a $. In both cases,
add a T to the billing code field at exit.

Action = W#ttdd
     Wait up to dd seconds to receive tt DTMF digits. Digits collected are
added to the billing code field, followed with a T. Generate a dialing
failure on timeout.

Action = W#Tttdd
     Wait up to dd seconds to receive tt DTMF digits and measure elapsed
time. Digits collected are added to the billing code field, followed with
a Tddd, where ddd is the number of tenth seconds elapsed. Clear input buffer
when * received. Generate a dialing failure on timeout.

Action = WCddtt...tE
     Wait up to dd seconds to receive DTMF code tt...t. An unmatching digit
restarts the search. Generate a dialing failure on timeout.

Action = W*ntdd
     Wait up to dd seconds for something to happen. Clear the Wait Timer
at the start. Generate a dialing failure on a timeout. Continue in the
dialing register when either:
   (1) n DTMF digits are received
   (2) at least one, but less than n DTMF digits are received,
       with a lapse of t seconds after the last digit
   (3) SIT tone received.
   (4) 1004 Hz tone received.
   (5) busy signal is received
   (6) reorder signal is received
   (7) ringback signal is received
   (8) voice signal is received
or (9) dialtone is received

In all cases, add the following to the billing code field:
   (rx)Tddd, where
      rx = Mxx...x, x = DTMF digit (case 1 or 2) or
      rx = xx[x], for SIT tones received (case 3), where
           x = tl, with
               t = tone 1-5 and
               l = length * (short) or # (long), or
      rx = 6# for 1004 Hz tone received (case 4)
      rx = 7# for busy signal received (case 5)
      rx = 7* for reorder signal received (case 6)
      rx = 71 for ringback signal received (case 7)
      rx = 72 for voice signal received (case 8)
      rx = 73 for dialtone received (case 9)
   ddd = the Wait Timer, in tenth seconds.

Action = WTttxxyyzdd
     Wait up to tt seconds to receive one or two tone(s) lasting d.d seconds.
Generate a dialing failure on timeout. Filter 1 frequency parameter is
xx, filter 2 frequency parameter is yy. Tone detection center frequency
= 17898/(tone parameter). Detection filters have a Q of 10 (not narrowband);
detection threshold is approximately -48 dBm. For z = 1 or 2, look for
energy output from filter z; if z = B, look for simultaneous energy output
from filter 1 and 2. If successful, add 6#Tddd to the billing code field,
ddd = tenth seconds elapsed.

Action = E0 
     Send the entire authorization code field.

Action = E1 
     Send the first two digits in the authorization code
field (II code for Feature Group D).

Action = E2 
     Send the tenth through the eighth from the last digits
in the authorization code field, not counting any ST digits at the end
(area code for normal dialing).

Action = E3 
     Send the seventh through the fifth from the last
digits in the authorization code field, not counting any ST digits at the
end (exchange for normal dialing).

Action = E4 
     Send the last four digits in the authorization code
field, not counting any ST digits at the end (station for normal dialing).

Action = E5 
     Send the entire billing code field.

Tone Controller Table

Address	Number	Character
41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70	01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48	! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P

9.5 Internal Functional Description

This section describes the function of each subsystem in the Test Module, and the order in which operations are performed to achieve traffic placement.

9.5.1 System Architecture

The Test Module can be configured in sizes from 1 to 48 ports (telephone lines). There are three types of controllers: Master Controller, Coupler Controller, and Tone Controller. There is a single Master Controller. There is a Coupler Controller for every 24 telephone lines. There are the same number of Tone Controllers as telephone lines.

9.5.2 Master Controller

The Master Controller supervises the entire system's operation. It communicates with each of the two types of slave controllers (Coupler and Tone Controllers). It is master of the communications bus and is sensitive to eight interrupt lines on the main backplane which are driven by slave controllers. Its function is to allocate the slaves and coordinate all operations required to perform any desired task. It is the sole link between the Test Module and the Computer, communicating via a single serial RS-232 line. The Master Controller also provides a low impedance busy tone signal.

Dipswitches 1-3 set the baud rate. Binary values 0-7 correspond to 110, 300, 600, 1200, 2400, 4800, 9600, and 19200 bits per second, respectively. Switch ON = 0, OFF = 1. Switch 3 is the most significant bit.

Dipswitch 4 sets the startup Tone Controller scan option. If ON, it stops scanning at the first Tone Controller not located. If OFF, the scan continues up to 24 Tone Controllers if there is one Coupler Controller present, or 48 if two are present.

The normal setting is:

switches 7-1 = ON-ON-ON-ON-OFF-OFF-ON.

9.5.3 Coupler Controller

One Coupler Controller is used for each pair of coupler cages. Each Controller monitors the ringing-in and line current statuses and controls the on-/off-hook status of the 12 couplers on Side 1 and the 12 couplers on Side 2.

A coupler cage consists of 12 line cards; each line card has two dedicated connections to the control port on the Coupler Controller. An output lead (OH) controls whether the telephone line is on- or off-hook: an open circuit corresponds to on-hook, and a ground corresponds to off-hook. An input lead (DT) determines the status of the telephone line. If the line is on-hook, an open on this detect line indicates an idle condition; a ground indicates an incoming ring. If the line is off-hook, a ground on the detect line indicates the presence of line current; an open indicates the lack of line current (possibly due to a hangup from the other end of the line).

The Coupler Controllers continuously monitor the DT leads of all 24 line cards. When commanded, they activate the OH leads. Each of the 24 cards is independent from one another. The Coupler Controllers also supply +12 volts to the coupler cages. Each coupler cage connector carries 26 leads: 12 OH, 12 DT, +12 volts, and ground.

When ringing-in is detected, the Coupler Controller notifies the Master Controller and answers the line if so commanded. When a disconnect signal is detected, it hangs up the line and notifies the Master Controller.

The Coupler Controller forms a queue of incoming and disconnected calls, and processes them when the Master Controller is ready to handle the information. Lists of lines for which ringing or disconnects are to be ignored can be created for various purposes. All lines can be taken on- or off-hook on command, and timing constraints can be set: the minimum duration of time for line breaks acceptable as a disconnect signal, the minimum time for acceptance of a ringing-in, the length of time that disconnect signals are to be ignored after taking a line off-hook to ride through the click-over when dialing out, for example; and line breaks are guaranteed to last at least two seconds to insure against accidental reseizure of a line just released.

An LED lamp on the Coupler Controller illuminates when the Master Controller communicates with the Coupler Controller. The first Coupler Controller has all dipswitches set ON; the second has all ON except #1. These determine the identity of the board.

9.5.4 Tone Controller

The Tone Controller independently receives information from the test call; no other board in the system need be tied up while a test is in progress. Likewise, when dialing a number, processing time is not required for any other board while waiting for dial tone or actually dialing a number.

Each Tone Controller contains a DTMF receiver to accept information; a dial tone generator to produce a "ready" tone; a dial tone detector to permit recognition of local telephone line readiness; a DTMF generator to place outgoing calls and access to other equipment; a "ready" tone detector to enable use with OCC's; an MF generator to dial into trunk lines; and (optionally) an MF receiver to receive ANI and dialed digit information from the local operating company. All of these hardware functions are software controllable, permitting flexibility in creating new dialing patterns and detection/generation facilities.

An LED lamp on the Tone Controller illuminates steadily when it is either waiting for incoming digits or is engaged in dialing an outgoing number. The lamp flashes when an action is completed and awaiting servicing by the Master Controller (whenever its interrupt line is lowered).

The dipswitch is set to the binary value of the Tone Controller, in the range 1-48. Switch 7 is the most significant bit. Tone Controller 1 has switches 7-1 set to ON-ON-ON-ON-ON-ON-OFF; Tone Controller 48 is set to ON-OFF-OFF-ON-ON-ON-ON. These determine the identity of the board.

9.5.5 Coupler Cage

Twelve line cards are housed in each coupler cage. The cage consists of a physical mounting arrangement, and two backplanes: a front backplane, and a rear backplane. The line cards are powered by the associated Coupler Controller (+12 volts).

9.5.5.1 Front Coupler Backplane

The front backplane contains 12 edge sockets, into which the line cards are inserted. Common leads across all line cards are paralleled on the front backplane (power and ground). All other leads, which are isolated to one line circuit, are brought to the top of the backplane, either to solder pads or connectors, to be forwarded to the rear backplane. The front backplane is constructed from 1/8 inch board material to support pressures resulting from plugging in, and removing line cards.

9.5.5.2 Rear Coupler Backplane

The rear coupler backplane mounts behind the front coupler backplane. All connections to the front coupler backplane are via solder pads or connectors at the top of the backplane. The two backplanes are connected to one another either through mating connectors, or feedthrough jumpers at the top of the boards.

Individual pairs of leads originating from the line cards are rerouted to four 26-pin header sockets in the middle of the backplane. These are: coupler audio (CA); center tap (CT); coupler control (CCON); and expansion 1 (EXP 1). The CCON leads connect to the Coupler Controller. The telephone line connections are to both EXP 1 and to the first 12 circuit pairs of a 50-pin telephone connector at the bottom of the backplane. The second 12 circuit pairs of the socket are connected to a 26-pin EXP 2 header. Telephone line connections are either through the 50-pin connector (for the first 12 pair), or through EXP 1, which is then connected to EXP 2 of another coupler cage (to pick up the second 12 pair of the 50-pin connector on that cage).

9.5.5.3 UVC-1 (Universal Voice Coupler)

The UVC-1 is an interface between ARONTS and the telephone lines. It is a 2-wire loop start coupler. The card is all solid-state, and includes overvoltage and overcurrent protection.

The coupler connects to a Coupler Controller with a DETECT output and an ON/OFF-HOOK input. The input is used simply to draw loop current or go open circuited; the output is a combination of several signals. The UVC-1 detects ringing, forward, and reverse line current. These three outputs are paralleled together to form the DETECT output. If the coupler is in the on-hook mode, and the DETECT line goes low, then it must be ringing, and the Coupler Controller detects it as such. If the coupler is off-hook, then DETECT goes low if telephone line current is present. When this signal disappears, there has been a break in line current, and depending upon the length of this signal, the Coupler Controller may interpret this as a disconnect indication.

The audio connections from the coupler are made to the Tone Controllers via a split secondary output transformer in the UVC-1, which is used strictly as a single winding.

There are three LED lamps on the front of the UVC-1 visible from the front of the cabinet. A red indicator illuminates during the presence of ringing voltage, a green lamp lights when forward loop current is present, and a yellow LED indicates the presence of reverse loop current.

The UVC-1 card is used as an interface to loop start telephone lines for outgoing purposes, and to loop or ground start lines for incoming purposes. The card is also used as a telephone lookalike interface for connection to other switches. In such instances, a station interface must be used on the receiving switch.

Options

A ground start option is available for the UVC-1 permitting its use on outgoing ground start lines. An external earth (Telco) ground is required.

The UVC-1 can be used as the dry side (originating end) of 2-wire loop reverse battery trunks. The reverse loop current detection must be disabled. A jumper on the card side of the front coupler backplane can be cut to dedicate the card slot as loop reverse battery, or the UVC-1 itself can be modified.

Loop reverse battery interfaces work as follows. Signaling from the trunk equipment towards ARONTS is through the polarity of the source talk battery. When the UVC-1 goes off-hook, the trunk circuit detects the loop current and may return a wink signal, which is a momentary polarity reversal; the UVC-1 reports the reverse current as a loop current loss to the Coupler Controller, permitting it to measure the duration and detect it. Trunk circuits can also send acknowledgement winks in addition to startwinks, dependent on the trunk type.

In order to program a wait for wink signal in a dialing register (W5), the Tone Controller must be optioned for such usage.

9.5.6 Main Cage

The main cage houses all controller boards. The main backplane is attached to the rear of the main cage and contains 100-pin edge sockets into which the cards plug. The backplane provides a straight parallel connection between all pins. Two expansion connectors are provided for paralleling several main cages. A power connector provides all required voltages to the cards.

9.5.7 System Power Supply

The system power supply provides power for the Test Module. Voltages provided are: +7 volts; +15 volts; and -15 volts. The +7, +15, and -15 volt supplies have a common system ground. Circuit cards which utilize these supplies provide on-card voltage regulators for isolation and decentralization.

9.5.8 Internal Communications Prioritization

All Controllers communicate with the Master Controller through a parallel bidirectional communications bus on the main backplane. This consists of seven address lines, CA6-CA0; eight data lines, CD7-CD0; a parity line, CPAR; and a strobe line, CSTR. The Master Controller commands a slave via the following sequence: the Master Controller outputs the slave address and the command; after a bus settling time, the Master Controller lowers the strobe line; all slaves read the address/data information on the falling edge of the strobe line, and the addressed slave accepts the command; after a fixed period of time, the Master Controller raises the strobe line; if the command requires data parameters, they are sent after the command in sequence in the same fashion; when complete, the Master Controller then places the address and data bus into a high impedance receiving state; the slave controller places the Master Controller's address (00) on the address bus, and the acknowledgement on the data bus; after a settling time, the slave controller lowers the strobe line; the Master Controller receives the response; after a fixed period of time the slave releases all bus lines; and the Master Controller is again in control of the bus.

The board communications bus addresses are set as follows: Master Controller, 00; Coupler Controllers, 10-1F; Tone Controllers, 41-7F (all hexadecimal notation).

Since all transactions on the communications bus are initiated by the Master Controller, the bus does not provide a means for slave controllers to alert the Master Controller to conditions requiring servicing. These service requests are instead handled by a set of eight interrupt inputs to the Master Controller, INT7-INT0, which are present on the main backplane. Slave controllers share these interrupt input lines; a slave controller requests service by lowering an interrupt line. If more than one device is on one interrupt line, the Master Controller polls those boards to determine which is the source of the interrupt. When the conditions causing the interrupt are removed through proper servicing by the Master Controller, the interrupt request is removed.

Tone Controllers share INT6, and INT5-INT1. Upon power-up, the Master Controller polls all Tone Controllers to determine to which interrupt line they are attached, and stores the information in a table. When an interrupt is detected on one of these five lines, the Master Controller then checks each Tone Controller recorded as being associated with that interrupt. Tone Controllers provide an interrupt when: all information has been received from the test call; a timeout has occurred; an outgoing call has successfully been completed; or an outgoing call has failed.

In addition to the general purpose interrupt output, which is one of the five INT5-INT1 lines, each Tone Controller also uses INT6 (when optioned for such usage). This interrupt is activated when an MF sequence has been received, or when it must wait for a wink to be received before continuing dialing.

Each Coupler Controller uses both INT7 and INT0. When a line rings in, is not blocked, and calls are not inhibited, the associated Coupler Controller lowers the INT0 line. When a disconnect has been detected, INT7 is lowered. The Master Controller always polls the Coupler Controllers to determine the interrupt source; they all share the same pair of interrupt inputs.

The INT7-INT0 lines are level sensitive interrupt inputs to the Master Controller, prioritized in the following order, from highest to lowest: INT6, INT0, INT7, INT5, INT4, INT3, INT2, INT1. This means that any interrupt input is processed only if there is no higher level interrupt pending. The firmware is set up so that during processing of any of these external interrupts, no further interrupts can occur. This prevents any new interrupt-- either higher or lower-- to be recognized after processing of a prior one begins until that processing is complete (and therefore that interrupt has been released). The interrupt priorities govern to a large extent the operation of the Test Module itself.

9.5.9 Internal Communications Protocols

This section describes the commands which the Master Controller issues the Coupler and Tone Controllers. These instructions are sent over the parallel communications bus, with the destination controller address on the CA6-CA0 lines. The first data byte is always the command instruction, which is optionally followed by data parameters.

The syntax used in this description of the interprocessor protocols is as follows: command numbers are given in hexadecimal; () is a data byte sent over the communications bus; and ACK is the address of the slave controller. Use of (xx) indicates that "x" is a hexadecimal nibble; use of (xxxxxxxx) indicates that "x" is a binary digit, 0 or 1.

9.5.9.1 Coupler Controller (addresses 10-1F)

Mnemonic: RD 
Command: Read Memory Location 
Code: (00)(ah)(al) 
Response: (dd) 
Function: Read the contents of memory location (ah)(al) (ah is address
high and al is address low) as (dd). 

Mnemonic: WR 
Command: Write Memory Location 
Code: (01)(ah)(al)(dd) 
Response: (rr) 
Function: Write (dd) to memory location (ah)(al) and read back as (rr).


Mnemonic: CALL 
Command: Call a Subroutine 
Code: (02)(ff)(aa)(cc)(bb)(ee)(dd)(ll)(hh)(ah)(al) 
Response: (ACK) 
Function: Preload the flag register with (ff); A with (aa); BC with
(bbcc); DE with (ddee); HL with (hhll), and call address (ah)(al) as a
subroutine. 

Mnemonic: INIT 
Command: Initialize Controller 
Code: (03) 
Response: (ACK) 
Function: Attempt to reset the controller the same as a hardware reset
would do. 

Mnemonic: SELF-TEST 
Command: Have the Controller Test Itself 
Code: (04) 
Response: (00) if all okay 
(FF) if a ROM checksum error 
(ah) otherwise 
Function: Perform internal tests. If other than (00) or (FF) is returned,
there is a RAM error in the block (ah)(00)-(ah)(FF). 

Mnemonic: SPARE 
Command: Reserve for Future 
Code: (05) 
Response: none 
Function: No effect. 

Mnemonic: IDENT 
Command: Identify as Coupler Controller and Give Status 
Code: (06) 
Response: (szdh1110) 
Function: If this Coupler Controller is activating INT7 then s=1; if
it is activating INT0 then z=1; if calls are inhibited then h=1; if d=0,
then an analog switch; if d=1, then a digital switch. 

Mnemonic: IL 
Command: Initialize Lines 
Code: (07) 
Response: (ACK) 
Function: Place all SIDE1 and SIDE2 lines in this Coupler Controller's
group on-hook (hang them up). 

Mnemonic: IRNG 
Command: Initialize Ringing Status 
Code: (08) 
Response: (ACK) 
Function: Clear the queue of incoming rings. 

Mnemonic: IDY 
Command: Initialize Dollar Yes 
Code: (09) 
Response: (ACK) 
Function: Begin answering calls. 

Mnemonic: IDN 
Command: Initialize Dollar No 
Code: (0A) 
Response: (ACK) 
Function: Stop answering calls. 

Mnemonic: INDA 
Command: INitialize Don't Answer 
Code: (0B)(ya0spppp) 
Response: (ACK) 
Function: If y=1, set the specified port to don't answer mode; if y=0,
set to answer mode. If a=0, then specified port is (pppp)=0-B of side (s)=0,1
(s=0 for SIDE1; s=1 for SIDE2). If a=1, then all ports of specified side
are affected. 

Mnemonic: INIG 
Command: INitialize IGnore disconnects 
Code: (0C)(ya0spppp) 
Response: (ACK) 
Function: Specify port to ignore/look for disconnects. Syntax as INDA.


Mnemonic: LM 
Command: Line Make 
Code: (0D)(000spppp) 
Response: (ACK) 
Function: Take port (pppp), side (s) off-hook. Syntax as INDA. 

Mnemonic: LB 
Command: Line Break 
Code: (0E)(000spppp) 
Response: (ACK) 
Function: Place port (pppp), side (s) on-hook. Syntax as INDA. 

Mnemonic: RING 
Command: Answer Incoming Ring 
Code: (0F) 
Response: (1111xxxx) if no ports ringing 
(d00spppp) if at least one port is ringing 
Function: Answer the first port ringing in the queue and report which
port it is as side (s), port (pppp), and delete from queue. Syntax as INDA.
If the port has been initialized with the INDC command as containing an
authorization code, then d = 1; if not, then d = 0. 

Mnemonic: HUP 
Command: Find out which port disconnected and was hung up 
Code: (10) 
Response: (1111xxxx) if no ports disconnected 
(000spppp) if at least one port has hung up 
Function: Report which port was first in the disconnected queue as side
(s), port (pppp), and delete from queue. Syntax as INDA. 

Mnemonic: IO 
Command: Go into I/O mode 
Code: (11) 
Response: (ACK) 
Function: Stop processing rings and disconnects in main program. Used
to access input/output ports without interference from the foreground program.


Mnemonic: RUN 
Command: Resume normal operation 
Code: (12) 
Response: (ACK) 
Function: Process rings and disconnects in main program. 

Mnemonic: INDCC 
Command: INDC Clear 
Code: (13) 
Response: (ACK) 
Function: Clear direct connection authorization codes for all ports.


Mnemonic: INDC 
Command: Initialize Direct Connection 
Code: (14)(000spppp)(dig)(dig)...(dig)(FF) 
Response: (ACK) 
Function: Load authorization code (dig)(dig)...(dig) to port spppp,
(dig) from 01 to 10. Up to eight digits can be stored for each port. 

Mnemonic: RDC 
Command: Read Direct Connection 
Code: (15)(000spppp) 
Response: (dig)(dig)...(dig)(FF) 
or (FF) 
Function: Read back the prestored authorization code (dig)(dig)...(dig)
for port spppp, (dig) from 01 to 10. If no code has been stored, simply
(FF) will be the response. 

Mnemonic: SERCOM 
Command: SERial COMmunication 
Code: (16)(aa)(tt) 
Response: (rr) 
Function: Transmit (tt) serially to line card (aa) and read back serially
(rr). Used for communicating with digital line cards only. 

Mnemonic: MARK 
Command: Mark line with a linetype 
Code: (17)(tttspppp) 
Response: (ACK) 
Function: Mark port spppp with linetype ttt. If pppp=1111 then mark
entire side s with linetype ttt. 

Mnemonic: WINK 
Command: Wink a line 
Code: (18)(h00spppp) 
Response: (ACK) 
Function: Wink port spppp, then if h=1 take the port off-hook. The port
must be of type 4, 5, or 6 and must be in Ring Detect or Done Wink status.


Mnemonic: RINGMF 
Command: Answer incoming call requiring an MF decoder 
Code: (19) 
Response: (tttspppp) if such a call pending 
(11111111) if none 
Function: Answer the first port requiring service of an MF decoder,
and report the linetype as ttt, the side as s, and the port as pppp. 

Mnemonic: STATUS 
Command: Determine status of INT 0 
Code: (1A) 
Response: (s0uvwxyz) 
Function: Find out if INT 0 is asserted, and if so, what pending types
of actions are pending. If INT 0 is active, s=1; if Wink Detect, u=1; if
Wink Fail, v=1; if Feature Group A, w=1; if Feature Group B, no ANI, x=1;
if Feature Group B, ANI, y=1; if Feature Group D, z=1. INT 0 is removed,
although if there are pending actions it will automatically be reasserted.


Mnemonic: WAIT0M 
Command: Remove INT 0 for 1 second if require MF decoder 
Code: (1B) 
Response: (ACK) 
Function: If INT 0 is asserted only for calls requiring MF decoders,
it is removed for one second; if other calls are pending, it is not removed.
Any calls requiring an MF decoder in the ensuing second do not assert INT 0. 

Mnemonic: STIME 
Command: Set Time 
Code: (1C)(0wwwattt)(dd) 
Response: (ACK) 
Function: If a=0, then set time www for linetype ttt to value dd; if
a=1, set time www for all linetypes to value dd. 

Mnemonic: WWINK 
Command: Wait for Wink 
Code: (1D)(000spppp) 
Response: (ACK) 
Function: Wait for a wink from port spppp. When either received or timed
out (10 seconds), assert INT 0. 

Mnemonic: DWWINK 
Command: Done Wait for Wink 
Code: (1E) 
Response: (r00spppp) if port done or failed WWINK (11111111) if none

Function: Report the result of a WWINK command after INT 0 has been
asserted. If r=1, then the wink was detected; if r=0, the wink was not
detected within 10 seconds. 

Mnemonic: PSTAT 
Command: Port Status 
Code: (1F)(000spppp) 
Response: (fadiXlll)(ls)(tt) 
Function: Report the Line Mark (fadiXlll), the Line Status (ls), and
the Line Timer (tt) for port spppp. Line Mark: f=Failed; a=Direct Access;
d=Don't Answer; i=Ignore Disconnects; lll=Linetype. Line Status: 0=Idle;
1=Ring Start; 2=Ring Detect; 3=Wait to Go Off-hook; 4=Off-hook Ignore Disconnect;
5=Off-hook Look for Disconnect; 6=Disconnect Detected; 7=Wait for On-hook;
8=Start Wink; 9=Guard Wink; 10=Done Wink; 11=Wait for Wait for Wink; 12=Wait
for Wink; 13=Wait for Wink End; 14=Guard Wait for Wink; 15=Wink Fail; 16=Wink
Detect; 17=Wait to Answer. 

Mnemonic: WAIT0 
Command: Kill INT 0 and wait 1 second 
Code: (20) 
Response: (ACK) 
Function: Remove INT 0 and wait one second before letting any requests
reassert it. 

Mnemonic: RTIME 
Command: Read Time Parameters Out 
Code: (21)(00000ttt) 
Response: (Linetype 0)...(Linetype 6) 
Function: Read out seven timing values for each Linetype for timing
parameter ttt. 

Mnemonic: INFAIL 
Command: INitialize FAILed status 
Code: (22)(ya0spppp) 
Response: (ACK) 
Function: Fail/unfail a port. Syntax as INDA. 

Mnemonic: SETGAIN 
Command: Set gain for digital switch 
Code: (23)(0a0spppp)(TtttRrrr) 
Response: (ACK) 
Function: If a=0, then set gain for individual port to ttt dB, + for
T=0, - for T=1, and set receive gain to rrr dB, + for R=0, - for R=1. If
a=1, then set gains for all ports on side s. 

Mnemonic: SETINHLIM 
Command: Set inhibit limit for digital switch 
Code: (24)(0a0spppp)(xxxxxxxi) 
Response: (ACK) 
Function: If a=0, then inhibit limiting for individual port if i=1,
do not inhibit limiting if i=0. If a=1, then set or clear limiting for
all ports on side s. 

Mnemonic: LH 
Command: Line Hook 
Code: (25)(ha0spppp) 
Response: (ACK) 
Function: If h=1 then take port spppp off-hook; if h=0 then place port
spppp on-hook. If a=1 then do for all ports on side s. 

Mnemonic: ZSTATS 
Command: Zero port STATisticS 
Code: (26) 
Response: (ACK) 
Function: zero the port statistics for all of the ports 

Mnemonic: RDSTAT 
Command: ReaD port STATistics 
Code: (27)(xxxspppp) 
Response: (Byte 1)...(Byte 10) 
Function: Read the statistics for port spppp: 
Bytes 1-3 = current or last call duration, seconds 
Bytes 4-7 = accumulated duration, seconds 
Bytes 8-10 = accumulated number of calls 
Each field is in BCD format, least to highest byte

9.5.9.2 Tone Controller (addresses 41-7F)

Instructions (00) through (05) are the same as for the Coupler Controller.

Mnemonic: IDENT 
Command: Identify as Tone Controller and Supply Status 
Code: (06) 
Response: (wxyz1011) 
Function: If this Tone Controller is activating its INT lead then w=1;
if idle, then (xyz)=0; if the Travel Code/Authorization Code/Telephone
Number entry is done, then (xyz)=1; if that entry has timed out, then (xyz)=2;
if the Billing Code entry is done, then (xyz)=3; if that entry has timed
out, then (xyz)=4; if outgoing dialing is done, then (xyz)=5; if outgoing
dialing has caused a dialing failure, then (xyz)=6; if a task is in progress,
then (xyz)=7. 

Mnemonic: IH 
Command: Initialize Hold 
Code: (07)(rrnnnnnn) 
Response: (ACK) 
Function: Load Hold register (rr)=0, 1, or 2 with value (nnnnnn). 

Mnemonic: IEW1 
Command: Initialize Enter Wait 1 
Code: (08)(rrnnnnnn) 
Response: (ACK) 
Function: Load Enter Wait register 0, 1, or 2 with (rr)=0, 1, or 2 with
value (nnnnnn). 

Mnemonic: IEW2 
Command: Initialize Enter Wait 2 
Code: (09)(rrnnnnnn) 
Response: (ACK) 
Function: Load Enter Wait register 3, 4, or 5 with (rr)=0, 1, or 2 with
value (nnnnnn). 

Mnemonic: IDW 
Command: Initialize Dialing Wait 
Code: (0A)(rrnnnnnn) 
Response: (ACK) 
Function: Load Dialing Wait register (rr)=0, 1, or 2 with value (nnnnnn).

Mnemonic: IBP 
Command: Initialize BeePs 
Code: (0B)(rrnnnnnn) 
Response: (ACK) 
Function: Load Beep register (rr)=0, 1, or 2 with value (nnnnnn). 

Mnemonic: IP 
Command: Initialize Pointers 
Code: (0C) 
Response: (ACK) 
Function: Set all read pointers to the beginning of each field. 

Mnemonic: DF 
Command: get Dialing Failure 
Code: (0D) 
Response: (nn) 
Function: Read back the which W command failed in a dialing register.

Mnemonic: INT 
Command: Activate Interrupt Line 
Code: (0E) 
Response: (ACK) 
Function: Used by the Master Controller to determine to which INT line
this Tone Controller is connected. 

Mnemonic: SB 
Command: Send Beeps 
Code: (0F)(nn) 
Response: (ACK) 
Function: Send (nn) beeps. 

Mnemonic: RX 
Command: Go into Receive Mode 
Code: (10) 
Response: (ACK) 
Function: Receive incoming information from user. 

Mnemonic: TX 
Command: Go into Transmit Mode 
Code: (11) 
Response: (ACK) 
Function: Place an outgoing call using the internal dialing register.


Mnemonic: IDLE 
Command: Go into the Idle Mode 
Code: (12) 
Response: (ACK) 
Function: Kill any process. 

Mnemonic: XW 
Command: Xfer to Wait 
Code: (13) 
Response: (ACK) 
Function: Remove interrupt and wait for billing code; then activate
interrupt once again. 

Mnemonic: R 
Command: Read User Digit 
Code: (14) 
Response: (dd) 
Function: Permit LCRC to read the incoming user digits. Touchtone 1-9,
0, *, #, A, B, C, D set (dd)=01-10; "T" sets (dd)=(11); "N"
sets (dd)=(12); "M" sets (dd)=(13); "X" sets (dd)=(14).

Mnemonic: B 
Command: Read User Billing Code 
Code: (15) 
Response: (dd) 
Function: Permit LCRC to read the incoming user billing code. (dd)=(01)-(10),
(14) as above. 

Mnemonic: QS 
Command: Store Sequence 
Code: (16)(dd)...(dd)(00) 
Response: (ACK) 
Function: Store a sequence for outgoing dialing. (dd)=(01)-(11) as for
"R". "Q" sets (dd)=(15); "S" sets (dd)=(16);
"W" sets (dd)=(17); "V" sets (dd)=(18). 

Mnemonic: Q# 
Command: Store User Number 
Code: (17)(dd)...(dd)(00) 
Response: (ACK) 
Function: Overwrite the user's telephone number entry. (dd)=(01)-(10)
as for "R". 

Mnemonic: XMD 
Command: Xfer call for More digits with Dialtone 
Code: (18)(nn) 
Response: (ACK) 
Function: Remove interrupt. Provide dialtone until first digit received.
Overwrite billing code field and wait for (nn) digits unless shortened
with "*". 

Mnemonic: XMQ 
Command: Xfer call for More digits Quietly 
Code: (19)(nn) 
Response: (ACK) 
Function: As XMD, but without generating dialtone. 

Mnemonic: TRTN 
Command: Call Transmit Tone Subroutine 
Code: (1A)(nn) 
Response: (ACK) 
Function: Call the TRTN Subroutine with register A=(nn) 

Mnemonic: CLR TTBUF 
Command: Clear Incoming Digit Buffer 
Code: (1B) 
Response: (ACK) 
Function: Zero the input buffer; only useful prior to using the TXRX
command. 

Mnemonic: TXRX 
Command: Transmit and Receive 
Code: (1C) 
Response: (ACK) 
Function: Transmit the internal dialing register, then go into receive
mode without clearing the input buffer. Used for Switch Card testing. 

Mnemonic: STAC 
Command: STore Authorization Code 
Code: (1D)(dig)(dig)...(dig)(FF) 
Response: (ACK) 
Function: The authorization code (dig)(dig)...(dig) is used instead
of requesting it from the user, (dig) from 01 to 0A. 

Mnemonic: RXA 
Command: Go into Receive mode with Authorization code 
Code: (1E) 
Response: (ACK) 
Function: As RX, Except do not accept an authorization code from the
user; use the preloaded code. 

Mnemonic: RXFGD 
Command: Go into Receive mode for Feature Group D call 
Code: (1F) 
Response: (ACK) 
Function: As RX, except receive two MF fields: II + ANI, and called
number. 

Mnemonic: KILL6 
Command: Kill INT 6 
Code: (20) 
Response: (ACK) 
Function: Remove INT 6 if asserted. 

Mnemonic: RXFGB 
Command: Go into Receive mode for Feature Group B with ANI 
Code: (21) 
Response: (ACK) 
Function: As RX, except receive one MF field (ANI) and one DTMF field
(called number). 

Mnemonic: CUTHRU 
Command: Specify Cuthrough option for Feature Group D call 
Code: (22)(000000tt) 
Response: (ACK) 
Function: Handle Feature Group D cuthrough (10XXX#) call as follows:
tt=0, exit with telephone number field empty; tt=1, go to RX (treat as
Feature Group A or Feature Group B without ANI); tt=2, go to RXA to get
called telephone number (treat as Feature Group B with ANI); tt=3, treat
as a timeout (call will be hung up). 

Mnemonic: RUMF 
Command: aRe yoU an MF decoding Tone Controller? 
Code: (23) 
Response: (00) if not equipped for MF decoding 
(FF) if equipped for MF decoding 
Function: Determine if the Tone Controller can be used for MF decoding.


Mnemonic: INAC0 
Command: INitialize Area Code 0 
Code: (24)(xxxxyyyy) 
Response: (ACK) 
Function: Set the default area code to X0Y. If an MF field retrieves
seven digits, or 0 + seven digits, insert the default area code in front
of the seven digits. 

Mnemonic: INAC1 
Command: INitialize Area Code 1 
Code: (25)(xxxxyyyy) 
Response: (ACK) 
Function: As INAC0, except set the default area code to X1Y. 

Mnemonic: DPARAM 
Command: Dump PARAMeters 
Code: (26) 
Response: (TIME1)...(TIME6)(BEEPS1)...(BEEPS4) (HOLD1)...(HOLD4)(DWT1)...(DWT4)
(CUTHRU)(AREACD1)...(AREACD3) 
Function: Dump 22 bytes of information. 

Mnemonic: LPARAM 
Command: Load PARAMeters 
Code: (27)(TIME1)...(TIME6)(BEEPS1)...(BEEPS4) (HOLD1)...(HOLD4)(DWT1)...(DWT4)
(CUTHRU)(AREACD1)...(AREACD3) 
Response: (ACK) 
Function: Load 22 bytes of information. 

Mnemonic: STATUS 
Command: determine STATUS of INT 6 
Code: (28) 
Response: (iccccccc) 
Function: Determine status of interrupt 6; if set, i=1. If c=0, send
wink; c=1, receive wink. Kill INT 6 after execution of command. 

Mnemonic: WINK 
Command: indicate if WINK has been received or not 
Code: (29)(ww) 
Response: (ACK) 
Function: Tell the Tone Controller if a wink has been received or not.
If ww=FF, then a wink has been received; if ww=0, then a timeout has occurred
and a wink has not been received. 

Mnemonic: TRTNMF 
Command: TRansmit ToNe with MF pairs 
Code: (2A)(tt) 
Response: (ACK) 
Function: As TRTN, except that the tones correspond to MF pairs: 01-09=1-9;
0A=0; 0B=KP; 0C=ST; 0D=ST'; 0E=ST2'; 0F=ST3'. 

Mnemonic: RDFIL 
Command: ReaD FILter output 
Code: (2B) 
Response: (0 0 700 900 1100 1300 1500 1700) 
Function: Read the outputs of the MF filters; a bit is set if energy
in that frequency band has been detected. The RXFGD command must first
have been executed. 

Mnemonic: XFGDW 
Command: Xfer Feature Group D call to Wait for billing code 
Code: (2C) 
Response: (ACK) 
Function: Provide BEEP2 beeps, provide ready tone, then wait up to TIME1
seconds for the first billing code digit; when received, kill ready tone;
if timeout, exit; after first digit received, wait up to TIME3 seconds
for subsequent digits. Overall timeout is TIME2 seconds. 

Mnemonic: IN0+ 
Command: Initialize Feature Group D 0+ call handling 
Code: (2D)(0000000c) 
Response: (ACK) 
Function: Handle normally for c=0; for c=1, dump the ANI and get the
authorization code via DTMF input.

10. SOFTWARE REVISIONS

This chapter describes the differences between the ARONTS software of 11/91 as described in the prior sections of this manual, and the release dated 5/96. Most of the user interface is identical; only the changes are noted.

10.1 Main Menu

There are two new menu options: Run Job Queue, and Set Job Queue. These are discussed in section 10.11 (Job Queue).

10.2 Resume Testing

There are two aspects related to resumption of testing: site selection, and test application within a site which is accessed. The previous software addressed only site selection. During a test run, sites are picked from the selection criteria of the Test Schedule. When a test session is quit prior to test completion, there remain three sets of sites: (1) those which have been completely tested; (2) those partially tested; and (3) those which have not yet been accessed. Resume Testing previously skipped the first set, and treated the second and third groups identically. Any tests already performed from the second set were repeated; whenever a site was called, the test suite began in a fresh state as specified in the Test Definition.

This release retains the state of testing on each ARONTS port. Upon resumption, the site which was accessed on each individual port is recalled from that same port, and if the site is successfully reached, testing continues from where it was in the previous test run. If the site cannot be accessed after resumption, it is either dropped (after logging), or re-attempted later (section 10.6, Retry Site Access). In the latter case, if the site is subsequently accessed, testing starts from the beginning for that Test Definition.

For proper resume operation, the Site Information and Test Definitions should not be changed between the original test run and test resumption; the sites for which testing was in progress upon exit use the Site Information and Test Definition as loaded during the first run. Subsequent site access uses the current (possibly modified) Site Information and Test Definition. The Test Schedule should not be changed. The Test Numbers and Dialing Registers can be changed, however. When changes are made between quitting and resuming, and prior to printing the Log, care should be given to proper interpretation of the results. The Log printout always shows the information as it exists at the time of printing, not necessarily what it was at the time the test was conducted. (The log file contains the index of the Test Number and Dialing Register, as well as the Outline of the remote site for retrieval of Originating numbers, not the actual data value for these parameters.) The RawData.Txt file contains the data values as they existed at the time the record was created.

The resume operation overrides any changes made regarding port status under System Setup (enable/disable lines), and retains any Failed ports.

10.3 Site Information

The characters A, B, C, and D can be used in the Test and Program fields for the RTS-1 sites. These fourth column DTMF digits augment the standard 0-9 digits. Naturally, the RTS-1's must be programmed with these codes to match this information. ARONTS can be used to reprogram these codes, as described in section 7.3.3. The purpose is to make it more difficult for would-be hackers to break into the RTS-1 sites.

10.4 Common Features

The LEC Names, CO Descriptions, State/Country, Test Numbers, and Dialing Registers menu options have common new features. The displayed page can be scanned forward and backward with the + and - keys, as displayed on the options line. The Page Up and Page Down keys can also be used for the same purpose. The option Page is relabeled according to the appropriate information; for example, with Dialing Registers, the Register option permits the user to go directly to any specified register.

A Block Move/Copy option is added. A starting point, an endpoint, and a new beginning point are entered. The block of information between the starting point and endpoint is copied to a block starting at the new beginning point. Existing information at the destination spots is overwritten. No warning is given (the files are not written until the Exit Retaining All Changes option is selected). If the original block and ending block overlap, the effect is to move, or shift, the block up or down in index. This can be used to duplicate sequences of Dialing Registers, for example, in order to make minor changes in a related group. It can also be used simply to rearrange the Test Numbers for various grouping purposes.

10.5 Test Numbers

Blank domestic numbers may be entered without interference by the general requirement of entry of ten numeric digits. The purpose primarily is to create holes, or delete Test Numbers used with the Long Range feature (section 10.7).

Test Number file sizes are variable (rather than as previously fixed at 3000 numbers). Test Numbers are read until either the file end or the number of Test #'s as set in System Setup is reached. If the file contains less than the specified amount of numbers, the remainder are automatically filled with blank numbers. Upon exiting, the file is written according to the maximum number in System Setup. This can increase the file size, but not decrease it.

10.6 System Setup

Several additional features are available under System Setup.

Maximum Test Number

Up to 65000 Test Numbers can be specified -- the previous maximum was 3000. It is generally advantageous to keep this number no larger than required in order to reduce file access times. This revision also keeps the Test Number files only as large as this number dictates.

If the maximum Test Number is increased, Main Menu option Zero Statistics must immediately be executed to increase the test number statistics file. If the maximum Test Number is greater than 3000, the Test Numbers program (section 6.4.4) operates directly on the Test Numbers file; the Exit screen is eliminated, and all session changes are irrevocable.

Credit Card Numbers and Secret Authcodes

The previous single Credit (calling) Card Number and Secret Authcode are expanded to ten each. Upon entry, and after password validation, an index from 0-9 is entered; the appropriate contents are then stored for that particular entry. The information is referenced in Dialing Registers as c0-c9 and s0-s9. If c or s is used without a numeric specifier following, it is interpreted as c0 and s0, respectively, to maintain compatibility with earlier Dialing Registers.

More Options

The System Setup option line provides a new screen reached with the More option. This provides three additional parameters.

The Manual DTMF Code field permits the 000 default code recorded as Passed to be set to any sequence from 1-4 digits in length.

The Access Tries field permits the default 3 successive attempts to access a site to be altered. This is the number of times a site is sequentially called attempting access; it is also the number of times local dialtone is attempted to be drawn from the ARONTS port before the port is Failed. The value also determines the number of successive secondary dialing failures for RTS-1 sites before abandoning a test (see log code 133, section 10.13).

Retry Site Access changes the way sites are abandoned when access is not achieved. Previous operation was always according to this parameter being set to No: when a site is called according to the selection criteria of the Test Schedule, and access is not accomplished, the site is recalled until a total of Access Tries is reached. At this point, code 126 (Unable to Access Site) is logged, and the site is abandoned.

If Retry Site Access is set to Yes, the same process occurs, except that the site is not abandoned. As long as an active site is being tested in a Partition, and idle ports are found in that Partition, the unreached sites are reattempted. Testing stops when a complete cycle searching for a scheduled, untested site does not access a new location. On each cyclical attempt, Access Tries calls are made, and code 126 logged. When no more sites can be reached, code 132 (Gave Up on Site) is logged. The Test Number field shows the Partition number (1-4).

The purpose of Retrying Site Access is twofold. If a list of sites is scheduled for testing, and by happenstance someone is manually testing through one of the scheduled remote sites, ARONTS keeps trying to reach that site in the hope that before the test session is over, the manual user will have relinquished control, and permitted ARONTS to perform its scheduled task. The other situation is for multiple ARONTS installations. If separate groups have their own ARONTS unit, but share a common set of remote sites, it may occur that separate ARONTS units are scheduled to access an overlapping set of sites at the same time. By Retrying Site Access, each ARONTS tests whichever sites it can reach, and keeps trying to get to the other sites; hopefully each ARONTS can access the sites initially used by the other ARONTS at a later point in the test session. This provides for automatic interleaving of site usage.

If a large percentage of scheduled sites are expected to be unavailable, it is probably better to set Retry Site Access to No; otherwise, the test session may last much longer than required to test the active sites. Of course, the operator can always Quit Testing manually. Another reason to inhibit this feature is to limit the test run duration for the case when a new site is finally reached towards the end of testing, and a large Test Definition is used for the sites; this could double the overall session duration if there are more ARONTS ports than remote sites scheduled.

10.7 Test Definitions

The Dialing Register and Consecutive Tests can be set to blank (or zero) for a Test Group. If so, the entire Group is not used. This is equivalent to Zeroing the Test Numbers for that Group; it can be a simple way to temporarily inhibit testing of a Group without losing the information of the Test Numbers. If any of the three fields are blank, the Group remains untested.

The display Numbers option provides an {Escape} option if more than one screen of Test Numbers is being displayed; this is primarily useful when displaying the large quantities of numbers available under the Long Range mode.

Long Range Group

If the new Range option is not used, the standard arrangement is retained: all numbers within a single Group must be within a range of 103. Any set of numbers within that range can be accommodated. However, the Group can be placed into a new mode of operation: Long Range. The Range option toggles the Group between standard and Long Range. Test Numbers in the Group are zeroed when the type of Range is changed.

Long Range Groups have no limitation based upon the upper and lower Test Number values; the largest possible range of 1-65000 is acceptable. There is a limitation on the selection of those numbers: at most three ranges within the Group is permitted. For example, 1-500, 502-999, 2000-3000 is acceptable; and 234-345, 400, 500 is acceptable. If a change is made which causes more than three ranges to result, the first three are retained, and a warning beep is generated.

Additionally, for Long Ranges only, Test Numbers specified which are either blank or (000) 000-0000 are automatically skipped during testing. This permits individual numbers to be deleted from the test list (from the Main Menu Test Numbers option) without breaking the Long Range up into more ranges.

Long Ranges are particularly useful when a bulk quantity of numbers is to be tested from various sites; each Test Definition can be set to the maximum of 1-65000. All actual Test Numbers found in the Test Number file are then tested from each site. The feature can also be used to test bulk quantities of authorization codes. In this case, the authcodes to be tested are entered as international Test Numbers, which permits a variable length code up to 12 digits in length to be accommodated. The Dialing Register specified uses the n* field as the authcode, and embeds the dialed number in the Dialing Register.

10.8 Reconfirmation

The Main Menu asks for reconfirmation for the Wipe RawData and Zero Statistics options. A sequence of Yes/No is now required instead of the previous Yes/Yes response.

10.9 File Maintenance

The Format B: option is not available if there is no physical disk drive B:. If there are two floppy drives, the Format A: option changes to Format B: as the cursor moves through the field.

Archive options are added for the Job Queue (section 10.11), and Backup/Retrieve options are provided for the Job Queue Archive.

10.10 Test Analysis

The Analyze.Txt file generated when file output is selected has been moved from the D:\Report directory to the current directory (C:\ARONTS).

Screen #10-1

The main Analysis screen is altered to provide several wide listing options, and a Test Number Conditions option is supplied.

Screen #10-2

Test Number Conditions

The Statistics by Test Number listings permit the provisions of conditions in order to inhibit the printing of statistics for Test Numbers which are not of interest. The default criteria print data for any Test Number which is nonzero. The Criteria screen enables the entry of constraints.

A line is included in the listing if the successful tests are within the minimum and maximum range specified, inclusive; any of the individual unsuccessful tests is greater than or equal to its respective threshold; or the total number of unsuccessful tests reaches or exceeds the Total Failures threshold. Once entered, the conditions remain in place until the Test Analysis program is exited, afterwhich the defaults are reinstated. The Custom Menu, with the canned report option, can be used to easily run repetitive reports on an ongoing basis (sections 4.3 and 6.5).

If File Output is activated, the conditions are not used; any Test Number with nonzero data is automatically included in the output file. In this situation, the file is exported into a spreadsheet or database package, which can perform test criteria itself.

The wide listing for Test Number statistics includes a Total Failures column, along with a leading column displaying the actual Test Number in front of its index. Both the standard and wide Test Number statistics reports show a Total and a Sum line. The Total line shows all statistics collected for all Test Numbers. The Sum line shows the numerical sum over all Test Numbers which meet the list conditions, which in general is less than the Total line. The criteria screen Scan option provides a method to display the Total and Sum values prior to creating a listing.

10.11 Job Queue

A Job Queue is provided which operates at a level above the Tester program. The purpose of the Job Queue is to set up in advance a list of jobs to be run at specified times, and to have ARONTS execute each job in turn automatically. The current Job Queue is stored in a Queue.Dat file. Various versions can be archived in the Queue.Zip file (section 10.10).

Screen #10-3

Set Job Queue

The current Job Queue is viewed and modified via Main Menu option Set Job Queue. Five jobs are shown. The following fields may be entered for each job:

Wait Until Day. The day of the week the job is to commence: the field cycles from Sunday to Saturday, AnyDay, and back to Sunday.

Wait Until Time. The hour and minute on the Start Day the job is to begin. Twenty-four hour time is used; valid entries are from 00:00 through 23:59.

File Versions. The Test Schedule, Test Definitions, Test Numbers, Dialing Registers, and Module Commands files version numbers may be entered for each job. If the current file version is to be used, a blank (or zero) entry is made. Nonblank file versions change the current file to that specified, and leave them behind as the current version.

When the Job Queue is run, the Started and Completed day and time are recorded for each job. Reset clears these fields and permits the job to be rerun. Delete Job deletes the job number at which the cursor is resting, and shifts all higher job numbers down one job.

If all jobs within the current Job Queue are to be endlessly repeated, the Automatic Restart option is set to Yes. Upon completion of the last job, all five jobs are automatically reset and the process starts over.

If more than five jobs need to be scheduled, a list of Job Queues can be created and archived with appropriate version numbers. Each Job Queue should have its Next Queue entry set to the version of the continuation of the job list. The first should be made current prior to running the Job Queue. A circular list is permitted.

{Escape} provides a menu with Don't Exit, Cancel All Changes and Exit, and Exit Retaining All Changes options. The actual (current) Job Queue file is not written unless explicitly commanded.

Screen #10-4

Run Job Queue

Main Menu option Run Job Queue is used to activate the Job Queue. If file versions are contained in the Job Queue, they are retrieved and made current prior to running the assigned jobs. The current file versions are overwritten without inquiry at the time. A single warning message is provided prior to starting the Job Queue. If the current versions are not archived first they may be lost.

Upon activating the Job Queue, ARONTS waits for the first job's listed start day of week and time. If the day of week is the same as the Wait Until Day, but the start time is prior to the current time, the job immediately commences. There is a built-in delay requiring the minute to change twice before the job is started, to permit the operator to view the Job Queue status before the screen disappears. Depression of {Space} starts the job immediately if its start time has passed.

While the exact day of week is required for the first job listed to begin, it is not necessarily required to match for subsequent jobs. The system looks at the seven day window beginning on the day the first job actually began; if within that week, the next job was supposed to have run before the current day, it is immediately executed (irrespective of the Wait Until Time). This is for the situation, for example, when Job #1 begins on Monday, and Job #2 is scheduled for a Tuesday start, but Job #1 does not finish until Wednesday. Job #2 is immediately started. If Job #2 is scheduled for Sunday, it waits.

If a Wait Until Day is set to AnyDay, the system always waits until the start time has been reached. If a set of tests is to be run without concern for start times and days, each job can be set to Wait Until AnyDay at 00:00. In this situation, the Job Queue is used merely as a sequencer to bring in file versions and execute the Tester.

Upon completion of all jobs, if the Next Queue is not blank, the designated Job Queue version is automatically retrieved from the Job Queue Archive; all five jobs (of the new, now current Job Queue) are automatically Reset; and operations begin as for the first Job Queue. The seven day window is reset upon each Job Queue brought in from the archive.

The Job Queue does not check that specified file versions exist in the various archives until they are actually retrieved. If a file is missing, execution continues with the last current version for the affected file.

Executing the Job Queue automatically runs the Tester program, commanding it to exit when the Test Schedule is complete. If any Partitions in a Test Schedule are set to Use Operation Tables, the job does not exit. The completed day and time is not entered in the Job Queue, and no other jobs are run. Operation Tables indicate that continuous testing is requested, and are not compatible with using the Job Queue, other than delaying its start. For example, a list of Routining Test Schedules can be placed into the Job Queue, and the last entry set to use Operation Tables; once the Routining is complete, ARONTS conducts continuous testing according to the last job entry.

During test operations which are started via the Job Queue, if the operator Quits Testing (prior to automatic exit), the Job Queue is aborted and control returns to the Main Menu. The Job Queue contains the Started day and time for the last job, but no Completed entries. If the Job Queue is not explicitly altered or reset (via Set Job Queue), the next time the Job Queue is run, the fact that the last job was not completed is detected, and that job is automatically resumed. If data files are altered, or testing subsequently begun directly and not via Run Job Queue, the resumption will be incorrect (section 10.2); the operator must Reset the incomplete job in the Job Queue prior to running it.

While the Job Queue is pending, waiting for the scheduled start of the next job, the operator may exit with {Escape}. The Job Queue can be restarted at a later time without penalty.

Interface with Other Systems

Two optional files may be used to interface with other computing facilities: PreProc.Bat, and PostProc.Bat. If the first file exists, after retrieving any specified files from the archives, and before the tester program is executed, the PreProc.Bat Dos batch file is executed. It is called with seven parameters: the current job number (1-5); and the current version numbers of the Job Queue, the Test Schedule, the Test Definitions, the Test Numbers, the Dialing Registers, and the Module Commands. A value of 0 represents a current file without an attached version number. The batch file can interpret this information with the %1 - %7 replaceable parameters and make decisions based upon them. The preprocessing command file can be used to signal another system that testing is about to commence; possibly import Test Numbers into the current Test Numbers file; or to delete RawData.Txt. Another useful possibility is to read the time from some other system and synchronize the Dos clock.

Upon completion of a job, if the batch file PostProc.Bat exists, it is executed with the same parameters as described above for PreProc.Bat. It can be used, for example, to copy the RawData.Txt file to a network directory, begin billing comparison, or execute the VPCLog.Exe program to provide for automatic printout of the Log file, or creation of Printer.Txt for copying to another directory. If the latter option is desired, the appropriate keystrokes would be required to be stored in an ASCII file, and input redirected from it.

Remote Access can be initiated from within the Run Job Queue program as well as the Main Menu and Tester.

10.12 RawData Path

The default path for the output file RawData.Txt is D:\Report. It is possible to change the drive and path by placing a Dos Set command in the file Menu.Bat: Set RawData=Path, where Path is the desired drive and path. If Path is .\, the file is written into the current directory (C:\ARONTS); if Path is X:Data\, the file is written onto drive X in directory Data. The stated path must end with a backslash. This feature can be used to have Tester directly deposit the output file onto a network drive for interface with other software. Main Menu displays free space for drive X, unless x: is specified (lower case drive letter). Display of free space on a network drive can prove slow, and for that reason the inhibit option is provided.

Main Menu option Wipe RawData refers to the chosen path. The File Maintenance Offload option for RawData.Txt also refers to the chosen path.

10.13 Tester Program

The Tester program is ordinarily activated from the Main Menu. If it is desired to call it from a Dos batch file, two command line parameters may be utilized: Tester [Exit] [Resume]. If the resume parameter is passed, the program resumes testing (the same as if called from the Main Menu). If the exit parameter is passed, upon completion of all testing, the program automatically Quits, and the program terminates.

The Quit menu shows the status of the automatic exit parameter, and can be toggled on and off by operator input. The Alert Tone option is moved from within the Log display to the Master Display. In this way, the alert tone can be turned on if the log is empty. This option generates a beep tone whenever an entry is written to the log. When activated, Alert Tone blinks. The blinking number of Log Entries has been made nonblinking. Scheduled (sites) blinks until all site selection criteria have been loaded. Operation Table information is only displayed after the date and time if one of the Partitions is using Operation Tables.

A Freeze Failures option is added. When activated, it blinks. A password is required for activation. If turned on, the next failure on any port is frozen; Display One for the affected port is automatically performed; and all test processing stops until the operator releases the test with a {Space}. While a test call is frozen, a beep tone is generated every 10 seconds. This option permits the user to catch all failures in real time if at the console. Another use is to actually hold the telephone circuit up until a call trace can be performed to ascertain the cause of the trouble. In order for this to be done, the test Dialing Registers must be split into a main and a Next Register so that upon departure from the test register, the circuit is not knocked down prior to the failure display. It is also necessary to address the call timer (02dd command) and session timeouts for RTS-1 sites.

Log Times

Time is recorded in the Log file to one second resolution (previously it was two second resolution). The time recorded is that of the clock at the time the test register is exited. Times logged are that of the Dos clock by default. An option is provided to use the hardware real-time clock as the source of the date and time fields in the log file. To enable this option, use the Dos Set command in the file Menu.Bat, by including: Set Clock=HW; any setting other than HW logs time according to the software Dos clock. The hardware option can only be activated on 286 and higher processors. This hardware clock setting affects the date/time stored in the log file; all other timing activity is driven from the Dos clock.

The hardware clock option is provided for the situation where the Dos clock drifts from the actual time. Upon booting, Dos reads the hardware clock and initializes its internal (software) clock. Multi-tasking and other environments can cause the Dos clock to lose time after boots.

New Log Codes

Three new log codes are provided: 131-133. Log code 132 Gave Up on Site is discussed in section 10.6. Code 131 RTS-1 Session Timed Out can only be generated with RTS-1 firmware version 2.2. If the RTS-1 session times out while ARONTS is listening for the milliwatt (W*) or Manual DTMF code (W#T), ARONTS detects the DTMF D sent by the RTS-1 prior to hanging up, and logs the call accordingly. The site is automatically recalled, and the test call repeated. If the session timeout occurs at any other time, a communications problem between ARONTS and the RTS-1 is detected, ARONTS attempts to regain control of the RTS-1, and when unsuccessful, recalls the site, and the test call is repeated. This situation creates Logcode 112, not 131.

RTS-1 sites which have defective outgoing test lines can cause tests to fail in various ways. If the W# or WC commands are used in the test register to cause ARONTS to listen for the RTS-1 redialing the Test Number, and there is no telephone line or dialtone on the specified line, the RTS-1 sends back the error digit and cancels the test. This causes a secondary dialing failure because the W# or WC command is not satisfied, and log code 112 is generated. ARONTS tries the test again. When Access Tries (section 10.6) successive failures of this type occur, the test call is abandoned, and log code 133 Gave Up on Test is recorded.

Log Code Clarification

The Test Number field for Logcodes 97 Recalled Site, 98 Calling Site, Specific Test, 99 Calling Site, 105 No Response from HotShoe, and 109 No Response from RTS show the successive number of access attempts. A Test Number itself has no meaning for these codes. If Access Tries is set to 3 (section 10.6), the typical sequence is Logcode 109 with 1 Access Attempt, Logcode 109 with 2 Access Attempts, Logcode 109 with 3 Access Attempts, and finally Logcode 126 Unable to Access Site.

Logcodes which provide a DF x number indicate that the x^th W command in the Dialing Register failed (timed out). For Access Registers, if the first W command fails, it is assumed that there is no local ARONTS dialtone, and leads to Logcodes 104 Local line lost dialtone, Hot Shoe Call, and 108 Local line lost dialtone, RTS Call.

Logcodes 107 and 111 Unable to read RTS info refer to ARONTS polling the RTS's internal Test Mode and Program accesses, Failures, and Answers. This is performed when Collecting RTS Info is selected from System Setup (section 6.4.1). The second code appears if a timeout occurs. If a timeout (dialing failure) occurs while accessing an RTS, Logcode 110 Improper RTS access response results. If garbled information is received, but no timeout occurs, Logcode 117 Improper billing code field is recorded.

Logcode 122 Invalid Dialing Register is obvious except for the case when the register itself is apparently not invalid. This most commonly occurs in Access Registers when the Test or Program code is specified, but the Site Information does not have the Test or Program code stored.

Logcodes 113-115, and 128 refer to a disconnect being received at the ARONTS telephone line at various stages in the test process. This should not occur unless the remote site hangs up on ARONTS.

If transmission quality between ARONTS and RTS sites is imperfect, it is possible to obtain Logcode 116 RTS call with premature DTMF. This indicates that DTMF digits were received while listening for milliwatt, but the digits were received less than one second after dialing. The cause of this is that while ARONTS is counting DTMF digits which the RTS is redialing (with the W# command), a single DTMF digit is broken up into two or more by a momentary dropout in transmission, excessive distortion, or an excessive noise hit. The result is that the W# command exits prior to actual completion of RTS redialing; and the W* command encounters the last few digits of the RTS redial sequence, recording the DTMF being received prematurely. If this is more than a rare occurrence, an S one second pause after the W# and before the W* should provide sufficient dead time to mask several DTMF digits. If this is done, the wait time measurements will artificially be one second shorter than the actual value.

During an RTS test call, a dialing failure (timeout) other than the third W command (nominally the one used to detect test call progress) results in Logcode 112 Lost RTS test call. Depending upon where the timeout occurred, the actual test completion may or may not have been recorded. For example, the first W command is generally used for ARONTS to listen to the RTS redial the test number. If a line transmission dropout occurs (a similar, but opposite problem to Logcode 116 described above), an insufficient number of digits may be detected by ARONTS if the W# command is used for such monitoring. In this case, it is not known if the test call was placed properly but not received correctly by ARONTS, or if there was a dropout during the ARONTS command to the RTS providing the test number. Logcode 112 is recorded and the test call repeated. If this occurs more than rarely, two methods can be used to limit its occurrence. Commanding the RTS to dial the actual desired telephone number appended with DTMF A, and having ARONTS listen for a single DTMF A reduces the probability to that of a dropout during the one digit A, which is much less than a dropout during any of the digits. For situations where the fourth column DTMF digit confuses the CO, an alternate correction is to listen for fewer than the number of digits expected, and placing an S one second pause after it to prevent Logcode 116 resulting (see above).

It is also possible for a timeout to occur during an RTS test call after the actual test has been completed, during the process when ARONTS is communicating with the RTS. In this situation, the test call has already been logged correctly, and Logcode 112 follows. ARONTS automatically goes into a recovery mode to regain control of the RTS, which is transparent to the user. In general, Logcode 112 simply points out that there has been some difficulty, but the test call is repeated if it is not properly recorded. Other than monitoring to improve test efficiency, the code can be ignored.

10.14 Test Number Import

The program LoadNums.Exe is provided to permit an external database to be used as a source of Test Numbers. LoadNums is used to read an input file to modify TestNums.Dat and its versions. It creates an output error file which can be used to check valid inputs. Usage is as follows:

LoadNums < inputfile > errorfile

Standard MS-Dos input and output is used, so the program may be exercised with a simple LoadNums invocation. Doing so causes input to be directed from the keyboard, and the output errors go to the screen. When used with files, the input and error files are ASCII text files. Each line in the inputfile specifies one test number to be updated, a range of numbers to change multiple access status, change to a different file version, go into AutoFile mode, go into AutoNumbering mode, or store the next Test Number in sequence. All parameters on the line are separated by one or more spaces.

TestNumber "New Number"

The TestNumber must be in the range 1 through the maximum number of test numbers specified in System Setup. The New Number must be 12 digits enclosed in double quotes. Domestic numbers have the first two digits as spaces, followed by the 10-digit telephone number. For example, " 4109361212" represents (410) 936-1212. International numbers must begin at the first spot and be filled with trailing spaces to make up a total of 12 digits. For example, "123456789 ".

0 1 FirstNumber LastNumber Multiple

The multiple-call status of the range of numbers specified by FirstNumber and LastNumber are modified by this command. Multiple access is permitted (a *) with Multiple=1, and Multiple access is not permitted (no *) with Multiple=0.

0 0 Version

This command changes the file acted upon from the default TestNums.Dat to TestNums.vvv, where vvv is a three-digit version number specified by Version. All subsequent commands take effect on that file unless AutoFile mode is activated. The file must first exist. Empty files can be created by exercising the Zero option for TestNums from the File Maintenance menu, going into Main Menu Test Numbers and exiting saving all changes, and copying TestNums.Dat to various TestNums.vvv files. After updating by LoadNums, these files are not archived and can be lost unless they are actively archived with the PAK command. Complete syntax for it is available by entering PAK /H from the command line. However, the command

Pak a TestNums TestNums.123 TestNums.129 ... TestNums.999

illustrates the way several new file versions can be placed into the archive.

0 2 Version

This command places LoadNums into AutoFile mode, starting with the stated version number. In this mode, new files are automatically created and archived. If more than the maximum number of Test Numbers are added, the starting file version is closed, and the next sequential version number is automatically created. Note: AutoFile mode overwrites any existing versions in the Test Numbers Archive!

0 3 FirstNumber Multiple

This command places LoadNums into AutoNumbering mode, starting with FirstNumber. Subsequent numbers loaded with the 0 4 command autoincrement the Test Number, and are stored with Multiple (1) or not (0) attributes. If AutoFile mode is already turned on, FirstNumber is ignored, and the command is used simply to set the multiple call status of subsequent 0 4 inputs.

0 4 "New Number"

This command stores the next Test Number when in AutoNumbering or AutoFile modes. The Test Number index is automatically incremented.

Example

The most automated procedure for Test Number import is to use AutoFile mode. This example creates three Test Number files, versions 101, 102, and 103, and places them into the Test Number Archive. Assume that the maximum Test Number is set to 9999, and that 25,000 Test Numbers are to be imported in a single operation. The input file is:

0 2 101 Start AutoFile with ver. 101
0 3 1 1 Store subsequent input with Multiple attribute
0 4 " 3012000001" Store Test Number 1 in ver. 101
0 4 " 3012000002" Store Test Number 2 in ver. 101
... ...
0 4 " 3012009999" Store Test Number 9999 in ver. 101
0 4 " 3012010001" Store Test Number 1 in ver. 102
0 4 " 3012010002" Store Test Number 2 in ver. 102
... ...
0 4 " 3012019999" Store Test Number 9999 in ver. 102
0 4 " 3012020001" Store Test Number 1 in ver. 103
0 4 " 3012020002" Store Test Number 2 in ver. 103
... ...
0 4 " 3012025002" Store Test Number 5002 in ver. 103

The second line is not needed unless the Multiple call attribute is to be set. The 0 4 command automatically assigns the next Test Number available in sequence and stores the specified number. When the file version is full (with the maximum Test Number stored), the next version number is created. This example creates two 9999 entry files, and one 5002 entry file.

10.15 [Failure] Log

Selecting [Failure] Log from the Main Menu (section 6.6.2) displays the following screen:

Screen #10-5

In addition to restricting the log by site types, other parameters may be used. Choosing Restrict to Selected Entries displays the following screen:

Screen #10-6

The bottom right of the screen offers log restrictions unrelated to the site types. Log codes are not displayed on this screen; modifying them (with the {Space} key) provides an entire screen, similar to Screen #22, showing which log codes are to be included in the log display.

Ranges of Test Numbers and Dialing Registers may be entered. Only log entries using these parameters are selected for display. Parameters for First and Last Port refer to the lines on ARONTS. This selection can be useful if Partitions are used (section 3.3) -- upon completion of testing, separate log printouts can be made for each of the test Partitions.

The default setting for each of the selection fields is the most permissive; if nothing is entered, the result is the same as if the Use Entire Log option from the previous screen were utilized. After the desired fields are specified, {Escape} produces the log display. While displaying the log, the Clear option has no effect if the Restrict to Selected Entries option was used to display the log; in order to clear the log, the Use Entire Log option must be used.

Escaping from the log display returns to the first screen if the Restrict to Selected Entries option was used to view the log. This permits an interactive log examination session.

10.16 Site Selector Menus

Various program options provide a common Site Selector Menu (screen #10, section 6.3.1). The maximum number of entries for each field is increased from eight to 24. Eight entries are displayed at a time; if any of the fields contain more than eight values, four additional keystroke options are provided. These scroll options are illustrated in the previous Failure Log Selector Menu example screen.

{+} scrolls the screen displays up to show higher numbered entries, one-by-one; {Page Down} scrolls the screen displays to show higher numbered entries "below" those currently displayed, in groups of eight; {-} scrolls the screen displays down to show lower numbered entries, one-by-one; and {Page Up} scrolls the screen displays to show lower numbered entries "above" those currently displayed, in groups of eight. These scroll options affect all of the fields which contain more than eight entries. The position of the highlighted field is irrelevant.

The presence of the scroll options indicates that there are "hidden" entries on the screen.

10.17 Conversion of Test Schedule Files

The Test Schedule file format of 5/96 is not compatible with previous software versions. Upon software installation, the Test Schedule must be initialized (Zero in File Maintenance), or converted. If it is not necessary to retain old Test Schedules, from the Dos prompt, enter:

Del TestSked.Zip

To convert existing Test Schedules into the revised format, individually make each current, and from the Dos prompt, enter CvTstSkd. This changes the file TestSked.Dat into the required form. The (converted) current Test Schedule can then be placed into the Test Schedule Archive under File Maintenance, overwriting if necessary. Repeat this process for all Test Schedules in the archive.

10.18 Computing Environment

Additional issues arise when ARONTS software is loaded onto non-supplied computers. This software revision is compatible with Ms-Dos 3.3, 5.0, and 6.0. Earlier releases were not directly compatible with the Dos Print command in versions later than 3.3. If Ms-Dos 6.0 is used, SetVer must be loaded, and the Backup50.Exe file copied or renamed to Backup.Exe. It should be verified that SetVer assigns Dos version 5.0 to Backup.Exe. This is the default as shipped by Microsoft. A sample Config.Sys and Autoexec.Bat are stored as Config.60 and AutoExec.60 in the \ARONTS directory. Similar versions are provided for Ms-Dos 3.3; a combination of the two should be used for Ms-Dos 5.0, depending upon individual configurations.

The AutoExec.Bat files included assume a standard 2400 bps modem present at Com2:. If the modem is not present, the Com2 parameter must be changed to ComX in Menu.Bat. It may be necessary to modify Speed.Bat if the result codes for the modem differ from the values included in that file. Additionally, the first line should be modified to go to the highest baud rate for the particular modem. If any special commands need to be issued upon initialization for a high speed modem, they should be inserted in AutoExec.Bat; a representative sample is supplied in the AutoExec.Hi file.

Memory

ARONTS software assumes a clean environment; if too many TSR's or drivers are loaded in low (conventional) memory, the software may not run, or be unable to execute the List menu options (which executes Print as a subprocess). The first choice is to free up conventional memory by placing drivers and TSR's in upper memory with Dos 5.0 and 6.0. If this is not possible, alternate versions of the programs are provided. The executables *.sm should be renamed to *.Exe after first renaming the originals as *.Big. The small executables cannot be used with more than 2500 sites or 5000 LEC's.

10.19 Version 6 Firmware

Tone and Master Controllers equipped with version 6.0 firmware offer additional commands. (4/97)

10.19.1 Additional Dialing Register Actions

Tone Controllers with version 6.0 firmware provide these Dialing Register actions in addition to those given in section 9.4.

Action = P*
    Initialize all gains to factory default.  See Gain Table.  This
is only necessary if gains have been altered within a Dialing
Register, and it is desired to restore them to the factory
settings.  The start of every Dialing Register implicitly initial-
izes all gains to the current gain setting upon activation.  This
action does not alter the value of the current gain settings.

Action = PWxxyy
    Set filter 1 detect threshold according to parameter xx; set
filter 2 detect threshold according to parameter yy; see Gain
Table.  The W* commands use filter 2 to detect SIT and successful
tones; filter 1 is used to detect busy, reorder, ringback, voice,
and dialtone signals.  Making these filters less sensitive
increases rejection of unwanted signals; making these filters too
sensitive can cause false positive detection due to spurious
signals, or noise on the line.

Action = PTxxyy
    Set transmit tone 1 level according to parameter xx; set transmit
tone 2 level according to parameter yy; see Gain Table.  Tone 1 is
used for SIT and the low frequency DTMF and MF tones.  Tone 2 is
used for the high frequency DTMF and MF tones.

Action = PQxxyy
    Set transmit tone 1 quiet level according to parameter xx; set
transmit tone 2 quiet level according to parameter yy; see Gain
Table.  These levels are used to generate the local dialtone or
ready tone in the W#P and W#D commands.

Action = PDxxyy
    Set DTMF receive gain according to parameter xx; set auxiliary
input transmit gain according to parameter yy; see Gain Table.

Action = M*wwwwxyyyyz
    This is a restriction on the existing action.  Permissible values
for x and z are 0 and 2; the 1 option is eliminated.  The transmit
levels for tone 1 and tone 2 are set by parameters xx and yy in the
PTxxyy action, respectively.

Action = W**Vntdd
    Identical to W*ntdd, except for international cadences: double-
ring ringback and reorder signals.

Action = W**pnzttxxyydd
    Similar to the W* action, except does not detect SIT tones and
instead permits programmable successful tone detection frequency: 
wait up to tt seconds to receive tone lasting d.d or 0.0dd seconds,
n DTMF digits, or m<n DTMF digits after an interdigital timeout of
z seconds, or cadence outputs:  busy, reorder, ringback, dialtone,
voice.  Filter 1 parameter xx should be centered on cadence
frequency center of 480 Hz (75 for 35795 ratio, or 37 for 17898
ratio).  Filter 2 parameter yy determines the successful tone
frequency.  Filter parameters xx and yy are either (17898/center
frequency) or (35795/center frequency) according to option parame-
ter p:

    p    Cadence          Duration    Ratio
    1    USA              d.d         17898
    2    USA              d.d         35795
    3    USA              0.0dd       17898
    4    USA              0.0dd       35795
    5    International    d.d         17898
    6    International    d.d         35795
    7    International    0.0dd       17898
    8    International    0.0dd       35795

The tone duration 0.0dd must typically be set 20-30 ms longer than
desired.  Generate a dialing failure on a timeout.  Result codes
identical to W* action.

Action = WT*pttxxyyzdd
     This action is a superset of the previous WT action, equivalent
to WT*1ttxxyyzdd.  Wait up to tt seconds for presence or absence of
tone(s) lasting d.d or 0.0dd seconds. Filter 1 parameter xx and
filter 2 parameter yy are either (17898/center frequency) or
(35795/center frequency) according to option parameter p:

    p    Look for         Duration    Ratio
    1    Presence         d.d         17898
    2    Presence         d.d         35795
    3    Presence         0.0dd       17898
    4    Presence         0.0dd       35795
    5    Absence          d.d         17898
    6    Absence          d.d         35795
    7    Absence          0.0dd       17898
    8    Absence          0.0dd       35795

For z = 1 or 2, look for filter z energy only; if z = B, look for
both tones.  The tone duration 0.0dd must typically be set 20-30 ms
longer than desired.  If successful and looking for tone presence,
add 6#Tddd to the billing code field, ddd = tenth seconds elapsed. 
If unsuccessful, generate a dialing failure.

Action = W#Pttdd
    Identical to W#Tttdd, except that a Precise dialtone (350 + 440
Hz) is transmitted as a prompt while waiting to receive the first
DTMF digit.  Transmit at the quiet level.

Action = W#Dttdd
    Identical to W#Tttdd, except that a 400 Hz Dialtone is transmit-
ted as a prompt while waiting to receive the first DTMF digit. 
Transmit at the quiet level.

Action = WVxxz
    Set external audio input level according to xx; for z=1, activate
the external Play output; for z=0, deactivate the external Play
output.  Used to transmit voice messages (Wait for Voice): a first
WV action can set a nonzero level and turn on a message machine; a
second WV action, after a delay, can set a zero level and turn a
message machine off.

10.19.2 Additional External Communications Protocols

Master Controllers with version 6.0 firmware provide these commands in addition to those given in section 9.3.

Command:  MBUFC
This command has been eliminated.

Command:  SeLFTeST
Code: SLFTSTbb, SLFTST*
Response:  return code from board bb
Function:  perform a self-test command (04) on controller board
address bb.  If bb=00, then tests the Master Controller; the same
as the previous SLFTST command.  For SLFTST*, perform a self-test
on all Tone Controllers.  Restricted command.

The following commands must only be issued if all Tone Controllers have version 6 firmware:

Command:  Analog Tone Controller Test
Code: ATCTSTbb, ATCTST*
Response:  return code from board bb; 00 if OK
Function:  perform an analog self-test on Tone Controller board
address bb.  For ATCTST*, perform the test on all Tone Controllers. 
Restricted command.

Command:  INitialize all Gains
Code: ING*
Response:  R
Function:  Initialize all Tone Controller gains to factory
settings.  Equivalent to INGT2824, INGQ4240, INGW5656, INGD0099.

Command:  INitialize Gains for Transmit
Code: INGTxxyy
Response:  R
Function:  Initialize all Tone Controller tone 1 levels according
to parameter xx, all tone 2 levels according to parameter yy.  xx
and yy = 00-99.  See Gain Table.  These override the factory
settings and take effect at the beginning of all Dialing Registers.

Command:  INitialize Gains for Quiet level
Code: INGQxxyy
Response:  R
Function:  Initialize all Tone Controller tone 1 quiet levels
according to parameter xx, all tone 2 quiet levels according to
parameter yy.  xx and yy = 00-99.  See Gain Table.  These override
the factory settings and take effect at the beginning of all
Dialing Registers.

Command:  INitialize Gains for W*
Code: INGWxxyy
Response:  R
Function:  Initialize all Tone Controller filter 1 detection
thresholds according to parameter xx, all filter 2 detection
thresholds according to parameter yy.  xx and yy = 00-99.  See Gain
Table.  These override the factory settings and take effect at the
beginning of all Dialing Registers.

Command:  INitialize Gains for Dtmf receive and external audio
          input
Code: INGDxxyy
Response:  R
Function:  Initialize all Tone Controller DTMF receiver amplifiers
according to parameter xx, all external audio input gains according
to parameter yy.  xx and yy = 00-99.  See Gain Table.  These over-
ride the factory settings and take effect at the beginning of all
Dialing Registers.

Command:  COMmunications TeST
Code: COMTSTbb, COMTST*
Response:  00 if all OK, else error code
Function:  perform a communications test on controller board
address bb.  For COMTST*, perform a communications test on all Tone
Controllers.  Restricted command.

10.19.3 Additional Internal Communications Protocols

These Tone Controller commands are in addition to those in section 9.5.9.2

Mnemonic:  ING
Command:  Initialize Gains
Code:  (2E)(pp)(xx)(yy)
Response: (ACK)
Function:  Change a pair of default gains
 pp=11 (ING*, P*) xxyy must be sent
 pp=23 (INGWxxyy, PWxxyy)
 pp=17 (INGTxxyy, PTxxyy)
 pp=21 (INGQxxyy, PQxxyy)
 pp=16 (INGDxxyy, PDxxyy)
xx, yy=00-99

Mnemonic:  ATEST
Command:  Analog Test
Code:  (2F)
Response: (00), pass; (cc), fail
Function:  Perform an analog self-test; takes approximately 20
seconds.  If fails, send error code (cc) and leave the Tone
Controller in the mode where the test failed for diagnostic
purposes; it may be necessary to perform a reset to continue from
that point.

10.19.4 Gain Table

All settings are for a 600 ohm termination. Transmit is the output level in dBm, used in the INGT and INGQ commands, and Dialing Register actions PT and PQ. Filter is the filter 1 and 2 detect threshold levels in dBm, used in the INGW command and Dialing Register action PW. DTMF is the gain in front of the DTMF receiver, in dB; at a gain of 0 dB the DTMF detection levels are nominally -29 to +1 dBm, each tone. External is the gain from the external audio input to the line, in dB.

xx,yy

Transmit

Filter

DTMF

External

 
 
 
 
 
 
 
 
 
+2.5
+2
+1.5
+1
+0.5
0
-0.5
-1
-1.5
-2
-2.5
-3
-3.5
-4
-4.5
-5
-5.5
-6
-6.5
-7
-7.5
-8
-8.5
-9
-10
-11
-12
-13
-14
-15
-16
-17
-18
-19
-20
-21
-22
-23
-24
-25
-26
-27
-28
-29
-30
-31
-32
-33
-34
-35
-36
-37
-38
-39
-40
-41
-43
-45
-47
-49
-51
-53
-55
-57
-59
-61
-63
-65
-67
-69
off
off

-8
-8.5
-9
-9.5
-10
-10.5
-11
-11.5
-12
-12.5
-13
-13.5
-14
-14.5
-15
-15.5
-16
-16.5
-17
-17.5
-18
-18.5
-19
-19.5
-20
-20.5
-21
-21.5
-22
-22.5
-23
-23.5
-24
-25
-26
-27
-28
-29
-30
-31
-32
-33
-34
-35
-36
-37
-38
-39
-40
-41
-42
-43
-44
-45
-46
-47
-48
-49
-50
-51
-52
-53
-54
-55
-56
-58
-60
-62

0
+0.5
+1
+1.5
+2
+2.5
+3
+3.5
+4
+4.5
+5
+5.5
+6
+6.5
+7
+7.5
+8
+8.5
+9
+9.5
+10
+10.5
+11
+11.5
+12
+12.5
+13
+13.5
+14
+14.5
+15
+15.5
+16
+17
+18
+19
+20

+12
+11.5
+11
+10.5
+10
+9.5
+9
+8.5
+8
+7.5
+7
+6.5
+6
+5.5
+5
+4.5
+4
+3.5
+3
+2.5
+2
+1.5
+1
+0.5
0
-0.5
-1
-1.5
-2
-2.5
-3
-3.5
-4
-5
-6
-7
-8
-9
-10
-11
-12
-13
-14
-15
-16
-17
-18
-19
-20
-21
-22
-23
-24
-25
-26
-27
-28
-29
-30
-31
-32
-33
-34
-35
-36
-38
-40
-42
-44
-46
-48
-50
-52
-54
-56
-58
-60
-62
-64
off
off

10.20 April 2005 Update Option

ARONTS systems equipped with this hardware and software feature option provide SNMP trap output and telnet remote access. An ethernet port with static address is required.

10.20.1 SNMP Trap Output

ARONTS can generate an SNMP Trap output to alert network monitoring stations of excessive Failure Log entries. From the More screen under System Setup several SNMP related options are provided:

SNMP Trap Logcodes: select which logcodes are to be counted towards the trigger level to generate an SNMP Trap message.

SNMP Trap Log Entry Trigger: sets the number of log entries specified in the previous option which are required to trigger an SNMP Trap message. Valid values are 1-65535.

SNMP Trap: can be set to Enabled or Disabled.

If ARONTS is equipped for this feature, and the SNMP Trap setting is enabled, then when new log entries with logcodes matching the SNMP Trap Logcodes setting reach the number set by the SNMP Trap Log Entry Trigger parameter, ARONTS generates a single SNMP Trap message. The count is cleared upon entering the testing operation, whether via the Main Menu Test Sites, Resume Testing, or Run Job Queue method. While testing is in progress, the MASTER DISPLAY screen shows the current count at the bottom right of the screen under Log Entries. The field displays x/y, where x is the number of matching SNMP Trap Logcodes added to the Failure Log during this run; and y is the number of total entries in the Failure Log (not the number generated during this run). The y value is identical to that displayed if the SNMP Trap option is not present or activated.

The SNMP Trap message is sent to the IP address specified in the ethernet setup screens. It can be modified by using a web browser pointed to the ARONTS ethernet IP address. Logging in as admin with its associated password provides access to the appropriate parameter screens.

After receiving an SNMP Trap message at the monitoring station, the user may wish to initiate a telnet session to gain remote control of ARONTS and inspect the Failure Log to determine the best course of action.

10.20.2 Telnet Remote Access

The More screen under System Setup provides a setting Telnet Access, which can either be Enabled or Disabled. If ARONTS is so equipped, and telnet access is enabled, then the ARONTS menu system can be reached via a telnet operation. The remote system must use TCP access to the ARONTS ethernet IP address specifying Port 7001. The terminal emulator program should be set for ANSI mode. A suitable program is Hyperterminal. TCP (Telnet) access operates in the same manner as remote modem access described in section 5.3. Of particular note is the special character table shown in that section. The terminal emulator program may be set up to map these keys automatically, or at a minimum the user must remember to use control A for any menu screen Escape key action.

The Main Menu, Run Job Queue, and Tester Program all provide an option to kill the remote telnet session: these should be used to gently exit remote access and restore control to the local operator. However, disconnecting the TCP session without using these menu options while in those three applications only automatically restores local operation. Should a session be inadvertently disconnected when not in those three applications, the user should reconnect, proceed to one of those screens, and exit to restore local control.

If remote access is in progress via modem, then remote telnet operation is inhibited; if remote access is in progress via telnet/TCP, then remote modem operation is inhibited.

10.21 June 2006 Update

This ARONTS software-only update addresses Originating Numbers, RTS-2 sites, and Expected Timeouts.

10.21.1 Installation

It is safest to first duplicate the files in the ARONTS directory to another directory. (Mkdir \ARONTS1; xcopy *.* \ARONTS1 /s from the ARONTS directory.) Updates from previous ARONTS software requires the Sites.dat file to be converted into a newer format. To perform the conversion, from the Dos prompt in the ARONTS directory, execute the CvtSites command. It automatically backs up the previous file (to OldSites.dat). Once this is done, the new software version must be used.

10.21.2 Originating Numbers

Previous software had requirements making the Originating Numbers for RTS-1 ports dependent upon one another; each port could not be identified with an independent number. This linkage is eliminated; each of the eight ports can have any number associated with it no matter what is assigned to the other seven ports.

The capability of identifying RTS-1 sites (under Site Information) as one or two modules, corresponding to 8 or 16 ports, is eliminated. (The 8/16 option described in section 6.3.1 is gone, as is the Originating Number linkage). The ports previously identified as 11-18 and 21-28 are now identified simply as 1-8. Accordingly, when identifying the Out Line in Dialing Registers (section 6.4.5), the single digits 1 through 8 are used. Dialing Registers containing 11-18 from previous files are interpreted as outlines 1-8 to provide backwards compatibility.

o1-o8 Dialing Register Commands

A new Substitution Dialing Register command (section 7.3.1) is provided, which is 3-characters long: o1x through o8x. The lower-case "o" refers to an Originating Number. The second character, 1 through 8, references the Originating Number for that RTS-1 or RTS-2 line. The trailing x is 0-9 or * as described in section 7.3.1 to specify the number of digits.

This command makes it easier to construct Dialing Registers which use one RTS-1 or RTS-2 line to call another of its lines; the same register can be used across all sites, and it is not necessary to duplicate Originating Numbers as Test Numbers. One example to employ the command is to use line #2, for instance, to leave voicemail for line #3 with o3*; subsequently, the voicemail can be retrieved directly from line #3. As always, it is still necessary to specify one Test Number in the Test Definition even though it is unused.

Originating Number Checks in Tester

As described in sections 3.4 and 3.9, it is possible for sites on ARONTS ports to specify Test Numbers which are currently in use at other sites connected to other ARONTS ports. If those Test Numbers are not marked for Multiple Calls, those tests are skipped for partitions using Operation Tables, and the order rearranged or Paused for partitions Routining. As clarification, this check is done using the Test Number number; i.e. Test Number 10 is checked against any other ports which might be using Test Number 10. The actual telephone number stored as Test Number 10 is not compared.

This software version additionally checks the actual telephone number of the Test Number against all Originating Numbers stored for all sites currently being accessed by ARONTS. This primarily comes into play when an RTS-2 line is used as a responder; as shipped, the third line on RTS-2's is programmed for this behavior. The RTS-2 responder function permits in-house RTS-2's to be used as milliwatt Test Numbers without reliance on Telco milliwatts. However, the RTS-2 responder function can only be used if the unit is not already in use. The software feature discussed here prevents attempting to use such Test Numbers when the destination RTS-2 which provides the responder line is already in use on another ARONTS port. With Routining, care must be taken not to create "lock-up" situations where two RTS-2's are being accessed by ARONTS and the Test Definition for each is configured to call the other's responder line: in such a case, they both will Pause indefinitely.

10.21.3 RTS-2 Sites

The RTS-2 Test commands are a superset of the RTS-1 command set, and therefore they can be accessed as if they were RTS-1's. This software version offers a separate RTS-2 Site type (under Site Information). Both the RTS-1 and RTS-2 provide internal peg counts: commands 62-65 for Test Mode accesses, Program Mode accesses, access Failures, and access Answers. The RTS-2 additionally provides a cumulative count of active Minutes (command 66) and a Unit ID number (command 60).

ARONTS automatically polls sites marked as RTS-1 and collects the 62-65 data (if enabled under System Setup). This works whether the sites are actually RTS-1's or RTS-2's. With this software version, ARONTS also collects the 66 and 60 information from sites marked as RTS-2's. No changes are necessary in the ARONTS environment other than changing the site type to RTS-2 to retrieve that data. The most recent values collected are shown in the Analysis (Data) displays and listings as well as the Display Details option in the Failure Log and the Display One screen while testing.

For backward compatibility, the default RTS-2 setting uses "Short" counts: the 62-66 data is sent in 3-digit format (which is all the RTS-1 provides). However, the RTS-2 actually maintains these counts in 6-digit form. By default, ARONTS polls RTS-2's for 3-digit counts. If the RTS-2 is configured not to use Short counts, it responds to commands 62-66 with six digits (parameter 03, nominally reprogrammed with 9403062). If the RTS-2 is placed into this mode, it must not be marked as an RTS-1 site; additionally, under System Setup/More the new option Collect 6-digits of data from RTS-2's must be set to Yes. ARONTS then retrieves all of the data in 6-digit format. With ARONTS configured this way, if the RTS-2 is set for Short counts, this is detected and it falls back to collecting the information in 3-digit mode (but it adds several seconds to the retrieval process to detect the mismatch).

To summarize, it is preferable to mark RTS-2 sites as RTS-2 sites (rather than RTS-1 sites) under Site Information; and if they are programmed not to utilize Short counts, enable 6-digit collection in System Setup. The displays and reports automatically reflect whatever is retrieved.

10.21.4 Expect Timeout

Under certain test scenarios it is expected that a Dialing Register should timeout. An example is the detection of a "stuttered" dialtone indicating a message waiting. This software version offers an additional Dialing Register Expect field option: Timeout. Registers marked to expect timeouts are logged as Successful (logcode 100) if they do timeout. The log line shows Passed (Timeout as Expected, DFx) indicating that the x^th W action timed out.

When a Dialing Register marked to expect a timeout does not timeout it is logged with a new code: 134 Didn't time out as expected.

As always, in order to achieve a correct Failure Log display and listing the Dialing Registers (and Test Numbers) must not be altered between the test run and executing the (Main Menu) Failure Log.

10.22 June 2007 Update

This ARONTS update addresses running the software under Windows XP and extended SNMP trap generation and monitoring.

10.22.1 Hardware

A PC running Windows XP with a serial port (COM1 or COM2) for connection to the Test Module is required. An ethernet connection to a LAN is necessary for Remote Access, shared output monitoring, and SNMP trap creation. A floppy disk drive makes it more convenient to transfer files from a predecessor ARONTS computer. For backwards compatibility the software can run in a Dos-only environment; however, the extended SNMP trap generation and monitoring features are not then available.

10.22.2 Installation

Open C:\Windows\System32\Config.nt. After the line: device=%SystemRoot%\system32\himem.sys add a new line: device=%SystemRoot%\system32\ansi.sys and save.

Create an ARONTS user account with limited or administrative privileges. If remote access is to be utilized a password is required (aronts).

With Windows Explorer, create a C:\ARONTS folder. Extract prog6-07.zip to the ARONTS folder. If data files are not to be transferred from another ARONTS computer, extract data_500.zip to the ARONTS folder as well. Create a Report folder in C:\ARONTS. If the Test Module is not attached to the computer's COM1 port, edit Menu.bat and change Set TELCRO=COM1 to Set TELCRO=COM2.

Right-drag Menu.bat to the desktop and create a shortcut; rename it ARONTS. Double-click the ARONTS icon to bring up the ARONTS software window. Right-click its title bar and set its properties for the largest font size which results in a suitable display; save the changes to the desktop shortcut. (Alt-Enter often toggles the display window between normal and full screen modes, but full screen mode cannot be used when accessing via Remote Desktop.) Right-drag the ARONTS desktop icon to C:\Documents and Settings\ARONTS\Start Menu\Programs\Startup and create a shortcut. If SNMP traps are to be generated, right-drag Startrap.bat in C:\ARONTS to C:\Documents and Settings\ARONTS\Start Menu\Programs\Startup and create a shortcut (rename it Startrap). When running, this window may be minimized but must not be closed.

To transfer files from another ARONTS computer: Go to File Maintenance and Archive each of the six file Current Versions into their respective zip archives. Note the Current Version numbers. Select Backup/Retrieve and Backup everything to a floppy disk except programs (statistics and log file may be omitted if desired). Put the floppy disk in the new computer and go to File Maintenance. Select Backup/Retrieve and Retrieve the same files. Escape to the first File Maintenance screen and Retrieve the Current Version numbers from the six archives.

From the ARONTS Main Menu, select Custom Menu and Initialize SNMP Data.

While logged on with Administrative privileges: Right-click the C:\ARONTS\Report folder, select Sharing, and check Share this folder on the network. Also check Allow network users to change my files to permit remote users to delete used print files. Select Control Panel, System, the Remote tab, and under Remote Desktop check Allow users to connect remotely to this computer. Select Remote Users and Add ARONTS as an authorized remote desktop accessor. Install the net-snmp-5.4.0-1.win32.exe program (only required for SNMP trap generation). Only the Base Components and Standard agents boxes need be checked.

Edit TestTrap.bat in C:\ARONTS and change 1.1.1.2 to the desired SNMP Trap receiver's IP address. Double-click TestTrap.bat and verify that the ARONTS Test Message is received.

10.22.3 Rawdata Path

The default Rawdata path is C:\ARONTS\Report to permit LAN access to Rawdata.txt as it is updated. The path can be changed by altering the suitable line in Menu.bat.

10.22.4 Print Options

Under the previous Dos-only environment, when any List command is given, the file Printer.txt is created in the C:\ARONTS folder. Next, the local printer's status is checked and if it is online at that instant, Printer.txt is automatically spooled for printing (second paragraph in Chapter 6). (To maintain this operation on a Dos-only system, delete PrintChk.dat from C:\ARONTS.)

List commands continue to operate by first creating Printer.txt. One of two things next occurs, depending upon the setting chosen under Custom Menu Autoprint: if Never is picked, the newly created Printer.txt is copied to the C:\ARONTS\Report (shared) folder with a new name of PrintXXX.txt - where XXX spans the range 000-999. The first serial number not found is used for the new file. In this manner, if Remote Desktop is used to control the ARONTS computer, and a List option is performed, the remote user has immediate access to the print file through the network. After copying or printing, the user should delete the PrintXXX.txt file for simplicity in identifying new print files.

If Autoprint Always is picked, Printer.txt is automatically spooled to the system printer. A serialized print copy is not created in the Report folder.

Under the Windows environment, the Main Menu Terminate Print Job option is not used; instead, the built-in Windows local printer folder is best utilized for printer control.

Standard ARONTS List options presume a fixed width font with 80 characters per line. Loading PrintXXX.txt into Notepad for printing suffices. Wide list options assume a 132 character per line capability. It is best to open PrintXXX.txt in Word, Wordpad, or other word processing program in order to set a small fixed font size, landscape printing, or both prior to printing.

10.22.5 SNMP Trap Output

SNMP traps are generated in a different manner than described in section 10.20.1. Traps are handled independently for each site and provide information about the event. Up to 20 Dialing Registers are marked as potentially initiating a trap. Each of these registers is designated with a streak number required to send a trap. Ordinarily this refers to a cumulative number of failures (of any type) for that register at that site without any intervening successes (passes). To define these "trap" registers, Custom Menu option Edit SNMP Registers is used (it simply edits the text file SNMPRegs.dat). Beginning at the third line in the file, up to 20 lines can be included with information on 20 Dialing Registers. The first number is the Dialing Register number. A streak number is specified next: negative for failures and positive for successes. Typically this is a negative number. This sets the threshold of cumulative failures (or successes) for when a trap is to be generated. This streak is handled separately for each site: i.e., if -5 is chosen, this requires five successive failures for this Dialing Register on a particular site; successes with this register at another site take no effect.

After the streak specification, a textual description is provided. Only the first 20 characters are used. This description is included in the generated SNMP trap message.

Replace the sample third line with actual information. To verify the interpretation of SNMPRegs.dat, after saving and closing Notepad select Custom Menu option View SNMP Registers.

If (for some reason) a positive streak is specified for an SNMP register, a single trap message is generated when that streak of successes is reached; no further traps will be generated for that site/register (until Initialize SNMP Data is executed, or a failure occurs which resets the successful streak). If a negative streak (cumulative failures) is specified, a single trap message is generated when that streak of failures is reached. Additional failures without an intervening success do not create more traps. Once a trap has gone out for a failure streak, the next success for that site/register generates a single trap message indicating success (the problem has cleared). Once a success resets the failure streak count, another streak of failures can again create a failure trap message.

The trap message is a Generic Trap (6) with a Specific Trap Code of the site number. The textual description attached is of the form:

10: White Marsh, MD Failed Reg 10 (no MWI after 30 sec) 5 times 06/10/07 20:05:11

The site number is listed first (the same as the Specific Trap Code) followed by the first Notes line from Site Information (trailing spaces are omitted). Either Failed or Passed follows. The Dialing Register number and SNMPRegs.dat description are shown next. The streak threshold is shown (or 1 for a pass after a previous failure streak generated a trap). The date and time are appended to the message content.

The streaks used to determine if a trap message is to be generated are persistent; i.e., stopping a test session and starting a new one retains the previous streak count (as well as the cumulative passed and failed counts depicted in TrapStats.htm).

Depending on the system, it can take a number of seconds to actually complete the SNMP trap message generation. It is presumed that the test environment is set up in such a way that voluminous quantities of traps are not typically sent, which would significantly slow down all ARONTS test processing.

With SNMP Trap Enabled in Setup/More, when testing is in progress the MASTER DISPLAY screen shows the Log Entry count as x/y as described in section 10.20.1. However, x represents log entries using Dialing Registers listed in SNMPRegs.dat which were added in the current test run. The y value continues to show the total number of entries in the log file.

Configuring SNMP Data

The first line in SNMPRegs.dat defines the SNMP trap message. When editing it, change 1.1.1.2 to the IP address of the trap receiver as tested in section 10.22.2. For a different MIB manufacturer code, replace 1.3.6.1.4.1 as desired. The ~ character represents the site number, and is used for the Specific Trap Code; if a single Specific Trap Code is desired for all sites, replace ~ with the desired Specific Trap Code. If a different MIB category is desired for the description, change .1.3.6.1.2.1.1.1 to another value. The | character represents the pre-built trap textual message content. When making changes in this line, it is useful to first test them with TestTrap.bat by changing that file.

Viewing Trap Generation Status

In addition to traps received at the network SNMP monitoring station, LAN users can access status files in the shared Report folder. Traps.htm contains a list of all traps generated: each line is the textual description sent with the trap (failures depicted in red). Double-clicking should display the file in the default web browser. The file continuously appends as traps are generated. An incomplete last line may appear as the shared file is accessed, but the information is at most one minute late.

TrapStat.htm shows the cumulative passed and failed counts, and current streak statuses for the SNMP Dialing Registers for each site. The streak is noted as passed or failed. The site number and description, and SNMP Dialing Register description are the same as for the trap messages. The date/time shown indicates the last time this site/register encountered action. Failure streaks are depicted in red. Double-clicking should display the file in the default web browser. This file is updated once per minute.

Counts in TrapStat.htm are cleared, and entries in Traps.htm are deleted with the Custom Menu Initialize SNMP Data option.

10.22.6 Remote Access

Under Windows XP, remote modem and telnet access built into the ARONTS software is not used. Instead, the Windows application Remote Desktop is employed. The client computer specifies the ARONTS computer information along with the ARONTS user and associated password. When a remote control session has ended, the user should end the Remote Desktop session to permit others to gain control.

It should be noted that it is not necessary for a remote user to activate Remote Desktop merely to monitor the running status; the shared Reports folder available over the LAN permits inspection of the Rawdata.txt (if that is even required with the inclusion of the other files), Traps.htm, and TrapStat.htm files.

10.22.7 File Maintenance

While the Backup/Retrieve features provided under Main Menu item File Maintenance may still be used with floppy disks, in the Windows environment it is simple to drag the entire C:\ARONTS folder to backup media such as flash drives. However, the File Maintenance options to store different versions of the various data files into the six archives can still be used to advantage for maintaining multiple files for differing test scenarios.

Install/uninstall options are not required for the ARONTS software proper; copying and deleting the C:\ARONTS folder suffices. The general setup requirements addressed in section 10.22.2 are applicable.

Logo