[srsran-users] srsRAN LTE/5G simulation question

[J Giovatto]

Hi
My best guess notes in line.

On 5/10/24 18:04, JOE LUKOSE wrote:
> Thanks Joe for for the quick response, that was helpful.
> Please bear with me, I just have a few follow up questions.
> 1) Ignoring the EPC for the moment, is there any software within
> the UE and eNodeB that would operate incorrectly given the 1 frame per 
> hour
> thought experiment? i.e., can't help but notice the emphasis on the word
> "most" in your reply.
Im not sure if it is 100% time agnostic, its been a while but I did some 
experiments a ways back and knocked it down to 1 *subframe *per 10 
seconds or so to step thru the acquisition states and not get blasted by 
logs.
> 2) Are the eNodeB and UE really in lock step at the frame rate (10ms) 
> or is
> it the subframe rate (1ms)? Seems like it would have to be at the
> subframe rate (1ms) in order to support TDD modes as well as satisfy
> hybrid ARQ process latencies in FDD.
Correct again its been a while were are talking subframe here.
> 3) Does a ZMQ packet contain a frame or a subframe?

Im pretty sure its a stream of subframes I/Q data.

You will have to look at the code and the phy/rf interface and 
understand how that works.

lib/include/srsran/phy/rf/rf.h

for example srsran_rf_recv_with_time(...)

this flows from the radio impl (zmq) back to the phy controlling the 
"pulse" of the system via some callbacks etc.

Id say crank up the logs and sprinkle a few sleep(1) in the flow and 
see, thats how I got hooked.

> 4) Could you elaborate on any suspected concerns within the EPC?
> how does the EPC maintain its clock? i.e. what informs the EPC what 
> time it is?

Since we do all our emulation in a single box with no external time 
source I'd say it has to been linux time to manage timers.

Yea here it is ...

A quick grep for time in the epc dir:

src/mme/nas.cc

bool nas::start_t3413()
{
    int fdt = timerfd_create(CLOCK_MONOTONIC, 0);
   if (fdt < 0) {
     m_logger.error("Error creating timer. %s", strerror(errno));
     return false;
   }

Joe

> Joe
>> On 05/10/2024 8:15 AM CDT J Giovatto <jgiovatto at adjacentlink.com> wrote:
>>
>> Hi Joe,
>>
>> I think you are correct in theory you could pass 1 frame per hour and 
>> *most *of the ue and enb software would NOT know the difference 
>> because the timer/tick is rx/tx frame based.
>>
>> With the TCP ZMQ  UL and DL transport the nodes are in lock step 
>> push/pull connection.
>>
>> I think you might have problems with the EPC at some point if it 
>> slows down too much.
>>
>> Joe
>>
>> On 5/10/24 08:42, JOE LUKOSE wrote:
>>> Hello Community,
>>> I have a question regarding the feasibility of using the srsRAN 
>>> LTE/5G software stack in a simulation only environment using ZeroMQ 
>>> (no SDRs) with a GNU "radio" broker to interconnect n UEs to m eNodeBs.
>>> In the simulation environment, the broker models multiple channel(s) 
>>> and sums signals within channel matrix for each receiver. The 
>>> simulation is computationally intensive and is expected to run much 
>>> slower than real time.
>>> In this environment is simulation time completely decoupled from 
>>> srsRAN stack real time constraints?
>>> The srsRAN document states support for ZeroMQ interface for 
>>> transmitting/receiving data packets between UE and eNodeB.
>>>
>>> This suggests that the srsRAN software stack interface between eNB 
>>> and UE is data driven and not bound by strict real-time constraints. 
>>> Is this a proper understanding? Any clarification you can provide is 
>>> greatly appreciated.
>>> Thanks,
>>> Joe
>>>
>>> _______________________________________________
>>> srsran-users mailing list
>>> srsran-users at lists.srsran.com
>>> https://lists.srsran.com/mailman/listinfo/srsran-users
>>
>> _______________________________________________
>> 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/20240510/a3ce12e1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4079 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20240510/a3ce12e1/attachment-0001.bin>