`(10) Patent No.:
`a2) United States Patent
`Mooreetal.
`(45) Date of Patent:
`*Jul. 26, 2005
`
`
`US006922548B1
`
`(54) PROVIDING REMOTE NETWORK DRIVER
`INTERFACE SPECIFICATION SERVICES
`OVER A WIRELESS RADIO-FREQUENCY
`MEDIUM
`
`(75)
`
`om:
`Inventors: Timothy M. Moore, Bellevue, WA
`(US); Ervin Peretz, Redmond, WA
`(US); Kenneth D. Ray, Redmond, WA
`(US)
`
`(73) Assignee: Microsoft Corporation, Redmond, WA
`(US)
`Subject to any disclaimer, the term ofthis
`patent is extended or adjusted under 35
`US.C. 154(b) by 0 days.
`
`(*) Notice:
`
`This patent is subject to a terminal dis-
`claimer.
`
`(21) Appl. No.: 09/556,565
`(22)
`Filed:
`Apr.24, 2000
`(SV)
`Tint. C07 eee cece eeeseeeeeeeeeeeeeeeeeeeeeneees HO04B 7/00
`(52) US. Ch cece 455/41.2; 455/557; 455/528;
`455/463; 709/315; 709/331; 709/332; 710/62;
`710/63; 710/8; 710/65
`(58) Field of Search ........c00.ccccccccn 455/41.2, 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
`
`5,566,331 A * 10/1996 Irwin et al... 707/10
`5,765,155 A *
`6/1998 Nakamura .....
`wee 707/10
`
`2/1999 Blumenau............... 711/162
`5,875,478 A *
`
`be seeeeeeeee 340/7.29
`5,918,158 A *
`6/1999 LaPorta et al.
`9/1999 Mahanyetal. ............. 370/338
`5,949,776 A *
`5,987,060 A
`11/1999 Grenonetal.
`6,480,505 B1 * 11/2002 Johansson etal. .......... 370/449
`6,480,711 BL * 11/2002 Guedalia ..scccccsesssee-: 455/412.1
`7/2003 Nevoet al. cesses 370/278
`6,600,726 B1 *
`
`8/2003 Mizutaniet al. 0.0.0.0... 370/310
`6,603,744 B2 *
`
`EP
`EP
`
`FOREIGN PATENT DOCUMENTS
`0975 123 Al
`1/2000
`0.998 094 AZ
`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 wasoriginally designed for
`bus-attached networking devices. One such network mes-
`sage protocol is the NDIS device managementprotocol. 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/432.2
`
`18 Claims, 3 Drawing Sheets
`
`20
`
` i
`
`|
`
`
`
`\
`[SYSTEM MEMORY
`|__
`2
`] | &
`;
`[ROM
`2a
`
`
`RF
`=
`
`
`
`
`
`
`
`5
`INTERFACE
`UNIT
`iE,
`PROCESSING
`Ra
`OPERATING
`‘SYSTEM
`
`
`INTERFACE|f
`
`NETWORK
`APPLICATION
`
`
`
`
`
`37|HARODISK MAG OISK|OPTICAL DISK) ceaia port
`
`
`ra
`DRIVE
`ORME
`INTERFACE
`
`
`
`INTERFACE
`INTERFACE
`INTERFACE
`54
`PROGRAM
`
`/
`‘TA
`[para aise
`oa
`
`Magneticdisk Opticaldiva:
`drive
`dove
`|
`Modem
`
`
`SarO 1Reyboat
`
`
`
`
`
`
`
`
`
`
`a
`
`Monttor
`=
`
`
`
`rd
`
`2.
`
`35
`
`8
`
`7
`
`8
`
`REMOTE COMPUTER
`
`som
`
`
`APPLICATION
`PROGRAMS:
`ae
`
`1
`
`Exhibit 1027
`Apple, et al. v. Uniloc
`IPR2019-00251
`
`
`
`
`
` MODULES:
`
`
`
`|
`
`45
`
`PERSONAL COMPUTER
`at
`ae
`
`36
`
`zm
`
`|
`
`
`
`Mouse
`a2
`
`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 IEEEInternational 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 Salutation Architecture APIs 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 (MAC) 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 Megowanetal., 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. RichardIII, “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
`
`
`
`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 1 of 3
`
`US 6,922,548 B1
`
`
`
`20
`
`PERSONAL COMPUTER
`48
`
`2
`
`PROCESSING
`UNIT
`
`VIDEO
`ADAPTER
`
`RF
`INTERFACE
`
`23
`
`47
`
`(om
`
`—
`Monitor
`
`64
`
`60
`
`
`4
`
`63 RED -
`evice
`
`
`
`
`
`
`SYSTEMMEMORY
`
`|___ 99
`
`24
`
`BIOS
`
`(RAM)
`
`26
`5
`5
`OPERATING
`SYSTEM | 35
`
`
`36
`
`
`
`
`
`
`NETWORK
`INTERFACE
`
`=
`
`APPLICATION
`PROGRAM
`
`32
`34
`46
`OTHER
`
`
`
`
`MODULES
`DRIVE
`DRIVE
`DRIVE
`SUARACE
`
`INTERFACE|INTERFACE|INTERFACE 54
`
`
`PROGRAM
`/
`DATA
`ee rakey
`
`
`38|hard disk =, . =<
`
`[ssoo)
`drive
`Magnetic disk Optical drive
`drive
`|
`Modern
`T
`30
`|
`28
`
`PROGRAM HARDDISK|MAGDISK|OPTICAL DISK "1
`
`27
`
`80
`
`29
`
`1
`
`an
`
`
`rT
`=
`Keyboard
`
`
`OPERATING|APPLICATION PROGRAM PROGRAM 52
`
`SYSTEM
`PROGRAMS
`MODULES
`DATA
`49
`
`
`
`'
`
`}
`!
`
`;
`
`Mouse
`42
`
`40
`
` | REMOTE COMPUTER
`
`Figure 1
`
`so
`
`36
`
`1d
`
`APPLICATION
`PROGRAMS
`
`3
`
`
`
`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 2 of 3
`
`US 6,922,548 B1
`
`
`
`Application Layer
`
`Presentation Layer
`
`Session Layer
`
`Transport Layer
`
`Network Layer
`
`
`
`
`
`
`
`116
`
`100
`
`102
`
`104
`
`106
`
`108
`
`112
`
`|
`110 rneaaaSpeglGgoY
`
`
`
`
`Data Link Layer
`
`
`Physical Layer
`
`
`Figure 2
`
`4
`
`
`
`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 3 of 3
`
`US 6,922,548 B1
`
`152
`
`
`
`Host Remote NDIS Networking Driver
`
`~~164
`
`Bluetooth Host
`
`Bluetooth Device
`
`160
`
`«dt 162
`
`
`Media Access Control Layer
`
`
`
`
`
`Physical Layer
`
` Control
`
`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 U.S. application Ser. No.
`09/556,567, entitled “Bluetooth Compliant Wireless Device
`Connections As ModemsOr 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 programmersof 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
`componentproviding 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 problemsinher-
`ent in Infrared links, however, a radio frequency connection
`
`10
`
`15
`
`20
`
`30
`
`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.
`
`SUMMARYOF 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 wasoriginally
`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 whichthe 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
`consumerelectronics, 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 maybe located
`in both local and remote memorystorage 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 memoryto 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. A basic
`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 ROMorother 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 skilledin theart that other
`types of computer readable media which canstore 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.
`Anumberof 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
`memorystorage 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 meansfor establish-
`ing communications over the WAN 52. The modem 54,
`which maybe 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 shownare 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 maintainsit 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 variousof 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 modelis 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-
`mentby 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 hardwareitself.
`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 implementedat 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 meansof 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 Hyderet 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 NDISalso provides a driver architecture
`whichis 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 bedistributed 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-
`workinterface 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 NDISspecification 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 messageset
`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
`numberof 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 NDISarchitecture 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 unchangedbecauseit is merely a message transport
`mechanism that passes NDIS OIDs and NDISdata packets
`encapsulated in remote NDIS messages. Furthermore, add-
`ing network functionality in the form of new NDIS OIDsis
`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 OIDsare 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
`
`10
`
`15
`
`20
`
`8
`MTUof the media minus the RNIDSheadersize. The device
`152 can fill
`in the MaxTransferSize value in an NDIS
`
`function call to the largest LZCAP messageit can send. If the
`host 164 has a smaller L2CAP maximum messagesize, it
`can overwrite the returned information with its own maxi-
`
`mum messagesize. 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
`
`ServiceNamecan 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-
`Namecan be set to “PEER”. A device should not advertise
`
`more than one PAN profile with a ServiceName of PEER.
`
`Item
`
`ServiceClassIDList
`ServiceClass0
`ProtocolDescriptorList
`Protocol0
`Protocol1
`ProtocolSpecificParameterO
`
`ProtocolSpecificParameter1
`
`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 NDISdata packets. A data 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 othertraffic. Therefore, a separate LZCAP
`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 wasdescribed above with reference to FIG. 2, control
`messagesare 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 andstatus 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. Messagesto the device 162 can be sent
`in the form of L2CAP Packet Data Unit (PDU). The device
`can be sent a message on the control channel 160 from the
`host 164, and can then send the response on that same
`control channel. One example of such a typical transaction
`for a Blueto