BlueTooth High-Level Simulator

comnet.technion.ac.il/~cn23s00

Computer Networks Laborator

y

Technion Israel Institute of Technology

BlueTooth High-Level BlueTooth High-Level Simulator Simulator

A Base Platform For Simulating Packets A Base Platform For Simulating Packets Routing Algorithms Over A Bluetooth Routing Algorithms Over A Bluetooth ScatternetScatternet

Students: Ehud Klugman [email protected] Eitan Peri [email protected]

Instructor : Ran Cohen

299-0767, ZLE Strategy summaryBlueTooth High Level

Simulator

What Is Bluetooth ? Bluetooth is a technology specification. Bluetooth is a technology specification. Describes how various electronic products such as mobile Describes how various electronic products such as mobile

phones, computers, and personal digital assistants (PDAs) phones, computers, and personal digital assistants (PDAs) can interconnect with each other using a short-range wireless can interconnect with each other using a short-range wireless connection.connection.

The wireless connection is established using a low-power The wireless connection is established using a low-power radio link among the devices. radio link among the devices.

The primary benefit of this technology is the elimination of The primary benefit of this technology is the elimination of proprietary cables which are currently required to connect proprietary cables which are currently required to connect devices for information synchronization. devices for information synchronization.

Examples: LAN connection, email downloading, Automatic Examples: LAN connection, email downloading, Automatic house.house.


Simulator

Piconet A “mini-network” using radio

freq’ (no cables) Consist out of:

One master unit. One to seven slaves units.

Slaves communicate only with the master unit.

Small coverage due to low powered high freq’ (2.45 GHz).

Using 1Mhz freq’-hop/time-division-duplex (each time slot 625s)


Simulator

Scatternet Group of piconets with

overlapping area of coverage.

A unit can act as master & slave at the same time in different piconets or as slave in both piconets

Different piconets use different hop channels.

It is possible to route packets in a scatternet.


Simulator

Project ObjectivesProject Objectives Base platform for simulating routing algorithms over a

scatternet. The functionalities (master, slave) of each unit, and it’s

behavior (executing requests/responses) can be define by one or more of the following:

Pre-written input files. Executing commands from the command prompt by the

user at run time (User-Interface). The definitions of each unit is used, to simulate

connecting/disconnecting units to the scatternet and simulate routing algorithms over the time axis.

Supporting run-time tracing over units’ functionalities and behavior, and connectivity to the scatternet.


Simulator

Our Implementation - GeneralOur Implementation - General Language: Java.

Code can run on any platform. Ready classes for networking and threads.

Each unit is represented by a separate process. Our code implements a single unit, which can be executed

from the command prompt. Each unit has its own input file that describe the units’

functionality over the time axis. Running a few units simultaneously (by writing script or

batch file for example), can create a piconet/ scatternet.

The units communicate over the network using UDP: UDP is best for simulation radio transmissions. Units can run on different machines. Packets loss is simulated in application level.


Simulator

Acknowledge is needed for every packet transmissions and is implemented in application level.

Packets enumerating is used to distinguish packets:

Avoiding duplicated packets/ack to be executed more then once.

Use Responses Cache in order to save re-calculating a certain response, when duplicating request is received.

Our Implementation – General (cont.)Our Implementation – General (cont.)


Simulator

Running the simulation can be done through script or batch file:

Scripts or batch files contain some attributes for each unit, in a single line.

It executes the processes/units one by one. Command-line user interface or input file can be

used to execute commands on run time: Changing the functionalities of a unit, means defining it

as slave or master in a specific piconet, or removing those functionalities.

As master- executing and sending requests to other slaves in the same piconet.

As Slave- executing and sending responses to the master of the same piconet.

Seeing the units functionalities, connectivity, behavior, and other information.

Our Implementation – General (cont.)Our Implementation – General (cont.)


Simulator

High Level Design – Classes RelationsHigh Level Design – Classes Relations

