Download BlueTooth Simulation - Networked Software Systems Laboratory

BlueTooth
Simulation
Project Final Report
2001
Part a
Technion
Haifa,Israel
Table Of Contents
BLUETOOTH SIMULATION ........................................................................... 1
Table Of Contents................................................................................................................................... 2
Introduction ............................................................................................................................................ 4
OUR WORK ........................................................................................................................................... 5
Bluetooth Problems ......................................................................................................................... 5
Bluetooth scheduling algorithm ...................................................................................................... 5
Steps in simulating a new scheduling algorithms ................................................................................ 6
Scheduling Algorithms which will be examined ................................................................................. 6
Bluetooth Technology ............................................................................................................................. 7
Introduction ....................................................................................................................................... 8
Bluetooth Network Structure .......................................................................................................... 8
BlueTooth Stack.............................................................................................................................. 9
Bluetooth connection creation states ............................................................................................. 10
Bluetooth unit possible addresses ................................................................................................. 11
Bluetooth connection states .......................................................................................................... 11
Radio AND Baseband LAYERS ..................................................................................................... 12
Frequency and time division ......................................................................................................... 12
Types Of Connection .................................................................................................................... 13
Structure of a sent Packet .............................................................................................................. 15
Higher Level Layers ........................................................................................................................ 17
LMP – Link Manager Protocol ..................................................................................................... 17
L2CAP - Logical Link Control and Adaptation Protocol. ........................................................... 17
RFCOMM - Cable Replacement protocol .................................................................................... 17
SDP - Servise Discovery Protocol ................................................................................................ 17
TCS-BIN Telephony Control protocol-binary .............................................................................. 17
AUDIO.......................................................................................................................................... 17
NS - Network Simulator ....................................................................................................................... 18
Introduction ....................................................................................................................................... 18
Simulator Components ...................................................................................................................... 19
Simulator Structure on Disk .............................................................................................................. 20
NS Overview ..................................................................................................................................... 21
TCL Programing ........................................................................................................................... 21
C++ Programing ........................................................................................................................... 21
NS Objects .................................................................................................................................... 22
Node ......................................................................................................................................... 23
Link .......................................................................................................................................... 23
Packet ....................................................................................................................................... 24
BlueHoc ................................................................................................................................................. 25
Introduction ....................................................................................................................................... 25
Bluetooth States Simulation............................................................................................................... 25
BlueHoc Packet Types ....................................................................................................................... 25
BlueHoc Packet Header ..................................................................................................................... 25
Baseband Simulation ......................................................................................................................... 26
Scheduler Simulation ......................................................................................................................... 26
L2CAP Simulation............................................................................................................................. 26
C++ classes in Bluehoc ...................................................................................................................... 26
Connection Establishment in BlueHoc .............................................................................................. 27
LMP signaling............................................................................................................................... 27
L2CAP Connection Establishment ............................................................................................... 27
2
APPENDIX I ......................................................................................................................................... 28
Packet types ....................................................................................................................................... 28
APPENDIX II ....................................................................................................................................... 29
NS Basics ........................................................................................................................................... 29
Script Explanations ....................................................................................................................... 30
Packet Flow of the Example ......................................................................................................... 32
NAM results of the Example ........................................................................................................ 32
APPENDIX III ...................................................................................................................................... 33
Hdr_bt ................................................................................................................................................ 33
Hdr_l2cap .......................................................................................................................................... 33
APPENDIX IV ...................................................................................................................................... 34
Structure of a Bluetooth node in Bluehoc .......................................................................................... 34
References ............................................................................................................................................. 35
Bluetooth Links ................................................................................................................................. 35
NS Links ............................................................................................................................................ 35
BlueHoc Links ................................................................................................................................... 35
3
Introduction
Project goal
Simulation of Bluetooth protocol on a software environment and solution proposals
for its scheduling problems.
Bluetooth Overview
Bluetooth is an emerging standard for low-power, low-cost pico-cellular wireless
systems for personal area network connection among mobile computers, mobile
phones and other devices. The Bluetooth wireless technology specification provides
secure, radio-based transmission of data and voice. It delivers opportunities for rapid,
ad hoc, automatic, wireless connections, even when devices are not within the line of
sight. The Bluetooth wireless technology uses a globally available frequency range to
ensure interoperability no matter where you travel.
Project Motivation
Although Bluetooth is a world wide standard and is developed by the most
influencing companies in the world there are still some uncovered problems in it, and
solving them is a necessity. One of these problems is the BT scheduling algorithm,
which can decrease the transfer rate from 1Mbps to a very low rate.
Choosing the Simulation Environment
After checking several options for network simulation programs
some of which:
-Writing our own simulator using some Technion software packages.
-Getting a commercial simulator.
-Ns - free, open source, academic package.
We chose Ns for its wide range of implemented protocols, its maintainability,
reliability, result simulation analysis with graphic tools, and its support center.
Ns Overview
NS is an open-sourced, object-oriented, event-driven simulator targeted at networking
research, written in C++ and OTcl. It provides wide support for simulation of wired
and wireless networks over variety of protocols.
BlueHoc Overview
BlueHoc simulator provides a Bluetooth extension for the Network Simulator (NS).
BlueHoc is IBM’s new Bluetooth open-sourced simulation.
Released on the 10.2.2001. It allows users to evaluate how Bluetooth performs under
various ad-hoc networking scenarios.
4
OUR WORK
Bluetooth Problems
Bluetooth is a world wide standard and is developed by the most influencing
companies in the world. However there are still some uncovered problems with its
specifications.
Some of these problems are:
 Bluetooth scatternets.
 Bluetooth routing protocols.
 Bluetooth scheduling algorithm.
