The bigger, the better

John Anians is a senior engineer at Tellabs (Naperville, IL), where he and others perform product evaluations on digital cross-connects. Telecom carriers use digital cross-connects to integrate new equipment into networks containing previous generations of equipment. The cross-connects contain electrical and optical interfaces that run at speeds from T1 (1.544 Mbps) to OC-48 (2.5 Mbps). Anians does his best to emulate network configurations that customers will use.

Tellabs 5500 digital cross-connect chassis.

A: I start with a product definition from marketing, which I use to begin planning a test bed. The project’s lead engineer will write an overview of the product. Systems engineers will then develop documents and specifications on how the product will work. From those documents, I estimate the time required to test a product. If we deem the test time is excessively long, we won’t design the product.

Q: Once a product is in development, how do you proceed?

A: I make it a point to understand how a new feature will work, then I develop a strategy for how our customers will use the product. I test a product from an applications perspective. I emulate how the cross-connect will grow at the customer’s site because you can never make a test bed too big.

Q: How does a cross-connect system “grow”?

A: Customers grow a cross-connect system by increasing the number of cross-connects, adding blades to a “shelf” [chassis] and by adding new shelves to the system as their needs grow. For example, in a previous project that involved cell-site aggregation, I started by emulating a few cell sites in a test network, then added cell sites until I had as many as a customer might use. I kept adding blades, and I tried to duplicate the new shelf’s life cycle.

Q: What does a test bed contain?

A: Test networks contain call generators and SONET/SDH communications-performance analyzers. We use our own equipment and commercial test equipment to generate traffic. I automate the test bed by writing Tcl/Tk scripts.

Q: What’s involved in a test?

A: I run as much traffic as possible in a test, and I analyze performance by conducting bit-error-rate measurements. A product must run error free to be acceptable. I also test for redundancy—traffic must be protected (facilities, blades, intra-system networks, etc. are all designed to protect traffic in the event of a signal or equipment failure). A customer must also be able to remove and replace blades while the system remains online.

Q: How long do you spend testing a new design?

A: Initial test plans and scripts take about two months to complete with a final evaluation taking about four additional weeks. Following a test, we produce a report that highlights the number of tests passed, tests failed, and defects found. System and design engineers use that data to make design changes.

Q: What are the greatest test challenges you face?

A: The first challenge of my job comes in learning how our customers will use our products. I don’t want disappointed customers. Beyond that, I’d like my test equipment to let me view all the data paths in a system simultaneously. That is, I want the ability to look at all tributaries in a data stream. For example, while evaluating a DS3 stream, I want to look at all of its DS0 tributaries.