Overhead reduction in Ethernet passive optical network (EPON)

Embodiments reduce overhead in Ethernet Passive Optical Network (EPON) networks by reducing the amount of switching among Optical Network Units (ONUs) done by the Optical Line Terminal (OLT). In one embodiment, Logical Link Identifiers (LLIDs) hosted by the same ONU are linked at the OLT such that the OLT grants same ONU LLIDs consecutively when appropriate. This reduces the optics related delay associated with switching among ONUS. At the same time, the linking of LLIDs hosted by the same ONU allows for data from multiple LLIDs to be grouped together within a single Forward Error Correction (FEC) block at the ONU, when appropriate, reducing FEC overhead.

FIELD OF THE INVENTION

The present disclosure relates generally to passive optical networks.

BACKGROUND

Background Art

A Passive Optical Network (PON) is a single, shared optical fiber that uses inexpensive optical splitters to divide a single fiber into separate strands feeding individual subscribers. An Ethernet PON (EPON) is a PON based on the Ethernet standard. EPONs provide simple, easy-to-manage connectivity to Ethernet-based equipment, both at customer premises and at the central office. As with other Gigabit Ethernet media, EPONs are well-suited to carry packetized traffic.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1illustrates an example Ethernet Passive Optical Network (EPON)100. Example EPON100is provided for the purpose of illustration only and is not limiting of embodiments of the present disclosure. As shown inFIG. 1, example EPON100includes an Optical Line Terminal (OLT)102, an optical passive splitter106, and Optical Network Units (ONUs)110aand110b.

OLT102typically sits at a central office (CO) of the network and is coupled to a fiber optic line104. OLT102may implement a DOCSIS (Data Over Cable Service Interface Specification) Mediation Layer (DML) which allows OLT102to provide DOCSIS provisioning and management of network components. Additionally, OLT102implements an EPON Media Access Control (MAC) layer (e.g., IEEE 802.3ah or 802.3av). Optionally, passive splitter106can be used to split fiber optic line104into a plurality of fiber optic lines108a-b. This allows multiple subscribers, such as ONUs110aand110b, which may be in different geographical areas, to be served by the same OLT102in a point-to-multipoint topology.

ONUs110a-bmay include units that typically sit at the subscriber's end of the network, or coaxial media converters (CMCs) that bridge between an EPON network and a coaxial network to form an EPON over Coaxial (EPOC) network. ONUs110a-bmay each serve one or more end user devices (not shown inFIG. 1). The end user devices may provide one or more services (e.g., Voice over Internet Protocol (VoIP), High Definition TV (HDTV), etc.) at a single subscriber's unit and/or at a multi-dwelling unit (MDU).

ONUs110a-bshare fiber optic line104in a time division multiplexing (TDM) manner for upstream communication to OLT102. To avoid collisions, OLT102uses the Multi-point Control Protocol (MPCP) (a Medium Access Control (MAC) level protocol) to synchronize ONUs110a-bto the same timing reference, allow for a discovery and registration process for new ONUs, and schedule upstream transmissions from ONUs110a-b.

The discovery and registration process allows OLT102to discover and register new ONUs that wish to join the network. The process includes OLT102periodically broadcasting a MPCP Discovery GATE message. The Discovery GATE message specifies a discovery time slot, within which a new ONU can send a request for registration to OLT102. To join the network, a new ONU responds to a MPCP Discovery GATE message by sending a MPCP REGISTER_REQ message, which contains the ONU's MAC address. Upon receiving the REGISTER_REQ message from the ONU, OLT102registers the ONU and assigns it a Logical Link identifier (LLID). OLT102then sends the assigned LLID to the ONU in a MPCP REGISTER message. Separately, in a MPCP GATE message, or in the REGISTER message, OLT102then grants the ONU a transmission time slot. The ONU responds by sending a MPCP REGISTER_ACK, message in the granted time slot, terminating the registration process.

One or more LLIDs can be assigned to the same ONU as described in co-owned U.S. Pat. No. 7,436,765, titled “Method and Apparatus for Dynamically Allocating Upstream Bandwidth in Passive Optical Networks,” which is incorporated herein by reference in its entirety. For example, referring to FIG.1, ONU110ais assigned two LLIDs112aand112b, while ONU110bis assigned a single LLID112c. Typically, LLIDs are assigned randomly. As a result, an ONU may or may not be assigned LLIDs with consecutive numbers.

