Wireless architecture for a traditional wire-based protocol

Wireless architecture for traditional wired-based protocols

The following description is generally about communication systems, and more specifically about enabling traditional wired-based devices to communicate via a wireless link and/or a wired link and communicate digital data at a high rate.

No matter where the user may be located at a particular time (for example, home, office, travel,...), many users use wireless network connection systems to communicate. Wireless communication devices have become smaller and more powerful (eg, enhanced functionality and/or applications, larger memory capacity) to meet user needs, while improving portability and convenience. Users have discovered many uses for wireless communication devices including cellular phones, personal digital assistants (PDAs) and the like. For example, a wireless communication device may include the functionality of capturing and processing images (for example, static images, moving images, video games, and the like).

Applications and/or functionality operating with very high data rates may have considerable power requirements and/or high current levels. These power requirements and/or current levels can easily be used for devices that communicate using wired protocols. However, wireless communication systems may not have the ability to operate with these high data rates. Therefore, the communication that the user desires to send and/or receive may be restricted in some situations.

Some devices traditionally operate only with wired capacity, such as the Mobile Display Digital Interface (MDDI). Therefore, users with the device may not be able to communicate while on the move and may need to spend other costs to obtain a wireless device, which is not always feasible. In some cases, the user may decide to operate two devices (one with wired capacity and one with wireless capacity) to achieve the benefits of the two devices. However, the cost associated with the two devices and keeping track of the two devices may impose an excessive burden on the user.

To overcome the foregoing and other shortcomings, a technology for allowing a traditional wired-based protocol to communicate via a wired or wireless framework is provided. The disclosed technology provides this flexibility with minor changes to the wired architecture.

The following presents a simplified summary of one or more embodiments in order to provide a basic understanding of some aspects of the embodiments. This summary is not an extensive overview of the embodiment(s), and is neither intended to identify the key or critical elements of the embodiments nor to delineate the scope of the embodiments. Its sole purpose is to present some concepts of the described embodiments in a simplified form as a prelude to the more detailed description that will be presented later.

According to one or more embodiments and their corresponding disclosures, various aspects are described in connection with high-speed communication of digital data between a host entity (for example, a transmitter) and one or more remote user devices.

According to related embodiments, a method for wirelessly communicating digital data at a high rate between a host entity and one or more remote user interface client devices for user interface data is provided. The method may include associating one or more remote user interface client devices with the host entity and sending a capability packet containing at least one capability of the remote user interface client device(s) to the host entity. The method may further include transmitting a status packet including at least one link quality information to the host entity.

Another embodiment relates to a device capable of wirelessly communicating high-speed digital data. The device may include a memory that stores information about a first MAC address associated with the device and at least a second MAC address associated with a remote host device. The device also includes a processor that analyzes the information stored in the memory and selectively associates the device with a remote host device.

Another embodiment relates to a device for wirelessly communicating high-speed user interface data. The device may include a component for associating at least one receiver with a remote transmitter and a component for wirelessly communicating at least one capability information of the receiver to the remote transmitter. The device may also include a component for periodically sending at least one link quality data packet to the remote transmitter and a component for selectively disassociating with the remote transmitter.

Another embodiment relates to a computer-readable medium, which embodies a method for wirelessly transmitting high-speed user interface data. The method may include associating one or more remote user interface devices with a host and sending a first packet containing the capability information of the remote user interface device(s). The method may further include periodically sending at least one second packet including quality data of a communication link between the remote user interface device and the host.

Another embodiment relates to a processor for wirelessly communicating high-speed user interface data. The processor can be configured to associate an interface device with a remote host, send information about a capability of the interface device in a capability packet, and transmit a message including information about the communication between the interface device and the remote host. A state packet of the data of the communication link.

Yet another embodiment relates to a method for performing high-rate wireless digital data communication between a transmitter and at least one remote receiver for user interface data. The method may include associating with the at least one remote receiver and receiving a first packet including at least one capability of the at least one remote receiver. The method may also include receiving link quality information on a reverse link from the at least one remote receiver.

Another embodiment relates to a device for wirelessly communicating high-speed user interface data. The device may include: a memory that stores information about an identification code of at least one remote user interface device; and a processor that selectively communicates with the at least one remote based on the stored information in part The user interface device is associated. The device may further include an information component that analyzes at least one capability of at least one remote user interface device received in a client capability packet.

Another embodiment relates to a device for wirelessly communicating user interface data at a high rate. The apparatus may include a component for selectively associating with at least one remote user interface device and a component for sending an association response to the at least one remote user interface device. The association response may contain a client identification code for the at least one remote user interface device. The apparatus may also include a component for receiving a first capability packet and a component for associating the at least one remote user interface device with an identification code based in part on at least one capability included in the first capability packetofcomponents.

Another embodiment relates to a computer-readable medium, specifically a method for wirelessly transmitting high-speed user interface data. The method may include associating a host device with at least one remote client device and receiving a first packet containing capability information of the at least one remote client device. The method may further include assigning a client identification code to the at least one remote client device based in part on the first packet and receiving a data between the host device and the at least one remote client device. The second packet of quality data information of the communication link.

Another aspect relates to a processor for wirelessly communicating high-speed user interface data. The processor can be configured to associate a host with a remote interface device, receive information about a capability of the remote interface device, and assign an identifier to the remote interface device. The processor may be further configured to send the identifier to the remote interface device and receive information about a communication link between the remote interface device and the host in a status packet.

To achieve the above and related objects, one or more embodiments include features that will be fully described below and specifically pointed out in the scope of the patent application. The following description and additional drawings detail certain illustrative aspects of this or these embodiments. However, these aspects only indicate some of the various ways, in which the principles of various embodiments can be adopted and the embodiments are intended to include all these aspects and their equivalents.

Various embodiments will now be described with reference to the drawings. In the following description, for the purpose of explanation, numerous specific details are stated in order to provide a thorough understanding of one or more aspects. However, it is obvious that the embodiment(s) can be practiced without such specific details. In other cases, well-known structures and devices are shown in block diagram form to help describe these embodiments.

As used in this application, the terms "component", "module", "system" and the like are intended to refer to computer-related entities (hardware, firmware, combination of hardware and software, software or software in execution) ). For example, the component can be (but is not limited to) a process, a processor, an object, an executable (code), a thread, a program, and/or a computer running on the processor. To illustrate, an application program executed on a computing device and the computing device can be a component. One or more components can reside in a process and/or thread and a component can be located on a computer and/or distributed between two or more computers. In addition, these components can be executed from various computer-readable media storing various data structures. A component can communicate via a regional process and/or a remote process, such as based on a signal with one or more data packets (e.g., data from a component that interacts with another component in a regional system, a distributed system, and / Or via the signal across a network such as the Internet and other systems (communication).

In addition, various embodiments are described herein in conjunction with user devices. User devices can also be called systems, user units, user stations, mobile stations, mobile devices, remote stations, access points, base stations, remote terminals, access terminals, mobile phones, user terminals, Terminal, user agent or user equipment. User devices can be cellular phones, cordless phones, call initiation protocol (SIP) phones, wireless zone loop (WLL) stations, PDAs, handheld devices with wireless connection capabilities, or other processing devices connected to wireless modems .

In addition, standard programming and/or engineering techniques can be used to implement the various aspects or features described herein as methods, devices, or articles of manufacture. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer readable device, carrier or medium. For example, computer-readable media may include (but are not limited to) magnetic storage devices (for example, hard disks, flexible disks, magnetic strips, ...), optical disks (for example, compact disks (CD), digital universal Optical discs (DVD),...), smart cards and flash memory devices (for example, cards, sticks, secure disks,...).

In the following embodiments, various aspects and embodiments can be described in the context of the Mobile Display Digital Interface (MDDI) and/or the Institute of Electrical and Electronic Engineers (IEEE) 802.15.3 Media Access Control (MAC) layer. Although these invention aspects can be very suitable for use in the disclosed embodiments, those skilled in the art should easily understand that these invention aspects can also be applied to various other traditional wired-based protocols. Therefore, any reference to MDDI and/or IEEE802.15.3 MAC is only intended to illustrate aspects of the invention, and it should be understood that these aspects of invention have a wide range of applications.

Various embodiments will be presented based on a system that may include numerous components, modules, and the like. It should be understood and understood that various systems may include additional components, modules, etc. and/or may not include the owners of the components, modules, etc. discussed in conjunction with the figures. A combination of these methods can also be used. In addition, it can be in a plurality of mobile devices (for example, cellular phones, smart phones, laptop computers, handheld communication devices, handheld computing devices, satellite radios, global positioning systems, PDAs, and/or other suitable devices) Implement various systems.

Referring now to the drawings, FIG. 1 illustrates a block diagram of a system 100 for enabling a traditional wire-based device to communicate wirelessly. The system 100 includes a transmitter 102 in wired and/or wireless communication with a receiver 104. The transmitter 102 and the receiver 104 can be components that traditionally communicate via a wire-based protocol. Although, as should be understood, many transmitters 102 and receivers 104 may be included in the system 100, for the sake of simplicity, a single transmitter 102 that transmits communication data signals to a single receiver 104 is described.

The communication sent from the transmitter 102 to the receiver 104 is called the forward link and the communication sent from the receiver 104 to the transmitter 102 is called the reverse link. The transmitter 102 can be connected to a data source 106 (for example, storage, memory, and the like) and the receiver 104 can be connected to an interface device 108 such as a display.

The system 100 can be operated in at least two operating modes (ie, low-consumption mode and/or low-latency mode). The low-consumption mode optimizes a packet sent over the air (for example, wirelessly) by requesting the channel configuration time. The channel configuration time allows the data to travel from either direction (from the transmitter to the receiver or from the receiver to the sender). Transmitter) the time it was sent. In the low-latency mode, the channel configuration time can be determined based on the knowledge of the data contained in the forward link and the reverse link.

