Re: [STDS-802-3-EPOC] PHY Link Ad Hoc Notes
Ed,
The lack of good practice is not an excuse for no such practice. I have an
issue with people showing up at the meeting and presenting material out of
the blue. First, we spent lots of time analyzing the material on the call,
that could be spent better discussing how the given presentation adds (or
not) to the work we have to do. Second, for the F2F meetings, we have
requirements to submit in advance to let people examine the materials in
advance and become prepared for discussion. It is just bad practice to
surprise people on the call, especially when we are expected to take
decisions. It has been preached over and over again that the foundation of
good progress is consensus building ? hard to do that when you see material
on the call for the first time.
My main goal for the proposal was not strictly adhering to motions but to
design something reliable. Something that has a standing chance to work
versus a bunch of motions passed without much foundation behind them. But
let?s deconstruct your email in more detail.
1) Your concern is that SFD should be part of the preamble and outside
of the FEC protection. However, that will make it vulnerable to bit errors
and potential frame misalignment. Knowing nothing of FEC so far (apart that
we will have FEC), there is no way to asses probability of such an event
actually taking place, and hence establishing whether you can do that or
not. I am not too attached to SFD at this position, though, so if it is
proven that SFD can be outside of the FEC protection, I am willing to accept
that. However, I need to see numbers to prove just that. Faith does not work
here.
I think the best way forward in here is to compare SFD location within or
outside the FEC protected area. If either one has accepted frame alignment
performance, then we can go either way. But choosing just based on faith is
not the right way to go.
2) Configuration ID as you mentioned was not accepted at this time and
as such, I did not want to deal with it this time. I believe, though, it can
be dealt as a new TALV type without any problems. The structure is
extensible without any problems.
3) FEC has been decided, indeed, though without any additional details
(what type, what payload rate etc. is largely missing). Until it is proven
that FEC alone can give you MTTFPA equal to or better than the age of the
Universe, I move you will need good CRC to prevent false packet acceptance
events, which can be disastrous for larger PLC frames carrying plenty of
register data. It is not a matter what occupies more or less bandwidth, but
a matter of statistics and bit error calculations. Before we take such a
decision, we need to (a) know details about the proposed FEC, and (b)
calculate MTTFPA for this link and (c) only then decide that we do not need
CRC. In the lack of evidence otherwise, I assume CRC is needed to guarantee
PLC reliability. I would further move that any proposals for FEC without bit
error calculations are not moving us in the right direction and choosing FEC
type based on bandwidth overhead is just the wrong way to go.
4) Yes, I was against repeating read/write requests as you presented it
and I still am. I was not against the concept in general ? please do not
misrepresent the position I presented at the last meeting. The format I
suggest has been already tested in OAM and works just great as long as FEC
and CRC do their job right. If you compare both proposals, you?ll see
differences in how addresses and read/write requests are lumped together (I
did not have time to draw hundreds of examples to show all possibilities).
Also, I would be very happy to drop it (read / write sequences) altogether
and just do things as OAM does ? one managed object at the time. That is the
most resilient approach and I would be happy if we agreed on this approach
5) About the bandwidth usage itself: let?s not try to save bits on this
data channel in the name of saving bits, and for two reasons: (a) we added
FEC into it without any evidence that it will be really needed (I did not
hear your concerns about bandwidth waste then), (b) we have plenty of
bandwidth to go in this channel. We do not have to compete with user data
for access, and it is always available. Sending 1.1 Mbit/s worth of data
versus 1.0 Mbit/s of data and having extra reliability will pay off in the
longer run ? the PLC link has to be available (as you emphasized many times)
or there is no EPoC at all.
We are not bandwidth pressed in PLC and what I am suggesting does not
multiply bandwidth demand. I am truly baffled by this notion of concerns
about bandwidth usage when we do not know how much register data we will
have to transfer (our best estimates are nothing more than guesses, nobody
really knows this early in the process) and we have apparently agreed on
quite a generous PLC channel size, allowing us to establish quite a large
data pipe to CNUs. So I do not buy this argument
In general, I am very much concerned with the fixed-size frame format that
seems to be behind your proposals so far. It seems to me ATM all over again,
with all of its pros and cons and I would like to understand what is so
attractive in a fixed-sized frame format, with bunch of noops in the middle
and how it saves us bandwidth on PLC link versus what I propose ?
Looking forward to more discussion on individual items.
Regards
Marek
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Monday, 08 April, 2013 1:51 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] PHY Link Ad Hoc Notes
Marek,
Thanks for sending out the presentation in advance. On the earlier email,
you brought up the requirement to send presentations in advance of the ad
hoc call. While I agree that this is good practice, we have not required it
in the past. In fact, I don?t believe that any of the other presentations
were sent in advance. In most cases, I have asked people to send them out
after the call. We only have a week between calls and I don?t want to slow
down submissions by requiring the early submissions. The ad hoc call is an
opportunity to try ideas before the formal presentation at the main meeting.
I don?t think that the single slide proposal for an instruction format was a
surprise or inappropriate since we had asked for ideas for instruction
format on the previous call.
On your proposal, it isn?t fully consistent with the motions/straw polls
from the last meeting. We decided to lump the SFD into the preamble field
and passed that in a motion on the defined format. We are asking for
proposals for the format of the preamble that should include the SFD. I
think that the preamble isn?t QAM16 or covered by the FEC. It is minor
point but I think that we can drop the SFD from the payload. Unfortunately,
we didn?t have time for a motion but we had a straw poll to add the
configuration ID. You didn?t have it in your payload format. Again, it is
a minor point.
While we decided to include FEC, we didn?t decide on the need for an
additional CRC. I noticed that you included a CRC-32. I would like to see
justification for it when combined with the FEC. Are we better off with a
bigger FEC and not a CRC-32? A smaller FEC with a CRC-8/16/32? I?m not
sure. I know that others have more detailed presentations on this subject
in the works. I didn?t include the CRC-32 in the instruction format for
that reason.
On the Ad Hoc, you were against the proposed instruction format including an
address and repeating write data count. You argued that it was too
sensitive to errors that would come through the FEC/CRC. If I look at your
proposal, I see the same sensitivity. If you get a bit error in the type or
length, the frame can?t be decoded. As I mentioned on the call, I don?t
believe that there is any reason that an address or length is more critical
than write data. If a bit error is passed on almost any of the critical
write data, it would be a big problem. The wrong center frequency, upstream
PLC frequency, configuration ID, bit loading, exclusion band size, TDD/FDD
mode, etc would be a problem. With that said, I think that error
sensitivity is a topic related to the FEC/CRC decision and not the
instruction format. I would also note that only the configuration of the
upstream PLC frequency is required to be a write without verification. The
transmit power level and transmit offset will be checked by the CLT PHY.
Once the upstream PLC is up and running, the CLT PHY could decide to do
write/verify if was concerned about the configuration. Personally, I don?t
think that it is necessary and I would do unverified broadcast writes to
configure downstream channels.
The instruction format that you suggest has a much higher overhead. I
really don?t see the justification for the extra bytes. I also noticed that
you moved the PHY address into the instructions. I only had a single
address for each PLC frame since the read instructions should only trigger a
single PLC frame in response. Multiple reads could be confusing for the
upstream response.
Hope that is helpful and Thanks for the presentation.
Ed?
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Saturday, April 06, 2013 10:22 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] PHY Link Ad Hoc Notes
Dear colleagues,
Attached please find an alternative (and more detailed) proposal for PLC
framing. I identified a number of areas that will need more discussion,
primarily associated with selection of PLC FEC and PLC CRC, PLC SFD
sequence, as well as decision on whether individual PLCS data frames are
fixed or variable size.
I also included proposal for the internal structure, addressing, and
flexible data access mechanism, allowing for OAM-like behavior over the PLC,
while allowing for direct addressing of individual registers (and bits
within the register) together with chained sequential read/write operations.
I would like to ask for feedback before the call so that the proposal can be
further polished and then hopefully discussed in more detail on the call
next week
Please note that I do not discuss any PLC PMD related topics, including
mapping into carriers, etc. I believe these should be discussed in parallel,
to simplify detection of PLC SFD. For example, PLC SFD should start always
in a known subcarrier relative to the start of the PLC channel, so that the
data decoder can optimize the search mechanism to limit acquisition time. It
is just a thought, but I believe we should not be discussing digital PLC and
OFDM PLC parts separately.
regards
Marek Hajduczenia, PhD
ZTE Portugal
Standard Development and Industry Relations
Edifício Amoreiras Plaza,
Rua Carlos Alberto da Mota Pinto, nr. 9 - 6 A,
1070-374 Lisbon, Portugal
Office: +351 213 700 090
Fax: + 351 213 813 349
Mobile: +351 961 121 851 (Portugal)
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Wednesday, 03 April, 2013 11:26 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] PHY Link Ad Hoc Notes
Ed, et al.,
Since it is not recorded in the minutes, but it was brought up on the call,
I feel it is important enough to bring it up again. I would really
appreciate if there were no more surprise presentations brought forward for
discussion. It is hard enough to have to examine proposals on the fly on a
small screen, written in minuscule font, but it is also wasteful in terms of
time to have to formulate opinions on complex topics like PLC, its framing
etc., on the fly. I think we would be better served being able to preview
the presentations before the meeting.
With that said, I plan to develop an alternative framing proposal for the
next call and distribute the draft presentation by next Monday. I would
encourage everybody to follow similar approach and give other participants
at least one working day to go through the materials ahead of the call.
Regards
Marek Hajduczenia, PhD
ZTE Portugal
Standard Development and Industry Relations
Edifício Amoreiras Plaza,
Rua Carlos Alberto da Mota Pinto, nr. 9 - 6 A,
1070-374 Lisbon, Portugal
Office: +351 213 700 090
Fax: + 351 213 813 349
Mobile: +351 961 121 851 (Portugal)
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Wednesday, 03 April, 2013 9:31 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-3-EPOC] PHY Link Ad Hoc Notes
All,
I have attached the slides from today?s call. Here is the a summary of the
call.
1) Editor for PLC
a. Most of PLC will be in the PCS and handled by Marek (digital and
framing)
b. Saif/Joe will handle the rest of it in the PMA.
2) Huawei and Broadcom presented a Downstream Command Format proposal
(at the end of the slides)
a. Efficient method to set blocks of configuration registers in the
PHY.
b. Marek has concerns about errors in the PLC and impact to
incrementing address.
c. Do we need to have FEC and CRC in PLC? Do we need to worry about
undetected errors multiplying?
d. Qualcomm wants to consider no address and a fixed register set for
PLC.
3) Baseline Proposal Review (slides 34-35)
a. One or more PLCs in the downstream is not clear.
b. 1MHz granularity for setting PLC location
c. General support for 6MHz min size of EPoC spectrum around PLC.
Question on whether it could be 24MHz?
d. PLC hunting is a vendor specific algorithm but MDIO controls needs
to be define. Bill K will make presentation.
e. 8 or 16 carriers for PLC are adjacent.
Thanks,
Ed?
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: cid:image009.jpg@01CD505E.7B800DB0
Edward Boyd | Sr Technical Director
Broadcom Corporation | (O) 707-792-9008 | (M) 707-478-1146
<http://www.linkedin.com/company/broadcom> Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: image005 <http://twitter.com/#!/broadcom>
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: image002
<https://www.facebook.com/Broadcom> Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: image003
<https://plus.google.com/109188783526874806673/posts#109188783526874806673/p
osts> Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: image004
<https://www.youtube.com/user/BroadcomCorporation> Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: image006 <http://blog.broadcom.com/> Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: image008 <http://broadcom.com/>
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: image007
_____
<="" p="">
_____
<="" p="">
_____
<="" p="">
_____
________________________________________________________________________
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
