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

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
Vatsal Bhardwaj
Program Manager
Windows Device experience group
Vatsalb @ microsoft.com
Microsoft Corporation
Robin Heydon
Technical consultant
Robin.Heydon @ csr.com
CSR plc
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
Profiles Supported
Windows XP SP2
Windows XP x64
Human Interface Device (HID)
X
X
Dial-up Networking (DUN)
X
X
Hard Copy Replacement Printing (HCRP)
X
X
Personal Area Network user (PANU)
X
X
File push – Object Push Profile (OPP)
X
X
Virtual COM ports
X
X
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 oriented
links (eSCO)
Improved AFH channel interference avoidance
with 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 is
provided 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 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
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 Extensibility
Potential Clients:
Sync Software, Imaging Software
BPP
BIP
Sync Profile FTP Profile
User mode
OPP
HS Profile
HF Profile
CT Profile
Kernel mode
Audio Stack
SCO
VCOM
DUN
SPP
RFCOMM
HID
PANU
HCRP
A/V Profiles Kernel mode
extensibility
Audio Stack
L2CAP
Primary Client:
Audio profiles
New Proposed DDI
SCO
L2CAP
HCI
Hardware
SDP
New Core
Component
Existing
Component
Open to 3rd-Party
Development
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 during
device 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 SDK
http://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 Bluetooth
or general Bluetooth feedback
Bthfb @ microsoft.com
For feedback on Microsoft SDK for Bluetooth
Bthapi @ microsoft.com
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
Appendix
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 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
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
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.