Skip to content
In this repository, you we implement, using OMNET++, a network topology, which consists of an SP “service provider node” (e.g., Verizon or AT&T) representing the manager of the network (i.e., the one that allocates bandwidth to the users) connecting two types of users: DSL and TDM. The DSL users D1 and D2 are each dedicated a link such that the …
C++ Makefile
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
out/gcc-debug
DSLNode.ned
Makefile
README.md
SELF.msg
SELF_m.cc
SELF_m.h
SPNode.cc
SPNode.h
SPNode.ned
TDMNode.ned
buffer.cc
buffer.h
buffer.ned
cmps284Packet.msg
cmps284Packet_m.cc
cmps284Packet_m.h
g09a2_report.pdf
grantPacket.msg
grantPacket_m.cc
grantPacket_m.h
nodeMAC.cc
nodeMAC.h
nodeMAC.ned
omnetpp.exe
omnetpp.ini
out.dat
package.ned
splitter.cc
splitter.h
splitter.ned
testt.exe
topology.ned
trafficGen.cc
trafficGen.h
trafficGen.ned

README.md

DSL-vs.-TDM-Discrete-Event-Simulations

Summary

In this repository, we implement, using OMNET++, a network topology (shown below), which consists of an SP “service provider node” (e.g., Verizon or AT&T) representing the manager of the network (i.e., the one that allocates bandwidth to the users) connecting two types of users: DSL and TDM. The DSL users D1 and D2 are each dedicated a link such that the bandwidth on the bidirectional link connecting D1 is 5Mbps, and for D2 it is 10Mbps. On the other hand, all N TDM users share a single channel of total capacity 100Mbps in both the upstream and downstream directions, and are allocated bandwidth in the upstream direction in a TDM fashion (i.e., each user Ti =1…N gets a fixed timeslot in every TDM frame). The TDM frame is set to Xms (the default value would be 2ms), such that X is a variable that can change for different simulation scenarios. Here, we shall ignore data transmission and bandwidth allocation in the downstream direction.

OMNeT++ Version

This project has been created and tested only on OMNeT++ 5.0. More likely, it might not run on OMNeT++ 4.5 or previous verisons.

Running our code

This is arguably the most important part of this README.md file. If our code doesn't run, you probably wouldn't use it. You have to EXACTLY follow the steps listed below so that our code wouldn't run.

Download the source files

Do not do it form GitHub since some hidden configuration files weren't and can't be uploaded. Instead download the file from the supported URL listed below:
https://cdn.georgechalhoub.com/academia/aub/courses/cmps284/assignments/assignment2/g09_a2.tar.gz

Extract the source files

That will easy. You may do it from the Terminal or the GUI of your operating system.

Import it onto OMNeT++

Writing this would be tedious, so I created a full functional video which shows you every step, how to download the project, how to extract it, how to import it and how to run. The URL can is listed below: https://cdn.georgechalhoub.com/academia/aub/courses/cmps284/assignments/assignment2/video.html

Network Topology

Network Diagram Topology

More information

Each of the two types of users includes a traffic generator responsible for generating traffic according to a given data rate Ri. However, a TDM user requires to buffer (in a queue) the generated packets until a time slot is available for transmission; whereas a DSL user can directly send arriving packets to the SP node since the channel is always dedicated for that user.

Thus, packets incoming to TDM users will incur four types of delay before being read at the SP side: queuing delay (at the user), transmission delay (at the user), propagation delay (the time it takes for a bit to travel from the TDM user to the SP), and packet processing time (at the SP node, when receiving the packet). In contrast, packets incoming to DSL users will incur three types of delay: transmission delay, propagation delay and packet processing time.

The splitter is a passive device responsible of forwarding incoming packets to the right direction (in this case, packets coming from TDM users to the SP node); thus it does not incur any type of delay.

The TDM frame must have a fixed time slot for each TDM user, such that the transmission occurs in a round robin fashion (i.e., T1 then T2 then T3, etc.) and each time slot is separated by a guard time G. The guard time G is set to 125 microseconds.

Thus, the time slot Si for each TDM user Ti can be calculated as follows: S1 = (X - N x G) / N

The simulator must start with the SP node sending to every DSL and TDM user a grantPacket.msg in the downstream direction. For DSL users, once the message is received, the generator is turned on (by default, it is off), and the upstream transmission starts. On the other hand, for TDM users, since the splitter will simply broadcast the message to all users, the message is first checked that it is destined to the right user (using the userID value). If the ID of the incoming message does not match its own ID, the message is dropped; otherwise the transmission start time is extracted, which specifies when the TDM user must start transmitting in the upstream direction (i.e., in the first TDM frame).

The user IDs are set as follows: The SP node will have ID 0; TDM users will have IDs from 1 to N, and DSL users D1 and D2 will have IDs N+1 and N+2, respectively.

