1. comnet.technion.ac.il/~cn23s00 Computer Networks Laborator y Technion Israel Institute of Technology BlueTooth High-Level Simulator A Base Platform For Simulating Packets Routing Algorithms Over A Bluetooth Scatternet Students: Ehud Klugmanklugman@internet-zahav.net Eitan Perieitanp@barak-online.net Instructor : Ran Cohen

2. BlueTooth High Level Simulator 299-0767, ZLE Strategy summary 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.

3. BlueTooth High Level Simulator 399-0767, ZLE Strategy summary 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)

4. BlueTooth High Level Simulator 499-0767, ZLE Strategy summary 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.

5. BlueTooth High Level Simulator 599-0767, ZLE Strategy summary 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.

6. BlueTooth High Level Simulator 699-0767, ZLE Strategy summary 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.

7. BlueTooth High Level Simulator 799-0767, ZLE Strategy summary   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.)

8. BlueTooth High Level Simulator 899-0767, ZLE Strategy summary 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.)

9. BlueTooth High Level Simulator 999-0767, ZLE Strategy summary High Level Design – Classes Relations BT_send BT_requestsCache BT_recv BTudpConnection BT_responsesCache BT_unitFuncManager BT_unitFunc 1 N SlaveMaster Inherited BT_scheduler BT_userInterface

10. BlueTooth High Level Simulator 1099-0767, ZLE Strategy summary High 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

11. BlueTooth High Level Simulator 1199-0767, ZLE Strategy summary High Level Design – Main Classes Description   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

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

13. BlueTooth High Level Simulator 1399-0767, ZLE Strategy summary High Level Design – Main Classes Description   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

14. BlueTooth High Level Simulator 1499-0767, ZLE Strategy summary High Level Design – Main Classes Description   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

15. BlueTooth High Level Simulator 1599-0767, ZLE Strategy summary High Level Design – Main Classes Description   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

16. BlueTooth High Level Simulator 1699-0767, ZLE Strategy summary High Level Design – Main Classes Description   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

17. BlueTooth High Level Simulator 1799-0767, ZLE Strategy summary High Level Design – Main Classes Description   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

18. BlueTooth High Level Simulator 1899-0767, ZLE Strategy summary 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.

19. BlueTooth High Level Simulator 1999-0767, ZLE Strategy summary Request  Response Flow On 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.

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

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

22. BlueTooth High Level Simulator 2299-0767, ZLE Strategy summary 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.

23. BlueTooth High Level Simulator 2399-0767, ZLE Strategy summary 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.

24. BlueTooth High Level Simulator 2499-0767, ZLE Strategy summary 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.

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

26. BlueTooth High Level Simulator 2699-0767, ZLE Strategy summary Threads Flows  BTscheduler – 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 execute the command Run forever Run forever

27. BlueTooth High Level Simulator 2799-0767, ZLE Strategy summary 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.

28. BlueTooth High Level Simulator 2899-0767, ZLE Strategy summary Threads Flows – cont.  BTrecv runs forever while waiting for packets from network runs 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. –-manager. –If NO: forward the packet to unit-functionality-manager.

29. BlueTooth High Level Simulator 2999-0767, ZLE Strategy summary 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. 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. 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.

30. BlueTooth High Level Simulator 3099-0767, ZLE Strategy summary 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. Synchronize between sending a request, and receiving and 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 response only after its corresponding request was sent by the other thread. 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. Promises that handling response that was received for one request will not interrupt sending another request.

31. BlueTooth High Level Simulator 3199-0767, ZLE Strategy summary 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. Both, the Scheduler (or User-If thread) and the receiver (BTreacv) access the responses-To-Be-Sent cache.

32. BlueTooth High Level Simulator 3299-0767, ZLE Strategy summary Low level networking protocol HEADERDATA Field Name Packet TypePacket’s Sequence Number SeparatorData Field Size [char] 3Not limited 1 Possible Values “req” for request “rsp” for response -Space character -

33. BlueTooth High Level Simulator 3399-0767, ZLE Strategy summary Low level networking protocol – cont.  The data field for response (“rsp”) is constructed out of two main components: 1. The packet’s sequence number of the appropriate request. 2. The response data itself.  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

34. BlueTooth High Level Simulator 3499-0767, ZLE Strategy summary Caching Usage  Requests Cache KEYValue Sender IP Addr.Sender Port No.Seq. Num. Of received packet Corresponding response  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.

35. BlueTooth High Level Simulator 3599-0767, ZLE Strategy summary Caching Usage – cont.  Responses Cache KEYValue Sender IP AddrSender 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 !!!

36. BlueTooth High Level Simulator 3699-0767, ZLE Strategy summary 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.

37. BlueTooth High Level Simulator 3799-0767, ZLE Strategy summary 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 Polling Forward massage Massage from Slave #1

38. BlueTooth High Level Simulator 3899-0767, ZLE Strategy summary 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

39. BlueTooth High Level Simulator 3999-0767, ZLE Strategy summary 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

40. BlueTooth High Level Simulator 4099-0767, ZLE Strategy summary 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)

41. BlueTooth High Level Simulator 4199-0767, ZLE Strategy summary 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)

42. BlueTooth High Level Simulator 4299-0767, ZLE Strategy summary 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

43. BlueTooth High Level Simulator 4399-0767, ZLE Strategy summary 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)

44. BlueTooth High Level Simulator 4499-0767, ZLE Strategy summary 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)

45. BlueTooth High Level Simulator 4599-0767, ZLE Strategy summary 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)

46. BlueTooth High Level Simulator 4699-0767, ZLE Strategy summary 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)

47. BlueTooth High Level Simulator 4799-0767, ZLE Strategy summary 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: Master Slave2Slave1

48. BlueTooth High Level Simulator 4899-0767, ZLE Strategy summary 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 U1 U4 U5 U2 U3 U8 U7 U6 1 2 3 4 3 2 1 4

49. BlueTooth High Level Simulator 4999-0767, ZLE Strategy summary 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 U1 U4 U5 U2 U3 U8 U7 U6 1 2 3 4 3 2 1 4

50. BlueTooth High Level Simulator 5099-0767, ZLE Strategy summary