| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Frank,
It was this kind of argument that caused the GPON solution for 28 dB B+ budget to use the wording that the requirement is that the FEC bytes be transmitted.
In my understanding, the vast majority of the gates involved in FEC are in the decoder. The gates needed at the transmit end to insert the FEC bytes are much more modest. In this case the builder of the ONU can decide what technology to use to meet the BER requirement at the specified power level. If he wants to use a FEC decoder and a less sensitive receiver, he can because he knows that the FEC bytes will be there. If he thinks that it is more cost / power effective to use a more sensitive receiver without FEC then he can simply ignore the FEC bytes.
Of course there is some reduction of efficiency due to transmitting FEC bytes anyway, but this may not be too serious.
Regards,
Nortel Networks UK Limited, London Rd, Harlow, Essex CM17 9NA, UK
External +44 1279 402540 ESN 742 2540
Fax +44 1279 402543
_____________________________________________
From: Frank Chang [mailto:ychang@VITESSE.COM]
Sent: 09 February 2007 09:14
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] [FEC] Mandatory or Optional (was [FEC Superating] - kickoff preso)
Glen;
Its very nice to have Thomas chime in from transceiver vendor perspective. This reiterates the argument brought up during Monterey meeting.
Its understandable MAC sub-rating simplify the optics and confg if FEC is always on (mandatory). But in contrast to optional, its downside is to pay the expense/complex of FEC circuitry when its gain isnot needed. Take G.975 7% RS code as example, this means at least extra 3-5W power dissipation (depending on the number of gates and process), the cost of IC itself, the PCB complex/size and time to market etc etc.
I think this is where the group better draw attention to mitigate the impact if MAC sub-rating tends preferred.
Regards
Frank C.
-----Original Message-----
From: Glen Kramer [mailto:glen.kramer@teknovus.com]
Sent: Thursday, February 08, 2007 4:20 PM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] [FEC] Mandatory or Optional (was [FEC Superating] - kickoff preso)
Thomas,
Thank you for the good analysis of penalty associated with line rate increase. I am as well leaning to keep PHY rate as it is, and slow down the MAC (as is done in Ethernet in the past many times).
The following your question is somewhat different though, so I started a new thread under the [FEC] tag.
> Finally in response to your point that if the FEC is mandatory, that
> another approach could be taken, why does the FEC have to be mandatory
> for this?
> For optional FEC couldn't one do the following (again stated from a
> FEC/PCS ignorant point of view). When FEC is turned on both
PCS(64B/66B,
> scrambling or other) and FEC are combined to deliver smaller combined
> overhead. When FEC function is turned of only PCS coding is enabled.
I should clarify that no final decision has been made by the task force yet on whether FEC should be mandatory of optional, though a straw pall in Monterey has indicated a preference for mandatory usage.
Unlike 1G EPON, which used a frame-based FEC, 10G is converging on a stream-based approach. It is easier to do at high speed and with 64b/66b coding, but the downside is that non-FEC-capable (or non-FEC-enabled) devices would not understand the incoming data.
Because stream-based FEC changes format of the line data, it seems that synchronization mechanisms would be different with and without FEC.
Thus, OLT and ONUs would have to implement two Tx and two Rx paths in PCS, and enable only one at a time.
The question is how an ONU would start? Should it enable a sync machine with FEC or without FEC? Should it start at normal rate or increased rate, if super-rating is used? It maybe that all previously registered ONUs are close enough and the OLT decided to turn the FEC off. But the new ONU that tries to register is far away. How would it signal OLT to turn the FEC back on? It is also very unclear if switching FEC on and off on the fly would even be possible.
So, if we decide to make FEC optional, it probably would have to be a static configuration, where a carrier decides in advance that all devices attached to this particular EPON should be pre-configured to use or not use FEC.
As far as I understand, carriers are not particularly fond of the idea of having different configurations for different segments of their networks. There is always a concern that an ONU with a wrong configuration would be attached to a wrong EPON, etc. Also, monitoring equipment and protocol analyzers need to be aware of what signal format to look for.
I think that in reality, a carrier would keep the same configuration for all EPONs, and if any of the ODNs require FEC, it will enable FEC for all of them anyway. (Carriers - please comment.)
10GEPON leads to 1000% bandwidth increase compared to 1G EPON. I don't think it would be such a detrimental thing for the adoption of the technology if the bandwidth will increase "only" 930% due to always-on FEC. On the other hand, it would make devices simpler (as well as cheaper and probably consuming less power) as only one Rx and Tx path will need to be implemented, and it will simplify configuration.
In other words, I see 10GEPON FEC as part of a new line coding, not as a separate option. 1G uses 8b/10b with 20% overhead + separately 9% FEC overhead. The new line coding in 10G EPON uses 10% (3%+7%) and includes FEC.
Glen
------------------------------------------------------------------------
--
DISCLAIMER: This e-mail expresses my views as an individual contributor to the task force, not as task force chair.
------------------------------------------------------------------------
--