Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. 1 Ref: SIM Access 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. Motivation 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
  2. 2. 2 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.
  3. 3. 3 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- networks. 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 solution convenient. 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 the realization.
  4. 4. 4 Use of the GSM- algorithms Architectural elements 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.
  5. 5. 5 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. Billing issues 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.
  6. 6. 6 Security issues 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 • Communication o SEND SHORT MESSAGE o OPEN CHANNEL, SEND DATA, etc. SIM AT applications can be triggered by: • Phone menu selection • Arrival of SMS
  7. 7. 7 Architectural elements 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 method. 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".
  8. 8. 8 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. Billing issues 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. Security issues Same as for the previous scenario.
  9. 9. 9 Use of a combined SIM/WIM Architectural elements 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 access scenario.
  10. 10. 10 Message Sequence Charts Fig. 7: Message sequence chart for SIM- based authentication using a combined SIM/WIM 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. Billing issues Same as for the previous scenario. Security issues Same as for the previous scenario. Conclusions 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
  11. 11. 11 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
  12. 12. 12 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 Bluetooth support. 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.
  13. 13. 13 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.
  14. 14. 14 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 bandwidth. 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 packet type. Figure 9 illustrates the sequence chart for HV1 SCO packet type connection + suspend / start.
  15. 15. 15 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 simultaneously.
  16. 16. 16 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.
  17. 17. 17 Other challenges 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 these. • 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. Conclusion 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 success story. Debugging Embedded Bluetooth Designs By Clifford Chow and Gilbert Goodwill, Wind River;jsessionid=B5LHADIG0D0TQQSNDLPCKHSCJUNN2JVN?articleID=16505161 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
  18. 18. 18 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 baseband functionality. 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 request. 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 appropriately. 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).
  19. 19. 19 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
  20. 20. 20 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.
  21. 21. 21 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 information shown. 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 application task. 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.
  22. 22. 22 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
  23. 23. 23 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.