Embed Size (px)
Citation preview
Master Thesis
Bluetooth API for JOP- Implementation of the Java Specification Request 82
Author:Kasper Hansen
[email protected]. 290482-XXXX
Supervisors:Rasmus U. Pedersen
Martin Schoeberl
Copenhagen Business School
February 10, 2007
Executive Summary
This report covers the implementation of a Java Bluetooth Application Programming Inter-face (API). The API makes it possible for the Java Optimized Processor (JOP), an embeddedreal time system, to communicate wireless with remote devices e.g. mobile phones.
The project is open source under the General Public License (GPL). The project website,http://blueonjop.sourceforge.net, provides documentation for usage of the API, and descrip-tion to download the source code of the API.
The implementation of the API conforms to the Java Specification Request 82 (JSR-82).The specification is developed through the Java Community Process (JPC), where a groupof experts are evolving the Java technology. This adds value to the API developed, sincethere will be APIs for other platforms also conforming to this specification. Code will beable to be ported from platform to platform, since the JSR-82 secures the compatibility.
Developers will find it easier to develop Bluetooth applications on JOP. They will be ableto use the API classes they know of. Furthermore, they will be able to reuse code writtenfor another platform. All in all, the API provides a rapidly and error prone development ofBluetooth/embedded system.
Since the API is open source the costs of deploying systems are reduced. The API is free,and costs only concerns the hardware. Besides JOP, a Bluetooth Intelligent Serial Moduleis used. With these components, and the API you are set for developing ground breakingapplications.
1
Contents
1 Introduction 12
1.1 Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.1 Work Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.1 Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Bluetooth Technology 16
2.1 Radio Waves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1 Radio Wave Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.2 Radio Wave Transmission . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.3 Radio Wave Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.4 Radio Wave Propagation Model . . . . . . . . . . . . . . . . . . . . . 22
2.2 Transmission Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1 SCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.2 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Time Division Duplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Bluetooth Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Bluetooth Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.1 Bluetooth Device Address (BD ADDR) . . . . . . . . . . . . . . . . . 28
2.5.2 Active Member Address (AM ADDR) . . . . . . . . . . . . . . . . . 28
2.5.3 Parked Member Address (PM ADDR) . . . . . . . . . . . . . . . . . 28
2.5.4 Active Request Address (AR ADDR) . . . . . . . . . . . . . . . . . . 28
2
2.5.5 Bluetooth Device Name . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6 Spread Spectrum Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . 29
2.7 Piconet and Scatternet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8 Power Consumption Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8.1 Hold Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8.2 Sniff Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.8.3 Park Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.9 Bluetooth Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.9.1 Stack Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.10 Summery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 Bluetooth Security 34
3.0.1 Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.0.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.1 Bluejacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1.2 Implementation Weaknesses . . . . . . . . . . . . . . . . . . . . . . . 37
3.1.3 BlueBug (HeloMoto) . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1.4 BlueSnarf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.5 BlueSmack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.6 BlueBump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.7 BlueDump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.8 BlueChop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.9 Car Whisperer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.10 Battery Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.11 Attacker Opportunities . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.1.12 Hiding Equipment (BlueBag) . . . . . . . . . . . . . . . . . . . . . . 40
3.1.13 Long Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2 Antivirus Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3
4 Ongoing Research 43
4.1 Received Signal Strength Indicator (RSSI) . . . . . . . . . . . . . . . . . . . 43
4.1.1 Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Bit Error Rate (BER)/ Link Quality (LQ) . . . . . . . . . . . . . . . . . . . 47
4.3 Inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1 IrDA Supported Connection Establishment . . . . . . . . . . . . . . . 48
4.3.2 Inquiry Simplification . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 Device ID with Blueprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.1 Device ID an alternative . . . . . . . . . . . . . . . . . . . . . . . . . 52
5 Bluetooth Intelligent Serial Module 54
5.1 AT Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.1 Configuration (ATSn) . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1.2 Information (ATIn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1.3 Inquiry (AT+BTI(N)) . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.4 Service Discovery (AT+BTVbd addr,uuid) . . . . . . . . . . . . . . . . 57
5.1.5 Connect (ATDbd addr,uuid) . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.6 Send (ATX’’Hello World’’) . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.7 Data Mode (ATO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.8 Escape Sequence (^^^) . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.1.9 Disconnect (ATH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.1.10 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Algorithm for reading BISM reply . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3 Summery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6 Java Bluetooth 61
6.1 JOP and Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1.1 How is JOP different . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1.2 Bluetooth API for JOP . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.1.3 Object Exchange Protocol (OBEX) . . . . . . . . . . . . . . . . . . . 63
4
6.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3 Implementation of the Bluetooth Classes . . . . . . . . . . . . . . . . . . . . 66
6.3.1 Implementation of the OBEX classes . . . . . . . . . . . . . . . . . . 71
6.4 GAP Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.4.1 Note 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.4.2 Note 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.4.3 Note 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4.4 Note 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4.5 Note 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.4.6 Note 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.4.7 Note 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5 Debugging made difficult . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.6 Sourceforge.net Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.7 Summery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7 Test of the API 80
7.1 Device Discovery Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.1.1 No devices in range . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.1.2 Devices in range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.2 Service Search Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.2.1 Device not reachable . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.2.2 UUID list with not supported service . . . . . . . . . . . . . . . . . . 82
7.3 Connection and OBEX Push Profile . . . . . . . . . . . . . . . . . . . . . . . 82
7.3.1 Bluetooth Connect/Disconnect, OBEX Push . . . . . . . . . . . . . . 82
7.3.2 Connect To Device Out Of Range . . . . . . . . . . . . . . . . . . . . 83
7.3.3 Push File To Device Out Range (prior in range) . . . . . . . . . . . . 84
7.3.4 File not accepted by user . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.3.5 Too long OBEX header . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8 Bluetooth and Marketing 86
5
8.1 Type of Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.1.1 Ski Centre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.1.2 Fiat Trade Show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.1.3 Mall Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.2 System Categorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.2.1 JOP/BISM Pair Support of Systems . . . . . . . . . . . . . . . . . . 90
8.3 Pros and Cons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.3.1 Pros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.3.2 Cons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.3.3 Cons in General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.4 Viral Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.5 Market Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.6 Marketing Law . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.6.1 How is permission achieved? . . . . . . . . . . . . . . . . . . . . . . . 95
8.6.2 Tracking The Consumer . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.6.3 Ethics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.7 Down-side risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.8 Summery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
9 Prototype Development 98
9.1 Data Flow Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
10 Conclusion 101
10.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
A Bluetooth API References 103
B Summery of meeting with law graduate, Anette Høyrup 104
C Blueprinting Example 106
6
D OBEX Over SPP Using AvetanaOBEX 108
E Hcidump 110
F Prototype Implementation 115
7
List of Tables
2.1 Radio Frequency Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Distance Power Loss Coefficient . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Calculation of Floor Penetration Loss Factor . . . . . . . . . . . . . . . . . . 23
4.1 BER/LQ Conversion Table[10] . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1 BISM Pros/Cons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.1 Java Bluetooth APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2 GAP Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
C.1 Blueprinting of Sony Ericsson K700i . . . . . . . . . . . . . . . . . . . . . . . 107
8
List of Figures
1.1 The Java Optimized Processor . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Development Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Radio Waves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Simple Radio Transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Pulse Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Amplitude Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Frequency Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Radio Wave Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Diffraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 Frequency Division Duplexing Guard Band Illustration (top)[21] . . . . . . . 25
2.9 TDD Schema[21] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.10 The Hop Definition on Single-slot Packets (top) and Multi-slot Packets (middleand bottom)[21] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.11 Bluetooth Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.12 Linked Piconets Forming a Scatternet[9] . . . . . . . . . . . . . . . . . . . . 30
2.13 Stack Protocol[20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Authentication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Attack Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 The Trolley Named BlueBag[14] . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Fresnel Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Golden Receive Power Range[4] . . . . . . . . . . . . . . . . . . . . . . . . . 43
9
4.2 a) Triangulation b) Maximum Likelihood Estimation c) Hyperbolic Tri-lateration[25] 45
4.3 a) Signal Strength Varies With Distance b) Signal Strength with InterveningWalls After Compensating By Use Of WAF[7] . . . . . . . . . . . . . . . . . 46
4.4 Database Tuple Example [22] . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1 Blu2i RS-232 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Components Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.1 OBEX Over SPP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2 OBEX Connect Packet Using ATX Command . . . . . . . . . . . . . . . . . . 64
6.3 Too Long OBEX Header Packet Using ATX Command . . . . . . . . . . . . . 65
6.4 Maximum OBEX Header Packet Using ATX Command . . . . . . . . . . . . 65
6.5 OBEX PUT Packet[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.6 blueonjop Website at Sourceforge.net . . . . . . . . . . . . . . . . . . . . . 79
7.1 No Devices In Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.2 Inquiry And Service Search Output . . . . . . . . . . . . . . . . . . . . . . . 82
7.3 Service Search Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.4 Bluetooth Connect/Disconnect, OBEX Push Output . . . . . . . . . . . . . 83
7.5 Connect To Device Out Of Range Output . . . . . . . . . . . . . . . . . . . 84
7.6 Push File To Device Out Of Range Output . . . . . . . . . . . . . . . . . . . 84
7.7 File Not Accepted By User Output . . . . . . . . . . . . . . . . . . . . . . . 85
7.8 Too Long OBEX Header Output . . . . . . . . . . . . . . . . . . . . . . . . 85
8.1 Mobile Services in Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.2 Graphic User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.3 Fiat Opt-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.4 The Gateway Mall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.5 Question 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.6 Question 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.1 Architectural Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10
9.2 Data Flow Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
11
Chapter 1
Introduction
Bluetooth is an evolving technology. More and more devices like mobile phones, PDAsetc. are being equipped with Bluetooth transmitters. Today one billion Bluetooth devicesare in the hands of the consumers1. Throughout the years Bluetooth has been diffused,and adopted by the users. A common use of the cable-replacement technology is the wire-less headset. However, Bluetooth is applied in many types of scenarios, such as wirelessfile transfer, calendar synchronization between PC and mobile devices, and Internet accesspoints. The combination of the diffusion and support of services, that Bluetooth bring opendoors for new types of information systems to be developed. This is the perspective of thismaster thesis.
Java has been the major programming language throughout my study. As of in the realworld me and my fellow students have been using Java for many types of programmingprojects. Java code is platform independent. It runs within the Java Virtual Machine (JVM)executing the byte code. This really is an advantage, since programmers doesn’t need toadjust the code to a specific device or platform. Since the fall semester 2005 I have beenworking with Java in context of embedded systems. The Java Optimized Processor (JOP)has made this possible, since a hardware implementation of the JVM executes the codethat have made up our systems. A group at Copenhagen Business School is founded un-der the name Embedded Software Lab (ESL). The lab is working on extending JOP in anykind of way. Different areas of research have been started e.g. voice recognition. The focusof these theses is different in technology, but share the context to JOP. Figure 1.1 shows JOP.
JSR-82 is a specification for Bluetooth programming in the Java language. An implemen-tation of the specification makes it possible for JOP to host Java code that make use ofBluetooth operations. This really is a compelling feature, and a Bluetooth Application Pro-gramming Interface (API) will make it very accessible to communicate with other Bluetoothdevices, in JOP context.
1Bluetooth Special Interest Group (SIG) press release 13. November 2006
12
Figure 1.1: The Java Optimized Processor
1.1 Research Question
With the introduction in mind, and conversations with my instructors, the following researchquestion forms this master thesis.
Is the Bluetooth technology suited for embedded systems, and how can the JSR-82 specifi-cation be implemented on the Java Optimized Processor (JOP)?
1.1.1 Work Questions
To support the work of answering the research question (section 1.1) work questions havebeen prepared. The work questions are in context of the research question and are sub tasksfor the project. The sub tasks will bring a structure to the project and ease the answeringof the research question, in the final conclusion.
� What is Bluetooth based upon?
� How does the Bluetooth stack work?
� How is Bluetooth suited for Embedded Systems?
� What hardware should be used to Bluetooth-enable JOP?
� How is the JSR-82 implemented on JOP?
� How is the javax.obex package (optional for JSR-82) implemented on JOP?
� How is the JOP implementation of JSR-82 applied?
13
� What kind of systems does the technology open doors for?
� How can business take advantage of the Bluetooth technology?
1.2 Methodology
This project is rather technical and have a practical approach. The project is built aroundthe selection of a hardware module to extend JOP, and develop the API for the Java interfacebetween JOP and Bluetooth module.
Since this project address the technical sides of Bluetooth, most information can be found inthe specification, providing sufficient information on the protocol. However the informationfound in the specification, I will supplement with information found in books, articles, andon the Internet.
Regarding the selection of Bluetooth hardware I will not be able to collect and evaluateevery hardware out there. Therefore I will put effort in finding a suitable hardware, butwith the main focus on the selected hardware, by testing it and implementing the API forit. So the focus will be more qualitative, rather than quantitative in the matter of hardwareevaluation. This might influence in the way that the right hardware isn’t selected from thestart. But the hardware in question is examined in depth, and knowledge is learned fromworking with the hardware in context of a Bluetooth API for JOP.
Regarding the development method for the API, I will take an agile approach to smoothenthe process. The specification/requirements are defined beforehand. The deployment andmaintenance are not really parts of this project, since the API is for use in other applications,and not deployed in the same manner. Of course you can predict that there will be founderrors and bugs in the API, that should be corrected. Since the project is open source, theerror correction etc. can be done by the developers using the API, and be submitted tobenefit the entire community. Figure 1.2 outline the development phases of this project. Thehatched boxes/phases are omitted.
Figure 1.2: Development Phases
14
Back is the design (part of it), the implementation, and test phase. There will be muchiteration between these phases, and they may be merged, since my beforehand knowledge ofBluetooth is very modest. Also my prior experience of working with JOP, have shown thatthe best way to go about is a prototyping approach. The approach have the key advantageof changes are easily met. This meets JOP development, since you run into challenges likememory consumption, and other limitations you wouldn’t normally need to address whendeveloping Java applications for e.g. a PC.
The fact that I’m the only developer on this project, influence the method. The produc-tion of design papers etc. might be overkill for one person. Instead the focus will be putin documentation of the code, and how to use it on JOP. I think this will result in a moreproductive project, and being more valuable for future developers.
To test the API I will run tests in a regular fashion, but also develop a prototype usingthe API, to prove the functioning of the API, but also provide an example for future devel-opers.
1.2.1 Boundaries
The boundary for this project is not to implement the server part of the JSR-82. The APIwill not be able to set up channels for remote devices to connect to. This boundary is set,due to the limits of this project. The project will focus on the implementation of the clientpart of the protocol. It will sufficient to evaluate the hardware to be integrated with JOP. Itwill not have any affect on the result of project, but it will leave further implementation tobe performed after the end of the project.
15
Chapter 2
Bluetooth Technology
Bluetooth is a short-range wireless technology. The development was started in 1994 byEricsson with the purpose of coming up with a wireless alternative to the cables that linkedmobile phones to headsets and such. The development group at Ericsson named the technol-ogy ”Bluetooth” after Harald ”Bluetooth” (real name Harald Gormsson), the Danish kingin the 10th century who united Denmark and Norway, while his name reflect the uniting ofotherwise isolated devices and systems. The name got stuck and that’s why Bluetooth is thename of the wireless technology.
Later, several other companies had their attention on the technology and in 1998 the Blue-tooth Special Interest Group (SIG) was formed. In 1999 the Bluetooth 1.0 specification wasreleased. The Bluetooth specification is open, so every one can make use of it. Ericsson sawthat this was the way for technology to become successful[21].
In order for companies and manufacturers to display the Bluetooth brand mark with theirproducts, they have to comply with the specification. SIG have set up a qualification programhandled by the Bluetooth Qualification Test Facility.
2.1 Radio Waves
Most wireless technologies are based on radio waves and so is Bluetooth. Technologies likeGPS and Wi-Fi also use radio waves to transmit signals. A radio wave is an electromagneticwave that can travel through air, liquid and solid objects. Figure 2.1 illustrates a radiowave. The wavelength is a measure for the distance covered by a complete wave cycle. Thenumber of cycles made in a second is know as the frequency, and is measured in Hertz (Hz).The frequency is 1 Hz if there is a full wave cycle once per second. 100Hz would measureto 100 cycles per second. The frequency and the wavelength are inversely proportional.The longer the wavelength, the lower the frequency, and the other way around. The height
16
Figure 2.1: Radio Waves
of a wave is known as the amplitude. The amplitude is a measure for the strength of the wave.
All radio waves conform to equation 2.1:
Speed of light = Frequency×Wavelength[23] (2.1)
It can then be determined that a radio wave travels 299,792 km/s (speed of light), and asmentioned above a change in frequency, or wavelength, will affect the other part inversely.Furthermore, radio frequency (RF) is defined to be in the range of 10kKz and 100GHz. Tocompare this range with other kind of waves (non-electromagnetic waves), a car vibratesaround 300 beats per second, and you are able to hear sound waves from 400 - 10,000 beatsper second. So the number of cycles made by a radio wave at 100GHz, that is 100 billioncycles per second, are very fast compared to the other kinds of vibrations in this example.
2.1.1 Radio Wave Creation
Any electric charge which accelerates produces electromagnetic radiation. The radiation isthe basics of a electromagnetic radio wave. By controlling the acceleration of the electriccharge, the wavelength of the radio wave that radiate from the charge is adjusted. The fasterthe acceleration, the shorter the wavelength. Equation 2.1 shows the relation between thewavelength, frequency, and speed of light. By controlling acceleration and hence the wave-length, indirectly you are also to control the frequency of the radiated wave, since the speedof light is a constant factor.
An example of a simple radio can be built by use of a coin (peace of metal) and a 9-voltbattery (power supply). By tapping the coin against the two terminals of the battery, theyare connected for an instance. The current flows through the coin and hence radio waves areradiated of the coin. By holding the coin and the battery near an AM-radio, you will hearsome noise in the radio when the coin and the battery are tapped against each other, sinceradio waves are sent out and receipted by the AM-radio. This is a simple radio transmitter.By tapping the coin you transmit data by means of a morse-like protocol. Figure 2.2 shows
17
the components of the simple radio1.
Figure 2.2: Simple Radio Transmitter
2.1.2 Radio Wave Transmission
There are three basic ways to transmit data using radio waves, based on the characteristicsof a radio wave (frequency and amplitude):
Pulse Modulation (PM) This way data is transferred by switching the radio signal on andoff. This kind of modulation would be category of the simple radio transmitter (coinand battery) described above.
Figure 2.3: Pulse Modulation
Amplitude Modulation (AM) Data is transferred by varying the amplitude (the height)of the waves. Different amplitude has different values. An AM Radio uses this method.
Frequency Modulation (FM) varies the frequency of the waves. Different frequencieshave different values. FM-radios, Televisions, and mobile phones uses FM modulation.Bluetooth also uses FM.
1Example from http://electronics.howstuffworks.com/radio2.htm
18
Figure 2.4: Amplitude Modulation
Figure 2.5: Frequency Modulation
Turning on and off the current rapidly will create radio waves. However a more sophisticatedway is used in modern communication. Changing the current in a e.g. wire, instead turningit in and off, will create a sine wave. For example fluctuating the current smoothly between10 volts and -10 volts. Hereby you are not only able to transmit using PM, but the othermodulation schemas will be possible.
Part of every radio transmission setup is the transmitter, mentioned above, but also a receiverneeds to be in place to process the signal. The receiver’s job is to listen for radio waves andconvert the electromagnetic waves into current. Information are extracted from the current.A receiver consists of an antenna, used to pick up radio waves. The tuners job is to separatethe sine waves picked up by the antenna. The tuner would be tuned only to extract radiowaves at a given frequency. The detector then extracts information (voice) from the radiowave, and sends it through an amplifier before going through the speakers (an AM-radioexample).
2.1.3 Radio Wave Behavior
Radio waves can have different types of behavior when coming in contact with objects. Thedifferent types of behavior are dependent on the type of object it gets in contact with. Shape,size, and material of objects are some of the factors that affect the behavior. Interferencecan be caused by obstacles like concrete walls, metal cabinets, or even raindrops. Generally,
19
transmissions made at higher frequencies are more subject to radio absorption (by the ob-stacles) and larger signal loss. Higher frequencies have smaller wavelengths; hence, signalswith smaller wavelengths tend to be absorbed by the obstacles that they collide with. Thiscauses high-frequency devices to have a shorter operating range [17].
Bluetooth operates at a higher level of frequency and hence has a lower transmit rangethan e.g. AM-radios. Table 2.1 list radio wave frequencies and example application2. Pleasenote that the wave length should not be mistaken by the range of transmission.
Band name Wave length Frequency Example usesExtremely low frequency 100,000km - 10,000km 3-30Hz Communication with submarines
Super low frequency 100,000km - 10,000km 30-300Hz Communication with submarines
Ultra low frequency 10,000km - 1000km 300-3000Hz Communication within mines
Very low frequency 1000km - 100km 3-30kHz Wireless heart rate monitors
Low frequency 10km - 1km 30-300kHz Navigation, AM longwave broadcasting
Medium frequency 1km - 100m 300-3000kHz AM (Medium-wave) broadcasts
High frequency 100m - 10m 3-30MHz Amateur radio
Very high frequency 10m - 1m 30-300MHz FM and television broadcasts
Ultra high frequency 1m - 100mm 300-3000MHz Television broadcasts, mobile phones, wireless LAN
Super high frequency 100mm - 10mm 3-30GHz Microwave devices, mobile phones (W-CDMA)
Extremely high frequency 10mm 1mm 30-300GHz Radio astronomy, high-speed microwave radio relay
Table 2.1: Radio Frequency Spectrum
When radio waves come in contact with objects, different types of behavior are possible.If a radio wave hits an object larger then the wavelength of the radio wave, the radio waveis reflected off surface of the object. Looking at table 2.1 you see that Bluetooth radio waveshave a wavelength of 1m to 10cm, since Bluetooth operates within the 2.4GHz band. Re-flection is likely to happen when a Bluetooth radio wave hits an object larger than 10cm inwidth or height. The angle that the wave hits the object is called ”the angle of incidence”,and ”the angle of reflection” of the wave is equal to ”the angle of incidence”. This is why asatellite has a dish around the receiver to reflect the waves toward the antenna.
Refraction is a behavior that occurs when a radio wave hits an object of higher densitythan its current medium. The radio wave then travels through the object, but in a differentangel of direction then it did before the collision with the object.
Another behavior is scattering. Like reflection, the wave is reflected of the object. In thecase of scattering the wave is reflected in multiple directions. Scattering can happen when aradio wave hits an object of irregular shape, with a rough surface area.
2http://en.wikipedia.org/wiki/Radio spectrum
20
A radio wave can also be absorbed. When a radio wave is absorbed into an object theradio is lost. As frequencies gets higher, absorption is more likely to occur, this is why highfrequency radio waves are useless for long-distance communication.
Figure 2.6: Radio Wave Behavior
Bluetooth has an advantage over IrDA. Data can be transferred between devices there areout of sight of each other. Figure 2.7 shows how it is possible for data to be transferredwithout line of sight operations. The radio wave is broken up and bends around the objectin it path. This behavior is called diffraction.
Figure 2.7: Diffraction
When embedding a system like JOP into bigger systems, like a refrigerator, you cannotalways depend on the design, of the overall system, makes it possible to implement the JOPhardware anywhere in the system e.g. it could be easier or even less expensive to put it somespecific place. So the embedded systems need to be flexible and not to depend on several
21
things that make the development or production expensive. Take the refrigerator for exam-ple. You want to build a more intelligent refrigerator, so you embed a system like JOP fordoing some job or service. If you need the embedded system to communicate wireless withthe surrounding environment through IrDA for example you would have to implement thehardware in the door of the refrigerator for easy access, and line of sight access. But it mightbe less expensive to place it elsewhere. Using Bluetooth brings more flexibility on where toplace hardware when embedding systems. This feature is very positive when designing anembedded system like JOP.
2.1.4 Radio Wave Propagation Model
The behavior of the Bluetooth technology and radio waves in general, makes the use ofthe technology widespread. But how is Bluetooth suited for embedded systems (and evenreal-time systems)? How will waves be affected when radio transmitter is built-in e.g. refrig-erators? These are questions that need to be investigated and analyzed.
In free space radio waves travel with the speed of light, and as it travels energy is lost.If the distance travelled is doubled the energy of the wave will be four times as weak. Thisis what is known as the ”inverse square law of electromagnetic propagation”[23]. Equation2.2 shows the factor by which defines the energy loss for travelling radio waves.
1
R2where radius R is the distance travelled (2.2)
However in practice the equation doesn’t provide a picture of how a radio signal is trans-mitted, since links between transmitters and receivers encounter different terrain, path, andobjects. As a result it’s not possible to formulate a single equation that describes the lossof energy fitting to all links here on earth. Instead empirical models are made in order topredict the likely behavior of the wave under certain conditions3.
Several models have been developed, each meant to estimate links with certain kinds ofcharacteristics. Overall the models can be grouped into the three:
� Indoor propagation attenuation
� Outdoor propagation attenuation
� Environmental effects
The two first in the list pretty much explain themselves, while the third hold a group ofmodel used for estimation of energy loss in rain, and other environmental effects.
3http://en.wikipedia.org/wiki/Radio propagation
22
An example of such a model for indoor attenuation, is ITU Model for Indoor Attenuation,named after the International Telecommunication Union (ITU). It’s suited for links in the900MHz -5.2GHz band4. The model is as follows:
L = 20 log f + N log d + Pf (n)− 28 (2.3)
Where L is the path loss in units of dB. f is the frequency. N the distance power loss co-efficient, which can be determined through table 2.2. d is the distance in meters. Pf is afunction with n, the number of floors between the transmitter and the receiver, as input.Table 2.3 shows example of Pf .
The propagation models are useful, and come in handy to estimate if a link is possibleat all before you set up expensive hardware or develop systems that end up not working inpractice. Since the models are empiric, they seek the most likely answer, but may not reflectthe energy loss in an actual case. However you are better suited for analysis with the models,then without.
Frequency Band Residential Area Office Area Commercial Area900 MHz N/A 33 201.2 GHz N/A 32 221.3 GHz N/A 32 221.8 GHz 28 30 224 GHz N/A 28 225.2 GHz N/A 31 N/A
Table 2.2: Distance Power Loss Coefficient
Frequency Band Number of Floors Residential Area Office Area Commercial Area900 MHz 1 N/A 9 N/A900 MHz 2 N/A 19 N/A900MHz 3 N/A 24 N/A1.8 GHz n 4n 15+4(n-1) 6 + 3(n-1)2.0 GHz n 4n 15+4(n-1) 6 + 3(n-1)5.2 GHz 1 N/A 16 N/A
Table 2.3: Calculation of Floor Penetration Loss Factor
4http://en.wikipedia.org/wiki/ITU Model for Indoor Attenuation
23
2.2 Transmission Types
On the basis, Bluetooth uses serial communication to transmit data. In a higher level Blue-tooth support two kinds of links between the master and slaves of a piconet. One link isconnection-oriented, and one connectionless. The connection-oriented link requires a sessionestablishment before data can be sent. Data must arrive the same order as sent. Connection-less on the other hand doesn’t require establishment of a session, and sender can just senddata to the receiver. The two types of links are in terms of Bluetooth called SynchronousConnection-Oriented (SCO) and Asynchronous Connectionless (ACL).
2.2.1 SCO
This type of link is used for time-bounded information, like voice. Since the data sent is time-sensitive, packets are never retransmitted. In the voice example, if retransmitting packet andplaying the retransmitted data would come out as noise, and ruin the voice even more.
2.2.2 ACL
The ACL link is used for data transfer. It provides a transport safe link, ensuring that lostor corrupt packets are retransmitted for data integrity. In the basics it can be compared withTCP/IP protocol.
2.3 Time Division Duplexing
Most communication systems require data to be sent in both directions. For example on theInternet a user enters the URL of a website in a browser and a request is sent to the matchingwebserver, a reply, with the content of the website is sent back. Also some require being ableto be sending and receiving at the same time, also known as a full-duplex operation. A full-duplex operation would be handy for a voice conversation where one person would talk toanother, and the latter would be able to interrupt with a question. Since Bluetooth supportSCO for transfer of voice, it would be desired to support the full-duplex operation, so thevoice wouldn’t only be one way. There are two ways of providing a full-duplex operationin a radio system, Frequency Division Duplex (FDD) and Time Division Duplex (TDD).FDD was used since 1920s and today is a common method. To apply FDD, two antennasare required, one for sending and one for receiving. The two antennas respectively send andreceive over different frequencies with a guard band in between, so interference is avoided.Since two antennas are applied TDD support true full-duplex capabilities. Time DivisionDuplex (TDD) is the technique used by Bluetooth. It can be referred to as half-duplex,since only one antenna is used, and hence it cannot send/receive at the same time. However
24
Figure 2.8: Frequency Division Duplexing Guard Band Illustration (top)[21]
end user perceive no gabs when voice is transmitted. The Bluetooth specification refers toTDD as full-duplex. Since one antenna must be shared for sending and receiving purposes aschema is set to share time between the two operations. The schema consists of time slotsof 625 ms in length. The master starts to send data at even time slots and the slave startssending at odd time slots. Receiving is the other way around. Packets can extend over fivetime slots. The start of a packet is aligned to the slot start.
Figure 2.9: TDD Schema[21]
TDDs is said to be more valuable, since it do not waste bandwidth. Bandwidth can beallocated on a per need basis for either uploading or downloading, and therefore optimizingthe use of available bandwidth. Also the cost of producing radios based on FDD is moreexpensive, due to duplexers and isolation technique needed to separate the two bands (trans-mitting and receiving) [27]. Overall TDD is considered to outperform FDD. However FDDis better for more constant load of uploads and downloads, but it’s a rare scenario, and theflexibility by TDD is highly valued.
25
Figure 2.10: The Hop Definition on Single-slot Packets (top) and Multi-slot Packets (middleand bottom)[21]
2.4 Bluetooth Packets
Bluetooth packets are constructed, much like TCP packets that are widely used on the In-ternet. The TCP protocol specifies how packet are designed, so two independent partiesare able to communicate with each other. The same concept is present when we talk aboutBluetooth. The Bluetooth spec outline how data is wrapped in a packet, so basically thepacket is received at the intended device, and it is able to analyze the data and put the bitsof data together in the right sequence. The way it is designed provides the basics of theoperations end users utilize.
The overall design is illustrated at figure 2.11, and consists of an Access Code, Header andthe Payload. The three parts can be split into pieces that describe the part at a lower level.To start with a higher abstraction level is applied.
Figure 2.11: Bluetooth Packet
The Access Code is used for signalling purpose. There are three types of Access Codes.The Channel Access Code (CAC) identifies a piconet. The code is used for all packets sentover the piconet, so two or more piconets can be constructed within the same range of thedevices. The last two Access Codes are Device Access Code (DAC) and Inquiry AccessCode (IAC). The former is used to label packets for paging (finding out if a device is inrange), and the latter for inquiries (discover new devices). IAC have two combinations onefor discovering general devices, and one for discovering a dedicated group of devices. The
26
dedicated is used if you only what to discover devices that provide operations shared by theinquiring device. These two values are specified by the JSR-82 as constants at Java classesjavax.bluetooth.DiscoveryAgent.GIAC, and javax.bluetooth.DiscoveryAgent.LIAC. LIACis short for Limited Dedicated Inquiry Access Code and GIAC for General/Unlimited InquiryAccess Code. So within your Java code you are able to specify what kind of devices you wantto receive a discovering reply from.
The Header part contains info about what member of the piconet the packet is meant to.The address that specify is 3-bits, and hence 7 nodes can be part of a piconet, since the allzero address is used for broadcasting. The addresses are described in detail at section 2.5.2.The next 4-bits is the Packet Type. There are four different SCO link packets and sevendifferent types of ACL packet. The Type code also indicates the number of slots the packetwill be sent over, as described in the TDD section. This enables other devices to stop listento the channel for remaining time. The next 1-bit is used for flow control. If the receiver’sbuffer is full a stop sign can be sent to stop the sender from sending more packets. Whenthe buffer is empty or can accept more packets a ”go” is sent to the sender. The flow bitisn’t used in SCO packets. The next 1-bit is for Automatic Retransmission Request (ARQ).The ARQ is used for sign for the packet was received in good order. The Cyclic RedundancyCheck (CRC), that is part of the payload of the packet, is calculated both on sender andreceivers side. If the check matches an ACK is sent in form of the ARQ field, otherwiseNACK indication is returned. If no ACK is returned a NACK is assumed by the sender.The next bit is a Sequence Number, used at the receivers end to put packets into order. Ifpackets are sent twice, due to non returned ACK for example, the receiving device can filterout packets already received to avoid corrupt data assembly. The last 8-bit is the HeaderError Check (HEC), which is used to check the integrity of the header. If the HEC checkdoes not match, the entire packet is discarded. To protect header data for transmission errorseach bit is repeated three times in a row. This is why the otherwise 18-bit header describedabove, actually fill 54 bit as figure 2.11 indicate[18].
Last is the Payload part, which can be split into three lower level parts. A Payload Headerof 8-bit or 16-bit specifies the length of the data packet and fields for logical channels andflow control. The body of the payload is the actual data. The body can be from 0-2721 bit.The body is followed by the pre-mentioned 16-bit CRC code.
2.5 Bluetooth Addresses
Nodes in a Bluetooth network are assigned different addresses. Since a net of Bluetooth nodescan be constructed, each node needs to be identifiable, so the nodes can distinguish one nodefrom another. Furthermore, additional addresses are introduced, in order for the net to beexpandable (parking members). The following subsections will describe the addresses usedin the protocol.
27
2.5.1 Bluetooth Device Address (BD ADDR)
Every Bluetooth device has a unique BD ADDR (pronounced bee-dee-adder). The addressis 48 bits and consists of three parts:
Lower Address Part (LAP) containing 24 bits (company assigned)
Upper Address Part (UAP) containing 8 bits
Nonsignificant Address Part (NAP) containing 16 bits
2.5.2 Active Member Address (AM ADDR)
The AM ADDR is a 3 bits address assigned by the master to slaves of the piconet. Addresses001 to 111 (seven addresses) can be assigned to slaves and address 000 is used to broadcastpackets to multiple slaves. The AM ADDR is the first field in the baseband packet header.In conclusion eight nodes can be part of the piconet (one master + seven slaves).
2.5.3 Parked Member Address (PM ADDR)
Due to the AM ADDR (see section 2.5.2) only seven active slaves can actively communicatewith the master. The PM ADDR is 8 bits and the addresses from 0x01 to 0xFF can beassigned. The address 0x00 will be assigned to the following connected devices. They willrespond to activation by the master on the BD ADDR (see section 2.5.1).
2.5.4 Active Request Address (AR ADDR)
A packed member can accept an unpark request from the master to become an active member.Within an access-window the slave can send a request back to the master to become an activemember.
2.5.5 Bluetooth Device Name
Is a user-friendly name (encoding UTF-8). It can be up to 248 bytes. For example onBluetooth enabled mobile phones, users can set the device name to any desired name. Bydefault the device name is usually set to the model name of the phone. The device name isfor parrying devices. When users search for remote devices like headsets or so, the searchwill provide a list of devices in range, and the device name provide an ease of selection forparrying. Users find it easier to identify and select a user-friendly name than an unique 48bits BD ADDR.
28
2.6 Spread Spectrum Frequency Hopping
Bluetooth makes use of waves in the 2.4GHz frequency band. Other technologies also makeuse of this band, for example the 802.11b standard (Wi-Fi). Interference can happen if devicesoperate within the range of each other. Interference can course packets to jammed, mean-ing that data is prevented from being transferred. To minimize the impact of interferenceBluetooth uses a technique called Spread Spectrum Frequency Hopping (SSFH). Bluetoothmake use of the 2.402-2.480GHz (both frequencies inclusive) range and devices hop betweenthese frequencies with a 1MHz interval. The sender and receiver follow the same hops inpre-determined sequence. Due to equation 2.4 the spectrum consists of 79 frequencies. Thespecification states that there can be made up 1600 hops per second. The SSFH reducesthe chance of devices to be jammed in a fixed frequency. In practice this means that severaldusins of links can be made with a range of 30 feet (the reach of a Bluetooth radio)[17].
(2.480− 2.401GHz)÷ 1MHz = 79MHz (2.4)
Despite overcoming jamming problems, the SSFH also has other advantages. Since thefrequency is changed all the time, it’s harder for intruders to eavesdrop on the signal anddata sent over the link. Bluetooth security will be examined in section 3.
2.7 Piconet and Scatternet
Piconets can be grouped to form a scatternet. A device can join different piconets. It canbe master in one net and a slave in another net, but not master of both nets. This enablesyou to do inter-communication between piconets. In practice for example this means thatyou can reach a printer from your laptop placed more than 10 meters away (reach of a classthree Bluetooth transmitter).
2.8 Power Consumption Modes
Not only does Bluetooth save power by means of the RSSI (see section 4.1), but the technologyalso have modes to put devices into to reduce power consumption even more. The modes areprimary used to control devices in the piconet, but the side effect of turning of the transceiverto saver power when possible is not passed.
2.8.1 Hold Mode
The hold mode is entered when there is no need to transmit data for a longer period oftime. The period of time to be in hold mode is negotiated between the master and the slave.
29
Figure 2.12: Linked Piconets Forming a Scatternet[9]
Either of them can force the other one into hold, but only what have been accepted for themax. period of time. During the hold period, each device can perform any other task, likeinquiring for new devices, or turn of the transceiver to save power.
2.8.2 Sniff Mode
Sniff mode is also a power saving mode of operation. A device on sniff mode is still anactive member of the piconet, and listens to the piconet, but only for determined interval oftime. The time interval is like hold mode parameters, negotiated. Both the slave and mastercan request for the link to go on sniff mode, but only the master can force the other deviceinto this mode of operation. When in sniff mode, it’s only possible for the master to starttransmission in the time slots of sniff. A device in sniff mode is still a member of the piconet,and hence it still got its AM ADDR.
2.8.3 Park Mode
When a slave doesn’t need to participate in the channel it can be parked. Still it is possiblefor the slave to be synchronized for the SSFH. A parked member get the PM ADDR assigned,which is used to reach it again, so it again can be activated.
30
2.9 Bluetooth Stack
Seeing the Bluetooth technology at a higher level, the stack protocol is presented at figure2.13. Like the Open Systems Interconnection (OSI) Reference Model[11], the Bluetooth stackis layered. Also, like OSI the goal of the architecture is to provide interoperability betweenapplications written for the specification. To deal with this, applications run over identicalprotocols stacks, as specified by the Bluetooth SIG. The Bluetooth specification is open,so manufacturers of Bluetooth devices and software inventors are able to develop commondevices that live up to the request that devices and applications are able to interoperateacross vendors. Part of the complete stack is the layers specific to wireless technology, butalso protocols like OBEX, FTP, UDP etc. have been adopted by the stack. Designing theprotocols for Bluetooth instead of re-inventing the wheel, speeded up the development of thespecification. Not only did it have a positive affect on the spec, but also on the adoptionof the technology in general. Since developers where familiar with the protocols, and it waspossible for legacy application to be ported to the use of Bluetooth.
Looking more in detail on the layers of the stack, we see how Bluetooth is commonly
Figure 2.13: Stack Protocol[20]
implemented. Usually, the physical implementation of Bluetooth is in form of a card, ordongle that is plugged into a host, e.g. a PC. For the host to control and communicate withthe module a Host Controller Interface (HCI) is provided. The HCI is the module interfacefor the host to Link Manager (LM), Link Controller (LC), and Baseband. Layers above theHCI reside on the host. HCI isn’t required to be certified, but it is used by modules to beinteroperative with hosts of different manufacturer. You could imagine systems where theBluetooth module is part of a self-contained design in such a way that the HCI is omitted.This could be a radio controlled toy etc[20].
31
The Baseband layer of the Bluetooth module handles frequencies and time slots for datato be transferred/received over the radio link. Above the baseband is the LM, which handleoperation such as encryption, authentication, and negotiation of packets size. The LM op-erations are transparent to higher level protocols, since no packets go to higher layers. LMpackets have a higher priority then L2CAP packets, so they are not delayed by data fromthe L2CAP layer.
The L2CAP (Logical Link Control and Adaption Protocol) layer is physically on the host,it communicate with the lower layers through the HCI, and reassembles packets as describesin section 2.4. On top of L2CAP is the RFCOMM, which is a cable replacement protocolemulating RS-232. Furthermore, protocols like OBEX use RFCOMM, to transfer data. TheBluetooth stack as a whole isn’t always used, but vertically parts of the stack, like the OBEXexample above could be implemented in order to provide the desired services.
2.9.1 Stack Implementation
Different stack implementations are available on the host side. Dependent of the platformon PCs stacks like BlueZ, OpenBT, and Windows XP are available. Bluez and OpenBTare implementations for Linux, and Windows XP for the Microsoft Windows XP operatingsystem. Bluez is the stack that is commonly used on Linux, and also the one providing thefunctionality of the hcidump command I used to analyze the OBEX protocol on a low levelcommunication (appendix E). The Bluez is licensed under the GNU General Public License(GPL), in contrast to Windows XP which is proprietary, and not much implementation infois available to describe it further.
2.10 Summery
Bluetooth on its basis rely on radio magnetic waves to transfer data. Almost any wirelesstechnology is based upon radio waves, except the infrared technology (IrDA). Being basedon radio waves carries the advantage that data can be transferred between devices withoutline of sight operation. This makes little requirements to where Bluetooth networks can beset up. Different behaviors of radio waves are possible when interfering with objects. Thebehavior and the result on transmitted radio waves can be predicted, by use radio propa-gation models, which estimate the effect the environment have on the transmission betweendevices. The models for propagation make it possible to evaluate usage of radio waves, henceBluetooth, in embedded systems for a given case. The evaluation will be able to determinewhat kind of class transmitters should be used in the network based on the requirements ofrange. If an environment is radio wave/Bluetooth hostile, a more powerful device class canbe selected to expand the range of the network.
32
The Bluetooth protocol is designed for ad-hoc networks. It provides operations for devicediscovery, and service search within a remote device. The SSFH allows different networks toexist in shared locations, with the minimum of interference. The individual networks provideduplex communication between master and slave nodes, by use of TDD schema, witch providea flexible communication between nodes. The power modes of Bluetooth, which minimizethe power consumption when no activity is on the network, is a feature satisfying embeddedsystem with a battery for power supply.
33
Chapter 3
Bluetooth Security
The Bluetooth technology comes with built-in authentication and encryption options. ABluetooth link can both make use of authentication or encryption, a combination of both,and also be non-secure by not making use of any of the options. Dependent of what kindof application type where the Bluetooth technology is applied, the different levels of securitycan be matched to the desired needs.
Since Bluetooth is a wireless technology, networks of ad hoc architecture are possible toestablish. Network can be set up on the fly as devices travels around. This feature makesthe security aspects more advanced, since flexibility needs to be available in order to optionthe possibilities of the technology, than a static wired network.
3.0.1 Cryptography
Encryption is supported by Bluetooth through the Secure And Fast Encryption Routine(SAFER+) algorithm. The algorithm was a contender at the Advanced Encryption Standard(AES) contest that the Rijndael algorithm was the winner of. Like most modern encryptionalgorithms, the SAFER+ algorithm is open, meaning that the security relies on the key.Every body knows the algorithm, so you need the key to be secret in order to secure infor-mation. SAFER+ make use of 128-bit key which bring 2128 possible keys for an intruder tosearch through in order to decrypt the cipher, and also acknowledge the plaintext
Like other algorithms crypto-analysts have been investigating SAFER+ in order to findweaknesses that can be used to break it. However this is not relevant at this point, sincemany of them are highly theoretical, and the SAFER+ algorithm is still found to be secure.What is more interesting to take a look at is the way security is applied in Bluetooth appli-cations and the implementation weaknesses that have been discovered through time. Firstthe authentication procedure will be summarized to give an overview and some backgroundknowledge for what to come.
34
3.0.2 Authentication
To be able to determine that you set up a link between the two correct Bluetooth devices,authentication can be requested on connection establishment. The authentication is basicallybased on a Personal Identification Number (PIN), which can be up to 128 bits, but in mostcases is only a four-digit number (32 bits). The longer the PIN the more secure you can bethat the device you connect to is the one you think it is.
Figure 3.1 gives an overview of the authentication protocol. On connection establishment, ifauthentication is required by any part, the responder sends back a failure if no prior paringhas been made. The initiator sends random 128 bits (called IN RAND). Based on the IN RAND
and the PIN, e.g. entered by the user on both sides, the function E22 calculates the linkkey. The link key is input for a combination key that both the initiator and the respon-der generate in cooperation. In the first version of Bluetooth it was possible to use a unitkey that only one part contributed to, but is has been deprecated due to security issues.To reduce the impact of hostile connection establishment and authentication attempts, also
Figure 3.1: Authentication Protocol
referred to as Denial of Service (DoS) attacks, there should be some waiting time betweenevery failed authentication attempt. The waiting time should be exponential increased forevery connection attempt. After successful authentication the waiting time should be resetto the minimum.
35
3.1 Attacks
What might be the biggest problem with Bluetooth security is the devices that the tech-nology was designed for. Mobile phones etc. have limited key boards making it hard totype-in lengthy passwords. Therefore is has become practice that paring between devices isdone by use of a four-digit number, instead of full use of the bits that is offered by the linkkey algorithm. Some vendors even use standard PINs for their devices making security evenworse. Since the link key is the starting point, and input for the other algorithms, a weakPIN will jeopardize the rest of communication.
If two devices are paired in a hostile area (where an intruder is listening), and records theconversation between the pairing devices it’s possible to run a brute force attack against thePIN and hence crack it. [26] have tested PIN length and the corresponding time to crackit, and found a PIN length of 4-digits could be broken in 0.064 seconds. Increasing the PINlength to 7-digits would result in 76.127 seconds. Not using the fully 128-bits, the pairingprotocol offers, have a bad influence on the security of Bluetooth, if an intruder is present attime of pairing.
Furthermore the following attacks are have been discovered[15]:
Inquiry attack every Bluetooth device in discoverable mode will reply on a inquiry, herebyyou are able to see what devices are in range at given time. The BD ADDR can beanalyzed and by use of the LAP (see section 2.5.1) you can determine the manufacturerof the device. Blueprinting could also be used for detailed info (see section 4.3). Sincethe BD ADDR is unique a more sophisticated analysis could be used to determine whatpersons (devices) are in the same locations at the same time, and where they moving.
Traffic monitoring can be used to determine master nodes at a location, by monitoringall traffic. The victims devices will use the same CAC (Channel Access Code), and theBD ADDR of the master device can be computed from CAC. So you would be able todiscover even non-discoverable masters.
Paging attack if a remote device is connectable, but not discoverable, you are able to testif the device is in range. The attacking device pages the victim device, and if an IDis returned the attacker knows that the victims device is within range. After the IDis returned the attacker could also get a hold of the user-friendly name by sending aname request to victim’s device. RedFang is a tool (a small C application for Linux)that exercises this technique1.
Frequency hopping attack the hopping frequencies is calculated from the BD ADDR andmaster clock, so by analyzing the frequency hopping you could determine what devices
1RedFang - Bluetooth Discovery Tool, http://www.securiteam.com/tools/5JP0I1FAAE.html
36
are talking to each other. The frequency hopping actually makes eavesdropping harder,since the attacker should know hopping sequence, or record the whole spectrum. Butanalyzing the frequency hopping would be an option for an intruder.
3.1.1 Bluejacking
Bluejacking is becoming a trend. It’s something you can do, even without any technicalknowledge. This is why it’s diffusing. Doing an inquiry in e.g. a train or on the street, andsending a phone book entry to a discovered device with the text ”Hello, you’ve been blue-jacked”, is Bluejacking. Text could also be personalized, like ”I like your pink top”. Basicallyit’s just harassment, that do no further harm on the devices, but the phenomenon is becomingsuch a trend, that websites such as http://www.bluejackq.com/ have been published wherepeople share their Bluejacking stories. The website also distribute Bluejacking software torun on mobile devices, and making the experience even easier for the hostile Bluejackers.
3.1.2 Implementation Weaknesses
Above the Bluetooth protocol has been investigated, with focus on the security aspects. Thesecurity of any protocol isn’t more secure than the implementation of the protocol in question.Trifinite.org is a group of experts trying to identify security flaws, and expose them to thecommunity.
3.1.3 BlueBug (HeloMoto)
One of the first security loopholes found in Bluetooth enabled devices was the HeloMetoattack, named after the Motorola phones it were achieved on. Later the Trifinite.org grouphas named the flaw BlueBug, since it has appeared on phones of other manufacturers as well.The loophole allows an intruder to issue AT commands without the owner of the attackedphone being prompted. The possibilities of the attack are many, since you basically can doanything by means of AT commands. You would be able to initiate phone calls, sending SMS,reading SMS, reading phone book entries, connecting to the internet etc. So the damage thatcould be done is quite tremendous.
The attacker initiates connection to the unauthenticated OBEX Push Profile pretendingto send e.g. a vCard. The attacker interrupts the connection before the owner of the at-tacked phone gets prompted if he/she will accept a vCard. Now the attacker’s device is listedas a trusted device on the victims phone, and this is the flaw! Since the attackers device is inthe list of trusted devices he/she is able to connect to connect to the headset profile withoutauthentication, since it wrongly already is authenticated. Being connected to the headsetprofile the attacker can execute the AT-commands without the knowledge of the victim.
37
Figure 3.2: Attack Symbols
3.1.4 BlueSnarf
BlueSnarf also uses the opportunity to connect to OBEX Push Profiles, without authentica-tion. But instead of making a PUT request, a OBEX GET request is performed. The IrMCspecification (sync. of calendar, contacts etc.) provide a number of filenames that can berequested for. Other file types as well can be requested, if you either know the path and file-name, or correctly guess it. Some implementations even allow connecting to the OBEX FTPserver in the same manner. Here no file names need to be known in advance, the attackercan navigate through the victims file system, and retrieve list of files. The FTP version isalso known as BlueSnarf++.
If the implementation, wrongly, allows this, the files will be transferred to the attacker’sdevice. The information in these files could be quite sensitive to the victim, and hence be ofvalue for an attacker.
3.1.5 BlueSmack
An attack otherwise know as Denial of Service (DoS) attack is in terms of Bluetooth namedBlueSmack! The attack is performed with the intention of paralyzing the victim’s device,and not being able to perform any operations while the attack is going on. On TCP/IPnetwork (internet incl.) a DoS attack could be by performing multiple ping requests to thetarget computer. Often the ping is performed by a group of computers (since a single willnot have the desired effect) against the target computer in order to maximize the load, andforcing it to freeze. This is also the case of BlueSmack. The Bluez stack on Linux providesthe l2ping command in order to ping a remote device in terms of Bluetooth. The packetlength of the ping packet can be set by use of the -s <num> option. Trifinite.org writes thatmost iPaqs react at size of 600 bytes.
3.1.6 BlueBump
BlueBump not only requires technical skills, it also requires the attacker have certain socialskills, since he need to be in contact and convince the victim of doing tasks. The method isstarting by sending a file to victim, and forcing to do authentication. After sending the file
38
(could be a funny pic or movie), the attacker still holds the connection open. The attackerconvinces the victim to delete his device from the trusted list (since he convinced him ofbeing more secure). The victim is not aware of the the connection is still active. Theattacker would now request for a link-key regeneration. The regeneration will create a newentry of the attackers device, without the knowledge of the victim. The attacker is now ableto connect to the victim’s device, as long as the entry isn’t deleted.
3.1.7 BlueDump
This attack could be used as an initial step before PIN cracking. If the attacker knows theBD ADDR of a set of paired devices, he could create a false HCI Link Key Request Nagative Reply
from one of the paired devices to another. The target device would (if vulnerable to Blue-Dump) delete the link key and go into pairing mode. Now the attacker can sniff the newpairing of the devices, and misuse the short PIN length to be able to crack it, and hencedecrypt cipher to come, or connect itself by using the PIN just cracked.
3.1.8 BlueChop
Is an attack for bringing down a piconet. The master must support multiple devices in thepiconet. An attacker spoofs a slave that is already in the piconet, and contacts the master.This will course the piconet to disrupt. This attack has also been seen against the TCP/IPprotocol. If two nodes with the same MAC is on the same network, the network will alsodisrupt, since it course confusion on how packets should be routed.
3.1.9 Car Whisperer
In cars today it is common that hand-free sets are integrated into the cars control panel. Ofcourse it uses Bluetooth to provide the needed functionality. The problem however is that notmuch interaction is possible in order for the driver to type in PIN etc. so the manufacturersuse standard PINs. Trifinite.org has implemented a script to do pairing between a remotedevice and an attackers device. Based on the first three bytes of the BD ADDR the PIN canbe determined, which open the door to inject audio into the car.
3.1.10 Battery Attack
For the Bluetooth devices that are driven from batteries, the attacker has the opportunity toforce the targeted device into a mode of higher energy consumption in combination with thepower control feature of RSSI (see section 4.1). This attack doesn’t have an immediate effect,
39
but the result will occur after ongoing hits. The battery attack can be used by attackers whowant a DoS like result.
3.1.11 Attacker Opportunities
Bluetooth is a short range wireless technology spreading from <100m. This means to set upa link between devices you need to be within range. The same goes for the intruders. Thismakes it risky for intruders, since there’s a risk of them getting caught, while they can bein eye contact with the victims. However you cannot be sure that you are safe from beingattacked even if no-one is within the range of 100m with a laptop or if nothing is in range atall (persons and e.g. laptops).
3.1.12 Hiding Equipment (BlueBag)
Different ways of hiding an attack is possible and have been tested in the real world. BlueBagis a trolley carrying equipment for going through with an attack against Bluetooth-enableddevices. It has been used by the F-Secure team to investigate how vulnerable phones are,and how many of them is out there to be attacked (sort of a market research in their case).F-Secure are an antivirus software vendor. In Milan (Italy) they found, that within 24 hours,1300 smart phones that could be attacked. The top tree services to be attacked was OBEXPush Profile, Headset, and Dial-up Networking[14].
Figure 3.3: The Trolley Named BlueBag[14]
40
3.1.13 Long Distance
The Trifinite.org group has also proven that you need be aware of long distance attacks aswell. They managed to go through with the BlueSnarf attack on a Nokia 6310i using a Linuxlabtop running the Bluez stack/utilities, and a modified Bluetooth USB adapter. The attackwas made over a distance of 1.78 Km.
The group arranged the two nodes (attacker and victim) in such a way that the most op-timal conditions where met for the class 2 device (the victims mobile phone). Placing thesimulated victim at an elevated spot would give the best condition for radio waves to traveland be received by the attacking device. The theory behind the act, is what is called FresnelZones. The magnitude of radio signal is the strongest in the 1st zone. In order to get be bestresult, no obstructions must come within 60 pct. from the centre line. Even the victim’sdevice being a class 2 device with a normal range of 10m, the conditions made it possibleto transmit over a longer distance (1.78 Km). The attacking device being a modified class 1device with an external antenna connector2 had better conditions to transmit than the class2 device, due to the enhanced power class.
The radius of a Fresnel Zone can be calculated for a point on the direct line between the twonodes of the link. The equation for radius of the zones is found at equation 3.1.
Fn =
√nλd1d2
d1 + d2
(3.1)
where F is the radius in meter, and n the zone due for calculationλ is the wavelength of the transmitted signal in meter
d1 is the distance to one end of the linkd2 is the distance to the other end of the link
Hereby you can determine if any obstructions are with the rule of thumb (60 pct. from thecenter line), and conclude if the path is the most optimal3.
2http://trifinite.org/trifinite stuff bluetooone.html3http://www.zytrax.com/tech/wireless/fresnel.htm
41
Figure 3.4: Fresnel Zones
3.2 Antivirus Software
Since the use of the mobile phone has changed since the time of introduction dangers in formof viruses and intrusion are also coming into this field. One of the first manufacturers ofantivirus software for mobile phones is F-Secure. They introduce a software support a saferenvironment, through file scans etc. for virus detection[14].
42
Chapter 4
Ongoing Research
4.1 Received Signal Strength Indicator (RSSI)
The RSSI is a measure for how well a signal is received. In Bluetooth the RSSI value is usedas a power control mechanism. If the RSSI value differs from the preferred value (the GoldenReceive Power Range figure 4.1) the receiver can request the transmitter to either turn up thepower/strength of the signal if the signal isn’t strong enough, or turn it down to save powerif the signal is so clear that it exceeds the upper range value. Basically, if a device is closeand no interference occur power can be saved by turning down the signal, since there is noneed for excessive use of power. The power control is handled by the Link Manager Protocol,and transparent to users, applications and software developers. However it is possible for
Figure 4.1: Golden Receive Power Range[4]
software to read the RSSI value through the HCI. The RSSI value is measured in integervalues, based on mill watts (mW) or more often translated to dBm1, since it’s easier to work
1dBm = log(mW)×10
43
with, due to strip of long decimal numbers. The Bluetooth spec. [2] describe the RSSI valueN to be within the range of -128 ≤ N ≤ 127 in units of dBm. There is however a problemconcerned with the mapping of dBm to RSSI, since different manufacturers use differentschemas. Vendors have their own tables for converting dBm to RSSI. Also the manufacturersaren’t consistent on what kind of scale to use for the RSSI value. Some go up to 255, someto 101, and 31 etc. in RSSI value pointed out in [8] where the 801.11 Wi-Fi technology isin focus. If this wasn’t enough anarchy, vendors use different granularity in the RSSI value,meaning how many steps are possible within the scale. [8] provides equation 4.1 to be ableto compare RSSI values from different manufacturers.
RSSI
RSSI Max× 100 (4.1)
4.1.1 Positioning
Positioning is a hot topic, and is spreading around the world. We have all heard of GPSnavigation, that help people travel from A to B. Also in the field of Bluetooth the topic hasbeen researched since GPS is not possible in-door and the cost for Bluetooth transceivers arefairly low.
To be able to locate an user carrying a device would make it possible to develop moresophisticated systems adapted to the users location and situation. As [28] writes it: ”Criticalfor location awareness is an accurate assessment of the mobile user’s local position”.
Bluetooth provides a number of different options that could be used for positioning:
1. Signal Strength (RSSI)
2. Bit Error Rate (BER)
3. Time of Arrival (ToA)
4. Angle of Arrival (AoA)
The first tree measurements for positioning should be combined with metrics for distancerelationships[28]. AoA however, is based geometric relationships to calculate node positions.AoA isn’t a standard measure in Bluetooth, but is listed to provide an overview of possibletechniques for positioning in general.
There is a common agreement that RSSI is the way to go about for position with Blue-tooth, since this is the angle that the various projects tend to go. Research has both takendirection in form of empirical studies, or alternative by use of radio propagation modelling.The empirical one gather data for e.g. RSSI values and distance relationships as mentionedabove to provide a metric. The more theoretical model in the area is based on propagations
44
models (see section 2.1.4) and the metric is calculated through the equations. Of course inthe ground basics the propagation models have been developed based on empirical approachin combination with the theory, but in the literature the method is described as theoretical.
Common is the method for determining location based on triangulation. At least this isthe what are stated in the articles describing the projects. The most basic method andthe commonly used when reading the articles in depth and evaluating the method used isnamed Hyperbolic Tri-angulation which locate a remote device by calculating the intersec-tion of tree circles with the centers being the sensor devices (see figure 4.2c). Figure 4.2ashows triangulation, and is used when direction is determined for example by use of AoA.The position is calculated by means of trigonometry laws of sines and cosines. MaximumLikelihood Estimation is based on minimizing the distance between the measured distancefrom the nodes and the estimated distance, and hereby locating a node in question with highprobability. The variability in RSSI has been discussed and the way it effect the RSSI for use
a) b)
c)
Figure 4.2: a) Triangulation b) Maximum Likelihood Estimation c) Hyperbolic Tri-lateration[25]
in a positioning system. The following are items that course variability and are argumentswhy RSSI cannot be used for positioning.
� Antenna orientation
45
� Obstacles in the way
� Transmitter/receiver variability
The antenna orientation tends to have affect on how well the signal is transmitted. If a per-son angle his or her phone in one way or another the signal received may vary. Further moreobstacles or humans in the way affect the way how a signal is received[16]. Especially humanswhich consist of a large percentage of water absorb radio waves and reduce the transmittedsignal. Walls may also be located between two transceivers. [7] have however tested the WallAttenuation Factor (WAF) and found that it compensate effectively for attenuation due toobstructions. Figure 4.3 illustrate the result of the WAF. Another problem that critics state
a) b)
Figure 4.3: a) Signal Strength Varies With Distance b) Signal Strength with InterveningWalls After Compensating By Use Of WAF[7]
is the variability in transmitters and receivers. They may be configured to transmit withsome power level d dBm, but actually they send with some value close to d dBm, but notexactly d [19]. This is also the argument of [25] why RSSI cannot be used for positioning.
Although there are many critics Bluetooth for positioning, research in the area of RF-positionhave brought conclusions that state the opposite. RADAR [7] for example is an in-buildingRF-based user location and tracking system, based on the IEEE 802.11 Wi-Fi standard whichinvestigates the empirical and propagation model approach. The empirical study is based ona setup of 3 base stations in a building recording RSSI values associated with coordinatesof the floor location. The data set provide a training set for the data mining algorithmk -nearest neighbor. It was found that averaging tuples by use of of larger k would degradethe accuracy rapidly because points far removed from the true location also are included inthe averaging procedure, thereby corrupting the estimate. Based on propagation models,the RADAR project also tested the performance of their work, and although the empiricalapproach was more accurate they found that the theoretical approach was cost effective, insense that it did not require detailed empirically measurements, and had low set up costs.
46
Above are a number pros and cons for Bluetooth positioning. Dependent on what sourceyou turn to, different conclusions are available. Of course there are many factors to influencea position system based on Bluetooth, and in the end it all depends on the environment,whether it is possible to determine a location and with what accuracy. What is significant Ithink and is the fact that it is possible to measure if a remote device is close, or just with-inrange. In contrast to a mobile marketing system this is a very important feature, to be ableto act within the law of marketing. This I will go more into in section 8.6.
4.2 Bit Error Rate (BER)/ Link Quality (LQ)
The BER is a measure for how well a link is. The value identifies how many bits in errorout of 1 million. A value of 0 is the best, and larger is worse. [13] states that as the valueapproaches 1000 (BER = 0.01%) it is an indication that the link is very bad a lots of Blue-tooth packets are being lost. The BER is also referred to as the Link Quality (LQ).
The BER has been mentioned in [28] for positioning service. Also in [12] the BER/LQwas used to determine the existence of a user. The Bluetooth device carried by the user wasused as a key for the screensaver/lock on a desktop computer. The Linux Bluez stack wasused on the desktop, and a Perl script utilized the the hcitool of the stack. The LQ inBluez can be between 0 and 255 as specified in [3]. 0 is bad, 255 the best. In the examplethe threshold used in the example was 128. If the quality dropped below 128 it assumed theBluetooth device, and thus the user was no longer near the computer, and the screen wouldbe locked. If the quality again came above 128, the screen would be un-locked.
Table 4.1 provides a way for conversion from BER to LQ value.
BER LQ0 255BER ≤ 40
40000255 - BER×40000
4040000
< BER < 400040000
215 - BER32× 40000
400040000
< BER < 4000040000
105 - BER256
× 40000
Table 4.1: BER/LQ Conversion Table[10]
In relation to positioning by use of RSSI value e.g. the RADAR system mentioned above,where the k -nearest neighbor data mining algorithm is applied. I think the model for predic-tion could be improved if the BER/LQ measure was incorporated into the data bags. To addthe BER/LQ attribute to the bag of data, would provide additional information supportingthe decision making, for any algorithm used. Therefore it would be interesting to see howthe attribute would affect the model on a test set.
47
4.3 Inquiry
Will the Bluetooth technology be able to do inquiry, service discovery and pairing in a rea-sonable time frame to push data to the user before they are moving on? The answer to thisquestion is crucial. It’s so important for a system to be adopted that it will perform nearto 100 pct. One bad experience in the start for one consumer, or several bad cases for anexperienced user, can course the system to be dropped and never used again.
Since Bluetooth is a wireless technology you must expect that users travel, and hence atone point is out of range. This would mean that the current transaction of the user would becorrupted. Most Bluetooth transmitters in mobile phones are class 2 transmitters, meaningthat they have a range of about 10 m radius. This range can easily be put behind by a personwalking with a speed of 5 km/h. A person walking with that speed would in best case bein range for 14.4 seconds2 Now, this may seem like long time to take action for a system,but the Bluetooth spec. prescribe that a device should be in inquiry mode for 10.24 secondsto discover remote devices. Now subtraction the time the device should be in inquiry modefrom the time the remote device is within range (14.4 seconds), not much time is left forconnection establishment and actual data transfer. Of course you could use class 1 transmit-ters, to lengthen the time in range for a person who is walking by. But for two devices tocommunicate from a distance of 100 m, they both have to be able transmit that long, andmost mobile phones are designed with class 2 transmitters. Over time you could expect theperformance of Bluetooth transmitters in mobile phones to increase and production cost todecrease, equivalent to Moore’s law. Therefore in the future, the time frame would be muchhigher, leaving more time for data transfer in the above example.
4.3.1 IrDA Supported Connection Establishment
To simplify the problem that many Bluetooth devices can be within range and be discoveredin an inquiry request [29] have come up with solution making it easier to identify what devicethe connection should be established to, and making the connection establishment faster.Worst case connection establishment on Bluetooth is 10.24 seconds while [29] come up witha maximum of 2 seconds. Imagine that you are the cash register in the super market, andyou are about to pay through your Bluetooth service. Doing a inquiry search would list the20 cash registers in the shop, so which one are you going to pick? By use of IrDA supportedconnection establishment, you shouldn’t make the choice of which host you connect to, it’sdone for you. The ideas supposed is exchanging the BD ADDR through a infrared service, so theinquiry process is eliminated. Afterwards the IrDA link is disconnected and the Bluetoothconnection establishment will start. The advantage of not doing the whole transaction basedon IrDA is by switching to Bluetooth you are able to operate without line of sight. Also itcan be hard to select devices from an inquiry list on an a mobile phone due to limited user
25km/t ÷ 3.6 = 1.39m/s ⇒ 20m ÷ 1.39m/s = 14.4 sec.
48
interaction possibilities, thus with IrDA as initial establishment the link could be selected bymeans the physical action of holding the phone in front of the service.
4.3.2 Inquiry Simplification
In order for a Bluetooth link to be established devices need to acknowledge each other. Theinquiry process is the way Bluetooth practice how devices become aware of one another, andis the first step of a tree-phase procedure to establish a Bluetooth connection. The Bluetoothstandard recommends the inquiry process to last 10.24 seconds. However, this may be crit-ical for some applications as a faster connection establishment would be desired. Thereforeresearch has been going on the area of inquiry simplification and speed up mechanism inorder to meet the needs for faster discovery of remote devices.
Different suggestions have been made in order to improve the inquiry process. For example[30] writes about a inquiry procedure where the two devices gain knowledge of each otherinstead of only the one inquiring. This proposal will however only be an improvement forapplications where nodes acts arbitrary as masters or slaves. Nodes would benefit from thatif they self where discovered they didn’t have to discover the other device. The inquiry wouldhave to be performed anyway in order gain full knowledge of the proximity area. The researchtopic I find most useful is the one regarding specification-compatible inquiry simplification.It would be highly beneficial to be able to improve the inquiry process and still be ablecompatible with Bluetooth devices not knowing of the improvements. First a little on theinquiry process.
The Bluetooth inquiry process is built upon an inquiring device being the master send-ing broadcast messages, and a scanning device acting as the slave. To receive an inquirypacket the slave must receive/listen for the packet on the same frequency as the inquiringdevice. For the two devices to hit the same frequency the scanning device changes frequencyevery 1.28 seconds, while the inquiring changes frequency at a more frequent hop level. Thisway they are to hit the same frequency very fast, and to change frequency if noise should becorrupting the channel. The inquiring device sends the broadcast packets for at time slot of625µs followed by the same interval where it listens for a response on the same frequency.When an inquiry packet (broadcast) is received the scanning device drops out of the scanmode for a random number of time slots (0 to 1023 time slots spanning from 0 to 639.375 ms).The delay minimizes collision between multiple devices receiving the same inquiry packet.After the back-off period the slave returns to scanning mode to receive another broadcastpacket which initializes it to send a response back to the broadcasting device. The responseconsists of the BD ADDR and clock value of the slave device. The master can then go onwith the inquiry phase to discover more devices, or enter the paging phase to establish a linkbetween the two devices.
The inquiry phase uses 32 frequencies out of the total 79 frequencies of Bluetooth. The
49
32 frequencies are split into two trains each contain 16 frequencies, called A-train and B-train. The trains exchange one frequency every 1.28 seconds. After 20.48 seconds the trainshave completely swapped frequency members. The specification dictates that the inquiringdevice repeats a train for 256 iterations. A train takes 10 ms to complete. Also there need tobe 3 train switches, meaning that each train will have to be repeated twice (A → B → A →B), to be sure that every device in range will be in the inquiry scan sub state and listen to acommon frequency for at least one inquiry time slot. This is how the 10.24 seconds appear:
2 trains× 2 iterations× 256 times× 0.01 seconds = 10.24 seconds (4.2)
The time spent for the individual is in focus, and desired to be optimized. However thereare further benefits as a consequence hereof. [24] inform that reducing the time spent in theinquiry sub state, which is a significant power consuming state, will reduce power consump-tion. Furthermore, being in the inquiry sub state all other traffic is prevented to the device,setting the slaves of the piconet on break. Last, the inquiry packets sent out are potentialnoise source for neighbor networks. Allot is depending on the inquiry process to be reduced,and significant benefits could be achieved.
Analytical studies of the inquiry time shows that 99 pct. of devices can be discovered in5.12 seconds over an ideal channel[24]. They derived a probability density function for theinquiry time. Based on the function they where able to identify an optimal inquiry time.Based on a desired pct. of devices to be discovered, the inquiry time can be derived.
4.4 Device ID with Blueprinting
Discovering remote devices, by scanning an area, is one of the core operations of Bluetoothdevices. Scanning or inquiring will result in a set of remote devices within range. Remotedevices are represented by the unique BD ADDR and the friendly name used for user inter-face displaying. Also major service class, major device class and minor device class can becollected from remote devices during the inquiry process. This is useful in order to determinewhat kind of remote devices are within range. Are you searching for a printer the systemfilter out non-printer devices from the inquiry result.
Apart from this identification the Bluetooth specification doesn’t specify a way to deter-mine further what kind of models are within range. Of course you got the first three bytesof the BD ADDR you could use to determine the manufacturer of a remote device. Furthermore, a usefull observation made in [6] indicates that the device model can be identified usingthe Bluetooth friendly name which over 20 pct. of users leave as default on their devices anddo not change after purchase.
Almost you are near the target of getting as specific information as possible, however, youare in lack of model (in most cases) and firmware version. A technique is introduced below
50
00:60:57@2621543
device: Nokia 6310i
version: V 5.22 15-11-02 NPL-1
date: n/a
type: mobile phone
note: vulnerable to BlueBug attack
Figure 4.4: Database Tuple Example [22]
on to collect this information as well.
Blueprinting is a technique for efficiently determining the properties of a Bluetooth device.The technique and underlying idea is similar to IP Fingerprinting used in tools for analyzingand determining host operating systems based on the behavior the IP stack3. Blueprintinguses specific information from the Service Discovery Protocol (SDP) and generates a hashof the investigated device. The hash is mapped against a database of pre-registered devices.Hereby it can obtain device information like manufacturer, model, and firmware version.
The information is quite useful in many scenarios. In context of a marketing system basedon Bluetooth you would be able to determine which media types a remote node supports. Ifthe remote node is a mobile phone for example you should only push content, to the phone,it support. You shouldn’t push a .mp4 video to a phone that doesn’t support video content,instead you could push a picture, if it’s supported.
The Blueprinting hash is calculated by using equation 4.3.
n∑s=1
Rs × Cs (4.3)
where Rs is the Record Handle and Cs the Channel Number of Service s.
When data is retrieved through the SDP the calculation of the hash is rather light in con-sumption of processor time, which makes it very suited for devices with limited hardware tocalculate. In order to achieve a higher matching rate the manufacturer part of the BD ADDRis added as a prefix to the hash. As mentioned earlier the hash can be mapped against adatabase of pre examined device info. Figure 4.4 illustrates a tuple in the device database.The downside of being able to obtain info of the remote device is security related. Being ableto identify the devices makes it easier for potential attackers to accomplish malicious acts.
3The nmap tool on Linux operating system utilize IP Fingerprinting
51
Attacks like Denial of Service (DoS), BlueSnafing, and the HeloMoto attack is made easierwhile attackers get to know what kind of devices they are cracking (see chapter 3).
The authors of Blueprinting have developed a Perl script to run on a Linux box with theBlueZ stack. The script extracts the info from a service search and calculates the hash. Thetool is intended for people to use against their own devices, and submit results to the devicedatabase. I’ve tested to tool against my mobile phone, and a hash was calculated. But Iwas surprised of the result. Before hand I’ve calculated the hash on my own, and the tworesults didn’t match. I’ve investigated the Perl script, and found that not only is the channelof a service used on the calculation, but also the Protocol/Service Multiplexer (PSM) valueused where no channel is available. The PSM is used in Connection Request Packets[2]. Soservices with no RFCOMM link should use the PSM value as a multiplier instead. AppendixC illustrates the calculation of the hash.
The reason and the condition why the technique is possible, is that device models are dif-ferent in the way offer services. A record handle is a 32-bit number that uniquely identifieseach service record within an SDP server[2]. The record handle of one service at one devicedo not necessary has to identify the same type of service at another device. The same goesfor the channels. It’s these conditions that the Blueprinting technique relies on.
What happens if users, by installing and running an application that add a service to theSDP server? I think the Blueprinting technique is in lack of documentation since it doesn’tanswer this question. The scenario would kind of break the technique if all services wereto be used in the equation, since each device running every possible Bluetooth applicationwould have to be added to the database. If Blueprinting only uses most common services,and hereby I refer to the profiles handled in the Bluetooth specification, it will last. However,the Perl script (bp.pl) rely on the sdptool browse --tree --l2cap [bdaddr] commandthat browse all available services on the device specified by a Bluetooth address as a parame-ter4. Defenders of the Blueprinting technique could argue that you wouldn’t run a Bluetoothapplication, and at the same time desire other devices to identify your device in order topush the right content at you. When you run an app like a game or so you wouldn’t want tobe disturbed.
4.4.1 Device ID an alternative
When investigation the Blueprinting technique I found that not all profiles are used to calcu-late the hash, although the equation says so! Doing a service search against my Sony EricssonK700i mobile phone I found that one profile was not added when calculating the hash. Thefirst reason I can come up with is that no channel was available, also no PSM value for theL2CAP transport layer was provided. However, the profile had some interesting attribute
4sdptool man page
52
values. The name of the profile was ”PnP Information” (short for Plug and Play), withUUID 0x1200. The service record attribute with id 0x0101 had value ”K700” and id 0x0102
had value ”Sony Ericsson”. The attribute id’s are specified to be respectively description(0x0101) and provider (0x0102). This really questions the Blueprinting technique! Why useit when you by using the SDP can get a hold on service class, major- and minor device class,and also the manufacturer and model? The PnP record contains the following attributes.
� Name
� Description
� Vendor
� Vendor ID
� Product ID
� Version
The problem by this technique is of course that not all devices provide this ”PnP Informa-tion”. Therefore you cannot determine all devices this way. But indeed it is a stable wayto go about a long way down the road. You could argue that if the ”PnP Information”isn’t supported it isn’t worth while sending e.g. an .jpg, .mp3, or .mp4 advertisement tothe device, while it may not support any of the media types. If it do not support ”PnPInformation” what are the odds of it supporting one of the media types?
53
Chapter 5
Bluetooth Intelligent Serial Module
Pros ConsPossible to impl. in known language
Debugging*No need for hardware extension
Limited to AT interfacePrice (¿200)
Easy for new developers to get started*Exceptions and error messages can be provided if another serial line is implemented on JOP.
Table 5.1: BISM Pros/Cons
One of the big concerns of this project was to find a Bluetooth transmitter that could beintegrated with JOP. Different approaches were considered. One alternative was to extendJOP with an SDIO Card, but this solution would require the stack to be implemented onJOP. This would be a hardcore solution, and out of range for a master thesis project. Amore attractive solution for this project would be to find a Bluetooth module that didn’trequired a host implementation of the stack. This is where the products from Blu2i comeinto the picture. Blu2i is a line of products from Ezurio that allows any product, existingor in development, to be enhanced with wireless connectivity1. The Blu2i RS-232 Adapter(illustrated at figure 5.1) connects to the host (in this case JOP) through the RS-232 port,also known as the COM port on PCs. JOP connect to the PC through the RS-232 port whenapplications, or the make process needs to be downloaded. During runtime you could useJava System.out to for showing text strings at the console of the PC. Debugging over serialline would also go this way to be displayed at the console. However when first a program isdownloaded, the serial line could be omitted while JOP could be communication with a PCthrough UDP instead of the RS-232 port. Furthermore the Blu2i product line provides an
1http://blu2i.com/index.asp
54
implementation of the Bluetooth stack leaving the host with no requirements of Bluetoothstack software. This is why it is referred to as the Bluetooth Intelligent Serial Module (BISM).Also it got good recommendations at a Google group thread2.
Figure 5.1: Blu2i RS-232 Adapter
The BISM is a class 1 transmitter, meaning that it has a range of 250m in free space.It has a data transfer rate up to 230Kbps. Due to equation 5.1 you would be able to send a.mp3 file in less than 14 seconds (assuming the file is 3MB of size). In context of embeddedsystems size matters! The physical size of the BISM is 102 × 54 × 5 (mm), and weights 30g.
3MB× 1024Kb÷ 230Kbps = 13.36 seconds (5.1)
Temperature range normal operation: -20◦C to +75◦C. Furthermore it has status lights thatwould be beneficial when debugging etc.
The BISM is qualified for Bluetooth 1.1 and therefore has the right to wear the Bluetoothlogo. This may not seem important, but it’s rather crucial that you know for sure thatthe device is operation according to the specification, since otherwise would mean that youcouldn’t be sure that the device would be fit to communicate with Bluetooth devices fromother manufacturers or such.
5.1 AT Interface
The BISM is controlled by the host through Hayes AT-like commands. [13] is 37 pages shortspecification of supported commands. AT commands are basically text commands (ASCII)that are sent to the BISM over the serial line. It can be compared with the commands
2http://groups.google.com/group/sci.electronics.design/browse frm/thread/1f3cf15d842be2e/29a53e12266a4ffd?=bluetooth&rnum=9#29a53e12266a4ffd
55
Figure 5.2: Components Overview
we use to operate a PC from a prompt or shell. You could type in commands and sendthem to the BISM though a HyperTerminal, just the way you operate within a commandprompt. However this project is seeking a more automated approach. Figure 5.2 illustratethe components, and relationships. Hayes AT commands was used in the old days to operatemodems. The same approach is used by the Blu2i Bluetooth modules. The module receives acommand ended by the carriage return character, and does whatever the command is tellingit to do. When the task has been executed, the module replies with status of the executedtask or with the info requested by the command sent. The module can be configured thoughS-registers. The S-registers are used to store parameters on the BISM. The parameters holdvalues that define how the BISM should operate. Example of a S-register is the S517, itdefine how long the module should be in inquiry mode. Setting this S-register to 5 will makethe module do inquiry for five seconds and then return to be able receive further commands.
The following subsections will provide an overview and description of the most importantcommands that the implementation of the Java API is based upon.
5.1.1 Configuration (ATSn)
The ATSn command is used to read current S-registers. The n should be replaces with theS-register integer value. To set a new value and hence a different set up, you can write a newvalue by ATSn=m, where m is the new value. After writing to a S-register the value must bestores in non-volatile memory to sufficient after power down or reset. S-registers are writtento non-volatile memory by use of the AT&W command.
5.1.2 Information (ATIn)
To read information like firmware version the ATIn command can be used, where n is theinformation integer value. Not only statically information can be read, also values like RSSI
56
can be read if a connection is established to a remote device. RSSI is not part of the JSR-82,however some APIs have implemented this additional feature as well, since it provide usefulinformation to imply the distance to the remote device.
5.1.3 Inquiry (AT+BTI(N))
In order to discover remote devices the AT+BTI can be used. It will return the BD ADDRof the remote devices in range. To also discover the the friendly names and device class thecharacter N can be appended the command.
5.1.4 Service Discovery (AT+BTVbd addr,uuid)
Service discovery is unfortunately not that trivial. You have to investigate every possibleUUID to get a list of supported services. The reply will be 0 if the service is present, 1 it’snot, 2 if the device cannot be reached, 3 if the SDP database is corrupt or invalid, or 4 if thedevice is not in idle mode.
5.1.5 Connect (ATDbd addr,uuid)
To connect to a remote device in range you have to use the ATD’’BD ADDR,UUID’’. Replywill either be INVALID ADDRESS or CONNECT BD ADDR. It is possible to connect toany RFCOMM service. The BISM only support SSP profile, but implementation of aboveprofiles will make it possible to e.g. push files (see section 6).
5.1.6 Send (ATX’’Hello World’’)
Sending a text string to a remote device after connection is established is by use of the ATX
command. Example usage is ATX”Hello World”. Remember the quotes. As of the momentof writing it is only possible to send 34 characters per command. To send non-visual charac-ters use \hh where hh is the hex value of the character.
To start with I had big problems sending data, since packets was limited to 34 characters.See section 6.1.3 for further details.
5.1.7 Data Mode (ATO)
To overcome the limit of the ATX command the BISM can go into data mode after connec-tion establishment. There is very little documentation on this command, and I first didn’t
57
acknowledged how to use it and what it meant. But after confronting my guidances withthe limit of ATX they asked me if I couldn’t put the BISM into data mode? I didn’t thoughtthis was possible, since I’ve written e-mails with the Blu2i support regarding ATX and theydidn’t tell me the alternative. However data mode cannot be applied in context of the OBEXimplementation (see section 6.1.3 for further details).
5.1.8 Escape Sequence (^^^)
To go out of data mode ^^^ (three circumflexes) should be sent to BISM. In between everycharacter there needs to be a pause. By default the pause is set to 100ms, but it can bechanged as well as the escape character. This is done via the S-registers mentioned above.
5.1.9 Disconnect (ATH)
ATH disconnect from the current connection. Relpy will be NO CARRIER.
5.1.10 Errors
[13] list 38 type of errors. Each error have an associated error number, and the meaning ofthe number can be looked up in the spec for troubleshooting. For example ERROR 05 is asyntax error. If you receive such an error, the command sent is not in the right form or thecommand doesn’t exist.
5.2 Algorithm for reading BISM reply
The AT commands commented above is sent to the BISM over the serial line (RS-232). TheBISM will in most cases reply back with an <cr,lf>OK<cr,lf>, dependent of the command,if the command is supported and received by the BISM. If not a <cr,lf>ERROR nn<cr,lf>
could be expected. The problem is that you do not know how long it take for BISM to reply.Also the reply could be split in chunks e.g. when inquiry is performed the discovered deviceswill be sent from BISM as they are discovered. Listing 5.1 illustrates how the reply is readand parsed into a String array to traversed by the invoker of the method. The reading stopswhen the reply is either an OK, or an ERROR. The value(s) of the reply from the BISM isthen returned in the String array. The reading of the replies is a very central part of theimplementation of the API described in section 6.3.
58
Listing 5.1: Reply Read Algorithmpub l i c s t a t i c S t r ing [ ] readStandard ( ) {
buf = new St r i ngBu f f e r ( ) ;l i s t = nu l l ;f o r ( ; ; ) {
RtThread . sleepMs ( 2 0 ) ;c = ( char ) System . in . read ( ) ;i f ( c == 13)break ;
}boolean doBreak = f a l s e ;f o r ( ; ; ) {
RtThread . sleepMs ( 2 0 ) ;i f ( System . in . a v a i l a b l e ( ) > 0) { // hacking
c = System . in . read ( ) ;} e l s ec = 13 ;i f ( c != 13 /*&& c != −1*/ ) {
i f ( c != 10)buf . append ( ( char ) c ) ;
e l s e {i f ( buf . t oS t r i ng ( ) . regionMatches (0 , OK, 0 , OK. l ength ( ) ) | |
buf . t oS t r i ng ( ) . regionMatches (0 , ERROR, 0 , ERROR. l ength ( ) ) ) {doBreak = true ;
}i f ( buf . l ength ( ) > 0) {
l i s tAdd ( buf . t oS t r i ng ( ) ) ;buf . d e l e t e (0 , buf . l ength ( ) ) ;
}}
}i f ( doBreak )
break ;}/*whi l e ( System . in . a v a i l a b l e ( ) > 0) {
System . in . read ( ) ;RtThread . sleepMs (10 ) ;
}*/System . in . read ( ) ;RtThread . sleepMs ( 1 0 ) ;System . in . read ( ) ;r e turn l i s t ;
}
5.3 Summery
The BISM provides varies operations through the AT interface. The AT command referenceprovide a detailed description of commands and associated the operation. Also the device iseasy configurable through the S-registers.
The only lack of functionality is the service search, but it is possible to determine if a serviceis present. It’s just up the logic of the API, that the service search will produce a list ofservices, rather than a Boolean description of a single service.
59
However the limitations of the transmit operation (ATX) has courses some issues, due tothe packet length of the higher layer OBEX protocol. This will be examined in the comingchapter.
60
Chapter 6
Java Bluetooth
The JSR-82 is a specification for how Java applications can make use of the Bluetoothtechnology. There are several Application Programming Interfaces (APIs) for Bluetoothon the market that follow the specification. Dependent on what kind of platform you use(Windows or Linux) different implementations of the API are available. Some APIs performnative instructions controlled within your Java code, while other is pure Java implementationof the stack as well. Take Harald for example1. Harald is a pure Java implementation of theBluetooth stack, although it doesn’t conform to the JSR-82 (a different design of the API ischoosen). Harald accesses the Bluetooth chip of e.g. USB dongels through the javax.comm
package that needs to be installed. Table A show an overview of available APIs2. Referencesto the APIs are at appendix A. Some of the APIs, mostly the free ones, do not supportOBEX, which is the javax.obex package. However there is a way go about. AvetanaObex isa Sourceforge project3 that basically is an extraction of the OBEX part of avetanaBluetooth.It is intended for use on J2ME devices, that usually doesn’t offer javax.obex operations,but since it is a Java implementation it will also run using J2SE combined with any JSR-82implementation. AvetanaObex uses the lower SPP layer to do OBEX communication. Ittransforms a SPP connection to and OBEX connection, and provide and implementaion ofOBEX protocol by means of javax.obex. I’ve written and example application of how touse send a file via OBEX over a SPP link. The source code is available at appendix D.The extraction of the javax.obex packages from the avatanaBluetooth API is interestingin context of the BISM (chapter 5). The module supports SPP, but not above layers likeOBEX. AvetanaObex would be a great source for inspiration and help when implemetingthe optional part of the JSR-82 for JOP.
1http://www.control.lth.se/∼johane/harald/2http://www.caside.lancs.ac.uk/java bt.php3http://sourceforge.net/projects/avetanaobex/
61
Name License OS Java JSR-82 OBEX
Java API’s with Bluetooth stacks built in
Harald Free Any Any No No
aveLink Commercial Any Any Yes Yes
JavaBluetooth GNU Any - Yes No
Java API’s running on top of external Bluetooth stacks
avetanaBluetooth Commercial Win XP, Linux, MacOS J2SE Yes Yes
BlueCove GNU Win XP, Linux J2SE Yes No
JBluez GNU Linux J2SE No No
Impronto DK Commercial Linux J2SE Yea Yes
Table 6.1: Java Bluetooth APIs
6.1 JOP and Bluetooth
JOP is Bluetooth-enabled through the Bluetooth Intelligent Serial Module (BISM). TheBISM is an intelligent device containing stack implementation and provide an AT-commandlike interface for the host device to control it. The module connects through the RS-232 port,also known as the COM port on PCs. JOP also have the RS-232 port, so the BISM couldeasily be controlled by JOP. The fact that the host doesn’t need any stack implementationin order to Bluetooth communicate is very attractive. Mainly because of the decreasedtime-to-market development. Section 6.2 describes JOP implementation detail in depth.
6.1.1 How is JOP different
Why use JOP instead of other systems? First of all, the market for Bluetooth systems is justopening. The forecast of advertisement on the mobile phone is predicted to be a bonanza.In 2007 9 billion DKK will be used on mobile marketing on a global basis. By the year 2011,the market will hit a value of 70 billion DKK4. The market is in the very early stage of itslife cycle. Therefore it could be very profitable to get into the market at this point. What’sspecial about JOP then is that a different type of systems can be build. So far the systemsthat I have seen are very much centralized, based on a server controlling Bluetooth componentat de-centralized locations. Using JOP, a different architecture can be used. JOP enables amore decentralized architecture. This may in fact be a good idea, especially when looking
4http://www.kampanje.com/annonsering/article48735.ece
62
at small companies who only need 1 or 2 devices to actually do the marketing. Looking atcosts, at server can be very expensive for low budget companies. Also, you could imaginea system that was required to be mobile for it to be used. For instance a hot dog stand orso, and the system wouldn’t be able to be connected to a central server that controlled theBluetooth devices.
6.1.2 Bluetooth API for JOP
The research question states that the Bluetooth API implemented for JOP should conformto the JSR-82. So naturally this is the target of the project. It is a clear goal to implementthe API as specified in JSR-82. The implementation will follow the design of JSR-82, andonly where it’s explicitly documented where the implementation will not follow the JSR-82,the implementation will be different from the specification. It’s not a goal for the projectto come up with a different design then JSR-82, so the API for JOP will only differ whereimplementation is not possible due to limitation of the BISM or JOP.
6.1.3 Object Exchange Protocol (OBEX)
The OBEX was original designed for IrDA communication. However the protocol has beenadopted by Bluetooth and many applications use OBEX over Bluetooth e.g. synchronizationof calenders. Many Bluetooth devices today also support the OBEX Push Profile, which isa Bluetooth service enabling other devices to send/push files to the device. The files canfor example be vCards (phone book entries), ring tones or images etc. What’s special aboutthis service is that no paring is required, also no additional software is to be installed on thedevices. So as little user interaction is required to be able to receive files from remote devices.
Although BISM doesn’t support OBEX it is able to connect to such a service, since theservice is over the RFCOMM link. This too is what the avetanaObex does. It connectsto an OBEX service using the operations of the SPP stack, and on top of this link providean implementation of the OBEX protocol. The avetanaObex was a source of inspiration toimplement the OBEX protocol on top of the BISM functionality to run with JOP as the hostdevice.
Using the Linux Bluez packet analyzer named hcidump it was possible to see how the BISMconnected to an OBEX Push Profile. The OBEX spec was very helpful also in order to getan overview of the packets. Figure 6.1 illustrates the additional traffic that needs to be ex-changed between client and server for OBEX to work over a SPP link. The black arrows arethe additional packets, and the red arrows shows a clump of packets handled by the under-laying protocol (SPP). Using the ATX command (see section 5.1.6), data can be transferredover the SPP. Data is wrapped in a Bluetooth packets like showed at figure 2.11. As the ATX
63
Figure 6.1: OBEX Over SPP Overview
command offer transfer of visible characters as well as non-visual characters, OBEX packetscan be constructed, and sent wrapped in a underlaying protocol packet. However there is anissue concerning the packet length. The AT-commands can maximum be 34 characters longon BISM firmware version 2.7.0. From prior versions the length of characters has been in-creased, but still 34 characters doesn’t give you much to work with when transferring OBEXpackets. Mostly because of the ATX command and the surrounding quotes of the string addup to five characters. Furthermore data of OBEX packets, like packet type, packet lengthand content length is made up by non-visual characters. So the hex value most be transferredinstead. Since you must add another two characters in order to transfer a hex value of a char-acter (non-visual) the actual information transferred can be divided by three. Sending theinitial connect packet is no problem. The packet is made up by seven hex values, which canbe constructed within the 34 character limit. As illustrated at figure 6.2 the command onlyadd up to 26 characters. But OBEX isn’t just about connect packets, the protocol contains
Figure 6.2: OBEX Connect Packet Using ATX Command
different types of packets, and specially header data packets and pure data packet containsmore info and hence more bytes (characters by use of the ATX command) to be transferred.
64
One example is the a header packet for setting the name of file to be transferred. Figure 6.3illustrates this by showing a header packet containing the name of the file to be transferred.In the example the name of the file is abc, but due to non-visual character (all except thea, b, and c) the OBEX packet constructed, exit the upper bound of the AT command. Thecharacters that is pass the 34 character limit is colored red. With the current firmware ver-
Figure 6.3: Too Long OBEX Header Packet Using ATX Command
sion of the BISM, a file can only be named with a one length character e.g. a like the figure6.4 shows. This is quite a problem, since mobile phones etc. you would desire to transfer filesto, usually handles files based on their extensions e.g. vCard (electronic business card/phonebook entry) have the file extension .vcf. When a file is received on the mobile phone overthe Bluetooth connection and the OBEX Push Profile, the mobile phone places the file in afolder where the file is suited. The following examples are from a Sony Ericsson model K700i.JPEG files go into Pictures folder, MP4 files goes into Videos folder, and so on. Dependenton the folder, different functions are available, for example in Pictures folder main functionis view, and in Videos folder the main function is play. The placement is ruled by the fileextension, and it isn’t possible to move files from one folder to another. So the file extensionis rather crucial. Since the file extension in most cases is a four character sequence, the datacannot be sent using the ATX command since the constructed packet will be too long.
Figure 6.4: Maximum OBEX Header Packet Using ATX Command
It’s possible to set the BISM into data mode, when connected to another device. Thismeans that you could just write bytes to the serial line and the bytes would be transferredover the link. You wouldn’t have to think about packet length and so on, data would justbe transferred. However there is a problem regarding OBEX. Data is transferred regardlessof packet structure of the OBEX protocol, so the other end of the link wouldn’t be able totranslate and understand the data transferred. So after investigating how data is transferredby use of the Linux hcidump utility, and an OBEX client it can be determined that settingthe BISM into data mode cannot solve the above mentioned packet length problem. For now
65
the only solution is to wait for another firmware release, where more characters can be usedto construct AT commands. Or corporation with the company could be made to develop theBISM in direction of what would be appropriate for ELS at CBS.
6.2 Implementation
The BISM come with different connection types. Since JOP is equipped with a RS-232 port,I’ve chosen the RS-232 to Bluetooth adapter. The BISM is also produced as an USB adapter,but in order to give the project an easy start and to test if the adapter was useful at all, theRS-232 adapter was chosen for the project.
To write to the serial line on JOP one could use the System.out.print in Java. If con-nected to a PC the output of System.out.print would be transferred to the PC over theserial line and printed at the command-prompt (if the download app is running). This was theway I started out testing the BISM. After downloading the app on JOP I’ve switched cables,JOP/PC to JOP/BISM, and the commands could be sent by use of the static print method.As predicted, the BISM understood the commands sent from JOP. To read replies from BISMon JOP, the System.in.read in Java did the job. So having these two examples on howto use native functions on JOP, I’ve implemented the abstract class java.io.OutputStreamin a class I’ve named net.sourceforge.blueonjop.BluetoothOutputStream for use in myimplementation of the JSR-82.
What’s important to note is when you want to make use of the BISM be sure that debugginginfo is removed from JOP classes, or it is sent over the Ethernet. Using System.out.println
for debugging will interfere with the AT commands and the BISM will not be able the under-stand the commands. So use debugging over Ethernet to display info etc. This fact makes itdifficult to do a simple task like debugging. Debugging can be difficult, since you basicallyneed to find and correct errors made by yourself. This is hard even when writing an essay,and even more when programming. Usually compiler output and debugging utilities helpsthe developer in writing error free applications.
6.3 Implementation of the Bluetooth Classes
Some classes and interfaces specified in the JSR-82 are central in their operations, and usewhen writing Java/Bluetooth applications. In this section I will describe these classes, andcomment on the choice of implementation I’ve made to make the API run on JOP with theRS-232 adapter. The list of classes/interfaces are:
66
� javax.bluetooth.LocalDevice
� javax.bluetooth.RemoteDevice
� javax.bluetooth.DiscoveryAgent
� javax.bluetooth.DiscoveryListener
� javax.microedition.io.Connector
The DiscoveryListener is the interface that an app should implement to in order to makeuse the DiscoveryAgent class. The interface has four methods to be implemented in orderto receive information about device discovery, service discovery, and completion of the twodiscovery types. The work is done by DiscoveryAgent class which then calls the interfaceof the app where the info becomes available to app using the API.
For an app to use the DiscoveryAgent it first has to contruct an object of the LocalDevice
singleton, and if a local Bluetooth device is present the DiscoveryAgent can be retrieved(listing 6.1).
Listing 6.1: Initializing Objects
LocalDevice locDev = LocalDevice . getLoca lDev ice ( ) ;
DiscoveryAgent agent = locDev . getDiscoverAgent ( ) ;
To inquiry for remote devices in range you should call the inquiry method that takes twoarguments, what kind of devices you are looking for, and this which is an object of class wechose for the implementation of DiscoveryListener interface. There are two constants tobe used DiscoveryAgent.GIAC and DiscoveryAgent.LIAC. GIAC is for General/UnlimitedInquiry Access Code which will inquire for all devices in range, and LIAC is for LimitedDedicated Inquiry Access Code is used when you wish to inquire for units that share acommon characteristic. DiscoveryAgent.CACHED could be used to only retrieve pre-knowndevices.
Listing 6.2: Start Inquiry
agent . s t a r t I n qu i r y ( DiscoveryAgent .GIAC, t h i s ) ;
The call (listing 6.2) will trigger the DiscoveryAgent to search for devices, and transfereach device found as an object (javax.bluetooth.RemoteDevice) to the class invoking theinquiry through the DiscoveryListener interface, and give a notice when the inquiry iscompleted and with what status through the inquiryCompleted(int) method of the inter-face.
The implementation of the DiscoveryAgent is based on threads, and a semaphore like han-dling of task performed (inquiry, service search). This was done in order to overcome the
67
stack overflow issue on JOP. When the startInquiry is invoked a boolean variable is set totrue, and the thread handling the inquiry will know to start.
Listing 6.3: startInquiry Implementationpub l i c boolean s t a r t I n qu i r y ( i n t accessCode , D i s cove ryL i s t ene r l i s t e n e r ) {
i f (MyBluetoothApp . l ogg ing )System . out . p r i n t l n ( ” s t a r t I n qu i r y ” ) ;
t h i s . l i s t e n e r = l i s t e n e r ;inq = true ;RtThread . sleepMs (2000 ) ; // l e t inqu i r y s t a r tr e turn true ;
}
The thread mentioned above is started in the constructor of the DiscoveryAgent singleton,which is initialized as in listing 6.1. The thread and the task it is performing is at listing 6.4.The variable out is an instance of the BluetoothOutputStream class that I’ve implemented.The class extends the abstract class java.io.OutputStream. The BluetoothOutputStream
enables writing to the serial line where the RS-232 adapter should be plugged-in. The code isvery much inspired by the java.io.PrintStream/com.jopdesign.sys.JVMHelp from JOPsource tree. I’ve could have used the static methods of PrintStream, but an output streamobject needed to be returned in other part of the API, so I just use an object here aswell, since it is Java (object oriented language). The thread loops, and if the inq attributedescribed in listing 6.3 is true the inquiry is triggered. The inquiry is activated by sendingthe ASCII command (the command is described at section 5.1.3) over the serial line to theadapter. The adapter will then reply with the result. The reply is parsed by the classnet.sourceforge.blueonjop.ReplyReader, and each device is transferred to the inquiringapp through the DiscoveryListener interface as the module discover the nodes. Dependenton the parsed reply from the adapter, a status code is sent to the interface to notify the app.At last the inq is set to false, so the loop will not enter the if block again without it beingrequested.
Listing 6.4: Thread Performing Inquirynew RtThread (INQ PRIO , INQ PERIOD) {
pub l i c void run ( ) {f o r ( ; ; ) {
waitForNextPeriod ( ) ;i f ( inq ) {
synchron ized ( out ) {out . wr i t e ( ”AT+BTIN\ r ” . getBytes ( ) ) ;d ev i c e s = ReplyReader . readInq ( l i s t e n e r ) ;i f ( d ev i c e s . l ength > 1)
l i s t e n e r . inquiryCompleted ( D i s cove ryL i s t ene r .INQUIRY COMPLETED) ;e l s e {
i f ( d ev i c e s [ 0 ] . regionMatches (0 , ReplyReader .ERROR, 0 ,ReplyReader .ERROR. length ( ) ) )l i s t e n e r . inquiryCompleted ( D i s cove ryL i s t ene r . INQUIRY ERROR) ;
e l s el i s t e n e r . inquiryCompleted ( D i s cove ryL i s t ene r .INQUIRY COMPLETED) ;
}inq = f a l s e ;
} //End synchronized b l o c k} //End i f
} //End fo r ( ; ; ) loop
68
} //End pub l i c vo id run ()} ; //End Thread
When the inquiry is completed and a remote device was in range, you could do a servicesearch on the remote device through the Service Discovery Protocol (SDP) to what profilesit offer. This is done in a similar way to the inquiry through the DiscoveryAgent. Themethod takes as argument what kind of attributes to search for, what kind of profiles shouldit check for (UUID), the remote device to search on, and the interface implementation toreceive the result. The attribute set is null, since we would like all attributes describing theservice.
Listing 6.5: .UUID [ ] uuidSet = {new UUID( ”1101” ) , new UUID( ”1105” ) } ;//1101 S e r i a l Port Pro f i l e , 1105 OBEX Push P ro f i l eagent . s e a r chS e r v i c e s ( nu l l , uuidSet , new RemoteDevice ( ”001060B2D6DB” ) , t h i s ) ;
The call will invoke the following code in listing 6.6. Like the implementation for devicediscovery to service search is based on a thread. The thread is looping and when the ser
attribute is set to true the service search is performed by use of the global attributes thatare set to what the arguments of the method are carrying.
Listing 6.6: searchServices Implementationpub l i c i n t s e a r chS e r v i c e s ( i n t [ ] a t t rSe t , UUID [ ] uuidSet ,
RemoteDevice device , D i s cove ryL i s t ene r l i s t e n e r ) {t h i s . l i s t e n e r = l i s t e n e r ;t h i s . dev i c e = dev i ce ;t h i s . uuidSet = uuidSet ;s e r = true ;r e turn 0 ;
}
Now for the description of the service search implementation. The thread is started fromconstructor of DiscoveryAgent like the thread doing the inquiry. The source code is atlisting 6.8. First the ASCII command is constructed (described in section 5.1.4), since itshould be customized for remote device (the BD ADDR), and then it is sent over the serialline. The reply adapter is sent back over the serial, and read and parsed by the ReplyReaderclass. The adapter reply with a code for each service searched upon. Based on the codes,different outcome is possible. If the service is present, it is added to a String array whichis later transferred to the app through the DiscoverListener interface. If the service isnot present it is not added to the array. To manage the reply codes from the adapter, I’vecreated some constants that are at listing 6.7.
Listing 6.7: Constants in DiscoveryAgent
pr i va t e s t a t i c f i n a l S t r ing SERVICE IS PRESENT = ”0” ;p r i va t e s t a t i c f i n a l S t r ing SERVICE NOT PRESENT = ”1” ;p r i va t e s t a t i c f i n a l S t r ing SERVICE NOT REACHABLE = ”2” ;p r i va t e s t a t i c f i n a l S t r ing SERVICE CORRUPT = ”3” ;p r i va t e s t a t i c f i n a l S t r ing SERVICE IDLE = ”4” ;p r i va t e s t a t i c f i n a l S t r ing SERVICE ERROR = ”5” ;
69
Dependent on the service search status, a status code is returned through the serviceSearchCompletedmethod of the interface to notify the app. Also the ser is set to false, so the service searchwill not be performed until requested again.
Listing 6.8: Thread Performing Service Searchnew RtThread (SER PRIO , SER PERIOD) {
pub l i c void run ( ) {f o r ( ; ; ) {
waitForNextPeriod ( ) ;i f ( s e r ) {
synchron ized ( out ) {out . wr i t e ( ”AT+BTX\ r ” . getBytes ( ) ) ; /*do not acceptincoming connect ions or inqu i ry r e que s t s */i f ( ! ReplyReader . readStandard ( ) [ 0 ] . regionMatches (0 , ReplyReader .ERROR, 0 ,ReplyReader .ERROR. length ( ) ) ) {
; //??}index = 0 ;s e r v i c e s = new St r ing [ 2 0 ] ;code = SERVICE IS PRESENT ;f o r ( i n t i = 0 ; i < uuidSet . l ength ; i++) {
buf = new St r i ngBu f f e r ( ) ;buf . append ( ”AT+BTV” ) ;buf . append ( dev i ce . getBluetoothAddress ( ) ) ;buf . append ( ” , ” ) . append ( uuidSet [ i ] . getUUID ( ) ) ;buf . append ( ”\ r ” ) ;out . wr i t e ( buf . t oS t r i ng ( ) . getBytes ( ) ) ;s e r v i c e = ReplyReader . readSer ( ) ;// s e r v i c e s [ index ] = s e r v i c e [ 0 ] ;// index++;i f ( s e r v i c e . l ength > 1) {
i f ( s e r v i c e [ 0 ] . regionMatches (0 , SERVICE IS PRESENT , 0 ,SERVICE IS PRESENT . l ength ( ) ) ) {s e r v i c e s [ index ] = uuidSet [ i ] . getUUID ( ) ;index++;
} e l s e i f ( s e r v i c e [ 0 ] . regionMatches (0 , SERVICE NOT REACHABLE, 0 ,SERVICE NOT REACHABLE. l ength ( ) ) ) {
code = SERVICE NOT REACHABLE;break ;
}} e l s e {
code = SERVICE ERROR;break ;
}}i f ( code . regionMatches (0 , SERVICE NOT REACHABLE, 0 ,SERVICE NOT REACHABLE. l ength ( ) ) ) {
l i s t e n e r . serv iceSearchCompleted (0 ,D i s cove ryL i s t ene r .SERVICE SEARCH DEVICE NOT REACHABLE) ;
} e l s e i f ( code . regionMatches (0 , SERVICE ERROR, 0 ,SERVICE ERROR. l ength ( ) ) ) {
l i s t e n e r . serv iceSearchCompleted (0 ,D i s cove ryL i s t ene r .SERVICE SEARCH ERROR) ;
} e l s e i f ( index == 0) {l i s t e n e r . serv iceSearchCompleted (0 ,D i s cove ryL i s t ene r .SERVICE SEARCH NO RECORDS) ;
} e l s e {St r ing [ ] tmp = new St r ing [ index ] ;f o r ( i n t j = 0 ; j < index ; j++)
tmp [ j ] = s e r v i c e s [ j ] ;l i s t e n e r . s e r v i c e sD i s c ov e r ed (0 , tmp ) ;l i s t e n e r . serv iceSearchCompleted (0 ,D i s cove ryL i s t ene r .SERVICE SEARCH COMPLETED) ;
70
}s e r = f a l s e ;
} //End synchronized b l o c k} //End i f
} //End fo r ( ; ; ) loop} //End pub l i c vo id run ()
} ; //End Thread
The next step of the common Bluetooth app would be to establish a connection to one ofthe services that the remote device offer. This is illustrated in listing 6.9.
Listing 6.9: javax.microedition.io.ConnectorConnection c = Connector . open ( ”001060B2D6DB,1105 ” ) ; //TODO use btgoep :// in s t ead
The implementation of Connector class is very straight forward. Through the AT commandsfor connection establishment (see section 5.1.5) and disconnection (section 5.1.9) the opera-tions are performed, and the reply parsed. Also the class implements the javax.microedition.io.Connection interface, and makes it possible to open an java.io.OutputStream for datatransfer. However an input stream cannot be created since it is of the boundaries. It hasbeen chosen to implement the client part of the API, and cut off the server implementationof the API.
Now the most fundamental Bluetooth classes have been described. In the next section theOBEX classes will be described in order to fulfill the picture.
6.3.1 Implementation of the OBEX classes
Like the Bluetooth classes there are some central interfaces in the specification of the java.obexpackage. The interfaces to be described are:
� javax.obex.ClientSession
� javax.obex.Opertation
� javax.obex.HeaderSet
First an introduction to a common use of the API. Note the c attribute that is being castedis from listing 6.9.
Listing 6.10: OBEX ConnectionCl i en tS e s s i on con = ( C l i en tS e s s i on ) c ;HeaderSet hs = con . createHeaderSet ( ) ;HeaderSet re sp = con . connect ( hs ) ;
To start with the connection that was set up using the Bluetooth API is being casted to aClientSession which is an interface. The implementation I’ve chosen to code in a class
71
named ClientSessionImpl. The connect method have the following implementation (listing6.11). In the start of the method an OBEX CONNECT packet is sent. This packet is alsoillustrated by figure 6.2 in a previous section. This packet specifies e.g. what OBEX versionthat should be used. Through the ReplyReader a check is being made that the packet hasbeen sent. If the packet is sent, a reply could be expected from the remote device. The replyis read by the ReplyReader as well. If the first byte of the packet received is 0xA0 it meansthat the connection was OK, since the code is translated into an OBEX HTTP OK. However youcouldn’t be sure to receive such a packet, so the response is parsed and the code set for theHeaderSet object returned.
Listing 6.11: javax.obex.ClientSession Implementationpub l i c HeaderSet connect ( HeaderSet hs ) {
BluetoothOutputStream . p r i n t (ATX CONNECT. getBytes ( ) ) ;i f ( ! ReplyReader . readStandard ( ) [ 0 ] . regionMatches (0 , ReplyReader .OK, 0 ,
ReplyReader .OK. l ength ( ) ) )re turn nu l l ; // throw Exception
St r ing r ep ly = ReplyReader . readRX2 ( ) ;S t r i ngBu f f e r re sponse = new St r i ngBu f f e r ( ) ;r e sponse . append ( r ep ly . charAt ( 4 ) ) ;r e sponse . append ( r ep ly . charAt ( 5 ) ) ;responseCode = Ut i l . hexToInt ( re sponse . t oS t r i ng ( ) ) ;hs . setResponseCode ( responseCode ) ;r e turn hs ;}
In the source code of app using the API a common way to check the connection status isat listing 6.12. If the response is OK, you could go on with the protocol. A header packetshould be sent to the remote device, containing name of the file. Also other headers can beset for the packet, like MIME-type, length, and description etc.
Listing 6.12: Connection Status (listing 6.10 preceded)i f ( r e sp . getResponseCode ( ) != ResponseCodes .OBEX HTTP OK)
//Connection f a i l e d −> error hand l inge l s e {
hs = con . createHeaderSet ( ) ;hs . setHeader ( HeaderSet .NAME, ” t e s t . vc f ” ) ; // t h i s cou ld only be named ’ x ’hs . setHeader ( HeaderSet .TYPE, ” text /x−vcard” ) ; // t h i s wouldn ’ t be p o s s i b l eOperation op = con . put ( hs ) ;OutputStream out = op . openOutputStream ( ) ;out . wr i t e ( obj ) ;out . c l o s e ( ) ;op . c l o s e ( ) ;con . d i s connec t ( con . createHeaderSet ( ) ) ;
}
The header packet is constructed in the API the following way (listing 6.14). The packet isconstructed in a java.lang.String by use of the hex values for the individual bytes of thepacket. The packet is wrapped by the ATX command, making it ready to be executed andsent through the BISM AT command interface.
Listing 6.13: setHeader Method of the HeaderSet Interfacepub l i c void setHeader ( S t r ing header , S t r ing value ) {
i f ( tmp . l ength ( ) > 0)tmp . d e l e t e (0 , tmp . l ength ( ) ) ;
72
i f ( head . l ength ( ) > 0)head . d e l e t e (0 , head . l ength ( ) ) ;
foo = 0 ;S t r ing pseudo [ ] =
{”0” , ”1” , ”2” , ”3” , ”4” , ”5” , ”6” , ”7” , ”8” , ”9” ,”A” , ”B” , ”C” , ”D” , ”E” , ”F” } ;
i f ( va lue == nu l l | | value . l ength ( ) == 0) {tmp . append ( ”\\00\\00” ) ;foo = 2 ;
} e l s e {f o r ( i n t i = 0 ; i < value . l ength ( ) ; i++) {
byte b = ( byte ) va lue . charAt ( i ) ;i f (b >=33 && b <= 127)
tmp . append ( ( char )b ) . append ( ”\\00” ) ;e l s e {
byte ch = 0x00 ;ch = ( byte ) (b & 0xF0 ) ;ch = ( byte ) ( ch >>> 4 ) ;// s h i f t the b i t s downch = ( byte ) ( ch & 0x0F ) ;//must do t h i s i s h igh order b i t i s on !out . append ( pseudo [ ( i n t ) ch ] ) ;ch = ( byte ) (b & 0x0F ) ; // S t r i p o f fout . append ( pseudo [ ( i n t ) ch ] ) ;byteStr = out . t oS t r i ng ( ) ;out . d e l e t e (0 , out . l ength ( ) ) ;tmp . append ( byteStr ) . append ( ”\\00” ) ;
}f oo += 2 ;
}}tmp . append ( ”\\00” ) ;foo++;head . append ( ”ATX\”” ) ;head . append ( ”\\02\\00” ) ;byte in = ( byte ) ( foo +7);byte ch = 0x00 ;ch = ( byte ) ( in & 0xF0 ) ;ch = ( byte ) ( ch >>> 4 ) ;// s h i f t the b i t s downch = ( byte ) ( ch & 0x0F ) ;//must do t h i s i s h igh order b i t i s on !out . append ( pseudo [ ( i n t ) ch ] ) ;ch = ( byte ) ( in & 0x0F ) ; // S t r i p o f fout . append ( pseudo [ ( i n t ) ch ] ) ;byteStr = out . t oS t r i ng ( ) ;out . d e l e t e (0 , out . l ength ( ) ) ;head . append ( ”\\” ) . append ( byteStr ) ;head . append ( header ) ;byte in1 = ( byte ) ( ( foo +4)) ;byte ch1 = 0x00 ;ch1 = ( byte ) ( in1 & 0xF0 ) ;ch1 = ( byte ) ( ch1 >>> 4 ) ;// s h i f t the b i t s downch1 = ( byte ) ( ch1 & 0x0F ) ;//must do t h i s i s h igh order b i t i s on !out . append ( pseudo [ ( i n t ) ch1 ] ) ;ch1 = ( byte ) ( in1 & 0x0F ) ; // S t r i p o f fout . append ( pseudo [ ( i n t ) ch1 ] ) ;byteStr = out . t oS t r i ng ( ) ;out . d e l e t e (0 , out . l ength ( ) ) ;head . append ( ”\\00” ) . append ( ”\\” ) . append ( byteStr ) ;head . append ( ”\\00” ) ;head . append (tmp . t oS t r i ng ( ) ) ;head . append ( ”\”\ r ” ) ;
73
}
The put method takes the HeaderSet object as an argument, and sends the it over the serialline for the BISM to handle it. Reading the reply and parsing it comes up with a status codein form of the responseCode property of the Operation interface implementation.
Listing 6.14: put Method of the ClientSession Interfacepub l i c Operation put ( HeaderSet hs ) {
St r i ngBu f f e r re sponse = new St r i ngBu f f e r ( ) ;BluetoothOutputStream . p r i n t ( hs . getATXHeader ( ) . getBytes ( ) ) ;S t r ing [ ] s = ReplyReader . readStandard ( ) ;i f ( ! s [ s . length −1] . regionMatches (0 , ReplyReader .OK, 0 , ReplyReader .OK. l ength ( ) ) )
re turn nu l l ; // throw ExceptionSt r ing rx = ReplyReader . readRX2 ( ) ;r e sponse . append ( rx . charAt ( 4 ) ) ;r e sponse . append ( rx . charAt ( 5 ) ) ;responseCode = Ut i l . hexToInt ( re sponse . t oS t r i ng ( ) ) ;r e turn t h i s ;
}
Left is opening the java.io.OutputStream, also showed in listing 6.12, and writing the bytesof the file to the stream. The stream implementation is based on the ATX command as well.It was tested if the BISM could be set to data mode, so bytes could be sent over the link asthey where written to the serial line. This was not possible, since the bytes of the packet didnot arrive as a unit on the remote device, hence it could not be interpreted by the OBEXprotocol. The data mode feature however should be noted, for use in applications dependingon an internal protocol, since it would provide a faster data transfer. Instead OBEX packetsneeded to be assembled in a string, and sent using ATX command. The OBEX packet shouldbe of the form illustrated at figure 6.5. The first byte of the packet is the PUT code, indicating
Figure 6.5: OBEX PUT Packet[1]
”final bit set” or ”final bit not set” respectively. The packet length is how long the wholepackets is. Byte 3 is ”indication body” or ”end of body” value. If the packet is containing thelast bytes of the file, 0x49 is used, and 0x48 for the rest of the packets. The body length ishow long the data is in bytes, plus the tree bytes of the length it self and the body code (0x48or 0x49). Last are the bytes of the files. The implementation of the of the OutputStream
is at listing 6.15. The write method takes the byte array as an argument, and loops overthe bytes. A packet is constructed for each byte, since due to the limitations of the ATXcommand (34 characters). The method could be optimized a bit, since it would be possibleto send a minimum of three bytes at a time. The formal bytes of the packet would take up23 characters of the available 34, leaving 11 characters left. Since each non-visual byte wouldtake up space of tree characters it would be possible to send 3 bytes since it would take up
74
9 characters of the 11 bytes left. If one of the bytes was a visible character it would onlyuse one character, and leave more space for another byte to be sent in the same packet. Forsimplicity the write method sends one byte at a time.
Listing 6.15: OutputStream Implementationpub l i c c l a s s OutputStreamImpl extends OutputStream {
pr i va t e s t a t i c S t r ing tmp ;s t a t i c S t r ing [ ] pseudo ;s t a t i c S t r i ngBu f f e r out , data ;pub l i c void wr i t e ( byte [ ] b ) {
f o r ( i n t i = 0 ; i < b . length −1; i++) {byte b1 = ( byte ) b [ i ] ;data = new St r i ngBu f f e r ( ) ;data . append ( ”ATX\”” ) ;i f ( ! f a l s e )
data . append ( ”\\02\\00\\07\\48\\00\\04” ) ;e l s e
data . append ( ”\\82\\00\\07\\49\\00\\04” ) ;data . append ( ”\\” ) ;byte ch = 0x00 ;pseudo = new St r ing [ ]{”0” , ”1” , ”2” , ”3” , ”4” , ”5” , ”6” , ”7” , ”8” , ”9” ,”A” , ”B” , ”C” , ”D” , ”E” , ”F” } ;out = new St r i ngBu f f e r ( ) ;ch = ( byte ) ( b1 & 0xF0 ) ;ch = ( byte ) ( ch >>> 4 ) ;// s h i f t the b i t s downch = ( byte ) ( ch & 0x0F ) ;//must do t h i s i s h igh order b i t i s on !out . append ( pseudo [ ( i n t ) ch ] ) ;ch = ( byte ) ( b1 & 0x0F ) ; // S t r i p o f fout . append ( pseudo [ ( i n t ) ch ] ) ;S t r ing hexByteStr = out . t oS t r i ng ( ) ;data . append ( hexByteStr ) ;data . append ( ”\”\ r ” ) ;tmp = data . t oS t r i ng ( ) ;BluetoothOutputStream . p r i n t (tmp . getBytes ( ) ) ;i f ( ! ReplyReader . readStandard ( ) [ 1 ] . regionMatches (0 , ReplyReader .OK, 0 ,
ReplyReader .OK. l ength ( ) ) )re turn ; // throw Exception
i f ( ! ReplyReader . readRX2 ( ) . regionMatches (0 , ReplyReader .RX CONTINUE, 0 ,ReplyReader .RX CONTINUE. l ength ( ) ) )re turn ; // throw Exception
//ReplyReader . readStandard ( ) ;//ReplyReader . readRX2 ( ) ;
}byte b1 = ( byte ) b [ b . length −1] ;data = new St r i ngBu f f e r ( ) ;data . append ( ”ATX\”” ) ;i f ( ! t rue )
data . append ( ”\\02\\00\\07\\48\\00\\04” ) ;e l s e
data . append ( ”\\82\\00\\07\\49\\00\\04” ) ;data . append ( ”\\” ) ;byte ch = 0x00 ;out = new St r i ngBu f f e r ( ) ;ch = ( byte ) ( b1 & 0xF0 ) ;ch = ( byte ) ( ch >>> 4 ) ;// s h i f t the b i t s downch = ( byte ) ( ch & 0x0F ) ;//must do t h i s i s h igh order b i t i s on !out . append ( pseudo [ ( i n t ) ch ] ) ;ch = ( byte ) ( b1 & 0x0F ) ; // S t r i p o f f
75
out . append ( pseudo [ ( i n t ) ch ] ) ;S t r ing hexByteStr = out . t oS t r i ng ( ) ;data . append ( hexByteStr ) ;data . append ( ”\”\ r ” ) ;tmp = data . t oS t r i ng ( ) ;BluetoothOutputStream . p r i n t (tmp . getBytes ( ) ) ;i f ( ! ReplyReader . readStandard ( ) [ 1 ] . regionMatches (0 , ReplyReader .OK, 0 ,
ReplyReader .OK. l ength ( ) ) )re turn ; // throw Exception
i f ( ! ReplyReader . readRX2 ( ) . regionMatches (0 , ReplyReader .RX OK, 0 ,ReplyReader .RX OK. l ength ( ) ) )re turn ; // throw Exception
//ReplyReader . readStandard ( ) ;//ReplyReader . readRX2 ( ) ;
}// . . .
The last lines of code in listing 6.12 is closing the OutputStream and the Connection. Theclose methods I’ve implemented to be JSR-82 compatible, but the body of the methodsare empty. This however is quick-and-dirty solution. Some internal attribute could be setto identify if the connection/stream was open or not. Regarding the disconnect, which isthe last operation in the OBEX example, it has been implemented in with equality to theconnect method (see listing 6.11).
6.4 GAP Analysis
Table 6.2 provides an overview of the missing implementations, and deviation from JSR-82specification. The notes for the table give an description of the issues, and why the deviationfound place.
6.4.1 Note 1
It’s only possible to use the API to initiate the connection establishment of a link, not set upa channel that other can connect to. It would be possible to accept for incoming connections,by use of the ATA command [13], but the <cr,lf>RING 123456789012<cr,lf> send fromthe BISM every second, indicating an incoming call, could garble with the reading of otherreplies. So it would be possible to implement the API part, letting JOP be the server, butsome mechanism of filtering the ring replies etc. should be implemented.
6.4.2 Note 2
There is no cache of pre-discovered devices. Instead of using the DiscoveryListener.GIAC
parameter for inquiry the DiscoveryListener.CACHE could be used to only retrieve pre-
76
GAP Category Location Comment
JSR-82 Server Boundaries javax.bluetooth.*; Note 1
Cached devices Missing javax.bluetooth.DiscoveryAgent Note 2
Service record Different javax.bluetooth.ServiceRecord Note 3
Attribute set Missing javax.bluetooth.DataElement Note 3
UUID Different javax.bluetooth.UUID Note 4
Device class Different javax.bluetooth.DeviceClass Note 5
Cancel device discovery Not working javax.bluetooth.DiscoveryAgent Note 6
Cancel service search Not working javax.bluetooth.DiscoveryAgent Note 6
Exceptions Different javax.bluetooth.BluetoothStateException Note 7
Table 6.2: GAP Analysis
discovered devices. It could be implemented, but some communication with the inquirythread (listing 6.4) and the startInquiry method should be established.
6.4.3 Note 3
When searching for services on remote device it could be specified, what kind of attributesthe returned javax.bluetooth.ServiceRecord should contain. The BISM doesn’t makethis option implementable, since the data of a service search is limited to a service presence.Instead the javax.bluetooth.ServiceRecord is implemented using a string instead, andthe javax.bluetooth.DataElement holding the attribute values are left out of this APIimplementation.
6.4.4 Note 4
The constructor of UUID class would normally take a long value as an argument, but I’veimplemented it using a String instead. Since the reply from the BISM for the UUID of aservice would be a String, due to facts of Note 3.
77
6.4.5 Note 5
The DeviceClass parameter of the DiscoveryListener .deviceDiscovered interface methodis implemented as an String, instead of an DeviceClass object. The DeviceClass could beimplemented, by parsing the String and setting the major and minor device class values ofthe object. There 32 major categories spreading from Computer, to Phone, to Toy etc. Minorclasses within the Computer Major Class are Laptop, Server-class computer, and HandheldPC/PDA (clam shell) etc. It would indeed be attractable to implement the DeviceClass.
6.4.6 Note 6
The methods cancelServiceSearch and cancelInquiry of the DiscoveryAgent class is notworking. The implementations are empty method bodies, since it’s not possible to stop theBISM doing these tasks, once they are started. The method returns false as standard whenthey are called, since it will not stop the BISM from performing the tasks.
6.4.7 Note 7
Exceptions are not implemented in the API. Instead if an error occurs for a connectionestablishment etc. the object in question will be set to null. A check can be made afterwardsto see if the operation was successful or not.
6.5 Debugging made difficult
On JOP when using BISM you have to sent debugging info over UDP. This makes the JOPa bit more complicated then you would be use to. Another problem is that when debuggingover UDP you are not sure of receiving all the info, since UDP is not transport safe. Somaybe you would expect some info, but maybe the UDP packet was sent, but not received,or maybe the packet wasn’t sent at all, since the line of code was never run. So you got theseextra factors in the game. Furthermore, info like exceptions and other errors (byte code notimplemented, memory failure etc.) cannot be sent over UDP, but only by use of the serialline. But since the port is occupied by the BISM this kind of info is just something you cannotmake use of when developing with the BISM on JOP. This has been one of the reasons whythe implementation of the JSR-82 has been a hard job to do, but also it will influence futureJOP developers that want to make use of the BISM module and the JSR-82 implementation.The issue could be addressed, by extending JOP with another serial line, one for debuggingand one for the adapter, but it is out of the bounds for this project to extend JOP in this
78
kind of way. However it could be useful for future project to build another serial line, beforemaking use of the API implementation and the BISM. I think that the time given will comeback, and also benefit other JOP developers in the community.
6.6 Sourceforge.net Project
For others to be able to use and benefit from the developed Bluetooth API for JOP, ithas been made available at Sourceforge.net. The project UNIX name is blueonjop, andthe associated website http://blueonjop.sourceforge.net provide the needed documentationto download, and use the API for JOP applications.
Figure 6.6: blueonjop Website at Sourceforge.net
6.7 Summery
In this chapter the implementation of the core classes was described in regards to both JSR-82 and the optional part for OBEX communication (the javax.obex package). The reviewof the implementation, provide a description on how to use the API, and a description of theAPI code the usage involve. The GAP analysis provides a clear documentation of what isimplemented, what isn’t, and what is different from the JSR-82.
79
Chapter 7
Test of the API
Having written the code to form the API, the code should be tested. Documentation is akey aspect, since the API is meant for others to use and rely on it. Just as debugging havenot been so strait forward, testing also seems a bit harder. All this because of the missingserial line to send information to printed in the prompt of a PC.
To overcome the difficulties, the test environment consist a JOP application using the Blue-tooth API, and a PC. The PC will ask JOP to do different kinds of test cases. The requestis based on UDP. JOP executes the following sections of code, and logs the information. Theinformation is then pushed to the PC, printing the info, over UDP.
The test is based in the black box principles. The code used in the test cases is the two appli-cations running on the PC: UDPBomber and UDPLogger. On JOP the test.MyBluetoothApp
is running.
7.1 Device Discovery Test
7.1.1 No devices in range
To start with, a test of the inquiry process is made. An inquiry is made, and no Bluetoothdevices are in range (I’ve haven’t turned any on). The API is expected to do the inquiry,and to see if any reply on the inquiry packets sent out. If no device is discovered, only theinquiryCompleted(int, int) should be invoked of the DiscoverListener interface.
80
Figure 7.1: No Devices In Range
Figure 7.1 shows the result, which is as expected. No devices are discovered, and theinquiryCompleted(int, int) method is invoked with a status code, indicating no errors.Prior to the status code the string ”I know you” is printed. To test if JOP is ready, and theapplication loaded, a test packet is sent to JOP, to see if it receives the UDP packet. Whenthe test packet is received, JOP replies with a packet to the PC containing the string ”I knowyou”. This is also used in the remaining test cases.
7.1.2 Devices in range
To discover remote devices in range is a core functionality of Bluetooth. The test case wasrun with at least one device in range (I could not be sure no other devices were in range).Upon calling the startInquiry method of DiscoveryAgent class, it would be expected thatthe agent will send the found devices to the implementation of deviceDiscovered method ofthe DiscoveryListener interface. If devices were found, the inquiryCompleted should becalled upon end of the inquiry process, with the INQUIRY COMPLETED status code.
Figure 7.2 shows the output of the inquiry. To devices were found, the one expectedand another device also in range. The result is as expected, also the status code match theexpected value.
81
Figure 7.2: Inquiry And Service Search Output
7.2 Service Search Test
7.2.1 Device not reachable
It would be desired to see how the API would act, when a service search was initialized ona device not being turned on, or just out of range. Figure 7.2 also hold this information.The service search was initialized after the Bluetooth was turned off on the device (friendlyname KH-Mobile). The expected result would be that no services should be found, and thestatus code for completion would be SERVICE SEARCH DEVICE NOT REACHABLE. The result isas expected.
7.2.2 UUID list with not supported service
Can the API handle to search upon a service that a device doesn’t support? This is tested inthis case. The service search was initialized with UUIDs: 0x1101, 0x1105 and not supported0x1117. The search finds the two supported services (SPP and OBEX Push Profile). Theservice not expected to be supported (0x1117) is not found (see figure 7.3).
7.3 Connection and OBEX Push Profile
7.3.1 Bluetooth Connect/Disconnect, OBEX Push
To start with a normal usage that was expected to work was run. Since the OBEX headerpacket is limited, the name of the file pushed was ”a” (one character). Figure 7.4 shows
82
Figure 7.3: Service Search Output
the output of the case. The Bluetooth connection is set up and OBEX header, and file waspushed to the mobile phone used in the test case.
Figure 7.4: Bluetooth Connect/Disconnect, OBEX Push Output
7.3.2 Connect To Device Out Of Range
When connecting to a device out of range. The JSR-82 specifies that an exception shouldbe thrown. The Bluetooth API for JOP used another approach by setting the object tonull. A check can be made to see if the connection has been established, or of null an erroroccurred. Figure 7.5 shows the output of connecting to a device not in range. The test codehas a check of the Connection object, and if it’s null further code is not run. The resultis as expected, an object with no reference is returned, indicating an error upon connectionestablishment.
83
Figure 7.5: Connect To Device Out Of Range Output
7.3.3 Push File To Device Out Range (prior in range)
A test case where the device starts to be within range, and then moves out of range ispredicable. How would this be handled by the API? If the Bluetooth connection is shut downbefore the OBEX connect operation is performed, an exception should be thrown accordingto the JSR-82. As in section 7.3.2, the Bluetooth API for JOP would set the object to null
instead. Figure 7.6 is the outputs of a mis-accomplished OBEX connect operation. Instead
Figure 7.6: Push File To Device Out Of Range Output
of throwing an exception the Operation object to be used to perform the PUT operation,and output stream, is set to null.
7.3.4 File not accepted by user
Another case, would be the user not accepting the file to be pushed. This would result in theexpected HTTP OBEX CONTINUE not to be sent back from the server. Figure 7.7 shows the out-put of the test case. As expected the check on the response code coursed the communication
84
Figure 7.7: File Not Accepted By User Output
the break, and go on to disconnection of the link.
7.3.5 Too long OBEX header
One of the restrictions of the API, is the length of the OBEX packets (see figure 6.3). Whatwould happen if you set name of a file longer than the ATX command could handle. The
Figure 7.8: Too Long OBEX Header Output
output (figure 7.8) shows the result, and how the API would react. It’s possible to constructa packet that would be too long. The PUT operation of OBEX protocol would not beaccomplished, resulting in the Operation object to be null. The exception/null referenceis also the case here, but the API handle the case as expected.
85
Chapter 8
Bluetooth and Marketing
To bring in a business perspective on the project and the Bluetooth/embedded system pair,this chapter will examine business cases, and look into what makes Bluetooth marketingvaluable. Companies are beginning to prioritize Mobile Marketing in a higher level than seenbefore. Mobile services are the media in most progress due to budgets for 2007 (see figure8.1). Although the focus is on communication through SMS, as the article1, where the index
Figure 8.1: Mobile Services in Progress
is published states the marketing is moving towards the mobile phones. The article states
1Børsen 10. january 2007, Annoncører tænder for mobilen
86
that it becomes interesting when you can use mobile marketing for location based marketing.The fact that mobile marketing is in progress, and that location based services are interestingsets Bluetooth marketing in favorable position in the years to come, if the progress continues.
8.1 Type of Systems
The Bluetooth technology is integrated into many mobile phones these days. Therefore manypeople carry around a Bluetooth device. The potential of Bluetooth systems are increasingas the Bluetooth technology is being adopted by the users. A Bluetooth device support arange of profiles, also know as services. These services are integrated into the device, and noadditional software is required. This makes it very accessible to users. However the profilesare not the only option for building Bluetooth systems. Software can be developed, to bedownloaded on the device to provide detailed information system using Bluetooth for wirelesscommunication. The systems can be designed to fulfill special needs and requirements.Pictures of example systems are from the http://www.blipsystems.com website.
8.1.1 Ski Centre
Example of a customized system is found at the Vr̊adal alpine ski centre. Users of the ski
Figure 8.2: Graphic User Interface
centre have the opportunity to download an application on their mobile device (for free). Theapplication will provide them with information regarding the local weather forecast, activitiesduring the stay, and special offers from the shops. The information gets updated through
87
the Bluetooth network. Not only is the info updated, but the location based awareness ofBluetooth makes it possible to transfer specific messages, based on the location of the user.Figure 8.2 shows the graphical user interface of the system.
8.1.2 Fiat Trade Show
A case where the built-in profiles are utilized is the Fiat car manufacturer. At a trades showthey sat up an interactive zone based on Bluetooth. With four different touch points on awall, visitors of the stand could receive digital content on their Bluetooth device. Dependenton the touch point, the Bluetooth device was held up against, content was pushed. Onetouch point resulted in the push of a calendar date for the release of the new Fiat Punto.Also a video clip of the Punto, the Fiat logo, and other images were available. The touchpoints are showed at figure 8.3. The interactive zone differentiates Fait from the other car
Figure 8.3: Fiat Opt-in
manufacturers at the show. Resulting in a more valuable marketing, while visitors of theshow would more likely remember the Punto, than a competitor brand. A side effect isthat the downloaded video clip is likely to be redistributed to the friends of the visitors.The phenomenon of customers giving on messages, also known as Viral Marketing will beinvestigated in section 8.4.
8.1.3 Mall Marketing
The Gateway mall in South Africa, is a Bluetooth enabled mall. The innovative mall deployeda Bluetooth marketing system that average 1.3 million monthly visitors can experience. Blip-System is the one behind the system that has been integrated into the mall. The system
88
provides the shoppers with information on upcoming events, to specific store specials, andpromotions. Also Bluetooth store specific vouchers are being sent out, a way to make con-sumers adopt the systems. Once there is something in it for them, they see the opportunities.
Figure 8.4: The Gateway Mall
BlipSystem is not the only hardware/software providers on the market of Bluetooth mar-keting. Also the company at www.futurlink.com has the hardware and software suite, toarrange campaigns etc. for a mall marketing system. At their website they provide a widerange of usage scenarios of their system.
Examples fields of usage are; Tourist zones, hotels, shopping centers, public transporta-tion, museums, and sport events. The field of application is so wide, and I believe manymore could be added to the list.
8.2 System Categorization
Based on the systems identified a categorization could be stated. Based on the complexityof the system, and the use of customized software making up the system.
Simple System is a system that utilize a profile of the Bluetooth device. The systeminteracts with the device through the standard interface. The system have simplebusiness logic of sending information in standard formats to the Bluetooth device.
Complex System categorize systems, that utilize the standard interface of the Bluetoothdevice, as the Simple System does. However the Complex System have a more advancedbusiness logic hidden behind the scenes. The logic could be campaigns targeted towardsspecific consumers, or supplying consumers with supplementary products in a shop.Since the Complex Systems utilize standard interfaces, also standard media formatsare used.
89
Customized System is the category where systems fully customized fit in. Software isdesigned both to run on the remote device, and on the server side. A standard profilecould be used to transfer data, but the channel is set up within a customized appli-cation. But also, and more likely, the system utilizes a protocol of its own, based ona low level protocol like the Serial Port Profile. The format of the media/informationto be transferred could be a standard, but dependent of interoperability with otherapplications a self designed format could be used.
8.2.1 JOP/BISM Pair Support of Systems
These tree categories with different characteristics is interesting to match up against the APIdeveloped in this project, to see what the API supports.
The Simple System is basically what the prototype would be placed. The API supportsit regards to the OBEX Push Profile. So the use of a standard service is supported. How-ever, OBEX Push Profile is the only profile supported at this moment, as no profiles wererequired by the JSR-82. An issue however is the naming convention of standard file formats,and how a mobile phone interprets them. Since a file cannot be named e.g. <something>.pdfdue to the header restrictions of the JOP/BISM pair (see figure 6.3), a mobile phone receiv-ing the document cannot identify the file as a Portable Document Format. It’s the sameissue when it comes to content type like image/jpeg for an image or text/x-vcard for aelectronic business card, that a system could also act upon. However the header packet willjust be too long for BISM to send.
A Complex System have the same requirements as the simple system when it comes tothe interaction with the Bluetooth node. So the API support it in the same degree as theSimple System. The business logic on the server part of the system will also be possible toimplement in any case. JOP is able to communicate through an Ethernet interface with acentral server, or other JOP nodes, but will also be able to compute decentralized businesslogic.
The Customized System hasn’t been in focus in this project, since much effort have beenput into the OBEX protocol. Little requirements are put on the API, since connection estab-lishment and disconnection are the only jobs to handle by the API. The communication inbetween is up to the given implementation of the Customized System. BISM can be set intodata mode which provides a faster rate of transfer, since data isn’t wrapped in AT commands.An advantage that isn’t possible when using e.g. OBEX. The API developed supports thiscommunication, but the connection establishment should be initialized by JOP/BISM. Fur-ther development of the API would make it possible for making remote nodes able to connectto a channel set up by JOP.
90
8.3 Pros and Cons
As with any channel for marketing there are pros and cons attached. Assessment of the factswill make it possible for a company to decide if they could benefit from Bluetooth marketing.
8.3.1 Pros
Expansion of Marketing Mix: It would be possible to expand the current mix of mar-keting channels, and be able to reach a new market segment. The combination oftraditional marketing channels and Bluetooth makes it possible for an untraditionalapproach to attract attention of the consumer.
Context/location relevant: Companies would be able to provide a more context and lo-cation aware marketing that the mass media isn’t capable of. The local shop wouldbe able to advertise as consumers are walking by, or consumers could be informed ofsupplementary products when looking at products in a shop.
Time relevant: The Bluetooth technology is time relevant, as commercials could be pushedto affect impulse buying.
Interactivity (possible): When applications are downloaded to run on user devices, inter-activity is possible. To make it more fun, or valuable for the user.
No variable cost: The Bluetooth net is free, since no operators are involved. Marketingby SMS or WAP place costs on the consumer, the company, or even both of them.
Lower power consumption: The built-in power modes of Bluetooth makes the technologyideal for mobile devices, saving battery power for longer life time.
Fast data transfer (1 Mbps) [21]: Content like movie clips and audio could be trans-ferred in an instant.
Bluetooth services attracts customers to the location: Since the customers needs tobe on-site to use Bluetooth services they will be near the e.g. company store. If MP3song is being sent out for free, the consumers need to be near the shop, and maybemotivating them to make a buy. Instead of them being at their home, when receivingthe offer.
8.3.2 Cons
User behaviour bias: There will always be some bias for a new technology/innovation tobe adopted.
91
Fixed cost: There are fixed cost connected to the establishment of a Bluetooth networkthat might hold small budget companies from establishing such a network.
Time for connection establishment (10.24 sec.)[5]: In some cases the time spent oninquiry will be too long. As the device will come out of range in just a few seconds.However research has showed that the inquiry time can be significant reduced (seesection 4.3.2).
Less information about the user than by SMS: On SMS you got phone number of theuser. The telephone companies sell information about their costumers. With Bluetooththat’s not possible. However you are able to retrieve some important information, likethe device vendor/model (by Blueprinting), and you might be able to associate someadditional information to the unique BD ADDR of the device to keep track of theconsumer. This however should be dealt within the frames of the law (see section8.6.2).
Location dependent: A company like the insurance company Nykredit will have a difficulttime in branding themselves by Bluetooth services (not so many people come near bythe HQ). Although they can rent a spot at Støget (shopping street at the heart ofCopenhagen). So you could predict an industry for this kind of hosting.
8.3.3 Cons in General
When it comes to mobile marketing in general (like SMS or Bluetooth) there are some consthat project.
Law for consumer protection: Of course there are some restrictions by law made to pro-tect the consumers. We should all be happy about the law since we do not wantadvertising to be a jungle. The marketing law is examined in section 8.6 to see what ispossible for a Bluetooth system within the law.
Limited user interfaces for user devices: Most mobile devices have very bad user actionoperability. This of course affects how systems for marketing should be built.
8.4 Viral Marketing
The concept of Viral Marketing, I think would be one of the key benefits from using theBluetooth technology for marketing. This is why companies should consider Bluetooth intheir marketing strategies.
92
Viral marketing describes any strategy that encourages individuals to pass on amarketing message to others, creating the potential for exponential growth in themessage’s exposure and influence2.
Viral Marketing has been very popular in on the internet over the years. It all started whenHotmail.com added a tag to the e-mails sent by the users of the account. This way Hot-mail.com could just sit back and let their users do the marketing. The concept has beenspreading to all industries, and in different forms. You might have received an e-mail fromone of your friends, or a colleague with link to some funny/cool/sexy video clip, actuallybeing some commercial for a car manufacturer or beer brand etc.
I’ve experienced a number of times where friends of mine tell me to turn on Bluetoothon my mobile phone. They want to send me a funny video clip, or a sound, that the receivedfrom one other they know. So the concept is spreading from the internet to the mobilephones and other Bluetooth devices. Originally, I do not think the content was pushed overBluetooth, but download from the internet, and transferred to their mobile phones. But ifpeople find it funny to give on messages to their friends over Bluetooth, I do not think thebias is very big, for Bluetooth marketing to catch on.
There are a number of characteristics for Viral Marketing3.
1. Gives away products or services
2. Provides for effortless transfer to others
3. Scales easily from small to very large
4. Exploits common motivations and behaviors
5. Utilizes existing communication networks
6. Takes advantage of others’ resources
These items outline that Bluetooth marketing could be used in a strategy for Viral Marketing.The bullets very much match the Bluetooth technology. Companies who have been using aviral approach to marketing, I think we will see using Bluetooth for spreading their messagein the near future.
2http://www.carmelwebdesigns.com/gettingStarted/Viral Marketing Strategies.php3http://www.wilsonweb.com/wmt5/viral-principles.htm
93
8.5 Market Survey
A simple market survey will help indicate if Bluetooth marketing is likely to be adopted bythe consumers. In general the position is that the ring tone services offered today are toexpensive (figure 8.5). So the pricing might keep consumers from requesting content for theirmobile phones. This is exactly what can be concluded from figure 8.6. People would use
Figure 8.5: Question 1
a service more if it was for free. This is an important peace of information. In regards toViral Marketing where one of the keys to success is giving away products or services, this isa factor in favor of the use Bluetooth, since no cost is put on the consumer.
8.6 Marketing Law
One important aspect is the marketing law. To use Bluetooth as for marketing, it would haveto fit under the current law for consumer protection. Danish law states that a company wouldneed permission by the consumer to make contact (with a sale in mind) to a consumer, by useof electronic mail4. So there are some legal matters to consider in order to deploy a Bluetoothmarketing system. To come up with solution on how a system should be implemented I’vehad a meeting with the law graduate working for the Danish Consumer Council. A summeryof the meeting is at appendix B.
4Marketing law section 6
94
Figure 8.6: Question 2
8.6.1 How is permission achieved?
One thing is for sure. The model should be opt-in, where consumers have the option to getinformation/advertisements, and it should be easy for the consumers to sign off a service.Only one or two products or companies could be covered by the same permission from theconsumer.
The permission could be achieved by a physical act of the consumer putting the phone neara hot-zone, like the Fiat case section 8.1.2. In a mall or places where the consumer come bymore than once, a may be a good idea to set up a stand were consumer can register to re-ceive advertisements from selected stores. The terms should be clear to consumer in all cases,but this way stores will be able to push content without the consumer physically requesting it.
Another approach that would be sufficient for a permission would be would be if the con-sumer named the Bluetooth device (the friendly name) e.g. Ikea to receive content fromthe company Ikea. It would be easy for the consumer to sign off again, just by selectinga different name for the device. The companies could advertise for keywords that could beused, in order to make the permission to span product categories etc.
95
8.6.2 Tracking The Consumer
It would be very beneficial to keep track of the consumer, by use the unique BD ADDR. Howeverthis is not legal, at first hand. Information about the consumer may not be stored, andmerged with data from other companies to extend the knowledge of an individual consumer.Information acknowledged through the Bluetooth technology should be treated the same way,or even more restricted, as with marketplaces on the web and IP addresses. Treatment shouldbe more restricted because of the static unique physical address of the Bluetooth device thanof an, in some cases, dynamic IP address.
8.6.3 Ethics
The ethics are important, also when it comes to Viral Marketing. By Viral Marketing thecontent will fly around potentially affecting consumers who do not desire the content. Themarketing law doesn’t protect consumers sending messages to consumers, so the companiesshould have a code of ethics to prevent consumers being offended.
8.7 Down-side risk
The downside risk of marketing by Bluetooth may also be considered. Of course there is riskof consumers are feeling they are being spammed. Therefore I think it should be consideredvery well where and in what cases the technology would be useful. Another thing, beingimportant is to inform the users, so they get what they expect. If the consumers are notaware of what they go into, I’m sure the threshold for them feeling spammed is much lowerthan if they are aware of volume and content sent to them.
Recently there has been bad publicity about mobile services. Service providers have beencharging to much according to the law. You can only charge 12.00 DKK per day per phonenumber, but it has been practice not to follow the consumer protection law. Also very badquality of service has been an issue. Consumers are not able to download what they paid for.The Danish TV program ”Kontant” has documented this, and only 50 pct. of the downloadspayed for actually got to the phone. You could predict some scepticism by consumers to startwith. Consumers might think, why are they giving away valuable content for free? There issomething wrong here! Maybe it’s not free after all, and I will be billed on my monthly phonebill. However, when people become more familiar with the Bluetooth technology, I think thisbias is of no concern.
96
8.8 Summery
The Bluetooth technology was original intended for wire replacement between headsets andmobile phones etc. However the functionality of the protocol makes it possible to use thetechnology for a lot more. Information systems can be built that use the technology in amore a versatile fashion. Looking into the systems currently being developed, there is a trendthat Bluetooth is used for marketing applications, utilizing existing Bluetooth profiles, butalso enhance information and functionality by designing applications to run on user devices.
On the Internet, companies have put effort into supporting Viral Marketing. The valueof word of mouth is so important to companies, since it has great influence on the persons re-ceiving a message. By using Bluetooth to send out marketing messages, there is the technicalbasis for a message to be forwarded to other consumers. However, the challenge is producingthe right message (video clip or other media) that have the value to initiate it to be sent on.
97
Chapter 9
Prototype Development
A prototype of a system will not only provide a test of the API, but also contribute to asan example for developers how to get started writing Bluetooth applications. The prototypeis a system to be used for Bluetooth marketing. The system will be able to push files to aremote device, by use of the OBEX protocol, that most Bluetooth enabled mobile phonesetc. support. Figure 9.1 gives a conceptual overview of the system. Devices within range(approximately 10m for device class 3) are discovered by the application running on JOP,and a file is pushed to a device if the user initiates the transfer by placing the phone nearJOP (the user give permission). Afterwards, during the file transfer the user can walk withinthe range of the transceivers.
9.1 Data Flow Analysis
The data flow diagram at figure 9.2 shows the processes of the prototype. The inquiry processis where the application discover remote devices. If a device or several devices are discoveredit will result in a connection attempt for the first device discovered. Since it is quicker totry to connect to a service than performing the service discovery to see if the OBEX pro-file is supported, the connect is used. If the service isn’t present the BISM will reply withNO CARRIER. And inquiry will be performed again.
The RSSI value is tested to see if permission is given by the user holding the remote de-vice. If there is permission a file is transferred, and afterwards the connection is shut down.If the device isn’t close, disconnection will occur. On disconnect the BISM will reply withNO CARRIER, and the go on with inquiry routine.
98
Figure 9.1: Architectural Overview
The application should run for an indefinite time, but the System.exit(0) event illustratethe end of the application, for example when the power is turned off.
The implementation (Java source code) of the prototype is at appendix F.
99
Figure 9.2: Data Flow Analysis
100
Chapter 10
Conclusion
The work of this project has two key areas, the Bluetooth technology and embedded systems.The technical task was to combine the two areas, and extend an embedded system to be ableto communicate wireless by use of Bluetooth. Also it has been examined how Bluetoothtechnology is suited for embedded systems.
Bluetooth is suited for embedded systems, and many devices are manufactured with a Blue-tooth radio, and built-in service profiles. The technology in its self is suited for embeddedsystems, as many features are appealing in contrast to IrDA, that have been used earlier forwireless transfer on e.g. mobile phones. The transfer rate, power consumption, inquiry/ser-vice discovery procedures, and no need for line of sight operation, are features making Blue-tooth an attractive technology. Furthermore it has an open specification, and the cooperationbetween manufacturers is why the technology has been diffused, and is made valuable to theconsumers using it.
On the con side, the technology have some issues, although they do not shine as muchthrough as the pros. Inquiry time might be too long for some applications to fully function.And the aspect of security is also a con, but this is not a technology issue rather an imple-mentation issue of too short PINs, due to limited user/device interaction. The cons do notweight that much when it comes to Bluetooth and embedded systems.
The diffusion of Bluetooth and wide range of devices supporting Bluetooth makes the tech-nology compelling when developing new systems. Since the support is wide, also of standardprofiles, you should think of Bluetooth when developing a new system (embedded). Thereare allot of possibilities for user interactions, and information transfer in context of embed-ded systems (for example a mobile phone and a coffee machine). Incorporating a Bluetoothinterface as a part of new system makes it possible for users to interact with devices remotely
101
and ground-breaking fashion.
JOP has been extended with Bluetooth, by use the BISM, and an API was developed toease use of Bluetooth in applications. The API conform to the JSR-82, which makes it easierfor developers write Bluetooth applications, since it is a standard way for Java applicationsto interact with Bluetooth. Information and tutorials are easy to find in books and on theInternet in regards to JSR-82. Also a Java/Bluetooth applications written for a PC shouldbe able to be ported to JOP, since Java is (or should be) platform independent. The imple-mentation is made as close as possible to the specification, but little is different for the JOPimplementation. These differences have been stated in the GAP analysis (section 6.4). TheAPI can be downloaded from the website1, created under the Sourceforge project, and usedfreely for future JOP developers.
10.1 Future Work
Regarding the Bluetooth extension of JOP, the API has made it possible to use Bluetooth inJOP context. However there is work to be done regarding the implementation of the serverside of the API. Since the project is at Sourceforge developers can register to work on theAPI in the spirit of open source.
It could be considered to look for other Bluetooth modules instead of BISM, since it donot make it possible for fully OBEX support in regards to the API. The BISM is controlledthrough an AT interface, but alternative of modules could be researched to get further knowl-edge on how to Bluetooth extend JOP.
1http://blueonjop.sourceforge.net
102
Appendix A
Bluetooth API References
To support table in the report, the following references are provided.
API ReferenceHarald http://www.control.lth.se/∼johane/harald/aveLink http://www.avelink.comJavaBluetooth http://www.javabluetooth.orgavetanaBluetooth http://www.avetana-gmbh.deBlueCove http://sourceforge.net/projects/bluecove/JBluez http://jbluez.sourceforge.netImpronto DK http://www.rococosoft.com/blue dk.html
103
Appendix B
Summery of meeting with law
graduate, Anette Høyrup
Date: 6/12/2006
Danish Consumer Council (Forbrugerr̊adet in Danish), FBR for short, state they are notscared of technology in general. They think a Mobile Marketing solution based on the Blue-tooth technology should be available for those consumers who desire the service.
A 100 pct. opt-in model according to the law is supported by FBR, instead of an optout model that would, unwanted, enter the personal life of the consumers.
FBR encourage a technological solution where consumers can cut off any connection to thecompanies broadcasting Mobile Marketing content. Also consumers should be able to cutoff, or momentarily turn off, connections to individual companies and still be able to receivecontent from other providers.
Permission is always required by the consumer and the terms should be very clear, con-crete as possible, and visible! Permission can be achieved by the physical act of puttingthe phone very close to a marked spot, or placing the phone in a stand. Technical theact can be determined by testing the received signal strength of remote devices. Howeverthe test should be very precise, so that content will not be pushed to consumers just passingnear by sensor. In fact, no consumer should be pushed content without the initial permission.
No more than one or two products or companies should be covered within the same per-mission. It should be made clear beforehand that the content pushed to e.g. the mobile
104
phone is an advertisement, no hidden messages are allowed.
Signing off or withdrawing a permission should be made easy for the consumer e.g. a textmessage (SMS) and with no charge of a fee.
Regarding data persistency no identification should be possible, so that companies can mergeand process data to extend their knowledge of the individual consumer. Information ac-knowledged through the Bluetooth technology should be treated the same way, or even morerestricted, as with marketplaces on the web and IP addresses. Treatment should be morerestricted because of the static unique physical address of the Bluetooth device than of an,in some cases, dynamic IP address.
Lastly, in context to Viral Marketing and in general, companies should act ethically whenbroadcasting content in respect of consumer rights.
105
Appendix C
Blueprinting Example
This is a calculation of the Blueprint hash. I’ve retrieved some info by use BTScanner1, aJava tool under GPL. Since the PSM value is not retrievable through Java I made use ofthe sdptool browse --tree 00:12:EE:46:DO:C0 command on Linux to get a hold on thePSM value for the Mouse And Keybord profile. Table C.1 show the calculation.
The final result of the hash with prefix etc. is 0012EE@5047463.
1download at http://www.pentest.co.uk/
106
n Profile Record Handle (R) Channel or PSM (C) Rn × Cn
1 Dail-up Networking 0x10000 1 65536
2 HS Voice Gateway 0x10002 4 262152
3 Serial Port 0x10003 2 131078
4 Serial Port2 0x10004 3 196620
5 Object Push 0x10005 6 393246
6 OBEX IrMC Sync Server 0x10006 8 524336
7 OBEX Basic Imaging 0x1000A 9 589914
8 OBEX File Transfer 0x1000D 7 458843
9 HF Voice Gateway 0x1000E 5 327750
10 OBEX SyncML Client 0x10018 15 983400
11 Service Name Unknown 0x1001B - -
12 Mouse And Keybord 0x1001C 17 1114588∑5047463
Table C.1: Blueprinting of Sony Ericsson K700i
107
Appendix D
OBEX Over SPP Using
AvetanaOBEX
Listing D.1: ObexExample.java Sourcecode
import java . i o . OutputStream ;
import javax . m i c ro ed i t i on . i o . Connector ;
import javax . obex . C l i e n tS e s s i on ;
import javax . obex . HeaderSet ;
import javax . obex . Operation ;
import javax . obex . ResponseCodes ;
pub l i c c l a s s ObexExample {
pub l i c void main ( St r ing [ ] a rgs ) throws Exception {
St r ing vCard =
”BEGIN:VCARD\n” +
”VERSION: 2 . 1 \ n” +
”N: Hansen ; Kasper\n” +
”EMAIL;PREF;INTERNET: kaha01ae@student . cbs . dk\n” +
”REV:20060227T201446Z\n” +
”END:VCARD” ;
byte [ ] obj = vCard . getBytes ( ) ;
C l i e n tS e s s i on con =
( C l i en tS e s s i on )
Connector . open ( ”btgoep ://0012 ee46d0c0 : 6 ” ) ;
108
HeaderSet hs = con . createHeaderSet ( ) ;
HeaderSet re sp = con . connect ( hs ) ;
i f ( r e sp . getResponseCode ( ) != ResponseCodes .OBEX HTTP OK)
System . out . p r i n t l n ( ”Connection f a i l e d ” ) ;
e l s e {
hs = con . createHeaderSet ( ) ;
hs . setHeader ( HeaderSet .NAME, ” t e s t . vc f ” ) ;
hs . setHeader ( HeaderSet .TYPE, ” text /x−vcard” ) ;
Operation op = con . put ( hs ) ;
OutputStream out = op . openOutputStream ( ) ;
out . wr i t e ( obj ) ;
out . c l o s e ( ) ;
op . c l o s e ( ) ;
con . d i s connec t ( con . createHeaderSet ( ) ) ;
}
con . c l o s e ( ) ;
}
}
109
Appendix E
Hcidump
Hcidump is a Linux command line utility for reading HCI data comming and going to aBluetooth device. The data can be printed to the screen or to a file. Options are avaiableto configure the output to human readable-form or raw bytes. listing F.1 shows the outputof the hcidump -X command when running the ObexExample Java class where sourcecode isshowed in appendix D.
Listing E.1: Hcidump Example
1 HCI s n i f f e r − Bluetooth packet ana lyze r ver 1 .24
2 dev i c e : hc i0 snap l en : 1028 f i l t e r : 0 x f f f f f f f f
3 < HCI Command: Create Connection (0 x01 |0 x0005 ) plen 13
4 0000 : c0 d0 46 ee 12 00 18 cc 02 00 00 00 01 . . F . . . . . . . . . .
5 > HCI Event : Command Status (0 x0f ) p len 4
6 0000 : 00 01 05 04 . . . .
7 > HCI Event : Connect Complete (0 x03 ) plen 11
8 0000 : 00 06 00 c0 d0 46 ee 12 00 01 00 . . . . . F . . . . .
9 < ACL data : handle 6 f l a g s 0x02 dlen 12
10 L2CAP( s ) : Connect req : psm 3 s c i d 0x0040
11 < HCI Command: Write Link Po l i cy S e t t i n g s (0 x02 |0 x000d ) plen 4
12 0000 : 06 00 0 f 00 . . . .
13 > HCI Event : Command Complete (0 x0e ) plen 6
14 0000 : 01 0d 08 00 06 00 . . . . . .
15 > HCI Event : Number o f Completed Packets (0 x13 ) plen 5
16 0000 : 01 06 00 01 00 . . . . .
17 > HCI Event : Max S l o t s Change (0 x1b ) plen 3
18 0000 : 06 00 05 . . .
19 > ACL data : handle 6 f l a g s 0x02 dlen 16
20 L2CAP( s ) : Connect rsp : dc id 0x005e s c i d 0x0040 r e s u l t 0 s t a tu s 0
110
21 Connection s u c c e s s f u l
22 < ACL data : handle 6 f l a g s 0x02 dlen 16
23 L2CAP( s ) : Config req : dc id 0x005e f l a g s 0x00 c l en 4
24 MTU 1024
25 > HCI Event : Number o f Completed Packets (0 x13 ) plen 5
26 0000 : 01 06 00 01 00 . . . . .
27 > ACL data : handle 6 f l a g s 0x02 dlen 18
28 L2CAP( s ) : Config rsp : s c i d 0x0040 f l a g s 0x00 r e s u l t 0 c l en 4
29 Success
30 MTU 674
31 > ACL data : handle 6 f l a g s 0x02 dlen 16
32 L2CAP( s ) : Config req : dc id 0x0040 f l a g s 0x00 c l en 4
33 MTU 674
34 < ACL data : handle 6 f l a g s 0x02 dlen 14
35 L2CAP( s ) : Config rsp : s c i d 0x005e f l a g s 0x00 r e s u l t 0 c l en 0
36 Success
37 < ACL data : handle 6 f l a g s 0x02 dlen 8
38 L2CAP(d ) : c id 0x005e l en 4 [ psm 3 ]
39 RFCOMM( s ) : SABM: cr 1 d l c i 0 pf 1 i l e n 0 f c s 0x1c
40 > HCI Event : Number o f Completed Packets (0 x13 ) plen 5
41 0000 : 01 06 00 02 00 . . . . .
42 > ACL data : handle 6 f l a g s 0x02 dlen 8
43 L2CAP(d ) : c id 0x0040 l en 4 [ psm 3 ]
44 RFCOMM( s ) : UA: cr 1 d l c i 0 pf 1 i l e n 0 f c s 0xd7
45 < ACL data : handle 6 f l a g s 0x02 dlen 18
46 L2CAP(d ) : c id 0x005e l en 14 [ psm 3 ]
47 RFCOMM( s ) : PN CMD: cr 1 d l c i 0 pf 0 i l e n 10 f c s 0x70 mcc len 8
48 d l c i 12 frame type 0 c r e d i t f l ow 15 p r i 7 ack t imer 0
49 f r ame s i z e 669 max retrans 0 c r e d i t s 7
50 > ACL data : handle 6 f l a g s 0x02 dlen 19
51 L2CAP(d ) : c id 0x0040 l en 15 [ psm 3 ]
52 RFCOMM( s ) : PN RSP: cr 0 d l c i 0 pf 0 i l e n 10 f c s 0xaa mcc len 8
53 d l c i 12 frame type 0 c r e d i t f l ow 14 p r i 7 ack t imer 0
54 f r ame s i z e 330 max retrans 0 c r e d i t s 7
55 < ACL data : handle 6 f l a g s 0x02 dlen 8
56 L2CAP(d ) : c id 0x005e l en 4 [ psm 3 ]
57 RFCOMM( s ) : SABM: cr 1 d l c i 12 pf 1 i l e n 0 f c s 0x43
58 > HCI Event : Number o f Completed Packets (0 x13 ) plen 5
59 0000 : 01 06 00 02 00 . . . . .
60 > ACL data : handle 6 f l a g s 0x02 dlen 8
61 L2CAP(d ) : c id 0x0040 l en 4 [ psm 3 ]
62 RFCOMM( s ) : UA: cr 1 d l c i 12 pf 1 i l e n 0 f c s 0x88
63 < ACL data : handle 6 f l a g s 0x02 dlen 12
111
64 L2CAP(d ) : c id 0x005e l en 8 [ psm 3 ]
65 RFCOMM( s ) : MSC CMD: cr 1 d l c i 0 pf 0 i l e n 4 f c s 0x70 mcc len 2
66 d l c i 12 f c 0 r t c 1 r t r 1 i c 0 dv 1 b1 0 b2 0 b3 0 l en 0
67 > ACL data : handle 6 f l a g s 0x02 dlen 13
68 L2CAP(d ) : c id 0x0040 l en 9 [ psm 3 ]
69 RFCOMM( s ) : MSC CMD: cr 0 d l c i 0 pf 0 i l e n 4 f c s 0xaa mcc len 2
70 d l c i 12 f c 0 r t c 1 r t r 1 i c 0 dv 0 b1 1 b2 1 b3 0 l en 0
71 < ACL data : handle 6 f l a g s 0x02 dlen 12
72 L2CAP(d ) : c id 0x005e l en 8 [ psm 3 ]
73 RFCOMM( s ) : MSC RSP: cr 1 d l c i 0 pf 0 i l e n 4 f c s 0x70 mcc len 2
74 d l c i 12 f c 0 r t c 1 r t r 1 i c 0 dv 0 b1 0 b2 0 b3 0 l en 0
75 > ACL data : handle 6 f l a g s 0x02 dlen 13
76 L2CAP(d ) : c id 0x0040 l en 9 [ psm 3 ]
77 RFCOMM( s ) : MSC RSP: cr 0 d l c i 0 pf 0 i l e n 4 f c s 0xaa mcc len 2
78 d l c i 12 f c 0 r t c 1 r t r 1 i c 0 dv 1 b1 1 b2 1 b3 0 l en 0
79 < ACL data : handle 6 f l a g s 0x02 dlen 9
80 L2CAP(d ) : c id 0x005e l en 5 [ psm 3 ]
81 RFCOMM(d ) : UIH : cr 1 d l c i 12 pf 1 i l e n 0 f c s 0x53 c r e d i t s 33
82 < ACL data : handle 6 f l a g s 0x02 dlen 15
83 L2CAP(d ) : c id 0x005e l en 11 [ psm 3 ]
84 RFCOMM(d ) : UIH : cr 1 d l c i 12 pf 0 i l e n 7 f c s 0 x4f
85 0000 : 80 00 07 10 00 f f f f . . . . . . .
86 > ACL data : handle 6 f l a g s 0x02 dlen 9
87 L2CAP(d ) : c id 0x0040 l en 5 [ psm 3 ]
88 RFCOMM(d ) : UIH : cr 0 d l c i 12 pf 1 i l e n 0 f c s 0x89 c r e d i t s 13
89 > HCI Event : Number o f Completed Packets (0 x13 ) plen 5
90 0000 : 01 06 00 04 00 . . . . .
91 > ACL data : handle 6 f l a g s 0x02 dlen 17
92 L2CAP(d ) : c id 0x0040 l en 13 [ psm 3 ]
93 RFCOMM(d ) : UIH : cr 0 d l c i 12 pf 1 i l e n 7 f c s 0x89 c r e d i t s 1
94 0000 : a0 00 07 10 00 11 14 . . . . . . .
95 < ACL data : handle 6 f l a g s 0x02 dlen 167
96 L2CAP(d ) : c id 0x005e l en 163 [ psm 3 ]
97 RFCOMM(d ) : UIH : cr 1 d l c i 12 pf 0 i l e n 158 f c s 0 x4f
98 0000 : 02 00 9e 01 00 15 00 74 00 65 00 73 00 74 00 2e . . . . . . . t . e . s . t . .
99 0010 : 00 76 00 63 00 66 00 00 42 00 10 74 65 78 74 2 f . v . c . f . . B . . t ex t /
100 0020 : 78 2d 76 63 61 72 64 00 48 00 76 42 45 47 49 4e x−vcard .H.vBEGIN
101 0030 : 3a 56 43 41 52 44 0a 56 45 52 53 49 4 f 4e 3a 32 :VCARD.VERSION:2
102 0040 : 2e 31 0a 4e 3a 48 61 6e 73 65 6e 3b 20 4b 61 73 . 1 .N: Hansen ; Kas
103 0050 : 70 65 72 0a 45 4d 41 49 4c 3b 50 52 45 46 3b 49 per .EMAIL;PREF; I
104 0060 : 4e 54 45 52 4e 45 54 3a 6b 61 68 61 30 31 61 65 NTERNET: kaha01ae
105 0070 : 40 73 74 75 64 65 6e 74 2e 63 62 73 2e 64 6b 0a @student . cbs . dk .
106 0080 : 52 45 56 3a 32 30 30 36 30 32 32 37 54 32 30 31 REV:20060227T201
112
107 0090 : 34 34 36 5a 0a 45 4e 44 3a 56 43 41 52 44 446Z .END:VCARD
108 > HCI Event : Number o f Completed Packets (0 x13 ) plen 5
109 0000 : 01 06 00 01 00 . . . . .
110 > ACL data : handle 6 f l a g s 0x02 dlen 13
111 L2CAP(d ) : c id 0x0040 l en 9 [ psm 3 ]
112 RFCOMM(d ) : UIH : cr 0 d l c i 12 pf 1 i l e n 3 f c s 0x89 c r e d i t s 1
113 0000 : 90 00 03 . . .
114 < ACL data : handle 6 f l a g s 0x02 dlen 14
115 L2CAP(d ) : c id 0x005e l en 10 [ psm 3 ]
116 RFCOMM(d ) : UIH : cr 1 d l c i 12 pf 0 i l e n 6 f c s 0 x4f
117 0000 : 02 00 06 49 00 03 . . . I . .
118 > HCI Event : Number o f Completed Packets (0 x13 ) plen 5
119 0000 : 01 06 00 01 00 . . . . .
120 > ACL data : handle 6 f l a g s 0x02 dlen 13
121 L2CAP(d ) : c id 0x0040 l en 9 [ psm 3 ]
122 RFCOMM(d ) : UIH : cr 0 d l c i 12 pf 1 i l e n 3 f c s 0x89 c r e d i t s 1
123 0000 : 90 00 03 . . .
124 < ACL data : handle 6 f l a g s 0x02 dlen 11
125 L2CAP(d ) : c id 0x005e l en 7 [ psm 3 ]
126 RFCOMM(d ) : UIH : cr 1 d l c i 12 pf 0 i l e n 3 f c s 0 x4f
127 0000 : 82 00 03 . . .
128 > HCI Event : Number o f Completed Packets (0 x13 ) plen 5
129 0000 : 01 06 00 01 00 . . . . .
130 > ACL data : handle 6 f l a g s 0x02 dlen 13
131 L2CAP(d ) : c id 0x0040 l en 9 [ psm 3 ]
132 RFCOMM(d ) : UIH : cr 0 d l c i 12 pf 1 i l e n 3 f c s 0x89 c r e d i t s 1
133 0000 : a0 00 03 . . .
134 < ACL data : handle 6 f l a g s 0x02 dlen 11
135 L2CAP(d ) : c id 0x005e l en 7 [ psm 3 ]
136 RFCOMM(d ) : UIH : cr 1 d l c i 12 pf 0 i l e n 3 f c s 0 x4f
137 0000 : 81 00 03 . . .
138 > HCI Event : Number o f Completed Packets (0 x13 ) plen 5
139 0000 : 01 06 00 01 00 . . . . .
140 > ACL data : handle 6 f l a g s 0x02 dlen 13
141 L2CAP(d ) : c id 0x0040 l en 9 [ psm 3 ]
142 RFCOMM(d ) : UIH : cr 0 d l c i 12 pf 1 i l e n 3 f c s 0x89 c r e d i t s 1
143 0000 : a0 00 03 . . .
144 < ACL data : handle 6 f l a g s 0x02 dlen 8
145 L2CAP(d ) : c id 0x005e l en 4 [ psm 3 ]
146 RFCOMM( s ) : DISC : cr 1 d l c i 12 pf 1 i l e n 0 f c s 0xa2
147 > ACL data : handle 6 f l a g s 0x02 dlen 8
148 L2CAP(d ) : c id 0x0040 l en 4 [ psm 3 ]
149 RFCOMM( s ) : UA: cr 1 d l c i 12 pf 1 i l e n 0 f c s 0x88
113
150 < ACL data : handle 6 f l a g s 0x02 dlen 8
151 L2CAP(d ) : c id 0x005e l en 4 [ psm 3 ]
152 RFCOMM( s ) : DISC : cr 1 d l c i 0 pf 1 i l e n 0 f c s 0 xfd
153 < ACL data : handle 6 f l a g s 0x02 dlen 12
154 L2CAP( s ) : Disconn req : dc id 0x005e s c i d 0x0040
155 > ACL data : handle 6 f l a g s 0x02 dlen 8
156 L2CAP(d ) : c id 0x0040 l en 4 [ psm 3 ]
157 RFCOMM( s ) : UA: cr 1 d l c i 0 pf 1 i l e n 0 f c s 0xd7
158 > HCI Event : Number o f Completed Packets (0 x13 ) plen 5
159 0000 : 01 06 00 03 00 . . . . .
160 > ACL data : handle 6 f l a g s 0x02 dlen 12
161 L2CAP( s ) : Disconn rsp : dc id 0x005e s c i d 0x0040
162 < HCI Command: Disconnect (0 x01 |0 x0006 ) plen 3
163 0000 : 06 00 13 . . .
164 > HCI Event : Command Status (0 x0f ) p len 4
165 0000 : 00 01 06 04 . . . .
166 > HCI Event : Disconn Complete (0 x05 ) plen 4
167 0000 : 00 06 00 16 . . . .
114
Appendix F
Prototype Implementation
Listing F.1: FilePusher.java1 package t e s t ;2
3 import java . i o . OutputStream ;4
5 import javax . b luetooth . * ;6 import javax . m i c ro ed i t i on . i o . Connection ;7 import javax . m i c ro ed i t i on . i o . Connector ;8 import javax . obex . C l i e n tS e s s i on ;9 import javax . obex . HeaderSet ;
10 import javax . obex . Operation ;11 import javax . obex . ResponseCodes ;12
13 import net . s ou r c e f o r g e . b lueonjop . BTPosit ioning ;14
15 import e j i p . CS8900 ;16 import e j i p . LinkLayer ;17 import e j i p . Net ;18 import e j i p . Packet ;19 import e j i p .Udp ;20 import e j i p . UdpHandler ;21 import j op r t . RtThread ;22 import u t i l .Dbg ;23 import u t i l . Timer ;24
25 pub l i c c l a s s Fi l ePusher implements D i s cove ryL i s t ene r {26
27 s t a t i c Net net ;28 s t a t i c LinkLayer ipLink ;29
30 s t a t i c i n t IP = (130 << 24) + (226 << 16) + (33 << 8) + 184 ;31 s t a t i c i n t PORT = 2346 ;32
33
34 s t a t i c boolean iknowyou , s e r v i c e , connect ;35
36 s t a t i c F i l ePusher fp ;37 s t a t i c LocalDevice locDev ;38 s t a t i c DiscoveryAgent agent ;39
115
40 s t a t i c HeaderSet hs ;41 s t a t i c Connection c ;42 s t a t i c C l i e n tS e s s i on cs ;43 s t a t i c Operation op ;44 s t a t i c OutputStream out ;45
46 s t a t i c S t r ing [ ] bdAddr ;47 s t a t i c i n t bdAddrIndex ;48 s t a t i c S t r ing r s s i ;49
50 pub l i c s t a t i c void main ( St r ing [ ] a rgs ) {51 Dbg . i n i t ( ) ;52 RtThread . i n i tC l a s s ( ) ;53
54 net = Net . i n i t ( ) ;55 ipLink = CS8900 . i n i t (Net . eth , Net . ip ) ;56
57 new RtThread (4 , 2000) {58 pub l i c void run ( ) {59 f o r ( ; ; ) {60 waitForNextPeriod ( ) ;61 net . loop ( ) ;62 }63 }64 } ;65 new RtThread (4 , 2000) {66 pub l i c void run ( ) {67 f o r ( ; ; ) {68 waitForNextPeriod ( ) ;69 ipLink . loop ( ) ;70 }71 }72 } ;73
74 UdpHandler adder ;75 adder = new UdpHandler ( ) {76 pub l i c void r eque s t ( Packet p) {77 // loop over the data content o f the packet78 i n t [ ] data = new in t [ 7 ] ;79 i n t cnt = 0 ;80 f o r ( i n t i = Udp .DATA; i < (p . l en /4 ) ; i++) {81 data [ cnt++] = p . buf [ i ] ;82 }83 i f ( data [ 0 ] == 1) {84 udpLogger ( ” I know you” ) ;85 iknowyou = true ;86 } e l s e i f ( data [ 0 ] == 0){87 iknowyou = f a l s e ;88 }89
90 p . s e tS ta tu s ( Packet .FREE) ;91
92 }93 } ;94 Udp . addHandler (2345 , adder ) ; //The JOP serve r por t !95
96 System . out . p r i n t l n ( ”Program s t a r t ” ) ;97
98 fp = new Fi lePusher ( ) ;99 locDev = LocalDevice . getLoca lDev ice ( ) ;
100 agent = locDev . getDiscoveryAgent ( ) ;101 hs = HeaderSet . i n i t ( ) ;102
103 bdAddr = new St r ing [ 1 0 ] ;104 bdAddrIndex = 0 ;
116
105
106
107
108 RtThread . s t a r tMi s s i on ( ) ;109 //run f o r e v e r110 f o r ( ; ; ) {111 Timer .wd ( ) ;112 i n t t = Timer . getTimeoutMs ( 5 0 0 ) ;113 whi le ( ! Timer . t imeout ( t ) ) {114 i f ( iknowyou ) {115 agent . s t a r t I n qu i r y ( DiscoveryAgent .GIAC, fp ) ;116 whi le ( ! connect ) {117 //wait118 }119 i f ( bdAddrIndex > 0) {120
121 f o r ( i n t x=0; x<bdAddrIndex ; x++) {122 udpLogger (bdAddr [ x ] ) ;123 }124
125
126 c = Connector . open (bdAddr [0 ]+ ” ,1105 ” ) ;127
128 r s s i = BTPosit ioning . RSSI ( ) ;129 udpLogger ( r s s i ) ;130 i n t r = st r ingToInt ( r s s i ) ;131
132 i f ( c != nu l l && r > 9) {133 cs = ( C l i e n tS e s s i on ) c ;134 hs = cs . connect ( hs ) ;135 i f ( hs != nu l l ) {136 i f ( hs . getResponseCode ( ) != ResponseCodes .OBEX HTTP OK) {137 udpLogger ( ”Connect e r r o r ”+hs . getResponseCode ( ) ) ;138 } e l s e {139 udpLogger ( ”Connect ok” ) ;140 hs . setHeader ( HeaderSet .NAME, ”a” ) ;141 op = cs . put ( hs ) ;142 i f ( op != nu l l ) {143 i f ( op . getResponseCode ( ) != ResponseCodes .OBEX HTTP CONTINUE) {144 udpLogger ( ”Put e r r o r ” ) ;145 } e l s e {146 udpLogger ( ”Put cont inue ” ) ;147 out = op . openOutputStream ( ) ;148 byte [ ] b = new byte [ 2 ] ;149 b [ 0 ] = ’b ’ ;150 b [ 1 ] = ’ c ’ ;151 out . wr i t e (b ) ;152 }153 }154 hs = cs . d i s connec t ( hs ) ;155 i f ( hs != nu l l ) {156 i f ( hs . getResponseCode ( ) != ResponseCodes .OBEX HTTP OK) {157 udpLogger ( ”Disconnect e r r o r ”+hs . getResponseCode ( ) ) ;158 } e l s e159 udpLogger ( ”Disconnect ok” ) ;160 }161 }162 }163 c . c l o s e ( ) ;164 } e l s e {165 udpLogger ( ”RSSI to low/No connect ion ?” ) ;166 i f ( c != nu l l )167 c . c l o s e ( ) ;168 }169
117
170 }171
172 bdAddrIndex = 0 ;173 // iknowyou = f a l s e ;174 }175 }176 }177 }178
179
180 pub l i c void dev i ceDi scovered ( RemoteDevice btDevice , S t r ing cod ) {181 bdAddr [ bdAddrIndex ] = btDevice . getBluetoothAddress ( ) ;182 bdAddrIndex++;183 }184
185
186 pub l i c void inquiryCompleted ( i n t discType ) {187 connect = true ;188
189 }190
191
192 pub l i c void s e r v i c e sD i s c ov e r ed ( i n t transID , S t r ing [ ] servRecord ) {193 //no implementation194 }195
196
197 pub l i c void serv iceSearchCompleted ( i n t transID , i n t respCode ) {198 //no implementation199 }200
201 s t a t i c i n t val , tmp , ten ;202 s t a t i c i n t NEGATIVE = ( in t ) ’− ’ ;203 s t a t i c boolean neg ;204 pub l i c s t a t i c i n t s t r ingToInt ( S t r ing s ) {205 va l = 0 ;206 tmp = 0 ;207 neg = f a l s e ;208 ten = 0 ;209
210 f o r ( i n t i=s . l ength ()−1; i >=0; i−−) {211 i f ( i==0) {212 i f (NEGATIVE == ( in t ) s . charAt ( 0 ) ) {213 neg = true ;214 }215 }216
217 i f ( ! neg ) {218
219 i f ( i != s . l ength ()−1) {220 ten = ten * 10 ;221
222 }223
224
225 tmp = ( ( i n t ) s . charAt ( i ) ) − 48 ;226 i f ( ten !=0)227 tmp = tmp* ten ;228
229 va l = va l + tmp ;230
231 i f ( i==s . l ength ()−1)232 ten = 1 ;233 }234 }
118
235
236 i f ( neg )237 va l = va l * −1;238 r e turn va l ;239 }240
241 pub l i c s t a t i c void udpLogger ( S t r ing s ) {242 Packet p = Fi lePusher . getPacket ( ) ;243 Udp . setData (p , new St r i ngBu f f e r ( s ) ) ;244 Udp . bu i ld (p , IP , PORT) ;245 } //END pub l i c s t a t i c void udpLogger ( S t r ing s )246
247 pub l i c s t a t i c Packet getPacket ( ) {248 Packet p = nu l l ;249 f o r ( ; p == nu l l ; ) {250 p = Packet . getPacket ( Packet .FREE, Packet .ALLOC) ;251 p . i n t e r f = ipLink ;252 RtThread . sleepMs ( 1 0 ) ;253 }254 r e turn p ;255 } //END pub l i c s t a t i c Packet ge tPacket ( Packet p )256 }
119
Bibliography
[1] Irda object exchange protocol. Technical report, 1999.
[2] Bluetooth specification version 2.0 + edr [vol 0]. Technical report, 2004.
[3] Specification of the bluetooth system, covered core package version: 2.0 + edr. Technicalreport, 2004.
[4] Survey over positionering via bluetooth. 2004.
[5] Lauri Aalto, Nicklas Gthlin, Jani Korhonen, and Timo Ojala. Bluetooth and wap pushbased location-aware mobile advertising system. In MobiSys ’04: Proceedings of the 2ndinternational conference on Mobile systems, applications, and services, pages 49–58, NewYork, NY, USA, 2004. ACM Press.
[6] J.Harkin AJ.Solon, MJ.Callaghan and TM.McGinnity. Case study on the bluetoothvulnerabilities in mobile devices. pages 125–129, 2006.
[7] Paramwir Bahl and Venkata N. Padmanabhan. Radar: An in-building rf-based userlocation and traking system.
[8] Joe Bardwell. Converting signal strength percentage to dbm values. 2002.
[9] Miguel Bravo-Escos. Networking gets personal. 2002.
[10] Ling-Jyh Chen, Rohit Kapoor, M. Y. Sanadidi, and Mario Gerla. Enhancing bluetoothtcp throughput via packet type adaptation.
[11] George Coulouris, Jean Dollimore, and Tim Kindberg. Distributed Systems Conceptsand Design. Addison Wesley, 3rd edition, 2001.
[12] Mirko Dlle. Jump start. Linux Magazine, (71), October 2006.
[13] TDK Systems Europe. Blu2i at command set. Technical report, 2004.
[14] F-Secure. Going around with bluetooth in full safety. 2006.
120
[15] Christian Gehrmann. Bluetooth Security. Artech House, Incorporated, 2004.
[16] Josef Hallberg, Marcus Nilsson, and Kre Synnes. Positioning with bluetooth. 2003.
[17] Wei-Meng Lee. Windows XP Unwired - A Guide for Home, Office, and the Road.O’Reilly, 2003.
[18] Tancred Lindholm. Setting up a bluetooth packet transport link. Department of Com-puter Science Helsinki University of Technology.
[19] Dimitrios Lymberopopoulos, Quentin Lindsley, and Andres Savvides. An empiricalcharacterization of radio signal strength variability in 3-d ieee 802.15.4 netwoks usingmonopole antennas.
[20] Robert Morrow. Bluetooth Operation and Use. McGraw-Hill Professional, 2002.
[21] Nathan J. Muller. Bluetooth Demystified. McGraw-Hill Professional, 2000.
[22] Collin Mulliner and Martin Herfurt. Blueprinting - remote device identification basedon bluetooth fingerprinting techniques. 2004.
[23] NASA. Basics of space flight. 2004.
[24] Brian S. Peterson, Rusty O. Baldwin, and Jeffrey P. Kharoufeh. Bluetooth inquirytime characterization and selection. IEEE Transactions on Mobile Computing, 5(9),September 2006.
[25] Andreas Savvides, ChihChieh Han, and Mani B. Strivastava. Dynamic fine-grainedlocalization in adhoc networks of sensors. 2001.
[26] Yaniv Shaked and Avishai Wool. Cracking the bluetooth pin.
[27] Raze Technologies. The advantages of tdd over fdd in wireless data applications. 2001.
[28] Kiran Thapa. An indoor positioning service for bluetooth ad hoc networks. 2003.
[29] Ryan Woodings, Derek Joos, Trevor Clifton, and Charles D. Knutson. Rapid heteroge-neous connection establishment: Accelerating bluetooth inquiry using irda.
[30] Gergely V. Zruba and Vishant Gupta. Simplified bluetooth device discovery analysisand simulation. 2004.
121
