Re: [STDS-802-3-EPOC] PHY Link Ad Hoc Notes
Marek,
Please see inline below.
Thanks,
Ed...
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Monday, April 08, 2013 12:11 AM
To: Ed (Edward) Boyd; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: 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.
[Ed] I'm not sure what to say. The ad hoc is a forum for discussion and I'm open to people presenting new ideas at the last second. In all cases, the decision will be made at a future meeting and people have an opportunity to work on other proposals. If you want to make a procedural change for all of the ad hocs, I recommend that we discuss and have a motion at the next meeting.
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.
[Ed] The motions are solid and make sense. They were voted on by the group with a strong consensus. I strong disagree with your statement above.
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.
[Ed] This doesn't make sense to me. The Preamble with SFD allows you to determine the start of the FEC block. You wouldn't use the FEC to correct bit errors in the preamble/SFD. We are requesting proposals for the preamble. I don't think that anyone is suggesting faith. We need a preamble to find the PLC. Once we are locked on, the start of frame and FEC block is known.
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.
[Ed] I agree. It can be added.
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.
[Ed] I don't disagree in general. We have proposals on FEC coming and I think that we should consider CRC at the same time. The total overhead for FEC+CRC should be evaluated for error correction/detection performance.
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
[Ed] It would be great if you could highlight the differences on Wednesday. It is not clear to me and it seems very different than the OAM format.
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
[Ed] I don't agree with this paragraph. We selected a FEC so that we could correct errors and provide burst error correction. A CRC would only detect errors and we decided that we wanted to survive burst errors. We will determine the cost (number of bits) versus performance (better SNR and burst protection) when we select the FEC. Some think that we have enough bandwidth and others believe that it is tight. I want to get the most out of what we have. I think that it is enough bandwidth if we have an efficient format. I don't see any additional reliability in your format proposal or any advantage. Please point out the advantages on Wednesday so the bytes have value.
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 ...
[Ed] I don't understand this paragraph. I have not proposed a fixed size frame or anything like ATM. I'm not against a fixed size frame and I would be happy to see it work since it would be simpler. The FEC block size detection is much easier and we don't need a post-amble. I don't see anything in your proposal that addresses this issue. The Duane/Hesham/Ed proposal was a single slide on a variable instruction format to configure a remote PHY. You argued that the variable size instruction was not reliable. To address your issues with reliability, Qualcomm suggested a fixed format. I don't think that they suggested ATM.
Looking forward to more discussion on individual items.
Regards
Marek
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]<mailto:[mailto:ed.boyd@xxxxxxxxxxxx]>
Sent: Monday, 08 April, 2013 1:51 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto: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<mailto: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]<mailto:[mailto:marek.hajduczenia@xxxxxx]>
Sent: Wednesday, 03 April, 2013 11:26 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto: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<mailto: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
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image005]<http://www.linkedin.com/company/broadcom>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image002]<http://twitter.com/#!/broadcom>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image003]<https://www.facebook.com/Broadcom>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image004]<https://plus.google.com/109188783526874806673/posts#109188783526874806673/posts>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image006]<https://www.youtube.com/user/BroadcomCorporation>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image008]<http://blog.broadcom.com/>[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: image007]<http://broadcom.com/>
________________________________
<="" 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
