|
Evaluating
Bluetooth Throughput and Interoperability
with other Protocols
Click
here to view and execute the VisualSim
model
This
shows the topology of a Master-Slave
Bluetooth system in VisualSim. The Blue_1
and Blue_2 have been designated as the
Slaves and the HUB has been designated
as the Master. The roles can be reversed
by modifying the Packet_Destination
parameter of the model. This model contains
three Master/Slave nodes with built-in
arbiter, transmitter and receiver. The
statistics and plotting are integrated
in the model. The traffic enters the
system at each Slave and leaves the
network at the Master.
Click
here to view the interactive VisualSim
Block Diagram and model
The
VisualSim model of a Bluetooth Master/Slave
configuration contains a State Machine,
with state being the state of the network.
The transmitter and receiver are contained
in a single window. The parameters of
the model can be modified to create
multiple operating conditions. The MAC
layer model is signaling and timing-accurate.
This
Bluetooth model has been created based
on the specification laid out by the
Bluetooth SIG version 1.1. For more
details on the Bluetooth MAC layer details,
please refer to the Bluetooth Link-Layer
specifications- Part C, D and E. Modeling
can be a very effective tool for analyzing
a variety of architecture and performance
issues.
Some
of the issues to be considered by System
Architects include:
- How
to account for frame errors that
cause retries, or contention from
other Bluetooth devices, when the
application is based on a Constant
Bit Rate (CBR) algorithm?
- How
should priority be assigned for
applications such as voice transmission
and what is the impact on the effective
throughput?
- What
are the resource trade-offs in implementing
new applications and features in
custom hardware or software over
the Bluetooth standard?
- What
is the buffer tradeoff versus end-to-end
frame latency?
The
variety of Bluetooth options and the
low-power requirements of the final
product increases the complexity of
these technical decisions. The non-deterministic
nature of the traffic profile requires
accurate modeling efforts to predict
the resource requirements, and the effective
maximum throughput when used in connection
with other protocols such as Bluetooth
and Ethernet.
The
purpose of this model is to evaluate
the throughput of a Wireless LAN
network for a number of constraints
including:
1. Impact of packet fragmentation
on throughput
2. Frame latency due to preemption
by voice traffic
3. Effective utilization based on
Protocol signal overhead, and variable
node and Access points Wire-rates.
Model Overview
The Discrete-Event simulation model
in VisualSim consists of traffic
generators, Master/Slave nodes and
statistics generation. The VisualSim
model has been constructed as a
hierarchical design to enable easy
of understanding and modification.
Each node contains wired and wireless
link- one for the network and one
for the product-side. The arbiter
is built-in each node and as such,
they can function as both Master
and Slave. The transmitter and receiver
have been built into the same flow.
Each node has a priority queue that
controls the messaging. The priority
of the connection-oriented flow
is captured in this block. The other
frames all have the same priority
and are not affected by the preemption.
This model supports statistical
delay of Master/Slave Connection
with a arbitration mechanism. Data
Transfer is modeled to being timing
accurate. TX Time 366 us, Hop Time
(625 us - TX Time)
Data
Structure
The input frame is a Data Structure
that contains the following fields:
public String Station_Name = "Null"
; // Station Name
public double Station_X_Pos = 0.0
; // Station X position (ft)
public double Station_Y_Pos = 0.0
; // Station Y position (ft)
public double Station_Direction
= 0.0 ; // Station direction (degrees)
public double Station_Velocity =
0.0 ; // Station velocity (ft/sec)
public double Station_Power = 0.0
; // Station power (dbm)
public String Packet_Transmitter
= "Null" ; // Routing
Relavant Information
public String Packet_Receiver =
"Null" ; // Routing Relavant
Information
public String Packet_Type = "Null"
; // Relevant Descriptor
public int Packet_Number = 0 ; //
Unique ID
public int Packet_Priority = 0 ;
// Packet Priority
public int Packet_Slots = 1 ; //
Packet Slots (1, 3, 5)
public int Packet_Size = 0 ; //
Packet Size in Bytes (Master, Slave)
public int Packet_Original_Size
= 0 ; // Original Packet Size in
Bytes
public int Packet_Hop_ID = 0 ; //
Packet Hop ID
public boolean Packet_Select = false
; // Selection Flag
public double Packet_Time = 0.0
; // Packet Time
public double Packet_Delta_Time
= 0.0 ; // Relative time to next
Packet
The Bluetooth Data Structure carries
the information associated with
each frame for analysis and signalling.
The key fields used in the model
are source, destination, frame size
and timestamp. The model generates
frames at periodic rates but can
be easily modified to accommodate
a network trace for more accurate
modeling. Provision is provided
for mobile position, direction and
velocity in the input definition.
The Data Structure can be enhanced
to add other details as required
fvor the modeling including adding
the actual data that needs to be
transmitted.
Model
Details
The protocol data (FRAME) and control
frames (RCVR, TMIT, Busy and TRY)
are based on the Bluetooth specification.
When a Master/Slave connection is
established the communication continues
until both sides have exhausted
all the frames to transmit or the
connection is preempted by a higher
priority connection-oriented request.
The
model has been constructed with
expandability in mind. The model
can be enhanced to add the Physical
Layer. In addition, application
such voice calling and keyboard
interface can be developed on top
of this model.
Modifying
Parameters to create new scenarios
The model has a number of top-level
parameters for the user to modify
and evaluate performance. The key
one's are the input_packet_byte_size
and the min/max connect time. Modify
these to vary the fragmentation
effects and the The frame size and
fragmentation limit are maintained
as parameters that can be modified
to test protocol functionality and
system throughput. The traffic rate
can also be generated by modifying
the Mean time and using a different
distribution.
-
Vary
the simulation time by double-clicking
on the Gear (top-right) and modifying
the Stop Time parameter.
-
Vary
the Probability_Hop_Collision
as a probability value between
0 and 1, by double-clicking on
the parameter icon on the canvas.
Notice the change in the Frame
Latency. Also notice the variations
in the Protocol States.
-
Vary
the Frame_Size_Bytes parameter
by double-clicking on it and changing
the value. As the size of the
frame increases the latency starts
to grow as a results increased
waiting time. Additionally, the
frame can be made connection-oriented
and a priority added to create
a non-deterministic situation.
This change is not available in
the Web model.
-
Double-click
on the Blue_1_Traffic and the
Blue_2_Traffic blocks and change
the Packet Destination. This will
create a new setup.
Analysis
Three analysis graphs are displayed
on this page below.
1. The timeline plot titled Bluetooth
Protocol contains all the Bluetooth
signals: RCVR, XMIT, BUSY, TRY and
FRAME. The plot shows fragmentation
frames being transmitted. Contention
is shown in the first sequence where
there are two RTS frames. This plot
represents the functional accuracy
of the implemented algorithm and
evaluates the protocol correctness
for scenarios such as fragmentation,
arbitration and contention.
2. Frame Latency shows the variation
of the latency against various parameters.
Vary the size of the input frame
or the input rate to see the latency
get modified.
3. Access Out text display shows
the values of the Data Structure
fields at the Access Point.
|