For upstream data transmissions, ONUs110a-bsend MPCP REPORT messages to OLT102in order to receive time grants for upstream transmission. A REPORT message for a given LLID indicates the status (e.g., fill-level) of an upstream data queue associated with the LLID (LLID queue). An ONU that hosts multiple LLIDs, such as ONU110ainFIG. 1, may send the status of its LLID queues in one or multiple REPORT messages to OLT102.

MPCP REPORT messages may be sent by ONUs110a-bin response to polling GATE messages from OLT102, which poll ONUs110a-bfor LLID queue status, or may be piggy-backed to data transmissions. OLT102responds to MPCP REPORT messages from ONUs110a-bby sending unicast GATE messages to ONUs110a-b. A unicast GATE message grants a particular ONU/LLID pair a time slot for upstream transmission. The granted ONU/LLID pair then transmits data from its queue in the assigned time slot.

OLT102may employ a variety of algorithms to determine the order in which ONU/LLID pairs are granted time slots for upstream transmission. For example, OLT102may use a fairness-based algorithm that further supports multiple Quality of Service (QoS) levels among ONU/LLID pairs. Sometimes, the determined order may require OLT102to switch back and forth between ONUs. For example, referring toFIG. 1, OLT102may grant in this order LLID0112a, LLID2112c, and then LLID1112b, requiring OLT102to switch back and forth between ONU110aand ONU110b.

Typically, when switching from ONU to ONU, delay is incurred due to the time needed for the optics (e.g., laser) in one ONU to turn off and the optics in the other ONU to turn on. Additional delay is also incurred due to the time needed for the receiver at OLT102to synchronize each time to the transmitting ONU. These delays contribute to what is referred to herein as overhead in an EPON network, which reduces the upstream bandwidth utilization efficiency.

Another source of overhead specific to 10 Gbit/s (10 G) EPON networks is due to mandatory Forward Error Correction (FEC), which is applied on a 255-byte block level rather than on a frame level as in 1 Gbit/s (1 G) EPON. This FEC mechanism requires the OLT to grant an ONU/LLID pair with only a small amount of data (e.g., 64 bytes) a time slot that is large enough for sending an FEC encoded 255-byte block.

Embodiments of the present disclosure, as further described below, reduce overhead in EPON networks by reducing the amount of switching among ONUs done by the OLT. In one embodiment, LLIDs hosted by the same ONU (same ONU LLIDs) are linked at the OLT such that the OLT grants same ONU LLIDs consecutively (without other LLIDs being granted in between) when appropriate. This reduces the optics related delay associated with switching among ONUs. At the same time, the linking of LLIDs hosted by the same ONU allows for data from multiple LLIDs to be grouped together within a single FEC block at the ONU, when appropriate, reducing FEC overhead.

Embodiments will now be described with respect to exemplary OLT implementations. These implementations are provided for the purpose of illustration only and are not limiting. As would be understood by a person of skill in the art based on the teachings herein, embodiments may be implemented in a variety of other ways without departing from their scope.

FIG. 2illustrates an example Optical Line Terminal (OLT)200according to an embodiment of the present disclosure. Example OLT200is provided for the purpose of illustration only and is not limiting. Example OLT200may be used to implement embodiments as further discussed below. As shown inFIG. 2, example OLT200includes a Dynamic Bandwidth Allocator (DBA) module202, a scheduler module210, an embedded processor214, and a Media Access Control (MAC) module216. DBA module202includes a DBA scheduler module204, a DBA polling module206, a DBA Time Division Multiplexing (TDM) module208, and a DBA grant module212. As would be understood by a person of skill in the art, OLT200may include additional modules not shown inFIG. 2.

For purposes of this discussion, the term “module” shall be understood to include at least one of software, firmware, and hardware (such as one or more circuits, microchips, or devices, or any combination thereof), and any combination thereof. In addition, it will be understood that each module can include one, or more than one, component within an actual device, and each component that forms a part of the described module can function either cooperatively or independently of any other component forming a part of the module. Conversely, multiple modules described herein can represent a single component within an actual device. Further, components within a module can be in a single device or distributed among multiple devices in a wired or wireless manner.

