LMS srsRAN and LimeSDR-Mini v2

Projects LibreCellular
1

Has anyone tried the LibreCellular / LMS version of srsRAN with the LimeSDR Mini v2?

I’ve been using a LimeSDR-USB with it for some time now, which has been working flawlessly.

Swapping out the LimeSDR-USB for the new LimeSDR-Mini v2 performance is exactly the same for 20 minutes (as measured with iperf between the UE and eNodeB. Connected directly via cables the UE is able to download at 75Mbit/s and upload at 50Mbit/s as expected).

After 20 mins of iperf the UE is disconnected with a stream of device connections and disconnections appearing on srsran enb’s console.

Restarting the modem doesn’t appear to help however restarting srsran enb gives you another 20 mins before the same thing happens.

The problem seems to be repeatable, I’ve just tried 3 times back to back with the Mini 2 and experienced 3 failures.

Repeated the same with the original LimeSDR-USB and no issues given the same 3 x 20 minute runs.

2

Interesting, thanks for sharing! My first thought was possible overheating, but if you can simply restart srsENB and then get another 20 minutes, it suggests something quite different.

Building up a LimeSDR Mini v2 base station for the LibreCellular CI platform is on the roadmap, but will also discuss with colleagues.

3

I initially suspected overheating too but it still does it with a big fan cooling it unfortunately.

Thanks! Let me know if your colleagues have any ideas.

4

I wondered if you were able to time a few runs, so we could confirm if it’s after some precise amount of time has elapsed.

Have thought if it could be related to sample timestamp FPGA implementation with Mini v2, but then I think it has been used fine with other cellular stacks. The other thing that occurred to me is whether the optimal time_adv_nsamples value could be different for Mini v2. I don’t know enough about this and whether it is more RFIC specific, or switching from one vendor FPGA to another could affect the delay time. From what I gather the value is found by trial and error!

Tagging @Zack in case he has any ideas.

5

Happy giving some more timings a go. Was proving a bit tricky, given having to start the enodeb, connect the modem which can take a while. Then fiddle with routing and kick off iperf.

I’ll give it a few more goes tonight and start a timer from when the enodeb is running.

I’ve currently got the timing advance set to your suggested value for the original mini. I would have expected that sort of timing error to occur randomly. This problem certainly seems to occur within a small window. My first thought was a timer misbehaving.

1 Like
6

Took me a bit longer than planned but results are in.

I timed from the enodeb process using “time”, stopping it / the timer as soon as I spotted the log going nuts.

Ran it 4 times, the last leaving the modem idle for a few mins before starting iperf just to see if it made any difference.

real 22m7.653s
real 22m12.651s
real 22m9.344s
real 22m13.454s

There’s still a small amount of timing error there (watching logs gets boring fast) but they seem to be reasonably close each time.

Do any of the above match up with a timer value?

Thanks,

Phil

7

Hi Phil,

Many thanks for this, much appreciated.

I couldn’t say regarding timer values, but maybe @Zack or @ricardas might know.

8

Has anyone in the team had a chance to take a look at this yet?

I’d quite like to get the to bottom of it. Happy to continue poking but some guidance on where I might look would be appreciated.

9

I’ll give my two cents here, but bear in mind I know very little about the complete software stack so I might be completely wrong.
These are things I’ve seen in my own project which also deals with time synchronization, so they may or may not apply here.

The packet timestamp basically reduces to a sample counter in the FPGA I think. An integer overflow somewhere might generate such issues (I have a change request on gr-limesdr for such a problem). But this seems unlikely here, At the sort of sample rates required (I assumed 20 Msps) I did some quick calculations and the issue would show up a lot sooner, in a matter of a hundred seconds or so for a 32 bit overflow. And after it overflowed it would probably no longer allow you to attach even briefly at all.

The second thing that comes to mind is the samples arriving after the timestamp expired, leading to dropped sample packets. This could be more likely here, but I have no insight into what might cause it after exactly 20 minutes.
In gr-limesdr, the function LMS_GetStreamStatus is used periodically to determine and output to console the stream status and the lms_stream_status_t struct has a number of interesting members, including droppedPackets, underrun and overrun. This could be used to potentially debug the issue.

I’ll just add that I’m also interested in the cause of the behaviour you observed.

Adrian

10

I am running LimeSDR Mini v2 for 7 hours continuously today in the background. I am using LimeSuiteGUI to stream the data using timestamp synchronization. No problems whatsoever. So the problem should be at the upper software layers. At the LimeSuite layer I see no problems.

11

Just a quick update to say that we are investigating this and will see if we can recreate the problem with srsRAN + LimeSDR Mini v2.

1 Like
12

BTW, I see this in my cabled setup as well – just over 20 minutes and my client gets knocked off, restarting ENB fixes it. I have a very controlled environment (single Linux PC with EPC and ENB running, a single UE). I can enable any kind of logging or get packet captures if that will help.

13

I’ve been meaning to continue looking into this for…a year apparently.

If it helps, I found that the 20 minute issue only occurred with the build of srsENB which supposed the lime driver directly.

When using the SoapySDR driver, with LimeSDR backend everything works fine.

i suspect there’s a gremlin hiding in the direct limesuite driver integration somewhere, but I’ve not got any further than suspecting.

14

So one thing you could try is building the (very new) branch of srsRAN_4G that has integration with Lime Suite NG:

You can have classic Lime Suite and NG installed at the same time, but for now when you run srsRAN cmake you will need to disable support for classic with -DENABLE_LIMESDR=off.

The “enb.conf” changes used with a LimeSDR USB:

device_name = limesuiteng
device_args =logLevel:3,dev0:"LimeSDR",port0:"dev0",port0_rx_path:"LNAH",port0_tx_path:"BAND2"

The available device args:

You’ll likely need to adjust these for a Mini. Looks as though at present there can be a ~10s delay after streaming starts before transmit. As I say, this is very new and on top of which I suspect that Mini support in NG is not terribly well tested, but would be interested to hear how this works out if you give it a spin. I found that with a LimeSDR USB it ran fine for around 10-12 hours, but again please bear in mind that this is a work in progress.