We will shortly explain each of these problems.
Bluetooth scatternets problem
Although scatternets are defined by BT specifications, there are some uncovered
points which need to be specific handled.
A simple example is considering a master that is also a slave in another piconet.
In one hand it needs to control the piconet, but on the other hand it needs to send and
receive data from its master, this resolves a problem, because a master must be always
active, transmitting or receiving data in its own piconet.
Bluetooth routing protocols
When considering a big Bluetooth network scenario, when a unit desires to connect to
a unit that is in the network but not in the piconet, there needs to be a routing
algorithm to handle such kind of communication.
Bluetooth scheduling algorithm
Bluetooth is a Master driven TDD standard, which means it is up to the master to
decide the amount of traffic each slave will receive.
Today the only scheduling technique proposed is round robin, but there can easily be
found a scenario where slaves require bigger amount of traffic.
Every application that runs on Bluetooth, eventually gets to the physical layer and
uses Bluetooth scheduling algorithm. Therefor it is a necessity to examine this issue.
We chose to address the scheduling algorithm problem in Bluetooth.
A more detailed explanation of the problem
Once a master polls a slave, the next slot is reserved for that slave irrespective of
whether the slave has data to send or not. That is why when the scheduling is not
handled in an accurate way, the throughput can drop to less then 50%, then if it was
handled properly.
An example of the problem can be seen in figure 1.
5
Figure 1. ACL connection between master and slave-1 , slave-2 . slave-2 has no data
to address the master nevertheless both slave-1 and slave-2 receives the
same amount of traffic. The approximately throughput is 75% .
When you consider a bluetooth network with ACL, SCO links and all packets type
available (1,3,5 slots), you can understand that there is no mathematical basis to
analyze all the different possibilities.
That is why, when giving a new scheduling solution the only way to check it, is by a
simulator.
Steps in simulating a new scheduling algorithms

First it is necessary that Bluetooth will be implemented in NS.
For that we use BlueHoc. IBM's extension to NS, simulating some of Bluetooth
main concepts, but far from being a complete Bluetooth simulation.
 By adding and changing parts in BlueHoc we create a new scheduling proposal.
 To check that our simulation of Bluetooth is correct, we have to create a simple
scenario with a simple scheduling algorithm that has mathematical basics,
simulate it, and compare the results. (Checking our simulation correctness).
 Now that we know our simulation is correct, we can check various of schedule
algorithms.
Scheduling Algorithms which will be examined
Simple Round Robin – Has a known mathematical basics, and with a simple
scenario will able us to check the correctness of Bluetooth simulation in NS.
Exhaustive – A scheduler that completely empties the slave's and the
corresponding master's buffer, before switching to the next slave.
Gated - Similar to Exhaustive, the only difference is that Gated scheduling
empties the data that was in the buffer when switching to it, and not sending data
that got to the buffer after the switching.
Globally Gated – Same as Gated but in a predefined bigger period of time.
Priority Scheme & K-Fairness – two priority scheduling algorithms.
Other Scheduling algorithms – It is for sure that as we build this project, we will
find ones.
6
After further study of NS and BlueHoc we have implemented the following
scheduling algorithms:
 Round Robin.
 Exhaustive.
 Gated.
 Globally Gated.
