Implementation of a new LTE scheduler consider velocity of UEs as metric based on ff-pf-mac-scheduler.cc

[Hosein]

Hi
I proposed a new scheduler for LTE which considers velocity of UEs as a metric to allocate RBs to UEs. for some reasons related to the application I needed, I want to give priority to UEs with higher speed to send their data (I also consider the past throughput of UEs as PF, but now simply assume scheduler only check UEs velocity and allocate RBs based on that)
I reviewed pf-ff-mac-scheduler.cc and I wish I could change it to consider the velocity. but I couldn't find out exactly where should I change the code to consider the velocity as well and is it possible to access the UE's velocity there? (I know in LTE standard, the scheduler which is in eNB does not know the velocity of UEs, but assume scheduler somehow know about UE's velocity, I want to know is it possible in simulation to access UE's velocity in scheduler?)

[Tommaso Pecorella]

Hi,

please check one of the various posts in this forum about how a node/function can retrieve a given node's positions and speed.

As a bonus, you'll probably find one or more of my rants about how wicked is this assumption and how I would happily kick in the nuts(*) anyone proposing something similar without adding the line "and now let's see how the performances are different if we consider a realistic assumption".

Cheers,

T.

(*) figuratively, of course. I just reject papers with shaming reviews.

[Hosein]

Thank you for your kindly(!) reply.
1- I know how to retrieve a node's position and speed from the given node, but I couldn't find the Node in pf-ff-mac-scheduler.cc!
2- I didn't understand what you said about kicking in nut, reject paper ets. for proposing non realistic things and ...
but if you mean my proposed scheduler is not realistic because I assume the scheduler know the UE's speed so it is nuts ..., the way that how scheduler can know UE's speed is out of scope this group and I will discuss about it and how can we modify control channels and protocols to allow the scheduler knowing UE's speed in my paper. at this stage I don't want (and I am not sure if it is possible to) implement that part (how scheduler know speed information), so I just want to use UE's speed at scheduler (regardless of how it can be obtained).
So I appreciated you if you can tell me is it possible or not and help me instead of make fun of me!!
Thanks
Hossein

[Tommaso Pecorella]

Hi,

I didn't want to make fun of you, and I'm sorry if you misunderstood.

Your approach seems reasonable (first check if the algorithm is worth studying, then add the needed parts to make it realistic). I was referring exactly to this very same thing: I've seen too many idiots stopping at the first stage and claiming victory, without realizing that the hard part is the second one.

As a matter of fact, the problem is the information knowledge delay. What you'll have in a few is the code to know the instantaneous (and ideal) node's position and speed. Any realistic algorithm will have to cope with the fact that this information is not really available because:

1) the measure is affected by errors (even if one uses GPS) and

2) there is a delay between the UE measure and the measure delivery to the EPC.

Depending on the speed of the control loop (i.e., how much overhead one wants to introduce in the system), this difference may be quite huge. Just think to a motorbike in a city traffic. You'd have to send speed info every 10th of second to track it decently.

Anyway, you seems well aware of these issue, so you can use the ideal code wisely (it's still an ideal case, useful as a limit).

And now the code.

for (uint32_t i = 0; i < NodeList::GetNNodes (); i++)
  {
    Ptr<Node> node = NodeList::GetNode (i);
    Ptr<MobilityModel> mobility = node->GetObject<MobilityModel>();
    if (mobility)
      {
        std::cout << "node " << i << " is located at " << mobility->GetPosition ();
        std::cout << " and its speed is " << mobility->GetVelocity () << std::endl;
      }
  }

As you see, the code uses two tricks that should used carefully.

1) it pokes *all* the nodes in the simulation (it's up to you to filter the ones you're interested into) and

2) it ask the position and speed directly to the node's mobility model (thus it's not a measure, it's an a-priori knowledge).

Cheers,

T.

[Tommaso Pecorella]

And of course I should read two times the messages before replying...

Oh well, the code will be useful to somebody (maybe).

The answer (though not definitive, as I'm not the LTE master) may be: use the RTNI. The scheduler should know the RTNI of the UEs being served, and the UE knows its RTNI.

FromDrbActivator::ActivateDrb:

      Ptr<LteUeRrc> ueRrc = m_ueDevice->GetObject<LteUeNetDevice> ()->GetRrc ();
      NS_ASSERT (ueRrc->GetState () == LteUeRrc::CONNECTED_NORMALLY);
      uint16_t rnti = ueRrc->GetRnti ();

where m_ueDevice is a NetDevice. 

How to find the LTE NetDevice in the node is easy (just scan the NetDevices and use dynamic cast). Of course this assuming that the Node just owns one LTE netdevice...

Sorry for not reading carefully the message.

Cheers,

T

On Tuesday, September 16, 2014 11:46:19 PM UTC+2, Hosein wrote:

[Hosein]

Thank you very much Tommoso for your time and complete answer. I really appreciated you.