1 Institutionen för systemteknik Department of Electrical Engineering Examensarbete Bluetooth Packet Reader in an OSE Environment Henrik Ekblad Tobias Gentzell LiTH-ISY-EX
2 Bluetooth Packet Reader in an OSE Environment, Examensarbete utfört i Kommunikationssystem vid Linköpings Tekniska Högskola av Henrik Ekblad Tobias Gentzell Reg nr:lith-isy-ex-3131 Handledare: Niclas Persson Examinator: Fredrik Gunnarsson Linköping
3 Avdelning, Institution Division, Department Department of Electrical Engineering Division of Automatic Control Datum Date Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport ISBN ISRN Serietitel och serienummer ISSN Title of series, numbering LiTH-ISY-EX-3131 URL för elektronisk version Title Titel Bluetooth Packet Reader in an OSE Environment Bluetooth paket läsare i en OSE miljö Författare Author Henrik Ekblad & Tobias Gentzell Sammanfattning Abstract Bluetooth is today the fastest growing wireless standard, which enables data communication of all kinds. The original idea for Bluetooth was to be a low-effect and low-cost radio interface between mobile phones and their accessories. Now there are numerous of other user scenarios. The master thesis describes the basics about data communication and a more detailed version of the wireless standard Bluetooth. In order to gain knowledge about Bluetooth, we have to create a simple Client/Server application that sends data from one computer to another. The program is implemented at Enea Data AB own operating system, OSE (Operative System Embedded). This thesis also considers the possibility to use the Bluetooth Host stack and the already existing Loopback function to simulate Bluetooth communication, thus run both the Client and Server applications on one computer without the Bluetooth devices. Finally we have created a serial sniffer which is an external process that displays the data traffic between the Bluetooth Host stack and the Bluetooth device. Looking at the packets coming through the serial port gives a deep understanding of how Bluetooth communication really works. Nyckelord Keyword Bluetooth, OSE, Serial Port, Packet, Loopback
4 Abstract Abstract Bluetooth is today the fastest growing wireless standard, which enables data communication of all kinds. The original idea for Bluetooth was to be a low-effect and low-cost radio interface between mobile phones and their accessories. Now there are numerous of other user scenarios. The master thesis describes the basics about data communication and a more detailed version of the wireless standard Bluetooth. In order to gain knowledge about Bluetooth, we have to create a simple Client/Server application that sends data from one computer to another. The program is implemented at Enea Data AB own operating system, OSE (Operative System Embedded). This thesis also considers the possibility to use the Bluetooth Host stack and the already existing Loopback function to simulate Bluetooth communication, thus run both the Client and Server applications on one computer without the Bluetooth devices. Finally we have created a serial sniffer which is an external process that displays the data traffic between the Bluetooth Host stack and the Bluetooth device. Looking at the packets coming through the serial port gives a deep understanding of how Bluetooth communication really works. i
5 Acknowledgements Acknowledgements We would like to thank Enea Realtime AB for letting us do our Master Thesis at their division Communication in such an interesting field as Bluetooth. With the experience the staff possesses we have got the help we have needed to succeed with our task and we would like to thank all of them for taking their time to help us. A special thanks to all of them who is involved in the New Technology Group of Bluetooth at Enea Realtime. Interesting discussions have led us to new ideas when solving our problems. With their help the project has reached a higher dimension. We also like to thank our supervisors at the Division of Control and Communication at Linköpings University, PhD Fredrik Gunnarsson and Niclas Persson. With their experiences and skills they have led us through this work. They have proof-read our thesis several times and given us the support and backup we have needed to make the thesis complete. ii Tobias Gentzell & Henrik Ekblad Stockholm 6th February 2001
6 Contents Contents iii ABBREVIATIONS INTRODUCTION ENEA DATA AB PURPOSE OF THE MASTERS THESIS PROBLEM DESCRIPTION DOCUMENT OVERVIEW BLUETOOTH INTRODUCTION HISTORY USER SCENARIOS THE FUNDAMENTALS OF DATA COMMUNICATIONS BLUETOOTH STACK THE STRUCTURE OF BLUETOOTH HOST STACK Bluetooth Radio Bluetooth Baseband Link Manager Protocol (LMP) Host Controller Interface (HCI) Logical Link Control and Adaptation Protocol (L2CAP) Radio Frequency Communication (RFCOMM) Stack Control Manager (SCM) Service Discovery Protocol (SDP) Further Protocol Layers Serial Port Profile RELATIONS BETWEEN THE LAYERS HOST SUPPORTING INTERFACES Virtual Operative System (VOS) Serial Interface Layer (SIL) THE BLUETOOTH APPLICATION PROGRAMMERS INTERFACE (BTAPI) BLUETOOTH APPLICATION EXAMPLE BLUETOOTH THEORY BLUETOOTH BASEBAND PACKETS Access Code Packet Header Payload Format Packet Types HCI TRANSPORT LAYER HCI UART Transport Layer HCI PACKETS HCI Command Packet HCI Event Packet HCI Data Packets LOOPBACK BLUETOOTH APPLICATION TOOL KIT...32
7 Contents 6 OSE A REALTIME OPERATIVE SYSTEM EASE OF USE HIGHER PERFORMANCE KERNEL MEMORY MANAGEMENT PROCESSES Static process Dynamic processes Interrupt processes Timer interrupt processes Prioritised processes Background processes Phantom processes BLOCK AND BLOCK PROCESSES SIGNALS DESIGNING A SYSTEM BUILDING A SYSTEM DEBUGGING ERROR HANDLING Process error handler Block error handler Kernel error handler Error vs. Warnings ANALYSE USING THE ERICSSON BLUETOOTH APPLICATION TOOL KIT EXAMINATION OF THE LOOPBACK FUNCTION SETTING UP THE BLUETOOTH SYSTEM IN THE OSE ENVIRONMENT APPLICATION Choice of Application Layer Make and User Configuration file Client/Server Application THE PACKET READER PROCESS Representation RESULTS AND LIMITATIONS RESULT LIMITATIONS FOR THE BLUETOOTH SPECIFICATION 1.0B APPLICATION LIMITATIONS SOFTWARE LIMITATIONS CONCLUSION AND FUTURE WORK...53 iv
8 Contents APPENDIX A: FUNCTION CALLS IN THE CLIENT APPLICATION...54 APPENDIX B: FUNCTION CALLS IN THE SERVER APPLICATION...58 APPENDIX C: FUNCTION CALLS IN THE PACKET READER PROCESS. 60 APPENDIX D: FUNCTION CALLS IN THE BT_API...61 APPENDIX E: FUNCTION CALLS IN THE SIL...62 APPENDIX F: FLOWCHART OF ONE CYCLE OF THE CLIENT/SERVER APPLICATION...64 APPENDIX G: ONE LOGGED CYCLE FROM THE CLIENT...65 APPENDIX H: ONE LOGGED CYCLE FROM THE SERVER...72 REFERENCES...78 v
9 Abbreviations Abbreviations ACK ACL API BSP BT CAC CPU CRC CTS DAC DBM DH DIAC DM DV ETSI FCC FEC FHS FTP GFSK GIAC HCI HEC HV IAC ID INET IP ISM IT L2CAP LAN LAP LC LMP LSB MSB MSVC NAK OBEX OCF OGF OS Abbreviations Explanation Acknowledge Asynchronous Connection-Less Application Programmers Interface Board Support Package Bluetooth Channel Access Code Central Processing Unit Cyclic Redundancy Code Clear To Send Device Access Code Data Bas Manager Data-High rate (data packet type) Dedicated Inquiry Access Code Data-Medium rate (data packet type) Data Voice (data packet type for voice) European Telecommunications Standards Institute Federal Communications Commission Forward Error Correction Frequency Hop Synchronisation File Transfer Protocol Gaussian Frequency Shift Keying General Inquiry Access Code Host Controller Interface Header Error Check High quality Voice (e.g. HV1 packet) Inquiry Access Code Identification OSE s version of TCP/IP (Internet) Internet Protocol Industrial, Scientific, Medical Information Technology Logical Link Control and Adaptation Protocol Local Area Network Lower Address Parts Link Control Link Manager Protocol Least Significant Bit Most Significant Bit Microsoft Visual C Negative Acknowledgement Object Exchange (Protocol) Opcode Command Field Opcode Group Field Operative System 1
10 Abbreviations 2 OSE PCM PDU PIN PPP PROM RFCOMM RTOS RTS SCM SCO SDP SIG SIL SUNET TCP TDD UAP UART UDP USB VOS WAP Operating System Embedded Pulse-Code Modulation Protocol Data Units Personal Identification Number Point-to-Point Protocol Programmable Read-Only Memory Radio Frequency Communication Real-Time Operative System Ready To Send Stack Control Manager Synchronous Connection-Oriented Service Discovery Protocol Special Interest Group Serial Interface Layer Swedish University NETwork Transmission Control Protoco Time-Division Duplex Upper Address Part Universal Asynchronous Receiver-Transmitter User Datagram Protocol Universal Serial Bus Virtual Operative System Wireless Application Protocol
11 Introduction 3 1 Introduction 1.1 Enea Data AB Four recently graduated MSc founded Enea in The first assignments they had were to write an operating system for flight control computers. After more than 30 years of experience in the industry of Information Technology the company has got a strong market position in technical system development for industry. Enea has always been a pioneer within data communication technology, for instance they registered Sweden s first domain name, Enea.se, and they also are the founders behind the Server SUNET. Enea Data AB consists of three major subsidiaries: Enea OSE Systems, Enea Realtime and Enea Business Software. Enea OSE Systems is the largest of the subsidiaries and the only international part of the concern. The core business for Enea OSE Systems is the development of the OSE real-time operating system. The system was created specifically to fit the telecom industry and today it is the fastest-growing real-time operating system in the world market. The OSE (Operative System Embedded) real-time operating system is also a perfect platform for the new wireless technology Bluetooth. Enea Realtime is a supplier of real-time development services. They have customers in telecom business, mostly within base station systems, WAP applications and Bluetooth. Enea Realtime also collaborates extensively with Enea OSE Systems on customising OSE products. Another important area have become the medical industry, to get a strong market position within this area Enea Realtime has recently acquired Epact from Linköping. Enea Business Software is working within the field of e-business. Enea Data AB is listed on Attract 40 at OM Stockholm Exchange. The company has at the moment around 800 employees but they are recruiting new labour in all fields of the business continuously. Enea s business concept is to market and sell services, products and training within the areas, real-time operating system OSE, embedded systems, business supporting IT and e-business solutions, in order to contribute to the further development and competitiveness of Swedish and foreign industrial and service companies. 1.2 Purpose of the Masters Thesis In the society of today people and companies are struggling to get wireless. A group of five multinational companies decided to create a new standard for wireless mobile communication that supports all demands from the market. The new standard is called Bluetooth. One of the companies that stand behind the standard is Ericsson, who has created the data communication stack for Bluetooth. The Bluetooth Host stack is specified to work in any host environment. At this very moment companies around the world are competing with each other to be the first to have product to sell on the market. The companies want their products to work in different host environments, so it is important for the distributors of the operative systems to make their system support the Bluetooth Host stack.
12 Introduction Our work is to find out whether or not it is possible to create a testing tool so that you can run a Client/Server application over the Bluetooth stack on one computer not having to use any Bluetooth devices. This is ment to be a product that Enea Data AB will sell to customers so that they can quickly create a functioning Bluetooth application. Another task is to create a packet reader that reads and displays all the packet passing the serial port to the Blutooth device which is nice to know when you test your application. The packet reader was asked for in our office by a lot of people and they said that it would ease the testing and understanding of Bluetooth. 1.3 Problem Description Enea Data AB has ported the Bluetooth Host stack to the OSE-environment, which makes it possible for the OSE users to create Bluetooth applications. Enea Data AB are looking for a tool that makes it possible to simulate a connection between a Client and a Server side on a single host by using the Bluetooth Host stack. In the end the goal with the tool is to test the performance of the applications and if they achieve the demands. Ericsson implemented a Loopback function, which makes it possible to execute the Client and Server on the same Host using the same stack. Loopback was implemented to test the applications. The first general step is to investigate whether it is possible to implement Loopback in an OSE environment by using a simple Client/Server application. The next task is to read the data passing through the Loopback. The data will tell us which function call that was called in the stack; this will increase the understanding of the stack. The work should include the following steps: 1. Create a simple Client/Server application, working on the top of the Bluetooth Host stack, which sends and receives data between two Bluetooth devices. 2. An investigation if the Loopback function works as Figure 1.1 illustrate, i.e. a function where the information packets passes by and it is possible to identify them. Figure 1-1 An assumed illustration of how the Loopback function would work. 3. Store all data traffic between the Bluetooth Host stack and the Bluetooth device by copying and sending the packets forward to an external process. 4. Decode the data, which will give us information about outgoing and incoming functions and messages. The data consist of a header and other information. 5. Log the data and represent it in a way that is easy to understand. 4
13 Introduction Document Overview This document overview chapter will give the reader an overall picture of the thesis. The thesis starts with an introduction of the Bluetooth wireless technology and to the basic background in data communication in chapter 2. The next chapter will give the reader an insight in how the Bluetooth data communication stack works and how the layers in it collaborate with each other. Chapter 4 is contained in the thesis to make it possible for the reader to understand how the Packet Reader process is working and how the data information is packeted in the Bluetooth transmission. The chapter will also introduce the Loopback function in the Bluetooth Host stack. Chapter 5 describes the Bluetooth module we are using in the project. The real-time operative system OSE is described in chapter 6. The chapter is introducing the reader to OSE specific things like different processes and signal consideration. In chapter 7 the different steps in the task will be discussed and analysed. First the investigation of the Loopback function will be discussed. Then the building of the Client/Server application and all settings in the environment is described. The next step in the documentation is the description of the construction of the Packet Reader process and how the task will be represented. Chapter 8 is giving the reader a summary of the result and limitations that has occurred during the solving of the tasks.
14 Bluetooth Introduction 6 2 Bluetooth Introduction This chapter will give the reader a short introduction to the project Bluetooth. It will give the reader a brief insight why Bluetooth is created and what it could be used to. The chapter also contents an introduction to the fundamental terms that is used in basic data communication. For more reading about data communication see . 2.1 History In 1994 Ericsson Mobile Communications AB started to investigate the possibility of developing a low-effect, low-cost radio interface between mobile phones and their accessories. In February 1998 five companies Ericsson, Nokia, IBM, Toshiba and Intel, formed a Special Interest Group (SIG). The consortium contains the leading companies within the fields of mobile phones, laptops, core and digital-signalprocessing technology. The reason SIG was put together was to establish a standard for the air interface, the software that controls it and thereby ensuring interoperability between devices of different manufacturers. SIG developed a wireless radio standard and named it Bluetooth, after the Danish Viking Harald Blaatand. In case Bluetooth becomes a revolution in wireless communication, which many experts and technicians think, there are many solutions that simplify everyday situations that come true. It is the imagination that sets the limits. Among other things home automation, home entertainment, electronic commerce and access control. 2.2 User Scenarios There are lots of future user scenarios for the Bluetooth communication. A few of them will soon enter the market for wireless products. The first product is Ericsson wireless headset for mobile phones, which entered the market at New Year A big and important part of Bluetooth is the profiles which makes the different products interoptable. In this case where Ericsson has their headset they use the Headset Profile. This profile ensures the user that all the mobile phones that support the Headset Profile can make use of the headset not just the Ericsson mobile phone. Other scenarios including profiles are for example: Three-in-one phone (use the phone as an intercom, cordless or as a mobile phone in different functions area) which uses the Cordless Telephony Profile and the Intercom Profile. Interactive conference (connect every participant for instant data exchange)which uses the Object Push Profile. Briefcase trick (access while the portable PC is still in the briefcase) which uses the Dial-up Networking Profile. Automatic synchronisation (when entering the office, the address list and calendar in your notebook automatically updates the files on your desktop computer or vice versa) which uses the Synchronication Profile. Cordless desktop (connect all peripheral tools to your PC or the LAN (Local Area Network) which uses the LAN Access Profile. Wireless support for the industry (to install e g control functions in critical place in a rough environment that does not allowed cables) which uses the Serial Port Profile. For further information about user scenarios see .
15 Bluetooth Introduction A lot of the companies who has got the Bluetooth license do not make consumers products for Bluetooth. Enea Data AB is one of them; they are porting the Bluetooth Host Stack to the OSE environment, making it possible for the consumers to create suitable applications for their specific project. 2.3 The Fundamentals of Data Communications The fundamental purpose of data communication is to exchange information between two agents for example a Server and a Client. Consider for example the transfer of a file between two computers. To transfer a file the Client (source) must activate a direct communication path or create the data path via a communication network, and finally the source system must be ascertain that the Server (the destination) is prepared to receive data. The file transfer application on Client system must ascertain that the file management program on the Server is prepared to access and store incoming file transfers. If the file formats used on the Client/Server are different from each other, one or the other must perform a format translation function. For example this could happen when you transmit files between different operating systems. When discussing computer communications terms like layer, stack, protocol and communication architecture are a necessity to know. For two entities to communicate they must speak the same language. What is communicated, how it is communicated, and when it is communicated must conform to some mutually acceptable conventions between entities involved. The conventions are referred to as a protocol (see Figure 2-1), which may be defined as a set of rules governing the exchange of data between two entities. 7 Figure 2-1 The course of events for data communication. The key elements of a protocol are: Syntax: Include such things as data format and signal levels. Semantics: Include control information for coordination and error handling. Timing: Includes speed matching and sequencing.
16 Bluetooth Introduction Having introduced the concept of a protocol, we can now introduce the concept of communication architecture. It is clear that it has to be a higher degree of cooperation between the two computers. In general terms, communications can be said to involve three agents: application, computers and networks (in our case Bluetooth). It is therefore natural to simplify the problem and organise the communication task into three relatively independent layers (see Figure 2-2). Network access layer Transport layer Application layer 8 Figure 2-2 An illustration of the three typical layers; Network access, Transport and Application layer. These layers are together called a stack. The network layer is concerned with the exchange of data between a computer and the network to which it is attached. The sending computer must provide the network with the address of the destination computer, so that the network may route the data to the appropriate destination. Regardless of the nature of the applications that are exchanging data, there is usually a requirement that data will be exchanged reliably. That is, we would like to be assured that all of the data arrive at the destination application and that the data arrive in the same order in which they were sent. Thus, it makes sense to collect those mechanisms in a common layer shared by all applications; this is referred to as the transport layer. Finally, the application layer contains the logic needed to support the various user applications.
17 Bluetooth Stack 9 3 Bluetooth Stack This chapter will give the reader an illustration how the different layers of the Bluetooth stack and interfaces between them work and why they are included in the Bluetooth software and hardware. The chapter also tells the reader which layer communicating with each other. Finally the chapter will give a brief introduction to Bluetooth programming, see . 3.1 The Structure of Bluetooth Host Stack The Bluetooth software supplied by Ericsson is basically a Stack similar to the stacks that are used in all data communication. The stack contains different layers of protocols, which eases the communication. The Bluetooth module also includes three hardware layers (Link Manager, Baseband and Radio) that are important for the Bluetooth functionality. There is also a layer called HCI (Host Controller Interface) Firmware that implements the HCI commands for the Bluetooth hardware. The typical layers for the Bluetooth module and the Bluetooth Host Stack are described in the following chapters and in Figure 3-1 below. Today the Bluetooth stack is a two CPU solution, which means that the software is running on one CPU and the hardware (Bluetooth module) is running on another CPU. We must therefore have a transport layer between the two CPU s. To simplify the structure of the stack, compare Figure 3-1 with Figure 2-2. The application layer in the Bluetooth Host stack is the same as the highest layer, the File transfer application. The rest of the Bluetooth stack except the Radio layer will be a part of the Communications service module. Finally the Radio layer can be resembled with the Network access module. Figure 3-1 An illustration of the Bluetooth software (Host stack) and the Bluetooth hardware (the module) including the interfaces to the Operating System, Serial port and the Application. SIL is the interface that passes the HCI commands to the HCI Transport Layer.
18 Bluetooth Stack Bluetooth Radio The Bluetooth Radio (layer) is the lowest defined layer of the Bluetooth specification. It defines the requirements of the Bluetooth transceiver device operating in the 2.4GHz ISM (Industrial Scientific Medical) band, which is the same frequency band as microwave oven is operating in. The Bluetooth radio accomplishes spectrum spreading by frequency hopping in 79 hops displaced by 1 MHz, starting at 2.402GHz and finishing at 2.480GHz. In a few countries (i.e. Spain & France) this frequency band range is (temporarily) reduced, and a 23-hop system is used. In order to comply without band regulations in each country. In both systems a guard band is used at the lower and upper band edge. When it comes to the modulation characteristics, the Bluetooth radio module uses Gaussian Frequency Shift Keying (GFSK) where a binary one is represented by a positive frequency deviation and a binary zero by a negative frequency deviation. For further information se  Bluetooth Baseband The Baseband is the physical layer of the Bluetooth. It manages physical channels and links apart from other services like error correction, data whitening, hop selection and Bluetooth Security. The Baseband layer lies on top of the Bluetooth Radio layer in the Bluetooth stack. The Baseband protocol is implemented as a Link Controller, which works with the Link Manager for carrying out link level routines like link connection and power control. The Baseband also manages asynchronous and synchronous links, handles packets, do paging and inquiry in order too access Bluetooth devices in the area. The Baseband transceiver applies a Time-Division Duplex (TDD) scheme (alternate transmit and receive). Therefore apart from different hopping frequency, the time is also slotted. For deeper understanding see . The channel is divided into time slots, each 625 ms in length. The time slots are numbered according to the Bluetooth clock of the piconet master. A piconet is when two or more Bluetooth units are sharing one channel. The maximum number of units in one piconet is eight. One of the participating units becomes a master of the piconet and the rest of the units become slaves. A TDD scheme is used where master and slave alternatively transmit. The master shall start its transmission in even-numbered time slots only, and the slave shall start its transmission in odd-numbered time slots only. The packet start shall be aligned with the slot start. Baseband handles two types of links: Synchronous Connection-Oriented (SCO) and Asynchronous Connection-Less (ACL) link. The SCO link is a symmetric point-topoint link between a master and a single slave in the piconet. The master maintains the SCO link by using reserved slots at regular intervals. The SCO link mainly carries voice information. The master can support up to three simultaneous SCO links while slaves can support two or three SCO links. SCO packets are never retransmitted. SCO packets are used for 64 kb/s speech transmission. The ACL link is a point-tomultipoint link between the master and all the slaves participating on the piconet. In the slots not reserved for the SCO links, the master can establish an ACL link on a per-slot basis to any slave, including the slave already engaged in an SCO link. Only a single ACL link can exist. For most ACL packets, packet retransmission is applied.
19 Bluetooth Stack 13 different packet types are defined for the Baseband layer of the Bluetooth system. All higher layers use these packets to compose higher level PDU s (Protocol Data Units). The packets are ID, NULL, POLL, FHS and DM1; these packets are defined for both SCO and ACL links. DH, AUX1 and DM are defined for ACL links only. HV and DV are defined for SCO links only. For more detailed information about the packets see chapter Each packet consists of three entities, the access code, the header and the payload. Access code is used for timing synchronisation, offset compensation, paging and inquiry. The header contains information for packet acknowledgement, packet numbering for out-of-order packet reordering, flow control, slave address and error check for header. The packet payload can contain voice field, data field or both. It has a data field; the payload will also contain a payload header Link Manager Protocol (LMP) The Link Manager (LM) carries out link set-up, authentication, link configuration and other protocols. It discovers other remote LM s and communicates with them via the LMP. To perform its service provider role, the LM uses the services of the underlying Link Controller. The LMP essentially consists of a number of PDU s, which are sent from one device to another, determined by the address in the header of the packet. LM PDU s is always sent as single-slot packets and the payload header is therefore one byte. To find out more about the LMP see  Host Controller Interface (HCI) The HCI provides a command interface to the Baseband controller and link manager, and access to hardware status and control registers. Essentially this interface provides a uniform method of accessing the Bluetooth Baseband capabilities. The HCI exists across three sections: the Host, Transport Layer, and Host Controller. Each of the sections has a different role to play in the HCI system. The HCI is functionally broken up into three separate parts, see  and . HCI Driver: The HCI Driver is located on the Host. The Host will receive asynchronous notifications of HCI events. HCI events are used for notifying the Host when something occurs. When the Host discovers that an event has occurred it will then parse the received event packet to determine which event occurred. The term Host means the HCI-enabled Software Unit. The HCI Driver establishes the communication between the rest of the stack and the HCI Firmware in the Bluetooth hardware that is connected to the computer. HCI Firmware: The HCI Firmware is located on the Host Controller (the Bluetooth hardware device). The HCI Firmware implements the HCI commands for the Bluetooth hardware by accessing Baseband command, Link Manager commands, hardware status registers, control registers and event registers. 11
20 Bluetooth Stack Host Controller Transport Layer: The HCI Driver and Firmware communicate via the Host Controller Transport Layer, i.e. a definition of the several layers that may exits between the HCI Driver on the Host system and the HCI Firmware in the Bluetooth hardware. These intermediate layers, the Host Controller Transport Layer, should provide the ability to transfer without intimate knowledge of data being transferred. There are several different layers that can be used, which three have been defined initially for Bluetooth: RS232, UART (Universal Asynchronous Receiver-Transmitter) and USB (Universal Serial Bus). The Host should receive asynchronous notification of HCI events independent of which Host Controller Transport Layer is used Logical Link Control and Adaptation Protocol (L2CAP) The L2CAP layer provides connection-oriented and connection-less data services to upper layer protocols with protocol multiplexing capability, segmentation and reassemble operation and group abstractions. Two link types are supported: Synchronous Connection-Oriented (SCO) links and Asynchronous Connection-Less (ACL) links. SCO links support real-time voice traffic using reserved bandwidth. ACL links support best effort traffic. L2CAP itself only supports ACL. To get more extensive descriptions see  Radio Frequency Communication (RFCOMM) The RFCOMM is a transport protocol, with additional provisions for emulating RS- 232 serial ports. The emulation includes transfer of the state of the non-data circuits. RFCOMM has a built-in scheme for null modem emulation. For a deeper understanding see . This protocol supports up to 60 simultaneous connections between two Bluetooth devices. The RFCOMM is used when the programmer intends to make use of the serial port in the Host computer, e.g. using the printer on Host computer. Thus its connections are Client/Server based Stack Control Manager (SCM) The SCM layer is part of the Ericsson Bluetooth stack. It is not described in the Bluetooth specification see  instead. The SCM layer creates data- and voice links through the HCI layer. It takes care of and stores link keys in the case that paired links are used. The SCM enables multiple applications on top of the Bluetooth stack by setting up links independent from each other. The SCM enables local routing in L2CAP, by generating a local handle when the Host sets up a local data link with the local Bluetooth address. This service is used in that case there are more then one application on top of the RFCOMM, e.g. when the Host uses the Loopback test service. 12
21 Bluetooth Stack Service Discovery Protocol (SDP) The SDP makes it possible to discover which services a Bluetooth device has to offer and the characteristics of those available services by using the existing L2CAP connection. A specific Service Discovery Protocol is needed in the Bluetooth environment qualitatively different from service discovery in traditional networkbased environments. The set of services that are available changes dynamically based on the RF proximity of devices in motion. The SDP defined in the Bluetooth specification is intended to address the unique characteristics of the Bluetooth environment, see . When the SDP has got the data it asks for from the other devices it will store the data in the DBM (Data Base Manager). The DBM will maintain the data for the users. The other layers will make a request if they need information about the other devices and the DBM will make a response Further Protocol Layers It is possible to add further layers on top of the stack. It is up to the programmer to choose which layer that supports his needs, this particular layer or layers will then be the top of the stack. Typical protocol layers are e.g. TCP/IP, PPP, WAP, UDP and OBEX, see Figure 3-2. In the Bluetooth specification is OBEX specific defined to support the Bluetooth profiles and standard. Figure 3-2 Further protocol layers. The layers that are specific for the Bluetooth stack are Radio, Baseband, LMP, L2CAP, RFCOMM and SDP.
22 Bluetooth Stack Serial Port Profile There are several types of profiles (see Figure 3-3) that are specified in the Bluetooth specification for profiles. The profiles are made so there should be interoperability between devices from different manufactures for specific service cases. They are written so all defines are process mandatory. This means that if a feature is used, it is used in a specified manner. The profile we are using is the Serial Port profile and the following section will give the reader a short introduction to the profile. Figure 3-3 Bluetooth profiles The Serial Port profile defines the protocols and procedures that shall be used by devices using Bluetooth for RS232 or UART (or similar) serial cable emulation. The scenario covered by this profile deals with legacy applications using Bluetooth as a cable replacement, through a virtual serial port abstraction. The Serial Port profile is placed on top of the RFCOMM layer. The profile requires support from one-slot packets only, which means that this profile ensures that data rates up to 128 kbps can be used. Other restrictions are that only one connection at a time is dealt within this profile, i.e. only point-to-point configurations are considered. It is possible to get around this problem by using multiple executions of the Serial Port profile on the same device. There are a few fundamentals about the profile. It is optional to use security features such as authorisation, authentication and encryption, but support for authentication and encryption is mandatory. There are no fixed master/slave roles, but there are always one device that is the initiator of the link establishment and one device that is waiting for another device take initiative to connect. For more details about the profile see .
23 Bluetooth Stack Relations Between the Layers The Host stack layers are communicating with each other by commands and events. All the protocol components have the same kind of messages. The layers are built on top of each other like a stack and a layer can make use of the layers closest to it. It has to start the lower layers it wants to communicate with in order to make use of their services. Usually this could be done with a request start function that every protocol layer has. A more detailed description is made in . When this starting procedure is done the two layers has an interface between each other. Table 3-1 gives a presentation, which layers that register to each other. This starting procedure must be done before a connection can be accepted. PROTOCOL PROTOCOL LAYER THAT IS POSSIBLE TO START LAYER HCI Driver-GC Is the lowest layer, so it never will be starting other layers. L2CAP It will start the HCI layer and the SCM layer. SCM It will start the HCI layer. SDP It will start the L2CAP layer. RFCOMM It will start the L2CAP layer. Table 3-1 Presentation of which layer that starts each layer in the Bluetooth Host stack. L2CAP, which provides connection-oriented service to upper layer protocol, makes it possible for other layers to set up connections with L2CAP. The established connection then works a peer to peer connection. Peer to peer is direct communication between to identical layers at to separate Host stacks. There is also a possibility to send data peer to peer from the HCI, L2CAP and RFCOMM layers if a data buffer is allocated at the specific layer where you want to create a peer to peer connection. The advantage of using a peer to peer connection is that no data will be copied in the stack. This depends on that the only thing that passes through the stack is a pointer to the allocated memory, which the highest layer has allocated. The layers also have a Message library and a State library, which stores the current message and state. The State library implements a state machine, which can be used to call functions depending on the incoming message. Certain states can be set so the same message can be handled differently in different states. There are two types of messages that could be sent: command message and event message. Command messages are sent from a higher layer to a lower layer and an event message is sent in the other direction. A command message is a request message and an event message is an indication.
24 Bluetooth Stack Host Supporting Interfaces To make the Host environment support the stack, two interfaces have to be created. To read more about VOS and SIL see  Virtual Operative System (VOS) Since the stack is OS independent the VOS Interface will support the stack to run on different OS environment. The first thing that a programmer has to do is to port the stack into the Host environment. The stack is direct portable for the OSE environment, which means that the VOS service routines will be mapped directly or with small modifications. The VOS translates all calls and messages between two separate processes to support the current OS. The VOS Interface has rather common functions like allocating and freeing memory, sending and receiving messages, and administration of running processes Serial Interface Layer (SIL) The SIL is a communication interface between the HCI driver and the HCI firmware. They communicate via the serial port (RS232 or USB Driver) in the Host environment. The SIL consist of a few easy functions that open and close the connection between the HCI driver and the HCI firmware, and read and write from the serial link. 3.4 The Bluetooth Application Programmers Interface (BTAPI) The BTAPI is an interface that will make it easier to communicate with the Host stack. The interface will give access to the services that is provided by the protocol layers in the stack. The BTAPI enables the programmers to communicate with every single layer, i.e. HCI, L2CAP, SCM, RFCOMM and SDP. Every programmer is able to build an own BTAPI, but there is an ability to use the one that is distributed by Ericsson see  for more information. Ericsson s BTAPI is built to work with a Client, a Server and a Security application. The BTAPI will simplify the initialisation of the stack for the Client and Server. It will also take care of the connection set-up over RFCOMM, which is a rather complicated procedure. First the BTAPI will send a start request to the adapted layers (RFCOMM and SDP), that will start the stack i.e. register the layer to each other (see chapter 3.2). The BTAPI also communicates with the Message library and State library in the same way as protocol layers in the stack do. If the programmer wants to create an application that uses the Bluetooth profiles the BTAPI makes it easier for the programmer to register the profile (service) on the top of the RFCOMM layer.
25 Bluetooth Stack Bluetooth Application Example Bluetooth needs a Server and a Client-application to function as a communication system. The Security application makes it possible to have a single or multiple Bluetooth applications on a host. To get a slight idea we give a simple example of a Client/Server application and its functionallity. Picture that we want to send data from one computer to any Bluetooth device in your surrounding, this is how the major structures would look like. Client Initiate the Bluetooth stack. Perform device inquiry to find the Bluetooth devices nearby. Set-up an RFCOMM connection to the Server. Send/receive data. Disconnect the RFCOMM connection. Server Initiate the Bluetooth stack. Support the Client with information (data). Security Register to the stack being the Security manager. Take care of accepting a new ACL connection. Provide the stack with a fixed PIN-code on request.
26 Bluetooth Theory 18 4 Bluetooth Theory This chapter will give the needed theory about the structure of Bluetooth packets and HCI packet, see , . The chapter will also give the reader a deeper understanding about the used transport layer  and the Loopback function , . 4.1 Bluetooth Baseband Packets When defining packets and messages in the Baseband of Bluetooth, you are following the Little Endian format, which means that the least significant bit (LSB) will be the first bit sent over the air. The Baseband controller interprets the first bit arriving from a higher software layer as b0 (bit zero) and this is the first bit to be sent over air. The data on a piconet channel is conveyed in packets. Each packet consists of three entities: the access code, the header, and the payload. The format of a general packet is shown below in Figure 4.1.The number of bits in each entity is indicated in the picture. Both the access code and header are of fixed size while the payload can range from zero to a maximum of 2745 bits. Figure 4-1 Standard packet format Access Code All packets start with an access code. If a header follows the access code, the access code will be 72 bits long; otherwise it will be 68 bits long. The access code is used for synchronisation, DC offset compensation and identification. All packets exchanged on the channel of the piconet will be identified by the access code. Packets sent in the same piconet are preceded by the same channel access code. In the receiver of a Bluetooth unit, a sliding correlator correlates to the access code and triggers when a threshold is exceeded. This trigger signal is used to determine the receive timing. The access code is also used in the paging and inquiry procedures. In this case the header and payload are excluded in the packet. There are three different types of access code that are defined and they are: Channel Access Code (CAC) Device Access Code (DAC) Inquiry Access Code (IAC)
27 Bluetooth Theory The different types of access codes are used in different operating modes. The channel access code is included in all packets exchanged on the piconet channel. The device access code is used for special signalling procedures as paging and response of paging. The inquiry access code can be of two types. First there is a general inquiry access code (GIAC), which is common to all devices, and there is the dedicated inquiry access code (DIAC), which is common for a dedicated group of Bluetooth units that share a common characteristic. The inquiry access code is used to discover other Bluetooth unit in the range. The access code consists of a preamble, a sync word and a possible trailer, see Figure Figure 4-2 Access code format. The CAC consists of a preamble, sync word and a trailer. Its total length will then be 72 bits. The DAC and IAC do not always contain the trailer and will then have a total length of 68 bits. Preamble: The preamble is a fixed zero-one pattern of four symbols used to facilitate DC compensation. The sequence depends on the sync word that follows. If the sync word starts with 1 the sequence will be 1010 otherwise it will be Sync Word: The sync word is a 64-bit code word derived from a 24-bit address (Lower Address Parts). The used type of LAP is dependent of the type of access code of interest. For CAC the master s LAP is used. For the GIAC and the DIAC are the reserved respectively dedicated LAP s used and for the DAC is the slave unit LAP used. The construction guarantees large Hamming distance between sync word based on different LAP s. Trailer: The trailer is appended to the sync word when a packet header follows the access code. When CAC is used will this be the case, but the trailer is also used in DAC and IAC when these codes are used in FHS packets. The trailer is also a zero-one pattern of four symbols. Together with the three MSB s of the sync word the trailer forms a 7-bit pattern of alternating ones and zeroes which may be used for extended DC compensation. The trailer sequence is either 1010 or 0101 depending on whether the MSB of the sync word is 0 or 1.
28 Bluetooth Theory Packet Header The header contains Link Control (LC) information and consists of 6 fields shown below in Figure 4-3. Figure 4-3 Header format. The total number of bits in the header is accordingly 18, but the header is encoded with a rate 1/3 FEC that results in a 54-bit header. AM_ADDR: The AM_ADDR is the member address for the Bluetooth unit in a piconet and it is used to distinguish between active member participating on the piconet. In a piconet one or more slaves are connected to one single master. To identify each slave separately each slave will be allotted a temporary 3-bit address to use when it is active. When a slave is disconnected or placed in parked mode it will give up their AM_ADDR, and when it wants to get connected again it will get re-assigned. Type: There are 16 different types of packet that can be distinguished. The 4-bit TYPE code specifies which packet type that is used. The TYPE code depends on which physical link type that is associated with the packet. The type will tell you whether the packet is sent over an SCO link or an ACL link. When the link type is determined the type of SCO packet or ACL packet may be determined. The TYPE code also reveals how many slots the current packet will occupy. Flow: This bit is used to have flow control of packets over the ACL link. When the receiving buffer for the ACL link in the recipient is full and is not emptied, the bit will be set to 0 that indicates that the transmission is stopped temporary. These flag only concern the ACL link so the other types (ID, POLL, NULL and SCO packets) will not be affected. When the receiving buffer is empty an indication (FLOW=1) is returned. ARQN: This 1-bit is used to inform the source of a successful transfer of payload data with CRC. The bit will be set to 1 if it is a positive acknowledges (ACK) or 0 if it is a negative acknowledge (NAK). The ARQN is piggy-backed in the header of the return. The success of the reception is checked by means of a cyclic redundancy check (CRC) code. If no message is returned a NAK is assumed implicitly. SEQN: The SEQN bit provides a sequential numbering scheme to order the data packet stream. Every time a new transmitted packet contains data with CRC the SEQN bit will be inverted. This is required to filter out retransmissions at the destination so the destination won t receive the same packets twice. By comparing the SEQN of consecutive packets, correctly received retransmissions can be discarded.
29 Bluetooth Theory 21 HEC: Each header has a header-error-check to check the header integrity. The HEC consists of an 8-bit word generated by the polynomial 647 (octal representation). The first thing that happens is that the HEC will be initialised with an 8-bit value. Usually the upper address part (UAP) of the master device is used. The only packet type that does not use it is a FHS packet. The next step after initialisation is that the HEC will be calculated for the 10 header bits. The receiver must initialise the HEC check circuitry with the proper 8-bit UAP before it will check the HEC. If no check is done by HEC the entire packet will be disregarded Payload Format Two fields are distinguished in the payload and that is the voice field (synchronous) and the data field (asynchronous). The SCO packets only have the voice field and the ACL packets only have the data field. There are an exception and that is DV (Data Voice) packets, which have both types of fields. Voice Field: The lengths of the voice fields are fixed and for the HV (High quality Voice) packets the length is 240 bits and for the DV packets the length is 80 bits. There is no payload present. Data Field: The data field consists of three segments and that is the payload header, the payload body and possibly a CRC code. It is only the AUX1 packet that does not carry a CRC code. Payload Header: Only data fields have a payload header. The length of the payload is either one or two bytes. Packets in segments one and two have a 1- byte payload header and the packets in segments three and four have a 2-bytes payload header. The payload header specifies the logical channel, controls the flow on the logical channels and has a payload length indicator. The payload length indicator is 5 bits and 9 bits for the 1-byte (see Figure 4-4) and the 2- byte (see Figure 4-5) payload header, respectively. In case of a 2-byte payload header, four bits into the next byte extend the length indicator. The remaining four bits of second byte are reserved for future use and shall be set to zero. Figure 4-4 Payload header format for single-slot packets. Figure 4-5 Payload header format for multi-slot packets. In the payload the logical channel field are transmitted first and the length last.
30 Bluetooth Theory The L_CH code has four different contents of information. Code 00 is reserved for future use. Code 01 and 10 is used for L2CAP message. An L2CAP message can be fragmented into several packets and 10 is used for an L2CAP packet carrying the first fragment. Code 01 is used for the continuing fragments. If there is no fragmentation code 10 is used for every packet. Code 11 is used for LMP messages. The flow indicator in the payload is used to control the flow at the L2CAP level. It is used to control the flow per logical channel. FLOW=1 means that it is OK to send and FLOW=0 means stop. The link manager is responsible for setting and processing the flow bit in the payload header. 22 Payload Body: The payload body contains the user Host information and determines the effective user throughput. The length of the payload body is indicated in the length field of the payload header. CRC Code Generation: The CRC code is generated in a way similar to the HEC. The exception is that the code is generated by another polynomial (210041, with octal representation). Before determining the CRC code, an 8- bit value is used to initialised CRC generator. When the FHS packets sent in Master Page Response State is used will the CRC code initialised by the UAP of the slave. If the FHS packet has been sent in Inquiry Response State the DCI will be used to initialise the CRC code. For all other packets, the UAP of the master is used.
31 Bluetooth Theory Packet Types The types of packets used are related to the physical links they are used in. Two types of links are defined and that is SCO link and ACL link. For each of these links there are 12 different packet types defined. There are four control packets that is common to all link types. The 4-bit TYPE code is used to indicate the different packets on a link. There are four segments that the packet types are divided in. The first segment is reserved for the four control packets common to all physical link types. The other segments are containing packets that have various lengths of their time slots. The time slots are for the segments two to four: one, three and five time slots respectively. Common Packet Types: There is in addition to the four common control packets another common packet that is called ID. The ID packet is not listed in the first segment as the other common packets. ID Packet: The identity or ID packet has a fixed length of 68 bits and consists of the device access code (DAC) or inquiry access code (IAC). It is a very robust packet since the receiver uses a bit correlator to match the received packet to the known bit sequence of the ID packet. The packet is used, e.g. in paging, inquiry and response routines. NULL Packet: The NULL packet has a total fixed length of 126 when it doesn t have any payload and only consists of the channel access code and packet header. The NULL packet is used to return link information to the source regarding the success of the previous transmission, or the status of the receiving buffer, i.e. the NULL packet returns the ARQN bit or the FLOW bit. POLL Packet: The POLL packet does not have a payload and is very similar to the NULL packet. The difference is that the POLL packet requires a confirmation from the recipient. The POLL packet does not affect the ARQN and SEQN fields. The slave must respond the reception of a POLL packet with an implicit acknowledgement. The master in a piconet can use this packet to poll the slaves, even though the slave does not have the information that was asked for. FHS Packet: The FHS packet is a special control packet revealing, e.g. the Bluetooth device address and the clock of the sender. The FHS packet covers a single slot. The packet is used in Page Master Response, Inquiry Response and in Master Slave Switch.
32 Bluetooth Theory SCO Packets: SCO packets are used on the synchronous SCO link. The packets will never be retransmitted and do not include CRC. SCO packets are routed to the synchronous I/O (voice) port. Three pure SCO packets have been defined so far in the Bluetooth Specification. The SCO packet is typically used for 64 kb/s speech transmission. The SCO packet is defined as an asynchronous data field in addition to a synchronous (voice) field. The types of SCO packets are HV1, HV2, HV3 and DV packet. The DV packet is a combined data/voice packet. ACL Packets: ACL packets are used on the asynchronous links. It carries user data or control data. There are seven different types of ACL packets including the DM1 packet. Six of them include a CRC code and retransmission is applied if no acknowledgement of proper reception is received. It is just the AUX1 packet that does not include a CRC code and is therefor not retransmitted. 24 DM1: The DM1 packets are a part of the first segment in order to support control messages in any link type. There is one major difference between DM1 packets and the other common packets and that are that the DM1 packet also carries regular user data. DM stands for Data Medium rate. The DM1 packet may cover up to a single time slot and it contains up to 18 information bytes plus 16-bit CRC code. The packet is coded with a rate 2/3 FEC, which adds 5 parity bits to every 10-bit segment. If its necessary, extra zeros are appended after that the CRC bits to get the total number of bits equal a multiple of 10. In the DM1 packet the header is only 1 bit long. DH1: The DH1 packet is similar to DM1 packet, except that the information in the payload is not FEC encoded. This gives the opportunity to send up to 28 information bytes plus a 16-bit CRC code. DH stands for Data High rate. The packet may cover up to a single slot. DM3: This packet is a DM1 packet, except for the payload that is extended. The extended payload let the packet cover up to three time slots. The payload header is 2-bytes long and the payload contains up to 123 information bytes plus a 16-bit CRC code. When a DM3 packet is sent or received, the RF hop frequency shall not change for duration of three time slots. The channel access code is transmitted in the first time slot. DH3: The DH3 packet is similar to the DM3 packet. The difference is that the information in the payload will not be encoded with FEC. As a result of this, the DH3 packet can carry up to 185 information bytes plus a 16-bit CRC code. A DH3 packet may also cover three time slots, and when a DH3 packet is sent or received so will the hop frequency not change for duration of three time slots. DM5: The DM5 packet is a DM1 packet with an extended payload. The extended packet may cover up to five time slots. The payload header is 2-bit long and the payload contains up to 226 information bytes plus a 16-bit CRC code. When a DM5 packet is sent or received, the hop frequency shall not change for duration of five time slots.
33 Bluetooth Theory DH5: The DH5 packet is similar to the DM5 packet, except that the information in the payload is not FEC encoded. That means that the packet can carry up to 341 information bytes plus 16-bit CRC code. The DH5 packet will also cover five time slots and the hop frequency shall not change for duration of the time slots. AUX1: The AUX1 packet reminds of a DH1 packet but it has no CRC code. The packet can carry up to 30 information bytes. The AUX1 packet may cover up to a single time slot. 25
34 Bluetooth Theory HCI Transport Layer There are three types of transport layers that can be used to communicate between the HCI Driver and the HCI Firmware. They are USB, UART and RS232. The main goal with the transport layer is transparency. The Host Controller Driver should not care whether it is running over USB or UART. It is possible to modify the transport layer to change between the different types of media. In our specific task the HCI UART Transport Layer will be used. The HCI USB Transport Layer would be the most favourable transport layer since it is faster then the other transport layers but unfortunately is the OSE operative system not compatible to USB HCI UART Transport Layer In the HCI UART transport layer four types of HCI packets are allowed. They are HCI Command Packet, HCI ACL Data packet, HCI SCO Data packet and HCI Event packet. Those four packets will all have a HCI packet indicator, the indicator is 1-byte long. The HCI does not provide the ability to differentiate the four HCI packet types. By this cause the packet indicator is added to the HCI packet. The packet indicator is sent right before the HCI packet. A packet indicator is always expected to come before next HCI packet receives. Over the UART Transport Layer, only HCI packet indicators followed by HCI packets are allowed. The settings for the serial port in the HCI UART Transport Layer are shown below in Table 4-1. Baud rate manufacturer-specific Number of data bits 8 Parity bit no parity Stop bit 1 stop bit Flow control RTS/CTS Flow-off response time 3 ms Table 4-1 Serial port settings in the HCI UART Transport Layer. Flow control with RTS/CTS (Request To Send/Clear To Send) is used to prevent temporary UART buffer overrun. The HCI has its own flow control mechanisms for HCI commands, HCI events and HCI data, thus the UART flow control is not supposed to be used for the HCI flow control. When CTS is set to 1 or 0 is the Host/Host Controller allowed sending respectively not allowed to send. The flow-off response time defines the maximum time from setting RTS to 0 until the byte flow actually stops. When the Host or the Host Controller loses synchronisation in the communication over RS232 a reset is needed. A loss of synchronisation means that an incorrect HCI packet has been detected, or that the length field in an HCI packet is out of range. When the UART synchronisation is lost from Host to Host Controller, the Host Controller should send a Hardware Error Event to the Host to make him attentive of the synchronisation error. The Host Controller is then expecting to receive an HCI Reset command from the Host in order to perform a reset.
35 Bluetooth Theory If the UART synchronisation is lost from the Host Controller to the Host instead, the Host will send a HCI Reset command in order to reset the Host Controller. The Host shall then re-synchronise by looking for the HCI Command Complete event. 4.3 HCI Packets The communication between the HCI Driver and the HCI Firmware is done with HCI packets. There are four different kinds of packets that can be sent via the UART Transport Layer. The packets are shown in Table 4-2 below. HCI PACKET TYPE HCI PACKET INDICATOR HCI Command Packet 0x01 HCI ACL Data Packet 0x02 HCI SCO Data Packet 0x03 HCI Event Packet 0x04 Table 4-2 HCI packet indicators. HCI Command Packets can only be sent to the Bluetooth Host Controller, HCI Event Packets can only be sent from the Bluetooth Host Controller and HCI ACL/SCO Data Packets can be sent in both directions HCI Command Packet The HCI provides a uniform command method of accessing the Bluetooth hardware capabilities. The Host Controller & Baseband, Informational and Status commands provide the Host access to various registers in the Host Controller. The HCI Policy commands are used to affect the behaviour of the local and remote Link Manager. The HCI Link commands provide the Host with the ability to control the link layer connections to other Bluetooth devices. The HCI Command Packet is used to send commands to the Host Controller from the Host. The results of the HCI commands will be reported back to the Host in form of an event so that no problems will occur when the commands take different amounts of time to be completed. The Host Controller will e.g. generate the Command Complete event when a command is completed for most of the HCI commands. The commands that do not receive a Command Complete event when the command is completed will instead receive a Command Status event when the Host Controller has begun to execute the command. If something goes wrong the Command Status event will return an appropriate error code in the Status parameter. The Host is able to send at a maximum of one HCI Command Packet until a Command Complete or Command Status event has been received, when a initial power-on or a reset has been done. 27
36 Bluetooth Theory The Host Controller must be able to accept HCI Command Packets with up to 255 bytes of data excluding the HCI Command Packet header. Each command is assigned a 2 byte Opcode used to uniquely identify different types of commands. The Opcode is then separated in two fields that are called Opcode Group Field (OGF) and Opcode Command Field (OCF). The first 6 bits of the Opcode contains the OGF and the last 10 bits belong to the OCF, see Figure Figure 4-6 HCI Command Packet. The six types of HCI commands will be introduced below. Link Control Commands: The Link Control commands allow the Host Controller to control connections to other Bluetooth devices. The Link Manager (LM) controls how the Bluetooth piconets and scatternets are established and maintained, and to that LM uses the Link Control commands. These commands instruct the LM to create and modify link layer connections with Bluetooth remote devices, perform inquiries of other Bluetooth devices in range and do other LMP commands. The OGF is defined as 0x01. Link Policy Commands: The Link Policy commands provide methods for the Host to affect how the Link Manager manages the piconet. When Link Policy commands are used, the LM still controls how the Bluetooth piconets and scatternets are established and maintained, depending on adjustable policy parameters. These policy commands modify the Link Manager behaviour that can result in changes to the link layer connections with Bluetooth remote devices. The OGF is defined as 0x02. Host Controller and Baseband Commands: The Host Controller and Baseband commands provide access and control to various capabilities of the Bluetooth hardware. These parameters provide control of the Bluetooth devices and of the capabilities of the Host Controller, Link Manager and Baseband. The Host device can use these commands to modify the behaviour of the local device. The OGF is defined as 0x03. Informational Parameters: The manufacturer of the Bluetooth hardware fixes the Informational parameters. The Host device cannot modify any of these parameters. These parameters provide information about the Bluetooth device and the capabilities of the Host Controller, Link Manager and Baseband. The OGF is defined as 0x04.
37 Bluetooth Theory Status Parameters: The Host Controller modifies all Status parameters. The Host device cannot modify any of these parameters. The Status parameters provide information about the current state of the Host Controller, Link Manager and Baseband. The OGF is defined as 0x05. Testing Commands: The Testing commands are used to provide the ability to test various functionalities of the Bluetooth hardware. These commands provide the ability to arrange various conditions for testing. For further information about the specific test mode Loopback see chapter 4.4. The OGF is defined as 0x HCI Event Packet An event is a mechanism that the HCI uses to notify the Host for command completion, link layer status changes and more. The HCI Event Packet is used by the Host Controller to notify the Host when events occur. An HCI Event Packet can be up to 255 bytes long excluding the HCI Event Packet header, so the Host must be able to accept event packets that is that long. The first byte in the HCI Event Packet is occupied by the Event code. The Event code is used to uniquely identify different types of events. The HCI Event packet is illustrated below in Figure Figure 4-7 HCI Event Packet.
38 Bluetooth Theory HCI Data Packets When the Host and the Host Controller is exchanging data between each other are they using HCI Data Packets. The data packets are defined for both ACL and SCO data types. The packets do not have the same format, see Figure 4-8 and Figure 4-9. The formats are shown below. Figure 4-8 ACL Data Packet. Figure 4-9 SCO Data Packet. The Connection Handle occupies the first 12 bites in both packets. The Connection Handle is an identifier that is used to uniquely address a data/voice connection from one Bluetooth device to another. The Connection Handle is maintained for the lifetime of a connection.
39 Bluetooth Theory Loopback The theory and functionality around the Loopback Test Mode has been put together from ,  and . The function HCI_ReqWriteLoopbackMode will change the value for the setting of the Host Controllers Loopback Mode. The settings will then determine the path of information, see Loopback data path in Figure 4-10 and Figure It is possible to choose HCI_LOOPBACK_NONE, HCI_LOOPBACK_LOCAL or HCI_LOOPBACK_REMOTE. Local Loopback mode means that you set a flag in the Host Bluetooth device, HCI sends the commands down to the firmware in the local device and the device simply returns an event that declares that the command came through. If a package was sent the firmware returns the package unmodified. Figure 4-10 Local Loopback Mode. Any Bluetooth device put in Remote Loopback mode returns the commands to the Local Bluetooth device. This of course requires two Bluetooth devices and a given address to the device. Set the remote device in Remote Loopback mode and make the host create the ACL/SCO connection, the packages sent via HCI reaches the remote Bluetooth device and returns it to the host device without being manipulated. Figure 4-11 Remote Loopback Mode.
40 Bluetooth Application Tool Kit 32 5 Bluetooth Application Tool Kit We have been using parts of Ericsson s Bluetooth Application Tool Kit, a Bluetooth hardware device and a manual for Bluetooth applications. The software for this tool kit is only supported on a PC Host computer; therefore we have used an OSE ported Host stack. The hardware of the Bluetooth kit is described below and in . Key Features Pre-qualified Bluetooth 1.0B Module RF output power class 2 FCC and ETSI approved 460 kb/s max data rate over UART Multiple interface for different applications -UART for data -PCM for voice -USB for voice and data I 2 C interface Internal crystal oscillator HCI firmware included Multi Point Operation Built-in shielding Suggested Applications Computers and peripherals Handheld devices and accessories Access points 1. Bluetooth module 2. Reset button 3. USB port power supply 4. Jumper area 5. On board inverted-f antenna 6. UART-connector Figure 5-1 The Tool Kit circuit board.
41 Bluetooth Application Tool Kit To make easy access possible to certain signals, a jumper area is included on the Tool Kit. The pin configuration for the jumper area is listed in the table below. Note that pin 1 is at the edge of the board next to the reset button. 2 PCM_CLK 4 PCM_SYNK 6 VCC 3.3V 8 DETACH 10 GROUND 1 Vin 5V nom 3 WAKE_UP 5 PCM_OUT 7 PCM_IN 9 RESET OSE operative system does not support USB so we only use it for power supply for the Bluetooth device. Instead we use the UART and connect it to the UARTconnector on the device. The software supplied by Ericsson helps the user to understand the wonders about Bluetooth programming. The two Bluetooth applications supplied by Ericsson are Testsample application and a Chat application. The Testsample application is a straightforward Bluetooth application written in C-code. This application uses the profile Headset (see Appendix A) it creates therefore an SCO connection and sends small and big headset data packets from the client to the server. Finally it disconnects and counts the succeeded connections and inquiry s made. The Chat program on the other hand is written in C++ code and uses a graphical interface. You perform an inquiry and select the Bluetooth device that you want to exchange information with and create a connection to it. There is a chat window where you type the message that you want to send to the receiving side. 33
42 OSE A RealTime Operative System 34 6 OSE A RealTime Operative System All the theory in this chapter is put together from  and . This is a short and brief introduction to OSE. It will give you the fundamentals so that you understand how it affects an application implemented on the soft kernel of OSE. OSE is a real-time embedded system that satisfies all the requirements a programmer can ask for in a RTOS (Real Time Operating System). A RTOS should take care of problems like non-stop operations and distributions over many CPUs and have all the sufficient tools and functionality that is needed to develop these kinds of systems. OSE is designed to support all of these requirements. The OSE supports non-stop real-time systems and allows recovery from hardware and software failures. It will also support fully distributed system and dynamic reconfiguration of hardware and software during run-time. OSE Kernel is distributed as an OSE Soft Kernel so the programmer can run his OSE Kernel process on the Host, e.g. Windows 95/98/NT Host, Solaris Host or Linux Host. The OSE Soft Kernel can simulate a single CPU system or a fully distributed and fault tolerant system. The main use of the OSE Soft Kernel is to test the application in the Host environment (see Figure 6-1) before moving it to target hardware, e.g. Power PC. When the programmer need to run his applications on the target he has to use different BSP (Board Support Package) for the specific target. The programmer can simulate a distributed system when two or more Soft Kernels are executed. Figure 6-1 As a Host process itself, the Soft Kernel allows OSE processes to execute under simulated kernel conditions. The Bluetooth Host stack is ported to a numbers of environments, which includes a few hardware targets and as well as a few OSE Soft Kernel environments. 6.1 Ease of use The number of system calls in an OSE design is drastically reduced compared to other operating system. This has been achieved by making many functions automatic. Since all programmers uses the same limited set of tools, it is easier to understand, correct or modify programs written by others % of the processes in a system needs 6 or fewer system calls. Additional functions are available for designs of distributed systems and for processor specific functions. Processor specific functions are used either when hardware must be used to realise the system or to obtain very high performance. The six basic calls are shown in Table 6-1.
43 OSE A RealTime Operative System 35 SYSTEM CALL EXPLANATION Alloc allocate memory Free_buff return allocated memory to Operative System Send send a message to a process Receive receive selected messages, sleep if no selected messages are available Recieve_w_tmo like receive, but wake up again after a specified time if message is available Delay sleep for a specified time Table 6-1 The six basic calls in OSE. 6.2 Higher performance OSE is exclusively to fit the features of each processor supported. Every conceivable effort has been made to ensure that OSE is as fast as possible. The entire system is written in heavily optimised assembler. The data structures are designed to fit the processor memory structure and the specific system calls. Tasks that traditionally have been left to the user to accomplish as best as he can, have been taken over by the executive. These tasks are included in the system call timings. OSE can be tailored to a specific application when configuring the operating system. For example in another project, you decide on another configuration, all modules written for the old configuration are completely compatible in the new system, but they assume the characteristics of the new system i.e. they are smaller, faster or whatever you have selected. A major reason for the high performance of the OSE operating system is that a signal-based operating system lends itself to very efficient implementation. This fact has been utilised to its fullest extent. 6.3 Kernel The kernel is the stumbling block of an operating system. It is the part that contains all the mechanisms that are necessary to distribute the CPU to several different processes. The kernel also contain the mechanisms that are needed to make the system calls work. 6.4 Memory management The amount of code memory and data memory needed in your system is determined by system configuration and design. In OSE the memory area is called a pool. The signal buffers, stacks and kernel area will be allocated in the pool. There are two common types of memory pools, system pool and local pool. The OSE system always has to have one "global" pool that is called the system pool. The system designer may also want to create "local" pools, which reside in the same memory space as the process they support. The first pool that will be created in a system is the system pool. There are two things that make the system pool special and that is; its existence is crucial to the kernel and it must always be located in the kernel memory. It is quite possible to let all processes allocate what they need from the system pool. There is one disadvantage. When the system pool is corrupted the whole system will crash.
44 OSE A RealTime Operative System Processes A Real Time System is made up of several sub-programs, processes, which is executed separately by it self and independently from other processes. You define your own processes with a priority number and they will automatically run on the operating system. A process running under a real-time operating system can find itself in one of three distinctly different states, running, ready and waiting. Running means that the process is the one currently in control of the CPU. In a single processor system, only one process can be in this state at a time. The ready state means that the processes needs the CPU but will be running as soon as it is permitted to. All processes ready to run are placed in a ready queue. Each process priority level has its own ready queue. Other processes might be in a waiting state because they are i.e. waiting to receive a signal or to let a delay expire. By sending signals from one process to another it is possible to communicate and send data between different processes. It is always possible during run time to create and remove processes and create new connections. There are different categories of processes that are carefully designed so that they fulfil every possible need in a system Static process In small and medium-sized systems, the static process category is the most commonly used. Static processes are created at system start by the kernel, or by the interface library if the static processes reside in separately linked software unit. These processes are supposed to exist at all times i.e. for the lifetime of the system. It is not allowed for any process to kill a static process. It may only be killed if it is a part of separately linked and loaded software unit, and only as a part of an operation that kills all processes in that unit Dynamic processes Opposite of static processes, dynamic processes can be created and killed freely during run-time. If other processes than the creator of the process needs to communicate with the dynamic process, they can communicate with the creator to obtain the new process ID. Other processes may also obtain the process ID from the dynamic process itself. Dynamic processes can also be used to preserve stack space, since stack space is only used while the processes exist Interrupt processes Interrupt processes are called in response to hardware or a software event and will run from the beginning to the end each time, provided that no other process with higher priority is called. The interrupt with lower priority will continue again when the process with higher priority has finished its task. The process is written as a subroutine that means that an interrupt process can be interrupted by another interrupt process Timer interrupt processes These processes act exactly the same way as interrupt processes except that they are called in response to changes in the system timer. For example, a system designer can specify that a certain timer-interrupt process is to run with one-second intervals. Timer interrupts are also called in order of priority.
45 OSE A RealTime Operative System Prioritised processes Prioritised process is the most common process type. They are written as infinite loops that will run as long as no interrupts process or another prioritised process with a higher priority is ready to run. A process can wait for one or more specified signals to arrive. If none of them are present in its queue the process is swapped out and another process is allowed to run Background processes Background processes run in a strict time sharing mode at a priority level below prioritised processes. They are also written as infinite loops in the same manner as prioritised processes. The time slice mechanism in background processes is used to distribute leftover CPU power in certain specified amounts of time between a number of processes. When a background process has consumed its time slice it will be preempted and put at the end of the ready queue Phantom processes Phantom processes do not contain any executable code and is therefore unable to receive any signals. If a signal set to a phantom process not is redirected by a redirection table, it will be lost and the memory space it occupies will be freed. Phantom processes are mainly used in conjunction with a redirection table and form part of a logical channel for communication across target boundaries. 6.6 Block and block processes In OSE, you are able to group your processes together into a block. A block of processes may have their own memory pool, or they can allocate memory from the global system pool. When a pool is corrupted it will only affect the block, which is connected to that pool and the processes in those blocks. Processes in other blocks will continue as normal, as long as they do not depend on some process that is included in the corrupted pool. The creator of a new process has the possibility to choose where the new process should be placed. Usually a created process will be placed in the same block as the creators process. It is convenient to look at the processes in a block as one homogenous process because many system calls that operate on a single process also work on the entire block. It is e.g. possible to start or kill all processes in a block with one single system call. Grouping processes into block makes it easier to get a better system structure. It is especially useful in larger and more complex systems. 37
46 OSE A RealTime Operative System Signals In a Real Time Operative System it is not recommended to use global variables (i.e. variables used by more than one process). If processes use global variables or buffers, there will be access problems. This problem may occur when one process has accessed the first bit of such variable and a change of processes occurs before the next bit is accessed. While the process is swapped out, some other process may change the variable or buffer. Therefore the result of global variables is unpredictable. In OSE also global variables will make it impossible to use the powerful debugging tools that are available. One way of communicating or synchronising between processes instead is to use signals. A signal is a message that is sent from one process to another. Before the process wants to send a signal to another process it has to get knowledge of the receiving process identity. Static processes can be declared as public so other processes are able to communicate with it. The communicating process has to declare the static process as external and will then obtain the process identity. Dynamic processes are given the identity when they are created and any other process that wants to communicate with the dynamic process must determine the destination process identity. When a process other then the creator wants to communicate with a dynamic process it will determine the process identity by communicate with its creator. The user of a signal has to allocate a memory buffer for the signal from the memory pool before it can send the signal. If the user has received a signal it will also be possible to use the buffer from the received signal if the buffer size is large enough. The buffer will contain the signal number (signal type) and any data that will be sent. All signals have some hidden information as attributes associated with them: these are signal owner, size, sender and address. System calls can examine these attributes and they can also be changed by certain system calls, e.g. the send system call will change the owner of the signal buffer from the sending process to the receiving process. It will also set the sender and address attributes of the signal. When a process gains access to a buffer either by allocating or receiving it, the process becomes owner of the buffer. It is only the owner that may perform operations on the buffer. When the signal has been sent to another process the sending process can no longer access it. This is done to eliminate conflicts. A process may specify what kind of signals it is interested in receiving at any particular moment. All signal numbers are placed in an array, that the receiving process can check for the interesting signal. The process can also wait for the specified signal to arrive without checking the signal queue. The signals that are not of interest for the moment will be left in the signal queue. If a certain signal is not in the signal queue and the process wants to wait for its arrival, execution will switch to another process. A process can also be interested in all kinds of signals, thus receive any signal in its signal queue. If a process with high priority is waiting for a signal and a process with lower priority sends that signal, the sending process is immediately pre-empted and the process with higher priority receiving the signal will start to execute.
47 OSE A RealTime Operative System 6.8 Designing a system The first step in the design process is to divide the system into a number of processes. Separate processes must handle concurrent events. If two events occur at the same time, different processes must handle them. In a terminal, for example, the operator may be typing at the keyboard while the host computer sends the characters to the terminal. In the work division between processes, one important consideration is to minimise the interface between processes; they should have as little as possible to do with each other. Another design consideration is to avoid very small and very large processes. It also desirable not to have processes share hardware. When the system is designed, the processes are written either in a high-level language or assembler. When writing in C or assembler, we suggest that you use the process templates designed. Each process is put in a separate file, and these are compiled or assembled as required. It is now time to use OSE simulator (if you have access to it) to verify that the processes work as specified. This step should eliminate most bugs on the source level, such as wild pointers, incorrect if statements etc. It is possible that errors are made in the system design, in the writing of the processes, in the configuration of the operating system or in the linking commands. If this is the case, the errors must be detected and located during runtime. The OSE simulator and debugger are very useful when trying to find these errors. 6.9 Building a system This section describes how to create a system using OSE. It discusses major design parameters such as memory usage, speed factors and interrupts. It also illustrates various phases of programming, from getting started to catching the last bug, see Table 6-2. THE SYSTEM BUILDING PROCESS: 1. Determine the specifications of the system, such as functions, speed requirement, environment etc (Do not take speed requirements too lightly.). 2. Design the system; i.e. determine hardware configuration or soft-kernel configurations, memory usage, interrupt structure, processes and process interface. 3. Configure the system, that is, enter configuration data into the configuration file. 4. Run the configuration program 5. Write the process and compile or assemble them as needed. 6. Assemble the source file generated by the configuration program. 7. Link the system. 8. Burn PROM, load the emulator, or load the target system. 9. Test and debug until specifications are realised. You may have to iterate steps 1 9 several times. Table 6-2 The system building process. 39
48 OSE A RealTime Operative System Debugging Once a program is written, it is similar to debug when OSE is used since OSE s debugging tools are specifically designed to detect real-time problems in the interaction between many programs. Breakpoints can then be set on system events. Break points can be set on a specific signal, sent from a specific process with a specific signal content. A system trace gives the ability to examine events that led to a crash after the crash occurred. The system display gives you a quick overview of the behaviour of the total system, instead of looking through hundreds of pages of code. In order to utilise these debugging tools to the fullest extent, you should ensure that all process communication is handled by signals. A debugging session can be run from a terminal, a Host machine or via a network. In addition, software in the debugged system can also issue commands to the debugger at system start Error handling The error handlers are subroutines, which are activated in response to some erroneous event at run-time. They will simply return the error code so that it is easy to find the error. The error handler is called either explicitly by a process in the application or by the kernel when a user error is detected, depending on whom discovered the error. OSE has three different levels of error handlers, process error handler, block error handler and kernel error handler Process error handler If there is a process error handler present for the process where the error was detected, that error handler is called first. If it returns a flag saying that it could not handle the error, then the error is propagated to the next level, which is the block error handler level. Otherwise the kernel resumes execution in the user code and the process can continue. Errors considered as fatal by OSE are always propagated to the next level Block error handler The block error handler is called if there is no process error handler for the process where the error occurred, or if the process error handler returned an error flag. The block error handler may then be able to resolve the situation in exactly the same manner as on the previous process error handler level Kernel error handler The kernel error handler is a user specified part of the kernel and is configured into the kernel when the kernel is generated. This handler is called if no other error handler is present, if a reported error is fatal or if previous levels could not resolve the situation.
49 OSE A RealTime Operative System Error vs. Warnings Fatal errors include all situations where kernel data has been damaged. In all cases of fatal error only the kernel error handler is called. This is done with interrupts disabled, so no system calls may be issued from within the error handler. The kernel error handler is at this time responsible for restarting the system. If the error handler issues a return statement, the kernel enters an infinite loop, which can be exited only by hardware reset. Warnings on the other hand includes situations where data areas in user space have been damaged, where a memory pool has been exhausted or when an illegal parameter was passed to system call. Note however that many warnings are fatal for all processes in the involved address space, since a damaged data area can never be guaranteed not to affect another process operating in the same unprotected memory area. When a warning is detected, the process or block error handler is called only if this would not affect the system s safety. Otherwise only the kernel error handler will be called.
50 Analyse 42 7 Analyse 7.1 Using the Ericsson Bluetooth Application Tool Kit When you purchase the Bluetooth Application Tool Kit, Ericsson supplies two Bluetooth program examples that will increase the understanding and get you started with Bluetooth. It was a good thing to review the Testsample application since it is similar to the one that we intended to write, see chapter 5. The program does an inquiry and connects to the chosen Bluetooth device. It creates a SCO connection and starts to send headset data and then disconnect. The course of events in the Bluetooth Testsample is pretty much the basics within Bluetooth. By tracing the program step by step it was easier to get a deeper understanding of the Bluetooth Host Stack and how the data communication worked. How the stack works is not really relevant to the programmer, it is only of interest to know the interface (commands) to use towards the stack. 7.2 Examination of the Loopback Function Enea s product management group wanted to deliver a testing tool for Bluetooth applications so that the customer could test and evaluate their applications without using Bluetooth devices. Our task was to investigate whether it is possible to make use of the Loopback function to create this testing tool. The product management group took for granted that the Loopback function was an opening in the Bluetooth Host stack and that this made it possible to manipulate the data coming through the Loopback function. The Bluetooth specification does not document too much about the Loopback function and there was no one that could answer the questions we have had. Because of this it has been a long procedure to find out the functionality of the Loopback function. Loopback is not a function and does not perform the way that the product management group thought, see Bluetooth Theory chapter It is simply a flag that is set in the Bluetooth hardware that indicates which way the commands are routed (see Loopback data path Figure 4-10). If the flag is set to Local Loopback mode HCI sends the commands down to the firmware in the local Bluetooth device and the device simply returns an event that declares that the command came through. If a package was sent the firmware returns the package unmodified. This means that a Bluetooth device is still needed in order to use the Local Loopback mode. It is possible to manipulate the data and create the wanted filter but it seems unnecessary since most of the packets are coded. The header is coded with HEC code (Header Error Check) and the payload is coded with a 16-bit CRC error check, at least the HEC checks must be right for a packet reception to be successful. If an error is indicated the packet is being retransmitted.
51 Analyse Figure 7-1 shows a possible course of events when using Local Loopback mode. It is not possible to implement it in any application, it must be adapted to the local Loopback mode behaviour. After implementing the Local Loopback in our application and the HCI-commands were sent the program crashed and it did not work properly. The Bluetooth device was set in Remote Loopback mode but it acted the same way and it could not get a hold of the remote Bluetooth device. After contacting Ericsson about the Remote Loopback mode they claimed that it did not work properly. 43 Figure 7-1 Flowchart of the Local Loopback mode. We have done a few tests with Local Loopback in order to appoint that Loopback does not fulfil our demands. If you put the device in Local Loopback mode you will be able to test different commands but you can only test one side e.g. the Client side. Thus, the Loopback mode is only to test the Bluetooth device or communication between devices only.
52 Analyse Setting up the Bluetooth System in the OSE Environment We to implemented the Client/Server application on Enea Data s own realtime operative system. The operative system makes it easy to create different processes that communicates with each other in a system, see chapter 6.5. This is the wanted characteristics since the function packet reader and the stack consists of quite a few processes that needs to communicate with each other to make a functioning system. It is possible to implement OSE on different processors, we choose between using a PowerPC or a Personal Computer. The PowerPC is very expensive and every time you compile the program you have to download the new application to the processor. It is therefore faster and easier to get started with OSE when using the softkernel on a personal computer. Our computer uses two separate operating systems, Microsoft Windows and Red Hat Linux. Therefore we had to choose whether we should run the OSE softkernel on top of Linux or Windows. Most of the people in our office uses Linux and they could easily give us support on this environment but since the Bluetooth Host stack was not ported to Linux we simply had to choose Windows. There were two options when we compiled our system; one was to use make files and the other one was to create a workspace in MSVC. Using MSVC will give the user a higher understanding of Bluetooth because of the excellent tracing possibilities, but in order to create a workspace in MSVC using the soft kernel you need to include a number of OSE configuration files, OSE source files, OSE libraries and plenty of predefines. The first time you create a working OSE environment it takes lots of time and effort. Therefore we decided to use make files instead, see chapter
53 Analyse Application Choice of Application Layer The Client/Server application is implemented on top of the RFCOMM layer to get good overview of the Bluetooth stack since it is the highest layer in the stack. The RFCOMM layer also supports ACL connection, which is great since we intend to send data, see chapter The last aspect is that Ericsson s BTAPI supports and have a nice interface towards the RFCOMM layer which makes it easier to initiate, start and connect the stack. The main purpose of the Serial port profile (see chapter ) is to emulate the serial port on the destination computer but since it is written to be implemented on top of the RFCOMM layer and supports our needs this profile was chosen Make and User Configuration file One way to make it easier to compile and test a written program with multiple source files is to use a makefile. A makefile is a textfile that includes all compiler commands and other predefines that is needed to make a program running. The makefile will then create object files that will be linked together to an executable program. Enea Data AB has made a makefile that is specially written for programming in an OSE environment and this is also the makefile we are using to make our Bluetooth program running in the OSE environment. The makefile is built after a special file structure that has to be followed to get the wanted functionality. The file will link the program to a user configuration file that will set all specific settings for the program. This file sets which compiler your are about to use and which target you will run your program on. It will also set the BSP for the specific Kernel you are about to use. Then there are a lot of other settings that can be used for other specific scenarios. In our case we will be using different settings for the Bluetooth stack. The file will configure the whole OSE environment for the program. For more information about makefiles see .
54 Analyse Client/Server Application This chapter describes in an easy way what has to be done to create our Client/Server application. The flow charts below tell exactly what is happening in each application. See Appendix F to view the total flowchart of one cycle (Initiation, discovery, connection, sending data and disconnection). For details about the function calls in the Client and the Server see Appendix A and Appendix B, respectively. All the function calls from the BT_API are listed in AppendixD. Initation for the Client: First of all the Client needs to enable communication via the serial port to the Bluetooth device. The initiation of the serial port is done by calling the function HCI_ReqConfigurePort(). Instead of doing things like starting every singel layer from the Client you simply call the function BT_API_Start() (tailor made for your specific whishes) and it starts all the wanted layers for you (SD_ReqStart() implicity starts the lower layers). Last thing done is to write the characteristics as encryption, authentication and timeouts for the Client. See flowchart in Figure 7-2. STACK LIB INITIATION BT_API SCM_ReqStart() SCM_START_CNF SCM_ReqRegister() SCM_REGISTER_CNF SCM_SECURITY_HANDLER BT_API_Init() HCI_ReqConfigurePort() HCI_CONFIGURE_PORT_CNF SD_ReqStart() BT_API_Start() SD_START_CNF SDS_ReqStart() SDS_START_CNF COM_ReqStart() COM_START_CNF SCM_ReqRegister() SCM_REGISTER_CNF SCM_MONITOR_GROUP HCI_ReqWriteCod() BT_API_InitStackForServer() HCI_WRITE_COD_CNF HCI_ReqWriteName() HCI_WRITE_NAME_CNF HCI_ReqWriteScanEnable() HCI_WRITE_SCAN_ENABLE_CNF DBM_ReqRegisterService() PROFILE_SerialPort() COM_REGISTER_CNF COM_ReqFillPdl() COM_FILL_PDL_CNF BT_API_RegisterProfile() SERVER SECURITY Figure 7-3 Flowchart for the initiation stage in the Server application. Client BT_API BT_API_Init() HCI_ReqConfigurePort() HCI_CONFIGURE_PORT_CNF BT_API_Start() SD_ReqStart() SD_START_CNF SDS_ReqStart() SDS_START_CNF COM _ReqStart() COM_START_CNF SCM_ReqRegister() SCM_MONITOR_GROUP SCM_REGISTER_CNF BT_API_InitStackForClient() HCI_ReqWriteEncryptionMode() HCI_WRITE_ENCRYPTION_MODE_CNF HCI_ReqWriteAuthenticationMode() HCI_WRITE_AUTHENTICATION_MODE_CNF HCI_ReqWriteConnectTimeout() HCI_WRITE_CONNECT_TIMEOUT_CNF HCI_ReqWritePageTimeout() HCI_WRITE_PAGE_TIMEOUT_CNF STACK LIB INITIATION Figure 7-2 Flowchart for the initiation stage in the Client application. Initiation for the Server: If you want to run a Host as a Server you have to have a Security application that control all Security problems that may come up. The Security application is a rather simple process that starts the SCM layer and then sets itself to Security Handler. The process can then handle problems like PIN code (if the user wants to have one) and to authorise incoming connection requests from adjacent Clients by. The Security process will be started before the Server will be running. The Security application we are using is an application that Ericsson has made for their Bluetooth Application Tool Kit.
55 Analyse 47 The Server process starts with initiating the BTAPI so it will be able to communicate with it. The next step is to configure the serial port with the design parameters the HCI Transport Layer inquiry (see chapter 4.2). After a successful configuration the Server call the BT_API_Start to start all the stack layers with calling the functions SD_ReqStart, SDS_ReqStart and COM_ReqStart that will implicitly starts all the lower layer in the stack. To make the Server process able to communicate with other devices it has to register to the SCM as SCM_MONITOR_GROUP, which means that the application will be notified when links are created or destroyed. Then the Server is ready to initiate itself as a Server to the stack (see Appendix B). The next step is to select a suitable Bluetooth profile for the application and initiate it to the DBM. In our case were we wanted a minimal and simple Client/Server application the Serial port profile was the most suitable (see chapter 2.2). See flowchart in Figure 7-3. STACK Client BT_API BT_API SERVER LIB HCI_ReqInquiry() HCI_INQUIRY_EVT HCI_INQUIRY_EVT HCI_INQUIRY_CNF BT_API_ConnectRfcomm() SCM_ReqConnect() SCM_CONNECT_CNF SD_ReqConnect() SD_CONNECT_CNF SD_ServiceSearch() SD_SERVICE_SEARCH_CNF SD_ServiceAttribute() SD_SERVICE_ATTRBUT_CNF DBM_ReqRegisterService() DBM_REGISTER_SERVICE_CNF DBM_ReqAddDescriptor() DBM_ADD_DESCRIPTOR_CNF SD_ReqDisconnect() SD_DISCONNECT_CNF COM_ReqConnect() COM_CONNECT_CNF DISCOVERY DATA CONNECT SCM_CONNECT_EVT COM_PARAMETER_NEGOTIATION_IND COM_RspParameterNegotiation() COM_CONNECT _IND COM_RspConnect() Figure 7-4 Flowchart of the device discovery and data connection for both Server and Client application. Device Discovery and Data Connection (Client side): To find the destination Bluetooth device you make a inquiry for the specific Bluetooth device by calling the function HCI_ReqInquiry(). All the layers are started and a connection is set up by the function BT_API_ConnectRfcomm(), see flowchart in Figure 7-4. SCM_ReqConnect() implicate connects all the layers and create the connection. Device Discovery and Data Connection (Server side): When the initiation is done the Server will wait for other Bluetooth devices to do an inquiry. The Security application will control all incoming inquires and accept them if they fit our Server application. Then the Server will get an indication from the stack and will then be ready to receive data from the connected Client.
56 Analyse 48 STACK Client BT_API BT_API SERVER LIB COM_DataAlloc() COM_DataSend() send the message COM_DATA_CNF COM_ReqDisconnect() COM_DISCONNECT_CNF SCM_ReqDisconnect() SCM_DISCONNECT_CNF DBM_ReqUnRegisterService() DBM_UNREGISTER_SERVICE_CNF SEND DATA DISCONNECT COM_DATA_IND COM_DISCONNECT_EVT SCM_DISCONNECT_EVT COM_DataExtract() COM_RspData() WriteData() print the message Figure 7-5 Flowchart of sending data and disconnect device for both the Client and the Server application. Sending Data (Client side): Allocate memory for the message that you wish to send, this is done in the function Com_DataAlloc(). Fill the buffer with the message and send the pointer to the data through the stack with the function COM_DataSend(). Receiving Data and Logging Message (Server side): When the data message has arrived to the application it will extract the interesting data from the message, i.e. remove the header from the packet. Next step is to send a response to the stack that the message has arrived to the application and finally send the extract message to the function WriteData. The function WriteData is then logging the message at the screen. After the printing of message the Server is ready to receive another message. Disconnecing the Client: To cut the connection you only have to disconnect the COM-layer, SCM-layer and unregister the DBM-RegisterService. The Client is made so that when the data connection is being disconnected it starts all over again with a device inquiry, this will give us continious data packages sent over the SIL-layer. Disconnecting the Server: When the Client is requesting a disconnection or there is a loss of the connection the Server will disconnect its COM connection followed by disconnection of the SCM.
57 Analyse The Packet Reader Process The Serial Interface Layer (SIL) (see Appendix E) makes it possible to send data from the OSE environment to the serial port. We have modified the SIL interface so that it not only sends information over the serial port to the Bluetooth device it also sends a signal (chapter 6.7) to the Packet Reader process containing the same information. This makes it possible to externally modulate and display the packets containing important information. The Packet Reader is made, as an external process so there should not be any risk that the information sent through the SIL-interface would be destroyed or affected. The function sorts all the packets (chapter 4.3) and prints the important information. This will give a good understanding what is happening between the stack and the Bluetooth device; it simply displays all the traffic. For example the HCI_ReqInquiry command result in the packets showing in Figure 7-6 that have been reading and writing at the serial port. See Appendix G and Appendix H to see the traffic for the whole Client and Server sequences (init, discover, send data and disconnect). ******************************************* * Writing Data Packet From the Serial port * ******************************************* Packet OpCode HCI Command Group HCI Command Parameter *********************************** HCI_Link_Control_Command HCI_Inquiry_Command LAP: 9e 8b 33 Inquiry_Length: 4 Num_Responses: 0 ******************************************* * Reading Data Packet From the Serial port * ******************************************* Packet Event Code Parameters *********************************** 12 HCI_Command_Status_Event Status: Currently_in_Pending Number_of_HCI_Command_Packets: 1 Command_Opcode: ******************************************* * Reading Data Packet From the Serial port * ******************************************* Packet Event Code Parameters *********************************** 13 HCI_Inquiry_Result_Event Number_of_responses: 1 BD_Adress: 0 d0 b f Page_Scan_Repetition_Mode: R1 Page_Scan_Period_Mode: R0 Page_Scan_Mode: Mandatory_Page_Scan_Mode Class of device: Clock_Offset: 7420 ******************************************* * Reading Data Packet From the Serial port * ******************************************* Packet Event Code Parameters *********************************** 14 HCI_Inquiry_Complete_Event Status: Command_Completed_Successfully Number_of_Responses: 1 Figure 7-6 Logging sequence for the command packet HCI_ReqInquiry on the Client side.
58 Analyse Representation The reason to make an illustrative representation of the packets that passes by the serial port is to get a deeper understanding of what happens with the function calls from the application through the Host stack down to the device. We were suspecting that one call at application level conclude with several HCI function calls to the device. With the logging of the Packet Reader process we were able to see all traffic through the serial port and we could confirm our suspicion. The logging of the packets will take place in stages of different identifications procedures. Since we are using OSE is there a possibility to send signals from SIL to the Packet Reader process with all information about the packets. Two different signals in SIL were created one from the reading section and one from the writing section (see Appendix C). When the signals are received in the process they will be separated by signal identification. After the signal identification we will identify which type of packet it is by investigate the packet type code (see Table 4-3). Depending of the type of packet that is identified the rest of the packet will be identified in different ways. Afterwards all interesting information included in the packet will be logged. Command Packets: These packets will only appear in the writing section in SIL and will therefore always come with the Write signal. All the information in the packet is of interest. First the opcode (see chapter 4.3.1) is identified too separate the command groups from each other and after that is the different commands separate from each other. Then we are able to extract the parameter information that comes with the specific command packet. Event Packets: These packets will only appear in the reading section in SIL and will therefore always come with the Read signal. First the event cod (see chapter 4.3.2) will be extract and identified. After the identification of the code all the belonging parameters to the event are able be to extracted. We are able to see which command that is generating the event and if the command is succeeded. ACL and SCO Data Packets: ACL and SCO data packets are able to appear in both the writing and the reading section in SIL. The packets do not have the same structure (see chapter 4.3.3), but both of them include a connection handle that is of interest. The connection handle will lead the data to the correct receiving layer at the other side. There are two other fields that are of interest in the ACL packet and that is the packet boundary flag and the broadcast flag. The packet boundary flag is identifying if the packet is the first part of a higher layer messages or it is a continuing fragment of a higher layer messages. The broadcast flag will tell us if there is a point-to-point connection or a piconet broadcast connection. In our case it will always be a point-to-point connection. The last field that is extracted in the packets is the length of the data.
59 Results and Limitations 51 8 Results and Limitations 8.1 Result We created a Client/Server scenario, which exchanges data and information about each other. The Loopback function was not possible to implement since it did not work the way that the product management group thought it would, see Figure 1-1. In order to use the Loopback mode you have to create a specific application for this purpose. Therefore it is not possible to create the tool Enea Data AB were looking for, thus the tool that simulates connection between a Client and a Server side on a single host by using the Bluetooth Host stack. Our Packet Reader process makes it possible to view all the packets sent from the host to the Bluetooth device. The packets give the programmer all the information needed to get an understanding what is done and is really happening when the communication starts. The Packet Reader will for example tell if a HCI command is succeeded or if something goes wrong and this will hopefully give enough information to correct a bug in a program. The data sent is also logged so you can see what possible external inferences do to the data packet byte by byte. This Packet Reader process is also directed for educational purpose and will give the pupils a good overview what is really happening between the Bluetooth Host stack and the Bluetooth hardware. Appendix G and Appendix H shows one single cycle (initiation, discovery, data connect, send data and disconnect) of the packets being send from the Client and the Server. 8.2 Limitations for the Bluetooth Specification 1.0b Since Bluetooth is rather new wireless technology there is a lot of teething troubles that you can not escape from. We have ran into a few of those. One particularly thing was the implementation of the Loopback function. It turned out that the Remote Loopback mode was not supported and that the specification about the test commands was inferior. Due to this a lot of time of the investigating of the Loopback functions was spent on the understanding of the specification. Other things that are not supported are point-to-multipoint and multi-to-multipoint connections. This will not be a restriction for us since we only will be using a pointto-point connection for our Client/Server application. Periodic inquiry is another event that is not supported by the version 1.0b of the Ericsson Bluetooth module. None of these restrictions will cause any problems in our work. There will be a new release for the Bluetooth specification 1.1 in late february but the information of what is changed in it is yet not relisad by Ericsson. 8.3 Application Limitations The application is a rather simple Client/Server application where we are sending a string of data from the Client to the Server. The application could easily be extended so that it could for example send data files or voice data. The Client/Server application is limited to be used with the Ericsson Bluetooth Host stack where the not standardised protocol SCM is used, however the Packet Reader process is independent of SCM. Another thing that is specific for the application is that the Client will find all devices in the surrounding area but it will only connect itself to the
60 Results and Limitations one specific Bluetooth device that is defined in the initiation of the OSE environment. This limitation is however not a problem. It is rather easy to change this behaviour for the Client, but since we were looking for a simple application the choice was not to implement a different behaviour. The Packet Reader is fully implemented for the different HCI command groups and events but all of the commands are not displayed out on the screen. The commands that are implemented are the ones that appear when logging the packets sent from the Client/Server application. If the Packet Reader runs beside another application there might be other command and event packets being send and therefore they will not be displayed properly. It is of course possible to implement all the commands but it is just a matter of time and effort. We are not identifying all information that the data packets contains. The ACL data will not be extracted into application data according to Figure 2-1. It is possible to extract the application data but it is not considered in this task. The Packet Reader process is an external process and it is not possible to manipulate the data that passes through the serial port, this could be a limitation for further work. If we had concentrated our work at manipulating the data it must have been done inside the Serial Interface Layer and it had probably given us problems with timeouts and that the system might become volatile. One problem with manipulating the data in the Serial Interface Layer is that the Bluetooth module takes care of all error data and claims for a retransmission and therefore no strange errors occurs. 8.4 Software limitations There are a few limitations in the software. Since we are working on top of the OSE Soft Kernel there are no possibilities to make a simple window based graphical interface for the representation of the logged data. In order to do this data has to be sending to the Windows environment by using UDP (User Datagram Protocol). It is possible to use UDP if INET (OSE s version of TCP/IP) is included in the OSE Soft Kernel. It is not certain that a graphical interface would make the presentation more foreseeable. Because of this we are just displaying the logged data in a text window, in our case the DOS window. Our application will not work on a Linux based OSE Soft Kernel since the Bluetooth Host stack not yet is ported to this kind of environment. 52
61 Conclusion and Future Work 53 9 Conclusion and Future Work One part of the task was to investigate the possibilities to implement the Bluetooth test mode Loopback in future application-testing tools. The conclusion is that the way Ericsson has implemented the Loopback mode at the moment will not give the opportunity to create a testing tool that can achieve the demands that the product management group asks for. However we do think that it is possible to create a testing tool with Loopback functionality, but that requires another implementation of an own Loopback function which makes it possible to manipulate the data packets. Most packets that convey in the air between two Bluetooth devices are coded with both CRC (Cyclic Redundancy Check) at the payload and HEC (Header Error Check) at the header. This mean that the coded data is checked after the transmission and if any of these code checks results in an error; there will be a retransmission of the packet. For that reason we do not see the point with implementing a Loopback function which is able to manipulate the data packets. Writing a Client/Server application is a rather simple procedure, but there are a lot of initiation scenarios to take care of, which take a lot of time to implement. The easiest way to take care of the initiation problems is to build a BTAPI (Bluetooth Application Interface) that initiates the Bluetooth module for the wanted purpose. We discovered that when you have a functional BTAPI it is easier to build a more independent Client/Server application. The main part of the task was to create an external process that could store all data traffic that passes by the Serialport Interface Layer. The process, Packet Reader, will make it easy to detect what commands or events that has gone wrong. Often the logging also will tell us which error that has occurred. The conclusion is that it is possible and rather simple to create this process since we are using the OSE (Operating System Embedded) environment, which supports signal exchange very well. The only critical course of event is allocating and freeing memory. If a signal is left without being freed the memory pool will soon be full The first thing to do if you want improve the Packet Reader process is to add all the commands and events that could occur in Bluetooth communication. This would not be a tricky thing to do but it would take some time. When the programmer is using voice communication (real-time data) for example it would be interesting to investigate the calls that would occur. Another thing that could be done is to use common data communication protocols like UDP (User Datagram Protocol) and INET (OSE s version of TCP/IP) to build a graphical interface that could include a filter function where you could ask for specific commands or event and just display them. It would probably be complicated but not impossible to do.
62 Appendix A: Function Calls in the Client Application Appendix A: Function Calls in the Client Application The Client includes a number of functions that all needed to enable communication between the Client and the Server. This is a brief function description for the Client Bluetooth application. Our choices of parameters are underlined and bold. FUNCTION EXPLANATION VOS_PROCESS (CLIENT_Process) This is the main program of the Client application. It explicitly starts the stack by calling the different functions below. Client_Process then takes care of and handles the messages that are delivered to the Operating System by other functions. 54
63 Appendix A: Function Calls in the Client Application 55 FUNCTION Void CLIENT_Init (void) EXPLANATION This function sets the stack initialisation information. The variables used are found in the struct BTAPI_TStackInitInfo in the header file BT_API.h. Since we are only using an ACL connection all we need are the first four variables defined in the struct and these are. It also sets the RFCOMM connection information. The information variables are all found in the struct BTAPI_TrfcommConnectInfo and they are as follows. Stack Variables Explanation Information Variables EncryptionMode AuthMode ConnectTimeout PageTimeout Defines the encryption mode. Possible values are: HCI_ENCRYPTION_OFF HCI_ENCRYPTION_POINT_TO_POINT HCI_ENCRYPTION_POINT_TO_MULTI_ POINT Declares if authentication is needed. Possible values are: HCI_AUTH_ENABLE HCI_AUTH_DISABLE HCI will wait for this time for a response from the application after indicating a new connection. So the application has this specific time before the LM will reject to connection request to the remote side. HCI will wait for this time on a reply for a page scan.
64 Appendix A: Function Calls in the Client Application 56 Connection Information Variables Address ServiceClass Variables Explanation The destination Bluetooth device address. This is were the Service Record Profile for the destination is determined and possible values for the Bluetooth version 1.0 are: SRP_HEADSET_GENERIC_AUDIO_UUID SRP_DAILUP_GENERIC_NETWORKING_ UUID SRP_CORDLESS_GENERIC_TELEPHONY_ UUID SRP_INTERCOM_GENERIC_TELEPHONY_ UUID SRP_SERIAL_GENERIC_SERIAL_PORT_ UUID SRP_FAX_GENERIC_TELEPHONY_UUID SRP_LAN_ACCESS_USING_PPP_UUID MaxFrameSize PacketType Max size of a data-packet to be sent over this channel and possible values are: COM_DEFAULT_MFS = 127 COM_MIN_MFS = 27 COM_MAX_MFS = ACL packet type and the different packets are: SCM_DM1 SCM_DH1 SCM_AUX1 SCM_DM3 SCM_DH3 SCM_DM5 SCM_DH5 SCM_HV1 SCM_HV2 SCM_HV3 SCM_DV
Introduction to Bluetooth Wireless Technology Jon Inouye Staff Software Engineer Mobile Platforms Group Intel Corporation Bluetooth Bluetooth is is a a trademark trademark owned owned by by Bluetooth Bluetooth
Bluetooth: Short-range Wireless Communication Wide variety of handheld devices Smartphone, palmtop, laptop Need compatible data communication interface Complicated cable/config. problem Short range wireless
Bluetooth Demystified S-72.4210 Postgraduate Course in Radio Communications Er Liu email@example.com -10 Content Outline Bluetooth History Bluetooth Market and Applications Bluetooth Protocol Stacks Radio
Simulation of Bluetooth Network Lennart Lagerstedt Stockholm, 2003 Master of Science Thesis Project The Department of Microelectronics and Information Technology, Royal Institute of Technology (KTH) Lennart
A Guide to the Wireless Network Library Conforming to Standard v1.1 SystemView by ELANIX Copyright 1994-2005, Eagleware Corporation All rights reserved. Eagleware-Elanix Corporation 3585 Engineering Drive,
CS263: Wireless Communications and Sensor Networks Matt Welsh Lecture 6: Bluetooth and 802.15.4 October 12, 2004 2004 Matt Welsh Harvard University 1 Today's Lecture Bluetooth Standard for Personal Area
2011 [A SHORT REPORT ON BLUETOOTH TECHNOLOGY] By Ram Kumar Bhandari 1. Introduction Bluetooth Technology A Technical Report Bluetooth is a short-ranged wire-less communication technology implementing the
Wireless Local Area Network Internet Protocol Suite Application layer File transfer protocol Telnet Hypertext transfer protocol Transport layer Network layer Host-tonetwork layer User datagram protocol
Mobile and Ubiquitous Computing Bluetooth Networking" George Roussos! firstname.lastname@example.org! Bluetooth Overview" A cable replacement technology! Operates in the unlicensed ISM band at 2.4 GHz! Frequency
Implementing A Bluetooth Stack on UEFI Tony C.S. Lo Senior Manager American Megatrends Inc. presented by UEFI Plugfest October 2014 Agenda Introduction Bluetooth Architecture UEFI Bluetooth Stack Summary
Wireless Sensor Networks 11th Lecture 29.11.2006 Christian Schindelhauer email@example.com 1 Bluetooth in WSN? There are several commercially available MAC protocol/products Wi-Fi Bluetooth
Bluetooth Origin of the name Harald I Bleutooth (in Danish, Harald Blåtand) (b. c. 910 d. c. 987), king of Denmark was credited with the first unification of Denmark and Norway Ericsson, inspired on the
Communication Systems WPAN: Bluetooth Page 1 Outline Historical perspective Piconet Scatternet Lattency modes Applications Page 2 Bluetooth Bluetooth (BT) wireless technology is a short-range communications
Bluetooth Renato Lo Cigno www.dit.unitn.it/locigno/teaching ...Copyright Quest opera è protetta dalla licenza Creative Commons NoDerivs- NonCommercial. Per vedere una copia di questa licenza, consultare:
Guide to Wireless Communications, 3 rd Edition Chapter 5 Wireless Personal Area Networks Objectives Describe a wireless personal area network (WPAN) List the different WPAN standards and their applications
Efficient Multicast Schemes for Mobile Multiparty Gaming Applications P6-6th semester 2006 Group 681 - ComNet Aalborg University 9th March 2006 Institut for elektroniske systemer Fr. Bajers Vej 7 Telefon
CHAPTER 12 BLUETOOTH AND IEEE 802.15 These slides are made available to faculty in PowerPoint form. Slides can be freely added, modified, and deleted to suit student needs. They represent substantial work
Bachelor s Thesis (UAS) Information Technology Networking and Programming 2011 IDAHOSA AKHANOLU IMPLEMENTATION AND SECURITY OF BLUETOOTH TECHNOLOGY i BACHELOR S THESIS (UAS) ABSTRACT TURKU UNIVERSITY OF
Bluetooth Basic idea Universal radio interface for ad-hoc wireless connectivity Interconnecting computer and peripherals, handheld devices, DAs, cell phones replacement of IrDA Embedded in other devices,
Core System Package [Controller volume] Part B BASEBAND SPECIFICATION This document describes the specification of the Bluetooth link controller which carries out the baseband protocols and other lowlevel
Wireless Networked Systems CS 795/895 - Spring 2013 Lec #7: Medium Access Control WPAN, Bluetooth, ZigBee Tamer Nadeem Dept. of Computer Science Bluetooth Page 2 Spring 2013 CS 795/895 - Wireless Networked
Bluetooth Wireless Technology meets CAN Matthias Fuchs esd electronic system design GmbH, Hannover, Germany To access mobile and moving CAN fieldbus systems a wireless approach is often a good solution.
Journal of the Korean Physical Society, Vol. 42, No. 2, February 2003, pp. 200 205 Design of Bluetooth Baseband Controller Using FPGA Sunhee Kim and Seungjun Lee CAD and VLSI Lab.,Department of Information
OBILE COUTING CE 40814/60814 Fall 2015 Bluetooth Basic idea Universal radio interface for ad-hoc wireless connectivity Interconnecting computer and peripherals, handheld devices, DAs, cell phones replacement
IEEE OEB Wireless Seminar Fremont, CA - 12/07/02 Essential Bluetooth It s everywhere you want to be Noel Baisa Technical Marketing Manager Device Connectivity Division 408-721 721-74667466 Noel.Baisa Baisa@nsc.com
Table of Contents 1 Introduction...2 2 Installation...2 2.1 Software Installation...2 2.1.1 Installation on Windows 95/98/ME/2000/XP...2 2.1.2 Installation on Windows NT...3 2.1.3 Installation on Linux...3
Computer Networks II Advanced Features (T-110.5111) Bluetooth, PhD Assistant Professor DCS Research Group Based on slides previously done by Matti Siekkinen, reused with permission For classroom use only,
RS- serial ports have nine circuits, which can be used for transferring data and signalling. can emulate the serial cable line settings and status of an RS- serial port. provides multiple concurrent connections
Hindawi Publishing Corporation International Journal of Distributed Sensor Networks Volume 2013, Article ID 963508, 7 pages http://dx.doi.org/10.1155/2013/963508 Research Article Sensor Protocol for Roaming
_äìé`çêé» UART Host Transport Summary February 2004 CSR Cambridge Science Park Milton Road Cambridge CB4 0WH United Kingdom Registered in England 3665875 Tel: +44 (0)1223 692000 Fax: +44 (0)1223 692001
Wireless Personal Area Networks & Wide Area Networks Patrick J. Stockreisser firstname.lastname@example.org Lecture Outline In the lecture we will: Look at PAN s in more detail Look at example networks
Vol:1, No:3, 27 Performance Evaluation of Bluetooth Links in the Presence of Specific Types of Interference Radosveta Sokullu and Engin Karatepe International Science Index, Electrical and Computer Engineering
Part H:1 HOST CONTROLLER INTERFACE FUNCTIONAL SPECIFICATION This document describes the functional specification for the Host Controller Interface (HCI). The HCI provides a command interface to the baseband
University of New Orleans ScholarWorks@UNO University of New Orleans Theses and Dissertations Dissertations and Theses 8-7-2003 VNC Service on Bluetooth Wireless Network Rui Xia University of New Orleans
Bluetooth Claudio Casetti Dipartimento di Elettronica Politecnico di Torino WPAN Technologies HomeRF Bluetooth Bluetooth A cable replacement technology 1 Mb/s symbol rate Range 10+ meters Single chip radio+baseband
Bluetooth WHITE PAPER DATE 25 August 99 N.B. DOCUMENT NO. 1.C.123/1.0 RESPONSIBLE Riku Mettala E-MAIL ADDRESS Riku.Mettala@nmp.nokia.com STATUS Bluetooth PC Card Transport Layer Version 1.0 The Bluetooth
Operating Systems 16. Networking Paul Krzyzanowski Rutgers University Spring 2015 1 Local Area Network (LAN) LAN = communications network Small area (building, set of buildings) Same, sometimes shared,
5.7 WRAN: IEEE 802.22 (1) Wireless Regional Area Network long range up to 100 km Standard published in 2011 Enabling Rural Broadband Wireless Access Using Cognitive Radio Technology in TV Whitespaces Use
Institutionen för systemteknik Department of Electrical Engineering Examensarbete Multiple Synchronized Video Streams on IP Network Examensarbete utfört i infomationskodning i sammabete med Kapsch TrafficCom
Verkkomedian perusteet Fundamentals of Media T-110.250 19.2.2002 Antti Ylä-Jääski 19.2.2002 / AYJ lide 1 Goals and topics protocols Discuss how packet-switching networks differ from circuit switching networks.
Wireless LANs The 802.11 Protocol Stack The 802.11 Physical Layer The 802.11 MAC Sublayer Protocol The 802.11 Frame Structure Services 56 802.11 The 802.11 Working Group The IEEE 802.11 was formed in July
Improving Simultaneous Voice and Data Performance in Bluetooth Systems Abstract In the Bluetooth system, isochronous applications, such as voice and audio, are carried by Synchronous Connection Oriented
Bluetooth low energy technology Bluegiga Technologies Topics Background What is Bluetooth low energy? Basic concepts Architecture Differentiation and comparison Markets and applications Background Background
Status of P1451.5 802.11 Sub-Specification June 7, 2004 Ryon Coleman Senior Systems Engineer 802.11 Subgroup email@example.com Agenda 1. IEEE 802.11 Architecture 2. Scope within the 1451 Reference Model
IEEE 802.11 The standard defines a wireless physical interface and the MAC layer while LLC layer is defined in 802.2. The standardization process, started in 1990, is still going on; some versions are:
DATA SHEET 3Com Wireless Bluetooth PC Card, USB Adapter, and Printer Adapter Key Benefits Simplicity Bluetooth Connection Manager provides automatic discovery and point-and-click management of devices,
CCNA Exploration1 Chapter 7: OSI Data Link Layer LOCAL CISCO ACADEMY ELSYS TU INSTRUCTOR: STELA STEFANOVA 1 Explain the role of Data Link layer protocols in data transmission; Objectives Describe how the
Proceedings of the 5th WSEAS Int. Conf. on APPLIED INFOATICS and COUNICATIONS, alta, September -7, 25 (pp24-28 Optimizing Pacet Size via aximizing Throughput Efficiency of AQ on Bluetooth ACL Data Communication
ECE4110 Internetwork Programming Introduction and Overview 1 EXAMPLE GENERAL NETWORK ALGORITHM Listen to wire Are signals detected Detect a preamble Yes Read Destination Address No data carrying or noise?
Bluetooth in Mobile Devices Vidar Rinne Mälardalen University School of Innovation, Design and Engineering Computer Science: Game Development firstname.lastname@example.org Abstract The basic idea of Bluetooth
Distributed Queue Dual Bus IEEE 802.3 to 802.5 protocols are only suited for small LANs. They cannot be used for very large but non-wide area networks. IEEE 802.6 DQDB is designed for MANs It can cover
Advantages and disadvantages Advantages Disadvantages Asynchronous transmission Simple, doesn't require synchronization of both communication sides Cheap, timing is not as critical as for synchronous transmission,
6 WPANs 6.1 Introduction A PAN is a network solution that enhances our personal environment, either work or private, by networking a variety of personal and wearable devices within the space surrounding
By Jonas Åslund LiTH-ISY-EX-3153-2002 2002-05-16 Titel Authentication in peer-to-peer systems Examensarbete utfört i informationsteori Vid Linköpings tekniska högskola av Jonas Åslund Reg.nr: LiTH-ISY-EX-3153-2002
DBT-120 Bluetooth USB Adapter Rev.2.1 (09/25/2002) 2 Contents Introduction... 5 Package Contents... 6 Installing Bluetooth Software... 6 Hardware Installation... 8 Introduction to Bluetooth Software...
Chapter 5 Introduction to OSI Reference Model 1 Chapter 5 Introduction to Open System Interconnection Reference Model Introduction The Open Systems Interconnection (OSI) model is a reference tool for understanding
SpaceWire-R DRAFT SCDHA 151-0.3 Issue 0.3 13 September 2013 Takahiro Yamada Japan Aerospace Exploration Agency (JAXA) Institute of Space and Astronautical Science (ISAS) 1 CONTENTS 1. INTRODUCTION... 3
ANNEX B - Communications Protocol Overheads The OSI Model is a conceptual model that standardizes the functions of a telecommunication or computing system without regard of their underlying internal structure
Sierra Radio Systems Mesh Data Network Reference Manual Version 1.0 Contents Hardware Xbee backpack board Xbee base station Xbee firmware configuration RS485 network power injector Protocol specification
Hands-on course Mobile Communications Summer 2008 Material and Assignments in the areas of: Medium Access in Wireless Networks Freie Universität Berlin Institute of Computer Systems & Telematics A. Liers,
MIL-STD-1553 INTERFACES TO TELEMETRY SYSTEMS Ray Nicolais Product Manager Digital Data Systems AYDIN VECTOR Division Newtown, Pennsylvania Donald H. Ellis System Engineer AEROSYSTEMS ASSOCIATES Huntsville,
Security Nelli Gordon and Sean Vakili May 10 th 2011 What is Bluetooth? Bluetooth is an open standard for short-range radio frequency (RF) communication. Bluetooth technology is used primarily to establish
Embedded Systems Dr. Santanu Chaudhury Department of Electrical Engineering IIT Delhi Lecture 26 Networked Embedded Systems III Today, we shall look at wireless networks which are intended for usage in
IEEE P802.15 Working Group for Wireless Personal Area Networks TM SCORT - An Alternative to the Bluetooth SCO Link for Voice Operation in an Interference Environment Slide 1 Bluetooth SCO Link The Bluetooth
A Study of Wireless Compressed Digital Transmission Andreas Floros 1, Marios Koutroubas 2, Nicolas-Alexander Tatlas 2 and John Mourjopoulos 2 1 ATMEL Hellas S.A., Patras Science Park, Platani, 26 500 Patras,
Data Communication and Network Introducing Networks Introduction to Networking Computer network, or simply network Refers to the connection of two or more computers by some type of medium You can connect
Smart cards and smart objects communication protocols: Looking to the future. Denis PRACA Hardware research manager, Gemplus research Lab, France Anne-Marie PRADEN Silicon design program manager, Gemplus
Chapter 14 Functions of physical layer: Encoding/decoding of signals Preamble generation/removal (for synchronization) Bit transmission/reception Includes specification of the transmission medium Functions
1 Interference of Bluetooth and IEEE 82.11: Simulation Modeling and Performance Evaluation N. Golmie, R. E. Van Dyck, and A. Soltanian National Institute of Standards and Technology Gaithersburg, Maryland
Page 1 of 8 D-STAR Review & Final Exam Summary This lesson consists of a selection of items from the review sections of Lessons #1 - #9. The Final Exam consists of twenty questions selected from the individual
Layer 2 Technologies Layer 2: final level of encapsulation of data before transmission over a physical link responsible for reliable transfer of frames between hosts, hop by hop, i.e. on a per link basis
Implementation and validation of SAE J1850 (VPW) protocol solution for diagnosis application Pallavi Pandurang Jadhav 1, Prof. S.N.Kore 2 1Department Of Electronics Engineering, Walchand College Of Engineering,
Computer Communication III Wireless Media Access IEEE 802.11 Wireless LAN Advantages of Wireless LANs Using the license free ISM band at 2.4 GHz no complicated or expensive licenses necessary very cost
Rec. ITU-R M.1453-2 1 RECOMMENDATION ITU-R M.1453-2 Intelligent transport systems dedicated short range communications at 5.8 GHz (Question ITU-R 205/8) (2000-2002-2005) Scope This Recommendation outlines
Wireless IP for IoT / M2M 101 The Basics Aeris White Paper A concise introduction to using wireless devices for Internet of Things (IoT) and machine-to-machine (M2M) data transmissions. www.aeris.com 1
Computer Networks Wireless LANs Mobile Communication Technology according to IEEE (examples) Local wireless networks WLAN 802.11 Personal wireless nw WPAN 802.15 WiFi 802.11a 802.11b 802.11h 802.11i/e/
Data Link Layer (cont.) (Sicherungsschicht) Chapter 5 (part 2) [Wa0001] HDLC - 1 LOGICAL LINK CONTROL MEDIUM ACCESS CONTROL PHYSICAL SIGNALING DATA LINK LAYER PHYSICAL LAYER ACCESS UNIT INTERFACE PHYSICAL
ATM Technology in Detail Professor Richard Harris Objectives You should be able to: Discuss the ATM protocol stack Identify the different layers and their purpose Explain the ATM Adaptation Layer Discuss
WPAN-like Systems WPAN Wireless Personal Area Network PAN: Personal Area Network. Small, within a few meters. WPAN: Wireless PAN. Mostly short-range, low-power, lowrate networks. More or less self-organizing.