[srslte-users] How is subframe-level timing established and adhered to for over-the-air (OTA) eNB transmissions?

[Vikas Jain]

Thanks Paul for the information. Looked at the rf_uhd functions for the
timed send and receive, along with the run_thread() function in
srsenb/src/phy/txrx.cc which seems to be driving the notion of tti.
Following is what I could understand.

(1) As you mentioned, USRP doesn't have any concept of subframe.
(2) Assuming a sample rate of 11.52 MHz, the Linux host (in the
txrx::run_thread() function) continually requests (via uhd streamer's recv
primitive) a batch of 11520 samples (=1 subframe) in every iteration. The
64-bit timestamp (obtained from the timestamp field in CHDR header) of the
very first I/Q sample received at Linux host is mapped to a start TTI
value, which happens to be SFN=1023, subframe index = 6 in srsLTE
implementation.
(3) Following this, the Linux host essentially establishes an association
between the USRP time and the internal TTI value. TTI value is internally
maintained in srsLTE stack and is incremented thereon, for every received
batch of 11520 samples.
(4) In the srsLTE implementation, the lead time for TX is set to 4
subframes i.e. TX samples are prepared for TTI = n+4, when I/Q samples are
received for TTI=n. The notion of n+4 for transmitting the TX samples is
indicated by setting the timestamp field in TX I/Q samples to be = RX
timestamp (for TTI = n) + 4ms

So, essentially, the entire timeline in the srsLTE stack is driven by the
timestamp in RX I/Q samples and the TTI values is only needed to be
maintained in srsLTE stack only. Could you confirm if this is the correct
understanding?

I had one question regarding the timestamp field in the CHDR header. The
field is 64-bit in size. Noticed that the USRP is reporting clock ticks in
this 64-bit timestamp field. Do you know if the USRP implementation uses up
to all the 64-bits? i.e. can we assume that this field will never
wrap-around?

Regarding your comment about the pdsch_enodeb example, is it correct to say
that as soon as the USRP receives 11520 samples (assuming sampling rate is
set to 11.52 MHz), it transmits those as one subframe over the air?  With
this approach, some pdsch_enodeb implementation could potentially overwhelm
the USRP, if say, it sent many such batches of 11520 samples in a short
amount of time (< 1ms). Are there any buffering limits to what could be
buffered in USRP in such cases, beyond which USRP may be would drop any
incoming samples?

Thanks.


On Mon, Aug 10, 2020 at 4:18 AM Paul Sutton <paul at softwareradiosystems.com>
wrote:

> Hi Vikas,
>
> The USRP doesn't have any concept of subframes or subframe number.
> Instead, most UHD devices maintain an internal clock (based on ADC clock I
> believe) and support timestamped send/receive. srsUE and srsENB
> applications use these functions to determine the timestamp of received
> samples and to instruct the USRP to transmit samples at a specific time.
> For reference, see rf_uhd_recv_with_time and rf_uhd_send_timed in
> https://github.com/srsLTE/srsLTE/blob/master/lib/src/phy/rf/rf_uhd_imp.c
>
> The pdsch_enodeb example is different in that it is transmit-only. In this
> case, the application simply sets the transmit rate on the USRP and then
> continuously streams samples to it, knowing that they will be sent in
> sequence at the correct rate.
>
> Best regards,
> Paul
>
> On 08/08/2020 18:45, Vikas Jain wrote:
>
> Dear Community,
>
> I have two USRP B210 boards, each connected to a Linux host over USB. One
> Linux host is running the example program lib/examples/pdsch_enodeb.c and
> the other linux host is running the lib/examples/pdsch_ue.c. The UE side is
> able to successfully decode PSS/SSS/PBCH and subsequently decode all the
> PDSCH subframe transmissions.
>
> On the eNB side, I am running the pdsch_enodeb program with MCS =1 and PRB
> = 50, which translates to sampling rate of 11.52 MHz, which means 11520 I/Q
> samples per subframe (1ms).  The  pdsch_enode program invokes
> srslte_rf_send_multi() API to send the I/Q samples, which does not have any
> notion of time.  The I/Q samples for every subframe are simply transmitted
> asynchronously over USB one after the other. Please see the attached eNB
> USB wireshark trace (collected from one of the runs) showing I/Q sample
> transmission for two consecutive subframes. I/Q samples for first subframe
> is sent in a span of ~590us and the second subframe's I/Q samples are sent
> immediately after it in a span of ~700 us; similarly, other subframes
> follow right after this and so on.
>
> Following are the questions:
>
> (1) How does USRP determine the set of USB I/Q packets that make up one
> subframe? From the Wireshark trace, I couldn't see any fields in the CHDR
> header that would indicate the group of USB I/Q packets which constitute
> one subframe?
> (2) I presume USRP internally has a notion of OTA subframe boundary time,
> which is strictly maintained. Is this correct?
> (3) How is the OTA subframe number determined in USRP for a group of USB
> I/Q packets (for one subframe) received from Linux host?
> (4) How is it ensured that the USRP is not overwhelmed or starved for USB
> I/Q packets being received from Linux host? From the Wireshark trace, it
> seems that the Linux host application just sends the I/Q packets one after
> the other, without any regards to USRP aspects.
> (5) Does Linux host know the OTA subframe number in which the USB I/Q
> packets (sent over USB link) were actually transmitted over the air? I
> presume such association would be needed to correlate e.g. HARQ ACK for the
> PDSCH transmissions etc.
>
> Will appreciate any help in understanding the above. If there is any
> document or material on these aspects that can help understand how subframe
> timing is managed between USRP and Linux host, it will be very helpful.
>
>
> Thanks.
>
>
> _______________________________________________
> srslte-users mailing listsrslte-users at lists.softwareradiosystems.comhttp://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>
>
> --
> ________________________________________________________________
> Paul Sutton Ph.D.
>
> Software Radio Systems (SRS)http://www.softwareradiosystems.compaul@softwareradiosystems.com
>
> PGP Key ID: 3B4A5292
> Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292
> ________________________________________________________________
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20200816/b25ecf21/attachment.htm>