Patent Application
20150195039
This application is directed, in general, to Ethernet networks and, more specifically, to a system and method for interchanging data between the optical portion and the electronic portion of a hybrid Ethernet-based passive optical network (EPON).
Broadband Internet access has become a vital service for many governments, businesses and households. Because of its high performance and comparative low cost, EPON has become the technology of choice for telecom service providers to offer fiber to the home, the building, the curb, etc. EPONs are often geographically extended using electronic (“cable”) networks. It has become advantageous to use a unified protocol to communicate data over both the EPON and the electronic network. The Institute of Electrical and Electronics Engineers (IEEE) uses the term, “EPON over cable,” or EPoC, to describe the use of EPON protocols over a cable distribution network (CDN). EPONs and their cable extensions (together called “hybrid EPONs”) are in wide use and expected to be the primary delivery mechanism for broadband Internet services for years to come.
One aspect provides an interworking unit. In one embodiment, the interworking unit includes: (1) a cable line terminal (CLT) module operable to communicate with a plurality of cable network units (CNUs) via a CDN and (2) an optical networking unit (ONU) module coupled to the cable line terminal module and operable to generate a message requesting registration of the interworking unit as an ONU in an optical network and reporting a speed of the CDN.
Another aspect provides a method of interchanging data between an optical network and a CDN. In one embodiment, the method includes: (1) causing an interworking unit to communicate with a plurality of CNUs via the CDN, (2) generating a message in the interworking unit requesting registration of the interworking unit as an ONU in the optical network and (3) reporting a speed of the CDN via the optical network.
Yet another aspect provides a hybrid EPON-EPoC network. In one embodiment, the hybrid EPON-EPoC network includes: (1) a CDN coupled to a plurality of CNUs, (2) an EPON, (3) an interworking unit, having: (3a) a CLT module coupled to the CDN and operable to allow the plurality of CNUs to communicate via the EPON and (3b) an ONU module operable to cause the interworking unit to be registered with an OLT as an ONU in the EPON and report a speed of the CDN to the OLT.
Reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
It is realized herein that, while high data rates are possible in a hybrid network, inefficiencies remain. It is more specifically realized herein that the manner in which data is communicated between the EPON and the cable extension may be made more efficient. Accordingly, various embodiments of a system and method for interchanging data between the optical portion and the electronic portion of a hybrid EPON will be disclosed and described herein.
In general, the system and method provide, through the use of a novel interworking unit, an architecture and method that interconnect an EPON with downstream EPoC networks (i.e. forming a hybrid EPON-EPoC network). The interworking unit appears as an ONU to the OLT at the central office, and, at the same time, as the CLT for all the cable network units (CNUs) in the same CDN attached to the interworking unit. A salient point is that the EPON is decoupled from the CDN. The CDN could, and likely would, be operating at a different speed, both upstream and downstream, than the EPON. Multiple interworking units are possible for a given EPON, and multiple CNUs may be concurrently attached to the EPON through the interworking units. The various CDNs networks attached to the interworking units can operate at different speeds.
As an aside, while the term, CDN, implies use of a cable, and perhaps even a coaxial cable, for communication, the term is used more broadly herein to include any distribution network that may cooperate with an optical network to form a hybrid network. Thus, a CDN may be a wireline or wireless electronic network, or even an optical network of any conventional or later-developed type. If the interworking unit is to report the availability of future packets, an important characteristic of the CDN is that it be such that the interworking unit is able to report the availability of future packets with a high degree of certainty.
Certain embodiments of the interworking unit employ a modified REGISTER-REQ message that allows a device to identify its type to the OLT when it registers. Other important information, such as downstream and upstream speed of the attached CDN for interworking units can also be reported upon registration. A novel, enhanced REPORT message is introduced, by which an interworking unit can report “future data packets” which the interworking unit is expected to receive from the CNUs in the future. With this novel message, the OLT can allocate resources to allow the transmission of these “future packets” reducing latency with little or no loss of bandwidth efficiency.
The interworking unit functions primarily in the EPON. No assumption is made about the EPoC network. Therefore, the interworking unit can readily support other type of networks as long as the interworking unit is aware of, with sufficient certainty, data packets arriving from downstream in the future. “sufficient certainty” is typically gained through reports received by the interworking unit. Examples are other EPONs, wireless networks, etc.
EPON is specified in the IEEE 802.3ah-2004 (see, IEEE 802.3ah, “Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. Amendment: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks”, June 2004) and 802.1v-2009 suite of standards. The EPON standard specifies an EPON as the physical layer and Ethernet as the layer 2 in providing high-speed access service.
In the downstream direction, EPON uses time-division multiplexing (TDMA). All packets are transmitted downstream regardless of their intended destinations. In this example of
In the upstream direction, EPON uses Time-Division Multiple Access (TDMA). The OLT subdivides time into a number of time slots, each time slot being 16 nanoseconds (ns) long. The OLT allocates the time slots to the ONUs dynamically based on status reports from these ONUs as well as the policy at the OLT. The OLT can assign a number of contiguous slots to an ONU for transmission so that packets of varying sizes can be sent without segmentation. The allocation message from OLT indicates when an ONU can start to transmit upstream and the amount of the data that can be transmitted, in terms of number of time slots. The OLT ensures that the uplink data packets from different ONUs do not interfere with each other.
The Multipoint Control Protocol (MPCP) has five message types: GATE, REPORT, REGISTER-REQUEST (REGISTER-REQ), REGISTER, and REGISTER-ACKNOWLEDGE (REGISTER-ACK). The REPORT and GATE messages are used for dynamic time slot allocation, while the REGISTER messages are used for ONU registration. All five multipoint control messages contain the following fields: (1) Destination MAC Address, (2) Source MAC Address, (3) Type, encoded with the value x88-08 to indicate that the packet is an MPCP message, (4) Op Code, encoded to indicate the type of MPCP message such as GATE, REPORT, etc., (5) Timestamp, (6) Payload, and (7) FCS. The Timestamp field conveys the contents of the LocalTime register at the time of the transmission of the message. One use of this field is for the OLT to compute the Round-Trip Time (RTT) between the OLT and a given ONU. The Payload field contains the contents of the message. Its encoding depends on the message type. Padding may be added to satisfy the minimum message-size requirement. The FCS may be used to check whether there are errors in the packet.
The REPORT and GATE messages will now be described in more detail. REPORT messages are sent by ONUs to inform the OLT of the status of its upstream transmit queues. Each REPORT message is specific to a LLID that is assigned to the ONU. If the ONU is assigned a number of LLIDs, a REPORT message must be sent for each LLID. Each LLID can be associated with up to eight transmit queues.
EPON uses the concept of threshold reporting to encode the queue reports. A number of thresholds, up to 13 in the illustrated embodiment, can be configured for a queue. When encoding the queue reports for a queue, the ONU could report, in time slots, the size of all the integral packets just below a threshold. Consider the example illustrated in
The GATE message 600 further contains a Sync Time field 604 included only in discovery GRANT messages, a pad 410 a number of octets long, and the FCS 411. The Sync Time field, only included for discovery GRANT messages described below, informs an unregistered ONU of the time that the OLT requires to synchronize the received signal. The ONU should send idle code for this period of time before sending its REGISTER message.
The Grants/Flags field 601 is encoded as follows. The first three bits, bits 0-2, are used to encode the number of grants granted in GATE message 600. Up to four grants can be included. The next bit, bit 3, is used to indicate whether GATE message 600 is a normal GATE message or a discovery GATE message. A normal GATE message is a GATE message that an OLT sends to a specific ONU, giving the ONU permission to transmit at specific times. Discovery GATE messages are broadcast over the network giving the grant to all unregistered ONUs, so that they can send their REGISTER messages to the OLT to register themselves with it. The next four bits, one bit for each grant, are used to instruct the ONU whether a REPORT message should be sent at the end of the transmission for each grant.
Note that a grant is allocated to an LLID and not to individual queues of the LLID. Upon the receipt of a grant, it is up to the ONU to decide the transmission order of the packets among the queues.
The OLT dynamically allocates bandwidth to the ONUs based on information from the REPORT messages. One Dynamic Bandwidth-Allocation (DBA) algorithm is the IPACT algorithm. In IPACT, the OLT allocates bandwidth to the ONUs in a round-robin fashion. When the OLT allocates a grant to an ONU, the OLT allocates enough time so that the maximum amount of data as indicated in the REPORT message can be transmitted (plus one additional time slot for a REPORT message). To prevent a single ONU from hoarding the system, the OLT may place an upper limit to the size of a grant to an ONU. The advantage of the IPACT system is that it is very bandwidth-efficient, since no bandwidth assigned to an ONU would ever be wasted, as the OLT only allocates the time slot knowing that the data is available at the ONU to be transmitted. However, between the time that the ONU sends its REPORT message and the time that the ONU is instructed to transmit, data may be arriving at the ONU, the data arriving in this period cannot be transmitted until the next GATE message. Therefore, the IPACT algorithm may introduce more latency than other DBA algorithms, as data may have to wait longer at the transmit queue.
Other DBA algorithms have also been proposed. The most common family of algorithms involves allocating extra bandwidth to an ONU in anticipation of incoming traffic to the ONU. These are usually referred to as predictive DBA. Many variations exist, such as constant credit, linear credit, predictive credit, etc. with varying degrees of complexity and accuracy of prediction. In general, these algorithms would introduce less latency than IPACT but at the expense of bandwidth efficiency.
Many cable service providers are interested in providing Ethernet service by providing EPON over C (EPoC).
A common practice for cable service providers is to deploy optical fiber to an aggregation point near a group of subscribers (e.g., a neighborhood or a business building). The existing CDN is used to deliver services to the subscribers.
Various embodiments of the interworking unit 805 are possible. Only some embodiments are described in detail herein. In these embodiments, the interworking unit appears as an ONU to the OLT at the central office and as the CLT for all CNUs in the CDN attached to the interworking unit 805. Thus, the EPON is decoupled from the CDN.
The CDN could and likely would be operating at a different speed, both upstream and downstream, than the EPON. In practice, the operating speed of the CDN depends on a number of factors, such as the bandwidth allocated for the Ethernet service, the quality of the network, environmental conditions, etc. In fact, because of changing environmental conditions, the CDN may operate at different speeds at different times.
By decoupling the EPON from the CDN, the interworking unit isolates changes in the CDN from the EPON. Multiple CDNs can be attached downstream from the EPON, with each CDN attached to a logically separate interworking unit. Each individual CDN can operate at its own individual speed, possibly different from that of other CDNs.
Some enhancements to the EPON registration process will now be described. As specified in the EPON standard, an ONU registers with the OLT when the ONU first powers up. After the initial registration, the ONU re-registers at regular intervals. Thus, the ONU module in an interworking unit would also register with the OLT as specified in the EPON standard. However, the illustrated embodiment enhances the REGISTER-REQ message. When an interworking unit registers with the OLT, the enhanced REGISTER-REQ message includes the following additional information: ONU ID, ONY type, upstream operating speed, and downstream operating speed.
In response to the REGISTER-REQ message, the OLT sends the REGISTER message to the ONU module, indicating whether it accepts or rejects the registration request from the ONU module. In one embodiment, the above information is echoed in the REGISTER message. Similar to the case of the REGISTER-REQ message, the echoed information can be encoded using the reserved/pad octets in the REGISTER message.
Since the CDN usually operates at a much lower speed than the EPON, the OLT should avoid sending an excess amount of packets to an interworking unit as the packets may be discarded because of buffer overflow. Since the OLT is aware of the current downstream speed of the CDN that is attached to the interworking unit (through the enhanced REGISTER-REQ message described in the preceding paragraph), the OLT can limit the number of packets sent to the CDN downstream from an interworking unit. The traffic that is under rate control includes both unicast and multicast traffic that are for CPE that are attached to the CDN of the interworking unit. If the span of a multicast group is not known, packets destined for that multicast group are forwarded to all the CDNs and so they will come under rate control at the OLT for all interworking units. However, packets that are destined only for the ONU modules are not forwarded to the CDNs and so these packets are not under rate control. Examples of these packets are EPON MPCP control packets.
Downstream packet processing at the interworking unit will now be described.
The filter 1103 is operable to determine whether the packet is destined for devices that are attached to the CDN. The packet is only forwarded if it is destined for devices that are attached to the CDN. Otherwise, the packet is discarded. The interworking unit 900 can acquire the MAC addresses for the devices attached to the CDN through a number of means such as the EPoC registration process for CNUs, a learning process (i.e. observing and remembering the source addresses of packets from the CDN), or by administrative means. After passing the filter 1103, the packet is placed in a downstream transmission queue 1104 of the CLT module 902, queued for transmission downstream over the CDN.
Upstream packet processing at the interworking unit 900 will now be described. The CLT module 902 gives grants to downstream CNUs using GATE messages. It receives packets from a CNU at the time slot that is allocated to that particular CNU. The CLT module 902 examines the header of the incoming packets and, based on the information collected, forwards the packet to a transmission queue 1105 at the ONU module 901. The ONU module 901 transmits the packet to the OLT upon the receipt of a GATE message with the appropriate grant.
With the current REPORT message, system operation is not efficient. In the illustrated embodiment, the REPORT message is enhanced to improve the performance of the system. A relatively simple example will illustrate this.
For the purposes of the example, the ONU module 901 of the interworking unit 900 is assumed to have only a single transmit queue; the current time is set to t=0; packet size and time are measured in terms of time slots; the size of a time slot is different for the EPON and the CDN(s); the time slot of the EPON will be used as the unit of measurement; two packets are in the ONU buffer, of size 30 and 40 time slots respectively; and the interworking unit 900 is expecting to receive a packet of size 90 time slots from one CNU at time t=90, and another packet of size 80 time slots from another CNU at t=170. Under conventional operation, if the ONU module 901 is sending a REPORT message upstream now, the REPORT message would include two queue reports in two queue sets: one queue report indicating a queue length of 30 time slots, and the other queue report indicating a queue length of 70 (=30+40) time slots. If the OLT decides to instruct the interworking unit 900 to transmit at t=180, the OLT could grant a transmission of length 70 time slots so that both packets at the transmit queue could be transmitted (assuming that the OLT uses the conventional IPACT algorithm, rather than any predictive algorithm). However, at t=101>90, the interworking unit 900 has already received the packet from the first CNU. This packet has to wait until the next transmission cycle for the interworking unit 900. Alternatively, if the OLT decides that the interworking unit 900 should transmit at t=201>170, packets from both CNUs will have already arrived by then and would be available for transmission. A grant of 70 time slots would force both packets to wait until the next transmission cycle, resulting in degraded system performance.
The use of predictive algorithms may improve the response time but at the expense of bandwidth efficiency, as the prediction may not be accurate 100% of the time. A novel REPORT message is introduced that allows the ONU module 901 to report upstream information about packets that it expects to receive in the future with high certainty. In the above example, the new REPORT message allows the interworking unit 900 to report, as a queue report, a queue length of 150 time slots (=30+40+80) at a future time of at least 80 time units, and also a queue length of 240 time slots at a future time of at least 170 (=90+80) time units.
Following the Time Stamp field 406 is an 8-bit Flags field 1201, which is encoded as follows. The first bit is a Format indicator field 1202 used to indicate whether the queue reports in this message are two or three octets long. In the illustrated embodiment, an ONU can send up to four messages for the same report. Each message still requires one time slot, and they should be transmitted contiguously (i.e. one after another). Therefore, the ONU decides the number of messages to transmit based on the amount of available time slots for reporting. All the messages in the same report have the same time stamp, which has the value of when the first message is sent. The second and third bits together constitute a Sequence Number field 1203 are used to indicate whether this message is the first, second, third, or fourth message of a complete report. The fourth bit is an End Indicator field 1204, used to indicate that this message is the last message of a complete report. The fifth and sixth bits together constitute a Preferred Size field 1205. This field is used by the CNU to indicate its preference for the number of messages (up to 4) for the next report. Even though an ONU can express its preference, it is up to the OLT to decide the amount of time slots allocated. In the illustrated embodiment, Bits 7 and 81206, 1207 are reserved.
The next field is the Number of Queue Sets field 1208, which is the same as in the current REPORT message. The first octet of each queue set is the Bitmap field 1209, which is used to indicate the presence or absence of a queue report, as in the current REPORT message. In the illustrated embodiment, however, a queue report 1210 can be either two or three octets long, as indicated in the flags field 1201 described above. If a queue field 1210 is two octets long, it is used to encode the length of the queue buffer, the same as the current REPORT message. If a queue field 1210 is three octets long, the third octet is used to encode the future time, in units of time slots after the enhanced REPORT message is sent, that the queue length as encoded is realized. This third octet will be referred to herein as the “Future Time” field.
When sending a report that consists of multiple messages, different messages can use different formats for the queue reports. If the OLT only allocates a limited number of time slots for reporting, the ONU should always report queue status for packets that are currently available at the ONU.
Suppose the OLT 101 receives the enhanced REPORT message at time t1 and decides to send a GATE message 1302 to ONU module 901 at time t2, and that the ONU module 901 receives this message at time t3. For simplicity, assume that the GATE message 1302 contains a single grant. Let the value of the “start time” of this grant be “d.” The ONU module 901 should transmit packets at t4, after a wait of d time slots (i.e. t4=t3+d). The OLT 101 will receive the data packets at t=t5.
Note that the time difference between the moment that the OLT 101 sends the GATE message 1302 and the moment that the OLT 101 receives data packets from ONU module 901 is t5−t2. This duration has three components: the time to transmit the GATE message from OLT 101 to CNU 901 (i.e. t3−t2), the waiting time at ONU module 901 (i.e. d=t4−t3), and the time to transmit the first time slot of data from ONU module 901 to OLT 101 (i.e. t5−t4). The sum of the first and the third components is the round trip delay (RTT) between OLT 101 and ONU module 901 (i.e. t5−t2=d+RTT). In the EPON standard, this quantity can be estimated using the time stamp field 406 in the multipoint control header 401. Thus, if OLT 101 wants to receive data packets from ONU module 901 at time t=t5, as this is the time that the network is free of other transmissions, then it should encode a value of d=t5−t2−RTT in the start time field 602 for the grant in the GATE message 600.
If the OLT 101 allocates a time slot so that the data arriving at t=t10 can also be transmitted, it is efficient to have t10≦t4 (i.e. all the data should be ready for transmission at t=t4). The value of t4−t0 can be readily estimated by the OLT 101. It consists of four components: The transmission time of the REPORT message 1301 from ONU module 901 to OLT 101 (i.e. t1−t0), the waiting time at OLT 101 (i.e. t2−t1), the transmission time of the GATE message 1301 from the OLT 101 to the ONU module 901 (i.e. t3−t2), and the waiting time at the ONU module 901 before data transmission, (i.e. t4−t3=d).
The first and third components together make up the RTT between the OLT 101 and the ONU module 901. Therefore, t4−t0=d+RTT+(t2−t1). The OLT 101 is aware of all the quantities in the equation. The condition t10≦t4 is equivalent to (t10−t0) (t4−t0), or (t10−t0)<d+RTT+(t2−t1). The quantity v=(t10−t0) is value that is encoded in the “future time” field of the queue report. Thus the condition becomes:
v≦d+RTT+(t2−t1),
which can be readily verified by the OLT 101. Therefore, once the OLT 101 determines when it wants to receive data, it can determine whether it should allocate resource, and how much, to transmit data that would arrive at the ONU module 901 after the ONU module 901 has sent the REPORT message 1301. This is a simple but effective way to use the “future time” parameter at the OLT. In related embodiments, the “future time” parameter is used in other ways (e.g., in predictive algorithms).
The following are some of the advantages of the embodiments described herein. Certain embodiments allow an ONU module at an interworking unit to report to an OLT when (and how much) data would be ready in the future, after the REPORT message is sent, specifying the condition that an OLT can readily check to determine the amount of resources that can be allotted for “future data” with little or no loss of bandwidth. This allows lower latency with little or no loss of bandwidth efficiency. Some embodiments do not preclude the OLT using prediction algorithms to further reduce the latency of the packets, but at the expense of possible bandwidth wastage. Related embodiments allow multiple interworking units and multiple regular CNUs to be connected on the same EPON. The EPoC networks attached to the interworking units can operate at different speeds. Since an ONU module in the interworking unit has the option to report “future data” at different future times, this information can be used by the OLT to predict better data arrivals at the ONU module, if so desired. The EPON and the CDNs that are attached downstream to the interworking unit are decoupled. Therefore, network maintenance procedures such as diagnostics are simplified. In addition, all the capabilities described herein are available in the EPON. The enhancements are modifications to the REGISTER-REQ message, and a new REPORT message. No assumption is made about the EPoC network. Thus, networks other than EPoC attached downstream to the interworking unit are contemplated, as long as the interworking unit is aware of, with high certainty, about data packets arriving from downstream in the future. Examples are other optical networks, non-cable-based wired networks and wireless networks.
Other embodiments exist as well. For example, the “future time” parameter in the enhanced REPORT message 1200 can be larger than one octet, and the format of the REGISTER-REQ message 1000 as well as the enhanced REPORT message 1200 can be different, etc.
Those skilled in the art to which this application relates will appreciate that other and further additions, deletions, substitutions and modifications may be made to the described embodiments.
