GB2616887A

GB2616887A - Monitoring optical access networks

Info

Publication number: GB2616887A
Application number: GB2204143.8A
Authority: GB
Inventors: Cooper Ian
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 2022-03-24
Filing date: 2022-03-24
Publication date: 2023-09-27
Also published as: GB202204143D0

Abstract

A method and apparatus to monitor an optical access network. An optical head-end 1400 provides network access to customer premises equipment (CPE) 1200. The optical head-end contains a data processing system (DPS) 1100 which receives telemetry data from the CPE on an on-going basis and stores it in local storage 1120. The DPS determines from the telemetry data whether a trigger condition has been met, and if so, a report is transmitted to a support system 1300. The trigger condition may be determined by expert system analysis, pattern matching or a neural network. The telemetry data may indicate: Forward Error Correction (FEC) statistics, dropped packet statistics, queue lengths, optical power measurements, device temperature measurements etc. The advantage of the invention is that continuous telemetry analysis such as that required by Central Office Re-architected as a Datacentre (CORD) technology may be achieved without overwhelming the communication network with telemetry data. By decentralising the analysis of telemetry, management traffic overheads may be reduced and network resources expended on unnecessary reporting, such as power, bandwidth etc., may be decreased.

Description

MONITORING OPTICAL ACCESS NETWORKS

Field

The present disclosure relates to telemetry data for optical networks.

More specifically, aspects of the disclosure relate to a computer-implemented method of monitoring an optical access network, a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out such a method, a computer-readable data carrier having stored thereon such a computer program, a data carrier signal carrying such a computer program, a data processing system configured to perform such a method and an optical head-end comprising such a data processing system.

Background

Traditional fixed communication networks communicate signals over copper wires. Since electromagnetic interference and crosstalk from neighbouring lines is a significant problem in such networks, complex schemes for collecting, analysing and acting on detailed telemetry data using dynamic optimisation techniques have become commonplace.

Initial deployments of optical communication networks have not involved large-scale telemetry data gathering, instead relying only on alarms to indicate when catastrophic failures, such as the severing of an optical fibre, have occurred.

As broadband data has overtaken (and increasingly subsumed) voice telephony signals, telecommunication head-ends (also known as central offices or exchanges) have become increasingly similar to computer datacentres.

Datacentres rely on telemetry monitoring to identify and even predict faults and data congestion so that corrective action can be taken as soon as possible, ideally before users notice any service degradation.

In recent times traditional copper access networks have begun to be replaced by optical networks such as passive optical networks (PONs). Optical line terminals (OLTs) are provided in the optical head-end to connect it to individual users. Whitebox' OLTs have recently become available which are capable of running agents. This has enabled telemetry data reporting by OLTs. Central Office Re-architected as a Datacentre (CORD) is a technology intended to provide optical head-ends modelled on datacentres. The CORD approach to telemetry is to continuously (i.e. very regularly, e.g. every second) report telemetry data via Kafka bus (a publish/subscribe asynchronous messaging system) to a server cluster and to store that data on all servers of the cluster (for redundancy) for several days.

However, as optical networks grow so does the quantity of associated telemetry data, potentially overloading communication networks to the extent that quality of service is reduced.

What is needed is a way of achieving the benefits of detailed telemetry on optical networks, without overwhelming communication networks with telemetry data.

Summary

According to a first aspect, there is provided a computer-implemented method of monitoring an optical access network, the method comprising a data processing system local to an optical head-end: obtaining telemetry data from one or more customer premises equipments (CPEs) served by the optical head-end on an on-going basis; storing the obtained telemetry data in a local storage container; determining from the stored telemetry data whether a trigger condition is met; and causing a report to be transmitted to a support system in response to a determination that the trigger condition is met.

The computer-implemented method can further comprise maintaining the local storage container so that it only contains recently obtained telemetry data by either: once the local storage container is full, storing the obtained telemetry data by overwriting a least recent portion of the stored telemetry data; or deleting or separately archiving a least recent portion of the stored telemetry data when a predetermined criterion is met.

The report can comprise either: all of the stored telemetry data, or a most recent portion of the stored telemetry data, or a portion of the stored telemetry data pertinent to the trigger condition.

The computer-implemented method can further comprise compressing: all of the telemetry data, or a least recent portion of the telemetry data, or a portion of the telemetry data not pertinent to the trigger condition.

The compressing step can be performed before the storing step, such that the obtained telemetry data is stored in a compressed form.

Determining whether the trigger condition is met can be performed by: expert system analysis, pattern matching, or a neural network.

