US 6,922,548 B1
`(10) Patent No.:
`(12) United States Patent
`
`Moore et al. *Jul. 26, 2005 (45) Date of Patent:
`
`
`US006922548B1
`
`(54) PROVIDING REMOTE NETWORK DRIVER
`INTERFACE SPECIFICATION SERVICES
`OVERA WIRELESS RADIO-FREQUENCY
`MEDIUM
`
`(75)
`
`.
`;
`Inventors T‘méthy M Moore’ Bellevue, WA
`(US)> Em“ Perem Redmond> WA
`(Us); Kennflh D- Ray, Redmond, WA
`(US)
`
`5,566,331 A * 10/1996 Irwin et al.
`................... 707/10
`5,765,155 A *
`6/1998 Nakamura .....
`707/10
`
`2/1999 Blumenau ............. 711/162
`5,875,478 A *
`
`..... 340/7.29
`5,918,158 A *
`6/1999 LaPorta et al.
`............. 370/338
`5,949,776 A *
`9/1999 Mahany et al.
`5,987,060 A
`11/1999 Grenon et al.
`.......... 370/449
`6,480,505 B1 * 11/2002 Johansson etal.
`6,480,711 B1 * 11/2002 Guedalia ................. 455/4121
`
`7/2003 Nevo et al. ............. 370/278
`6,600,726 B1 *
`............ 370/310
`6,603,744 B2 *
`8/2003 Mizutanietal.
`
`(73) Assignee: Microsoft Corporation, Redmond, WA
`(US)
`J
`y
`Sub'ect to an disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`Notice:
`
`*
`
`This patent is subject to a terminal dis-
`claimer.
`
`(21) Appl. No.: 09/556,565
`
`(22)
`
`Filed:
`
`AP“ 24: 2000
`
`Int. Cl.7 .................................................. H04B 7/00
`(51)
`(52) US. Cl.
`...................... 455/412; 455/557; 455/528;
`455/463; 709/315; 709/331; 709/332; 710/62;
`710/63; 710/8; 710/65
`(58) Field of Search ............................. 455/412, 422.1,
`455/463, 557; 528, 41.1; 517; 709/315;
`332; 331; 370/328, 252; 449; 466; 710/62,
`63, 8
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`EP
`EP
`
`FOREIGN PATENT DOCUMENTS
`0 975 123 A1
`1/2000
`0 998 094 A2
`5/2000
`OTHER PUBLICATIONS
`
`Patent Abstracts of Japan, vol. 2000, No. 03, Mar. 30, 2000
`& JP 11 355322 A (Nokia Mobile Phones Ltd), Dec. 24,
`1999 abstract.
`
`(Continued)
`
`Primary Examiner—Marceau Milord
`(74) Attorney, Agent, or Firm—Leydig Voit & Mayer LTD
`
`(57)
`
`ABSTRACT
`
`invention provides a method and computer
`The present
`program product for providing, over a RF link conforming
`to the Bluetooth Specification, a network message protocol
`which is bus-independent and was originally designed for
`bus-attached networking devices. One such network mes-
`sage protocol is the NDIS device management protocol. In
`such a manner, many computer software products designed
`to operate over a hard-wired (or bus-attached) network can
`also be used over a Bluetooth wireless network.
`
`5,497,412 A *
`
`3/1996 Lannen et al.
`
`........... 455/4322
`
`18 Claims, 3 Drawing Sheets
`
`
`
`
`
`if
`41
`
`
`>
`SYSTEMMEMORV —22
`FERSONALCOMPUTER
`Q
`1
`
`
`
`
`‘ M
`n
`u
`m,
`axes
`6‘
`
`_ u
`‘
`
`2°
`52
`PROCE$5INE
`VIDEO
`RF
`
`INTERFADE ‘
`lfiAMl
`_ 25
`UNIT
`mm“
`
`
`
`
`OPERATING
`as RF Dawes SYSTEM
`
`
`
`
`NETWORK
` OTHERmenu
`
`“new
`INTERFACE '
`APPLICA'HON
`
`
`
`
`“ONES
`mmDATA
`
`
`I
`23
`
`
`
`
`
`
`
`
`
`
`
`1
`27
`
`37 mumsx musx ovrmmsx “mum“
`DRIVE
`DRNE
`DRNE
`WTERFACE
`INTERFACE
`INVERFAGE
`INTERFACE
`
`
`
`
`
`
`
`an mam
`.
`,
`Mann-lied“
`5,1,.
`(Malam-
`am:
`1
`”I
`I
`
`
`mhymn:
`Mann
`1
`1
`:
`t
`1
`'
`1
`‘2
`40
`OPERATING
`AFFLICATION
`”$35M
`PROGRAM
`5’
`5va
`page”... W W.
`..
`
`
`
`
`35
`la
`:7
`3’
`REMOVE COMPUTER
`
`
`
`
`
`50/
`
`
`
`AFPUCATKJN
`WIOGRAMS
`313
`
`.0
`
`,
`
`,,
`
`,.
`
`
`
`1
`
`Apple, et al. v. Unlloc
`|PR2019—00251
`
`Exhibit 1027
`Apple, et al. v. Uniloc
`IPR2019-00251
`
`1
`
`

