| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I agree, insofar as the LPF is able to maintain the proper bit spacing. However, I don’t think the LPF will be able to tell which bit position some data is supposed to start on… ·
Hypothetical example: suppose there’s a period of successive 0x00 bytes that is suppressed from the front haul to handle quiescent periods. At some point after all these zeroes, there will be a non-zero
byte.
o
When the next set of data is supposed to go out on the radio, you need to know when the first bit for that next byte is supposed to go out on the radio
o
If you send the next byte out one bit position early, the radio will interpret the data incorrectly, as bits will effectively be shifted left
o
If you send the next byte out one bit position late, the radio will also interpret the data incorrectly, as bits will effectively be shifted right ·
I think you need to be able to specify the presentation time to sufficient accuracy that the RoE device can know the theoretically precise time for when that leading bit should go out.
o
For each ¼ ns period specified by the current timestamp granularity, there could be ~6 different bit position that would match a given timestamp. How is the RoE node supposed to know which of these
6 different bit positions is the right time to push out the first bit of that new radio data?
o
With future 100 Gbps links, there would be ~25 possible bit positions for each timestamp.
o
This is why I proposed re-defining the units of the RoE timestamp to be in picoseconds. This still allows specifying a time up to 1 µs in the future (what all seemed to agree was well beyond the expected
transit time for any 4G or 5G fronthaul), while still providing enough precision to specify the timestamp for future links up to 1 Tbps. --kb ------------------------------------------------------------------ From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Richard Tse Richard: Rich From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Richard Maiden Hi all, Please find a short presentation attached where I try to frame the requirements from an RF perspective. Ultimately I’d argue that the only thing that matters is that the appropriate sample is put on the air at the appropriate time. The
block which determines this is the egress buffer (FIFO) in the radio. This FIFO has 2 controls on the egress side, clock and read address. There are so many ways to generate these signals that I think this topic is out of scope for 1904.3. We just need to
make sure that we do not do anything to box ourselves in with the packet definitions which preclude any particular mechanism. Kevin brings up a good point with the accuracy of our timestamp field. The granularity of its accuracy means that if it is regularly used (rather than a one-time start mechanism), it will be tricky to ensure that we don’t introduce jitter
every time we receive a timestamp. Effectively we’d have a moving time-quantization error. For LTE 20MHz for example, we have 30.72MSps for each AxC or 32.5520833333’ns per sample interval. Right now our timestamp granularity is 0.25ns. If we perform a one-time
timestamp, we’ll have some quantization error on when we actually send but that would not be a problem. However, on the next presentation time timestamp, we will likely have a different quantization error and so we will in effect jump forwards or backwards
in time on when we actually transmit that sample – that’s a problem. Adding more granularity (fractional bits) would reduce this error but I’m not sure how far we’d have to go.
Thanks, Richard Richard Maiden ALTERA (an Intel Company) 101 Innovation Drive San Jose, CA 95134 Tel: +1 (949) 382-5402 |