In an embodiment, scheduler module210, DBA polling module206, DBA TDM module208, and embedded processor214each can send grant requests to DBA scheduler module204. A grant request as used herein is a request to DBA scheduler module204to cause a GATE message to be sent or broadcast on the network granting a time slot for upstream transmission. As further described below, different grant request types can be supported by OLT200. For example, grant requests may be issued for the purpose of servicing a particular LLID having a non-empty queue or for initiating a discovery and registration interval for new ONUs to join the network. DBA scheduler module204selects which among the grant requests it receives is serviced next, and provides this information to DBA grant module212. DBA grant module212schedules the grant in MAC216.

Scheduler module210is configured to issue grant requests for servicing LLIDs with non-empty queues. Typically, scheduler module210receives queue status information from ONUs, piggy-backed onto upstream data transmissions in the form of MPCP REPORT messages. Additionally, scheduler module210may receive queue status information from ONUs in response to polling GATE messages sent out by OLT200to particular ONUs. Scheduler module210issues grant requests to DBA scheduler module204based on queue status information.

In an embodiment, scheduler module210issues grant requests to DBA scheduler module204according to a fairness-based algorithm, which may further support different QoS levels across ONUs and/or ONU/LLID pairs. For example, scheduler module210may implement a weighted-deficit round-robin algorithm to select a grant request for sending to DBA scheduler module204.

In an embodiment, as further described below with reference toFIGS. 4-8, scheduler module210maintains a service linked list of LLIDs that ensures that same ONU LLIDs are granted consecutive time slots whenever possible. The service linked list is updated by scheduler module210based, in part, on information received from DBA scheduler module204. For example, DBA scheduler module204sends an activation/de-activation signal to scheduler210whenever a non-zero/zero (non-empty/empty queue) REPORT message is received for a particular LLID pair. This enables/disables a link in the linked list for that particular LLID. Scheduler module210cycles through enabled links, and for each enabled link, determines if the LLID associated with the link is within its service level. If scheduler module210determines that an LLID is due for service, it sends a grant request for the LLID to DBA scheduler module204.

DBA polling module206is configured to send a polling grant request to DBA scheduler module204whenever an LLID in a maintained polling list is determined to have an expired last polling time. The last polling time for a particular LLID is the time at which a last REPORT message was received from the LLID. A LLID has an expired last polling time when the current time exceeds the last polling time by greater than a selected poll interval and no REPORT message has been received from the ONU/LLID pair (piggy-backed to a data transmission). In an embodiment, DBA polling module206cycles periodically through LLIDs in the polling list, checking the polling status of each LLID. In another embodiment, some LLIDs in the polling list can be disabled such that DBA polling module206may skip checking their polling status.

In an embodiment, as further described below with reference toFIG. 3, the polling list maintained by DBA polling module206is a linked list, in which same ONU LLIDs are linked. As such, when cycling the list, DBA polling module206will check the polling status of same ONU LLIDs in a consecutive fashion. This causes polling grants, when needed, to be sent to same ONU LLIDs consecutively and for any resulting upstream REPORT messages from same ONU LLIDs to be transmitted in consecutive time slots to the OLT.

DBA TDM module208is configured to send periodic high-priority grant requests (TDM grant requests) to DBA scheduler module204for servicing latency-sensitive LLIDs. In an embodiment, LLIDs for latency-sensitive services (e.g., VoIP) are mapped to DBA TDM module208. DBA TDM module208maintains a list of such LLIDs, with respective grant length and period for each LLID. In an embodiment, DBA TDM module208issues TDM grant requests for maintained LLIDs in a round-robin fashion. In another embodiment, DBA TDM module208may implement a linked list, similar to the polling linked list, so that TDM grant requests to same ONU LLIDs are grouped consecutively. Alternatively, DBA TDM module208may share the same list (implemented as a two-tiered list) with DBA polling module206.

Embedded processor214may also be configured by firmware to send grant requests to DBA scheduler module204. In an embodiment, embedded processor214is configured to send grant requests to DBA scheduler module204periodically to initiate discovery and registration intervals. Other types of processor-initiated grant requests may also be used. In an embodiment, embedded processor214maintains a firmware master list of LLIDs, which may also be a linked list in order to group same ONU LLIDs together. This causes processor-initiated grants to be sent to same ONU LLIDs consecutively.

