The present essay is a tutorial on the OMNeT++ simulation environment, through the analysis of the known ALOHA protocol. The theoretical account implements the ALOHA random entree protocol on the Link bed, and simulates a host to server instant broadcast. ALOHA is instead simple yet convenient to show the potency of OMNeT++ in imitating radio protocols. The concluding portion evaluates the pure and the slotted ALOHA fluctuations, in respect to the theoretical theoretical accounts.

Introduction

OMNeT++ is a distinct event simulation ( DES ) environment, developed by Andras Varga as public beginning, and is accompanied by Academic Public License, which means that it is free for non-profit-making academic usage. The purpose behind OMNeT++ was the development of an unfastened beginning generic simulation environment, non entirely dedicated to web simulations as the more known ns-2, or the commercial Opnet. The environment offers alternatively, a generic and flexible platform to develop simulation models dedicated to complex IT systems, as radio and detector webs, the authoritative IP and IPv6 tonss, line uping webs, optical webs and assorted hardware architectures.

Typical illustration of a model that provides simulation constituents for IP, TCP, UDP, Ethernet and MPLS, is the INET Framework and the MiXiM, which is an collection of several models for Mobile and wireless simulations. The OMNeT++ ver. 4.0 is built on the known Eclipse CDT ver. 5.0, and uses most of its resources. It is offered for Windows and Linux runing systems. The nucleus of the theoretical accounts is coded in C++ , in Linux uses the gcc compiler and in Windows uses the MinGW port for the gcc suite. There is a commercial version called OMNEST, with no important accoutrements than the unfastened version, except the optional usage of the native Visual C++ compiler for the Windows platform.

The ALOHA protocol was one of the oldest random entree protocols, invented by Norm Abramson in 1969. The first radio web, implementing package shift over wireless, used the pure ALOHA fluctuation, have ab initio established in Hawaii. Later Abramson interfaced the ALOHAnet with the ARPAnet, the crude signifier of cyberspace. The ALOHA have inspired the creative activity of CSMA/CD and the birth of Ethernet. Finally, the random entree protocol has evolved to modern-day CSMA/CA, the MAC bed of Wi-Fi. The slotted ALOHA and the ulterior pure ALOHA have simple executions, appropriate for simulation. It uses merely the host to server broadcast blink of an eye, but is equal to cipher the maximal channel capacity and show some other interesting properties, every bit good.

OMNeT++ DESCRIPTION

The Structure of Models

OMNeT++ is based on C++ scheduling and follows the object-oriented attack with categories and category cases, the alleged objects. The simulation theoretical account consists of faculties, which communicate by message passing. The nucleus component is the simple faculty, which is written in C++ , and constitutes an case of a faculty type from the simulation category library. The following structural component in the hierarchy is the compound theoretical account, which is formed from simple faculties or other compound theoretical accounts. Every faculty, simple or compound, has ports to pass on with the external environment, called Gatess. Gates could be bidirectional or could be restricted to input or end product. Faculties are connected through their Gatess via connexions and they communicate by interchanging messages, via these connexions.

Fig. 1. Model construction in OMNeT++ .

The block diagram in Fig. 1 depicts the internal faculty construction harmonizing to the declared hierarchy, in OMNeT++ . The connexions are limited within the faculty scope but the message exchange can be established across hierarchy degrees. This is applicable in the instance of patterning wireless systems and the simulation of ALOHA Stationss will do usage of it. Otherwise, messages are going through the concatenation of connexions. Faculties have parametric quantities, which are used to go through low-level formatting informations during the induction of the simulation. The compound theoretical accounts can go through parametric quantities to the contained sub-modules. The concluding theoretical account which contains the sum of the faculties is called web theoretical account, is represented as a category and each simulation tally is executed on an case of this category.

The NED linguistic communication

The construction of the simulation in OMNeT++ is based on the web description linguistic communication ( NED ) . The NED includes declarations for the simple faculties and definitions for the compound faculties and the web theoretical account. The linguistic communication scheduling is accomplished by the incorporate in writing editor, as shown in Fig. 2 or the text editor, as shown in Fig. 3. Both editors are bring forthing tantamount codification, and the coder can exchange from one another without any disparagement.

Fig. 2. The in writing editor for NED.

