Re: [STDS-802-3-EPOC] Timestamp presentation for PHY Link call
I think that concerts were mixed in this timestamp discussions/proposal. The PHY layer OFDM symbol synchronization /lineup has been mixed with CNU ranging.
“During initiation of the link and ranging, before the link is setup, the CLT must allocate transmission opportunities for the joining CNU.” This statement is true, but ranging process is controlled by EPON protocol, ie., MPCP. Timestamps are already there for synchronization of CLT with CNUs. Why need another layer of timestamp for ranging?
Eugene
________________________________________
From: Avi Kliger [akliger@xxxxxxxxxxxx]
Sent: Tuesday, August 13, 2013 9:51 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Timestamp presentation for PHY Link call
Duane
Sorry for the slow responsiveness. I agree with the functions you listed for the time stamp for the PHY layer functionality.
During initiation of the link and ranging, before the link is setup, the CLT must allocate transmission opportunities for the joining CNU. This can only be done with a time stamp at the PHY layer.
Also, during normal operation there will be some message exchanges between the CLT and the CNU that would not involve the MAC, like probing, ranging and maybe others. The CLT would need the time stamp to let the CNU know when (e.g. on which OFDMA frame) it must transmit its PHY link signaling.
As for the components of the time stamp, why can it be just time indications? Like in the MAC timestamps?
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Tuesday, August 06, 2013 7:15 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Timestamp presentation for PHY Link call
Marek,
My bullet on network synchronization was merely a suggestion that, if needed, the time stamp could be used for this purpose. Please don’t blow it up into some that was not intended.
Below is a more detailed illustration of the timestamp counter chain which I will add to the presentation for tomorrow. Counter bits sizes were selected for specific reason which I will explain on the call. I believe we need to be concerned with single bits in order to achieve interoperability.
[cid:image001.png@01CE9814.97F0C670]
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx<mailto:duane.remein@xxxxxxxxxx>
Director, Access R&D
919 418 4741
Raleigh, NC
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Tuesday, August 06, 2013 11:11 AM
To: Duane Remein; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-3-EPOC] Timestamp presentation for PHY Link call
Duane,
Before we switch from PHY synchronization to synchronization services, I would really love to get feedback to the questions I posted on the reflector some time ago, if possible, i.e., what are we missing with 802.3bf and 802.1as in place that would prevent us from supporting synchronization services over EPoC. We seem to be in a hurry to define whole solution for delivery of synchronization services over EPoC, while I do not think we fully explored the use of these two standards in combination to deliver sync services.
Following the discussion at the last call, and you proposal, I can certainly see how we can achieve PHY synchronization, though perhaps visual explanation of the actual need for it would be certainly also very welcome. As mentioned before, I want to understand the problem better to be able to vote on this topic in an informed manner in York, should this topic comes up for discussions and motions.
As for your proposal itself – I understand that the field sizes you propose are merely minimum required sizes – we typically do not become overly concerned with single bits, especially when future extensibility might be of interest. Looking at the definitions of individual fields, it would be helpful to actually show what units we measure each in.
Last but not least, one or two numeric examples would be helpful, to better understand what each individual fields are expected to do. Without additional drawings, it is a bit a stretch to figure out what is what, despite the text you already included in the slides.
Thank you
Marek
PS. “worst cast” likely needs to be “worst case” ???
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Tuesday, August 06, 2013 3:30 PM
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Cc: Duane Remein
Subject: RE: [STDS-802-3-EPOC] Timestamp presentation for PHY Link call
Marek,
You probably noticed that this bullet is followed by a question mark, as is the bullet “Other”. My guess is that a timestamp, as described, would be useful in ToD synchronization and general network timing but you are correct, I haven’t explored it’s application in this area.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx<mailto:duane.remein@xxxxxxxxxx>
Director, Access R&D
919 418 4741
Raleigh, NC
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Tuesday, August 06, 2013 5:20 AM
To: Duane Remein; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-3-EPOC] Timestamp presentation for PHY Link call
Duane,
Could you please clarify how your proposal is associated with “Network Synchronization/ToD” ? It is mentioned up front, but otherwise – disregarded afterwards …
Marek
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Tuesday, August 06, 2013 5:43 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-3-EPOC] Timestamp presentation for PHY Link call
Mark,
Presentation for tomorrows call.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx<mailto:duane.remein@xxxxxxxxxx>
Director, Access R&D
919 418 4741
Raleigh, NC
________________________________
________________________________
<="" 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