Understanding the Lte Mac Scheduler - some questions without answers...

[Infiel]

Hi, because there was no reply, I will try to explain my problem more clearly.

I am playing with lena-simple-epc scenario. Currently I am very interesting in deep understanding of how the MAC Scheduler (and also MAC Layer) works. It seems to be the most complicated and most expanded module for me for now. I have added a simple log information to PfFfMacScheduler (I am using it, because I am not interested in RR scheduler, it provides to much simplification to process). This log information stores information about which resource were scheduled to which UE in Downlink and Uplink. All information are collected from PfFfMacScheduler::DoSchedDlTriggerReq function, and here is a simple output:

(...)
ENB:SCHED:UL:T[9.0000000] 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
ENB:SCHED:DL:T[10.0000000] RNTI[1] 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
(...)

were T is time and for UL each number represents consecutive RB where value is equal to UE RNTI to which it was allocated. While for DL, RNTI number is showed explicit and following numbers means which RB were allocated to it (values are equal to RB number from available list). I have attached a modified .cc file, so you can analize or try it by yourself (line 959 for Uplink and 566 for downlink).

First strange thing which I have observed, that there was no DL scheduling for more than one UE in the same TTI which was the event that I want to observe (to determine  scheduler behaviour on that situations). I have added more UEs to simulation and change interpacketinterval time, but I was still unlucky. It is just a case of the type of application used, or something is wrong / I do not understand something?

The second behaviour, which I can't understand is scheduling resources by scheduler, even if I call serverApps.Stop(0.0001) and clientApps.Stop(0.0001). I have observed that applications called EpcEnbApplication and EPsSgwPgwApplication are still sending information to/from tune_device and to/from S1Interface. I read the doc, and I think I understood the purpose of those apps. But why they are sending packets all the time? Is that some signalling traffic? Is the source of RB allocation to UEs caused by that and / or some signalling? Or there is some additional tricky part, which I can't find and/or understand? It is important to me, cause I will want to test some algorithms, and I want to have ability to simply set when and which UE will be transmitting data to which UE and with what characteristic.

I will be grateful for any help.

Regards,
Michal

[Luca Costantino]

Il 06 marzo 2012 13:21, Infiel <pank...@gmail.com> ha scritto:
> First strange thing which I have observed, that there was no DL scheduling
> for more than one UE in the same TTI which was the event that I want to
> observe (to determine  scheduler behaviour on that situations). I have added
> more UEs to simulation and change interpacketinterval time, but I was still
> unlucky. It is just a case of the type of application used, or something is
> wrong / I do not understand something?

how many ues did you define? if you defined more than rbnum, of course
no ue will get more than one rb

--
Chiave pubblica http://luca.costantino.googlepages.com/luca.costantino.asc

Prima di tutto vennero a prendere gli zingari e fui contento, perché
rubacchiavano.
Poi vennero a prendere gli ebrei e stetti zitto, perché mi stavano antipatici.
Poi vennero a prendere gli omosessuali, e fui sollevato, perché mi
erano fastidiosi.
Poi vennero a prendere i comunisti, e io non dissi niente, perché non
ero comunista.
Un giorno vennero a prendere me, e non c’era rimasto nessuno a protestare.
(Martin Niemöller)

[Infiel]

I think you do not understand me correctly:

I observe something like this:

ENB:SCHED:DL:T[10.0000000] RNTI[1] 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

ENB:SCHED:DL:T[11.0000000] RNTI[2] 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
ENB:SCHED:DL:T[12.0000000] RNTI[3] 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

But I want to observe something like that:
ENB:SCHED:DL:T[10.0000000] RNTI[1] 0 1 2 3 20 21 22 23
ENB:SCHED:DL:T[10.0000000] RNTI[2] 6 7 10 11
ENB:SCHED:DL:T[10.0000000] RNTI[3] 4 5 8 9 12 13 14 15 16 17 18 19

Whivh means that in the same TTI, eNB is transmitting data to three different UEs, where RB are allocated by 2 (RBG size) and are spreaded, depending on channel quality for given frequency / time period, and number of allocated RB is different and depending on number of data waiting to sent / QoS / throughput / whatever.

W dniu wtorek, 6 marca 2012, 13:23:55 UTC+1 użytkownik Luca napisał:

W dniu wtorek, 6 marca 2012, 13:23:55 UTC+1 użytkownik Luca napisał:

[Infiel]

Really nobody knows anything? Have someone tested my code?

[Luca Costantino]

in the past few days several bugs were squashed in lena, did you
upgrade your code?

[Infiel]

no I haven't. Just need to hg clone again ?

[Luca Costantino]

hg pull
hg update
./waf build

spend some time learning how to use the mercurial system, you're gonna need it

luca

[Infiel]

heh yes I know that :) But I choose waf to learn first ;) and stay with simple, old svn for personal use.

I will let you know about progress, when I update and merge the code.

[Infiel]

