Patent Description:
The Fibre-to-the-x (FTTx) family of network architecture protocols are now commonly deployed in order to replace all or a part of the copper twisted pair telecommunication network with optical fibre up the last mile. The technologies include Fibre to the Node (FTTN), Fibre to the Cabinet (FTTC) and Fibre to the Home (FTTH). As the fibre termination moves closes to the customer premises, the remaining copper twisted pair can carry greater bandwidth to the home premises but the costs to the broadband network provider to deploy the fibre replacement increase significantly.

In an attempt to extend the optical fibre portion of the network closer to the customer premises without significantly increasing cost, a Fibre-to-the Distribution Point (FTTDP) protocol is being standardised by the International Telecommunication Union (ITU) under the name G. Fast which should eventually deliver 1Gb/s over short lengths of copper.

Distribution points are significantly smaller than street-side cabinets and therefore may be installed on telephone poles, or in footway boxes or underground chambers. However, the flexibility of where they can be physically placed also causes complications in terms of delivering power to the distribution points since optical fibre cannot supply power. To avoid costly energy contracts to supply power to the distribution points, in G. Fast it is proposed that the distribution points are reverse-powered by the customer premises units connected to them, using the existing wired telephony cabling.

With this necessity for distribution points based on G. Fast to be reverse-powered from the customer's premises, it can no longer be assumed that this particular Network Element (NE) will always be powered up. Whilst a single active customer premises equipment is generally sufficient to maintain power to the core general functions of the distribution point, when all the customer premises equipment connected to a given distribution point turn off, then the distribution point itself will also power down and therefore be unresponsive to any requests for information from any network devices within the overall network until power is restored.

Battery backup has been proposed to address this problem. However batteries only have a finite charge and it is not possible to determine when power will be restored. Adding larger batteries makes the distribution point unit larger in order to store the batteries and furthermore, more power would need to be drawn from the reverse-power system in order to keep the batteries charged.

Therefore the presence of batteries to maintain power to the distribution point creates many new problems. At most they can provide a short time in which to allow a graceful shutdown at the cost of requiring replacement batteries every few years Aspects of the present invention address the above problems.

<NPL> describes use cases of interest for Network Function Virtualisation (NFV).

<CIT> discloses a Mid-Level Manager network information management system that monitors and manipulates the flow of private information on public networks.

An embodiment of the invention provides an optical fibre network as claimed in Claim <NUM>.

In another aspect, the invention provides a management apparatus aggregator as claimed in Claim <NUM>.

Further advantageous aspects of the invention are set out in the appended dependent claims.

The present invention will now be described with reference to the accompanying figures in which:.

<FIG> shows a Fibre to the Distribution Point (FTTDP) optical network <NUM> in a first embodiment. In this embodiment the optical network is a Passive Optical Network (PON). In FTTDP, distribution point units <NUM> (DPU) are used to provide the conversion between optical signals generated in an optical head-end unit <NUM> and customer premises equipment <NUM> (CPE). Such DPUs <NUM> are small enough to be mounted on poles <NUM> and are located much closer to CPEs <NUM> than traditional cabinets used in FTTC (not shown). In other cases, DPUs <NUM> can be mounted in footway boxes and underground chambers connected to underground wires contained in ducts. In this embodiment, each DPU is typically located on a pole with an overhead drop wire <NUM> connecting to the CPEs <NUM> and an optical fibre <NUM> connecting the DPU <NUM> to the head-end unit <NUM>. In <FIG>, CPEs 7a and 7b are connected to DPU 3a and the CPEs 7c and 7d are connected to DPU 3b.

Unlike FTTC cabinets which have a dedicated mains power supply, the DPU <NUM> must be reverse powered via each electrical drop wire <NUM> from each CPE <NUM>. In this embodiment, each CPE <NUM> connection is sufficient to maintain the core functionality of the DPU <NUM>. Examples of the reverse powering scheme can be found in European patent application <CIT>.

The DPUs <NUM> are linked to the head-end unit <NUM> by a fibre optic line <NUM>. The head-end unit <NUM> contains an Optical Line Terminal <NUM> to convert data destined for the recipient DPU <NUM> into optical signals for transmission over the fibre optic line <NUM> and to convert received optical signals from a DPU3 back into an electrical interface. Once converted, the signals received at the head-end unit <NUM> are routed to their destination by a routing function <NUM>. The routing function <NUM> ensures that control data and/or internal network data is routed to other network functions such as a Network Management System <NUM> (NMS), an Operation Support Systems <NUM> (OSS), one or more persistent management agents <NUM> (PMA) or a PMA Aggregator <NUM>. The routing function <NUM> also ensures that external data traffic is routed to external networks such as the internet <NUM>.

