Patent Description:
A passive optical network (PON) is one system for providing network access over "the last mile. " The PON is a point to multi-point network comprised of an optical line terminal (OLT) at the central office, an optical distribution network (ODN), and a plurality of optical network units (ONUs) at the customer premises. In some PON systems, such as Gigabit PON (GPON) systems, downstream data is broadcasted at about <NUM> Gigabits per second (Gbps) while upstream data is transmitted at about <NUM> Gbps. However, the bandwidth capability of the PON systems is expected to increase as the demands for services increase. To meet the increased demand in services, some emerging PON systems, such as Next Generation Access (NGA) systems, are being reconfigured to transport the data frames with improved reliability and efficiency at higher bandwidths, for example at about ten Gbps. <CIT> relates to an apparatus to an apparatus comprising a data framer configured to frame a data stream into a plurality of frames each comprising a plurality of fields sized to align the frames with a word boundary greater than or equal to about to the data framer and configured to transmit the frames. Included is an apparatus comprising at least one component configured to implement a method comprising encapsulating a data stream with at least one Gigabit Passive Optical Network (GPON) Encapsulation method (GEM) payload aligned with a word boundary at least about four bytes long, encapsulating the GEM payload with a GPON Transmission Convergence (GTC) frame aligned with the word boundary, and transmitting the GTC frame.

<CIT> relates to a method for encapsulating variable length packets, and related packet encapsulator and decapsulator. Variable length data packets are encapsulated by adding an Asynchronous Transfer Mode (ATM) compatible, five octet long packet header (PACKET-HDR) to each data packet. The fifth octet of this packet header constitutes a header error check field (HEC).

In one embodiment, the disclosure includes an apparatus comprising an OLT configured to couple to a plurality of ONUs and transmit a plurality of downstream frames to the ONUs, wherein each of the downstream frames comprises a plurality of forward error correction (FEC) codewords and a plurality of additional non-FEC encoded bytes that comprise synchronization information that is protected by Header Error Control (HEC) code as specified in the appendend claims.

The disclosure includes an apparatus comprising a processing unit configured to arrange control data, user data, or both into a plurality of FEC codewords in a downstream frame and arrange a physical synchronization sequence (PSync), a superframe structure, and a Passive Optical Network-identifier (PON-ID) structure in a plurality of additional non-FEC encoded bytes in the downstream frame, and a transmission unit configured to transmit the FEC codewords and the additional non-FEC encoded bytes in the downstream frame within a <NUM> microsecond window.

The disclosure includes a method comprising implementing, at an ONU, a synchronization state machine that comprises a Hunt State, a Pre-Sync State, and a Sync State for a plurality of downstream frames, wherein each of the downstream frames comprises a physical synchronization block (PSBd) comprising a Physical synchronization (PSync) pattern, a superframe structure, and a PON-ID structure, wherein the superframe structure comprises a superframe counter and a first HEC protecting the superframe structure, and wherein the PON-ID structure comprises a PON-ID and a second HEC protecting the PON-ID structure.

In PON systems, errors in a plurality of frames may be corrected using a FEC scheme. According to the FEC scheme, the transmitted frames may comprise a plurality of FEC codewords, which may comprise a plurality of data blocks and parity blocks. Each quantity of blocks that correspond to an FEC codeword may then be aligned or "locked" using a "state machine," e.g. in a buffer, framer, or memory location at an ONU or OLT. The FEC codeword may be locked after detecting one by one its data blocks and parity blocks and verifying that the blocks' sequence matches the expected block sequence of an FEC codeword. Otherwise, when a block is detected as out of sequence, the process may be restarted at the second block in the block's sequence to detect and lock the correct block sequence.

Disclosed herein is a system and method for supporting transmission synchronization and error detection/correction in PON systems, such as <NUM> Gigabit PONs (XGPONs). The system and method uses a framing mechanism that supports the FEC scheme and provides transmission synchronization in the PON. The frames may be transmitted within a plurality of transmission windows, e.g. about <NUM> microseconds time periods, where each transmission window may comprise an integer multiple of FEC codewords for error detection/correction. The transmission window may also comprise additional or extra bytes that may be used for transmission synchronization. The extra bytes may comprise frame synchronization and/or time synchronization and may not be FEC encoded (e.g. not protected by FEC), and therefore may not be handled by the FEC scheme. Instead, the extra bytes may also comprise HEC encoding, which may provide error detection/correction for the synchronization information in the frames.

