Prompt

You have not logged in or are not authorized!

Remember my choice for next time?

PON management: The cloud is the limit

TextStart

By Zhang Shujian (China Telecom)

China Telecom commenced a passive optical network (PON) deployment in 2007 that reached over 15 million FTTx subscribers by the end of 2010; but despite this rapid expansion, it has been able to establish a complete FTTx management system, and it is now studying cloud technology as an option for future PON management.

The introduction of PON has changed telecommunications networking, both in terms of deployment procedures and O&M. Automatic service launch, fault location, and onsite maintenance have all become more challenging, as have network management and quality of service (QoS) assurance; all place greater demands on O&M, both in terms of labor and skill.

To overcome these difficulties, China Telecom's provincial branches have each established a variety of centralized PON management systems that leverage either new or legacy infrastructure.

In 2011, we invited a number of vendors, including Huawei, to draw specifications for a PON element management system (EMS) that would simplify the interconnections between our own IT support systems and a vendor's EMS. These specifications would include detailed guidelines for overall PON management and secondary procedures such as service launch, diagnostics, and alarm handling.

Enhancing PON EMS

Automatic service provisioning

Automatic service launches are critical to widespread FTTx deployment. Clear and specific requirements are needed for both network deployment and service launch. We already had certain requirements for northbound-related tasks, but we lacked service provisioning procedures that effectively leveraged the PON EMS for efficient network pre-configuration and parameter management.

We also needed to consider how these procedures would vary by configuration and device.

China Telecom responded by identifying the templates/parameters that warranted pre-configuration for OLTs and terminals; these specific requirements provide a baseline for project delivery and network cutover, enabling us to configure network devices in batches.

Enhanced alarm processing

PON infrastructure is inherently more dynamic than its predecessors; unfortunately, this has led to a burgeoning number of alarms. One of our provincial branches dealt with over 100,000 per day, which would be a disaster if there really were that many crises. As it is, it is merely a heavy burden, as a lot of effort is wasted on false alarms, while the real breakdowns are frequently ignored amidst all the noise.

Some of our branches have developed upper-layer systems for alarm sorting and filtering that aim to enhance accuracy and efficiency; this helps standardize alarm configuration and automate work order response, but development of these systems is difficult and the O&M burden is heavy.

More input should be given to enhance the alarm report & handling mechanisms; this would also enable automatic analysis and work order dispatch. In this context, we have standardized alarm names, descriptions, and the handling mechanism as well. Alarm compression rules are also now pre-defined so that invalid alarms are filtered out; with the reduced workload, maintenance becomes less haphazard and more orderly.

Standardized test functionality

Based on the function, application scenario, and target involved, we can carry out PON testing during and after service launch. Mid-service launch testing encompasses comparative configurations and configuration progress, with services launched upon completion. These tests are meant to prevent problems such as data configuration errors and fiber breaks.

Post-launch issues primarily include equipment/network errors, fiber failures, service malfunctions, and terminal faults. Post-launch testing generally focuses on user-complaint handling, configuration comparison, fault diagnosis & testing, and post-troubleshooting verification.

We defined specific testing rules for the PON EMS, including link information query, one-key automatic testing, and item-specific testing. Other rules have also been defined for testing that cover port activation/deactivation, wideband & narrowband 112 internal/external line testing, incoming/outgoing VoIP simulation, port performance monitoring, and optical-fiber link testing.

With their integrated access, PON devices yield complex and diversified configuration data that is nearly impossible to verify manually. In this context, PON EMS must be used for checking and comparison of configuration data, operating status, and network values for OLTs, ONUs, and the EMS itself, for which we have predicted values based on two categories of both maintenance and service configuration items.

Cloud-based PON EMS

Current PON management systems are generally local/remote backup systems, distributed architecture systems, or integrated into a single system. Therefore, PON expansion may overload the EMS. China Telecom usually divides systems geographically, with the expanded capacity generally meaning an increased number of servers and enhanced O&M complexity.

China Telecom's various provincial branches have adopted EMS equipment from different vendors, which vary by overall architecture, server design, database layout and operating system. This can lead to complex management, higher costs, and poor resource sharing.

We need a centralized PON EMS that facilitates central management. A cloud-based PON EMS would be one possible avenue. Small-scale cloud technologies are already commercially proven, while a large-scale solution would most likely include the following.

Private-cloud EMS

Vendors can upgrade their legacy PON EMS software and hardware to better facilitate centralized management. Separate modules can be utilized for critical functions and resource-intensive activities such as data collection & backup; in this context, the solution would consist of one or more sets of basic EMS servers, plus multiple independent modules for performance analysis, data backup, service provisioning, and other functions.

Shared-cloud EMS

Besides compatibility with various hardware resources, the shared-cloud EMS would require standardized IT infrastructure and virtualized technologies, while EMS resources would be managed and relocated in a unified manner. Specifically, the solution would require an EMS hardware resource pool that accommodates CPUs, memory, hard drives, and network ports. Vendors could use these pooled resources as required to establish a virtual environment, such as VMware's virtual machine, to meet our needs.

EMS application clouds

After operators build a cloud-based PON EMS, they will no longer require network management software; instead, vendors would need only provide plug-ins that follow the southbound interface specifications, which would enable loose coupling between the EMS and other equipment.

In addition, software would not be dependent on general hardware, or even a specific device. Through unified northbound interfaces for the EMS, operators could integrate their hardware resources, which would simplify IT O&M and enhance efficiency. For large-capacity PON EMS, this solution would help enhance computing capability, security and reliability.

EMS evolution to cloud architecture will be a long-term process involving a large number of obstacles, including EMS restructuring and industry chain immaturity. Operators should move more quickly from the private cloud to the application cloud. With a maturing industry chain, cloud-based EMS is surely the way forward.

TextEnd

Download (610KB)