Network MANET Information

Published:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Mobile Ad-Hoc Network (MANET) is a collection of self-organized and self-configured mobile devices which use wireless transmission for temporary communication [1]. MANET does not require any pre defined infrastructure or central administration, feature that make it easier to setup and support its great mobility and flexibility.

MANET has the capability of extending its coverage range from small scales such as Body Area Networks (BAN) and Personal Area Networks (PAN), to bigger scenarios such as Local Area Networks (LAN) and even Wide Area Networks (WAN) which imply multi-hop wireless networks and currently represent a challenge for technologies such as Mesh and WiMAX.

Different coverage ranges also involve different technologies for ad-hoc wireless networks. The Bluetooth specifications are used to build short-range MANET networks such as BANs and PANs, and the 802.11 standard supports wireless LAN ad-hoc networks.

For Routing, MANET networks do not need an address configuration server such as routers or DHCP (Dynamic Host Configuration Protocol). Every node configures its own network address and, by using the support of other nodes, finds the way to reach a destination. Moreover, every node also works as a router by forwarding data packets for other nodes [2].

Routing Protocols


Defining the experimental methodology to use is a critical task because it will determine the success of further stages such as Implementation and Evaluation. Moreover, the results produced from the experimental model have to reflect to the ones that could be obtained from real scenarios.

Taking the previous statements into account, the selection of the experimental methodology was based on the analysis of existing video evaluation techniques and tools, and their integration with simulated / virtual scenarios.

Among the research papers related to this project area, the work developed by J. Orozco [10] and C. H. Ke [15] has been the main reference for the conception of the experimental methodology deployed in the present work.

The following chapter sections will focus on the description of the proposed experimental model, which form is presented in figure xx, with particular emphasis in its sequential operations (model components), inputs, outputs, and the software tools required. Furthermore, the experimentation procedure as well as the data collection and evaluation procedures are planned and organized in order to get the results that will support the final evaluation.

YUV Video Player

YUVviewer is a freeware application to play raw videos in YUV format, created by K. K. Wang and Y. Wang [12].

YUVviewer has been used during the experimentation and its simple interface, as is shown in figure xx, has allowed an easy configuration of video settings such as Frame Size and Frame Rate as well as the parallel comparison, frame by frame, between the original raw video and the distorted video obtained after experimentation.

Raw Video Sequences

The raw video sequences used for the experimentation belong to Leibniz Universität Hannover [13], and their significant information for the experimentation is shown in the tables below:

Two frame dimensions, cif and qcif, will be tested for each video sequences sample. The first raw video, known as foreman, shows a construction worker closely talking to the camera. His background is basically the same all the time and the only relevant movements come slightly from his head while talking.

In the football raw video the camera follows the ball played by a group of people. It definitely contains more dynamic sequences than foreman, with a background changing slowly when the camera rotates, and new players appearing during the game. It is noticed that some elements, such as the pitch and the snow, have roughly the same surface and colour patterns. The movement speed of the camera increases during the last ten frames tested.

