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).
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.
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.
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".
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 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.
For more related information, please use the Appendix below.
|
