Passive Optical Networks (PONs) are proving to be valuable assets when it comes to new service offerings and technologies. With increasing competition in the video marketplace and pressure from governments regarding national broadband plans, PONs give providers the ability to meet challenges head-on.
The ITU-T’s Gigabit PON (GPON) specification is the first of the family of PON technologies being tested by the University of New Hampshire InterOperability Laboratory (UNH-IOL).
Today’s GPON testing focuses primarily on the ONT Management Control Interface (OMCI) protocol, a key component to GPON’s interop lifecycle. OMCI allows carriers to provision broadband apps and services, but its real strength comes from its inherent flexibility.
OMCI Configuration For A Single Service Offering
OMCI was one of the first specs to document a standardized provisioning mechanism for the end-to-end Layer 2 data path, making it both powerful and complex. Most deployed services are configured specific to the provider, where each deployment represents a subset of what OMCI is capable of configuring; OMCI as a whole was defined as a superset of all possible configurations. Figure 1 shows a typical OMCI configuration for a single service, based on Broadband Forum TR-156 requirements.
A PON consists of a single Optical Line Termination (OLT) and multiple Optical Network Terminations (ONTs) communicating over an Optical Distribution Network (ODN). The PON operates as a point-to-multipoint link in the downstream and a point-to-point link in the upstream. This topology means such downstream applications as broadcast video can leverage the multicast nature of the PON but, on the flip side, it means increased complexities for upstream applications requiring dedicated bandwidth. The TR-156 spec along with an implementer’s guide published by the ITU-T has helped to clarify some of the required configuration approaches.
Within OMCI, the OLT is the configuration master and may approach the configuration of an ONT as it sees fit; this has led to a massive gap between ONT devices produced by different manufacturers. Given the many-to-few relationship of possible ONTs to OLTs in the market, companies can triage with conformance testing of basic functions on the ONT. Conformance testing helps ensure the ONT is, at the very least, correctly implementing the standard as worded. This is an effective method to prove the ONT accepts the OMCI messages from the OLT, and that the ONT operates on those messages, thus supporting basic configuration topologies.
The real meat of OMCI testing is through the interoperability of a given OLT and a given ONT, exercising such multiple deployment scenarios as different network architectures or services. The UNH-IOL already has found different OLT implementations that configure a Layer 2 data path that, while functionally identical at the edges, took two different configuration routes within the OMCI layer.
This isn’t a problem with the standards, but it does mean different ONTs must be able to accept both configurations to realize a fully interoperable deployment.
Lincoln Lavoie is senior engineer at the University of New Hampshire InterOperability Laboratory. Contact him at email@example.com.