The transmitter 102 may be configured to determine the forward link rate and the reverse link rate based on various criteria (e.g., round-trip delay measurement). The transmitter 102 can send at least one reverse link encapsulation packet per frame. The reverse link encapsulation packet can be used to adapt to the transfer of the reverse packet via the transfer link to establish the reverse link.

The receiver 104 can be configured to receive and/or send data communications via wired functionality and/or wireless functionality. The determination of which functionality to use can be based on the data type (for example, voice, text, image...), the traditional method of communication (for example, wired or wireless link), the transmitted file or packet Various criteria for size and other criteria regarding data, transmitter, transmitter, and/or receiver are performed. The transmitter 102 can communicate data without knowing how the receiver 104 receives the data (for example, wired or wireless).

FIG. 2 illustrates a wireless transmitter 200 according to one or more disclosed embodiments. The wireless transmitter 200 can be configured to communicate high-speed data (such as digital data). The various wireless systems described herein may include a wireless transmitter and a wireless receiver. The wireless transmitter 200 may include a host 202 and a special client (C1) 204, and the special client may be connected to one or more displays or devices. The host 202 and the client (C1) 204 can be connected by a traditional high data rate link (for example, MDDI) 206. A module containing a client (C1) 204 and a wireless modem 208 (such as an ultra-wideband modem including UWB MAC and UWB PHY) is operably connected to an existing wired link (such as an MDDI link or a wireless modem configured to Support high-speed data link). In some embodiments, if the client (C1) 204 and the modem 208 are connected to a wired link, the host 202 may need to be upgraded to handle wireless functionality, which will be described in more detail below. FIG. 3 illustrates another wireless transmitter 300 with a host 302 and a client 304 co-located. It also includes a wireless modem 306. Another example of a wireless transmitter 400 is illustrated in FIG. 4, in which the host and C1 are merged into a single hardware/software entity 402. A wireless modem 404 is included to facilitate wireless communication.

Referring now to FIG. 5, it illustrates a wireless receiver 500 according to the disclosed embodiment. The wireless receiver 500 includes a client (C2) 502, which can be connected to a number of devices and a display 504 (for simplicity, only one display is shown). The client (C2) 502 can be configured to process and generate high-rate digital data packets. In some embodiments, the client (C2) 502 does not have a physical layer of the MDDI stack. A single transmitter can be connected to several receivers according to the disclosed embodiments.

Figure 6 illustrates a system 600 for extending the capabilities of a traditionally wired configuration to allow communication via a wireless link. The system 600 includes a transmitter 602 that communicates with a receiver 604 via a forward link. The receiver 604 communicates with the transmitter 602 via a reverse link. The transmitter 602 and the receiver 604 may be devices that normally communicate via a wired protocol, however, the system 600 allows the devices to communicate via the wired protocol and/or via a wireless protocol (such as via a high-speed wireless link). Although, as should be understood, many transmitters 602 and receivers 604 may be included in the system 600, for the sake of simplicity, a single transmitter 602 that transmits communication data signals to a single receiver 604 is described.

The transmitter 602 may include a host 606, a part of a client (C1) 608, and a communication component 610. For example, the host 606 may be an MDDI host. In some embodiments, the host 606 may be a component separated from the transmitter 602 and connected to the transmitter 602 via a wired link. A part of the client (C1) 608 is kept on the host 606 or kept in communication with the host 606 for clock synchronization. For example, the client (C1) 608 can be connected to the host 606 via a traditional wired link (for example, an MDDI link). The host 606 can be configured to send or communicate data packets to the client (C1) 608. These packets can be communicated to the receiver 604 via the communication component 610. The communication component 610 can include a modem such as an ultra-wideband (UWB) modem. Some packets (for example, MDDI round-trip delay measurement packets) are processed by the client (C1) 608 and communicated to the receiver 604. Other packets (for example, a filler packet) should be discarded by the client (C1) 608 and not communicated to the receiver 604. That is, some packets are continuously transmitted on the forward wireless link or the reverse wireless link. A stuffing packet, for example, maintains the timing between the transmitter 602 and the receiver 604. The packets can be generated by the transmitter 602 or the receiver 604 via respective client parts.

The receiver 604 may include an interface device 612 (for example, a display), a part of the client (C2) 614, and a communication component 616. In some embodiments, the device 612 may be a component separate from the receiver 604 and connected to the receiver 604 via, for example, a wired link. The client (C2) 614 can be connected to the device 612 via a wired link. The client (C2) 614 can be configured to process a packet received from the transmitter 602. The receiver 604 may receive the communication from the transmitter 602 via the communication component 616, which may include, for example, a UWB modem.

The system 600 can be configured to operate in one of two modes of operation. These modes include a low-consumption mode and a low-latency mode. In the low-consumption mode, the client (C1) 608 excludes (for example) filling packets and round-trip delay packets and places the data to be sent in a buffer that can be included in the communication component 610 (for example, a UWB modem) middle. The communication component 610 (for example, via a UWB MAC) can periodically request a one-way channel time allocation (CTA) from the transmitter 602 to the receiver 604 based on the size of the buffer. In a reverse direction (ie, the reverse link), the client (C2) 614 can, for example, exclude the padding packet and place the reverse link data it intends to send in a communication component 616 (for example, , UWB modem) in the associated buffer. In this reverse direction, the communication component 616 can request a reverse direction CTA.

For the low-latency mode, during an initialization phase, the communication component 610 (e.g., UWB modem) may request to continue in the forward direction<i>m</i>CTA in milliseconds and continuous in the reverse direction<i>n</i>CTA in milliseconds. The expected ratio of traffic in the forward and reverse directions is<i>m</i>：<i>n</i>and<i>m</i>The second series corresponds to R_f-mddiThe duration of the previous transfer rate to the link. T is the duration of a super frame, which is determined by the latency limit of the application, where: (<i>m</i>＋<i>n</i>)&lt;T_CTAP&lt;T

Referring now to FIG. 7, it illustrates a system 700 for communicating via a wired and/or wireless architecture. The system 700 includes a transmitter 702 and a receiver 704. The transmitter 702 and the receiver 704 communicate via a forward link (from the transmitter 702) and/or a reverse link (from the receiver 704). The communication via the forward link and/or the reverse link may depend on special circumstances (for example, the data to be transmitted, the data rate, the quality of the communication link, the status of each device...) through a wired protocol And/or via a wireless agreement. Although, as should be understood, many transmitters 702 and receivers 704 may be included in the system 700, for the sake of simplicity, a single transmitter 702 that transmits communication data signals to a single receiver 706 is described.

The transmitter 702 may include a host component 706 connected to a client (C1) component 708 and a communication component 710. The receiver 704 may include a device 712 connected to a client (C2) device 714 and a communication device 716. The client (C1) component 708 and the client (C2) component 714 are separate parts of a client.

Those skilled in the art should understand that the transmitter 702 and/or the receiver 704 may include additional components. For example, the transmitter 702 can include an encoder component (not shown), which can modulate and/or encode signals according to a suitable wireless communication protocol, and these signals can then be transmitted to the receiver 704 . In some embodiments, the encoder component may be a speech encoder (vocoder) or another type of encoder that uses a speech analyzer to convert analog waveforms into digital signals. Suitable wireless communication protocols may include (but are not limited to) Orthogonal Frequency Division Multiplexing (OFDM), Orthogonal Frequency Division Multiple Access (OFDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA) ), Global System for Mobile Communications (GSM), High Speed Downlink Packet Access (HSDPA) and the like.

The receiver 704 may include a decoder component (not shown) that can decode one of the received signals and/or data packets for processing. After successfully decoding a data packet, a confirmation component (not shown) can generate a confirmation indicating the successful decoding of the data packet, and can send the confirmation to the transmitter 702 to inform the transmitter 702 that the data packet is received and decoded, and Therefore, there is no need to retransmit.

The host component 706 may include a query module 718 and a measurement module 720. The query module 718 can be configured to query a host media access control (MAC) at an application data rate provided by the MAC. For wireless communication, the operating rate may depend on the rate of the wireless link. The measurement module 720 can be configured to determine the forward link rate and the reverse link rate based on, for example, a round-trip delay measurement that can be specified in a wireless protocol. In some embodiments, the wireless operating rate can be determined by the minimum of the two rates (forward link rate and reverse link rate), the maximum capacity of the host 706, and the maximum capacity of the client (C1) 708. There should be a minimum allowable rate R_min. If the measured operating rate is lower than the minimum allowable rate, the operating rate can be adjusted by the transmitter 702 and/or receiver 704 via respective components (for example, the communication components 710 and/or 716). The transmitter 702 can inform the receiver 704 of the rate to be used to process the communication.

The client (C2) component 714 can include a notifier module 722 that can be configured to notify the transmitter 702 of the application data rate provided by the MAC. The notification may be based on a query received from the transmitter 702 (for example, a query sent by the query module 718). For reverse link packets, the notifier module 722 can specify the number of bytes required by the receiver 704 to send on the reverse link in the current frame. The client (C2) component may also include an assigner module 724, which can be configured to depend on various parameters associated with the communication (for example, communication type, communication speed, transmitter, receiver, and Its analogs) and assign a communication to a wired protocol or a wireless protocol.