Determining whether the trigger condition is met can be performed in dependence on data indicating one or more of: Forward Error Correction (FEC) Corrected Blocks; FEC Uncorrectable Blocks; dropped packets; head-end queue length; optical input power; optical output power; transceiver temperature; and transceiver voltage.

The optical access network can be a PON, the optical head-end can be an OLT and the CPEs can be optical network units (ONUs).

The support system can be an Operations Support System (OSS) or a Business Support System (BSS).

According to a second aspect, there is provided a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of the first aspect.

According to a third aspect, there is provided a computer-readable data carrier having stored thereon the computer program of the second aspect.

According to a fourth aspect, there is provided a data carrier signal carrying the computer program of the second aspect.

According to a fifth aspect, there is provided a data processing system (DPS) local to an optical head-end, the DPS comprising: a receiver configured to obtain telemetry data from one or more customer premises equipments (CPEs) served by the optical head-end on an on-going basis; a local storage container configured to store the obtained telemetry data; a processor configured to determine from the stored telemetry data whether a trigger condition is met; and a transmitter configured to transmit a report to a support system in response to a determination by the processor that the trigger condition is met.

The local storage container can be: a time series database, optionally having a retention policy arranged to create a circular buffer, or a continuous log.

The DPS can be provided by one or more servers connected to the optical head-end via one or more leaf and/or spine switches of a Central Office (CO) software-defined network (SUN).

According to a sixth aspect, there is provided an optical head-end comprising the DPS of the fifth aspect.

Brief description of the figures

Aspects of the present disclosure will now be described by way of example with reference to the accompanying figures. In the figures: Figure 1A schematically illustrates an example system comprising a data processing system local to an optical head-end; Figure 1B schematically illustrates an alternative example system comprising a data processing system local to an optical head-end; and Figure 2 is a flowchart of a computer-implemented method of monitoring an optical access network.

Detailed description of the figures

The following description is presented to enable any person skilled in the art to make and use the system and/or perform the method of the invention, and is provided in the context of a particular application. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art.

The present inventor has recognised that telemetry parameters on optical access networks tend to be much more static than on copper networks, often remaining essentially constant over a time period of months or even years and only changing significantly in rare events such as cable cuts. Continuous telemetry reporting to multiple servers can therefore be considered to be 'overkill'. The proposed solution is for a computing device local to an optical head-end (e.g. an OLT) to store telemetry data in a local storage container and report it on to a support system (where it can be analysed and corrective action taken, by automatic and/or manual means) in response to a trigger condition being met. In this way, the benefits of continuous telemetry analysis can be achieved without overwhelming the communication network with telemetry data and expending resources such as power, bandwidth and memory on unnecessary reporting.

This can for example be achieved by running an agent (e.g. using Python scripts) on an OLT that stores telemetry data locally (e.g. in a circular buffer -a time-series database which is progressively overwritten). Patterns in that data predictive of faults such as laser failures, or suggestive that an upgrade to some aspect of the optical access network might improve performance can be identified locally, e.g. using neural networks or expert systems. If such a pattern is identified, then telemetry data can be reported for further analysis and appropriate action.

For example, if 12 parameters are measured by each of 32 optical network units (ONUs) connected to an OLT at 1 second intervals, with 2 bytes being used for each parameter plus 2 bytes for a timestamp, then storing the last 6 hours of telemetry data would require 33MB of storage -easily achievable within an OLT which typically has 1.6 to 3.6GB of storage. In contrast, real-time transmission of all that telemetry data to a remote support system would require over 12kbps, which would be a considerable burden on the control network. Pre-processing the data locally and only sending it back to the central monitoring position when necessary results in a reduced bandwidth requirement for the control network. Compression of the stored parameter file reduces this bandwidth requirement further.

Figure 1A schematically illustrates a system 1000 comprising a data processing system (DPS) 1100 local to an optical head-end. The DPS 1100 comprises an interface 1130 comprising a receiver (Rx) 1131 configured to obtain telemetry data from one or more customer premises equipments (CPEs) 1200 served by the optical head-end on an on-going basis. The DPS 1100 further comprises a local storage container 1120 configured to store the obtained telemetry data and a processor 1110 configured to determine from the stored telemetry data whether a trigger condition is met. The interface 1130 also comprises a transmitter (Tx) 1132 configured to, when the trigger condition is met, transmit a report to a support system 1300.

The local storage container 1120 can for example be a time series database, optionally having a retention policy arranged to create a circular buffer, or a continuous log.

