[srsran-users] 5g using zmq questions
Guillermo Yanez
jgyanez1 at gmail.com
Tue Nov 8 16:47:52 UTC 2022
I'm doing tests with open5gs, for 4g, it works for me with zmq, although to
test 5g, I want to use UERANSIM, if they make progress they send me a tip
El mar, 8 nov 2022 a las 9:59, J Giovatto (<jgiovatto at adjacentlink.com>)
escribió:
> 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
> >>
> >>
> >
>
> _______________________________________________
> srsran-users mailing list
> srsran-users at lists.srsran.com
> https://lists.srsran.com/mailman/listinfo/srsran-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20221108/d88a8598/attachment.htm>
More information about the srsran-users
mailing list