The communication component 716 can include a wired module 726 and a wireless module 728. The wired module 726 can be configured to provide wired functionality and the wireless module 728 can be configured to provide wireless functionality. It can be determined whether to use the wireless module 728 to communicate wirelessly or to use the wired module 726 to communicate. The determination can be based on factors including the operating rate, the type of data being transmitted (for example, voice, text, image,...), the size of the data or file being transmitted, whether the data is usually communicated via a wired link or a wireless link, etc. A variety of factors. The wired module 726 and/or the wireless module 728 may include a buffer for storing content so that a change is made during the communication from one module to another (eg, wireless to wired, wired to wireless) At the time, communication will not be lost due to exchange issues.

Information about whether the receiver 704 communicates via a wired link or a wireless link does not need to be communicated to the transmitter 702. The transmitter 702 performs its functions in substantially the same manner regardless of the communication method (wired or wireless).

According to some embodiments, the transmitter 702 may include a component (not shown) configured to fragment a sub-frame, and the receiver 704 may include a component (not shown) configured to reassemble the sub-frame ). The maximum length of the MDDI subframe (for example) can be about 65,536 bytes, although it is usually small. If the basic rate is about 480 Mbps, the maximum size of an 802.15.3 MAC frame can be roughly 4,096 or about 8,192 bytes. If the basic physical layer rate is roughly 200 Mbps, the size can be about 2,048 bytes. Therefore, the sub-frames may need to be fragmented on the transmitter 702 side and recombined on the receiver 704 side to adapt to the size of the frame. The fragmentation and reassembly can be performed by the respective communication components 710 and 716 and/or other components associated with the transmitter 702 and the receiver 704.

Figure 8 illustrates another embodiment of a system 800 for extending a traditionally wired configuration to allow communication via a wireless link. The system 800 may include a transmitter 802. The transmitter 802 includes a host 806, a part of a client (C1) 808, and a communication component 810. The system 800 may also include a receiver 804. The receiver 804 includes a device 812, a part of a client (C2) 814, and a communication component 816. The transmitter 802 communicates to the receiver 804 via a forward link and the receiver 804 communicates to the transmitter 802 via a reverse link. As noted in the previous figures, although a number of transmitters 802 and receivers 804 may be included in the system 800, for the sake of simplicity, a single transmitter 802 that transmits communication data signals to a single receiver 804 is described.

The system 800 can include a memory 818 operatively coupled to the receiver 804. The memory 818 can store the data rate of the packet and/or packet type (for example, the application data rate provided by the MAC, the operating rate of the wireless link...), the operation mode of the packet and/or the packet type, and/or Information on other parameters associated with data is transmitted via a wireless protocol, a wired protocol, or a combination of these protocols. For example, a wired protocol can be used for a communication during a communication and a decision to switch to a wireless protocol can be made, or vice versa, without interrupting or terminating the communication.

A processor 820 is operatively connected to the receiver 804 (and/or the memory 818) to facilitate analysis of information on determining whether a special communication should be sent via a wired protocol or a wireless protocol. The processor 820 may be a processor dedicated to analyzing and/or generating information communicated to the receiver 804, a processor controlling one or more components of the system 800, and/or both analyzing and generating information received by the receiver 804 It also controls a processor of one or more components of the system 800.

The memory 818 can store protocols associated with data communication rates, operating rates, actions taken to control the communication between the receiver 804 and the transmitter 802, and so on, so that the system 800 can use the stored protocols and/or algorithms to perform operations such as Improved communication is achieved in the wireless network described in this article. It should be understood that the data storage (for example, memory) components described herein may be volatile memory or non-volatile memory, or may include volatile and non-volatile memory. For example (but not limiting), non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electronically programmable ROM (EPROM), and electronically erasable ROM (EEPROM). ) Or flash memory. Volatile memory may include random access memory (RAM), which acts as external cache memory. For example (but not limiting), RAM is available in many forms, such as synchronous RAM (DRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM) ), Synchronous Link DRAM (SLDRAM) and Direct Rambus RAM (DRRAM). The memory 818 of the disclosed embodiment is intended to include (but is not limited to) these and other suitable types of memory.

Figure 9 illustrates a system 900 for communicating with a conventional wired device via a wired link or a wireless link. The system 900 is represented as a functional block, which can be a functional block that represents a function implemented by a processor, software, or a combination thereof (for example, firmware). The system 900 includes a receiver 902, which can be configured to receive an operating rate for a communication. This operating rate can be received from, for example, the transmitter or the transmitter host. The operating rate can set or establish the rate of communication in the forward and reverse directions. The system 900 also includes a wireless communicator 904, which can be configured to send and/or receive a communication via a wireless protocol. A wired communicator 906 can be configured to send and/or receive a communication via a wired protocol.

It should be noted that there may be packet extensions and/or new packets in the forward and/or reverse direction. For example, in the forward direction, MDDI transmitter information can be added to a packet. This packet extension can provide MDDI transmitter-side information to the MDDI client on the receiver side. This information may include the rate at which the MDDI host and client should operate on the transmitter side. In the reverse direction, the extension of a client capability packet can include about four bytes for MDDI receiver MAC information and about two bytes for MDDI receiver client information. However, other extensions It is also possible.

The system 900 also includes a determiner that can selectively determine whether to use a wireless communicator to communicate via a wireless protocol or to use a wired communicator to communicate via a wired protocol. This determination can be selectively made based on various parameters such as the communication operation rate. Other parameters can also be analyzed to make this determination. For example, it can be based on how to send and/or receive special communications traditionally (e.g., historical analysis), the type of communications (e.g., voice, image, text,...), and information about communications, transmitters and/or receivers Other parameters to make the judgment.

Figure 10 illustrates an exemplary forward link MDDI data transfer 1000 in a low consumption mode according to various embodiments presented herein. A mode type that enables an MDDI transmitter 1002 to send data to an MDDI receiver 1004 can be a low-consumption mode. In this mode, a wirelessly sent packet is optimized for channel configuration time, which is the time it takes to send data from either direction (for example, forward or reverse). The MDDI transmitter 1002 may include a part of the client (C1) 1006 and the MDDI receiver 1004 may include a part of the client processing (C2) 1008.

The MDDI client (C1) 1006 can place the data to be sent in a buffer such as a UWB modem. For example, the data to be sent should exclude unnecessary packets such as padding packets and round-trip delay packets. As explained at 1012, send MDDI data to a transmitter MAC 1010. The transmitter MAC 1010 (or UWB MAC) may periodically or continuously request at least one CTA from the MDDI transmitter 1002 to the MDDI receiver 1004 based on, for example, the size of the buffer.

At 1014, the transmitter MAC 1010 may request the forward link CTA from a piconet controller (PNC) MAC 1016 (e.g., periodically or continuously). At 1018, the PNC MAC 1016 can respond to the transmitter MAC 1010 with a channel time response code. This response code can indicate whether the data has been successfully communicated. After receiving a successful channel time response code, as indicated at 1022, the transmitter MAC 1010 can send MDDI data to a receiver MAC 1020.

Figure 11 illustrates an exemplary reverse link MDDI data transfer 1100 in a low consumption mode according to various embodiments presented herein. An MDDI receiver 1102 can initiate communications intended for an MDDI transmitter 1104 via a reverse link. The MDDI receiver 1102 may include a part of the client (C2) 1106 and the MDDI transmitter 1104 may include a part of the client (C1) 1108.

As indicated at 1112, the MDDI receiver 1102 can send MDDI data to a receiver MAC 1110. At 1116, receiver MAC 1110 may request reverse link CTA from PNC MAC 1114. The request may correspond to the data that should be sent in the reverse direction. At 1118, PNC MAC 1114 can respond with a channel time response code. At 1120, the receiver MAC 1110 can send the MDDI data in the CTA to the transmitter MAC 1122. As indicated at 1124, the transmitter MAC 1122 may send or give MDDI data to the user at 1124 at a certain time before receiving the MDDI data from the receiver MAC 1110 or substantially simultaneously with the reception of the MDDI data from the receiver MAC 1110 ( C1) 1108. As indicated at 1128 and 1130, the MDDI transmitter host 1126 can send and/or receive at least one reverse link package per frame. Reverse link data can be sent preemptively without waiting for a data request. The user end can specify the number of bytes that need to be sent on the reverse link in the current frame. The host 1126 can correspondingly configure the request in the reverse link encapsulation packet.

FIG. 12 illustrates a low-latency mode MDDI connection setting 1200 according to various embodiments presented herein. In the low-latency mode, the channel configuration time can be determined based on the extrapolation from the data contained in the packets in the forward direction and the reverse direction. An MDDI transmitter 1202 may include a part of a host 1204 and a client (C1) 1206. During the initialization phase, at 1210, the UWB modem on the transmitter 1202 can send a MAC query to a transmitter MAC 1208. A MAC query is a query sent to find out the rate supported by the MAC and retransmission statistics. At 1212, the transmitter MAC 1208 can respond to the query. This response can be a MAC response indicating the rate supported by the MAC retransmission statistics.

The host sends a MAC query packet to query information about the transmitter/receiver side. A packet length field contains two bytes of a 16-bit integer without a sign. The integer specifies the total number of bytes in the packet that does not include the packet length field. A packet type field contains two bytes of 16-bit integer without sign. The 151 packet type identifies the packet as a MAC query packet. The client ID is a byte containing a 16-bit unsigned integer reserved for the target client (C2) ID. The MAC query parameter field is two bytes and the CRC field contains two bytes of the 16-bit CRC of all the bytes in the packet including the packet length.

