Bluetooth Connection Establishment Process Project Mid Semester Report

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 16

Bluetooth

Connection
Establishment
Process
Project Mid
Semester Report
1 Project Goals

• Study the environment of Opnet and its functionality


and capabilities.
• Study the bluetooth principles.
• Build the simulation environment.
• Prove credibility of the simulation.
• Check suggested algorithms.

2
2 Background

2.1 General description of the Bluetooth


system
Bluetooth is a short-range radio link intended to replace the cable(s) connecting
portable and/or fixed electronic devices. Key features are robustness, low complexity,
low power, and low cost.

Bluetooth operates in the unlicensed ISM band at 2.4 GHz. A frequency hop
transceiver is applied to combat interference and fading. A shaped, binary FM
modulation is applied to minimize transceiver complexity. The symbol rate is 1 Ms/s.
A slotted channel is applied with a nominal slot length of 625 s . For full duplex
transmission, a Time-Division Duplex (TDD) scheme is used. On the channel,
information is exchanged through packets. Each packet is transmitted on a different
hop frequency. A packet nominally covers a single slot, but can be extended to cover
up to five slots.

The Bluetooth protocol uses a combination of circuit and packet switching.


Slots can be reserved for synchronous packets. Bluetooth can support an
asynchronous data channel, up to three simultaneous synchronous voice channels, or a
channel which simultaneously supports asynchronous data and synchronous voice.

The Bluetooth system consists of a radio unit, a link control unit, and a support unit
for link management and host terminal interface functions.

Different functional blocks in the Bluetooth system

The Bluetooth system provides a point-to-point connection (only two Bluetooth units
involved), or a point-to-multipoint connection.
In the point-to-multipoint connection, the channel is shared among several Bluetooth
units. Two or more units sharing the same channel form a piconet.

3
One Bluetooth unit acts as the master of the piconet, whereas the other unit(s) acts as
slave(s). Up to seven slaves can be active in the piconet. In addition, many more
slaves can remain locked to the master in a so-called parked state.
These parked slaves cannot be active on the channel, but remain synchronized to the
master. Both for active and parked slaves, the channel access is controlled by the
master.

Multiple piconets with overlapping coverage areas form a scatternet. Each piconet
can only have a single master. However, slaves can participate in different piconets on
a time-division multiplex basis. In addition, a master in one piconet can be a slave in
another piconet. The piconets shall not be frequency-synchronized. Each piconet has
its own hopping channel.

a. Piconets with a single slave operation (point to point).


b. A multi-slave operation (point to multi point)
c. Scatternet operation.

4
2.2 Bluetooth system connection
establishment process

2.2.1 General
The channel in the piconet is characterized entirely by the master of the piconet.
The Bluetooth device address (BD_ADDR) of the master determines the
FH hopping sequence and the channel access code; the system clock of the master
determines the phase in the hopping sequence and sets the timing. In addition, the
master controls the traffic on the channel by a polling scheme.
By definition, the master is represented by the Bluetooth unit that initiates the
connection (to one or more slave units). Note that the names ‘master’ and ‘slave’ only
refer to the protocol on the channel: the Bluetooth units themselves are identical; that
is, any unit can become a master of a piconet. Once a piconet has been established,
master-slave roles can be exchanged.

The next figure shows a state diagram illustrating the different states used in the
Bluetooth link controller. There are two major states: STANDBY and
CONNECTION; in addition, there are seven substates, page, page scan, inquiry,
inquiry scan, master response, slave response, and inquiry response. The substates
are interim states that are used to add new slaves to a piconet. To move from one state
to the other, either commands from the Bluetooth link manager are used, or internal
signals in the link controller are used (such as the trigger signal from the correlator
and the timeout signals).

5
State diagram of Bluetooth link controller

2.2.2 States description and access


procedures
2.2.2.1 General
In order to establish new connections the procedures inquiry and paging are used. The
inquiry procedure enables a unit to discover which units are in range, and what their
device addresses and clocks are. With the paging procedure, an actual connection can
be established. Only the Bluetooth device address is required to set up a connection.
Knowledge about the clock will accelerate the setup procedure. A unit that establishes
a connection will carry out a page procedure and will automatically be the master of
the connection.
In the paging and inquiry procedures, the device access code (DAC) and the inquiry
access code (IAC) are used, respectively. A unit in the page scan or inquiry scan
substate correlates against these respective access codes with a matching correlator.

6
2.2.2.2 Standby state
The STANDBY state is the default state in the Bluetooth unit.
The controller may leave the STANDBY state to scan for page or inquiry messages,
or to page or inquiry itself. When responding to a page message, the unit will not
return to the STANDBY state but enter the CONNECTION state as a slave. When
carrying out a successful page attempt, the unit will enter the CONNECTION state
as a master.