Note: For subsequent frame(s), the TDM user should generate a self-message from the time it starts transmitting in the first frame plus Xms, and keeps repeating this indefinitely for every frame. In each time slot, the TDM user must send the generated and queued cmps284Packet.msg messages (which is provided to you) until no more packets can fit in the allocated time slot (i.e., for the period Si, if enough packets are available in the buffer). Here, fragmentation is not allowed; that is if a packet cannot fit within the remaining time slot, it stays in the queue and gets differed to the subsequent frame(s).

You would convert Si into bytes and use the result as threshold for sending packets.

The default grantPacket size is 64 bytes. The packets generated by the generator module vary in size between 64 bytes and 1518 bytes. The generator module is provided to you as trafficGen.ned(.cc/.h); however, you must complete the areas marked as TODO to have a functional module. The foregoing module must be integrated as part of the TDM and DSL nodes that you need design and implement. In the TDM user module, the generator is directly connected to buffering queue, whereas in the DSL module it can directly be linked to the output gate of the compound module. Similarly, the splitter module is provided to you. However if need be, you are responsible for ensuring it has all the required information needed to be fully functional.

Simulation Scenarios

For each network scenario, a configuration run must be created in omnetpp.ini, and the required information (i.e., set of parameters) must be specified. The statistics collected for each network scenario must be stored, to be plotted in a graph as described later.

Scenario 1

In the first network scenario, the arrival rates for D1, D2 and every Ti =1…N must be set to 2Mbps. The TDM frame is set to the default value (i.e., 2 ms). The total number of TDM users N = 10.

Scenario 2

In the second network scenario, the arrival rate for D1 is set to 5Mbps and for D2, it is set to 8 Mbps. The total number of TDM users N = 10. The arrival rate of Ti =1…5 is set to 8Mbps and of Ti =6…10 it is set to 5Mbps. The TDM frame is set to the default value (i.e., 2 ms).

Scenario 3

In the third network scenario, the arrival rate for D1 is set to 5Mbps and for D2, it is set to 12 Mbps. The total number of TDM users N = 10. The arrival rate of Ti =1…5 is set to 5Mbps and of Ti =6…10 it is set to 10Mbps. The TDM frame is set to the default value (i.e., 2 ms).

Scenario 4

In the fourth and last network scenario, the arrival rate for D1 is set to 5Mbps and for D2, it is set to 12 Mbps. The total number of TDM users N = 10. The arrival rate of Ti =1…10 is set to 12Mbps. The TDM frame is set to 2 ms.

Stopping the Simulation

The simulation must be stopped by specifying the simulation time (e.g., 20s) in omnetpp.ini.

Description of our files

1. TDMNode.ned

This file is contains the code for the compound module specifying the design of the TDM node in the network. In addition, it includes the interconnection of the simple modules nodeMAC.ned , trafficGen.ned , and buffer.ned. This node has the parameter ‘userID’ that is assigned a value between 1 and N where N is the number of TDM users connected to the splitter. On the submodular level, the output gate of the trafficGen submodule is connected to the input gate of the buffer node. The latter’s output gate is connected to the nodeMAC submodule, which has an inout gate connected to the inout gate of the parent module. The gate connections is in such a way that the nodeMAC submodule receives a grantPacket message originally from the service provider node (SPNode). If the ID of this message matches the ‘userID’ of the TDM node, trafficGen starts generating cmps284Packet messages out into the buffer node that begins to queue the messages.

2. DSLNode.ned

This is another compound module. However, this file specifies the design of the DSL node in the network. It also includes the interconnection of simple modules: nodeMAC.ned and trafficGen.ned. This node has the parameter ‘userID’ that is assigned a value of either N + 1 or N + 2. On the submodular level, the output gate of the trafficGen submodule is connected to the input gate of the nodeMAC submodule, which has an inout gate connected to the inout gate of the parent module.

3. SPNode.ned

This file is the compound (or simple) module specifying the design of the SP node in the network. It has a ‘userID’ parameter as well, but it’s value is always zero. The SPNode has an inout vector gate of size.

4. nodeMAC.ned

The file nodeMAC.ned contains the code for the simple module nodeMAC. It has no parameters in this setup, and has one inout gate and one in gate. This is the module that receives a “grantPacket” message from the SP node, turns on the generator, and sets the transmission start time. It is responsible for generating self messages for every TDM frame, and for calling the corresponding method in the buffer module to send traffic.

5. splitter.ned

The file splitter.ned contains the code for the simple module splitter. The splitter node is a passive device responsible for forwarding incoming packets from TDM users to the SP node. It has no parameters in this setup, and has two gates inout gates, one of which is vector gate.

6. buffer.ned

The file buffer.ned contains the code for the simple module buffer. The buffer node is responsible for queuing incoming packets from TDM users to the SP node. It has no parameters in this setup, and has one input gate and one output gate.

7. topology.ned

The file topology.ned, includes all simple and compound modules as well as how they are interconnected. The network module in the project is made of the SPNode that has an id of 0, in addition to ten tdm Nodes with ids between 1 and 10, as well as two dsl nodes with ids 11 and 12, and finally, a splitter node. The four scenarios all have N set to 10, thus the network module has ten tdm nodes. SPNode is the service provider node representing the manager of the network.