Maintaining an event log and history of the status and load of each CPE <NUM> and DPU <NUM> is particularly important in this FTTDP network <NUM> setup due to the reverse powering constraint. Since the power to a line cannot be guaranteed at all times, information may be lost if the status and configuration metrics are stored at the DPU <NUM> and all of its connected CPEs <NUM> are turned off. Furthermore any functions in the network core such as the NMS <NUM> or OSS <NUM> which request data while a particular DPU <NUM> is unpowered will not be able to establish a connection and may waste resources trying to repeat the request until the DPU <NUM> does eventually power on. Finally, in traditional networks loss of power to a network element is treated as an alarm, and this is not appropriate here.

To overcome these problems, in this embodiment, a PMA <NUM> is introduced into the network core to act as a proxy/manager for the DPU <NUM>. In this embodiment, there is a one to one mapping between DPUs <NUM> and PMAs <NUM>. Each DPU <NUM> is configured to send metric data to its associated PMA <NUM> as soon as it is generated. The PMA then handles all requests relating to the status and configuration of the DPU <NUM> regardless of whether the DPU <NUM> is operational at the time of the request, although the PMA <NUM> is able to determine the power status of the DPU <NUM>. As will be described in more detail below, with the change in network architecture, the PMA <NUM> is also able to perform other actions including:.

In this embodiment, each PMA <NUM> is a proxy for a single DPU <NUM>. The PMAs <NUM> perform aggregation of metric data to generate new measures and values. To improve scalability within the optical network and the large numbers of PMAs <NUM>, a PMA aggregator <NUM> is configured to aggregate the large volume and data and serve it to requests from the NMS <NUM> or OSS <NUM>.

<FIG> shows the distribution point unit <NUM> (DPU) in more detail. For external communication, the DPU <NUM> comprises an optical network terminal <NUM> (ONT) for converting between optical signals conveyed over the optical fibre <NUM> linking the DPU <NUM> to the network core and xDSL signalling conveyed through an xDSL terminating unit <NUM> (XTU) to the drop wire <NUM> linking the DPU <NUM> to the customer premises.

The DPU <NUM> includes reverse powering circuitry <NUM> to extract power from each connected drop line <NUM> and a DPU controller <NUM> controls the provision of power within the DPU <NUM>.

To send information to the corresponding PMA <NUM>, an events and errors log <NUM> contains all statistical data relating to the operation of the DPU <NUM> and any data relating to the DPU is sent to the PMA <NUM> using a first Embedded Operations Channel (EOC).

Since the status of the CPE <NUM> is also relevant, the DPU <NUM> also forwards any messages and alerts relating to the CPE <NUM> to the PMA <NUM> using a second EOC. An EOC <NUM> xDSL side interface <NUM> receives metric data from the CPE <NUM> from the XTU <NUM> and an EOC <NUM> ONU side interface <NUM> sends the data to the PMA <NUM>. A reformatter <NUM> is present for any necessary conversion.

While the PMA can set items such as the Profile, limit PSD mask and band plan, examples of the type of information sent to the PMA include:.

To support other functions, the DPU controller is also configured to receive firmware updates into a firmware store <NUM> from the PMA which can then be used to update the firmware <NUM> as well as configuration updates into a configuration store <NUM>. A further function is power management including the ability to send a "dying gasp" message in the event of power loss to send a final burst of data. This also notifies the PMA <NUM> that the DPU <NUM> has lost power.

The DPU <NUM> in the first embodiment is simplified by removing status reporting functions to the PMA <NUM>.

The requirements for the PMA are given below:.

<FIG> schematically shows the structure of the PMA <NUM> located in the network core. In this embodiment, there is a PMA for each DPU and it handles requests for DPU status information on behalf of the DPU at all times regardless of its power status.

The PMA <NUM> contains a DPU interface <NUM> to communicate with the corresponding DPU <NUM> and a Q interface <NUM> for communication with the NMS <NUM> and OSS <NUM> systems.

The PMA receives performance (including errors) data from the CPE <NUM> and the DPU <NUM> via the different EOC channels into a statistics aggregation unit <NUM>.

As mentioned above, while the PMA can set the Profile, limit PSD mask and band plan in addition to other configuration items, examples of the type of information sent to the PMA include:.

As explained earlier, in this embodiment each DPU is associated with a single PMA to act as a proxy device storing state information on various metric statistics send over the EOC interfaces. To analyse the data and create new metrics, in this embodiment, the stats aggregation function <NUM> will receive statistics and use them to calculate new information. Examples include:.

