Technion Israel Institute of Technology Blue Tooth High-Level

Technion Israel Institute of Technology Blue. Tooth High-Level Simulator A Base Platform For Simulating Packets Routing Algorithms Over A Bluetooth Scatternet Computer Networks Laborator y Students: Ehud Klugman [email protected] net Eitan Peri [email protected] net comnet. technion. ac. il/~cn 23 s 00

What Is Bluetooth ? u u u 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. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 2

Piconet u u u A “mini-network” using radio freq’ (no cables) Consist out of: l One master unit. l One to seven slaves units. Slaves communicate only with the master unit. Small coverage due to low powered high freq’ (2. 45 GHz). Using 1 Mhz freq’-hop/timedivision-duplex (each time slot 625 s) Blue. Tooth High Level 99 -0767, ZLE Strategy summary 3

Scatternet u u 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. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 4

Project Objectives Base platform for simulating routing algorithms over a scatternet. u The functionalities (master, slave) of each unit, and it’s behavior (executing requests/responses) can be define by one or more of the following: u l l 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. u Supporting run-time tracing over units’ functionalities and behavior, and connectivity to the scatternet. u Blue. Tooth High Level 99 -0767, ZLE Strategy summary 5

Our Implementation - General u Language: Java. l l u Each unit is represented by a separate process. l l l u Code can run on any platform. Ready classes for networking and threads. 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: l l l UDP is best for simulation radio transmissions. Units can run on different machines. Packets loss is simulated in application level. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 6

Our Implementation – General (cont. ) u u Acknowledge is needed for every packet transmissions and is implemented in application level. Packets enumerating is used to distinguish packets: l l 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. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 7

Our Implementation – General (cont. ) Running the simulation can be done through script or batch file: l l u 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: l l 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. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 8

High Level Design – Classes Relations Slave Master Inherited BT_scheduler BT_unit. Func N 1 BT_user. Interface BT_unit. Func. Manager BTudp. Connection BT_requests. Cache BT_send BT_recv BT_responses. Cache Blue. Tooth High Level 99 -0767, ZLE Strategy summary 9

High Level Design – Main Classes Description BTsend Simulates the transmitting unit of the device. u Sends UDP packets to other devices. u Appropriate header is added before packet is sent: u Request header l Response header l Before sending response to network, it is added to the Requests cache. u Contains inner-class: BTsender – actual network access u Blue. Tooth High Level 99 -0767, ZLE Strategy summary 10

High Level Design – Main Classes Description BTrecv Simulates the receiving unit of the device. u Receive UDP packets u Header analysis: u l Response: check if already exists in responses cache. – – l Yes? Ignore packet. No ? Add to responses cache and forward to BTunit. Func. Manager 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). Blue. Tooth High Level 99 -0767, ZLE Strategy summary 11

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

High Level Design – Main Classes Description BTunit. Func. Manager u Handles the management of the different functionalities that a unit can have, on different piconets: l l u 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: l l 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. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 13

High Level Design – Main Classes Description BTunit. Functionality Holds all the common attributes (variable) and behavior (methods) to a master and slave functionalities: u Common Attributes: u Mac. Address (combination of IP address and port number). l Local ID in the piconet & more. l u Common behavior: Parsing a request type. l Parsing response type. l Handing functions for all the supported types of requests and response. l Blue. Tooth High Level 99 -0767, ZLE Strategy summary 14

High Level Design – Main Classes Description BTunit. Master. Func & BTunit. Slave. Func Handle all the attributes and behavior of a master or slave functionality. u As so, include the main code regarding executing BT requests and response. u As master: Executing all the supported types of requests, and handle all types of incoming responses. u As slave: Executing all the supported types of responses, and handle all types of incoming requests. u In the future, the different routing algorithms should be add/implemented mainly to those classes. u Blue. Tooth High Level 99 -0767, ZLE Strategy summary 15

High Level Design – Main Classes Description BTscheduler Implements the scheduler, which is the main flow (thread) and entry point of the project. u It responsible to create all the other classes (BTunit. Func. Manager, BTudp. Connection, BTuser. Interface etc. ). u 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. u Executing the command is done by calling the different functions of BTunit. Func. Manager. u Blue. Tooth High Level 99 -0767, ZLE Strategy summary 16

High Level Design – Main Classes Description BTuser. Interface Responsible to implement the user interface of the project. u Read user commands from the command prompt, and execute those command right away. u Executing those commands is done by using the BTscheduler parsing functions. u Blue. Tooth High Level 99 -0767, ZLE Strategy summary 17

