Wireless architecture for a traditional wire-based protocol

Device for wirelessly transmitting user interface data at high speed

[0001] Information on Divisional Application

[0002] This case is a divisional application. The parent case of this division is an invention patent application with an application date of May 25, 2007, an application number of 200780015006.4, and an invention title of "Wireless Structure for Traditional Line-Based Protocols".

[0003] Cross reference to related applications

[0004] This application claims the rights and interests of the following applications under 35 USC §119(e): The title of the application on May 26, 2006 is "WIRELESS ARCHITECTURE FOR A TRADITIONAL" (WIRELESS ARCHITECTURE FOR A TRADITIONAL). WIRE-BASED PROTOCOL) U.S. Provisional Application No. 60/809,068; filed on July 26, 2006, entitled "WIRELESS ARCHITECTURE FOR A TRADITIONAL WIRE-BASED PROTOCOL) Provisional Application No. 60/833,564; and No. 60/833,565 filed on July 26, 2006 entitled "WIRELESS ARCHITECTURE FOR A TRADITIONAL WIRE-BASED PROTOCOL" (WIRELESS ARCHITECTURE FOR A TRADITIONAL WIRE-BASED PROTOCOL) No. Provisional Application, the full text of these applications is incorporated herein by reference.

Technical field

[0005] The following description relates generally to communication systems, and more specifically to enabling traditional line-based devices to communicate over wireless and/or wired links and transmit digital data at high rates.

Background technique

[0006] No matter where the user may be located at a specific time (for example, home, office, travel, ...), many people will communicate using a wireless network connection system. Wireless communication devices have become smaller and more powerful (eg, increased 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 to capture and process images (e.g., still images, moving images, video games, and the like).

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

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

[0009] In order to overcome the foregoing and other shortcomings, a technology for allowing traditional wired-based protocols to communicate through a wired structure or a wireless structure is provided. The disclosed technology provides the flexibility with minor changes to the wired structure

CN 105682152 Β

active.

Summary of the invention

[0010] The following presents a simplified overview 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 one or more embodiments, and is neither intended to identify key or decisive 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.

[0011] According to one or more embodiments and corresponding disclosures, various aspects are described in conjunction with the high-speed transmission of digital data between a host entity (for example, a transmitter) and one or more remote user devices.

[0012] According to related embodiments, a method for wirelessly transmitting 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 including at least one capability of the remote user interface client device to the host entity. The method may further include transmitting a status packet including at least one link quality information to the host entity.

[0013] Another embodiment relates to a device capable of wirelessly transmitting high-rate 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 may also include a processor that analyzes the information stored in the memory and selectively associates the device with a remote host device.

[0014] Yet another embodiment relates to a device for wirelessly transmitting high-rate user interface data. The apparatus may include means for associating at least one receiver with a remote transmitter and means for wirelessly transmitting at least one capability information of the receiver to the remote transmitter. The device may also include a device for periodically sending at least one link quality data packet to the remote transmitter and a device for selectively disassociating from the remote transmitter.

[0015] Another embodiment relates to a computer-readable medium that implements a method for wirelessly transmitting high-rate user interface data. The method may include associating one or more remote user interface devices with a host and sending a first packet including capability information of the remote user interface devices. The method may further include periodically sending at least a second packet including quality data of the communication link between the remote user interface device and the host.

[0016] Yet another embodiment relates to a processor for wirelessly transmitting high-rate user interface data. The processor may be configured to associate an interface device with a remote host, send information about the capabilities of the interface device in a capability packet, and transmit information about the communication link between the interface device and the remote host. The status package of the data.

[0017] Yet another embodiment relates to a method for 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 the reverse link from the at least one remote receiver.

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

CN 105682152 Β

[0019] Yet another embodiment relates to a device for wirelessly transmitting user interface data at a high rate. The apparatus may include means for selectively associating with at least one remote user interface device and means for sending an association response to the at least one remote user interface device. The association response may contain a client identification for the at least one remote user interface device. The apparatus may also include means for receiving a first capability package and means for associating the at least one remote user interface device with an identity based in part on at least one capability included in the first capability package.

[0020] Yet another embodiment relates to a computer-readable medium that implements a method for wirelessly transmitting high-rate user interface data. The method may include associating a host device with at least one remote client device and receiving a first packet including capability information of the at least one remote client device. The method may further include assigning a client identification to the at least one remote client device based in part on the first packet and receiving a communication included between the host device and the at least one remote client device The second packet of link quality data information.

[0021] Yet another aspect relates to a processor for wirelessly transmitting high-rate user interface data. The processor may be configured to associate a host with a remote interface device, receive information about the capabilities 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 the communication link between the remote interface device and the host in a status packet.

[0022] In order 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 claims. The following description and drawings set forth in detail certain illustrative aspects of the one or more embodiments. However, these aspects only indicate a few of the various ways in which the principles of the various embodiments can be adopted, and the described embodiments are intended to include all the aspects and their equivalents.

Description of the drawings

[0023] FIG. 1 illustrates a block diagram of a system for enabling a conventional line-based device to communicate wirelessly.

[0024] FIG. 2 illustrates a wireless transmitter according to one or more disclosed embodiments.

[0025] FIG. 3 illustrates another wireless transmitter with co-located host and client.

[0026] FIG. 4 illustrates another example of a wireless transmitter in which the host and C1 are combined on a single hardware/software entity.

[0027] FIG. 5 illustrates a wireless receiver in accordance with the disclosed embodiment.

[0028] FIG. 6 illustrates a system for extending the capabilities of a traditionally wired configuration to allow communication over a wireless link.

[0029] FIG. 7 illustrates a system for communicating via wired and/or wireless structures.

[0030] FIG. 8 illustrates another embodiment of a system for extending a traditionally wired configuration to allow communication over a wireless link.

[0031] FIG. 9 illustrates a system for communicating with traditionally wired devices through a wired link or a wireless link.

[0032] FIG. 10 illustrates an exemplary forward link MDDI data transfer in a low overhead mode according to various embodiments presented herein.

[0033] FIG. 11 illustrates an exemplary reverse link MDDI data transfer in a low overhead mode according to various embodiments presented herein.

[0034] FIG. 12 illustrates low-latency mode MDDI connection settings according to various embodiments presented herein.

[0035] FIG. 13 illustrates a method for configuring a traditionally wired device to communicate through a wired protocol and/or a wireless protocol.

CN 105682152 Β

[0036] FIG. 14 illustrates a method for determining an operating rate in accordance with one or more disclosed embodiments.

[0037] FIG. 15 illustrates a method for communicating in a low overhead mode according to various embodiments presented herein. [0038] FIG. 16 illustrates a method for communicating in a low-latency mode according to various embodiments presented herein. [0039] FIG. 17 illustrates a single wireless transmitter associated with multiple wireless receivers in accordance with the disclosed embodiments.

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

[0041] FIG. 19 illustrates a method for wirelessly transmitting digital data at a high rate.

[0042] FIG. 20 illustrates a method for wirelessly transmitting high-rate digital data.

[0043] FIG. 21 illustrates a method for receiver-initiated disassociation between a user device and a host entity.

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

[0045] FIG. 23 illustrates a method for high-rate wireless data communication between a transmitter and a remote receiver.

[0046] FIG. 24 illustrates a method for selective disassociation between a transmitter and a remote receiver.

[0047] FIG. 25 illustrates an apparatus that can be configured to wirelessly transmit high-rate digital data with a remote host device.

[0048] FIG. 26 illustrates an apparatus for wirelessly transmitting high-rate user interface data with a remote transmitter.

[0049] FIG. 27 illustrates a device that can be configured to wirelessly transmit high-rate user interface data.

[0050] FIG. 28 illustrates an apparatus for wirelessly transmitting user interface data at a high rate.

[0051] FIG. 29 illustrates a conceptual block diagram of a possible configuration of a terminal.

Detailed ways

[0052] Various embodiments are now 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 may be obvious that the embodiments can be practiced without these specific details. In other cases, well-known structures and devices are shown in block diagram form in order to help describe these embodiments.

[0053] As used in this application, the terms "component", "module", "system" and the like are intended to refer to computer-related entities (hardware, firmware, a combination of hardware and software, software or software in execution) . For example, a component may be (but is not limited to) a process, a processor, an object, an executable file, a thread of execution, a program, and/or a computer running on a processor. For illustration, both the application program running on the computing device and the computing device may be components. One or more components may reside in a process and/or execution thread, and the components may be limited to one computer and/or dispersed between two or more computers. In addition, these components can execute from various computer-readable media having various data structures stored thereon. A component can communicate via a local process and/or a remote process, for example, based on a signal with one or more data packets (e.g., from a signal that interacts with another component in a local system, a distributed system, and/or a signal across For example, the data of components interacting between the Internet and other systems).

[0054] In addition, various embodiments are described herein in connection with a user device. User devices can also be referred to as systems, subscriber units, subscriber stations, mobile stations, mobile devices, remote stations, access points, base stations, remote terminals, access terminals, handsets, user terminals, terminals, user agents, or user equipment . The user device can be a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a PDA, a handheld device with wireless connection capabilities, or other processing devices connected to a wireless modem.

[0055] In addition, standard programming and/or design techniques may 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 cover readable from any computer

CN 105682152 Β

A computer program for device, carrier, or media access. For example, computer-readable media may include (but are not limited to) magnetic storage devices (for example, hard disks, floppy disks, magnetic strips, ...), optical disks (for example, compact disks (CD), digital versatile disks (DVD), ...) ·), smart cards and flash memory devices (for example, cards, sticks, key drives,...).

