Richard,
There are essentially 3 scenarios we’re looking at here:
1. Uncompressed CPRI data
2. Compressed CPRI data
3. Non-CPRI IQ data (likely compressed)
I concur that for scenario #1, a sequence number is sufficient. For scenario #2 and #3, I’m not sure what level of synchronization is required, but I suspect that even with 5G, this synchronization will be » 1 ns; as has been noted previously, 1 ns ≈ 30 cm.
The path for synchronization can be/must be different from the path used for transporting RoE traffic. That’s okay. As long as each node has a sense of “absolute time”, packet reception/transmission time can be properly coordinated between the distributed nodes. In previous meetings, we’ve talked about the need for egress buffering at the far end of RoE links to compensate for any jitter variability—as long as the egress buffer is larger than the jitter that is seen in a properly engineered network.
Rough examples:
· Suppose a given network can afford 500 µs for round-trip transport time (250 µs each way)
o If the network has 150 µs jitter, this leaves 100 µs for nominal transport time (~20 km)
o If the network only has 100 µs jitter, that leaves 150 µs for nominal transport time (~30 km)
o If the network has 50 µs jitter, this leave 200 µs for nominal transport time (~40 km)
--kb
===================================================================
All,
Typically the REC (Radio Equipment Controller) will have GPS and it uses this to lock its internal PLL when it generates the serial data stream (in CPRI or SyncE). This clock is then recovered & cleaned of jitter on the RRH side. In the CPRI case, a Round Trip Time delay is measured (much like 1588v2) to provide a latency measurement. We now have frequency lock and link latency. In CPRI, IQ data is time-stamped based with the hyperframe number (1/150th of a 10ms radio frame) and the BFN (basestation frame number).
Assuming we have frequency lock from SyncE and a latency measurement from 1588v2 then I’d suggest that RoE packets simply require some sequence number.
There are a couple of challenges though. Firstly, although 1588v2 packet will travel over the same network, I’m not sure we can assume that these packets will follow the same path as the RoE packets? If this cannot be assumed then (some) RoE packets will need to contain 1588v2 information.
Secondly, SyncE and 1588v2 will lock PLLs and give latency measurement based on the Ethernet clock domain (a multiple 31.25MHz). Today, all baseband units provide samples over CPRI based on a multiple of 3.84MHz (e.g. 30.72MSps for LTE20). Crossing this clock domain can introduce undeterministic latency. Most designs have a system budget for this of 16/3ns.
Thanks,
Richard
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
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
===================================================================
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
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
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
You would need to add 16 more bits to the timestamp.
- Jouni
Sent from a smart phone.. Mind the typos..
where woukd the other 16 bits come from?
Sent from HUAWEI AnyOffice
Subject: Re: fractional nanoseconds
time: 2015-05-02 15:14:23 Hi,
I was thinking the same as 1588 can do i.e. 1/65536 ns.
Jouni
Sent from a smart phone.. Mind the typos..
\> Marek Hajduczenia \ kirjoitti 2.5.2015 kello 9.32:
\>
\> Jouni,
\>
\> What would be the resolution of these fractional nanoseconds?
\>
\> Marek
\>
\> -----Original Message-----
\> From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On Behalf Of
\> Jouni Korhonen
\> Sent: Friday, May 01, 2015 6:30 PM
\> To: STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
\> Subject: fractional nanoseconds
\>
\> Folks,
\>
\> We have already had some discussion on this topic earlier but.. what is your
\> opinion on having fractional nanosecond accuracy in the time stamping (e.g.
\> when sending a timestamp in the RoE header)? If we follow what 1588 did for
\> the correction field that would mean 16 additional bits, which may or may
\> not be significant overhead wise.
\>
\> Comments & opinions?
\>
\> - Jouni
\>
\> --
\> Jouni Korhonen, CTO Office, Networking, Broadcom Corporation
\> O: +1-408-922-8135, M: +1-408-391-7160
\>
Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you.