`

`US 6,922,548 B1
`Page 2
`
`OTHER PUBLICATIONS
`
`Post, Guido, et al., Control and Data Flow Aspects in the
`Design of A Wireless Data Radio Modem: A Case Study,
`1996 IEEE International Conference on Acoustics, Speech,
`and Signal Processing—Proceedings, (ICASSP), Atlanta,
`May 7—10, 1996; IEEE International Conference on Acous-
`tics,
`Speech,
`and
`Signal
`Processing—Proceedings,
`(ICASSP), New York, IEEE, US, vol. 6 Conf. 21, May 7,
`1996, pp. 3201—3204, XP000681738.
`Specification of the Bluetooth System, V.1.0B, Dec. 1, 1999.
`Riku Mettala et al., Bluetooth Protocol Architecture (White
`Paper), V1.0, Nokia Mobile Phones, Sep. 29, 1999.
`Brent Miller et al., Mapping SalutationArchitectureAPIs to
`Bluetooth Service Discovery Layer (White Paper), V. 1.0,
`IBM Corporation, Jul. 1, 1999.
`IEEE Standard, 802.11, Part 11: Wireless LAN Medium
`Access Control (ll/(AC) and Physical Layer (PHY) Specifi-
`cations, 1“ Ed. 1999, and Supplements 802.11a—1999 and
`802.11b—1999.
`
`Bob O’Hara and AI Petrick, IEEE 802.11 Handbook A
`Designer’s Companion, Dec. 1999.
`
`Pat Megowan et al., IrDA Object Exchange Protocol, V1.2,
`Counterpoint Systems Foundry, Inc. Microsoft Corporation,
`Mar. 18, 1999.
`
`Universal Plug and Play Device Architecture, v1.0,
`Microsoft Corporation, Jun. 8, 2000.
`
`Golden G. Richard III, “Service Advertisement and Discov-
`ery: Enabling Universal Device Cooperation,” http://com-
`puter.org/internet/, Sep.—Oct. 2000.
`
`ETSI TS 101 369 v7.1.0 (Nov. 1999), Digital Cellular
`Telecommunications System (Phase 2+); Terminal Equip-
`ment
`to Mobile Station (TE—MS) Multiplexer Protocol,
`Global System for Mobile Communications (GSM 07.10
`v7.1.0 Release 1998).
`
`* cited by examiner
`
`2
`
`

`

`US. Patent
`
`Jul. 26, 2005
`
`Sheet 1 0f3
`
`US 6,922,548 B1
`
`
`
`20
`
`47
`
`PERSONAL COMPUTER
`
`21
`
`PROCESSING
`UNIT
`
`43
`
`VIDEO
`ADAPTER
`
`RF
`INTERFACE
`
`23
`
`E
`
`
`"’—
`Monitor
`
`64
`
`62
`
`'
`
`
`
`A;
`.
`63 RF DevIce
`
`SYSTEM MEMORY
`
`.__ 22
`
`
`
`
`
`
`
`BIOS
`
`(RAM)
`
`
`
`OPERATING
`SYSTEM
`
`
`’
`APPLICATION
`PROGRAM
`
`24
`
`26
`
`I—“ 25
`
`__ 35
`
`36
`
`
`
`
`54
`
`
`
`NETWORK
`INTERFACE ’ 53
`
`SERIAL PORT
`INTERFACE
`
`46
`
`51
`
`./._
`m
`Modern
`
`
`OTHER
`PROGRAM
`MODULES
`
`38
`
`HARD DISK
`DRIVE
`INTERFACE
`hard disk
`d five
`
`27
`
`OPTICAL DISK
`MAG DISK
`DRIVE
`DRIVE
`INTERFACE
`INTERFACE
`-—_-.
`F—i'!
`#‘ ,
`—"_"
`MagneIIc dIsk Opucal mm
`dnve
`I
`
`2|8 T
`
`30 T
`
`so
`
`,
`
`29
`
`31
`
`:
`I
`
`.
`'
`
`OPERATING
`SYSTEM
`
`APPLICATION
`PROGRAMS
`
`PSJSEEM
`MODULES
`
`PROGRAM
`DATA
`
`
`
`33
`
`
`"magi
`"'
`Keyboard
`|
`4o
`
`i
`Mouse
`42
`
`52
`
`49
`
`35
`
`35
`
`37
`
`I REMOTE COMPUTER
`
`Figure 1
`
`5°
`
`35
`
`APPLICATION
`PROGRAMS
`
`3
`
`

`

`US. Patent
`
`Jul. 26, 2005
`
`Sheet 2 0f3
`
`US 6,922,548 B1
`
`1 00
`
`102
`
`104
`
`106
`
`1 08
`
`
`
`Application Layer
`
`Presentation Layer
`
`Session Layer
`
`Transpon Layer
`
`
`
`Network Layer
`
`
`
`'
`L
`110 NeMOFKDev'ca'nterfaoespeclfiwtlon/
`
` Data Link Layer
`
`116
`
` 112
`
`Physical Layer
`
`
`Figure 2
`
`4
`
`

`

`US. Patent
`
`Jul. 26, 2005
`
`Sheet 3 0f3
`
`US 6,922,548 B1
`
`152
`
`Host Remote NDIS Networking Driver
`
`
`
`V\j\164
`
`Bluetooth Host
`
`Bluetooth Device
`
`A4/ 162
`
`160
`
`154
`
`Media Access Control Layer
`
`156
`
`
`
`Physical Layer
`
`Figure 3
`
`5
`
`

`

`US 6,922,548 B1
`
`1
`PROVIDING REMOTE NETWORK DRIVER
`INTERFACE SPECIFICATION SERVICES
`OVER A WIRELESS RADIO-FREQUENCY
`MEDIUM
`
`CROSS-REFERENCE TO RELATED
`APPLICATION
`
`This application is related to US. application Ser. No.
`09/556,567, entitled “Bluetooth Compliant Wireless Device
`Connections As Modems Or Sockets” filed on Apr. 24, 2000
`and US. application Ser. No. 09/556,568, entitled “Blue-
`tooth MiniPort Driver Model” filed on Apr. 24, 2000 both of
`which are incorporated herein by reference in their entirety.
`
`TECHNICAL FIELD
`
`This invention relates generally to wireless interface
`technology and, more particularly, relates to the interface
`between computer software applications and wireless
`devices operating in accordance with the Bluetooth speci-
`fication.
`
`BACKGROUND OF THE INVENTION
`
`To provide the greatest compatibility between software
`and hardware components on a computer system, the oper-
`ating system of the computer defines certain interfaces
`which can be accessed and used by the programmers of the
`software components and which are to be provided and
`supported by the designers of hardware components. Thus,
`by using the defined interface, the software component can
`be assured of compatibility with all of the hardware com-
`ponents which support the interface. Similarly, a hardware
`component providing a specific interface can be assured that
`software components will be able to locate and access the
`functionality provided by the hardware component through
`the interface.
`
`Generally, computers and other electronic devices are
`interconnected via physical cables or wires. These commu-
`nication paths allow for the exchange of data or control
`information between such devices. However, it increasingly
`recognized that certain advantages arise from the elimina-
`tion of cables and wires to interconnect devices. Such
`
`advantages include ease of configuration and
`reconfiguration, due to the elimination of the need to physi-
`cally add,
`remove, or displace a physical medium.
`Furthermore, space which would traditionally be used for
`device interconnection media may be given to other uses.
`Furthermore, device mobility is increased through the use of
`wireless connections.
`
`One method for providing wireless connections between
`devices employs a light wave in the Infrared region of the
`electromagnetic spectrum to link devices. The IrDA
`(Infrared Data Association) protocol defines one such con-
`nection mechanism. Unfortunately, such a mechanism must
`usually operate in a line of sight manner. That is to say that
`any opaque obstruction between transmitter and receiver
`will prevent proper operation. Additionally, IR transmitters
`are typically not omnidirectional when incorporated into a
`communicating device, so that for proper operation,
`the
`transmitter must be pointed generally in the direction of the
`receiver, within some nominal deviation such as 30 degrees.
`Finally,
`IR transmitters are typically fairly low power
`devices, and accordingly the range of IR links is usually
`limited to approximately one meter.
`Radio frequency links solve many of the problems inher-
`ent in Infrared links, however, a radio frequency connection
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`scheme is needed whereby a variety of applications can
`easily access the radio link through a connection mechanism
`that provides an appropriate interface. One protocol which
`defines communication between wireless devices through
`radio frequency links is the Bluetooth specification. Blue-
`tooth devices do not require a line of sight with one another
`to operate, and their range can be significantly greater than
`that of IR links. However, one difficulty with the Bluetooth
`specification is that very few computer software programs
`are written to communicate with Bluetooth compliant
`devices. Another difficulty with the Bluetooth specification
`is that there are very few higher level networking protocols
`which are designed to operate over an RF link conforming
`to the Bluetooth specification.
`
`SUMMARY OF THE INVENTION
`
`Accordingly, the present invention provides a method and
`computer program product for providing, over a RF link
`conforming to the Bluetooth specification, a network mes-
`sage protocol which is bus-independent and was originally
`designed for bus-attached networking devices. In such a
`manner, many computer software products designed to
`operate over a hard-wired (or bus-attached) network can also
`be used over a Bluetooth wireless network.
`
`Additional features and advantages of the invention will
`be made apparent from the following detailed description of
`illustrative embodiments which proceeds with reference to
`the accompanying figures.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`While the appended claims set forth the features of the
`present invention with particularity, the invention, together
`with its objects and advantages, may be best understood
`from the following detailed description taken in conjunction
`with the accompanying drawings of which:
`FIG. 1 is a block diagram generally illustrating an exem-
`plary computer system on which the present
`invention
`resides;
`FIG. 2 is a block diagram generally illustrating a seven
`layer network model; and
`FIG. 3 is a block diagram generally illustrating a layer
`model on which the present invention can operate.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`Turning to the drawings, wherein like reference numerals
`refer to like elements, the invention is illustrated as being
`implemented in a suitable computing environment.
`Although not required, the invention will be described in the
`general context of computer- executable instructions, such
`as program modules, being executed by a personal com-
`puter. Generally, program modules include routines,
`programs, objects, components, data structures, etc.
`that
`perform particular tasks or implement particular abstract
`data types. Moreover, those skilled in the art will appreciate
`that the invention may be practiced with other computer
`system configurations, including hand-held devices, multi-
`processor systems, microprocessor based or programmable
`consumer electronics, network PCs, minicomputers, main-
`frame computers, and the like. The invention may also be
`practiced in distributed computing environments where
`tasks are performed by remote processing devices that are
`linked through a communications network. In a distributed
`computing environment, program modules may be located
`in both local and remote memory storage devices.
`
`6
`
`

`

`US 6,922,548 B1
`
`3
`With reference to FIG. 1, an exemplary system for imple-
`menting the invention includes a general purpose computing
`device in the form of a conventional personal computer 20,
`including a processing unit 21, a system memory 22, and a
`system bus 23 that couples various system components
`including the system memory to the processing unit 21. The
`system bus 23 may be any of several types of bus structures
`including a memory bus or memory controller, a peripheral
`bus, and a local bus using any of a variety of bus architec-
`tures. The system memory includes read only memory
`(ROM) 24 and random access memory (RAM) 25. Abasic
`input/output system (BIOS) 26, containing the basic routines
`that help to transfer information between elements within
`the personal computer 20, such as during start-up, is stored
`in ROM 24. The personal computer 20 further includes a
`hard disk drive 27 for reading from and writing to a hard disk
`60, a magnetic disk drive 28 for reading from or writing to
`a removable magnetic disk 29, and an optical disk drive 30
`for reading from or writing to a removable optical disk 31
`such as a CD ROM or other optical media.
`The hard disk drive 27, magnetic disk drive 28, and
`optical disk drive 30 are connected to the system bus 23 by
`a hard disk drive interface 32, a magnetic disk drive inter-
`face 33, and an optical disk drive interface 34, respectively.
`The drives and their associated computer-readable media
`provide nonvolatile storage of computer
`readable
`instructions, data structures, program modules and other
`data for the personal computer 20. Although the exemplary
`environment described herein employs a hard disk 60, a
`removable magnetic disk 29, and a removable optical disk
`31, it will be appreciated by those skilled in the art that other
`types of computer readable media which can store data that
`is accessible by a computer, such as magnetic cassettes, flash
`memory cards, digital video disks, Bernoulli cartridges,
`random access memories, read only memories, and the like
`may also be used in the exemplary operating environment.
`Anumber of program modules may be stored on the hard
`disk 60, magnetic disk 29, optical disk 31, ROM 24 or RAM
`25, including an operating system 35, one or more applica-
`tions programs 36, other program modules 37, and program
`data 38. A user may enter commands and information into
`the personal computer 20 through input devices such as a
`keyboard 40 and a pointing device 42. Other input devices
`(not shown) may include a microphone, joystick, game pad,
`satellite dish, scanner, or the like. These and other input
`devices are often connected to the processing unit 21
`through a serial port interface 46 that is coupled to the
`system bus, but may be connected by other interfaces, such
`as a parallel port, game port or a universal serial bus (USB).
`A monitor 47 or other type of display device is also
`connected to the system bus 23 via an interface, such as a
`video adapter 48.
`In addition to the monitor, personal
`computers typically include other peripheral output devices,
`not shown, such as speakers and printers.
`The personal computer 20 may operate in a networked
`environment using logical connections to one or more
`remote computers or devices, such as a remote computer 49
`or RF device 64. The remote computer 49 may be another
`personal computer, a server, a router, a network PC, a peer
`device or other common network node, and typically
`includes many or all of the elements described above
`relative to the personal computer 20, although only a
`memory storage device 50 has been illustrated in FIG. 1. The
`Radio Frequency (RF) device 64 can be a cellular phone,
`digital camera, another personal computer, or other device
`which includes the capability to communicate through the
`RF spectrum. The logical connections depicted in FIG. 1
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`
`include a local area network (LAN) 51 and a wide area
`network (WAN) 52, and an RF connection 63. Such net-
`working environments are commonplace in offices,
`enterprise-wide computer networks, intranets and the Inter-
`net.
`
`When used in a LAN networking environment, the per-
`sonal computer 20 is connected to the local network 51
`through a network interface or adapter 53. When used in a
`WAN networking environment, the personal computer 20
`typically includes a modem 54 or other means for establish-
`ing communications over the WAN 52. The modem 54,
`which may be internal or external, is connected to the system
`bus 23 via the serial port
`interface 46: When used in
`conjunction with an RF connection 63, the personal com-
`puter 20 includes an RF interface 62.
`In a networked
`environment, program modules depicted relative to the
`personal computer 20, or portions thereof, may be stored in
`the remote memory storage device. It will be appreciated
`that the network connections shown are exemplary and other
`means of establishing a communications link between the
`computers may be used.
`the invention will be
`In the description that follows,
`described with reference to acts and symbolic representa-
`tions of operations that are performed by one or more
`computers, unless indicated otherwise. As such, it will be
`understood that such acts and operations, which are at times
`referred to as being computer-executed, include the manipu-
`lation by the processing unit of the computer of electrical
`signals representing data in a structured form. This manipu-
`lation transforms the data or maintains it at locations in the
`
`memory system of the computer, which reconfigures or
`otherwise alters the operation of the computer in a manner
`well understood by those skilled in the art. The data struc-
`tures where data is maintained are physical locations of the
`memory that have particular properties defined by the format
`of the data. However, while the invention is being described
`in the foregoing context, it is not meant to be limiting as
`those of skill in the art will appreciate that various of the acts
`and operations described hereinafter may also be imple-
`mented in hardware.
`
`In accordance with the invention, and turning to FIG. 2,
`the Open Systems Interconnection (OSI) seven-layer model
`is shown. This model is an industry standard abstraction of
`computer networking. The application layer 100 directly
`serves the end user and supports the software applications
`with which the user interacts. The presentation layer 102
`provides the mechanisms which interpret data being sent
`from the application layer 100 on one computer to the
`application layer on another. The session layer 104 describes
`the organization of the data being transferred. The transport
`layer 106 acts as a final error correcting layer to ensure the
`data is delivered accurately, in the proper sequence, and with
`no loss or duplication. The network layer 108 defines the
`addressing and routing of the data across the network. It
`controls the operation of the local sub-network and decides
`which physical path the data should take, given network
`conditions, priority of service, and other factors. The data
`link layer 110 controls the transmission of blocks of data, or
`packets, across the network, and provides more fundamental
`error correction. The data link layer 10 is divided into two
`sublayers: the logical link control (LLC) sublayer and the
`media access control (MAC) sublayer. The LLC sublayer
`ensures error-free transmission of data frames by maintain-
`ing logical links, controlling frame flow, sequencing frames,
`acknowledging frames; and retransmitting unacknowledged
`frames. The MAC sublayer manages access to the network,
`checks frame errors and address recognition of the received
`
`7
`
`

`

`US 6,922,548 B1
`
`5
`frames. Protocols which include an LLC sublayer need only
`a minimal transport layer 106. Finally, the physical layer 112
`carries the signals which are sent to the network connection
`114. Generally, the physical layer 112 is implemented in the
`hardware connecting the computer 20 to the network con-
`nection 114.
`
`ANetwork Device Interface Specification (NDIS) 116 can
`reside between the network layer 108 and the data link layer
`110. The NDIS 116 can provide a library of interfaces
`between the software components and the hardware com-
`ponents. The NDIS 116 can define a fully abstracted envi-
`ronment for network interface card (NIC) driver develop-
`ment by providing routines for every external function that
`a NIC driver would need to perform. Thus, the NDIS 116 can
`provide interfaces for communication between a NIC driver
`and a overlying protocol driver and between a NIC driver
`and the underlying NIC hardware itself.
`Generally the application layer 100, presentation layer
`102, session layer 104, transport layer 106, and the network
`layer 108 are implemented in software components operat-
`ing on a computer. The data link layer 110 and the physical
`layer 112 are generally implemented by the hardware
`components, such as a network interface card. The NDIS
`116 library can be used by a software driver implemented in
`the transport layer 110 to communicate with a network
`interface card driver implemented at the data link layer 110.
`A transport layer driver generally implements a network
`protocol stack, such as the well known Transfer Control
`Protocol/Internet Protocol (TCP/IP) stack used on the Inter-
`net. If the transport layer software driver has a packet of data
`to be transmitted, it can call the NIC driver by means of an
`interface from the NDIS 116 library, and pass down the
`packet to be transmitted. Similarly, the NIC driver can use
`an interface of the NDIS 116 to pass the packet to the NIC
`itself for transmission across the network. The NDIS 116
`
`interface can call the operating system specific components
`which perform the transmission at the NIC. The NDIS 116
`interfaces can also be used by the NIC driver to communi-
`cate with the transport layer software driver and pass up a
`received packet of data, or other information.
`One example of the physical layer 112 is the wireless
`Radio-Frequency (RF) device 64. An increasingly popular
`RF protocol for wireless communication between device 64
`and computer 20 is the Bluetooth protocol, described in
`more detail in the “Specification of the Bluetooth System”
`Version 1.0B (Dec. 1, 1999) incorporated herein by refer-
`ence in its entirety. See also the “Windows Wireless Archi-
`tecture” presentation at Appendix B, the “Bluetooth Archi-
`tecture Overview” presentation at Appendix C,
`the
`“Bluetooth Experience in Windows” presentation at Appen-
`dix D, and the “Bluetooth Stack in Windows” presentation
`at Appendix E. As described in the Bluetooth Specification,
`the Logical Link Control and Adaptation Protocol (L2CAP)
`allows higher level protocols to operate over a Bluetooth
`compliant RF link. The L2CAP layer is more particularly
`described in “Specification of the Bluetooth System” Ver-
`sion 1.0B, Part D entitled “Logical Link Control and Adap-
`tation Protocol Specification” (Dec. 1, 1999), attached at
`Appendix A, and incorporated herein by reference in its
`entirety. One such higher level messaging protocol is the
`Remote Network Device Interface Specification (Remote
`NDIS) from Microsoft Corporation, described in more detail
`in co-pending application Ser. No. 09/302,735, entitled
`“Method and System for Abstracting Network Device Driv-
`ers” by Hyder et al., filed on Apr. 30, 1999, and assigned to
`the assignee of the present application, which is incorpo-
`rated herein by reference in its entirety. As described in the
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`co-pending application, Remote NDIS provides extensibil-
`ity without change to the bus specific message transport
`mechanisms, allowing implementation on a greater variety
`of such transport mechanisms implemented by the physical
`layer 112. Remote NDIS also provides a driver architecture
`which is proved for both networking and external bus device
`models.
`
`“In the absence of the present invention, hardware manu-
`factures are required to write two drivers, an NDIS miniport
`driver and a bus or network interface. However, the two
`drivers may be distributed as a single binary. The first driver,
`the NDIS miniport driver, exchanges information with NDIS
`116 and communicates with the bus or network interface
`driver through some vendor-specific API. The bus or net-
`work interface driver is bus- or network-specific and com-
`municates with hardware through the appropriate bus or
`network driver. The NDIS miniport driver and the bus or
`network interface driver communicate through a vendor-
`specific API because both drivers are written by the manu-
`facturer of the network device being accessed. Therefore,
`while the NDIS miniport must conform to the NDIS API in
`order to communicate with NDIS layer 116, and the bus or
`network interface must conform to the appropriate bus or
`network driver in passing information to network device, the
`interaction between the NDIS miniport and the bus or
`network interface is completely at
`the discretion of the
`hardware manufacturer.
`
`Requiring device manufacturers to write two drivers for
`each piece of equipment they market presents some fairly
`serious problems. For example, the sheer number of device
`drivers is difficult and expensive to manage, both for the
`hardware manufacturer and for operating system developers
`who may distribute certain device drivers with their soft-
`ware. Furthermore, since manufacturers provide both the
`connection to NDIS and the bus or network interface, the
`network functionality and the specifics of a particular bus
`are likely to be coupled, making it impossible to update one
`without the other. Solving these problems will allow for
`faster deployment of remotely connected networking
`devices and lower costs for developing host-based drivers.
`The NDIS miniport driver and the bus or network
`interface, both of which were provided by the device hard-
`ware manufacturer, can be replaced with a Remote NDIS
`miniport layer and bus- or network-specific microports. The
`Remote NDIS miniport layer and bus- or network-specific
`microports are independent of the particular device being
`accessed and therefore can be included as part of the
`operating system. Therefore, hardware manufacturers writ-
`ing to the Remote NDIS specification are no longer required
`to write host-based drivers for their devices. Remote NDIS
`
`defines a connection-agnostic or connection-independent
`message set along with a description of how the message set
`operates over a particular connection, such as a specific bus
`or network. Because the remote NDIS interface is
`
`standardized, a core set of host drivers can support any
`number of attached networking devices, thereby improving
`system stability and user satisfaction because no new drivers
`must be installed to support a new network device. The
`remote NDIS architecture includes a remote NDIS miniport
`driver that understands the remote NDIS message set and
`communicates with bus- or network-specific microport driv-
`ers. Specifically, the Remote NDIS miniport layer encapsu-
`lates NDIS OIDs (Object IDentifiers) and NDIS data packets
`into data structures that can be passed without modification
`to a networking device. The data structures are known as
`Remote NDIS messages.
`The bus- or network-specific microport drivers represent
`an intermediate layer that understands the bus or network
`
`8
`
`

`

`US 6,922,548 B1
`
`7
`responsible for passing the messages onto the device. Thus,
`the microport layer receives the remote NDIS messages and
`passes them to the corresponding element of a bus or
`network driver layer. The bus or network driver layer then
`passes the remote NDIS message to remote the NDIS
`devices.
`
`Because network protocol mechanisms are abstracted
`above the bus or network-specific microport layer, adding
`new network functionality can be accomplished by changing
`only the remote NDIS miniport layer. The microport layer
`remains unchanged because it is merely a message transport
`mechanism that passes NDIS OIDs and NDIS data packets
`encapsulated in remote NDIS messages. Furthermore, add-
`ing network functionality in the form of new NDIS OIDs is
`available to all bus or network microports because a single
`remote NDIS miniport layer can serve them all. The present
`invention also maintains backward compatibility. As new
`NDIS OIDs are added, a remote NDIS device may respond
`that it does not understand the NDIS OID and therefore does
`
`not support the new network functionality.”
`Turning now to FIG. 3, a single L2CAP channel, such as
`L2CAP channel 160, can be used for Remote NDIS control
`communications. Such control communications can include
`
`the responses to those messages, and
`control messages,
`messages by which the device 162 can indicate a change in
`
`8
`MTU of the media minus the RNIDS header size. The device
`152 can fill
`in the MaxTransferSize value in an NDIS
`
`function call to the largest L2CAP message it can send. If the
`host 164 has a smaller L2CAP maximum message size, it
`can overwrite the returned information with its own maxi-
`
`mum message size. Either the host 164 or the device 162 can
`initiate the setup of both the control and data L2CAP
`channels.
`
`A minimal Service Discovery Protocol (SDP) record
`which can be used for a Bluetooth Remote NDIS device can
`be as shown in Table 1 below. As can be seen, the Remote
`NDIS device uses the standard Service Discovery descrip-
`tion. Personal Area Network (PAN) services can communi-
`cate with each other. It is possible for a Bluetooth device to
`have multiple PAN services. For example, a cellular phone
`can have a Wireless WAN server that gives Bluetooth
`devices access to the cellular data network. In such a case the
`
`ServiceName can be “WWAN”, or an even more descriptive
`name. Alternatively,
`the cellular phone can have a PAN
`service that allows internal PAN service to communicate
`
`peer-to-peer between devices. In such a case, the Service-
`Name can be set to “PEER”. A device should not advertise
`
`more than one PAN profile with a ServiceName of PEER.
`
`10
`
`15
`
`20
`
`Item
`
`ServiceClassIDList
`ServiceClassO
`ProtocolDescriptorList
`ProtocolO
`Protocoll
`ProtocolSpecificParameterO
`
`ProtocolSpecificParameterl
`
`ProtocolSpecificParameterN
`ServiceName
`
`TABLE 1
`
`Definition
`
`Type/Size
`
`Value
`
`UUID/32-bit
`
`Attribute
`ID
`0x0001
`
`0x0004
`
`UUID/32-bit L2CAP
`UUID/32-bit PAN
`Unit8
`N = control
`channel #
`N = data
`channel 1
`N = control
`channel N
`
`Unit8
`
`Unit8
`
`L2CAP
`PAN
`Control
`Channel
`Data
`Channel
`Data
`Channel
`Displayable
`text name
`
`state. A separate L2CAP channel 150 can be used to
`exchange Remote NDIS data packets. Adata message can be
`up to 1500 bytes in length, which takes approximately 20 ms
`when using the full Bluetooth bandwidth, and can greatly
`increase should the data message be required to share the
`bandwidth with other traffic. Therefore, a separate L2CAP
`channel 160 is provided to limit the latency in sending
`control messages. Additional L2CAP channels can be added
`to accommodate multiple networking channels that may
`exist on the device 162.
`
`As was described above with reference to FIG. 2, control
`messages are sent directly to the control layer 158, shown in
`FIG. 3, while the data can be first received by the Media
`Access Control Layer 154 and then encapsulated for trans-
`mission across the physical network at the physical layer
`156. To facilitate the sending of responses and status signals,
`and to allow for immediate control, the control layer 158 is
`connected directly to both the Media Access Control Layer
`154 and the physical layer 156.
`Network data is passed between the host 164 and the
`device 162 over the L2CAP channel 150. This data can be
`
`encapsulated in an NDIS packet mechanism, on the model
`already used by the NDIS network stack. The maximum
`length of packets supported by L2CAP can be the maximum
`
`45
`
`50
`
`55
`
`60
`
`65
`
`A remote NDIS Bluetooth device can initiate or accept
`two or more L2CAP channels: a control channel and one or
`more data channels. Messages to the device 162 can be sent
`in the form of L2CAP Pac