Wireless Communication Network Communication

Wireless Communication And Network Computing
CSIT Dept's SGBAU Amravati Page 1
Practical No: 1
Aim: Study of OMNeT ++ 5.1.1 simulator.
Tool: Omnet++ 5.1.1
Theory:
OMNeT++ is an object-oriented modular discrete event network simulation framework. It has a
generic architecture, so it can be (and has been) used in various problem domains:
 modeling of wired and wireless communication networks
 protocol modeling
 modeling of queueing networks
 modeling of multiprocessors and other distributed hardware systems
 validating of hardware architectures
 evaluating performance aspects of complex software systems
 in general, modeling and simulation of any system where the discrete event approach is
suitable, and can be conveniently mapped into entities communicating by exchanging
messages.
OMNeT++ itself is not a simulator of anything concrete, but rather provides infrastructure and
tools for writing simulations. One of the fundamental ingredients of this infrastructure is a
component architecture for simulation models. Models are assembled from reusable components
termed modules. Well-written modules are truly reusable, and can be combined in various ways
like LEGO blocks. Modules can be connected with each other via gates (other systems would
call them ports), and combined to form compound modules. The depth of module nesting is not
limited. Modules communicate through message passing, where messages may carry arbitrary
data structures. Modules can pass messages along predefined paths via gates and connections, or
directly to their destination; the latter is useful for wireless simulations, for example. Modules
may have parameters that can be used to customize module behavior and/or to parameterize the
model's topology. Modules at the lowest level of the module hierarchy are Wireless
Communication and Network Computing called simple modules, and they encapsulate model
behavior. Simple modules are programmed in C++, and make use of the simulation library.
OMNeT++ simulations can be run under various user interfaces. Graphical, animating user
interfaces are highly useful for demonstration and debugging purposes, and command-line user
interfaces are best for batch execution. The simulator as well as user interfaces and tools are
highly portable. They are tested on the most common operating systems (Linux, Mac OS/X,
Windows), and they can be compiled out of the box or after trivial modifications on most
Unixlike operating systems.
OMNeT++ also supports parallel distributed simulation. OMNeT++ can use several mechanisms
for communication between partitions of a parallel distributed simulation, for example MPI or
named pipes. The parallel simulation algorithm can easily be extended, or new ones can be
plugged in. Models do not need any special instrumentation to be run in parallel -- it is just a
matter of configuration.

OMNeT++ can even be used for classroom presentation of parallel simulation algorithms,
because simulations can be run in parallel even under the GUI that provides detailed feedback on
what is going on.
Modeling Concepts
An OMNeT++ model consists of modules that communicate with message passing. The active
modules are termed simple modules; they are written in C++, using the simulation class library.
Simple modules can be grouped into compound modules and so forth; the number of hierarchy
levels is unlimited. The whole model, called network in OMNeT++, is itself a compound
module. Messages can be sent either via connections that span modules or directly to other
modules. The concept of simple and compound modules is similar to DEVS atomic and coupled
models. In Fig. 2.1, boxes represent simple modules (gray background) and compound modules.
Arrows connecting small boxes represent connections and gates. Network Compound module
Simple modules
Figure : Simple and compound modules
Using OMNeT++
Building and Running Simulations This section provides insights into working with OMNeT++
in practice. Issues such as model files and compiling and running simulations are discussed. An
OMNeT++ model consists of the following parts:
• NED language topology description(s) (.ned files) that describe the module structure with
parameters, gates, etc. NED files can be written using any text editor, but the OMNeT++ IDE
provides excellent support for two-way graphical and text editing
• Message definitions (.msg files). You can define various message types and add data fields to
them. OMNeT++ will translate message definitions into full-fledged C++ classes.
• Simple module sources. They are C++ files, with .h/.cc suffix. The simulation system provides
the following components:
• Simulation kernel. This contains the code that manages the simulation and the simulation class
library. It is written in C++, compiled into a shared or static library.
• User interfaces. OMNeT++ user interfaces are used in simulation execution, to facilitate
debugging, demonstration, or batch execution of simulations. They are written in C++, compiled
into libraries. Simulation programs are built from the above components. First, .msg files

are translated into C++ code using the opp_msgc. program. Then all C++ sources are compiled
and linked with the simulation kernel and a user interface library to form a simulation executable
or shared library. NED files are loaded dynamically in their original text forms when the
simulation program starts.
Running the Simulation and Analyzing the Results
The simulation may be compiled as a standalone program executable; thus it can be run on other
machines without OMNeT++ being present, or it can be created as a shared library. In this case
the OMNeT++ shared libraries must be present on that system. When the program is started, it
first reads all NED files containing your model topology, then it reads a configuration file
(usually called omnetpp.ini). This file contains settings that control how the simulation is
executed, values for model parameters, etc. The configuration file can also prescribe several
simulation runs; in the simplest case, they will be executed by the simulation program one after
another. The output of the simulation is written into result files: output vector files, output scalar
files, and possibly the user’s own output files. OMNeT++ contains an Integrated Development
Environment (IDE) that provides rich environment for analyzing these files. Output files are
lineoriented text files which makes it possible to process them with a variety of tools and
programming languages as well, including Matlab, GNU R, Perl, Python, and spreadsheet
programs.
User Interfaces
The primary purpose of user interfaces is to make the internals of the model visible to the user, to
control simulation execution, and possibly allow the user to intervene by changing
variables/objects inside the model. This is very important in the development/debugging phase of
the simulation project. Equally important, a hands-on experience allows the user to get a feel of
the model’s behavior. The graphical user interface can also be used to demonstrate a model’s
operation. The same simulation model can be executed with various user interfaces, with no
change in the model files themselves. The user would typically test and debug the simulation
with a powerful graphical user interface, and finally run it with a simple, fast user interface that
supports batch execution.
Component Libraries
Module types can be stored in files separate from the place of their actual use, enabling the user
to group existing module types and create component libraries.
Files In Omnet
C++ (.cc and .h) files, containing simple module implementations and other code; Message
(.msg) files, containing message definitions to be translated into C++ classes; NED (.ned) files
with component declarations and topology descriptions; Configuration (.ini) files with model
parameter assignments and other settings. The process to turn the source into an executable form
is this, in nutshell:

Message files are translated into C++ using the message compiler, opp_ msgcC++ sources are
compiled into object form (.o files) Object files are linked with the simulation kernel and other
libraries to get an executable or a shared library note that apart from the first step, the process is
the same as building any C/C++ program. Also note that NED and ini files do not play a part in
this process, as they are loaded by the simulation program at runtime.
One needs to link with the following libraries:
The simulation kernel and class library (the oppsim library) and its dependencies (oppenvir,
oppcommon, oppnedxml, etc). Optionally, with one or more user interface libraries (opptkenv,
oppqtenv and oppcmdenv.) Note that these libraries themselves may depend on other libraries.
The exact files names of libraries depend on the platform and a number of additional factors
Universal Standalone Simulation Programs
A simulation executable can store several independent models that use the same set of simple
modules. The user can specify in the configuration file which model is to be run. This allows one
to build one large executable that contains several simulation models, and distribute it as a
standalone simulation tool. The flexibility of the topology description language also supports this
approach.
Conclusion : In this practical we have studied omnet++ 5.1.1 simulator.

