Single-push-button testing automates Sonet network certification
Detailed operational analysis of fiber-optic networks in a single-ended configuration can be verified by means of single keystrokes on the latest Sonet test sets
Charles E. alexander
cerjac telecom operation
As synchronous optical networks grow more complex, Sonet test sets are becoming more intelligent. The latest Sonet test sets are small, rugged, relatively lightweight and computer-powerful. Indeed, they can provide active and automatic interpretation of Sonet overhead and payload conditions with the push of a single front-panel button. Consequently, comprehensive testing and monitoring of complex Sonet signal transmissions over fiber-optic networks can be made quickly, easily and accurately.
In addition, skilled and semi-skilled test operators can use these Sonet testers for network interpretation and analysis. Furthermore, experienced and inexperienced network planners and engineers can operate and check out the installation of Sonet network equipment and turn up customer services without having to become maintenance experts.
Widespread deployment of fiber-optic networks is accelerating Sonet services throughout the carrier marketplace. This trend presents a host of challenges for field personnel involved in Sonet network installation and verification as they encounter this challenging technology. Fortunately, the latest Sonet test sets are providing intelligent tools to ease this transition by taking advantage of Sonet`s advanced transport and overhead capabilities.
The Sonet standard supports a range of signal payload types, from traditional digital signals, level one (DS-1s) and DS-3s to optical carrier, level 3c (OC-3c) clear-channel 155-megabit-per-second links. In addition to payload support, however, Sonet overhead capability provides key alarm, parity and automatic protection switching functions that can be used for diagnostics, testing and troubleshooting.
In the early days of Sonet deployment, personnel involved in the installation of associated equipment required detailed knowledge of payload mappings and overhead byte definitions. Armed with this knowledge and test equipment that provided access to the basic 1s and 0s of Sonet signals, test personnel with sufficient expertise were able to solve problems encountered in installing and commissioning new Sonet equipment and services and to troubleshoot Sonet circuits.
Today, however, Sonet test sets employ automatic configuration, trouble identification and automatic sequencing, and are helping to redefine Sonet installation and maintenance requirements. In the past, test personnel had to read and interpret hexadecimal or binary overhead values. Now, Sonet test sets provide "plain English" decodes for automatic protection switching messages and other critical overhead functions, and interpret overhead data to provide immediate and accessible information on payload type and quality.
For example, with a push of the auto button, the automatic configuration function is activated and provides fast and accurate verification of the network setup by sequentially performing signal source, synchronous transport system (STS) payload and sub-rate scanning, pseudo random binary sequence matching, configuration reporting and alarm and error reporting.
Via a troublescan button, the Sonet test set can prioritize several error results and display them in oversized characters. Numerous status, alarm and error light-emitting diode lamps indicate whether the Sonet signals are corrupted.
With another button for stimulus/ response test capability, the Sonet test set shows users how to hook up network equipment, automatically sequences the equipment through alarm and error conditions to verify proper operation, and reports exception conditions.
A built-in 3.5-inch floppy-disk drive is used to save and recall output data and user configurations, support field-usage of pre-programmed test suites and protocols, and upgrade the test set`s firmware.
Early Sonet systems tended to be simple point-to-point configurations. These systems eventually gave way to ring architectures--both path-switched and line-switched. Today, these topologies are combined with other network elements, such as digital crossconnect systems, in complex mesh networks.
In a typical network segment, a subtending OC-12 (622-Mbit/sec) terminal multiplexer is used as a delivery vehicle for services dropped from an OC-48 (2.5-gigabit-per-second) fiber-optic ring. In this setup, the OC-12 equipment is located far away from the OC-48 terminal, so diverse-routing of the OC-12 circuit is employed using automatic protection switching on the OC-12 extension. At the OC-12 site, STS-1 signals are connected to a data crossconnect system (DCS) for grooming of DS-3 and VT1.5-mapped DS-1 signals. The OC-3c concatenated services are dropped directly from the OC-12 terminal.
Installation of the OC-12 terminal multiplexer in this network raises some technical issues and could introduce these potential problems:
The OC-12 drop to the terminal multiplexer might not be available at the time of initial installation, necessitating stand-alone verification of the multiplexer without a far-end system.
When the OC-12 drop is provided, it might not be provisioned for the correct automatic protection switching type and mode, and it might not be configured with the proper selection of tributary mappings. Furthermore, the drop might be provided by another network. This condition would limit the amount of information available about the circuit and make it difficult to interrogate network element databases and perform configuration changes.
The OC-12 multiplexer could provide a connection between two previously unconnected Sonet islands--the OC-48 ring and the DCS. When interconnecting Sonet systems in this way, synchronization is always a concern, particularly when crossing boundaries between networks that use different primary reference sources.
The STS-1 connections to the DCS may also produce difficulties. It is necessary to verify that the DCS mappings within the STS-1 (clear-channel, mapped DS-3, or VT1.5-mapped DS-1) correspond correctly to those in the STS-1 signals dropped from the OC-12 multiplexer.
The OC-3c circuits dropped from the OC-12 multiplexer must be verified for end-to-end continuity and error-free performance before services are delivered to the end user.
Simple point-to-point systems are often installed by configuring both ends of the system, connecting the fiber-optic cable and then working to clear the system alarm lights. If the two ends of the system are not being installed one at a time or, as in this network example, if the far-end signal is being provided from a non-similar system or another network and is not yet available, tests must be made to verify terminal multiplexer operation in a stand-alone configuration.
After network hardware and software installation, the multiplexer is powered on, the Sonet test set is connected to the multiplexer`s main OC-12 connection and auto configuration with trouble-scan is initiated on the test set by a single keystroke. The protection line interface card can be partially removed from the multiplexer to keep the main line active during this test.
Auto-configuration verifies the presence and format of the OC-12 signal and identifies the payload assignments of each of the 12 constituent STS-1s. (Frequently, at this point in the installation, each STS-1 is provisioned to the "Sonet unequipped" state.) The desired payload assignments can then be programmed into the multiplexer and verified by again running auto-configuration on the test set.
This one-keystroke test procedure typifies the new capability in Sonet testing. Prior to the advent of auto-configuration, it would have been necessary to examine the overhead of each STS-1 in sequence, manually check the C2 overhead byte and interpret the hexadecimal or binary value of that byte to determine the payload mappings in the multiplexer. Furthermore, if a VT1.5-mapped payload is encountered, interrogation of the VT signal label in the V5 overhead byte is also necessary. This involved procedure requires detailed knowledge of the Sonet standard, the mapping mechanisms and the overhead byte definitions. Now, with the latest Sonet test sets, all these functions can be accomplished with a single keystroke.
Initiation of auto-configuration also places the Sonet test set in trouble-scan operation, which monitors for error and alarm conditions. Trouble-scan automatically detects Sonet framing, parity and far-end block errors. If no errors are detected, a "no trouble" message is displayed on the test set. Sonet alarms can be easily checked by examining the field of alarm lights on the test set. If a trouble or alarm light is turned on by the test set indicators, it can be traced and cleared by systematic module replacement or provisioning of the multiplexer while visually monitoring the test set.
After verification of normal operation, the multiplexer should be checked for proper operation under abnormal conditions by the Sonet test set. First, the proper alarm responses should be verified on the OC-12 Sonet link. Once again, automatic test capability can be implemented.
The Sonet overhead provides virtual loopback capability by sending upstream responses to specific downstream alarm conditions. For example, the line remote defect indicator test, formerly line far-end receive failure, automatically applies downstream failure conditions, such as loss of signal, loss of frame and line alarm indication signal, and looks for the line remote defect indicator response. A simple pass/fail result is then displayed on the Sonet test set.
Automatic protection switching should also be checked, first by verifying the automatic protection switching and mode on the terminal equipment, and then by forcing a protection switch. The switching type and mode can be checked by looking at the English language decode of the K1/K2 overhead bytes. The readout will indicate "1+1" or 1:n and either unidirectional or bidirectional. The results should agree with the planned automatic protection switching type and mode for the circuit and should agree with the type and mode detected in the OC-12 drop signal.
B2 line errors can be injected to force a switch to protection mode. Note that the protection fiber-optic cable connection on the OC-12 terminal should be looped or connected to the far-end system. The multiplexer will not switch to an unterminated, alarmed circuit. Verification of the switch-to-protect is displayed on the multiplexer`s craft terminal.
Far-end signal verification
Before the far-end fiber-optic cable feed is connected to the terminal multiplexer, the incoming signal can be checked in a way that is similar to how the near-end multiplexer was turned up. The incoming fiber-optic cable is connected to the Sonet test set, and auto-configuration with trouble-scan is initiated. This procedure reports the format, payloads and error/alarm conditions found in the received Sonet signal and optical power. Verification is therefore confirmed that the received signal falls within acceptance guidelines. The English-language decode of the automatic protection switching type and mode can also be checked to verify proper configuration of the far-end system.
If the received parameters do not meet the agreed configuration, the network providing the drop can be contacted, and the issues can be resolved before the near-end OC-12 multiplexer is connected to the circuit.
Because the OC-12 multiplexer in the network has both Sonet inputs and outputs, it will insert pointer adjustments as required to compensate for differences in the Sonet line rates. For example, the OC-12 system will most likely generate STS-1 and OC-3c drops based on local office building integrated timing source timing. However, the incoming OC-12 signal might be timed from another network. This timing difference will result in pointer adjustments in the STS-1 and OC-3c drops.
In general, an appreciable level of pointer adjustments should raise a potential red flag, suggesting a possible timing failure in either the incoming OC-12 signal or in the newly installed OC-12 multiplexer. Whereas establishment of acceptance levels for pointer adjustment activity is currently a network-specific activity, automatic display of pointer adjustment activity can identify potential problems even in the absence of acceptance thresholds.
In similar fashion, the synchronization between the DCS and the OC-12 multiplexer can be verified by examining the pointer adjustment activity in the upstream STS-1s going toward the OC-48 ring. The STS-1s originating on the DCS (and multiplexed through the OC-12 system) will exhibit pointer adjustments if a timing difference exists between the DCS and the OC-12 multiplexer.
Auto-configuration and trouble-scan can be used to check the STS-1 connections from the DCS. This testing will determine whether the payload configurations are correct and will identify STS-1 and VT1.5 path level errors and alarms, along with STS-1 section and line status.
Once again, the Sonet test set is connected to the line under test, and auto-configuration is initiated. Discrepancies between the actual configuration (reported by the test set) and the agreed configuration can be eliminated before the circuit is turned up.
The OC-3c end-user drops can also be checked using auto-configuration. Additional testing may be in order for these links, however, because they represent a clear-channel customer service. To qualify these links, it is often appropriate to run long-term commissioning tests and collect data for documentation of service level and quality.
Each network is generally classified with its own testing standards for length of test and bit-error-rate test pattern to be employed. In these networks, test operators should pre-store these test setups in the test set`s memory or floppy disk. The standard tests can then be quickly called up in the field and initiated. After the extended test is run, a hardcopy paper or floppy disk record can be placed on file for the circuit. u
Charles E. Alexander is product line manager for Hewlett-Packard Cerjac Telecom Operation, Westford, MA.