Fig. 3. The text editor for NED.

The scheduling theoretical account

The typical codification development includes the undermentioned stairss: The coder creates the web theoretical account, by making the appropriate network_name.ned file, utilizing the IDE. The NED file describes the web name and the topology, which are the names of the sub-modules, simples and compounds. Every sub-module should hold its ain module_name.ned file, which includes the parametric quantity declarations and other meta-data. As mentioned, the behaviour of every simple faculty is expressed in C++ , so there should be two specific files, the module_name.cc and the module_name.h, for every simple faculty. These files are compiled during simulation executing by the back uping C++ compiler, and linked with the simulation meat and libraries.

The coder normally tests the behaviour of the simulation theoretical account harmonizing to different inputs. These could be entered manually by the user, during simulation executing, or could be included in a constellation file. By and large, there is a particular type of file the omnetpp.ini that contains these parametric quantities and the remainder of the edifice blocks, to back up user interaction. The IDE includes an editor for the low-level formatting files, which can exchange between signifier position, as shown in Fig. 4, and beginning position, as shown in Fig. 5. The two Fieldss are tantamount.

Fig. 4. The text editor for NED.

There are two cardinal methods to develop C++ codification for programming the simple faculty behaviour: The co-routine based and the event processing map. In the first attack, every faculty executes its ain menace of codification, which is activated every clip it receives a message from the simulation meat. In the last attack, the simulation meat calls the faculty map, holding the specific message as statement. Prior to chief ( ) map executing, an low-level formatting map declares variables and objects and before plan expiration, a finalisation map saves the informations logged during simulation, and produces histograms.

Fig. 5. The text editor for NED.

OMNeT++ Architecture and Potentiality

The undermentioned Fig. 6 nowadayss the internal logic construction of OMNeT++ . The first block is the theoretical account constituent library, which the coder develops in C++ , and contains the compiled codification of simple and compound faculties. The simulation meat and the category library ( SIM ) instantiates the faculties and construct the concrete simulation theoretical account. The user interface libraries ( Envir and Cmdenv or Tkenv ) provide the simulation environment, which defines the beginning of input informations, the sink of simulation consequences and the debugging information. It controls the simulation executing, visual image and life.

Fig. 6. OMNeT++ architecture and logical blocks.

Cmdenv provides merely command line and text manner input-output, and it is more appropriate for batch simulations. Tkenv is the graphical user interface ( GUI ) of OMNeT++ . It provides automatic life, faculty end product Windowss and object inspectors. The undermentioned Fig. 7 depicts an active simulation end product through OMNeT++/Tkenv.

Fig. 7. OMNeT++Tkenv simulation end product.

OMNeT++ includes really powerful tools to visualise the interaction among faculties. A sequence chart diagram provides a manner to inspect the timing of the events during simulation by pull outing informations from an event log file. During the finalisation modus operandi, the logged informations are saved to specific consequence files, the vectors in network_name.vec and the scalars in network_name.sca files, severally. For the consequence analysis, OMNeT++ produces the analysis file network_name.anf, which contains aggregated informations in vectors and scalars plus any histograms, created during the concluding phase. All the types of informations can be farther processed by utilizing form regulations, in “ datasets and charts ” subdivision, to bring forth advanced charts and graphs. In the ALOHA simulation most of the available picks are used for presentation.

Aloha Simulation

Background Theory

The slotted ALOHA is the most simple random entree protocol. The conveying station ever broadcasts at the full rate R of the channel. The transmittal initiates at the beginning of the slot, which is common for the sum of the Stationss. If two or more Stationss transmit at the same time, so the status is called hit and all the Stationss involved, after a random clip different for each, retransmit the frame until successful bringing. The process is presented at the undermentioned figure:

Fig. 8. Slotted ALOHA protocol.

The slotted ALOHA protocol allows each station to transmitat at the channel ‘s full velocity R, but requires slots to be synchronized in all the Stationss, something non nessesary for the unslotted or pure ALOHA. The undermentioned assumtions are made to simplify simulation:

The beginning generates individual frames of length L spots. The inter-arrival times between frames follow exponential distribution.

If R bits per second is the capacity of the radio nexus so the slot clip is set equal to the transmittal clip of each frame, which is: .

