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. What Is Bluetooth ? • Bluetooth is a technology specification. • Describes how various electronic products such as mobile phones, computers, and personal digital assistants (PDAs) can interconnect with each other using a short-range wireless connection. • The wireless connection is established using a low-power radio link among the devices. • The primary benefit of this technology is the elimination of proprietary cables which are currently required to connect devices for information synchronization. • Examples: LAN connection, email downloading, Automatic house. 99-0767, ZLE Strategy summary

3. 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 625s) 99-0767, ZLE Strategy summary

4. 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. 99-0767, ZLE Strategy summary

5. Project 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. 99-0767, ZLE Strategy summary

6. 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. • 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. 99-0767, ZLE Strategy summary

7. Our Implementation – General (cont.) • Acknowledge is needed for every packet transmissionsand 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. 99-0767, ZLE Strategy summary

8. Our Implementation – General (cont.) 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. 99-0767, ZLE Strategy summary

9. High Level Design – Classes Relations Slave Master BT_scheduler Inherited BT_unitFunc N 1 BT_userInterface BT_unitFuncManager BTudpConnection BT_send BT_recv BT_requestsCache BT_responsesCache 99-0767, ZLE Strategy summary

10. High Level Design – Main Classes Description BTsend • 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 99-0767, ZLE Strategy summary

11. High Level Design – Main Classes Description BTrecv • 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). 99-0767, ZLE Strategy summary

12. High Level Design – Main Classes Description BTrecv – Cont. • No ? forward to BTunitFuncManager to calculate the response. • Contains inner-class: BTreceiver – actual network access 99-0767, ZLE Strategy summary

13. High Level Design – Main Classes Description BTunitFuncManager • 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. 99-0767, ZLE Strategy summary

14. High Level Design – Main Classes Description BTunitFunctionality • 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. 99-0767, ZLE Strategy summary

15. High Level Design – Main Classes Description BTunitMasterFunc & BTunitSlaveFunc • 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. 99-0767, ZLE Strategy summary

16. High Level Design – Main Classes Description BTscheduler • 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. 99-0767, ZLE Strategy summary

17. High Level Design – Main Classes Description BTuserInterface • 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. 99-0767, ZLE Strategy summary

18. Requests 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. 99-0767, ZLE Strategy summary

19. Request  Response Flow On the executing master: • The BTscheduler or BTuserInterface parse a user command, from the input file of command prompt, and pass it to a BtunitFuncManager‘s function. • BtunitFuncManager sees if master is defined for this unit, and if yes pass it to a BTunitMasterFunc’s function. • 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. 99-0767, ZLE Strategy summary

20. Request  Response Flow (cont.) On the receiver slave: • BTudpConnection receives the request and pass it to a BtunitFuncManager‘s function. • 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. • 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. 99-0767, ZLE Strategy summary

21. Request  Response Flow (cont.) On the executing master: • BTudpConnection receives the response and pass it to a BtunitFuncManager‘s function • BtunitFuncManager sees if master is defined for this unit, and if yes pass it to the BTunitMasterFunc’s function. • 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. 99-0767, ZLE Strategy summary

22. Implemented Types of Requests and Responses • 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. 99-0767, ZLE Strategy summary

23. Implemented Types of Requests and Responses – 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. 99-0767, ZLE Strategy summary

24. Implemented 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. 99-0767, ZLE Strategy summary

25. Implemented Request Polling – Timing & Policy • Choose the next slave to poll. This slave is chosen from the slaves that are connected to the piconet of that master. • 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. • 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. • 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. 99-0767, ZLE Strategy summary