[0056] In the following embodiments, various aspects and embodiments may be described in the context of the Mobile Display Digital Interface (MDDI) and/or the Institute of Electrical and Electronics Engineers (IEEE) 802.15.3 Media Access Control (MAC) layer. Although these inventive aspects may be well-suited for use with the disclosed embodiments, those skilled in the art will readily understand that these inventive aspects are equally applicable for use in various other traditional wire-based protocols. Therefore, any reference to MDDI and/or IEEE 802.15.3 MAC is only intended to illustrate the inventive aspects, and it should be understood that the inventive aspects have a wide range of applications.

[0057] Various embodiments will be presented depending 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 all 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 multiple mobile devices (eg, 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.

[0058] Referring now to the drawings, FIG. 1 illustrates a block diagram of a system 100 for enabling a conventional line-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 may be components that traditionally communicate through a wire-based protocol. Although, as will be understood, a large number of transmitters 102 and receivers 104 may be included in the system 100, for the sake of simplicity, a single transmitter 102 that transmits a communication data signal to a single receiver 104 is described.

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

[0060] The system 100 can operate in at least two operating modes (ie, a low overhead mode and/or a low latency mode). Low overhead mode optimizes packets sent in the air (for example, wirelessly) by requesting channel allocation time, which allows data to be sent from either direction (from transmitter to receiver or from receiver to transmitter) time. In the low latency mode, the channel allocation time can be determined based on the knowledge of the data contained in both the forward link and the reverse link.

[0061] The transmitter 102 may be configured to determine the forward link rate and the reverse link rate based on various criteria (eg, round-trip delay measurement). The transmitter 102 can transmit at least one reverse link encapsulation packet every frame. The reverse link encapsulation packet can be adapted to transfer the reverse packet through the transfer link, thereby establishing a reverse link.

[0062] The receiver 104 may be configured to receive and/or transmit data communications through 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 transmitting the data (for example, a wired link or a wireless link), and the size of the file or packet to be transmitted. Various criteria and other criteria regarding data, transmitter and/or receiver. The transmitter 102 can transmit data without knowing how the receiver 104 receives the data (for example, wired or wireless).

[0063] FIG. 2 illustrates a wireless transmitter 200 according to one or more disclosed embodiments. The wireless transmitter 200 may be configured to transmit high-rate data (eg, digital data). The various wireless systems described herein may include wireless transmitters and wireless receivers. 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. Host 202 and client (C1) 204 can pass through traditional high data rate links

CN 105682152 Β

(For example, MDDI) 206 connection. 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 link configured to support high-speed data) Road) in. 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 that are co-located. The wireless modem 306 is also included. Another example of a wireless transmitter 400 is illustrated in FIG. 4, where the host and C1 are combined on a single hardware/software entity 402. A wireless modem 404 is included to facilitate wireless communication.

[0064] Reference is now made to FIG. 5, which illustrates a wireless receiver 500 in accordance with the disclosed embodiment. The wireless receiver 500 includes a client (C2) 502, which can be connected to several 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 the physical layer of the MDDI stack. A single transmitter can be connected to several receivers according to the disclosed embodiments.