All nodes are synchronized and convey frames merely at the beginning of a slot.

If a node has a new frame to direct, it waits until the beginning of the following slot.

If two or more frames collide, so their hosts retransmit after random clip, following exponential distribution.

If there is no hit, so the node transmits its following frame following exponential distribution.

I define N the figure of Stationss runing the slotted ALOHA protocol and p the chance of each station to convey in the following slot. The chance for the same station to make non convey in the following slot is so, and for the remainder of the Stationss is. Therefore, the chance for a station to hold a successful transmittal during the following slot is to convey and the remainder of the Stationss to make non convey, so it is, and because there are N Stationss, the chance that an arbitrary node has a successful transmittal is.

A slot where a individual station transmits is called a successful slot. The efficiency of slotted ALOHA is defined as the long tally fraction of successful slots, which is:

To happen the maximal efficiency, we seek that maximizes ( 1 ) . Then:

. Using this value, the maximal efficiency is:

For a big figure of active Stationss, the maximal efficiency accrues from ( 2 ) as N approaches eternity:

From ( 3 ) , the maximal efficiency of slotted ALOHA is 0.368 or 36.8 %

The unslotted version or pure ALOHA protocol does non hold the limitation of slot synchronism, and the station is able to air when a new frame is available. So pure ALOHA is a full-decentralized random entree protocol. When a transmission station detects a hit, after finishing the transmittal, it retransmits the frame with chance p. If it chooses to prorogue the transmittal for a individual frame transmittal period, so the chance is ( 1-p ) . The figure below depicts transmittals and hits in the unslotted channel.

Fig. 9. Pure ALOHA protocol.

The maximal efficiency of pure ALOHA protocol is calculated likewise as the slotted ALOHA. The lone difference here is that the remainder of the Stationss should hold non begun conveying before and should non get down during the broadcast of the given station. The chance that the remainder of the Stationss remain idle is and the chance that they remain idle is once more. Therefore, the chance that the given station will hold a successful transmittal is.

Again, we seek the value of that maximizes ( 4 ) , which is the chance of successful transmittal for the amount of the N Stationss.

. Using this value the maximal efficiency is:

From ( 5 ) , the maximal efficiency accrues as N approaches eternity, which is:

From ( 6 ) I assume that the maximal efficiency, for the pure ALOHA protocol, is 0.184 or 18.39 % , the half of slotted ALOHA.

Fig. 10. Throughput in ALOHA protocols.

Another utile diagram is in Fig. 10. It depicts the evident high quality of slotted ALOHA over the pure ALOHA protocol, despite the restrictions that turn it to non-functional. The normalized sum traffic is the aggregative traffic, which generated by the beginning of the station, divided by the channel capacity R and the normalized throughput I? is the mean successful traffic ( non-collided ) divided by R. The slotted ALOHA achieves double throughput than the pure ALOHA and achieves its maximal efficiency when the generated traffic rate peers the channel ‘s capacity R. The pure ALOHA although, achieves its maximal efficiency when the generated traffic peers to R/2.

Model Development

NED linguistic communication

The undermentioned paragraphs describe the procedure of making a functional theoretical account for the simulation of ALOHA protocol in OMNeT++ . The object of simulation is to analyze the behaviour of the ALOHA theoretical account and to corroborate the theoretical values of maximal efficiency for pure and slotted ALOHA. The ALOHA random entree protocol is peer based and does non utilize a server-client architecture. It is convenient to analyze the consequence of hits and random retransmissions merely in the instance when one host is having ( becomes server ) and the remainder of the hosts are conveying.

The first measure is to develop the NED codification that describes the web Aloha. The undermentioned Aloha.ned file creates the Aloha web, which consist of simple faculties, one called waiter and a figure of hosts, equal to numHosts parameter. The txRate defines the transmittal rate R, of the radio channel, and slotTime defines the type of protocol. Zero means pure ALOHA and 100ms defines the slot clip length. The parametric quantity @ show selects a background image, taken from the library.

web Aloha

{

parametric quantities:

int numHosts ; // figure of hosts

dual txRate @ unit ( bits per second ) ; // transmittal rate

dual slotTime @ unit ( MS ) ; // zero means no slots ( pure Aloha )

@ show ( “ bgi=background/terrain ” ) ;

submodules:

waiter: Waiter ;

host [ numHosts ] : Host {

txRate = txRate ;

slotTime = slotTime ;

}

}