BT_sendBT_requestsCache

BT_recv

BTudpConnection

BT_responsesCache

BT_unitFuncManager

BT_unitFunc

1

N

Slave Master

InheritedBT_scheduler

BT_userInterface


Simulator

High Level Design – Main Classes DescriptionHigh Level Design – Main Classes Description

Simulates the transmitting unit of the device. Sends UDP packets to other devices. Appropriate header is added before packet is sent:

Request header Response header

Before sending response to network, it is added to the Requests cache.

Contains inner-class: BTsender – actual network access

BTsend


Simulator


Simulates the receiving unit of the device. Receive UDP packets Header analysis:

Response: check if already exists in responses cache.– Yes? Ignore packet.– No ? Add to responses cache and forward to

BTunitFuncManager Request: check if already exists in requests cache.

– Yes? fetch the appropriate response from the cache and send it back to the sender (immediate response).

BTrecv


Simulator


– No ? forward to BTunitFuncManager to calculate the response.

Contains inner-class: BTreceiver – actual network access

BTrecv – Cont.


Simulator


Handles the management of the different functionalities that a unit can have, on different piconets:

Adding/removing functionalities. Keep information on the current functionalities. When executing a request, this class pass the request to the master

functionality, and when executing a response to one of the slaves. The same when a request or response is received from the network.

A unit can be one or more of the following: A master on a certain piconet. A slave in up to 7 other piconets. A slave is differ from other slaves (at

this unit) by it’s master IP and Port number.

BTunitFuncManager


Simulator


Holds all the common attributes (variable) and behavior (methods) to a master and slave functionalities:

Common Attributes: MacAddress (combination of IP address and port number). Local ID in the piconet & more.

Common behavior: Parsing a request type. Parsing response type. Handing functions for all the supported types of requests

and response.

BTunitFunctionality


Simulator


Handle all the attributes and behavior of a master or slave functionality.

As so, include the main code regarding executing BT requests and response.

As master: Executing all the supported types of requests, and handle all types of incoming responses.

As slave: Executing all the supported types of responses, and handle all types of incoming requests.

In the future, the different routing algorithms should be add/implemented mainly to those classes.

BTunitMasterFunc & BTunitSlaveFunc


Simulator


Implements the scheduler, which is the main flow (thread) and entry point of the project.

It responsible to create all the other classes (BTunitFuncManager, BTudpConnection, BTuserInterface etc.).

Its flow include reading the input file line by line, parse the line and schedule (& execute) the command that is defined by this line in the right time.

Executing the command is done by calling the different functions of BTunitFuncManager.

BTscheduler


Simulator


Responsible to implement the user interface of the project.

Read user commands from the command prompt, and execute those command right away.

Executing those commands is done by using the BTscheduler parsing functions.

BTuserInterface


Simulator

Requests and ResponsesRequests and Responses Requests and Responses are the basic packets types

that are transferred between the master and it’s slaves. Requests - Issued by the master and sent to a single

slave in this master’s piconet, or to all slaves in this piconet (broadcast).

Responses – Issued by a slave and sent back. Responses cannot be issued independently by the slave. They are issued as a result of receiving a request from the master.


Simulator

Request Request Response Flow Response FlowOn the executing master:1. The BTscheduler or BTuserInterface parse a user command, from

the input file of command prompt, and pass it to a BtunitFuncManager‘s function.

2. BtunitFuncManager sees if master is defined for this unit, and if yes pass it to a BTunitMasterFunc’s function.

3. BTunitMasterFunc do: Parse the request, and finds it type and parameters. Do some actions specific for this type of request. Send a request to the other slave (on different unit), using

BTudpConnection. Waits for a response using Java’s “wait” method.


Simulator

Request Request Response Flow (cont.) Response Flow (cont.)

On the receiver slave:1. BTudpConnection receives the request and pass it to a

BtunitFuncManager‘s function.2. BtunitFuncManager sees if a slave with the same master