<FIG> illustrates one embodiment of a PON <NUM>. The PON <NUM> comprises an OLT <NUM>, a plurality of ONUs <NUM>, and an ODN <NUM>, which may be coupled to the OLT <NUM> and the ONUs <NUM>. The PON <NUM> may be a communications network that does not require any active components to distribute data between the OLT <NUM> and the ONUs <NUM>. Instead, the PON <NUM> may use the passive optical components in the ODN <NUM> to distribute data between the OLT <NUM> and the ONUs <NUM>. The PON <NUM> may be NGA systems, such as ten Gigabit GPONs (or XGPONs), which may have a downstream bandwidth of about ten Gbps and an upstream bandwidth of at least about <NUM> Gbps. Other examples of suitable PONs <NUM> include the asynchronous transfer mode PON (APON) and the broadband PON (BPON) defined by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) G. <NUM> standard, the GPON defined by the ITU-T G. <NUM> standard, the Ethernet PON (EPON) defined by the Institute of Electrical and Electronics Engineers (IEEE) <NUM>. 3ah standard, the <NUM> Gigabit EPON as described in the IEEE <NUM>. 3av standard, and the Wavelength Division Multiplexed (WDM) PON (WPON), all of which are incorporated herein by reference as if reproduced in their entirety.

In an embodiment, the OLT <NUM> may be any device that is configured to communicate with the ONUs <NUM> and another network (not shown). Specifically, the OLT <NUM> may act as an intermediary between the other network and the ONUs <NUM>. For instance, the OLT <NUM> may forward data received from the network to the ONUs <NUM>, and forward data received from the ONUs <NUM> onto the other network. Although the specific configuration of the OLT <NUM> may vary depending on the type of PON <NUM>, in an embodiment, the OLT <NUM> may comprise a transmitter and a receiver. When the other network is using a network protocol, such as Ethernet or Synchronous Optical Networking (SONET)/Synchronous Digital Hierarchy (SDH), that is different from the PON protocol used in the PON <NUM>, the OLT <NUM> may comprise a converter that converts the network protocol into the PON protocol. The OLT <NUM> converter may also convert the PON protocol into the network protocol. The OLT <NUM> may be typically located at a central location, such as a central office, but may be located at other locations as well.

In an embodiment, the ONUs <NUM> may be any devices that are configured to communicate with the OLT <NUM> and a customer or user (not shown). Specifically, the ONUs <NUM> may act as an intermediary between the OLT <NUM> and the customer. For instance, the ONUs <NUM> may forward data received from the OLT <NUM> to the customer, and forward data received from the customer onto the OLT <NUM>. Although the specific configuration of the ONUs <NUM> may vary depending on the type of PON <NUM>, in an embodiment, the ONUs <NUM> may comprise an optical transmitter configured to send optical signals to the OLT <NUM> and an optical receiver configured to receive optical signals from the OLT <NUM>. Additionally, the ONUs <NUM> may comprise a converter that converts the optical signal into electrical signals for the customer, such as signals in the Ethernet protocol, and a second transmitter and/or receiver that may send and/or receive the electrical signals to a customer device. In some embodiments, ONUs <NUM> and optical network terminals (ONTs) are similar, and thus the terms are used interchangeably herein. The ONUs may be typically located at distributed locations, such as the customer premises, but may be located at other locations as well.

In an embodiment, the ODN <NUM> may be a data distribution system, which may comprise optical fiber cables, couplers, splitters, distributors, and/or other equipment. In an embodiment, the optical fiber cables, couplers, splitters, distributors, and/or other equipment may be passive optical components. Specifically, the optical fiber cables, couplers, splitters, distributors, and/or other equipment may be components that do not require any power to distribute data signals between the OLT <NUM> and the ONUs <NUM>. Alternatively, the ODN <NUM> may comprise one or a plurality of processing equipment, such as optical amplifiers. The ODN <NUM> may typically extend from the OLT <NUM> to the ONUs <NUM> in a branching configuration as shown in <FIG>, but may be alternatively configured in any other point-to-multi-point configuration.

