1. USB/1394 on the PC Mark Slezak Program Manager Windows Device experience group MarkSl @ microsoft.com Microsoft Corporation

2. USB – Refactoring of USBHub Stack Update to Improve USB Rewrite of USBHub.sys Improvements include better: Power Management Selective Suspend behavior Kernel Debugging over USB Beta New feature for Windows codenamed “Longhorn” Allows for debugging systems without legacy ports

3. 1394 – What’s Changed & What Hasn’t Longhorn is primarily bug fixes Improving the current code base is the main goal Improvements to 1394 debugging Removal of IP over 1394 in Longhorn http://www.microsoft.com/whdc/system/bus/1394/IP_1394.mspx

4. Bluetooth on the PC Vatsal Bhardwaj Program Manager Windows Device experience group Vatsalb @ microsoft.com Microsoft Corporation Robin Heydon Technical consultant Robin.Heydon @ csr.com CSR plc

5. Outline Bluetooth on future OS Bluetooth on 64-bit versions of Windows Bluetooth on Longhorn Overview of Bluetooth Driver development interfaces – Presentation from Cambridge Silicon Radio Bluetooth SIG roadmap Improving end user experience with sync on Microsoft’s stack for Bluetooth Call to Action

6. Bluetooth on 64-Bit Versions of Windows Port the existing Windows XP SP2 features to x64 client release No Bluetooth stack on Windows Server 2003 Profiles SupportedWindows XP SP2Windows XP x64 Human Interface Device (HID)XX Dial-up Networking (DUN)XX Hard Copy Replacement Printing (HCRP)XX Personal Area Network user (PANU)XX File push – Object Push Profile (OPP)XX Virtual COM portsXX

7. New Features on Longhorn Profile parity with Windows XP SP2 and Windows XP x64 Core stack enhancements Support for Synchronous Connection Oriented links (SCO) Channel avoidance Improved extensibility L2cap and SDP interfaces SCO/eSCO interfaces Qualification update to Bluetooth 2.0 + EDR (Enhanced Data Rate)

8. New Features for Longhorn – Core Stack Improvements Synchronous connection oriented links (SCO) Enhanced Synchronous connection oriented links (eSCO) Improved AFH channel interference avoidance with 802.11 Support for newer, faster hardware – EDR radios

9. New Features for Longhorn – Extensibility Goals SCO driver development interface Service discovery protocol (SDP) driver development interface L2cap driver development interface Device installation User mode extensibility in the Microsoft core stack for Bluetooth is provided with RFCOMM sockets (published as part of SDK) and VCOM ports

10. New Features for Longhorn – Extensibility (con’t) Out of scope Providing interface to HCI layer to enable 3rd parties to add HCI commands Providing interface to allow addition of custom L2cap/SCO/SDP interfaces Providing a mechanism to install custom RFCOMM protocol layer on top of the L2cap protocol layer

11. Profile Examples Which Can Be Developed on Top of Microsoft Stack for Bluetooth Headset profile Handsfree profile Advanced audio distribution profile A/V remote control profile File transfer protocol profile

12. HCI SCOL2CAP SDP Audio Stack SCO Hardware Kernel mode User mode RFCOMM New Proposed DDI HS Profile Sync Profile CT Profile HF Profile BPP BIP A/V Profiles FTP Profile Audio Stack L2CAP SPP VCOM OPP HIDPANU HCRP DUN User Mode Extensibility Potential Clients: Sync Software, Imaging Software Kernel mode extensibility Primary Client: Audio profiles Bluetooth Protocol Stack on Longhorn New Core Component Existing Component Open to 3 rd -Party Development

13. Bluetooth driver development interfaces overview Robin Heydon Technical Consultant CSR plc

14. Value proposition to CSR Our customers who wish to use a Microsoft Stack Gives them level of flexibility to add profiles We will support them in adding these profiles Leverage current Microsoft Stack Reusing the existing robust code base Add functionality that our customers want Leverage CSR profile code base Used in many end products already - interoperability

15. Bluetooth DDI Interface Interfaces to Bluetooth L2CAP and SDP Using IOCTLs to perform actions IOCTL_BTH_GET_LOCAL_INFO Reads Bluetooth Local Radio Information BD_ADDR, Version Numbers, Name, Class Of Device, Supported Features IOCTL_BTH_SDP_SUBMIT_RECORD_WITH_ INFO Writes an SDP record that will be published Also includes Class of Device, Security, Browsability IOCTL_INTERNAL_BTH_SUBMIT_BRB Does most of the other useful stuff Create connections, send data, etc…

16. Bluetooth BRB Interface Using Internal Bth Submit BRB, you can: Connect to services BRB_L2CA_OPEN_CHANNEL BRB_L2CA_ACL_TRANSFER BRB_L2CA_CLOSE_CHANNEL Register connectable services BRB_REGISTER_PSM L2CAP_SERVER_INTERFACE ConnectionIndication BRB_L2CA_OPEN_CHANNEL_RESPONSE

17. Example Service L2CAP_SERVER_INTERFACE Associates the PSM with an IndicationCallback function BRB_REGISTER_PSM Registers the PSM as connectable IOCTL_BTH_SDP_SUBMIT_RECORD_WITH_INFO Publishes an SDP record describing the service IndicationCallback (ConnectionIndication) Indicates that a inbound connection has arrived BRB_L2CA_OPEN_CHANNEL_RESPONSE Accepts this inbound connection L2CA_TRANSFER_DATA Transfers data, in and out L2CA_CLOSE_CHANNEL Closes the channel

