JP2003532315A - Generating device drivers - Google Patents

Abstract

  (57) [Summary] The present invention provides a method and a computer program product for providing a network message protocol designed for a bus-independent, originally bus-attached networking device, over an RF link compliant with the Bluetooth specification. One such network message protocol is the NDIS device management protocol. In this way, many computer software products designed to operate on hardwired (or bus-attached) networks can also be used over Bluetooth wireless networks.

Description

Detailed Description of the Invention

CROSS REFERENCE TO RELATED APPLICATIONS This application is incorporated by reference herein in its entirety, April 24, 2000.
Filed on the date "Bluetooth Compliant Wireless
Device Connections As Modems Or Sock
U.S. application Ser. No. 09 / 556,567 entitled "ets (Bluetooth compliant wireless device connection as modem or socket)"
), And “Bluetooth MiniP filed on April 24, 2000.
ort driver model (bluetooth miniport driver model) "in relation to US application no. 556,568 (docket number 204858).

TECHNICAL FIELD The present invention relates generally to wireless interface technology, and more specifically, to
It relates to an interface between a computer software application and a wireless device operating according to the Bluetooth specification.

BACKGROUND OF THE INVENTION To maximize the compatibility between software and hardware components on a computer system, the computer's operating system defines specific interfaces. This interface can be accessed and used by the programmer of the software component, and the designer of the hardware component can provide and support this interface. Thus, the use of this defined interface ensures that the software component is compatible with all hardware components that support that interface. Similarly, providing a particular interface by a hardware component ensures that the software component can detect and access the functionality that the hardware component provides through the interface.

Computers and other electronic devices are typically interconnected through physical cables or wires. These communication paths allow the exchange of data or control information between such devices. However, there is increasing recognition that the elimination of cables and wires for interconnecting devices provides certain advantages. Such advantages include ease of configuration and reconfiguration by eliminating the need to physically add, remove, or move physical media. In addition, the space previously used for the interconnect medium of the device can be used for other purposes. In addition, the use of wireless connections improves the mobility of the device.