The undermentioned Server.ned file describes the waiter ‘s simple faculty. It loads an image for the waiter icon and defines a gate of input type ( in ) , with which it is non necessary to set up a connexion. It can have a message straight from a host via @ directIn, something that is usual to wireless simulations.

simple Server

{

parametric quantities:

@ show ( “ i=device/antennatower_l ” ) ;

Gatess:

input in @ directIn ;

}

The undermentioned Host.ned describes the host ‘s simple faculty. It loads a set of parametric quantities from the omnetpp.ini file, the radioDelay, which is the extension hold over the wireless nexus, pkLenBits, which is the length of the frame, and iaTime, which is the random inter-arrival clip, following exponential distribution. The remainder of the parametric quantities, txRate and slotTime, are loaded in Aloha.ned, during sub-module instantiation.

simple Host

{

parametric quantities:

dual txRate @ unit ( bits per second ) ; // transmittal rate

dual radioDelay @ unit ( s ) ; // extension hold of wireless nexus

volatile int pkLenBits @ unit ( B ) ; // package length in spots

volatile dual iaTime @ unit ( s ) ; // packet interarrival clip

dual slotTime @ unit ( s ) ; // zero means no slots ( pure Aloha )

@ show ( “ i=device/pc_s ” ) ;

}

Configuration

The most critical file is the constellation file omnetpp.ini. It shops the values of the parametric quantities that are loaded in the NED parametric quantity Fieldss. When declaring on the [ General ] field that Aloha.slotTime=0, is presets globally the pure ALOHA protocol. Similarly, the Aloha.numHosts=20 defines the figure of hosts to be 20, the Aloha.txRate=9.6kbps defines the R to be 9600bps. The last definitions load the parametric quantities of Aloha theoretical account and accordingly the parametric quantities of the simple faculties that Aloha theoretical account controls, which are the waiter and the host faculties. The definitions Aloha.host [ * ] .pkLenBits=952b and Aloha.host [ * ] .radioDelay=10ms load straight the parametric quantities pk.LenBits and radioDelay on every host submodule, severally.

[ General ]

web = Aloha

# debug-on-errors = true

# record-eventlog = true

Aloha.numHosts = 20

Aloha.slotTime = 0 # no slots

Aloha.txRate = 9.6Kbps

Aloha.host [ * ] .pkLenBits = 952b # =119 bytes, so that ( with +1 byte guard ) slotTime is a nice unit of ammunition figure

Aloha.host [ * ] .radioDelay = 10ms

[ Config PureAloha1 ]

description = “ pure Aloha, overloaded ”

# excessively frequent transmittals result in high hit rate and low channel use

Aloha.host [ * ] .iaTime = exponential ( 2s )

[ Config PureAloha2 ]

description = “ pure Aloha, optimum burden ”

# near optimum burden, channel use is close theoretical upper limit 1/2e

Aloha.host [ * ] .iaTime = exponential ( 6s )

[ Config PureAloha3 ]

description = “ pure Aloha, low traffic ”

# really low traffic consequences in channel being idle most of the clip

Aloha.host [ * ] .iaTime = exponential ( 30s )

[ Config PureAlohaExperiment ]

description = “ Experimental mutliparameter demostration ”

repetition = 2

sim-time-limit = 90min

**.vector-recording = false

Aloha.numHosts = $ { numHosts=10,15,20 }

Aloha.host [ * ] .iaTime = exponential ( $ { mean=1,2,3,4,5..9 measure 2 } s )

[ Config SlottedAloha1 ]

description = “ slotted Aloha, overloaded ”

# slotTime = pkLen/txRate = 960/9600 = 0.1s

Aloha.slotTime = 100ms

# excessively frequent transmittals result in high hit rate and low channel use

Aloha.host [ * ] .iaTime = exponential ( 0.5s )

[ Config SlottedAloha2 ]

description = “ slotted Aloha, optimum burden ”

# slotTime = pkLen/txRate = 960/9600 = 0.1s

Aloha.slotTime = 100ms

# near optimum burden, channel use is close theoretical upper limit 1/e

