UI "Designer" for NS3 Based Visual Scripting

[Tomaz Canabrava]

Hello All, 

My name is Tomaz Canabrava, I'm a student of the University of Luxembourg, masters of high speed computing. Because some of the disciplines in my masters uses NS-3, I started to look at the code and I found that no visual tool exists to help diagram what the simulation should look like, so I started to develop one.

Currently it's fairly small (and doesn't run the simulations yet)

The main idea is to create all the elements of the simulation on the visual interface, that will create a graph that will then be passed to a python script (or a c++ implementation) that will generate the necessary simulation without the need of recompiling c++ code.

This also (will) make it easy to have multiple versions of the "project" and run side by side 

simulations within the same program.

The question is... Is this something that the NS-3 team wants, or I'm creating something that will just go to waste?

technology used: Qt6

[Tom Henderson]

Hello Tomaz, I'll share my personal opinion on this; others may want to chime in.

I think that a graphical configuration tool would be very nice for our users, especially in an educational context.  The reason that one does not exist is that it has proven to be difficult (time consuming) to maintain one.  However, if several people wanted to pitch in with maintenance, it should be doable.

Rather than starting from scratch, I would recommend to try to reuse an existing GUI, either from IMUNES [1] or CORE [2] (CORE is a fork of IMUNES).  The IMUNES GUI [3], which was extended by CORE, is the nicest one that I have used over the years.  It is easy to drag and drop icons and right click to configure things.  These tools are primarily designed to orchestrate containers for network emulation.  However, they could also used to configure ns-3 simulations and could even be used to run ns-3 simulations (if the GUI were extended to call for the launch of a simulation rather than the launch of a network emulation).

Many years ago, Craig Dowell worked on a small project to use the CORE GUI to configure ns-3 simulations [4]. Why didn't this go further than proof-of-concept?  Again, no one on the project had time/energy to carry it forward at that time.  But if I had more free time, I would use this work as a starting point for an ns-3 configuration tool.  I also think it would help for education if the tool could be dual use; users could potentially run emulations and simulations from a common interface.

Similarly, the network animator (NetAnim) and Pyviz lost steam when their original authors and core contributors moved on from the ns-3 project.  A few maintainers are still doing some work on NetAnim and Pyviz, and Evan Black is actively maintaining the NetSimulyzer (a newer visualization tool for ns-3).  Those tools are visualizers, however-- not configuration tools.  John Abraham experimented a bit with a variant of NetAnim called the 'composer' but it didn't progress beyond early stages.

Others have expressed interest over the years in developing a browser-based configuration tool as well as an all-in-one dedicated IDE (graphical configurator, code editor, animator) like a commercial tool, but in my opinion, those would take even more effort than trying to adapt something like IMUNES or CORE and just tackle the graphical configuration aspect.

- Tom

[1] https://imunes.net

[2] https://github.com/coreemu/core

[3] https://www.youtube.com/watch?v=nxoG5dPIZV0

[4] https://www.nsnam.org/~tomh/ns-3-CORE-report.pdf

--
You received this message because you are subscribed to the Google Groups "ns-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-developer...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ns-developers/b28da6e7-b25b-49ae-b887-f32d58f83933n%40googlegroups.com.

[Tomaz Canabrava]

Hello Tom,

On Sun, Feb 22, 2026 at 7:57 PM Tom Henderson <to...@tomh.org> wrote:

Hello Tomaz, I'll share my personal opinion on this; others may want to chime in.

I think that a graphical configuration tool would be very nice for our users, especially in an educational context.  The reason that one does not exist is that it has proven to be difficult (time consuming) to maintain one.  However, if several people wanted to pitch in with maintenance, it should be doable.

Understood, and Agreed. 

Rather than starting from scratch, I would recommend to try to reuse an existing GUI, either from IMUNES [1] or CORE [2] (CORE is a fork of IMUNES).  The IMUNES GUI [3], which was extended by CORE, is the nicest one that I have used over the years.  It is easy to drag and drop icons and right click to configure things.  These tools are primarily designed to orchestrate containers for network emulation.  However, they could also used to configure ns-3 simulations and could even be used to run ns-3 simulations (if the GUI were extended to call for the launch of a simulation rather than the launch of a network emulation).