In an embodiment, the OLT <NUM>, the ONUs <NUM>, or both may be configured to implement an FEC scheme to control or reduce transmission errors. As part of the FEC scheme, the data may be combined with an error correction code, which may comprise redundant data, before being transmitted. For instance, the data and the error correction code may be encapsulated or framed into a FEC codeword, which may be received and decoded by another PON component. In some embodiments, the FEC codeword may comprise the error correction code and may be transmitted with the data without modifying the data bits. When the error correction code is received, at least some of the errors in the transmitted data, such as bit errors, may be detected and corrected without the need to transmit additional data. Transmitting the error correction code in addition to the data may consume at least some of the channel bandwidth, and hence may reduce the bandwidth available for data. However, the FEC scheme may be used for error detection instead of a dedicated back-channel to reduce the error detection scheme complexity, cost, or both.

The FEC scheme may comprise a state machine model, which may be used to lock an FEC codeword, e.g. determine if a plurality of received blocks that represent the FEC codeword are aligned appropriately or in a correct sequence. Locking the FEC codeword or verifying the FEC blocks' alignment may be necessary to obtain the data and the error correction code correctly. For instance, the OLT <NUM>, the ONUs <NUM>, or both may comprise an FEC processor, which may be hardware, such as a circuit, or software that implements the state machine model. The FEC processor may be coupled to the corresponding receivers and/or deframers at the OLT <NUM> or the ONUs <NUM>, and may use analog-to-digital conversion, modulation and demodulation, line coding and decoding, or combinations thereof. The FEC codeword comprising the received blocks may also be locked at a memory location or buffer coupled to the FEC processor and the receiver.

Typically, downstream data in PON systems may be transmitted in a plurality of GPON Transmission Container (GTC) frames, e.g. at a GTC layer, within a plurality of corresponding fixed time windows, e.g. of about <NUM> microseconds. A GTC frame may comprise a downstream Physical Control Block (PCBd) and a GTC payload (e.g. user data) that may not comprise time or time of day (ToD) information. However, to establish PON transmissions synchronization, ToD information or any other synchronization information may be needed in the transmitted frames. In an embodiment, the OLT <NUM> may be configured to transmit ToD information and/or any other synchronization information to the ONU(s) <NUM>, for instance in a downstream frame in a corresponding transmission window. The downstream frame may also support the FEC scheme for error detection and correction. Accordingly, the transmission window may comprise FEC code words, which may comprise data and error correction code, and time or ToD information. Specifically, the transmission window may comprise an integer multiple of FEC codewords and a plurality of extra or additional bytes that may not be FEC encoded, and therefore may not be handled or protected from errors using the FEC scheme. The additional or extra bytes may be used to provide time (e.g. ToD) and/or synchronization information for PON transmissions and may also comprise HEC encoding that may be used to detect and/or correct any errors in the synchronization data.

For instance, the OLT <NUM> may transmit downstream data in a plurality of XGPON Transmission Container (XGTC) frames within a corresponding time window of about <NUM> microseconds or any fixed length time window. The XGTC frame (and the corresponding time window) may comprise a payload that comprises the FEC codewords, for example about <NUM> FEC codewords using Reed Solomon (RS) (<NUM>,x) FEC encoding (e.g. x is equal to about <NUM> or about <NUM>). Additionally, the XGTC frame (and the corresponding time window) may comprise additional bytes (e.g. in the PCBd), e.g. about <NUM> bytes, that comprise synchronization and/or time synchronization data and HEC encoding, as described in detail below.