DBA scheduler module204is configured to select the order in which grant requests that it receives from scheduler module210, DBA polling module206, DBA TDM module208, and/or embedded processor214are serviced. In an embodiment, DBA scheduler module204services received grant requests according to a priority order. For example, DBA schedule module204may service TDM grant requests from DBA TDM module208first, followed by polling grant requests from DBA polling module206, processor-initiated grant requests from embedded processor214, and finally grant requests from scheduler module210. Other priority orders ma also be used.

In addition to selecting the servicing order, DBA scheduler module204also determines a time slot value for the grant request selected for service. DBA scheduler module204then provides the grant request selected for service and the associated time slot value to DBA grant module212. DBA grant module212forms a grant based on the grant request and associated time slot value, schedules the grant for forwarding to MAC216, and then forwards the grant to MAC216at a scheduled time. In an embodiment, DBA grant module212enqueues the grant in a buffer of outgoing grants of MAC216, MAC216processes its outgoing grants buffer in a first-in-first-out (FIFO) manner, placing each grant in a respective MPCP GATE message and transmitting the GATE message onto the network. In an embodiment, up to four outstanding grants per ONU can be present in the buffer of MAC216.

FIG. 3illustrates an example polling linked list300according to an embodiment of the present disclosure. Example polling list300is provided for the purpose of illustration and is not limiting of embodiments. As described above, polling linked list300may be maintained by a polling module, such as DBA polling module206. Entries corresponding to same ONU LLIDs are linked in list300so that the polling module checks them for polling eligibility in a consecutive fashion. As a result, when more than one LLID belonging to the same ONU are eligible for polling, polling grants are sent to the ONU consecutively, and any resulting upstream REPORT messages are transmitted in consecutive time slots to the OLT. This increases the utilization efficiency of the EPON network.

In an embodiment, as shown inFIG. 3, polling linked list300is implemented using a Random Access Memory (RAM) with twice as many entries (RAM addresses) as LLIDs. It is noted that embodiments are not limited to RAMs that support 256 LLIDs as shown inFIG. 3, but can be extended to any number of LLIDs (e.g., 512, 1024, 2048, etc.). In an embodiment, the RAM is divided into a lower section302(lower offset RAM addresses) and an upper section304(upper offset RAM addresses). Lower section302and upper section304may be equal in size. At any given time, only one of lower section302and upper section304is used by DBA polling module206to issue polling grants, while the other section is made available for update (e.g., by software) to add/remove entries.

When a section is in use by DBA polling module206, a head pointer indicates the first LLID to check for polling eligibility. In the example shown inFIG. 3, when lower section302is used, head pointer306indicates that polling eligibility check should start at memory offset or LLID1. The entry stored in a memory offset provides the next memory offset or LLID to check for polling eligibility. For example, inFIG. 3, entry310of memory offset1indicates that the next memory Offset or LLID to check for polling eligibility is 6. Thus, for example, DBA polling module206will check LLID1, then LLID6, then LLID7, then LLID3, and so on.

In an embodiment, a polling cycle terminates when an entry of pre-determined value (e.g., 2049) is read. After a polling cycle is complete, DBA polling module206determines whether software updates require that a switch to the unused section be made. If yes, then DBA polling module206switches to the other section by using the other head pointer. In an embodiment, after switching to upper section304, the MSB (most significant bit) of the entry read from the RAM is inverted to determine the next memory offset. For example, referring toFIG. 3, when the table entry associated with RAM address256(containing the value 6) is read, the entry's MSB is inverted to result in next memory offset262.

FIG. 4illustrates an example scheduler module400according to an embodiment of the present disclosure. Example scheduler module400is provided for the purpose of illustration and is not limiting of embodiments. Example scheduler module400may be an embodiment of scheduler module210described above inFIG. 2.

As shown inFIG. 4, example scheduler module400includes a linked list controller (LLC)402and a linked list RAM404. LLC controls RAM404to ensure that entries (links) for same ONU LLIDs are linked in the list. This allows for same ONU LLIDs, which are within their respective service levels, to be granted consecutive time slots for upstream transmission.