as the sender is defined for this unit, and if yes pass the request to the function of the corresponding BTunitSlaveFunc.

3. BTunitSlaveFunc do: Parse the request, and finds its type and parameters. Do some actions specific for this type of request. Send back a response to the master, using

BTudpConnection.


Simulator

Request Request Response Flow (cont.) Response Flow (cont.)

On the executing master:1. BTudpConnection receives the response and pass it to a

BtunitFuncManager‘s function2. BtunitFuncManager sees if master is defined for this unit, and if

yes pass it to the BTunitMasterFunc’s function.3. BTunitMasterFunc do:

Sees if this is the response to the pending request (to which it waits for a response). If no – ignore, if yes- continue.

Notify the thread that waits for a response. In the waiting thread, do the rest of the actions required

specific for this type of response, depends if the response showed success or not.

The master waits only limited time for a response. It it is expired it declares a timeout.


Simulator

Implemented Types of Requests and Implemented Types of Requests and ResponsesResponses

Connect Request Send by a master in order to connect a new slave to the

piconet (assigns a new ID number to the new slave: 1-7)

Disconnect Request. Send by a master in order to disconnect an old slave from

the piconet. The ID number of the slave is returned to the “free ID pool”,

so it can later be assigned to other slave.


Simulator

Implemented Types of Requests and Implemented Types of Requests and ResponsesResponses – cont. – cont.

Payload Request Master transfers a payload data to the slave. Currently, the slaves only prints this payload, but it can be

changed for any simulation purpose.

Forward response Sent by a slave to its master after latter sends polling

request. It is used when the slave wants to forward a request to

another slave in the same piconet. Demonstrates a possible implementation of high-level

protocol command.


Simulator

Implemented Request Polling - GeneralImplemented Request Polling - General Purpose - Give the salves the option to promote a transaction. Polling can last for a limited time or “forever”. General flow:

Master sends polling requests to its slaves once in a while. Each slave response one of the following :

– No response to execute.– One response to execute.– One response to execute, but afterwards, has one more

responses to execute (This technique is used when the slave has few responses to the master).

• When the master received the response it execute it (if there is one to execute), and send another polling request to this slave if it has more responses afterwards.


Simulator

Implemented Request Polling – Timing Implemented Request Polling – Timing & Policy& Policy

1. Choose the next slave to poll. This slave is chosen from the slaves that are connected to the piconet of that master.

2. If Slot Time still didn’t past since last time a polling request was handled to the chosen slave, go back to step 1. Else continue.

3. Mark the current time as the start time of handling the polling request for the chosen slave, send a polling request to this slave, and wait for a response.

4. Depends on the slave’s response- If no response was received within timeout or Polling Response indicates that

the slave has no response to execute, continue to 1. If the Polling Response indicates that the slave has one response to execute,

execute this response, and continue 1. If the Polling Response indicates that the slave has few responses to execute,

execute the first one (the one that was sent with this response), and go back to step 4.

Instead, the polling can define for one slave only..


Simulator

Threads FlowsThreads Flows BTscheduler – main threadBTscheduler – main thread

The main thread of the application.The main thread of the application. Schedules events that were defined in the input file.Schedules events that were defined in the input file. It’s main flow:It’s main flow:

– Parse the parameters of the execution command.– Initiate threads: BTrecv and BTuserInterface (optional).– Parse the input file through the execution:

– Read the time parameter from a single line and check if this time has reached yet.

If NO – sleep for a while.If Yes – parse the rest of the command line

and executethe command

Run foreverRun forever


Simulator

Threads Flows – cont.Threads Flows – cont. BTuserInterfaceBTuserInterface

runs only if the user has chosen to activate the user interface option.

It is started by the main thread, just after it finish parsing the execution command.

Its main flow:– Wait for a command from STDIN (from the user).– Parse the command and act accordingly:

