Bluetooth on CE. Mid - Presentation Roman Zoltsman & Oren Haggai Group /2001 Instructor: Nir Borenshtein HSDSL Lab. Technion

© Oren Haggai, Roman Zoltsman 2000, Part A Goals Establish a well-designed HCI-Bluetooth driver on top of MS-CE; Since the HCI layer is the most important basis of Bluetooth. We will prove it by inquiring successfully for number of other Bluetooth devices at the vicinity of the CE HH computer, and report the user about the addresses, names and classes of those devices.

© Oren Haggai, Roman Zoltsman 2000, The HCI driver, with the inquire test bed can be a pre-connection step, and will be the start point for Part 2 of the Project. develop this driver for WIN-NT machine. later on, do the changes necessary, to fit the HCI driver on a CE-PC target machine. later on, do the changes necessary, to fit the HCI driver on a CE-PC target machine. support other small devices powered by MS-CE (palm-size pc, HH pc etc…). support other small devices powered by MS-CE (palm-size pc, HH pc etc…). Part A Goals & Design

© Oren Haggai, Roman Zoltsman 2000, What Was Done So Far ? Testing existing Bluetooth HW. Choosing the main HW for the project. Checking existing open source protocol stack implementation (axis stack) on Linux OS, written in C. Running this stack, with a debugger, and learn the stack capabilities and behavior with different kinds of Bluetooth HW. Running this stack, with a debugger, and learn the stack capabilities and behavior with different kinds of Bluetooth HW.

© Oren Haggai, Roman Zoltsman 2000, Compares Axis user mode vs. kernel mode (later discussed). Divide Axis stack into functional blocks, OS specific sections, and DB sections. Choose the sections to port to NT machine Design our lower stack – ORstack. Completion of the HCI driver for WIN-NT. Thorough testing and debugging the Driver for NT, by mean of data flow, correctness & performance, with a minimal C++ GUI. What Was Done So Far ?

© Oren Haggai, Roman Zoltsman 2000, Theoretic Background Bluetooth – 3 layers application model Usage models scenarios i.E. Headset, Synchronization, file transfer etc… Synchronization, file transfer etc… Profiles i.E. Ftp, serial port, LanAccessPoint, etc… Protocols i.E. L2cap, RFCOMM, SDP, TCS, etc…

© Oren Haggai, Roman Zoltsman 2000, Bluetooth – 3 layers Application A Serial Port Profile Example

© Oren Haggai, Roman Zoltsman 2000, The LMP and Baseband in our case study are implemented on HW, while all the rest of the protocols are implemented on SW. So we do need the HCI layer in order to communicate with those two protocols (Host to Host controller communication), and that communication is done over UART. Serial Port Profile cont.

© Oren Haggai, Roman Zoltsman 2000, Bluetooth–3 Layers Application Axis Case Study

© Oren Haggai, Roman Zoltsman 2000, Axis Case Study Currently only one profile is supported by axis: SPP SERIAL PORT PROFILE SERIAL PORT PROFILE Axis intentions are to support the LAP (LAN access point) and voice profiles also.

© Oren Haggai, Roman Zoltsman 2000, OR-stack – Our stack design

© Oren Haggai, Roman Zoltsman 2000, OR-stack – Inner Look OR-stack–top driver OR-stack-lower driver Simple GUI interface HCI command interface Static Server Responding Events: Address Name of device Class of device Service type Inquiry A user Request

© Oren Haggai, Roman Zoltsman 2000, Or-stack Cont. We chose to implement the stack in user mode because: 1) The driver will be easy to debug, at run time, and more easily to program, because in user mode we can access any function, at any layer. 2)The systems calls are much more simple to understand. 2)The systems calls are much more simple to understand.

© Oren Haggai, Roman Zoltsman 2000, Or-stack Cont. 3) our implementation can be easily stuffed into the kernel, after it’s correctness was proved. 4) we are not a commercial organization and not forced to performance optimizations and forced to performance optimizations and demands, and only interested at the technology. demands, and only interested at the technology. Adaptation to CE OS, and in the test modes. Adaptation to CE OS, and in the test modes. 5) developing a device driver at kernel mode is a lot of ‘black work. lot of ‘black work. 6) The user mode has a lot to offer, by means of various test modes. various test modes.

© Oren Haggai, Roman Zoltsman 2000, OR-stack the lower driver This part had to be totally change, because of OS specific code. An Undergoing work was done, to make this lower driver flexible as we can, so we can easily switch from NT to CE. Lower driver roles: opens & close the device. Does various Setup procedures. Handles the packets to be transmitted to the device.

© Oren Haggai, Roman Zoltsman 2000, OR-stack top driver The main roles of the top driver: Handle receiving packets, by calling HCI state machine. Make Bluetooth transparent to the end-user. The first role achieved with the help of a worker thread, that checks the UART for incoming packets (automatically), and keeps the HCI state machine busy, handling those packets.

© Oren Haggai, Roman Zoltsman 2000, HCI – Driver Implementation The HCI layer is almost complete interface to the HW, and supports the most important Baseband and LMP commands. This layer contains two main logical parts: 1) Dynamic Command Queue, to handle 1) Dynamic Command Queue, to handle outgoing packets. outgoing packets. 2) HCI parser state machine for the incoming 2) HCI parser state machine for the incoming packets. packets.

© Oren Haggai, Roman Zoltsman 2000, HCI send thread command queue Queue (Commands) Queue (Commands) Queue (Commands) Queue (Commands) Queue (Commands) Queue (Commands) Queue (Commands) Insert command (queued) send command (extract) For each command to send Is Queue Empty ? No The queue behavior: Send while the Bluetooth HW permits. Each permission/s comes inside The Bluetooth event. control Yes

© Oren Haggai, Roman Zoltsman 2000, For each received packet Is Event ? Handle data No YES Parse the event type - check for success No HCI read thread state machine Command statusCommand completeSpecial Update Command queue/ try send if possible Handle return parameters. Parse the command opcode

© Oren Haggai, Roman Zoltsman 2000, Left TODO – Part A The second transition to CE OS. CE-PC Target machine. Palm size PC – (MIPS). Any other platform. GUI Interface for the CE user Discover other nearby Bluetooth units. Find the names of those units. Trace the class of device & service providers.

© Oren Haggai, Roman Zoltsman 2000, Left TODO – Part B Adapt more layers to or-stack. L2capSDPRFCOMM Support the serial port profile. Prove a fully serial connection from a CE target machine to a static server (I.E. A LINUX machine, with axis stack).

© Oren Haggai, Roman Zoltsman 2000, FIN