The sender 1202 requests to continue in the forward direction<i>m</i>CTA setting of 1214 milliseconds and continuous in the reverse direction<i>n</i>CTA in milliseconds. The expected ratio of traffic in the forward and reverse directions should be<i>m</i>：<i>n</i>. At 1216, send a channel time request (CTRq) to PNC Mac 1218. A channel time response code can be sent in the reverse direction shown at 1220 and in the forward direction shown at 1222 and sent to a receiver MAC 1224. As illustrated at 1226, the MDDI transmitter 1202 can initiate an MDDI transfer.

Corresponds to R_f-mddiThe duration of the MDDI forward link transfer rate is<i>m</i>Seconds, and when<i>T</i>When it is the duration of the super frame determined by the latency limit of the application, the following formula applies:<i>m</i>＋<i>n</i>&lt;<i>T</i>_<i>CTAP</i>&lt;<i>T</i>

In the low latency mode, reverse link data can be sent during the CTA period reserved in the reverse direction. Depending on the arrival time of the reverse link data relative to the MAC hyperframe, the transfer can have a maximum latency expressed as:<i>T</i>_<i>rl</i>＝<i>ceil</i>[{<i>k</i>*(<i>N/R</i>_<i>1</i>＋<i>RIFS</i>＋<i>H</i>/<i>R</i>_<i>2</i>)＋<i>SIFS</i>＋<i>T</i>_<i>ACK</i>}/<i>n</i>]*<i>T</i>in<i>k</i>It is the average number of retransmissions experienced by the MAC frame.<i>N</i>Is the size of the reverse link packet that should be sent and<i>n</i>It is the duration of the reverse link CTA in each super frame.<i>R</i>_<i>1</i>It is the physical layer transmission rate of MDDI data (MAC payload).<i>R</i>_<i>2</i>It is the physical layer transmission rate of PHY, MAC header and preamble.<i>H</i>It is the size of the MAC plus the size of the PHY header plus the size of the preamble.<i>SIFS</i>It is the duration of the short interval between frames.<i>RIFS</i>It is the duration of the interval between retransmission frames.<i>T</i>_<i>ACK</i>It is the duration of ACK transmission.<i>T</i>It is the duration of the super frame. For the purpose of explanation, assume that the ACK strategy is Imm-ACK (Immediate Acknowledgement). The latency of forward link packets can be determined accordingly<i>T</i>_<i>fl</i>. Given the application latency limit in the forward and reverse links, the duration of the MAC frame can be obtained accordingly. For example, various algorithms, methods, and/or techniques can be used to obtain the duration of the MAC frame and/or the latency of the forward link packet.

In view of the exemplary system shown and described, a method that can be implemented according to one or more embodiments is provided. Although for the purpose of simplifying the explanation, these methods are shown and described as a series of actions (or functional blocks), but it should be understood and understood that these methods are not limited by the sequence of actions, because according to some of these methods Actions can occur in a different order and/or concurrently with other actions from what is shown and described herein. In addition, not all the actions described are required to implement the following methods. It should be understood that various actions can be implemented by software, hardware, a combination thereof, or any other suitable components (for example, devices, systems, processes, components) for performing the functionality associated with the actions. It should also be understood that the actions will only be described in a simplified form of certain aspects presented in this text and these aspects may be described by a smaller and/or larger number of actions. Familiar with this technology should understand and understand that a method can alternatively be represented as a series of related states or events such as a state diagram.

Referring now to FIG. 13, it illustrates a method 1300 for configuring a traditionally wired device to communicate via a wired protocol and/or a wireless protocol. At 1302, a first part of a user terminal is placed on an MDDI transmitter. The MDDI transmitter can be wireless and can be connected to a data source. The MDDI transmitter may also include an MDDI host connected or interfaced to the client part by, for example, a traditional wired MDDI link.

At 1304, a second part of the user terminal is placed on an MDDI receiver, which may be a wireless MDDI receiver. The MDDI receiver can be connected to a device that can be, for example, a display. The part of the user end placed on the MDDI transmitter and the part of the user end placed on the MDDI receiver are different parts of the same user end. It should be noted that these respective parts of the client may be parts implemented by a processor, software, or a combination thereof (for example, firmware).

At 1306, a wired functionality and a wireless functionality are provided. This functionality is contained on the MDDI receiver, enabling the MDDI receiver to communicate via the wired functionality, the wireless functionality, or both.

For example (and not limitation), the MDDI receiver can be a mobile device that can receive a communication (such as a movie displayed on a CRT screen or display). The mobile device can also be connected to a wall-mounted display, allowing movies to be displayed on the wall so that other people can view the image. If the mobile device is multifunctional, it can broadcast a movie on the display and can substantially simultaneously receive or send a voice communication that is different from the voice communication associated with the movie. Therefore, the user of the mobile device can conduct a communication separate from the movie. An example of this can be used when a user's child is watching a movie and the user wants to answer the phone and walk away. Therefore, movies can be displayed via wired functionality and generally at the same time users can communicate via wireless functionality.

Figure 14 illustrates a method 1400 for determining an operating rate according to one or more disclosed embodiments. In a wireless MDDI, for example, the MDDI operating rate depends in part on the rate of the wireless link. The method 1400 for determining an operating rate starts at 1402, in which a host MAC is queried for an available application data rate (for example, the application data rate provided by the MAC). For example, an MDDI host can request a query.

At 1404, a round-trip delay is measured. The round-trip delay measurement can be used at 1406 to determine or determine a forward link rate and a reverse link rate. According to some embodiments, the round-trip delay measurement can be specified in a wired MDDI protocol that should be used.

At 1408, an operating rate is calculated. The operating rate can be calculated in part by comparing the forward link rate with the reverse link rate and determining the minimum of the two rates. The minimum of these two rates can be designated as the operating rate. In some embodiments, the minimum of these two rates (forward link rate and reverse link rate) can be further compared with the maximum capacity of the MDDI host and the maximum capacity of the MDDI client (C1) . The minimum or lowest rate obtained based on this comparison is assigned as the operating rate.

There should be a minimum allowable rate R_min, Which can be established or predetermined based on communication parameters. If the calculated operating rate is lower than the minimum allowable rate, adjustments can be made to increase the rate. At 1410, the operating rate is communicated or sent to a receiver (e.g., MDDI receiver) to inform the receiver of the rate to be used for communication.

In the above method 1400, for example, a transmitter can query the host MAC through a query module. The transmitter can further use a measurement module to measure the round-trip delay, determine the forward and reverse link rates, and calculate the operating rate. The transmitter can also use a communication component to send the operating rate to the receiver. It should be understood that the above is for example only and other components may be utilized in conjunction with one or more of the embodiments presented herein.

Referring now to FIG. 15, it illustrates a method 1500 for communicating in a low-consumption mode according to various embodiments presented herein. The forward link is shown on the left side of the figure and the reverse link is shown on the right side of the figure.

At 1502, the forward link data is placed in a buffer. It is possible to exclude unnecessary data such as stuffing packets and/or round-trip delay packets from the data placed in the buffer. For example, an MDDI client (C1) on the MDDI transmitter can be used to place the data in the buffer. At 1504, a one-way CTA is requested (e.g., periodically or continuously). A UWB MAC can request this information from the MDDI transmitter to a receiver based on, for example, the size of the buffer. At 1506, forward link data can be sent.

In the reverse direction, a host sends at least one reverse link encapsulation packet per frame. A user end (e.g., receiver) can specify the number of bytes that should be sent on the reverse link in the current frame. The host (e.g., the transmitter) can configure the request in a reverse link encapsulation packet. At 1508, the reverse link data that should be sent is placed in a buffer by, for example, an MDDI client (C2). The buffer can be located on a UWB modem of an MDDI receiver. At 1510, a request for a CTA in the reverse direction is sent by, for example, a UWB modem on the MDDI receiver side. The request may be for their CTA in the reverse direction corresponding to the data that should be sent in the reverse direction.

At 1512, an MDDI client (C2) on the receiver can preemptively send reverse link data to the client (C1) on the transmitter. As explained, at 1514, an MDDI client (C1) on the transmitter sends the data it has to the MDDI host in reverse encapsulation packets.

Figure 16 illustrates a method 1600 for communicating in low-latency mode according to various embodiments presented herein. The forward link is shown on the left side of the figure and the reverse link is shown on the right side of the figure. During the initialization phase in the low-latency mode, at 1602, a UWB modem on the transmitter (for example) requests to continue in the forward direction<i>m</i>CTA in milliseconds. At 1604, send a continuous in the reverse direction<i>n</i>CTA request in milliseconds. At 1606, the forward and reverse CTAs received in response to the request are compared. The expected ratio of traffic in the forward and reverse directions is<i>m</i>：<i>n</i>. It should be noted that<i>m</i>The millisecond series corresponds to R_f-mddiThe duration of the MDDI forward link transfer rate and:(<i>m</i>＋<i>n</i>)&lt;<i>T</i>_<i>CTAP</i>&lt;<i>T</i>in<i>T</i>It is the duration of the super frame, which can be determined by the latency limit of the application.