The DPS 1100 could optionally be provided by one or more computers comprised in an optical head-end (OHE) 1400. The optical access network can for example be a PON, the DPS 1100 can for example be an OLT located within an optical head-end and the CPEs 1200 can for example be ONUs. The support system 1300 can for example be an Operations Support System (OSS) or a Business Support System (BSS).

Alternatively, as shown in Figure 1B, the DPS could be provided by one or more servers 1100a, 1100b connected to an OLT 1410 in the OHE 1400 via one or more leaf switches 1510 and/or spine switches 1520 of a Central Office (CO) software-defined network (SUN) 1500. (Some of the functionality of the DPS could also be provided by the OLT 1410 itself.) Telemetry data could for example be communicated from the OLT 1410 to the servers 1100a, 1100b out of band using http request methods (e.g. POST) via a spare switch port. The SUN 1500 connects ONUs 1200a, 1200b to both the OSS/BSS 1300 and a broadband network gateway (BNG) 1600. The leaf and spine switches are arranged so that any leaf can connect to any other leaf via the same number of hops (two in the example illustrated) with redundancy built in. The SDN 1500 is controlled by an orchestrator/controller 1530 connected to an open network operating system (ONOS) cluster 1540. The OLT 1410 is controlled and managed by virtual OLT hardware abstraction (VOLTHA) 1550 and is connected to ONUs 1200a, 1200b via a passive optical splitter. The OLT 1410 could be separate to the leaf switches 1510 as shown, or incorporated into one of them.

Figure 2 is a flowchart of a computer-implemented method 2000 of monitoring an optical access network such as a PON or a point-to-point optical network. The method 2000 can be performed by a computing device local to an optical head-end such as the DPS 1100 of Figure 1A or the servers 1100a, 1100b of Figure 1B.

At step s220 telemetry data is obtained from one or more CPEs served by the optical head-end. This occurs on an on-going basis. For example, the following data could be received in one batch and further batches of the same data items, but with updated values, could follow at e.g. one second intervals. If multiple ONUs are connected, then batches of telemetry data could be received from each of them cyclically in series.

ONU Receive Power (dBm): -23.466 ONU Transmit Power (dBm): 5.956 RX FEC Good Blocks: 24768 RX FEC Corrections: 0 RX FEC Corrected Blocks: 0 RX FEC Uncorrectable Blocks: 0 The telemetry data received at step s220 is stored in a local storage container at step s240. The received data could be timestamped, though this is not necessary if a time-series database is used for storage. The descriptive text for each data item set out above also need not be included; only the values are required.

At query q260 it is determined, from the stored telemetry data, whether a trigger condition is met. If not, then the method loops back directly to step s220. If so, then a report is caused to be transmitted to a support system at step s270 before the method loops back to step s220. Query q260 can for example run continuously, periodically or in response to new data being obtained and/or stored.

The local storage container can be maintained so that it only contains recently obtained telemetry data. This can be achieved for example by, once the local storage container is full, storing the telemetry data at step s240 by overwriting a least recent portion of the stored telemetry data (e.g. data greater than 6 hours old). Alternatively, once the telemetry data has been stored at step s240, a determination can be made at optional query q280 as to whether a predetermined criterion is met, such as whether the available capacity of the local storage container has dropped below a threshold value. If so, then at optional step s290 a least recent portion of the stored telemetry data is deleted or separately archived. (A local archive could for example store data from the 2 days prior to the period which the local storage container covers, which could be retrieved on request, e.g. by the support system in response to receiving the report and determining that the report contains insufficient data to diagnose the cause of a fault or recommend appropriate corrective action.) The report caused to be transmitted at step s270 can for example comprise either all of the stored telemetry data, or a most recent portion of the stored telemetry data, or a portion of the stored telemetry data pertinent to the trigger condition.

The method 2000 can further comprise compressing either all of the telemetry data, or a least recent portion of the telemetry data, or a portion of the telemetry data not pertinent to the trigger condition (e.g. static data) at optional step s230.

This can optionally be performed before storing the telemetry data at step s240, such that the obtained telemetry data is stored in a compressed form. For example, if the ONU receive power is typically around -23.466 dBm and this varies by only ±0.05dBm over 24 hours then instead of keeping 24x60x60=86,400 records, a single record would suffice.

Determining whether the trigger condition is met at query q260 can for example be performed by expert system analysis, pattern matching, or a neural network.

