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 conunction 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.  
   

Model Applet: 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.


Model Applet: 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.