– “exit command” – terminate execution.– If the user gave illegal command or parameters - print an error

message – Else, execute the entered command as if it was printed in the

input file.


Simulator

Threads Flows – cont.Threads Flows – cont. BTrecvBTrecv

runs forever while waiting for packets from networkruns forever while waiting for packets from network Its main flow:Its main flow:

– Receive a packet (UDP) – Disassemble the packet to it’s main components.– Check the caches to see if the same packet has been

received before:– If YES: ‘response’ – ignore it. ‘request’ – send immediate

response.– If NO: forward the packet to unit-functionality-manager.-manager.


Simulator

Synchronization MechanismSynchronization Mechanism Generally - Prevent simultaneous access to data Generally - Prevent simultaneous access to data

structures, by two different threadsstructures, by two different threads.. Synchronize between execution of two commandsSynchronize between execution of two commands::

Both, the scheduler and User-If threads use the Both, the scheduler and User-If threads use the synchronized ‘synchronized ‘executeCommand’executeCommand’ function of function of BTschedulerBTscheduler to execute a single commandto execute a single command..

Synchronize between receiving requests or responses to Synchronize between receiving requests or responses to changing the unit functionalitychanging the unit functionality..

Scheduler thread (or User-If thread) may add/remove Scheduler thread (or User-If thread) may add/remove functionalities, and the receiver (BTrecv) thread uses those functionalities, and the receiver (BTrecv) thread uses those functionalities to handle the coming requests or response.functionalities to handle the coming requests or response.


Simulator

Synchronization MechanismSynchronization Mechanism –cont. –cont. Synchronize between sending a request and receiving its Synchronize between sending a request and receiving its

corresponding response corresponding response Synchronize between sending a request, and receiving and Synchronize between sending a request, and receiving and

handling the corresponding response.handling the corresponding response.

Uses a “wait” and “notifyAll” mechanism of Java.Uses a “wait” and “notifyAll” mechanism of Java.

Promises that the receiving thread will handle the received Promises that the receiving thread will handle the received response only after its corresponding request was sent by response only after its corresponding request was sent by the other thread.the other thread.

Promises that handling response that was received for one Promises that handling response that was received for one request will not interrupt sending another request. request will not interrupt sending another request.


Simulator

Synchronization MechanismSynchronization Mechanism – cont. – cont. Synchronization on the slave’s cache of responses to be Synchronization on the slave’s cache of responses to be

sent:sent: Both, the Scheduler (or User-If thread) and the receiver Both, the Scheduler (or User-If thread) and the receiver

(BTreacv) access the (BTreacv) access the responses-To-Be-Sentresponses-To-Be-Sent cache. cache.


Simulator

Low level networking protocolLow level networking protocol

HEADER DATA

Field Name Packet Type Packet’s Sequence Number

Separator Data

Field Size Field Size [char][char]

3 Not limited

1 Not limited

Possible Values

“req” for request“rsp” for response

- Space character

-


Simulator

Low level networking protocol – cont.Low level networking protocol – cont. The data field for The data field for responseresponse (“rsp”) is constructed out of two main (“rsp”) is constructed out of two main

components:components:1.1. The packet’s sequence number of the appropriate request.The packet’s sequence number of the appropriate request.2.2. The response data itself.The response data itself.

Example for response packet:Example for response packet:

rspenud-klugman/213.8.199.94,973981016120,:1 enud klugman/213.8.199.94,973981026720,:2 rsp_status_succe

White color – Packet type. Green color – Packets sequence number. Yellow color – the data field


Simulator

Caching UsageCaching Usage

Requests CacheRequests Cache

KEY ValueSender IP Addr. Sender Port No. Seq. Num. Of

received packetCorresponding response

Upon receiving a request If the key exists in the cache – immediate response If not – forward the request to the unit-functionality-

managerUpon sending a NEW response, It is added (with it’s

corresponding request) to the requests cache.


Simulator