Aloha.host [ * ] .iaTime = exponential ( 2s )

[ Config SlottedAloha3 ]

description = “ slotted Aloha, low traffic ”

# slotTime = pkLen/txRate = 960/9600 = 0.1s

Aloha.slotTime = 100ms

# really low traffic consequences in channel being idle most of the clip

Aloha.host [ * ] .iaTime = exponential ( 20s )

A choice of the SlottedAloha2 constellation overrides the value of slotTime with Aloha.host [ * ] .slotTime=100ms, which fixes the slotted ALOHA protocol with slot clip to 100ms. The Aloha.host [ * ] .iaTime=exponential ( 2s ) sets the frame inter-arrival clip on every host to follow exponential distribution, with average clip peers to 2 seconds.

The Config option PureAlohaExperiment exploits the OMNeT ‘s capablenesss of forming different experiments with simple repeat declarations. The statement Aloha.numHosts= $ { numHosts=10,15,20 } declares three ( 3 ) repeats holding 10, 1 and 20 hosts severally.

The statement Aloha.host [ * ] .iaTime=exponential ( $ { mean=1,2,3,4,5..9 measure 2 } s ) declares seven ( 7 ) repeats, with interarrival times equal to exponential distribution and means, 1, 2,3, 4, 5, 7 and 9, severally. The repeat=2 statement doubles the figure of tallies, so eventually the available picks will be 2x3x7=42 from 0 to 41 optional tallies. The statement sim-time-limit=90min constrains the simulation clip to 90 proceedingss.

C++ theoretical account coding

Fig. 11. The Aloha web theoretical account category diagram.

The simple faculties Host and Server are based on C++ scheduling. The relevant host.cc, host.h, server.cc and server.h, which are included wholly in the appendix subdivision, implement the theoretical account behaviour during simulation by interchanging messages straight one-another or with the simulation meat. The undermentioned Fig. 11 is a design- degree category diagram, depicting the basic relationships among web faculty Aloha and simple faculties, Host and Server. The two last, inherit from cSimpleModule simulation category library, and redefine the basic methods initialise ( ) , handleMessage ( ) , activity ( ) and finish ( ) , harmonizing to the desired map.

The Aloha web theoretical account comprises of several Host objects and one Server, so it keeps an collection association with Host and Server categories. It passes besides to them some parametric quantity values, some declared in the omnetpp.ini file and some taken from user duologue signifier. The Host faculty keeps an one-way association with Server because every Host declares a Server object in the attribute field, in order to direct a direct message ( pk ) subsequently, by naming the sendDirect ( ) map. The scheduleAt ( ) map plans the meats to direct the Host an “ endTxEvent ” message when the transmittal ends. This is represented by the self-association. Similarly, the Server faculty plans the meats to direct the Server an “ endRxEvent ” , when the response of the message sent from Host coatings, and is represented as the self-association.

The faculty codification is cited commented in the appendix. Here, I will explicate the coating ( ) map of the waiter faculty, because it creates the consequence studies, necessary for the development of the simulation.

null Waiter: :finish ( )

{

EV & lt ; & lt ; “ continuance: “ & lt ; & lt ; simTime ( ) & lt ; & lt ; endl ;

EV & lt ; & lt ; “ entire frames: “ & lt ; & lt ; totalFrames & lt ; & lt ; endl ;

EV & lt ; & lt ; “ collided frames: “ & lt ; & lt ; collidedFrames & lt ; & lt ; endl ;

EV & lt ; & lt ; “ entire receive clip: “ & lt ; & lt ; totalReceiveTime & lt ; & lt ; endl ;

EV & lt ; & lt ; “ entire hit clip: “ & lt ; & lt ; totalCollisionTime & lt ; & lt ; endl ;

EV & lt ; & lt ; “ channel use: “ & lt ; & lt ; currentChannelUtilization & lt ; & lt ; endl ;

recordScalar ( “ continuance ” , simTime ( ) ) ;

recordScalar ( “ entire frames ” , totalFrames ) ;

recordScalar ( “ collided frames ” , collidedFrames ) ;

recordScalar ( “ entire receive clip ” , totalReceiveTime ) ;

recordScalar ( “ entire hit clip ” , totalCollisionTime ) ;

recordScalar ( “ channel use ” , currentChannelUtilization ) ;

recordStatistic ( & A ; collisionMultiplicityHistogram, “ packages ” ) ;

recordStatistic ( & A ; collisionLengthHistogram, “ s ” ) ;

}

