UPTEC F 17017 Examensarbete 30 hp Maj 2017
Extended Bluetooth Profiles on CCpilot displays
Alexander Johnson Abstract Extended Bluetooth Profiles on CCpilot displays
Alexander Johnson
Teknisk- naturvetenskaplig fakultet UTH-enheten Bluetooth is used in modern cars to connect smartphones to stream music, to access internet and for phone services such as phone book Besöksadress: contacts and making calls. Similar features are now requested by Ångströmlaboratoriet Lägerhyddsvägen 1 customers of maximatecc's products, e.g. display computers, for off- Hus 4, Plan 0 road vehicles. This thesis is aimed to investigate what is needed to support these features in maximatecc's Linux based displays and how Postadress: the features can be used in a Qt application. Box 536 751 21 Uppsala For instance, the connectivity features in personal cars most Telefon: commonly utilizes the Bluetooth profiles: 018 – 471 30 03
Telefax: Advanced Audio Distribution Profile (A2DP) 018 – 471 30 00 Audio/Video Remote Control Profile (AVRCP) Personal Area Network (PAN) Profile Hemsida: Hands Free Profile (HFP) http://www.teknat.uu.se/student 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.
Handledare: Carl-Magnus Moon Ämnesgranskare: Ping Wu Examinator: Tomas Nyberg ISSN: 1401-5757, UPTEC F 17017 Popul¨arvetenskaplig sammanfattnig
Bluetooth anv¨andsidag i moderna bilar f¨oratt smidigt koppla upp sin smartphone f¨oratt f˚atillg˚angtill dess funktionalitet i bilens informations- och mediaenhet(IVI). Det g¨alleridag framf¨orallt
• Str¨ommamusik • F˚atillg˚angtill en internetuppkoppling • Anv¨andatelefonen f¨oratt ringa och ta emot samtal, hantera meddelanden och anv¨anda telefonboken. I vilken utstr¨ackning dessa erbjuds skiljer sig ˚atmellan biltillverkare och modell men, ˚atminstone som tillval, finns det i princip i alla nyproducerade bilar. I framtiden finns stora m¨ojligheterf¨or nya anv¨andingsomr˚adend¨arBluetooth kan nyttjas, d¨aribland
• Diagnostik och annan data fr˚anbilen • Monitorering av f¨orarensh¨alsotillst˚and. M¨ojlighetenatt anv¨andaBluetooth f¨oratt uppn˚aliknande funktionalitet efterfr˚agasnu av kunder till maximateccs displayenheter till terr¨angfordon.Dessa displayenheter anv¨anderfr¨amst operativsystemet Linux i vilket ett grundst¨odf¨orBluetooth finns inbyggt genom programvaran Bluez. F¨oratt underl¨attautvecklingen av applikationer med ¨onskad funktionalitet anv¨andsofta mellanprogramvara, middleware, vilken implementerar funktioner som inte direkt ¨artillg¨angliga via operativsystemet.
Genom att bland annat g˚aigenom projekt med ¨oppen k¨allkod riktat mot Linuxbaserade IVI i personbilsindustrin har har fyra mellanprogramvaror identifierats f¨oratt underl¨attaen implementering av dessa funktionaliteter. Dessa ¨ar
• Obexd (f¨ormeddelandehantering och telefonbok) • PulseAudio (f¨orhantering av ljud, b˚ademusik och samtal)
• oFono (f¨orsamtalshantering) • Connman (f¨orinternetaccess). Ett konceptuellt demoprogram har tagits fram d¨arvissa av dessa mellanprogramvaror anv¨ands som visar hur de praktiskt kan anv¨andasi en applikation skapad i utvecklingsverktyget Qt. Andra funktioner har testats med sm˚atestprogram, scripts, som f¨oljermed k¨allkoden. Testningen har fr¨amstutf¨ortsi en utvecklingsmilj¨osom 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 7 1.1 Background ...... 7 1.2 Specification ...... 7 1.3 Tasks and Methodology ...... 7
2 IVI in personal cars 8 2.1 Overview ...... 8 2.2 Connectivity features ...... 8 2.2.1 Hands Free Features ...... 10 2.2.2 Media Player ...... 10 2.2.3 Tethering ...... 10 2.2.4 Other technologies ...... 10 2.2.5 Future functionality ...... 10 2.2.6 Technical ...... 11 2.2.7 Profiles supported by mobile phones ...... 12 2.2.8 Compatibility check between phone model and IVI system ...... 12 2.3 OpenSource initiatives ...... 13
3 Bluetooth 14 3.1 General ...... 14 3.1.1 BR/EDR ...... 14 3.1.2 High Speed (HS) extension ...... 14 3.1.3 Bluetooth Low Energy ...... 14 3.2 The Bluetooth Stack ...... 15 3.2.1 Controller ...... 15 3.2.2 HCI ...... 16 3.2.3 Host ...... 17 3.3 Protocols ...... 17 3.3.1 L2CAP ...... 17 3.3.2 RFCOMM ...... 17 3.3.3 BNEP ...... 17 3.3.4 Obex ...... 18 3.3.5 SDP ...... 18 3.3.6 AVDTP/AVCTP ...... 18 3.4 Profiles ...... 18 3.4.1 Generic Access Profile (GAP) ...... 18 3.4.2 Serial Port Profile (SPP) ...... 18 3.4.3 Phone Book Access Profile (PBAP) ...... 19 3.4.4 Hands Free Profile (HFP) ...... 22 3.4.5 Advanced Audio Distribution Profile (A2DP) ...... 23 3.4.6 Audio/Video Remote Control Profile (AVRCP) ...... 25 3.4.7 Message Access Profile (MAP) ...... 25 3.4.8 Personal Area Network Profile (PAN) ...... 27 3.5 Security ...... 30 3.5.1 Bluetooth Security Model ...... 30 3.5.2 Legacy Pairing ...... 31
4 3.5.3 Secure Simple Pairing ...... 32 3.5.4 Secure Connection ...... 33 3.5.5 Detectable and Connectable only when needed ...... 33
4 Hardware and Development Environment 34 4.1 Tested Platforms ...... 34 4.1.1 CCPilot VA ...... 34 4.1.2 Virtual Machine ...... 34 4.2 Bluetooth Hardware ...... 34 4.3 Qt ...... 34
5 Software Components in Linux 36 5.1 BlueZ ...... 36 5.1.1 Kernel configuration ...... 36 5.1.2 Versions ...... 36 5.1.3 A2DP support ...... 37 5.1.4 AVRCP support ...... 39 5.1.5 HFP support ...... 39 5.1.6 PAN support ...... 40 5.1.7 MAP & PBAP support ...... 40 5.2 Obexd ...... 41 5.2.1 PBAP API ...... 41 5.2.2 MAP API ...... 42 5.2.3 Changes with different versions ...... 42 5.3 Audio ...... 43 5.3.1 Advanced Linux Sound Architecture - ALSA ...... 43 5.3.2 PulseAudio ...... 43 5.3.3 Audio Configuration in Bluez ...... 44 5.4 Telephony stack - oFono ...... 44 5.4.1 HFP AG plugin ...... 45 5.5 Network management ...... 45 5.6 DBus ...... 45 5.6.1 Service, Path and Interface ...... 45 5.6.2 Methods and signals ...... 45 5.7 Qt - Bluetooth Support ...... 46 5.7.1 QtBluetooth Classes ...... 46 5.7.2 Extending the support ...... 47 5.7.3 Combining the generated QDBusAbstractionInterface classes ...... 49 5.7.4 Pending replies ...... 49
6 Implementation 50 6.1 Configuration and setup ...... 50 6.1.1 Software versions on the tested systems ...... 50 6.1.2 Initiating scripts on CCpilot VA ...... 50 6.2 Qt Demo ...... 50 6.2.1 Overview ...... 50 6.2.2 Mainwindow ...... 51 6.2.3 Scandialog ...... 52 6.2.4 HFP ...... 52
5 6.2.5 PBAP ...... 52 6.2.6 MAP ...... 52 6.3 Testing features outside of the Qt Demo ...... 53 6.3.1 A2DP, AVRCP and PAN ...... 53 6.3.2 Python scripts ...... 53 6.3.3 Debugging ...... 53
7 Results and Discussion 54 7.1 Result of tested profiles ...... 54 7.1.1 VM ...... 54 7.1.2 CCPilot VA ...... 54 7.1.3 Ubuntu Laptop ...... 54 7.2 Unresolved issues ...... 54 7.2.1 VM related issues ...... 54 7.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 devices in 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 to peripheral devices. For newer displays through an external USB device but some older models may have built in support. However, none of the models up to now have smartphone connection functionality. Thus, maximatecc is intended to add this functionality to the CCpilot display computers in their future applications.
1.2 Specification This thesis project aims to investigate which functionalities that are available in personal cars today in terms of Bluetooth connectivity and what is needed to offer access to smartphone functionality in a similar way in terms of connection encryption, Bluetooth profiles, existing open source projects and other Linux Embedded libraries. The project should include design and 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 reading marketing 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 choose which manufacturers and models that should be investigated. In addition to this some open source IVI projects have been studied. These functionalities have been mapped to Bluetooth profiles and protocols, the Bluetooth stack, needed to achieve them.
To implement and test the profiles on an embedded device running Linux and create a demo in Qt the documentation, source code and mailing lists of different open source projects were investigated. The testing was performed in different Linux environments but mainly on a Virtual Machine (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. Some common features are
• Maps and navigation - Either a built-in system or through a plugged-in system using the head unit as a display
• Multimedia - Graphic and audio content, music, video or games, which can be displayed on the head unit or distributed to screens at the rear seats
• Internet access - For receiving traffic information, travel suggestion, audio streaming and much 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 hardware components, such as the MCU, memory and Bluetooth adapter is the bottom layer. Above that the OS layer resides containing an OS core and the board support package (BSP). Another step up the middleware layer provides functionalities not available through the OS directly. It serves the application with well defined interfaces to services in order to speed up application development. This layer may include media and graphics management, system infrastructure and automotive connectivity. Above the middleware layer is the application layer with software designed to provide a specific feature for the user. This layer may include software for providing mobile entertainment, office functions, navigation and vehicle information. To manage the IVI a Human Machine 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 models but 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 or profiles 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 for different car models and versions of IVI whereas others are more sparse and does not always explicitly say which features use Bluetooth. The found features can be grouped into three categories
• 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 this has been the standard feature of Bluetooth connected cars since the first car-kit was introduced in 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 as an alternative to radio and CD as the entertainment source in the IVI. This is often available through USB or Bluetooth, either by playing locally stored media files or by streaming through services connected to the internet, such as Spotify. The service includes streaming audio, remote control 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 and music streaming features, but is offered by some manufacturers. This feature opens up all the possibilities that comes with the internet for a wide range of applications to access data, such as traffic 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 on the IVI. This lets the user browse through different apps on the IVI with a GUI designed by the app/phone developer. The GUI is often simplified to make it easy and safe to use while driving. This functionality is today supported by Android Auto, MirrorLink, SmartDeviceLink and 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. These technologies 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 functionality are undoubted there have been suggestions that Bluetooth might not be the technology that will be used in the future. WiFi has been mentioned to take over for a few years now, but Bluetooth is still there in new car models. The fact that Bluetooth is so wide spread, both in terms of the end users 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 mentioned above.
2.2.5.1 More phone applications Future functionality may include further development in terms of phone applications which can be displayed on the IVI head unit where Bluetooth can play an important role in managing these connections and support them with an internet connection for example to get data. The introduction of Bluetooth Low Energy (BLE) also opens up for different kinds of sensors in the car or along the road with information. To know exactly what this will be used for in the future is 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 of preferences could be seat, wheel and mirror positioning and temperature. This could automatically be adapted to the preferences as the user enters the car. To make it possible to use in different cars 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 health information such as glucose and heart monitoring. This information could then be used to, for example, alert the driver and/or the driver’s doctor if something is wrong or even to stop the car 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 mechanical electrical systems. Bluetooth SIG mention this as a possibility to reduce manufacturing cost and weight, 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 Enhanced Data Rate (EDR) is used and the top level Bluetooth profiles used to achieve the different functionalities described above is mentioned in the following subsections. Further description of the different Bluetooth techonology systems can be found in the Bluetooth/General section and the 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 free profile (HFP) which is designed for low latency audio streams and includes control features for mobile phones based on AT commands. It also includes information about the network, such as operator name and signal strength, as well as multiple optional features, such as conference call. However, there is a headset profile (HSP) which is very similar to the HFP except with slightly less control feature. A third choice is the SIM Access Profile (SAP) which differs from the profiles mentioned above in the way that it uses the SIM card information from the phone to connect to the network directly as if the SIM card was inserted into the IVI. This has the benefit of 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 that any 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 to send contacts as vCard objects between devices. Other object exchange profiles such as Object Push Profile (OPP) can be used as well. The difference between these two profiles is that with OPP the contacts are pushed from the mobile phone to the IVI whereas with PBAP the transfer is requested from the IVI and different arguments can be set in order to get different parts of the 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 sends the messages as objects. Again the OPP can also be used as with the phone book access, but in analogy 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 combination with the audio/video remote control profile (AVRCP) is recommended. Technically HFP/HSP could be used for streaming the audio but the quality would not be sufficient since they are intended for voice, which is below 4 kHz whereas music often requires 20 kHz to be considered to 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 modem the 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], and Sony Xperia Z5 Premium, [8], are presented in table 2.1. All of these profiles are utilized in IVI’s today except for Human Interface Device (HID), which is used by input devices, such as keyboards and mouses. The profiles for the IVI functionalities which are supported by all devices are also the ones recommended whereas other profiles, e.g. HSP and OPP, are only supported by some and may be seen as alternative profiles. This is not meant to be a full investigation of phone models and does not provide any crucial information for this thesis but illustrates which profiles are commonly supported by modern phones. The supported profiles have not changed much in the recent years between releases, iPhone for example has had the same supported profiles since iPhone 4.
2.2.8 Compatibility check between phone model and IVI system Most car manufacturers provide tools to check compatibility between phone models and their different IVI systems. In general phones supporting the same profiles as the IVI should work but as 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 Xperia Z5 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 automotive industry has been looking into how to reduce the development cost and reuse as much code as possible. IVI’s today can contain over 100 million lines of code, compared to tens of thousands a decade ago, with most code being non-differentiating between manufacturers [9]. In this investigation many manufacturers have seen the benefit of open source platforms which are continuously 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 supporting already existing open source projects or by defining standard API’s where multiple middleware might be used as backend. Where no such projects are found they may host their own projects. • Tizen IVI - Tizen is a flexible operating system based on Linux and has different versions aimed for different purposes, IVI being one of them. It is GENIVI compliant and may be seen as a reference build of the GENIVI specification. • Automotive Grade Linux - AGL aims to provide not only a reference OS platform but an entire IVI system to be used as a starting point for developers. They build their reference platform 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 do collaborate in many tasks.
13 3 Bluetooth
3.1 General Bluetooth is a short range wireless technology standard intended to replace cables connecting electronic devices. It operates in the 2.4 GHz ISM band, which is 2400-2483.5 MHz. Although a lot has happened since it was invented by Ericsson in 1994 the key features remain, aiming to be robust, low power and low cost. The Bluetooth core specification adopts two forms of Bluetooth wireless technology systems: Basic Rate (BR) and Low Energy (LE). The BR system includes optional Enhanced Data Rate (EDR) and High Speed (HS) extensions.
The specification includes different levels of protocols used for communication and definitions of 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 common versions of Bluetooth and even though EDR was added later it is unlikely to find a Bluetooth device without the extension today.
It divides the frequency range into 79 different channels according to 2402 + k MHz, where k is the channel number and ranges between 0-78, leaving 2 MHz and 3.5 MHz as guard bands on the lower and upper end respectively. To avoid interference from other wireless devices in the same 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 unlikely that two different Bluetooth connections use the same frequency more than occasionally. The maximum 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), which utilizes 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 connection management. The HS extension offers a theoretical data speed of up to 24 Mbit/s. Although it has been available since 2009 it has not reached the same commercial popularity as BR/EDR and BLE.
3.1.3 Bluetooth Low Energy Originally developed by Nokia under the name Wibree the latest major addition to the Bluetooth standard was adopted in the Bluetooth Specification 4.0, under the name Bluetooth Smart, or sometimes also referred to as Bluetooth Low Energy. The intention was to target devices with very limited resources, such as coin-cell battery driven sensors, to make it possible to run a device on a small coin-cell battery for months or even years. It uses the same frequency range as the classical Bluetooth does but divided into 40 channels instead of 79. In addition it has 3 fixed channels designated for advertisements. The maximum throughput is about 1 Mbit/s which is comparable to BR without the EDR extension. However, one of the features which reduce the energy consumption is that the application utilizing the Bluetooth connection can manage the connection 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. The stack can be divided into controller and host parts as illustrated in Fig. 3.1 where the green parts belong to the controller and the blue part to the host. The controller and host will be described in this section as well as the Host controller interface (HCI) which defines how the host and controller interacts and communicates with each other.
Figure 3.1: An example of the Bluetooth BR/EDR stack with the controller and host part separated
3.2.1 Controller The controller is often implemented in the local Bluetooth hardware adapter. In every Bluetooth core system there is a Primary Controller which may be either a BR/EDR Controller, a LE Controller or a combined BR/EDR+LE Controller. It may also have one or more secondary controllers, which may be an AMP controller. In a system implementing a combined primary controller and an AMP controller some resources may be shared between the controllers whereas others 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 it is seldom omitted since it standardizes the interface between the controller and host. This is valuable 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 event of 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 ACL link must always be established between two actively connected devices. These messages are often divided into ACL-C, carrying control data from LMP, and ACL-U, carrying user data from L2CAP and is the one passing the HCI. As RFCOMM is encapsulated in L2CAP packets they are also 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 that information 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 connection with 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 can offer retransmissions.
SCO is intended for low latency audio connection, used for hands free phone calls, but any regular data stream could use this method. The Bluetooth audio connection transfers data at 64 kB/s and supports frequencies up to 4 kHz. This frequency range is enough for speech but not 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 Bluetooth adapter. It consists of a set of protocols designed for different use cases, which in some cases depends on other protocols. On top of the protocols profiles are used to define how the protocols are to be used to certain, common, use cases. Which protocols are needed in the implementation of 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 in this thesis.
3.3.1 L2CAP The Logical Link Control and Adaption Protocol defines connection-oriented and connection-less data services to higher layer protocols. It offers protocol multiplexing as well as segmentation and reassembly operation. L2CAP is a mandatory part of the Bluetooth stack of any system as the majority of all communication is based on the protocol, including mandatory profiles. The L2CAP 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 protocol designed to emulate a RS-232 serial port. It offers comparable services as TCP does in networking in terms of reliability and that it is stream based. RFCOMM packets are encapsulated in L2CAP packets.
3.3.3 BNEP The Bluetooth Network Encapsulation Protocol defines how packets from various networking protocols 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 exchanged between two devices. It was originally developed by Infrared Data Association (IrDA) as IrOBEX but 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 advertised for 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 command messages and responses are to be transported to control an audio or video stream. Both these protocols run on top of L2CAP.
3.4 Profiles While the protocols described above describes how communication are to be done for different purposes the Bluetooth specification takes things a step further by defining functions and protocols used to achieve higher level tasks through profiles. The top level profiles, describing the interoperability between applications, are called Application Profiles. In case of reuseability of common requirements between application profiles one or more generic profile can be created. The Application profiles are then implemented as a superset of the generic profile. There is one generic profile that all Bluetooth 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 to exchange data objects • Generic Audio/Video Distribution Profile - Defines the common steps to set up an audio or 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, connections and security are to be handled. It is mandatory for all Bluetooth devices to implementc which makes 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. All other profiles are dependent on the GAP which makes it, and the layers it depends on, mandatory for 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, between two 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-server model 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 book objects.
In the context of this thesis the PSE is the mobile phone and the PCE is the IVI.
3.4.3.2 Protocol stack 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 book server and client must be running for the respective role. For the server role a vCard builder is needed to create the object to be transferred and on the other end, at the client, a parser is used to extract the desired information. The profile is dependent on the profiles GAP, GOEP and 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 between the 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. As seen in the figure there might be several repositories which contain phone book objects as some contacts may be stored locally on the mobile phone whereas some may be stored on the SIM (or even different SIM cards as some phones support multiple SIM cards). The phone book objects contain the individual entries which are represented under the vCard format. Each entry in a phone 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 owner vCard is not known it can reference an empty vCard or only the mobile number if it is known to the PSE. The PSE shall support both vCard 2.1 and vCard 3.0 versions. The PCE can then request 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 or browsing, of which at least one must be supported by the PCE but both must be supported by the PSE. The downloading feature allows the PCE to download an entire phone book object which then can be stored locally on the PCE. This might require a relatively large storage capacity and the feature is very basic and no sorting is possible. The browsing feature allows the PCE to select the phone book object of interest, i.e. the missed call history, and then either pull an individual 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-DATETIME defined 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 a time 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 most recent call in each object. If the number for a call history entry can be linked to a main phone book entry at the PSE the contact information of that entry should be included when a call history entry is retrieved.
3.4.4 Hands Free Profile (HFP) 3.4.4.1 Profile roles The HFP defines the protocols and functions used to achieve a low latency voice connection and remote 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 output mechanism.
In the context of this thesis the AG is the mobile phone and the HF is the IVI.
3.4.4.2 Protocol stack 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 a Hands-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 through which the AT commands are sent, which is active as long as the connection lasts. The audio is sent 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 M are mandatory for the role and O are optional for the role to support. Each supported feature uses a set of mandatory procedures, see [12] for more information.
3.4.5 Advanced Audio Distribution Profile (A2DP) 3.4.5.1 Profile roles A2DP defines how to distribute high quality audio content between two Bluetooth devices. It defines 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.
3.4.5.2 Protocol stack Except for the mandatory entities, Baseband, LMP, L2CAP and SDP, the profile also utilizes AVDTP 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 in HFP. The difference is that it is sent as compressed audio packets over L2CAP, which increases the throughput but decreases latency. As latency is not as important for music streams as it is for 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 in a 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) packet and further in a L2CAP packet before sent over an ACL link. [13]
3.4.6 Audio/Video Remote Control Profile (AVRCP) 3.4.6.1 Profile roles AVRCP defines the protocols and procedures required to control an audio or video stream between Bluetooth devices. It includes metadata, control and browsing commands. The profile defines two roles
• Target • Controller. In the context of this thesis the Target is the mobile phone and the controller is the IVI.
3.4.6.2 Protocol stack 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 Trade Association through the AV/C Digital Interface Command Set Specification, depicted as AV/C in Fig. 3.7.
3.4.7 Message Access Profile (MAP) 3.4.7.1 Profile roles 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 the Message Notification service (MNS). In MAS the MCE acts as an OBEX client pulling messages from the MSE acting as the OBEX server. However, in MNS the MSE acts as the OBEX client pushing messages to the MCE. This is needed for the phone to automatically transfer an incoming message 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 message server and client must be running for the MSE and MCE respectively. If MNS is supported the MSE must also have a client, and the MCE a server, running. For the server role a bMessage builder is needed to create the object to be transferred and on the other end, at the client, a parser 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. Exactly how 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 to transmit 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 illustrated in Fig 3.11 taken from the MAP specification [14].
3.4.8 Personal Area Network Profile (PAN) 3.4.8.1 Profile roles PAN defines how to use BNEP to provide networking services between Bluetooth devices. It defines the roles
• Network Access Point (NAP) - A device which may work as an Ethernet bridge. A PAN user may connect to a NAP and exchange Ethernet packets through BNEP. The NAP has an 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 provide access to an additional network connection. Instead the GN service is used to create a temporary network between two or more Bluetooth devices
• PAN User (PANU) - The Bluetooth device that uses a NAP or GN service. It also supports direct 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
3.4.8.2 Protocol stack 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 handle procedures 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 may be 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 needs to use services provided by the phone to obtain an IP address for the connection, or verify that 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-Middle attacks and eavesdropping and Bluetooth is no exception. The security mechanisms defined in the Bluetooth Specification specifically address these threats. The scope of the security features defined in the Bluetooth specification is between two devices connected via Bluetooth thus end-to-end security is not possible if one of the devices serves as a gateway to a larger network. 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 security features:
• Pairing - The creation of shared secret keys between two devices • Bonding - Storing the secret keys from a pairing procedure to be used in subsequent connections
30 Table 3.2: The algorithms used for key generation, device authentication and encryption for the 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 be backwards compatible. The current specification includes methods from three different versions to achieve this for BR/EDR security. These are Legacy Pairing, Secure Simple Pairing (SSP) and Secure Connections. When the pairing procedure has been completed between two devices they may connect to any of the services/profiles supported by the remote device. Legacy pairing is now only supported for backwards compatibility as Bluetooth devices supporting at least version 2.1 requires Secure Simple Pairing but may still be able to use Legacy pairing when bonding with an older device if needed. SSP provided a new pairing procedure from a user perspective as different I/O capabilities of devices uses its own pairing procedure. In addition it also changed the 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 specification version 4.2 SSP was upgraded with improved algorithms for encryption and authentication and is now an own branch under Secure Connections. The algorithms used for key generation, device authentication 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 the Bluetooth 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 generated keys and the Bluetooth addresses. This also means that the stored keys will not follow the Bluetooth chip when moving a USB dongle for example but will remain on the device with the host implementation.
3.5.2 Legacy Pairing The Legacy Paring procedure used a four digit PIN code which was entered on both devices, if identical the pairing was successful. For devices without the ability to enter a PIN a static PIN code was used, often ”0000” or similar. One problem was that many users did not choose this randomly 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 while maintaining or improving the security. These two goals are often in conflict with each other but much effort has been spent in order achieve a satisfactory result. It was introduce together with four 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 a different combination of I/O capabilities of two connecting devices[16]. It also forces encryption to 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 Elliptic Curve Deffie-Hellman (ECDH), an Federal Information Processing Standard (FIPS)-approved algorithm. For device authentication and encryption the algorithms, E0 and SAFER+, were unchanged. [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 a scenario 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 six digit number is displayed on both devices and the user is prompt to respond with ”Yes” if the numbers match and ”No” otherwise. Numeric Comparison provides passive eavesdropping and MITM 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 one device has Numeric output but the other device Keyboard input capabilities. An example of such scenario is a keyboard and PC. With this method a six digit passkey is displayed on one device and the user is prompt to enter that passkey on the device with input capability. If the input matches the passkey the pairing is successful. Passkey Entry provides passive eavesdropping protection 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 the connecting devices does not have display nor input capabilities. An example of such scenario is a headset and a phone, where the headset has no input and no output as defined above. Internally this 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 is not mandatory. Just Works provides passive eavesdropping protection but no MITM protection and results in an unauthenticated connection. [16]
3.5.3.3.4 Out Of Bands Out Of Bands allows pairing using other technologies, such as Near Field Communication (NFC). If it provides passive eavesdropping and MITM protection depends 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 approved algorithms. The encryption algorithm was changed to Advanced Encryption Standard - Counter with cipher block chaining message authentication code (AES-CCM), as defined in [19]. With the AES-CCM algorithm the concept of message integrity was introduced, including a Message Integrity Check to the message payload. The device authentication algorithm was changed to HMAC-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 making the 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 enabled independently. 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 be visible 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 modes can be switched on and off at any time meaning that they can be enabled only when needed. The National Institute of Standards and Technology (NIST) recommends in [17] to be in discoverable and connectable mode for as short time as possible and avoid it in public places to maximize security.
33 Table 4.1: The used Bluetooth hardware on the different platforms where O indicates that the combination 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. As none of these systems could run the latest Bluetooth stack for Linux a laptop running Ubuntu was also used for some testing.
4.1.1 CCPilot VA CCPilot VA is a freely programmable 7” display. The computing core consists of a Freescale i.MX 537, 32-bit ARM processor running a freely programmable Linux system with kernel version 2.6.35. It also comes with the LinX Software Suit base package which is a package of commonly used software to simplify development. The Linux Bluetooth stack, Bluez 4.101, is installed for Bluetooth support.
4.1.2 Virtual Machine The VM, provided by maximatecc, is running a standard kubuntu 14.04, kernel 3.13.0, with all standard features. It also has a set of pre-installed applications, such as Qt Framework and Qt Creator, with configurations to quickly be able to develop for different CCPilot displays. The Linux 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 CCpilot VA, 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 also used together with the VM and the Ubuntu-laptop but with those setups the built in Bluetooth adapter of the host computer was mainly used.
4.3 Qt Qt[20] is a cross-platform development framework used to develop application software and is often used with the IDE QtCreator. It is available both under a commercial license and different open 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/object may emit a signal with event information. The signal can be picked up by one or more objects by 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 Bluetooth stack for Linux. It provides support for the core protocols and layers through kernel modules as well 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 with an API relies on other software components to be fully functional, as with the OBEX protocol and the profiles based on it, shown in Fig 5.1, is implemented through Obexd. The support can also 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 enabled or enabled as kernel modules in which case they can be loaded into the kernel at runtime when needed 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 the HS extension. According to Bluez documentation it supports the protocols and profiles in Tabl 5.2 although some protocols and profiles depend on external components. However, Bluez 5 and later 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 at runtime and a brief description of it available on CCpilot displays, which use a kernel with version 2.6. Instead Bluez 4.101, which is the last release of version 4.X, needs to be used and is the focus of this thesis. The main difference between 5.39 and 4.101 is that 4.101 does not have stable BLE support. The DBus API’s and some internal logic is also different between the two major releases making it non-backwards compatible. Bluez 4.X does not provide a list of supported protocols and profiles but the main protocols for BR/EDR are supported and the support of the profiles of interest is presented in this section.
5.1.3 A2DP support An interface, org.bluez.AudioSource, for connecting to a remote device acting like a source is available in the main user space daemon, bluetoothd, in Bluez 4.101. To actually make use of it an application must register the interface name org.bluez.MediaEndpoint together with a set of functions defined by the bluez media − api.doc before trying to connect. When connecting to an A2DP service Bluez will call org.bluez.MediaEndpoint.SelectConfiguration with a set of codec parameters supported by the remote device. The application must compare this to its own capabilities and send the best match back in a reply. Bluez will then call SetConfiguration on org.bluez.MediaEndpoint with the same codec parameters as negotiated earlier and a transport path which is used to acquire the audio stream. The application must then monitor the org.bluez.AudioSource.P roperyChanged signal to see when the property State changes to P laying. When it does the application must call org.bluez.MediaT ransport.Acquire on the transport path received earlier to get the file descriptor, which is read to get the audio packets, together with the maximum transfer unit, the size of the packets. When an audio stream is active the audio packets must be unpacked and decoded using the agreed upon codec before being sent to an audio output. [21]
37 Table 5.2: The list of supported protocols and profiles, including roles and versions, for Bluez 5.39
38 The basic concept and events described above applies to Bluez 5.X as well though some changes have been made, such as the interface names and how properties are handled. The handling of theses events is usually done in an external software component, such as PulseAudio, which unpacks, decodes and routes it to the audio hardware behind the scenes both for Bluez 4.101 and 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 role under the interface org.bluez.Control but the only method calls available are VolumeUp and VolumeDown, which are not fully implemented. To make proper use of the CT role Bluez 5 is needed. The interface changed with the release of Bluez 5.0 to org.bluez.MediaControl1 with the 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 with basically the same functionality as org.bluez.MediaControl1, deprecating that interface, as well as properties including, but not limited to, metadata and browsability of media on the remote device.
5.1.5 HFP support Bluez 4.101 provides a DBus API, through bluetoothd, to connect with a HFP service on a remote device but is intended to be used with an external telephony stack, such as oFono, to handle the AT commands over RFCOMM. The API was dropped in Bluez 5.0 and is after that intended 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 connection between Bluez and ALSA through the bluez − alsa package this support was dropped in Bluez 4.100. The simplest way to handle this now is through external software components, such as PulseAudio.
Bluez, PulesAudio and oFono are well integrated with each other and though they provide respective 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 components communicate 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 telephony control is done through oFono, PulseAudio manages the SCO connection and routes the audio to and from the audio hardware. Bluez manages the device and routes necessary information between oFono and PulseAudio. These three software components forms a basis for most IVI’s implemented 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, in Bluez 4.101 to connect to a remote device sharing its network connection over Bluetooth. Calling org.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 be able to actually use it the network interface needs to be configured and managed. This is often done 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 software Obexd which implements the obex protocol and obex based profiles on top of Bluez. Obexd was officially added to the Bluez project with the release of Bluez 5.0. Both 4.101 and 5.39 supports both 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 this case the phone.
5.2 Obexd Obexd is a software component which is used in addition to Bluez to implement the obex protocol and the profiles based on that protocol. It offers both a client and a server daemon. In the IVI we 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 DBus used by Bluez. To access the MAP and PBAP client APIs an obex session must be created using the org.openobex.Client interface with the method call CreateSession(dictdevice) sending a dict entry as an argument. The dict argument is configured through parameters and must contain an entry for the Destination, the Bluetooth device address of the phone, and the T arget, which is the target profile, MAP or P BAP . Other possible parameters are Source and Channel. The reply 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 P BAP as parameter will expose an API with the following method calls under the interface name org.openobex.P honebookAccess
• void Select(string location, string phonebook) - Needs to be called before any other method to select a phone book object.
Location is where the phone book object is stored, e.g. int for internal memory or sim for first SIM card.
P honebook is the phone book object, e.g. pb for main phone book or ich for incoming call history.
• string PullAll() - Returns the selected phone book object as a single string on vcard format.
• array{string vcard, string name} List() - Returns a list of the selected phone book object 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 a list, 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. Defaults to ”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 in the 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 API with the following method calls under the interface name org.openobex.MessageAccess
• void SetFolder(string name) - Sets the current working directory (CWD) to the supplied name
• string GetFolderListing(dict filter) - Returns the subfolders of the CWD • string ListMessages(string folder, dict filter) - Returns a string of all messages in the CWD in XML format as a MsgListingObject according to MAP specification. No existing function seems to exist to transfer the actual bMessage. However, the message content 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 in 0.46 and have not changed drastically in Bluez 5. However, as MAP was added in recent releases it was not mature and some more significant changes have been made to the API since obexd 0.46. An interface similar to MessageAccess is still there but a separate interface has been added to transfer the actual bMessage object, see obex-api.txt in Bluez 5.39 for more information. A major change affecting all APIs is the namespace change which applies to obexd from version 0.47 and onwards, including obexd in Bluez 5.X repository. The part ”org.openobex.XXX” has been replaced with ”org.bluez.obex.XXX” for both service and interface names and the interface names have also been numbered. The numbering makes it possible to keep older versions alongside the new 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 the module-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 the library and user utilities it is possible for programs to communicate directly with the sound devices. This works well when raw sound is transported from a single source to a single destination. In a situation where there might be multiple possible sources and destinations things 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 and resides just above the ALSA kernel in the user space. A goal is to make sure that sound passes through PA instead of directly being sent to the sound devices. PA can then prioritize and manage different audio streams. This is very convenient as the developer wont need to manage the transitions between HFP and A2DP audio streams and in some cases other local audio sources. Another benefit of PA is that even though it is designed for Linux it has been ported to other platforms as well, such as MacOS X and Windows XP [22], thus providing cross platform capabilities.
5.3.2.1 Interaction with ALSA The PA is built on different modules which can be loaded and unloaded depending on what PA is used for. Most modern software can detect if PA is present and use its API directly, in which case the 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 those that cannot communicate directly with PA it exposes itself as a virtual device and enables itself as the default ALSA sink. ALSA will then output sound to PA which then reroutes it back to ALSA 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 audio drivers. 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. Loads module-loopback automatically, which connects the incoming sound to a source, when an active audio stream is present over Bluetooth. For HFP PA will handle the SCO connection, routing the audio to and from the audio hardware for both roles, and for A2DP it will encode/decode the audio and send it to/from the audio hardware, 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 supported features 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 configuration file for PA, when loading module-bluetooth-discover for selecting which backend to use. The available choices are ofono, native or auto where it has been considered most stable to choose ofono or native.
5.3.3 Audio Configuration in Bluez When bluetoothd is started it automatically starts the services which are supported based on loaded kernel modules and settings in configuration files. The supported audio interfaces can be enabled 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 different interfaces 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 framework in Linux. It is built around a core daemon which provides the base level service and is responsible for loading relevant oFono drivers and plugins. An important concept in the core daemon is the modem abstraction. Each device is seen as a modem and is managed independently regardless of the underlying technology used. The drivers are designed to give support for different underlying technologies, from full-featured modems to Bluetooth devices. Another concept in oFono is atoms which provide easy to use DBus API’s for different service and can detect the presence of other atoms and exchange information for further enhanced functionality. The plugins are designed to provide relevant drivers and atoms for different services and can also be used to extend oFono to interact with other services on the system. oFono is well integrated with other communication projects such as Bluez and Connman. As for the Bluetooth protocol it is used to implement the profiles HFP, DUN and SAP. More specifically it 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 emulator atom. The plugin is also responsible for registering the SDP record in Bluez. Enabling the modem associated with a Bluetooth device will make the hand shake procedure and establish the Service Level Connection of the HFP.
5.5 Network management To simplify configuration, setup and management of network connections a management software is often used. In the Linux community there are two major ones which supports Bluetooth, Connman and NetworkManager. NetworkManager was originally designed for desktop computers and was for a long time considered to be the standard Linux management tool. As the need for network connection on embedded devices grew Connman was developed to be more flexible for devices with limited resources. NetworkManager has since then improved in similar envionments and the gap between them has gotten smaller. However, an advantage of Connman is that it is backed by the same team as Bluez, which vouches for good compatibility when new versions of Bluez are released.
5.6 DBus DBus is an inter-process communication (IPC) mechanism which is widespread in open source software today. This allows for different processes or applications to send information between each 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 common ones are the system bus and the session bus. The system bus is system-wide and is shared between different users whereas the session bus often is created solely for a specific user at log in. More session busses may be created by different applications but the session bus created at log 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 same bus a unique and well-known address is used. The address consists of three parts, a service name, an object path and an interface name. The service name represents the connection between the bus and an application. They are often on the form org.myDomain.myApp in order to keep them uniquely identifiable. An application may also provide multiple objects which messages can be sent to and from. This is handled by the object path which is a conceptual path in order to group objects. The actual form is any arbitrary file structure and may be on the form /audio/object1. Finally the interface defines a group of methods and signals which are advertised on the bus. The unique address combining these three parts may then look something like org.myDomain.myApp /object1 org.mayDomain.Interface1.Method1 where org.myDomain.myApp is the service, /object1 is the object path, org.myDomain.Interface1 is the 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. A method 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 method call. Together with the success message an optional return value may be supplied. Method calls always have exactly one source and one destination. Signals are messages from the application which 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, BlackBerry and Linux, both Bluez 4 and 5. In this section the APIand how it can be extended is briefly described.
5.7.1 QtBluetooth Classes The QtBluetooth API can be used to scan, retrieve information about and connect to remote devices. 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 in examples.
5.7.1.1 Scanning Classes Scanning for remote devices can be done either by the QBluetoothDeviceDiscoveryAgent- or QBluetoothServiceDiscoveryAgent-class. The device discovery class will return brief information about the device address and class, in a QBluetoothDeviceInfo object, for all discovered remote devices. To find out the services supported the service discovery class must be used. This class can either be used to discover services on a specified device or for all detectable devices. For each service discovered a QBluetoothServiceInfo object is created with information about the service and the device it was discovered on. The QBluetoothServiceInfo class is also used to create 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 used to retrieve information of the adapter, such as name and address, and can be used to set scan parameters 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 between devices. It can be done either by L2CAP or RFCOMM, in which case it is an implementation of the SPP. The server class is intended to be set up on a device as a service and should be accompanied with a service record, in the form of a QBlueoothServiceInfo object, containing all the information needed to connect to the service. The socket class can be used to connect to a server 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 paired with the remote device in advance. Three classes are designed to be used in this process, the QBluetoothTransferRequest, QBluetoothTransferManager and QBluetoothTransferReply. More information 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 they have 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. Qt Bluetooth for Linux is built on Qt D-Bus which is an abstraction of the DBus interface. A QDBusAbstraction 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 −−print −r e p l y −−dest=service .name /obj/path \ org.freedesktop.DBus. Introspectable .Introspect > name . xml which utilizes the common interface org.freedesktop.DBus.Introspectables method Introspect. The method will return all object paths and interfaces together with methods, signals and arguments of the chosen service, path and bus and write it to the named XML-file. The result may look like method return sender=:1.80 -> dest=:1.136 reply serial=2 string >!DOCTYP node PUBLIC ”-//freedesktop//DTD D-BUS Object Introspectation 1.0//EN ”http://www.freedesktop.org/sandards/dbus/1.0/introspect.dtd”>
47 files, the named .h and .cpp-files. It is followed by the XML-file and last the interface if more than one is present in the XML. Further options are available and can be accessed through running qdbusxml2cpp -h, one such example used in this thesis is the -i <filename> to add an #include in the output file.
5.7.2.2 Signatures Simple argument types is automatically mapped, through the QDBusArgument class, to a corresponding Qt type, such as a string is recognized as a QString. There is a set of primitive types which are natively supported. However, more complex types need to be annotated in the 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 different types. An example use case for this is a set of optional parameters which uses the string as a key to the parameter and the variant as data. The data can then be a string for one entry and an integer or boolean for another. The example with a{sv} can be solved using a QVariantMap or a custom made Metaclass and in the XML document it might look something like
48 -i my Meta Type.h when calling qdbusxml2cpp. The metaclass then must be registered at runtime in the application by adding qRegisterMetaType(MyStringMap); before any DBus call is made using the type. The resulting class can be instantiated and used to send and receive information through the DBus API with the advantage that the type of input arguments 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 classes which can be used as one of the roles of the different profiles. As Qt is cross platform this stage involves a layer which is specific to the Bluetooth stack used, in this case bluez 4. Above that layer the decision of which Bluetooth stack is used is taken into account. Finally there is an interface which can be used by the developer independently of which platform and software implementing the Bluetooth stack is used. When extending the support for a specific platform the architecture is not necessary. However, if both Bluez 4 and 5 will be used for different systems it 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 and the ones created through qdbusxml2cpp, uses asynchronous DBus function calls. It returns a QDBusPendingReply
QDBusPendingCallWatcher *watcher = new QDBusPendingCallWatcher(reply, this).
The watcher emits a signal when the reply is ready. The signal is connected to a function by
QObject::connect(watcher, SIGNAL(finished(QDBusPendingCallWatcher*)),this, SLOT(handleReply(QDBusPendingCallWatcher*))); where handleReply is a callback function implemented by the developer. The reply can then be assessed in handleReply, first by checking that the reply is of the expected format or if an error has occurred followed by the content of the reply. This is a reason for checking the reply even if it is expected to be an empty message or the actual data in the response is considered unimportant.
If there is no other task which can be performed before the reply is ready it is possible to wait 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 the ones which were not were easily added through the apt-get tool. For the CCpilot VA no such tool was available and the work of adding the external components were put on maxximatecc’s development team in Finland. The setup of software and their version are presented in Tabl. 6.1 for the different platforms. The phones used were a Sony XPeria Z5 Compact and a Samsung Galaxy 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 added to /etc/rc3.d/ to enable the system DBus on boot. Another script was made to start the session DBus 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 loadable kernel modules from the Linux kernel. The script needs to be run using source to make sure the session DBus is active in the konsole session. The script also makes sure that the Bluetooth device is up before starting bluetoothd when using the generic Bluetooth USB adapter. When using 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 objects of the types scandialog, hfp, pbap and map are created. These objects do not depend on eachother and all information exchange between them is done through the mainwindow object. Before the UI 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 map creates a designated obex session for each service and defines methods to pull objects through the DBus API exposed by the Obexd-client. The hfp object connects to the oFono API for the remote 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 Qt application.
6.2.2 Mainwindow The UI of the mainwindow contains multiple tabs, Tab1 was intended for music streaming but as the control feature was not implemented in Bluez 4.101 it remains empty, Tab2 for handling phone 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 hfp object with the digit field as input for dialing a number. An incoming call is indicated in a separate text field and can be managed through the call and hang up buttons for accepting or rejecting respectively. The operator of the connected phone’s network is shown on the top of the screen as well as the current signal strength.
On the right a listView is used to visualize the contact from the phone book by names. On clicking 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 ”P revious” is used.
6.2.3 Scandialog The dialog is used to scan the proximity for devices and displays the devices advertising themselves as phones. It does this by using the QBluetoothDeviceDiscovery class and filtering out only devices with phone set as their main class. This does not verify that the profiles used in the rest of the demo is supported by the device. When a device is discovered the current pariring status is checked, if the devices are already paired they appear in green otherwise in black. When a device is selected and the OK button is pressed the QDialog will attempt to pair, if not already paired. If the pairing is successful, or if already paired, the QDialog emits a signal with the address as a QString before closing. The address is caught by the Mainwindow and passed as parameter 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 the available modems in ofono through the org.ofono.ModemsManager interface. When the phone is 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 networkoperator can be queried and the signal emitted through the interface when properties are changed is connected to a slot in the hfp object to handle it dynamically. If the changed property is signalstrength or networkoperator a signal is emitted from the hfp object with the new value of the property which is caught by the mainwindow.
The hfp object also has public functions for accessing dialNumber and HangUpAll methods of the org.ofono.VoiceCallManager interface. The interface emits a signal when a new VoiceCall is added which is caught and evaluated if the call is incoming, in which case the hfp emits a similar 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 has been successfully created the main phone book of the internal memory of the phone is selected followed by listing the entries in the phone book. This returns a list with a vcard-number and name of each entry which is stored in a list. The contact name is displayed in the UI through a listView and by clicking a name the full vcard is requested. The reply is parsed by splitting the string at each new line. Each line is then split further at every : and it is examined if the first part contains ”TEL” in which case the second part is recognized to be a phone number. When a new phone number is parsed a signal is emitted with the number as a QString to be displayed in the digit field in the mainwindow, replacing any prior number in the field. In case of multiple numbers 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 has been successfully created the SMS inbox is set as the target folder followed by pulling the MessageListing 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 are then 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, through Bluetooth, to a device running PA in the background. AVRCP was tested by using the DBus interface in the konsole through dbus-send. PAN was tested with NetworkManager, which was preinstalled on both the VDM and the Ubuntu laptop. The DBus interface for connecting to a remote 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 network interface, the Obexd scripts used were
• map-client : used to create map session and request messages from a remote device running a MAP server
• pbap-client : used to create pbap session and pull contacts from a remote device running a 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 only included connecting to a profile and using a few selected features. This does not guarantee that other features work. More details are presented for each platform in this section.
7.1.1VM The Qt demo application verified some functionality of PBAP, MAP and HFP on the VM for all tested phones both with the built-in and external Bluetooth adapters. PBAP and MAP worked as expected aswell as the service level connection for the HFP. Although the making calls worked occasionaly through HFP it also proved to be very unstable which is discussed further later in the this section. Functionality of A2DP and PAN were also achieved on the VM outside of the Qt application. Streaming music worked as expected and PAN could be used to browse the internet using 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 tested phones. 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 as expected whereas it was not possible to connect to MAP on the Xperia Z5 Compact. On the Galaxy S3 it was possible to connect to MAP and to list and change folders but not to request the actual MessageListing objects. HFP and A2DP were not possible to test on the VA as both requires PulseAudio and HFP also requires oFono to work which is not available on the current image. 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 only tested through the external components and the Python test scripts. All tested featured worked on 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 unresolved towards 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 and the 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 device in a void state where it does not appear neither on the host nor the VM. In these cases it has been possible to reattach the external dongle and try again. If the problem have been the built 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 indicates the opposite
There has also been another issue where the USB connections stop working randomly. In that case all USB devices have stopped working and commands like lsusb freezes indefinitely. The latter problem have been located to /sys/devices/pci0000:00/0000:00:06.0/usb2/ which lsusb tries to read from when hanging. It is also not possible to open the folder in Dolphin, a file explorer, or by command cd in the konsole without the window freezing indefinitely. The dmesg log shows the message ohci-pci 0000:00:06.0: bad entry 25588780 when the problem occurs. No other 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 Bluez tarball all devices created the network interface bnep0 as expected. When testing it with NetworkManager the Xperia Z5 Compact had difficulties achieving connected status. It has worked a few times but most of the time it does not reach connected status, although it was possible to browse the internet through the connection while the status was connecting. For the Galaxy 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 and occasionally fails in calls resulting in no sound. In this case hanging up and redialing solves the problem. 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 the observations this occurs somewhere around 50% of the attempts. However, in some cases more than ten subsequent calls have been made without the problem occurring and in some cases it occurs 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 packet for unknown connection handle X where X is different indexes. This message also occurs continuously when no sound is emitted when a call is active. The controller often fragment the packets which then needs to be reassembled in the kernel. These messages occur when the reassembly fails. The reason it does fail vary and most of the time it is just a randomly damaged package which does not affect the overall sound but when it happens continuously, as it does when 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 when running Bluez and PulseAudio on Virtual Development Machines, according to oFono mail list [25], though with Bluez 5.33 and PA 6.0 but both the frequent occurrence of no sound and crashes/freezes are present. Some oFono configuration are mentioned in the responses, but those parameters have been added in later oFono versions and are not applicable to version 1.12 and did not fix the problem. The most probable cause mentioned in the responses is that the virtualization of the audio in the VM is not working properly together with the hardware as the same 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 PulseAudio which was not available on the Linux image currently available on the VA. As PulseAudio was not available A2DP was not testable either. As adding these items is not as straight forward on the 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 which were added to the image. An effort was also made to include PulseAudio but due to lack of flash memory the resulting image was too large. It is not the first time the lack of flash memory is a problem on the devices and a decision has been made to increase this. It also highlight a downside of using already existing software, that they may be larger than necessary due to many features not needed in an IVI implementation. Some of these features may be possible to omit when 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, preferably with 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 possible to 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 that iOS does not work together with the CrossLink AI due to encryption issues. This should be investigated 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 but the functionalities may be grouped into
• Hands free phone functionality - Two-way routing of call audio and management of phone calls. Extendable with features such as multiparty call, access to phone book, call history and 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) of an audio or video stream
• Personal Area Network Profile (PAN) - Setting up a wireless network to share an internet connection 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 protocols in the Bluetooth stack but it does also provide user space daemons and tools. The latest Bluez versions, 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 only affects 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 compatibility with 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. Together with 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 prioritizes and manages different audio stream such as the A2DP and HFP audio including necessary decoding 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 in PAN simplifies the development of IVI applications and they form the base of Bluetooth Connectivity together with Bluez for many Linux IVI solutions on the market, the open source projects Tizen IVI and GENIVI as an example.
Testing the profiles on the VDM and an Ubuntu laptop has been successful except for the audio routing in the HFP profile. The reason for this has not been determined, but is believed different in those systems. Testing the profiles on the CCpilot VA has been more difficult as the work of adding external components has been handled by others within the company, who has been assigned to higher prioritized tasks during most of the time of the thesis. The flash memory of 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 tested on the VA. Although MAP is expected to work with the same setup it has not, and the reason has not been determined.
59 References
[1] S. Marisetty, D. Srivastava, and J. A. Hoffmann, “An architecture for in-vehicle infotainment systems.” http://www.drdobbs.com/embedded-systems/ an-architecture-for-in-vehicle-infotainm/222600438, January 2010. Accessed in 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 in October 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. M¨uller and M. Astiz, “Automotive bluetooth telephony - combining bluez and 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 & terminology overview, 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/edr controller 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 [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 May 2016.
[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