Practical No: 2
Aim: To implement cloud simulation for number of Client Request on HTTP server in Omnet++
Tool: Omnet++ 5.1.1
Theory:
A web server is a computer system that processes requests via HTTP, the basic network
protocol used to distribute information on the World Wide Web. The term can refer to the entire
system, or specifically to the software that accepts and supervises the HTTP requests.[1]
The primary function of a web server is to store, process and deliver web pages to clients. The
communication between client and server takes place using the Hypertext Transfer Protocol
(HTTP). Pages delivered are most frequently HTML documents, which may
include images, style sheets and scripts in addition to text content.
Multiple web servers may be used for a high traffic website; here, Dell servers are installed
together being used for the Wikimedia Foundation.
A user agent, commonly a web browser or web crawler, initiates communication by making
a request for a specific resource using HTTP and the server responds with the content of that
resource or an error message if unable to do so. The resource is typically a real file on the
server's secondary storage, but this is not necessarily the case and depends on how the web
server is implemented.
While the primary function is to serve content, a full implementation of HTTP also includes
ways of receiving content from clients. This feature is used for submitting web forms,
including uploading of files.
Many generic web servers also support server-side scripting using Active Server
Pages (ASP), PHP, or other scripting languages. This means that the behaviour of the web server
can be scripted in separate files, while the actual server software remains unchanged. Usually,
this function is used to generate HTML documents dynamically ("on-the-fly") as opposed to
returning static documents. The former is primarily used for retrieving or modifying information
from databases. The latter is typically much faster and more easily cached but cannot
deliver dynamic content.
Web servers are not only used for serving the World Wide Web. They can also be
found embedded in devices such as printers, routers, webcams and serving only a local network.
The web server may then be used as a part of a system for monitoring or administering the
device in question. This usually means that no additional software has to be installed on the
client computer, since only a web browser is required (which now is included with
most operating systems).

#ifdef _MSC_VER
#pragma warning(disable:4786)
#endif
#include <fstream>
#include "HttpServer.h"
#include "HttpMsg_m.h"
Define_Module(HTTPServer);
void HTTPServer::initialize()
{
QueueBase::initialize();
}
simtime_t HTTPServer::startService(cMessage *msg)
{
EV << "Starting service of " << msg->getName() << endl;
return par("serviceTime").doubleValue();
}
void HTTPServer::endService(cMessage *msg)
{
EV << "Completed service of " << msg->getName() << endl;
HTTPMsg *httpMsg = check_and_cast<HTTPMsg *>(msg);
std::string reply = processHTTPCommand(httpMsg->getPayload());
httpMsg->setPayload(reply.c_str());
int clientAddr = httpMsg->getSrcAddress();
int srvAddr = httpMsg->getDestAddress();
httpMsg->setDestAddress(clientAddr);
httpMsg->setSrcAddress(srvAddr);
send(msg, "g$o");
}
std::string HTTPServer::processHTTPCommand(const char *httpReqHeader)
{
// parse header. first line should be: GET uri HTTP/1.1
std::string header(httpReqHeader);
std::string::size_type pos = header.find("rn");
if (pos == std::string::npos) {
EV << "Bad HTTP requestn";
return std::string("Bad request 400rn");

}
std::string cmd(header, 0, pos);
EV << "Received: " << cmd << "n";
// we only accept GET
if (cmd.length() < 4 || cmd.compare(0, 4, "GET ")) {
EV << "Wrong HTTP verb, only GET is supportedn";
return std::string("501 Not Implementedrn");
}
// parse URI and get corresponding content
pos = cmd.find(" ", 4);
std::string uri(cmd, 4, pos-4);
std::string content = getContentFor(uri.c_str());
// assemble reply
char len[16];
sprintf(len, "%d", (int)content.length());
std::string reply = std::string("HTTP/1.1 200 OKrn"
"Content-Type: text/htmlrn"
"Content-Length: ") + len + "rn"
"rn" +
content;
return reply;
}
std::string HTTPServer::getContentFor(const char *uri)
{
// try to find in cache
StringMap::iterator it = htdocs.find(uri);
if (it != htdocs.end())
return it->second;
// not in cache -- load and cache it
std::string fname = std::string("htdocs/")+(strcmp(uri, "/") == 0 ? "index.html" : uri);
#ifdef _MSC_VER
for (unsigned int i = 0; i < fname.length(); i++)
if (fname.at(i) == '/')
fname.at(i) = '';
#endif
std::ifstream file(fname.c_str(), std::ios::in|std::ios::binary|std::ios::ate);
if (file.fail()) {

std::string content = "<html><body><h3>404 Not found</h3></body></html>";
htdocs[uri] = content;
return content;
}
long size = file.tellg();
file.seekg(0, std::ios::beg);
char *buffer = new char[size];
file.read(buffer, size);
file.close();
std::string content(buffer, size);
delete[] buffer;
EV << "URI=" << uri << " ---> " << content << "n";
htdocs[uri] = content;
return content;
}
Output:
Figure : Http Server
Conclusion: In this way we have studied to implement cloud simulation for number of Client
Request on HTTP server in Omnet++

Practical No: 3
Aim: To simulate routing using Random Graph in Omnet++
Tools: Omnet ++ 5.1.1
Theory:
Random graph is the general term to refer to probability distributions over graphs. Random
graphs may be described simply by a probability distribution, or by a random process which
generates them. The theory of random graphs lies at the intersection between graph theory and
probability theory. From a mathematical perspective, random graphs are used to answer
questions about the properties of typical graphs. Its practical applications are found in all areas in
which complex networks need to be modeled – a large number of random graph models are thus
known, mirroring the diverse types of complex networks encountered in different areas. In a
mathematical context, random graph refers almost exclusively to the Erdős–Rényi random graph
model. In other contexts, any graph model may be referred to as a random graph.
Program:
package networks;
import node.Node;
network RandomGraph
{
parameters:
double n @prompt("Number of nodes") = default(15);
submodules:
node[n]: Node {
parameters:
address = index;
@display("p=100,100,ring");
gates:
port[n];
}
connections allowunconnected:
for i=0..n-2, for j=i+1..n-1 {
node[i].port[j] <--> { delay = 0.1ms; datarate = 1Gbps; } <--> node[j].port[i] if
uniform(0,1)<0.15;
}
}

Output:
Figure: Random Graph
Conclusion: In this way we have studied to simulate routing using Random Graph in Omnet++.