<FIG> illustrates an embodiment of a frame <NUM>, which may comprise FEC encoded control and/or user data and non-FEC encoded synchronization information. For instance, the frame <NUM> may correspond to a GTC or XGTC frame, e.g. downstream from the OLT <NUM> to an ONU <NUM>, and may be transmitted within a fixed time window. The frame <NUM> may comprise a first portion <NUM> and a second portion <NUM>. The first portion <NUM> may correspond to a GTC or XGTC PCBd or header and may comprise time or synchronization information, such as a PSync pattern, a ToD, other time and/or frame synchronization information or combinations thereof. Specifically, the time or synchronization information may not be FEC encoded and may be associated with HEC encoding in the first portion <NUM>, which may be used to detect/correct a plurality of bit errors that may occur in the first portion <NUM>. The first portion <NUM> is described in more detail below. In an embodiment, the frame <NUM> may correspond to a GTC or XGTC frame that is encoded using RS (<NUM>,x), and thus the first portion <NUM> may comprise about <NUM> bytes. Although, the first portion <NUM> precedes the second portion <NUM> in <FIG>, in other embodiments, the first portion <NUM> may be located in other locations of the frame <NUM>, such as subsequent to the second portion <NUM>.

The second portion <NUM> may correspond to a GTC or XGTC payload and may comprise a plurality of codewords that may be FEC encoded. For instance, the second portion <NUM> may comprise an integer multiple of FEC codewords. The GTC or XGTC payload may comprise a Payload Length downstream (Plend) <NUM>, an Upstream Bandwidth map (US BWmap) <NUM>, at least one Physical Layer Operations, an Administration and Maintenance (PLOAM) field <NUM>, and a payload <NUM>. The Plend <NUM> may comprise a plurality of subfields, including a B length (Blen) and a cyclic redundancy check (CRC). The Blen may indicate the length of the US BWmap <NUM>, e.g. in bytes. The CRC may be used to verify the presence of errors in the received frame <NUM>, e.g. at the ONU <NUM>. For instance, the frame <NUM> may be discarded when the CRC fails. In some PON systems that support asynchronous transfer mode (ATM) communications, the subfields may also include an A length (Alen) subfield that indicates the length of an ATM payload, which may comprise a portion of the frame <NUM>. The US BWmap <NUM> may comprise an array of blocks or subfields, each of which may comprise a single bandwidth allocation to an individual Transmission Container (TC), which may be used for managing upstream bandwidth allocation in the GTC layer. The TC may be a transport entity in the GTC layer that may be configured to transfer higher-layer information from an input to an output, e.g., from the OLT to the ONU. Each block in the BWmap <NUM> may comprise a plurality of subfields, such as an Allocation identifier (Alloc-ID), a Flags, a Start Time (SStart), a Stop Time (SStop), a CRC, or combinations thereof.

The PLOAM fields <NUM> may comprise a PLOAM message, which may be sent from the OLT to the ONU and include Operations, Administration and Maintenance (OAM) related alarms or threshold-crossing alerts triggered by system events. The PLOAM field <NUM> may comprise a plurality of sub-fields, such as an ONU identifier (ONU-ID), a message identifier (Message-ID), a message data, and a CRC. The ONU-ID may comprise an address, which may be assigned to one of the ONUs and may be used by that ONU to detect its intended message. The Message-ID may indicate the type of the PLOAM message and the message data may comprise the payload of the PLOAM message. The CRC may be used to verify the presence of errors in the received PLOAM message. For instance, the PLOAM message may be discarded when the CRC fails. The frame <NUM> may comprise different PLOAMs <NUM> that correspond to different ONUs, which may be indicated by different ONU-IDs. The payload <NUM> may comprise broadcast data (e.g. user data). For instance, the payload <NUM> may comprise a GPON Encapsulation Method (GEM) payload. <FIG> illustrates an embodiment of a frame portion <NUM> that may comprise non-FEC encoded synchronization information, such as in a downstream GTC or XGTC frame. For instance, the frame portion <NUM> may correspond to the first portion <NUM> of the frame <NUM>. The frame portion <NUM> may comprise a PSync field <NUM>, a ToD in seconds (ToD-Sec) field <NUM>, and a ToD in nanoseconds (ToD-Nanosec) field <NUM>. In an embodiment, the frame portion <NUM> may comprise about <NUM> bytes, where each of the PSync field <NUM>, the ToD-Sec field <NUM>, and the ToD in nanoseconds field <NUM> may comprise about eight bytes. Further, each of the PSync field <NUM>, the ToD-Sec field <NUM>, and the ToD-Nanosec field <NUM> may comprise HEC encoding that may be used to detect/correct errors in the corresponding field. The PSync field <NUM> may comprise a PSync pattern <NUM> and a HEC field <NUM>. The PSync pattern <NUM> may be used at an ONU, for instance at a data framer coupled to a receiver, to detect the beginning of the downstream frame portion <NUM> (or the frame <NUM>) and establish synchronization accordingly. For example, the PSync pattern <NUM> may correspond to a fixed pattern that may not be scrambled. The HEC field <NUM> may provide error detection and correction for the PSync field <NUM>. For example, the HEC <NUM> may comprise a plurality of bits that correspond to a Bose and Ray-Chaudhuri (BCH) code with a generator polynomial and a single parity bit. In an embodiment, the PSync pattern <NUM> may comprise about <NUM> bits and the HEC field <NUM> may comprise about <NUM> bits.

