Figure 1
Automated Remote Origination Network Test System
Instruction Manual
Copyright 1991, 1996, 2005, 2006, 2007
IC Engineering, Inc.
PO Box 321
Owings Mills, MD 21117
410-363-8748
Table of Contents
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.
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.
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:
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
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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:
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:
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.
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.
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.
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).
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.
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:
|
|
Remote |
| 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.
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
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
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
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
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.
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.
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.
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.
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
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