Practical No: 4
Aim: To simulate routing using hypercube topology in Omnet++
Tool: Omnet++ 5.1.1
Theory:
Hypercube networks are a type of network topology used to connect multiple processors with
memory modules and accurately route data. Hypercube networks consist of 2m
nodes. These
nodes form the vertices of squares to create an internetwork connection. A hypercube is basically
a multidimensional mesh network with two nodes in each dimension. Due to similarity, such
topologies are usually grouped into a k-ary d-dimensional mesh topology family where d
represents the number of dimensions and k represents the number of nodes in each dimension.
Code:
#include "HCRouter.h"
#include "HCPacket_m.h"
Define_Module(HCRouter);
#define SLOT_TIME 1.0
#define PROPDEL (0.99*SLOT_TIME)
void deflectionRouting(int my_address, int dim,
int *rte_dest, int num_rte, int *rte_port,
int *usr_dest, int num_usr, int *usr_port)
{
// This function implements a simple, fast, but very suboptimal, unfair,
// unbalanced etc. deflection scheme.
int i;
unsigned port_mask = (1<<dim)-1;
// used_ports: bits set to 1 will denote ports already assigned
unsigned used_ports = 0;
// assign transit cells to ports
for (i = 0; i < num_rte; i++) {
unsigned optimal = my_address ^ rte_dest[i];
unsigned usable = optimal & ~used_ports & port_mask;
if (usable) {
// route through first usable port (with smallest index)
int k;
for (k = 0; (usable & (1<<k)) == 0; k++);
rte_port[i] = k;
used_ports |= 1<<k;
}
else {
// deflect through first free port (with smallest index)
int k;

for (k = 0; used_ports &(1<<k); k++)
;
rte_port[i] = k;
used_ports |= 1<<k;
}
}
// assign user cells to remaining ports
for (i = 0; i < num_usr; i++) {
unsigned optimal = my_address ^ usr_dest[i];
unsigned usable = optimal & ~used_ports & port_mask;
if (usable) {
// route through first usable port (with smallest index)
int k;
for (k = 0; (usable & (1<<k)) == 0; k++)
;
usr_port[i] = k;
used_ports |= 1<<k;
}
else if (used_ports != port_mask) {
// deflect through first free port (with smallest index)
int k;
for (k = 0; used_ports &(1<<k); k++)
;
usr_port[i] = k;
used_ports |= 1<<k;
}
else {
// all ports used, cell will be discarded
usr_port[i] = -1;
}
}
}
void HCRouter::activity()
{
int my_address = par("address");
int dim = par("dim");
int fromUserGateId = gate("fromGen")->getId();
long total_usr = 0, discarded_usr = 0;
cMessage *endOfSlot = new cMessage("endOfSlot");
for ( ; ; ) {
int i;
// buffers for transit cells (rte) and for cells from local user (usr)
HCPacket *rte_cell[32];

int num_rte = 0;
HCPacket *usr_cell[32];
int num_usr = 0;
// collect cells; user cells go into separate buffer
scheduleAt(simTime()+SLOT_TIME, endOfSlot);
cMessage *msg;
while ((msg = receive()) != endOfSlot) {
HCPacket *pkt = check_and_cast<HCPacket *>(msg);
if (pkt->getArrivalGateId() != fromUserGateId) {
if (pkt->getDestAddress() != my_address)
rte_cell[num_rte++] = pkt;
else
send(pkt, "toSink");
}
else {
total_usr++;
if (num_usr < 32)
usr_cell[num_usr++] = pkt;
else {
discarded_usr++;
delete pkt;
}
}
}
// prepare arrays used in routing
int rte_dest[32], rte_port[32]; // destinations, output ports
int usr_dest[32], usr_port[32];
for (i = 0; i < num_rte; i++)
rte_dest[i] = rte_cell[i]->getDestAddress();
for (i = 0; i < num_usr; i++)
usr_dest[i] = usr_cell[i]->getDestAddress();
// make routing decision (function fills rte_port[] and usr_port[])
deflectionRouting(my_address, dim,
rte_dest, num_rte, rte_port,
usr_dest, num_usr, usr_port);
// send out transit cells
for (i = 0; i < num_rte; i++) {
rte_cell[i]->setHops(rte_cell[i]->getHops()+1);
sendDelayed(rte_cell[i], PROPDEL, "out", rte_port[i]);
}
// send out user cells
for (i = 0; i < num_usr; i++) {

if (usr_port[i] < 0) {
discarded_usr++;
delete usr_cell[i];
}
else {
usr_cell[i]->setHops(usr_cell[i]->getHops()+1);
sendDelayed(usr_cell[i], PROPDEL, "out", usr_port[i]);
}
}
EV << "rte[" << my_address << "]: Discarded " << discarded_usr << " out of " <<
total_usr << "n";
}
}
Output:
Figure : Hypercube Topology
Conclusion: In this practical we have studied to simulate routing using hypercube topology in
Omnet++

Practical No.5
Aim: To implement shortest path algorithm using AODV protocol in Omnet++
Tools: Omnet++ 5.1.1
Theory:
AODV is a process of reactive routing in which node has status of neighboring nodes in the form
of routing table. Routes are deleted from the routing tables which are not used from long time. If
a corresponding row is not used in recent times, it is deleted from the routing table. Information
of the predecessor nodes is maintained in the routing table, which is used for forwarding the
Route Reply packet to source node. Whenever any link was broken in the networks then the
predecessor node are alerted by RERR packets. In AODV routing, whenever a source node
generates route request and broadcasts route request (R_REQUEST) packets to its neighbors for
initiating route discovery process, neighboring node receives (R_REQUEST) packets and
rebroadcast to the neighbors and these steps are repeated until reaching of(R_REQUEST packet
to destination node.
Shortest path routing:
 Path-selection model
–Destination-based
–Minimum hop count or sum of link weights
–Dynamic vs. static link weights (i.e. load-insensitive routing)
Program: package inet.examples.aodv;
import inet.common.lifecycle.LifecycleController;
import inet.common.scenario.ScenarioManager;
import inet.networklayer.configurator.ipv4.IPv4NetworkConfigurator;
import inet.networklayer.ipv4.RoutingTableRecorder;
import inet.node.aodv.AODVRouter;
import inet.physicallayer.idealradio.IdealRadioMedium;
network SimpleRREQ
{
parameters:
@display("bgb=525,437");
submodules:
radioMedium: IdealRadioMedium {
parameters:
@display("p=50,50");
}
configurator: IPv4NetworkConfigurator {
parameters:
addDefaultRoutes = false;
addStaticRoutes = false;
addSubnetRoutes = false;

config = xml("<config><interface hosts='*' address='145.236.x.x'
netmask='255.255.0.0'/></config>");
@display("p=50,100");
}
routingTableRecorder: RoutingTableRecorder {
parameters:
@display("p=50,150");
}
lifecycleController: LifecycleController {
parameters:
@display("p=50,200");
}
scenarioManager: ScenarioManager {
parameters:
script = default(xml("<scenario/>"));
@display("p=50,250");
}
sender: AODVRouter {
parameters:
@display("i=device/pocketpc_s;r=,,#707070;p=270,51");
}
intermediateNode: AODVRouter {
parameters:
}
receiver: AODVRouter {
parameters:
}
}
network SimpleRREQ2
{
parameters:
submodules:
parameters:
}
parameters:

netmask='255.255.0.0'/></config>");
@display("p=50,100");
}
parameters:
@display("p=50,150");
}
parameters:
@display("p=50,200");
}
parameters:
@display("p=50,250");
}
parameters:
}
intermediateNodeA: AODVRouter {
parameters:
}
intermediateNodeB: AODVRouter {
parameters:
}
parameters:
}
}
network ShortestPath
{
parameters:
submodules:
parameters:
}

parameters:
netmask='255.255.0.0'/></config>");
@display("p=50,100");
}
parameters:
@display("p=50,150");
}
parameters:
@display("p=50,200");
}
parameters:
@display("p=50,250");
}
parameters:
}
intermediateNodeA: AODVRouter {
parameters:
}
intermediateNodeB: AODVRouter {
parameters:
}
intermediateNodeC: AODVRouter {
parameters:
}
parameters:
}
}

Design view:
Figure: design view of shortest path
Output:
Figure: Shortest path
Conclusion: In this way we have studied to implement shortest path algorithm using AODV
protocol in Omnet++.

Practical No: 6
Aim: Implement Rayleigh and Rician multipath fading channel blocks from the
Communications Block set
Tool: Matlab R2010
Theory:
Rayleigh and Rician fading channels are useful models of real-world phenomena in wireless
communications. These phenomena include multipath scattering effects, time dispersion, and
Doppler shifts that arise from relative motion between the transmitter and receiver.
Model and Parameters
The demo model simulates QPSK transmission over a multipath Rayleigh fading channel and
over a multipath Rician fading channel. You can control transmission and channel parameters via
workspace variables.
Rician Fading
The Rician fading block models line-of-sight propagation in addition to diffuse multipath
scattering. This results in a smaller variation in the magnitude of the channel gain. To see this
effect, we'll run a new simulation with the Rican fading channel visualization enabled. Note that
the magnitude fluctuates over approximately a 10 dB range (compared with 30-40 dB for the
Rayleigh fading channel). This variation would be further reduced by increasing the K-factor
(currently set to 10).
Code:
modelname = 'commmultipathfading';
open_system(modelname);
The following variables control the "Bit Source" block. By default, the bit rate is 500 kb/s (250
ksym/s) and each transmitted frame is 200 bits long (100 symbols).
bitRate % Transmission rate (b/s)
bitsPerFrame % Number of bits per transmitted frame
bitRate = 500000
bitsPerFrame = 200

