Issue with fairness in channel access in vanet-routing-compare.cc

[Boong Baang]

I am trying to calculate the jain's fairness for different densities using a trace file in vanet-routing-compare.cc. As per papers that I have read, for less densities (~50 veh), channel is pretty much clear and whoever wants to transmit, they get the access to the channel. When congestion increases, channel becomes saturated, and no everyone gets the same amount of channel access. I am talking about the default 10 Hz 802.11p.

For Jain's fairness, I need how many times each vehicle was able to send their packets successfully, and I think it is indicated by the Callback     

std::string dequeue_path= "/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/*/$ns3::OcbWifiMac/*/Queue/Dequeue";
Config::Connect (dequeue_path, MakeCallback (&BsmApplication::DequeueTrace));

But the result that I get using this is that every vehicle had the exact same number of packet being dequeued for both high and low density, which shouldn't be happening. A paper that analysed this (link), which shows that fairness should reduce when vehicle densities increase. So is the Callback that I am calling the right one to call for the indication that a vehicle has got access to the channel ?

[Adil Alsuhaim]

The DequeueTrace is invoked whenever a packet is dequeued from the outgoing MAC queue for whatever reason. This includes being dequeued for transmission, and being dequeued because it exceeded the maximum delay in the queue (I think the default is 500ms). This might explain why you're getting the exact same numbers.  I am not sure how you're tracking the numbers.

You can try other trace sources like Drop, which is invoked if a packet is dropped from the outgoing MAC queue for whatever reason (including if the queue is full). I think DropAfterDequeue is what gets triggered if a packet is dequeued and then dropped (as opposed to dequeued and then transmitted).

[Boong Baang]

On Friday, June 5, 2020 at 8:14:26 PM UTC-4, Adil Alsuhaim wrote:

The DequeueTrace is invoked whenever a packet is dequeued from the outgoing MAC queue for whatever reason. This includes being dequeued for transmission, and being dequeued because it exceeded the maximum delay in the queue (I think the default is 500ms). This might explain why you're getting the exact same numbers.  I am not sure how you're tracking the numbers.

I have a 1-D array with size equal to the number of users, and everytime the trace corresponding to the queue of a user is activated, the corresponding array is incremented.

 

You can try other trace sources like Drop, which is invoked if a packet is dropped from the outgoing MAC queue for whatever reason (including if the queue is full). I think DropAfterDequeue is what gets triggered if a packet is dequeued and then dropped (as opposed to dequeued and then transmitted).

I see, I will have a look at the other traces and try out the other ones. 

[Biplav Choudhury]

Hi Adil, hope you are well. Sorry to trouble you again 😔. 

I wanted to calculate the Channel Busy Ratio but the values I was getting are not looking correct. I posted the question on the group, if you have some time can you please look at it and let me know what you think about it.

The fairness issue I had was solved, thanks for the help.

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/gCQye0EEdzE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/5bb280a5-b532-44eb-8da8-e6d7cc75983bo%40googlegroups.com.