Requests and Responses are the basic packets types that are transferred between the master and it’s slaves. u Requests - Issued by the master and sent to a single slave in this master’s piconet, or to all slaves in this piconet (broadcast). u 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. u Blue. Tooth High Level 99 -0767, ZLE Strategy summary 18

Request Response Flow On the executing master: 1. The BTscheduler or BTuser. Interface parse a user command, from the input file of command prompt, and pass it to a Btunit. Func. Manager‘s function. 2. Btunit. Func. Manager sees if master is defined for this unit, and if yes pass it to a BTunit. Master. Func’s function. 3. BTunit. Master. Func 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 BTudp. Connection. Waits for a response using Java’s “wait” method. u u Blue. Tooth High Level 99 -0767, ZLE Strategy summary 19

Request Response Flow (cont. ) On the receiver slave: 1. BTudp. Connection receives the request and pass it to a Btunit. Func. Manager‘s function. 2. Btunit. Func. Manager 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 BTunit. Slave. Func. 3. BTunit. Slave. Func 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 BTudp. Connection. u u u Blue. Tooth High Level 99 -0767, ZLE Strategy summary 20

Request Response Flow (cont. ) On the executing master: 1. 2. 3. BTudp. Connection receives the response and pass it to a Btunit. Func. Manager‘s function Btunit. Func. Manager sees if master is defined for this unit, and if yes pass it to the BTunit. Master. Func’s function. BTunit. Master. Func do: Sees if this is the response to the pending request (to which it waits for a response). If no – ignore, if yescontinue. 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. u u u ü The master waits only limited time for a response. It it is expired it declares a timeout. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 21

Implemented Types of Requests and Responses u Connect Request l u 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. l The ID number of the slave is returned to the “free ID pool”, so it can later be assigned to other slave. l Blue. Tooth High Level 99 -0767, ZLE Strategy summary 22

Implemented Types of Requests and Responses – cont. u Payload Request Master transfers a payload data to the slave. l Currently, the slaves only prints this payload, but it can be changed for any simulation purpose. l u Forward response Sent by a slave to its master after latter sends polling request. l It is used when the slave wants to forward a request to another slave in the same piconet. l Demonstrates a possible implementation of high-level protocol command. l Blue. Tooth High Level 99 -0767, ZLE Strategy summary 23

Implemented Request Polling - General u Purpose - Give the salves the option to promote a transaction. u Polling can last for a limited time or “forever”. u General flow: l Master sends polling requests to its slaves once in a while. l Each slave response one of the following : – – – No 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 Blue. Tooth High Level has more responses afterwards. 99 -0767, ZLE Strategy summary 24 to this slave if it •

Implemented Request Polling – Timing & Policy 1. 2. 3. 4. 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 responsel l l 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. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 25

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

Threads Flows – cont. u BTuser. Interface runs only if the user has chosen to activate the user interface option. l It is started by the main thread, just after it finish parsing the execution command. l Its main flow: l – – Wait for a command from STDIN (from the user). Parse the command 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. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 27

Threads Flows – cont. u BTrecv runs forever while waiting for packets from network l Its main flow: l – – – 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. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 28

Synchronization Mechanism ØGenerally - Prevent simultaneous access to data structures, by two different threads. u Synchronize between execution of two commands: l u Both, the scheduler and User-If threads use the synchronized ‘execute. Command’ function of BTscheduler to execute a single command. Synchronize between receiving requests or responses to changing the unit functionality. l 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. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 29

Synchronization Mechanism –cont. u Synchronize between sending a request and receiving its corresponding response l l Synchronize between sending a request, and receiving and handling the corresponding response. Uses a “wait” and “notify. All” 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. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 30

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

Low level networking protocol HEADER Field Name Packet Type Packet’s Sequence Number Separator Data 3 Not limited 1 Not limited “req” for request “rsp” for response - Space character - Field Size [char] Possible Values DATA Blue. Tooth High Level 99 -0767, ZLE Strategy summary 32

Low level networking protocol – cont. u The data field for response (“rsp”) is constructed out of two main components: 1. 2. u The packet’s sequence number of the appropriate request. 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 l l l White color Green color Yellow color Blue. Tooth High Level – Packet type. – Packets sequence number. – the data field 99 -0767, ZLE Strategy summary 33

Caching Usage u Requests Cache KEY Sender IP Addr. u Sender Port No. Value Seq. Num. Of received packet Corresponding response Upon receiving a request If the key exists in the cache – immediate response l If not – forward the request to the unit-functionalitymanager l u Upon sending a NEW response, It is added (with it’s corresponding request) to the requests cache. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 34