The ToD-Sec field <NUM> may comprise a Seconds field <NUM>, a Reserved (Rev) field <NUM>, and a second HEC field <NUM>. The Seconds field <NUM> may comprise an integer portion of the ToD associated with the frame in units of seconds, and the Reserved field <NUM> may be reserved or may not be used. The second HEC <NUM> may be configured substantially similar to the HEC <NUM> and may provide error detection and correction for the ToD-Sec field <NUM>. In an embodiment, the Seconds field <NUM> may comprise about <NUM> bits, the Reserved field <NUM> may comprise about three bits, and the second HEC field <NUM> may comprise about <NUM> bits.

The ToD-Nanosec field <NUM> may comprise a Nanoseconds field <NUM>, a second Reserved (Rev) field <NUM>, and a third HEC field <NUM>. The Nanoseconds field <NUM> may comprise a fractional portion of the ToD associated with the frame in units of nanoseconds, and the second Reserved field <NUM> may be reserved or may not be used. The third HEC <NUM> may be configured substantially similar to the HEC <NUM> and may provide error detection and correction for the ToD-Nanosec field <NUM>. In an embodiment, the Nanoseconds field <NUM> may comprise about <NUM> bits, the second Reserved field <NUM> may comprise about <NUM> bits, and the third HEC field <NUM> may comprise about <NUM> bits.

<FIG> illustrates another embodiment of a frame portion <NUM> that may comprise non-FEC encoded synchronization information. For instance, the frame portion <NUM> may correspond to a PSBd in a downstream GTC or XGTC frame. The PSBd <NUM> may comprise a PSync pattern <NUM>, a superframe structure <NUM>, and a PON-ID structure <NUM>. In an embodiment, the frame portion <NUM> or PSBd may comprise about <NUM> bytes, where each of the PSync pattern <NUM>, the superframe structure <NUM>, and the PON-ID structure <NUM> may comprise about eight bytes. Further, each of the superframe structure <NUM> and the PON-ID structure <NUM> may comprise HEC encoding that may be used to detect/correct errors in the corresponding field.

The PSync pattern <NUM> may be used to detect the beginning of the PSBd in the frame and may comprise about <NUM> bits. The PSync pattern <NUM> may be used by the ONU to align the frame at the downstream frame boundary. The PSync pattern <NUM> may comprise a fixed pattern, such as 0xC5E5 <NUM> FD59 BB49. The superframe structure <NUM> may comprise a superframe counter <NUM> and a HEC code <NUM>. The superframe counter <NUM> may correspond to the most significant about <NUM> bits of the superframe structure <NUM> and may specify a sequence of transmitted downstream frames. For each downstream (XGTC or GTC) frame, the superframe counter <NUM> may comprise a larger value than the previous transmitted downstream frame. When the superframe counter <NUM> reaches a maximum value, a subsequent superframe counter <NUM> in a subsequent downstream frame may be set to about zero. The HEC code <NUM> may correspond to the least significant about <NUM> bits of the superframe structure <NUM> and may be configured substantially similar to the HEC fields described above. The HEC code <NUM> may be a combination of a BCH code that operates on about <NUM> initial bits of the frame header and a single parity bit.