The following variables control both the Rayleigh and Rician fading blocks. By default, the
channel is modeled as four fading paths, each representing a cluster of multipath components
received at around the same delay.
maxDopplerShift % Maximum Doppler shift of diffuse components (Hz)
delayVector % Discrete delays of four-path channel (s)
gainVector % Average path gains (dB)
maxDopplerShift =
200
delayVector = 1.0e-004 *
0 0.0400 0.0800 0.1200
gainVector = 0 -3 -6 -9
Output :
Figure. Multipath Rayleigh and Rician Channels

Figure. Band limited impulse response
Figure. Multipath
Conclusion: We have studied Implement Rayleigh and Rician multipath fading channel blocks
from the Communication Blockset

Practical No: 7
Aim: Acoustic Noise Cancellation using the Least Mean Square (LMS) algorithm to subtract
noise from an input signal
Tool: Matlab R2010
Theory:
The LMS adaptive filter uses the reference signal and the desired signal, to automatically match
the filter response. As it converges to the correct filter model, the filtered noise is subtracted and
the error signal should contain only the original signal.
The desired signal is composed of colored noise and an audio signal from a .wav file. The first
input signal to the adaptive filter is white noise. This demo uses the adaptive filter to remove the
noise from the signal output. When you run this demo, you hear both noise and a person playing
the drums. Over time, the adaptive filter in the model filters out the noise so you only hear the
drums.
Code:
if ~ispc
dsp_error('windowsOnly', ...
'This demo is supported only on Windows(R) platforms.');
end
Create a random number generator stream for the randn function which acts as noise source.
s = RandStream.create('mt19937ar','seed',23341);
Create an FIR digital filter System object which you will use to filter our random numbers to
create colored noise.
hfilt = signalblks.DigitalFilter('TransferFunction', 'FIR (all zeros)', ...
'Numerator', fir1(39, .25));
Create a System object to read from a multimedia file.
hsigsource = signalblks.MultimediaFileReader(which('dspafxf_8000.wav'), ...
'SamplesPerAudioFrame', 40, ...
'PlayCount', Inf, ...
'AudioOutputDataType', 'double');
Create and configure an LMS adaptive filter System object.
hlms = signalblks.LMSFilter(40,'Method', 'Normalized LMS', ...
'StepSize', .01);

To play the audio signal create an audio player System object with a sample rate of 8000Hz.
haudioout = signalblks.AudioPlayer('SampleRate', 8000);
Set up a waterfall plot that displays 5 traces of the 40 filter coefficients.
hplot = plotancdata('SIGNALBLKSANC: Acoustic Noise Cancellation', 5, 40);
Stream Processing Loop
In the processing loop, the LMS adaptive filter updates its coefficients to model the digital filter,
which enables you to remove the colored noise from the signal. The demo plays the audio signal
three times.
numplays = 0;
while numplays < 3
[y, eof] = step(hsigsource); % Read from audio file
noise = randn(s,40,1); % Produce random data
noisefilt = step(hfilt, noise); % Filter the random data
desired = noisefilt + y; % Construct LMS 'desired' input
[out, err, w] = step(hlms, noise, desired); % Run the LMS filter
step(haudioout, double(err)); % Play the output signal
hplot(w); % Plot the weights
numplays = numplays + eof; % Update number of plays
end
Output :
Figure. Filter Coefficients
Conclusion: We have studied Acoustic Noise Cancellation using the Least Mean Square (LMS)
algorithm to subtract noise from an input signal

Practical No: 8
Aim: Getting Started with Spectral Analysis Objects
Tool: MATLAB R2010
Theory:
The Signal Processing Toolbox(TM) provides several command line functions to perform
spectral analysis, including classical (non-parametric) techniques, parametric techniques, and
eigenvector (or subspace) techniques. In addition, objects have been added which enhance the
Usabilit, and visualization capabilities to these functions. There are nine classes representing the
following spectral analysis algorithms.
Periodogram
Welch
MTM (Thomson multitaper method)
Burg
Covariance
Modified Covariance
Yule-Walker
MUSIC (Multiple Signal Classification)
Eigenvector
Program:
h = spectrum.periodogram
h = spectrum.welch('kaiser',66,50)
h.WindowName = 'Chebyshev'
h = spectrum.welch({'Chebyshev',80})
h = spectrum.welch;
hopts = psdopts(h)
Fs = 1000; t = 0:1/Fs:.3;
randn('state',0);
x = cos(2*pi*t*200)+randn(size(t));
h = spectrum.periodogram('rectangular');
hopts = psdopts(h,x);
set(hopts,'Fs',Fs,'SpectrumType','twosided','CenterDC',true);
psd(h,x,hopts)
set(hopts,'NFFT',2^14);
hpsd = psd(h,x,hopts)
avgpower(hpsd)
set(hopts,'SpectrumType','onesided');

psd(h,x,hopts)
hpsd = psd(h,x,hopts);
avgpower(hpsd)
randn('state',0);
Fs = 32e3; t = 0:1/Fs:2.96;
x = cos(2*pi*t*10e3)+cos(2*pi*t*1.24e3)+cos(2*pi*t*1.26e3)...
+ randn(size(t));
nfft = (length(x)+1)/2;
f = (Fs/2)/nfft*(0:nfft-1);
h = spectrum.periodogram('rectangular');
hopts = psdopts(h,x); set(hopts,'Fs',Fs,'SpectrumType','twosided');
hopts.FreqPoints = 'User Defined';
hopts.FrequencyVector = f(f>1.2e3 & f<1.3e3);
msspectrum(h,x,hopts)
Fs = 1000; t = 0:1/Fs:.296;
p = 0.95;
h = spectrum.welch;
hpsd = psd(h,x,'Fs',Fs,'ConfLevel',p)
plot(hpsd)
Fs = 1000; t = 0:1/Fs:.296;
h = spectrum.welch('hamming',64);
hpsd1 = psd(h,x,'Fs',Fs);
Pxx1 = hpsd1.Data;
W = hpsd1.Frequencies;
h.WindowName = 'Kaiser';
Pxx2 = hpsd2.Data;
h.WindowName = 'Chebyshev';
Pxx3 = hpsd3.Data;
hpsd = dspdata.psd([Pxx1, Pxx2, Pxx3],W,'Fs',Fs)
plot(hpsd);
legend('Hamming','kaiser','Chebyshev');

Output :
Figure : Spectral Analysis
Conclusion: In this way, we have created Spectral Analysis

Practical No: 9
Aim: Write a Program to Perform GSM Digital Down Converter
Tool: Matlab R2010
Theory:
The Digital Down Converter (DDC) is an important component of a digital radio. It performs
frequency translation to convert the high input sample rate down to a lower sample rate for
efficient processing. In this demo the DDC accepts a bandpass signal with a sample rate around
70 megasamples per seconds (MSPS) and performs the following operations:
 Digital mixing or down conversion of the input signal using a Numerically Controlled
Oscillator (NCO) and a mixer.
 Narrowband low-pass filtering and decimation using a filter chain of Cascaded
Integrator-Comb (CIC) and FIR filters.
 Gain adjustment and final resampling of the data stream.
