We chose between two different Bluetooth implementations, one based on a simpler lower layer solution, which could be used when we controlled both sides of the connection and one based on using the entire stack. This in order to connect to other devices such as mobile phones. The main limitation of this implementation was the lack of the ability to make a direct Gameboy to Gameboy connection. Due to the fact that we did not have all the documentation needed to finish our rewriting of the application code.

4.1 General description:

Bluetooth is a short-range radio link that replaces cables between electronic devices up to 10 m. Robustness, low complexity, low power and low cost characterize it. Bluetooth operates in the unlicensed ISM band at 2.45 GHz. As this frequency is not reserved for Bluetooth, a frequency-hopping scheme with 79 sub-frequencies is used to combat interference and fading. The frequency-hopping scheme also enables Bluetooth to work in not only point-to-point connections but also in point to multi-point connections.

This means that two or more units sharing the same channel form a piconet, consisting of one master and up to seven slaves. When more than one master is involved in the piconet then they form a scatternet. Figure 4.1 shows the two concepts.

For full duplex transmission, a Time Division Duplex (TDD) scheme is used; each package is transmitted in different hop frequencies.

Bluetooth combines package and circuit switching where there is a support for an Asynchronous Connectionless Link (ACL) for data and up to three Synchronous Connection Oriented Links (SCO) for voice.

The voice channels have a maximum rate of 64 Kbps, ACL on the other hand has either 432.6 Kbps / 432.6 Kbps or 723.2 Kbps / 57.6 Kbps, depending if the channel is symmetric or asymmetric. The Bluetooth address consists of 48 bites, which is unique for every Bluetooth device.

Bluetooth is based on a stacked protocol model, where the communication is divided into several layers [1].

The lower layers consist of the Radio interface, Baseband and the Link Manager and the Host Control Interface plus the audio.

The higher layers of the stack are L2CAP, RFCOMM and SDP, which are the Bluetooth standardized parts of the stack. Besides these parts there is a Stack Connection Manager, SCM, which handles and administers the Bluetooth connection.

The main theories in this chapter about the lower layers of the stack come from the Bluetooth specification, and for the higher layers they come from Users manual- Bluetooth Host Stack by Ericsson. For a more detailed description read further in these two documents. The figures and tables in this section are also been taken from these documents.

4.2.1 Radio interface

The Bluetooth module is a class 2 device with no power control. Nominal ranges of the modules with antennas are up to 10 m (at 0dBm) which complies with the regulations in the ISM band.

Modulation technique is a binary Gaussian frequency shift keying (GFSK). The channel bandwidth is 1 MHz and the frequency deviation from the carrier frequency of the RF channel is between +/- 140 to +/-175 kHz for representing a ‘1’/’0’.

The bandwidth of the Bluetooth channel is 83,5 MHz which means that the bandwidth of each frequency slot is approximately 1 MHz. The normal hopping rate of the frequency hopping scheme is 1600 hops/s. The channel is divided into timeslots, with every slot is 625 ms in length.

Hopping frequency is determent by a pseudo-random hopping sequence, which is unique for each piconet. During each transmission the frequency of the sending device is fixed and a priority scheme is used where the master uses the even numbered timeslots and the receiving slave the odd numbered timeslots.

Between the master and the slave different type of links can be established, either Synchronous Connection Oriented Links (SCO) or Asynchronous Connectionless Link (ACL).

The SCO link is a symmetric point-to-point connection, which the master establishes and could be considered a circuit switched connection. Other aspects of the SCO link is that packets are never retransmitted which means that this is not a one hundred percent secure connection for data transmissions.

The ACL is a point-to-multipoint link between the master and one or more of the slaves in the piconet. This link is a packet switched connection and in contrast to the SCO the ACL link retransmits packets that are lost in the transmission. Another important feature of the ACL link is the master’s ability to do a broadcast to all the connected slaves when the Bluetooth address of the send message is left empty. Lastly when there is no data transmitted, no pulling is required.

