Extended Bluetooth Profiles on CCpilot displays1095401/FULLTEXT01.pdf• Diagnostik och annan data fr an bilen • Monitorering av f orarens h alsotillst and. M ojligheten att anv

UPTEC F 17017

Examensarbete 30 hpMaj 2017

Extended Bluetooth Profiles on CCpilot displays

Alexander Johnson

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

Extended Bluetooth Profiles on CCpilot displays

Alexander Johnson

Bluetooth is used in modern cars to connect smartphones to stream music, to access internet and for phone services such as phone book contacts and making calls. Similar features are now requested by customers of maximatecc's products, e.g. display computers, for off-road vehicles. This thesis is aimed to investigate what is needed to support these features in maximatecc's Linux based displays and how the features can be used in a Qt application.

For instance, the connectivity features in personal cars most commonly utilizes the Bluetooth profiles:

Advanced Audio Distribution Profile (A2DP)Audio/Video Remote Control Profile (AVRCP)Personal Area Network (PAN) ProfileHands Free Profile (HFP)Phone Book Access Profile (PBAP)Message Access Profile (MAP).

In Linux operating system the Bluetooth stack Bluez is used in the lower level implementation. Open source software components recommended to implement the above profiles includes:

Obexd (for MAP and PBAP)PulseAudio (for A2DP and HFP)oFono (for HFP)Connman (for PAN)

all of which help to implement the top level profiles of the Bluetooth stack needed, easily controlled by a Qt application through DBus.

Most of the external software components were not possible to add to the Linux image on the CCpilot VA display during the period of the thesis. Instead some features of the profiles have been tested, through a Qt demo and python test scripts, on a Virtual Machine in an environment similar to the CCpilot VA. All profiles tested had some functionality verified except for AVRCP, which is not supported until later versions of Bluez, not available for the Linux kernel on the CCpilot VA. However, the audio in the HFP only occasionally worked. On the CCpilot VA only PBAP was tested successfully.

ISSN: 1401-5757, UPTEC F 17017Examinator: Tomas NybergÄmnesgranskare: Ping WuHandledare: Carl-Magnus Moon

Popularvetenskaplig sammanfattnig

Bluetooth anvands idag i moderna bilar for att smidigt koppla upp sin smartphone for attfa tillgang till dess funktionalitet i bilens informations- och mediaenhet(IVI). Det galler idagframforallt

• Stromma musik

• Fa tillgang till en internetuppkoppling

• Anvanda telefonen for att ringa och ta emot samtal, hantera meddelanden och anvandatelefonboken.

I vilken utstrackning dessa erbjuds skiljer sig at mellan biltillverkare och modell men, atminstonesom tillval, finns det i princip i alla nyproducerade bilar. I framtiden finns stora mojligheter fornya anvandingsomraden dar Bluetooth kan nyttjas, daribland

• Diagnostik och annan data fran bilen

• Monitorering av forarens halsotillstand.

Mojligheten att anvanda Bluetooth for att uppna liknande funktionalitet efterfragas nu avkunder till maximateccs displayenheter till terrangfordon. Dessa displayenheter anvander framstoperativsystemet Linux i vilket ett grundstod for Bluetooth finns inbyggt genom programvaranBluez. For att underlatta utvecklingen av applikationer med onskad funktionalitet anvands oftamellanprogramvara, middleware, vilken implementerar funktioner som inte direkt ar tillgangligavia operativsystemet.

Genom att bland annat ga igenom projekt med oppen kallkod riktat mot Linuxbaserade IVI ipersonbilsindustrin har har fyra mellanprogramvaror identifierats for att underlatta en implementeringav dessa funktionaliteter. Dessa ar

• Obexd (for meddelandehantering och telefonbok)

• PulseAudio (for hantering av ljud, bade musik och samtal)

• oFono (for samtalshantering)

• Connman (for internetaccess).

Ett konceptuellt demoprogram har tagits fram dar vissa av dessa mellanprogramvaror anvandssom visar hur de praktiskt kan anvandas i en applikation skapad i utvecklingsverktyget Qt. Andrafunktioner har testats med sma testprogram, scripts, som foljer med kallkoden. Testningen harframst utforts i en utvecklingsmiljo som ska efterlikna displayenheterna.

1

Abbreviations

• A2DP - Advacned Audio Distribution Profile

• ACL - Asynchronous Connection-Oriented (logical transport)

• API - Application Programming Interface

• AT - ATtention

• AVCTP - Audio/Video Control Transport Protocol

• AVDTP - Audio/Video Distribution Transport Protocol

• AVRCP - Audio/Video Remote Control Profile

• BLE - Bluetooth Low Energy

• BNEP - Bluetooth Network Encapsulation Protocol

• BR - Basic Rate

• DUN - Dial Up Network Profile

• EDR - Enhanced Data Rate

• GAP - Generic Access Profile

• GN - Group Ad-hoc Network

• GOEP - Generic Object Exchange Profile

• GUI - Graphical User Interface

• HCI - Host Controller Interface

• HF - Hands-Free Unit

• HFP - Hands-Free Profile

• HS - High Speed

• HSP - Headset Profile

• ICE - In-Car Entertainment

• ich - incomming call history

• IVI - In-Vehicle Infotainment system

• L2CAP - Logical Link Control and Adaption Protocol

• MAP - Message Access Profile

• NAP - Network Access Point

• OBEX - Object Exchange Protocol

• OPP - Object Push Profile

2

• PAN - Personal Area Network Profile

• PANU - Personal Area Network Profile User

• pb - main phone book

• PBAP - Phone Book Access Profile

• RFCOMM - Radio Frequency Communication

• (e)SCO - (Enhanced) Synchronous Connection Oriented

• SDP - Service Discovery Protocol

• USB - Universal Serial Bus

• VM - Virtual Machine

3

Contents

1 Introduction 71.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Tasks and Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 IVI in personal cars 82.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Connectivity features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Hands Free Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Media Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.3 Tethering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.4 Other technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.5 Future functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.6 Technical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.7 Profiles supported by mobile phones . . . . . . . . . . . . . . . . . . . . . 122.2.8 Compatibility check between phone model and IVI system . . . . . . . . . 12