The PON-ID structure <NUM> may comprise a PON-ID <NUM> and a second HEC code <NUM>. The PON-ID <NUM> may correspond to about <NUM> bits of the PON-ID structure <NUM> and the HEC code may correspond to the remaining about <NUM> bits. The PON-ID <NUM> may be set by the OLT and used by the ONU to detect protection switching events or for security key generation. The second HEC code <NUM> may be configured substantially similar to the HEC fields described above. Specifically, the HEC code <NUM> may be used to detect/correct errors in the superframe counter <NUM> and the second HEC code <NUM> may be used to detect/correct errors in the PON-ID <NUM>.

Since the synchronization information may be encapsulated in a plurality of extra bytes in the downstream frames that may not be FEC encoded, the HEC code may be added to the synchronization information in the extra bytes, as described in the frame portion <NUM> or the frame portion <NUM>, to provide sufficient or acceptable error detection/correction capability for the synchronization information at the ONU. This HEC encoding scheme may provide efficient error detection/correction in a plurality of cases. For instance, when the ONU is in a fast-sleeping context, the ONU may re-lock every certain time period (e.g. every about <NUM> microseconds) to the OLT. As such, multiple errors may occur in the non-FEC encoded extra bytes (e.g. about <NUM> bytes) in case of false locking. However, there may be a substantially high probability that the errors are prevented or accounted for using the HEC encoding in the extra bytes.

For example, in the case of a bit error rate (BER) of about 1e-<NUM> in the PON downstream transmission, a HEC code that comprises about <NUM> bits within a corresponding about eight bytes field in the downstream frame, such as the HEC fields described above, may be used to detect up to about three bit errors and to correct up to about two bit errors in the corresponding eight bytes field. In this case, the probability of obtaining about three bit errors in a corresponding about eight byte field after using the HEC scheme may be substantially small, e.g. equal to about <NUM> percent. The three bit errors may be detected but may not be corrected using the HEC scheme. Further, the probability of obtaining about four bit errors or more in the corresponding about eight bytes field after using the HEC scheme may be equal to about <NUM> percent. However, the chances of obtaining about two error bits or less using the HEC scheme may be substantially high, e.g. equal to about <NUM> percent. The two bit errors may be detected and corrected using the HEC scheme.

During the frame locking process, the frame may be validated efficiently with at least about two correctable PSync patterns in the received frame. For instance, the ONU may successfully lock the downstream frame if at least about two PSync patterns, such as the PSync pattern <NUM>, have been received and detected correctly, e.g. in two subsequent about eight bytes fields. The probability of detecting two consecutive PSync patterns correctly using two corresponding HEC codes, such as in the HEC field <NUM>, may be substantially high, e.g. equal to about <NUM> percent raised to the second power or about <NUM> percent (e.g. <NUM>%^<NUM> = <NUM> percent). Thus, using about <NUM> extra bytes that comprise HEC encoding, as described in <FIG>, <FIG>, and <FIG> may enable the ONU to lock the downstream frame successfully at a substantially high level of certainty (e.g. about <NUM> percent).

Further, the chance of establishing a false lock at the ONU may require detecting two subsequent PSync fields that comprise the same fixed pattern (e.g. comprise the same bit errors). Such a situation may most likely occur when there may be about four bit errors in both PSync patterns. The probability of receiving the same about four bits in two corresponding about <NUM> bits (or the about <NUM> extra bytes in the frame) may be calculated by the binomial coefficient that is one out of <NUM>*<NUM>*<NUM>*<NUM>/(<NUM>*<NUM>*<NUM>*<NUM>) or about <NUM>/<NUM>,<NUM> percent. As such, the chance of getting two false PSync patterns may be equal to about <NUM> percent raised to the second power or about 1e-<NUM> percent. Thus, the chance of establishing a false lock may be about equal to the product (<NUM>/<NUM>)x(1e-<NUM>) or about 5e-<NUM> percent, which may be negligible. In a relatively fast-sleeping context of re-locking, e.g. about every ten microseconds, this situation may correspond to one false lock occurring every about <NUM>. 7e16 seconds and may be tolerated.