In the reverse direction during the low latency mode, at 1608, the reverse link data is sent during the CTA reserved in the reverse direction. At 1610, the duration of the MAC frame can be derived from the applied latency limitation in the forward and reverse links. In the following equation,<i>k</i>It is the average number of retransmissions experienced by the MAC frame.<i>N</i>Is the size of the reverse link packet that should be sent and n is the reverse link CTA duration in each super frame.<i>R</i>_<i>1</i>It is the physical layer transmission rate of MDDI data (MAC payload).<i>R</i>_<i>2</i>It is the physical layer transmission rate of PHY, MAC header and preamble.<i>H</i>It is the size of the MAC plus the size of the PHY header plus the size of the preamble. SIFS is the short duration of the inter-frame spacing. RIFS is the duration of the interval between retransmission frames.<i>T</i>_<i>ACK</i>Is the duration of the ACK transmission and<i>T</i>It is the duration of the super frame. For the purpose of explanation, assume that the ACK strategy is Imm-ACK (Immediate Acknowledgement). Various algorithms, methods and/or techniques can be used to determine the latency of forward link packets accordingly._fl. Depending on the arrival time of the reverse link data relative to the MAC hyperframe, the transfer can have a maximum latency expressed as:<i>T</i>_<i>rl</i>＝<i>ceil</i>[{<i>k</i>*(<i>N/R</i>_<i>1</i>＋<i>RIFS</i>＋<i>H</i>/<i>R</i>_<i>2</i>)＋<i>SIFS</i>＋<i>T</i>_<i>ACK</i>}/<i>n</i>]*<i>T</i>

Figure 17 illustrates a single wireless transmitter associated with multiple wireless receivers in accordance with the disclosed embodiments. To fully understand the disclosed embodiments, various wired packets and their behavior in wireless technology will now be described. No stuffing packets are generated in wireless communication of high-rate data, because stuffing packets are designed to maintain synchronization on a wired link and are therefore unnecessary in the case of a wireless link.

A client capability packet informs the host of the client capability. In a wired link, the user end should send this packet after the forward link is synchronized. The client can also send the client capability packet when the host sends a request via the reverse link flag in the reverse link packet. The client capability packet may contain fields about links such as data rate capability before calibration, interface type capability, data rate capability after calibration, and the like. The package may also contain fields about external devices such as display devices attached to the user terminal. These fields can include the number of alternate displays, the width of the bitmap, the height of the bitmap, the width of the display window, the height of the display window, the size of the color map, etc.

During an association procedure in wireless communication, the receiver can send a client capability packet as a response to the association response packet sent by the wireless transmitter. The wireless receiver (C2) can also send an alternative display capability packet when it is associated with any alternative display. When there is a change in the state of an external device (for example, adding a new device, removing an existing device, changing the parameters of an existing device, etc.), the wireless receiver (C2) can send a client capability packet to the transmitter. Otherwise or in addition, the client capability packet may be sent periodically to assist the reliability of the client capability packet.

A client request and status packet can be used to send information from a client to a host to allow the host to optimally configure the host-to-client link. In a wired configuration, the client can send this packet to the host as the first packet in the reverse link packet. Otherwise or in addition, when the host explicitly requests the packet via a reverse link flag in a reverse link encapsulated packet, the client can send the packet to the host.

In a wireless configuration, the wireless receiver can periodically send a client request and status packet to the wireless transmitter to indicate its CRC error count and when there is a status change of the external device. When the wireless transmitter requests a client request and status packet through the C2 flag field of a new C2 request packet, the wireless receiver can also send the client request and status packet to the wireless transmitter.

Referring again to FIG. 17, each wireless transmitter 1702 (only one of them is illustrated) can be combined with multiple wireless transmitters described as receiver 1 (R1) 1704, receiver 2 (R2) 1706, and receiver 3 (R3) 1708. The receiver associates or communicates. The transmitter 1702 and the receivers 1704, 1706, and 1708 may be MDDI transmitters and/or MDDI receivers or other transmitters and receivers capable of wirelessly communicating high-rate digital data. Each receiver 1704, 1706, 1708 may have multiple displays (not shown) and devices (not shown). For example, each receiver may have sixteen displays, but there may be more or less than sixteen displays associated with a single receiver.

For example, wireless devices such as wireless displays, wireless mice, wireless keyboards, etc. may have a wireless receiver, and each wireless device may be identified as an independent client. From the point of view of a host (eg, sender 1702), each of these clients can be identified by a unique client identification code (client ID). Therefore, the client C1 may have a client ID of "0". When there is a change in the capability of the external device connected to the receiver (R2) 1706, a wireless receiver such as the receiver (R2) 1706 can send a client capability packet to the wireless (C2) transmitter 1702. In addition or otherwise, each receiver can periodically send a client capability packet to ensure reliability.

The transmitter 1702 should maintain a device association table such as the table 1800 shown in FIG. 18. Table 1800 illustrates the association between a single wireless transmitter and multiple wireless receivers (eg, clients). Based on this table, packets intended for different receiver clients can be forwarded to individual devices. Table 1800 illustrates two clients (1 and 2). The MAC address X: Y: Z: P: Q: R and the client ID "C21" are associated with the client #1. The MAC address U: V: W: L: M: N and the client ID "C22" are associated with the client #2. In this way, the transmitter can communicate with the appropriate receiver by accessing the lookup table 1800.

In order for a transmitter to communicate with a receiver, there should be device associations. Either device (transmitter or receiver) can initiate the association process. For example, if the wireless transmitter is a phone and the wireless receiver is a projector/display, the phone (e.g., the transmitter) will usually initiate communication. However, there are situations where the receiver will initiate communication. Therefore, there may be a receiver-initiated association or a transmitter-initiated association.

Referring now to the drawings, FIG. 19 illustrates a method 1900 for communicating digital data wirelessly at a high rate, which can be initiated by a receiver. The method 1900 can facilitate wireless communication between a host entity (e.g., a transmitter) and one or more remote user interface client devices (e.g., a receiver). The wireless communication may include user interface data or other data.

When one or more remote user interface client devices (eg, wireless receivers) are expected to be associated with a wireless transmitter (eg, host entity), the method 1900 begins at 1902 by associating with the host entity . The association may include sending a packet requesting an association. The host entity can substantially simultaneously communicate wirelessly with more than one remote user interface client device. Once the association with the host entity is established, a capability packet is sent to the host entity at 1904. The capability package may include one or more capabilities of the remote user interface client device. At 1906, a status packet is sent to the host entity. The status packet may include link quality information.

According to some aspects, a request for an updated status packet is received from the host entity. At substantially the same time as the response is received, the request can be answered to update the status packet and send it to the host entity. In other aspects, the updated status packet can be sent periodically or automatically when a status change is detected.

The association between one or more remote user interface client devices and host entities may be interrupted due to communication failures, devices moving out of range, or due to other factors. It can be determined that when a host entity status packet is not received within a predetermined period of time, the association is interrupted. For example, at substantially the same time as requesting a host entity status packet, a timer can be started. The timer can be set to track and send the time interval of the request. The time interval can be predetermined and should be long enough to allow the request to be received at the host entity and cause the host entity to respond. If the timer expires (for example, no response is received within a predetermined time interval), the remote user interface client device or devices can be disassociated from the host entity.

If the communication between devices should be stopped, it can also be disassociated from the host entity. If so, the remote user interface client device(s) can be disassociated from the host entity and enter a disassociated state. Disassociation may include sending a disassociation request to the host entity and receiving a disassociation response from the host entity. According to some aspects, such as when there is a communication failure or the link or association between devices has been interrupted, the disassociation response may not be received from the host entity.

Figure 20 illustrates a method 2000 for wirelessly communicating high-speed digital data. Method 2000 can begin with a receiver-initiated association. In order to associate the device (for example, the receiver) with the host entity, an association request packet is sent at 2002. The association request packet can be sent after powering on the device when C2 desires to associate with the transmitter and requests association. The association request packet can include packet length, packet type, device parameters, transmitter MAC address, receiver MAC address, and CRC fields. The packet length can be two bytes containing a 16-bit integer without a sign. The integer specifies the total number of bytes in the packet that does not include the packet length field. The length of the packet type can be two bytes and contains a 16-bit integer without a sign. The l54 packet type identifies the packet as<i>Association request packet</i>. The device parameters can be two bytes used for device-specific parameters. The transmitter MAC address can be the 6-byte MAC address of the w-MDDI transmitter, and the receiver MAC address can be the 6-byte MAC address of the w-MDDI receiver. The CRC can be two bytes containing a 16-bit CRC of all the bytes in the packet including the packet length.

At the same time as sending the association request packet, at 2004, the device can enter a "Sent Association Request (Sent Association Request)" state and can start an association timer. Before the association timer reaches a predetermined time interval (for example, timeout, expiration), the wireless transmitter should confirm the association request packet and reply with an association response packet. The association response packet may include a client ID that identifies the wireless receiver.

At 2006, it is determined whether the timer has expired. Since the basic wireless media may be unreliable, it is possible to lose the associated response packet or other packets. Therefore, if the association response packet has not been received before the timer expires ("No"), the method 2000 continues to determine whether the timer has expired at 2006. If it is determined that the timer has expired at 2006, the method 2000 continues to resend a subsequent association request packet at 2002. This can be recursive, in which numerous subsequent association request packets can be sent up to the maximum number of times.

