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 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
Sent: ‎Wednesday‎, ‎April‎ ‎30‎, ‎2014 ‎9‎:‎08‎ ‎AM
To: 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
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)

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