[srsran-users] 5g using zmq questions
J Giovatto
jgiovatto at adjacentlink.com
Tue Nov 8 13:58:01 UTC 2022
On 11/7/22 03:16, Andre Puschmann wrote:
> 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.
OK Ill take a look and see what havoc I can create 😁
Thanks
Joe
>
>
> 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
>>
>>
>
-------------- 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/20221108/b3d07d46/attachment.sig>
More information about the srsran-users
mailing list