In an embodiment, LLC402maintains the list in RAM404up-to-date by cycling through the links in the list, adding or removing links based on shaping profiles and queue status changes of LLIDs (empty to non-empty and non-empty to empty). A shaping profile for a particular LLID is a profile that ensures that upstream traffic from LLIDs is shaped in conformance with a service level agreement (SLA) associated with the LLID.

In an embodiment, LLC402performs the following types of updates on the linked list of RAM404: a) adding a link for a given LLID when the LLID queue changes from empty to non-empty; b) adding a link for a given LLID when the LLID is within a range for service based on its shaping profile; c) removing a link for a given LLID when the LLID queue changes from non-empty to empty; d) removing a link for a given LLID when the LLID is no longer within a range of service based on its shaping profile; and e) removing a link for a given LLID based on a processor command.

FIG. 5illustrates an example linked list entry (link)500according to an embodiment of the present disclosure. Example linked list entry500is provided for the purpose of illustration only and is not limiting of embodiments. Example linked list entry500may be an entry of linked list RAM404. As described above, each entry in the linked list corresponds to a particular LLID.

As shown inFIG. 5, example linked list entry500includes a next element field502, a port field504, a link field506, a shaper field508, and an enable field510. Next element field502indicates the next element in the list checked by LLC402after the current element associated with entry500. In an embodiment, as further described below, LLC402uses the next element field502to ensure that same ONU LLIDs are linked together whenever the linked list is updated.

Port field504indicates a port number for the LLID that corresponds to entry500. Link field506indicates a link number for the LLID that corresponds to entry500. In an embodiment, the scheduler module maintains a one-to-one mapping between link numbers and LLIDs. Shaper field508is a one-bit field that indicates whether the link is within its range of service. In an embodiment, the scheduler module supports a separate background process that performs this check for all links in the list and that updates the shaper field508of each entry accordingly. Enable field510is a one-bit field that indicates whether the link is active or inactive. An inactive link is not checked by the scheduler as it cycles through the list. As such, enable field510provides the option for maintaining a link in the list without update by the scheduler. For example, a link that would have been removed from the list by the scheduler if checked can be disabled and thus maintained in the list.

FIG. 6illustrates an example linked list600after initialization according to an embodiment of the present disclosure. Example linked list600is provided for the purpose of illustration only and is not limiting of embodiments. In this embodiment, linked list600supports priority ordering such that links of the same priority are maintained grouped within a contiguous address space. For example, links of the lowest priority level (e.g., priority 0) are grouped in the lowest address spaces and links of the highest priority level (e.g., priority 7) are grouped in the highest address spaces. Within each of these priority groups of links, links can be linked together in order to be scheduled consecutively for grants.

In an embodiment, in order to define the boundaries between priority levels, a set of top pointers are provided to define the start addresses of priority levels. For example, priority level 0 starts at address 0. Initially after reset, as shown inFIG. 6, linked list600is empty and all of the top pointers point at a NULL location in the list (the NULL location does not represent a real location in the physical RAM). This initial condition means that all elements are in priority level 0 after initialization.

Subsequently, the top pointers are provisioned by software such that there are enough elements in each priority level to accommodate all services on the EPON for each ONU. Once the linked list is configured and ready for service, links are enabled to allow LLC402to begin linking/unlinking elements in the list as appropriate. In an embodiment, LLC402maintains two pointers for enabling linking/unlinking in the list. The pointers includes a previous element pointer, which points to the last non-NULL element encountered in the list, and a current element pointer, which points to the current element selected for update.FIGS. 7 and 8, described below, illustrates the linking and unlinking of elements using these two pointers.

FIG. 7is an example700that illustrates a linking of elements in an example linked list according to an embodiment of the present disclosure. Example700is provided for the purpose of illustration and is not limiting. In example700, the current element being updated (linked) is element D, which is pointed to by current element pointer (cur_el)704. Element D may be an element that was previously added to the list or that has just been added to the list. The previous element pointer (prev_el)702points to element B. Element B may be an element associated with the same ONU as element D such that linking element D to element B results in grants to LLIDs associated with elements B and D being provided consecutively by the OLT.

