BlueTooth High-Level Simulator

1. BlueTooth High-Level Simulator A Base Platform For Simulating Packets Routing Algorithms Over A Bluetooth Scatternet Students: Ehud Klugman klugman@internet-zahav.net Eitan Peri eitanp@barak-online.net Instructor : Ran Cohen

2. A BlueTooth Scatternet BlueTooth Background • BlueTooth is a technology specification. • It describes how various electronic products, can interconnect with each other using a short-range wireless connection, and establish a network. • Some BlueTooth basic terms: • Unit - The most primitive element in a BlueTooth scatternet. It can be any electronic product which implements the BlueTooth specification. At a single piconet, a unit can be a master unit or a slave unit. • Piconet - A “mini-network”, with small coverage area, which consist of one BlueTooth master unit, and one to seven slave units. Slaves communicate only with the master unit (and not with each other). • 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 those piconets. It is possible to route packets in a scatternet. 99-0767, ZLE Strategy summary

3. Project Objectives • Base platform for simulating routing algorithms over a scatternet. • Simulates connecting/disconnecting of units to the scatternet over the time axis. • The behavior of the unit is pre-defined by the user using different attributes. • Supporting run-time tracing over unit’s connectivity to the scatternet. • User Interference during run-time, can be used to connect/disconnect units form the piconet or the scatternet. 99-0767, ZLE Strategy summary

4. Our 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. • Running a few units simultaneously, 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. • Acknowledge is needed for every packet transmissions (except broadcast & SCO connection), and is implemented in application level. 99-0767, ZLE Strategy summary

5. Script Line Example: Btsim -master 2.3 7.5 132.68.55.1 2022 -if Port number of this role Executable Name Role of the unit Role’s start time Role’s end time IP address of this role Use user interface Our Implementation – General (cont.) • 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. • Running the simulation can be done through script: • Scripts Contain some attributes for each unit, in a single line. • It executes the processes/units one by one. • Command-line user interface can be used to change/see units’ attributes on run time: • Changing the roles of a unit, means connecting disconnecting it from a specific piconet, or destroying it completely. • Seeing the units connectivity, and other information. 99-0767, ZLE Strategy summary

6. Slave Master BT_scheduler Inherited BT_unitFunc N 1 BT_userInterface BT_unitFuncManager BT_udpConnection BT_requestsTable BT_msgSendQueue BT_send BT_recv BT_responseCache High Level Design – Classes Relations 99-0767, ZLE Strategy summary

7. High Level Design – Main Classes Description • BTudpConnection - A single network connection. • BTrecv - Inherited from thread class, and handles received massages from the network. There are two kind of received massages: • Request- Contain a certain command that should be handled by the receiving unit. For example, a request from new slave unit to the piconet’s master to be added to this piconet. • Response – Contains the result of executing previous Request. There are two kinds of responses: • Immediate response – Indicates that the request and was received, and the receiving unit started to process it. It is sent when the processing time of the request might be long. • Final replay – Indicates that the receiving unit finished processing the request, and contains the requested data. As in the example above, the master can replay to the new unit with its identification number in the piconet or by denying the request • BTrequestsTable - Implements a table, that contains requests that were sent on the network, but no acknowledgements were received for them. 99-0767, ZLE Strategy summary

8. High Level Design – Main Classes Description (continue) • BTresponseCache - Caching implementation of the responses that the unit is sending to other units: • When a request from the unit is received at the first time: • It is passed to BTunitFuncManager that generates a response. • The response is stored in the data structure of this class. • If this request is received again (response was lost): • Its response is stored in the cache of receiving unit (BTrecv). • The response is read from the cache, and is send immediately. The time of computing the response again is saved. • BTmsgSendQueue - Implements a queue of massages that should to be sent: • BTrecv & BTunitFunc classes fill this queue with massages. • BTsend’, which run on separate thread, fetches the massages that is located on the top of this queue, and send them. • BTsend -Inherited from thread class, and has two tasks: • Sends to network the massages that are in BTmsgSendQueue. Each sent massage is also added to BTrequestsQueue. • Re-send requests that weren’t acknowledged by the destination unit after a certain time (using BTrequestsQueue). 99-0767, ZLE Strategy summary

9. High Level Design – Main Classes Description (continue) • BTunitFunc - Represents a single functionality of the unit in the Bluetooth scatternet. • Such a functionality is either master or a slave in a single piconet. • A unit can own more than one BTunitFunc, if it is in a few piconets. • Those two functionalities are inherited from this class. • BTunitFuncManager - Responsible for the following: • Create a new BTunitFunc, or destroy an existing one. • Creation or destruction of BTunitFunc is done, when a command is passed to this class from BTscheduler or BTuserInterface classes. • Receive massages from BTrecv and deliver them to the right BTunitFunctional object.   • BTuserInterface- Inherited from thread class, & has the following tasks: • Display unit’s information to the user on screen. • Receive from the user some basic commands. • BTscheduler - It is the main stream of the unit, & has two main tasks: • Create all other objects on proccess initialization. • Schedule the creation and the destruction of BTunitFunc classes, by using functions of BTunitFuncManager 99-0767, ZLE Strategy summary