2.2.2.3 Page procedure


For the paging process, several paging schemes can be applied. There is one
mandatory paging scheme which has to be supported by each Bluetooth device. This
mandatory scheme is used when units meet for the first time, and in case the paging
process directly follows the inquiry process. Two units, once connected using a
mandatory paging/scanning scheme, may agree on an optional paging/scanning
scheme.

2.2.2.3.1 Page scan


In the page scan substate, a unit listens for its own device access code for the duration
of the scan window Tw page scan. During the scan window, the unit listens at a single
hop frequency, its correlator matched to its device access code. The scan window
shall be long enough to completely scan 16 page frequencies.
When a unit enters the page scan substate, it selects the scan frequency according to
the page hopping sequence corresponding to this unit. This is a 32-hop sequence in
which each hop frequency is unique. The page hopping sequence is determined by the
unit’s Bluetooth device address (BD_ADDR).
The page scan substate can be entered from the STANDBY state or the
CONNECTION state. In the STANDBY state, no connection has been established
and the unit can use all the capacity to carry out the page scan. Before entering the
page scan substate from the CONNECTION state, the unit preferably reserves as
much capacity for scanning.

2.2.2.3.2 Page
The page substate is used by the master (source) to activate and connect to a slave
(destination) which periodically wakes up in the page scan substate. The master tries
to capture the slave by repeatedly transmitting the slave’s device access code (DAC)
in different hop channels. Since the Bluetooth clocks of the master and the slave are
not synchronized, the master does not know exactly when the slave wakes up and on
which hop frequency. Therefore, it transmits a train of identical DACs at different hop
frequencies, and listens in between the transmit intervals until it receives a response
from the slave.

7
2.2.2.4 Inquiry procedures
In the Bluetooth system, an inquiry procedure is defined which is used in applications
where the destination’s device address is unknown to the source. One can think of
public facilities like printers or facsimile machines, or access points to a LAN.
Alternatively, the inquiry procedure can be used to discover which other Bluetooth
units are within range. During an inquiry substate, the discovering unit collects the
Bluetooth device addresses and clocks of all units that respond to the inquiry message.
It can then, if desired, make a connection to any one of them by means of the
previously described page procedure.

2.2.2.4.1 Inquiry scan


The inquiry scan substate is very similar to the page scan substate. However, instead
of scanning for the unit's device access code, the receiver scans for the inquiry access
code long enough to completely scan for 16 inquiry frequencies.
The length of this scan period is denoted Tw_inquiry_scan. The scan is performed at a
single hop frequency. As in the page procedure, the inquiry procedure uses 32
dedicated inquiry hop frequencies according to the inquiry hopping sequence. These
frequencies are determined by the general inquiry address.

2.2.2.4.2 Inquiry
The inquiry substate is used by the unit that wants to discover new devices.
This substate is very similar to the page substate. The inquiry substate can be entered
from the STANDBY state or the CONNECTION state. In the STANDBY state, no
connection has been established and the unit can use all the capacity to carry out the
inquiry. Before entering the inquiry substate from the CONNECTION state, the unit
shall free as much capacity as possible for scanning.

2.2.2.5 Connection state


In the CONNECTION state, the connection has been established and packets can be
sent back and forth. In both units, the channel (master) access code and the master
Bluetooth clock are used.

8
3 The problem with the connection
establishment process
A typical Bluetooth piconet is a dynamic network where units may enter into range
and get out of it frequently. Because of that, the piconet must search for new units in
parallel to the data transmission of the existing members.
While searching for new units the piconet cannot continue delivering packets. This is
because the master is responsible for both searching for new members and the link
control management.
Existing piconet waists too much time in searching for new units, so piconet
efficiency reduced.

9
4 Striving for solution
In order to minimize the performance overhead caused by the search for new units,
new algorithms should be developed and examined.
We are going to build comfortable simulation environment which enables to examine
suggested algorithms.
The environment should be:
• Credible - reflect the real behavior of the Bluetooth net under the suggested
algorithms, with a variety of assumed conditions.
• Flexible – enables the user to easily change the algorithm.
• Representative – supports a variety of criterions to analyze the algorithm.

10
5 Introduction to OPNET simulator
5.1 Modeling Domains
The Network, Node, and Process modeling environments are sometimes referred
to as the modeling domains of OPNET, since they essentially span all the
hierarchical levels of a model. The remaining specification editors correspond to
no particular modeling domain since they mainly support the three principal
editors. The capabilities offered by the three modeling domains mirror the types of
structures found in an actual network system; the issues addressed by each domain
are summarized in the following table and then briefly described in the remainder
of this section. [3]

OPNET Modeling Domains