The data that is sent are consist of packets which consist of assess code, a header and data. All values and parameters are sent and received in little endian formats, the least significant byte is sent first and negative values must use 2’s complement format.

The link manager in each Bluetooth module can communicate with another link manager by using the Link Manager Protocol (LMP) which is a peer-to-peer protocol.

The LMP messages have the highest priority and are used for link-setup, security, control and power saving modes. The LMP messages are sent in the payload and need not to acknowledge due to the reliable link provided by the Baseband and radio.

The HCI –firmware implements HCI commands for the Bluetooth Hardware by accessing Baseband commands, link manager commands, hardware status registers, control registers and event registers. Figure 4.5 shows the Bluetooth architecture.

There are three different types of HCI packets. HCI commands packets are sent from the host to Bluetooth module and HCI event packets, which are sent from the Bluetooth module to the HCI host. Finally there are HCI data packets.

This is used for sending commands to host controller from the host. The format is shown in Figure 4.6. Each command consist of 2 byte Opcode used to identify different types of commands. The Opcode parameters are divided into two fields: Opcode Commands Field (OCF) and Opcode Group Field (OGF).

The OGF occupies the upper 6 bits of the Opcode and the OCF occupies the other 10 bits of the Opcode. Further more all of the command parameters for each command have fixed size. Each command will specify each parameter and size of each parameter contains the command.

Used by the host controller to notify the host when events occur. The format of the HCI Event packet is shown below. The Event occupies 1 byte of the packet and the parameter length 1 byte.

Used for exchange data between the host and host controller. There are two types defined depending on the connection. The format for the ACL is shown below. It consist of 14 bits for the connection handler, 2 bits for the flag, the total length of the data that is in the packet and the data it self.

Provides connection-oriented and connectionless data service to upper layer protocols with multiplexing capability, segmentation and reassemble operation.

L2CAP permits higher level protocols and applications to transmit and receive L2CAP data packets up to 64 Kbytes in length

Is used as transport protocol plus emulation of RS-232 serial port. It supports up to 60 simultaneous connections between two Bluetooth devices and is able to transmit and receive data packets up to 32 Kbytes.

SDP is a crucial part of the Bluetooth framework. It provides the means for applications to discover which services are available and to determine the characteristics of those services using an existing L2CAP connection. Afterwards a connection can be established using information obtained via SDP.

Establishes the communication between the stack and HCI firmware in the hardware. HCI interface also ensures that the stack can run over a generic hardware. The HCI driver can be divided in to a generic component (GC) and an environment dependent component (EDC).

The SCM is one of the components in the Bluetooth stack, which handles and administrates the Bluetooth Baseband connection and the radio link.

The SCM has to be used for creating data links & voice links. It also takes care of link keys that are generated after pairing.

SCM enables multiple applications on top of the Bluetooth stack to setup independent data &voice links. In the Bluetooth concept it is possible to have multiple clients and servers on top of the Bluetooth stack, which is done by using multi protocol channels, sharing of the same data link enables this.

4.3 Application Peripheral Interface (API)

The interface to the stack is Ericsson propriety API, designed as environment independent and flexible [2]. It allows the establishment and tear down of data and voice connections, sending and receiving of data, as well as other Bluetooth functions such as performing inquiries and page function. Dynamically loading profile and adding own API complements suitable for the selected environment. One other important feature is the ability to access the L2CAP layer directly in order to implement new protocols on top of L2CAP by the user.

As mentioned earlier in the chapter, in order to make a connection to devices we had to use more of the stack. Our solution is based on the Ericsson stack. In the solution part that follows in the next section, we will discuss what API we chose and what are the limitations of that solution.

In order to understand and have some kind of understanding of how to use the stack and get an introduction to the stack concept a short description of the main principles of the stack will follow. But for a deeper understanding of the theories see [user manual –Ericsson Bluetooth stack]