The amfootball raw video contains a closer focus than the previous football video, which increase all the elements' details. It shows much more dynamic scenes where many american football players try to protect and / or catch the ball. During the last twenty five frames tested, the movement speed of the camera suddenly increases when it tries to follow a player running away with the ball to evade the opposing team.

    Encoder

    The H.264/AVC codec (encoder / decoder) used for the experimentation is JM version 1.7 from the Fraunhofer Institute for Telecommunications, Heinrich-Hertz-Institut [14]. The newer versions have not been taken because they do not support packet losses, an important condition for the experimental model. An extra requirement to run this codec is Visual C++, and for this reason, the installation of Visual Studio 2005 has been additionally planned for the Implementation stage.

    The H.264/AVC Encoder will use the raw video sequence (*.yuv) as an input, and taking the configuration parameters from the encoder.cfg file, will encode it generating as output a bitstream (*.264). Additional output files are created as support of the encoding process (figure xx, where grey arrows indicate input generated by a previous process, and output to be used by a next process).

    Cygwin will be the environment from which all the execution commands will be run and its functionality is explained in the Implementation section. For the encoding process, the execution command to run in the cygwin console is:

    ./lencod.exe > encoding.txt

    As a good practice during the experimentation, the code generated when an execution command is run has been saved in an identifiable text file, for example, as is shown for the encoding process above, encoding.txt will contain the result generated when ./lencod.exe is run.

    The complete list of execution commands and outputs is included in Appendix D

      Parser

      This Parser tool is originally part of the experimental work on H.264/AVC developed by J. Orozco [10] on Sun platform. The version used in this project was adapted by C. H. Ke [11] to work on cygwin environment.

      The Parser takes the H.264/AVC bitstream generated by the video encoder and transforms it into serial RTP (Real-time Transport Protocol, figure xx) packets. Then, according to the parameters specified in a config file, the parser extracts, from each RTP packet, the packet ID, emission time (as function of timestamp and frame rate), packet size and priority, and save this information in a video trace file, which will be used by the ns-2 network simulator as traffic generator.

      To get a clearer understanding of the parsing process, the figure xx shows, as example, on the left side the first RTP packet parsed from amfootball_cif.264, and on the right side the information exported to amfootball_cif.txt file, which will be used by ns-2 as traffic generator.

      The parsing execution command in the cygwin console is shown below, followed by figure xx with the parser's inputs and output.

      ./parser.exe config > parsing.txt

        Network Simulator

        The Network Simulator used in this project is ns-2, an open-source simulation tool currently developed by VINT (Virtual InterNetwork Testbed) group [16]. It is a discreet event simulator for networking research with support of routing, queuing, multicast protocols and IP protocols over wired and wireless networks. Among its main strengths, ns-2 supports multiple protocols and is capable of graphically representing network traffic [17].

        Another advantage to take into account, particularly for this project, is the open adaptability of ns-2, a feature that allows its perfect integration with the video evaluation tools, an essential technical requirement at the moment of building the project's framework.

        As was mentioned in the parsing process, ns-2 receives the video trace file and virtually transmits it over a MANET network, generating, as outputs, various trace files which are shown in detail in figure xx. Two of these trace files, sd_manet and rd_manet, contain the necessary information for the next error insertion process. Details of the ns2 v.2.31 installation, framework integration and MANET network simulations are given in the Implementation chapter.

        The first of the execution commands shown below is an example of how to run MANET20.tcl, a MANET simulation script file. The second execution command is used to run MANET20-out.nam, a traffic file for the Network Animator - nam - which will open a window containing a kind of simulation player for the graphical representation of the simulation.

        ns MANET20.tcl

        nam MANET20-out.nam

          Error Insertion

          The Error Insertion tool was also developed by J. Orozco [10] and adapted to the cygwin environment by C. H. Ke [11]. This tool identifies the lost packets by comparing the sender trace file (sd_manet) and receiver trace file (rd_manet) generated by ns-2. Then, it will insert the error to the bitstream encoded (*.264) by removing the lost packets identified, and save the modified bistream as distorted.264, the file to be decoded.

          Figure xx shows an example of the error insertion process taken from the anexample01a experiment, followed by figure xx with the inputs and output of this process.

          The execution command used for the error insertion in the cygwin console is:

          ./errinsert.exe *.264 distorted.264 sd_manet rd_manet > insertingerror.txt

            Decoder

            This decoder, as previously mentioned, is also part of the H.264/AVC codec from JM 1.7. It takes the distorted bitstream from the error insertion process and decodes it into yuv format (*_distorted.yuv). The decoder also takes the original raw sequence as a reference to calculate the PSNR, and additional log files are created as shown in figure xx.

            The execution command used to run the decoding process in the cygwin console is:

            ./ldecod.exe decoder_distorted.cfg > decoding.txt

              PSNR Calculation

              Once the video has been virtually transmitted over MANET network, the video quality measurement can be done by calculating the Peak Signal to Noise Ratio -PSNR- between the original raw sequence (*.yuv) and the processed sequence (*_distorted.yuv). The PSNR Calculation tool is part of EvalVid, a video quality evaluation tool-set [18], and its process components are clearly shown in figure xx.

              The execution command used to run the PSNR calculation in the cygwin console is explained as follow:

              ./psnr.exe 352 288 420 *.yuv *_distorted.yuv > psnr.txt

              the PSNR execution command

                Experimentation Procedure

                The Experimentation has been organized in such a way that the three raw video sequences (foreman, football and amfootball), each one in cif and qcif size format, will be tested under equal experimental conditions in order to compare and contrast different parameters and obtain a fair evaluation. Moreover, each experimentation instance will be tested twice in order to avoid possible errors in execution and assure correct results.

                The experimentation has been classified as follow:

                Experiment A

                In the Experiment A, the AODV and DSDV routing protocols are tested transmitting the H.264/AVC cif video (with packet size fixed to 1500 B) on scenarios where the sender node and receiver node are separated by 1, 2 and 3 hops. Detailed information is shown in the tables below.

                raw cif video sequence: foreman_cif

                Experiment A
                instance

                Routing Protocol

                Number of hops

                example_d

                AODV

                1: node(8) → node (18)

                example_e

                AODV

                2: node(3) → node (18) → node (6)

                example_f

                AODV

                3: node(1) → node (18) → node (15) → node (11)

                example_g

                DSDV

                1: node(15) → node (18)

                example_h

                DSDV

                2: node(2) → node (9) → node (3)

                example_i

                DSDV

                3: node(12) → node (15) → node (18) → node (1)

                Table xx: foreman_cif: Experiment A instances information

                raw cif video sequence: football_cif

                Experiment A
                instance

                Routing Protocol

                Number of hops

                example01

                AODV

                1: node(8) → node (18)

                example02

                AODV

                2: node(3) → node (18) → node (6)

                example03

                AODV

                3: node(1) → node (18) → node (15) → node (11)

                example04

                DSDV

                1: node(15) → node (18)

                example05

                DSDV

                2: node(2) → node (9) → node (3)

                example06

                DSDV

                3: node(12) → node (15) → node (18) → node (1)

                Table xx: football_cif: Experiment A instances information

                raw cif video sequence: amfootball_cif

                Experiment A
                instance

                Routing Protocol

                Number of hops

                anexample01

                AODV

                1: node(8) → node (18)

                anexample02

                AODV

                2: node(3) → node (18) → node (6)

                anexample03

                AODV

                3: node(1) → node (18) → node (15) → node (11)

                anexample04

                DSDV

                1: node(15) → node (18)

                anexample05

                DSDV

                2: node(2) → node (9) → node (3)

                anexample06

                DSDV

                3: node(12) → node (15) → node (18) → node (1)

                Table xx: amfootball_cif: Experiment A instances information

                Experiment B

                For Experiment B, the AODV and DSDV routing protocols are tested transmitting the H.264/AVC cif video on scenarios where the packet size has been defined with values of 500 B, 1000 B and 1500 B, and the distance between the sender node and the receiver node fixed to 1 hop. Detailed information is shown in the tables below.

                raw cif video sequence: foreman_cif

                Experiment B
                instance

                Routing Protocol

                Packet size (B)

                example_j

                AODV

                500

                example_k

                AODV

                1000

                example_l

                AODV

                1500

                example_m

                DSDV

                500

                example_n

                DSDV

                1000

                example_o

                DSDV

                1500

                Table xx: foreman_cif: Experiment B instances information

                raw cif video sequence: football_cif

                Experiment B
                instance

                Routing Protocol

                Packet size (B)

                example07

                AODV

                500

                example08

                AODV

                1000

                example09

                AODV

                1500

                example_a

                DSDV

                500

                example_b

                DSDV

                1000

                example_c

                DSDV

                1500

                Table xx: football_cif: Experiment B instances information

                raw cif video sequence: amfootball_cif

                Experiment B
                instance

                Routing Protocol

                Packet size (B)

                anexample07

                AODV

                500

                anexample08

                AODV

                1000

                anexample09

                AODV

                1500

                anexample_a

                DSDV

                500

                anexample_b

                DSDV

                1000

                anexample_c

                DSDV

                1500

                Table xx: amfootball_cif: Experiment B instances information

                  Experiment C

                  In Experiment C, the same procedure as Experiment A is followed but this time using H.264/AVC qcif raw video sequences. Detailed information is shown in the tables below.

                  raw qcif video sequence: foreman_qcif

                  Experiment C
                  instance

                  Routing Protocol

                  Number of hops

                  exampleq_p

                  AODV

                  1: node(8) → node (18)

                  exampleq_q

                  AODV

                  2: node(3) → node (18) → node (6)

                  exampleq_r

                  AODV

                  3: node(1) → node (18) → node (15) → node (11)

                  exampleq_s

                  DSDV

                  1: node(15) → node (18)

                  exampleq_t

                  DSDV

                  2: node(2) → node (9) → node (3)

                  exampleq_u

                  DSDV

                  3: node(12) → node (15) → node (18) → node (1)

                  Table xx: foreman_qcif: Experiment C instances information

                  raw qcif video sequence: football_qcif

                  Experiment C
                  instance

                  Routing Protocol

                  Number of hops

                  exampleq01

                  AODV

                  1: node(8) → node (18)

                  exampleq02

                  AODV

                  2: node(3) → node (18) → node (6)

                  exampleq03

                  AODV

                  3: node(1) → node (18) → node (15) → node (11)

                  exampleq04

                  DSDV

                  1: node(15) → node (18)

                  exampleq05

                  DSDV

                  2: node(2) → node (9) → node (3)

                  exampleq06

                  DSDV

                  3: node(12) → node (15) → node (18) → node (1)

                  Table xx: football_qcif: Experiment C instances information

                  raw qcif video sequence: amfootball_qcif

                  Experiment C
                  instance

                  Routing Protocol

                  Number of hops

                  exampleq_d

                  AODV

                  1: node(8) → node (18)

                  exampleq_e

                  AODV

                  2: node(3) → node (18) → node (6)

                  exampleq_f

                  AODV

                  3: node(1) → node (18) → node (15) → node (11)

                  exampleq_g

                  DSDV

                  1: node(15) → node (18)

                  exampleq_h

                  DSDV

                  2: node(2) → node (9) → node (3)

                  exampleq_i

                  DSDV

                  3: node(12) → node (15) → node (18) → node (1)

                  Table xx: amfootball_qcif: Experiment C instances information

                    Experiment D

                    In Experiment D, the same procedure as Experiment B is followed but this time using H.264/AVC qcif raw video sequences. Detailed information is shown in the tables below.

                    raw qcif video sequence: foreman_qcif

                    Experiment D
                    instance

                    Routing Protocol

                    Packet size (B)

                    exampleq_v

                    AODV

                    500

                    exampleq_w

                    AODV

                    1000

                    exampleq_x

                    AODV

                    1500

                    exampleq_y

                    DSDV

                    500

                    exampleq_z

                    DSDV

                    1000

                    exampleq_zz

                    DSDV

                    1500

                    Table xx: foreman_qcif: Experiment D instances information

                    raw qcif video sequence: football_qcif

                    Experiment D
                    instance

                    Routing Protocol

                    Packet size (B)

                    exampleq07

                    AODV

                    500

                    exampleq08

                    AODV

                    1000

                    exampleq09

                    AODV

                    1500

                    exampleq_a

                    DSDV

                    500

                    exampleq_b

                    DSDV

                    1000

                    exampleq_c

                    DSDV

                    1500

                    Table xx: football_qcif: Experiment D instances information

                    raw qcif video sequence: amfootball_qcif

                    Experiment D
                    instance

                    Routing Protocol

                    Packet size (B)

                    exampleq_j

                    AODV

                    500

                    exampleq_k

                    AODV

                    1000

                    exampleq_l

                    AODV

                    1500

                    exampleq_m

                    DSDV

                    500

                    exampleq_n

                    DSDV

                    1000

                    exampleq_o

                    DSDV

                    1500

                    Table xx: amfootball_qcif: Experiment D instances information

                      Data Collection and Evaluation Procedures

                      After each experimentation instance, the average PSNR value can be taken either from the decoding output files (log.dec and decoding.txt) or from the EvalVid PSNR.exe output (PSNR.txt). Then, Line-with-Markers charts from Microsoft Excel will be created to support the analysis of the results. It will be done specifically by comparing, for both AODV and DSDV routing protocols, the PSNR values against the number of hops for experiments A and C, and the PSNR Values against the packet sizes for experiments B and D.


                      Chapter 4: Implementation

                      Initial Settings

                      During the early stage of the framework implementation, ns-2 was installed in different Linux distributions such as Fedora 9, openSUSE 11 and Ubuntu 7.10 (Gutsy Gibbon). This later one showed more support online related to ns-2 and therefore an easier detailed process of installation.

                      When the integration to the video tools required for the final framework started, some executable files (.exe) were Win32 files, even though these could still be run on Linux by using Wine, an open source implementation of the Windows API on top of Unix [20]. However this Windows emulator as solution was not enough because the H.264/AVC Software Coordination, specifically the H.264/AVC coded, required Visual C++ as a component to encode and decode video sequences.

                      Then, migrating to a Windows environment was decided, and a Linux-like environment needed in order to run the ns-2 network simulator. Four options were found to do it:

                      • andLinux, an Ubuntu Linux system running in Windows 2000 based systems, still in beta version [21],

                      • Wubi, an official Ubuntu installer for Windows [22],

                      • Cooperative Linux, short-named coLinux, a method to run Linux on Windows natively [23], and,

                      • Cygwin, a set of tools to provide Linux capabilities on Windows platforms [24].

                      Between them, Cygwin was chosen because of its proven compatibility with ns-2 and the set of video tools.

                        Cygwin Installation

                        According to Chih-Heng Ke [ xx ], the latest version of ns-2 (v2.33) requires the latest gcc version (C / C++ compiler) which comes in the latest version of Cygwin (v1.5.25), and it is not compatible with the framework needed for the video evaluation. Then, it is recommended to use a previous version of Cygwin (v1.5.7) which works with the ns-2 versions 2.28, 2.29 and 2.31.

                        The first attempt to install Cygwin was done in Windows Vista, but even disabling its User Account Control (UAC) function and enabling the 'Windows XP SP2' compatibility, the operating system did not allow Cygwin to run properly. Cygwin was finally fresh installed in a Windows XP successfully, and the following table shows the components additionally installed for ns-2:

                        Component

                        Description

                        Packages / Version

                        XFree86

                        Implementation of the X Window System

                        XFree86-base v4.3.0-1,

                        XFree86-bin v4.3.0-8,

                        XFree86-prog v4.3.0-12,

                        XFree86-lib v4.3.0-1,

                        XFree86-etc v4.3.0-6

                        Make

                        The GNU version of the 'make' utility

                        make v3.80-1

                        Patch

                        Apply a diff file to an original

                        patch v2.5.8-8

                        Perl

                        Larry Wall's Practical Extracting and Report Language

                        perl v5.8.2-1

                        Gcc

                        GCC C compiler

                        gcc v3.3.1-3

                        gcc-g++

                        GCC C++ compiler

                        gcc-g++ v3.3.1-3

                        Gawk

                        GNU awk, a pattern scanning and processing language

                        gawk v3.1.3-4

                        gnuplot

                        A command-line driven interactive function plotting utility

                        gnuplot v3.8j.0-1

                        Tar

                        A GNU file archiving program

                        tar v1.13.25-5

                        Gzip

                        A GNU compression utility

                        gzip v1.3.5-1

                        Table xx: Cygwin Components installed for ns-2

                          ns-2 Installation

                          Once Cygwin is properly installed, ns-2 installation process is the same as the one followed in a Linux native environment. These are all the steps for ns-2 v2.31:

                          • Download ns-allinone-2.31.tar.gz from http://nchc.dl.sourceforge.net/sourceforge/nsnam/ , or from any official mirror, and move the file to the path d:/cygwin/home/Javier , where d is the local drive and Javier is the login name.

                          • Open a Cygwin window and in the path previously mentioned decompress the ns-allinone-2.31.tar.gz file by typing

                          tar -xzvf ns-allinone-2.31.tar.gz .

                          • Type cd ns-allinone-2.31 .

                          • Type ./install .

                          • Set the environment variables by adding them into the .bashrc file located on d:/cygwin/home/Javier :

                          • Refresh the environment variables by typing source ~/.bashrc .

                          • If ns-2 has been installed correctly by typing ns the percent sign % will be shown.

                          • Moreover, a validation can be done by typing ./validate in the

                          ns-2.31 folder, it will take about half an hour.

                            Patching ns-2 for H.264/AVC Video Evaluation Framework

                            For the final implementation of the Evaluation framework, ns-2 has to be patched by adapting it to use a parsed bitstream (trace file) as the traffic generator, and record packets information to be used by the decoding process afterwards. The ns-2 modification is based on the experiment done by C. H. Ke [11].

                            The ns-2 extensions start with the declaration of two new fields in the packet header, frametype and sendtime. frametype to define the type of frame a packet belongs to, with values of 1, 2, and 3 for the frames I, P and B respectively, and sendtime to set the timestamp when a packet is sent. The addition of these new fields is done in the packet.h file located in the path /ns2.31/common/ as the following figure shows:

                            These two new fields have to be declared in the agent.h and agent.cc files as well, located in the same path /ns2.31/common/ , as follow:

                            simulation script file.

                            MyUDP agent is an extension of the ns-2 UDP agent and does the same functions as win-dump and tcp-dump in real network environments. It assigns the output file name of the sender trace file (chosen by the user, in this particular case sd_manet) and records the timestamp, ID and payload size of each packet transmitted.

                            MyUDPSink agent is an extension of the ns-2 UDPSink agent and receives the fragmented packets from the MyUDP agent. It records the timestamp, ID and payload size of each packet received in the receiver trace file (which in this particular case is called rd_manet).

                            These new agents are implemented by five files: myudp.cc, myudp.h, myudpsink3.cc, myudpsink3.h, and mytraffictrace3.cc, which can be downloaded from [11] and saved in a folder called myh264 (path: /ns2.31/myh264/).

                            The new agents integration finishes with the modification of the
                            ns-default.tcl file located in the path ns-2.31/tcl/lib/ , and the insertion of their object files (MyUdp.o, MyUdpSink.o and MyTrafficTrace.o) in the OBJ_CC list of the ns-2.31 Makefile.

                            The changes will take effect after an ns-2.31 recompilation by typing ./configure ; make clean; make in the cygwin console (path:
                            /ns-allinone-2.31/ns2.31/).

                              MANET Prototype Model

                              Before experimenting into the H.264/AVC video evaluation over MANET network itself, an initial MANET prototype model was built to develop a good understanding of the simulation process in ns-2 environment. This MANET prototype model consists of 10 nodes with a predefined movement and constant bit rate packets (512 B) sent from node 0 to node 2. FTP is set as background traffic and AODV as routing protocol. The code sections of this MANET prototype model can be found in the Appendix XX.

                                Main Model

                                After the development of the MANET prototype model, which was built with default ns-2 parameters, an implementation of a MANET simulation main model started. This was a critical part of the implementation stage, where the design of a MANET network simulation using the extended / adapted ns-2 environment was necessary to accomplish the whole integration of the H.264/AVC video evaluation framework and its successful experimentation.

                                The code of the MANET simulation main model has been functionally divided into three files: MANET20.tcl, traffic-20-test and scen-20-test. An explanation in detail of them is dedicated to the rest of this section, and the codes included in Appendix B.

                                MANET20.tcl

                                As the figure xx shows, at the beginning of the MANET20.tcl, the mobile node characteristics are set before creating them. The channel type is defined as WirelessChannel model which handles the hidden and exposed terminal problem. The Radio-Propagation model is TwoRayGround, used when line-of-sight path exists between transmitter and receiver and reflexion of ground is considered [25], and the antenna type is OmniAntenna.

                                ns-2 uses Phy/WirelessPhy as the network interface type to simulate 802.11 wireless channel, Mac/802_11 is used as the Medium Access Control (MAC) type, and LL as the Link Layer type.

                                The interface queue (ifq) is a parameter used to define how packets are dropped at a node. For the simulation it is set to Queue/DropTail/PriQueue which means the queue is a FIFO one (DropTail) and the priority is given to routing packets (PriQueue). For the interface queue length (ifqlen), 300 is the maximum number of packets in buffer.

                                The seed parameter controls the (pseudo) random generators used in the
                                ns-2 simulations. Seed value 0.0 produces a new seed for every simulation run [26].

                                The dimensions (x, y) of the topology are set as (800, 500) in meters, and the simulation time is 400.0 seconds.

                                The nn parameter is the number of nodes to simulate. For the MANET prototype model it was set to 10, and for the MANET simulation main model the nn value is doubled to 20. Setting the value to 20 guaranties a high probability of finding and keeping a specific number of hops unvaried with the specific mobile nodes during the whole H.264/AVC video transmission over the MANET network, a condition required.

                                The adhocRouting parameter defines the Ad-hoc Routing Protocol to be used in the simulation. Ad-hoc On-demand Distance Vector (AODV), and Destination Sequence Distance Vector (DSDV) are the two routing protocols evaluated.

                                The packetSize parameter unit is Bytes and during the experimentation, values of 500, 1000 and 1500 B will be evaluated.

                                The cp and sc parameters call the traffic-20-test and scen-20-test files respectively. In the traffic-20-test file all the traffic flows are defined, and the scen-20-test file contains the information related to the nodes movement.

                                After completing the declaration of the mobile nodes parameters, the main tcl simulation script starts with the initialization of the global variables as is shown in Figure xx.

                                Firstly, an instance of the Simulator tcl class is created and assigned to the variable ns_ . With this class, a number of methods is called, such as the ones used to create nodes, links and topologies [27].

                                Then the topography object is called to keep track of movements of the nodes within the topological boundaries which were set to (x, y) = (800, 500) previously.

                                The trace support is set up for ns and nam by respectively opening the MANET20-out.tr and MANET20-out.nam, and calling their procedures
                                trace-all and namtrace-all-wireless. The trace file for ns is a log file where is kept information in detail about every stage a packet traces from source to destination, and nam (Network Animator) is a tool to get a graphical representation of the nam trace file generated by ns-2.

                                The last line shown in the figure xx creates a god (General Operations Director) instance. god will use nn (number of nodes = 20) as argument to build a matrix to store connectivity information of the topology [28].

                                The figure xx shows the final configuration of the mobile nodes with the agentTrace (AGT), routerTrace (RTR) and macTrace (MAC) turned on. These traces will be part of the information provided in the trace file.

                                After the nodes configuration, the tcl for loop will create the nn (20) nodes (from 0 to nn-1). random-motion is disabled (0) because the nodes movement is pre defined in the scen-20-test file. A unique pre defined scenario is required in order to obtain the same conditions for all the simulations and then produce unbiased results.

                                Once the mobile nodes have been created, their scenario and traffic pattern are loaded (imported from scen-20-test and traffic-20-test files respectively), and the initial position of the nodes in nam is defined, as is shown in Figure xx.

                                The figure xx shows the final instructions in MANET20.tcl file, setting the starting times for the traffic flows, and the closing times for the tracing activity and simulation in general. It is highlighted that the FTP background traffic starts first (at 20.0 seconds), and the video transmission starts 5 seconds later.

                                traffic-20-test

                                The traffic-20-test file starts with the definition of a MyUDP Agent, myUDP, assigned to a variable called udp1 and attached to a node, which in the sample shown in the figure xx is 8. This node will take the fragmented packets (whose size is defined in the main tcl file) from a MyTrafficTrace Agent to generate the udp traffic, and relevant information such as timestamp, ID, and payload size of each packet will be recorded in the sender trace file sd_manet .

                                After setting the traffic source, a MyUDPSink Agent, myUdpSink3, is defined, assigned to the variable null1, and attached to a node, which will take the function of sink (or destination) node. In figure xx, node 18 is the sink node, which will receive the udp traffic, and similarly to the sender, a receiver trace file rd_manet is created.

                                Continuing the analysis of the code in Figure xx, from line 11 to line 26, the trace file (or parsed bitstream), amfootball_cif.txt, is imported and information such as time ($time), framesize ($length) and frametype ($type) is extracted from it to a trace file called video1.dat .

                                Getting simulations as realistic as possible is important and the inclusion of background traffic flow support it. An FTP application using tcp as transport protocol is defined and attached to the same nodes involved in the transmission of the main udp traffic flow, according to the figure xx, the node 8 as tcp generator and the node 18 as tcp sink.

                                After defining the traffic flows, a MyTrafficTrace Agent, myTrace3, is defined and assigned to video1, the traffic trace file, which will be divided into smaller packets and attached to the lower layer udp1. The rest of the last instructions of traffic-20-test file, as shown in figure xx, are related to closing procedures of simulation time and trace files.

                                  scen-20-test

                                  This nodes movement pattern file has been generated by using the setdest ns-2 utility located in the path /ns2.31/indep-utils/cmu-scen-gen/setdest/ .
                                  The following parameters [29] were taking into account:

                                  Parameter

                                  Function

                                  Range

                                  Value

                                  Unit

                                  -v

                                  version

                                  1, 2

                                  1

                                  -n

                                  number of nodes

                                  1, 2, ...

                                  20

                                  -p

                                  pause time

                                  ≥ 0

                                  5.00

                                  seconds

                                  -M

                                  maximum speed

                                  ≥ 0

                                  10.00

                                  m/s

                                  -t

                                  maximum time

                                  ≥ 0

                                  400.00

                                  seconds

                                  -x

                                  width of space

                                  ≥ 0

                                  800.00

                                  meters

                                  -y

                                  height of space

                                  ≥ 0

                                  500.00

                                  meters

                                  Table xx: setdest parameters

                                  Then the line to run in the cygwin console is:

                                  Due to the number of mobile nodes and time simulated, a scen-20-test file with over two thousand lines is generated, and four sections has been clearly identified as follow:

                                  The scen-20-test file starts setting the initial (X, Y, Z) coordinates for each mobile node, as is shown in the figure xx for nodes 1, 2 and 3. The simulations are based on a two-dimensional scenario, therefore z=0.

                                  Once the initial topological location of all the nodes has been defined, the god object will store an array of the shortest / optimal number

Writing Services

Essay Writing
Service

Find out how the very best essay writing service can help you accomplish more and achieve higher marks today.

Assignment Writing Service

From complicated assignments to tricky tasks, our experts can tackle virtually any question thrown at them.

Dissertation Writing Service

A dissertation (also known as a thesis or research project) is probably the most important piece of work for any student! From full dissertations to individual chapters, we’re on hand to support you.

Coursework Writing Service

Our expert qualified writers can help you get your coursework right first time, every time.

Dissertation Proposal Service

The first step to completing a dissertation is to create a proposal that talks about what you wish to do. Our experts can design suitable methodologies - perfect to help you get started with a dissertation.

Report Writing
Service

Reports for any audience. Perfectly structured, professionally written, and tailored to suit your exact requirements.

Essay Skeleton Answer Service

If you’re just looking for some help to get started on an essay, our outline service provides you with a perfect essay plan.

Marking & Proofreading Service

Not sure if your work is hitting the mark? Struggling to get feedback from your lecturer? Our premium marking service was created just for you - get the feedback you deserve now.

Exam Revision
Service

Exams can be one of the most stressful experiences you’ll ever have! Revision is key, and we’re here to help. With custom created revision notes and exam answers, you’ll never feel underprepared again.