WO2009063272A1

WO2009063272A1 - Hid adaptation to attribute protocol

Info

Publication number: WO2009063272A1
Application number: PCT/IB2007/054621
Authority: WO
Inventors: Paivi M. Ruuska; Miika Laaksonen
Original assignee: Nokia Inc
Current assignee: Nokia Inc
Priority date: 2007-11-13
Filing date: 2007-11-13
Publication date: 2009-05-22
Anticipated expiration: 2010-05-13

Abstract

A system for conveying one or more message packets utilizing a wireless communication medium. The wireless communication medium may be utilized to convey message packets between a human interface device (HID) and a host device based on a HID profile. Fragmentation may be done at the HID profile level, and the resulting message packets may be conveyed without the requirement of first establishing lower level messaging channels in a PAL or L2CAP layer by utilizing an attribute protocol that is enabled to convey packet type.

Description

HID ADAPTATION TO ATTRIBUTE PROTOCOL

BACKGROUND OF INVENTION

L Field of Invention:

[0001J The present invention relates to a system for expediting communication in a wireless communication protocol, and more specifically, to increasing the transmission efficiency of human interface device (HID) profile communication by removing the need to establish lower level messaging channels before sending message packets.

2. Background:

[0002] This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.

[0003] More and more, the ability to communicate wirelessly is emerging as a popular feature to include in many devices where wireless communication was previously not contemplated. This popularity may, at least in part, be fueled by rapid technological development in the area of multifunction wireless communication devices (WCD). Consumers may now replace common standalone productivity devices like computers, laptops, facsimile machines, personal digital assistants, etc. with a single device capable of performing all of these functions. Devices including one or more of these exemplary abilities have been embraced by professionals who often find that work can be completed during times that were previously wasted (commutes to and from work, home, etc.)

[0004] However, while a WCD may be empowered with many beneficial features, the small size and power constraints of these devices may also create a hindrance for the user. For example, the operator interfaces installed in these devices are often small, and not conducive to high throughput. As a result, users must rely on peripheral input devices such as keyboards, mice, headsets, etc. in order to perform their work. Further, the small size and power limitations of many devices today also limits the number of physical ports to which wired devices may be connected. Therefore, a WCD must not only be able to support wireless communications with a peripheral device, it must also be able to support connections with multiple peripheral devices being operated concurrently.

[0005] As more and more common devices now include electronic control, there may also be a benefit realized by coupling these devices to a WCD, or possibly another "intelligent" mechanism. In an exemplary scenario, it may be desirable to wirelessly link two or more low power devices in a beneficial relationship, such as linking a wristwatch including health-monitoring intelligence to various wireless sensors placed on a user's body. Simpler communication protocols with reduced power requirements are now being developed so that even devices that have not historically been "computerized" may now provide wireless information to, and in some cases receive wireless information from, a another device. These devices must often run on battery power, and as a result, must rely on simple, power efficient communications in order to be functional.

[0006] Most of the existing wireless communication protocols are either too simple or too complex to make these newly computerized applications workable. For example, radio frequency (RF) communication is efficient and may be powered by a scanning device, however, currently available RF transponder chips are space-limited and usually only provide information. On the other hand, IEEE 802.1 Ix WLAN or "WiFi" is a commonly available and widely accepted wireless solution, but the power requirements for WLAN may not make it efficient enough for small device installations. Bluetooth™ is another short-range wireless protocol that is often used for linking peripheral devices to a WCD. The Bluetooth™ standard was originally designed to replace wires with a wireless medium for simple peripheral input devices. While, Bluetooth™ has now evolved much further than linking headsets and mice, it still may not be the best solution for extremely resource constrained wireless devices, as will be explored further below.

[0007] At least one problem inherent in the Bluetooth™ wireless protocol with respect to wirelessly-coupled peripheral devices is the required initial channel setup and repeated wireless channel establishment steps that must be completed before messages may be conveyed between a peripheral device and the host (e.g., device to which a user interface device may be coupled). For example, messaging for devices classified as user interface peripheral devices may be controlled by a human interface device (HID) profile in Bluetooth . The formalities that must be followed in order to convey these messages includes multiple steps to establish identified channels for sending messages of certain types, such as control messages and interrupt messages, and the repeated connection of these channels. The steps necessary to establish and utilize these channels may be acceptable for more substantial wireless devices, but may place an extreme burden on simpler devices where processing capability and stored energy may be extremely limited resources.

SUMMARY OF INVENTION

[0008] The present invention includes at least a method, computer program, module, device and system for conveying wireless messages. In at least one embodiment of the present invention, a wireless communication medium may be utilized to convey message packets between a human interface device (HID) and a host device without the requirement of first establishing and connecting lower level messaging channels.

[0009] In at least one embodiment of the present invention, a HID profile in a wireless communication medium protocol stack may create one or more message packets. These message packets may, for example, be created in response to activity that occurs in a peripheral human interface device or in a host device. The message packets created by the HID profile may include at least an HID header and a data payload. The message packets may further be one of two types, either control or interrupt message packets. Control message packets may be utilized for bi-directional data requests transmitted between the devices, while interrupt message packets usually contain data that was not requested and that is usually the result of activities or events in one of the devices.

[0010] The Bluetooth™ HID profile currently specifies that HID message packets be sent using a connection protocol that establishes at least two L2CAP wireless channels for control and interrupt messages, respectively. With respect to at least the Wibree™ wireless protocol, the protocol adaptation layer (PAL) defines three transport types for conveying message packets including an attribute protocol. In at least one embodiment of the present invention, the attribute protocol may be utilized to send HID message packets without having to first establish PAL messaging channels. Utilizing attribute packets, a universally unique identifier (UUID) or an attribute handle may identify the type of one or more HID message packets that have been embedded within attribute message packets. [0011] Further, various embodiments of the present invention may use different transmission strategies for conveying HID message packets. For example, HID message packets may be conveyed using a continuous link layer connection, which may be more appropriate for frequent device communication. For more spontaneous communication, a discontinuous link layer connection, or even a broadcast strategy, may be employed to transmit data while conserving energy in a device. In the scenario where broadcasts are utilized, a repeat pattern may be employed to ensure that message packets are received.

DESCRIPTION OF DRAWINGS

[0012] The present invention will be further understood from the following detailed description of various exemplary embodiments, taken in conjunction with appended drawings, in which:

[0013] FIG. IA discloses a modular description of an exemplary wireless communication device usable with at least one embodiment of the present invention.

[0014] FIG. IB discloses an exemplary structural description of the wireless communication device previously described with respect to FIG. IA.

[0015] FIG. 2 discloses exemplary Bluetooth™ and Wibree™ protocol stacks usable in accordance with at least one embodiment of the present invention.

[0016] FIG. 3A discloses an example of multiple wireless peripheral devices attempting to communicate concurrently with a dual-mode radio modem in accordance with at least one embodiment of the present invention.

[0017] FIG. 3B discloses further detail pertaining to the example of FIG. 3 A regarding operational enhancements for managing the operation of a dual-mode modem in accordance with at least one embodiment of the present invention.

[0018] FIG. 4 discloses a more detailed example of a Wibree™ protocol stack in accordance with at least one embodiment of the present invention.

[0019] FIG. 5A discloses an exemplary HID header and a table of HID packet type codes in accordance with at least one embodiment of the present invention.

[0020] FIG. 5B discloses an example of communication packet growth as a part of routing in a typical communication protocol. [0021] FIG. 5C discloses an example of HID communication packet growth as a part of routing in a typical communication protocol when packet fragmentation is performed at the HID protocol level.

[0022] FIG. 6 discloses an example of the steps required to send HID message packets utilizing a connection oriented protocol.

[0023] FIG. 7 discloses examples of HID packets formulated as attribute protocol message packets in accordance with at least one embodiment of the present invention.

[0024] FIG. 8 discloses exemplary communication strategies for attribute protocol message packets in accordance with at least one embodiment of the present invention.

[0025] FIG. 9 discloses an example of the steps required to send HID message packets utilizing an attribute protocol in accordance with at least one embodiment of the present invention.

[0026] FIG. 10 discloses a flowchart of an exemplary process for formulating an

HID message packet utilizing an attribute protocol in accordance with at least one embodiment of the present invention.

DESCRIPTION OF PREFERRED EMBODIMENT

[0027] While the invention has been described in terms of a number of exemplary embodiments, various changes can be made therein without departing from the spirit and scope of the invention, as described in the appended claims.

I. Wireless communication device

[0028] As previously described, the present invention may be implemented using a variety of wireless communication equipment. Therefore, it is important to understand the communication tools available to a user before exploring the various embodiments of the present invention. For example, in the case of a cellular handset or other handheld wireless devices, the integrated data handling capabilities of the device play an important role in facilitating transactions between the transmitting and receiving devices.

[0029] FIG. IA discloses an exemplary modular layout for a device usable with the present invention. WCD 100 is broken down into modules representing the functional aspects of the device. These functions may be performed by the various combinations of software and/or hardware components discussed below.

[0030] Control module 110 may regulate the overall operation of the device.

Inputs may be received from various other modules included within WCD 100. For example, interference sensing module 120 may utilize various techniques known in the art to sense sources of environmental interference within the effective transmission range of the wireless communication device. Control module 110 interprets these data inputs, and in response, may issue control commands to the other modules in WCD 100.

[0031] Communications module 130 may incorporate all of the communication aspects of WCD 100. As shown in FIG. IA, communications module 130 may include, for example, long-range communications module 132, short-range communications module 134 and machine-readable data module 136 (e.g., for NFC). Communications module 130 utilizes at least these sub-modules to receive a multitude of different types of communication from both local and long distance sources, and to transmit data to recipient devices within the transmission range of WCD 100. Communications module 130 may be triggered by control module 110, or by control resources local to the module responding to sensed messages, environmental influences and/or other devices in proximity to WCD 100.

[0032] User interface module 140 may include visual, audible and tactile elements that allow a user to receive data from, and enter data into, the device. The data entered by a user may be interpreted by control module 1 10 to affect the behavior of WCD 100. User-inputted data may also be transmitted by communications module 130 to other devices within transmission range. Other devices in transmission range may further send information to WCD 100 via communications module 130, and control module 110 may cause this information to be transferred to user interface module 140 to display for a user.

[0033] Applications module 180 may incorporate all other hardware and/or software applications on WCD 100. These applications may include sensors, interfaces, utilities, interpreters, data applications productivity and/or entertainment applications, etc. These applications may be invoked by control module 210 to read information provided by various modules, and may in turn supply data to requesting modules in WCD 100. [0034] FlG. IB discloses an exemplary structural layout of WCD 100, in accordance with at least one embodiment of the present invention, that may be used to implement the functionality of the modular system previously described with respect to FIG. IA. Processor 150 may control the overall device operation of WCD 100. As shown in FIG. IB, processor 150 may be coupled to at least communications sections 154, 158 and 166. Processor 150 may be implemented with one or more microprocessors that are each capable of executing software instructions stored in memory 152.

[0035] Memory 152 may include random access memory (RAM), read only memory (ROM), and/or flash memory, and stores information in the form of data and software components (also referred to herein as modules). The data stored by memory 152 may be associated with various software components or applications. In addition, this data may be associated with databases, such as a bookmark database, a productivity software database including business databases for scheduling, email, contacts, etc.

[0036] The software components stored by memory 152 include instructions that can be executed by processor 150. Various types of software components may be stored in memory 152. For instance, memory 152 may store software components that control the operation of communication sections 154, 158 and 166. Memory 152 may also store software components including a firewall, a service guide manager, a bookmark database, user interface manager, and any communication utilities modules or applications required to support WCD 100.

[0037] Long-range communications 154 may perform functions related to the exchange of information over large geographic areas (such as cellular networks) via an antenna. These communication methods may include technologies from the previously described IG to 3G. In addition to basic voice communication (e.g., via GSM), long- range communications 154 may operate to establish data communication sessions, such as General Packet Radio Service (GPRS) sessions and/or Universal Mobile Telecommunications System (UMTS) sessions. Also, long-range communications 154 may operate to transmit and receive messages, such as short messaging service (SMS) messages and/or multimedia messaging service (MMS) messages.

[0038] As a subset of long-range communications 154, or alternatively operating as an independent module separately connected to processor 150, transmission receiver 156 allows WCD 100 to receive transmission messages via mediums such as Digital Video Broadcast for Handheld Devices (DVB-H). These transmissions may be encoded so that only certain designated receiving devices may access the transmission content, and may contain text, audio or video information. In at least one example, WCD 100 may receive these transmissions and use information contained within the transmission signal to determine if the device is permitted to view the received content.

[0039] Short-range communications 158 is responsible for functions involving the exchange of information across short-range wireless networks. As described above and depicted in FIG. IB, examples of such short-range communications 158 are not limited to Bluetooth™, Wibree™, WLAN, UWB and Wireless USB connections. Accordingly, short-range communications 158 performs functions related to the establishment of short- range connections, as well as processing related to the transmission and reception of information via such connections.

[0040] Short-range input device 166, also depicted in FIG. IB, may provide functionality related to the short-range scanning of machine-readable data (e.g., NFC). For example, processor 150 may control short-range input device 166 to generate RF signals for activating an RFID transponder, and may in turn control the reception of signals from an RFID transponder. Other short-range scanning methods for reading machine-readable data that may be supported by short-range input device 166 are not limited to IR communication, linear and 2-D (e.g., QR) bar code readers (including processes related to interpreting UPC labels), and optical character recognition devices for reading magnetic, UV, conductive or other types of coded data that may be provided in a tag using suitable ink. In order for short-range input device 166 to scan the aforementioned types of machine-readable data, the input device may include optical detectors, magnetic detectors, CCDs or other sensors known in the art for interpreting machine-readable information.

[0041] As further shown in FIG. IB, user interface 160 may also be coupled to processor 150. User interface 160 may facilitate the exchange of information with a user. FIG. IB shows that user interface 160 includes a user input 162 and a user output 164. User^* input 162 may include one or more components that allow a user to input information. Examples of such components include keypads, touch screens, and microphones. User output 164 allows a user to receive information from the device. Thus, user output portion 164 may include various components, such as a display, light emitting diodes (LED), tactile emitters and one or more audio speakers. Exemplary displays include liquid crystal displays (LCDs), and other video displays.

[0042] WCD 100 may also include one or more transponders 168. This is essentially a passive device that may be programmed by processor 150 with information to be delivered in response to a scan from an outside source. For example, an RFID reader mounted in an entryway may continuously emit radio frequency waves. When a person with a device containing transponder 168 walks through the door, the transponder is energized and may respond with information identifying the device, the person, etc. In addition, a reader may be mounted (e.g., as discussed above with regard to examples of short-range input device 166) in WCD 100 so that it can read information from other transponders in the vicinity.

[0043] Hardware corresponding to communications sections 154, 156, 158 and

166 provide for the transmission and reception of signals. Accordingly, these portions may include components (e.g., electronics) that perform functions, such as modulation, demodulation, amplification, and filtering. These portions may be locally controlled, or controlled by processor 150 in accordance with software communication components stored in memory 152.

[0044] The elements shown in FIG. IB may be constituted and coupled according to various techniques in order to produce the functionality described in FIG. IA. One such technique involves coupling separate hardware components corresponding to processor 150, communications sections 154, 156 and 158, memory 152, short-range input device 166, user interface 160, transponder 168, etc. through one or more bus interfaces (which may be wired or wireless bus interfaces). Alternatively, any and/or all of the individual components may be replaced by an integrated circuit in the form of a programmable logic device, gate array, ASIC, multi-chip module, etc. programmed to replicate the functions of the stand-alone devices. Each of these components may also be coupled to a power source, such as a removable and/or rechargeable battery (not shown).

[0045] User interface 160 may interact with a communication utilities software component, also contained in memory 152, which may provide for the establishment of service sessions using long-range communications 154 and/or short-range communications 158. The communication utilities component may include various routines that allow the reception of services from remote devices according to mediums such as the Wireless Application Medium (WAP), Hypertext Markup Language (HTML) variants like Compact HTML (CHTML), etc.

II. Wireless communication mediums

[0046] The present invention may be implemented with, but is not limited to, short-range wireless communication mediums. Bluetooth™ is an example of a short- range wireless technology quickly gaining acceptance in the marketplace. A Bluetooth™ enabled WCD may transmit and receives data, for example, at a rate of 720 Kbps within a range of 10 meters, and may transmit up to 100 meters with additional power boosting. Current systems may run at a nominal rate of 1 Mbps. A user does not actively instigate a Bluetooth™ network. Instead, a plurality of devices within operating range of each other will automatically form a network group called a "piconet". Any device may promote itself to the master of the piconet, allowing it to control data exchanges with up to seven "active" slaves and 255 "parked" slaves. Active slaves exchange data based on the clock timing of the master. Parked slaves monitor a beacon signal in order to stay synchronized with the master, and wait for an active slot to become available. These devices continually switch between various active communication and power saving modes in order to transmit data to other piconet members. In addition to Bluetooth™ other popular short-range wireless networks include WLAN (of which "Wi-Fi" local access points communicating in accordance with the IEEE 802.1 1 standard, is an example), WUSB, UWB, ZigBee (802.15.4, 802.15.4a), Wibree™ and UHF RFID. All of these mediums have features and advantages that make them appropriate for various applications.

[0047] Wibree™ is an open standard industry initiative that has been adopted by the Bluetooth™ special interest group (SIG) as an ultra low power (ULP) extension of Bluetooth™ that may enable local connectivity in small devices with technology that increases the growth potential in these market segments. Wibree™ technology may complement close range communication with Bluetooth™-like performance in the 0-10 m range with a data rate of 1 Mbps. Wibree™ is optimized for applications requiring extremely low power consumption, small size and low cost. Wibree™ may be implemented either as stand-alone chip or as Bluetooth™-Wibree™ dual-mode^" chip. More information can be found on the Wibree™ website: www.wibree.com.

[0048] Now referring to FIG. 2, an exemplary Bluetooth™ protocol stack and an exemplary Wibree™ protocol stack are disclosed. Bluetooth™ stack 200 includes elements that may convey information from a system level to a physical layer where it may be transmitted wireless to another device. At the top level, BT Profiles 202 include at least a description of a known peripheral device which may be connected wirelessly to WCD 100 (e.g., in a HID profile), or an application that may utilize Bluetooth™ in order to engage in wireless communication with a peripheral device. The use of the phrase "peripheral devices" is not intended to limit the present invention, and is used only to represent any device external to WCD 100 also capable of wirelessly communicating with WCD 100. Bluetooth™ profiles of other devices may be established through a pairing procedure wherein identification and connection information for a peripheral device may be received by WCD 100 through a polling process and then saved in order to expedite the connection to the device at a later time. After the application and/or target peripheral device (or devices) is established, any information to be sent must be prepared for transmission. L2CAP level 204 includes at least a logical link controller and adaptation protocol. This protocol supports higher level protocol multiplexing packet segmentation and reassembly, and the conveying of quality of service information. The information prepared by L2CAP level 204 may then be passed to an application-optional host controller interface (HCI) 206. This layer may provide a command interface to the lower link manager protocol (LMP) layers, link manager (LM) 208 and link controller (LC) 210. LM 208 may establish the link setup, authentication, link configuration and other protocols related to establishing a wireless link between two or more devices. Further, LC 210 may manage active links between two or more devices by handling low-level baseband protocols. Wireless communication may then be established and conducted using the hardware (modem, antenna, etc.) making up physical layer (PHY) 212. Of course, the above identified layers of Bluetooth™ stack 200 may also be utilized in an order reversed from that disclosed above in order to receive a wireless transmission into WCD 100 from a peripheral device.

[0049] The layers in the standalone Wibree™ stack 220 are similar to the elements previously described. However, due to the relative simplicity of Wibree™ when compared to Bluetooth™, there are actually less layers utilized to achieve wireless communication. W Profiles 222, similar to the profiles used in Bluetooth™, are used to specify applications that may use Wibree for communication and peripheral devices with which a Wibree™ modem may wirelessly communicate (e.g., in a HID profile). The profile adoption layer (PAL) 224 may be used to prepare the information for transmission via wireless communication. Host interface (e.g., HIF and also sometimes referred to as host control interface, HCI, as in Bluetooth™) 226 may provide an interface between the upper layers communicating with applications and schedulers in WCD 100, and the lower layers of the Wibree™ stack 220 which establish and maintain the links to peripheral devices. Lower layers of the Wibree™ stack 220 may further include at least link layer (LL) 228. LL 228 may both establish and maintain wireless communications with other wireless enabled devices through the use of Physical Layer (PHY) 230. Wibree™ LL 228, however, differs significantly from LM 208 and LC 210 in Bluetooth™.

III. Dual-mode modem

[0050] FIG. 3 A includes an alternative exemplary implementation of at least one embodiment of the present invention. Again, in this example the three human interface devices (302, 304 and 306) are attempting concurrent communication with WCD 100 through dual-mode radio modem 300. Radio modem 300 may include local control resources for managing both "radios" (e.g., Bluetooth™ and Wibree™ software based radio control stacks) attempting to use the physical layer (PHY) resources of dual-mode radio modem 300. In this example, dual-mode radio modem 300 includes at least two radio stacks or radio protocols (labeled "Bluetooth" and "Wibree") that may share the PHY layer resources (e.g., hardware resources, antenna, etc.) of dual-mode radio modem 300. The local control resources may include an admission controller ("Adm Ctrl") and a dual-mode controller ("DuMo Manager"). These local control resources may be embodied as a software program and/or in a hardware form (e.g., logic device, gate array, MCM, ASIC, etc.) in a dual-mode radio modem interface, and the radio modem interface may be coupled to, or alternatively, embedded in dual-mode radio modem 300. The interaction of these control resources with the radio protocols utilizing dual -mode radio modem 300 is explained in reference to FIG. 3B.

[0051] With respect to FIG. 3B, an exemplary combination of the two separate radio protocol stacks (previously discussed with respect to FIG. 2) into a single combined entity controlled locally by at least an admission control 304 and a DuMo manager 316 is now disclosed. The two previously described standalone stacks are shown to establish the individual elements that may be incorporated into an integrated dual-mode entity 312. For a more specific discussion of the functioning of admission control 314 and a DuMo manager 316 in terms of managing the operations of dual-mode modem 300, please refer to Application No. 11/538,310, filed October 3, 2006, which is hereby incorporated by reference. Briefly, admission control 314 may act as a gateway for the dual-mode radio modem 300 by filtering out both Bluetooth™ and Wibree™ requests from the operating system of WCD 100 that may result in conflicts. Scheduling information may also be provided by Multiradio controller (MRC) 170, wherein certain periods of operation are allocated to dual-mode radio modem 300 in view of the other active radio modems operating in WCD 100. This scheduling information may be passed down to both the HCI + Extension level of the combined protocol stacks and also to DuMo manager 1228 for further processing. However, if scheduling information from MRC 600 is critical (delay-sensitive), it may be sent through MCS 700 via a direct connection to DuMo Manager 1228. The information received by DuMo manager may 316 then be used to create an interleaved schedule for dual-mode radio modem 300 allowing both the Bluetooth™ and Wibree™ protocols to operate concurrently.

IV. Protocol stacks and packet routing

[0052] FIG. 4 includes a more detailed description of the upper layers of the

Wibree™ communication protocol. The Wibree™ system includes two parts: the Wibree™ Radio 408 and the Wibree™ Host 402. Connection between radio 408 and host 402 goes through the HIF (also known as HCI). Further, PAL 224 includes at least General Access Profile (GAP) 406.

[0053] Application layer 400 may include various software applications that may be executed on computing devices. For example, an application may be a communication utility or productivity program running on WCD 100. An application may use W Profiles 222 in Wibree (e.g. Profile 1, Profile 2, HID profile, etc.) in order to formulate message packets for conveyance utilizing Wibree™ protocol stack 220. This wireless transaction may be supervised by Host Manager 404. The information may then be prepared by PAL 224 and GAP 406 for routing to Wibree™ radio 408, wherein LL 228 may both establish new wireless connections and manage existing connections with peripheral devices through the various resources (modem, antenna, etc.) that make up PHY layer 230.

V. Problems with packet routing in existing devices [0054] Fig. 5 A discloses an example of a HID message packet header 500 in accordance with at least one embodiment of the present invention. The HID header 500 may be one byte, including 8 bits that may specify two message packet characteristics. Bits 4-7 may express a HID packet type, and bits 0-3 may express any necessary parameters required by the particular header type. The various packet types that may be indicated in HID header 500 are shown further in table 502. The disclosed packet types may indicate, for example, whether the packet is a handshake, report, protocol or data packet. Further, the DataC type may be utilized to indicate that a message packet has been broken down into to smaller message packets due to the original packet being too large, and that the following packet is the continuation of the data in the DataC packet. The DataC functionality allows fragmentation of packets to occur at the HID profile level instead of delegating fragmentation to PAL 224 or below, reducing the reliance of the on lower level message packet handling and fragmentation when wirelessly conveying data.

[0055] Fig. 5B discloses a routing example for HID packets being created in a wireless communication protocol stack in accordance with methods currently known in the art. The wireless communication protocol in this example is Bluetooth™. A basic information frame packet (B-frame packet) is disclosed in layer 510. The packet in layer 510 may include at least a header portion and a payload portion. The header includes routing destination information for the packet, and the payload includes information such as general data, commands with corresponding parameters, etc. The header information in this example is a basic L2CAP header 512 including at least a length and a channel ID. The header for exemplary packet 510 further includes HID header 514. Information included in the header may then be used in routing the packet to the next layer.

[0056] The process of header creation repeats in the next protocol layer 516 , and the new header information may be inserted in front of the packet (as received) before being forwarded to the next layer. Packets may become so large that, in the case of some networks, the packet will exceed the maximum allowed length and will have to be split (e.g., fragmented). An example of packet fragmentation is shown in FIG. 5B wherein the packet from layer 510 is separated in layer 516 into packets 518 and 520. These two packets may then be forwarded to PHY layer 522 where additional header information may be added to each packet to form packets 524 and 526. These packets may then be transmitted via wireless communication and subsequently reassembled by a receiving device. In a receiving device the process shown may work in reverse, wherein each level from PHY to L2CAP (in the case of Bluetooth™) may remove the packet information added by the corresponding layer until the original packet manifests at the top level.

[0057] Another example of packet fragmentation is disclosed in FIG. 5C. In this example, HID data 550 may be created at the HID application level. The creation of this information may be triggered, for example, in response to an HID event in an HID device. In some instances, HID data 550 may yield a message packet that must first be segmented before being passed down through the protocol stack. For example, the size of a message packet created from HID data 550 may exceed a maximum transfer unit (MTU) size setting defined for the L2CAP layer. More specifically, the MTU setting may specify a maximum message packet size permitted for transmission by the L2CAP layer. The HID protocol includes, among other things, the ability to fragment message packets, and as a result, exemplary HID packets 552 and 554 may be created from original HID data 550.

[0058] Similar to the previous example, message packets 552 and 554 may then be passed to the L2CAP layer to form message packets 556 and 558. Since fragmentation has already occurred at the HID profile level, no further fragmentation is necessary in the L2CAP layer. The L2CAP may then pass message packets 556 and 558 to the link level layer where additional header information may be added to yield message packets 560 and 562. Finally, link level layer message packets 560 and 562 may be passed to PHY layer, where additional routing information may be added to the header to form message packets 564 and 566. The message packets may then be sent via wireless communication.

[0059] In many wireless systems this packet size enlargement may not be a problem. Systems with more processing resources and unlimited power may be designed to handle higher packet traffic with larger packets. However, moving large packets may present a problem in restricted resource systems. Each transferred byte takes additional power, so systems that run under tight power constraints, for example battery-powered systems in small electronic devices, may experience operational difficulties due to the energy wasted in moving large packets. Further, buffer size limitations in some devices, for example simple wireless devices, may be limited in the lower protocol stack layers. As a result, there may not be adequate space to reassemble packets if the overall packet size has grown so substantially that a single message packet becomes highly fragmented. [0060] Bluetooth™ currently specifies that HID message packets be sent utilizing a connection oriented protocol in L2CAP 204. A connection oriented protocol requires that messaging channels first be established before message packets may be sent. FIG. 6 discloses and example of the steps involved in this communication. Host A 600 and Host B 602 may first establish a link layer connection as shown at 604. After this initial low level connection, the connection channel must first be opened before message packets may be sent. At 606, a PAL_Channel_Connect_Request may be issued from Host A 600. This initial message may convey the channel ID information for the control and interrupt channels to Host B 602. After this message is received, Host B 602 may save the channel ID information and may respond with a PAL_Channel_Connect_Response message.

[0061] Once channels are established, message packets transmitted on a channel may be identified by the channel ID. More specifically, the transmitting device sets the channel ID of the receiving device to the HID packet it is transmitting. This way, the receiving device may not only distinguish between HID control and interrupt messages, but may also distinguish HID message packets from packets created by another profile. After the HID protocol messages are sent as shown at 606 in FIG. 6, the channels that were opened between Host A 600 and Host B 602 must be closed. However, in some cases this termination may be problematic. For example, a Bluetooth™ mouse may not immediately terminate connection because there may be continuous data exchange (e.g., as the mouse is moved) requiring a continuous LL and L2CAP (e.g., or PAL) channel connections. For devices that transmit data very infrequently, such as a remote control, there is no benefit in maintaining these continuous connections. More importantly, these continuous connections may negatively impact resource-constrained devices since each time a device sends messages it must first create a LL connection, L2CAP channels, send the data, close the L2CAP connection and then the LL connection. This is shown where PAL_ChannelJDisconnect_Request is followed by PAL_Channel_Disconnect_Response. The link level connection may then terminate communication between the devices at 608.

[0062] While the aforementioned HID message packet conveyance process may be acceptable for WCD 100, it may be overly burdensome for less sophisticated devices. For example, the necessity to establish one or more wireless channels for particular types of messaging, and then the requirement to connect and disconnect these channels before sending message packets would require both processing and power resources. In many simple devices both these resources are constrained, and therefore, the aforementioned PID message process, as set forth under Bluetooth™, is not optimized for these devices. Further, communication delays may become detrimental in the operation of devices that do not communicate on a regular or periodic basis, like a remote control. The duration of time needed for devices to establish lower level links and messaging channels every time a message is sent, and then subsequently closing these connections, may be prohibitive to spontaneous communication scenarios where immediate response is desired or required.

VI. Sending HID message packets utilizing attribute protocol

[0063] The present invention, in at least one embodiment, reduces the number of steps involved in conveying HID message packets, and as a result, may be more suitable for devices that, for example, are simple and/or resource-constrained, as well as devices that may require fast response to sporadic messaging. While Wibree™ will be described for the sake of explanation, the present invention is not limited to using in this wireless communication medium, and may also utilize Bluetooth™ or any other similar protocol.

[0064] Various embodiments of the present invention propose a fundamental change from the strategy utilized in the Bluetooth™ HID profile when implementing an HID profile in Wibree™. As previously described, the Bluetooth™ HID profile utilizes messaging controlled in L2CAP layer 204 that first requires the establishment of control and interrupt channels before conveying HID message packets. However, Wibree™ includes an attribute protocol that doesn't require the initial establishment of channels in PAL 224 before conveying a message. Therefore, using the attribute protocol may reduce overall communication burden, making it more appropriate for resource limited devices.

[0065] FIG. 7 discloses a variety of exemplary HID message packet structures in accordance with at least one embodiment of the present invention. A generic attribute packet created, for example by Wibree™ PAL 224, is shown at 700-704. Data payload 704 may be 28 bytes in length. The header portion of the exemplary attribute packet may include an attribute handle or a universally unique identifier (UUID) 702 that may be two bytes in length, as well as an operational code, or opcode 700, that is one byte in length. Opcode 700 relates to commands that may be interpreted by a receiving device. More specifically, opcode 700 may specify operations to be performed, the specification and format of which may be defined within the instruction set architecture (ISA) of the receiving device. WCD 100 may utilize this information to process message packets without having to first establish messaging channels for different HID message types.

[0066] An exemplary embodiment of the present invention utilizing attribute handles is shown in FIG. 7 at 710-716. A packet utilizing attribute handle-value indication may include a data payload 716 of 27 bytes, a HID header 714 of one byte, an attribute handle 712 of two bytes and a one byte opcode 710. Attribute Handle 712 may utilize reserved values for control and interrupt message packets that may be exchanged and stored when two devices first encounter each other. After this initial exchange, HID message packets may be sent without having to first establish a control and interrupt channel. Instead, a receiving device may identify the type of HID message packet from the previously stored attribute handle 712 and then process the packet accordingly.

[0067] Alternatively, another configuration of HID packet usable with the exemplary proposed Wibree™ HID architecture is shown in FIG. 7 at 720-726. UUID 722 may replace attribute handle 712 in the attribute packet header. Otherwise, data payload 726, HID header 724 and opcode 720 may be similar to the examples disclosed above. In this approach, only a UUID 722 of the pipe (e.g., control or interrupt) is required. UUID 722 may include a universally defined reserved value (e.g., 0x0011 or 0x0013) each specifying a control and an interrupt message types. Devices using this exemplary packet configuration do not need to define attribute handles 712 for UUID 722, exchange attribute handles 712 with each other, or store attribute handles 712 of encountered devices. As a result, using UUID 722 directly may be especially beneficial for HID devices and/or hosts that may be connected to multiple HID devices, because the universal definition of UUID 722 removes the requirement of storing multiple attribute handles 712 specific to each encountered HID device. Further, as described with respect to the attribute handle packet configuration, no preconfigured PAL-level messaging channels are required since the packet type is determinable from UUID 722 alone.

VII. Communication strategy

[0068] The attribute handle and UUID packet configurations of FIG. 7 may result in more compact and efficient communication between devices. This, in turn, may allow for alternative device communication strategies customizable to different scenarios. FIG. 8 discloses three exemplary communication strategies in accordance with at least one embodiment of the present invention. The first strategy utilizes a continuous link layer connection between devices. For example, a peripheral device may be wirelessly coupled to WCD 100 utilizing Wibree™. In this scenario, Master/HID host 800 may transmit packets at regular intervals. Slave/HID slave 802, aware this regular interval, may respond accordingly to each interval, or may skip some connection events if connection parameters enable a sleep mode. This strategy may be suitable where quick message response is required or devices are communicating constantly, and therefore, maintaining a continuous connection will help to maintain optimized communication performance.

[0069] The second example is a discontinuous link layer connection only when needed. HID host (initiator and master) 810 may request a connection by scanning for advertising information from HID device (advertiser and slave) 812. When the HID device has information to transmit, the HID may began to send advertising data which may be scanned by HID host 810. A connection may then be established by the initiator 810 in order to convey message packets between the devices. This type of link may be more appropriate for devices that communicate regularly, but not frequently enough to warrant the power expended in maintaining a continuous connection between the devices.

[0070J A third communication strategy may be most suitable for devices that communicate infrequently and/or spontaneously. For example, a remote control utilizing Wibree may fall within this category. HID host (scanner) 820 may scan at regular intervals for signals from HID device (advertiser) 822. HID device (advertiser) 822 may then transmit a broadcast signal whenever message packets are pending for transmission (e.g., in response to an action or event in HID device 822). One possible drawback to this strategy is that there is no acknowledgement that the broadcast has been received by HID host (scanner) 820. In at least one embodiment of the present invention, HID device 822 may repeat the broadcast message packets in a predetermined pattern in order to help ensure that the message packets being broadcast will be received by host (scanner) 822.

[0071] Now referring to FIG. 9, an exemplary activity flow for HID messages sent utilizing an attribute protocol in Wibree™ is disclosed in accordance with at least one embodiment of the present invention. As described with respect to FIG. 6, Host A 600 and Host B 602 may be coupled wirelessly^' via link level connection 604. However, in this example no channels are needed since an attribute protocol is being employed to communicate HID message packets instead of the previously described L2CAP controlled messaging as dictated by the Bluetooth™ HID profile. As disclosed at 900, only an HID protocol message attribute is transmitted before the connection is terminated at 608. As a result, the communication of HID message packets may require fewer steps, conserving processing and energy resources, which may be beneficial in resource limited devices. A reduction in steps needed to send messages may also yield faster message processing, and therefore, faster response in a receiving device that increases overall system performance.

[0072] An exemplary flowchart in accordance with at least one embodiment of the present invention is disclosed in FIG. 10. Initially, a link level connection may be established in step 1000 via a wireless communication medium (e.g., Wibree™). The process may then wait in step 1002 to until an HID event is detected. An HID event may include, for example, a user interaction with a human interface device (e.g., typing on a keyboard, moving a mouse, activating a headset, etc.) It is important to note that while a connection is shown as being established before an HID event in the present example, it is also possible for the HID event to occur before the link, which may in turn trigger the establishment of a wireless connection in order to send HID message packets. At least one scenario wherein the HID event may occur first is an instance where the HID device is acting in a remote control mode. Irregular use may be more suitable for a broadcast- type connection such as discussed in FIG. 8, part C. When communication is sporadic, device resources may be conserved by only maintaining a wireless link when necessary.

[0073] Regardless of the step in the process during which a wireless connection may be established, an HID message packet may be formulated in response to the detected event as disclosed in step 1004. More specifically, the type and content of packet (e.g., control or interface) may be determined by the nature of the event. A determination may then be made in step 1006 as to whether packet fragmentation is required in view of the HID packet size, the limitations of the wireless communication medium being used, etc. If fragmentation is required, then in step 1008 fragmentation may occur at the HID profile level. Adjusting packet size at this high level allows the present invention, in accordance with at least one embodiment, to avoid reliance on the L2CAP 204 or PAL 224 protocol levels for packet resizing. Regardless of whether packet fragmentation is required, the exemplary process may then proceed to step 1010, wherein the one or more HID message packets may be prepared for transmission using an attribute protocol by attaching header data usable for identification and routing purposes. [0074] In step 1010 a determination may be made as to whether the one or more message packets are associated with HID control messages or interrupt messages. If the one or more message packets are part of an HID interrupt message, then in step 1012 a UUID 722 or attribute handle 712 may be added to the one or more message packets identifying them as interrupt packets. Alternatively, if the one or more message packets are part of a HID control message, then in step 1014 a UUID 722 or attribute handle 712 header may be added to the one or more message packets identifying them as part of control message. In either case, steps 1012 or 1014 may proceed to step 1016 so that an opcode (e.g., 710) may be added to each header of the one or more message packets.

[0075] If the one or more message packets are being sent as part of a broadcast message (e.g., no acknowledgement will be received), then it may be appropriate to execute a repeat pattern in order to increase the likelihood that the one or more message packets will be received. A determination as to the message strategy to be employed may be made in step 1018. If the message is not a broadcast message (e.g., the one or more message packets are being conveyed utilizing a continuous link layer or discontinuous link layer connection), the process may send the message (including the transmission of the one or more message packets and the receipt of corresponding acknowledgements from the receiving device) in step 1020 and then resume again at step 1000 awaiting the detection of new HID events requiring the generation of HID message packets. However, if in step 1018 the one or more message packets are determined to be part of a broadcast message, then in step 1022 the one or more message packets may be sent in accordance with a predetermined repeat pattern, after which the process may return to step 1000 to await the detection of new HID events requiring the generation of HID message packets.

[0076] Accordingly, it will be apparent to persons skilled in the relevant art that various changes in forma and detail can be made therein without departing from the spirit and scope of the invention. The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

WHAT IS CLAIMED:

1. A method, comprising: establishing a link level connection over a wireless communication medium; detecting an event requiring human interface device (HID) profile based communication; determining a type for one or more HID message packets based on the event; creating the one or more message packets at the HID profile level of a protocol stack for the wireless communication medium, each of the one or more message packets comprising a HID header field and a data payload field; adding an attribute header corresponding to the determined type to each of the one or more message packets; and sending the one or more message packets via the wireless communication medium.

2. The method of claim 1 , wherein creating the one or more message packets includes a determination as to whether the one or more message packet requires fragmentation.

3. The method of claim 1 , wherein determining a type includes determining whether the one or more message packets are control message packets or interrupt message packets.

4. The method of claim 1 , wherein the attribute header includes at least opcode information.

5. The method of claim 4, wherein the attribute header further includes either attribute handle information or universally unique identifier (UUID) information.

6. The method of claim 5, wherein adding an attribute header comprises including the opcode information and either the attribute handle information or the UUID information in each attribute header, the attribute handle information and the UUID information identifying each message packet as a control message packet or an interrupt message packet.

7. The method of claim 1, wherein sending the one or more message packets does not require any pre-established profile adaptation layer (PAL) communication channels.

8. The method of claim 1, wherein sending the one or more message packets further comprises receiving an acknowledgement for the one or more message packets.

9. The method of claim 1, wherein sending the one or more packets further comprises broadcasting the one or more packets without receiving acknowledgement.

10. The method of claim 9, wherein broadcasting the one or more message packets includes repeating the one or more message packets in a predetermined pattern.

1 1. A computer program product comprising a computer usable medium having computer readable program code embodied in said medium, comprising: a computer-readable program code configured to establish a link level connection over a wireless communication medium; a computer-readable program code configured to detect an event requiring human interface device (HID) profile based communication; a computer-readable program code configured to determine a type for one or more HID message packets based on the event; a computer-readable program code configured to create the one or more message packets at the HID profile level of a protocol stack for the wireless communication medium, each of the one or more message packets comprising a HID header field and a data payload field; a computer-readable program code configured to add an attribute header corresponding to the determined type to each of the one or more message packets; and a computer-readable program code configured to send the one or more message packets via the wireless communication medium.

12. The computer program product of claim 1 1 , wherein creating the one or more message packets includes a determination as to whether the one or more message packet requires fragmentation.

13. The computer program product of claim 11 , wherein determining a type includes determining whether the one or more message packets are control message packets or interrupt message packets.

14. The computer program product of claim 11 , wherein the attribute header includes at least opcode information.

15. The computer program product of claim 14, wherein the attribute header further includes either attribute handle information or universally unique identifier (UUID) information.

16. The computer program product of claim 15, wherein adding an attribute header comprises including the opcode information and either the attribute handle information or the UUID information in each attribute header, the attribute handle information and the UUID information identifying each message packet as a control message packet or an interrupt message packet.

17. The computer program product of claim 1 1 , wherein sending the one or more message packets does not require any pre-established profile adaptation layer (PAL) communication channels.

18. The computer program product of claim 1 1 , wherein sending the one or more message packets further comprises receiving an acknowledgement for the one or more message packets.

19. The computer program product of claim 11 , wherein sending the one or more packets further comprises broadcasting the one or more packets without receiving acknowledgement.

20. The computer program product of claim 19, wherein broadcasting the one or more message packets includes repeating the one or more message packets in a predetermined pattern.

21. A module, comprising: at least one communication component coupled to an antenna array, and at least one processing component coupled to the communication component, the at least one processing component being configured to: establish a link level connection over a wireless communication medium; detect an event requiring human interface device (HID) profile based communication; determine a type for one or more HID message packets based on the event; create the one or more message packets at the HID profile level of a protocol stack for the wireless communication medium, each of the one or more message packets comprising a HID header field and a data payload field; add an attribute header corresponding to the determined type to each of the one or more message packets; and send the one or more message packet via the wireless communication medium.

22. A device, comprising: at least one communication module; and at least one processor coupled to the communication module, the at least one processor being configured to: establish a link level connection over a wireless communication medium; detect an event requiring human interface device (HID) profile based communication; determine a type for one or more HID message packets based on the event; create the one or more message packets at the HID profile level of a protocol stack for the wireless communication medium, each of the one or more message packets comprising a HID header field and a data payload field; add an attribute header corresponding to the determined type to each of the one or more message packets; and send the one or more message packet via the wireless communication medium.

23. The device of claim 22, wherein determining a type includes determining whether the one or more message packets are control message packets or interrupt message packets.

24. A device, comprising: means for establishing a link level connection over a wireless communication medium; means for detecting an event requiring human interface device (HID) profile based communication; means for determining a type for one or more HID message packets based on the event; means for creating the one or more message packets at the HID profile level of a protocol stack for the wireless communication medium, each of the one or more message packets comprising a HID header field and a data payload field; means for adding an attribute header corresponding to the determined type to each of the one or more message packets; and means for sending the one or more message packets via the wireless communication medium.

25. The device of claim 24, wherein determining a type includes determining whether the one or more message packets are control message packets or interrupt message packets.

26. A system comprising: at least one host device; and at least one human interface device (HID); the at least one HID device establishing a link level connection with the at least one host device over a wireless communication medium; the at least one HID device detecting an event requiring human interface device (HID) profile based communication; the at least one HID device determining a type for one or more HID message packets based on the event; the at least one HID device creating the one or more message packets at the HID profile level of a protocol stack for the wireless communication medium, each of the one or more message packets comprising a HID header field and a data payload field; the at least one HID device adding an attribute header corresponding to the determined type to each of the one or more message packets; and the at least one HID device sending the one or more message packets to the at least one host device via the wireless communication medium.