SONET/SDH Path Delay Network Emulator FAQs

Q. What is the difference between a SONET Path Delay Network Tester and a SONET Signal Delay Network Tester?
ANS: The Anue SONET Path Delay (PD) Emulator can differentially delay and impair individual paths within a SONET or SDH signal, in order to simulate real world network behavior of multiple concatenated paths. With Path delay, some of the transport overhead bytes are modified.

The SONET Signal Delay (DG) Emulator, in contrast, delays the entire signal that is being transmitted over an optical fiber. With signal delay, the traffic is not modified (unless impaired by the user) in any way; overhead and payload are delayed equally and remain together. Signal Delay just delays the traffic as though it were traveling over a long distance.

Q. What is the delay resolution of the SONET Path Delay Network Emulater?
ANS: The path delay tester has the ability to *differentially* delay any given path (with respect to all other paths) in increments of one SONET location. Thus, the minimum *differential* delay is 0, and the maximum differential delay is approximately 320ms. The resolution, when dealing with STS-1's is 1 byte, or ~154.3ns. The resolution when dealing with STS-3c's is also 1 SONET location. However, since we are dealing with an STS-3c, this is 3 bytes, but the resolution is still ~154.3ns as we are dealing with 3 bytes per SONET location.

Q. What is the resolution of the SONET Signal Delay Network Tester?
ANS: The resolution is 1 bit. One bit at OC 192 rate is ~100ps, at OC48 is ~401ps, at OC12 is ~1.608ns and at OC3 is ~6.43ns. The DG48 has a minimum delay of ~300ns, and can be incremented/decremented bit by bit, or set to a new delay, up to 250ms (or up to 750ms with the memory extension options). Note that in the Signal Delay, or DG, products when the delay is changed, the result is not 'seamless' as seen by the equipment to which it is connected. This is because the effect of changing the delay is the same as changing the length of the fiber it is emulating, and thus can result in lost data or the insertion of idle frames.

Q. What is the minimum delay through the PD Path Layer Network Emulator
ANS: The PD breaks down a SONET signal into 2 basic sections. The first, the transport overhead, is delayed by a fixed amount, and is approximately 400 ns. The 2nd section, the payload, is analyzed to identify the various paths within the SONET signal. The various paths can be minimally delayed by 64*4*154.3ns=39.5us. Note that since all the paths are delayed by the same minimum amount, the *differential* delay for the paths is still 0.

Q. What bytes, if any, are modified by the PD Network Tester?
ANS: The PD modifies the B1, B2, H1, H2 and H3 bytes. However, the SS bits of the H1 bytes are unmodified.

Q. Why are these bytes modified?
ANS: They are modified because when the various paths are delayed, and then rearranged, the outgoing pointer will be different than the incoming pointer. Therefore, the H1, H2 and H3 bytes are recomputed. Because of this, the section and line BIP (byte interleaved parity) bytes, B1 and B2, must also be recomputed.

Q. Are any other bytes modified?
ANS: Yes, but only under user control. Currently, on the PD Network Tester the user has the capability to insert path AIS or path unequipped on a per path basis. Additionally, the user has the ability to insert programmable errors on the entire line or on a specific path. Note that path level erroring is done prior to recomputing the outgoing B1/B2, and that line level erroring is done after recomputing B1/B2.

Q. Why is the TOH delayed differently than the SPE?
ANS: The TOH needs to be separated from the SPE because the SPE (the various paths) needs to be delayed by varying differential amounts, depending on what the user has programmed.

Q. Can I get access to/modify the H4 byte?
ANS: Not currently, but this will be supported in future network emulator releases.

Q. What bytes are monitored by the PD Network Emulator?
ANS: In the receive section, the user has access to the pointer values and states. In the transmit section, the user has access to the outgoing pointer values and states.

Q. What rates are supported?
ANS: PD is currently available for OC3, OC12, OC48 and OC 192 rates. OC3/12 rates are considered one load.
OC48 is considered one load.
OC192 is considered one load.

Q. PD is a high order Path Delay system. What about low order delay?
ANS: Anue plans to have a low order OC3/12 Network Tester available in the future.

Q. What is the difference between a low order and a high order Path delay tester?
ANS: The high order Path Delay Emulator (PD) analyzes the incoming signal, down to the STS1 level. The low order Path Delay Emulator (LOPD) is capable of further analyzing an STS1/STM0 or STM-1 path for VT1.5, VT2 or VT6 (SDH equivalents are VC11, VC12 and VC2) rates. (Note that VC-3 support will be available in a future release of the LOPD.) The LOPD is then capable of differentially delaying the low order paths. Note that the PD unit does not re-compute the B3 bytes of its paths. However, since the LOPD delays its constituent low order paths, it requires the B3 to be recomputed, if that path is setup to do low order delay, as the outgoing V1/V2/V3's will be recomputed.

Q. What applications would I use the MSPD Network Tester for?
ANS:

Q. What is a Load?
ANS: A “Load,” also referred to as a Software/Firmware Load, is a key part of an Anue Emulator. A Load, together with a Chassis and one or more Blades (or boards), forms a functional Anue Network Tester System. Unlike Chassis and Blades, Loads are not generic. Each Load provides a different functionality. Gigabit Ethernet Delay, Fibre Channel Delay, SONET Path Delay and SONET Signal Delay are all different Loads. Multiple loads can be combined onto a single Chassis/Blade to create “Combo” Emulator Systems.

Q. Does the MSPD follow incoming increments and decrements?
ANS: Yes. All incoming inc's and dec's are followed. Note that if incoming inc's dec's are greater than the SONET required 1 per 4 frames maximum, the MSPD will observe the incoming inc's and dec's, but will generate outgoing inc's and dec's according to the SONET standard, unless the user requests an override. Thus, for example, if a path is observed to get an inc every 2 frames (1 inc every 2nd frame), the outgoing path will generate an inc every 4 frames, and extra inc's will get put into a queue. If 10 incoming inc's are received, 10 outgoing inc's will be generated, but spaced at a minimum 4 frames apart.

Q. Can I generate outgoing increments and decrements, independent of the incoming increments and decrements?
ANS: Yes. Each path can be independently setup to generate outgoing inc's/dec's. This feature works in concert with any incoming inc's/dec's. For example, the user can request the MSPD Network Tester to generate 500 outgoing inc's, spaced 500 frames apart, and if an additional inc/dec happens to arrive, that inc/dec will be followed, in addition to the 'extra' generated inc's.

Q. How do I order an Anue Network Emulator or request more information?
ANS: Contact Anue Systems at sales@anuesystems.com or anueinfo@anuesystems.com, or by calling 512-527-0453. You can also contact your local sales representative or international distributor if one exists in your area. See our website for details: http://www.anuesystems.com.