Re: [802.3_EPOC] Continuing work on EPOC objectives
Thanks, Hugh! That is by far the best explanation that I've heard of the
reasoning behind the BER.
Based on this explanation, I went looking through more 802.3 archives and
found a submission given in July 2002 to the EPON TF. In this
presentation, a calculation was given for Mean Time to False Packet
Acceptance for 1G EPON using FEC. The conclusions there (I am glossing
over a lot of details) was that 10^-12 BER would give a MTTFPA of 4*10^16
years.
Making a similar calculation for 10^-10 gives an MTTFPA something on the
order of 10^14 years. Someone should double check my calculations, though.
Another concern that I've heard is how a BER-domain of 10^-10 (EPOC) would
interoperate with a BER-domain of 10^-12 (EPON). My analysis is that (in
the worst case) the overall network would operate at 10^-10 BER. At the
packet-error rate we've calculated, though, this shouldn't be a problem.
Someone that knows the technical in's and out's better than I do should
correct anything that I've miscalculated or misstated.
Thanks!
--kan--
--
Kevin A. Noll
-----Original Message-----
From: "Hugh Barrass (hbarrass)" <hbarrass@xxxxxxxxx>
To: Kevin Noll <kevin.noll@xxxxxxxxxxx>,
"STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Cc: "Hugh Barrass (hbarrass)" <hbarrass@xxxxxxxxx>
Subject: RE: [802.3_EPOC] Continuing work on EPOC objectives
Kevin,
The "tradition" of 10^-12 is like most traditions - it started at an
undefinable time with undefined reasons.
The required BER of 100M Ethernet is 10^-10. For 1000BASE-X it was
"improved" to 10^-12 (but not for 1000BASE-T). Later definitions have all
adopted 10^-12.
From the higher layer perspective, most transport layers are designed to
operate with a frame error ratio <10^-6 - so they are quite happy with a
BER < 10^-10 and they aren't noticeably improved by the lower BER. It was
argued that setting the BER to 10^-10 for gigabit or higher bit rates
would result in observable errors that were too frequent on the interface
(e.g. every 10 seconds) and that "customers" would not like that. This is
a difficult assertion to prove one way or the other. Of course customers
(and even system vendors) will always demand the lowest possible BER but
the laws of physics are notoriously intransigent and cost increases
significantly as one approaches perfection.
In short, if there is representation of a large tranche of customer demand
requesting 10^-10 then that will be an acceptable objective.
Whatever the BER objective, there will be a requirement to prove that the
Mean Time To False Packet Acceptance is sufficiently long (traditionally
10 billion years). A low BER can raise the risk that the CRC integrity can
be compromised and therefore an errored packet could escape detection and
cause havoc amongst the data.
Hugh.
-----Original Message-----
From: Noll, Kevin [mailto:kevin.noll@xxxxxxxxxxx]
Sent: Sunday, April 29, 2012 12:45 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Continuing work on EPOC objectivesŠ
I haven't seen much discussion of the objectives over the weekend. This is
good because you are all supposed to be spending time away from
work-related activities on the weekends. :-)
To bring up a more specific item for discussion - I'd like to hear
suggestions on how to handle Objective 9.
9. PHY to have a BER better than or equal to 10-10 at the PHY service
interface.
We started this objective with a BER of 10^-12 based on a misunderstanding
of the expectations in 802.3. We have heard several opinions on this
leading me to believe that 10^-10 is a reasonable goal.
What problems do you all see with setting the BER goal to be 10^-10?
--kan--
--
Kevin A. Noll
-----Original Message-----
From: <Noll>, Kevin Noll <kevin.noll@xxxxxxxxxxx>
Reply-To: Kevin Noll <kevin.noll@xxxxxxxxxxx>
To: "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: [802.3_EPOC] Continuing work on EPOC objectivesŠ
SG members,
I will be unable to attend the conference call tomorrow, so we will likely
not work on the objectives.
In order to keep the work moving along, I would like to open a dialog here
on the mailing list. I've copied below the latest revision of the
objectives that were adopted and those that still need work. Please
comment and/or suggest changes to the "TO BE CONSIDERED" set.
ADOPTED IN MARCH
1. Specify a PHY to support subscriber access networks using the EPON
protocol and operating on point-to-multipoint RF distribution plants
comprised of all-coaxial cable or hybrid fiber/coaxial media.
2. Maintain compatibility with 1G-EPON and 10G-EPON, as currently defined
in IEEE Std. 802.3 with minimal augmentation to MPCP and/or OAM if needed
to support the new PHY.
5. PHY to support symmetric and asymmetric data rate operation.
6. PHY to support independent configuration of upstream and downstream
transmission operating parameters.
7. PHY to operate in the cable spectrum assigned for its operation without
causing harmful interference to any signals or services carried in the
remainder of the cable spectrum.
TO BE CONSIDERED
4. Provide at least one physical layer specification that is capable of
operating at :
A baseline data rate of at least 1 Gbps at the PHY service interface when
transmitting in 120 MHz, or less, of assigned spectrum under baseline
plant conditions;
data rates lower than the baseline rate when transmitting in less than
120 MHz of assigned spectrum or when plant conditions prevent a higher
data rate;
data rates higher than the baseline rate and up to 10 Gbps when
transmitting in more than 120 MHz of assigned spectrum or when plant
conditions support a higher data rate;
9. PHY to have a BER better than or equal to 10-10 at the PHY service
interface.
--kan--
Kevin A. Noll
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1