One method of providing wireless connectivity between devices uses light waves in the infrared region of the electromagnetic spectrum to link devices. IrDA (Infrared
The Data Association (Infrared Data Association) protocol defines one such connection mechanism. Unfortunately, such mechanisms typically have to operate in a line of sight aligned manner. That is, an opaque obstruction between the transmitter and receiver prevents proper operation. Furthermore, IR transmitters are generally not omnidirectional when incorporated into a communication device, and therefore, to operate properly, within a certain nominal deviation, such as 30 degrees, the direction of the receiver is approximately the same. Have to turn to. Finally, IR transmitters are generally very low power devices, and therefore IR
The range of links is usually limited to about 1 meter.

Radio frequency links solve many of the problems inherent in infrared links. However, there is a need for a radio frequency connection scheme that allows various applications to easily access the wireless link via a connection mechanism that provides a suitable interface. One protocol that defines communication between wireless devices over radio frequency links is the Bluetooth specification. Bluetooth devices do not require the lines of sight they have to operate, and their range can be significantly wider than IR links. However, one drawback of the Bluetooth specification is that there are very few computer software programs written for communicating with Bluetooth compliant devices. Another difficulty with the Bluetooth specification is that there are very few high level networking protocols designed to operate over RF links that comply with the Bluetooth specification.

SUMMARY OF THE INVENTION Accordingly, the present invention provides, via an RF link compliant with the Bluetooth specification,
A method and computer program product for providing a network message protocol, originally designed for bus-independent, bus-added networking devices. In this way, many computer software products designed to operate on hardwired (or bus-attached) networks can also be used on Bluetooth wireless networks.

Further features and advantages of the invention will be apparent from the following detailed description of exemplary embodiments, which is described with reference to the accompanying drawings.

While the features of the invention are set forth in detail in the appended claims, the invention, together with its objects and advantages, will be best understood from a reading of the following detailed description in conjunction with the accompanying drawings. Could be

DETAILED DESCRIPTION OF THE INVENTION Referring to the drawings, like reference numbers indicate like elements, and
It is shown as 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 computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract types of data. Moreover, those skilled in the art will appreciate that the present invention may be implemented in other computer system configurations, including handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, etc. It will be appreciated that it can be done. 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.

Referring to FIG. 1, an exemplary system for implementing the present invention is a processing unit 21.
, A general-purpose computing device in the form of a conventional personal computer 20, including a system memory 22, and a system bus 23 that couples various system components, including the system memory, to the processing device 21. The system bus 23 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a local bus, using any of a variety of bus architectures. 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 includes a hard disk drive 27 for reading from and writing to the hard disk 60, a removable magnetic disk 2
Magnetic disk drive 28 for reading from and writing to
And further includes an optical disc drive 30 for reading from and writing to a removable optical disc 31, such as a CD ROM or other optical medium.

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 interface 33, and an optical disk drive interface 34, respectively. The drives and their associated computer-readable media provide personal computer 20 with non-volatile storage of computer-readable instructions, data structures, program modules, and other data. In the exemplary environment described herein, hard disk 60, removable magnetic disk 29, and removable optical disk 3
1 is used, those skilled in the art can store computer-accessible data such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memory, read only memory, etc. It will be appreciated that other types of computer-readable media may be used in the exemplary operating environment.

The hard disk 60, the magnetic disk 29, the optical disk 31, the ROM 24, or the RAM 25 includes a number of programs including an operating system 35, one or more application programs 36, other program modules 37, and program data 38. Modules can be stored. The user can input commands and information to the personal computer 20 via an input device such as the keyboard 40 or the 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 device 21 via a serial port interface 46 that is coupled to the system bus, but other parallel ports, game ports, universal serial buses (USB), etc. You can also connect with an interface. 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, although not shown.

Personal computer 20 uses logical connections to one or more remote computers or devices, such as remote computer 49 or RF device 64,
It can operate in a networked environment. Remote computer 49
May be another personal computer, server, router, network PC, peer device, or other common network node and generally includes many or all of the elements described above in connection with personal computer 20. However, in FIG. 1, only the storage device 50 is shown. The radio frequency (RF) device 64 may be a cellular phone, a digital camera, another personal computer, or other device that includes the ability to communicate over the RF spectrum. The logical connection shown in FIG. 1 includes a local area network (LAN) 51 and a wide area network (W).
AN) 52, and RF connection 63. Such a networking environment
It is common in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the personal computer 20 is connected to the local network 51 via a network interface or adapter 53. Personal computer 20, when used in a WAN networking environment, typically includes a modem 54, or other means for establishing communications over WAN 52. The modem 54 may be an internal device or an external device, and is connected to the system bus 2 via the serial port interface 46.
3 is connected. The personal computer 20 includes an RF interface 62 when used with the RF connection 63. In a networked environment,
The program modules shown associated with personal computer 20 or portions thereof may be stored in a remote 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.

In the following description, unless otherwise stated, the present invention is described with reference to acts and symbolic representations of operations that are performed by one or more computers. Thus, it should be understood that such operations and operations, which are sometimes described as being performed by a computer, also include the manipulation by a processor of a computer of electrical signals that represent data in a structured form. This operation is
The data is transformed or held in a location in the computer's memory system, thereby reconfiguring or changing the operation of the computer in a manner well understood by those skilled in the art. A data structure in which data is held is a physical location in memory that has specific properties defined by the format of the data. However, while the present invention has been described in the foregoing context, it will be appreciated by those skilled in the art that the various acts and operations described below may be implemented in hardware and are not intended to be limiting. .

