A Proposal for DOCSIS 4.0:
Passive optical networks (PONs) are rapidly evolving and will eventually replace traditional wireline access technologies. Optical line additions already outpace digital subscriber line (DSL) line additions, and by 2010 there will be an estimated 35-50 million PON subscribers in the world.
This article is a follow up to Alon Bernstein’s 2007 SCTE/ET paper titled "Future Directions in the Battle Between Cable and PON." The 2007 paper presented a general overview of the competitive landscape and outlined how to overlay DOCSIS management and a DOCSIS back-office system on top of a PON. This article dives deeper into the technologies that enable this overlay, or in other words, how to build a system that appears as a cable modem termination system (CMTS) to the back office and at the same time appears as an optical line termination (OLT) to the optical network unit (ONU).
The article will focus on how to map the various DOCSIS-enabled services, such as, but not limited to:
• Registration
• Dynamic service provisioning
• Security
• Video
The mapping of these services could be considered for a DOCSIS standardization, which could be named "DOCSIS 4.0."
The presentation will also explore how PON is deployed in telco networks today vs. how it may be deployed in cable networks in the future.
While Ethernet PON (EPON) and Gigabit PON (GPON) are the dominant fiber to the home (FTTH) technologies, this presentation will give a quick overview of other FTTH technologies and how DOCSIS PON (DPON) can map on top of them.
It’s important to note that several design guidelines have changed since the previous paper was published. These changes are highlighted and detailed in the relevant sections. The term "bandwidth" as used in this article is in reference to data rates, throughput or capacity, unless otherwise noted. DPON protocols The following sections describe how the PON and DOCSIS protocols are combined into DPON – a cohesive protocol that combines the best of both systems. These protocols may be the basis for an extension to the existing DOCSIS Radio Frequency Interface (RFI). DPON registration The basic concept behind DPON registration is to let the EPON/GPON standard handle the layer 1 (physical layer) connection establishment and to allow the DOCSIS protocol to handle the second and third layers (data link and network layers). This partitioning allows for a clean demarcation of where EPON/GPON stops and where DOCSIS begins.
Once the physical layer connection is established, the system is ready for the DOCSIS registration. The "secret sauce" that turns DOCSIS into DPON is the software that translates DOCSIS definitions into EPON/GPON definitions. In the 2007 paper, it was recommended that this software be placed on the ONU; however, it now makes sense to place it on the OLT since this means that no changes – not in the hardware or the software – are needed on the ONU side. The OLT (which emulates a CMTS) instantiates a "virtual cable modem," which does the actual protocol exchange with the back office applications (time of day, dynamic host configuration protocol, trivial file transfer protocol – ToD/DHCP/TFTP). Once the virtual cable modem is online, it can translate the entire DOCSIS configuration it received to the EPON/GPON equivalent and use the EPON/GPON management channel to relay the information to the ONU. EPON registration The EPON standard (802.3ah) can be viewed as standard Ethernet with an extension that enables it to perform point-to-multipoint operations. As such, it does not even define higher layers of management or get into the network layer. Using DOCSIS management and network support as a followup to the PON physical layer establishment is the most natural way for a cable operator to register PON subscribers.
As outlined earlier, an EPON style registration establishes the physical layer connectivity. Once established, the OLT creates a "virtual cable modem" that goes through the DHCP/TOD/TFTP on behalf of the ONU, as depicted in Figure 1. A couple of observations about the EPON registration:
• The DOCSIS processes of initial and periodic ranging are replaced by their EPON equivalents.
• There is no need to follow up the TFTP download with REG-REQ/REQ-RSP/REG-ACK DOCSIS messages since all the information that is required for registration is already contained in the TFTP file. The actual setup of the ONU (such as classification rules for the upstream) is done through the PON native operations, administration and maintenance (OAM) channel. Quality of service (QoS) parameters for the downstream and upstream are local to the ONT and do not have to be sent over the OAM.
• The ONU Internet protocol (IP) address is used for management only and is negotiated in the DHCP process. It can be used in one of two ways: (1) Either the OLT is always the host of the ONU IP address and all communication to the ONU is done through the OAM channel; or (2) the DHCP IP address is sent to the ONU so that it can communicate directly to management applications. The first option is natural to DPON since it means that all management communication to the ONU is intercepted by the OLT, thus the OLT can do the work of translating them to DOCSIS-like management information bases (MIBs).
• The customer premises equipment (CPE) in the home (such as personal computers) would go though a regular DHCP for address assignment and is not impacted by the registration process. GPON registration GPON is an International Telecommunication Union standard and not an Ethernet standard. GPON is not sending Ethernet packets directly on the wire, but instead it involves encapsulating them into a special header. Contrary to the EPON specifications that do not say much regarding the management aspects of a PON system, GPON goes to the other extreme and defines so much of the management that Internet service providers (ISPs) need to choose which features to trim off. And like the EPON case, it makes sense to replace the ITU telco-centric management with a cable (DPON) system.
Figure 2 depicts the GPON registration. It is very similar to the EPON process with the exception that the messages used to establish the physical layer connectivity are different. Other than that, all observations made on EPON are relevant to the GPON case as well. DPON dynamic services It appears that EPON/GPON deployments do not use dynamic services as extensively as DOCSIS. The assumption is that since there is enough bandwidth in the EPON/GPON world, then with proper admission control and traffic prioritization (which can be statically defined during ONU registration), there is no need to establish a new flow whenever a new service type (voice, data, gaming, etc.) is requested by a user. This is the typical mindset for DSL deployments as well.
However, as the number of services and QoS levels offered to a single subscriber increase, it will not make engineering sense to statically provision QoS for them. Since each service uses resources on the OLT, having them all statically provisioned on it means that the OLT has to be engineered to support all of them, which will of course result in more expense. For example, if a subscriber is authorized to have a gaming service, video-conferencing service and a phone service, it would be wasteful (and expensive) to statically define three queues and three classification rules on the OLT since it is unlikely that all services would be used at once by all the subscribers authorized to use them.
While there is no need to send DOCSIS DSx messages to the ONU, the basic concept of a "dynamic service" can be adopted by EPON/GPON and queuing/classification rules. These rules can be dynamically created as a result of PacketCable/Packet Cable Multimedia (PCMM) gates and relayed to the ONU through the OAM channel. DPON security Security is an inherent issue in any network in which a shared medium is potentially visible at the customer premises. Like other shared medium networks, PON systems use an encryption process to protect against unwanted listening.
The GPON protocol exploits the directional nature of fiber transmission to simplify its security protocol. Unlike terminals for wireless or coaxial cable media, ONTs are not able to see the upstream data transmitted on the PON by other ONTs. Consequently, encryption only needs to be applied to the downstream data. This also allows the encryption keys to be transmitted upstream in the clear.
The EPON standard did not address the security of the downstream transmissions. However, the encryption method defined by Nippon Telegraph and Telephone is the de facto standard. This encryption method can be implemented for either downstream only traffic (like GPON) or for both the upstream and downstream directions. The primary purpose of upstream encryption is to provide message authentication. If the OLT receives a transmission with the incorrect encryption key for that upstream bandwidth grant, it will simply discard the data.
Both EPON and GPON use the advanced encryption standard (AES), which is a block cipher operating on 16-byte data blocks. Specifically, the counter mode is used in which a stream of 16-byte pseudorandom cipher blocks are generated and exclusively operated with the input data to produce the cipher text. The inverse process is used at the receiver to recreate the clear text data. Both EPON and GPON use 128-bit keys. Note that this is different than the DOCSIS 3.0 AES, which uses cipher block chaining (CBC) mode. CBC acts as the residual encryption of a block and as the "seed" for the encryption of the next block.
The combination of encryption and authentication minimize the risk of theft of service. Denial of service attacks on the PON itself are prevented by the OLT dynamic bandwidth allocation (DBA) algorithm, which assigns upstream transmission bandwidth to each ONT.
From a DOCSIS point of view, although EPON/GPON appears to handle the "privacy" aspects of a network sufficiently (meaning that one user cannot see another user’s data) DOCSIS appears to have more extensive security mechanisms then either GPON or EPON. For example, with DOCSIS early authentication, the security is established even prior to registration. Bringing EPON/GPON to that level of security would require software changes (and possibly hardware changes for the GPON upstream) and as such would not work for the first phase of DPON, which attempts to minimize changes to the ONU.
In addition, the key exchange protocols used in DOCSIS are different than those used in EPON/GPON. In order to keep the ONU changes to a minimum, the OLT software will have to support EPON/GPON style key exchange. Mapping DOCSIS QoS to EPON/GPON A critical piece of DPON is the ability to translate the content of the configuration information that is derived from DOCSIS protocol exchange (contained in the TFTP configuration file or created dynamically by PCMM) to a set of parameters that can be programmed to an ONU over the OAM channel.
A general statement can be made that since downstream queuing is implemented on the OLT, an implementer may choose any QoS implementation that fits. The upstream scheduler in charge of DBA is also located on the OLT and can be programmed. Thus, there is a good degree of flexibility in creating scheduling modes that mimic those required by the DOCSIS specifications (for example, UGS, committed rates, etc). However, at least as a first phase, it is recommended to stick to the basics. One may argue that the more complex scheduling requirements on DOCSIS (for example, maintaining jitter guarantees) are not needed for the data rates EPON/GPON supports and should not be included in the DPON specifications. This would allow simpler, faster and more cost-effective implementations.
EPON does not necessarily define classification and queuing in great detail. But a version of the EPON specification called "China telecom EPON" (affectionately known as CPON) does define service level agreement (SLA) and queuing in a great detail and is supported by multiple vendors.
As far as QoS, EPON follows an Ethernet model where instead of individual service flows, there are priorities within a pipe. This is also a model common in the DSL world where the "pipe" is the rate that the DSL modem is capable of reaching. In the EPON case, the "pipe" is defined on the upstream by the logical link identifier (LLID). Still, since the queue depth for each priority is signaled in every report message, it is possible to enhance an EPON scheduler to perform per-queue rate limiting. The other alternative is to use the current DOCSIS flow definition with the understanding that all the individual service flows are shaped to a given pipe rate, and not to the whole downstream/upstream bandwidth.
While DOCSIS defines many parameters relating to classification and SLAs, GPON defines fewer parameters and leaves more open to the implementer. Consequently, there is a good degree of flexibility in defining a reasonable mapping.
A DOCSIS service flow maps naturally to a GPON port-ID. It appears that the per-flow rate limiters and per-flow traffic priority are the only parameters common to the GPON and DOCSIS specifications. The classification capabilities and SLA parameters are regarded as part of the DBA configuration, which is outside the GPON standard scope. Therefore, the exact mapping might be implementation dependent, but for software-based DBA, any mapping can be defined.
Table 1 summarizes the support for different parameters according to the various standards. China telecom EPON doesn’t currently require classification based on IPv6 DA/SA/next header/flow label as specified in DOCSIS. PCMM PCMM is a flexible framework for providing services to a cable network. (See Figure 3.) The core elements of a PCMM system are the application manager and the policy server.
The application manager communicates with a user application in some application-specific way. For example, the PC application may be a Web page that a user clicks on to get a specific service (such as a movie to watch). The application manager translates this application-specific information to a format that the policy server can understand.
The policy server makes sure that the user is allowed to watch the movie and interfaces with the CMTS to dynamically create the QoS profile that will allow the service to be delivered reliably.
In a DPON system, no changes need to be made to the ONU (since it’s the PC that communicates with the application manager), to the policy server or to the application server. This is true in the DPON model where back-office applications do not have to change because of the media conversion to PON.
Since the OLT runs a CMTS software module, it already contains all the standard PCMM interfaces to the policy server as well as the translation software that will convert the DOCSIS style QoS definitions that the policy server provides to PON style definitions. DPON video No EPON/GPON discussion is complete without identifying a video strategy. Typically, two types of solutions are available to PON systems: video overlay and native IPTV support.
Video overlay emulates an HFC system over fiber. It uses a third color (in addition to receive and transmit) to carry RF modulated over fiber and to run the existing cable video back office to control video subscribers. In such a configuration, the video color can be muxed with the EPON/GPON colors after the OLT.
Native IPTV support sends video over IP as a data service. This is obviously a less costly option from the optical perspective (no need for a third color), but wide-scale IPTV delivery is still fairly new and considered risky.
An interesting option for DPON is to use a video over DOCSIS (VDOC) system as outlined in the 2006 SCTE/ET paper "The Converged World of 2010 – A Case for Video Delivery Over DOCSIS." The proposed architecture in this article enables converging existing cable video back-office systems with IPTV delivery, an approach that fits naturally into a DPON framework. Voice services In the PacketCable 1.0 model, it is the cable modem that initiates a dynamic service request to create a dedicated service flow for a voice call when a user either initiates or receives a call. As pointed out earlier, this is not the model PON is using. In fact, PacketCable 2.0 moves away from this model and allows the CMTS to initiate the dynamic service addition. With CMTS software running on the OLT, all the interfaces to PacketCable 2.0 are available, and the only issue is mapping them to PON definitions. This mapping is no different than the one used in registration. MIB A critical piece of back-office integration is the emulation of the cable modem and CMTS MIBs on the OLT. Not all of the DOCSIS MIBs make sense in such an environment, and it’s most likely that the ones that are useful in cable monitoring of PON subscribers are those related to packet accounting. PON OAM PON systems have a dedicated channel for performing OAM operations on their links. There is no direct equivalent function in DOCSIS, although existing DOCSIS functions (for example, the keep-alive provided by periodic ranging used as a way to detect link faults) provide services that are equivalent to those provided by PON OAM.
Both the IEEE and ITU-T PON protocols include OAM capabilities. Both protocols provide OAM for their physical layers. While GPON defines several explicit OAM capabilities associated with the ONU and its subscriber interfaces, EPON allows for these types of OAM capabilities through organization-specific extensions.
The EPON OAM capabilities were defined as part of the same project that developed the Gbps EPON protocol (IEEE 802.3ah). OAM is an optional sub-layer that applies to point-to-point links and the emulated point-to-point links of a PON (i.e., between peer OAM entities). The goal of the OAM is to monitor the network health and provide fast identification and location of fault conditions and failing links. To achieve this, one must include remote failure indications, remote loopback, link monitoring, and miscellaneous functions such as discovery of OAM capabilities and extensions to support higher layer management applications. The specification does not include provisioning, station management (i.e., the ability to set/write remote MIB variables), bandwidth allocation functions, or functions such as protection switching that pertain to multiple links.
Ethernet "slow protocol" frames called OAM protocol data units (OAMPDUs) are used to carry the OAM control and status information. An OAMPDU frame includes a flag field to indicate information such as local and remote stability, link faults, critical events and dying gasp, and threshold limit values (TLVs). This flag field communicates additional error event, local, remote, organization-specific OAM information. The organization-specific OAMPDU and TLV allow an equipment vendor to provide additional OAM capabilities, including managing the ONU and its user-network interfaces.
GPON specifies an ONT management and control interface (OMCI) for OAM and ONT control functions such as configuration, fault, performance and security management. The OLT is the master, and the ONTs are the slaves. Configuration management involves controlling the ONT through configuration of the ONT equipment, user network interfaces (UNIs), GEM ports (for connections across the ONT), interworking termination points, OAM flows, physical ports, service profiles, traffic descriptors, and GEM adaptation layer profiles. ONT fault management is limited and primarily concerned with failures. The faults include those for the subscriber and PON interface units, the various UNIs, the connection and interworking termination points, and the ONT as a whole. Similarly, the ONT has limited performance monitoring capabilities. The OMCI allows managing the performance monitoring histories of such things as the Ethernet, voice and Internet control message protocol (ICMP) traffic; 802.11 counters; the GEM overhead; and asynchronous DSL (ADSL) and very high bit rate DSL (VDSL) interfaces at the ONT.
The GPON control and management information is communicated through a combination of mechanisms. GPON uses a 125 µs transmission convergence (GTC) frame structure for the downstream and upstream transmissions. The GTC frame overhead includes fields for prompt communication of information for bandwidth requests and grants, key switching, and physical layer OAM. The GTC frames carry physical layer OAM (PLOAM) messages that are used to manage the physical medium dependent and GTC layers. One of the functions of the PLOAM is to establish an ONT management and control channel (OMCC) that carries the OMCI messages for each ONT. The OMCI message set consists of Get, Get response, Set, alarm notifications, test, test response, and test request messages. The format of the OMCC packets is not specified in the GPON standards.
In addition to the PON OAM, the DSL Forum‘s TR-069 [CPE WAN Management Protocol (CWMP)] is typically used by carriers for managing the services over both the EPON and GPON systems. It provides a common framework for CPE auto-configuration, dynamic service provisioning, software and firmware image management, status and performance monitoring, and diagnostics. All these can be replaced by their DOCSIS equivalents.
Since a good number of these OAM functions are not in DOCSIS, one option is to enhance DOCSIS to support these OAM functions (which would make mapping to PON easy). The other is to leave these OAM functions alone and keep them out of the scope of DPON where appropriate. The DPON system solution While placing a DOCSIS/PON translation software on the OLT is quick way to get the DPON protocols up and running, it is only part of the solution needed for DPON. The following sections outline the major components that make up a DPON system and how an existing cable network can be upgraded for PON support. PON architecture DPON is more than simply emulating DOCSIS registration and services. PON is deployed primarily in the telco space now, and the telco architecture may or may not fit the cable view of the network.
Telcos model their PONs after their DSL deployments. The basic concept is that a PON ONU appears as a high-speed DSL subscriber to the rest of the network. Of course, this is the same concept that DPON embraces, but with ONUs appearing as high-speed cable modems. To understand PONs in the telco world, a short high-level introduction to DSL networking is required.
In the DSL world, the broadband remote access server (BRAS) terminates subscriber sessions. "Termination" means running the protocol state machine between the user and the network, for example, the point-to-point protocol over Ethernet (PPPoE). In the DOCSIS case, the "termination" would be the DOCSIS encapsulation and media access control (MAC) protocol.
The DSL access multiplexer (DSLAM) is the entity that connects to the phone lines and aggregates them all into a single pipe. In summary, the BRAS takes care of layers 2 and 3 of the communication stack (link and transport) while the DSLAM takes care of layer 1 (physical layer). Telcos view a PON OLT as a different type of DSLAM, meaning they view it as a different type of media that is connected to the BRAS the same way that a DSLAM is. It’s important to note that even though DSL is a point-to-point technology (twisted-pair to every home), and PON is point-to-multipoint media, the EPON/GPON MAC protocol is built to emulate a point-to-point environment on top of a PON. Thus, it is possible to treat an OLT as a virtual DSLAM with faster point-to-point connections.
Individual subscriber sessions can be carried over to the BRAS in many ways, and each telco tends to have a different solution. Some prefer Ethernet switching solutions with a separate virtual local area network (VLAN) for each subscriber, and some use multi-protocol label switching (MPLS) pseudo-wires. In other solutions, a couple of subscribers are aggregated onto a single VLAN or pseudo-wire.
The same concepts can be applied to OLTs as well. They may carry the data for each subscriber on a separate VLAN or pseudo-wire, or they may aggregate them. It appears that separate VLANs per subscriber is the common approach in today’s PONs. Since VLAN tags have a 4096 number space, it’s common to use Qin-Q VLAN tagging in order to support a larger number of subscribers.
Originally, communications betweenBRAS and DSLAM were asynchronous transfer mode (ATM)-based, but as Ethernet replaced ATM, the DSL Forum came up with TR-101 to describe Ethernet-based DSL networks. (See Figure 4.) More recently, the DSL forum came up with an update to TR-101 that is GPON specific. As can be seen in Figure 5, the reference model is pretty much the same (with OLT and ONU replacing the DSLAM and DSL model), and many of the updates have to do with the specific mapping of PON ports to VLAN. Note that in these solutions, the concept of separating the physical media from the router is similar to the modular CMTS (M-CMTS) architecture. However, they are not directly applicable, as pointed out in John T. Chapman’s 2008 SCTE paper "Modular CMTS V2.0 – An Architectural Discussion."
For DPON, two architectures are of a particular interest because of their natural fit into current cable networks:
Integrated BRAS/OLT: In this model, the BRAS functions (e.g., termination of subscriber sessions, subscriber management, etc.) are all implemented inside the OLT. In this case, the output of the OLT is IP packets, which can be sent directly to the network without further per-subscriber awareness/processing/tunneling. This model is similar to the current integrated CMTS architecture that is deployed in cable networks around the world.
Distributed BRAS/OLT: This is a more common architecture for today’s OLTs, however, and makes it more compatible with M-CMTS. The recommendation is to use L2TPv3 (used in DEPI) for the subscriber tunnels instead of VLANs. Furthermore, inline with the per-QAM (quadrature amplitude modulation) port aggregation of DEPI, it would make sense to create DEPI tunnels that are not per subscriber, but rather per PON or group of PON ports. Metro Ethernet and DPON The Metro Ethernet Forum has defined a set of standards that allow for consistent management and monitoring of metropolitan area networks (MANs) that are Ethernet-based. Though initially targeted at assisting with the migration from synchronous optical network/synchronous digital hierarchy (SONET/SDH) transport to Ethernet-based networks, it has already been extended to business subscribers and may be extended to residential subscribers, too.
In today’s networks, the OLT itself is connected to a metro network and as such should comply with the MEF standards. The subscribers themselves are not part of the metro network, and in the case of cable operators are best managed by a DOCSIS-like system, such as DPON. Range DOCSIS permits cable modems to be located as far away as 100 miles from the CMTS. However, 10-15 miles is the typical range. Because the HFC plant is active (powered fiber node and amplifiers), the range is more of an operational issue of getting power and servicing remote locations, and less of a technology issue.
The optical specifications of the current EPON and GPON systems provide for a maximum of 28 dB total optical link loss (with Class B+ optics). As illustrated in Figure 6, this budget allows roughly a 20 km reach with 32 ONUs on the PON, or 10 km with 64 ONUs. These distances and numbers of ONUs per PON are small relative to the typical values within an HFC system. One option to increase the range and number of ONUs is to locate the OLT remotely, closer to the subscribers. Remote OLTs, however, require appropriate enclosures and power feeds.
The ITU-T has just begun a project to extend PON’s reach. The objective is to use amplifier or repeater-based reach extenders to allow using ONUs built to current specs. The specifications are expected to support both single-sided and mid-span architectures. The single-sided architecture uses optical amplifiers co-located with the OLT in order to amplify the transmitted downstream signal and pre-amplify the received upstream signal. A mid-span extender places the amplification at a remote location between the OLT and ONU. The single-sided topology preserves a passive outside plant and has the extender managed as part of the OLT. However, there are potential technical and safety issues associated with the high optical power it would require in the downstream. It appears that the maximum reach with a single-sided topology is about 40 km with a 32-way split, but it will enable higher split ratios at shorter distances (128-way split at about 28 km reach).
The main advantage to the mid-span extender topology is that it allows significantly longer reach. With Class B+ optics, it is possible to locate the mid-span extender 40-60 km from the OLT. With the 20 km reach from the extender to the ONUs, the total reach is 60-80 km. Mid-span extenders are easier in this regard. They also allow the possibility of using an optical-electrical-optical repeater function rather than an optical amplifier in either the upstream or both directions. The drawbacks to the mid-span extenders are that they require remote powering and some degree of remote management functionality. However, they are still simpler devices than remote OLTs. Density This section explores "density" in terms of how much space is needed at a hub site to support a given number of subscribers.
Since the HFC plant is active, it is possible to aggregate a very large number of subscribers onto the single fiber that connects to a fiber node. A typical number in today’s deployments is in the range of 250-500 subscribers. Also, because in today’s deployments there is only a single 40 Mbps channel going to this group of subscribers, it is possible to use a single CMTS port to serve them.
By comparison, a single PON port typically supports up to 32 subscribers (there are deployments with a 64-way split), but at much higher data rates. Clearly the current HFC solution is denser today, but as the number of subscribers per fiber node decreases, and the bandwidth per subscriber increases, the density figures would not be as far off as they are today.
An often misunderstood issue with PON is the number of homes passed vs. the number of homes connected. The 32 PON connections do not have to be per homes passed, which means that only 20-40 percent are actually connected. It is possible to wire the headend in such as way that all 32 ports are used for connected subscribers and thus maximize the hub density.
Another issue is fiber density. In fiber-rich plant, it may be possible to support PON with existing fibers. However, in fiber-poor regions, fiber utilization becomes an issue, and the likely solutions are some sort of wavelength division multiplexing (WDM) technology – either by WDM over the fiber in the "second mile" (which will require an active node to convert it back to PON colors) or a WDM+PON solution. Redundancy For redundancy considerations, the PON system can be broken down into the following components:
• PON facility: fiber and passive components; active components (e.g., amplifiers, if used)
• OLT: Network connection (uplink); optical line units (OLUs) that connect to the PON; common units/functions
• ONU: optical interface; other ONU functions
OLT network connection failures or other common function failures are critical since they disrupt service for all subscribers connected to the OLT. These types of failures are not unique to PON and can be addressed by existing network configurations that are common to CMTS deployments, for example, 1:1 redundant Ethernet cards on the OLT.
In much the same way that an RF upconverter failure is the main source of hardware failures on the CMTS, OLU failures are the most common sources of hardware failures on the OLT. An OLT OLU failure affects the subscribers on one or more of the PONs connected to that OLU. As the number of PONs supported by an OLU and/or the number of subscribers on a PON increase, OLU protection may become necessary. Simple 1:1 OLU redundancy can be implemented with a 1:2 optical splitter or switch to connect the working and protection OLUs to the same PON. Forward error correction (FEC) may be required, however, to overcome the additional optical loss through the splitter or switch. More complex 1:N OLU protection schemes are being studied, but their cost-effectiveness relative to 1:1 protection will depend on many factors.
Failures associated with a PON facility affect only those subscribers served by that PON, and ONT-related failures only affect the subscriber(s) served by that ONT. For economic reasons, no protection was traditionally provided against a fault that affected 48 or fewer residential telephone customers. Since PONs use extremely reliable passive components, it is unlikely that PON facility protection will be used for residential subscriber applications. However, if optical amplifiers are used in order to increase the numbers of ONUs supported by a PON (i.e., the PON split ratio), the optical amplifiers will probably require redundancy. The cost of the redundant optical amplifiers must be taken into account when determining whether the increased split ratio is cost effective. FTTH technologies The optical market offers many solutions that are all "fiber to the home." A cable operator may choose any of them based on cost, regulation issues, performance or even the technology religion of the key decision makers. No discussion on DPON is complete without outlining these options and how DPON fits into them. This article does not rank or compare these different strategies. Rather, it points out of the role DPON plays in each one of them.
10G EPON and 10G GPON: IEEE 802.3 is developing a standard for next generation EPON operating at 10 Gbps (802.3av). The study has been underway for two years, with the first drafts published and ratification expected in mid-2009. Field trials will start the following year, and mass deployment will begin a year later (2011).
The most important property of 10G EPON is backward compatibility with existing EPON and GPON deployments. An additional wavelength is used to carry the 10 Gbps downstream so that it doesn’t interfere with existing deployed ONUs. The uplink for both new and legacy ONUs shares the same wavelength through time division multiplexing (TDM) arbitration. While the downlink speed is 10 Gbps, the uplink speed can be either 1 Gbps or 10 Gbps. The control protocol (multi-point control protocol, MPCP) is barely changed, except minimal adjustments for the discovery procedure. The optical link budget options include PR30, which is similar to the Class B+ with a 29 dB optical link loss budget.
FSAN/ITU-T is studying alternatives for next generation GPON. While it’s too soon to gauge their ultimate direction, there is a strong desire to unify EPON and GPON standards, at least in the PMD.
The availability of 10 Gbps speeds makes it suitable for carrying IPTV in band, supporting customized viewing of high definition (HD). It will provide a dramatic increase in the number of HD channels reaching the home, allowing improved customer experience, taking form in customizable view angles for sports games, directed commercials and other applications yet to be envisioned. Usage of analog overlay wavelength is still supported for simple migration.
Since DPON is located far above the physical layer, the speed up (and possible addition of colors for these technologies) will not impact the DPON definitions.
Point-to-point Ethernets: Point-to-point Ethernets can be thought of as a simple extension of existing Ethernet networks to the residential markets. Instead of sharing the media all the way to a neighborhood and splitting it on the last mile, (as is done in HFC, PON and WiMAX) the fiber is dedicated to the subscriber all the way to the central office (similar to a DSL case where the twisted-pair is going from the home to the central office). However, even in these networks some level of provisioning is needed since (even in cases where the physical media is capable of delivering 1 Gpbs) a subscriber may not be authorized to transmit at such rate. And IPv6, security, etc., can all be handled "DOCSIS style," which is the essence of the DPON concept.
WDM-PON: WDM-PON is a natural extension to point-to-point Ethernets, but instead of having separate fibers from the central office, each sub has a dedicated color, and at the last mile a special type of optical splitter separates the colors to the individual subscribers. A "color-blind" ONU can tune to any color, so there is no need to manufacture a different type of ONU for every subscriber. The role DPON would play in a WDM-PON deployment is identical to that of a point-to-point Ethernet.
WDM-PON + EPON/GPON: In principle, it is possible to combine both point-to-point and EPON/GPON on the same fiber; each color can be split to 32 subscribers. Such a system can (in theory) support 1,024 subs on a single fiber (!) and may be attractive in deployments that are fiber poor. In terms of DPON, the same comments that were made for point-to-point/WDM-PON/EPON/GPON apply here as well.
Micro fiber nodes: In a typical cable deployment, an RF signal is modulated over cable and sent to a fiber node, where it gets converted back to RF over coax and delivered to the home. But what if the fiber node was in the home, and the only RF devices connected to it were a standard cable modem and set-top boxes that belong to a single household? Such an architecture can be viewed as "fiber to the home" since a fiber does extend all the way to the home. In terms of DPON, it is obviously a "DPON" system because it’s driven by CMTSs and not by OLTs. Conclusion Migrating from HFC to pure fiber plant is not an easy or obvious choice for a cable operator. However, there are certain cases where a need for a PON is clear. A few are greenfields, plant upgrades (aging coax), acquisition and business customers.
Time will tell if these "PON islands" will replace HFC plant. But even if PON is restricted to certain applications or areas in the plant, a PON system that is integrated seamlessly into the back office is a powerful tool, and could be as simple as adding software that does DOCSIS/PON translation to the OLT. That said, the benefit from a cable-specific OLT designed from the ground up to fit cable network architectures is significant.
This article is adapted from a paper presented at ET ’08.
Alon Bernstein is a software architect for Cisco Systems. Reach him at [email protected]. Steve Gorshe is a principal engineer for PMC-Sierra. Reach him at [email protected].