Query q260 of determining whether the trigger condition is met can for example be performed in dependence on data indicative of (imminent) quality of service degradation and/or data indicative of (imminent) equipment failure. For example if queue and/or buffer levels (e.g. in an OLT and/or on a per PON basis) are beyond a threshold and/or packets are being dropped this could point towards a network issue such as an ONU not scheduling its upstream traffic properly or too much downstream traffic arriving at the optical head-end. Forward Error Correction (FEC) Corrected Blocks or Uncorrectable Blocks having higher than normal values (typically zero) could indicate that there is something wrong with the physical layer transmission system, e.g. a laser output is low, a fibre has been damaged or bent excessively or an optical receiver is drifting into faulty condition. Unusual transceiver temperatures and/or voltages and/or optical input and/or output power levels could be indicative of (imminent) equipment failure.

For example, a PON laser bias current increasing by a significant amount may indicate that the laser has aged prematurely.

The trigger condition could be in respect of a single parameter or a combination of multiple parameters. What this combination of parameters is and what weighting would be given to each parameter in order to make a judgement could be different in different circumstances (e.g. for each PON/ONU combination). This could be determined by analysing all the parameters for a time to understand what 'normal' operation looks like and also identify which parameters are particularly sensitive under fault condition for that particular circumstance. This could for example be achieved using an expert system.

The determination of whether the trigger condition is met at query q260 could be made solely based on the telemetry data obtained from the CPEs at step s220. Alternatively, it could also take into account additional data obtained at optional step s250, such as telemetry data measured at the optical head-end, for example the following.

OLT Receive Power ONU (dBm): -27.212 OLT Transmit Power (dBm): 4.591 Round trip delay (ps): 15791 OLT Transmit Bias (pA): 99600 OLT ASIC Temperature (°C): 66 OLT Transceiver Temp (°C): 61 OLT Laser Temp (°C): 44 OLT Common Collector Voltage (mV): 3252 Such head-end telemetry data could also be reported to the support system, for example in the same report as the telemetry data received from the CPEs.

In some implementations, reporting to the support system occurs only in response to a determination that the trigger condition is met, with no reporting occurring for any other reason. In other implementations, some limited additional reporting could occur, for example for testing/audit purposes, to investigate effects of changes to the network or traffic conditions or how parts of the network differ from one another. Such additional reporting is however not continuous; it could be periodic (for example hourly, daily, weekly, monthly or annually) and/or prompted by requests from the support system. In all implementations, the lack of continuous telemetry reporting to the support system reduces the load on the network, saving power and bandwidth and avoiding quality of service issues which may arise due to an overwhelming quantity of telemetry reports.

Embodiments of the invention will be apparent to those skilled in the art from consideration of the specification. It is intended that the specification be considered as exemplary only.

Where this application lists one or more method steps, the presence of precursor, follow-on and intervening method steps is not excluded unless such exclusion is explicitly indicated. Similarly, where this application lists one or more components of a device or system, the presence of additional components, whether separate or intervening, is not excluded unless such exclusion is explicitly indicated.

In addition, where this application has listed the steps of a method or procedure in a specific order, it could be possible, or even expedient in certain circumstances, to change the order in which some steps are performed, and it is intended that the particular steps of the method or procedure claims set forth herein not be construed as being order-specific unless such order specificity is expressly stated in the claim. That is, the operations/steps may be performed in any order, unless otherwise specified, and embodiments may include additional or fewer operations/steps than those disclosed herein. It is further contemplated that executing or performing a particular operation/step before, contemporaneously with, or after another operation is in accordance with the described embodiments.

The scope of the present invention includes any novel features or combination of features disclosed herein. The applicant hereby gives notice that new claims may be formulated to such features or combination of features during prosecution of this application or of any further applications derived therefrom. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the claims.

Insofar as embodiments of the invention described are implementable, at least in part, using a software-controlled programmable processing device, such as a microprocessor, digital signal processor or other processing device, data processing apparatus or system, it will be appreciated that a computer program for configuring a programmable device, apparatus or system to implement the foregoing described methods is envisaged as an aspect of the present invention. Such a computer program may be embodied as source code or undergo compilation for implementation on a processing device, apparatus or system or may be embodied as object code, for example.

Such a computer program may be encoded as executable instructions embodied in a carrier medium, non-transitory computer-readable storage device and/or a memory device in machine or device readable form, for example in volatile memory, non-volatile memory, solid-state memory, magnetic memory such as disk or tape, optically or magneto-optically readable memory such as magnetic tape, compact disk (CD), digital versatile disk (DVD) or other media that are capable of storing code and/or data. Such a computer program may alternatively or additionally be supplied from a remote source embodied in a communications medium such as an electronic signal, radio frequency carrier wave or optical carrier wave. Such carrier media are also envisaged as aspects of the present invention.