The coating ( ) map is called before the expiration of the simulation. The first six bids enable the printout of the category variables on the Tkenv window. It prints the concluding simulation clip, the sum transmitted frames, the collided frames on the waiter, the entire response clip of un-collided frames, the entire clip spent on hits, and the last value of channel use, which comes from the undermentioned expression:

It is expected that the Final Channel Utilization, after an equal simulation clip, that will make the maximal theoretical values if the entrance traffic is adjusted at an optimum value. The recordScalar ( ) map records these values to the relevant scalar file config_name.sca. Another note is that during initialize ( ) map there is codification to make vector logging, which is the undermentioned maps:

collisionMultiplicityVector.setName ( “ hit multiplicity ” ) ;

collisionMultiplicityVector.setType ( cOutVector: :TYPE_INT ) ;

collisionMultiplicityVector.setInterpolationMode ( cOutVector: :NONE ) ;

collisionLengthVector.setName ( “ hit length ” ) ;

collisionLengthVector.setUnit ( “ s ” ) ;

collisionLengthVector.setInterpolationMode ( cOutVector: :NONE ) ;

channelUtilizationVector.setName ( “ channel use ” ) ;

channelUtilizationVector.setType ( cOutVector: :TYPE_DOUBLE ) ;

channelUtilizationVector.setInterpolationMode ( cOutVector: :LINEAR ) ;

It creates three vectors, the current figure of hits, the current clip wasted by the hit and the current channel use, with the simulation timestamp. The undermentioned map creates two histogram maps, the figure of hits and the clip wasted by hits. The histogram is auto-ranging, holding declared merely the lower bound to be 0.0 by the setRangeAutoUpper ( ) map:

collisionMultiplicityHistogram.setName ( “ hit multiplicity ” ) ;

collisionMultiplicityHistogram.setRangeAutoUpper ( 0.0 ) ;

collisionLengthHistogram.setName ( “ hit length ” ) ;

collisionLengthHistogram.setRangeAutoUpper ( 0.0 ) ;

The data-logging codification lies in the handleMessage ( ) map, where:

collisionMultiplicityVector.record ( currentCollisionNumFrames ) ;

collisionMultiplicityHistogram.collect ( currentCollisionNumFrames ) ;

collisionLengthVector.record ( dt ) ;

collisionLengthHistogram.collect ( dt ) ;

channelUtilizationVector.record ( currentChannelUtilization ) ;

The record ( ) map appends a time-stamped value on the relevant vector and the collect ( ) map adds another value on the histogram graph. The recordStatistic ( ) map finalizes the two histogram graphs before expiration.

recordStatistic ( & A ; collisionMultiplicityHistogram, “ packages ” ) ;

recordStatistic ( & A ; collisionLengthHistogram, “ s ” ) ;

Simulation Consequences

Sequence Charts

To enable the event logging characteristic, the bid record-eventlog=true should be placed on the omnetpp.ini file. Then, on the terminal of the simulation, a config_name.elog file is created. To hold a clear presentation of the ALOHA protocol, I choose two options: A slotted ALOHA simulation, with exponential interarrival times holding 2 unsweet mean and pure ALOHA simulation, with exponential interarrival times holding 6 unsweet mean. A typical slotted ALOHA sequence is the followers:

On the # 2096 event, the host [ 4 ] receives a ego scheduled message “ endTxEvent ” from the meat, on the beginning of a new slot.

It generates the package “ pk-7- # 26 ” , get down to convey it to the waiter with the sendDirect ( ) bid and set the host ‘s state=TRANSMIT.

It schedules the terminal of transmittal message “ endTxEvent ” with a scheduleAt ( ) bid, after clip:

, where L is the frame length ( 960b ) and R is the channel capacity ( 9600bps ) .

On the # 2097 event, after the fake extension clip ( on the wireless channel ) , the waiter receives the package “ pk-7- # 26 ” from host [ 4 ] , set the channelBusy=true and schedules the terminal of response with a scheduleAt ( ) bid, after 100 simulated millisecond.