26. Threads Flows • BTscheduler – main thread • The main thread of the application. • Schedules events that were defined in the input file. • It’s main flow: • Parse the parameters of the execution command. • Initiate threads: BTrecv andBTuserInterface (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 execute the command • Run forever 99-0767, ZLE Strategy summary

27. Threads Flows – cont. • BTuserInterface • 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. 99-0767, ZLE Strategy summary

28. Threads Flows – cont. • BTrecv • runs forever while waiting for packets from network • 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. 99-0767, ZLE Strategy summary

29. Synchronization Mechanism • Generally - Prevent simultaneous access to data structures, by two different threads. • Synchronize between execution of two commands: • Both, the scheduler and User-If threads use the synchronized ‘executeCommand’ function of BTscheduler to execute a single command. • Synchronize between receiving requests or responses to changing the unit functionality. • Scheduler thread (or User-If thread) may add/remove functionalities, and the receiver (BTrecv) thread uses those functionalities to handle the coming requests or response. 99-0767, ZLE Strategy summary

30. Synchronization Mechanism –cont. • Synchronize between sending a request and receiving its corresponding response • Synchronize between sending a request, and receiving and handling the corresponding response. • Uses a “wait” and “notifyAll” mechanism of Java. • Promises that the receiving thread will handle the received response only after its corresponding request was sent by the other thread. • Promises that handling response that was received for one request will not interrupt sending another request. 99-0767, ZLE Strategy summary

31. Synchronization Mechanism – cont. • Synchronization on the slave’s cache of responses to be sent: • Both, the Scheduler (or User-If thread) and the receiver (BTreacv) access the responses-To-Be-Sent cache. 99-0767, ZLE Strategy summary

32. Low level networking protocol 99-0767, ZLE Strategy summary

33. Low level networking protocol – cont. • The data field for response (“rsp”) is constructed out of two main components: • The packet’s sequence number of the appropriate request. • The response data itself. • Example for response packet: rspenud-klugman/213.8.199.94,973981016120,:1enud klugman/213.8.199.94,973981026720,:2 rsp_status_succe • White color– Packet type. • Green color– Packets sequence number. • Yellow color – the data field 99-0767, ZLE Strategy summary

34. Caching Usage • Requests Cache • Upon receiving a request • If the key exists in the cache – immediate response • If not – forward the request to the unit-functionality-manager • Upon sending a NEW response, It is added (with it’s corresponding request) to the requests cache. 99-0767, ZLE Strategy summary

35. Caching Usage – cont. • Responses Cache • 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 !!! 99-0767, ZLE Strategy summary

36. Using 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. 99-0767, ZLE Strategy summary

37. MASTER Polling Massage from Slave #1 SLAVE 1 SLAVE 1 Forward massage Using The Simulator – cont. • High level protocols (routing) should be written using those instruction. • For example, we’ve implemented the forward high-level command: 99-0767, ZLE Strategy summary

38. 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 99-0767, ZLE Strategy summary

39. 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 the new process in a separate window 99-0767, ZLE Strategy summary

40. 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 Executing the new process (BT Unit) 99-0767, ZLE Strategy summary

41. 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 Path to the input file (-f flag) 99-0767, ZLE Strategy summary

42. 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 • Use IP of current machine (-a flag). • “df” – default IP • “lb” – loop back IP 99-0767, ZLE Strategy summary

43. 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 Port Number of this unit (-p flag) 99-0767, ZLE Strategy summary

44. 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 Optional: The number of duplicated sending to the network out of 10 attempts (-d flag) 99-0767, ZLE Strategy summary

45. 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 Optional: The number of successfully sending to the network out of 10 attempts (-s flag) 99-0767, ZLE Strategy summary

46. 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 Using the User Interface (-i flag) 99-0767, ZLE Strategy summary

47. Master Slave2 Slave1 Using The Simulator – cont. • Input File – Simple Example (NT): MASTER 2 management add_master 4 request 127.0.0.10 20030 req_connect 5 request 127.0.0.20 20040 req_connect Slave 1 1 management add_slave 127.0.0.5 20000 Slave 2 1 management add_slave 127.0.0.5 20000 Will result at time 5: 99-0767, ZLE Strategy summary

48. U2 1 U1 2 U3 3 4 U4 U5 4 1 3 U6 2 U8 U7 Using The Simulator – cont. • Input File – Complex Example (NT): MASTER U1 2 management add_master 15 request 132.68.48.67 20002 req_connect 30 request 132.68.48.67 20003 req_connect 30 request 132.68.48.67 20004 req_connect 33 request 132.68.48.67 20005 req_connect 35 management print 60 request 255.255.255.255 0 req_polling 40 10 31 management print 104 request 255.255.255.255 0 req_polling 70 15 175 management print 180 request 132.68.48.67 20002 req_discont 180 request 132.68.48.67 20003 req_discont 180 request 132.68.48.67 20004 req_discont 180 request 132.68.48.67 20005 req_discont 99-0767, ZLE Strategy summary

49. U2 1 U1 2 U3 3 4 U4 U5 4 1 3 U6 2 U8 U7 Using The Simulator – cont. • Input File – Complex Example (NT): SLAVE U4 1 management add_slave 132.68.48.67 20001 1 management add_slave 132.68.48.67 20005 10 management print 50 management print 60 management print 70 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 99-0767, ZLE Strategy summary

50. THE END 99-0767, ZLE Strategy summary