<FIG> illustrates an embodiment of a synchronization state machine <NUM>, which may be used, e.g. by the ONU, to synchronize a downstream transmitted frame, such as the frame <NUM>. The synchronization state machine <NUM> may use a PSync pattern in the downstream frame that may not be FEC encoded, such as the PSync pattern <NUM> or the PSync pattern <NUM>. The PSync pattern may be located in a portion of the downstream frame, such as the PSBd, the frame portion <NUM>, or the first portion <NUM>. In some embodiments, the PSync pattern may be protected by a HEC code, such as the HEC field <NUM>.

The synchronization state machine <NUM> may be implemented by the ONU, e.g. using software, hardware, or both. The synchronization state machine <NUM> may begin at a Hunt State <NUM>, where a search for the PSync pattern in all possible alignments (e.g. bit and/or byte alignments) may be performed. If a correct PSync pattern is found, then the synchronization state machine <NUM> may transition to a Pre-Sync State <NUM>, where a search for a second PSync pattern that follows the last detected PSync pattern by a fixed time length (e.g. by about <NUM> microseconds) may be performed. If a second PSync pattern is not found successfully at the Pre-Sync State <NUM>, then the synchronization state machine <NUM> may return from the Pre-Sync State <NUM> back to the Hunt State <NUM>. If a second PSync pattern is found successfully at the Pre-Sync State <NUM>, then the synchronization state machine <NUM> may transition to a Sync State <NUM>. If the Sync State <NUM> is reached, the synchronization state machine <NUM> may declare a successful synchronization of the downstream frame, and subsequently frame processing may begin. In an embodiment, if the ONU detects M consecutive incorrect PSync fields or patterns (M is an integer), then the synchronization state machine <NUM> may declare an unsuccessful synchronization of the downstream frame and return back to the Hunt State <NUM>. For instance, M may be equal to about five.

<FIG> illustrates an embodiment of a framing method <NUM>, which may be used, e.g. by the OLT, for framing a downstream frame, such as a XGTC or GTC frame before sending the downstream frame to the ONU(s). The downstream frame may comprise control and/or user data that may be FEC encoded and synchronization and/or time data that may not be FEC encoded. However, at least some of the synchronization and/or time data may be protected in the downstream frame using HEC code. At block <NUM>, the control data, user data, or both (control/user data) may be encapsulated into an integer multiple of FEC codewords in the downstream frame. For instance, the control/user data may be converted in to a plurality of FEC codewords that may be located in the XGTC or GTC payload portion. For example, the control/user data may comprise the Plend, a plurality of PLOAM fields or messages, user payload, or combinations thereof.

At block <NUM>, the synchronization/time data and the corresponding HEC code may be encapsulated in a plurality of remaining bytes without FEC encoding in the downstream frame. For instance, the synchronization data may be located in the XGTC or GTC PCBd or PSBd portion. The synchronization/time data may comprise a plurality of synchronization elements, such as a PSync pattern, a ToD, a PON ID, or combinations thereof. The synchronization/time data may also comprise a corresponding HEC code or field for at least some of the synchronization/time elements, such as the ToD, the PON ID, and/or the PSync pattern. At block <NUM>, the FEC codewords that comprise the control/user data and the remaining bytes that comprise the synchronization/time data and corresponding HEC code may be transmitted, e.g. to the ONU(s), in the downstream frame. The method <NUM> may then end.

<FIG> illustrates an embodiment of an apparatus <NUM> that may be configured to implement the PON framing method <NUM>. The apparatus may comprise a processing unit <NUM> and a transmission unit <NUM> that may be configured to implement the method <NUM>. For example, the processing unit <NUM> and the transmission unit <NUM> may correspond to hardware, firmware, and/or software installed to run hardware. The processing unit <NUM> may be configured to arrange control data, user data, or both into a plurality of FEC codewords in a downstream frame and arrange synchronization information in a plurality of additional non-FEC encoded bytes in the downstream frame, such as described in steps <NUM> and <NUM> above. The synchronization information may comprise the PSync field <NUM>, the ToD-Sec field <NUM>, and the ToD-Nanosec field <NUM>. Alternatively, the synchronization information may comprise the PSync pattern <NUM>, the superframe structure <NUM>, and the PON-ID structure <NUM>. The processing unit <NUM> may then forward the FEC codewords and the additional non-FEC encoded bytes to the transmission unit <NUM>. The transmission unit <NUM> may be configured to transmit the FEC codewords and the additional non-FEC encoded bytes in the downstream frame within a fixed time window, e.g. at about <NUM> microseconds. In other embodiments, the processing unit <NUM> and the transmission unit <NUM> may be combined into a single component or may comprise a plurality of subcomponents that may implement the method <NUM>.