On the # 2098 event, the host [ 4 ] receives the ego scheduled “ endTxEvent ” message from the meat, set the host ‘s state=IDLE and agenda the following frame transmittal after random clip.

On the # 2101 event, the waiter receives the self-scheduled message “ endRxEvent ” , set the channelBusy=false and cipher the remainder of the category variables.

The events # 2100 and # 2099 happen about at the same time, therefore they collide on the waiter, get downing with event # 2102, so # 2103 and stoping the hit with event # 2106. The packages transmitted are supposed to be discarded by the waiter. The overlapping bluish parallelograms indicate the hit zone. The Fig. 12 depicts the above sequence:

Fig. 12. Slotted Aloha sequence chart.

Fig. 12. Pure Aloha sequence chart.

The pure ALOHA protocol is free of slot limitations and the host is able to convey whenever a package is available. Similarly as the old process on the event # 52, host [ 0 ] begins conveying and on the event # 53 the waiter starts having. However, on event # 54 the host [ 6 ] starts conveying and the waiter detects a hit on the event # 55. The hit ends on the event # 58 and both packages are discarded. It is obvious the waiter waste longer clip interval on the former hit, due to the non-synchronized status of the hosts. Pure ALOHA looks less efficient than slotted ALOHA. Afterwards, host [ 6 ] retransmits on event # 59 and the waiter responds on event # 60. The broadcast remain un-collided and ends usually on event # 62.

The pure ALOHA protocol

This subdivision is covering with the rating of the simulation theoretical account, its behaviour comparing the theoretical anticipations and some decisions that consequences from the extracted graphs. The most important parametric quantity to ALOHA simulation is the traffic seed. The entrance traffic is considered a Poisson procedure. The specifications of a Poisson procedure declare Poisson distribution for the figure of incoming packages and exponential distribution for the times between the packages ( interarrival times ) . It is assumed that the station ‘s beginning generates one package ( frame ) per message of changeless length ( 960b ) . So the theoretical account needs to imitate merely the interarrival times, utilizing the map exponential ( average ) . The mean is a dual preciseness figure stand foring the mean of the distribution, in seconds. The map returns a dual preciseness float, stand foring the random clip, in seconds.

For the pure ALOHA theoretical account: The user selects ab initio, via a duologue field, a low traffic profile ( mean=30 sec ) , so a heavy traffic profile ( mean=2 sec ) and eventually the optimum traffic profile ( mean=6 sec ) . It is expected that the optimum traffic profile induces a channel use ratio near the theoretical upper limit of 0.184. After the executing of the pure ALOHA simulation, utilizing the tree traffic profiles, the relevant vector and scalar files ( PureAloha*-0.vec and PureAloha*-0.sca ) appear in the aloha/results directory. The station processing of these files produces the PureAloha.anf analysis file, which is included. The simulation clip is 90 min for all theoretical accounts and the figure of host is 20.

The first group of histograms in Fig. 13 depicts the PDF of the hit multiplicity, for the three traffic distributions. It is obvious that the heavy traffic profile induces much more hits and therefore the chances to hold more than two or three coincident hits are higher. The figure of multiplicity extends up to 20 comparing to 9 in optimum traffic and 3 in low traffic. The scalar files give some accessional informations on every distribution, like lower limit, maximal and average values, standard divergence, etc.

Fig. 12. Pure Aloha hit multiplicity.

Fig. 13. Pure Aloha hit length.

The 2nd group of histograms in Fig. 13, depicts the PDF of the hit clip length distribution, for heavy, low and optimum traffic. As the generated traffic lessenings, higher hit times become less likely until they disappear, in low traffic profiles. The fundament clip length of two hits becomes dominant and lasts about 0.2 sec.

Fig. 14. Pure Aloha Channel Utilization for 20 hosts.

The above graph depicts the Aloha channel use, during the first 5400 fake seconds. It is obvious that the simulation stabilizes after the initial 500 sec. The ruddy line represents the optimum traffic profile and from the scalar variable appears to be 0.172, value near the theoretical upper limit. The bluish line is the heavy traffic profile, with 0.145. This proves that the pure ALOHA protocol can manage high traffic rather expeditiously. The green line is the low traffic profile with 0.057. This low factor proves that the random entree protocol becomes more efficient as the traffic additions. If we decrease the figure of host to 10, the channel use chart becomes less equivocal. The former high traffic profile ( mean=2 sec ) becomes now near the optimal, with utilization making 0.194, and the former optimal and low profiles become low. It is concluded that as the figure of host additions the optimum traffic should go less intense to maintain the use factor near its theoretical upper limit.