Furthermore, the DSL users are connected to a dedicated channel (total bandwidth of the channel of dslnode1 is 5Mbps and that of dslnode2 is 2Mbps). All TDM users share a single channel with total capacity of 100Mbps, where the dslnodes and splitter are connected directly to the SPNode:

spNode.in_out[0] <--> { delay = 13333ns; datarate = 100Mbps; } <--> splitter.to_from_SP_Node; spNode.in_out[1] <--> { delay = 16666ns; datarate = 5Mbps; } <--> dslNode1.in_out; spNode.in_out[2] <--> { delay = 16666ns; datarate = 2Mbps; } <--> dslNode2.in_out;

Where the SPNode has a vector gate of size 3. As seen in the code snippet, there is a delay (depends on distance between spnode and the corresponding node) that incurs to packets along the channel. The splitter is connected to all tdm users.

8. SPNode.h

The file acts as the header file of SPNode.cc. C++ code files in this program all have header files. The header declares "what" a class (or what is being implemented) will do, while the cpp file defines "how" it will perform those features. According to StackOverFlow, this would reduce “compilation times and also the amount of recompilation needed when something in the implementation changes.”

9. SPNode.cc

The SPNode is a simple module that is responsible for sending grant packets and processing cmps284 packets.

10. nodeMAC.h

The file acts as the header file of SPNode.cc. C++ code files in this program all have header files. The header declares "what" a class (or what is being implemented) will do, while the cpp file defines "how" it will perform those features. According to StackOverFlow, this would reduce “compilation times and also the amount of recompilation needed when something in the implementation changes.”

11. nodeMAC.cc

Contains functions handleMessage, generateMessages, writeToFile and finish.

12. buffer.h

The file acts as the header file of buffer.cc. C++ code files in this program all have header files. The header declares "what" a class (or what is being implemented) will do, while the cpp file defines "how" it will perform those features. According to StackOverFlow, this would reduce “compilation times and also the amount of recompilation needed when something in the implementation changes.”

13. buffer.cc

The buffer stars by getting the user ID, the number of TDM users, the time slot, the X time and G. It has two functions handleMessage and queue that are responsible for sending messages.

14. omnetpp.ini

​The configuration file, which includes the four different scenarios.

15. trafficGen.cc

We had to fill the TO DO that is found here.

16. trafficGen.h

The file acts as the header file of trafficGen.cc. C++ code files in this program all have header files. The header declares "what" a class (or what is being implemented) will do, while the cpp file defines "how" it will perform those features. According to StackOverFlow, this would reduce “compilation times and also the amount of recompilation needed when something in the implementation changes.”

17. grantPacket_m.cc

This file is (thankfully) autogenerated by OMNeT++.

18. grantPacket_m.h

This file is (thankfully) autogenerated by OMNeT++.

19. cmps284Packet_m.h

This file is (thankfully) autogenerated by OMNeT++.

20. cmps284Packet.msg

This file was provided to us in the assignment.

21. cmps284Packet_m.cc

This file is (thankfully) autogenerated by OMNeT++.

22. X autogenerated SELF_m.cc

This file is (thankfully) autogenerated by OMNeT++.

23. X autogenerated SELF_m.h

This file is (thankfully) autogenerated by OMNeT++.

24. splitter.cc

This file contains the functions for the splitter. The main function, handleMessage, deciding if a message is going to the TDM user or SP node, and then sending it. This file was provided.

25. splitter.h

The header file for splitter.cc ​(provided). Contains a private integer named numberOfTDMUsers as well as three functions named initialize, handleMessage and finish. This file was provided.

26. grantPacket.msg

Contains userID of type int, startTime of type simtime_t and packetSize of type int.

27. Makefile

OMNeT++ uses “Makefiles” to build our C++ code. The use of MakeFile is traditional but highly useful. While writing a Makefile is definitely not a simple job, OMNeT++ already comes with a tool that can generate the Makefile for use, saving hours of labour work.

The tool that is provided by OMNeT++ is called opp_makemake which will automatically generate a Makefile for our simulation program. The algorithm that is used by opp_make is based on the source files in the current directory or directory tree.

28. package.ned

This file contains nothing but the package name “omnetpp” and the license that is used in the code.

29. X x omnetpp.exe

This is an executable file that gets created and opened when you run the simulation. It will contain the GUI components.

30. trafficGen.ned

This file has been provided in the assignment.

31. g9_a2_report.pdf:

A comprehensive report which gives a clear and detailed description of the code design, and installation.

Prompt

This was originally a university assignment. You may find the full prompt on the URL below: https://cdn.georgechalhoub.com/academia/aub/courses/cmps284/assignments/assignment2/instructions_version2.pdf

Copyright.

There is no copyright on this. The reason I have put it online is that because I want others to use the code or learn from this project. It would be flattered if you give me back attribution but you really don't have to.

You can’t perform that action at this time.