[0065] FIG. 6 illustrates a system 600 for extending the capabilities of a traditionally wired configuration to allow communication over a wireless link. The system 600 includes a transmitter 602 that communicates with a receiver 604 through a forward link. The receiver 604 communicates with the transmitter 602 through a reverse link. The transmitter 602 and the receiver 604 may be devices that generally communicate through a wired protocol, however, the system 600 allows the devices to communicate through a wired protocol and/or through a wireless protocol (for example, through a high-speed wireless link). Although, as will be understood, numerous transmitters 602 and receivers 604 may be included in the system 600, for simplicity purposes, a single transmitter 602 that transmits communication data signals to a single receiver 604 is described.

[0066] The transmitter 602 may include a host 606, a part of the 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 through a wired link. Keep a part of the client (C1) 608 turned on or communicate with the host 606 for clock synchronization. For example, the client (C1) 608 may be connected to the host 606 through a traditional wired link (for example, an MDDI link). The host 606 may be configured to send or transfer data packets to the client (C1) 608. These packets may be transmitted to the receiver 604 through a communication component 610, which may 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 (Cl) 608 and transmitted to the receiver 604. Other packets (for example, a filler packet) should be discarded by the client (C1) 608 and not transmitted to the receiver 604. In other words, some packets should not be 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 packet can be generated by the transmitter 602 or the receiver 604 through the corresponding client part.

[0067] 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 through, for example, a wired link. The client (C2) 614 may be connected to the device 612 through a wired link. The client (C2) 614 may be configured to process packets received from the transmitter 602. The receiver 604 may receive the communication from the transmitter 602 through a communication component 616, which may include, for example, a UWB modem.

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

CN 105682152 Β

[0069] For the low latency mode, during the initialization phase, the communication component 610 (eg, UWB modem) may request a CTA lasting m milliseconds in the forward direction and a CTA lasting n milliseconds in the reverse direction. The expected ratio of traffic in the forward and reverse directions is m:n and m seconds is the duration corresponding to the forward link transfer rate of Rf-mddi. T is the superframe duration, which is determined by the waiting time limit of the application, where:

[0070] (m+n)<Tctap<T

[0071] Referring now to FIG. 7, it illustrates a system 700 for communicating via wired and/or wireless structures. The system 700 includes a transmitter 702 and a receiver 704, and 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 through the forward link and/or the reverse link can be based on specific 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 through The wireless protocol is carried out. Although, as will be understood, numerous transmitters 702 and receivers 704 may be included in the system 700, for simplicity purposes, a single transmitter 702 that transmits a communication data signal to a single receiver 706 is described.

[0072] 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) component 714 and a communication component 716. The client (C1) component 708 and the client (C2) component 714 are corresponding parts of the client.

[0073] Those skilled in the art will understand that the transmitter 702 and/or the receiver 704 may include additional components. For example, the transmitter 702 may include an encoder component (not shown), which may modulate and/or encode a signal according to a suitable wireless communication protocol, and the signal may be subsequently 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 Mobile communication system (GSM), high-speed downlink packet access (HSDPA) and the like.

[0074] The receiver 704 may include a decoder component (not shown) that can decode the received signal and/or the data packet therein for processing. After successfully decoding the data packet, the 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.

[0075] The host component 706 may include a query module 718 and a measurement module 720. The query module 718 may be configured to query the host media access control (MAC) for the 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 may be configured to determine the forward link rate and the reverse link rate based on, for example, round-trip delay measurements that may be specified in the wireless protocol. In some embodiments, the wireless operation rate may 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 Rmin. If the measured operating rate is lower than the minimum allowable rate, the operating rate can be adjusted by the transmitter 702 and/or the receiver 704 through corresponding components (for example, the communication components 710 and/or 716). The transmitter 702 may inform the receiver 704 of the rate to be used to process the communication.

