The code

Local data types

con:

This struct contains all information needed about each connection. This includes the Connection Handle, Active Member Address, BD Address, type of connection (ACL or SCO), the intersection of supported features on the Link Manager in each end of the connection, the currently used packet type, the packet types allowed by the initiator of the connection and the opcode of the last LMP message sent.

pdu:

Used to typecast the memory chunk of an LMP command to it's logical contents.

Helper functions

A whole bunch of helper functions has been added to look up a specific connection based on the different available data (AM address, BD address, connection handle). Functions to add and remove connection structures are also added as well as a function for looking up room for a connection in a bitmap of available connections. Having to add standard functions like memset and strlen was also necessary (or at least easier than figuring out how to get access to them in VCC). Finally a function for choosing the packet type to be used based on the shared features of the connected devices and the wish of the creator of the connection is also implemented. In this function my preference of packet type is encoded, so that if several packet types are available it will choose the largest packet size.

Initialisation

Besides from initialising all global state variables one thing is done here which is not specified that I have to do in the protocol specification. This is making the master device inquire for all slaves in the pico net. I do this because this initialises all devices and puts them in PAGESCAN mode and thus ready for connection. The Host Controller actually provides a function for doing this but neither of the above layers seem to be interested in knowing the addresses of the other devices (and as there is no way of converting between BD addresses and IP addresses I can see why they are not interested). It is still completely fine for the above layers to use this function later (if there for example are new devices in the pico net (which won't happen in VCC but might happen in a real network)).

Runtime function

Basic Concepts

As the Baseband layer is not always ready to receive data the LMP command to be executed next is always kept in a global variable until it is sent. Likewise data packets sent by the above layer is kept in a buffer until sent. Whenever the Baseband is ready any waiting packet will be sent. The LMP command has priority above any waiting data as specified in paragraph 1 of the Link Manager Protocol, p. 191.

Notice that as there is only one variable for storing the LMP command to be executed this will be overwritten if the above layer executes several HCI commands without waiting for a Command Complete or Command Status event. I take this to be the correct behaviour as it on p. 533 is stated that '[on] power-on the Host can send a maximum of one outstanding HCI Command Packet until a Command Complete or Command Status event has been received.' Furthermore there is nowhere any mention of an LMP command queue and there isn't any reason to have one if the above layer behaves nicely. This is one of the (many) places where I find the specification a bit vague, explaining the behaviour superficially in many words with little content.

It is stated in paragraph 2 of the Link Manager Protocol specification that in case an SCO connection exists LMP commands may be sent in DV packets, otherwise they have to be sent in DM1 packets. DV packets are synchronous transfer combined data and voice packets which are not implemented in the Baseband so this we have to ignore. As it is only a 'may' the usage of DM1 packets for all LMP commands is still fine. DM packets were not supported in the Baseband either, but these I have included by adding 2/3 FEC encoding for DH like packets.

Host Controller Interface functions

As there are functions in the specification of the HCI Link Control Commands that does not make sense to us (stuff to do with encryption, power management etc.) it is very lucky that not all commands needs to be supported in order for this to be a valid implementation of the Host Controller Interface. This is due to the command Read_Remote_Supported_Features. With this you can specify a subset of the specified instruction set which is supported and the above layers are thus restricted to only using these commands. Here follows a description of the supported commands.

Inquiry Makes the Baseband enter the INQUIRY mode. This will generate the Command Status event plus an Inquiry Result event for each device that answers the inquiry. At timeout or when Num_Responses devices have answered the Inquiry Complete event will be generated.

Inquiry_Cancel Makes the Baseband enter STANDBY mode. Generates a Command Complete event.

Periodic_Inquiry_Mode Works similarly to calling Inquiry periodically with a random time between Min_Period_Length and Max_Period_Length between each. Generates same events as Inquiry but does so continuously times until the periodic inquiry mode is exited.

Exit_Periodic_Inquiry_Mode Exits the periodic inquiry mode immediately (not waiting to send Inquiry Complete if an inquiry is currently running). Generates a Command Complete event.

Create_Connection Tries to establish an ACL connection to the device with the specified BD address by making the Baseband PAGE the device. A connection structure is initialised. When the Baseband has assigned the device an Active Member address it will let the LM know and thus we both know this address and that the device is initialised and we can continue to set up the connection. A Command Status event will be generated as will a Connection Complete event on both connected devices once the Link Manager has finished to set up the connection.

Disconnect If an existing connection is specified as the Connection_Handle parameter this initiates the termination sequence. The parameter Reason should contain information about why the disconnection is requested.

Add_SCO_Connection Adds a logical connection handle to the ACL connection specified by the Connection_Handle parameter. The connection will use one of the packet types implied by the Packet_Type parameter. At least one packet type which is known to be available should be supplied and then the Link Manager will choose the most appropriate of the listed available types.

Accept_Connection_Request Accepts a connection to the requesting device with the BD address in BD_ADDR. If the connection requested allows for role switching, the accepting device can indicate it's desired role.

Reject_Connection_Request As the above, but the above layer has to supply a reason for the rejection.

Change_Connection_Packet_Type Try to set the packet type for the connection indicated by Connection_Handle to one of the types specified in Packet_Type. This should be used after Read_Remote_Supported_Features in order to be sure that the requested packet type is available.

Remote_Name_Request Will initiate the procedure of acquiring the user friendly name of a remote device.

Read_Remote_Supported_Features Will initiate the procedure of exchanging the list of supported features of each device and report the intersection of these to each device.

Link Manager Commands

The Link Manager commands are only used by the protocols internally and are as such not of much interest to the reader. The curious reader can look at the code in appendix A where these are listed in the code.

Data Packets

When sending data across a connection, the data is first put into an output buffer. In the first packet sent on a connection, the total length of the data to be transferred is written. Depending on the size of the packet type of the current connection the data from the upper layer will be split into as many chunks as required and sent through the baseband one by one. On the other end the incoming data is collected in an input buffer until the last packet have been received. When this happens the collected data will be sent to the higher layer and both ends of the connection are informed that the data was sent successfully.