There are any number of things you can point to that demonstrate what is driving growth in fiber deployment, regional FTTH/PON initiatives, national high-speed broadband growth, core network 100/400G upgrades, or preparation for new services such as 5G.

Loopback?

One thing that is critical for these new or upgraded services to function to their peak and with maximum reliably is that the physical layer fiber networks they are built on have no flaws. If it’s a new link or network, that means verifying that fibers have been laid and spliced correctly in the first place. If it’s existing networks, that means checking that fibers are still in good shape and that nothing has changed significantly since original deployment (remember that accidents and damage do occur and sections may have been replaced/repaired).

The most thorough approach in these cases is to check and certify fibers bi-directionally, but as the saying goes there is more than one way to crack an egg, leading to many questions: do different bi-directional (bi-dir) test methods achieve the same end-goal, do they perform the same in terms of total testing time, is one approach better than another, or is one approach more suited for a specific application?

We’ve touched on bi-directional (bi-dir) fiber testing in previous blogs where we looked at bi-dir fiber testing and how to cut test times in half. There are a number of reasons to perform bi-dir test and when it comes to the OTDR piece the basics are that it gives more accurate measurements, can reveal more detail and correctly diagnose issues (or non-issues), for example:

Hidden events

Bi-dir OTDR fiber tests can reveal events hidden by OTDR dead zones where events that are close together could be missed and shown as a single event, the reflected (or backscattered) light from the first event means that the light reflected by a nearby event, just after the first, is swamped or missed by the OTDR. Testing from the other end (far end) of the fiber link would reveal that second event so you have a more accurate view of what is in the real/actual fiber link.

Gainers

Differences between fiber manufacturers or even manufacturing batches can lead to variances in the backscatter coefficient of a fiber and when spliced to another fiber results in a ‘gainer’. Bi-dir OTDR testing allows you to average out these manufacturing/ backscattering/ measurement differences to give true event loss, helping you diagnose whether a splice, connector or section of fiber really is a problem and needs to be replaced, potentially saving you time and money or stopping you from abandoning a good fiber link.

As there is a clear benefit to bi-dir OTDR testing, the question is: what’s the best way to go about it and are there any limitations? You can generally choose between three use cases:

  1. Two units – a true bi-dir approach with one at each end of a link under test
  2. One unit – that is moved from one end of the link to the other to test both directions
  3. One unit – that stays put and employs a loopback device to enable bi-dir testing

The only realistic and practical options, at least in terms of total time to complete testing which includes travel time, are 1 and 3.

The first and obvious thing about option 1 is potential cost due to requiring two OTDR versus just one for option 3. Also, with option 3 you can effectively test two fibers at once – the first fiber from the OTDR at one end and loopback device at the far end, plus the second fiber (obviously using the same ducting or in the same fiber bundle) coming from the far end loopback device to the OTDR location. You would be forgiven for immediately choosing option 3.

With option 3, there is a manual element to the process. You have to run an OTDR test in one direction, pause testing while you disconnect from fiber 1, inspect and connect to fiber 2, then manually restart testing, plus (critically) you have to perform an additional continuity test before the main OTDR test to make sure the loopback device is connected properly. With option 1, you do not need to do this as there is an OTDR connected at both ends of the fiber plus there are solutions available (such as the VIAVI FiberComplete application) that will automatically handle testing in both directions to remove any delays that come from manually starting each part of the bi-dir test. VIAVI has tested both approaches: our fully-automated FiberComplete solution versus the loopback mode on our regular OTDR. There was only a marginal difference in the total test time (which includes all the setup, fiber inspection and actual testing time). The extra time taken with the loopback approach to continuity check, OTDR test, disconnect, inspect, reconnect and then test again was more or less the same as the time taken by FiberComplete to perform the automatic exchange of setup data between near- and far-end devices, perform bi-dir testing, and retrieve test results from the far-end unit.

If time is not the key issue, does the choice really boil down to equipment cost? The answer is no, it’s actually the total distance, or length, of the fiber link or loop being tested. I’ll explain!

We already touched on the issue earlier when stating that with loopback, you can test two fibers at once, and two fibers means twice the length of fiber. If site A and site B are 10 km apart, the total length of fiber under test is 2 x 10 km = 20 km.

The distance limit matters when it comes down to the trade-off between getting good event detection at the near-end (closer to the OTDR) versus far-end of the fiber loop with a single OTDR test/acquisition. Up to approximately 20 km, you can test both fibers in the loop and get good event detection and measurement accuracy at both near and far ends of the loop, enabling reliable matching of events when aligning the results from testing carried out in each direction in order to perform the results analysis and averaging. Once you go beyond 20 km total loop length, the wider OTDR test pulse width required to get good event detection and measurements at the far end starts to impair event detection and measurement accuracy at the near end… and vice-versa. So, up to around 20 km length for loopback testing enables you to achieve the best tradeoff with OTDR pulse width setup to get good event detection, near-end versus far-end. Once you go past this approximate total length, you need to start looking at true bi-directional testing (use cases 1 or 2).

This table sums up the pros and cons:

PriceTesting timeEase of useDistance limitation
1 = Two units
2 = One unit
3 = One unit + Loopback

 

So it really comes down to the application and specifically the total length of fiber link being tested that will govern which approach to take. True, fully-automated bi-dir test with two OTDR is better-suited for longer links, whereas a single OTDR with a loopback test feature is more suitable for shorter distances, say up to 20 km. This means for access network applications, loopback would be a great approach that provides the best balance between price and testing time measured against ease-of-use (remember there is loopback device that has to be installed which requires a continuity test before the main tests) and total distance tested.

For more information take a look at our Fiber Testing or OTDR Testing a pages. I hope you will join me for Part II when we will discuss bi-directional PON certification.

 

Douglas Clague is currently solutions marketing manager for fiber optic field solutions at VIAVI. Doug has over 20 years of experience in test and measurement with a primary focus on fiber optics and cable technologies, supporting the telecommunications industry. Prior to VIAVI, Doug held positions as manufacturing engineer, solutions engineer and business development manager. Doug has participated on numerous industry panels around fiber and cable technology trends. He attended Brunel University in London and graduated with an honours degree in electrical and electronic engineering.

 

About The Author

Avatar

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Do NOT follow this link or you will be banned from the site!
Close