350 likes | 394 Views
USB/1394 on the PC . Mark Slezak Program Manager Windows Device experience group MarkSl @ microsoft.com Microsoft Corporation. USB – Refactoring of USBHub. Stack Update to Improve USB Rewrite of USBHub.sys Improvements include better: Power Management Selective Suspend behavior
E N D
USB/1394 on the PC Mark Slezak Program Manager Windows Device experience group MarkSl @ microsoft.com Microsoft Corporation
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
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
Bluetooth on the PC Robin Heydon Technical consultant Robin.Heydon @ csr.com CSR plc Vatsal Bhardwaj Program Manager Windows Device experience group Vatsalb @ microsoft.com Microsoft Corporation
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
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
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)
New Features for Longhorn –Core Stack Improvements • Synchronous connection oriented links (SCO) • Enhanced Synchronous connection orientedlinks (eSCO) • Improved AFH channel interference avoidancewith 802.11 • Support for newer, faster hardware – EDR radios
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 isprovided with RFCOMM sockets (published as part of SDK) and VCOM ports
New Features for Longhorn – Extensibility (con’t) • Out of scope • Providing interface to HCI layer to enable 3rd partiesto 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
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
Bluetooth Protocol Stack on Longhorn User Mode ExtensibilityPotential Clients:Sync Software, Imaging Software BPP BIP FTP Profile Sync Profile User mode OPP HS Profile VCOM DUN HF Profile HID PANU HCRP CT Profile SPP Kernel modeextensibility Primary Client:Audio profiles A/V Profiles Audio Stack SCO RFCOMM Audio Stack L2CAP Kernel mode New Proposed DDI SCO L2CAP SDP New CoreComponent HCI ExistingComponent Open to 3rd-PartyDevelopment Hardware
Bluetooth driver development interfaces overview Robin Heydon Technical Consultant CSR plc
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
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…
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
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
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
Bluetooth Roadmap Features That are Interesting to Microsoft • Bluetooth QoS • Efficient service discovery • Alphanumeric PINs • Simple pairing
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
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
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 duringdevice discovery
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
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 SDKhttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/bluetooth/bluetooth/bluetooth_start_page.asp
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
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
Contact Information • For feedback on Microsoft stack for Bluetoothor general Bluetooth feedback • Bthfb @ microsoft.com • For feedback on Microsoft SDK for Bluetooth • Bthapi @ microsoft.com
Summary • Product name: Microsoft stack for Bluetoothon 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 theirdevices using the Microsoft SDK for Bluetooth,Microsoft DDK for Bluetooth
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
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 usedto invoke our UI • Link to SDK • http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bluetooth/bluetooth/bluetooth_start_page.asp
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 viasocket IOCTL
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
© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.