srsRAN + LimeSDR Carrier Aggregation?

pgreenland · 8 January 2023 16:22

Hi All,

I’ve been setting up srsRAN with a LimeSDR for LTE network simulation purposes.

Following @andrewback 's great notes on the LibreCellular site (https://librecellular.org/).

Using the native lime API version of srsRAN (GitHub - myriadrf/srsRAN at native_lime_20.10.1)

I’ve got MIMO working well, with 150MBps down and 50MBps up, as measured by iperf.

I’m now looking to get carrier aggregation working but may have misunderstood the hardware and am wondering if it’s not actually possible.

LimeSDR USB has 2 x Tx and 2 x Rx channels. With each TX/RX pair sharing a LO.

I was therefore hoping to configure intra-band aggregation with 2 x 20Mhz channels next to each other. Thereby allowing the tx / rx lo’s to be sat at the midpoint with the 40Mhz fitting within the 61.44MHz bandwidth limit.

Everything seems to start ok and my UE can see the network, but upon attempting to associate I end up with lots and lots of events from srsenb and an unhappy UE.

After stopping srsenb LimeSuite confirms that both RX and TX frequencies are correct and the LO’s are set as I would expect between the two channels.

Here’s the sort of thing I see from srsRAN when using 2 x 5Mhz channels (EARFCN 2850 and 2900):

RACH:  tti=3651, cc=1, pci=4, preamble=39, offset=5, temp_crnti=0x46

               -----------------DL----------------|-------------------------UL-------------------------
rat  pci rnti  cqi  ri  mcs  brate   ok  nok  (%) | pusch  pucch  phr  mcs  brate   ok  nok  (%)    bsr
lte    4   46   15   0    6   9.1k    4    0   0% |  27.0   31.8   33   13    91k    6    0   0%    0.0
RACH:  tti=4301, cc=1, pci=4, preamble=47, offset=7, temp_crnti=0x47
RRCReestablishmentReject for rnti=0x47. Cause: Unhandled Reestablishment due to ReconfigFailure
Disconnecting rnti=0x47.
RACH:  tti=4441, cc=1, pci=4, preamble=1, offset=5, temp_crnti=0x48
lte    4   46   14   0    9   2.9k   11   12  52% |  18.1   29.6   34   22    29k    7    4  36%    0.0
lte    4   48   15   0    3   5.4k   11    0   0% |  28.1   30.2   33   18    83k   10    0   0%    0.0
RACH:  tti=5021, cc=1, pci=4, preamble=24, offset=7, temp_crnti=0x49
RRCReestablishmentReject for rnti=0x49. Cause: Unhandled Reestablishment due to ReconfigFailure
Disconnecting rnti=0x49.
RACH:  tti=5131, cc=1, pci=4, preamble=14, offset=7, temp_crnti=0x4a
RACH:  tti=5681, cc=1, pci=4, preamble=42, offset=7, temp_crnti=0x4b
RRCReestablishmentReject for rnti=0x4b. Cause: Unhandled Reestablishment due to ReconfigFailure
lte    4   46  n/a   0    0      0    0    0   0% |   n/a    n/a    0    0      0    0    0   0%    0.0
lte    4   48   15   0   15   1.6k    4   12  75% |   5.5   30.3    0   22   4.1k    1    4  80%    0.0
lte    4   4a   15   0   11   5.3k   13   12  48% |  20.7   28.7   33   19    49k   11    4  26%    0.0
lte    4   4b  n/a   0    0      0    0    0   0% |  26.9    n/a    0    0    727    1    0   0%    0.0
Disconnecting rnti=0x4b.
RACH:  tti=5821, cc=1, pci=4, preamble=51, offset=5, temp_crnti=0x4c
RACH:  tti=6381, cc=1, pci=4, preamble=40, offset=7, temp_crnti=0x4d
RRCReestablishmentReject for rnti=0x4d. Cause: Unhandled Reestablishment due to ReconfigFailure
Disconnecting rnti=0x4d.
RACH:  tti=6511, cc=1, pci=4, preamble=36, offset=5, temp_crnti=0x4e
lte    4   46   14   0    0      0    0    3 100% |   n/a    1.3    0    0      0    0    0   0%    0.0
lte    4   48  n/a   0    0      0    0    0   0% |   n/a    n/a    0    0      0    0    0   0%    0.0
lte    4   4a  n/a   0    0      0    0    0   0% |   n/a    n/a    0    0      0    0    0   0%    0.0
lte    4   4c   13   0    8   3.6k   14   15  51% |  21.1   28.6   33   19    32k   11    4  26%    0.0
lte    4   4e   12   0    4   4.0k    5    0   0% |  27.8   30.5   33   16    56k    7    0   0%    0.0
RACH:  tti=7091, cc=1, pci=4, preamble=10, offset=7, temp_crnti=0x4f
RRCReestablishmentReject for rnti=0x4f. Cause: Unhandled Reestablishment due to ReconfigFailure
Disconnecting rnti=0x4f.
RACH:  tti=7221, cc=1, pci=4, preamble=31, offset=5, temp_crnti=0x50
lte    4   46  n/a   0    0      0    0    0   0% |   n/a    n/a    0    0      0    0    0   0%    0.0
lte    4   48  n/a   0    0      0    0    0   0% |   n/a    n/a    0    0      0    0    0   0%    0.0
lte    4   4a  n/a   0    0      0    0    0   0% |   n/a    n/a    0    0      0    0    0   0%    0.0
lte    4   4c  n/a   0    0      0    0    0   0% |   n/a    n/a    0    0      0    0    0   0%    0.0
lte    4   4e   15   0   12   2.4k    9   12  57% |  14.1   30.3   34   22    17k    4    4  50%    0.0
lte    4   50   15   0   10   6.3k   13   12  48% |  21.0   30.6   33   18    57k   11    4  26%    0.0
RACH:  tti=7891, cc=0, pci=1, preamble=36, offset=7, temp_crnti=0x51
RRCReestablishmentReject for rnti=0x51. Cause: Unhandled Reestablishment due to ReconfigFailure
Disconnecting rnti=0x51.
RACH:  tti=8011, cc=0, pci=1, preamble=45, offset=7, temp_crnti=0x52
lte    4   46  n/a   0    0      0    0    0   0% |   n/a    n/a    0    0      0    0    0   0%    0.0
lte    4   48  n/a   0    0      0    0    0   0% |   n/a    n/a    0    0      0    0    0   0%    0.0
lte    4   4a  n/a   0    0      0    0    0   0% |   n/a    n/a    0    0      0    0    0   0%    0.0
lte    4   4c   12   0    0      0    0    3 100% |   n/a    5.0    0    0      0    0    0   0%    0.0
lte    4   4e  n/a   0    0      0    0    0   0% |   n/a    n/a    0    0      0    0    0   0%    0.0
lte    4   50    5   0    0      0    0    0   0% |   n/a   -0.3    0    0      0    0    0   0%    0.0
lte    1   52   15   0    8   4.5k   15   12  44% |  18.2   28.9   33   18    40k   10    4  28%    0.0
RACH:  tti=8821, cc=0, pci=1, preamble=17, offset=9, temp_crnti=0x53
RRCReestablishmentReject for rnti=0x53. Cause: Unhandled Reestablishment due to ReconfigFailure
Disconnecting rnti=0x53.
RACH:  tti=8941, cc=0, pci=1, preamble=11, offset=7, temp_crnti=0x54
RACH:  tti=9741, cc=0, pci=1, preamble=16, offset=7, temp_crnti=0x55
RRCReestablishmentReject for rnti=0x55. Cause: Unhandled Reestablishment due to ReconfigFailure