Many years ago, Craig Dowell worked on a small project to use the CORE GUI to configure ns-3 simulations [4]. Why didn't this go further than proof-of-concept?  Again, no one on the project had time/energy to carry it forward at that time.  But if I had more free time, I would use this work as a starting point for an ns-3 configuration tool.  I also think it would help for education if the tool could be dual use; users could potentially run emulations and simulations from a common interface.

That certainly is a nice idea, I looked at the links you pasted and I do have some questions (mostly about the API design).

on the other side (UI, Gui and such) - I'm an experienced Qt/C++ developer so I don't think tacking the GUI side of things to be complex (I co maintain various applications on the KDE ecosystem, such as konsole, and codevis). 

Similarly, the network animator (NetAnim) and Pyviz lost steam when their original authors and core contributors moved on from the ns-3 project.  A few maintainers are still doing some work on NetAnim and Pyviz, and Evan Black is actively maintaining the NetSimulyzer (a newer visualization tool for ns-3).  Those tools are visualizers, however-- not configuration tools.  John Abraham experimented a bit with a variant of NetAnim called the 'composer' but it didn't progress beyond early stages.

Others have expressed interest over the years in developing a browser-based configuration tool as well as an all-in-one dedicated IDE (graphical configurator, code editor, animator) like a commercial tool, but in my opinion, those would take even more effort than trying to adapt something like IMUNES or CORE and just tackle the graphical configuration aspect.

- Tom

[1] https://imunes.net

[2] https://github.com/coreemu/core

[3] https://www.youtube.com/watch?v=nxoG5dPIZV0

[4] https://www.nsnam.org/~tomh/ns-3-CORE-report.pdf

Thanks for those links. I believe a common "failure" on most of the trials is what I'm facing now: The lack of a "specification" of sorts, that the simulator would ingest, and generate automatically the needed objects. While looking at CORE and Imune, the specific classes and objects from the c++ world were not there to be drag'n dropped, and there's no easy way to map the values from/to gui to the cpp objects (not all of them have a property system, for instance the *Helper classes such as PointToPointHelper - those I had to manually map).

if we can define, and load, a simulation from a descriptive file (graphviz, json, xml of sorts) then, implementing the interface for this is "the easy part".  

[Alberto Gallegos]

Dear Tomaz,

I agree on most points with Tom.

The main problem with a GUI , either one that generates code or a visualizer is the lack of maintenance and future outlook for their projects.
In fact, if you look at the literature there is at least 1 or 2 proposals A YEAR for ns-3 GUI related tools.

But all the proposals fall into the same old troves:

- Here I am proposing this amazing blablah GUI .... that "OTHERS" can extend.  Nobody does, and the project quickly fall into an "unusable" state.

  ns-3 is an ever evolving project. You have to think not only in the current state of the project, but also where is going and how will it be to maintain the code.

- In many ns-3 proposal there are people who "I propose X and Y, with....,with x and y library or framework.

Libraries that have constant changes between versions and code that is introducing breaking code changes makes the code hard to maintain.

Also ns-3 is mainly done in c++, personally, I would not like to be maintaining code in other "additional languages".  Choose dependencies carefully.

The more dependencies there are, the harder is to maintain and install, because you have to think not only maintaining the changes in ns-3 but also whatever the changes

 are in the thousand dependency libraries you are  introducing. People never think about that.

 For the record, I would not use QT libraries (they often have breaking changes, and it has been done before, look at NetAnim and NetSimulizer), python eeerr... SLOOOOOOW, do I have to say more?

But... to each their own.

- Like Tom mentioned, why everyone wants to start from scratch? USE what is already been done in your proposal, Probably the proposals that tom mentioned are a good starting point.

But there are many many many others.

Re-usability, low dependency cost, and future maintenance plan. That's what a ns-3 GUI needs.

Finally, in my opinion, the development of the meta-code or the method that connects the GUI with ns-3 is more important that making a new GUI. That meta code or connection method can be extended, fixed and improved.

There will never be a "GUI" that covers all ns-3 user needs (in fact none of the current proposals cover mine, because they are always only for WiFi or LTE), people will continue making their own GUIs that cover their specific needs,

 but at least they would not have to start from scratch if there is a unified meta-language/translate method that they can reuse in their own GUI.

