Scope of the document
This document outlines the possibilities for SIM-based access mechanisms that could be
used at Public Bluetooth Access Points (PBAPs), which may require adjustment to
existing or the development of new Bluetooth profiles respectively additional hard and/or
software on PBAPs.
Bluetooth - an ubiquitous wireless communication technology
Bluetooth, originally defined as a cable replacement technology, is on its way to become
the standard communication technology for mobile user devices like: mobile phones,
PDAs and notebooks. Assuming Bluetooth will be the future built-in wireless short-range
communication technology for mobile devices, new application scenarios emerge and
others will get pushed to a wider audience. These scenarios include:
B2C (business to customer)
• PBAPs (access to the internet and local information)
• mobile payment
• electronic ticketing
• mobile advertising
B2E (business to employee)
• authentication and access control
• corporate PKI deployment
The SIM - an operators asset
The SIM- card has proven to be a very successful mechanism for user authentication on
GSM networks. There is a clear association in the users' minds between the SIM and their
account. Currently there are deployed about 800 millions of SIMs worldwide. Each and
every SIM is a potential authentication token for a wide range of applications apart from
GSM network authentication. For this reason it is also used for authentication in other
scenarios, e.g. payment schemes in m-commerce. Another option is the use of the SIM
authentication mechanism for controlling access to other wireless networks, e.g. WLAN
or Bluetooth. Additional initiatives related to the SIM, e.g. SIM Toolkit, can potentially
be used to this end.
Bluetooth and the SIM - a promising liaison
The SIM paves the way for service offerings like a SIM-based authentication of users to
third party service providers and the billing for content on behalf of these parties. This
would enable a fast roll-out of new services on top of wireless public access solutions.
Bluetooth is ready to serve as the enabling technology for:
• offering SIM-based services in a local environment
• transforming the SIM into a smartcard for applications
• let the smartcard reader „nightmare“ vanish
Overall functionality and architecture
Fig. 1: Main architectural elements
The diagram in figure 1 shows the main architectural elements present in this scenario.
The access server controls the access points, enables the connection to the Internet and
connects to the necessary elements of the mobile operators' core network respectively to
the authentication and billing service providers. User devices will connect to services on
the Internet using multiple access points. The access server will allow this connection if
and only if the user device is able to authenticate the user.
SIM-based Access Mechanisms
This section lists briefly different mechanisms for SIM-based access requiring different
functionality on the SIM:
Use of the GSM- algorithms
In this case the already existing GSM- mechanisms for user authentication are used.
Therefore, the existing billing infrastructure, for example the GPRS- billing system, can
be used to enable time or volume based billing using the existing subscription of the user.
A shortcoming of this approach is the inflexibility resulting from the use of existing
mechanisms which were designed focussing on GSM issues only. The mechanism
facilitates billing and requires not much additional effort to realize a working system but
relies strongly on the inflexibility of the traffic based billing mechanism of today's GSM-
Nokia has an already working solution for public WLAN access, the so called Nokia
OWLAN. A drawback of this solution is the necessity of a second SIM card to make the
Use of SIM Toolkit
This mechanism incorporates operator specific SIM Toolkit applications which do not
belong to the standard GSM infrastructure. SIM Toolkit applications are usually installed
by the issuer of the SIM- card which is the mobile operator. Therefore more flexibility
may be gained but the number of users may reduce to the subscribers of a single operator
and usually proprietary non-standard mechanisms will be used for authentication (for
example algorithms based on a shared secret). This mechanism facilitates billing but
requires additional effort for the relisation.
Use of a combined SIM/WIM
The WIM (WAP Identity Module) is based on the WAP 2.0 specification enabling secure
transactions and non-repudiation based on a digital signature. Users can perform
transactions securely and easily using a single PIN code. In this case, the WIM is
implemented on the operator SIM card enabling secure transactions and authentication.
This mechanism assumes that the functionality of the WIM is not only accessible via the
WAP- Browser of the mobile phone, but also via an appropriate interface remotely via
Bluetooth. Furthermore some additional effort is necessary to do the actual authentication
at the access server. This mechanism facilitates billing but requires additional effort for
Use of the GSM- algorithms
Fig. 2: Architectural elements for SIM- based authentication using GSM- algorithms
The diagram in figure 2 shows the main architectural elements present in this scenario.
The access server connects to the necessary elements of the mobile operator's core
network to enable authentication and billing using standard GSM algorithms. The
connection to the Mobile Switching Center (MSC) is necessary to run the authentication
according to the A3 algorithm between the SIM card in the mobile phone and the GSM
network. The connection to the GPRS billing network node ensures that connections of
authenticated users are correctly billed to their mobile phone account. A drawback of this
approach is its dependency on the current GSM algorithms for authentication and billing.
This mechanism enables traffic-based billing only (per time or volume). This dependency
implies also the advantage of this approach - it is relatively easy to apply without major
changes in the way the SIM card is used.
Message Sequence Charts
Fig. 3: Message sequence chart for SIM- based authentication using GSM- algorithms
Figure 3 shows the message sequence chart for the GSM-based authentication. Upon the
reception of the registration request from the user device including the IMSI
(international mobile subscriber identity) fetched from the SIM card identifying the
subscription of the SIM card's owner with the mobile operator, the AS will request the
profile of the mobile user from the GSM network including so called authentication
triplets. These triplets are comprised of a random challenge (RAND), an encrypted
version of this challenge (SRES) and a session key KC not further used in this scenario.
In the next step the AS will initiate the standard GSM authentication process issuing the
RAND to the user device which will forward this authentication request to the SIM. The
SIM will return a signed response (SRES) using the private key of the subscriber. The
authentication reply will then be forwarded to the AS which checks if the SRES equals
the SRES included in the used triplet. If the user is correctly authenticated then the access
server will allow Internet access.
The AS begins collecting traffic data when the authentication of the user was successful
e.g. the number of bytes exchanged or the time the connection is used. It will transform
the collected accounting data into the GPRS- specific standard format and forwards this
information to the GPRS billing system of the mobile operator. The charges will appear
on the phone bill of the mobile subscriber or may be charged from his pre- paid account,
if the mobile operator implements this option.
The data transfer from and to the SIM over the Bluetooth link should be secured,
therefore the user device and the mobile phone should be in paired mode ensuring link
level encryption of the data flow between the user device and the SIM respectively
mobile phone. The same holds for the connection between the user device and the access
point. Because the user device simply relays most of the messages which the mobile
phone respectively the SIM issue. Another issue to consider is the security of the
connection between AS and the operators network. All traffic should be encrypted and an
established trust relationship is a must.
Use of SIM Toolkit
SIM Application (SIM AT) Toolkit Basics
SIM AT (ETSI GSM 11.14) is an API for accessing services of the mobile phone such as:
• Fetching location information
o PROVIDE LOCAL INFORMATION
• User interaction
o GET INPUT (strings, numbers, pins, etc.)
o DISPLAY TEXT
o SELECT ITEM
o LAUNCH BROWSER
o SEND SHORT MESSAGE
o OPEN CHANNEL, SEND DATA, etc.
SIM AT applications can be triggered by:
• Phone menu selection
• Arrival of SMS
Fig. 4: Architectural elements for SIM- based authentication using SIM Toolkit
The diagram in figure 4 shows the main architectural elements present in this scenario.
The access server connects to an authentication provider which will be in most of the
cases the mobile operator which is the issuer of the SIM card, because of the fact that the
SIM toolkit applications are operator specific. This means the operator as issuer of the
SIM holds the responsibility of the SIM's reliability and will therefore control the
application installation of SIM Toolkit applications. The main add-ons necessary for this
scenario is a SIM toolkit application enabling the encryption of data using a symmetric
encryption algorithm and it's counterpart in the network. Another underlying assumption
of this scenario is the possibility to access SIM toolkit mechanisms over a local link to
the mobile phone namely Bluetooth rather than over the GSM link. Furthermore the
access server of the public Bluetooth infrastructure must supply some accounting
functionality in order to bill the user via his mobile phone bill or another payment
For further information reagrding the use of SIM Toolkit for Internet applications see
also the WebSIM concept as developed in Eurescom P1005 "JINI & Friends @ Work:
Towards secured service access".
Message Sequence Charts
Fig. 5: Message sequence chart for SIM- based authentication using SIM Toolkit
Figure 5 shows the message sequence chart for the SIM Toolkit- based authentication.
Upon a service request from the user's device including the telephone number (or another
means of authentication) identifying the subscription of the SIM card's owner the AS will
issue a random challenge to the user's device. The device will then return a signed
response using for example AES or IDEA implemented on the SIM and accessible via
SIM toolkit. In the course of this interaction there may be a dialog displayed on the
mobile phone's display asking the user whether she/he is willing to accept the interaction
or not. Upon receipt of the signed response the AS will issue a request to the mobile
operator asking him to verify the signed response. When the result of the verification is
positive the AS will allow the user to access the Internet respectively it's services.
The billing functionality in this scenario may be based on the GPRS billing mechanisms
but may use other options like content based billing too. This would require additional
functionality installed on the access server, the billing and service provider's machines.
Therefore, this scenario requires more effort to realize billing but is in turn more flexibly
with regards to the payment method used.
Same as for the previous scenario.
Use of a combined SIM/WIM
Fig. 6: Architectural elements for SIM- based authentication using a combined SIM/WIM
The architectural components for this scenario are depicted in figure 6. The scenario is
based on public key cryptography implemented in the so called WAP identity module
(see Wireless Identity Module, Part: Security, Version 12-July-2001, WAP-260-
WIM-20010712-a) and therefore enabling public Bluetooth access using wireless PKI
functionality. This scenario not necessarily requires external parties like mobile phone
operators to establish a trust relationship between the access server of a public Bluetooth
access provider and the user device. This assumes that the user as well as the access
server respectively the public Bluetooth access provider trust the certification authorities
(trust centres) which issue the certificates. The scenario furthermore requires that the
mechanisms of the WIM- Card originally designed for the wireless application protocol
implemented in most of the currently available mobile phones in Europe will be
externally accessible. Another problem with the WIM- functionality results from its
relation to WTLS. This may narrow the applicability of this mechanism to scenarios
where a SSL-like authentication is sufficient. Even though WAP provides application
level signing through WMLScript this functionality may not be applicable for the public
Message Sequence Charts
Fig. 7: Message sequence chart for SIM- based authentication using a combined
Figure 7 shows the message sequence chart for the WIM- based authentication. Upon a
service request from the user's device the AS will send it's certificate and a request for the
client certificate to the user's device. The device will verify the server's certificate and
then fetch the user's certificate from the WIM to send it to the AS. The AS will also
verify the user's certificate and if all went well allow the user to access to it's services.
Same as for the previous scenario.
Same as for the previous scenario.
All of the above mentioned SIM- based access mechanisms require access to the SIM-
card which is usually inserted into the mobile phone. Therefore, the access to the SIM-
card is assumed to happen over the Bluetooth link. This requires an appropriate Bluetooth
profile enabling such transactions. Currently the Bluetooth Car Working Group is
specifying the so called SIM- Access- Profile. This profile provides a mechanism to
remotely talk to a SIM, the mobile phone respectively the Server just mediates the
communication between the client- phone and the SIM. The profile solves the scenario
for which it was developed which is: "Bring a mobile phone into a car and use the SIM of
this phone with the car's built-in GSM- phone". To come up with new services, like the
ones discussed in this former sections, using the SIM over a Bluetooth connection it must
be possible to have remote access to some of the SIM's functionality. The SIM Access
profile currently prohibits access to SIM in any "non-car" scenario. For an universal
application of the SIM access profile it must be extended to allow for simultaneous use of
SIM and other applications without deactivation of the radio link, it must be possible to
have the phone permanently active and use the SIM simultaneously. This may obviously
result in a more complex profile specification and implementation but otherwise the
necessary access to the SIM for most exciting applications like user authentication, e-
signature and so on over Bluetooth is not possible.
Apart from this requirement there are also other requirements regarding SIM- based
access. Using the SIM Toolkit approach requires the local access to SIM Toolkit
application via Bluetooth. Currently SIM Toolkit applications will be triggered via a
menu which is added to the phones menu structure or via the receipt of a special SMS,
requiring a GSM radio link. So they communicate via visual output and input via the
phones keyboard and/or via SMS. There are no means to talk to an application via
Bluetooth. Therefore there are interfaces and protocols missing enabling a TCP/IP- like
addressing of and communication to SIM Toolkit applications via Bluetooth, see figure 8.
Fig. 8: A possible Bluetooth/USIM communication Stack
Using the WIM requires that the mechanisms of the WIM- Card originally designed for
the wireless application protocol implemented in most of the currently available mobile
phones in Europe will be externally accessible. Another problem with the WIM-
functionality results from its relation to WTLS. This may narrow the applicability of this
mechanism to scenarios where a SSL-like authentication is sufficient. Even though WAP
provides application level signing through WMLScript this functionality may not be
applicable for the public access scenario.
As much as SIM- based access is appealing, there remains some work to do to make it a
convenient means for future applications. Some information and different viewpoints
regarding the discussed scenarios can be found in the results of the Eurescom Project
1005, TI3 in section 2.
Tutorial: Integrating voice and stereo on a single Bluetooth device
Users don't want to carry separate Bluetooth devices but designing
the ability to play voice and music on one device has challenges
By Yogesh Kamat Mhamai and Bikash Chowdhury, Impuslesoft
Wireless Net DesignLine
July 20, 2006 (5:00 PM EST)
All this leads to the following conclusion. There is no consistent approach adopted by
Bluetooth music players for addressing the AVRCP Pause / Play semantics The lack of
agreed upon guidelines increases the design and implementation complexity for the
Bluetooth stereo headset.
It's in the implementation
Let us now comprehend the other piece of the puzzle—the mobile phones.
In the mono world, mobile phone vendors adopted a simple approach of maximizing
voice quality and justifiably so. Today there are more than 100 million phones with
Unfortunately, they vary widely in their Bluetooth voice implementation. For
example, some mobile phones require ACL + SCO connection to be established upon
call arrival, while some require the ACL link to be always on, and the SCO link to be
established only on call arrival; others choose to have the SCO link always on.
In addition, the SCO packet type (HV1, HV2, HV3) supported by the mobile phone
can vary between vendors as well as between models from the same vendor. This is
shown in Figure 6.
6. Scenarios to be addressed for Bluetooth voice depending on mobile phone.
Figures 7 and 8 show the sequence chart for ACL link on call arrival and ACL
link always on.
7. ACL link on call arrival.
8. ACL link always on.
Real life configurations for the music player and mobile phone that the Bluetooth
stereo headset designer needs to address stem largely from implementation
decisions taken by either or both the music player and mobile phone vendor.
Imagine a case where AVRCP Pause / Play is implemented using A2DP Suspend /
Start, and the mobile phone has the ACL Link Always On (SCO Link on Call Arrival)
and supports only HV1 packet.
If the Bluetooth stereo headset was streaming music at say 350 kbps bit rate, any
request for SCO connection with HV1 packet type will be rejected by the Bluetooth
baseband in the Bluetooth stereo headset.
This is because HV1 packet type requires the entire bandwidth " HV1 packet is a
single slot packet type carrying 10 bytes of information and needs to be transmitted
once in every two time slots; the piconet master needs 1 slot to send the HV1 packet
and the next slot to receive the HV1 packet " effectively taking up the entire
In the presence of an existing ACL link streaming at 350 kbps (which in an ideal
world will eventually go to Suspend mode upon Call Arrival), the Bluetooth baseband
in the Bluetooth stereo headset knows it cannot meet the bandwidth requirement of
a simultaneous SCO link with HV1 packet type and rejects the request for SCO
connection. This is obviously a big problem for mobile phones that support only HV1
Figure 9 illustrates the sequence chart for HV1 SCO packet type connection +
suspend / start.
9. Sequence chart for HV1 SCO packet type connection + suspend / start.
Imagine another situation where the Bluetooth mobile phone supports HV3 packet
type. The Bluetooth baseband on the Bluetooth stereo headset will accept the
incoming connection—the piconet master requires 1 slot to send an HV3 packet, the
next slot to receive the HV3 packet; the next 4 slots and hence bandwidth, is
available before the master needs to send the next HV3 packet.
However, if the Bluetooth music player has implemented the AVRCP Pause / Play
using the Streaming Silence mechanism, the Bluetooth stereo headset will have
problem managing an ACL link that is streaming data (silence) and a SCO link
10. Sequence chart for HV3 SCO packet type + streaming silence.
Another problem caused by less than ideal implementation is the handling of button
press. There are instances when the mobile phone streams beeps for any button
press on the SCO link when music is streaming on the ACL link.
The user experience is unpleasant. Whenever a key is pressed, a beep is played out
on the Bluetooth stereo headset. This requires pausing the music, switching to the
SCO link, playing the beep, resuming the music only to interrupt it again the next
time a key is pressed on the mobile phone.
A workaround is to ask the consumer to disable the key pad beeps on the mobile
phone. This is both inelegant and expensive. It requires support calls, documentation
and user education and is therefore unacceptable.
11. Sequence chart for SCO Beeps on mobile phone.
There are multiple configurations that a Bluetooth stereo headphone and a Bluetooth
mono headset need to take care of independently. When both the Bluetooth stereo
and Bluetooth mono features need to come together, these configurations multiply
leading to increased complexity of the Bluetooth stereo headset design.
Resolving basic options
In the past, mobile phone vendors have made product choices that were justified in
the isolated context of the mobile phone use case. One example is opting for HV1
packet type for the best quality audio as compared to HV3 packet type support.
Similarly, Bluetooth music player vendors have made choices that work well in a
narrow use case—for example using Streaming Silence for AVRCP Pause / Play. The
limitations imposed by such choices are proving to be very expensive in the world of
stereo-mono co-existence. The recent formation of AV-HFP working group within the
Bluetooth SIG is anticipated to help address this very issue.
There are a host of other systemic issues that need to be addressed in designing a
Bluetooth stereo headset. For the sake of completeness, we will briefly touch upon
• Managing MIPS requirement in single chip solutions during switchover. The
MIPS load may shoot up to 90 to 95 percent of the available horsepower in
single chip solutions as most Bluetooth basebands are designed optimally for
cost. Care must be taken to handle this peak MIPS load.
• Managing jitter during switchover. While jitter is always a major challenge in
wireless streaming, it becomes particularly severe during switchover. Coupled
with the peak MIPS load, this becomes a sticky problem to solve.
• Latency. Latency needs to be as small as possible so as to present a near-
wired user experience. There are two components to this " call arrival and
resumption of music after call is over. In the first case, if latency is high, the
call might be dropped, while in the latter, user might feel that music is being
lost during switchover. In either case, user experience suffers.
The requirement of Bluetooth music and voice to co-exist brings to the fore technical
and non-technical challenges. The good news is that these challenges are not
insurmountable because they relate largely to implementation choices made by
individual companies and absence of a cohesive guideline.
These challenges have been recognized and are being addressed. Through co-
ordination at the consortium level (Bluetooth SIG) as well as by individual
companies, it is possible to convert the potential into a technical and commercial
Debugging Embedded Bluetooth Designs
By Clifford Chow and Gilbert Goodwill, Wind River
The Bluetooth market is primed for growth, pushing designers to quickly get
systems to market. By using visualized message sequence charts, designers can
accelerate development cycles.
Bluetooth developers are in crunch time. Interoperability headaches, high costs, and
overhyped capabilities have slowed the rollout of Bluetooth-enabled products. Now
that many of these problems have been curbed, the Bluetooth market is primed to
grow. But to succeed equipment and chip developers have to get their Bluetooth
products to market in a hurry or risk the chance of being left out of the Bluetooth
game all together.
Debugging is a vital element for Bluetooth products come to life. However, it can
also be one of the biggest bumps in the Bluetooth development process. Immediate
analysis of debug output may not always be readily available so acquiring the debug
information and downloading it from the embedded device to a host development
environment requires special attention. And depending on the host stack
implementation, timing issues between various stack layers can hinder the use of
standard host-target debuggers with breakpoints.
A better approach would be to combine classical breakpoint methods for immediate
control with time-stamped logging and analysis of the logs after their acquisition. In
this article, we'll layout some of the key headaches designers will face during the
Bluetooth debugging process. We'll also show how strong development tools that
allow developers to integrate operating system and task information into message
sequence charts can make a big difference.
Challenges in Embedded Design
Most embedded Bluetooth designs share functionality across two processors. The
host processor houses the Bluetooth host stack and applications while an auxiliary
baseband processor, generally housed in an RF/baseband module, controls the RF
One main reason that embedded Bluetooth designs fail is because developers do not
consider the multiprocessor nature of these designs. Designers can be so focused on
looking for problems in the code, that they overlook when the host stack fails to
initialize its communication with the baseband processor.
The host stack's application programming interface (API) also causes failures during
the debugging process. The application may not call the correct sequence of APIs
and hence receives a strange return result or no result back from the host stack.
An improperly configured serial interface also contributes to debugging problems.
Incorrect baud rates or flow control settings can cause the embedded device's serial
driver not to respond during host stack initialization. Thus when a host stack fails to
initialize and synchronize with the baseband, it won't respond to any application
While the situations are above troublesome, they are not the biggest culprit of
debugging headaches in an embedded Bluetooth design. On the contrary, the
varying nature of host stacks creates even bigger problems for engineers. In general,
each vendor features a unique host stack. Thus designers must implement different
debugging methodologies and approaches when working with various stacks.
One way to solve this problem is by placing some type of protocol analyzer between
the embedded device and the Bluetooth RF module. The analyzer can help ensure
the communication port of embedded device is configured correctly that the module
receives the software reset command from the host stack and responds
A more effective method, however, is the use of a message sequence chart (MSC),
which is a diagramming method that depicts the sequence of commands flowing
between two devices or layers of an application (Figure 1).
Figure 1: Using an MSC, a client application performs a request to the host stack to
discover any other Bluetooth devices within range.
The MSC chart allows the developer to view the request sent from the application as
it is handled and travels through the various layers of the Bluetooth host stack. The
developer can then compare this sequence chart against a standard and check to see
that everything is behaving as expected. If the developer receives a negative
response to the request, then he/she can look at the MSC trace, and pinpoint which
layer originated the negative response.
Debugging Access Points
In essence, the LAN access profile (LAP) is essentially a point-to-point protocol (PPP)
stack communicating to a peer over a Bluetooth connection that will provide IP
connectivity. Any PPP stack should be able to be used in conjunction with the
Bluetooth serial port profile (SPP) to achieve connectivity.
While LAP is a nice protocol for establishing communication between access points
and clients, it is also a source of headaches for designers. Imagine a scenario where
one client has connected via Bluetooth to an access point, established a PPP
connection, and pushed a 100-KB file with an FTP application. In this scenario, a
problem occurs when another Bluetooth client attempts to retrieve that file via FTP
and the transfer halts at a random point during the transmission. Although the PPP
link between devices is "up," both devices can no longer "ping" each other.
Lockup issues such as these can be caused by a number of factors. For one, the
Bluetooth host stack can drop packets if it is not able to communicate with the RF
module correctly or internally. Second, a serial-port emulation, PPP stack, or FTP
application can be handling traffic incorrectly. Debugging this issue is complicated by
the fact that only a binary image of the PPP source code may be available to the
developers. Proper development tools to assist the developer in understanding why
the file transfer is halting are necessary to identify a solution.
A good test for "burst" traffic over the Bluetooth serial-port emulation is to open a
file pointer to a 10-KB text file and then send various sized fragments of the file over
the serial port emulation to the peer. Sending the test data file through the
Bluetooth host stack allows the developer to determine whether or not the host stack
is communicating properly with the baseband processor embedded in an
RF/baseband module, and if the SPP is handling the data traffic send requests.
However, increasing the size of the data fragment being sent through the serial-port
emulation can result in the test application "freezing up." To illustrate this point, let's
turn to Figure 2, which displays an MSC graph of the recorded freeze in the system
Figure 2: Serial port emulation sending one packet of data.
By itself, Figure 2 indicates to the developer that the test application requested data
to be sent, and the data was confirmed as having been sent. So why didn't the test
application continue sending the rest of the file data?
The answer to this question comes from extrapolating additional data from the data
graphs. Collecting information about tasks, such as any memory allocation or
semaphore issues, can help developers understand why the test application is no
longer sending data.
A test application was designed to send data file fragments in 800-B chunks.
However, collected data shown in Figure 3, says that although an 800-B memory
allocation was made, the actual data sent through the stack is a fraction of this (only
0x121 bytes were allocated from the assigned memory partition). The developer can
also see that there is a semaphore that was set by the test application task that has
not been released.
Figure 3: Serial port emulation message flow with memory and semaphore
In the example above, the serial-port emulation drivers were asked to send 800
bytes of data at one time. However, it broke the 800-B block down into smaller
chunks. After successfully sending the first 0x121 bytes, it didn't send the rest of the
original data block because it was waiting for the test application to prompt it.
Meanwhile the requesting test application is waiting for the serial emulation send
buffers to be empty before it can send more data, which caused the "lockup" in the
The solution to this problem is to fix the serial-port emulation routines to read from
the data buffer until all data is sent without being prompted by the test application.
With the appropriate modifications in place, the code now transfers data in various
sizes as required when doing real-life data transfers with a PPP stack.
The Benefit of a Visualized MSC Tool
As designers can see from Figure 3 above, there's a lot of power using a visualization
tool with time stamping versus a standard MSC-style graph. Figure 3 shows the
precise timing of the events, while the standard graph in figure 1 has only the
events' order. In addition, the visualization tool can display information about the
state of the host stack processes. With the standard MSC diagrams, the developer
knows that a message is sent into the host stack, but they do not know when that
message is handled by the receiving task.
In an embedded real-time system, the time required to handle a message is a critical
ingredient. A visualization tool can present information that allows the developer to
understand why a task could not handle a message in a timely manner. Reasons can
include incorrect priority assignments, or resource contention.
By examining the visual flow of the message trace, the developer can view the
source of an error message returned to the application. With the more advanced host
development platforms, the MSC log can be over-laid with other embedded task
event information. These events (such as task memory allocation, semaphore usage,
and task suspension) can contribute to a host stack layer incorrectly handling the
request message and returning an error status to the application.
Take the example shown in the earlier MSC (Figure 1) and in the visualized MSC log
graph show in (Figure 4). The sequence of messages pictured in each begins with
an indication of data coming into the host stack from the HCI layer. This indication is
then passed "up" (to the left in Figure 1 and down in Figure 4) the stack to the
server application. Once the message has been received at its destination, an
appropriate response message is sent from there to the RFCOMM (COM) layer.
Figure 4: Visualized MSC log graph.
One might expect this message to immediately be passed in turn down the stack
back towards the HCI layer. On the plain MSC, one sees instead another message, a
request for more data, passed from the server to the COM layer. Indeed, the same
sequence of messages can be seen in the visualized MSC log graph, but the
additional information there explains what is happening. While the first message
from the server task made the COM layer "READY" to run, indicated by the green
"saw-tooth" line, the CPU was not available for it to actually execute. (Executing
tasks are shown with a thick green line.)
Instead, the server did not relinquish the CPU, presumably processing the
information it had received. All contexts seen here are running at equal priority. It is
not until the server makes a request for more data, in its second message to COM
that it gives up the CPU awaiting confirmation of that request.
Once the server frees the CPU, COM can now execute. It processes both messages,
the response to the previous incoming data and the request for more, and passes
them down to L2CAP. From there the messages propagate "down" to the HCI layer
(or its "sub-layers" for reading and writing, HCR and HCW). This sequence completes
with a confirmation, XXX_DATA_CNF, being passed back "up" the stack to the
server, confirming that its request for more data has been handled.
The comparison of figures 1 and 4 indicates some of the advantages of the visualized
log approach. The supplementary information on task states, priorities, and OS
events used within and outside of the Bluetooth stack, allows insight into the
Bluetooth stack's behavior. Developers needn't wonder why a message didn't
propagate or yielded a negative result, but instead can find the cause directly.
Additionally, by using the MSC visual log approach, developers can determine the
correct task and functional thread to set the breakpoint with minimal interference to
other stack tasks.
Summing it Up
Bluetooth is a technology that is being rapidly adopted and as such, it can be difficult
for developers to absorb and integrate the technology. But state-of-the-art
development tools that enable developers to integrate OS events and task
information into message sequence charts can help application developers debug
Bluetooth applications much faster. They can detect incorrect configurations of
Bluetooth stack interfaces, uncover task starvation, and race conditions, and conduct
post-mortem analysis of failed applications.