Ensure equal PNF timing pace

If VNF and PNF are deployed through different processes, it's crucial to
maintain synchronization and ensure smooth operation. This commit
addresses the need to keep the VNF slot ahead of 2 (as required for
network deployment), while ensuring that PNFs wait appropriately to
avoid overtaking the slot. Specifically, this involves measuring slot
duration and implementing a wait mechanism to ensure that PNFs do not
exceed a slot duration of 300 microseconds. This ensures proper smooth
operation, especially in the case of RFsim.

nfapi/oai_integration/nfapi_pnf.c

@@ -2258,8 +2258,32 @@ void oai_subframe_ind(uint16_t sfn, uint16_t sf) {
   }
 }
 
+#define SLOT_DURATION 300  // in microseconds
+static void maybe_slow_down_pnf(void)
+{
+  /* uses a usleep to wait for approximately the same time period (300 us) */
+  static struct timespec last_execution = {0};
+  struct timespec current_execution;
+  clock_gettime(CLOCK_REALTIME, &current_execution);
+  // Calculate elapsed time since last execution
+  long elapsed_time = (current_execution.tv_sec - last_execution.tv_sec) * 1000000; // Convert seconds to microseconds
+  elapsed_time += (current_execution.tv_nsec - last_execution.tv_nsec) / 1000; // Convert nanoseconds to microseconds
+  if (elapsed_time < SLOT_DURATION)
+    usleep(SLOT_DURATION - elapsed_time);
+  // Update last_execution time
+  last_execution = current_execution;
+}
+
 void handle_nr_slot_ind(uint16_t sfn, uint16_t slot)
 {
+  if (IS_SOFTMODEM_RFSIM) {
+    // RFsim can run faster than realtime. However, we need to give the VNF
+    // some time to send an answer, so the PNF can run faster than realtime,
+    // but it should not too much. This function will "maybe" slow down, up to
+    // a slot length of SLOT_DURATION us
+    maybe_slow_down_pnf();
+  }
+    
     //send VNF slot indication, which is aligned with TX thread, so that it can call the scheduler
     //we give four additional slots (2ms) which should be enough time for the VNF to
     //answer