See the implementation code in the added pages, additional documentation of the
scheduling algorithm and how they are implemented can also be seen in the code.
BlueHoc Capabilities:
There are some points to be noticed in the current BlueHoc implementation reflecting
our work:
1) The original scheduling algorithm of BlueHoc is a quota-giving
algorithm where each slave gets a quota by different characteristics.
Each quota was approximately enough for each slave to transmit three
5-slot packets each time.
2) Slaves can only transmit null packages, for now they do not transmit to
the master data.
3) There is no SCO implementation in BlueHoc. When referring to Voice,
it is Ns audio module transmitted over regular ACL link.
4) The size of the packet (1,3,5 slots) is determined at the beginning of
the simulation and cannot be changed during it.
5) Probability is not implemented in the connection creation process. It is
implemented in Telnet connection and can be manipulated for running
various simulation scenarios, Voice and FTP do not have probability
capabilities yet.
6) Scatterenet is not yet implemented in the current version of BlueHoc,
but it should be operational in the next version.
Next Semester Work:
1) Mathematical analysis of the simple algorithms we have already
implemented.
2) Implementation of more difficult and smart scheduling algorithm in a
Piconet.
3) Slave response data transmission implementation.
4) Different packet sizes, and SCO link configuration.
5) Check and create new scheduling algorithms for Scatternets.
7
Bluetooth Technology
Introduction
Bluetooth Network Structure
One can describe a Bluetooth basic network as a group of 2 – 8 units that is called a
PICONET. Each piconet has one unit defined as Master and all other units defined
as Slaves. Piconet is created when two Bluetooth devices are in transmission range
and start a connection between them, the unit which start the connection usually
becomes master. A master can send data to a slave, and slave can reply to the master,
but a slave can not send data directly to another slave.
Because bluetooth is a wireless technology, it has been decided that the time will be
slotted into slots, each slot 625usec long, in each slot there can be one bluetooth
packet sent and in each slot the transmission is in a different frequency. The Master
can send packets only in even slots, and a slave can reply only if the master addressed
him and only in the following slot, therefor slaves can only transmit in odd slots.
There is no hardware difference between the master unit and the slave unit, that is
every bluetooth unit can be master or slave.
A more complex bluetooth network is called a SCATTERNET.
Scatternet is built from several piconets, where each unit in one piconet can be a
member in another piconet, but the master unit can be a master of only one piconet.
As you can imagine, in a Scatternet things are more complex, a slave that is connected
to two piconets must know how to synchronize itself between the two piconet
masters, (this is a problem not yet fully defined by bluetooth SIG).
You can see types of connection structure possibilities in Figure 2.
Figure 2. single slave operation (a), multi-slave operation (b),
Scatternet operation (c).
During a connection slaves can decide to try and become masters themselves, they
can ask to quit the piconet, or to change their state into a park state for a known
amount of time, after which the master will wake them up. If you can imagine a big
scenario were units can move around, connect and disconnect, and change state to
different states, you can understand the difficulties analyzing such a protocol.
8
BlueTooth Stack
Figure 3. Bluetooth stack.
In order to understand Bluetooth one must see its global structure, that is, its stack.
(Shown in figure 3).
The layers of bluetooth can be split into two main parts:
Core layers that are used by every bluetooth application:
- Bluetooth Radio the actual RF transceiver.
- Baseband also called LC controls the physical layer.
- LMP controls the piconet link set-up and management.
- L2CAP controls data transfer to and from higher layers.
Higher layers that are used by specific applications:
- RFCOMM – simulates a serial port to enable TCP/IP, PPP, OBEX
connections.
- TCS BIN – telephone connection between bluetooth devices
- SDP – controls bluetooth application with other bluetooth devices.
- AUDIO – controls sound transfer.
- Other existing know protocols.(can be seen in Figure 3)
Some of the bluetooth layers are implemented in hardware and some in software.
Altogether the layers structure of bluetooth provide a very wide stack.
9
Figure 4. Different functional blocks in the Bluetooth system.
Bluetooth connection creation states
There are two main states where Bluetooth devices can be :
STAND-BY – Option of default for every bluetooth unit when it is not connected to
any piconet, in this state the use of power is very low.
CONNECTION – The state in which the connection is well defined.
A transformation from STAND-BY to CONNECTION is possible by
Inquiry process and page process.
Inquiry process – Enables the initiator unit to idetiffy other bluetooth units which are
in range of transmittion . At the end of the process the initiator unit
will receive the BD-ADDR and the clock of all units that
responded.
Page process – ussualy accures after the inquiry process ,but if the BD-ADDR is
known, page can accure without inquiry. At the end of the process the
initiator unit will become the master of the active piconet.
Figure 5. State diagram of Bluetooth link controller.
10
Bluetooth unit possible addresses
BD_ADDR – Bluetooth device address. A unique address, written in its hardware,
which makes each BT unit different. 48-bit long constructed from 3
fields LAP field 24-bit, NAP field 16-bit, UAP 8-bit.
AM_ADDR – Active Member Address. 3-bits long Assigned to each active slave in a
piconet . Also considered as the MAC address, where 0 is a
broadcast transmission.
PM_ADDR – Parked Member Address. 8-bit long address for slaves in PARK mode.
AR_ADDR – Access Request Address. 8-bit long address for slaves in PARK mode,
for active return to the piconet.
Bluetooth connection states
Active mode state –In this state the Unit is in an active piconet, it has AM_ADDR
given by the master.
Sniff mode state – Slaves are still connected to the piconet, but they transfer data
only during a sniff slot that occurs every Tsniff. Units get into
sniff mode by master demands.
Hold mode state – Defined only for ACL connection, the slave looses its
AM_ADDR and exit the piconet for a known amount of time.
Units get into hold mode by themselves or by master demands.
(SCO packets can be received in hold mode).
Park mode state – Defined for slaves that are not intersted in an active connection
but want to stay synchronide. The slave looses its AM_ADDR but
recives two new addresses PM_ADDR , AR_ADDR, used to
return from park state to active state. A smart use of this state can
increse the number of slaves in a piconet up to 255.
Figure 6. Ericson Bluetooth device.
Because the goal of this project is to find solutions for BlueTooth scheduling problem,
it is important to understand how bluetooth works mainly in the lower level layers,
where the scheduling of bluetooth is determined.
Therefor in the next few pages the radio and Baseband layers are explained in a more
detailed manner.
11
Radio AND Baseband LAYERS
Frequency and time division
Bluetooth operates at 2.4 GHz in the ISM band (Industrial-Scientific-Medical)
with a bandwidth of ~79 MHz ,and can transmit to a maximum range of 10m (can be
expended to 100m for some application).
The ISM band is not exclusive to bluetooth and in it also operating other instruments
which may interfere with the bluetooth connection , furthermore bluetooth units
themselves could interfere one another .Therefor the bluetooth technology uses a
hoping frequency technique, which is called channel hopping sequence .
The frequency in which a Bluetooth unit transmits changes 1600 times in a second,
creating a slotted channel . Each slot is 625usec long and in it one BT packet is sent.
There is a defined scheme how packets are sent called TDD scheme where the master
start transmitting only in even slots and slaves reply only in odd slots.
Figure 7. TDD and Timing.
Usually one slot time is enough to transmit a package but in some cases (when the
package is longer) the package is transmitted in 3 or 5 slots, as shown in figure 8.
Figure 8. packets sent over a slotted channel.
12
The channel hopping sequence is unique for each piconet, that is, each unit in the
same piconet has the same hopping sequence, this enables the units in the same
piconet to connect while not interfering with another piconet in the same place.
The channel hopping sequence of the piconet is determined by the master's
BD_ADDR (unique address for each BT device) and the master’s clock.
For units that is still not connected to a piconet there is unique hopping sequence
which is called inquiry & page hopping sequence, this sequence is known to all
Bluetooth units enabling them to connect in the state of inquiry and page without
being in a piconet.
Multiple frequency hoping decreases the chance of collision with other devices,
Furthermore error check algorithms neutralize minor errors, creating a stable reliable
network.
Figure 9. Ericson Baseband devies
Types Of Connection
Bluetooth hardware enables two types of connections:
ACL - Asynchronous Connection Less
Designated for data transfer. Takes place only in free slots (slots which are not
preserved for SCO).
Supports point-to-point and broadcast point-to-multi-point connections.
After the master transmits a packet the addressee slave may reply in the following
slot.
If the master transmits a broadcast, all the slaves receive the packet and in the
following slot non-of the slaves respond.
ACL's ARQ - In ACL connection error check algorithm are used, and if an error has
been detected the lost package is retransmitted (not necessarily in the following
master's slot).
Transmission rate of ACL connection is up to 723.2Kbps for one direction (57.6Kbps
for the other direction), or for a symmetric connection, up to 433.9Kbps for each side.
There can be only one ACL connection established by a master and one slave.
13
SCO - Synchronous Connection Oriented
Designated for voice transfer. The connection established by SCO is symmetric
and packets are sent only in reserved slots. When SCO connection is established, two
following time slots are reserved (in a constant time gap), the master transmits in the
first slot and the slave replies in the following one.
The time between two following slots is a parameter determined when the connection
is established and it is called Tsco which is counted in number of slots (can be 2, 4 or
6 slots). Tsco is affected by the error-fixing algorithm, the better error algorithm
chosen, there is a need to send another SCO packet faster, and therefore Tsco is
smaller. All that because it is crucial to maintain the voice rate transfer of SCO which
is 64Kpbs.
A master can handle up to three SCO connections in the same time, a slave can
establish up to three SCO connections with the same master or up to two SCO
connections with different masters.
In Figure 10 you can see a combination of SCO and ACL links.
Figure 10. SCO connection between the master and slave 1 , ACL connections with
slaves 2 , 3. The SCO connection Tsco is 6 slots, you can see that every 6
slots the master transmit a packet to slave 1.
14
Structure of a sent Packet
The information sent between two bluetooth units is called BT packet.
The packet is built out of 3 main fields as shown in figure 11.
Figure 11. standard packet format
In most packets all the 3 fields appear, but there are packets without payload, and
there are packets with only access code.
Explanation of the different fields is shown bellow.
The Access code
Has 3 types of use:
CAC – Channel Access code. Sent by units that are in a piconet connection,
determined by the master's LAP. If a unit in a piconet receives a packet that
does not have the CAC defined by the master, it means the packet is sent to a
different piconet and should not be accepted.
IAC – Inquiry Access Code. Used in Inquiry state, a state for a new connection with
other BT devices. There is a global code called GIAC which is known to all
bluetooth devices, enabling them to connect when don’t know anything about
each other.
DAC – Device Access Code. Designated for units that are in paging process, designed
to signal and identification .
The Header
Used by units connected to a piconet, it's fields are shown in figure 12.
Figure 12. Header Format
AM_ADDR - 3-bit long, marks the mac address of an active unit.
TYPE - Defines the type of the message that was sent. There are 15 packet types,
some of them data packets and some control packets. (See appendix 1)
Null packet - consists of the channel access code and packet header only. Used
for ARQN and flow. Does not require acknowledgment.
Poll Packet – similar to null packet but requires acknowledgment.
DH1/3/5 , DM1/3/5 – ACL data packets 1,3,5 slots with or without encoding.
HV1/3/5 – SCO voice packets 1,3,5 slots.
15
FHS Packet - The FHS packet is a special control packet revealing, among
Other things, the Bluetooth device address and the clock of the
sender. Used in the connection states page and inquiry and in
frequency hop synchronization.
FLOW - One bit designed to control data flow in ACL link, it determines when to
stop transmitting data if a buffer is full.
SEQN & ARQN - Used as ACK or NACK in ACL link.
HEC- Error checking field for the header.
The Payload
Can transfer data or voice, depends on the connection. Its size moves between
0 to 2745 bits. Has a header that can be 1 or 2 bytes long depends on it’s length.
Shown bellow in figure 13 .
Figure 13. One byte payload header.
The packet payload is determined by Higher levels LMP, L2CAP.
L_CH field determines to which level the packet is destinated, as shown in figure 14.
Figure 14. L_CH possibilities.
16
Higher Level Layers
LMP – Link Manager Protocol
LMP messages are used for link set-up, security and control. They are transferred
in the payload instead of L2CAP and are distinguished by a reserved
value in the L_CH field of the payload header (0x3).
The messages are filtered out and interpreted by LM on the receiving side and are not
propagated to higher layers.
Link Manager messages have higher priority than user data, this means that if
the Link Manager needs to send a message, it shall not be delayed by the
L2CAP traffic.
LMP packets are always sent as single-slot packets and the payload header is
therefore one byte.
LMP default packet is shown in figure 15
Figure 15. Payload body when LM PDUs are sent.
L2CAP - Logical Link Control and Adaptation Protocol.
This layer has 4 main tasks
Support multiple types of protocols in higher levels such as
RFCOMM,SDP end more .
Dividing and reconstructing of packets, enabling the data to be sent
trough the baseband layer.
Quality of service , enables using a quality of service parameter which
marks priority between deferent links.
Maping , enables maping of network groups.
RFCOMM - Cable Replacement protocol
Simulates Bluetooth as a line channel based on RS232 standard , enabling protocol
such as TCP/IP , PPP , OBEX to use Bluetooth.
SDP - Servise Discovery Protocol
Defines how a client application will behave when identifying a network application
in its environment.
TCS-BIN Telephony Control protocol-binary
Defines establishment and control of telephony call between Bluetooth units
AUDIO
Designated for voice transfer, doesn’t walk through L2CAP but goes directly
To the core layers
17
NS - Network Simulator
Introduction
NS is a software package that can simulate most of the network protocols exist today
and those that are in development.
NS implements network protocols such as TCP and UDP, traffic source behavior such
as FTP, Telnet, Web, CBR and VBR, queue management mechanism such as Drop
Tail and RED, routing algorithms such as Dijkstra, and more.
NS has a very powerful result analyzing tools, a Graphical User Interface
called NAM, which can show the simulation scenario, and a graph analyzer called
Xgraph, which can show the data on graphs.
NS had developed since 1989 and has evolved over the years by multiple scientists in
several universities and companies such as: UCB (Berkely), USC, LBNL and Xerox.
Today NS is a very powerful simulation tool, enable of simulating every network
protocol. It gives the ability to check, analyze and verify existing protocols and
coming-ahead ones.
NS was originally developed for Unix systems and by some manipulations
We succeeded making it work on Windows systems.
When you examine what are your demands from a network simulator you realize it
has two different kinds of things it needs to do:
On one hand, detailed simulations of protocols requires a systems programming
language which can efficiently manipulate bytes, packet headers, and implement
algorithms that run over large data sets. For these tasks run-time speed is important
and turn-around time (run simulation, find bug, fix bug, recompile, re-run) is less
important. On the other hand, a large part of network research involves slightly
varying parameters or configurations, or quickly exploring a number of scenarios. In
these cases, iteration time (change the model and re-run) is more important. Since
configuration runs once (at the beginning of the simulation), run-time of this part of
the task is less important.
That is why NS uses two language approach:
▪ Tcl - for scripting.
▪ C++ - for large complex and real-time work.
The aim is to enable the user to produce simple script files, within them
he can easily construct large scenarios, instead of making changes to the C++ files
every time he wants to produce a different scenario.
C++ and OTcl Duality
The C++ compiled objects are made available to the OTcl interpreter, through an
OTcl linkage that creates a matching OTcl object for each of the C++ objects, and
makes the control functions.In this way, the controls of the C++ objects are given to
OTcl. It is also possible to add member functions and variables to a C++ linked OTcl
18
object. The objects in C++ that do not need to be controlled in a simulation or
internally used by another object do not need to be linked to OTcl. Likewise, an
object can be entirely implemented in OTcl.
Figure 16. C++ and OTcl: The Duality
Figure 8 shows an object hierarchy example in C++ and OTcl. One thing to note in
the figure is that for C++ objects that have an OTcl linkage forming a hierarchy, there
is a matching OTcl object hierarchy very similar to that of C++.
Simulator Components
▪ Tcl - Tool Command Language, An interpreted scripting language, easy to learn
and easy to use, which enables the user to make scenarios quickly and easily.
▪ Otcl - Object Oriented extension for the Tcl language.
▪ Tclcl - C++ and Otcl Linkage, every object in C++ has an identical object in Otcl.
Tclcl makes the connection between them.
▪ NS - Network Simulator. This is the core of the simulator within it there are all the
C++ files and TCL files which build the simulator.
▪ NAM - Network Animator. Creates a graphical animation of the scenario from the
ns output, where you can actually see the stations (nodes), the links, and
the packets transfer from one point to another.
Enables to see the simulation in different speeds with a time speed slider
and has basic control options such as stop, rewind etc.
Figure 17 shows the NAM functionality.
19
Figure 17. NAM Functionality
Simulator Structure on Disk
After installing Ns it is a good idea to understand where you can find what,
Or more precisely what is really important for using NS.
The tcl8.3, tk8.3, Otcl, Tcl, NAM-1 are all stand alone programs that you only need to
compile once, there is no need to make any change in these programs.
The core of Ns is in NS-2, this is the directory in which changes are made.
Simulator
tcl8.3
tk8.3
OTcl
Tcl
NS-2
tcl
examples
cod
ex e test
validation
test
NAM-1
C++
tcl
.. code
lib.
..
Ns tcl
.
Objects
code
core
20
NS Overview
ns is an object oriented simulator, written in C++, with an OTcl interpreter as a
fronted, that takes as input a tcl file, which is a full simulation scenario written in tcl
language, understands it and produces an output file which is the input file for the
nam program or other analysis programs. (see Figure 18)
Figure 18. NS functionality
Ns provides two levels of programming
TCL Programming
Using existing implemented protocols for different scenario examinations.
C++ Programming
Developing a new protocol or changing existing ones.
TCL Programing
In order to create a simulation network, a user should write a Tcl script that describes
the simulation network topology by definitions of:
Nodes – network components such as end-point clients, routers, switches, etc.
Links – two-way,one-way etc.
Agents – tcp , udp ,cbr etc.
Applications – ftp, telnet etc.
The best way to understand how to build a tcl file is to look at a simple example,
which you can see in appendix 2.
C++ Programing
In order to create a new protocol or to change an existing protocol there is a need to
write / change the actual c++ code.
The Tcl files only determine the parameter settings of the simulation, but all the
objects which build it are implemented in C++.
When the Ns simulator runs, only compiled C++ code is running.
In C++ all the definitions of the network components are established,
Every component (class) has its member functions and variables
and the connection between the components , massage passing and traffic scheduling
is made in the C++ code level.
21
Our basic advice is to use OTcl:
for configuration, setup, and “one-time” stuff.
if you can do what you want by manipulating existing C++
objects.
and use C++:
if you have to change the behavior of an existing C++ class in ways
that weren’t anticipated.
NS Objects
This section talk about the NS components, mostly compound network components.
TclObject
NsObject
Connector
Queue
DropTail
Dela
y
RED
Agent
…
Classifier
…
AddrClassifier
McastClasifier
TCP
…
Ren
SAC
o
K
Figure 19. OTcl Class Hierarchy (Partial)
The root of the hierarchy is the TclObject class that is the superclass of all OTcl
library objects (scheduler, network components, timers and the other objects including
NAM related ones). As an ancestor class of TclObject, NsObject class is the
superclass of all basic network component objects that handle packets, which may
compose compound network objects such as nodes and links. The basic network
components are further divided into two subclasses, Connector and Classifier, based
on the number of the possible output data paths.
Connector - The basic network object that have only one output data path.
The objects which inherit from it are queues , links etc.
Shown in schemes as –
Connector
Classifier - A switching objects that have possible multiple output data paths.
Shown in schemes as –
22
Node
A node is a compound object composed of a node entry object , agents and classifiers
as shown in Figure20.
Figure 20. Node
A node has an address classifier that does the address routing and a port classifier that
demultiplex the packets to the correct agent.
Link
A link is another major compound object in NS. When a user creates a link using a
duplex-link member function of a Simulator object, two simplex links in both
directions are created as shown in Figure 21.
Figure 21. Link
The output queue of a node is actually implemented as a part of simplex link object.
Packets dequeued from a queue are passed to the Delay object that simulates the link
delay, and packets dropped at a queue (when the queue is full) are sent to a Null
Agent and are freed there. Finally, the TTL object calculates Time To Live
parameters for each packet received and updates the TTL field of the packet.
23
Packet
A NS packet is composed of a stack of headers, and an optional data space
(see Figure 22). The packet header format is initialized when a Simulator object is
created, where a stack of all registered (or possibly useable) headers, such as the
common header that is commonly used by any objects as needed, IP header, TCP
header, RTP header (UDP uses RTP header) and trace header, is defined, and the
offset of each header in the stack is recorded. What this means is that whether or not a
specific header is used, a stack composed of all registered headers is created when a
packet is allocated by an agent, and a network object can access any header in the
stack of a packet it processes using the corresponding offset value.
Figure 22. NS Packet Format
Usually, a packet only has the header stack (and a data space pointer that is null).
Although a packet can carry actual data (from an application) by allocating a data
space, the most common approach in NS is creating a new header for the application
and modifying the agent to write data received from the application to the new header.
24
BlueHoc
Introduction
BlueHoc simulator provides a Bluetooth extension for the Network Simulator – NS.
BlueHoc was developed in IBM research labs and released on the 10.2.2001.
BlueHoc supports the following specifications of the Bluetooth protocol:
Device Discovery performance of Bluetooth.
Connection Establishment and QoS negotiation.
Medium access control scheduling schemes.
Radio characteristics of Bluetooth system.
Statistical modeling of the indoor wireless channel.
Performance of TCP/IP based applications over Bluetooth.
The following Bluetooth layers have been simulated by Bluehoc:
Bluetooth radio.
Bluetooth baseband.
Link Manager Protocol (LMP).
Logical Link Control and Adapatation Protocol (L2CAP).
Simulates a Bluetooth piconet consisting of a master and 1-7 slaves.
Scatternet and mobility are not implemented yet.
BlueHoc is based on the open source simulator NS and uses the TCP/IP
simulations of NS to provide a complete simulation model for Bluetooth
performance evaluation.
Bluetooth States Simulation
In BlueHoc simulation , the states are simulated exactly in the way Bluetooth core
Describes them and they are:
ST = standby , I = inquiry , IS = inquiry scan , IR = inquiry response , P = page
PS = page scan , SR = slave response , MR = master response , C = connection
BlueHoc Packet Types
BlueHoc Supports the following Bluetooth packet types:
BT_NULL, BT_ID, BT_POLL, BT_FHS
BT_DM1, BT_DH1, BT_HV1, BT_AUX1, BT_HV2,
BT_DM3, BT_DH3, BT_HV3, BT_DV,
BT_DM5 = 0x0e, BT_DH5.
BlueHoc Packet Header
As described in the NS section, every packet that is unique for a specified protocol
Has a header in which the important data can tranfer.
In BlueHoc simulation there are two types of packet header:
hdr_bt , hdr_l2cap – more information can be found in Appendix 3.
25
Baseband Simulation
BlueHoc provides an accurate simulation of the basic features of Bluetooth baseband
like frequency hopping, device discovery and channel control.
Bluehoc supports the following specifications:
Frequency Hopping kernel with 79 frequency hops and Hop Selection for
Determining Tx/Rx frequency.
All Bluetooth states (INQUIRY, PAGE, etc…) procedures are implemented.
Slave and Master have different specifications (different classes).
All ACL packet types.
Stop and Wait ARQ.
Round Robin Scheduler.
Scheduler Simulation
Bluehoc simulates a Deficit Round Robin scheduling scheme.
Deficit Round Robin (in Bluetooth) – A scheduling scheme which enforces the
Master to poll to every slave on a specified slot (even slots only) and the next slot is
reserved for that slave (which the master referred to) irrespective of weather it has
data to sent or not.
The Scheduler in Bluehoc is centralized at the master unit.
L2CAP Simulation
Bluehoc supports the following specifications:
Signaling at L2CAP level for connection creation.
Multiple L2CAP connections over a single ACL connection.
Segmentation and Reassembly for higher layer packets.
C++ classes in Bluehoc
BlueHoc has added the following C++ classes to NS:
Baseband
Implements basic
baseband.cc
features of Bluetooth
baseband
BT_DRRScheduler
Deficit Round Robin bt-drr.cc
(DRR) based scheduler
LinkController
Stop and wait ARQ
bt-lc.cc
LBF
Leaky bucket filter
lbf.cc
LMP
Implements some LMP lmp.cc
commands
L2CAP
Basic L2CAP
l2cap.cc
functionality
BTHost
Bluetooth host which is bt-host.cc
layered over L2CAP
BTClassifier
Classifies packets
bt-classify.cc
based on active mode
address
26
The definitions for Bluetooth specific headers and classes are in "Ns-2/bt-def.h" and
"Ns-2/bt-core.h". Figure 27 in Appendix IV shows a master node with the targets of
the above objects. The black arrows show the target settings and thus the flow of
packets while blue arrows show callbacks, which give the upper layer a permit to send
a packet.
Connection Establishment in BlueHoc
Some connection establishment related signaling has been simulated in BlueHoc (see
Figure 2). A group of devices consisting of a single master and up to 7 active slaves is
called a Piconet. In BlueHoc only a single piconet is considered.
LMP signaling
Once paging is over and the slave is tuned to the master hopping sequence, Link
Manager Protocol establishes an Asynchronous Connection-Less (ACL) link between
the master and the slave. For this the master's LMP sends a
LMP_host_connection_req to the peer LMP. When the master's LMP receives a
response from the slave LMP it send an HCI Event to BTHost indicating that the
connection with the required device has (or has not) been created. The master then
sends a QoS setup command with the QoS parameters, which depend on the
application for which the connection is required. For simplicity it is assumed that
there is only one flow per ACL connection. The LMP passes on the QoS parameters
to the deficit round robin based scheduler which finds out whether the connection can
be accepted or not.
L2CAP Connection Establishment
After the QoS negotiation at the LMP is over, it sends
HCI_QoS_setup_complete_event to BThost. The host then sends
L2CA_Connect_Req to L2CAP. Signaling takes place between L2CAP peers. Each
L2CAP channel has a connection identifier (CID) associated with it.
For signaling the CID is 1.
The L2CAP side which initiates connection establishment (usually the master) sends
an L2CAP_connection_request and the other sides sends an
L2CAP_connection_response. Through this exchange each end can identify the other
end through its CID. Several L2CAP connections can be established in this manner
over a single ACL connection. However in this version of the simulator multiple
L2CAP connections over a single ACL connection are not considered since QoS
negotiation is done only once for per ACL connection at LMP level instead of
L2CAP. The L2CAP level QoS negotiation is yet to be implemented.
27
APPENDIX I
Packet types
Figure 23. Packets defined for SCO and ACL link types
28
APPENDIX II
NS Basics
Here We'll show a simple NS simulation script, explains what each line does
and show the animation results of NAM on this script.
#Create a simulator object
set ns [new Simulator]
#Open the NAM trace file
set out [open out.nam w]
$ns namtrace-all $out
#Define a 'finish' procedure
proc finish {} {
global ns out
$ns flush-trace
#Close the NAM trace file
close $out
#Execute NAM on the trace file
exec nam out.nam &
exit 0
}
#Create two nodes
set n0 [$ns node]
set n1 [$ns node]
#Create links between the nodes
$ns duplex-link $n0 $n1 10Mb 10ms DropTail
Now that the basic network setup is done, the next thing to do is to setup traffic
agents such as TCP and UDP, traffic sources such as FTP and CBR, and attach
them to nodes and agents respectively.
#Setup a TCP Agent
set tcp [new Agent/TCP]
$ns attach-agent $n0 $tcp
#Setup a TCPSink Agent
set sink [new Agent/TCPSink]
$ns attach-agent $n1 $sink
#Connect the TCP and TCPSink agents
$ns connect $tcp $sink
#Setup a FTP over TCP connection
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 1.0 "$ftp start"
$ns at 4.0 "$ftp stop"
#Call the finish procedure after 5 seconds of simulation time
$ns at 5.0 "finish"
#Run the simulation
$ns run
29
Script Explanations
Every network scenario script (Otcl script) starts with making a Simulator object
instance.
set ns [new Simulator]: generates an NS simulator object instance, and
assigns it to the variable ns.
This line does the following:
Initialize the packet format
Create a scheduler
Select the default address format
The "Simulator" object has member functions that do the following:
Create compound objects such as nodes and links.
Connect network component objects created.
Set network component parameters.
Create connections between agents.
Specify NAM display options.
Etc.
Most of member functions are for simulation setup (referred to as plumbing functions
in the Capabilities section) and scheduling, however some of them are for the NAM
display. The "Simulator" object member function implementations are located in the
"Ns-2/Tcl/lib/ns-lib.tcl" file.
$ns namtrace-all file-descriptor: This member function tells the simulator to
record simulation traces in NAM input format. It also gives the file name that
the trace will be written to later by the command $ns flush-trace.
proc finish {}: is called after this simulation is over by the command
$ns at 5.0 "finish". In this function, post-simulation processes are specified.
set n0 [$ns node]: The member function node creates a node. A node in NS is
compound object made of address and port classifiers (described in a later
section). Users can create a node by separately creating an address and a port
classifier objects and connecting them together. However, this member function
of Simulator object makes the job easier. To see how a node is created, look at
the files:
" Ns-2/Tcl/lib/ns-lib.tcl" and " Ns-2/Tcl/lib/ns-node.tcl".
$ns duplex-link node1 node2 bandwidth delay queue-type: creates two simplex
links of specified bandwidth and delay, and connects the two specified nodes. In NS,
the output queue of a node is implemented as a part of a link, therefore users should
specify the queue-type when creating links. In the above simulation script, DropTail
queue is used. If the reader wants to use a RED queue, simply replace the word
DropTail with RED. The NS implementation of a link is shown in a later section.
Like a node, a link is a compound object, and users can create its sub-objects and
connect them and the nodes. Link source codes can be found in
" Ns-2/Tcl/lib/ns-lib.tcl" and " Ns-2/Tcl/lib/ns-link.tcl" files.
set tcp [new Agent/TCP]: This line shows how to create a TCP agent.
30
But in general, users can create any agent or traffic sources in this way. Agents and
traffic sources are in fact basic objects (not compound objects), mostly implemented
in C++ and linked to OTcl. Therefore, there are no specific Simulator object member
functions that create these object instances. To create agents or traffic sources, a user
should know the class names these objects (Agent/TCP, Agent/TCPSink,
Application/FTP and so on). Agents source codes can be found in
"Ns-2/Tcl/lib/ns-default.tcl" file. This file contains the default configurable
parameter value settings for available network objects. Therefore, it works as a good
indicator of what kind of network objects are available in NS and what are the
configurable parameters.
$ns attach-agent node agent: The attach-agent member function
attaches an agent object created to a node object. Actually, what this function does is
call the attach member function of specified node, which attaches the given agent to
itself. Therefore, a user can do the same thing by, for example, $n0 attach $tcp.
Similarly, each agent object has a member function attach-agent that attaches a
traffic source object to itself.
$ns connect agent1 agent2: After two agents that will communicate
with each other are created, the next thing is to establish a logical network
connection between them. This line establishes a network connection by setting the
destination address to each others' network and port address pair.
$ns at time "string": This member function of a Simulator object makes
the
scheduler (scheduler_ is the variable that points the scheduler object created by [new
Scheduler] command at the beginning of the script) to schedule the execution of the
specified string at given simulation time. For example, $ns at 1.0 "$ftp start" will
make the scheduler call a start member function of the FTP traffic source object,
which starts the FTP to transmit data. In NS, usually a traffic source does not
transmit actual data, but it notifies the underlying agent that it has some amount of
data to transmit, and the agent, just knowing how much of the data to transfer,
creates packets and sends them.
After all network configuration, scheduling and post-simulation procedure
specifications are done, the only thing left is to run the simulation. This is
done by $ns run.
31
Packet Flow of the Example
Figure 24 shows the internals of the OTcl script example simulation (shown above).
The network consist of two nodes (n0 and n1) of which the network addresses are 0
and 1 respectively. A TCP agent attached to n0 using port 0 communicates with a
TCP sink object attached to n1 port 0. Finally, an FTP application (or traffic source) is
attached to the TCP agent, asking to send some amount of data.
Figure 24. Packet Flow Example
NAM results of the Example
Figure 25. NAM animation results
32
APPENDIX III
In BlueHoc simulation there are two types of packet header:
hdr_bt , hdr_l2cap:
Hdr_bt
uchar
Bt_packet_type
Uchar
Uchar
Uchar
Uchar
Payload
Uchar
Int
Int
Double
Double
Am_addr
type
flow
arqn
Seqn
Hec
Ph
Dir
RecvId_
SendId_
Xpos_
Ypos_
Uchar
Uchar
Uint
Uchar*
L_ch
flow
length
data
Hdr_l2cap
ushort
ushort
L2cmd
Length
cid
Cmd
33
uchar
uchar
uchar
code
identifier
length
APPENDIX IV
Structure of a Bluetooth node in Bluehoc
34
Figure 27: Structure of a Bluetooth node
References
Bluetooth Links



Bluetooth Special Interest Group: http://www.bluetooth.com
Bluetooth Official Web Site: http://www.bluetooth.net/
Bluetooth Specifications Book :
http://www.bluetooth.com/developer/specification/Bluetooth_1
1_Specifications_Book.pdf
NS Links
NS Home Page: http://www.isi.edu/nsnam/ns
NS Installation: http://www.isi.edu/nsnam/ns/ns-build.html
NS Documentation: http://www.isi.edu/nsnam/ns/nsdocumentation.html
NS Manual Page: http://www.isi.edu/nsnam/ns/ns-man.html
NS Class Hierarchy:
http://wwwsop.inria.fr/rodeo/personnel/Antoine.Clerget/ns
Tcl/Tk Quick Reference Guide:
http://www.slac.stanford.edu/~raines/tkref.html
OTcl Tutorial : http://bmrc.berkeley.edu/research/cmt/cmtdoc/otcl
Guide to awk: http://www.canberra.edu.au/~sam/whp/awkguide.html
XGraph: http://jean-luc.ncsa.uiuc.edu/Codes/xgraph
Network Animator (NAM): http://www.isi.edu/nsnam/nam/nam.html
BlueHoc Links

The BlueHoc Project Home Page:
http://oss.software.ibm.com/developerworks/opensource/bluehoc/
35