Ensuring reliable delivery of triple-play bundled services over FTTx

Service providers deploying FTTx networks need to follow a complete application- aware test and service assurance strategy in order to properly install, provision, and maintain the quality of new, IP-based services.

By John Williams
JDSU

As competition from cable multiple-system operators (MSOs) increases, telco service providers must act fast before these competitors' service offerings significantly impact their profits. Fiber-to-the-X (FTTx) networks are playing an increasingly important role in helping telco service providers stay in the game, retain existing customers, and ultimately win new ones. Such networks are becoming an essential part of the telcos' competitive strategies to offer the triple play of Internet Protocol (IP)-based voice, data, and video. Fortunately, the technologies used to build FTTx networks--including passive optical networks (PONs), DSL, and new video compression techniques--are approaching practical price points.

It is not enough to simply deploy FTTx networks, however. Successful delivery of triple-play services will require service providers to do much more than deploy physical infrastructure and remotely determine if packets are being transported across the network; they must also ensure that the services themselves perform flawlessly. If service providers successfully deploy FTTx physical plants but deliver sub-par services, they face the possibility of forever losing once loyal customers to competitors offering the same type of service packages with better quality.

To deploy FTTx networks that deliver high-quality, IP-based services, telcos must add an application-aware test and service assurance strategy to their arsenal of test processes and procedures. New test and measurement equipment and service assurance systems with highly integrated capabilities and multi-port access are necessities. These solutions must enable field technicians and operational support personnel to test the network at the physical layer as well as test the quality of service (QoS) of each IP-based application. Both the network's physical transport mechanisms and packet flow mechanisms must meet stringent parameters in order to deliver proper application-specific QoS levels.

Triple play requires triple testing

As with the physical plant, turning up triple-play services is performed in three different stages: Network element installation and pre-qualification, premises provisioning, and service assurance and maintenance. Each lifecycle stage brings different challenges to each of the three triple-play services.

IP video

Before IP video service can be turned up, service providers must determine the suitability of the customer's access network for IP video. Video class-of-service (CoS) mechanisms, such as VLAN tag segregation, load planning, and resulting bandwidth, must be determined. DSLAM equipment must be upgraded to support Internet Group Management Protocol (IGMP) snooping and IP multicast functionality. Last mile access topology must be established to deliver the bandwidth necessary to support IP video. Typically, the delivery of three simultaneous broadcast video channels is required.

Once these items have been addressed, the requisite network elements and connectivity can be provisioned. Network elements that need to be installed and tested include DSLAM ports, residential gateways, in-home wiring, and set-top boxes. Re-qualification of access links also may be completed.

When turning up and provisioning IP video service, provisioning errors and video quality issues are identified. Case-by-base troubleshooting must be performed before service installation can be completed. Ideally, test records in this phase of the process should be captured to provide a baseline reference for future service assurance activities. Such recorded data will improve mean-time-to-repair (MTTR) and result in a much better customer experience, ultimately reducing customer churn.

To improve the installation process, field technicians need to be able to verify three parameters before IP video service can be turned up: Adequate xDSL performance, video service provisioning, and video QoS. Equipment must be able to emulate the customer's set-top box, obtain video program flows, and validate the video QoS metrics established by the service provider for each parameter.

Video QoS testing results displayed on the field technician's test device should show all the critical parameters that affect video flows. If the program clock reference (PCR) jitter is high, for example, the decoder cannot properly decode the video payload. Trouble with IGMP latency impacts the time it takes to change broadcast video channels and, therefore, is an important "customer experience" component. The number of lost packets in the video transport stream, as measured by the continuity error indicator, is the most critical of the three. Pass/fail thresholds should be set in test devices for each of these parameters, promoting consistency in operational practices and helping improve service assurance processes for IP video services.

