Connecting Bluetooth Devices
Problem definition and assumptions
The example problem we look here is a typical bluetooth piconet
scenario. Lets say you enter "Walmart" and want to know where the
"oranges" are. So you take out your cellphone and search for a map
service provided by the "Walmart" piconet. The service is assumed to
be located on the master of the "Walmart" piconet. For simplicity,
assume that there is only one piconet. Later we will look at the
complications introduced if more than one piconet are connected to
form a scatternet and when the service is located on some node other
than the piconet you enter. Also to avoid Inquiry problems, we will
assume that your cellphone can get the Bluetooth address (BD_ADDR)
of the "Walmart" master by doing a simple NSLOOKUP in the local
database (cellphone diary) of recently visited piconets.
When you enter "oranges" and press search in your browser window,
the request will be received by L2CAP of your bluetooth device
(cellphone in this example) as L2CA_ConnectReq event. Here we
will assume that L2CAP maintains a cache of connection handles of
recent connections. Also there is a dirty bit in the cache for each
entry which tells whether the connection handle (CH) for a
particular connection is valid or not. The dirty bit is set when LMP
reports to L2CAP about connection break or termination for that CH
(this is implementation dependent and there is no need for you to
follow exactly like this).
Connection establishment at the client side
L2CAP does a simple NSLOOKUP on "walmart" and gets the address of
the master (BD_ADDR). L2CAP will then check whether the CH for that
address is present in the cache or not. If there is already a CH
(not in this case because you just entered the piconet) and its not
dirty then L2CAP can go ahead and try to establish a logical
connection with the L2CAP of the "Walmart" master by issuing the
L2CAP_Connect_Req event to the HCI layer below. If there is
no link connection, then L2CAP tells the HCI to create one by
issuing the LP_Connect_Req event. HCI will send
HCI_Create_Connection command packet to the LMP. LMP will
send back the Command Status Event . The Command Status event
is used to indicate that the command has been received and the LMP
is currently performing the task for HCI_Create_Connection command.
This event is needed for asynchronous operation of the host, making
it possible for the host to do other things and not wait for the
command to finish.
LMP receiving the request for connection, will see whether there
is already a CH for the connection (in case of cache overflow or for
other reasons L2CAP may miss the cache). if there is CH, LMP will
send the Connection Complete Event to the HCI with the CH. If
there is no CH for the remote device (Walmart master), LMP will
first try to create a LMP channel between the two devices. This is
done by sending a LMP_host_connection_req PDU (Protocol Data
Unit) to the remote device. But before the LMP channel can be
established a physical connection channel has to be established by
the two devices at the baseband level.
Connection at the physical level
The connection at the baseband is level is bit complicated. The
complication is that the Bluetooth specification allows only the
master to page a slave and not vice versa (or atleast we are under
that impression). So your cellphone will create its own local
piconet (temporarily though) and try to page "Walmart" master as its
slave. The "Walmart" master, when in page scan mode discovers this
page message (which is just a simple ID packet containing the
slave's Device Access Code - DAC - from your cellphone sent at the
page hopping frequency determined by the slave's BD_ADDR - "Walmart"
address), it will send a slave response. This response message again
only consists of the slave's - "Walmart" - device access code. The
slave will transmit this reponse 625 micro-seconds after the
beginning of the received page message and at the response hop
frequency that corresponds to the hop frequency in which the page
message was received.
The master - your cellphone - when receives the ID packet, will
respond with a FHS packet containig the master's real-time Bluetooth
clock, the master's 48 bit BD_ADDR, the BCH parity bits and class of
device. This packet is again sent on page hopping sequence. The
slave - "Walmart" - returns a response (slave's device access code
only) to acknowledge the reception of FHS packet. Now both the
devices are in CONNECTION state and can now establish a higher level
of channel on top of this physical channel. The first packet sent by
master - your cellphone - will be a POLL packet just to re-confirm
the connection. Slave can respond using any packet. Also note that
when the connection is established, the frequency hopping sequence
used is the channel hopping frequency determined by the master's -
your cellphone - BD_ADDR. So the POLL packet will be sent using
channel hopping frequency.
Connection at the server side
After establishing the physical channel, the baseband will create
an ACL data packet (DM1, DM3 or DM5), set the L_CH field in the
payload header as 11 (a LM packet). AM_ADDR in the packet header is
also set by your cellphone (notice that FHS packet sent by you had
an AM_ADDR field which suggested the slave to use that as the Active
Member Address for this connection). The one byte
LMP_host_connection_req PDU forms the payload for the packet.
When other side receives the packet, it is forwarded to the LMP
since it is a LM message. The LMP of "Walmart" recognizes the
LMP_host_connection_req PDU sent from your cellphone and generates a
Connection Request event for the HCI. When HCI receives this
event, it tells the L2CAP about the request as LP_ConnectInd
event. The L2CAP can again pass this event to upper layers by
L2CA_ConnectInd event and let the application decides whether
to accept the connection or reject it. There are cases where lower
layers can take these decisions but they will not be explored in
this document. The upper layers can accept or reject the connection
request using L2CA_ConnectRsp or L2CA_ConnectRspNeg
respectively. Similarly, L2CAP informs the HCI using either
LP_ConnectRsp or LP_ConnectRspNeg events. The HCI of
"Walmart" then sends the LMP either a
HCI_Accept_Connection_Request or
HCI_Reject_Connection_Request command. The LMP can either
respond with LMP_accepted or LMP_not_accepted PDU
depending on whether the connection is accepted ot not. This PDU is
sent back to your cellphone by the baseband of
"Walmart".
LM channel establishment
Your cellphone will receive the baseband packet and pass the PDU
to the LMP since it was sent on the LM channel (L_CH = 11). If the
connection was rejected, the LMP will sent teh HCI a Connection
Complete Event with an error code. HCI will tell L2CAP using
LP_ConnectCfmNeg and L2CAP will tell upper layers using
L2CA_ConnectCfmNeg. If the connection was accepted, LMP will
send a LMP_setup_complete PDU to the remote device LMP
("Walmart" in this case). The remote device will also send a
LMP_setup_complete PDU to your cellphone and a LM channel is
established. After this both the device LMPs will send a Connection
Complete event with Status flag in the event flag set to 00
indicating successfull connection. HCI will tell the L2CAP using
LP_ConnectCfm and L2CAP will tell upper layers using
L2CA_ConnectCfm. This will initiate the L2CAP channel
establishment now. Also in the Connection Complete event
packet the LMP will send the CH for the connection. L2CAP can now
assign a CID (Connection Identifier) to the connection and establish
a L2CAP channel using this CH.
L2CAP channel establishment
L2CAP essentially uses Signalling commands to establish a L2CAP
channel. It uses signalling commands L2CAP_ConnectReq and
L2CAP_ConnectRsp to establish a L2CAP channel. The upper
layers can use this L2CAP channel to send data and other
information.
| 