If the timer has not expired ("No"), it is determined at 2008 whether an association response packet has been received. If it is determined at 2008 that the association response packet has been received ("Yes"), the method 2000 continues at 2010 and sends a client capability packet to the wireless transmitter that confirms the association request packet. At 2012, a status packet or a client capability packet can be transmitted. When the wireless receiver receives an association response from a wireless transmitter, it can send the client capability packet. After sending the client capability packet, the wireless receiver can enter an associated state and the associated wireless receiver can enter an associated state. In this way, a three-way handshaking association is established. If the association request packet, the association response packet, and/or the client capability packet are lost, these packets can be transmitted again (if the wireless link is stable). In other cases, the wireless transmitter and the wireless receiver do not become associated (for example, they remain in a disassociated state).

Figure 21 illustrates a method 2100 for performing receiver-initiated disassociation between a user device (e.g., receiver) and a host entity (e.g., transmitter). The method 2100 begins at 2102 by associating the user device with a host entity. At substantially the same time as the establishment of the association with the host entity, a capability packet is sent at 2104. The capability package may include one or more capabilities of the user device. At 2106, a status packet can be transmitted. The transmission of the status packet can be performed periodically or when the status changes based on a request for a packet from the host entity.

At 2108, it may be determined that the association is interrupted and/or at 2110, it may be determined to stop communication with the host entity. For example, it can be determined whether the wireless receiver has not received a transmitter MAC response packet from the wireless transmitter within a predetermined amount of time. The MAC response packet provides MAC statistics about the wireless receiver's MAC, such as the average number of retransmissions, and packet error rate. The packet content can include packet length, packet type, client ID, average number of transmissions, frame error rate, physical layer rate, and CRC. The length of the MAC response packet can be two bytes containing a sixteen-bit integer without a sign. The integer specifies the total number of bytes in the packet that does not include the packet length field. The packet type is two bytes containing a sixteen-bit integer without a sign. The 150 packet type identifies the packet as a MAC response packet. The client ID is a two-byte group containing a sixteen-bit integer without a sign. It depends on which client is the initiator of the packet and is the client ID of C1/C2. The average number of retransmissions can be two bytes and for each MAC frame transmitted in the reverse direction. The frame error rate can be two bytes and is the packet error rate seen in the forward direction. The physical layer rate can be two bytes and is the transmission rate on the physical layer. The CRC is two bytes containing the 16-bit CRC of all the bytes in the packet including the packet length.

The transmitter MAC response packet provides MAC statistics about the wireless transmitter MAC, such as the average number of retransmissions, packet error rate, and so on, to the wireless receiver. This packet is sent by the wireless transmitter that confirms the MAC response packet sent by the wireless receiver. The packet contains a packet length field of one or two bytes, which contains a 16-bit integer without a sign. The integer specifies the total number of bytes in the packet that does not include the packet length field. It also contains a packet type field of one or two bytes, which is an integer containing 16 bits without a sign. The 159 packet type identifies the packet as a sender MAC response packet. A client ID is two bytes containing a 16-bit integer without a sign. This is the client ID of C2 (target client). The average number of retransmissions is the average number of retransmissions for each MAC frame transmitted in the reverse direction. The frame error rate is the packet error rate seen in the forward direction. The physical layer rate is the transmission rate on the physical layer. The packet also contains a CRC whose length is two bytes containing the 16-bit CRC of all the bytes in the packet including the packet length.

If the association is interrupted or communication should stop, or the association is interrupted and communication should stop, the user device should be disassociated from the host entity. The disassociation may include sending an explicit disassociation request packet to the wireless transmitter at 2112. If there is still a communication link between the host entity and the user device (for example, all communications have been lost), a disassociation response packet is received from the wireless transmitter at 2114. At the same time as receiving the disassociation response, at 2116, the user device enters a disassociation state.

The disassociation request packet can be sent by C2 when it intends to disassociate from the wireless transmitter and exits smoothly. The disassociation request packet contains a packet length field. Its length is two bytes containing a 16-bit integer without a sign. The integer specifies the total number of bytes in the packet that do not contain the packet length field. Item. A packet type field contains two bytes of 16-bit integer without sign. The 156 packet type identifies the packet as<i>Disassociation request packet</i>. The client ID field is two bytes configured for the client ID of C2. The CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet including the packet length.

Respond to<i>Disassociation request packet</i>Instead, send a disassociation response packet. It has a packet length of 2 bytes. The 2 bytes contain a 16-bit integer without a sign. The integer specifies the total number of bytes in the packet that does not include the packet length field. A packet type contains two bytes of 16-bit integers without signs. The 157 packet type identifies the packet as<i>Disassociate response packet</i>. The client ID is two bytes of the client ID configured for C2 and the CRC field contains two bytes of the 16-bit CRC of all the bytes in the packet including the packet length.

Now referring to FIG. 22, it illustrates a method 2200 for performing high-rate wireless digital data communication between a transmitter and one or more remote receivers for user interface data. When the transmitter wishes to associate with a particular wireless receiver, it initiates the association. For example, if the wireless transmitter is a phone and the wireless receiver is a projector, the phone (for example, the wireless transmitter) will usually start the association process. The transmitter-initiated association is similar to the receiver-initiated association.

When a transmitter is associated with one or more remote user interface devices via a transmitter-initiated association, the method 2200 can start at 2202. The association may include sending a request to establish an association between devices to the receiver. The receiver can respond to the request, indicating that the connection is possible (for example, the receiver is not associated with another transmitter). At substantially the same time as the device is associated, a packet containing capability information is received from the remote user interface device at 2204, and link quality information is received at 2206, such as on the reverse link. The information can be sent in response to a C2 request packet, which can be sent from the wireless transmitter to the receiver to request the receiver to send a client capability packet. C2 can include packet length, packet type, C2 client ID, and C2 flag fields. The packet length field contains two bytes of a 16-bit integer without a sign. The integer specifies the total number of bytes in the packet that does not include the packet length field. The packet type contains two bytes of 16-bit integers without signs. The 149 packet type identifies the packet as a C2 request packet. The C2 client ID field contains two bytes of 16-bit unsigned integers reserved for the ID of C2. The C2 flag field is only 1 byte containing an 8-bit integer without a sign. The integer contains a set of flags to request information from C2. For example, if one bit is set to 1, C1 requests the specified information from the client. If this bit is set to 0, C1 does not need information from C2. Bit 0 indicates that C1 needs the client capability packet from C2. Bit 1 indicates that C1 needs a "client request and status packet" from C2. The CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet including the packet length.

In some cases, the transmitter may initiate an association, but the receiver may already be associated with a differential receiver or may not be expected to be associated with this transmitter. In this case, when the client (C2) does not want to associate with the w-MDDI transmitter (after the power is turned on), the client (C2) can send an association rejection packet as a response to an association request. The association rejection packet contains various fields including packet length, packet type, transmitter MAC address, receiver MAC address and CRC. The packet length can be two bytes containing a 16-bit integer without a sign. The integer specifies the total number of bytes in the packet that does not include the packet length field. The packet type can be two bytes containing a 16-bit integer without a sign. The 154 packet type identifies the packet as<i>Association request packet</i>. The transmitter MAC address can be the six-byte MAC address of the w-MDDI transmitter, and the receiver MAC address can be the six-byte MAC address of the w-MDDI receiver. The CRC is two bytes containing the 16-bit CRC of all the bytes in the packet including the packet length.

Another packet that can be sent is the MAC CTA configuration packet, which is used by the host to set the CTA in the forward and reverse directions. This can be used in the w-MDDI low-latency operating mode in the case of IEEE 802.15.3 MAC. If the MAC protocol allows the transmitter MAC to set the CTA in the reverse direction, the packet will be discarded at the transmitter. Otherwise, it will be forwarded to the receiver. MAC CTA sets the packet content to include a packet length field, which is two bytes containing a 16-bit integer without a sign. The integer specifies the total number of bytes in the packet that do not contain the packet length field . A packet type field contains two bytes of 16-bit integer without sign. The 152 packet type identifies the packet as a CTA configuration packet. The C1 client ID field contains two bytes of 16-bit unsigned integers reserved for the host's ID (0). The C2 client ID field contains two bytes of 16-bit unsigned integers reserved for the ID of C2. The forward CTA parameter is the CTA parameter used for data transfer in the forward direction and the reverse CTA parameter is the CTA parameter used for data transfer in the reverse direction.

Figure 23 illustrates a method 2300 for high-rate wireless data communication between a transmitter and a remote receiver. Method 2300 illustrates a transmitter-initiated association and starts at 2302 by transmitting a transmitter association request packet to a remote receiver. The sender association request packet is sent by the sender when it intends to associate with a particular MDDI receiver (after the power is turned on) to request an association. The sender association request packet includes: a packet length of one or two bytes, which contains a 16-bit integer without a sign, and the integer specifies the total number of bytes in the packet that does not include the packet length field; and A packet type of one or two bytes, which contains a 16-bit integer without a sign. The 158 packet type identifies the packet as<i>Association request packet</i>. It also includes: a receiver MAC address, which is six bytes and includes the receiver MAC address; and a transmitter MAC address that is the byte of the transmitter MAC address. A CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet including the packet length.

At substantially the same time as sending the first association request packet, at 2304, the transmitter enters a "sender association request sent" state and can start a timer (for example, an association timer) or other tracking means. The time interval between the transmission of the first association request packet and the reception of the response from the remote receiver (such as the association request packet) is tracked, and at 2306, it is determined whether the predetermined time interval has expired (for example, the timer has expired). Expect). If the timer has expired ("Yes"), it indicates that no association request packet has been received from the remote transmitter and the method 2300 continues at 2302, where a subsequent association request packet is sent. Any number of subsequent sender association request packets can be sent up to the maximum (e.g.,<i>max_sender_association_retry</i>)frequency. If the timer has not expired ("No"), it is determined at 2308 whether an association request packet is received.

