ns3 Small introduction PLANETE Group Inria Sophia Antipolis

ns-3 – Small introduction PLANETE Group Inria Sophia Antipolis Méditerranée 10 November 2020

SOMMAIRE 1. Introduction to ns-3 and its modules 2. Simple simulation example 3. Log module 4. Trace module 5. How to create a new module ns-3 – Small introduction 2

Introduction o Why a new network simulator? • There are many other simulators out there! • Not that many are free, scalable and extensible • • Lack of support for development and evolution Split object model (OTcl and C++) and use of Tcl is confusing for students, and does not scale well Lack of support for creating methodologically sound simulations New modules were created in a disorganized and non validated way • We already do have ns 2, and it is free! • • • Cost of hardware is decreasing and virtualization is getting faster • • • Hard to reproduce results Harder to setup and change environment You can not test a non existent technology/system ns-3 – Small introduction 3

Introduction o NS-3 is a new simulator, written from ”scratch” • Not really an evolution of ns-2 • Programming languages: C++, Python o Well, not really from scratch • Parts from: • GTNet. S. • Yans • ns-2 ns-3 – Small introduction 4

Advantages o Scalable • Packets can have ”virtual zero bytes” (or dummy bytes) § For dummy application data that we don't care about § No memory is allocated for virtual zero bytes § Reduces the memory footprint of the simulation o Real-world Integration • Packets can be saved to PCAP files, in a real format § Many tools can read PCAP files, e. g. Wireshark • Real-time scheduler § Simulation events synchronized to ”wall clock time” • ”Network Simulation Cradle” § Run Linux Kernel TCP/IP stack under simulation Linux 2. 6. 18, Linux 2. 6. 26 • DCE – Direct Code Execution § Can run applications over ns 3 • Integration into testbed and virtual machine environments § Emu. Net. Device: Send/Receive data from/to simulation from/to real world § Tap Net. Device: allows a “real” host to participate in an ns-3 simulation as if it were one of the simulated nodes ns-3 – Small introduction 5

NS-3 Modules High-level wrappers for everything else. No smart pointers used. Aimed at scripting. Node class Net. Device ABC Address types (IPv 4, MAC, etc. ) Queues Socket ABC IPv 4 ABCs Packet Sockets helper Internet-stack (ipv 4 impl. ) Routing: olsr, global-routing Devices: csma | wifi |. . . mobility node common simulator Events Scheduler Time arithmetic core Smart pointers Dynamic type system Attributes Callbacks, Tracing Logging Random Variables Packet Tags Packet Headers Pcap/ascii file writing ns-3 – Small introduction Mobility Models (static, random walk, etc. ) 6

The basic model Packet generator and consumer running on a Node Application Protocol Stack Net Device Socket like API Interface between an application and a network stack Network card which, can be plugged in an IO interface of a Node The computer mother board: Ram, IO, CPU, Interfaces… Node Physical connector between Net. Devices ns-3 – Small introduction Node Channel 7

Important o Net. Devices are strongly bound to Channels of a matching type • Wifi. Net. Device ↔ Wifi. Channel • Csma. Net. Device ↔ Csma. Channel o Helpers • Don’t intend to be generic • Don’t intend to be reusable • Intend to save lines of code • Intend to help users to have a set of easy default configuration ns-3 – Small introduction 8