In accordance with the present invention, referring to FIG. 2, Open Systems Interconnection (OSI)
7-layer model is shown. This model is an industry standard abstraction for computer networking. The application layer 100 directly services the end user and supports the software applications with which the user interacts. The presentation layer 102 provides a mechanism for interpreting data sent from the application layer 100 on one computer to the application layer on another computer. The session layer 104 describes the structure of the transferred data. The transport layer 106 acts as the final error correction layer to ensure that the data is delivered in the correct order and without loss or duplication. The network layer 108 defines the addressing and routing of data on the network. It controls the operation of the local sub-network and also determines which physical path the data should take, given network conditions, service priorities, and other factors. The data link layer 110 controls the transmission of data blocks or packets over the network and provides more basic error correction. Data link layer 1
10 is divided into two sublayers, a logical link control (LLC) sublayer and a medium access control (MAC) sublayer. The LLC sublayer ensures error-free data frame transmission by maintaining logical links, controlling frame flow, ordering frames, acknowledging frames, and retransmitting unacknowledged frames. To do. The MAC sublayer manages access to the network, checks for frame errors and recognizes received frames. Protocols including LLC sublayers require only a minimal transport layer 106. Finally, the physical layer 112 carries signals sent to the network connection 114. Generally, physical layer 112 is implemented in the hardware that connects computer 20 to network connection 114.

The Network Equipment Interface Specification (NDIS) 116 may reside between the network layer 108 and the data link layer 110. NDIS116
May provide a library of interfaces between software and hardware components. The NDIS 116 can define a completely abstracted environment for NIC driver development by providing routines for all external functions that a network interface card (NIC) driver needs to perform. Therefore, NDIS 116
An interface may be provided for communicating between the IC driver and the upper protocol driver and between the NIC driver and the lower NIC hardware itself.

In general, application layer 100, presentation layer 102, session layer 104, transport layer 106, and network layer 108 are implemented with software components running on a computer. Data link layer 110 and physical layer 112 are typically implemented in hardware components such as network interface cards. The NDIS 116 library can be used by software drivers implemented in the transport layer 110 to communicate with network interface card drivers implemented in the data link layer 110. The transport layer driver is a well-known TCP / IP (Transfer Control) generally used on the Internet.
Implement a network protocol stack, such as a Protocol / Internet Protocol (Transfer Control Protocol / Internet Protocol) stack. If the transport layer software driver has a data packet to send, it can call the NIC driver using the interface from the NDIS 116 library and pass the packet to be transferred down. Similarly, the NIC driver uses the interface of NDIS116
The packet can be passed to the NIC itself for transmission over the network. The NDIS 116 interface can call operating system specific components that perform the transmission on the NIC. The NIC driver can also use the NDIS 116 interface to communicate with the transport layer software driver and pass the received data packets or other information onto it.