The stack API gives application programmers access to the APIs provided by the different layers of the stack; RFCOMM, SDP, L2CAP, SCM and HCI interfaces. By using the API the application programmer is given full access to the features provided by the Bluetooth technology. In the description that follows when discussing different layer such as layer A and layer B etc, the layers can be any of the components of the stack.

Layer A communicates with layer B by calling the correct request message function, which is the same for every layer.

The request function allocates memory to send data and parameters, which in the next step is sent to layer B. Layer B waits for messages from the queue, when a new message arrives to layer B it’s handled in a state machine. Depending on if the message results in a confirmation, a message is send directly to layer A.

In case it results in another message to another layer, then layer B calls the correct request function. All the message handling are done by the operating system routines.

Control message is the communication between different layers, which exchanges information with each other. A data message passes through the stack where each layer adds its header to the data packet. In the same way, on the other side each layer removes the headers one by one.

The difference between command messages and event messages can be seen below. A command message is messages sent from a higher layer to a lower layer, which is a request. An event message is the opposite, a lower layer sent a message to a higher, corresponds to an indication.

4.3.1.3 Layer to layer

Communication between to two protocol layers is described here. Because all the protocol components have the same kind of messages one could use the standard message to communicate with all the other different protocols, in another word replacing the "B_" with SCM_, COM_, SD_, L2CAP or HCI_. Table 4.1 shows the messages, which can be sent from layer A to B.

For a layer to make use of a service in a lower layer, it has to register itself to the layer, which can be done by a request register function. Afterwards if successful the two layers have an interface with each other until one of the layers request de-registration. Now a connection can be established by request connection function.

Messages sent from the lower layer B to the higher layer A could be summand up by the Table 4.2. The same argumentation can be used here as with case of communication layer A to B.

For more on the parameters see User manual Bluetooth Host Stack

4.3.1.4.1 Start

As stated above, before making any use a component one has to start the interface to the lower layer, layer A starts the interface with layer B etc. This is done by function B_ReqStart. Figure 4.12 shows the start procedure.

The registration is next step; a server must register to lower level with B_ReqRegister. As the lower level must know were to send the received messages.

A Client layer does not need to register itself, because it receives messages from higher layer and thereby knows were to send back the response. If the registration is successful the two layers can set up a connection and send data. One important note, sever registration has no effect on the client side. A de-registration is done by sever sending B_ReqDeRegister. See Figure 4.13.

A client initiates the set up connection by calling the B_ReqConnect function of the protocol layer it wants to use. If the sever is registered to the lower layer a B_TConnectInd is received. As seen above the server can decide whether to accept or to decline, depending what the server send as B_RspConnect parameters. Either client or the server can send a B_ReqDisconnect; the other side receives a B_TdisconnectEvt.

When the connection is established, both the server and the client can start sending data to the other side. The highest layer must call the B_DataAlloc function, which allocates memory in the stack and the highest layer can put its data in there. After this a B_DataSend is send to a lower layer. This function call has a pointer to the allocated memory as parameter. This means that the data is not copied on every level as the data travels though the layers.

On the opposite side a B_TDataInd is received, which indicates that data is delivered to layer A. This layer then send a B_DataExtract to retrieve a pointer to the data block and the length of it.

If this is successful then a B_RspData is sent. Depending on the correctness of the data a positive or negative response is indicated I the return parameter.

Figure 4.15 shows a data-sending scheme.

4.4 The two Bluetooth solutions

As mentioned in the introduction, the two main solutions we had to deal with were one based on HCI and one based on an API. When we started out the only part of the Bluetooth we had was the lower layers, with HCI interface at our disposal. Even though this was quite limiting we could make simple implementations as long as we controlled the entire connection.

But when the project entered the next step we had to have the higher layers of stack, in order to connect to a mobile phone. This meant that we had to have an API to use on top of the stack.

A schematic figure over the HCI connection can be seen in Figure 4.16. As seen in Figure 4.16 the peer-to-peer connection is established between the HCI layers of the stack.

