Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-3-EPOC] next Work Item and Socialization conference call for this Wednesday



Hi Ed,

This proposal is to simplify Upstream EPoC, allowing FEC encoding without having to figure out ahead on which RE the data start and stop will fall on and the bit loading the subcarriers.

False or missed detection is always a possibility but the BM is designed to be more robust than the FEC encoded data on the typical link.

The payload after LDPC FEC encoding is always a multiple of 65 b, this is in the current D05 spec, this is not the essence of my proposal.  My BM signaling scheme is compatible with it.

If having the BM placement just after the data start is viewed as a problem, the BM could be moved and inserted prior the data.

I will be happy to discuss and explain the scheme at the meeting in Norfolk.

Thanks
Leo

From: ed_boyd@xxxxxxxxx [mailto:ed_boyd@xxxxxxxxx]
Sent: Wednesday, May 07, 2014 12:41 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx; Leo Montreuil
Subject: Re: [STDS-802-3-EPOC] next Work Item and Socialization conference call for this Wednesday

Hi Leo,

Thanks for sending out this presentation.  I think that I understand what you are proposing.  Unfortunately, I’m not qualified to say what this means to the burst marker detection ability so I will defer to someone else to review that portion of the proposal.  I do worry that it makes us more sensitive to false detection.

I think that using this method for the end of burst is a good and it would help limit the burst size and simplify the burst detection state machine that Duane and I proposed.  We would avoid stuffing bits into the end of the block.  I still don’t see the need to make the parity 65 bits.  If the data in the block is multiples of 65 bits, we will have a size that is Nx65 plus a constant for the parity.  I don’t see a need to waste bits or change the parity size to 65 bits multiples.

I don’t think that the proposed method for start of burst works.  The start of burst marker consumes a significant amount of bits and the amount of bits is different for every start of burst position.  The amount of data is not only the 2 REs, it is also the REs covered by the burst marker where the data rate drops in half.  This positioning will cause a significant jitter.  I think that the method described by Duane and I is still required.  We take a fixed time offset from the data detected and start transmitting on a valid boundary.  In this way, we don’t have any jitter.  Since you need to allocate the worst start burst marker overhead and worst case delay, I don’t see a savings in your method.  I would be happy to discuss this further since I might be missing something in your proposal.

Thanks,
Ed….

Sent from Windows Mail

From: Leo Montreuil<mailto:leo.montreuil@xxxxxxxxxxxx>
Sent: ‎Wednesday‎, ‎April‎ ‎30‎, ‎2014 ‎9‎:‎08‎ ‎AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>

All,
Here is how we can use the Burst Marker to delimit the data in the Upstream OFDMA channel. This is work in progress.
Thanks
Leo Montreuil

From: Mark Laubach [mailto:laubach@xxxxxxxxxxxx]
Sent: Monday, April 28, 2014 9:04 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-3-EPOC] next Work Item and Socialization conference call for this Wednesday

Dear IEEE P802.3bn Task Force Participants,

Our scheduled work item and socialization conference call is this Wednesday at 10AM Pacific.

Agenda items:

1.       Work item review and hopefully some volunteers for blank status items.

a.       I’ll have an update posted tomorrow for: Work Items for Norfolk, Virginia Interim, May 2014 (rev 01c)(4/9/14)<http://www.ieee802.org/3/bn/public/wias/workitems_3bn_01c_0514.pdf>

2.       As per last week’s call, Leo was preparing socialization on an upstream burst marker approach.  If he is ready, he’ll send out the presentation on the reflector before Wednesday.

3.       Anything else.

If you have any presentations for socialization on the above or other topics, please send them on the reflector by 5PM Pacific tomorrow (Tuesday).     Note that priority for time (if we get tight) will be given to socialization addressing blank and “S” work items.

Please be familiar with the IEEE SA Patent Policies at:
https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.pdf

WebEx Meeting Number: 929 018 362
To join: https://broadcom.webex.com/broadcom/j.php?J=929018362
Meeting Password: This meeting does not require a password.

Yours truly,
Mark Laubach, Chair
IEEE P802.3bn EPoC PHY Task Force

Broadband Communications Group
Broadcom Corporation
1351 Redwood Way
Petaluma, CA, 94954
  [broadcom.jpg]
Tel: +1.707.792.9093
Cell: +1.650.996.2219


________________________________

<="" 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

JPEG image