SMARTPHONES DISCONNECT FROM srsRAN LibreCellular after 15-20 minutes using LimeSDR Mini

Hi everybody,

I have tested the srsRAN from LibreCellular using LimeSDR mini v1 and v2. I observed that the 4G smartphones (Motorola and Samsung) that I am using in the tests just disconnect from the eNB after running for 15-20 minutes. It seems something related with time_adv_nsamples, since when the disconnection occurs the offset changes abruptly from 9 to 16 or even for higher values….as shown below. Has anyone had this same problem? This problem does not occur using the original version of srsRAN and the soapy. The behavior is the same for LimeSDR v1 and v2.

/home/innovatech/Desktop_myriadrf/srsRAN/srsenb/src/enb_cfg_parser.cc:1507: Force DL EARFCN for cell PCI=1 to 9310

Opening 1 channels in RF device=lime with args=index=0,rxant=LNAH,txant=BAND2,cal=all,refclk=10e6

Supported RF device list: UHD soapy lime file

Number of requested channels: 1

Found device #0: LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1D90FA6B92DE88

Reference clock 10.00 MHz

Initializing limesdr device

Setting reference clock to 10.00 MHz

Using external reference clock requires hardware modification (R59/R62)

Setup RX stream 0

Setup TX stream 0

RX antenna/s set to: LNAH

TX antenna/s set to: BAND2

==== eNodeB started ===

Type to view trace

RX sampling rate: 5.76

Setting analog RX LPF BW to: 3.75

TX sampling rate: 5.76

Setting analog TX LPF BW to: 5.00

Setting manual TX/RX offset to 73 samples

Setting frequency: DL=768.0 Mhz, UL=713.0 MHz for cc_idx=0 nof_prb=25

Calibrating RX channel: 0, BW: 3.75

Calibrating TX channel: 0, BW: 3.75

RACH: tti=3241, cc=0, pci=1, preamble=13, offset=9, temp_crnti=0x46

User 0x46 connected

RACH: tti=5041, cc=0, pci=1, preamble=24, offset=9, temp_crnti=0x47

User 0x47 connected

Disconnecting rnti=0x46.

RACH: tti=3741, cc=0, pci=1, preamble=37, offset=9, temp_crnti=0x48

User 0x48 connected

Disconnecting rnti=0x48.

RACH: tti=3301, cc=0, pci=1, preamble=20, offset=9, temp_crnti=0x49

User 0x49 connected

Disconnecting rnti=0x49.

RACH: tti=3961, cc=0, pci=1, preamble=4, offset=9, temp_crnti=0x4a

User 0x4a connected

Disconnecting rnti=0x4a.

Disconnecting rnti=0x47.

RACH: tti=3851, cc=0, pci=1, preamble=26, offset=9, temp_crnti=0x4b

User 0x4b connected

RACH: tti=6841, cc=0, pci=1, preamble=41, offset=9, temp_crnti=0x4c

User 0x4c connected

Disconnecting rnti=0x4b.

RACH: tti=8681, cc=0, pci=1, preamble=5, offset=9, temp_crnti=0x4d

User 0x4d connected

Disconnecting rnti=0x4d.

RACH: tti=9581, cc=0, pci=1, preamble=25, offset=9, temp_crnti=0x4e

User 0x4e connected

Disconnecting rnti=0x4e.

Disconnecting rnti=0x4c.

RACH: tti=7001, cc=0, pci=1, preamble=51, offset=9, temp_crnti=0x4f

User 0x4f connected

Disconnecting rnti=0x4f.

RACH: tti=9911, cc=0, pci=1, preamble=31, offset=9, temp_crnti=0x50

User 0x50 connected

Disconnecting rnti=0x50.

RACH: tti=8541, cc=0, pci=1, preamble=49, offset=9, temp_crnti=0x51

User 0x51 connected

RACH: tti=8361, cc=0, pci=1, preamble=31, offset=16, temp_crnti=0x52

RACH: tti=8381, cc=0, pci=1, preamble=2, offset=29, temp_crnti=0x53