2.3 OpenSource initiatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Bluetooth 143.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 BR/EDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.2 High Speed (HS) extension . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.3 Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 The Bluetooth Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.1 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.2 HCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.3 Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.1 L2CAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.2 RFCOMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.3 BNEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.4 Obex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.5 SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.6 AVDTP/AVCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4.1 Generic Access Profile (GAP) . . . . . . . . . . . . . . . . . . . . . . . . . 183.4.2 Serial Port Profile (SPP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4.3 Phone Book Access Profile (PBAP) . . . . . . . . . . . . . . . . . . . . . 193.4.4 Hands Free Profile (HFP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4.5 Advanced Audio Distribution Profile (A2DP) . . . . . . . . . . . . . . . . 233.4.6 Audio/Video Remote Control Profile (AVRCP) . . . . . . . . . . . . . . . 253.4.7 Message Access Profile (MAP) . . . . . . . . . . . . . . . . . . . . . . . . 253.4.8 Personal Area Network Profile (PAN) . . . . . . . . . . . . . . . . . . . . 27

3.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.1 Bluetooth Security Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.2 Legacy Pairing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4

3.5.3 Secure Simple Pairing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.5.4 Secure Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.5.5 Detectable and Connectable only when needed . . . . . . . . . . . . . . . 33

4 Hardware and Development Environment 344.1 Tested Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.1 CCPilot VA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.1.2 Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Bluetooth Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3 Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Software Components in Linux 365.1 BlueZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.1 Kernel configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.1.2 Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.1.3 A2DP support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.1.4 AVRCP support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.1.5 HFP support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.1.6 PAN support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.1.7 MAP & PBAP support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2 Obexd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2.1 PBAP API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2.2 MAP API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.3 Changes with different versions . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3 Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3.1 Advanced Linux Sound Architecture - ALSA . . . . . . . . . . . . . . . . 435.3.2 PulseAudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3.3 Audio Configuration in Bluez . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.4 Telephony stack - oFono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.4.1 HFP AG plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.5 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.6 DBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.6.1 Service, Path and Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 455.6.2 Methods and signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.7 Qt - Bluetooth Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.7.1 QtBluetooth Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.7.2 Extending the support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.7.3 Combining the generated QDBusAbstractionInterface classes . . . . . . . 495.7.4 Pending replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Implementation 506.1 Configuration and setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.1.1 Software versions on the tested systems . . . . . . . . . . . . . . . . . . . 506.1.2 Initiating scripts on CCpilot VA . . . . . . . . . . . . . . . . . . . . . . . 50

6.2 Qt Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.2.2 Mainwindow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2.3 Scandialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.2.4 HFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5

6.2.5 PBAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.2.6 MAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.3 Testing features outside of the Qt Demo . . . . . . . . . . . . . . . . . . . . . . . 536.3.1 A2DP, AVRCP and PAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.3.2 Python scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.3.3 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7 Results and Discussion 547.1 Result of tested profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.1.1 VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.1.2 CCPilot VA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.1.3 Ubuntu Laptop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.2 Unresolved issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.2.1 VM related issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.2.2 VA related issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8 Conclusions 58

References 60

6

1 Introduction

1.1 Background

Modern cars are usually equipped with the functionality to connect your smartphones to devicesin the cars, e.g., transferring contact list to the car’s built-in display and playlists to play music.Some of maximatecc’s customers in the industrial domain have requested maximatecc’s products,e.g., CCpilot display computers, to have the same functionality available in their off-road vehicles.

CCpilot is a maximatecc display computer product with Bluetooth support for connection toperipheral devices. For newer displays through an external USB device but some older modelsmay have built in support. However, none of the models up to now have smartphone connectionfunctionality. Thus, maximatecc is intended to add this functionality to the CCpilot displaycomputers in their future applications.

1.2 Specification

This thesis project aims to investigate which functionalities that are available in personal carstoday in terms of Bluetooth connectivity and what is needed to offer access to smartphonefunctionality in a similar way in terms of connection encryption, Bluetooth profiles, existingopen source projects and other Linux Embedded libraries. The project should include designand implementation of a conceptual demo and test system to verify functionality and reliability.

1.3 Tasks and Methodology

The Bluetooth functionalities available in personal cars today have been investigated by readingmarketing descriptions from manufacturers and specification of phone models from recent years.This has been done to get a basic idea and no statistical approach has been utilized to choosewhich manufacturers and models that should be investigated. In addition to this some opensource IVI projects have been studied. These functionalities have been mapped to Bluetoothprofiles and protocols, the Bluetooth stack, needed to achieve them.

To implement and test the profiles on an embedded device running Linux and create a demoin Qt the documentation, source code and mailing lists of different open source projects wereinvestigated. The testing was performed in different Linux environments but mainly on a VirtualMachine (VM) and on a CCpilot VA.

7

2 IVI in personal cars

2.1 Overview

The IVI is usually built around one or more head units, displaying the GUI to the user. Somecommon features are

• Maps and navigation - Either a built-in system or through a plugged-in system using thehead unit as a display

• Multimedia - Graphic and audio content, music, video or games, which can be displayedon the head unit or distributed to screens at the rear seats

• Internet access - For receiving traffic information, travel suggestion, audio streaming andmuch more

• Connectivity - Utilizing other devices for content to the above features through USB,Bluetooth or WiFi.

An example architecture of an IVI system is presented in Fig. 2.1 where the actual hardwarecomponents, such as the MCU, memory and Bluetooth adapter is the bottom layer. Above thatthe OS layer resides containing an OS core and the board support package (BSP). Another step upthe middleware layer provides functionalities not available through the OS directly. It serves theapplication with well defined interfaces to services in order to speed up application development.This layer may include media and graphics management, system infrastructure and automotiveconnectivity. Above the middleware layer is the application layer with software designed toprovide a specific feature for the user. This layer may include software for providing mobileentertainment, office functions, navigation and vehicle information. To manage the IVI a HumanMachine Interface (HMI) is exposed to the user. The HMI layer may consist of touchscreens,keypads, audio and video interfaces. [1]

2.2 Connectivity features

The functionality of the IVI systems differ substantially between manufacturers and car modelsbut Bluetooth connectivity is almost always available, at least as a premium feature. However,Bluetooth connectivity, which often is what is advertised, does not explain which features orprofiles are supported. Some manufacturers provide good documentation of the available features,what Bluetooth profile is used and the compatibility of each feature against different phones fordifferent car models and versions of IVI whereas others are more sparse and does not alwaysexplicitly say which features use Bluetooth. The found features can be grouped into threecategories

• Hands Free Features

• Media Player

• Tethering

which are explained in the following subsections.

8

Figure 2.1: An overview of the architecture of an IVI system. Reproduced from [1]

9

2.2.1 Hands Free Features

In general Bluetooth has almost become synonymous with wireless headset/handsfree and thishas been the standard feature of Bluetooth connected cars since the first car-kit was introducedin 2001 [2]. This feature includes

• placing, accepting and hanging up phone calls

• routing the call audio to and from the audio system of the car.

It may also include additional subfeatures such as

• conference calls - multiparty calls

• network status - operator, signal strength etc

• phone book access

• call history

• message access

2.2.2 Media Player

In recent years audio streaming of high quality music has become a very appreciated feature asan alternative to radio and CD as the entertainment source in the IVI. This is often availablethrough USB or Bluetooth, either by playing locally stored media files or by streaming throughservices connected to the internet, such as Spotify. The service includes streaming audio, remotecontrol and meta data, such as song title, artist etc.

2.2.3 Tethering

Sharing the phones internet connection, tethering, is not as widely used as the hands free andmusic streaming features, but is offered by some manufacturers. This feature opens up all thepossibilities that comes with the internet for a wide range of applications to access data, such astraffic information or navigation.

2.2.4 Other technologies

A connectivity feature which has come in recent years is the ability to use the phones apps onthe IVI. This lets the user browse through different apps on the IVI with a GUI designed bythe app/phone developer. The GUI is often simplified to make it easy and safe to use whiledriving. This functionality is today supported by Android Auto, MirrorLink, SmartDeviceLinkand CarPlay(Apple). The technology itself does not run over Bluetooth, though some of them,MirrorLink for example, utilizes Bluetooth for some features such as hands free calls. Thesetechnologies have not been investigated further within the scope of this thesis.

2.2.5 Future functionality

While the benefit of using wireless technologies in cars to connect to smart phone functionalityare undoubted there have been suggestions that Bluetooth might not be the technology that willbe used in the future. WiFi has been mentioned to take over for a few years now, but Bluetooth isstill there in new car models. The fact that Bluetooth is so wide spread, both in terms of the endusers knowledge as well as standardized interfaces for developers to work against, suggests that

10

it will be around for quite a while longer, possibly together with other technologies as mentionedabove.

2.2.5.1 More phone applications

Future functionality may include further development in terms of phone applications which canbe displayed on the IVI head unit where Bluetooth can play an important role in managingthese connections and support them with an internet connection for example to get data. Theintroduction of Bluetooth Low Energy (BLE) also opens up for different kinds of sensors in thecar or along the road with information. To know exactly what this will be used for in the futureis very difficult but a few possible applications are mentioned in this section.

2.2.5.2 Driver preferences

One possible mobile application is personal preferences stored in the phone. Examples ofpreferences could be seat, wheel and mirror positioning and temperature. This could automaticallybe adapted to the preferences as the user enters the car. To make it possible to use in differentcars there must exist a standard or at least known distances and angles in every car model.

2.2.5.3 Health monitoring while driving

One thing that many manufacturers, BMW and Ford for example, are looking into is healthinformation such as glucose and heart monitoring. This information could then be used to, forexample, alert the driver and/or the driver’s doctor if something is wrong or even to stop thecar in case a heart attack is detected. [3]

2.2.5.4 Car diagnostics

Bluetooth technology may also be used to gather data to monitor and diagnose mechanicalelectrical systems. Bluetooth SIG mention this as a possibility to reduce manufacturing cost andweight, affecting fuel efficiency, by reducing copper wires in the car. [4]

2.2.6 Technical

For all Bluetooth connectivity commonly found in cars today Basic Rate (BR) and EnhancedData Rate (EDR) is used and the top level Bluetooth profiles used to achieve the differentfunctionalities described above is mentioned in the following subsections. Further description ofthe different Bluetooth techonology systems can be found in the Bluetooth/General section andthe profiles selected as best for the use case can be found in the Bluetooth/Profiles section.

2.2.6.1 Hands free phone calls

The most common profile used to achieve the function of a wireless headset is the hands freeprofile (HFP) which is designed for low latency audio streams and includes control features formobile phones based on AT commands. It also includes information about the network, suchas operator name and signal strength, as well as multiple optional features, such as conferencecall. However, there is a headset profile (HSP) which is very similar to the HFP except withslightly less control feature. A third choice is the SIM Access Profile (SAP) which differs fromthe profiles mentioned above in the way that it uses the SIM card information from the phone toconnect to the network directly as if the SIM card was inserted into the IVI. This has the benefitof being able to use the stronger antenna of the car and does not drain the phone’s battery to

11

the same extent as less data is transferred between the phone and the car. The downside is thatany call or messages made through the IVI head unit will not appear in the phone.

2.2.6.2 Phone book

For phone book functionality there is a phone book access profile (PBAP) which is designed tosend contacts as vCard objects between devices. Other object exchange profiles such as ObjectPush Profile (OPP) can be used as well. The difference between these two profiles is that withOPP the contacts are pushed from the mobile phone to the IVI whereas with PBAP the transferis requested from the IVI and different arguments can be set in order to get different parts ofthe phone book, such as ”incoming call history” and ”phone book saved contacts”.

2.2.6.3 Messages

For accessing messages (SMS, email etc) the Messaging Access Profile (MAP) is used which sendsthe messages as objects. Again the OPP can also be used as with the phone book access, but inanalogy it does not provide the same flexibility as MAP.

2.2.6.4 Music Streaming

For music streaming functionality the advanced audio distribution profile (A2DP) in combinationwith the audio/video remote control profile (AVRCP) is recommended. Technically HFP/HSPcould be used for streaming the audio but the quality would not be sufficient since they areintended for voice, which is below 4 kHz whereas music often requires 20 kHz to be consideredto be of sufficient quality.

2.2.6.5 Tethering

For tethering the profiles personal area network profile (PAN) and dial up network profile (DUN)exist. Whereas DUN formerly was used to connect to internet using a mobile phone as a modemthe PAN profile has become the standard profile in recent years to share an internet connection.

2.2.7 Profiles supported by mobile phones

The Bluetooth BR/EDR profiles supported by iPhone 6, [5], Samsung Galaxy S6, [6][7], andSony Xperia Z5 Premium, [8], are presented in table 2.1. All of these profiles are utilized inIVI’s today except for Human Interface Device (HID), which is used by input devices, such askeyboards and mouses. The profiles for the IVI functionalities which are supported by all devicesare also the ones recommended whereas other profiles, e.g. HSP and OPP, are only supported bysome and may be seen as alternative profiles. This is not meant to be a full investigation of phonemodels and does not provide any crucial information for this thesis but illustrates which profilesare commonly supported by modern phones. The supported profiles have not changed much inthe recent years between releases, iPhone for example has had the same supported profiles sinceiPhone 4.

2.2.8 Compatibility check between phone model and IVI system

Most car manufacturers provide tools to check compatibility between phone models and theirdifferent IVI systems. In general phones supporting the same profiles as the IVI should work butas versions may differ or details in the implementation may make some features incompatible,only the tested phones and software versions are recommended by the manufacturers.

12

Table 2.1: The supported Bluetooth profiles for iPhone 6, Samsung Galaxy S6 and Sony XperiaZ5 Premium where O indicates that the profile is supported by the profile

2.3 OpenSource initiatives

As the amount of code needed for IVI systems has sky rocketed in recent years the automotiveindustry has been looking into how to reduce the development cost and reuse as much code aspossible. IVI’s today can contain over 100 million lines of code, compared to tens of thousandsa decade ago, with most code being non-differentiating between manufacturers [9]. In thisinvestigation many manufacturers have seen the benefit of open source platforms which arecontinuously maintained and this has lead to different open source initiatives.

Some examples of such initiatives are

• GENIVI Alliance - Focus on standardizing a platform of middleware, mainly by supportingalready existing open source projects or by defining standard API’s where multiple middlewaremight be used as backend. Where no such projects are found they may host their ownprojects.

• Tizen IVI - Tizen is a flexible operating system based on Linux and has different versionsaimed for different purposes, IVI being one of them. It is GENIVI compliant and may beseen as a reference build of the GENIVI specification.

• Automotive Grade Linux - AGL aims to provide not only a reference OS platform but anentire IVI system to be used as a starting point for developers. They build their referenceplatform on top of Tizen IVI, so their contribution focuses on the applications.

Although theses projects overlap to some extent they do aim to be complementary units and docollaborate in many tasks.

13

3 Bluetooth

3.1 General

Bluetooth is a short range wireless technology standard intended to replace cables connectingelectronic devices. It operates in the 2.4 GHz ISM band, which is 2400-2483.5 MHz. Although alot has happened since it was invented by Ericsson in 1994 the key features remain, aiming to berobust, low power and low cost. The Bluetooth core specification adopts two forms of Bluetoothwireless technology systems: Basic Rate (BR) and Low Energy (LE). The BR system includesoptional Enhanced Data Rate (EDR) and High Speed (HS) extensions.

The specification includes different levels of protocols used for communication and definitionsof how these protocols are to be used for a set of common use cases through profiles.

3.1.1 BR/EDR

The BR/EDR is what is referred to as classical Bluetooth. This is still the most commonversions of Bluetooth and even though EDR was added later it is unlikely to find a Bluetoothdevice without the extension today.

It divides the frequency range into 79 different channels according to 2402 + k MHz, wherek is the channel number and ranges between 0-78, leaving 2 MHz and 3.5 MHz as guard bandson the lower and upper end respectively. To avoid interference from other wireless devices in thesame frequency range, both Bluetooth and others, Bluetooth utilizes frequent frequency hopping.It is done at a rate of 1600 hops per second and uses a pseudo random pattern to make it unlikelythat two different Bluetooth connections use the same frequency more than occasionally. Themaximum throughput of BR is 1 Mbit/s while with the EDR extension it is up to 3 Mbit/s.

3.1.2 High Speed (HS) extension

The main feature of the HS extension to the BR/EDR is alternate MAC/PHY (AMP), whichutilizes the 802.11 standard also used in WiFi networks, on a separate radio to enhance the speed.The BR/EDR and the primary radio is still used for device discovery, pairing and connectionmanagement. The HS extension offers a theoretical data speed of up to 24 Mbit/s. Althoughit has been available since 2009 it has not reached the same commercial popularity as BR/EDRand BLE.

3.1.3 Bluetooth Low Energy

Originally developed by Nokia under the name Wibree the latest major addition to the Bluetoothstandard was adopted in the Bluetooth Specification 4.0, under the name Bluetooth Smart, orsometimes also referred to as Bluetooth Low Energy. The intention was to target devices withvery limited resources, such as coin-cell battery driven sensors, to make it possible to run a deviceon a small coin-cell battery for months or even years. It uses the same frequency range as theclassical Bluetooth does but divided into 40 channels instead of 79. In addition it has 3 fixedchannels designated for advertisements. The maximum throughput is about 1 Mbit/s which iscomparable to BR without the EDR extension. However, one of the features which reduce theenergy consumption is that the application utilizing the Bluetooth connection can manage theconnection interval, from 7.5 ms up to 4.0 s, which affects the throughput.

14

3.2 The Bluetooth Stack

Bluetooth is defined as a layer protocol architecture referred to as the Bluetooth stack. Thestack can be divided into controller and host parts as illustrated in Fig. 3.1 where the greenparts belong to the controller and the blue part to the host. The controller and host will bedescribed in this section as well as the Host controller interface (HCI) which defines how the hostand controller interacts and communicates with each other.

Figure 3.1: An example of the Bluetooth BR/EDR stack with the controller and host partseparated

3.2.1 Controller

The controller is often implemented in the local Bluetooth hardware adapter. In every Bluetoothcore system there is a Primary Controller which may be either a BR/EDR Controller, a LEController or a combined BR/EDR+LE Controller. It may also have one or more secondarycontrollers, which may be an AMP controller. In a system implementing a combined primarycontroller and an AMP controller some resources may be shared between the controllers whereasothers are dedicated to a specific controller.

The BR/EDR Controller includes the

15

• Radio

• Baseband

• Link Manager

• optional Host Control Interface (HCI)

3.2.2 HCI

The HCI belongs to both the Host and Controller. While it is not mandatory in the stack itis seldom omitted since it standardizes the interface between the controller and host. This isvaluable since it ensures interoperability for different manufacturers of controllers/hosts.

There are four types of messages which go through the HCI. These four messages are

• Command packets - which are packets sent from the host to control the Bluetooth adapter

• Event packets - which are generated by the Bluetooth adapter to alert the host of an eventof interest

• Asynchronous Connection-Oriented (ACL)

• Synchronous Connection-Oriented (SCO).

The two latter are described briefly below.

3.2.2.1 Asynchronous Connection-Oriented (ACL)

ACL is the most common type of messages for communication over Bluetooth and an ACLlink must always be established between two actively connected devices. These messages areoften divided into ACL-C, carrying control data from LMP, and ACL-U, carrying user data fromL2CAP and is the one passing the HCI. As RFCOMM is encapsulated in L2CAP packets they arealso transferred over an ACL link. In general if a packet is unacknowledged it is retransmitted,although this can be limited if needed for isynchronous data. A benefit of using packets is thatinformation can be compressed and sent when available in a variety of sizes as depicted in Fig.3.2.

3.2.2.2 Synchronous Connection-Oriented (SCO)packets

As opposed to the ACL, packet oriented communication devices can also establish a connectionwith periodically reserved time frames on an established ACL connection as depicted in Fig. 3.2.In general SCO offers no retransmissions, but enhanced SCO (eSCO) is more flexible and canoffer retransmissions.

SCO is intended for low latency audio connection, used for hands free phone calls, but anyregular data stream could use this method. The Bluetooth audio connection transfers data at64 kB/s and supports frequencies up to 4 kHz. This frequency range is enough for speech butnot for higher quality audio such as music streams.

16

Figure 3.2: Visualization of the communication using ACL and SCO. From [10]

3.2.3 Host

The host is the software stack in the host computer which communicates with the Bluetoothadapter. It consists of a set of protocols designed for different use cases, which in some casesdepends on other protocols. On top of the protocols profiles are used to define how the protocolsare to be used to certain, common, use cases. Which protocols are needed in the implementationof a stack are determined by which profiles are to be supported and their protocol dependencies.

3.3 Protocols

In the following section a brief description is made of the host protocols used by the profiles inthis thesis.

3.3.1 L2CAP

The Logical Link Control and Adaption Protocol defines connection-oriented and connection-lessdata services to higher layer protocols. It offers protocol multiplexing as well as segmentationand reassembly operation. L2CAP is a mandatory part of the Bluetooth stack of any system asthe majority of all communication is based on the protocol, including mandatory profiles. TheL2CAP packets are passed to the HCI, or directly to the LMP, and sent over the ACL link.

3.3.2 RFCOMM

The Radio Frequency Communication protocol is a reliable data stream based transfer protocoldesigned to emulate a RS-232 serial port. It offers comparable services as TCP does in networkingin terms of reliability and that it is stream based. RFCOMM packets are encapsulated in L2CAPpackets.

3.3.3 BNEP

The Bluetooth Network Encapsulation Protocol defines how packets from various networkingprotocols are to be encapsulated before being transported over L2CAP.

17

3.3.4 Obex

Objecy Exchange is a transfer protocol that defines data objects and how they can be exchangedbetween two devices. It was originally developed by Infrared Data Association (IrDA) as IrOBEXbut is now adopted by other standards, such as Bluetooth.

3.3.5 SDP

The Service Discovery Protocol (SDP) defines how profiles and their services are to be advertisedfor remote devices to discover. It also includes information needed to connect to the service.

3.3.6 AVDTP/AVCTP

The Audio and Video Distribution Transport Protocol defines discovery, negotiation of parameters,establishment and transport of Audio and/or Video streams. AVCTP defines how commandmessages and responses are to be transported to control an audio or video stream. Both theseprotocols run on top of L2CAP.

3.4 Profiles

While the protocols described above describes how communication are to be done for differentpurposes the Bluetooth specification takes things a step further by defining functions and protocolsused to achieve higher level tasks through profiles. The top level profiles, describing the interoperabilitybetween applications, are called Application Profiles. In case of reuseability of common requirementsbetween application profiles one or more generic profile can be created. The Application profilesare then implemented as a superset of the generic profile. There is one generic profile that allBluetooth devices must implement, the Generic Access Profile (GAP). Other generic profiles are

• Generic Object Exchange Profile (GOEP) - Defines how to use OBEX protocol in order toexchange data objects

• Generic Audio/Video Distribution Profile - Defines the common steps to set up an audioor video stream.

The GAP and the application profiles of interest for this thesis are presented in this section.

3.4.1 Generic Access Profile (GAP)

3.4.1.1 Profile overview

The GAP defines the basic requirements for a device and describes how discovery, connectionsand security are to be handled. It is mandatory for all Bluetooth devices to implementc whichmakes every other implemented profile dependent on GAP.

3.4.1.2 Protocol stack

For BR/EDR the GAP is dependent on the Radio, Baseband, LMP, L2CAP and SDP layers. Allother profiles are dependent on the GAP which makes it, and the layers it depends on, mandatoryfor all Bluetooth devices.

3.4.2 Serial Port Profile (SPP)

The serial port profile defines how to set up an emulated serial port, through RFCOMM, betweentwo units. In practice any profile depending on RFCOMM also depends on SPP.

18

3.4.3 Phone Book Access Profile (PBAP)

3.4.3.1 Profile roles

The PBAP defines a protocol which is tailored for retrieving phone book objects with a client-servermodel based on OBEX. Thus two roles are defined :

• The phone book server equipment (PSE) which is the source of the phone book objects

• The phone book client equipment (PCE) which is the device that retrieves the phone bookobjects.

In the context of this thesis the PSE is the mobile phone and the PCE is the IVI.


Figure 3.3 shows the protocols and entities used by the profile. Except for the mandatory entities,Baseband, LMP, L2CAP and SDP, the profile also utilizes RFCOMM and OBEX. A phone bookserver and client must be running for the respective role. For the server role a vCard builderis needed to create the object to be transferred and on the other end, at the client, a parser isused to extract the desired information. The profile is dependent on the profiles GAP, GOEPand SPP. [11]

Figure 3.3: The protocol stack used by the PBAP

Before phone book objects can be exchanged a secure connection must be established betweenthe two devices. This initialization procedure includes bonding, security initialization messages,creation of link keys, encryption and service discovery.

19

3.4.3.3 Phone Book Objects

There are 5 types of phone book objects defined in PBAP specification 1.1:

• pb - The main phone book

• ich - Incoming call history

• och - Outgoing call history

• mch - Missed call history

• cch - Combined call history, includes the incoming, outgoing and missed calls.

The phone book objects are sorted in a virtual folder structure as illustrated in Fig 3.4. Asseen in the figure there might be several repositories which contain phone book objects as somecontacts may be stored locally on the mobile phone whereas some may be stored on the SIM (oreven different SIM cards as some phones support multiple SIM cards). The phone book objectscontain the individual entries which are represented under the vCard format. Each entry in aphone book object is identified by a handle, which is a 32 bit value, on the form handle.vcf .The handle 0.vcf in the main phone book objects is reserved for the owners vCard. If the ownervCard is not known it can reference an empty vCard or only the mobile number if it is knownto the PSE. The PSE shall support both vCard 2.1 and vCard 3.0 versions. The PCE can thenrequest a specific vCard version for the entries to be transferred.[11]

20

Figure 3.4: The folder structure used by the PBAP when pulling contacts [11]

3.4.3.4 Retrieval Features

The phone book objects can be retrieved by the PCE using two different features, downloading orbrowsing, of which at least one must be supported by the PCE but both must be supported by thePSE. The downloading feature allows the PCE to download an entire phone book object whichthen can be stored locally on the PCE. This might require a relatively large storage capacityand the feature is very basic and no sorting is possible. The browsing feature allows the PCEto select the phone book object of interest, i.e. the missed call history, and then either pull anindividual entry or a list of entries which can be sorted and filtered.

3.4.3.5 Call History

The vCard entries in och, ich, mch and cch are extended with the property X-IRMC-CALL-DATETIMEdefined by IrMC[13]. This property has a parameter which indicates if the call was MISSED,RECEIVED or DIALED which is especially useful for the cch entries. The property also has atime stamp which indicates when the call took place. As an example a call missed on March

21

20th, 2005 at 10 am would be stamped:

• X-IRMC-CALL-DATETIME;MISSED:20050320T100000

The handles of the call history entries are to be updated dynamically with 1.vcf being the mostrecent call in each object. If the number for a call history entry can be linked to a main phonebook entry at the PSE the contact information of that entry should be included when a callhistory entry is retrieved.

3.4.4 Hands Free Profile (HFP)


The HFP defines the protocols and functions used to achieve a low latency voice connection andremote control of a mobile phone through a hands free device. The profile defines two roles:

• Audio Gateway (AG)

• Hands-Free unit (HF), which serves as the Audio Gateway’s remote audio input and outputmechanism.

In the context of this thesis the AG is the mobile phone and the HF is the IVI.


Fig 3.5 shows the protocol and entities used in this profile. Except for the mandatory entities,Baseband, LMP, L2CAP and SDP, the profile also utilizes SCO, RFCOMM and requires aHands-Free control to handle the AT command communication between two connected devices.The profile depends on the profiles GAP and SPP.

3.4.4.3 Service Level Connection and SCO use

Connecting to the profile initiates a service level connection, the RFCOMM connection throughwhich the AT commands are sent, which is active as long as the connection lasts. The audio issent through a SCO channel encoded with Continuous Variable Slope Delta (CVSD) modulation.This connection is only active when there is a present audio stream.

22

Figure 3.5: The protocol stack used by HFP with additional entities needed

3.4.4.4 Features

The profile describes a list of features shown in Table 3.1 where the features noted with an Mare mandatory for the role and O are optional for the role to support. Each supported featureuses a set of mandatory procedures, see [12] for more information.

3.4.5 Advanced Audio Distribution Profile (A2DP)


A2DP defines how to distribute high quality audio content between two Bluetooth devices. Itdefines two roles,

• Audio Source (SRC)

• Audio Sink (SNK).

In the context of this thesis the source is the phone and the sink is the IVI system.


Except for the mandatory entities, Baseband, LMP, L2CAP and SDP, the profile also utilizesAVDTP as depicted in Fig. 3.6. The profile is also dependent on the profiles GAP and GAVDP.[13]

3.4.5.3 Compressed audio frames

The advanced audio indicates that it differs from normal ”Bluetooth audio”, which is used inHFP. The difference is that it is sent as compressed audio packets over L2CAP, which increasesthe throughput but decreases latency. As latency is not as important for music streams as it isfor voice calls the sink can keep a buffer to deal with retransmissons due to packet losses. [13]

23

Table 3.1: The features defined by the HFP documentation for HF and AG role respectively.M indicates mandatory to implement and O optional. Source [12]

24

Figure 3.6: The protocols used by the A2DP

The standard codec, which is mandatory to support, is the Low Complexity Subband Codec(SBC) but other codecs, such as MP3, are optional to implement. The codec parameters used ina connection between two devices are negotiated when establishing a connection to the profile.The compressed audio frame is encapsulated in a Real-time Transport Protocol (RTP) packetand further in a L2CAP packet before sent over an ACL link. [13]

3.4.6 Audio/Video Remote Control Profile (AVRCP)


AVRCP defines the protocols and procedures required to control an audio or video streambetween Bluetooth devices. It includes metadata, control and browsing commands. The profiledefines two roles

• Target

• Controller.

In the context of this thesis the Target is the mobile phone and the controller is the IVI.


As depicted in Fig. 3.7 the profile depends on the mandatory entities, the Baseband, LMP,L2CAP and SDP, and AVCTP. The remote control commands are defined by 1394 TradeAssociation through the AV/C Digital Interface Command Set Specification, depicted as AV/Cin Fig. 3.7.

3.4.7 Message Access Profile (MAP)


MAP is an OBEX-based profile to allow exchange of messaging objects, SMS, MMS and emails,between Bluetooth devices. It adopts a client-server model and defines the roles

• MSE - Message Server Equipment

• MCE - Message Client Equipment.

25

Figure 3.7: The protocols and other entities used by the AVRCP

However, this profile defines two different services, the Message Access service (MAS) and theMessage Notification service (MNS). In MAS the MCE acts as an OBEX client pulling messagesfrom the MSE acting as the OBEX server. However, in MNS the MSE acts as the OBEX clientpushing messages to the MCE. This is needed for the phone to automatically transfer an incomingmessage to the IVI.

3.4.7.2 Protocol Stack

Figure 3.8 shows the protocols and entities used by the profile. Except for the mandatory entities,the baseband, LMP, L2CAP and SDP, the profile also utilizes RFCOMM and OBEX. A messageserver and client must be running for the MSE and MCE respectively. If MNS is supported theMSE must also have a client, and the MCE a server, running. For the server role a bMessagebuilder is needed to create the object to be transferred and on the other end, at the client, aparser is used to extract the desired information. The profile is dependent on the profiles GAP,GOEP and SPP. [14]

3.4.7.3 Message representation

The message objects are sorted in a virtual folder structure as illustrated in Fig 3.9. Exactlyhow the folder tree is set up may vary on different MSE’s but the folders

• telecom/msg/inbox

• telecom/msg/sent

• telecom/msg/deleted

must always be present. An outbox must also be present if the MSE device has the ability totransmit messages and a draft folder must also be present if a similar folder, with saved, unsent,messages, is present on the MSE. In addition any custom folders, such as user-defined folders,are supported.

There are several object defined in the specification, some worth mentioning are

• Folder-Listing objects - An XML object with information of all subfolders in the CWD

26

Figure 3.8: The protocols and other entities used by MAP

• Message-Listing objects - An XML object with information of the messages in the CWD,as illustrated in Fig 3.10 taken from the MAP specification [14]

• bMessage objects - the actual text message encapsulated in bMessage format, as illustratedin Fig 3.11 taken from the MAP specification [14].

3.4.8 Personal Area Network Profile (PAN)


PAN defines how to use BNEP to provide networking services between Bluetooth devices. Itdefines the roles

• Network Access Point (NAP) - A device which may work as an Ethernet bridge. A PANuser may connect to a NAP and exchange Ethernet packets through BNEP. The NAP hasan additional network connection to a different network which the PAN user, indirectly,gets access to

• Group Ad-hoc Network (GN) - Similar to NAP with the exception that it does not provideaccess to an additional network connection. Instead the GN service is used to create atemporary network between two or more Bluetooth devices

• PAN User (PANU) - The Bluetooth device that uses a NAP or GN service. It also supportsdirect PANU to PANU connection.

In the context of this thesis the IVI will work as a PANU and the phone as a NAP.[15]

27

Figure 3.9: The virtual folder tree used by the MSE to expose messages

28

Figure 3.10: An example of a Message-Listing object from the MAP specification [14]

Figure 3.11: An example of the bMessage object from the the MAP specifcation [14]

29

Figure 3.12: The protocols and other entities used by PAN


As depicted in Fig. 3.12 the profile depends on the mandatory entities, the Baseband, LMP,L2CAP and SDP, and BNEP. It is also dependent on a Management Entity (ME) to handleprocedures during initialization, configuration and connection management. [15]

3.4.8.3 Example connection in the IVI use case

An example of the flow of events occurring in a connection between the IVI and the phone maybe

1. Either the phone, NAP, or the IVI, PANU, can initiate the connection

2. The IVI initiate the L2CAP channel for BNEP after an ACL connection has been established

3. Once the L2CAP channel has been established Ethernet traffic can start. The IVI needsto use services provided by the phone to obtain an IP address for the connection, or verifythat an IP address previously used is valid for the connection

4. The connection may be terminated at any time by either of the roles.

3.5 Security

The most significant threats for wireless communication in general are Man-In-The-Middleattacks and eavesdropping and Bluetooth is no exception. The security mechanisms definedin the Bluetooth Specification specifically address these threats. The scope of the securityfeatures defined in the Bluetooth specification is between two devices connected via Bluetooththus end-to-end security is not possible if one of the devices serves as a gateway to a largernetwork. Such end-to-end security must be implemented above Bluetooth if desired.[16]

3.5.1 Bluetooth Security Model

The security model adopted by the Bluetooth core specification includes five distinct securityfeatures:

• Pairing - The creation of shared secret keys between two devices

• Bonding - Storing the secret keys from a pairing procedure to be used in subsequentconnections

30

Table 3.2: The algorithms used for key generation, device authentication and encryption forthe different security specifications [16]

• Device authentication - Verification of connecting device using Bluetooth Device Address

• Encryption - Message Confidentiality

• Message integrity - Protection against message forgeries, added in Version 4.2

The security specification has evolved over time and an important part of Bluetooth is to bebackwards compatible. The current specification includes methods from three different versionsto achieve this for BR/EDR security. These are Legacy Pairing, Secure Simple Pairing (SSP) andSecure Connections. When the pairing procedure has been completed between two devices theymay connect to any of the services/profiles supported by the remote device. Legacy pairing isnow only supported for backwards compatibility as Bluetooth devices supporting at least version2.1 requires Secure Simple Pairing but may still be able to use Legacy pairing when bondingwith an older device if needed. SSP provided a new pairing procedure from a user perspective asdifferent I/O capabilities of devices uses its own pairing procedure. In addition it also changedthe algorithm used for key generation to the FIPS approved P-192 Elliptic Curve Deffie-Hellman,but leaving the algorithms for device authentication and encryption unchanged. In specificationversion 4.2 SSP was upgraded with improved algorithms for encryption and authentication andis now an own branch under Secure Connections. The algorithms used for key generation, deviceauthentication and encryption for the different security models are shown in Tabl. 3.2 [16]

3.5.1.1 Crucial security implemented in the controller

The security features are implemented in the Bluetooth hardware, in the controller in theBluetooth stack, as it is considered to be more safe than implementing things in the host.These features includes the crucial parts key generation, device authentication and encryption.The host still needs some security management in terms of user I/O and storing the generatedkeys and the Bluetooth addresses. This also means that the stored keys will not follow theBluetooth chip when moving a USB dongle for example but will remain on the device with thehost implementation.

3.5.2 Legacy Pairing

The Legacy Paring procedure used a four digit PIN code which was entered on both devices, ifidentical the pairing was successful. For devices without the ability to enter a PIN a static PINcode was used, often ”0000” or similar. One problem was that many users did not choose thisrandomly so an attacker could easily check the most common combinations in a very short time.

31

3.5.3 Secure Simple Pairing

In version 2.1 the SSP was introduced with the aim to simplify the pairing procedure whilemaintaining or improving the security. These two goals are often in conflict with each other butmuch effort has been spent in order achieve a satisfactory result. It was introduce together withfour associated models

• Numeric Comparison

• Just Works

• Out Of Bands

• Passkey Entry

to address the issue of different I/O capabilities of Bluetooth devices, each model designed for adifferent combination of I/O capabilities of two connecting devices[16]. It also forces encryptionto be used for all communication except for SDP[17].

3.5.3.1 Algorithms

As shown in Tabl. 3.2 the algorithm utilized for key generation was changed to P-192 EllipticCurve Deffie-Hellman (ECDH), an Federal Information Processing Standard (FIPS)-approvedalgorithm. For device authentication and encryption the algorithms, E0 and SAFER+, wereunchanged. [18]

3.5.3.2 I/O Capabilities

The defined input capabilities [16] are

• Yes/No - The device can accept or decline an incoming connection

• Keyboard - The device can enter a six digit number

• No Input

and output capabilities are

• Numeric Output - The device can display a six digit number

• No output.

3.5.3.3 Associated Models

3.5.3.3.1 Numeric Comparison The Numeric Comparison model is designed for ascenario where both devices have Numeric output and Keyboard or Yes/No input capabilities.An example of such scenario is a cell phone and a PC. When attempting to pair a random sixdigit number is displayed on both devices and the user is prompt to respond with ”Yes” if thenumbers match and ”No” otherwise. Numeric Comparison provides passive eavesdropping andMITM protection and results in an authenticated connection. [16]

32

3.5.3.3.2 Passkey Entry Passkey Entry is designed for the scenario where only onedevice has Numeric output but the other device Keyboard input capabilities. An example ofsuch scenario is a keyboard and PC. With this method a six digit passkey is displayed on onedevice and the user is prompt to enter that passkey on the device with input capability. If theinput matches the passkey the pairing is successful. Passkey Entry provides passive eavesdroppingprotection and MITM protection and results in an authenticated connection.[16]

3.5.3.3.3 Just Works Just Works is designed for the scenario where at least one of theconnecting devices does not have display nor input capabilities. An example of such scenario is aheadset and a phone, where the headset has no input and no output as defined above. Internallythis method uses the Numeric Comparison protocol but it never displays the number to the user.The user may be asked to accept the connection on the device with I/O capabilities but this isnot mandatory. Just Works provides passive eavesdropping protection but no MITM protectionand results in an unauthenticated connection. [16]

3.5.3.3.4 Out Of Bands Out Of Bands allows pairing using other technologies, such asNear Field Communication (NFC). If it provides passive eavesdropping and MITM protectiondepends on security methods of the technology used.[16]

3.5.4 Secure Connection

3.5.4.1 Algorithms

In specification version 4.2 the BR/EDR security was upgraded to use only FIPS approvedalgorithms. The encryption algorithm was changed to Advanced Encryption Standard - Counterwith cipher block chaining message authentication code (AES-CCM), as defined in [19]. Withthe AES-CCM algorithm the concept of message integrity was introduced, including a MessageIntegrity Check to the message payload. The device authentication algorithm was changed toHMAC-SHA256 and the key generation algorithm was upgraded to the stronger P-256 ECDH,instead of P-192.

3.5.4.2 Pairing procedure

The concept of I/O capabilities and associated models was unchanged from SSP thus makingthe pairing procedure identical from a user perspective.

3.5.5 Detectable and Connectable only when needed

The Bluetooth specification defines a scan parameter with two scan modes which can be enabledindependently. These are

• Inquiry Scan - Visible when remote devices are scanning (Discoverable)

• Page Scan - Connectable

and can be managed by any application. A device without Inquiry scan enabled will not bevisible for other scanning devices but can be connected to for someone who knows the 48-bit,unique, ID of the device, the Bluetooth Device Address, if Page scan is enabled. These modescan be switched on and off at any time meaning that they can be enabled only when needed. TheNational Institute of Standards and Technology (NIST) recommends in [17] to be in discoverableand connectable mode for as short time as possible and avoid it in public places to maximizesecurity.

33

Table 4.1: The used Bluetooth hardware on the different platforms where O indicates that thecombination has been tested and X that it has not been tested

4 Hardware and Development Environment

4.1 Tested Platforms

The main work was done on a VM with the aim of also testing it on a CCpilot VA display. Asnone of these systems could run the latest Bluetooth stack for Linux a laptop running Ubuntuwas also used for some testing.

4.1.1 CCPilot VA

CCPilot VA is a freely programmable 7” display. The computing core consists of a Freescalei.MX 537, 32-bit ARM processor running a freely programmable Linux system with kernel version2.6.35. It also comes with the LinX Software Suit base package which is a package of commonlyused software to simplify development. The Linux Bluetooth stack, Bluez 4.101, is installed forBluetooth support.

4.1.2 Virtual Machine

The VM, provided by maximatecc, is running a standard kubuntu 14.04, kernel 3.13.0, with allstandard features. It also has a set of pre-installed applications, such as Qt Framework and QtCreator, with configurations to quickly be able to develop for different CCPilot displays. TheLinux Bluetooth stack, Bluez 4.101, is installed for Bluetooth support.

4.2 Bluetooth Hardware

The Bluetooth hardware used in the project is presented in Tab. 4.1. Together with the CCpilotVA, a CrossLink AI, a wireless access module designed for the CCpilot connected through USB,as well as a generic Bluetooth USB adapter, Hama 049232, was used. The Hama-adapter was alsoused together with the VM and the Ubuntu-laptop but with those setups the built in Bluetoothadapter of the host computer was mainly used.

4.3 Qt

Qt[20] is a cross-platform development framework used to develop application software and isoften used with the IDE QtCreator. It is available both under a commercial license and differentopen source licenses. It is mainly designed for enabling easy development of GUI applications

34

using QML, a user interface markup language, combined with the power of C++ and JavaScript.

In order to simplify event handling Qt introduced a signals and slots mechanism. A widget/objectmay emit a signal with event information. The signal can be picked up by one or more objectsby connecting a slot to it.

35

Figure 5.1: The Bluez architecture where kernel and user space are separated

5 Software Components in Linux

5.1 BlueZ

Bluez is the most commonly used Bluetooth stack for Linux and is seen as the standard Bluetoothstack for Linux. It provides support for the core protocols and layers through kernel modules aswell as DBus API’s for a set of profiles through daemons, a process running in the background,in the user space as illustrated in Fig. 5.1. Some protocols and profiles which are supported withan API relies on other software components to be fully functional, as with the OBEX protocoland the profiles based on it, shown in Fig 5.1, is implemented through Obexd. The support canalso be extended in the user space either through third party software or custom made software,using the Bluez development library libbluetooth− dev.

5.1.1 Kernel configuration

Kernel configuration is needed to use Bluetooth in Linux and can either be statically enabledor enabled as kernel modules in which case they can be loaded into the kernel at runtime whenneeded using modprobe. The enabled configurations used in this thesis are presented in Tabl.5.1 together with their module names, used when using modprobe, and a brief description of it.

5.1.2 Versions

BlueZ 5.39 is the latest major release of the stack and supports BLE and BR/EDR but not theHS extension. According to Bluez documentation it supports the protocols and profiles in Tabl5.2 although some protocols and profiles depend on external components. However, Bluez 5 andlater requires a Linux kernel version 3.4 (3.5 for Low Energy) or later which is not currently

36

Table 5.1: The kernel configurations needed to be enabled, their module names for loading atruntime and a brief description of it

available on CCpilot displays, which use a kernel with version 2.6. Instead Bluez 4.101, which isthe last release of version 4.X, needs to be used and is the focus of this thesis. The main differencebetween 5.39 and 4.101 is that 4.101 does not have stable BLE support. The DBus API’s andsome internal logic is also different between the two major releases making it non-backwardscompatible. Bluez 4.X does not provide a list of supported protocols and profiles but the mainprotocols for BR/EDR are supported and the support of the profiles of interest is presented inthis section.

5.1.3 A2DP support

An interface, org.bluez.AudioSource, for connecting to a remote device acting like a sourceis available in the main user space daemon, bluetoothd, in Bluez 4.101. To actually makeuse of it an application must register the interface name org.bluez.MediaEndpoint togetherwith a set of functions defined by the bluez media − api.doc before trying to connect. Whenconnecting to an A2DP service Bluez will call org.bluez.MediaEndpoint.SelectConfigurationwith a set of codec parameters supported by the remote device. The application must comparethis to its own capabilities and send the best match back in a reply. Bluez will then callSetConfiguration on org.bluez.MediaEndpoint with the same codec parameters as negotiatedearlier and a transport path which is used to acquire the audio stream. The application mustthen monitor the org.bluez.AudioSource.ProperyChanged signal to see when the property Statechanges to Playing. When it does the application must call org.bluez.MediaTransport.Acquireon the transport path received earlier to get the file descriptor, which is read to get the audiopackets, together with the maximum transfer unit, the size of the packets. When an audio streamis active the audio packets must be unpacked and decoded using the agreed upon codec beforebeing sent to an audio output. [21]

37

Table 5.2: The list of supported protocols and profiles, including roles and versions, for Bluez5.39

38

The basic concept and events described above applies to Bluez 5.X as well though some changeshave been made, such as the interface names and how properties are handled. The handlingof theses events is usually done in an external software component, such as PulseAudio, whichunpacks, decodes and routes it to the audio hardware behind the scenes both for Bluez 4.101and 5.X.

5.1.4 AVRCP support

Bluez 4.101 only supports the TG role of AVRCP. It does provide an interface for the CT roleunder the interface org.bluez.Control but the only method calls available are VolumeUp andVolumeDown, which are not fully implemented. To make proper use of the CT role Bluez 5 isneeded. The interface changed with the release of Bluez 5.0 to org.bluez.MediaControl1 withthe method calls

• void Play()

• void Pause()

• void Stop()

• void Next()

• void Previous()

• void VolumeUp()

• void VolumeDown()

• void FastForward()

• void Rewind()

which increases the functionality to a reasonable level. An experimental interface, org.bluez.MediaP layer1,also appeared in Bluez 5.0 and 5.1. This interface was adopted in the release of 5.2 withbasically the same functionality as org.bluez.MediaControl1, deprecating that interface, as wellas properties including, but not limited to, metadata and browsability of media on the remotedevice.

5.1.5 HFP support

Bluez 4.101 provides a DBus API, through bluetoothd, to connect with a HFP service on aremote device but is intended to be used with an external telephony stack, such as oFono, tohandle the AT commands over RFCOMM. The API was dropped in Bluez 5.0 and is after thatintended to be fully implemented in an external telephony stack.

The sound, transported over an SCO link, needs to be routed to and from the audio hardware,using Advanced Linux Sound Architecture (ALSA). While formerly supporting direct connectionbetween Bluez and ALSA through the bluez − alsa package this support was dropped in Bluez4.100. The simplest way to handle this now is through external software components, such asPulseAudio.

Bluez, PulesAudio and oFono are well integrated with each other and though they providerespective API’s for user applications they communicate internally. An overview of the HFP

39

Figure 5.2: The user application (UI) communicates with the middleware components,PulseAudio, Bluez (bluetoothd) and oFono, through a DBus API. These componentscommunicate with the appropriate kernel modules as well as with each other through DBus.

implementation architecture with PulseAudio and oFono is depicted in Fig. 5.2 where telephonycontrol is done through oFono, PulseAudio manages the SCO connection and routes the audioto and from the audio hardware. Bluez manages the device and routes necessary informationbetween oFono and PulseAudio. These three software components forms a basis for most IVI’simplemented in Linux, adopted by GENIVI and used in the Tizen IVI implementation.

5.1.6 PAN support

An interface, org.bluez.Network, is provided by the main user space daemon, bluetoothd, inBluez 4.101 to connect to a remote device sharing its network connection over Bluetooth. Callingorg.bluez.Network.Connect with the uuid or string representation of the role to connect as (gn,nap or panu) will on success return the created network interface name, such as bnep0. To beable to actually use it the network interface needs to be configured and managed. This is oftendone with an external software component, such as NetworkManager or Connman.

5.1.7 MAP & PBAP support

The obex protocol is not implemented in Bluez 4.101. This is solved by adding the softwareObexd which implements the obex protocol and obex based profiles on top of Bluez. Obexd wasofficially added to the Bluez project with the release of Bluez 5.0. Both 4.101 and 5.39 supportsboth the client and server sides of MAP. However, MNS support was added in version 5.4. Thus

40

with Bluez 4.101 and obexd 0.46 messages need to be pulled from the message server, in thiscase the phone.

5.2 Obexd

Obexd is a software component which is used in addition to Bluez to implement the obex protocoland the profiles based on that protocol. It offers both a client and a server daemon. In the IVIwe are interested in the client daemon as the mobile phone will serve as the server.

The client daemon offers a DBus API but uses the session DBus as opposed to the system DBusused by Bluez. To access the MAP and PBAP client APIs an obex session must be created usingthe org.openobex.Client interface with the method call CreateSession(dictdevice) sending a dictentry as an argument. The dict argument is configured through parameters and must containan entry for the Destination, the Bluetooth device address of the phone, and the Target, whichis the target profile, MAP or PBAP . Other possible parameters are Source and Channel. Thereply contains the path to the opened session where the API is exposed.

5.2.1 PBAP API

Using obexd version 0.46 the resulting obex session with PBAP as parameter will expose anAPI with the following method calls under the interface name org.openobex.PhonebookAccess

• void Select(string location, string phonebook) - Needs to be called before any othermethod to select a phone book object.

Location is where the phone book object is stored, e.g. int for internal memory or sim forfirst SIM card.

Phonebook is the phone book object, e.g. pb for main phone book or ich for incomingcall history.

• string PullAll() - Returns the selected phone book object as a single string on vcardformat.

• array{string vcard, string name} List() - Returns a list of the selected phone bookobject with vcard handle, e.g. ”1.vcf”, and name of each entry.

• string Pull(string vcard) - Returns the full vcard associated with the given vcard handle.

• array{string vcard, string name} Search(string field, string value) - Returns alist, vcard handle and name, of entries which match the search condition.

The field is the property which the value is tested against.

• uint16 GetSize() - Returns the number of entries in the selected phone book

• void SetFormat(string format) - Set the vcard format used for the session. Defaultsto ”vcard21”

• void SetOrder(string order) - Set the order returned vcards are presented. Defaults to”indexed”

41

• void SetFilter(arraystring) - Set the properties which should be included in the vcards.An empty string may be sent as an argument to clear the filter, which is the default setting.

• arraystring ListFilterFields() - Returns all possible properties which may be used inthe SetFilter-method

• arraystring GetFilter() - Returns the current filter settings

5.2.2 MAP API

Using obexd version 0.46 the resulting obex session with MAP as parameter will expose an APIwith the following method calls under the interface name org.openobex.MessageAccess

• void SetFolder(string name) - Sets the current working directory (CWD) to the suppliedname

• string GetFolderListing(dict filter) - Returns the subfolders of the CWD

• string ListMessages(string folder, dict filter) - Returns a string of all messages inthe CWD in XML format as a MsgListingObject according to MAP specification.

No existing function seems to exist to transfer the actual bMessage. However, the messagecontent for SMS is available under the subject parameter in the Message-Listing object.

5.2.3 Changes with different versions

Using a different version of obexd the exact API’s may differ. The PBAP API is quite mature in0.46 and have not changed drastically in Bluez 5. However, as MAP was added in recent releasesit was not mature and some more significant changes have been made to the API since obexd0.46. An interface similar to MessageAccess is still there but a separate interface has been addedto transfer the actual bMessage object, see obex-api.txt in Bluez 5.39 for more information. Amajor change affecting all APIs is the namespace change which applies to obexd from version 0.47and onwards, including obexd in Bluez 5.X repository. The part ”org.openobex.XXX” has beenreplaced with ”org.bluez.obex.XXX” for both service and interface names and the interface nameshave also been numbered. The numbering makes it possible to keep older versions alongside thenew one for backwards compatibility in case major changes are made to an interface in the future.

Some important versions for PBAP and MAP:

• Initial support for PBAP - Obexd v0.9

• Initial support for MAP - Obexd v0.43

• Change namespace to ”org.bluez.obex” - Obexd v0.47

• Added to Bluez repostory after Obexd v0.48 - Bluez v5.0

• Add support for MNS to MAP - Bluez v5.4

42

Figure 5.3: How the communication flows from a PA source to a PA sink, through themodule-loopback

5.3 Audio

5.3.1 Advanced Linux Sound Architecture - ALSA

ALSA provides sound card drivers in the Linux kernel as well as a user space library. With thelibrary and user utilities it is possible for programs to communicate directly with the sounddevices. This works well when raw sound is transported from a single source to a singledestination. In a situation where there might be multiple possible sources and destinationsthings start to become more difficult.

5.3.2 PulseAudio

PulseAudio (PA) is a software package which serves as a sound server. It is a middleware andresides just above the ALSA kernel in the user space. A goal is to make sure that sound passesthrough PA instead of directly being sent to the sound devices. PA can then prioritize andmanage different audio streams. This is very convenient as the developer wont need to managethe transitions between HFP and A2DP audio streams and in some cases other local audiosources. Another benefit of PA is that even though it is designed for Linux it has been ported toother platforms as well, such as MacOS X and Windows XP [22], thus providing cross platformcapabilities.

5.3.2.1 Interaction with ALSA

The PA is built on different modules which can be loaded and unloaded depending on what PA isused for. Most modern software can detect if PA is present and use its API directly, in which casethe audio source is also a PulseAudio source. The source-ouput, the output of the PA source,is connected to a sink-input, the input to the PA sink, through the module-loopback. For thosethat cannot communicate directly with PA it exposes itself as a virtual device and enables itselfas the default ALSA sink. ALSA will then output sound to PA which then reroutes it back toALSA with a designated sink as depicted in Fig 5.3.

5.3.2.2 Bluetooth modules

There are three modules related to Bluetooth

• module-bluetooth-discover - Detects available Bluetooth audio devices and load audiodrivers. Needs to be loaded for PA to work with Bluetooth

• module-bluetooth-device - An abstraction of a Bluetooth source or sink

43

• module-bluetooth-policy - Handles the transition between HF GW and A2DP. Loadsmodule-loopback automatically, which connects the incoming sound to a source, whenan active audio stream is present over Bluetooth.

For HFP PA will handle the SCO connection, routing the audio to and from the audio hardwarefor both roles, and for A2DP it will encode/decode the audio and send it to/from the audiohardware, depending on the active role of the profile.

5.3.2.3 Support in different versions

As major changes was done in Bluez with the transition from version 4 to 5 the supportedfeatures for the different Bluez versions in PA has had the following history

• 4.0 - Bluez 4 : A2DP and HFP/HSP (sound only)

• 5.0 - Bluez 5 : A2DP support added

• 6.0 - Bluez 5 : HFP (sound only) and HSP (sound + native backend) added.

In 6.0 and later versions a parameter has been added to /etc/pulse/default.pa, a configurationfile for PA, when loading module-bluetooth-discover for selecting which backend to use. Theavailable choices are ofono, native or auto where it has been considered most stable to chooseofono or native.

5.3.3 Audio Configuration in Bluez

When bluetoothd is started it automatically starts the services which are supported based onloaded kernel modules and settings in configuration files. The supported audio interfaces can beenabled by setting them to true in /audio/manager.c in the Bluez 4.101 source code or editing/etc/bluetooth/audio.conf and restarting bluetoothd. In the configuration file the differentinterfaces may be enabled or disabled under the General option.

5.4 Telephony stack - oFono

oFono is an open source project which provides a telephony application development frameworkin Linux. It is built around a core daemon which provides the base level service and is responsiblefor loading relevant oFono drivers and plugins. An important concept in the core daemon is themodem abstraction. Each device is seen as a modem and is managed independently regardless ofthe underlying technology used. The drivers are designed to give support for different underlyingtechnologies, from full-featured modems to Bluetooth devices. Another concept in oFono is atomswhich provide easy to use DBus API’s for different service and can detect the presence of otheratoms and exchange information for further enhanced functionality. The plugins are designed toprovide relevant drivers and atoms for different services and can also be used to extend oFonoto interact with other services on the system.

oFono is well integrated with other communication projects such as Bluez and Connman. As forthe Bluetooth protocol it is used to implement the profiles HFP, DUN and SAP. More specificallyit is used to handle the AT command communication within these profiles. [23]

44

5.4.1 HFP AG plugin

Four atoms are associated with the HFP AG plugin, the voicecall, network, SIM and emulatoratom. The plugin is also responsible for registering the SDP record in Bluez. Enabling themodem associated with a Bluetooth device will make the hand shake procedure and establishthe Service Level Connection of the HFP.

5.5 Network management

To simplify configuration, setup and management of network connections a management softwareis often used. In the Linux community there are two major ones which supports Bluetooth,Connman and NetworkManager. NetworkManager was originally designed for desktop computersand was for a long time considered to be the standard Linux management tool. As the need fornetwork connection on embedded devices grew Connman was developed to be more flexible fordevices with limited resources. NetworkManager has since then improved in similar envionmentsand the gap between them has gotten smaller. However, an advantage of Connman is that it isbacked by the same team as Bluez, which vouches for good compatibility when new versions ofBluez are released.

5.6 DBus

DBus is an inter-process communication (IPC) mechanism which is widespread in open sourcesoftware today. This allows for different processes or applications to send information betweeneach other to notify that an event occurred, send data or use methods among other things.

The DBus service provides multiple message busses for different purposes. The most commonones are the system bus and the session bus. The system bus is system-wide and is sharedbetween different users whereas the session bus often is created solely for a specific user at login. More session busses may be created by different applications but the session bus created atlog in is referred to as the session bus.

5.6.1 Service, Path and Interface

To distinguish between different applications, and objects within an application, using the samebus a unique and well-known address is used. The address consists of three parts, a servicename, an object path and an interface name. The service name represents the connectionbetween the bus and an application. They are often on the form org.myDomain.myApp inorder to keep them uniquely identifiable. An application may also provide multiple objectswhich messages can be sent to and from. This is handled by the object path which is aconceptual path in order to group objects. The actual form is any arbitrary file structure andmay be on the form /audio/object1. Finally the interface defines a group of methods and signalswhich are advertised on the bus. The unique address combining these three parts may thenlook something like org.myDomain.myApp /object1 org.mayDomain.Interface1.Method1 whereorg.myDomain.myApp is the service, /object1 is the object path, org.myDomain.Interface1 isthe interface and Method1 is the method within the interface being called.

5.6.2 Methods and signals

Methods and signals are used to send and receive information to and from an application. Amethod is a message sent to the application to cause code to be executed in the application. The

45

method will then return a success or error message depending on the outcome of the methodcall. Together with the success message an optional return value may be supplied. Method callsalways have exactly one source and one destination. Signals are messages from the applicationwhich is exporting the interface and are available to any number of other applications listening.

5.7 Qt - Bluetooth Support

Qt5 provides a limited API for Bluetooth, Qt Bluetooth, supported on Android, BlackBerryand Linux, both Bluez 4 and 5. In this section the APIand how it can be extended is brieflydescribed.

5.7.1 QtBluetooth Classes

The QtBluetooth API can be used to scan, retrieve information about and connect to remotedevices. To translate it to Bluetooth profiles it is the GAP and SDAP which are implemented.In addition to this setting up a RFCOMM connection and transferring files are explained inexamples.

5.7.1.1 Scanning Classes

Scanning for remote devices can be done either by the QBluetoothDeviceDiscoveryAgent- orQBluetoothServiceDiscoveryAgent-class. The device discovery class will return brief informationabout the device address and class, in a QBluetoothDeviceInfo object, for all discovered remotedevices. To find out the services supported the service discovery class must be used. This classcan either be used to discover services on a specified device or for all detectable devices. Foreach service discovered a QBluetoothServiceInfo object is created with information about theservice and the device it was discovered on. The QBluetoothServiceInfo class is also used tocreate custom service records which can be accessed by remote devices.

5.7.1.2 Connecting through QBluetoothLocalDevice

The QBluetoothLocalDevice class enables access to a local Bluetooth adapter. It can be usedto retrieve information of the adapter, such as name and address, and can be used to set scanparameters for the adapter. In addition it is used to connect and pair with remote devices.

5.7.1.3 Socket and Server

The QBluetoothServer and QBluetoothSocket classes are used to freely send information betweendevices. It can be done either by L2CAP or RFCOMM, in which case it is an implementationof the SPP. The server class is intended to be set up on a device as a service and should beaccompanied with a service record, in the form of a QBlueoothServiceInfo object, containing allthe information needed to connect to the service. The socket class can be used to connect to aserver on a remote device using the information in the QBluetoothServiceInfo object.

5.7.1.4 OPP Transfer Classes

One of the implemented profiles in QtBluetooth is the OPP. It can be used without being pairedwith the remote device in advance. Three classes are designed to be used in this process, theQBluetoothTransferRequest, QBluetoothTransferManager and QBluetoothTransferReply. Moreinformation on how it is used can be found in the Qt tutorial, [24].

46

5.7.1.5 Other classes

Other classes include different support classes, such as QBluetoothAddress and QBluetoothUuid,to help manage and validate the format of data types. There are also classes for BLE but theyhave not been investigated in this thesis.

5.7.2 Extending the support

To implement the functionality described in this report the native API must be extended. QtBluetooth for Linux is built on Qt D-Bus which is an abstraction of the DBus interface. AQDBusAbstraction class is created for each DBus interface and can then be used to call methods,through Qt’s slots, and listen to signals, through Qt’s signals.

5.7.2.1 DBus abstraction

XML documents for the D-Bus interfaces can be generated in Linux konsole by calling

dbus−send −−s e s s i o n −−pr int−r ep ly −−dest=s e r v i c e . name / obj /path \org . f r e ede sk top . DBus . I n t r o s p e c t a b l e . I n t r o s p e c t > name . xml

which utilizes the common interface org.freedesktop.DBus.Introspectables method Introspect. Themethod will return all object paths and interfaces together with methods, signals and argumentsof the chosen service, path and bus and write it to the named XML-file. The result may looklike

method return sender=:1.80 -> dest=:1.136 reply serial=2string >!DOCTYP node PUBLIC ”-//freedesktop//DTD D-BUS Object Introspectation

1.0//EN”http://www.freedesktop.org/sandards/dbus/1.0/introspect.dtd”>

<node>< i n t e r f a c e name=” i n t e r f a c e .Name”>

<method name=”Method1”><arg type=”o” d i r e c t i o n=” in ”/>

</method><method name=”Method2”>

<arg type=” s ” d i r e c t i o n=” out ”/></method>

</ i n t e r f a c e></node>

”

where the methods and signals for interface.Name are advertised and the type of the argumentsis described by signatures defined by DBus, o and s in this example, and the direction of thesignal. Some of the lines in the beginning and the last quote needs to be removed to makeit a valid XML document. The XML document can then be used to automatically create aQDBusAbstraction class of the interface using qdbusxml2cpp by calling

qdbusxml2cpp -p my DBus interface.h:my DBus interface.cpp name.xml interface.Name

where −p indicates that the proxy code generated should be written to the following destination

47

files, the named .h and .cpp-files. It is followed by the XML-file and last the interface if more thanone is present in the XML. Further options are available and can be accessed through runningqdbusxml2cpp -h, one such example used in this thesis is the -i <filename> to add an #includein the output file.

5.7.2.2 Signatures

Simple argument types is automatically mapped, through the QDBusArgument class, to acorresponding Qt type, such as a string is recognized as a QString. There is a set of primitivetypes which are natively supported. However, more complex types need to be annotated inthe XML file. An example of a complex type is a{sv} which is a dictionary with a string, s,associated with another variant, v, which for different entries in the dictionary can be differenttypes. An example use case for this is a set of optional parameters which uses the string as akey to the parameter and the variant as data. The data can then be a string for one entry andan integer or boolean for another. The example with a{sv} can be solved using a QVariantMapor a custom made Metaclass and in the XML document it might look something like

<node>< i n t e r f a c e name=” org . Access ”>

<method name=” SetFolder ”><arg type=” s ” d i r e c t i o n=” in ”/>

</method><method name=” GetList ”>

<annotat ion name=” org . q t p r o j e c t . QtDBus . QtTypeName . In0 ”value=”QVariantMap”/>

<arg type=”a{ sv}” d i r e c t i o n=” in ”/><arg type=” s ” d i r e c t i o n=” out ”/>

</method><method name=”GetMessage”>

<arg type=” s ” d i r e c t i o n=” in ”/><arg type=”a{ s s }” d i r e c t i o n=” in ”/><annotat ion name=” org . q t p r o j e c t . QtDBus . QtTypeName . In1 ”

value=”MyStringMap”/><arg type=” s ” d i r e c t i o n=” out ”/>

</method></ i n t e r f a c e>

</node>

where <annotation name=”org.qtproject.QtDBus.QtTypeName.In0” value=”QVariantMap”/>defines the first unrecognized input, a{sv}, as a QVariantMap. Notice the In0 ending of thename, it describes the nature and index of the type. This is used for input and output argumentsin method calls, for parameters the ending is omitted. Other complex types, as a{ss}, needs tobe annotated by a custom type in Qt. For a custom type to be recognized it needs to be declaredas a MetaType. For the example above with a{ss}

typedef QMap<QString, QString> MyStringMap;QT DECLARE METATYPE(MyStringMap)

is added to a header file which is included when generating the QDBusAbstractionInterfaceclass by adding

48

-i my Meta Type.h

when calling qdbusxml2cpp. The metaclass then must be registered at runtime in the applicationby adding

qRegisterMetaType(MyStringMap);

before any DBus call is made using the type. The resulting class can be instantiated and used tosend and receive information through the DBus API with the advantage that the type of inputarguments used and received replies expected can be validated at compilation.

5.7.3 Combining the generated QDBusAbstractionInterface classes

With the QDBusAbstractionInterfaces generated they can start to be put together into classeswhich can be used as one of the roles of the different profiles. As Qt is cross platform thisstage involves a layer which is specific to the Bluetooth stack used, in this case bluez 4. Abovethat layer the decision of which Bluetooth stack is used is taken into account. Finally there isan interface which can be used by the developer independently of which platform and softwareimplementing the Bluetooth stack is used. When extending the support for a specific platformthe architecture is not necessary. However, if both Bluez 4 and 5 will be used for different systemsit may be convenient since they have different DBus APIs.

5.7.4 Pending replies

The classes created based on the Qt D-Bus API’s, both classes included in Qt Bluetooth andthe ones created through qdbusxml2cpp, uses asynchronous DBus function calls. It returns aQDBusPendingReply <Type> which is not ready at the time. To handle this a QDBusPendingCallWatchermay be created with the reply as an argument with

QDBusPendingCallWatcher *watcher = new QDBusPendingCallWatcher(reply, this).

The watcher emits a signal when the reply is ready. The signal is connected to a functionby

QObject::connect(watcher, SIGNAL(finished(QDBusPendingCallWatcher*)),this,SLOT(handleReply(QDBusPendingCallWatcher*)));

where handleReply is a callback function implemented by the developer. The reply can thenbe assessed in handleReply, first by checking that the reply is of the expected format or if anerror has occurred followed by the content of the reply. This is a reason for checking the replyeven if it is expected to be an empty message or the actual data in the response is consideredunimportant.

If there is no other task which can be performed before the reply is ready it is possible towait by calling

reply.waitForFinished();

in which case no other instructions in the program are executed before the reply is ready.

49

Table 6.1: The versions of the used software for the different systems

6 Implementation

6.1 Configuration and setup

6.1.1 Software versions on the tested systems

For the VM and the Ubuntu laptop many of the components were already installed and theones which were not were easily added through the apt-get tool. For the CCpilot VA no suchtool was available and the work of adding the external components were put on maxximatecc’sdevelopment team in Finland. The setup of software and their version are presented in Tabl. 6.1for the different platforms. The phones used were a Sony XPeria Z5 Compact and a SamsungGalaxy S3.

6.1.2 Initiating scripts on CCpilot VA

A soft link to the init script etc/init.d/S30dbus, available on the CCPilot VA image, was addedto /etc/rc3.d/ to enable the system DBus on boot. Another script was made to start the sessionDBus with the line export $(dbus-launch) and to enable the kernel modules bluetooth, btusb,l2cap, rfcomm, bnep and sco using modprobe, a program available to add and remove loadablekernel modules from the Linux kernel. The script needs to be run using source to make surethe session DBus is active in the konsole session. The script also makes sure that the Bluetoothdevice is up before starting bluetoothd when using the generic Bluetooth USB adapter. Whenusing the CrossLink AI the script init-wireless, available on the CCPilot VA image, was used.

6.2 Qt Demo

6.2.1 Overview

The demo is controlled through the UI defined in the mainwindow class. In mainwindow objectsof the types scandialog, hfp, pbap and map are created. These objects do not depend on eachotherand all information exchange between them is done through the mainwindow object. Before theUI appears, a popup dialog requests the user to scan and select a remote device to connect to.The device address is then used as an input argument for the other objects. Pbap and mapcreates a designated obex session for each service and defines methods to pull objects throughthe DBus API exposed by the Obexd-client. The hfp object connects to the oFono API for theremote phone and is used to manage that connection. In the background PulseAudio manages

50

Figure 6.1: The UI in the tab handling phone calls and the phone book

incoming and outgoing audio streams, both HFP and A2DP, without any involvement of the Qtapplication.

6.2.2 Mainwindow

The UI of the mainwindow contains multiple tabs, Tab1 was intended for music streaming butas the control feature was not implemented in Bluez 4.101 it remains empty, Tab2 for handlingphone calls and the phone book and Tab3, named Page, is used for message access.

6.2.2.1 UI for phone calls and phone book

The UI in Tab2 is shown in Fig. 6.1 containing a numpad and a digit field to enter a number.The buttons to call and hang up a call are connected to the correspoding functions in the hfpobject with the digit field as input for dialing a number. An incoming call is indicated in aseparate text field and can be managed through the call and hang up buttons for accepting orrejecting respectively. The operator of the connected phone’s network is shown on the top of thescreen as well as the current signal strength.

On the right a listView is used to visualize the contact from the phone book by names. Onclicking a name the corresponding phone number appears in the digit field.

6.2.2.2 UI for message access

The tab for message access contains a listView which is used to display a selected text message,including sender number, date & time and the textual content as well as the index of the message

51

in comparison to all available messages. To change the active message the buttons ”Next” and”Previous” is used.

6.2.3 Scandialog

The dialog is used to scan the proximity for devices and displays the devices advertising themselvesas phones. It does this by using the QBluetoothDeviceDiscovery class and filtering out onlydevices with phone set as their main class. This does not verify that the profiles used in the restof the demo is supported by the device. When a device is discovered the current pariring statusis checked, if the devices are already paired they appear in green otherwise in black. When adevice is selected and the OK button is pressed the QDialog will attempt to pair, if not alreadypaired. If the pairing is successful, or if already paired, the QDialog emits a signal with theaddress as a QString before closing. The address is caught by the Mainwindow and passed asparameter to the constructors of the PBAP, HFP and MAP classes.

6.2.4 HFP

The hfp object registers required metatypes and searches for the connected phone among theavailable modems in ofono through the org.ofono.ModemsManager interface. When the phoneis found the DBus interfaces for the phone is created and ensures that the modem is ”powered”.

Through the org.ofono.NetworkRegistration interface the properties signalstrength and networkoperatorcan be queried and the signal emitted through the interface when properties are changed isconnected to a slot in the hfp object to handle it dynamically. If the changed property issignalstrength or networkoperator a signal is emitted from the hfp object with the new valueof the property which is caught by the mainwindow.

The hfp object also has public functions for accessing dialNumber and HangUpAll methodsof the org.ofono.VoiceCallManager interface. The interface emits a signal when a new VoiceCallis added which is caught and evaluated if the call is incoming, in which case the hfp emits asimilar signal to be caught by the mainwindow.

6.2.5 PBAP

The PBAP obex session is created in the constructor of the pbap class. When a session hasbeen successfully created the main phone book of the internal memory of the phone is selectedfollowed by listing the entries in the phone book. This returns a list with a vcard-number andname of each entry which is stored in a list. The contact name is displayed in the UI through alistView and by clicking a name the full vcard is requested. The reply is parsed by splitting thestring at each new line. Each line is then split further at every : and it is examined if the firstpart contains ”TEL” in which case the second part is recognized to be a phone number. Whena new phone number is parsed a signal is emitted with the number as a QString to be displayedin the digit field in the mainwindow, replacing any prior number in the field. In case of multiplenumbers of a contact only one will be shown in the digit field.

6.2.6 MAP

The MAP obex session is created in the constructor of the map class. When a session hasbeen successfully created the SMS inbox is set as the target folder followed by pulling theMessageListing objects of the selected folder. This returns a single QString containing all

52

messages in XML. The XML is parsed using QXmlStreamReader to extract the textual message,date & time and number of the sender of each message and stores it in a struct. All messages arethen stored in a list and a QStringListModel is created with an active message to be displayed.The active message can be changed by the public functions nextMsg() and prevMsg().

6.3 Testing features outside of the Qt Demo

6.3.1 A2DP, AVRCP and PAN

A2DP was tested by initiating the music player on the mobile phone while connected, throughBluetooth, to a device running PA in the background. AVRCP was tested by using the DBusinterface in the konsole through dbus-send. PAN was tested with NetworkManager, which waspreinstalled on both the VDM and the Ubuntu laptop. The DBus interface for connecting to aremote device running a NAP server was also tested using a Python script.

6.3.2 Python scripts

Bluez, Obexd and oFono provides test-scripts written in Python together with its source code.These can be used to quickly test some features or components. The Bluez scripts used were

• simple-agent : used to pair and connect to a remote device

• test-network : used to connect to a PAN service on a remote device resulting in a networkinterface,

the Obexd scripts used were

• map-client : used to create map session and request messages from a remote device runninga MAP server

• pbap-client : used to create pbap session and pull contacts from a remote device runninga PBAP server,

and the oFono scripts used were

• list-modems : list all modems, their status and some information

• enable-modem : enable given modem

• dial-number : use given modem to dial a number

• hangup-all : hang up all phone calls

• monitor-ofono : monitors the oFono DBus

6.3.3 Debugging

Further tools used for monitoring and debugging was

• bluez-hcidump : a package which monitors HCI events and commands for Bluez

• dmesg : prints the message buffer from the kernel

• running pulseaudio with the -vv option to print log while running

53

7 Results and Discussion

7.1 Result of tested profiles

The result of the tested profiles on different platforms is presented in Tabl 7.1. The tests onlyincluded connecting to a profile and using a few selected features. This does not guarantee thatother features work. More details are presented for each platform in this section.

7.1.1 VM

The Qt demo application verified some functionality of PBAP, MAP and HFP on the VM for alltested phones both with the built-in and external Bluetooth adapters. PBAP and MAP workedas expected aswell as the service level connection for the HFP. Although the making calls workedoccasionaly through HFP it also proved to be very unstable which is discussed further later inthe this section. Functionality of A2DP and PAN were also achieved on the VM outside of the Qtapplication. Streaming music worked as expected and PAN could be used to browse the internetusing the Samsung Galaxy S3 wheras it only occasionally worked with the XPeria Z5 Compact.PAN was also tested using the Python script which succesfully created a network on both testedphones. AVRCP could not be tested as it is not implemented in Bluez 4.101.

7.1.2 CCPilot VA

On the CCPilot VA only the PBAP and MAP were possible to test and the PBAP worked asexpected whereas it was not possible to connect to MAP on the Xperia Z5 Compact. On theGalaxy S3 it was possible to connect to MAP and to list and change folders but not to requestthe actual MessageListing objects. HFP and A2DP were not possible to test on the VA as bothrequires PulseAudio and HFP also requires oFono to work which is not available on the currentimage. PAN was tested using the Python script without success.

7.1.3 Ubuntu Laptop

As the Ubuntu laptop used Bluez 5 the Qt Demo could not be used so functionality was onlytested through the external components and the Python test scripts. All tested featured workedon the laptop except for the HFP audio, which did not work at all.

7.2 Unresolved issues

During the progress of the thesis many issues occurred and some of these were still unresolvedtowards the end of it.

7.2.1 VM related issues

There have been several issues in the VM, one involves catching the Bluetooth USB devices andthe other when streaming audio.

7.2.1.1 Catching the USB device

Catching the USB Bluetooth from the host computer has occasionally failed, leaving the devicein a void state where it does not appear neither on the host nor the VM. In these cases ithas been possible to reattach the external dongle and try again. If the problem have been thebuilt in BT adapter then the VM, and in some cases even the host computer, had to be restarted.

54

Table 7.1: Result of the tested profiles for the different platforms together with brief comments.O indicates that at least some features of the profile works as expected, where as X indicatesthe opposite

There has also been another issue where the USB connections stop working randomly. In thatcase all USB devices have stopped working and commands like lsusb freezes indefinitely. Thelatter problem have been located to /sys/devices/pci0000:00/0000:00:06.0/usb2/ which lsusbtries to read from when hanging. It is also not possible to open the folder in Dolphin, a fileexplorer, or by command cd in the konsole without the window freezing indefinitely. The dmesglog shows the message ohci-pci 0000:00:06.0: bad entry 25588780 when the problem occurs. Noother solution than to restart the VM have been found.

7.2.1.2 Issues with PAN on the VM

When testing to connect to the PAN service through the test script provided in the Blueztarball all devices created the network interface bnep0 as expected. When testing it withNetworkManager the Xperia Z5 Compact had difficulties achieving connected status. It hasworked a few times but most of the time it does not reach connected status, although it waspossible to browse the internet through the connection while the status was connecting. For theGalaxy S3 the connection worked as expected.

7.2.1.3 Audio issues with HFP on VM

Although some functionality of the HFP were achieved on the VM the audio is unstable andoccasionally fails in calls resulting in no sound. In this case hanging up and redialing solves theproblem. The VM may also freeze during a call, often when initiating or terminating a call,and will then need to be restarted. No structured test has been done on this but based on theobservations this occurs somewhere around 50% of the attempts. However, in some cases morethan ten subsequent calls have been made without the problem occurring and in some cases itoccurs on every single call after restarting the VM. No such problem was encountered for audio

55

streaming through A2DP.

7.2.1.3.1 dmesg log -Short before the freeze the dmesg log shows several entries of Bluetooth: hci0 SCO packetfor unknown connection handle X where X is different indexes. This message also occurscontinuously when no sound is emitted when a call is active. The controller often fragmentthe packets which then needs to be reassembled in the kernel. These messages occur when thereassembly fails. The reason it does fail vary and most of the time it is just a randomly damagedpackage which does not affect the overall sound but when it happens continuously, as it doeswhen no sound is emitted, it is an indication that something is wrong.

7.2.1.3.2 Virtualization of the audio may be a problem -The reason for this has not been established, but others have had similar problems whenrunning Bluez and PulseAudio on Virtual Development Machines, according to oFono maillist [25], though with Bluez 5.33 and PA 6.0 but both the frequent occurrence of no soundand crashes/freezes are present. Some oFono configuration are mentioned in the responses, butthose parameters have been added in later oFono versions and are not applicable to version 1.12and did not fix the problem. The most probable cause mentioned in the responses is that thevirtualization of the audio in the VM is not working properly together with the hardware as thesame setup has been working on other tested units.

7.2.2 VA related issues

7.2.2.1 Results on the CCPilot VA

On the VA it was not possible to test the HFP as the Qt demo requires oFono and PulseAudiowhich was not available on the Linux image currently available on the VA. As PulseAudio wasnot available A2DP was not testable either. As adding these items is not as straight forward onthe VA as it is with the apt-get tool the task of adding the component, and their dependencies,was put on the development team in Finland to look into. Obexd was one component whichwere added to the image. An effort was also made to include PulseAudio but due to lack offlash memory the resulting image was too large. It is not the first time the lack of flash memoryis a problem on the devices and a decision has been made to increase this. It also highlight adownside of using already existing software, that they may be larger than necessary due to manyfeatures not needed in an IVI implementation. Some of these features may be possible to omitwhen compiling, though this has not been investigated further.

7.2.2.2 MAP not working on CCpilot VA

Although the MAP should work with the same setup as PBAP problems were encountered.Limited debugging was made but with no result. Further debugging needs to be done, preferablywith tools like hcidump.

7.2.2.3 Patch the Network interface

The DBus API for connecting to PAN was found to be wrongly defined and was not possibleto use. There exists a patch for this, which is applied to the same version of Bluez on the VM,available from bluez git [26].

56

7.2.2.4 iPhone support

No test has been made with an iOS device as none were available but it has been suggested thatiOS does not work together with the CrossLink AI due to encryption issues. This should beinvestigated further as it is a big drawback if iOS devices are not supported.

57

8 Conclusions

The Bluetooth connectivity features varies between manufacturers and levels of IVI system butthe functionalities may be grouped into

• Hands free phone functionality - Two-way routing of call audio and management of phonecalls. Extendable with features such as multiparty call, access to phone book, call historyand messages

• Music Streaming - Routing of high quality audio stream and control

• Tethering - Sharing the internet access of a phone to be used by any other application.

The Bluetooth profiles most often used to achieve these functionalities are

• Handsfree Profile (HFP) - Low latency audio transport as well as AT commands to manage

• Phonebook Access Profile (PBAP) - Access the phone book and call history

• Message Access Profile (MAP) - Access messages and/or emails

• Advance Audio Distribution Profile (A2DP) - High quality audio stream

• Audio/Video Remote Control Profile (AVRCP) - Control and information (metadata) ofan audio or video stream

• Personal Area Network Profile (PAN) - Setting up a wireless network to share an internetconnection

and they all use classic Bluetooth (BR/EDR, Bluetooth spec. version 2.1).

The Bluetooth stack Bluez is included in the Linux Kernel to offer support for the core protocolsin the Bluetooth stack but it does also provide user space daemons and tools. The latest Bluezversions, 5.39, require Linux kernel 3.4 or later and many systems cannot meet that requirement,including the CCpilot VA, and is left with version 4.101. In terms of profile support this onlyaffects the AVRCP which is not supported through the main Bluez daemon until Bluez 5.0.Whilst other changes have been made to the DBus API and internally, affecting the compatibilitywith other components, the most significant change is the support for Bluetooth Low Energy,not effecting the current IVI features.

The IVI use case is highly prioritized in Bluez and other open source projects for Linux. Togetherwith the software components

• Obexd - Implements the Object Exchange Protocol and profiles dependent on the protocol,such as PBAP and MAP. Included in the Bluez project from version 5.0

• ALSA - The sound card drivers in the Linux kernel

• PulseAudio - A sound server on top of ALSA which detects Bluetooth devices and prioritizesand manages different audio stream such as the A2DP and HFP audio including necessarydecoding and handshake procedures.

• oFono - A telephony stack used to handle the AT commands in the HFP profile

58

• Connman or NetworkManager - Configures and manages the created network interface inPAN

simplifies the development of IVI applications and they form the base of Bluetooth Connectivitytogether with Bluez for many Linux IVI solutions on the market, the open source projects TizenIVI and GENIVI as an example.

Testing the profiles on the VDM and an Ubuntu laptop has been successful except for theaudio routing in the HFP profile. The reason for this has not been determined, but is believeddifferent in those systems. Testing the profiles on the CCpilot VA has been more difficult as thework of adding external components has been handled by others within the company, who hasbeen assigned to higher prioritized tasks during most of the time of the thesis. The flash memoryof the CCpilot VA also proved to be too small to fit the external components, except for Obexd,on top of the already existing image. The result it that only PBAP has been successfully testedon the VA. Although MAP is expected to work with the same setup it has not, and the reasonhas not been determined.

59

References

[1] S. Marisetty, D. Srivastava, and J. A. Hoffmann, “An architecture forin-vehicle infotainment systems.” http://www.drdobbs.com/embedded-systems/

an-architecture-for-in-vehicle-infotainm/222600438, January 2010. Accessedin May, 2016.

[2] Bluetooth SIG, “Blutooth - our history.” https://www.bluetooth.com/media/

our-history. Accessed in May 2016.

[3] J. B. White, “A car that takes your pulse,” The Wall Street Journal, November 2012.

[4] Bluetooth SIG, “Bluetooth expands beyond hands-free calling.” https://www.bluetooth.

com/marketing-branding/markets/automotive-cars. Accessed in May, 2016.

[5] Apple Inc, “ios: Supported bluetooth profiles.” https://support.apple.com/en-us/

HT204387, May 2016.

[6] Samsung Electronics H.K. Co. Ltd., “Galaxy s6 specification.” http://www.samsung.

com/hk_en/consumer/mobile/smartphones/smartphones/SM-G9200ZWUTGY. Accessed inOctober 2016.

[7] M. Gerczuk, “Android rsap - compatibility.” http://www.android-rsap.com/

compatibility.html. Accessed in October 2016.

[8] CBS Interactive Inc., “Sony xperia z5 premium specification.” https://www.cnet.com/

products/sony-xperia-z5-premium/specs/. Accessed in October 2016.

[9] GENIVI Alliance, “Bmw case study.” https://www.genivi.org/sites/default/files/

BMW_Case_Study_Download_040914.pdf, September 2014.

[10] T. Muller and M. Astiz, “Automotive bluetooth telephony - combining bluezand the modern vehicle.” http://www.bmw-carit.com/downloads/presentations/

20121106-AutomotiveBluetoothTelephony.pdf, November 2012. Accessed in May 2016.

[11] Bluetooth SIG, “Phone book access profile specification v1.1,” August 2010.

[12] Bluetooth SIG, “Handsfree profile specification v1.7.1,” December 2015.

[13] Bluetooth SIG, “Advanced audio distribution profile specification v1.3.1,” July 2015.

[14] Bluetooth SIG, “Message access profile specification v1.2,” July 2013.

[15] Bluetooth SIG, “Personal area networking profile specification v1.0,” February 2003.

[16] Bluetooth SIG, “Bluetooth specification version 4.2 [vol 1: Architecture & terminologyoverview, part a: Architecture],” December 2014.

[17] J. Padgette, K. Scarfone, and L. Chen, “Guide to bluetooth security.” http://csrc.nist.

gov/publications/nistpubs/800-121-rev1/sp800-121_rev1.pdf, June 2012.

[18] Bluetooth SIG, “Bluetooth specification version 4.2 [vol 2: Core system package [br/edrcontroller volume, part h: Security specification],” December 2014.

[19] D. Whiting, R. Housley, and N. Ferguson, “Counter with cbc-mac (ccm).” https://tools.

ietf.org/pdf/rfc3610.pdf, September 2003.

60

http://www.drdobbs.com/embedded-systems/an-architecture-for-in-vehicle-infotainm/222600438

http://www.drdobbs.com/embedded-systems/an-architecture-for-in-vehicle-infotainm/222600438

https://www.bluetooth.com/media/our-history

https://www.bluetooth.com/media/our-history

https://www.bluetooth.com/marketing-branding/markets/automotive-cars

https://www.bluetooth.com/marketing-branding/markets/automotive-cars

https://support.apple.com/en-us/HT204387

https://support.apple.com/en-us/HT204387

http://www.samsung.com/hk_en/consumer/mobile/smartphones/smartphones/SM-G9200ZWUTGY

http://www.samsung.com/hk_en/consumer/mobile/smartphones/smartphones/SM-G9200ZWUTGY

http://www.android-rsap.com/compatibility.html

http://www.android-rsap.com/compatibility.html

https://www.cnet.com/products/sony-xperia-z5-premium/specs/

https://www.cnet.com/products/sony-xperia-z5-premium/specs/

https://www.genivi.org/sites/default/files/BMW_Case_Study_Download_040914.pdf

https://www.genivi.org/sites/default/files/BMW_Case_Study_Download_040914.pdf

http://www.bmw-carit.com/downloads/presentations/20121106-AutomotiveBluetoothTelephony.pdf

http://www.bmw-carit.com/downloads/presentations/20121106-AutomotiveBluetoothTelephony.pdf

http://csrc.nist.gov/publications/nistpubs/800-121-rev1/sp800-121_rev1.pdf

http://csrc.nist.gov/publications/nistpubs/800-121-rev1/sp800-121_rev1.pdf

https://tools.ietf.org/pdf/rfc3610.pdf

https://tools.ietf.org/pdf/rfc3610.pdf

[20] Qt. https://www.qt.io/. Accessed in November 2016.

[21] J. B, “Bluez A2DP AudioSink for ALSA.” http://www.lightofdawn.org/blog/

?viewDetailed=00032, June 2013. Accessed in May 2016.

[22] PulseAudio, “Pa.” https://www.freedesktop.org/wiki/Software/PulseAudio/.Accessed in May, 2016.

[23] oFono. https://01.org/ofono. Accessed in May, 2016.

[24] The Qt Company, “Qt - bluetooth file transfer example.” http://doc.qt.io/qt-5/

qtbluetooth-btfiletransfer-example.html. Accessed in November 2016.

[25] J. Gauthier and G. Chini, “Hands free/pulse - not working well.” https://lists.ofono.

org/pipermail/ofono/2015-September/015883.html, September 2015. Accessed in May2016.

[26] Bluez Project, “bluez.git - pan patch.” http://git.kernel.org/cgit/bluetooth/bluez.

git/diff/network/connection.c?id=57170b311f1468330f4a9961dc0b3ac45f97bc13&

id2=c1d662075288d475ee6e1740d39ac84fe806542a. Accessed in November 2016.

61

https://www.qt.io/

http://www.lightofdawn.org/blog/?viewDetailed=00032

http://www.lightofdawn.org/blog/?viewDetailed=00032

https://www.freedesktop.org/wiki/Software/PulseAudio/

https://01.org/ofono

http://doc.qt.io/qt-5/qtbluetooth-btfiletransfer-example.html

http://doc.qt.io/qt-5/qtbluetooth-btfiletransfer-example.html

https://lists.ofono.org/pipermail/ofono/2015-September/015883.html

https://lists.ofono.org/pipermail/ofono/2015-September/015883.html

http://git.kernel.org/cgit/bluetooth/bluez.git/diff/network/connection.c?id=57170b311f1468330f4a9961dc0b3ac45f97bc13&id2=c1d662075288d475ee6e1740d39ac84fe806542a



Documents

Extended Bluetooth Profiles on CCpilot displays1095401/FULLTEXT01.pdf• Diagnostik och annan data fr an bilen • Monitorering av f orarens h alsotillst and. M ojligheten att anv