The main HCI command and events we used are presented in Figure 4.17. Before any connection can be established between two devices some information (Bluetooth address, device class etc) about the other device has to be acquired which is done by an inquiry command sent from one of the devices. When this command is executed all devices with in 10 m which are in scan mode will respond to the inquiring device.

After an inquiry has been done a connection to a specific device is done by ACL connection command. When the connection has been established all the necessary bits are in place for sending and receiving of data.

The data can either be send based on the first package principal or on a fragment package principal. For more insight in HCI commands and packets formats see the Bluetooth specification. Some examples of the commands- and events- packets used above can be found in Appendix F.

RFCOMM Communication Module Protocol (RCMP) [3] is the UART interface between the Gameboy and the Bluetooth Baseband chip in the Bluetooth module. This is an Ericsson specific protocol, which is based on the Ericsson Bluetooth stack.

The hardware system is described in the Figure 4.18.

The entire link from Gameboy to Gameboy through the GSM network can be seen in Figure 4.19, where the RCMP level is used to send the data between the Gameboy consoles.

To avoid misinterpretation when the data 0x44 is going to be sent, an escape sequence of 0x44 + 0x44 is sent. All this is necessary due to the fact that the start flag also is 0x44.

• 0x44 à 0x44 + 0x44

The protocol follows the API guidelines, which means that both Bluetooth Baseband ship and Gameboy must wait for a DataCnf in order to send the next packet. The largest packet length is 1 Kbytes.

4.4.2.1.2 The Communication

The communication sent from Gameboy using RCMP I different scenarios can be seen in Figure 4.19.

The first time the Gameboy and the Bluetooth module is to be connected, a pairing scheme must be made. During this procedure, both devices exchange information with each other and also an encryption key is generated for the connection.

When the pairing has been successfully done a connection is established and data can be sent from one device to the other.

As the name of the protocol suggests the protocol an interface is give at RFCOMM level. Higher protocols such as AT-commands, TCP/IP etc will be sent as ordinary data. Thus enabling the Gameboy to send ATDxxx for connecting to other modems.

The main shortcoming of RCMP was the fact that it was only a Client code, which meant that a connection could only be established to a server. This meant that the possibility for direct Gameboy to Gameboy connection could not be achieved. In order to solve this problem, we had to rewrite some of the code. Sadly due to time factors and specially lack of documentation, we had to abandon this solution. For direct Gameboy to Gameboy connection the simpler HCI solution could be used, but the down side was that we had two different codes.

4.5 Bluetooth tools

This was the main Hardware we used for the development of the Bluetooth. The kit consist of all that is needed for hardware / software development, with full Bluetooth capability.

This kit comes with a well-documented folder were both the hardware and the software are described thoroughly. It has both a USB interface and three RS232 ports. It also has all necessarily audio hardware. For a more comprehensive information over the EBDK se the documentation of the EBDK.

BATK is a much smaller kit physically; it is also less powerful. The main purpose for it is small development (as some of the hardware is not available) and /or demonstrations. It has also not been qualified to the Bluetooth specification.

The kit has both an USB interface and an UART interface [4]. The hardware consist of a two-layer printed circuit board equipped with a UART buffer, a voltage regulator, few passive components and the Bluetooth Module of Ericsson ROK 101007.

This is the Bluetooth hardware which we use in the final version of our prototype, to have something that is portable, is one of the more important aspects of our concept.

ROK 101007 is a short-range module for implementing Bluetooth functionality in to various electronic devices [5]. The module consists of three major parts, a Baseband controller, a flash memory and a radio that operates in 2.4-2.5GHz free ISM band.

The key features of the module is a pre-qualified Bluetooth 1.0B Module, multiple interface for different applications, UART for data, PCM for voice and USB for voice and data. An I2C interface, internal crystal oscillator, Built-in shield and lastly HCI firmware, which enables the possibility

For a more comprehensive information see ROK Bluetooth Module document.

Block diagram over the module can be seen in Figure 4.24.