[0076] The client (C2) component 714 may include a notifier module 722, which may 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 (eg, 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 (assigned module 724, which may be configured to depend on various parameters associated with the communication (eg, communication type, rate of communication, transmitter, receiver, and the like) Instead, the communication is assigned to a wired protocol or a wireless protocol.

CN 105682152 Β

[0077] The communication component 716 may include a wired module 726 and a wireless module 728. The wired module 726 may be configured to provide wired functionality and the wireless module 728 may be configured to provide wireless functionality. It may be determined whether to use the wireless module 728 to communicate wirelessly or to use the wired module 726 to communicate. The determination may be based on including the operating rate, the type of data transmitted (for example, voice, text, image, ...), the size of the data or file transmitted, whether the data is usually transmitted 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 storage for content so that changes (eg, wireless to wired, wired to wireless) will not be lost due to conversion issues when changes are made during communication from one module to another.ofBuffer.

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

[0079] According to some embodiments, the transmitter 702 may include a component (not shown) configured to segment subframes, and the receiver 704 may include a component (not shown) configured to reassemble the subframes . The maximum length of the MDDI subframe (for example) may be about 65,536 bytes, although it is usually small. If the basic rate is about 480Mbps, the maximum size of the 802.15.3 MAC frame may be about 4,096 or about 8,192 bytes. If the basic physical layer rate is approximately 200 Mbps, the size may be approximately 2,048 bytes. Therefore, the subframe may need to be segmented on the transmitter 702 side and reassembled on the receiver 704 side to fit the size of the frame. The segmentation and reassembly may be performed by the respective communication components 710 and 716 and/or other components associated with the transmitter 702 and receiver 704.

[0080] FIG. 8 illustrates another embodiment of a system 800 for extending a traditionally wired configuration to allow communication over a wireless link. The system 800 may include a transmitter 802, which includes a host 806, a part of the client (C1) 808, and a communication component 810. The system 800 may also include a receiver 804, which includes a device 812, a part of the client (C2) 814, and a communication component 816. The transmitter 802 communicates to the receiver 804 through the forward link and the receiver 804 communicates to the transmitter 802 through the reverse link. As mentioned previously with respect to the above figures, although a large 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 a communication data signal to a single receiver 804 is described. .

[0081] The system 800 may include a memory 818 operably coupled to the receiver 804. The memory 818 can store data rates about packets and/or packet types (for example, the application data rate provided by the MAC, the operating rate of the wireless link...), the operation modes of the packets and/or the packet types, and/or the data rate related to the packet and/or packet type. , Transmit information about other parameters associated with data through a wired protocol or a combination of these protocols. For example, a wired protocol can be used to communicate during communication and the decision to switch to a wireless protocol can be made, or vice versa, without interruption or termination.

[0082] The processor 820 is operatively connected to the receiver 804 (and/or the memory 818) to facilitate analysis of information regarding determining whether a particular 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 the processor of one or more components of the system 800.

[0083] The memory 818 may store protocols associated with data communication rates, operating rates, actions taken to control the communication between the receiver 804 and the transmitter 802, etc., so that the system 800 may use the stored protocols and/or algorithms to Improved communication is achieved in wireless networks as described herein. It should be understood that the data storage (eg, memory) components described herein may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. For example (and not limitation), non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Flash memory. Volatile memory may include random access memory (RAM), which acts as external cache memory. By way of example (and not limitation), RAM is available in many forms, such as

CN 105682152 Β

Synchronous RAM (DRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Memory Bus RAM (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.

[0084] FIG. 9 illustrates a system 900 for communicating with a conventional wired device through 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 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 communications via a wireless protocol. The wired communicator 906 may be configured to send and/or receive communications through a wired protocol.

[0085] It should be noted that there may be package extensions and/or new packages in the forward and/or reverse direction. For example, in the forward direction, MDDI transmitter information can be added to the packet. This package extension can provide MDDI sender 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 to the client capability package can include about four bytes for MDDI receiver MAC information and about two bytes for MDDI receiver client information. However, other extensions are also possible. of.

[0086] The system 900 also includes a determiner, which can selectively determine whether to use a wireless communicator to communicate through a wireless protocol or to use a wired communicator to communicate through a wired protocol. The determination may be selectively made based on various parameters such as the communication operation rate. Other parameters can also be analyzed to make the determination. For example, it can be based on how specific communications are traditionally sent and/or received (e.g., historical analysis), the type of communications (e.g., voice, image, text,...), and other information about communications, transmitters, and/or receivers. Parameters to make the determination.

[0087] FIG. 10 illustrates an exemplary forward link MDDI data transfer 1000 in a low overhead mode according to various embodiments presented herein. One type of mode for the MDDI transmitter 1002 to send data to the MDDI receiver 1004 may be a low overhead mode. In this mode, wirelessly transmitted packets are optimized for channel allocation time, which is the time it takes to transmit 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.

[0088] The MDDI client (C1) 1006 may place the data to be transmitted in a buffer on, for example, 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, the MDDI data is sent to the transmitter MAC 1010. The transmitter MAC 1010 (or UWB MAC) may periodically or continuously request data from the MDDI transmitter 1002 to the MDDI receiver 1004 based on, for example, the size of the buffer. At least one CTA.

[0089] At 1014, the transmitter MAC 1010 may request a forward link CTA from a piconet controller (PNC) MAC 1016 (eg, 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 transmitted. After receiving the successful channel time response code, as indicated at 1022, the transmitter MAC 1010 may send MDDI data to the receiver MAC 1020.

[0090] FIG. 11 illustrates an exemplary reverse link MDDI data transfer 1100 in a low overhead mode according to various embodiments presented herein. The MDDI receiver 1102 may initiate a given to the MDDI transmitter 1104 via the reverse link. Communication. 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.

[0091] As indicated at 1112, the MDDI receiver 1102 may send MDDI data to the receiver MAC 1110. At 1116, receiver MAC 1110 may request reverse link CTA from PNC MAC 1114. The request may correspond to that should be in the reverse direction

CN 105682152 Β

Data sent on. At 1118, PNC MAC 1114 can respond with the channel time response code. At 1120, the receiver MAC 1110 may place the HB in the 0^. . 1 Data is sent to the transmitter song. 1122_OAs indicated at 1124, the transmitter MAC 1122 may have sent or given MDDI data to the client at 1124 at some 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 encapsulation every frame. Reverse link data can be sent preemptively without waiting for data requests. The client can specify the number of bytes that need to be sent on the reverse link in the current frame. The host 1126 can correspondingly allocate the request in the reverse link encapsulation packet.

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

[0093] The host sends a MAC query packet to query MAC information on the transmitter/receiver side. The packet length field is two bytes containing a 16-bit unsigned integer, and the integer specifies the total number of bytes in the packet that does not include the packet length field. The packet type field is two (2) bytes containing 16-bit unsigned integers. 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 is two bytes containing a 16-bit CRC of all bytes including the packet length in the packet.

[0094] The transmitter 1202 requests a CTA setting 1214 lasting m milliseconds in the forward direction and a CTA lasting n milliseconds in the reverse direction. The expected ratio of traffic in the forward and reverse directions should be m:n. At 1216, send the channel time request (CTRq) to PNC Mac 1218_OThe 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 the receiver MAC 1224_OAs illustrated at 1226, the MDDI transmitter 1202 may start the MDDI transfer.

[0095] The duration corresponding to the MDDI forward link transfer rate of R-mddi is m seconds, and when T is the superframe duration determined by the waiting time limit of the application, the following formula applies:

[0096] m+n<TcTAP<T

[0097] In the low latency mode, reverse link data can be sent during the CTA reserved in the reverse direction. Depending on the arrival time of the reverse link data relative to the MAC superframe, the delivery can have a maximum waiting time expressed as:

[0098] Tri = ceset[{k* (N/R1+RIFS+H/R2) +SIFS+Tack} /n] *Τ

[0099] where k is the average number of retransmissions experienced by the MAC frame. N is the size of the reverse link packet that should be sent and n is the reverse link CTA duration in each superframe. Ri is the physical layer transmission rate of MDDI data (MAC payload). R2 is the physical layer transmission rate of the PHY.MAC header and preamble. Η is the size of the MAC plus the size of the PHY header plus the size of the preamble. SIFS is a short inter-frame space duration. RIFS is the duration of the interval between retransmission frames. Tack is the duration of the transmission of ACK. T is the superframe duration. For the purpose of explanation, assume that the ACK strategy is Imm-ACK (Immediate Acknowledgement). The waiting time Tfi of the forward link packet can be determined accordingly. Given the application waiting time limit in the forward and reverse links, the duration of the MAC frame can be derived accordingly. For example, various algorithms, methods, and/or techniques can be used to derive the duration of the MAC frame and/or the waiting time of the forward link packet.

CN 105682152 Β

[0100] In view of the exemplary systems shown and described, methods that can be implemented according to one or more embodiments are provided. Although the method is shown and described as a series of actions (or functional blocks) for the purpose of simplifying the explanation, it should be understood and understood that the method is not limited by the sequence of actions, because according to these methods, some actions It may occur in a different order and/or concurrently with other actions from the 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 may be implemented by software, hardware, a combination thereof, or any other suitable means (eg, device, system, process, component) for performing the functionality associated with the action. It should also be understood that the actions will only illustrate certain aspects presented herein in a simplified form, and these aspects may be illustrated by a smaller and/or larger number of actions. Those skilled in the art should understand and understand that the method may alternatively be represented as a series of related states or events in a state diagram, for example.

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

[0102] At 1304, the second part of the client is placed on the 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 client placed on the MDDI transmitter and the part of the client placed on the MDDI receiver are different parts of the same client. It should be noted that the corresponding part of the client may be a part implemented by a processor, software, or a combination thereof (for example, firmware).

[0103] At 1306, both wired functionality and wireless functionality are provided. This functionality is included on the MDDI receiver, enabling the MDDI receiver to communicate through the wired functionality, the wireless functionality, or the two functionality.

[0104] By way of example (and not limitation), the MDDI receiver may be a mobile device that can receive communications (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 imaging. If the mobile device is multifunctional, it can broadcast a movie on the display, and can generally simultaneously receive or transmit voice communications that are different from the voice communications associated with the movie. Therefore, the user of the mobile device can communicate separately from the movie. An example where this function can be used is when the user's children are watching a movie and the user wants to answer the phone and walk away. Therefore, movies can be displayed through wired functionality, and generally at the same time users can communicate through wireless functionality.

[0105] FIG. 14 illustrates a method 1400 for determining an operating rate in accordance with one or more disclosed embodiments. In wireless MDDI, for example, the MDDI operating rate depends in part on the rate of the wireless link. The method 1400 for determining the operating rate starts at 1402, where the host MAC is queried for the available application data rate (eg, the application data rate provided by the MAC). For example, the MDDI host can request the query.

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

[0107] At 1408, the 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 which of the two rates is the minimum. 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) may be further compared with both 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.

[0108] There should be a minimum allowable rate Rmg which can be established or predetermined based on communication parameters. If the calculated operation

CN 105682152 Β

If the 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 (eg, MDDI receiver) to inform the receiver of the rate that will be used for communication.

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

[0110] Reference is now made to FIG. 15 which illustrates a method 1500 for communicating in a low overhead 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.

[0111] At 1502, the forward link data is placed in the buffer. Unnecessary data such as padding packets and/or round-trip delay packets can be excluded from the data placed in the buffer. For example, the data can be placed in the buffer through the MDDI client (C1) on the MDDI transmitter. At 1504, a request for one-way CTAoUWB MAC (eg, periodically or continuously) may request this information from the MDDI transmitter to the receiver based on, for example, the size of the buffer. At 1506 forward link data can be sent.

[0112] In the reverse direction, the host sends at least one reverse link encapsulation packet per frame. The client (for example, the receiver) can specify the number of bytes that should be sent on the reverse link in the current frame. The host (for example, the sender) can distribute the request in the reverse link encapsulation packet. At 1508, the reverse link data that should be sent is placed in the buffer by, for example, the MDDI client (C2). The buffer may be located on the UWB modem of the MDDI receiver. At 1510, a request for reverse direction CTA is sent by, for example, a UWB modem on the MDDI receiver side. The request may be for those CTAs in the reverse direction that correspond to data that should be sent in the reverse direction.

[0113] At 1512, the MDDI client (C2) on the receiver may preemptively send reverse link data to the client (C1) on the transmitter. As explained, at 1514, the MDDI client (C1) on the transmitter sends the data it has to the MDDI host in a reverse encapsulation packet.

[0114] FIG. 16 illustrates a method 1600 for communicating in a 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, the UWB modem on the transmitter (for example) requests a CTA that lasts m milliseconds in the forward direction. At 1604, a CTA request for n milliseconds is sent in the reverse direction. 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 m:n. It should be noted that m milliseconds corresponds to the duration of the MDDI forward link transfer rate of Rf-mddi and:

[0115] (m+n)<Tctap<T

[0116] where T is the superframe duration, which can be determined by the waiting time limit of the application.

[0117] In the reverse direction during the low latency mode, at 1608, 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 application latency limits in the forward and reverse links. In the following equation, k is the average number of retransmissions experienced by the MAC frame. N is the size of the reverse link packet that should be sent, and n is the reverse link CTA duration in each superframe. Ri is the physical layer transmission rate of MDDI data (MAC payload). R2 is the physical layer transmission rate of the PHY.MAC header and preamble. Η is the size of the MAC plus the size of the PHY header plus the size of the preamble. SIFS is a short inter-frame space duration. RIFS is the duration of the interval between retransmission frames. Tack is the duration of the transmission of ACK and T is the superframe duration. For explanation purposes, it is assumed that the ACK strategy is Imm-ACK (Immediate Acknowledgement). Various algorithms, methods and/or techniques can be used to determine the waiting time Tfi of the forward link packet accordingly. According to the arrival time of the reverse link data relative to the MAC superframe, the transfer can have a maximum waiting time expressed as:

CN 105682152 Β

[0118] Tri = ce fixed [{k* (N/R1+RIFS+H/R2) +SIFS+Tack} /n] *Τ

[0119] FIG. 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.

[0120] The client capability package informs the host of the capabilities of the client. In a wired link, the client 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 through the reverse link flag in the reverse link encapsulation packet. The client capability packet may contain fields regarding links such as pre-calibration data rate capability, interface type capability, post-calibration data rate capability, and the like. This packet may also contain fields regarding external devices such as display devices attached to the client. The fields may include the number of replacement displays, bitmap width, bitmap height, display window width, display window height, color map size, and so on.

[0121] During the association procedure in wireless communication, the receiver may 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 alternate display capability package when it is associated with any alternate display. When there is a change in the state of the external device (for example, adding a new device, removing an existing device, changing the parameters of the existing device, etc.), the wireless receiver (C2) may send the client capability packet to the transmitter. Alternatively or in addition, the client capability package may be sent periodically to assist the reliability of the client capability package.

[0122] Client requests and status packets can be used to send information from the client to the 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. Alternatively or additionally, when the host explicitly requests this packet through the reverse link flag in the reverse link encapsulation packet, the client can send this packet to the host.

[0123] 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 the client request and status packet through the C2 flag field of the new C2 request packet, the wireless receiver may also send the client request and status packet to the wireless transmitter.

[0124] Referring again to FIG. 17, each wireless transmitter 1702 (only one of which is illustrated) can be described as a receiver 1 (R1) 1704, a receiver 2 (R2) 1706, and a receiver 3 (R3) 1708. Multiple wireless receivers are associated or communicated. The transmitter 1702 and the receivers 1704, 1706, and 1708 may be MDDI transmitters and/or MDDI receivers or other transmitters and receivers that can wirelessly transmit 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.

[0125] For example, a wireless device such as a wireless display, a wireless mouse, a wireless keyboard, etc. may have a wireless receiver, and each wireless device may be identified as a separate client. From the perspective of the host (for example, the sender 1702), each of these clients can be identified by a unique client identification (client ID). Therefore, the client C1 may have a client ID of "0". When the capability of the external device connected to the receiver (R2) 1706 changes, for example, the wireless receiver of the receiver (R2) 1706 may send the client capability packet to the wireless (C2) transmitter 1702. Additionally or alternatively, each receiver may periodically send client capability packets to ensure reliability.

[0126] The transmitter 1702 should maintain a device association table such as the table 1800 shown in FIG. 18. Table 1800 illustrates the association of a single wireless transmitter with multiple wireless receivers (e.g., clients). The packets intended for different receiver clients can be forwarded to the corresponding device based on the table. Table 1800 shows two clients (1 and 2) °MAC address X:Y:Z:P:Q:R and client ID

CN 105682152 Β

"C21" is associated with 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.

[0127] In order for the transmitter to communicate with the receiver, there should be a device association. 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 (eg, 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.

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

[0129] When one or more remote user interface client devices (eg, wireless receivers) desire to associate with a wireless transmitter (eg, host entity), the method 1900 begins by associating with the host entity at 1902 . The association may include sending a packet requesting the association. The host entity may wirelessly communicate with more than one remote user interface client device at substantially the same time. Once an association is established with the host entity, the 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, the status packet is sent to the host entity. The status packet may include link quality information.

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

[0131] The association between one or more remote user interface client devices and the host entity may be interrupted due to a communication failure, the device moves out of range, or based on other factors. If the host entity status packet is not received within a predetermined period, the associated interruption can be determined. For example, at substantially the same time as the request for the host entity status packet, the timer may be started. The timer can be set to track and send the request time interval. The interval may 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 (eg, no response is received within a predetermined interval), the one or more remote user interface client devices may be disassociated from the host entity.

[0132] If the communication between the devices should be stopped, it can also be disassociated from the host entity. If so, the one or more remote user interface client devices 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, for example, 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.

[0133] FIG. 20 illustrates a method 2000 for wirelessly transmitting high-rate digital data. The method 2000 may start with a receiver-initiated association. To associate a device (eg, a receiver) with a host entity, an association request packet is sent at 2002. The association request packet may be sent by C2 for an association request after the device is powered on when C2 expects to associate with the transmitter. The association request packet may 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 unsigned integer that specifies the total number of bytes in the packet that does not include the packet length field. The packet type can be two bytes in length and contain 16-bit integers without signs. The 154 packet type identifies the packet as an association request packet. Device parameters can be two bytes 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 may be two bytes containing a 16-bit CRC of all bytes in the packet including the packet length.

[0134] At the same time as sending the association request packet, at 2004, the device can enter the "Sent Association Request (Sent

CN 105682152 Β

Association Request) status and the association timer can be started. Before the association timer reaches a predetermined 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.

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

[0136] 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 the client capability packet is sent 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 the association response from the wireless transmitter, the client capability packet may be sent. After sending the client capability package, the wireless receiver can enter the associated state and the associated wireless receiver can enter the associated state. In the manner described, a three-way handshake association is established. If the association request packet, association response packet, and/or client capability packet are lost, these packets can be retransmitted when the wireless link is stable. Otherwise, the wireless transmitter and the wireless receiver do not become associated (for example, it remains in a disassociated state).

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

[0138] At 2108, an associated interruption can be determined and/or at 2110, a decision can be made to stop communication with the host entity. For example, if the wireless receiver does not receive the transmitter MAC response packet from the wireless transmitter within a predetermined amount of time, the determination may be made. The MAC response packet provides MAC statistics about the wireless receiver's MAC, such as the average number of retransmissions, packet error rate, and so on. The packet content can include packet length, packet type, client ID, average number of transmissions, frame error rate, physical layer rate, CRC°MAC response packet length can be two containing sixteen-bit integers without signs Byte, the integer specifies the total number of bytes in the packet that do 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 two bytes containing a sixteen-digit integer without a sign. It depends on which client is the initiator of the package but 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 experienced 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 a sixteen-bit CRC of all bytes in the packet including the packet length.

[0139] The transmitter MAC response packet provides MAC statistics about the wireless transmitter MAC such as the average number of retransmissions, packet error rate, etc., 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 length field containing two bytes contains a 16-bit integer without a sign, and the integer specifies the total number of bytes in the packet that do not include the packet length field. It also contains a two-byte packet type field, which contains a 16-bit integer without a sign. The 159 packet type identifies the packet as a transmitter MAC response packet. The client ID is two bytes containing a 16-bit unsigned integer. This is the client ID of the target client C2. 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 experienced in the forward direction. Physical layer rate

CN 105682152 Β

Is the transmission rate on the physical layer. The packet also contains a CRC, and its length is two bytes containing a 16-bit CRC of all bytes in the packet including the packet length.

[0140] If the association is interrupted or communication should stop, or if 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 communication has been lost), a disassociation response packet is received from the wireless transmitter at 2114. At substantially the same time as receiving the disassociation response, at 2116, the user device enters the disassociation state.

[0141] 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, the length of which is two (2) bytes containing a 16-bit unsigned integer, the integer specifies the total number of bytes in the packet that do not contain the packet length field Item. The packet type field is two bytes containing a 16-bit unsigned integer. The 156 packet type identifies the packet as a disassociation request packet. The client ID field is two bytes of the client ID allocated for C2. The CRC field is two (2) two (2) 16-bit CRCs containing all bytes in the packet including the packet length.

Ττ ο

[0142] In response to the disassociation request packet, a disassociation response packet is sent. 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. The packet type is two (2) bytes containing 16-bit unsigned integers. The 157 packet type identifies the packet as a disassociation response packet. The client ID is two bytes allocated for the client ID of C2, and the CRC field is two bytes containing a 16-bit CRC of all bytes including the packet length in the packet.

[0143] Referring now to FIG. 22, it illustrates a method 2200 for high-rate wireless digital data communication between a transmitter and one or more remote receivers for user interface data. When the transmitter desires 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 (eg, wireless transmitter) will usually start the association process. The transmitter-initiated association is similar to the receiver-initiated association.

[0144] The method 2200 may begin at 2202, when the transmitter is associated with one or more remote user interface devices through a transmitter-initiated association. The association may include sending a request to establish an association between the devices to the receiver. The receiver may respond to the request, indicating that the association is possible (eg, the receiver is not associated with another transmitter). At substantially the same time as associating the device, a packet containing capability information is received from the remote user interface device at 2204, and link quality information is received at 2206, for example, on the reverse link. The information may be sent in response to a C2 request packet, which may be sent by the wireless transmitter to the receiver to request the receiver to send a client capability packet. C2 may include packet length, packet type, C2 client ID, and C2 flag fields. The packet length field is two bytes containing a 16-bit unsigned integer that 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 16-bit unsigned integer. The 149 packet type identifies the packet as a C2 request packet. The C2 client ID field is two bytes containing a 16-bit unsigned integer reserved for the ID of C2. The C2 flag field is only 1 byte containing an 8-bit unsigned integer that contains a set of flags to request information from C2. For example, if you set a Set to 1, then C1 requests the specified information from the client. If the bit is set to 0, then C1 does not need information from C2. Bit 0 indicates that C1 needs a client capability package from C2. Bit 1 indicates that C1 needs a "client request and status packet" from C2. The CRC field is two bytes containing a 16-bit CRC of all bytes in the packet including the packet length.

[0145] In some situations, 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 power-up), the client (C2) can send an association rejection packet as a reply to the association request. The association refused to include the inclusion package

CN 105682152 Β

Various fields of length, packet type, transmitter MAC address, receiver MAC address and CRC. The packet length may be two bytes containing a 16-bit unsigned integer, and 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 unsigned integer. The 154 packet type identifies the packet as an association request packet. The Mac address of the transmitter may be the six-byte MAC address of the w-MDDI transmitter, and the MAC address of the receiver may be the six-byte MAC address of the w-MDDI receiver. The CRC is two bytes containing a 16-bit CRC of all bytes in the packet including the packet length.

[0146] Another packet that can be sent is the MAC CTA setup packet, which is used by the host to set the CTA in the forward and reverse directions. This can be used in the low-latency operation mode of w-MDDI 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, then the packet will be discarded at the transmitter. Otherwise, forward it to the receiver. The content of the MAC CTA setting packet includes a packet length field, which is two bytes containing a 16-bit unsigned integer, and the integer specifies the total number of bytes in the packet that do not include the packet length field. The packet type field is two bytes containing a 16-bit unsigned integer. The 152 package type identifies the package as a CTA configuration package. The C1 client ID field is two bytes containing a 16-bit unsigned integer that is reserved for the host's ID (0). The C2 client ID field is two bytes containing a 16-bit unsigned integer reserved for the ID of C2. The forward CTA parameter is a CTA parameter used for data transfer in the forward direction and the reverse CTA parameter is a CTA parameter used for data transfer in the reverse direction.

[0147] FIG. 23 illustrates a method 2300 for high-rate wireless data communication between a transmitter and a remote receiver. Method 2300 illustrates the sender-initiated association, and starts at 2302 by transmitting the sender association request packet to the remote receiver. When the sender intends to associate with a specific MDDI receiver (after power-up), the sender sends a sender association request for an association request. The sender association request packet includes: a packet length of 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 two bytes The packet type of, which contains 16-bit unsigned integers. The 158 packet type identifies the packet as an association request packet. It also includes: the receiver MAC address, which is six bytes and includes the receiver MAC address; and the transmitter MAC address, which is the byte of the transmitter MAC address. The CRC field is two bytes containing a 16-bit CRC of all bytes in the packet including the packet length.

[0148] At substantially the same time as sending the first association request packet, at 2304, the transmitter enters the "sender association request sent" state and may start a timer (for example, an association timer) or other tracking device. The time interval between the transmission of the first association request packet and the reception of the response from the remote receiver (for example, association request packet) is tracked, and at 2306, it is determined whether the predefined time interval has expired (for example, the timer has expired). period). If the timer has expired ("Yes"), it indicates that no association request packet was received from the remote sender and the method 2300 continues at 2302, where subsequent association request packets are sent. Any number of subsequent sender association request packets can be sent up to the maximum number (for example, max_sender_association_retry, max_sender_association_retry). If the timer has not expired (No"), it is determined at 2308 whether an association request packet is received.

[0149] If the determination at 2308 is 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 providing the client ID may be sent to the remote device.

[0150] The association response packet is sent in response to the association request packet sent by C1. This package provides the client ID and display/device ID to C2. This is the part associated with the three-way handshake. The association response includes packet length, packet type, client ID and CRC. The packet length is two bytes containing 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. The packet type is two bytes containing a 16-bit unsigned integer. The 155 packet type identifies the packet as an associated response packet. The client ID is two bytes of the client ID allocated for C2, and the CRC is two bytes of a 16-bit CRC containing all bytes in the packet including the packet length.

CN 105682152 Β

[0151] At substantially the same time as sending the association response packet, the transmitter may also start a timer such as an Association_Response (Association_Response) timer. At 2310, the receiver should reply with client capability packets and/or link quality information on the reverse link. If the association-response timer expires, the wireless transmitter retransmits the association response packet up to the maximum number of times (for example, association-retry (association_retry)). The sender's association request, association request, association response and client capabilities can constitute a four-way handshaking procedure. Alternative display information can also be received from a remote device.

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

[0153] In some situations, it may be necessary to suspend the association between the remote receiver and the transmitter, and it may be determined at 2408 that the communication between the transmitter and the remote receiver should be disabled. For example, if the wireless transmitter does not receive a MAC response packet from the receiver within a predetermined interval (for example, mac_response-failure_time, (mac_response_fasched_time)) within milliseconds, the receiver can be declared as disarmed Associated, and send the sender disassociation request packet to the receiver at 2410. A reply to a disassociation request (eg, a disassociation request) is received from the receiver at 2412. A disassociation confirmation confirmation (for example, a disassociation response) can be sent at 2414 to complete the disassociation procedure.

[0154] In some aspects, a disassociation request may be explicitly received at 2416 from a remote receiver. At 2418, a disassociation response confirmation (eg, disassociation response) is sent. At 2420, the identification of the disassociated device is removed from the association table.

[0155] The transmitter disassociation request packet is sent by the wireless transmitter that initiated the disassociation. It contains a two-byte packet length field, and the two bytes contain 16-bit unsigned integers, and the integer specifies the total number of bytes in the packet that do not include the packet length field. The two-byte packet type field contains 16-bit unsigned integers. The 157 packet type identifies the packet as a disassociation response packet. The client ID is two (2) bytes of the client ID allocated for C2. The CRC field is two bytes containing a 16-bit CRC of all bytes in the packet including the packet length.

[0156] FIG. 25 illustrates an initiating device-associated device 2500 according to various embodiments. The device 2500 may be a receiver, which is configured to transmit high-rate digital data and which is expected to be associated with a wireless transmitter or a remote host device 2502. The device 2500 can include a memory 2504 that can be configured to store information. The stored information may include the MAC address and/or client ID associated with the device 2500 (as received in the association response packet). For example, substantially simultaneously with associating 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.

[0157] The device 2500 may also include a processor 2506 that may 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, substantially simultaneously with receiving the associated request packet from the remote host device 2502, the processor 2506 may associate the device 2502 with the remote host device 2502. However, if no response packet is received from the remote host device 2502 after the predetermined 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.

[0158] The device 2500 may further include a communication data component 2508, which may be configured to update the MAC response packet with device MAC statistics for transmission to the remote host device 2502. After entering the associated state, the wireless receiver may send a MAC response packet periodically (for example, every mac_response-time millisecond). The host device 2502 can respond with a packet confirming receipt of the MAC response packet sent by the device 2500. If the device 2500 does not receive a response after a predetermined time interval (for example, mac_response_fail_time millisecond duration), the device 2500 can infer that it has been disconnected from the host device 2502

CN 105682152 Β

Connect and stop sending MAC response packets. 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 to send a MAC response packet.

[0159] 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 failures, 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 the status packet is not received from the remote host device 2502 in response to the transmitted update MAC response packet, the processor 2508 will select based on the inference that the device 2500 and the host device 2502 will no longer be associated Disassociate sexually.

[0160] 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 may be associated with the device 2500. The display component 2510 may be further configured to communicate the one or more alternate display information to the remote host device 2502. For example, if there is an alternate display associated with the wireless receiver, the alternate display capability package may be sent to the remote host device 2502.

[0161] FIG. 26 illustrates a device 2600 for wirelessly transmitting 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 transmitting at least one capability information of the at least one receiver to the 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 data packets. The data packet may be a link quality data packet received from a remote transmitter in response to the one or more link quality data packets.

[0162] Referring now to FIG. 27, it illustrates a device 2700 that can be configured to wirelessly transmit high-rate user interface data. The apparatus 2700 may include a memory 2702, which may be configured to store information about the identification of the remote user interface device (eg, the client ID assigned to the remote device). The processor 2704 may be configured to selectively associate with one or more remote user interface devices based in part on information stored in the memory 2702. The apparatus 2700 may also include an information component 2706, which may be configured to analyze at least one capability of the one or more remote user interface devices. The capabilities can be received in the client capabilities package. The information component 2706 may be further configured to analyze the link quality information data received in the status update packet.

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

[0164] 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 the communication link has fallen below a predetermined threshold, the processor 2704 may selectively disassociate.

[0165] Referring now to FIG. 28, it illustrates a device 2800 for wirelessly transmitting user interface data 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.

[0166] The device 2800 also includes a logic module 2804 for sending an association response. The association response may contain the client identification for each corresponding remote user interface device. The device includes a logic module 2806 for receiving capability packets. It also contains a logic module 2808 for associating with the identification. The association may be based in part on the capabilities included in the first capability package.

[0167] According to some aspects, the device 2800 may include a method for determining whether a capability packet is received within a predefined interval.

CN 105682152 Β

A logic module (not shown) and a logic module (not shown) for sending a second request for the capability package. If the capability packet is not received within the predefined interval, the second request can be sent.

[0168] According to other aspects, the apparatus 2800 may include a logic module for determining whether association with one or more remote user interface devices should be stopped. The embodiment may also include a logic module for selectively disassociating the one or more remote user interface devices when the association should be stopped.

[0169] Referring now to FIG. 29, it illustrates a conceptual block diagram of a possible configuration of the terminal 2900. As those skilled in the art will understand, the precise configuration of the terminal 2900 may vary depending on specific applications and overall design constraints. The processor 2902 can implement the systems and methods disclosed herein.

[0170] The terminal 2900 can be implemented with a front-end transceiver 2904 coupled to the antenna 2906. The baseband processor 2908 may be coupled to the transceiver 2904. The baseband processor 2908 may be implemented in a software-based structure or other types of structures. A microprocessor can be used as a platform for running software programs that provide, in particular, control and overall system management functions. The digital signal processor (DSP) can be implemented with an embedded communication software layer that runs dedicated algorithms to reduce the processing requirements 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.

[0171] 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.

[0172] The baseband processor 2908 includes a processor 2902. In a software-based implementation of the baseband processor 2908, the processor 2902 may be a software program running on a microprocessor. However, as those skilled in the art will readily understand, the processor 2902 is not limited to this embodiment, and may be any device known in the art capable of performing the various functions described herein (including any hardware configuration). , Software configuration or a combination) implementation. The processor 2902 may be coupled to the memory 2912 for storing data.

[0173] It should be understood that the embodiments described herein may be implemented by hardware, software, firmware, middleware, microcode, or any combination thereof. When the system and/or method are implemented by software, firmware, middleware or microcode, program code or code segments, they 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 instructions, data structures, or program statements. The code segment can be coupled to another code segment or a hardware circuit by transmitting and/or receiving information, data, arguments, parameters, or memory content. Any suitable means including memory sharing, message transfer, token transfer, network transfer, etc. may be used to transfer, forward or transfer information, arguments, parameters, data, etc.

[0174] What has been described above includes examples of one or more embodiments. Of course, it is not possible 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 described 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 appended claims. In addition, as far as the term "comprising" is used in the embodiments or claims, the term is intended to be inclusive in a manner similar to the way the term "including" is understood when used as a transition word in the claims.

CN 105682152 Β