To successfully troubleshoot IP video problems, field technicians will be looking for IP fault conditions such as video pixelizations or picture freezes, which result from lost packets, excessive packet jitter, or both. If no errors are detected at the physical layer of the access link under test, then it is likely that packet loss is taking place upstream of the DSLAM. PCR jitter typically will be specific to a channel, indicating a problem at the headend, with local ad insertions, or with source material transcoding operations.

The impact of packet loss varies. For instance, loss of a single packet carrying a B frame in an MPEG-2 video signal affects only one or two frames of the video flow. Loss of a single packet carrying an I-frame affects all frames until the next I-frame. Typically 14 to 15 frames are impacted depending upon the Group Of Picture (GOP)-size setting.

Ongoing monitoring of packet flow is required to keep IP video applications running at the QoS levels that customers have come to expect from competitive video service providers. Customers' quality of experience must be better than or, at the very least, equal to their previous experience.

IP voice

To turn up and provision an enterprise IP voice application, the enterprise network's suitability for VoIP's delay sensitive traffic must be determined. CoS features must exist in routers, and networks must be revised or reengineered to accommodate additional voice traffic. Load planning may impact network equipment, especially WAN interface bandwidth requirements. New service level agreements (SLAs) may be required.

In the installation phase, integrated access devices (IADs), voice gateways, routers, and phones are installed and tested. Physical layer testing of the WAN links is performed. Necessary connectivity and network elements can then be provisioned, and new cabling may be installed to the new end points (IP phones or terminal adapters).

As service is turned up, technicians focus on VoIP QoS testing and actual placement of IP phones. Provisioning errors and voice quality issues are identified and resolved before service provisioning can be completed. As with the IP video scenario, test records gathered during this phase of the process should be captured and recorded for future use. Should service problems occur, these records will shorten the trouble resolution process.

When turning up IP voice service, field technicians need to verify service provisioning and connectivity to signaling gateways. They also must verify call quality by placing both on-network and off-network (to PSTN) test calls. Critical test call parameters include packet delay, packet loss, and jitter. However, the mean opinion score (MOS) will be the most critical SLA metric used to measure overall VoIP quality.

In the service assurance phase, a variety of issues can cause poor VoIP service quality, including CPE-related issues caused by handsets, processor/DSP performance, microphone/earpiece acoustics, and network echo canceller performance. Network hand-offs between the packet network and the TDM network, typically managed by a voice gateway switch, are critical test points in all networks.

IP Internet data

To provide FTTx subscribers with IP Internet data service, ISP accounts must be established for each customer. Also, traffic planning must be modified to accommodate additional data flow. Broadband remote access servers will be impacted, and control/routing and bandwidth planning must be completed. In addition to establishing connectivity to ISPs and provisioning necessary network elements for increased data flow and CoS treatment, DSLAM ports may be reconfigured for dual-latency path support in this mixed application environment.

To complete the installation process, field technicians must verify DSL physical layer performance, ISP connectivity, and data service throughput. This is accomplished using a test tool with Web browser and FTP throughput test capabilities. Using selectable test file sizes and both upload and download testing, FTP throughput tests establish performance of the link that more closely models actual use cases than a simple download test. It is also wise to perform an HTTP test using a Web browser to ensure that the end users' ISP access/connectivity is working properly.

As IP Internet data service is turned up, provisioning accuracy must be validated. Again, records of any troubleshooting or issues should be captured for future reference.

In summary, testing must be performed at multiple layers, including the physical layer, data link layer, network layer, and application layer. Simple physical layer testing in the access network does not reveal all the potential QoS issues that can impact packet-based, triple-play applications.

John Williams is director, emerging markets and alliances at JDSU (formerly Acterna). He may be reached via the company's Web site at www.jdsu.com.

Figure 2: An IP video network: To troubleshoot IP video problems, field technicians will be looking for IP fault conditions such as video pixelizations or picture freezes, which result from lost packets and/or excessive packet jitter. If no errors are detected at the physical layer of the link under test, the packet loss is likely taking place upstream of the DSLAM.