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

[Paul Sutton]

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 list
> srslte-users at lists.softwareradiosystems.com
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users

-- 
________________________________________________________________
Paul Sutton Ph.D.

Software Radio Systems (SRS)
http://www.softwareradiosystems.com
paul at 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/20200810/e2a74f20/attachment.htm>