[srsran-users] 5g using zmq questions

[Andre Puschmann]

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