Thanks to all for your feedback and clarifications.
I agree that in the most general case of ‘non-CPRI data transmitted at irregular time intervals’ there is a need to provide the RRH with the absolute
time at which the first sample of the payload shall be transmitted. This information can be included in the RoE packets themselves. The overhead should not be very significant if packets are sufficiently long (e.g. 2 bytes time stamps for 128 bytes payload)
One could argue on the relevance of this scenario, but I have no issue with this approach which is open and simple.
A comment to Steinar’s feedback: I think that you are referring to interface 2 split (as defined in NGMN: Cell processing of L1 done in the RRH,
frequency domain compression and PRB extraction). This interface requires the definition of a control plane (to control UL synchronization, transfer scheduling information…). The control plane packets could also transport timing information (to indicate the
delta between the absolute RRH time and the TX frame). Packets are related to specific LTE frames. In that case, time stamps in the RoE packets may become redundant. I just want to point out possible alternatives to time stamps in the RoE packets. I know that
the definition of such an open interface for this category of cases is out of scope of the current work.
Best regards,
Philippe
De : Zhang, Sunny [mailto:sunny.zhang@xxxxxxxxx]
Envoyé : mardi 5 mai 2015 09:45
À : Steinar.Bjornstad@xxxxxxxxxxxxxxx; Bross, Kevin
Cc : Richard Maiden; SEHIER, PHILIPPE (PHILIPPE); Richard Tse; Jouni Korhonen; AshwoodsmithPeter; marek.hajduczenia@xxxxxxxxx; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Objet : RE: fractional nanoseconds
If the compression is fixed ratio, then time stamp is not must have, it could be recovered after de-compression.
If the compression ratio varies, then time stamp will be needed.
But adding time stamp in each packet may improve the 1588 timing sync accuracy and reduce the time constant of the loop filter, thus to reduce
the sync cost at RRU site.
Regards
-Sunny
All,
I think especially scenario 3. ) "Non.CPRI and likely compressed" is an interesting (and important) scenario. Benefits of using Ethernet is then more obvious.
In case of compression, I would expect packets not to arrive in specific time-intervals. Hence, time-stamping will be required.
There are essentially 3 scenarios we’re looking at here:
1. Uncompressed
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.
· 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)
===================================================================
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.
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)
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.
===================================================================
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).
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).
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.
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.
|