A typical simulation o o Create a series of C++ objects Configure and interconnect these objects Each object creates events with Simulator: : Schedule Call Simulator: : Run to execute all events A (fictional) simulation Node *a = new Node (); Node *b = new Node (); Link *link = new Link (a, b); Simulator: : Schedule (Seconds (0. 5), // in 0. 5 s from now &Node: : Start. Cbr, a, // call Start. Cbr on a "100 bytes", "0. 2 ms", b); //arguments Simulator: : Run (); ns-3 – Small introduction 9

Available models – Link layer Point-to-point (PPP links) Csma (Ethernet links) Bridge: 802. 1 D Learning Bridge Wifi (802. 11 links) • EDCA Qo. S support (but not HCCA) • Both infrastructure (with beacons), and adhoc modes o Mesh • 802. 11 s (but no legacy 802. 11 stations supported yet) • ”Flame”: Forwarding LAyer for MEshing protocol o o § ”Easy Wireless: broadband ad-hoc networking for emergency services” o Wimax: 802. 16 • ”supports the four scheduling services defined by the 802. 162004 standard” o Tap-bridge, emu: testbed integration o LTE ns-3 – Small introduction 10

Available models – Routing o Adhoc: • OLSR (RFC 3626) § Since NS 3. 8 with full HNA support (thanks Latih Suresh) • AODV (RFC 3561) o ”Global routing” (aka GOD routing) • Just computes static routes on simulation start o Nix-vector Routing • Limited but high performance static routing • For simulations with thousands of wired nodes o List-routing • Joins multiple routing protocols in the same node • For example: static routing tables + OLSR + AODV ns-3 – Small introduction 11

Available models – Applications (traffic generators) o Onoff • Generates streams, alternating on-and-off periods • Highly parameterized § Can be configured to generate many types of traffic – E. g. On. Time=1 and Off. Time=0 means CBR § Works with either UDP or TCP o Packet sink: receives packets or TCP connnections o Ping 6, v 4 ping: send ICMP ECHO request o Udp-client/server: sends UDP packet w/ sequence number o Udp-echo: sends UDP packet, no sequence number o Radvd: router advertisement (for IPv 6) ns-3 – Small introduction 12

Memory management o Smart pointers • ns-3 provides an implementation of smart pointers • Used to avoid passing references to heap-allocated objects • For most basic usage works as a regular pointer Ptr<Wifi. Net. Device> nd =. . . ; nd->Call. Some. Function (); • To create is slightly different Ptr<Wifi. Net. Device> nd = Create. Object<Wifi. Net. Device> (); ns-3 – Small introduction 13

Memory management o Smart pointers • ns-3 provides an implementation of smart pointers • Used to avoid passing references to heap-allocated objects • Used for automatic garbage collector, counting references to the objects • For most basic usage works as a regular pointer Ptr<Wifi. Net. Device> nd =. . . ; nd->Call. Some. Function (); • To create is slightly different § Objects that derive from ns 3: : Object must be allocated on the heap using Create. Object(). Ptr<Wifi. Net. Device> nd = Create. Object<Wifi. Net. Device> (); ns-3 – Small introduction 14

Fundamental elements - Packets o Packet objects used vertically in NS-3 to represent: • Units of information sent and received by applications • Information chunks of what will become a real packet (similar sk_buff in Linux kernel) • Simulated packets and L 2/L 1 frames being transmitted o Basic Usage • Create empty packet Ptr<Packet> packet = Create<Packet> (); • Create packet with 10 ”dummy” bytes Ptr<Packet> packet = Create<Packet> (10); • ”Dummy” bytes are simulated as being there, but do not actually occupy any memory (reduces memory footprint) • Create packet with user data Ptr<Packet> packet = Create<Packet> (”hello”, 5); • Copy a packet Ptr<Packet> packet 2 = packet 1 ->Copy (); o Note: packet copy is usually cheap (copy-on-write) ns-3 – Small introduction 15

Fundamental elements - Nodes o Node class • Represents a network element • May have an IPv 4 stack object • But it is completely optional! • May have a mobility model § But it is optional, e. g. Csma. Net. Device needs no mobility model • Contains a list of Net. Devices • Contains a list of Applications o Node. List class is a singleton implementation o Tracks all nodes ever created o Node index <=> Ptr conversions ns-3 – Small introduction 16

Fundamental elements - Sockets Plain C sockets int sk; sk = socket(PF_INET, SOCK_DGRAM, 0); struct sockaddr_in src; inet_pton(AF_INET, ” 0. 0”, &src. sin_addr); src. sin_port = htons(80); bind(sk, (struct sockaddr *) &src, sizeof(src)); struct sockaddr_in dest; inet_pton(AF_INET, ” 10. 0. 0. 1”, &dest. sin_addr); dest. sin_port = htons(80); sendto(sk, ”hello”, 6, 0, (struct sockaddr *) &dest, sizeof(dest)); char buf[6]; recv(sk, buf, 6, 0); ns-3 – Small introduction Ns-3 sockets Ptr<Socket> sk = udp. Factory->Create. Socket (); sk->Bind (Inet. Socket. Address (80)); sk->Send. To (Inet. Socket. Address (Ipv 4 Address (” 10. 0. 0. 1”), 80), Create<Packet> (”hello”, 6)); sk->Set. Receive. Callback (Make. Callback (My. Socket. Receive)); � […] (Simulator: : Run ()) void My. Socket. Receive (Ptr<Socket> sk, Ptr<Packet> packet) {. . . } 17

SOMMAIRE 1. Introduction to ns-3 and its modules 2. Simple simulation example 3. Log module 4. Trace module 5. How to create a new module ns-3 – Small introduction 18

Simple example Example first. cc Udp. Echo. Client Node 0 (10. 1. 1. 1) Define log name of the Udp. Echo. Server Node 1 (10. 1. 1. 2) Deffinition of the name component space, it is a ns 3 object Enable logs on the UDP Packet Udp. Echo. Client. Application Inserts two nodes Creates the Nodes Creates a point to point Sets the connection and container device properties Udp. Echo. Server. Application components (Level INFO) UDP Packet Data. Rate: 5 Mbps Delay: 2 ms Creates internet stack Installs internet stack Create addresses to the Install the point to on the nodes devices - point device in the >. /waf --run scratch/my. First Ipv 4 Address. Helper nodes Sent 1024 bytes to 10. 1. 1. 2 Install addresses to the Creates server Received 1024 bytes from 10. 1. 1. 1 devices - Assign App: echo. Client Installs server application Received 1024 bytes from 10. 1. 1. 2 App: echo. Server Installs client application into node 1 Server starts at 1 s and application into node 0 stops at 10 s Creates client nodes: Node. Container Client starts at 2 s and application finishes at 10 s App: echo. Server App: echo. Client Run simulation Stops simulation ns-3 – Small introduction Node 0 10. 1. 1. 1 Point to point device Node 1 10. 1. 1. 2 19

SOMMAIRE 1. Introduction to ns-3 and its modules 2. Simple simulation example 3. Log module 4. Trace module 5. How to create a new module ns-3 – Small introduction 20

Logging Subsystem - Levels o Logging should be used for debugging, print warnings and error messages • Or any time you want to easily get a quick message out of your scripts or models o Automatic logging features o Definition of log interests • Component-by-component • Global o Seven levels, of increasing verbosity • NS_LOG_ERROR — Log error messages; • NS_LOG_WARN — Log warning messages; • NS_LOG_DEBUG — Log relatively rare, ad-hoc debugging messages; • NS_LOG_INFO — Log informational messages about program progress; • NS_LOG_FUNCTION — Log a message describing each function called; • NS_LOGIC – Log messages describing logical flow within a function; • NS_LOG_ALL — Log everything. • Another, unconditional logging, level that is always displayed, no matter a the logging levels or component selection. § NS_LOG_UNCOND – Log the associated message unconditionally. ns-3 – Small introduction 21

Logging Subsystem – Select log information o Each level can be requested singly or cumulatively o Can be activated • Logging system function call Log. Component. Enable("Udp. Echo. Client. Application", LOG_LEVEL_INFO); o Shell environment variable (NS_LOG) export NS_LOG=Udp. Echo. Client. Application=level_info o Log is hierarchical, activating a level we activate all the lower level ones • In this case NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN and NS_LOG_ERROR [dcamara@guacharo ns-3 -dev]$. /waf --run scratch/my. First Waf: Entering directory `/home/dcamara/INRIA/repos/ns-3 -allinone/ns-3 -dev/build' Waf: Leaving directory `/home/dcamara/INRIA/repos/ns-3 -allinone/ns-3 -dev/build' 'build' finished successfully (2. 807 s) Sent 1024 bytes to 10. 1. 1. 2 Received 1024 bytes from 10. 1. 1. 1 Received 1024 bytes from 10. 1. 1. 2 ns-3 – Small introduction 22

Logging Subsystem - Options o Possible to add more information through options export ’NS_LOG=Udp. Echo. Client. Application=level_all|prefix_func| prefix_time’ • prefix_func — Shows the name of the function; • prefix_time — Shows the event time; • prefix_node — Shows the node ID; [dcamara@guacharo ns-3 -dev]$ export NS_LOG='Udp. Echo. Client. Application=level_info| prefix_func|prefix_time' [dcamara@guacharo ns-3 -dev]$. /waf --run scratch/my. First Waf: Entering directory `/home/dcamara/INRIA/repos/ns-3 -allinone/ns-3 -dev/build' Waf: Leaving directory `/home/dcamara/INRIA/repos/ns-3 -allinone/ns-3 -dev/build' 'build' finished successfully (2. 317 s) 2 s Udp. Echo. Client. Application: Send(): Sent 1024 bytes to 10. 1. 1. 2 Received 1024 bytes from 10. 1. 1. 1 2. 00737 s Udp. Echo. Client. Application: Handle. Read(): Received 1024 bytes from 10. 1. 1. 2 ns-3 – Small introduction 23

Logging Subsystem – How to use o Using the log system • Enable log on the component Log. Component. Enable("Udp. Echo. Client. Application", LOG_LEVEL_INFO); // Udp. Echo. Client. Application , is the name of the comp. for the log purposes • Add the message into the appropriate places NS_LOG_UNCOND (“Start of the component execution "); (…) NS_LOG_INFO (“Informational message"); ns-3 – Small introduction 24

Logging Subsystem on Optimized Builds o Optimized compilation • NS_LOG() expand to nothing in optimized builds o Coding style and best practices around the use of debugging code • No debug-related code should execute in the optimized build • For simple NS_LOG calls avoid unnecessary declarations, the statement should be self-contained • Instead of: uint 8_t tmp = obj->Get. Count (); NS_LOG_INFO (tmp == 0); • Use: NS_ASSERT (obj->Get. Count () == 0); ns-3 – Small introduction 25

Logging Subsystem on Optimized Builds – Complex code o Coding style and best practices around the use of debugging code • Complex debug-only code around NS_ASSERT() and NS_LOG() should be factored into a separate nonstatic global function Print. Stats (Address& from, uint 32_t packet. Size, uint 32_t total. Rx. Size) { std: : ostringstream oss; Inet. Socket. Address address = Inet. Socket. Address: : Convert. From (from); oss << "Received " << packet. Size << " bytes from " << address. Get. Ipv 4 () << " [" << address << "]" << " total Rx " << total. Rx. Size; return oss. str (); } (…) NS_LOG_INFO (Print. Stats (from, packet->Get. Size (), m_total. Rx)); ns-3 – Small introduction 26

SOMMAIRE 1. Introduction to ns-3 and its modules 2. Simple simulation example 3. Log module 4. Trace module 5. How to create a new module ns-3 – Small introduction 27

Trace Subsystem – Introduction o One of the most important mechanisms to understand evaluate ns-3 simulations • The way to collect data from the experiments and compare the results against previous implementations or different systems o Many other ways to get data out of the experiment • E. g. printfs, logs to files… • But are they standard? Are they scalable? Would it work for large development modules and simulations? • The work may become harder and harder ns-3 – Small introduction 28

Trace Subsystem – Why o We have already a log system, why not use it? • Different objectives • Logging subsystem control mechanism is not enough o One should be able to collect the interest information, even from the inside of the core of the system without needing to recompile the whole system o Should automatically generate standard formats (pcap) ns-3 – Small introduction 29

Trace Subsystem – Callback o Relies on Callback and Attribute mechanisms • The callback mechanism allows one piece of code to call a function (or method in C++) without any specific inter-module dependency • The called functions are threated as variables (point-to-function variable) int My. Function (int arg) {} //the function declaration pfi = My. Function; // one can initialize a variable to point to the function int result = (*pfi) (1234); // later call the function by its indirect name • Typically used in asynchronous processes as call back functions to inform when the process ended ns-3 – Small introduction 30

Trace Subsystem – Functor o To make it simple, Packaged function call • Function overload o Has two parts, a specific part and a generic part, related through inheritance • The caller function will call a generic overloaded operator (), that will cause the calling of the callback • The callback code called provides a specialized implementation of the generic operator () • The instantiated specialized functor overloaded operator () is returned to the module that will execute the callback (the calling code). • The calling code has just to understand the genneric operator ns-3 – Small introduction 31

Trace Subsystem – Functor example Functor Using example template <typename T, typename ARG> class Specific. Functor : public Functor<ARG> Class ref { public: Specific. Functor(T* p, int (T: : *_pmi)(ARG arg)) { m_p = p; Callback ref m_pmi = _pmi; } virtual int operator() (ARG arg) { (*m_pmi)(arg); } private: Callback call int (T: : *m_pmi)(ARG arg); T* m_p; }; class A { public: A (int ao) : a (a 0) {} int Hello (int b 0) { std: : cout << "Hello from A, a = " << a << " b 0 = " << b 0 << std: : endl; } Function that will be called int a; }; Instantiation of the functor with int main() the callback function reference { A a(10); Specific. Functor<A, int> sf(&a, &A: : Hello); sf(5); } Call with argument ns-3 – Small introduction 32

Trace Subsystem – Parts o Uses the concepts of independent tracing sources and tracing sinks o Tracing sources • Can signal events that happen in a simulation • Provide access to interesting underlying data o Tracing sinks • Entities that will consume the trace information and process it o We can say that trace sources are generators of events and trace sinks are consumers ns-3 – Small introduction 33

Trace Subsystem – Sources and sinks o This division provides a huge flexibility, since developers may create sources for everything they think may be useful, but if while are not connected to a sink nothing is output o There can be zero or more consumers of trace events generated by a trace source o The source and sinks are linked by callbacks ns-3 – Small introduction 34

Trace Subsystem – Trace example Using example Trace source #include ‘‘ns 3/object. h’’ #include ‘‘ns 3/uinteger. h’’ #include ‘‘ns 3/traced-value. h’’ #include ‘‘ns 3/trace-source-accessor. h’’ #include <iostream> using namespace ns 3; class My. Object : public Object { public: static Type. Id Get. Type. Id (void) { static Type. Id tid = Type. Id ("My. Object"). Set. Parent (Object: : Get. Type. Id ()). Add. Constructor<My. Object> (). Add. Trace. Source ("My. Integer", "An integer value to trace. ", Make. Trace. Source. Accessor( Add trace &My. Object: : m_my. Int)); source obj. return tid; } Genneric My. Object () {} Trace source Traced. Value<uint 32_t> m_my. Int; obj. }; ns-3 – Small introduction // Call back function void Int. Trace (Int old. Value, Int new. Value) { std: : cout << ‘‘Traced ‘‘ << old. Value << ‘‘ to ‘‘ << new. Value << std: : endl; } Callback function int main (int argc, char *argv[]) { Ptr<My. Object> my. Object = Create. Object<My. Object> (); Creates source my. Object->Trace. Connect. Without. Context ("My. Integer", Make. Callback(&Int. Trace)); Connects source and sink (informing callback) my. Object->m_my. Int = 1234; } Uses overloaded “=” operator over m_my. Int 35

Trace Subsystem – Using the Config Subsystem to Connect to Trace Sources o The most common way to access the sources is through the Config subsystem through the config path Config: : Connect. Without. Context ( "/Node. List/0/$ns 3: : Tcp. L 4 Protocol/Socket. List/0/Congestion. Window", Make. Callback (&Cwnd. Tracer)); o This function takes a path that represents a chain of Object pointers and follows them until it gets to the end of the path and interprets the last • The last segment has to be an attribute /Node. List/0/$ns 3: : Tcp. L 4 Protocol/Socket. List/0/Congestion. Window Zeroth node in The name space “$” means a Get. Object, the list of nodes Node. List contains of the following type created all simulated nodes (at run time) Zeroth socket in the Atribute, from type The list of sockets on the Traced. Value<uint 32_t> listed in the zeroth node in the returned object ns-3 – Small introduction Node. List 36

Trace Subsystem – Using the Tracing API o We are expected to have three levels of interaction with the tracing system: • Beginning user can easily control which objects are participating in tracing; • Intermediate users can extend the tracing system to modify the output format generated or use existing trace sources in different ways, without modifying the core of the simulator; • Advanced users can modify the simulator core to add new tracing sources and sinks. ns-3 – Small introduction 37

SOMMAIRE 1. Introduction to ns-3 and its modules 2. Simple simulation example 3. Log module 4. Trace module 5. How to create a new module ns-3 – Small introduction 38

Contributing with code for ns 3 o This takes into account new feature of an existing simulation model, or a new model altogether o Main steps that need to be followed and understood 1. Passing over a code review 2. License appropriately the code 3. Follow the ns-3 coding style and engineering guidelines 4. Write associated documentation, tests, examples 5. Prepare carefully your submission 6. Pick a submission tool ns-3 – Small introduction 39

Contributing with code for ns 3 – Overall o Understand how your new module will fit within ns-3 • Look the step in packet sending process • So if you’re trying to write a new application, derive from ns 3: : Application. If it’s a new routing protocol, derive from ns 3: : Ipv 4 Routing. Protocol, …. • The easiest way is to get an example of another module that is similar in functionality and uses it as an example, or a template, for the basic structure ns-3 – Small introduction 40

Contributing with code for ns 3 – Overall o To get started writing your new module, have a look at create-module. py script (inside src/) • It will generate a skeleton for your new module • It includes the necessary sub-folders for the module, and also the wscript file (for waf) o To be useful the new module has to be able to be attached to a node • The method for enabling this varies depending on the type of the component § Look into the helpers to have a hint o Write examples of how to use the module o Write tests and documentation ns-3 – Small introduction 41

Contributing with code for ns 3 – Code Review o Code review is a review process where one or more maintainers comment on the code o Contributors may be asked to revise their code or rewrite portions during this process o Code reviews are considered essential to maintaining a high quality simulation tool and reducing the potential for simulation errors o Enforce coding style guidelines o If the new module need some changes on the existing ns 3 this changes should be discussed with the maintainers beforehand to try to came up with solutions and alternatives o As much as possible, different configurations should be taken into account ns-3 – Small introduction 42

Contributing with code for ns 3 - Licensing o All code submitted must conform to the project licensing framework, which is GNU GPLv 2 compatibility o All new source files must contain a license statement o All modified source files must either conform to the license of the original file or (in rare cases) may add a license to the original license o When performing big changes in existent files, more than 20 or 30 lines, contributors may: • Add a Copyright statement in the header • Add an authorship, contact e-mail, for tracking author purposes ns-3 – Small introduction 43

Contributing with code for ns 3 – Coding style o Common set of conventions so that maintainers do not have to learn, recognize and adapt to a constantly changing code base o Since the maintainer of the code is often not the author, extensive commenting is very important o A common coding and commenting scheme can make for easier to read, easier to understand, easier to maintain and more bug-free code • Can be easily enforced with the help of the utils/check-style. py script ns-3 – Small introduction 44

Contributing with code for ns 3 – Code Layout Identation is 2 spaces Each statement into a Open and close braces different line “{“ “}” always in different lines Variables should be declared just after they are needed ns-3 – Small introduction o Follows the gnu coding standard • One variable declaration per line • While respecting a internal file coherence, variables declaration can be aligned or not among them • Each statement in a different line 45

Contributing with code for ns 3 – Code Layout o Name encoding • Function, method, and type names should follow the Camel. Case convention • Do not use all capital letters, even for acronyms, even for 2 letters ones, IP should be Ip instead Constants are all • Names should be descriptve Classes Types uses Types may optionally finish with a _t Camel. Case, with first letter capitalized UPPERCASE § English language, American spelling • Types are often names Variable instances use Camel. Case, with lower first letter § Phy, Packet, Buffer • Functions and methods adjectives and verbs § Get. X, Do. Dispose Member variables should start with m_ and global variables with g_ • Longer, descriptive names are better than short meaningless ones § Prefer size over sz • Names should always math the ns-3 – Small introduction purpose of the variable 46

Contributing with code for ns 3 – Code Layout Enables emacs users to ident their code correctly Copy right , licence, author, on the header of the file Avoid multiple Ensures the code is declarations of this. h All public methods inside the ns 3 should have comments namespace and use Doxygen tags o Comments • The code uses doxygen to document the code • Variables should have a small description of its purpose § Unless local variables that would have its use pretty obvious from the context o Do not use nil or null use 0 • Improves portability o Expose class members through access functions ns-3 – Small introduction 47

Contributing with code for ns 3 – Supporting material o Many times developers contribute with nice classes, interesting new models • But fail to include supporting test code, example scripts, and documentation • This is what will make others to be able to actually use your code o Every new submission should have at least one example that exercises the main part of the code • To help the reviewer to understand what is happening, and how to use the code • Add as much examples you can in the /samples and /examples directories ns-3 – Small introduction 48

Contributing with code for ns 3 – Supporting material o Every new code should include automated tests • Unit tests of model correctness • Validation tests of stochastic behavior • Overall system tests, if the model's interaction with other components must be tested o Documentation • Doxygen should be added to header files for public classes and methods, and should be checked for doxygen errors • Incompatible API changes must be documented in CHANGES. html • New features should be described in RELEASE_NOTES • New API or changes to existing API must update the inline doxygen documentation in header files • Consider updating or adding a new section to the tutorial in doc/tutorial/ • Consider updating or adding a new section to the manual in doc/manual/ • Update the AUTHORS file as appropriate ns-3 – Small introduction 49

Contributing with code for ns 3 – Just before submitting o Description • Ideally, one should be able to provide a summary description of what your code is doing, and why § 5 -line paragraph with a 1 -line (15 word) • Provide a description of their testing strategy o Minimize the size of each submission • Submissions should be as small as possible • Ideally, each submission should deal with one issue only o Coherent changes • Each submission should be a coherent block o Multi-part submission • If you have a huge submission you should consider breaking the submission into multiple smaller, coherent, submissions o History rewriting • Sometimes the history of version control systems are too verbose, and the majority of these logs have no meaning • The repository should be as clean as possible § Commits buildable § Pointless backups are removed ns-3 – Small introduction 50

Contributing with code for ns 3 – Submitting o Methods • Simple patch § A Unix like diff output • Patch reviews through rietveld § Rietveld is a web-based code review tool § http: //www. nsnam. org/developers/tools/rietveld/ • Hosted clone § Allow reviewers to have access to your repository § In the worst case, as an ns 3 developer, you can ask for be hosted at code. nsnam. org ns-3 – Small introduction 51

Sources o From where we get the material for this presentation • Mathieu Lacage's Trilogy summer school talks http: //www. nsnam. org/tutorials/trilogy-summer-school. pdf • Gustavo Carneiro's lab brief on ns-3 http: //www. nsnam. org/tutorials/NS-3 -LABMEETING-1. pdf • George Riley's ACM Spring. Sim keynote on ns-3 http: //www. nsnam. org/tutorials/Spring. Sim-2010 -Riley. pptx • Mathieu Lacage's Tunis tutorial http: //www. nsnam. org/tutorials/ns-3 -tutorial-tunis-apr 09. pdf • ns-3 tutorial http: //www. nsnam. org/docs/release/3. 13/tutorial/ns-3 -tutorial. pdf • ns-3 manual http: //www. nsnam. org/docs/release/3. 13/manual/ns-3 -manual. pdf • ns-3 Model Library http: //www. nsnam. org/docs/release/3. 13/models/ns-3 -model-library. pdf • ns-3 Contributing code http: //www. nsnam. org/developers/contributing-code/ ns-3 – Small introduction 52

Thank you for the Attention ns-3 – Small introduction PLANETE Group Inria Sophia Antipolis Méditerranée 10 November 2020

Simulation scenario o Easy to create a scenarios and visualize them Simulated Packets ns-3 – Small introduction 54