If it is determined at 2308 that the association request packet has not been received ("No"), the method 2300 continues at 2306 until the timer expires or the association request packet is received. If the association request packet has been received ("Yes"), an association response packet that provides a client ID to the remote device can be sent.

In response to the one sent by C1<i>Association request packet</i>Instead, an association response packet is sent. This packet provides the client ID and display/device ID to C2. This is part of the three-way handshake connection. The associated response packet includes packet length, packet type, client ID and CRC. The packet length is two bytes containing a 16-bit integer without a sign. The integer specifies the total number of bytes in the packet that does not contain the packet length field. The packet type contains two bytes of 16-bit integers without signs. The 155 packet type identifies the packet as<i>Associate response packet</i>. The client ID is the two bytes of the client ID configured for C2 and the CRC is the two bytes of the 16-bit CRC containing all the bytes of the packet length in the packet.

At the same time as sending the association response packet, the sender can also start a timer such as an Association_Response timer. At 2310, on the reverse link, the receiver should reply with a client capability packet and/or link quality information. If the association-response timer expires, the wireless transmitter resends the association response packet up to the maximum number of times (for example, association_retry). The sender's association request, association request, association response, and client capabilities can constitute a four-way handshake procedure. It can also receive alternative display information from a remote device.

Figure 24 illustrates a method 2400 for performing selective disassociation between a transmitter and a remote receiver. At 2402, an association between a transmitter and a remote receiver can be established. At 2404, a packet including the capabilities of the remote receiver can be received, and at 2406, link quality information can be received. In addition, a MAC address of the transmitter and an identification code of the remote receiver can be included in a device association table associated with the transmitter.

In some cases, it may be necessary to suspend the association between the remote receiver and the transmitter, and at 2408 it can be determined that the communication between the transmitter and the remote receiver should be disabled. For example, if the wireless transmitter is not at a predetermined time interval (e.g.,<i>mac_response_fail_time</i>) If a MAC response packet is received from a receiver within milliseconds, the receiver can be declared to be disassociated, and a sender disassociation request packet is sent to the receiver at 2410. At 2412, a reply to a disassociation request (for example, a disassociation request) is received from the receiver. At 2414, a disassociation completion confirmation (for example, disassociation response) can be sent to complete the disassociation process.

In some aspects, a disassociation request may be explicitly received at 2416 from a remote receiver. At 2418, send a disassociation response confirmation (for example, disassociation response). At 2420, the identification code of the disassociated device is removed from an association table.

The sender disassociation request packet is sent by the wireless sender that initiated the disassociation. It contains a packet length field of one or two bytes, which contains a 16-bit integer without a sign. The integer specifies the total number of bytes in the packet that does not include the packet length field. A two-byte packet type field, which contains a 16-bit integer without a sign. The 157 packet type identifies the packet as<i>Disassociate response packet</i>. A client ID is two bytes of the client ID configured for C2. A CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet including the packet length.

FIG. 25 illustrates an apparatus 2500 for initial device association according to various embodiments. The device 2500 may be a receiver that is configured to communicate high-rate digital data and it is expected to be associated with a wireless transmitter or remote host device 2502. The device 2500 may include a memory 2504 that can be configured to store information. The stored information may include a MAC address and/or a client ID (as received in an associated response packet) associated with the device 2500. For example, substantially simultaneously with being associated with a particular wireless transmitter, the wireless receiver may store the MAC address of the transmitter associated with the device 2500 or the remote host device 2502.

The device 2500 may also include a processor 2506 that can be configured to analyze the information stored in the memory 2504. The processor 2506 may further selectively associate the device 2500 with the remote host device 2502. According to some aspects, the processor 2506 can associate the device 2502 with the remote host device 2502 substantially simultaneously with receiving an associated request packet from the remote host device 2502. However, if a response packet is not received from the remote host device 2502 after the predetermined time interval and the maximum number of sent association requests has been exceeded, the processor 2506 does not associate the device 2500 with the remote host device 2502.

The device 2500 may further include a communication data component 2508, which may be configured to use device MAC statistics to update a MAC response packet for transmission to the remote host device 2502. After entering an associated state, the wireless receiver can periodically (such as each<i>mac_response_time</i>Milliseconds) Send a MAC response packet. The host device 2502 can respond with a packet confirming that it has received the MAC response packet sent by the device 2500. If the device 2500 is not at a predetermined time interval (for example,<i>mac_response_fail_time</i>After receiving a response after millisecond duration), the device 2500 can infer that it has been disassociated from the host device 2502 and stop sending the MAC response packet. As described above, the device 2500 and the host device 2502 may become disassociated. In some embodiments, the device 2500 may send a MAC response packet when the host device 2502 specifically requests the MAC response packet.

The device 2500 and the remote host device 2502 may become disassociated intentionally or unintentionally. For example, the communication link between the device 2500 and the remote user device 2502 may be lost due to communication failure, devices moving out of range of each other, or for other reasons. For example, if a disassociation request packet is received from the remote host device 2502, at substantially the same time as the request is received, the processor disassociates the device 2500 from the host device 2502. In another example, if a status packet is received from the remote host device 2502 without responding to the transmitted update MAC response packet, the processor 2508 will infer that the device 2500 and the host device 2502 will no longer be associated And selectively disassociate.

According to some aspects, the device 2500 can include a display component 2510, which can be configured to compile one or more alternative display information. Alternative display information can be associated with the device 2500. The display component 2510 can be further configured to deliver the replacement display information or information to the remote host device 2502. For example, if there is an alternative display associated with the wireless receiver, an alternative display capability packet can be sent to the remote host device 2502.

Figure 26 illustrates a device 2600 for wirelessly communicating high-rate user interface data with a remote transmitter. The device 2600 may include a logic module 2602 for associating at least one receiver with a remote transmitter. The device may also include a logic module 2604 for wirelessly communicating at least one capability information of the at least one receiver to a remote transmitter. The device 2600 may further include a logic module 2606 for selectively disassociating from the remote transmitter. According to some aspects, the device 2600 may further include a logic module 2608 for receiving a data packet. The data packet may be a link quality data packet received from a remote transmitter in response to one or more link quality data packets.

Referring now to FIG. 27, it illustrates a device 2700 that can be configured to wirelessly communicate high-speed user interface data. The device 2700 can include a memory 2702 that can be configured to store information about an identification code of a remote user interface device (such as a client ID assigned to the remote device). A processor 2704 can be configured to selectively associate with one or more remote user interface devices based in part on the information stored in the memory 2702. The device 2700 can also include an information component 2706 that can be configured to analyze at least one capability of the remote user interface device or devices. The capability can be received in a client capability packet. The information component 2706 can be further configured to analyze the link quality information data received in a status update packet.

According to some aspects, the device 2700 may include a status timer 2708, which may be configured to determine whether a response to the sender association request is received within a predetermined time interval. If the response is not received within the predetermined time interval, the processor 2704 may send a subsequent sender association request.

If it is desired to disassociate the remote user interface device, the processor 2704 may selectively disassociate the remote device. For example, if the link quality information data indicates that the quality of a communication link has fallen below a predetermined threshold, the processor 2704 may selectively disassociate.

Referring now to FIG. 28, it illustrates a device 2800 for communicating user interface data wirelessly at a high rate. The device 2800 includes a logic module 2802 for associating with another device, such as one or more remote user interface devices. The association can be optional.

The device 2800 also includes a logic module 2804 for sending an association response. The association response may contain the client identification code for each individual remote user interface device. The device includes a logic module 2806 for receiving a capability packet. It also includes a logic module 2808 for associating with an identification code. The association may be based in part on a capability contained in the first capability packet.

According to some aspects, the device 2800 may include a logic module (not shown) for determining whether the capability packet is received within a predetermined time interval and a logic for sending a second request for the capability packet Module (not shown). If the capability packet is not received within the predetermined time interval, the second request can be sent.

According to other aspects, the device 2800 may include a logic module for determining whether the association with one or more remote user interface devices should be stopped. These embodiments may also include a logic module for selectively disassociating the remote user interface device(s) when the association should stop.

Referring now to FIG. 29, it illustrates a conceptual block diagram of a possible configuration of a terminal 2900. Those familiar with this technology should understand that the precise configuration of the terminal 2900 can vary depending on the specific application and overall design constraints. The processor 2902 can implement the systems and methods disclosed herein.

The terminal 2900 can be implemented by a front-end transceiver 2904 coupled to an antenna 2906. A baseband processor 2908 can be coupled to the transceiver 2904. The baseband processor 2908 can be implemented in a software-based architecture or other types of architectures. A microprocessor can be used as a platform for executing software programs, which especially provide control and overall system management functions. A digital signal processor (DSP) can be implemented as an embedded communication software layer that executes special application algorithms to reduce the processing needs of the microprocessor. DSP can be used to provide various signal processing functions, such as pilot signal acquisition, time synchronization, frequency tracking, spread spectrum processing, modulation and demodulation functions, and forward error correction.

The terminal 2900 may also include various user interfaces 2910 coupled to the baseband processor 2908. The user interface 2910 may include a keypad, a mouse, a touch screen, a display, a ringer, a vibrator, an audio speaker, a microphone, a camera, and/or other input/output devices.

