| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
All, I may have missed a part of the exchange on time stamping. Can someone clarify the following: I assumed so far that RRH are synchronized either by a GPS or through 1588 (1588 possibly with a higher accuracy as proposed in the liaison letter).
My understanding is that a simple sequence number is sufficient in the RoE packets. The 1588 packets are transported on the same NW, but are not RoE packets. Why should we the RoE packets have their own time stamps? My view is that the RoE packets carry their own timing information: on DL when a RoE packet arrives at the RRH, the RRH knows when the emission
of the content of this packet should start, based on the timing information provided by the GPS or 1588. Even with large jitter amplitude, the RRH is able to compensate for the delays. I assume that the RoE packets are synchronized with the LTE frames. If this is not the case, it is necessary to indicate to the RRH the instant
at which the first sample of each RoE packet needs to be sent. This is maybe what I missed in my reasoning above (but even in this case, I am not sure that we need a highly accurate time stamping as the clocks on each side are synchronized) Thanks for your help, Philippe De : stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
De la part de Bross, Kevin I think we need to constrain our discussion to whether or not we NEED it for RoE. There may be reasons other standards are using more or less timing precision,
but what’s necessary for RoE? I agree that any time format selected should be easily converted to/from 1588’s time format. --kb ===================================================================
From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Richard Tse Since our timestamping is going to the same as 1588’s, I suggest we follow the same format. Using another format (like 0.1ns increments) has no
benefit and just causes problems as the system would have to convert between the formats.
Of course, we don’t need to use all 16-bits of the 1588 fractional nanoseconds field format. If we only want 4-bits worth, we should use the most
significant 4-bits of the 1588 fractional nanoseconds field (1/16 of a nanosecond increments). Rich From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Jouni Korhonen Pah.. we know less than 1ns would most likely be overkill for current known applications. The question I have / had is that whether we want to
follow what 1588 did or do something else. That something else being either 1) no fractional nanoseconds at all or 2) e.g. what WLAN guys are after (0.1ns which is 4 bits more). - Jouni
From: AshwoodsmithPeter [mailto:Peter.AshwoodSmith@xxxxxxxxxx]
LOL – yes I know ; )
My gut feeling is that as we get into 1/65535th of a nanosecond we are well beyond the realm of the possible so that may be way too
many bits. One nanosecond is about 25cm in fiber. So we are talking .0004 of a cm!!!! Seems like over kill to me but I’m not a clocking expert. I can see doing this kind of overkill on periodic PTP packets where the bits don’t cost bandwidth, but here where every bit counts I think we need
to be more frugal. Cheers, Peter From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
You would need to add 16 more bits to the timestamp. - Jouni
|