Okay, updating LENA to the newest version seems to fix problem 2. Now, after apps are stopped, there is only single packet exchange in the begining of the simulation.
However, problem one still is not solved - but I try to manipulate other traffic characteristic, and I hope I will achieve what I want, or, if not, I will need to say, that there is another bug...

By the way, I want to ask you if there is any source of announcements of new bugs fixes, or I just need to update repository time to time?

[Infiel]

And, I forget, to thank you very much for help and the information!!! :)

[Luca Costantino]

i knew about some of those bugs because i was the one that reported them...

anyway...
1) your problem is still not perfectly clear to me, try to explain better :)
2) have a daily look here [0] to know what changes has occurred in lena branch

best regards
luca

[0] http://lena.cttc.es/hg/lena/

[Infiel]

Hi,

A little bit late, but here is a more complex description of my first problem:

Consider a situation, when you have a single eNB and many UEs connected to it. Uplink and Downlink bandwidth is set to 25RB as default, so the RBG size is 2. Now, at some time (TTI), eNB has data flows to transmit for two different UEs. Scheduler should split the available spectrum (25RB) between those two transmissions, and this schedule should be aware of propagation loss etc. per RB per UE, so for me, there should be visible something like this: (numbers are equall to UE ids):

ENB:SCHED:DL:T[TTI] 1 1 1 1 2 2 1 1 2 2 2 2 2 2 2 2 1 1 1 1 1 1 2 2 0

But currently I can only achieve something like this:

ENB:SCHED:DL:T[TTI] 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0
ENB:SCHED:DL:T[TTI+1] 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 0

More over I think it should be observed also behaviour like this:

ENB:SCHED:DL:T[TTI] 0 0 1 1 0 0 1 1 2 2 0 0 0 0 2 2 1 1 1 1 1 1 2 2 0

in situation when the traffic is low, and there is no need to use all available RBs (bandwidth). But, I have to admint, that I am not sure hot it is realized in LTE (still need to read some chapters about ;) )

I hope that this description is more clear for you :)

Best regards
Michal

[Marco Miozzo]

Hi Michal,

the default scheduler in Lte is the Proportional Fair one and this is the reason behind the behavior you are experiencing.
The simulator provides also a Round Robin scheduler.
For more info on the schedulers (their design and their usage) please take a look to the Sphinx documentation provided. You can find a compiled version (html and pdf) in lena wiki:
http://iptechwiki.cttc.es/LTE-EPC_Network_Simulator_%28LENA%29

Regards,
marco.

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ns-3-users/-/77xt89o-70kJ.
To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

[Infiel]

heh thanks, I think I have missed the line:

At the start of each subframe , all the RBs are assigned to a certain user.

in this description previously. So both available schedulers introduce quite a lot of simplicity. Is the more adaptive and "realistic" scheduler planned for implementation or I have to start my own implementation? Cause I need to have the behaviour previously described.

To unsubscribe from this group, send email to ns-3-users+unsubscribe@googlegroups.com.

[Marco Miozzo]

Hi,

it depends on what you means as realistic.
The two schedulers are realistic RR and PF schedulers, at least from the literature. Moreover, when the traffic is low, the scheduler stops assigning resources to users with empty RLC queues but there is no control on the actual data to transmit (i.e., ON-OFF behavior). Considering the behavior you are describing in your first example of allocation, it seems that you need an allocation based on fitting the best CQI performance of each active user. Only PF right now consider this option, but usually allocates the whole subframe to a user for balancing the throughput among users.
Anyway, the framework already has all the functionalities to implement the behavior you are describing (i.e., sub-band CQI and AMC); therefore it is only a matter of play a bit with the current scheduler implementations.

Regards,
marco.

2012/3/15 Infiel <pank...@gmail.com>

To view this discussion on the web visit https://groups.google.com/d/msg/ns-3-users/-/6OidkyTlvrAJ.

To post to this group, send email to ns-3-...@googlegroups.com.

To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.

[Nicola Baldo]

On Mar 15, 2:29 pm, Infiel <panko...@gmail.com> wrote:
> *At the start of each subframe [image: t], all the RBs are assigned to a
> certain user.*

We didn't mean to say that all the RBs are assigned to the same user.
It should read "each RB is assigned to a certain user". Thanks for
pointing this out, we'll revise the documentation accordingly.

> in this description previously. So both available schedulers introduce
> quite a lot of simplicity. Is the more adaptive and "realistic" scheduler
> planned for implementation or I have to start my own implementation? Cause
> I need to have the behaviour previously described.

I think what happens is just that you are not using frequency-
selective fading in your simulations. By doing this, you should get
the desired behavior with the PF scheduler.

To understand why, please read carefully the equations of the PF
scheduler:
http://lena.cttc.es/manual/lte-design.html#proportional-fair-pf-scheduler
and ask yourself what happens when the channel quality is flat across
all RBs for the same user.

Nicola