For example in the case of the ES-LFE counter <NUM> mins - the stats aggregation function <NUM> would use the Code Violation information (amongst others), and for each second where there was a Code Violation event, the stats aggregation function <NUM> would increment the current <NUM> minute counter by <NUM>. At the end of the <NUM> minute period, the value of this counter would be stored as the previous <NUM> minute counter and the current <NUM> minute counter would be reset to <NUM> and the process continued. If requested for the information from the NMS <NUM> or other management entity, the stats aggregation function <NUM> would at the minimum, be able to return the values of either the current or up to the previous <NUM><NUM>-minute bin counters.

As described earlier, by forwarding all of the status information to the PMA <NUM>, the problems with intermittent power loss are reduced. The DPU <NUM> does not need to store or communicate status data to any other devices and since the received information is held at the PMA <NUM> which has a much more reliable power supply, status information is available to any requesting devices regarding the status of the DPU <NUM> at any time since the status information storage is completely delegated to the PMA <NUM>. When the DPU <NUM> is unpowered, then the PMA <NUM> responds to requests using the last known good data.

In addition to line metrics, the PMA <NUM> has a status request module <NUM> for communication with the DP Controller and Power Management module to determine other status information about the DPU <NUM>, in particular it receives and processes the dying gasp from the DPU <NUM>. A command store <NUM> sends instructions to the DPU Controller. In response to requests or instructions from other manager devices in the network core, configuration data and changes for the operation of the DPU are stored and sent to the DPU <NUM>. Therefore in the event of power loss, this information can be restored to the DPU <NUM> once power is restored.

The PMA <NUM> acts as a proxy on behalf of the DPU <NUM> and is always accessible regardless of the actual power status of the DPU <NUM>. The OSS <NUM> and NMS <NUM> often need to determine the real power state of the DPU as a whole, and each given line connected to an active CPE <NUM>, for example for diagnostics purposes. It can choose to take into account the power state for various purposes, e.g. a new firmware download, but equally it can choose to ignore the power state. It can therefore also queue pending requests for information or commands, such as firmware upgrades in firmware store <NUM> and configuration store <NUM> and execute them when power is restored to the DPU3. This requires the concept of a pending action, whose success or otherwise, is sent to the PMA when the action or download on the DPU <NUM> is actually attempted. When the OSS/NMS attempts to carry out an action that needs to the DPU to be powered up to complete, the PMA <NUM> acknowledges receipt and understanding of the action, but will not report or mark it as complete until it has actually happened, i.e. when the DPU is next powered up.

The PMA Aggregator <NUM> is present to allow for scalability when there are many PMAs. The PMA Aggregator supports all OSS/NMS management actions on a given DPU <NUM> and therefore it responds to requests from the NMS <NUM> with either aggregated metrics or the direct status information regarding a given DPU <NUM> or DPU line.

In summary, by moving the status reporting function out of the DPU and into a PMA located in the central office, the overall system provides the following properties:.

In the embodiment, each DPU has an associated PMA. In an alternative, there is a single PMA for all the DPUs and in a further alternative a PMA can be associated with a subset of the total number of DPUs.

Claim 1:
An optical fibre network comprising an optical fibre network section, a plurality of distribution nodes (<NUM>) linking the optical fibre network section to a plurality of customer premises units (<NUM>) via a plurality of electrical wired segments (<NUM>), each distribution node (<NUM>) being electrically powered by at least one of the customer premises units, wherein the optical fibre network further includes a routing function (<NUM>) and a network management system (<NUM>) in a network core of the optical fibre network, the optical fibre network characterised by further comprising : J a plurality of proxy management units (<NUM>), each in communication with the network management system (<NUM>) in the network core of the optical fibre network and each in communication with a distribution node (<NUM>) of the plurality of distribution nodes (<NUM>) via the routing function (<NUM>) and each operable to receive management data from said distribution node (<NUM>), store the received management data, and to process requests regarding the status of said distribution node (<NUM>) by responding with the stored management data, wherein each proxy management unit (<NUM>) is able to process said requests regardless of the power status of said distribution node (<NUM>), wherein there is a one-to-one mapping between each of the plurality of proxy management units (<NUM>) and each of the plurality of distribution nodes (<NUM>), wherein the optical fibre network further comprises a proxy management unit aggregator (<NUM>), the proxy management unit aggregator (<NUM>) connected to the routing function (<NUM>) and operable to receive management data relating to each distribution node (<NUM>), aggregate the management data relating to each distribution node (<NUM>), and to process requests from the network management system (<NUM>) in the network core of the optical fibre network by responding with the aggregated management data relating to each distribution node (<NUM>).