Code:
Create and configure a sine wave source System object to model the GSM source. You set the
object's frequency to 69.1e6*5/24 MSPS because, after digital mixing, the object will have a
baseband frequency of around 48 KSPS. Because the system you are modeling resamples the
input by a factor of 4/(3*256), you need to set the object's frame size to be the least common
multiplier of these factors.
Fs = 69.333e6; FrameSize = 768;
hsine = signalblks.SineWave( ...
'Frequency', 69.1e6*5/24, ...
'SampleTime', 1/Fs, ...
'Method', 'Trigonometric function', ...
'SamplesPerFrame', FrameSize);
hnco = signalblks.NCO( ...
'PhaseIncrementSource', 'Property', ...
'PhaseIncrement', int32((5/24) *2^32), ...
'PhaseOffset', int16(0), ...
'NumDitherBits', 14, ...
'NumQuantizerAccumulatorBits', 18, ...
'Waveform', 'Complex exponential', ...
'SamplesPerFrame', FrameSize, ...
'CustomAccumulatorDataType', numerictype([],32), ...
'CustomOutputDataType', numerictype([],20,18));
hcicdec = signalblks.CICDecimator( ...
'DecimationFactor', 64, ...
'NumSections', 5, ...

'FixedPointDataType', 'Minimum section word lengths', ...
'OutputWordLength', 20);
gsmcoeffs; % Read the CFIR and PFIR coeffs
hcfir = signalblks.FIRDecimator(2, cfir, ...
'CustomCoefficientsDataType', numerictype([],16), ...
'CustomOutputDataType', numerictype([],20,-12));
hpfir = signalblks.FIRDecimator(2, pfir, ...
hfirsrc = signalblks.FIRRateConverter(4, 3, fir1(31,0.25),...
gsmsig = fi(zeros(768,1),true,14,13);
mixsig = fi(zeros(768,1),true,20,18);
s = hfigsddc(Fs,FrameSize,64*2,256*3/4,100);
Configure figures for plotting.
for ii = 1:100
gsmsig(:) = step(hsine); % GSM signal
ncosig = step(hnco); % NCO signal
mixsig(:) = gsmsig.*ncosig; % Digital mixer
% CIC filtering and compensation
ycic = step(hcfir, step(hcicdec, mixsig));
% Programmable FIR and sample-rate conversion
yrcout = step(hfirsrc, step(hpfir, ycic));
% Frequency and time-domain plots
s = plotddcdata(s, ncosig, ycic, yrcout);end

Output
Figure. Sample Rate Converter
Figure. Mean-Square Spectrum Periodogram Estimat

Figure. Periodogram Mean-Square Spectrum Estimate
Conclusion: We have studied GSM Digital Down Converter

Practical No: 10
Aim: Analysis of Phase Shift Keying Simulation.
Tool: Matlab R2010
Theory:
Phase Shift Keying (PSK) is the digital modulation technique in which the phase of the carrier
signal is changed by varying the sine and cosine inputs at a particular time. PSK technique is
widely used for wireless LANs, bio-metric, contactless operations, along with RFID and
Bluetooth communications.
PSK is of two types, depending upon the phases the signal gets shifted. They are −
(1).Binary Phase Shift Keying (BPSK)
This is also called as 2-phase PSK or Phase Reversal Keying. In this technique, the sine wave
carrier takes two phase reversals such as 0° and 180°.
BPSK is basically a Double Side Band Suppressed Carrier (DSBSC) modulation scheme, for
message being the digital information.
(2).Quadrature Phase Shift Keying (QPSK)
This is the phase shift keying technique, in which the sine wave carrier takes four phase
reversals such as 0°, 90°, 180°, and 270°.
If this kind of techniques are further extended, PSK can be done by eight or sixteen values also,
depending upon the requirement.
Code:
nSamp = 8; numSymb = 100;
M = 4; SNR = 14;
hStr = RandStream('mt19937ar', 'Seed', 12345);
numPlot = 10;
msg_orig = randi(hStr, [0 M-1], numSymb, 1);
stem(0:numPlot-1, msg_orig(1:numPlot), 'bx');
xlabel('Time'); ylabel('Amplitude');
msg_rx = awgn(msg_tx, SNR, 'measured', hStr, 'dB');
h2 = scatterplot(msg_rx);
hDemod = modem.pskdemod('M', M, 'PhaseOffset', pi/4, 'SymbolOrder', 'Gray');
close(h1(ishghandle(h1)), h2(ishghandle(h2)));
msg_rx_down = intdump(msg_rx,nSamp);
msg_demod = demodulate(hDemod, msg_rx_down);
stem(0:numPlot-1, msg_orig(1:numPlot), 'bx'); hold on;
stem(0:numPlot-1, msg_demod(1:numPlot), 'ro'); hold off;

axis([ 0 numPlot -0.2 3.2]); xlabel('Time'); ylabel('Amplitude');
[errorBit ratioBit] = biterr(msg_orig, msg_demod, log2(M));
[errorSym ratioSym] = symerr(msg_orig, msg_demod);
Output :
Figure: Performance of Baseband
Conclusion: We have studied and analysis of Phase Shift Keying Simulation.

Practical No: 11
Aim: Introduction to MIMO Systems (Transmit Diversity vs. Receive Diversity).
Tool: MATLAB R2010
Theory:
Multiple-Input-Multiple-Output (MIMO) systems, which use multiple antennas at the
transmitter and receiver ends of a wireless communication system. MIMO systems are
increasingly being adopted in communication systems for the potential gains in capacity they
realize when using multiple antennas. Multiple antennas use the spatial dimension in addition to
the time and frequency ones, without changing the bandwidth requirements of the system.
For a generic communications link, this demo focuses on transmit diversity in lieu
of traditional receive diversity. Using the flat-fading Rayleigh channel, it illustrates the concept
of Orthogonal Space-Time Block Coding, which is employable when multiple transmitter
antennas are used. It is assumed here that the channel undergoes independent fading between the
multiple transmit-receive antenna pairs. For a chosen system, it also provides a measure of the
performance degradation when the channel is imperfectly estimated at the receiver, compared to
the case of perfect channel knowledge at the receiver.
 Transmit Diversity vs. Receive Diversity
 Space-Time Block Coding with Channel Estimation
 Orthogonal Space-Time Block Coding and Further Explorations.
Transmit Diversity vs. Receive Diversity
Using diversity reception is a well-known technique to mitigate the effects of fading over a
communications link. However, it has mostly been relegated to the receiver end. In [1], Alamouti
proposes a transmit diversity scheme that offers similar diversity gains, using multiple antennas
at the transmitter. This was conceived to be more practical as, for example, it would only require
multiple antennas at the base station in comparison to multiple antennas for every mobile in
a cellular communications system. This section highlights this comparison of transmit vs. receive
diversity by simulating coherent binary phase-shift keying (BPSK) modulation over flat-fading
Rayleigh channels. For transmit diversity, we use two transmit antennas and one receive antenna
(2x1 notationally), while for receive diversity we employ one transmit antenna and two receive
antennas (1x2 notationally). The simulation covers an end-to-end system showing the encoded
and/or transmitted signal, channel model, and reception and demodulation of the received
signal. It also provides the no-diversity link (single transmit- receive antenna case).

Code:
frmLen = 100; % frame length
numPackets = 1000; % number of packets
EbNo = 0:2:20; % Eb/No varying to 20 dB
N = 2; % maximum number of Tx antennas
M = 2; % maximum number of Rx antennas
and set up the simulation.
% Create a local random stream to be used by random number generators for
% repeatability.
hStr = RandStream('mt19937ar', 'Seed', 55408);
% Create BPSK mod-demod objects
P = 2; % modulation order
bpskmod = modem.pskmod('M', P, 'SymbolOrder', 'Gray');
bpskdemod = modem.pskdemod(bpskmod);
% Pre-allocate variables for speed
tx2 = zeros(frmLen, N); H = zeros(frmLen, N, M);
r21 = zeros(frmLen, 1); r12 = zeros(frmLen, 2);
z21 = zeros(frmLen, 1); z21_1 = zeros(frmLen/N, 1); z21_2 = z21_1;
z12 = zeros(frmLen, M);
error11 = zeros(1, numPackets); BER11 = zeros(1, length(EbNo));
error21 = error11; BER21 = BER11; error12 = error11; BER12 = BER11;
BERthy2 = BER11;
% Set up a figure for visualizing BER results
h = gcf; grid on; hold on;
set(gca, 'yscale', 'log', 'xlim', [EbNo(1), EbNo(end)], 'ylim', [1e-4 1]);
xlabel('Eb/No (dB)'); ylabel('BER'); set(h,'NumberTitle','off');
set(h, 'renderer', 'zbuffer'); set(h,'Name','Transmit vs. Receive Diversity');
title('Transmit vs. Receive Diversity');
% Loop over several EbNo points
foridx = 1:length(EbNo)
% Loop over the number of packets
forpacketIdx = 1:numPackets
data = randi(hStr, [0 P-1], frmLen, 1); % data vector per user
% per channel
tx = modulate(bpskmod, data); % BPSK modulation
% Alamouti Space-Time Block Encoder, G2, full rate
% G2 = [s1 s2; -s2* s1*]
s1 = tx(1:N:end); s2 = tx(2:N:end);
tx2(1:N:end, :) = [s1 s2];
tx2(2:N:end, :) = [-conj(s2) conj(s1)];
% Create the Rayleigh distributed channel response matrix
% for two transmit and two receive antennas
H(1:N:end, :, :) = (randn(hStr, frmLen/2, N, M) + ...
1i*randn(hStr, frmLen/2, N, M))/sqrt(2);
% assume held constant for 2 symbol periods

H(2:N:end, :, :) = H(1:N:end, :, :);
% Received signals
% for uncoded 1x1 system
r11 = awgn(H(:, 1, 1).*tx, EbNo(idx), 0, hStr);
% for G2-coded 2x1 system - with normalized Tx power, i.e., the
% total transmitted power is assumed constant
r21 = awgn(sum(H(:, :, 1).*tx2, 2)/sqrt(N), EbNo(idx), 0, hStr);
% for Maximal-ratio combined 1x2 system
for i = 1:M
r12(:, i) = awgn(H(:, 1, i).*tx, EbNo(idx), 0, hStr);
end
% Front-end Combiners - assume channel response known at Rx
% for G2-coded 2x1 system
hidx = 1:N:length(H);
z21_1 = r21(1:N:end).* conj(H(hidx, 1, 1)) + ...
conj(r21(2:N:end)).* H(hidx, 2, 1);
z21_2 = r21(1:N:end).* conj(H(hidx, 2, 1)) - ...
conj(r21(2:N:end)).* H(hidx, 1, 1);
z21(1:N:end) = z21_1; z21(2:N:end) = z21_2;
for i = 1:M
z12(:, i) = r12(:, i).* conj(H(:, 1, i));
end
% ML Detector (minimum Euclidean distance)
demod11 = demodulate(bpskdemod, r11.*conj(H(:, 1, 1)));
demod21 = demodulate(bpskdemod, z21);
demod12 = demodulate(bpskdemod, sum(z12, 2));
% Determine errors
error11(packetIdx) = biterr(demod11, data);
end % end of FOR loop for numPackets
% Calculate BER for current idx
% for uncoded 1x1 system
BER11(idx) = sum(error11)/(numPackets*frmLen);
% for G2 coded 2x1 system
% for theoretical performance of second-order diversity
BERthy2(idx) = berfading(EbNo(idx), 'psk', 2, 2);
% Plot results
semilogy(EbNo(1:idx), BER11(1:idx), 'r*', ...
EbNo(1:idx), BER21(1:idx), 'go', ...
EbNo(1:idx), BER12(1:idx), 'bs', ...
EbNo(1:idx), BERthy2(1:idx), 'm');

legend('No Diversity (1Tx, 1Rx)', 'Alamouti (2Tx, 1Rx)',...
'Maximal-Ratio Combining (1Tx, 2Rx)', ...
'Theoretical 2nd-Order Diversity');
drawnow;
end % end of for loop for EbNo
% Perform curve fitting and replot the results
fitBER11 = berfit(EbNo, BER11);
semilogy(EbNo, fitBER11, 'r', EbNo, fitBER21, 'g', EbNo, fitBER12, 'b');
hold off;
Output :
Figure. Transmit vs. Receive Diversity
Conclusion: We have studied MIMO Systems (Transmit Diversity vs. Receive Diversity).

Practical No: 12
Aim: Introduction to MIMO Systems ( Space-Time Block Coding with Channel Estimation).
Tool: Matlab R2010
Theory:
Space-Time Block Coding with Channel Estimation
Building on the theory of orthogonal designs, Tarokh et al. [2] generalized
Alamouti's transmit diversity scheme to an arbitrary number of transmitter
antennas, leading to the concept of Space-Time Block Codes. For complex signal
constellations, they showed that Alamouti's scheme is the only full-rate scheme for
two transmit antennas.
In this section, we study the performance of such a scheme with two receive
antennas (i.e., a 2x2 system) with and without channel estimation. In the realistic
scenario where the channel state information is not known at the receiver, this has
to be extracted from the received signal. We assume that the channel estimator
performs this using orthogonal pilot signals that are prepended to every packet [3].
It is assumed that the channel remains unchanged for the length of the packet (i.e.,
it undergoes slow fading).
A simulation similar to the one described in the previous section is employed here,
which leads us to estimate the BER performance for a space-time block coded
system using two transmit and two receive antennas.
Code:
frmLen = 100; % frame length
maxNumErrs = 300; % maximum number of errors
maxNumPackets = 3000; % maximum number of packets
EbNo = 0:2:12; % Eb/No varying to 12 dB
N = 2; % number of Tx antennas
M = 2; % number of Rx antennas
pLen = 8; % number of pilot symbols per frame
W = hadamard(pLen);
pilots = W(:, 1:N); % orthogonal set per transmit antenna
and set up the simulation.
% Reset the local stream
reset(hStr)
% Pre-allocate variables for speed
tx2 = zeros(frmLen, N); r = zeros(pLen + frmLen, M);
H = zeros(pLen + frmLen, N, M); H_e = zeros(frmLen, N, M);
z_e = zeros(frmLen, M); z1_e = zeros(frmLen/N, M); z2_e = z1_e;
z = z_e; z1 = z1_e; z2 = z2_e;
BER22_e = zeros(1, length(EbNo)); BER22 = BER22_e;
% Set up a figure for visualizing BER results

clf(h); grid on; hold on;
set(gca,'yscale','log','xlim',[EbNo(1), EbNo(end)],'ylim',[1e-4 1]);
xlabel('Eb/No (dB)'); ylabel('BER'); set(h,'NumberTitle','off');
set(h,'Name','Orthogonal Space-Time Block Coding');
set(h, 'renderer', 'zbuffer'); title('G2-coded 2x2 System');
% Loop over several EbNo points
foridx = 1:length(EbNo)
numPackets = 0; totNumErr22 = 0; totNumErr22_e = 0;
% Loop till the number of errors exceed 'maxNumErrs'
% or the maximum number of packets have been simulated
while (totNumErr22 <maxNumErrs) && (totNumErr22_e <maxNumErrs) &&
...
(numPackets<maxNumPackets)
data = randi(hStr, [0 P-1], frmLen, 1); % data vector per user
% per channel
tx = modulate(bpskmod, data); % BPSK modulation
% Alamouti Space-Time Block Encoder, G2, full rate
% G2 = [s1 s2; -s2* s1*]
s1 = tx(1:N:end); s2 = tx(2:N:end);
tx2(1:N:end, :) = [s1 s2];
tx2(2:N:end, :) = [-conj(s2) conj(s1)];128
% Prepend pilot symbols for each frame
transmit = [pilots; tx2];
% Create the Rayleigh distributed channel response matrix
H(1, :, :) = (randn(hStr, N, M) + 1i*randn(hStr, N, M))/sqrt(2);
% assume held constant for the whole frame and pilot symbols
H = H(ones(pLen + frmLen, 1), :, :);
% Received signal for each Rx antenna
% with pilot symbols transmitted
for i = 1:M
% with normalized Tx power
r(:, i) = awgn(sum(H(:, :, i).*transmit, 2)/sqrt(N), ...
EbNo(idx), 0, hStr);
end
% Channel Estimation
% For each link => N*M estimates
for n = 1:N
H_e(1, n, :) = (r(1:pLen, :).' * pilots(:, n))./pLen;
end
% assume held constant for the whole frame
H_e = H_e(ones(frmLen, 1), :, :);
% Combiner using estimated channel
heidx = 1:N:length(H_e);
for i = 1:M
z1_e(:, i) = r(pLen+1:N:end, i).* conj(H_e(heidx, 1, i)) + ...
conj(r(pLen+2:N:end, i)).* H_e(heidx, 2, i);

z2_e(:, i) = r(pLen+1:N:end, i).* conj(H_e(heidx, 2, i)) - ...
conj(r(pLen+2:N:end, i)).* H_e(heidx, 1, i);
end
z_e(1:N:end, :) = z1_e; z_e(2:N:end, :) = z2_e;
% Combiner using known channel
hidx = pLen+1:N:length(H);
for i = 1:M
z1(:, i) = r(pLen+1:N:end, i).* conj(H(hidx, 1, i)) + ...
conj(r(pLen+2:N:end, i)).* H(hidx, 2, i);
z2(:, i) = r(pLen+1:N:end, i).* conj(H(hidx, 2, i)) - ...
conj(r(pLen+2:N:end, i)).* H(hidx, 1, i);
end
z(1:N:end, :) = z1; z(2:N:end, :) = z2;
% ML Detector (minimum Euclidean distance)
demod22_e = demodulate(bpskdemod, sum(z_e, 2)); % estimated
demod22 = demodulate(bpskdemod, sum(z, 2)); % known
% Determine errors
numPackets = numPackets + 1;
totNumErr22_e = totNumErr22_e + biterr(demod22_e, data);
totNumErr22 = totNumErr22 + biterr(demod22, data);
end % end of FOR loop for numPackets
% Calculate BER for current idx
% for estimated channel
BER22_e(idx) = totNumErr22_e/(numPackets*frmLen);
% for known channel
BER22(idx) = totNumErr22/(numPackets*frmLen);
% Plot results
semilogy(EbNo(1:idx), BER22_e(1:idx), 'ro');
semilogy(EbNo(1:idx), BER22(1:idx), 'g*');
legend(['Channel estimated with ' num2str(pLen) ' pilot symbols/frame'],...
'Known channel');
drawnow;
end % end of for loop for EbNo
% Perform curve fitting and replot the results
fitBER22_e = berfit(EbNo, BER22_e);
semilogy(EbNo, fitBER22_e, 'r', EbNo, fitBER22, 'g'); hold off;

Output :
Figure. Space-Time Block Coding with Channel Estimation
Conclusion: We have studied MIMO Systems ( Space-Time Block Coding with Channel
Estimation).

Practical No: 13
Aim: Study of Network Simulator GNS3 1.3.13
Theory:
GNS3 is a Graphical Network Simulator that allows emulation of complex networks. You may
be familiar with VMWare or Virtual PC that are used to emulate various operating systems in a
virtual environment. These programs allow you to run operating systems such as Windows XP
Professional or Ubuntu Linux in a virtual environment on your computer. GNS3 allows the same
type of emulation using Cisco Internetwork Operating Systems. It allows you to run a Cisco IOS
in a virtual environment on your computer. GNS3 is a graphical front end to a product called
Dynagen. Dynamips is the core program that allows IOS emulation. Dynagen runs on top of
Dynamips to create a more user friendly, text-based environment. A user may create network
topologies using simple Windows ini-type files with Dynagen running on top of Dynamips.
GNS3 takes this a step further by providing a graphical environment.
GNS3 allows the emulation of Cisco IOSs on your Windows or Linux based computer.
Emulation is possible for a long list of router platforms and PIX firewalls. Using an EtherSwitch
card in a router, switching platforms may also be emulated to the degree of the card’s supported
functionality. This means that GNS3 is an invaluable tool for preparing for Cisco certifications
such as CCNA and CCNP. There are a number of router simulators on the market, but they are
limited to the commands that the developer chooses to include. Almost always there are
commands or parameters that are not supported when working on a practice lab. In these
simulators you are only seeing a representation of the output of a simulated router. The accuracy
of that representation is only as good as the developer makes it. With GNS3 you are running an
actual Cisco IOS, so you will see exactly what the IOS produces and will have access to any
command or parameter supported by the IOS. In addition, GNS3 is an open source, free program
for you to use. However, due to licensing restrictions, you will have to provide your own Cisco
IOSs to use with GNS3. Also, GNS3 will provide around 1,000 packets per second throughput in
a virtual environment. A normal router will provide a hundred to a thousand times greater
throughput. GNS3 does not take the place of a real router, but is meant to be a tool for learning
and testing in a lab environment. Using GNS3 in any other way would be considered improper
The GNS3 workspace is the area of GNS3 where you create topologies by adding devices and
links
The devices toolbar allows you to add devices to your network topology. You do this by
dragging devices from the Toolbar to the GNS3 workspace (explained below).

The devices toolbar is grouped into different types by default:
Routers
A router[a]
is a networking device that forwards data packets between computer
networks. Routers perform the traffic directing functions on the Internet.
Switches
A device that channels income data from any of multiple input ports to the specific
output port that will take the data towards its intended destination.
End Devices
Is an internet-capable computer hardware device on a TCP/IP network
Security Devices
To provide security between to devices or network
All Devices
It contains Switches, Router, Ethernet hub , Ethernet switch ,Frame Realy Switch,
Host, VPCS
Add a link
It is connection between two host or Routers

Creating the Simplest Topology
The right-most pane will provide a topology summary that will be better understood when we
built more complex topologies. For now, just know that the pane exists.
The middle section contains two panes. The top pane is your work area where a topology may be
graphically built. The bottom pane, called the Console, shows Dynagen at work. Dynagen, as
you recall, is the text-based front end to Dynamips, the core emulator being used. Learning how
to use Dynagen is like learning how to use DOS the first time, so we will not get into that here.
However, we will use a very few simple but useful commands in the Dynagen pane.
Click on a router icon under Nodes Types corresponding to the IOS platform you are using. In
our example, we are using a 7200 platform. You must use a platform for which you defined an
IOS. Drag an appropriate router node type over to the workplace pane in the middle and let go.
We now have a router ready to configure.
Connect topology :
Click the Add a Link button to start adding links to your topology. The mouse cursor will
change to indicate that links can be added. Click on PC1 in your topology to display available
interfaces. In this example Ethernet0 is available. Click Ethernet0 on PC1 and then select PC2.
GNS3 indicates that the devices have been powered on by turning the interface connectors from
red to green.
A console connection is opened to every device in the topology
Figure : Console window
Conclusion: We have studied Study of Network Simulator GNS3 1.3.13

Practical No: 14
Aim: Basic setup of two routers and communication setup between these routers.
Tool: GNS3 1.3.13
Theory:
GNS3 was designed to take some of the complexity out of emulating Cisco IOS environments
(among others). The other tools that are available (dynamips/dynagen) are still used by GNS3,
but are just configured and operated in the background.
connect two 7206 routers together with a single serial link. The first step to set this up is to drag
the two 7200s from the nodes types pane to the map pane.
Steps to connect to routers:
Step 1: Select the 7200 Series Router, Drag the First Router to the Map pane
Step 2: Select the 7206 Series Router Again, Drag the Second Router to the Map pane
Now that the two routers have been placed on the map pane, the two need to be connected
together with a serial link. The Add a Link tool is in the top navigation bar and resembles a cable
connector, once it is clicked the different types of link available are shown for selection. In this
case a serial link is going to be used to connect the two devices.
Step 3: Add a Link Tool - Selecting Serial Link Type
Once you have disabled the Add a Link tool, the lab and the two devices is complete. These
following parts cover the steps required to configure the IDLE PC value; the IDLE PC value is
important as it enables GNS3/dynamips to more efficiently use the host processor. Without it, the
process utilization of the host machine will often be at 100%. To begin, a single device needs to
be started and allowed to completely boot up. The process of starting R1 and displaying the
console. Watch the console until the device has been completely booted up and no additional
messages are being displayed.
The process of calculating the IDLE PC only needs to be done once for each router model type,
once it is calculated it will automatically be added to the configuration of all other similar
models. Hopefully the content of this article enables the reader to set up a simple lab and become
familiar with the process of using GNS3 and will help in future studies.

Figure : Connection between two routers
Output:
Figure : Console window for two router connection
Conclusion: We have studied basic setup of two routers and communication setup between these
routers.

Practical No: 15
Aim: To connect GNS3 to real network.
Tool: GNS3 1.3.13
Theory:
The idea of connecting a virtual network deviceIn the case of is possibleand easy to implement.
Steps to connect GNS3 to real network.
Step 1 : Select 3600 Series Router, Drag the router to the map, with Ethernet or FastEthernet
interface.
Step 2: drag and drop the cloud icon in our network map.
We right click on the cloud and select configure From the tab NIO Ethernet we select the option
that represents the real network interface in our workstation and we press the button Add.Then
press ok button to close the cloud configuration window.
Now, let’s connect our virtual router to the cloud that represents our real network. Click on the
Add Link button and we select the option Manual.The cursor becomes cross mark.
We can watch the booting procedure in the console by right clicking on the router icon and
selecting the consoleoption fromthe popup menu.
Now, if everything have been done fine, we should have a successful ping to our real network or
any real network device (workstations, servers, etc.)This was a simple example of how toconnect
a GNS3 virtual network to the real network

.
Fig. Real Network Scenario
Output:
Figure : Console window for router to network connection
Conclusion: We have studied how to connect GNS3 to real network.

Practical No: 16
Aim: To perform Static Routing configuration in GNS3 tool.
Tool: GNS3 1.3.13
Theory:
Static routing is the most secure way of routing. It reduces overhead from network resources. In
this type of routing we manually add routes in routing table. It is useful where numbers of route
are limited. Like other routing methods static routing also has its pros and cons.
connect two 3600 routers together with a single serial link. The first step to set this up is to drag
the two 7200s from the nodes types pane to the map pane.
Steps to connect to routers:
Step 1: Select the 3725 Series Router, Drag the First Router to the Map pane
Step 2: Select the 7200 Series Router Again, Drag the Second Router to the Map pane
Now that the two routers have been placed on the map pane, the two need to be connected
together with a serial link. The Add a Link tool is in the top navigation bar and resembles a cable
connector, once it is clicked the different types of link available are shown for selection. In this
case a serial link is going to be used to connect the two devices.
Step 3: Select the Switch, Drag the Switch to the Map pane
Step 4: Select the Switch Again, Drag the Second Switch to the Map pane
Step 3: Select two host, Drag to the Map pane
Now connect router to host through the switch in ethernet connection. Configure all routers and
switch and host. Then finally to see output console the routers.

Figure : Static Routing configuration
Output:
Figure : console window for Static Routing configuration
Conclusion: We have studied Static Routing configuration in GNS3 tool

Practical No: 17
Aim: To study the OPNET simulator tool.
Theory:
OPNET is very large and powerful software with wide variety of Possibilities Enables the
possibility to simulate entire heterogeneous networks with various protocols. Development work
was started in 1986 by MIL3 Inc. (nowadays OPNET Technologies Inc.)Originally the software
was developed for the needs of military, but it has grown to be a world leading commercial
network simulation tool OPNET is quite expensive for commercial usage but there are also free
licenses for educational purposes.
OPNET is a high level event based network level simulation tool Simulation operates at
“packet-level”. Originally built for the simulation of fixed networks OPNET contains a huge
library of accurate models of commercially available fixed network hardware and protocols.
Nowadays, the possibilities for wireless network simulations are also very wide Accurate radio
transmission pipeline stage for the modelling of the physical layer (radio interface) .The
simulator has a lot of potentiality, but there exists typically a lack of the recent wireless systems
Much of the work considering new technologies must be done by oneself OPNET can be used as
a research tool or as a network design/analysis tool (end user) The threshold for the usage is high
for the developer, but low for the end user.
The structure of OPNET:
OPNET consists of high level user interface, which is constructed from C and C++
source code blocks with a huge library of OPNET specific functions.
Hierarchical structure modelling is divided to three main domains:
• Network domain
• Networks + sub-networks, network topologies, geographical coordinates, mobility
• Node domain
• Single network nodes (e.g., routers, workstations, mobile devices…)
• Process domain
• Single modules and source code inside network nodes (e.g., data traffic source model)
• With OPNET it is also possible to run external code components (External System Domain,
ESD)

The Various Tools of OPNET:
• Source code editing environment
• Network model editor
• Node model editor
• Process model editor
• Antenna pattern editor
• Modulation curve editor (SNR – BER behavior)
• Packet format editor
• Analysis configuration tool
• Simulation tool
• ICI editor (Interface Control Information)
• Probe model tool (organization of result collection)
• Link model editor (properties of fixed link models)
• Path model editor (for routing and modeling virtual circuits)
• Demand model editor (wide scale application modeling)
• OPNET Animation viewer

Figure : Opnet Network Simulator

Key Features:
 Fastest discrete event simulation engine among leading industry solutions
 Hundreds of protocol and vendor device models with source code (complete OPNET
Model Library)
 Object-oriented modelling
 Hierarchical modelling environment
 Discrete Event, Hybrid, and optional Analytical simulation
 32-bit and 64-bit fully parallel simulation kernel
 Grid computing support for distributed simulation
 Optional System-in-the-Loop to interface simulations with live systems
 Realistic Application Modelling and Analysis
 Open interface for integrating external object files, libraries, and other simulators
 Integrated, GUI-based debugging and analysis
Conclusion: OPNET is event based (discrete time) network simulation tool. The software is
powerful but also demanding at least for the developers. Different layers and functionalities can
practically be modelled as accurately as needed with external model access (EMA) and external
system domain (ESD) functionalities. OPNET includes various additional modules and tools for
easing the usage of the software.

Wireless Communication Network Communication

More Related Content

Similar to Wireless Communication Network Communication

More from Vrushali Lanjewar

Recently uploaded

Wireless Communication Network Communication