The network components described above may be implemented on any general-purpose network component, such as a computer or network component with sufficient processing power, memory resources, and network throughput capability to handle the necessary workload placed upon it. <FIG> illustrates a typical, general-purpose network component <NUM> suitable for implementing one or more embodiments of the components disclosed herein. The network component <NUM> includes a processor <NUM> (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage <NUM>, read only memory (ROM) <NUM>, random access memory (RAM) <NUM>, input/output (I/O) devices <NUM>, and network connectivity devices <NUM>. The processor <NUM> may be implemented as one or more CPU chips, or may be part of one or more application specific integrated circuits (ASICs).

The secondary storage <NUM> is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM <NUM> is not large enough to hold all working data. Secondary storage <NUM> may be used to store programs that are loaded into RAM <NUM> when such programs are selected for execution. The ROM <NUM> is used to store instructions and perhaps data that are read during program execution. ROM <NUM> is a non-volatile memory device that typically has a small memory capacity relative to the larger memory capacity of secondary storage <NUM>. The RAM <NUM> is used to store volatile data and perhaps to store instructions. Access to both ROM <NUM> and RAM <NUM> is typically faster than to secondary storage <NUM>.

At least one embodiment is disclosed and variations, combinations, and/or modifications of the embodiment(s) and/or features of the embodiment(s) made by a person having ordinary skill in the art are within the scope of the disclosure. Alternative embodiments that result from combining, integrating, and/or omitting features of the embodiment(s) are also within the scope of the disclosure. Where numerical ranges or limitations are expressly stated, such express ranges or limitations should be understood to include iterative ranges or limitations of like magnitude falling within the expressly stated ranges or limitations (e.g., from about <NUM> to about <NUM> includes, <NUM>, <NUM>, <NUM>, etc.; greater than <NUM> includes <NUM>, <NUM>, <NUM>, etc.). For example, whenever a numerical range with a lower limit, Rl, and an upper limit, Ru, is disclosed, any number falling within the range is specifically disclosed. In particular, the following numbers within the range are specifically disclosed: R = Rl + k * (Ru - Rl), wherein k is a variable ranging from <NUM> percent to <NUM> percent with a <NUM> percent increment, i.e., k is <NUM> percent, <NUM> percent, <NUM> percent, <NUM> percent, <NUM> percent,. , <NUM> percent, <NUM> percent, <NUM> percent,. , <NUM> percent, <NUM> percent, <NUM> percent, <NUM> percent, <NUM> percent, or <NUM> percent. Moreover, any numerical range defined by two R numbers as defined in the above is also specifically disclosed. Use of the term "optionally" with respect to any element of a claim means that the element is required, or alternatively, the element is not required, both alternatives being within the scope of the claim. Use of broader terms such as comprises, includes, and having should be understood to provide support for narrower terms such as consisting of, consisting essentially of, and comprised substantially of. Accordingly, the scope of protection is not limited by the description set out above but is defined by the claims that follow, that scope including all equivalents of the subject matter of the claims. Each and every claim is incorporated as further disclosure into the specification and the claims are embodiment(s) of the present disclosure.

Claim 1:
A method comprising:
receiving, by an optical network unit, ONU, (<NUM>) a plurality of downstream frames from an optical line terminal, OLT, (<NUM>),
wherein each of the downstream frames comprises a plurality of forward error correction, FEC, codewords and a plurality of additional bytes;
the plurality of additional bytes comprising physical synchronization sequence, Psync, and at least one header error control, HEC, code;
the HEC code is configured to protect at least some data for synchronization, and the FEC codewords are encoded using a Reed Solomon, RS, (<NUM>,x) FEC encoding, where x is equal to <NUM> or <NUM>.