Domain Editor Modeling Focus
Network Network Project Network topology described in terms of subnetworks, nodes,
Project links, and geographical context.
Node Node Node internal architecture described in terms of functional elements and data
flow between them.
Process Process Behavior of processes (protocols, algorithms, applications), specified using
finite state machines and extended high-level language.

5.2 Network Domain


The Network Domain’s role is to define the topology of a communication
network. The communicating entities are called nodes and the specific capabilities
of each node are defined by designating their model. Node models are developed
using the Node Editor. Within a single network model, there may be many nodes
that are based on the same node model; the term node instance is used to refer to
an individual node, in order to distinguish it from the class of nodes sharing the
same model. However, in general, when the term node is used by itself, in the
context of the network domain, it can be assumed that a node instance is being
referred to, rather than a node model.
A network model may make use of any number of node models. OPNET does
not place restrictions on the types of nodes that can be deployed in a
communication network; instead it adopts an open approach whereby modelers
can develop their own “library” of node models to use as building blocks for
network models. In addition, there are no limits on the number of node models or
node instances that a network model may contain (other than those imposed by
workstation memory limitations).
The Project Editor can provide a geographic context for network model
development. You can choose locations on world or country maps for the
elements of wide-area networks and can use dimensioned areas for local-area

11
networks. In addition to providing an intuitive environment for deploying the
components of a network model, this feature provides an intrinsic notion of
distance, which allows automatic calculation of communication delays between
nodes.
The basic object used to build network models is the fixed communication node.
In OPNET, this is the only type of node available. Fixed nodes can be assigned
arbitrary locations, but during a simulation their location may not change. Several
different types of communication link architectures are provided to interconnect
nodes that communicate with each other. OPNET provides simplex
(unidirectional) and duplex (bidirectional) point-to-point links to connect nodes in
pairs and a bus link to allow broadcast communication for arbitrarily large sets of
fixed nodes. Each type of link can be customized by editing parameters or
supplying new logic for the underlying link models. The following figures show
some typical network model diagrams involving each of the supported link types.
To break down complexity and to simplify network protocols and addressing,
many large networks make use of an abstraction known as a subnetwork. A
subnetwork is a subset of a larger network’s devices that forms a network in its
own right. OPNET provides fixed, mobile, and satellite subnetworks to enhance
network models. These subnetworks can then be connected by different types of
communication links, depending on the type of subnetwork. The larger network
can then be viewed as a network of its subnetworks. This abstraction can be
carried out at many levels. In other words, one can form networks of subnetworks,
which in turn are formed of other subnetworks, and so on. At the bottom of this
hierarchy, the lowest level subnetwork is composed only of nodes and links, but
no other subnetworks. [3]

5.3 Node Domain


The Node Domain provides for the modeling of communication devices that can
be deployed and interconnected at the network level. In OPNET terms, these
devices are called nodes, and in the real world they may correspond to various
types of computing and communicating equipment such as routers, bridges,
workstations, terminals, mainframe computers, file servers, fast packet switches,
satellites, and so on.
Node models are developed in the Node Editor and are expressed in terms of
smaller building blocks called modules. Some modules offer capability that is
substantially predefined and can only be configured through a set of built-in
parameters. These include various transmitters and receivers allowing a node to be
attached to communication links in the network domain. Other modules, called
processors and queues, are highly programmable, their behavior being prescribed
by an assigned process model. Process models are developed using the Process
Editor.
A node model can consist of any number of modules of different types. Three
types of connections are provided to support interaction between modules. These
are called packet streams, statistic wires (also sometimes referred to as streams
and statwires, respectively), and logical associations. Packet streams allow
formatted messages called packets to be conveyed from one module to another.
Statistic wires convey simple numeric signals or control information between

12
modules, and are typically used when one module needs to monitor the
performance or state of another. Both packet streams and statistic wires have
parameters that may be set to configure aspects of their behavior. Logical
associations identify a binding between modules. Currently, they are allowed only
between transmitters and receivers in order to indicate that they should be used as
a pair when attaching the node to a link in the Network Domain.
The modeling paradigm selected for the Node Domain was designed to support
general modeling of high-level communication devices. It is particularly well
suited to modeling arrangements of “stacked” or “layered” communication
protocols. In the Node Editor, a device that relies on a particular stack of protocols
can be modeled by creating a processor object for each layer of that stack and
defining packet streams between neighboring layers. [3]

5.4 Process Domain