Before the update, a next element field706of element B contains the current element (G) linked to element B, and a next element field708of element D contains a NULL character, which indicates the presence of no next element. To link element D to element B, LLC402first writes the value contained in next element field706of element B into next element field708of element D. Then, LLC402writes the value of current element pointer704into next element field706of element B. As a result of the linking, element B now points to element D, which in turn points to element G (which was previously pointed to by element B).

FIG. 8is an example800that illustrates an unlinking of elements in an example linked list according to an embodiment of the present disclosure. Example800is provided for the purpose of illustration and is not limiting. In example800, the current element being updated is element G, which is pointed to by current element pointer (cur_el)804. The previous element pointer (prev_el)802points to element B.

As shown inFIG. 8, before the update, element G is linked to element B by figuring in next element field806of element B. A next element field808of element G points to element H. To unlink element G from element B, LLC402writes the value contained in next element field808of element G into next element field806of element B, and then sets the value of next element field808of element G to a NULL character. As a result of the unlinking, element B now points to element H, which was previously pointed to by element G. Element G has been unlinked and has no next element to point to.

FIG. 9is a flowchart of an example process900according to an embodiment of the present disclosure. Example process900is provided for the purpose of illustration only and is not limiting of embodiments. Process900may be performed by an OLT, such as OLT200, for example.

As shown inFIG. 9, process900begins in step902, which includes maintaining an ordering of LLIDs, wherein the ordering groups together LLIDs associated with a same ONU. In an embodiment, step902includes maintaining a list of LLIDs, wherein the LLIDs associated with the same ONU are linked together in the list of LLIDs. For example, the list may be similar to linked list300described above inFIG. 3or linked list404described above inFIGS. 4-8. As such, step902may be performed by a scheduler module, such as scheduler module210, a polling module, such as DBA polling module206, a TDM module, such as DBA TDM module208, or a processor, such as embedded processor214.

Subsequently, in step904, process900includes calculating grant sizes for grants for upstream transmission based on the ordering. Specifically, step904includes accounting for the back-to-back scheduling and/or overlap of upstream transmission slots to be granted to same ONU LLIDs based on the ordering.

In an embodiment, step904is preceded or followed by a step of processing the list of LLIDs, where the processing includes processing the LLIDs associated with the same ONU consecutively. For example, in an embodiment, the list of LLIDs may be a service list, and the processing may include checking the LLIDs associated with the same ONU consecutively for service eligibility. In another embodiment, the list may be a polling status list, and the processing may include checking the LLIDs associated with the same ONU consecutively for polling eligibility. As such, the transmitted grants may include grants to the same ONU for consecutive upstream transmission time slots.

Subsequently, in step906, process900includes sending grants for upstream transmission in accordance with the ordering. In an embodiment, step906is performed by a MAC module, such as MAC216. Accordingly, step906may further include placing the grants in respective MPCP GATE messages and transmitting the GATE messages onto the network.

Process900terminates in step908, which includes receiving data transmissions from the LLIDs associated with the same ONU in consecutive time slots. In another embodiment, step908, alternatively or additionally, includes receiving MPCP REPORT messages from the LLIDs associated with the same ONU in consecutive time slots. As such, process900reduces EPON overhead by reducing the need to switch among ONUs serviced by the OLT.

In an embodiment, the data transmissions from the LLIDs include a Forward Error Correction (FEC) encoded block that combines data from multiple LLIDs. Accordingly, overhead due to FEC block encoding requirements of 10 G EPON can be reduced.

FIG. 10is a flowchart of an example process1000according to an embodiment of the present disclosure. Example process1000is provided for the purpose of illustration only and is not limiting of embodiments. Example process1000may be performed by an ONU, including a CMC, for example.

As shown inFIG. 10, process1000begins in step1002, which includes receiving a plurality of upstream transmission grants for consecutive time slots from an OLT, the plurality of upstream transmission grants intended for a respective group of LLIDs of a plurality of LLIDs assigned to the ONU.

In step1004, process1000includes grouping data from queues associated with the group of LLIDs to form a block of data. In an embodiment, the data is grouped from queues having fill levels that are not aligned to the block size for FEC block encoding. Subsequently, step1006includes applying FEC encoding to the block of data to generate a FEC block across the misaligned data between the grants. Process1000terminates in step1008, which includes transmitting the FEC block to the OLT.

The breadth and scope of embodiments of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.