Caching Usage – cont. u Responses Cache KEY Sender IP Addr u Sender Port No. Value Seq. Num. Of received packet --- Upon receiving a response If the key exists in the cache – ignore packet l If not – forward the request to the unit-functionalitymanager l The unit manager should deal with each request only once !!! Blue. Tooth High Level 99 -0767, ZLE Strategy summary 35

Using The Simulator u One Top Script which execute all processes (BT units) l u 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. l 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. Blue. Tooth High Level 99 -0767, ZLE Strategy summary 36

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

Using The Simulator – cont. u Script File – Example (NT): start /separate c: jdk 1. 2. 2binjava Btscheduler -fteststest 4_m. txt -adf -p 20000 -d 5 –s 5 -i Execute a new process and continue immediately to the next line of the script Blue. Tooth High Level 99 -0767, ZLE Strategy summary 38

Using The Simulator – cont. u Script File – Example (NT): start /separate c: jdk 1. 2. 2binjava Btscheduler -fteststest 4_m. txt -adf -p 20000 -d 5 –s 5 -i Execute the new process in a separate window Blue. Tooth High Level 99 -0767, ZLE Strategy summary 39

Using The Simulator – cont. u Script File – Example (NT): start /separate c: jdk 1. 2. 2binjava BTscheduler -fteststest 4_m. txt -adf -p 20000 -d 5 –s 5 -i Executing the new process (BT Unit) Blue. Tooth High Level 99 -0767, ZLE Strategy summary 40

Using The Simulator – cont. u Script File – Example (NT): start /separate c: jdk 1. 2. 2binjava BTscheduler -fteststest 4_m. txt -adf -p 20000 -d 5 –s 5 -i Path to the input file (-f flag) Blue. Tooth High Level 99 -0767, ZLE Strategy summary 41

Using The Simulator – cont. u Script File – Example (NT): start /separate c: jdk 1. 2. 2binjava BTscheduler -fteststest 4_m. txt -adf -p 20000 -d 5 –s 5 -i Use IP of current machine (-a flag). “df” – default IP “lb” – loop back IP Blue. Tooth High Level 99 -0767, ZLE Strategy summary 42

Using The Simulator – cont. u Script File – Example (NT): start /separate c: jdk 1. 2. 2binjava BTscheduler -fteststest 4_m. txt -adf -p 20000 -d 5 –s 5 -i Port Number of this unit (-p flag) Blue. Tooth High Level 99 -0767, ZLE Strategy summary 43

Using The Simulator – cont. u Script File – Example (NT): start /separate c: jdk 1. 2. 2binjava BTscheduler -fteststest 4_m. txt -adf -p 20000 -d 5 –s 5 -i Optional: The number of duplicated sending to the network out of 10 attempts (-d flag) Blue. Tooth High Level 99 -0767, ZLE Strategy summary 44

Using The Simulator – cont. u Script File – Example (NT): start /separate c: jdk 1. 2. 2binjava BTscheduler -fteststest 4_m. txt -adf -p 20000 -d 5 –s 5 -i Optional: The number of successfully sending to the network out of 10 attempts (-s flag) Blue. Tooth High Level 99 -0767, ZLE Strategy summary 45

Using The Simulator – cont. u Script File – Example (NT): start /separate c: jdk 1. 2. 2binjava BTscheduler -fteststest 4_m. txt -adf -p 20000 -d 5 –s 5 -i Using the User Interface (-i flag) Blue. Tooth High Level 99 -0767, ZLE Strategy summary 46

Using The Simulator – cont. u 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 Slave 2 Blue. Tooth High Level Slave 1 99 -0767, ZLE Strategy summary 47

Using The Simulator – cont. u Input File – Complex Example (NT): MASTER U 1 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 U 3 33 request 132. 68. 48. 67 20005 req_connect 35 management print 60 request 255 0 req_polling 40 10 31 management print 104 request 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 Blue. Tooth High Level U 2 1 2 U 1 3 4 U 4 99 -0767, ZLE Strategy summary U 5 4 1 3 2 U 8 U 6 U 7 48

Using The Simulator – cont. u Input File – Complex Example (NT): SLAVE U 4 1 management add_slave 132. 68. 48. 67 20001 1 management add_slave 132. 68. 48. 67 20005 10 management print 50 management print U 3 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 Blue. Tooth High Level U 2 1 2 U 1 3 4 U 4 99 -0767, ZLE Strategy summary U 5 4 1 3 2 U 8 U 6 U 7 49

Blue. Tooth High Level 99 -0767, ZLE Strategy summary 50