As mentioned earlier in the discussion of the Node Domain, queue and
processor modules are user-programmable elements that are key elements of
communication nodes. The tasks that these modules execute are called processes.
A process can in many ways be thought of as similar to an executing software
program, since it includes a set of instructions and maintains state memory.
Processes in OPNET are based on process models that are defined in the Process
Editor. The relationship between process model and process is similar to the
relationship between a program and a particular session of that program running
as a task.
Just as nodes created in the Project Editor are instances of node models defined
with the Node Editor, each process that executes in a queue, processor, or esys
module is an instance of a particular process model. The process modeling
paradigm of OPNET supports the concepts of process groups. A process group
consists of multiple processes that execute within the same processor or queue.
When a simulation begins, each module has only one process, termed the root
process. This process can later create new processes which can in turn create
others as well, etc. When a process creates another one, it is termed the new
process’ parent; the new process is called the child of the Process that created it.
Processes that are created during the simulation are referred to as dynamic
processes.
OPNET places no limits on the number of processes that may be created in a
particular processor or queue. Processes may be created and destroyed based on
dynamic conditions that are analyzed by the logic of the executing processes. This
paradigm provides a very natural framework for modeling many common
systems. In particular, multitasking operating systems where the root process
represents the operating system itself and the dynamically created processes
correspond to new tasks; and multi-context protocols where the root process
represents a session manager, for example, and each new session that is requested
is modeled by creating a new process of the appropriate type.
Only one process may be executing at any time. A process is considered to be
executing when it is progressing through new instructions that are part of its
process model. When a process begins execution it is said to be invoked. A
process that is currently executing can invoke another process in its process group

13
to cause it to begin executing. When this happens, the invoking process is
temporarily suspended until the invoked process blocks. A process blocks by
indicating that it has completed its processing for its current invocation. Once the
invoked process has blocked, the invoking process resumes execution where it had
left off, in a manner similar to the procedure-call mechanism in a programming
language such as C.
Processes in OPNET are designed to respond to interrupts and/or invocations.
Interrupts, are events that are directed at a process and that may require it to take
some action. They may be generated by sources external to a process group, by
other members of a process group, or by a process for itself. Interrupts typically
correspond to events such as messages arriving, timers expiring, resources being
released, or state changes in other modules. Once a process has been invoked due
to an interrupt, it may invoke other processes in the group and these may in turn
invoke other processes, etc. An interrupt’s processing is completed when the first
process that was invoked blocks.
OPNET’s Process Editor expresses process models in a language called Proto-C,
which is specifically designed to support development of protocols and
algorithms. Proto-C is based on a combination of state transition diagrams (STDs),
a library of high-level commands known as Kernel Procedures, and the general
facilities of the C or C++ programming language. A process model’s STD defines
a set of primary modes or states that the process can enter and, for each state, the
conditions that would cause the process to move to another state. The condition
needed for a particular change in state to occur and the associated destination state
are called a transition.
Proto-C models allow actions to be specified at various points in the finite state
machine. The actions can be extremely general in nature since they are expressed
as C or C++ statements. In addition, because Proto-C is focused on modeling
protocols and algorithms, it provides an extensive library of over 300 Kernel
Procedures (also known as KPs) that can be invoked to perform commonly needed
actions. Kernel Procedures are grouped into packages of related functions.
The state transition diagram representation of Proto-C is well suited to the
specification of an interrupt-driven system because it methodically decomposes
the states of the system and the processing that should take place at each interrupt.
STDs developed in OPNET’s Process Editor have a number of extensions beyond
the capabilities offered by traditional state-transition diagram approaches:
• State Variables. Processes maintain private state variables with named
variables of arbitrary data types, including OPNET-specific, general C/C++
language, and user-defined types. This capability allows a process to flexibly
maintain counters, routing tables, statistics related to its performance, or messages
requiring retransmission. Arbitrary combinations of state variable values may be
used in all decisions and actions implemented by a process.
• State Executives. Each state of a process can specify arbitrarily complex actions
associated with the process entering or leaving that state. These actions, called
state executives, are expressed with the full flexibility of the C/C++ language.
Typical actions include modifying state information, creating or receiving
messages, updating the contents of and sending messages, updating statistics, and
setting or responding to timers.
• Transition Conditions. Transition condition statements, which determine
whether a transition should be traversed, may be expressed as general C/C++

14
language booleans that make reference to properties of a new interrupt as well as
to combinations of state variables.
• Transition Executives. Transitions may specify general actions, called
executives, which are implemented each time that they are traversed. [3]

5.5 Process Model Attributes


A process model may define parameters, called attributes, which are used once
it is instantiated as a process to customize aspects of its behavior. This technique
fosters reuse of process models for various purposes by avoiding “hardwired”
specification where possible. For instance, a process model that performs window-
based flow control may be defined with the window size as an attribute, so that it
is reusable in different situations requiring different values of the window size. [3]

15
6 Schedule
• April 2003: Learning the Bluetooth system,
focusing on connection establishment process.
• May 2003: Learning OPNET – building and
analysis of a simulation.
• June-July 2003: Building the model and test
its credibility.

16

You might also like