RACH: tti=8401, cc=0, pci=1, preamble=17, offset=16, temp_crnti=0x54

RACH: tti=8421, cc=0, pci=1, preamble=43, offset=16, temp_crnti=0x55

Disconnecting rnti=0x52.

Disconnecting rnti=0x53.

Disconnecting rnti=0x54.

Disconnecting rnti=0x55.

RACH: tti=8551, cc=0, pci=1, preamble=49, offset=16, temp_crnti=0x56

RACH: tti=8571, cc=0, pci=1, preamble=48, offset=16, temp_crnti=0x57

RACH: tti=8591, cc=0, pci=1, preamble=28, offset=16, temp_crnti=0x58

RACH: tti=8611, cc=0, pci=1, preamble=7, offset=16, temp_crnti=0x59

Disconnecting rnti=0x56.

RACH: tti=8631, cc=0, pci=1, preamble=2, offset=29, temp_crnti=0x5a

Disconnecting rnti=0x57.

Yes, @pgreenland has experienced this also, see:

Based on which @Zack tested, but could not recreate the problem. I also wondered if time_adv_nsamples could have some part to play. I think the only way to try and tune this parameter may be by trial and error. Perhaps you could test after increasing and decreasing the value, over a number of runs to at each setting and calculating the average uptime.

Can you please provide details of:

  • O/S version
  • Lime Suite version
  • srsRAN version

And how you installed the latter two, i.e. packages or from source. It would be good to try and recreate this. Thanks also for reporting the issue, it’s most helpful!

Hi All,

Well remembered @andrewback - I haven’t made too much more progress on this yet from my side.

My last tinkering session, I found that using a Mini v2 with srsRAN through SoapySDR appeared to let me pass the 20 minute boundary. Using it via the directly integrated LimeSuite driver appeared to be triggering the problem.

Zach didn’t seem to believe it was a hardware issue…in the FPGA sense. If the LibreCellular is using the directly integrated Lime driver, I wonder if there could be a timestamp conversion gremlin hiding in there somewhere?

Thanks,

Phil

Doesn’t seem to happen with LimeSDR Mini v1, though. Weird that using SoapySDR appears to help with stability, as the inverse was my experience with LimeSDR USB. If it is time_adv_nsamples setting related, I wonder if using SoapySDR — i.e. with an extra layer of indirection — is somehow compensating. IIRC the parameter is to adjust for the delay through the SDR, so if this was reduced with Mini v2 vs. v1, then the introduction of additional delay could help. Anyway, this is a wild guess and could be completely wrong.

Hi Andrew,

I am using Ubuntu 20.04.6 LTS installed on mini-pc: NUC10i7FNH. I have tested with internal and external clock. In case of external clock I am using mini GPS Leo Bodnar Electronics. I have tested with:

commit b6e9c087f049f782c68c5627ed55f4e9e8bebc14 (HEAD, tag: release_22_04_LC01)

commit d3c8454f41690bc8a86a5e667881ae1f1c50703a (HEAD → lc/main, origin/lc/main, origin/HEAD)

Lime:

commit b18db192f4faca43a6739143ca75b862067d6bde (HEAD, tag: v22.09.1)

I have installed the Lime Suite and srsRAN from source following:

https://librecellular.org/user/software#

The disconnection occurs with LimeSDR mini v1 and v2. The only difference I have observed: offset = 7 when the smartphones are connected for LimeSDR mini v1 and offset = 9 when the smartphones are connected for LimeSDR mini v2.

Below are the configurations I have used:

#####################################################################

[enb]

enb_id = 0x19B

mcc = 999

mnc = 70

mme_addr = 127.0.1.100

gtp_bind_addr = 127.0.1.1

s1c_bind_addr = 127.0.1.1

s1c_bind_port = 0

n_prb = 25

tm = 1

nof_ports = 1

#####################################################################

[rf]

dl_earfcn = 9235

tx_gain = 66

rx_gain = 47

device_name = lime

device_args = index=0,rxant=LNAH,txant=BAND2,cal=all,refclk=10e6

time_adv_nsamples = 73

Best regards, Sindi.