Such instructions, when executed by a processor (or one or more computers, processors, and/or other devices) may cause the processor (the one or more computers, processors, and/or other devices) to perform at least a portion of the methods described herein.

Where a processor is referred to herein, this is to be understood to refer to a single processor or multiple processors operably connected to one another. Similarly, where a memory is referred to herein, this is to be understood to refer to a single memory or multiple memories operably connected to one another.

The methods and processes can also be partially or fully embodied in hardware modules or apparatuses or firmware, so that when the hardware modules or apparatuses are activated, they perform the associated methods and processes. The methods and processes can be embodied using a combination of code, data, and hardware modules or apparatuses.

Examples of processing systems, environments, and/or configurations that may be suitable for use with the embodiments described herein include, but are not limited to, embedded computer devices, personal computers, server computers (specific or cloud (virtual) servers), hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, smartphones, tablets, network personal computers (PCs), minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. Hardware modules or apparatuses described in this disclosure include, but are not limited to, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), dedicated or shared processors, and/or other hardware modules or apparatuses.

Receivers and transmitters as described herein may be standalone or may be comprised in transceivers. A communication link as described herein comprises at least one transmitter capable of transmitting data to at least one receiver over one or more wired or wireless communication channels. Wired communication channels can be arranged for electrical or optical transmission. Such a communication link can optionally further comprise one or more relaying transceivers.

Claims

Claims 1. A computer-implemented method of monitoring an optical access network, the method comprising a data processing system local to an optical head-end: obtaining telemetry data from one or more customer premises equipments (CPEs) served by the optical head-end on an on-going basis; storing the obtained telemetry data in a local storage container; determining from the stored telemetry data whether a trigger condition is met; and causing a report to be transmitted to a support system in response to a determination that the trigger condition is met.
2. The computer-implemented method of claim 1, further comprising maintaining the local storage container so that it only contains recently obtained telemetry data by either: once the local storage container is full, storing the obtained telemetry data by overwriting a least recent portion of the stored telemetry data; or deleting or separately archiving a least recent portion of the stored telemetry data when a predetermined criterion is met.
3. The computer-implemented method of either of claims 1 or 2, wherein the report comprises either: all of the stored telemetry data, or a most recent portion of the stored telemetry data, or a portion of the stored telemetry data pertinent to the trigger condition.
4. The computer-implemented method of any of claims 1 to 3, further comprising compressing: all of the telemetry data, or a least recent portion of the telemetry data, or a portion of the telemetry data not pertinent to the trigger condition.
5. The computer-implemented method of claim 4, wherein the compressing step is performed before the storing step, such that the obtained telemetry data is stored in a compressed form.
6. The computer-implemented method of any preceding claim, wherein determining whether the trigger condition is met is performed by: expert system analysis, pattern matching, or a neural network.
7. The computer-implemented method of any preceding claim, wherein determining whether the trigger condition is met is performed in dependence on data indicating one or more of: Forward Error Correction (FEC) Corrected Blocks; FEC Uncorrectable Blocks; dropped packets; head-end queue length; optical input power; optical output power; transceiver temperature; and transceiver voltage.
8. The computer-implemented method of any preceding claim, wherein the optical access network is a passive optical network (PON), the optical head-end is an optical line terminal (OLT) and the CPEs are optical network units (ONUs).
9. The computer-implemented method of any preceding claim, wherein the support system is an Operations Support System (OSS) or a Business Support System (BSS).
10. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of any preceding claim.
11. A computer-readable data carrier having stored thereon the computer program of claim 10.
12. A data carrier signal carrying the computer program of claim 10.
13. A data processing system (DPS) local to an optical head-end, the DPS comprising: a receiver configured to obtain telemetry data from one or more customer premises equipments (CPEs) served by the optical head-end on an on-going basis; a local storage container configured to store the obtained telemetry data; a processor configured to determine from the stored telemetry data whether a trigger condition is met; and a transmitter configured to transmit a report to a support system in response to a determination by the processor that the trigger condition is met.
14. The DPS of claim 13, wherein the local storage container is: a time series database, optionally having a retention policy arranged to create a circular buffer, or a continuous log.
15. The DPS of either of claims 13 or 14, provided by one or more servers connected to the optical head-end via one or more leaf and/or spine switches of a Central Office (CO) software-defined network (SDN).
16. An optical head-end comprising the DPS of either of claims 13 or 14.