Re: [STDS-802-3-EPOC] Timestamp presentation for PHY Link call
How would you handle unicast transmissions for probing time and power setting etc? You do need some time indication, let's not call it time stamp.
ב-15 באוג 2013, בשעה 20:11, "Marek Hajduczenia" <marek.hajduczenia@xxxxxx> כתב/ה:
> Ed,
>
> In short, this reads to me as if you were actually proposing that we use something like CSMA/CD, with possible collisions in upstream (if two CNUs happen to be close enough for their upstream transmissions to collide). Is that in line with what you're suggesting ?
>
> Marek
>
> -----Original Message-----
> From: Ed Boyd [mailto:ed_boyd@xxxxxxxxx]
> Sent: Wednesday, August 14, 2013 5:46 PM
> To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
> Subject: Re: [STDS-802-3-EPOC] Timestamp presentation for PHY Link call
>
> All,
>
> Sorry to join the conversation late. I don't think that we need a time stamp in the downstream PLC. If the upstream PLC burst is an echo from a downstream PLC frame with a configured transmit offset per CNU, there is no need for a 32 bit grant timer or grants. A CNU that receives a Downstream PLC frame that requires a read will respond at a programmed delay from the start of the downstream frame. It keeps the PLC much simpler and doesn't cause a repeat of the MAC functionality in the PHY. Grants and a grant timers are important if you want to pack the upstream slots to fully utilize the upstream. The PLC upstream shouldn't require packing since it is only lightly loaded with acks.
>
> Thanks
> Ed
>
> Sent from my iPad
>
> On Aug 14, 2013, at 6:51 AM, "Dai, Eugene (CCI-Atlanta)" <Eugene.Dai@xxxxxxx> wrote:
>
>> Avi: I agree that PHY layer synchronization should be done before EPoC ranging could take place. This PHY layer synchronization could be frequency, phase and time information may be required. What I am not sure is that another timestamp is the right approach. The PHY layer process, i.e.. link set-up, should not involve "CNU join", transmission control, etc.., these should be control by MPCP. In this case we'll have clear separation of concepts and layers.
>>
>> Thanks,
>> Eugene
>>
>> ________________________________________
>> From: Avi Kliger [akliger@xxxxxxxxxxxx]
>> Sent: Tuesday, August 13, 2013 11:50 PM
>> To: Dai, Eugene (CCI-Atlanta)
>> Cc: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>> Subject: Re: [STDS-802-3-EPOC] Timestamp presentation for PHY Link call
>>
>> Eugene
>>
>> Yes. I used a wrong terminology, borrowed from other standards. I should have used link setup, but would you agree that time information exchange at the PHY later is necessary?
>>
>> ב-14 באוג 2013, בשעה 00:22, "Dai, Eugene (CCI-Atlanta)" <Eugene.Dai@xxxxxxx<mailto:Eugene.Dai@xxxxxxx>> כתב/ה:
>>
>>
>> This is exactly the where the concepts were mixed. EPoC ranging is no different from EPON ranging, it is controlled by MPCP, timestamps and synchronization are well defined there for the purpose.
>>
>> Another part is OFDM link setup; we need OFDM link to be up before ranging can be preformed. I will not call OFDM link setup progress as “ranging”. That how this new or additional "timestamp" mixed up two concepts.
>>
>> Eugene
>> ________________________________________
>> From: Avi Kliger [akliger@xxxxxxxxxxxx<mailto:akliger@xxxxxxxxxxxx>]
>> Sent: Tuesday, August 13, 2013 4:01 PM
>> To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
>> Subject: Re: [STDS-802-3-EPOC] Timestamp presentation for PHY Link call
>>
>> Ranging is done before link is established, so it cannot be done by the MAC.
>> Also, PLC provides a PHY level link that is transparent to the MAC, to carry PHY only related controls.
>>
>> -----Original Message-----
>> From: Dai, Eugene (CCI-Atlanta) [mailto:Eugene.Dai@xxxxxxx]
>> Sent: Tuesday, August 13, 2013 6:44 PM
>> To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
>> Subject: Re: [STDS-802-3-EPOC] Timestamp presentation for PHY Link call
>>
>> I mean "concepts were mixed..." sorry for the typo.
>> ________________________________________
>> From: Dai, Eugene (CCI-Atlanta) [Eugene.Dai@xxxxxxx<mailto:Eugene.Dai@xxxxxxx>]
>> Sent: Tuesday, August 13, 2013 10:56 AM
>> To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
>> Subject: 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<mailto:akliger@xxxxxxxxxxxx>]
>> Sent: Tuesday, August 13, 2013 9:51 AM
>> To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto: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<mailto: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><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><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><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><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><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><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><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
>>
>> ________________________________________________________________________
>>
>> 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
>>
>> ________________________________________________________________________
>>
>> 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
>>
>> ________________________________________________________________________
>>
>> 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
>
> ________________________________________________________________________
>
> 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
>
> ________________________________________________________________________
>
> 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
>
________________________________________________________________________
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