I am sure that you will do what you must.
But at the end of the day, regardless of what you choose, I think what ns-3 needs is somebody willing to maintain the code after its been release.

We do not have that, and that is WHY , there are not many advances in ns-3-GUI related stuff.

Regards,

Al.

[zhangkai]

Hello,

I completely agree that developing a GUI or some form of external interface could be one way to extend ns-3.

In my project(https://github.com/z14212638-eng/Ns3-based-Visualization), I used shared memory to export PPDU meta-information, so the GUI can read and process data generated by ns-3 without tightly modifying the simulator itself.

The project is almost 100% written in C++ (Qt6 for the GUI). I also provide an AppImage for users who don’t want to set up Qt and just want to use the tool directly, especially beginners who are experimenting with their own simulations.

I think a GUI won’t replace scripting workflows, but it might make ns-3 a bit more approachable for teaching and early-stage experimentation.

Would it be a good one ? I would be responsible for future maintenance and I'm looking forward to your reply .

Regards,

Kevin Zhang

[zhangkai]

Hello Tom,
My name is Kevin Zhang,I am a senior student .Just like Tomaz said,a GUI that could be used for ns-3 simulation is educational and might be hard to maintain , like NetAnim.But actually I have already made a GUI based on Qt6 and I call it "Ns3Visualizer".I have a passion for ns-3,and it is my dream to be one of the developers (although I am too young).This tool was designed for 2026-Gsoc ,but I am not sure if this one could be recognized as a good work .But anyway, I would be responsible for this tool and keep it updated,hope one day I am able to add this one to ns-3 source code.
Here is my Github repo address:https://github.com/z14212638-eng/Ns3-based-Visualization
Here is some screenshots and GIF of my Visualization tool .

Currently this tool supports :
- Automatically running the selected simulation through ui-operation
- Node/Channel PPDU-Timeline
- Rich ui-user interaction
- Providing PPDU-Timeline , Throughput-plot, Terminal output.
- Configure your own designed simulation (including general config,node config and flow config ect.)
- Load simulations in history(and save the simulation configuration as .nsproj)
- Details are in my Github repo:https://github.com/z14212638-eng/Ns3-based-Visualization

It is my sincere wish that this one would be a useful part contributing ns-3.And if possible,I really hope that someone could be my mentor to polish this tool.

Kevin Zhang

On Tuesday, February 24, 2026 at 10:26:13 AM UTC+8 shattered...@gmail.com wrote:

[Tom Henderson]

Kevin,

To have a GUI-based project or any other project with large scope in GSoC, you need to find a mentor interested to work on it, and you and the mentor needs to define some project that can be completed in the timeframe of the GSoC project.  We have found, over the years, that projects with small scope succeed than ones that take on too much scope and fail to merge at the end.

We have used GSoC to work on repositories outside of the official umbrella of ns-3 (i.e., hosted and maintained on external repositories) but there would need to be some belief that the broader ns-3 community is likely to be able to make use of the output of the program.  The SEM tool that I mentioned in the other thread is an example of this (https://apps.nsnam.org/app/sem/).  But generally, this is the exception rather than the rule.

For any GUI-based project, I think you are taking the correct first step to announce something for people to test on their own, and then people who like it and want to contribute to it can reach out to you and start to collaborate.  If it ends up being something that you plan to maintain and want to promote for the community, we can add a page to the ns-3 app store to advertise it.

- Tom

To view this discussion visit https://groups.google.com/d/msgid/ns-developers/45eba7e4-9ebd-4d29-aca4-406a50a349b5n%40googlegroups.com.

[Tom Henderson]

Tomaz, to reply to one of your specific points.

On 2/22/26 11:43 PM, Tomaz Canabrava wrote:

Thanks for those links. I believe a common "failure" on most of the trials is what I'm facing now: The lack of a "specification" of sorts, that the simulator would ingest, and generate automatically the needed objects. While looking at CORE and Imune, the specific classes and objects from the c++ world were not there to be drag'n dropped, and there's no easy way to map the values from/to gui to the cpp objects (not all of them have a property system, for instance the *Helper classes such as PointToPointHelper - those I had to manually map).

if we can define, and load, a simulation from a descriptive file (graphviz, json, xml of sorts) then, implementing the interface for this is "the easy part".  

I agree that this intermediate layer of scenario and experiment representation that could be parsed by ns-3 would be useful and would allow GUIs or other tools to author experiments without writing C++ or Python code.  

We do have something called the config store that is able to export simulation configuration to text or XML, and to ingest it later.  It does not capture everything, however (it focuses on the configuration of nodes or objects attached to nodes, but does not export everything about a scenario to run, however.  Perhaps it could be a start of something like this:

https://www.nsnam.org/docs/manual/html/attributes.html#configstore

- Tom

[Tomaz Canabrava]

Tom,

Thanks. this is indeed quite helpful. 

i am willing to work on extending this from a non-gui perspective in such way that we can store an entire simulation, and recover an entire simulation, from xml.

i believe this is the first step of making any kind of GUI promisses for NS3 

note that i am *not* looking for a summer of code - just want to improve NS3.

best

tomaz

[zhangkai]

Hi Tom,

Thank you very much for your thoughtful advice and it was really helpful.

Based on your suggestion, I plan to narrow the scope and focus on a small, well-defined WiFi PHY debugging tool rather than a broader GUI project. I’ll refine the idea and ask the developers for feedback to make sure it aligns with actual needs.

Thanks again for taking the time to share your ideas with me.I truly appreciate it.

Best regards,
Kevin

[zhangkai]

Dear Tomaz,

Hello! I noticed that we seem to share similar interests in improving visualization for ns-3.

If you’re open to it, I’d be glad to exchange ideas and possibly collaborate in the future, especially around WiFi PHY debugging tools or GUI-related improvements.

Looking forward to staying in touch.

Best regards,
Kevin

[Tom Henderson]

OK, using JSON as the representation may also make sense (i.e., it might be time to try to upgrade ConfigStore to use also JSON configuration).  ConfigStore has so few current users that it would not bother me to drop XML (anyone using ConfigStore XML out there, please correct me if I am wrong).

- Tom

[pd...@mac.com]

Hello Kevin and Tomaz,

A long time ago we developed an XML-based approach to describing and instantiating network models. We envisioned this could also be used for visualization, but our primary interest was in treating large network scenarios as data, rather than coding them in giant simulation scripts.

This was presented at WNS3 2013 (the predecessor of the ICNS3).
Barnes, etl. "Integrating ns3 Model Construction, Description, Preprocessing, Execution, and Visualization”

On ACM DL (I think this is no longer paywalled…)
https://dl.acm.org/doi/10.5555/2512734.2512758
https://dl.acm.org/doi/epdf/10.5555/2512734.2512758

The talk is here:
http://www.nsnam.org/wp-content/uploads/2013/01/WNS3-2013-Presentation-Barnes.pdf

We chose XML because we wanted

* A defined schema (XSD), which can be used to validate files
* A defined transformation language (XSLT) which facilitates some of the rewriting/transformations we envisioned.

The implementation basically interpreted node, net device, channel, and application XML stanzas to instantiate the required objects. The XML config options exactly matched the Attributes for the targeted object, so the XML

attribute=“string value”

Immediately mapped to

objectFactory->Set(“attribute”, “string value”)

Maybe there are ideas there that would be useful for you.

Peter

> --
> You received this message because you are subscribed to the Google Groups "ns-developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ns-developer...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/ns-developers/3656b9d9-c473-4fe8-8995-e16bf52f0af2%40tomh.org.

-----------------------
Peter Barnes
pd...@mac.com

[Biljana Bojovic]

Hi all, 

We (CTTC/OpenSim) will soon update this year's GSoC project description for the visualization of 5G-LENA. We expect soon to have mobility/handover support, and we would like to be able to visualize these scenarios properly, and show all the KPIs that would be of interest for the 5G scenario. Also, we are thinking of the possibility of using such a visualizer for debugging/inspecting, generation of specific logs/traces based on flow id/packet id. 

We like this json/xml generic approach. Such API opens many different possibilities, e.g., ns-3 for agentic AI. https://blogs.nvidia.com/blog/nvidia-agentic-ai-blueprints-telco-reasoning-models/

Kind regards,

Biljana

To view this discussion visit https://groups.google.com/d/msgid/ns-developers/8CC31901-4B4F-4553-9477-6ACC16FCCC79%40mac.com.