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

Wed May 19 00:14:32 UTC 2021

Hey Michael,

> 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.

It would be the second iteration, and the second UE in the loop.

The code you showed would still allocate one UE per TTI in a round-robin
fashion (remember that priority_idx is always changing, and so is the
starting iterator position due to the "std::advance(iter, priority_idx);"
call). Thus, you would still see all UEs getting allocated in
different ttis if they have data.

> 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.

That is correct.

> I guess I should simplify my question. If Allocate_user(user) is not
called in the function scheduler_metric.cc and I send a ping from ENB to
UE. Will I see a bit rate of zero or will the ENB will allocate in some
other way.

If the metric didnt allocate the user in the DL, the user should not get
any DL grant. However, I don't think your code is doing that.

Maybe you could experiment running the test sched_test_rand in debug mode,
and placing a breakpoint to see what's happening in the dl metric code.

Kind Regards,
Francisco

On Mon, May 17, 2021 at 3:00 PM Michael Seguin <mpseguin at buffalo.edu> wrote:

> Hello SrsLTE,
>
> I guess I should simplify my question. If Allocate_user(user) is not
> called in the function scheduler_metric.cc and I send a ping from ENB to
> UE. Will I see a bit rate of zero or will the ENB will allocate in some
> other way.
>
> From somw experiments I did, it looks like the Base Station is allocated
> some other way, not sure where though.
>
> Thanks,
>
> Mike Seguin
>
> On Thursday, May 13, 2021, Michael Seguin <mpseguin at buffalo.edu> wrote:
>
>> 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_-3910198670203079262_m_-430610901850942575_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/20210519/5840a427/attachment.htm>