Bluetooth Connection Establishment Process Project Mid Semester Report
Bluetooth Connection Establishment Process Project Mid Semester Report
Bluetooth Connection Establishment Process Project Mid Semester Report
Connection
Establishment
Process
Project Mid
Semester Report
1 Project Goals
2
2 Background
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 system consists of a radio unit, a link control unit, and a support unit
for link management and host terminal interface functions.
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.
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
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.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.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.
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]
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]
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]
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]
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