One example of physical layer 112 is wireless radio frequency (RF) device 64. Device 6
An increasingly popular RF protocol for wireless communication between 4 and computer 20 is the Bluetooth protocol. This is described in "Specification o", which is fully incorporated herein by reference.
f the Bluetooth System (Specification of the Bluetooth System) ", version 1.0B (December 1, 1999), in more detail.
In addition, “Windows (registered trademark) Wireless Ar” presented in Appendix B
"(Bluetooth (registered trademark) wireless architecture)" in Appendix C, "Bluetooth Architecture Ov"
"view (bluetooth architecture overview)", Appendix B, "B
Bluetooth Experience in Windows (registered trademark)
(Bluetooth experience with Windows®) ”and“ Bluetooth Stack in Windows® ”presented in Appendix E.
See also (Bluetooth stack in Windows®). As described in the Bluetooth specification, L2CAP (Logical
Link Control and Adaptation Protocol
(Logical Link Control and Adaptation Protocol) enables high level protocols to operate over Bluetooth compliant RF links. The L2CAP layer is attached to Appendix A and is fully incorporated herein by reference, "Log.
ical Link Control and Adaptation Pro
“Specification of the”, entitled “tocol Specification”.
Bluetooth System (Specification of Bluetooth system) "1.
The OB version, Part D (December 1, 1999), is described in more detail. One such higher level messaging protocol is Microsoft's Remote NDIS (Remote Network Equipment Interface Specification).
This is described in “M., by Hyder et al., Filed Apr. 30, 1999, assigned to the assignee of the present application and fully incorporated herein by reference.
method and System for Abstracting Net
Co-pending Application No. 09 / 302,7 entitled "Work Device Drivers (Method and System for Abstracting Network Device Drivers)"
No. 35 in more detail. As described in this co-pending application, remote NDIS provides scalability without changing the bus-specific message transport mechanism, thereby providing a relatively wide variety of implementations by physical layer 112. It becomes possible to implement such a transport mechanism. Remote NDIS also provides a proven driver architecture for both networking and external bus device models.

Without the present invention, a hardware manufacturer would have to write two drivers, an NDIS miniport driver and a bus or network interface. However, the two drivers can be distributed as a single binary. The first driver, the NDIS miniport driver, exchanges information with the NDIS 116 and communicates with the bus or network interface driver via a vendor-specific API. A bus or network interface driver is bus or network specific and communicates with the hardware via the appropriate bus or network driver. Since both the NDIS miniport driver and the bus or network interface driver are written by the manufacturer of the network device being accessed, they communicate via a vendor-specific API. Therefore, the NDIS miniport is
In order to communicate with the DIS layer 116, it must comply with the NDIS API,
Also, the bus or network interface must obey the appropriate bus or network driver in passing information to the network device, while the interaction between the NDIS miniport and the bus or network interface is completely hard. It is left to the ware maker. Requiring device manufacturers to write two drivers for each device they put on the market
It causes some very serious problems. For example, managing a pure number of device drivers can be difficult and expensive both for hardware manufacturers and operating system developers that may distribute certain device drivers along with software. In addition, the manufacturer
To provide both a connection to S and a bus or network interface,
The capabilities of the network and the characteristics of a particular bus may be combined, making it impossible to update one without the other. Resolving these problems allows for faster deployment of remotely connected networking devices and lower development costs for host-based drivers.

The NDIS miniport driver and the bus or network interface are both provided by the device hardware manufacturer and can be replaced with a remote NDIS miniport layer and a bus-specific or network-specific microport. The remote NDIS miniport layer, and bus-specific or network-specific microports are independent of the particular device being accessed, and thus can be included as part of the operating system. Therefore, hardware manufacturers who write drivers according to the Remote NDIS specification do not have 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 particular bus or network. Since the remote NDIS interface is standardized, the core set host driver can support any number of attached networking devices. This improves system stability and user satisfaction by eliminating the need to install new drivers to support new network devices. The remote NDIS architecture includes a remote NDIS miniport driver that understands the remote NDIS message set and communicates with bus-specific or network-specific microport drivers. In particular, the remote NDIS miniport layer sends NDIS OID (object identifier) and NDIS data packets,
Encapsulates in a data structure that can be passed to the networking device without modification. This data structure is known as a remote NDIS message.

A bus-specific or network-specific microport driver represents an intermediate layer that understands the bus or network that is responsible for passing messages to devices. Thus, the Microport layer receives remote NDIS messages and passes them on to the corresponding elements of the bus or network driver layer. Then
The bus or network driver layer passes the remote NDIS message to the remote NDIS device. Since the network protocol mechanism is abstracted above the bus or network specific microport layer, adding new network functionality can be done by changing only the remote NDIS miniport layer. The microport layer remains unchanged as it is only a message transport mechanism that passes NDIS OID and NDIS data packets encapsulated in remote NDIS messages. Further, all buses or network microports are available to add network functionality in the form of new NDIS OIDs, as a single remote NDIS miniport layer can service them all. The present invention also maintains backward compatibility. When a new NDIS OID is added, the remote NDI
The S device may respond that it does not understand its NDIS OID and therefore does not support its new network capability.

Turning to FIG. 3, a single L2CAP channel, such as L2CAP channel 160, can be used for remote NDIS control communication. Such control communications include control messages, responses to these messages, and device 162.
It contains a message by which the change of state can be indicated. Another L2C
The AP channel 150 can be used to exchange remote NDIS data packets. Data messages can be up to 1500 bytes in length, which takes about 20 ms when using the full Bluetooth bandwidth, but when the data message has to share bandwidth with other traffic. It costs much more than this. Therefore, a separate L2CAP channel 160 is provided to limit the latency in sending control messages. To accommodate multiple networking channels that may be present on device 162, additional L2
A CAP channel can be added.

As described above with reference to FIG. 2, the control message is sent directly to the control layer 158 shown in FIG. 3, while the data is first received by the medium access control layer 154 and then: At the physical layer 156, it can be encapsulated for transmission over a physical network. The control layer 158 is directly connected to both the medium access control layer 154 and the physical layer 156 to facilitate the transmission of response and status signals and to allow immediate control.

Network data is passed between host 164 and device 162 via L2CAP channel 150. This data can be encapsulated in the NDIS packet mechanism on the model already used by the NDIS network stack. The maximum packet length supported by L2CAP is the maximum MTU of the medium.
, Minus the RNIDS header size. Device 152 may send MaxTra up to the maximum L2CAP message (size) it can send.
The nsferSize value can be entered in the NDIS function call. The host 164 can overwrite the returned information with its own maximum message size if its L2CAP maximum message size is smaller. Either the host 164 or the device 162 has control and data L2CAP
Both setups of channels can be started.

The minimum service discovery protocol (SDP) record that 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 standard service discovery descriptions. Personal area network (PAN) services can communicate with each other. It is also possible that the Bluetooth device has multiple PAN services. For example, the cellular phone could have a wireless WAN server that allows the Bluetooth device access to the cellular data network. In such cases, ServiceName may be "WWAN", or a more descriptive name. Alternatively, the cellular phone may have a PAN service that enables an internal PAN service for peer-to-peer communication between devices. In such a case, ServiceName is "PEER
You can set it to ". The device is a P with a ServiceName called PEER.
No more than one AN profile should be advertised.

[0029]

[Table 1]

A remote NDIS Bluetooth device can initiate or receive more than one L2CAP channel, one control channel, and one or more data channels. The message to device 162 may be sent in the form of L2CAP packet data units (PDUs). This device includes a host 164
From the control channel 160, and the device can then send a response on that same control channel. Bluetooth RND
As an example of such a typical transaction of the IS device, there may be the following cases. The host 164 issues Bluetooth WRITE on the control channel with the content configured in the NdisQueryRequest type. Ndis
The RNDIS_OID value of the QueryRequest is OID_GEN_MED
It may be set to IA_CONNECT_STATUS. Upon receiving the Bluetooth data, the device 162 decrypts the NdisQueryRequest and performs necessary actions to determine the connection status. When the device has the information requested by the host in the NdisQueryRequest, the device sends control channel 1
Bluetooth WRI consisting of NdisQueryResponse on 60
Issue TE. In this case, NdisQueryResponse is OID_G
It may be set to EN_MEDIA_CONNECTION_STATUS.

Bluetooth is a peer-to-peer system. Furthermore, the SDP record does not define the difference between host and device system. Therefore, it is possible that the Bluetooth Microport can operate on itself. RND for host only
IS microport only needs to initiate some kind of message,
It only receives certain messages. However, the microport can be a host, a device, or both, so it can handle any messages that either the host or device can receive. Therefore, the microport must be able to handle these messages. A Bluetooth microport can only act as a host microport if it is connected to a cellular phone, for example, or it can be a host / port if it is connected to another machine also running the microport. It can act as both a device. Microports must be designed to avoid vibrations when processing messages.

The remote NDIS includes REMOTE_NDIS_P, including space for transporting fields of NDIS OOB and per-packet information.
It defines the format of the ACKET message. A file of per-packet information can be provided by NDIS if the remote driver specifies that it supports the feature. OOB information may be supported for specific media types. For example, in the case of Ethernet, a peer-to-peer emulation field is not necessary. In such a case, an offset of 44 bytes and the length of the packet information field are not needed. Therefore, in the case of a 1514-byte Ethernet (registered trademark) MTU, L2CAP is used.
MTU can be a minimum of 1554 bytes, wasting about 3% of the Bluetooth bandwidth. This is a problem for slow links. This is D
If the ataOffset is 4, it can be optimized assuming the rest of the RNDIS_PACKET header is null. This can reduce the data overhead by 16 bytes or 1%.

During operation, the Bluetooth microport can be loaded if the remote Bluetooth device supporting the PAN service is in range and able to communicate. By loading the microport,
An initialization message can be sent from the microport. If the remote device is a cellular phone, for example, it can respond with an initialization complete message. As another example, if the remote device is another Windows machine, this too may generate an initialization message. Microport is REMOTE_NDIS_INITIALIZE_MSG, R
EMOTE_NDIS_QUERY_MSG, REMOTE_NDIS_SET
_MSG, REMOTE_NDIS_RESET_MSG, REMOTE_ND
It is also possible to receive special messages such as IS_KEEPALIVE_MSG. For these messages, see “Remo
te NDIS Over Bluetooth Specification
(Remote NDIS via Bluetooth specification) ",
It is described in more detail. This is attached in Appendix F.

All references cited herein, including patents, patent applications, and publications, are
It is fully incorporated herein by reference.

Given the many possible embodiments to which the principles of the invention may be applied, the embodiments described herein with reference to the drawings are exemplary only, and limit the scope of the invention. It should be understood that it should not be interpreted as a thing. For example, one skilled in the art would
The elements of the exemplary embodiments shown as software can be implemented as hardware and vice versa, or the exemplary embodiments can be configured and detailed without departing from the spirit of the invention. It will be understood that it can be modified. Accordingly, the invention described herein contemplates all such embodiments as falling within the scope of the claims and their equivalents.

[Brief description of drawings]

[Figure 1]   1 is a block diagram generally illustrating an exemplary computer system in which the present invention is present.

[Fig. 2]   It is a block diagram which shows the 7-layer network model overall.

[Figure 3]   It is a block diagram which shows generally the layer model with which this invention can operate | move.

[Procedure amendment]

[Submission date] February 13, 2003 (2003.2.13)

[Procedure Amendment 1]

[Document name to be amended] Statement

[Name of item to be amended] Claims

[Correction method] Change

[Contents of correction]

[Claims]

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE, TR), OA (BF , BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, G M, KE, LS, MW, MZ, SD, SL, SZ, TZ , UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, B Z, CA, CH, CN, CR, CU, CZ, DE, DK , DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, J P, KE, KG, KP, KR, KZ, LC, LK, LR , LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT, R O, RU, SD, SE, SG, SI, SK, SL, TJ , TM, TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW (72) Inventor Irvin Perez             United States 98053 Washington             Redmond East Ames Ray             Crane 3649 (72) Inventor Kenneth Dee. Ray             United States 98052 Washington             Redmond Old Redmond             Road 7479 Apartment Dee             320 F term (reference) 5K033 DA17 DB12 DB14

Claims (18)

[Claims] 1. A method of creating a device driver for a wireless device, the steps of abstracting device control commands and data into a device independent format, and establishing a connection independent driver layer, the connection independent driver. A layer receiving the device control commands and data and encapsulating the device control commands and data in a connection independent format; and establishing an intermediate driver layer, the intermediate driver layer including the connection independent format. Receiving a device control command and data encapsulated in a connection and passing the device control command and data encapsulated in the connection independent format to a connection-specific driver layer; and establishing the connection-specific driver layer. And the connection A driver layer of the device receives the device control commands and data encapsulated in the connection independent format and converts the device control commands and data encapsulated in the connection independent format into connection-specific device control commands and data. ,
Sending the connection-specific device control commands and data to the wireless device. 2. The wireless device is capable of receiving wireless communication compliant with the Bluetooth protocol, and the connection-specific device control commands and data are compliant with the Bluetooth protocol. The method described. 3. The method of claim 1, wherein the connection-specific driver layer sends the connection-specific device control commands and data to the wireless device via at least one L2CAP channel. . 4. The connection-specific driver layer sends the connection-specific device control command over a first L2CAP channel and sends the connection-specific data over a second L2CAP channel. The method of claim 3 characterized. 5. The connection-specific driver layer converts device control commands and data encapsulated in the connection-independent format into connection-specific device control commands and data with reference to a service discovery protocol record. The method according to claim 1, characterized in that 6. The connection-specific driver layer sends the connection-specific device control commands and data by segmenting them into packets that are smaller than a maximum transmission unit of a wireless protocol used by the wireless device. The method of claim 1 characterized. 7. A method of communicating with a wireless device, the method comprising: abstracting device control commands and data into a device independent format; encapsulating the device control commands and data in the device independent format into a connection independent format. Converting the device control commands and data encapsulated in the connection-independent format into connection-specific device control commands and data, and transmitting the connection-specific device control commands and data to a wireless device. A method comprising: and. 8. The wireless device according to claim 7, wherein the wireless device is capable of receiving wireless communication conforming to the Bluetooth protocol, and the connection-specific device control commands and data conforming to the Bluetooth protocol. The method described. 9. The method of claim 7, wherein the connection-specific device control commands and data are sent to the wireless device via at least one L2CAP channel. 10. The connection-specific device control command is transmitted via a first L2CAP channel and the connection-specific data is transmitted via a second L2CAP channel. The method described. 11. The method of converting device control commands and data encapsulated in the connection-independent format into connection-specific device control commands and data refers to a service discovery protocol record. 7. The method according to 7. 12. The method of claim 7, wherein the connection-specific device control commands and data are transmitted by segmenting them into packets that are smaller than the maximum transmission unit of the wireless protocol used by the wireless device. the method of. 13. A computer program product comprising a computer-readable medium containing computer-executable instructions for creating a device driver for a wireless device, the computer-executable instructions providing device control commands and data in a device independent format. Abstracting; establishing a connection independent driver layer, the connection independent driver layer receiving the device control commands and data and encapsulating the device control commands and data in a connection independent format. Establishing an intermediate driver layer, the intermediate driver layer receiving a device control command and data encapsulated in the connection independent format, the device control command encapsulated in the connection independent format. Data and data to a connection-specific driver layer; and establishing the connection-specific driver layer, the connection-specific driver layer encapsulating device control commands in the connection-independent format; Receiving data and converting device control commands and data encapsulated in the connection independent format into connection-specific device control commands and data,
Computer program product for transmitting connection-specific device control commands and data to the wireless device. 14. The wireless device according to claim 13, wherein the wireless device is capable of receiving wireless communication complying with the Bluetooth protocol, and the connection-specific device control commands and data comply with the Bluetooth protocol. The listed computer program product. 15. The computer of claim 13, wherein the connection-specific driver layer sends the connection-specific device control commands and data to the wireless device via at least one L2CAP channel. Program product. 16. The connection-specific driver layer sends the connection-specific device control command via a first L2CAP channel and the connection-specific data via a second L2CAP channel. A computer program product as recited in claim 15, wherein the computer program product is a computer program product. 17. The connection-specific driver layer converts device control commands and data encapsulated in the connection-independent format into connection-specific device control commands and data with reference to a service discovery protocol record. 14. A computer program product according to claim 13, characterized in that 18. The connection-specific driver layer sends the connection-specific device control commands and data by segmenting them into packets that are smaller than a maximum transmission unit of the wireless protocol used by the wireless device. A computer program product as recited in claim 13, wherein the computer program product is a computer program product.