[srsran-users] 5g using zmq questions
Andre Puschmann
andre.puschmann at srs.io
Mon Nov 7 08:16:50 UTC 2022
Hi Joe,
On 6/11/22 18:52, J Giovatto wrote:
> As always, thanks for your timely response.
>
> I think I found something see notes below.
>
> 1) using the srsran_resample_arb or the avg code does not seem to make a
> difference, I think I stay with the resample method, seems easier to use
> w/o risk of buffer overrun.
Sounds good. Thanks for checking and confirming.
>
> 2) I was able to shmem rf working if and only if I start the ue after
> the enb starts updating frames, AND there is no loss on the ue side when
> its starts to recv frames.
>
> Here is a ue log block, highlighted is the warning I see when the ue
> starts and receives zeros such as the case when the enb is not up and
> sending yet. Once I see
>
> the Cell selection fail the ue never tries goes back to cell search.
The 5G UE is not as developed as the 4G one. It was really just meant as
a basic testing tool - currently only really exercising the happy path.
Also the UE state machines for cell search error handling, etc. aren't
well implemented - and that's what you've just come across.
It's known but I am afraid there is currently no plan to work on it on
our side.
However, in case you (or anybody else) is willing to go down that road
and implement it we are more than happy to assist and review contributions.
Thanks
Andre
>
>
> 2022-11-06T17:36:18.517436 [STCK ] [I] Triggering NAS switch on
> 2022-11-06T17:36:18.517445 [NAS5G ] [I] Switching on
> 2022-11-06T17:36:18.518345 [USIM ] [I] Read Home PLMN Id=90170
> 2022-11-06T17:36:18.518345 [NAS5G ] [I] Requesting IMSI attach
> (IMSI=901700123456780)
> 2022-11-06T17:36:18.518367 [NAS5G ] [I] Sending Registration Request
> 2022-11-06T17:36:18.518368 [RRC-NR ] [I] Proc "Setup Request" -
> Initiation of Setup request procedure
> 2022-11-06T17:36:18.518369 [RRC-NR ] [I] Proc "Cell Selection" - Starting...
> 2022-11-06T17:36:18.518379 [PHY-SA ] [I] [ 0] Cell Search: Going to IDLE
> 2022-11-06T17:36:18.518381 [PHY-SA ] [I] [ 0] Tuning Rx channel 0 to
> 1842.50 MHz
> 2022-11-06T17:36:18.518411 [RF ] [I] Mapping RF channel 0 (device=0,
> channel=0) to logical carrier 0 on f_rx=1842.5 MHz
> 2022-11-06T17:36:18.518431 [PHY-SA ] [I] [ 0] Cell search: Setting
> SSB configuration srate=11.52 MHz; c-freq=1842.500 MHz; ss-freq=1842.050
> MHz; scs=15kHz; pattern=A; duplex=fdd;
> 2022-11-06T17:36:18.895240 [PHY-SA ] [I] [ 0] Cell Search: Running
> Cell search state
> 2022-11-06T17:36:19.145715 [RRC-NR ] [I] Proc "Cell Selection" -
> Completed with failure.
> 2022-11-06T17:36:19.145731 [RRC-NR ] [W] Could not finish setup request.
> Deallocating dedicatedInfoNAS PDU
> 2022-11-06T17:36:19.767718 [MAC ] [I] [ 0] BSR:
> triggered_bsr_type=none, LCID QUEUE status: 0: 0 1: 0
> 2022-11-06T17:36:19.794576 [STCK ] [I] tti_tprof: {mean, max, min} =
> {0.00, 0, 0} msec
> 2022-11-06T17:36:20.879717 [MAC ] [I] [ 0] BSR:
> triggered_bsr_type=none, LCID QUEUE status: 0: 0 1: 0
> 2022-11-06T17:36:20.934177 [STCK ] [I] tti_tprof: {mean, max, min} =
> {0.00, 0, 0} msec
> 2022-11-06T17:36:21.993686 [MAC ] [I] [ 0] BSR:
> triggered_bsr_type=none, LCID QUEUE status: 0: 0 1: 0
> 2022-11-06T17:36:22.076760 [STCK ] [I] tti_tprof: {mean, max, min} =
> {0.00, 0, 0} msec
>
>
> So I tried to create the same behavior using zmq by sending zeors for
> the first 1000 frames, (see patch attached). With this change the ue
> will end up in the same state and never come in even after the enb sends
> the actual baseband frames.
>
> Also I went back and tried zmq with the standard 4g config and it does
> work as expected, see ue 4g log below.
>
> Found Cell: Mode=FDD, PCI=1, PRB=50, Ports=1, CP=Normal, CFO=-0.0 KHz
> Found PLMN: Id=00101, TAC=7
> MBMS service started. Service id=0, port=4321, lcid=1
> Random Access Transmission: seq=1, tti=4101, ra-rnti=0x2
> BBRRC Connected
> BRandom Access Complete. c-rnti=0x46, ta=0
> BBBBBBBBBBBBBNetwork attach successful. IP: 172.16.0.3
> Failed to setup/configure GW interface
> BBBBBBBBSoftware Radio Systems RAN (srsRAN) 6/11/2022 17:46:47 TZ:0
> BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB^CStopping ..
> BBBReceived RRC Connection Release (releaseCause: other)
> BBBBBBBBBBRRC IDLE
>
>
> So this behavior seems to be limited to the 5g ue when there is some
> initial loss in the stream. Im not sure how the real radios handle this
> but maybe there is some sort of reset path that needs to be taken ?
>
> Thanks
>
> Joe
>
>
>
>
> On 11/2/22 05:56, Andre Puschmann wrote:
>> Hi Joe,
>>
>> thanks for the post. See my responses below.
>>
>> On 31/10/22 16:44, J Giovatto wrote:
>>> Hi Folks,
>>>
>>> I have some questions about the zmq rf implementation and 5g frame
>>> structure.
>>>
>>> Some background, a while back I cooked up a shared memory rf
>>> implementation.
>>>
>>> The enb and ue's would each run independently reading and writing to
>>> UL/DL shared memory segment that mapped to a frame based on common
>>> real clock time.
>>>
>>> So every millisecond there was and UL/DL exchange as required aligned
>>> with the 4 TTI offset.
>>>
>>> Shared memory was chosen since:
>>>
>>> 1) its probably the fastest method of IPC for exchanging the large
>>> I/Q data blocks while trying to keep up with the 1 msec deadline.
>>>
>>> 2) allowed for mixing multiple UL I/Q samples, supporting multiple ue's
>>>
>>> for(int i = 0; i < nsamples; ++i)
>>> {
>>> // combine the bin with i/q data
>>> element->iqdata[i] += (q[i] * mult);
>>> }
>>>
>>> 3) allowed nodes to come and go since the is no "connection" required
>>> other than to attach to the shared memory segments, startup order not
>>> important.
>>>
>>> With the obvious drawbacks that its only scalable to the performance
>>> of a single machine and needs to run realtime.
>>>
>>>
>>> I have been trying to compare to the zmq rf which is very reliable
>>> probably due to its connection orientated push/pull and timer
>>> agnostic approach.
>>>
>>> When running in 4G mode both shared memory and zmq work as expected
>>> but in 5G mode I can only get zmq working, in shem rf I am not a able
>>> to decode msgs any more.
>>
>> I am assuming you mean srsENB in SA mode and srsUE trying to
>> find/sync/attach to the NR cell?
>>
>>
>>>
>>> The main reason I am looking into 5G running with shared memory now
>>> is to see if our hardware can still keep up with the additional
>>> data/cpu load that will be required with (can we still do what we
>>> need in 1 msec ?).
>>>
>>>
>>> One difference I see is the way decimation is done in zmq, see below,
>>>
>>> for (uint32_t i = 0, n = 0; i < nsamples; i++) {
>>> // Averaging decimation
>>> cf_t avg = 0.0f;
>>> for (int j = 0; j < decim_factor; j++, n++) {
>>> avg += ptr[n];
>>> }
>>> dst[i] = avg; // divide by decim_factor later via scale
>>> }
>>>
>>> vs the way I have been using srsran_resample_arb_compute method
>>>
>>> const double sratio = srate_out / srate_in;
>>>
>>> srsran_resample_arb_t r;
>>> srsran_resample_arb_init(&r, sratio, 0);
>>>
>>> return RF_SHMEM_BYTES_X_SAMPLE(srsran_resample_arb_compute(&r,
>>> (cf_t*)data_in,
>>> (cf_t*)data_out,
>>> RF_SHMEM_SAMPLES_X_BYTE(nbytes)));
>>>
>>> In theory Im thinking that the idea is still the same, move I/Q for
>>> Enb/UE in a timely fashion, but I must be missing something.
>>>
>>> 1) is srsran_resample_arb_compute the correct choice ?
>>
>> I am not very familiar with the internals of srsran_resample_arb*()
>> but have you tried to compare the difference between both numerically?
>>
>>>
>>> 2) were changes made to zmq rf to specifically support 5g mode ?
>>
>> No. The 5G PHY changes are all transparent to the ZMQ RF.
>>
>>>
>>> 3) how does if at all the 5G "mu" factor play into the zmq
>>> implementation see link below ?
>>
>> It also doesn't play a role. For the bandwidths we support we use the
>> exact same configs that we use for LTE.
>>
>> Not much of a help I am afraid.
>>
>> Thanks
>> Andre
>
>
--
Andre Puschmann
Software Radio Systems (SRS)
https://www.srs.io
andre at srs.io
PGP/GnuPG key: 0x204A85DFEA324D58
fingerprint: 3924 1C60 D52E 81A2 1F2E 0C9D 204A 85DF EA32 4D58
More information about the srsran-users
mailing list