[srsran-users] 5g using zmq questions
J Giovatto
jgiovatto at adjacentlink.com
Sun Nov 6 17:52:47 UTC 2022
Hi Andre,
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.
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20221106/0be9d249/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zmq_zeros.patch
Type: text/x-patch
Size: 1173 bytes
Desc: not available
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20221106/0be9d249/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20221106/0be9d249/attachment.sig>
More information about the srsran-users
mailing list