18. Summary Providing everything that is required Registering of PSMs Registering of SDP records Open / Read / Write / Close L2CAP Channels Connectionless Data Easy to use Easy to extend current stack Add current and new profiles

19. Bluetooth Roadmap Features That are Interesting to Microsoft Bluetooth QoS Efficient service discovery Alphanumeric PINs Simple pairing

20. Bluetooth QoS Myth: EDR will solve my problems of limited Bluetooth bandwidth, when using a stereo headset with other Bluetooth devices (like HID devices, printers, sync with mobile phones). With EDR, I don’t need QoS

21. Bluetooth QoS (con’t) Reality: EDR does increase the Bluetooth bandwidth to 2-3 Mbps, but is not an alternative to QoS, stereo audio, HID devices, printers all operate over ACL links with no channel access guarantees QoS is needed for better coexistence of Stereo audio profiles with other Bluetooth profiles

22. Efficient Service Discovery Current protocol takes a long time to discover Bluetooth devices and resolve their user friendly names  Bad user experience ~ 5-6 sec to discover all Bluetooth 1.2 devices ~ 10-11 sec to discover all Bluetooth 1.1 devices Remote name resolution (RNR) takes an additional 0.5 - 2 sec per device Efficient service discovery reduces requirements to make baseband connections during device discovery  Better user experience Reduces the need to issue RNR during device discovery

23. Improving Sync Experience on Windows OS COM ports challenges User Experience COM ports are hard to configure User must manually select them My sync experience

24. Question: I Am an ISV Writing Sync Applications, What Should I Do? Recommendation: Develop PC applications that use sockets to communicate to Bluetooth devices Socket interfaces are very common Provide richer environment More predictable buffering / data flow Good error status indications More control over connections Link to Online SDK http://msdn.microsoft.com/library/default.asp?url=/library/ en-us/bluetooth/bluetooth/bluetooth_start_page.asp http://msdn.microsoft.com/library/default.asp?url=/library/ en-us/bluetooth/bluetooth/bluetooth_start_page.asp

25. Some of the Partners Who Have Developed Their Sync Applications Using the Microsoft SDK for Bluetooth “Nokia's mission is to offer to the best products and solutions with a superior user experience. Cooperation with industry leaders, such as Microsoft, will enable us to offer truly compelling choices to mobile users. Nokia PC Suite software developed using these new Microsoft’s tools for Bluetooth provides our customers with a great end user experience when they connect and synch their mobile phone with their Bluetooth enabled Windows PC” - Jouni Rapakko, Technology Manager, PC Suite Unit, Nokia

26. Call to Action ALL Install the Longhorn builds on your machines and use the Microsoft stack for Bluetooth Send us your feedback on Bthfb @microsoft.com Driver/third party stack developers Send an email with business justification to bthddi @microsoft.com to request enrollment in beta program and get the Bluetooth DDI design documents Application Developers Use Microsoft SDK for Bluetooth to develop applications Post feedback, questions on the SDK on bthapi @microsoft.com alias OEMs Adopt Microsoft stack for Bluetooth on Longhorn Device vendors Use stronger PINs and Support alphanumeric PINs whenever possible Support Extended service inquiry and Improved service inquiry/response

27. Contact Information For feedback on Microsoft stack for Bluetooth or general Bluetooth feedback Bthfb @ microsoft.com For feedback on Microsoft SDK for Bluetooth Bthapi @ microsoft.com

28. Summary Product name: Microsoft stack for Bluetooth on Longhorn Low power cable replacement technology Microsoft stack for Bluetooth is extensible Value proposition to partners Reduce development cost, time to market for their Bluetooth product Microsoft provides the core stack functionality and APIs Partners can focus on developing profiles Product differentiation Device vendors can develop custom profiles for their devices using the Microsoft SDK for Bluetooth, Microsoft DDK for Bluetooth

29. Appendix

30. Recommendation: Bluetooth Security Use strong PINs Windows XP SP2 recommends the use of 8-character PIN length Support Alphanumeric PINs whenever possible (2005 Bluetooth SIG Roadmap feature) Don’t default to the discoverable state Don’t hardwire the same PINs to all your devices

31. Improving Overall User Experience Recommendation: Use the Bluetooth UI in Windows XP SP2 to discover, connect, and bind remote devices Provide a consistent interface so that users don’t have to learn multiple interfaces The BluetoothSelectDevices API can be used to invoke our UI Link to SDK http://msdn.microsoft.com/library/default.asp?url=/librar y/en-us/bluetooth/bluetooth/bluetooth_start_page.asp

32. Question: I am an ISV... Ideal situation is remote device uses RFCOMM directly without Serial Port profile If remote device uses SPP and depends RS232 status signals like RTS, CTS, RI, etc, then applications can manipulate RS232 signals by using SIO_RFCOMM_SEND_COMMAND socket IOCTL Applications can also implement the other parts of the SPP protocol like RPN and RLS messages via socket IOCTL

33. Community Resources Windows Hardware & Driver Central (WHDC) www.microsoft.com/whdc/default.mspx Technical Communities www.microsoft.com/communities/products/default.mspx Non-Microsoft Community Sites www.microsoft.com/communities/related/default.mspx Microsoft Public Newsgroups www.microsoft.com/communities/newsgroups Technical Chats and Webcasts www.microsoft.com/communities/chats/default.mspx www.microsoft.com/webcasts Microsoft Blogs www.microsoft.com/communities/blogs

35. © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.