Fig. 14. Pure Aloha Channel Utilization for 10 hosts.

The slotted ALOHA protocol

Similarly, as in the former analysis, three traffic profiles are executed, the low traffic ( mean=20 sec ) , the heavy traffic ( mean=0.5 sec ) and the optimum ( mean=2 sec ) . The optimum traffic profile is expected to bring on a channel use ratio near the theoretical upper limit of 0.368. After the executing of slotted ALOHA simulation, utilizing the three traffic profiles, the relevant vector and scalar file ( SlottedAloha*-0.vec and SlottedALoha*-0.sca, where *=1,2,3 ) appear in the aloha/results directory. The station processing of these files produces the SlottedAloha.anf analysis file, which is included. The simulation clip is 90 min for all theoretical accounts and the figure of host is 20.

The first group of histograms in Fig. 15 depicts the PDF of the hit multiplicity, for the three traffic distributions. The heavy traffic profile induces more hits than the other profiles and the chief volume is more distributed between two ( less than 30 % ) and four coincident hits, giving lower chances comparing to pure ALOHA, where the chief volume lies between two ( more than 40 % ) and three. The remainder of the traffic profiles give similar consequences like pure ALOHA.

Fig. 15. Slotted Aloha hit multiplicity.

Fig. 16. Slotted Aloha hit length.

The undermentioned Fig. 17 depicts the channel use, during the first 5400 fake seconds. The slotted ALOHA protocol demand 1000 seconds to stabilise, twice the clip of pure ALOHA. The optimum traffic profile gives utilization ration 0.37, a value higher than the theoretical upper limit. Generally, simulation values above or below theoretical bounds originate issues about the truth of the simulation theoretical account or the truth of the simulation package. The utilization ratios for heavy and low traffic profiles are 0.126 and 0.089, severally.

Fig. 17. Slotted Aloha Channel Utilization for 20 hosts.

A simulation tally with 10 host and slotted ALOHA protocol produces the undermentioned graph, in Fig. 18. The decision is the same as in pure ALOHA graph of Fig. 14. The heavy traffic profile gives now utilization factor 0.34, close theoretical upper limit. The optimum traffic profile gives 0.3 and the low traffic profile gives 0.045, well lower than the simulation of 20 hosts.

I confirm that the slotted ALOHA protocol is twice efficient than the pure ALOHA. It is besides possible to gauge the optimum figure of hosts, given the generated traffic rate or to gauge the optimum generated traffic, given the figure of hosts. All appraisals can be verified through simulations, before deploying the existent web, although the ALOHA is at present obsolete. Engineers implement the same rule on up to day of the month systems, and bypasses complex computations.

Fig. 18. Slotted Aloha Channel Utilization for 10 hosts.

Decision

OMNeT++ is a really powerful tool, with a big figure of utile characteristics. It is based on NED, a graphical scheduling linguistic communication, to develop the simulation web, although the user can take between the graphical or the tantamount textual signifier. The true power of OMNeT ‘s prevarications on the usage of C++ , because the behaviour of simple and compound faculties are C++ objects. This induces an increased trouble degree, sing that OMNeT does non offer an extended protocol library as the known commercial opposite numbers. There are independent efforts to develop incorporate models, oriented to specific simulation classs, as the MiXiM for radio and detector webs, although the user would non avoid composing advanced C++ codification.

Commercial simulation applications, like Opnet or QualNet are offering the same characteristics, and supply a complete graphical scheduling environment to easy develop simulations. They offer a big figure of protocol libraries, which covers a wide scope of demands. This reduces well the development clip, although the purchase cost is about prohibitory for a individual applied scientist, without the fiscal support of a university, a company or a research installation. The alternate open-source solution ns-2 is every bit powerful, has a big user database, but it is considered more hard, as it lacks the incorporate graphical scheduling editor, and its scheduling linguistic communication OTcL is C++ based, as good.