[srslte-users] A question about the code scheduler_metric.cc

Michael Seguin mpseguin at buffalo.edu
Thu May 13 13:07:17 UTC 2021


Hello Francisco,

I tried something like that where I didn't call the allocate_user(user) but
still saw metric trace data from it, but from what you are saying the base
station probably bypassed that code, and allocated the user after a certain
time.

void dl_metric_rr::sched_users(std::map<uint16_t, sched_ue>& ue_db,
dl_sf_sched_itf* tti_sched)
{
  tti_alloc = tti_sched;

  if (ue_db.empty()) {
    return;
  }

  // give priority in a time-domain RR basis.
  uint32_t priority_idx = tti_alloc->get_tti_tx_dl() %
(uint32_t)ue_db.size();
  auto     iter         = ue_db.begin();
  std::advance(iter, priority_idx);
  for (uint32_t ue_count = 0; ue_count < ue_db.size(); ++iter, ++ue_count) {
    if (iter == ue_db.end()) {
      iter = ue_db.begin(); // wrap around
    }
    if (ue_count == 1) {
      sched_ue* user = &iter->second;
      allocate_user(user);
    }
  }
}

I put a if statement so that only when the ue_count = 1 which would be the
second iteration or the first UE in the loop I believe. Might be
misunderstanding it though.

So from my understanding the dl_metric_rr is doing pre allocation of
resources. There is probably another function correct that determines what
RB was assigned to an UE at a given TTI? Is that what the scheduler_ue.cc
code is for in the srsenb/src/stack/mac/ location.

Thanks,

Mike Seguin


On Thu, May 13, 2021 at 12:42 PM Francisco Paisana <
francisco.paisana at softwareradiosystems.com> wrote:

> To avoid the UE from being allocated at all, you just don't call
> "allocate_user(user)" for the respective user, in the code snippet you
> shared in your first email.
>
> Kind Regards,
> Francisco
>
>
> On Thu, May 13, 2021 at 1:40 PM Francisco Paisana <
> francisco.paisana at softwareradiosystems.com> wrote:
>
>> Are you just altering the scheduling algorithm, aka dl_metric_rr? If so,
>> one option would be to create a container (e.g. map) with the "history" of
>> the UE allocations, in particular, the last TTI when the UE was allocated.
>> Then if the difference between the current TTI and last TTI is lower than a
>> certain threshold, you don't allocate the UE.
>>
>> However, take into account that you can't delay a UE allocation for too
>> long. SRB transmissions are critical for the whole UE state machine. If you
>> delay a UE transmission too much (several seconds), the eNB may decide to
>> release the UE due to inactivity.
>>
>> Kind Regards,
>> Francisco
>>
>>
>> On Thu, May 13, 2021 at 1:25 PM Michael Seguin <mpseguin at buffalo.edu>
>> wrote:
>>
>>> Hello Francisco,
>>>
>>> Is there any function that could say could stop a ue from being
>>> scheduled at all?
>>>
>>> For example, I want to hold a UE from being scheduled at all to build up
>>> the buffer state.
>>>
>>> Thanks,
>>>
>>> Mike Seguin
>>>
>>>
>>>
>>> On Thu, May 13, 2021, 8:16 AM Francisco Paisana <
>>> francisco.paisana at softwareradiosystems.com> wrote:
>>>
>>>> Hey Michael,
>>>>
>>>> That's the general idea of the priority_idx. However, it is not
>>>> guaranteed that a UE gets allocated in its priority "turn". For instance,
>>>> if, for priority idx = 0, UE 0 doesn't have any data to transmit, then the
>>>> scheduler will try to allocate the UE 1 instead. Furthermore, the scheduler
>>>> might allocate multiple UEs in the same TTI, if a given UE allocation
>>>> didn't fill the whole bandwidth.
>>>>
>>>> Kind Regards,
>>>> Francisco
>>>>
>>>>
>>>> On Thu, May 13, 2021 at 8:56 AM Michael Seguin <mpseguin at buffalo.edu>
>>>> wrote:
>>>>
>>>>> Hello srsLTE users,
>>>>>
>>>>> In the metric_scheduler.cc in the folder srsenb/src/stack/mac
>>>>>
>>>>> line 51 has a priority_idx. If that was changed to randomly pick a
>>>>> value would that change the user that gets allocated ? Instead of doing it
>>>>> based on TTI.
>>>>>
>>>>> Say we have two UEs, a base station, and an EPC.
>>>>> Priority_idx would be
>>>>> 0 then 1 then 2 then 0 then 1 then 2
>>>>>
>>>>> If I changed it to
>>>>> 2 then 1 then 0 then 2 then 1 then 2 then 1 then 1 then 0
>>>>>
>>>>> Would that change the order in which the UEs get allocated ?
>>>>>
>>>>> Thanks for all the help, very new to all this!
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free.
>>>>> www.avast.com
>>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
>>>>> <#m_-384682496135881640_m_2408756368856101987_m_-9092310830375856053_m_-6068502886421035500_m_-1747207416978121560_m_-726195664335574245_m_-5946548363992850858_m_-1162550078035873520_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>>> _______________________________________________
>>>>> srslte-users mailing list
>>>>> srslte-users at lists.softwareradiosystems.com
>>>>> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20210513/f144bc4d/attachment.htm>


More information about the srsran-users mailing list