Changing datarate of a busy channel

[Jeremy]

Hi everyone,

I'm currently simulating a channel in omnet, where the datarate channel changes every slot.

Sometimes this change happens when the channel is busy, i.e. a packet is in progress. In this case, the packet that is being sent will arrive at the time calculated before the datarate change.

However, I want it to behave more fluid model-like. E.g. assume we send a packet of 10bit at t=0 on a channel of 5bps, and we change the datarate at t=1 to 10bps, then at t=1 we have 5 bit left to transmit at a rate of 10bps, resulting in a finish time of 1.5s (rather than 2s, in the channel's normal behaviour).

In plain omnet I've been able to accomplish this fluid model using some custom elements and fiddling with the internals.

However, I now want to redo these simulations with the TCP protocol, while keeping the ability to change a busy channel's datarate and have the fluid model's behaviour.

Using the plain omnet approach, I cannot get it working.

Can this be achieved in INET? Or is it possible to implement in a reasonable way? I just noticed that INET 4 is on its way, does it have better support for this?

Thank you very much!

Jeremy

[Rudolf Hornig]

On Saturday, June 30, 2018 at 1:54:39 AM UTC+2, Jeremy wrote:

Hi everyone,

I'm currently simulating a channel in omnet, where the datarate channel changes every slot.

Sometimes this change happens when the channel is busy, i.e. a packet is in progress. In this case, the packet that is being sent will arrive at the time calculated before the datarate change.

However, I want it to behave more fluid model-like. E.g. assume we send a packet of 10bit at t=0 on a channel of 5bps, and we change the datarate at t=1 to 10bps, then at t=1 we have 5 bit left to transmit at a rate of 10bps, resulting in a finish time of 1.5s (rather than 2s, in the channel's normal behaviour).

In plain omnet I've been able to accomplish this fluid model using some custom elements and fiddling with the internals.

Probably the proper way to do it would be to define your own channel (based on IdealChannel) and calculate the packets arrival time by hand instead of relying on the built-in omnet behavior. Schedule the event to the pre-calculated arrival time for the destination module and also keep a pointer to the sent event. If the bitrate change happens while the packet is still scheduled (i.e. the channel is busy), you simple cancel the message, remove it from the event queue, then recalculate the arrival time based on the new datarate and re-schedule the event for the new arrival time. It is a little problematic that who should actually delete the message. Normally the receiver module deletes the message, but you keep a pointer on the sending site too, so you should dereference that pointer only, if you are absolutely sure that the receiving end did not delete it... It's a bit tricky, but doable...

 

However, I now want to redo these simulations with the TCP protocol, while keeping the ability to change a busy channel's datarate and have the fluid model's behaviour.

Using the plain omnet approach, I cannot get it working.

There is absolutely no reason why you could not do it with INET. INET is just an (admittedly big) bunch of modules. If you create a proper NetworkInterface module that behaves according to your "fluid" model, then there is no reason why you could not install it just like using a PPP interface... (The PPPInterface module would be a good starting point for that implementation BTW)

 

Can this be achieved in INET? Or is it possible to implement in a reasonable way? I just noticed that INET 4 is on its way, does it have better support for this?

INET 4 was just released. Obviously your requirement is very specific so no direct support for this, but as written above, as long as the model works and the module implements the INetworkInterface module interface type, you are good to go...

[Rudolf Hornig]

Oh just an additional idea: 

you might be indeed better to look into INET 4 and start from the ShortCut MAC. That is a very simplified mac protocol that does not have a physical layer at all (hence the name shortcut, that the sent packet directly pops up at the destination's MAC module without any physical layer modeling). (this is a radio model so this is not a wired one, so broadcast and multicast is also possible).

This could be a better starting point for you. You still have to implement the logic to recall the scheduled message, if a bitrate change is required during transmission...

[Jeremy]

Thank you very much for your suggestions, Rudolph!

Seems like I have to switch to INET 4 then, as the ShortCut MAC seems like a very interesting and easier starting point than creating a new NetworkInterface.

Kind regards,

Jeremy

[Rudolf Hornig]

You are welcome. INET 4 is the recommended version anyway for new projects. INET 3.x is no in maintenance mode, so we will not add new features there anymore.