Caching UsageCaching Usage – cont. – cont.

Responses CacheResponses Cache

KEY ValueSender IP Addr Sender Port No. Seq. Num. Of

received packet---

Upon receiving a response If the key exists in the cache – ignore packet If not – forward the request to the unit-functionality-manager

The unit manager should deal with each request only once !!!


Simulator

Using The SimulatorUsing The Simulator One Top Script which execute all processes (BT units)

Upon execution some constant parameters are defined:Port number, input file , user-IF usage.

Each Process has it’s input file which contains simulator instructions.

Those instructions describe unit’s behavior over the time axis:

– Adding/removing Master functionality.– Adding/removing Slave functionality.– Sending Requests/responses to other unit.– Start polling.


Simulator

Using The Simulator – cont.Using The Simulator – cont. High level protocols (routing) should be written using

those instruction.

For example, we’ve implemented the forward high-level command:

MASTER

SLAVE 1 SLAVE 1

Polling

Forward massage

Massage from Slave #1


Simulator

Using The Simulator – cont.Using The Simulator – cont. Script File – Example (NT):

start /separate c:\jdk1.2.2\bin\java Btscheduler

-ftests\test4\test4_m.txt -adf -p20000 -d5 –s5 -i

Execute a new process and continue immediately to the next line of the script


Simulator


start /separate c:\jdk1.2.2\bin\java Btscheduler


Execute the new process in a separate window


Simulator


start /separate c:\jdk1.2.2\bin\java BTscheduler


Executing the new process (BT Unit)


Simulator




Path to the input file (-f flag)


Simulator




Use IP of current machine (-a flag).

“df” – default IP

“lb” – loop back IP


Simulator




Port Number of this unit (-p flag)


Simulator




Optional: The number of duplicated sending to the network out of 10 attempts (-d flag)


Simulator




Optional: The number of successfully sending to the network out of 10 attempts (-s flag)


Simulator




Using the User Interface (-i flag)


Simulator

Using The Simulator – cont.Using The Simulator – cont. Input File – Simple Example (NT):

MASTER2 management add_master4 request 127.0.0.10 20030 req_connect5 request 127.0.0.20 20040 req_connect

Slave 11 management add_slave 127.0.0.5 20000

Slave 21 management add_slave 127.0.0.5 20000

Will result at time 5:

Master

Slave2 Slave1


Simulator

Using The Simulator – cont.Using The Simulator – cont. Input File – Complex Example (NT):

MASTER U12 management add_master15 request 132.68.48.67 20002 req_connect30 request 132.68.48.67 20003 req_connect30 request 132.68.48.67 20004 req_connect33 request 132.68.48.67 20005 req_connect35 management print60 request 255.255.255.255 0 req_polling 40 1031 management print104 request 255.255.255.255 0 req_polling 70 15175 management print180 request 132.68.48.67 20002 req_discont180 request 132.68.48.67 20003 req_discont180 request 132.68.48.67 20004 req_discont180 request 132.68.48.67 20005 req_discont

U1

U4

U5

U2

U3

U8U7

U6

1

2

3

4

3

2

1

4


Simulator

Using The Simulator – cont.Using The Simulator – cont. Input File – Complex Example (NT):

SLAVE U41 management add_slave 132.68.48.67 200011 management add_slave 132.68.48.67 2000510 management print50 management print60 management print70 response 132.68.48.67 20001 rsp_forward 1 3

req_payload HELLO SLAVE ID 1 from ID 3!!!!75 response 132.68.48.67 20005 rsp_forward 1 4

req_payload HELLO SLAVE ID 1 from ID 4!!!!77 response 132.68.48.67 20005 rsp_forward 2 4

req_payload HELLO SLAVE ID 2 from ID 4!!!!150 management print

U1

U4

U5

U2

U3

U8U7

U6

1

2

3

4

3

2

1

4


Simulator

Documents

BlueTooth High-Level Simulator