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

Re: [STDS-802-3-EPOC] Burst Markers



Since we haven't yet defined neither the burst markers nor the way
Dynamic-TDD will be implemented, it was premature to say it's not a good
solution.
I beleive a good solution can be found.
Thanks,
Raanan
 

  _____  

From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx] 
Sent: Tuesday, February 19, 2013 7:39 PM
To: raanan.ivry@xxxxxxxxxxxx; 'Victor Blake'
Cc: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] Burst Markers



Hi Raanan,

 

Thanks for the email.  I agree that we need to understand the overhead for
the burst markers.  I would like to keep it small but it is also important
that the detection is reliable.  I think that MMP could be solved with the
burst markers.  We are working on a proposal for the markers that we think
will work for both.  I believe that Juan (Qualcomm) is working on a marker
proposal with the same objective.

 

To be honest, I haven't spent much time considering the dynamic TDD case
with markers.  I like the idea of dynamic TDD and had proposed it in an
earlier presentation.  Can you give me a few more details on the challenges
of a dynamic TDD with burst markers? Why wouldn't it be a good solution
versus a MAP?

 

Thanks,

Ed..

 

From: Raanan Ivry [mailto:raanan.ivry@xxxxxxxxxxxx] 
Sent: Tuesday, February 19, 2013 2:37 AM
To: 'Victor Blake'; Ed (Edward) Boyd
Cc: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] Burst Markers

 

I agree with your answers/comments.

It's true that in the new wireless standards there is no strict line between
MAC and PHY.

In any case, when we decide about a solution, we need to compare it with
other option and to verify that we do not lose too much.

 

The map we are talking about is also relevant to some other issues we are
dealing with, like MMP and dynamic TDD.

BTW, if we want to adopt Dynamic TDD,  Burst Markers will not give a good
solution.

Thanks,

Raanan

 

  _____  

From: Victor Blake [mailto:victorblake@xxxxxxxxxxxxxxx] 
Sent: Monday, February 18, 2013 9:14 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Burst Markers

The map approach is what is used in some wireless protocols as well. It can
be very effective when there are a wide range of frequencies (channels) in
use and the allocations of services across them changes over time.

 

The gate can be thought of as a two dimensional means (time and LLID), the
map is really a three dimensional gate, time, channel, LLID. In this way,
the map is performing the same function as a gate. 

 

In other words, it's only adding one more parameter to the gate to make a
map. 

 

-Victor

 

From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx] 
Sent: Monday, February 18, 2013 1:44 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Burst Markers

 

Hi Raanan

 

Thanks for the email.  It is certainly possible to build and send MAPs as
done in other standards.  This type of solution is far from the current
Ethernet/EPON standard.  The PHY doesn't process the GATE frames in the
current standard and there isn't burst information signaled from the MAC to
the PHY. The GATEs are sent unicast with delay compensation in the start
time.  It would challenging to have a PHY rewrite the frames and figure out
the boundaries of the GATEs so it could construct the MAP.  

 

While laser ON/OFF doesn't exist in EPoC, other burst overheads do exist.  I
would like EPoC to have the same or less burst overhead than EPON so I use
the laser on/off and sync time from EPON as a reference point for
comparison.

 

In short, The MAP is an option for a new standard but it really isn't for an
EPON over Coax.  I think the marker will be simple and allow full
compatibility with the EPON standard and layering.

 

On the overhead, I think that it can be low based on discussions with our
PHY team.  It could be just a few symbols in a small number of carriers.  We
are working proposals on the details and are open to suggestions.  I think
that the shortened last code word will be the largest burst overhead for
EPoC. 

 

Hope that helps

Ed

 



Sent from my iPhone


On Feb 18, 2013, at 8:01 AM, "Raanan Ivry" <raanan.ivry@xxxxxxxxxxxx> wrote:

Hi Ed,

In your presentation you suggested the use of Burst Markers.

There is another option: All the information (a full map)  about teh burst
timing and frequencies can be sent in a Gate message by the CLT.

 

There are differences between EPON and EPoC which may permit such attitude:

1. Symbol size (EPoC) >> bit size (EPON)

2. There is no such thing as laser on/off time in EPoC

3. CLT-CNU synchronization is not a problem

 

We need to understand:

1. Why we need those Burst Markers

2. What  the penalty (overhead) we are going to pay  is.

 

Raanan

 

 

 

  _____  

 

  _____  


________________________________________________________________________

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