Continuous optical monitoring: how many fibres in the cable are actually being watched?

“Continuous optical monitoring system, compliant with current standards.” Another specification line that skips the thing that decides everything else: how many fibres in the cable actually stay under surveillance, and with what architecture. The model that answers this question has had a technical name for twenty years, RFTS — Remote Fibre Test System — and it is described by an ITU-T Recommendation that almost nobody cites under the right number.

The standard, under its current number.

The document is ITU-T Recommendation L.40, Optical fibre outside plant maintenance support, monitoring and testing system, approved by the World Telecommunication Standardization Assembly in Montreal between 27 September and 6 October 2000, with Appendices I to V approved on 9 March 2001. Since 15 February 2016 its number is L.302: the same Recommendation, renumbered without amendment and without republication. The L.302 record shows “in force”. Anyone who writes “L.40” in a 2026 specification is citing a number replaced ten years ago; the content is unchanged. The scope stated in clause 1 covers both trunk and access networks: it is not a document written for FTTH alone.

The three-part architecture, and a caveat.

The body of the Recommendation (clause 4) describes the minimum system — an operation terminal and an optical testing module (OTM) — with an optional server that adds a database and control of several modules. The OTM contains a controller, the test unit with an OTDR and power meters, fibre selectors, a coupler to inject or tap the test signal, a filter that protects the transmission equipment from the test light, and a water sensor at the cable joints.

A separate appendix, explicitly marked informative — “United States experience regarding remote fibre monitoring and testing” — describes the architecture the market still calls RFTS today, with a three-element layout: an OTAU (Optical Test Access Unit), a remotely controlled optical switch, typically sized at 72 fibres; an RTU (Remote Test Unit), the remotely driven OTDR; a TSC (Test System Controller), which selects the fibre and stores prior traces along with geographic route data. This is not a normative requirement: it is reported experience, and the distinction matters in a specification. One limitation the appendix flags: the TSC scans one fibre at a time, and if many fibres are connected, a break occurring right after the last scan can stay invisible for a time tied to the cycle — a figure to ask for in writing.

The dedicated-fibre arithmetic.

This is the question worth the expense. The appendix states it plainly: monitoring only dark fibres does not guarantee detection of faults affecting only the working fibres — the example given is water entering the cable and freezing, degrading some in-service fibres while leaving the monitored dark fibres unaffected. The remedy exists — monitor the active fibres too — but the number of fibres monitored drives up cost, which sets a practical limit: in the reported experience, typically only one or two fibres per cable stay under continuous surveillance. Anyone who writes “RFTS monitoring” without stating how many fibres in the cable are covered has bought a label, not coverage.

The alternative that extends coverage to active fibres needs a WDM coupler between the transmission equipment and the fibre, to inject the out-of-band test wavelength alongside the service signal — the same principle, the same filter and maintenance-band constraints already described for the 1650 nm in-service measurement. The stated benefit: power loss is detected almost in real time, the RTU is only needed to localise, and dark and active fibres are tested in the same cycle.

The appendix that speaks Italian.

The same document carries a third appendix, also informative, built — in its own words — “on the Italian experience and on information collected by European operators”. It describes a different approach from the American one: not cyclical OTDR scanning, but continuous attenuation monitoring, obtained by tapping a fraction of the power already travelling along the in-service fibre. The stated advantage is precisely what a periodic scan cannot give: transient degradation — the appendix cites strong vibration at a splice — does not show up in a periodic measurement, because by the time the OTDR comes round it is over. The figure reported is blunt: up to 20% of preventable faults have an initial stage detectable only through continuous attenuation monitoring. In this scheme the OTDR goes back to doing what it is for — locating the event once there is one — instead of running on in-service fibres, a use the same appendix advises against because of the risk of interference with WDM and optical filters.

Table III.1 is worth reading for a different reason. It lists the actors in outside plant maintenance, and alongside incumbent operators it explicitly names utilities — gas, water, energy — railways and motorways: those who own an optical infrastructure already in the ground and are starting to sell dark fibre without an in-house maintenance organisation. For anyone leasing dark fibre the question stops being technical and becomes contractual: availability parameters end up in a physical-level SLA, and Time-To-Locate and Time-To-Repair become contract terms with a penalty behind them. The monitoring system is what makes it possible to meet them — and, no less important, to demonstrate that they were met.

What the standard makes mandatory, and what it does not.

Table 1 of L.40/L.302 assigns each function a status, and that distinction matters more than the Recommendation’s title. Under preventative maintenance — periodic or continuous surveillance, detection of increasing loss, of power drop, of water ingress — every function is optional. After a fault, by contrast, three functions are required: confirmation of fibre condition, distinguishing a transmission-equipment fault from a fibre-network fault, and fault-location measurement. Fibre identification is required too, and — the item that matters to everyone in Italy — so is the interface with the outside plant database. A specification that just asks for “RFTS compliant with L.302” has bought post-fault diagnosis, not surveillance beforehand: proactive surveillance has to be written in as a separate requirement. And that interface, in Italy, is the point where the system has to talk to the national network register — which we have already covered for the SINFI 4.0 specifications — or to the in-house register, when the network is private.

The alarm thresholds: another thing the standard does not fix.

The same Appendix I lists a table of values — not from the Recommendation itself, but “typical, determined from experience” of whoever wrote it: end-to-end loss change 3.0 dB for a major alarm; event loss change 0.5 dB; event reflectance 5 dB; new event 1.0 dB; attenuation coefficient 0.5 dB/km; non-reflective-to-reflective change over 1.0 dB; on power alarms, a minor default of 1.0 dB and a major default of 3.0 dB. These are illustrative vendor values, reported in an informative appendix: L.40/L.302 does not mandate them. A specification that settles for “alarm thresholds per standard” has written no threshold at all: those numbers, or others justified by the design, need to be declared in writing and made configurable.

What to put in the specification.

The architecture, named: number and type of switching unit (stated size), remote test unit, controller — not “compliant monitoring system”.
The number of fibres monitored per cable, and whether they are dark only or active too — the line item that decides both cost and real coverage.
The scan cycle time, stated as a function of fibres per controller — not left at the factory default.
The required functions, named: fibre-condition confirmation, equipment-fault/network-fault distinction, localisation, fibre identification — and if proactive surveillance is wanted, write it in separately, since the standard leaves it optional.
Alarm thresholds in dB, declared and specific, configurable per link.
The interface with the register — SINFI or an in-house register — declared as a requirement, not a footnote.

How it is checked on acceptance.

A system power-on test is not enough. Check that the delivered architecture matches the design — same switch size, same number of fibres covered per cable — with a simulated fault test that genuinely runs through to the alarm with the expected location, not just to detection. Check that the declared thresholds are the ones actually configured in the system, not the factory ones. And check that the export to the outside plant database works against a real case, not a screenshot of the configuration screen.

The point.

A continuous optical monitoring system catches the fault before the customer calls only if it covers the right fibres, with a scan cycle compatible with the fibre count, and if the thresholds are the ones the project needs, not the factory ones. The Recommendation describing the architecture is twenty years old and mandates none of these three numbers: it leaves them to whoever writes the specification. That is the work we do when we design a network meant to be monitored, from the choice of architecture to the as-built documentation that records where the test fibres are and where the termination filters sit.

Do you need to write a specification for a continuous monitoring system, or check whether the one you already have covers the fibres that matter? Talk to an engineer: the number of monitored fibres takes one line to write down, and real coverage is discovered at the first fault.