This document relates to data communications in Ethernet Passive Optical Network (EPON) and EPON Protocol over Coax (EPoC) networks.
Fiber networks can provide broadband communication services to user premises. Some network operators, e.g., hybrid fiber-coaxial cable (HFC) operators, have begun using fiber optic networks to increase bandwidth capacity of the physical medium used to carry data in their networks. However, due to regulatory requirements or capital expenditure reasons, an all-fiber network often terminates at a hybrid fiber coax (HFC) network, which in turn provides entry into user premises.
The present document discloses achieving seamless data connectivity at a transition between a first network that uses a first medium access control (MAC) protocol for data communication over a first type of physical medium and a second network that uses a second MAC protocol for data communication over a second type of physical medium. In some disclosed embodiments, a combination apparatus provides a plurality of MAC instances on both the first network side and the second network side. The MAC instances on the first network side and the second network side are logically paired with each other during device discovery process on the network. The logical pairing is used to selectively provide data received at the first network interface to a MAC instance on the second network side and vice versa.
In particular, the present document discloses a fiber coax unit (FCU) that enables the carriage of Ethernet protocol data traffic over a coaxial network. The disclosed embodiments can be useful in multiple ways in providing high bandwidth data from a network to customer premises, including improving bandwidth used both in the uplink (customer premises to network) and the downlink (network to customer premises) directions. The disclosed techniques can reduce both operational expenses and capital expenses for carrying Ethernet protocol data over coax by selectively re-using certain architectural building blocks of the Ethernet passive optical network (EPON) framework. The disclosed techniques can also be deployed in current EPON networks or DPoE (DOCSIS provisioning of EPON) networks with little or no changes to existing equipment.
In one exemplary aspect, a Fiber Coax Unit (FCU) platform is disclosed. The FCU provides an Ethernet Passive Optical Network (EPON) interface to an EPON network and an Ethernet Protocol Over Cable (EPoC) interface to a cable network. A first data traffic is received and transmitted over the EPON interface using a plurality of optical network unit (ONU) media access control (MAC) protocol stack instances. A second data traffic is received and transmitted over the EPoC interface using a plurality of Coax Line Terminal (CLT) protocol stack instances. An FCU mediation layer selectively transfers portions of data from the first data traffic to the plurality of CLT protocol stack instances and the second data traffic to the plurality of OLT protocol stack instances. In some implementations, the FCU mediation layer directs a received operation, administration and maintenance (OAM) or extended OAM (eOAM) message from the EPON interface towards an associated CLT MAC protocol stack instance. In some implementations, the FCU mediation layer directs a received operation, administration and maintenance (OAM) or extended OAM (eOAM) message from the EPoC interface towards an associated ONU MAC protocol stack instance. In some implementations, the FCU selectively routes data between the first data traffic and the second data traffic based on association information created between a source EPON node and a destination EPoC node associated with the data during discovery and registration of a new cable network unit (CNU). In some embodiments, the FCU creates the association information by first creating a logical pair between an EPON MAC stack and an EPoC MAC stack based on their corresponding MAC addresses, obtaining a first logical link identifier by registering the paired EPON MAC stack in the EPON network, obtaining a second logical link identifier by registering the paired EPoC MAC stack in the EPoC network, and updating the logical pair with the first and the second logical link identifiers.
In another exemplary aspect, a process of operating a fiber cable unit (FCU) to provide data connectivity between an EPON that uses optical fiber as a first physical medium for communication and an Ethernet protocol over coax network that uses coaxial cable as a second physical medium for data communication is disclosed.
In yet another exemplary aspect, the disclosed techniques for selective data transmission between a plurality of EPON MAC stacks and a plurality of EPoC MAC stacks can be stored as executable instructions in a memory and a processor can read and execute the stored instructions to implement the disclosed techniques.
These and other aspects, and their implementations and variations are set forth in the drawings, the description and the claims.
Like reference symbols in the various drawings indicate like elements.
The present document relates to systems, devices and techniques for data communications in an Ethernet Passive Optical Network (EPON) and EPON Protocol over Coax (EPoC), and specifically to the architecture of the Fiber Coax Unit (FCU). Recently, CableLabs has issued Data Over Cable System Information Specification (DOCSIS) Provisioning of EPON (DPoE) architecture specifications versions 1 and 2. However, several features and operational details of the FCU, which can be used within the general framework of DPoE, have not been specified. The present document identifies certain functions of the FTU, which represents the functional block at which fiber ends and coaxial network begins, and several possible implementation options for implementing the FCU. Furthermore, this document also discloses a common management platform that can be used to implement the FCU functionality and changes to the DPoE architecture useful to support EPoC Coax Line Terminal (CLT) and Coax Network Unit (CNU) devices via the common management platform.
EPON Protocol over Coax (EPoC) reuses Ethernet Passive Optical Network (EPON) protocols for operation over coaxial (passive and amplified) access networks, while maintaining the same operating principles of EPON. In particular, EPoC reuses the operating principles and scheduling facilities provided by the Multi Point Control Protocol (MPCP) specified for EPON in IEEE Std 802.3.
The evolution of cable networks to all-IP-based service delivery is driven by the flexibility and ubiquity provided by IP connectivity as well as several market forces and trends, e.g., as disclosed in the present document.
The new IP-based services and applications can be delivered more efficiently if the underlying architecture natively supports IP transport without having to reuse non-IP-optimized transport architectures.
The proliferation of handheld and tablet devices that provide wireless connectivity significantly has increased the consumer demands of access to entertainment contents anywhere, at any time.
There is interest in cable operators for delivering managed subscription-based video services over IP end-to-end, replacing today's Motion Picture Experts Group—Transport Streams (MPEG-TS) delivery over the HFC access network. IP-based delivery of managed video services enables operator-managed video services to reach “any device, any time, any place,” which is essential for cable operators to maintain competitiveness as various over-the-top video sources flood the marketplace.
Several new revenue opportunities are made available by IP. For example, using IP allows wider reach of ads and expands the opportunities for ad placements.
The exponential increase in the demand to deliver video content, not only over the public Internet, but also for subscribed IPTV services to set-tops, mobile devices and laptops has also lead to an increased demand on IP connectivity.
A key challenge facing multiple system operators (MSOs) to migrate to an all-IP network is the astronomical increase in bandwidth required to deliver real-time entertainment over IP networks. EPoC is expected to address this problem in the most economic fashion, primarily through the internetworking with EPON/DPoE Systems.
Once developed, EPoC will support a number of deployment scenarios, with varied degrees of fiber penetration. The variable fiber penetration depth caters best to existing cable operator networks, requiring little or no changes at all to the existing cable plant.
With reference to
In the first scenario 152 shown in
The third scenario 156 shows a direct migration from an existing DOCSIS based cable plant to EPoC, where analog fiber is used for backhauling and FN displacement purposes, reaching the network diameters currently supported by the DOCSIS networks.
Given that these are just examples of future EPoC deployment scenarios, it is clear that this technology has an evolutionary potential in part based on its ability to coexist with both DOCSIS and EPON/DPoE, the ability to operate on its own, and the ability of reusing the existing coaxial plant with changes to electronic endpoints only. Taking advantage of certain available coaxial and fiber technologies, it is likely to help with the adoption of FTTx in cable networks, making Fiber to the Node architecture more popular. Eventually, the proximity of the fiber node to the customer as well as availability of EPON/DPoE equipment in the headend will facilitate the path of migration toward fiber-oriented services for both business and residential customers.
In various embodiments, an FCU 122 may include some of the following functional features.
An FCU may inter-connect fiber (EPON) and coax (EPoC) distribution domains, acting as a media converter between both domains (ODN=optical distribution network, CDN=coaxial distribution network) operating with different media, as well as with different data rates.
An FCU in the downstream direction (from the OLT towards the CNU) may filter packets not intended for any of CNUs connected to the given FCU, lowering bandwidth demand on CDN in the downstream direction. This particular functional requirement may not affect the upstream transmission direction in any way.
An FCU in the upstream direction aggregates transmissions from individual CNUs and makes them available to the OLT in a way that isolates the OLT from having to learn CDN parameters, be able to cope with dynamically changing and variable data rates for individual CNUs as well as having to distinguish CNUs from ONUs in terms of scheduling.
An FCU may allow the OLT to perform scheduling for individual ONUs and CNUs in the same fashion, without requiring any changes in the existing DPoE/EPON implementations.
An FCU may be reachable via OAM, eOAM and MPCP for remote control from the OLT perspective and may be seen from the OLT perspective as an EPON ONU (for all bandwidth control and management purposes).
The DPoE specifications describe a network architecture allowing EPON ONUs to be configured and managed using the cable operator's existing back office servers. Furthermore, the same provisioning concepts such as DHCP, TFTP, and configuration files are imposed on DPoE ONUs and DPoE Systems such that an access network based on EPON technology resembles a DOCSIS access network from the perspective of the cable operators back office servers.
In order to take full advantage of the existing DPoE management model covered in detail in DPoE specifications, the FCU in some implementations can be configured to reuse the concept of virtual Cable Modem (vCM) instantiated in the OLT (DPoE System in DPoE-specific terminology), which is used to provide IP-based management functions for a remote subscriber station reachable via a combination of OAM and eOAM specified by IEEE 802.3, IEEE 1904.1 and CableLabs in conjunction.
As shown in
In such an arrangement, the existing DPoE DEMARC specifications, defining the operation of a DEMARC Auto Configuration (DAC) protocol, can be extended in a transparent manner into EPON+EPoC Network management model shown in
Furthermore, the whole service provisioning and QoS model employed in DPoE and defined in DPoE-SP-MEF and DPoE-SP-MULPI (versions 1 and 2, as published by CableLabs) can be also extended to CNUs across the FCU, given that the required management traffic (OAM, eOAM) and subscriber traffic is passed transparently, while QoS enforcement in the EPON remains unchanged from what was defined in DPoE.
In
With reference to
On the EPON side (at the FE interface 302), the FCU is equipped with an ONU-like PHY 308, capable of continuous-mode downstream operation and burst-mode upstream operation, combined with a number of MAC instances 310: at least one unicast MAC instance, at least one multicast instance and exactly one broadcast MAC instance. Each MAC instance is associated with an LLID upon discovery and registration of the associated MAC instance at the OLT, following the provisions of the IEEE Std 802.3, Clause 77 for 10G-EPON capable FCU or Clause 64 for 1G-EPON capable FCU. All unicast and multicast MAC instances on the EPON interface side.
Moreover, on the EPON side (at the FE interface 302), the FCU is also equipped with one additional unicast MAC instance 310. This MAC instance is not associated with any CLT MAC instances and it is used exclusively for the local FCU management purposes.
Alternatively, the FCU at the FE interface can be equipped with the P2P Ethernet interface when connected to a P2P Ethernet port on the DPoE System capable of supporting such a data link. The support for P2P data links is not currently accounted for by DPoE specifications, though a person skilled in art could extend the coverage from P2MP architecture of EPON to P2P Ethernet architecture. Different data rate P2P Ethernet interfaces can be supported, ranging from 1 Gbit/s Ethernet, through 10 Gbit/s Ethernet as well as higher speed Ethernet interfaces, if the FCU requires such backhaul capacity. The architectural framework for the FCU device included in this document can be adapted to P2P Ethernet backhaul link.
In case of the P2P Ethernet backhaul link between the OLT and the FCU, there is only one MAC instance at the FE interface, and the MPCP is replaced by a generalized MAC Control sublayer.
On the EPoC side (at the FC interface), the FCU is equipped with a EPoC CLT PHY, capable of FDD or TDD mode operation (depending on the operator-driven configuration), combined with a number of MAC instances (marked as “CLT MAC” in
On the EPoC side (at the FC interface), there is no dedicated unicast MAC instance for the local FCU management purposes.
On the EPON side (at the FE interface), when equipped with the EPON backhaul interface, the unicast, multicast and broadcast ONU MAC instances are not equipped with the OAM Client and all OAM and eOAM packets received from the FE interface are forwarded across the FML towards the associated CLT MAC instance. This means, effectively, that the OAM management domain spans between the OLT and the CNU, as shown in
The FCU Mediation Layer (FML) 320 presented within the FCU at the FI interface 304 is primarily responsible for forwarding traffic between associated ONU MAC and CLT MAC instances, as well as performing additional scheduling, polling and mapping tasks for such MACs.
In some embodiments, the FML 320 forwards (acting as a repeater) downstream unicast, multicast or broadcast packets received from the EPON interface FE towards the appropriate CLT MAC instance at the FC interface. The forwarding decision is taken based on the association between the source (ONU) and destination (CLT) MAC created at the time of discovery and registration of a new CNU.
In some embodiments, the FML 320 forwards downstream management (OAM and eOAM) traffic received from the EPON interface FE towards the appropriate CLT MAC instance at the FC interface. The forwarding decision is taken based on the association between the source (ONU) and destination (CLT) MAC created at the time of discovery and registration of a new CNU.
In some embodiments, the FML 320 forwards upstream unicast and multicast packets received from the EPoC interface FC towards the appropriate ONU MAC instance at the FE interface. The forwarding decision is taken based on the association between the source (CLT) and destination (ONU) MAC created at the time of discovery and registration of a new CNU. In the upstream, all broadcast traffic may be constrained within the EPoC CDN.
In some embodiments, the FML 320 forwards upstream management (OAM and eOAM) traffic received from the EPoC interface FC towards the appropriate ONU MAC instance at the FE interface. The forwarding decision is taken based on the association between the source (CLT) and destination (ONU) MAC created at the time of discovery and registration of a new CNU. In the upstream direction, all broadcast traffic is constrained within the EPoC CDN.
In some embodiments, the FML 320 creates an association between the ONU MAC and CLT MAC instances at the time when a new CNU is discovered and registered at the CLT.
Any unicast or multicast downstream packets received from the EPoC interface FC and not intended for any of the unicast or multicast ONU MAC instances may be dropped at the FE interface, e.g., following the rules defined in IEEE Std 802.3, Clause 65 for 1G-EPON capable FCU and Clause 76 for 1G-EPON capable FCU. This means that only frames intended to be distributed within the given CDN subtended at the given FCU are forwarded by the FML and then handed off to the CLT for transmission in the FDD or TDD mode, as configured by the operator.
The process of creating an association between the ONU MAC and CLT MAC instance starts with the discovery of a new CNU MAC instance, at which time the CLT performs the CNU discovery and registration process, currently under definition in IEEE P802.3bn “EPoC” Task Force. During this process, the CLT binds also one local unicast CLT MAC instance with the newly discovered CNU MAC instance, creating an association between the allocated LLID, CNU MAC instance and the CLT MAC instance, required for the proper operation of the EPoC protocols.
After a successful registration of a new CNU MAC instance, the FML proceeds to create an association between the newly created CLT MAC instance and one of available (and currently inactive) ONU MAC instances. For simplicity, it is assumed that there is at least one inactive ONU MAC instance available for this process. In real devices, there may be a limited number of ONU MAC instances available for such an association, due to hardware limitations. The process of creating the association features three stages, outlined as follows.
In the first stage, an association is created between a currently inactive ONU MAC instance (MACE) and newly activated CLT MAC instance (MACC), where the association between these two MAC instances is based on the MAC address. In this stage, the MACE is not yet registered at the OLT and the only information that can be used to establish the association between MACE and MACC are their MAC addresses.
In the second stage of the process, the newly activated MACE is registered at the OLT following the process of MPCP discovery and registration defined in IEEE Std 802.3, Clause 77 for 10G-EPON capable FCU and Clause 64 for 1G-EPON capable FCU. At the end of this stage, the MACE is assigned EPON LLID (LLIDE) used to deliver all unicast data over EPON.
In the third stage of the process, the association between MACE and MACC is updated and the binding between two MAC instances is based on LLID value, i.e., LLIDE used within EPON ODN and the LLIDC used within EPoC CDN. There are no requirements towards the uniqueness of LLIDE and LLIDC values and they can be either the same or different. Both LLID domains in the proposed FCU architecture are isolated and can share the same LLID numbering space.
After the completion of the association process, traffic received across FE interface and tagged with LLIDE is forwarded towards MACC instance associated with LLIDC, corresponding to LLIDE, based on the association between the ONU MAC instance at the FE interface and the CLT MAC instance at the FC interface, maintained within the FML. Below are three examples for data frames, OAM frames and MPCP frames transmitted downstream from the OLT and the CNU on unicast LLIDE, intended for CNU with MACC associated with LLIDC, bonded with LLIDE.
In the downstream direction, the FML 320 provides sufficient buffering for frames intended to be delivered to respective CNUs. Such frames may need to wait for availability of downstream transmission link to the destination CNU, especially when there is difference between the data rate supported by EPON and EPoC. Similar buffering space is provided in the upstream direction as well, for any frames intended to be delivered to the OLT. The upstream buffer size should additionally account for the scheduling delay, since the upstream channel within EPON may not become available immediately, given the shared medium operating mode in the upstream direction.
Any user data frame is transmitted downstream with the destination MAC address of the target CPE device, connected to the CNU, and with the LLIDE, indicating the unicast link between the OLT and FCU. All such frames are then forwarded towards the associated LLIDC across the FML and then delivered to the target CNU using the TDD or FDD mode, depending on the operator configuration.
Any OAM frame is transmitted downstream with the slow protocol multicast MAC address of 0x01-80-C2-00-00-02 and with the LLIDE, indicating the unicast link between the OLT and FCU. Given the absence of the OAM Client in FCU in downstream direction, all such frames are forwarded towards the associated LLIDC across the FML and then delivered to the target CNU using the TDD or FDD mode, depending on the operator configuration.
Any MPCP frame is transmitted downstream with the MAC Control multicast MAC address of 0x01-80-C2-00-00-01 and with the LLIDE, indicating the unicast link between the OLT and FCU. Given that the FCU in the downstream direction is equipped with the MAC Control Client instances, MPCP frames are locally sunk by the associated clients and not forwarded towards individual CNUs.
The transmission in the upstream direction is generally the same, with one difference being the additional queuing delay due to the operation of the shared-medium access protocol in the upstream channel of EPON.
It will be appreciated that using the disclosed techniques, bandwidth utilization on EPON can be optimized for fiber devices only and is not burdened with CNUs that typically do not operate at full fiber interface data rate.
Similarly, using the disclosed techniques, bandwidth utilization on EPoC can be optimized for coax devices, both in terms of grant design, frequency, size etc.
In one advantageous aspect, the FCU 320 performs a simple media conversion and a repeater-like operation of FCU for associated EPON-side and EPoC-side LLIDs, without extra scheduling complexity (and delay) to accommodate for coax and fiber devices on the same port.
Existing EPON OLTs (and DPoE System) hardware can be used with EPoC CNUs unmodified, preserving already existing investment, while FCUs can be added to the already existing DPoE Network deployments are any time and at any location, providing the ability to serve both residential and business customers off the same ODN.
Each EPoC LLID is mapped through FCU Mediation Layer (FML) into an EPON LLID, allowing EPON OLT to schedule them independently and individually, providing improved QoS.
EPoC can use either FDD or TDD, without affecting scheduling across EPON, constraining the problems related with implementation of both of these modes of operation to EPoC only
Discovery windows for EPON devices can be smaller, not having to account for presence of both fiber and coax devices on the same port.
Frames that have errors can be dropped at the FCU when an incorrect FCS is detected. Therefore, in some embodiments, the FCU can mitigate error propagation problem in which a frame is transmitted by one of CNUs and is corrupted during the transmission over CDN, but still consumes unnecessarily upstream resources in the EPON.
The disclosed and other embodiments and the functional operations described in this document can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in combinations of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more them. The term “data processing apparatus” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus.
A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
The processes and logic flows described in this document can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Computer readable media suitable for storing computer program instructions and data include all forms of non volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
While this document contains many specifics, these should not be construed as limitations on the scope of an invention that is claimed or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination. Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.
Only a few examples and implementations are disclosed. Variations, modifications, and enhancements to the described examples and implementations and other implementations can be made based on what is disclosed.
This patent document claims the benefit of priority of U.S. Provisional Patent Application No. 61/726,794, filed on Nov. 15, 2012. The entire content of the before-mentioned patent application is incorporated by reference herein.
Number | Date | Country | |
---|---|---|---|
61726794 | Nov 2012 | US |