I’m a lowly embedded engineer rather than an RF guy so any pointers appreciated…am I merrily wandering down a dead end track?

Thanks,

Phil

andrewback · 8 January 2023 17:33

I’m afraid I can’t help, as I’ve not attempted to get CA up and running.

Tagging @Zack in case he can spot anything obvious.

Failing which you might want to try posting to the srsRAN mailing list. The native LMS API implementation is not supported, but you could try using SoapySDR also just to be on an officially supported stack.

pgreenland · 8 January 2023 17:49

Thanks for the speedy reply…hopefully it wasn’t just my shameless name dropping that got your attention .

I subsequently found a ticket in the main srsRAN repo that asked a similar question. One of the srsRAN devs appeared to believe that the LimeSDR wouldn’t be capable of it.

github.com/srsran/srsRAN

Low TX Power of SCELL in Carrier Aggregation

opened 07:35PM - 18 Nov 20 UTC

closed 09:00AM - 26 Nov 20 UTC

CassianoDev

## Issue Description ## When up the network at 2 xCA, a SCELL has a weak signal. ## Setup Details ## Ubuntu 20,04, Intel Core i74790, 32GBRAM, LimeSDR USB 3.0 Board v1.4 , srsLTE 20.10 commit fd5cde525 on branch master, UE: S7 EDGE g935f (exynos version) ## Expected Behavior ## SCELL power equivalent to the primary cell. ## Actual Behaviour ## SCELL power is low! Primary Cell: RSRP: -92, RSRQ: -4, RSSI: -74, SINR: 33 SCELL: RSRP: -130, RSRQ: -21, SINR: -16 ## Steps to reproduce the problem ## Install soapy drivers for lms7, build last LimeSuite, configure rr.conf for: cell_list = ( { rf_port = 0; cell_id = 0x01; tac = 0x0001; pci = 1; root_seq_idx = 204; dl_earfcn = 2850; // CA cells scell_list = ( {cell_id = 0x02; cross_carrier_scheduling = false; scheduling_cell_id = 0x01; ul_allowed = true} ) }, { rf_port = 1; cell_id = 0x02; tac = 0x0001; pci = 4; root_seq_idx = 205; dl_earfcn = 3050; // CA cells scell_list = ( {cell_id = 0x01; cross_carrier_scheduling = false; scheduling_cell_id = 0x02; ul_allowed = true} ) } Attach S7 EDGE g935f (exynos version) run *#0011# and view radio info ## Additional Information ## I tried to change the power by tx_power but without success! Log All Level Info: [log.zip](https://github.com/srsLTE/srsLTE/files/5562322/log.zip)

The example given would match mine, all be it with 20Mhz channels rather than the 5Mhz I selected (although I tried 20Mhz with the same outcome).

It would be good to know if it the LimeSDR should theoretically support it RF wise, with the two channels next to each other as I was planning?

If it should be possible, all be it with limitations the mainline repo + soapy was going to be my next port of call.

pgreenland · 18 February 2023 20:11

I’ve not made any progress with this, but hate when threads aren’t closed.

For any other intrepid travellers who have similar crazy ideas. My plan was to set the LOs in-between the frequencies of the two CA channels. Then frequency shift the baseband for one TX up and the other TX down. Doing the inverse for the RX channels.

I was originally planning on doing this in GNURadio, with some zeromq plumbing but I suspect I’ll fall foul of the timestamping requirements.

It may be possible to hack the srsRAN source to perform some sample rate conversions, frequency shifts and hack the filter widths but my SDR foo isn’t that strong. Too much work for very little gain…although it would be nice to see it working.

Turns out a MIMO transceiver should probably be left to what it was designed to do.