Add a "Transmission Bubble" for Nodes

[bpe2]

Add a configurable expanding bubble based on the configuration from the event specified in: https://github.com/usnistgov/NetSimulyzer-ns3-module/issues/30

This bubble should expand from the center of a Node for either a fixed duration or until it hits a target size.

[bpe2]

Added in version 1.0.4

[igs3000]

So, as per the present status of this “transmission sphere” feature, I understand that it can be scheduled along with a node's attribute.

Are you having any plan to automate the creation of transmission bubbles whenever a node transmits something?.

For that, we may need to interfere with the transmission call back function in an automated manner (I mean, not through the user's simulation script).

[bpe2]

Yeah, I have some plans to automate the creation of the transmission spheres, but for the time being, I wanted to see where something like this would be the most useful. Since there are many layers, someone may be interested in seeing this animation for (Application, MAC, Physical, ...). So, I'm not totally sure what that hook-up will look like yet.

If you're interested in using this. You could attach the "TX" trace at whatever layer you're interested in, and if you can get at the Node, you can pull off the NodeConfiguration with GetObject<NodeConfiguration>(). The call Transmit() on that.

If you've got any suggestions for how or where the attachment for the automatic transmit bubbles should be, then I'd love to hear it.

[igs3000]

In fact, I tried to automate it in some way and explored the code in that regard.

The mobility visualization is elegantly integrated with the mobility model (still, I could not understand how your code is doing this). I mean, it is scheduling Netsimulyzer's mobility events automatically along with the mobility model.

If we automate the creation of the transmission spheres, then it should be done by the same manner. For example, you may insert the scheduling of transmission spheres along with the transmissions (just like you are doing it in the case of mobility model)

Maybe I am not explaining it clearly. I may give some suggestions after understanding some parts of your code.

[bpe2]

Well, if you're interested in how the mobility stuff is connected, there are two piecies to that:

Whenever a NodeConfiguration is installed on a Node, it checks if it has a Mobility Model, and if it does, it connects to the "CourseChange" trace that most Mobility Models have, and if it doesn't have one, it attaches a listener for when new items are installed on that Node, just in case a Mobility Model is installed after the NodeConfiguration. You can see this here in the NodeConfiguration class

The other half is polling performed by the Orchestrator. It keeps track of every Node with a NodeConfiuration on it, and based on the "MobilityPollInterval", checks the Node to see if it has moved enough to change its location visually. That distance is configured by the "PositionTolerance" & "UsePositionTolerance" attributes set on the NodeConfiguration. You can see the polling for positions here. This polling may also be turned off by setting the "PollMobility" attribute on the Orchestrator to false (it's true by default)

Forgive me for the wall of text, but that should give you all of the context for how mobility is handled.

For the transmission spheres, I'm not sure if it's quite as straightforward. Since people are interested at transmissions at all different layers, it wouldn't make sense to just connect that animation to the MAC or Physical "TX" traces (not to mention there will be tons of them), but there are times when I'd only be interested in when something as high up as the Application layer transmits, so we need some way to control the granularity of these animations.

There are some other problems, like not all things capable of generating traffic already have "TX" traces, but I think this is the big one. That's why I released only the basic option without automatic connections, just to see how people are using it, to maybe guide the decision for what should happen automatically.

[igs3000]

In fact, I abstractly understood the way you are handling mobility along with mobility model. Still, I hope that transmission sphere can be handled in the same automatic manner.

_

For the transmission spheres, I'm not sure if it's quite as straightforward. Since people are interested at transmissions at all different layers, it wouldn't make sense to just connect that animation to the MAC or Physical "TX" traces (not to mention there will be tons of them), but there are times when I'd only be interested in when something as high up as the Application layer transmits, so we need some way to control the granularity of these animations.

There are some other problems, like not all things capable of generating traffic already have "TX" traces, but I think this is the big one. That's why I released only the basic option without automatic connections, just to see how people are using it, to maybe guide the decision for what should happen automatically.

_

I am having different opinion in this regard. For me, the transmission is just the event of the emission of Electromagnetic wave. Irrespective of from which layer of OSI stack it is initiated, the final transmission event hopefully happen only at the MAC/Physical Layer of the protocol stack. I mean, an electromagnetic wave (sphere) will start to expand from the node only at the mac/physical layer - so we need not worry about handling the TX events at the other upper layers like application layer. (because it will be redundant/duplicate of the same mac/phy layer event)

So, just like you are scheduling the mobility events through call back as below, _mobility->TraceConnectWithoutContext ( "CourseChange", MakeCallback (&netsimulyzer::NodeConfiguration::CourseChange, this)); mattachedMobilityTrace = true; Object::NotifyNewAggregate (); }

You can schedule the expanding sphere by making a call back to the actual MAC/Phy TX event. In fact, i do not know much about ns-3 - but I think, the “expanding sphere” can be easily scheduled along with the call back of MAC/Phy TX event.

Am I missing something here (from the simulator's point of view)

[igs3000]

Similarly, a packet drop event can be made available by temporarily changing the expanding sphere as a simple animation to mimic packet drop. I mean, at the event of packet drop, we can play another 3D animation on that node. I hope that you can automate this by adding another callback to packet drop event.

But unlike transmission, packet drop can happen at different layers. So to denote the packet drop at different layers, we may change the color of the 3D drop animation or entirely change the 3D model itself.

Sorry. Just another feature request. Ha.. ha.. ha..

Of course, I am making this suggestion without realizing the magnitude of changes needed to implement it in the Netsimulyzer 3D tool as well as the ns-3 module part. So, please bear with my “easy” way of making suggestions.

[bpe2]

Well, it's certainly true that the actual transmission occurs at the Physical layer, I'm certainly not here to try and dispute that. I guess my concern is that different simulations are focusing on different levels of granularity, so it may not be helpful to show all the physical transmissions as they occur, as someone may just in interested in something like when an application sends a packet for transmission. Even though this would be an abstract indication of events instead of what happens physically, it's sometimes very helpful in a large-scale simulation to be able to indicate that sort of thing has happened. There's the possibility, too, they may not be interested in showing these transmissions at all. We could have some sort of configuration, probably in the ns-3 module, for granularity of the animations. I'm just not totally sure what that will look like yet.

I kind of like your idea for animating packet drops, and I have been trying to come up with some way of indicating that sort of thing too. While, it's probably not going to come quick. I'll keep that in mind.

[igs3000]

I guess my concern is that different simulations are focusing on different levels of granularity, so it may not be helpful to show all the physical transmissions as they occur, as someone may just in interested in something like when an application sends a packet for transmission.

Of course, you are correct - but to simply make the lot of possible transmissions spheres more understandable, we may color them according to the type of packet.

For example, if it is a "data" packet that was sent by an application, then we may color it as green. similarly, if it is an acknowledgment packet, we may color it as yellow similarly, if it is a routing related message (RREQ/RREP or any other routing related) we may color it as red.

So there will be only one common TX point at Phy - by reading the header of the packet, we will understand the type of the packet and may color the sphere accordingly. (or even we may have an option for not creating spheres for certain types of transmissions based on the type of packet derived from the packet header). I mean, for example, if it is a route discovery related packet, then we may avoid creating spheres for them. Now the user will have control on different types of packets/spheres.

It may be hard to code, but I hope that this simplified approach will give a generic solution for handling different types/levels of packet transmissions.

[bpe2]

I like that idea, actually, of attaching a listener at the physical layer and inspecting the packet for what type of message it is for filtering. I'll give this a shot. Thanks for the suggestion!

[igs3000]

Another suggestion:

While trying to make animations for transmission spheres on a mobile node scenario, at the instance of such growing transmission spheres, there will not be any movement of nodes at all (the nodes will move meters/second, but the spheres will represent radio wave propagation which will happen 300000000 meters/second).

I mean, on a smoothly moving node scenario, if the node starts to transmit, then all the nodes in the network will literally stop until the end of the transmission sphere. Sometimes it will be irritating to see if there will be more than one transmission at that instance of time. So, at the 3D visualizer GUI, there may be an option to enable/disable the transmission sphere entirely to visualize the smooth node movements temporarily.

It will help us to use the GUI for better visualization of node movements/node transmissions as per our wish.

[bpe2]

I think that does make sense, and admittedly, there is some abstracting going on showing these spheres growing at the rate they do. I'll see what people think about potentially 'pausing' for that.

[igs3000]

https://www.projectguideline.com/wp-content/uploads/2021/09/out-3.webm?_=1

Check the above OMNet++ 3D visualization output. At the time of growing transmission sphere, the Sharks and the Ship stops to move (in other words, there will not be significant movement of those nodes). Pressing "fast-forward" button temporarily disable the growing transmission sphere animation—so that we can now see the node movements.

This is the problem and the solution that we are discussing here.