The baseband processor 2908 includes a processor 2902. In a software-based embodiment of the baseband processor 2908, the processor 2902 may be a software program running on a microprocessor. However, those familiar with the art should easily understand that the processor 2902 is not limited to this embodiment, and may be any component (including any hardware configuration) known in the art that can perform the various functions described herein. , Software configuration or its combination) implementation. The processor 2902 can be coupled to the memory 2912 for storing data.

It should be understood that the embodiments described herein can be implemented by hardware, software, firmware, middleware, microcode, or any combination thereof. When the system and/or method is implemented by software, firmware, middleware or microcode, program code or code segment, it can be stored in a machine-readable medium such as a storage component. Code segments can represent procedures, functions, subroutines, programs, routines, subroutines, modules, software packages, categories, or any combination of commands, data structures, or program descriptions. The code segment can be coupled to another code segment or a hardware circuit by transmitting and/or receiving information, data, parameters, parameters, or memory content. Any suitable means including memory sharing, message transfer, token transfer, network transfer, etc. can be used to transfer, forward or transfer information, parameters, parameters, etc.

What has been described above includes examples of one or more embodiments. Of course, it is impossible to describe every conceivable combination of components or methods for the purpose of describing these embodiments, but those skilled in the art will recognize that many other combinations and permutations of the embodiments are possible. Therefore, the embodiments described herein are intended to include all such changes, modifications and changes within the spirit and scope of the scope of the appended patent application. In addition, as far as the term "includes" is used in the implementation or the scope of the patent application, the term is intended to include in a manner similar to the way the term "includes" is understood when it is used as an interim term in a claim Sexual.

<p>100. . . system</p><p>102. . . Transmitter</p><p>104. . . receiver</p><p>106. . . Data source</p><p>108. . . Interface device</p><p>200. . . Wireless transmitter</p><p>202. . . Host</p><p>204. . . Client (C1)</p><p>206. . . Traditional high data rate link</p><p>208. . . Wireless modem</p><p>300. . . Wireless transmitter</p><p>302. . . Host</p><p>304. . . user terminal</p><p>306. . . Wireless modem</p><p>400. . . Wireless transmitter</p><p>402. . . Single hardware/software entity</p><p>404. . . Wireless modem</p><p>500. . . Wireless receiver</p><p>502. . . Client (C2)</p><p>504. . . monitor</p><p>600. . . system</p><p>602. . . Transmitter</p><p>604. . . receiver</p><p>606. . . Host</p><p>608. . . Client (C1)</p><p>610. . . Communication components</p><p>612. . . Interface device</p><p>614. . . Client (C2)</p><p>616. . . Communication components</p><p>700. . . system</p><p>702. . . Transmitter</p><p>704. . . receiver</p><p>706. . . Host component</p><p>708. . . Client (C1) component</p><p>710. . . Communication components</p><p>712. . . Device</p><p>714. . . Client (C2) component</p><p>716. . . Communication components</p><p>718. . . Query module</p><p>720. . . Measurement module</p><p>722. . . Notifier module</p><p>724. . . Assigner module</p><p>726. . . Wired module</p><p>728. . . Wireless module</p><p>800. . . system</p><p>802. . . Transmitter</p><p>804. . . receiver</p><p>806. . . Host</p><p>808. . . Client (C1)</p><p>810. . . Communication components</p><p>812. . . Device</p><p>814. . . Client (C2)</p><p>816. . . Communication components</p><p>818. . . Memory</p><p>820. . . processor</p><p>900. . . system</p><p>902. . . receiver</p><p>904. . . Wireless communicator</p><p>906. . . Wired communicator</p><p>908. . . Decider</p><p>1000. . . Exemplary forward link MDDI data transfer</p><p>1002. . . MDDI transmitter</p><p>1004. . . MDDI receiver</p><p>1006. . . Client (C1)</p><p>1008. . . Client side processing (C2)</p><p>1010. . . Transmitter MAC</p><p>1012. . . Send MDDI data</p><p>1014. . . Request Forward Link CTA</p><p>1016. . . Microgrid Controller (PNC) MAC</p><p>1018. . . Channel time response code</p><p>1020. . . Receiver MAC</p><p>1022. . . Send MDDI data</p><p>1100. . . Exemplary reverse link MDDI data transfer</p><p>1102. . . MDDI receiver</p><p>1104. . . MDDI transmitter</p><p>1106. . . Client (C2)</p><p>1108. . . Client (C1)</p><p>1110. . . Receiver MAC</p><p>1112. . . Send MDDI data</p><p>1114. . . PNC MAC</p><p>1116. . . Request reverse link CTA</p><p>1118. . . Channel time response code</p><p>1120. . . Send MDDI data in CTA</p><p>1122. . . Transmitter MAC</p><p>1124. . . Give MDDI data to C1</p><p>1126. . . MDDI transmitter host</p><p>1130. . . Send reverse link data</p><p>1200. . . Low latency mode MDDI connection setting</p><p>1202. . . MDDI transmitter</p><p>1204. . . Host</p><p>1206. . . Client (C1)</p><p>1208. . . Transmitter MAC</p><p>1210. . . MAC query</p><p>1212. . . MAC response</p><p>1214. . . CTA settings</p><p>1218. . . PNC MAC</p><p>1220. . . Channel time response code</p><p>1222. . . Channel time response code</p><p>1224. . . Receiver MAC</p><p>1300. . . method</p><p>1400. . . method</p><p>1500. . . method</p><p>1600. . . method</p><p>1702. . . Wireless transmitter</p><p>1704. . . Receiver 1 (R1)</p><p>1706. . . Receiver 2 (R2)</p><p>1708. . . Receiver 3 (R3)</p><p>1800. . . Device Association Table</p><p>1900. . . method</p><p>2000. . . method</p><p>2100. . . method</p><p>2200. . . method</p><p>2300. . . method</p><p>2400. . . method</p><p>2500. . . Device</p><p>2502. . . Remote host device</p><p>2504. . . Memory</p><p>2506. . . processor</p><p>2508. . . Communication data component</p><p>2510. . . Display component</p><p>2600. . . Device</p><p>2602. . . Logic module</p><p>2604. . . Logic module</p><p>2606. . . Logic module</p><p>2608. . . Logic module</p><p>2610. . . Logic module</p><p>2700. . . Device</p><p>2702. . . Memory</p><p>2704. . . processor</p><p>2706. . . Information component</p><p>2708. . . State timer</p><p>2800. . . Device</p><p>2802. . . Logic module</p><p>2804. . . Logic module</p><p>2806. . . Logic module</p><p>2808. . . Logic module</p><p>2900. . . Terminal</p><p>2902. . . processor</p><p>2904. . . Front-end transceiver</p><p>2906. . . antenna</p><p>2908. . . Baseband processor</p><p>2910. . . user interface</p><p>2912. . . Memory</p>

Figure 1 illustrates a block diagram of a system for enabling a traditional wire-based device to communicate wirelessly.

Figure 2 illustrates a wireless transmitter according to one or more disclosed embodiments.

Figure 3 illustrates another wireless transmitter with a co-located host and user end.

Figure 4 illustrates another example of a wireless transmitter in which the host and C1 are combined into a single hardware/software entity.

Figure 5 illustrates a wireless receiver according to the disclosed embodiment.

Figure 6 illustrates a system for extending the capabilities of a traditionally wired configuration to allow communication via a wireless link.

Figure 7 illustrates a system for communicating via wired and/or wireless architectures.

Figure 8 illustrates another embodiment of a system for extending a traditional wired configuration to allow communication via a wireless link.

Figure 9 illustrates a system for communicating with a traditionally wired device via a wired link or a wireless link.

Figure 10 illustrates an exemplary forward link MDDI data transfer in a low-consumption mode according to various embodiments presented herein.

Figure 11 illustrates an exemplary reverse link MDDI data transfer in a low consumption mode according to various embodiments presented herein.

Figure 12 illustrates a low-latency mode MDDI connection setting according to various embodiments presented herein.

Figure 13 illustrates a method for configuring a traditionally wired device to communicate via a wired protocol and/or a wireless protocol.

Figure 14 illustrates a method for determining an operating rate according to one or more disclosed embodiments.

Figure 15 illustrates a method for communicating in a low-consumption mode according to various embodiments presented herein.

Figure 16 illustrates a method for communicating in low-latency mode according to various embodiments presented herein.

Figure 17 illustrates a single wireless transmitter associated with multiple wireless receivers in accordance with the disclosed embodiments.

FIG. 18 is a device association table illustrating the association between a single wireless transmitter and multiple wireless receivers.

Figure 19 illustrates a method for wirelessly communicating digital data at a high rate.

Figure 20 illustrates a method for wirelessly communicating high-rate digital data.

Figure 21 illustrates a method for performing receiver-initiated disassociation between a user device and a host entity.

Figure 22 illustrates a method for high-rate wireless digital data communication between a transmitter and one or more remote receivers for user interface data.

Figure 23 illustrates a method for high-rate wireless data communication between a transmitter and a remote receiver.

Figure 24 illustrates a method for performing selective disassociation between a transmitter and a remote receiver.

Figure 25 illustrates a device that can be configured to wirelessly communicate high-rate digital data with a remote host device.

Figure 26 illustrates a device for wirelessly communicating high-rate user interface data with a remote transmitter.

Figure 27 illustrates a device that can be configured to wirelessly communicate high-speed user interface data.

Figure 28 illustrates a device for communicating user interface data wirelessly at a high rate.

Figure 29 illustrates a conceptual block diagram of a possible configuration of a terminal.