Wireless architecture for traditional wire based protocol

Traditional wireless architecture based on line protocol

The following description is generally about communication systems, and more specifically about enabling traditional line-based devices to communicate over wireless links and/or wired links.

This application claims the rights of U.S. Provisional Application No. 60/951,919 entitled "WIRELESS ARCHITECTURE FOR A TRADITIONAL WIRE-BASED PROTOCOL" filed on July 25, 2007, which is incorporated herein by reference in its entirety .

The wireless network connection system is utilized by many people to communicate when the user is located at a specific time regardless of where (for example, home, office, on the go...). Wireless communication devices have become smaller and more powerful (for example, 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 functionality to capture and process images (for example, still images, moving images, video games, and the like).

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

Some devices traditionally operate only with wired capabilities, such as the Mobile Display Digital Interface (MDDI). Therefore, a user with the device may not be able to communicate while on the move (for example, when traveling or moving), and may need to spend other costs to obtain a wireless device that 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 achieve the benefits of the two devices. However, being associated with two devices and being aware of the cost of the two devices may impose an excessive burden on the user.

A simplified summary of one or more aspects is presented below to provide a basic understanding of these aspects. This summary is not an extensive overview of all expected aspects, and is not intended to identify the key or decisive elements of all aspects, nor is it intended to describe the scope of any or all aspects. Its sole purpose is to present some concepts in one or more aspects in a simplified form as a prelude to the more detailed description presented later.

According to one or more aspects and their corresponding disclosures, various aspects are described in combination with service discovery between the wireless MDDI (w-MDDI) host and w-MDDI client for associating devices with each other and using each other's capabilities . Service discovery can be initiated by the host and/or the client. Perform service discovery through interaction with wiMedia UWB MAC and/or UDP/IP and/or support for multicast underlaying protocols. Optional mutual authentication can be performed before devices are associated.

One aspect relates to the use of wireless devices between the host entity and at least one remote A method of wireless transmission of data between MDDI client-capable devices at a high rate. The method includes: performing a service discovery process to obtain information about a plurality of wireless MDDI client-capable devices in a local area; and receiving information associated with at least one of the plurality of wireless MDDI client-capable devices instruct. The method also includes determining the security capability of each of the plurality of wireless MDDI client-capable devices and selectively executing the security association procedure. In addition, the method includes associating with at least one of a plurality of wireless MDDI client-side capable devices.

Another aspect relates to a wireless communication device including a memory and a processor. The memory stores instructions about the following: performing a service discovery process to collect information about a plurality of wireless MDDI client-capable devices in a local area; and receiving information about the plurality of wireless MDDI client-capable devices At least one related request. The memory also stores instructions on the following: determining the security capabilities of each of a plurality of wireless MDDI client-capable devices; executing security-related procedures; and communicating with a plurality of wireless MDDI client-capable devices At least one of them is related. The processor is coupled to the memory and is configured to execute the instructions stored in the memory.

Another aspect relates to wireless communication devices that transmit data wirelessly at a high rate. The device includes: a component for performing a service discovery process to collect information about a plurality of wireless MDDI client-capable devices in a local area; and a component for receiving information from the plurality of wireless MDDI client-capable devices At least one of the associated requested components. The device also includes: used to determine multiple devices with wireless MDDI client capabilities A component for the security capability of each of them; a component for selectively executing a security-associated program; and a component for associating with at least one of a plurality of wireless MDDI client-capable devices.

Another aspect relates to computer program products containing computer-readable media. The computer-readable medium includes a first set of program codes for enabling a computer to perform a service discovery process to obtain information about a plurality of wireless MDDI client-capable devices in a local area. The computer-readable medium also includes a second set of program codes for enabling the computer to receive instructions associated with at least one of the plurality of wireless MDDI client-capable devices, and for enabling the computer to determine the plurality of wireless MDDI client-capable devices The third set of code for the security capability of each of the capability type devices. In addition, the computer-readable medium includes a fourth set of program codes for causing the computer to execute a security-related program and a fifth set of programs for associating the computer with at least one of a plurality of wireless MDDI client-capable devices code.

Another aspect relates to at least one processor configured to communicate data at a high rate between a host entity and at least one remote device capable of wireless MDDI client. The processor includes: a first module for performing a service discovery process to obtain information about a plurality of wireless MDDI client-capable devices in a local area; and a first module for receiving and a plurality of wireless MDDI client-capable devices An indicated second module associated with at least one of the devices. The processor also includes a third module for determining the security capability of each of the plurality of wireless MDDI client-capable devices. In addition, the processor includes: a fourth module for selectively executing security association programs; The fifth module associated with at least one of the devices.

Another aspect relates to a method for wirelessly communicating data by a host entity at a high rate. The method includes transmitting a neighbor list message to the lower layer, the neighbor list message requesting a list of devices in the local area, and receiving the list of devices in the local area. The method also includes sending a host query packet to each of the devices, receiving a response including a string identifier of the responding device, and selectively associating with the responding device. A response is received before the expiration of the predetermined interval.

Another aspect relates to a wireless communication device including a memory and a processor. The processor is coupled to the memory and is configured to execute the instructions stored in the memory. The memory retains the instructions for transmitting the neighbor list information to the lower layer. The adjacent list message requests a list of devices in the local area. The memory also stores a list of devices in the receiving local area and sends a host query packet command to each of these devices. In addition, the memory stores instructions for receiving a response including a string identifier of the response device and selectively associated with the response device. A response is received before the expiration of the predetermined interval.

Another aspect relates to a wireless communication device that wirelessly transmits data at a high rate. The device includes a component for sending a neighbor list message to the lower layer and a component for receiving a list of devices in a local area. The adjacent list message requests a list of devices in the local area. The device also includes means for transmitting a host query packet to each of the devices and means for receiving a response including a string identifier of the responding device. A response is received before the expiration of the predetermined interval. It also includes components used to associate with the response device.

Another aspect relates to computer program products including computer-readable media. The computer-readable medium includes a first set of program codes for the computer to send a neighbor list message to the lower layer. The adjacent list message requests a list of devices in the local area. The computer-readable medium also includes a second set of program codes for the computer to receive the list of devices in the local area and a third set of program codes for the computer to transmit a host query packet to each of the devices. It also includes a fourth set of program codes for the computer to receive a response including the string identifier of the answering device and a fifth set of program codes for associating the computer with the answering device. A response is received before the predetermined interval expires; and another aspect relates to at least one processor configured to communicate data at a high rate. The processor includes a first module for transmitting neighbor list information to the lower layer and a second module for receiving a list of devices in a local area. The neighbor list message requests a list of devices in the local area. The processor also includes a third module for sending a host query packet to each of the devices and a fourth module for receiving a response including a string identifier of the response device. A response is received before the expiration of the predetermined interval. The processor also includes a fifth module for selectively associating with the response device.

In order to achieve the foregoing and related objectives, one or more aspects include the features fully described in the following and specifically pointed out in the scope of the patent application. The following description and additional drawings detail certain illustrative features of one or more aspects. However, these features only indicate a few of the various ways in which the principles of various aspects can be used. When considered in conjunction with the drawings, other advantages and novel features will become apparent from the following detailed description, and the disclosed aspects are intended to include all such aspects and their equivalents.

Now refer to the diagrams to describe the various aspects. In the following description, for explanatory purposes, numerous specific details are stated to provide a thorough understanding of one or more aspects. However, it is obvious that the aspect(s) can be practiced without these specific details. In other cases, well-known structures and devices are shown in block diagrams to help describe these aspects.

When used in this application, the terms "component", "module", "system" and the like are intended to refer to computer-related entities, which are hardware, firmware, a combination of hardware and software, software or Software in execution. For example, the component can be (but is not limited to) a process, a processor, an object, an executable code, an execution thread, a program, and/or a computer running on the processor. As an illustration, both the application program executed on the computing device and the computing device can be components. One or more components can reside in the executing processing program and/or thread, and the components can be localized on one computer and/or distributed in two or more computers. In addition, these components can be executed from various computer-readable media that have various data structures stored thereon. Components can (such as) communicate through local and/or remote processing procedures based on a signal that has one or more data packets (for example, from an interaction with a component in a local system, a distributed system, and/or The data of another component that interacts with other systems on a network such as the Internet through the signal).

In addition, this article describes various aspects in conjunction with mobile devices. Mobile devices can also be called systems, user units, user stations, mobile stations, mobile devices, wireless terminals, nodes, devices, remote stations, remote terminals, access terminals, user terminals, terminals, Wireless communication device, wireless communication A device, user agent, user device, or user equipment (UE), and may contain some or all of its functionality. Mobile devices can be cellular phones, wireless phones, session initiation protocol (SIP) phones, smart phones, wireless zone loop (WLL) stations, personal digital assistants (PDA), laptop computers, palm-type communication devices, and palm-type Computing device, satellite radio, wireless modem card, and/or another processing device used to communicate on a wireless system. In addition, this article describes various aspects in conjunction with base stations. A base station can be used to communicate with wireless terminals, and can also be called an access point, node, node B, eNode B, e-NB, or some other network entity, and may contain some or all of its functionality .

Various aspects or features will be proposed in terms of a system that can include many devices, components, modules, and the like. It should be understood and understood that various systems may include additional devices, components, modules, etc., and/or may not include all devices, components, modules, etc. discussed in conjunction with the drawings. A combination of these methods can also be used.

Referring now to the drawings, FIG. 1 illustrates a block diagram of a system 100 for enabling traditional line-based devices to communicate wirelessly. The various aspects disclosed in this article can be applied to general wireless video, distributed MAC, distributed resources, point-to-point wireless MAC, etc. 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 on a wire-based protocol. Although it should be understood that many transmitters 102 and receivers 104 may be included in the system 100, a single transmitter 102 that transmits communication data signals to a single receiver 104 is described for simplicity.

The transmitter 102 and the receiver 104 may be mobile display digital interface (MDDI) devices. In the following detailed description, various aspects are described in the context of an MDDI device and/or an Institute of Electrical and Electronics Engineers (Institute of Electrical and Electronics Engineers, IEEE) 802.15.3 media access control (MAC) layer. Those familiar with this technology will easily understand that these aspects are also suitable for use in various other traditional line-based protocols. Therefore, any reference to MDDI and/or IEEE 802.15.3 MAC is only intended to illustrate the aspects of the invention, and it is understood that the aspects of the invention have a wide range of applications.

The communication sent from the transmitter 102 to the receiver 104 is called the forward link (for example, the data from the host to the user end travels in the forward direction), and the communication sent from the receiver 104 to the transmitter 102 is called the forward link. It is a reverse link (for example, data from the user end to the host travels in the reverse direction).

The information transmitted on the MDDI link (for example, the forward link, the reverse link) is formed into packets. Multiple packets are formed together into sub-frames, and multiple sub-frames form a media frame. Each sub-frame starts with a special packet called a sub-frame header packet. The reverse link packet transmission is not controlled by the host. Whenever the w-MDDI receiver intends to transmit a packet on the reverse link, the receiver directly sends the packet to the w-MDDI transmitter via the underlying wireless MAC.

The transmitter 102 can be connected to a data source 106 (for example, storage, memory, and the like), and the receiver 104 can be connected to an interface device 108 such as a display. According to some aspects, a single transmitter 102 may be associated with multiple receivers 104.

According to some aspects, the transmitter is intended to communicate with one or more MDDI-clients (For example, receiver 104) the associated MDDI-host. The term "host" is used interchangeably with the terms "transmitter" and/or "device" herein, depending on how that term is used. In addition, the term "user terminal" may be used interchangeably with the terms "receiver" and/or "device" in this document depending on how the term is used.

If the MDDI-host wants to associate with the MDDI-receiver and wirelessly communicate data between devices at a high rate, the host performs a service discovery process. The service discovery process requests information about multiple wireless MDDI client-capable devices in a local area. During the service discovery process, the w-MDDI host receives information about a large number of wireless w-MDDI client-capable devices. The information includes string identifiers corresponding to device names, device capabilities, and status indications. This information can be stored locally in the w-MDDI host.

According to some aspects, during the service discovery process, the w-MDDI host transmits messages to the lower layer to obtain a list of devices that support w-MDDI in the local area. The lower layer responds with a list of devices, and the w-MDDI host sends the packet to each of the devices included in the received list. The participating devices send a response containing the string identifier of each of the response devices.

After the service discovery process, the w-MDDI host determines the security capabilities of each of the wireless w-MDDI client-capable devices (for example, whether user-side security is enabled, and whether the user-side requires security). w-MDDI host can submit a list of devices, and users can select one or more of these devices. After receiving the selection, the w-MDDI host selectively executes (mutual) security association procedures (if necessary), and It is associated with at least one of the wireless MDDI client-side capable devices.

According to some aspects, the lower layer supports multicast. If multicasting is supported, the w-MDDI host can query packets from the multicast group transmission service to request information from a device with wireless MDDI client capabilities. The multicast group is specified by the multicast address.

If the lower layer is wiMedia UWB MAC, the w-MDDI host can receive application-specific information elements about each of the w-MDDI client-side capable devices. If the lower layer is UDP/IP, the w-MDDI host sends a query packet to the multicast group transmission service on the UDP port, combines with the multicast group on the UDP port and receives the service response from each device supporting w-MDDI .

According to some aspects, the w-MDDI client (for example, the receiver 104) can initiate association with the w-MDDI host (for example, the transmitter 102) to wirelessly communicate data at a high rate. w-MDDI client can transmit adjacent list information to the lower layer. The adjacent list message requests a list of devices in the local area. According to some aspects, the lower layer can support multicast. According to some aspects, the lower layer is wiMedia UWB MAC and/or UDP/IP.

After receiving the list of devices in the local area (in response to the adjacent list message), the w-MDDI client sends a host query packet to each of the devices. In response to this message, each of the devices transmits a response including the string identifier of the responding device. The response shall be received before the expiry of the predetermined interval. The w-MDDI client is selectively associated with at least one of the answering devices. If the response is not received before the expiration of the predetermined interval, the association is unsuccessful, and the w-MDDI client returns to the previous state (for example, the state the MDDI client was in before starting the association process).

The various aspects disclosed in this article can preserve the link and MDDI packet structure, so that the beneficial features of MDDI (for example, partial screen updates, user data packets, control and status packets, etc.) can be preserved. In addition, the MDDI protocol can be implemented on top of a high-speed wireless AMC that provides point-to-point communication. In addition, wireless MDDI does not interfere with the function of wireless MAC.

Figure 2 illustrates a wireless MDDI protocol stack 200. The wireless MDDI protocol is universal and can operate on a variety of high-speed wireless technologies. Examples of high-speed wireless technologies include WiMedi Ultra Wideband (UWB), Wifi, 1xEVDO, etc. As illustrated in the vertical stack 200, the video/multimedia layer 202 can be implemented on top of the wireless MDDI (w-MDDI) layer 204. It also includes the underlying MAC layer 206, which can be 802.11, wiMedia UWB MAC, 802.15.3 UWB Mac, universal high-speed wireless MAC, and so on. The MDDI protocol stack 200 also includes a physical (PHY) layer 208, which can be 802.11, wiMedia UWB, general high-speed wireless PHY, and so on.

The MAC layer 206 and the corresponding PHY layer 208 can be any general high-speed interface. The illustrated MDDI protocol stack 200 operates on a universal high-speed L2 (which is a general term for MAC and link layers used in wireless communication networks).

FIG. 3 illustrates another wireless MDDI protocol stack 300. This diagram illustrates the operation of wireless MDDI (W-MDDI) on the Internet Protocol (IP), which is another mode of W-MDDI operation, on the User Datagram Protocol (UDP). The protocol stack 300 includes a video/multimedia layer 302. Since W-MDDI 304 is universal, it can be executed on top of L2 (which is MAC layer 306 and PHY layer 308) or other layers (eg, L3, L4). As explained, W-MDDI 304 performs similarly to the application layer.

In this diagram, W-MDDI 304 operates on top of UDP 310 and IP 312. IP 312 is similar to media applications (eg, media players, Voice over Internet Protocol (VoIP), etc.) or real-time client protocols. Having the UDP layer 310 and the IP layer 312 enables the client and the host to reside in disparate locations and be connected via an Internet connection or another type of connection. For example, the display may be located in Paris, France, and the host may be located in Dallas, Texas. W-MDDI can be used to deliver display content (for example, multimedia data) to the host (or vice versa) on the Internet. This operation can be similar to a remote desktop application, however, the illustrated protocol 300 can enable the host to drive communication to the client (eg, display).

The wireless channel can cause errors in the packet. In the wireless MDDI architecture disclosed in this article, it is assumed that the underlying underlying layer (for example, wireless MAC) provides a reliability mechanism such as packet retransmission to reduce the application packet error rate experienced by wireless MDDI. Therefore, the additional reliability mechanism in the wireless MDDI layer is not discussed in this article. However, according to some aspects, there may be a reliability mechanism in the wireless MDDI layer.

According to some aspects, when the underlying layer is UDP/IP, w-MDDI is temporarily stored on the standard UDP port WMDDI_UDP_CONTROL_PORT. WMDDI also opens the UDP port WMDDI_UDP_DATA_PORT for data communication. Devices with w-MDDI transmitter/receiver capabilities can combine the WMDDI_CONTROL_MULTICAST group with the multicast IP address WMDDI_CONTROL_MULTICAST_IP.

Figure 4 illustrates a wireless transmitter 400 according to one or more aspects. Send wirelessly The device 400 can be configured to communicate high-rate data such as digital data. The various wireless systems described herein may include wireless transmitters and wireless receivers. The wireless transmitter 400 may include an MDDI host 402 and a special MDDI client (C1) 404. The MDDI client is a part of the traditional MDDI client rather than the entire MDDI client. The MDDI client (C1) 404 may not be associated with a display or device. The host 402 and the client (C1) 404 can be connected via a traditional high data rate link (for example, an MDDI link) 406. The module contains a client (C1) 404 and can communicate via a wireless modem 408 such as an ultra-wideband modem including UWB MAC and UWB PHY. According to some aspects, the wireless modem 408 can be any high-speed modem. The host 402 and the client (C1) 404 can be operatively connected to an existing wired link, such as an MDDI link or a link configured to support high-speed data. According to some aspects, if the client (C1) 404 and the modem 408 are connected to a wired link, the host 402 may need to be upgraded to handle wireless functionality (which will be described in further detail below). The configuration illustrated in Figure 4 can be called a "Type A" wireless MDDI (w-MDDI) transmitter.

FIG. 5 illustrates another wireless transmitter 500 including a co-located MDDI host 502 and a client (C1) 504. According to some aspects, the host 504 and the client (C1) 504 can be co-located in the same software and/or hardware module. The host 504 and the client (C1) 504 can be connected to the high-speed wireless modem 506. The configuration illustrated in Figure 5 can be called "Type B" w-MDDI transmitter.

Another example of a wireless transmitter 600 is illustrated in FIG. 6, where the host and C1 are combined (or compressed) in a single hardware and/or software entity (w-MDDI transmitter) 602. A high-speed wireless modem 604 is included to facilitate wireless communication. Figure 6 says Ming's configuration can be called "Type C" w-MDDI transmitter.

Referring now to FIG. 7, a wireless receiver 700 according to the disclosed aspect is illustrated. The wireless receiver 700 includes an MDDI client processing (C2) 702 that can be connected to several devices and a display 704 (for simplicity, only one display is shown). The client (C2) 702 can be configured to process and generate high-rate digital data packets. According to some aspects, the client (C2) 702 does not have a physical layer of MDDI stacking. According to various aspects, a single MDDI transmitter can be connected to several MDDI receivers.

On the reverse link, the MDDI data packet can be generated by the receiver (C2) 700. The MDDI data packet can be transmitted to the transmitter via the UWB modem (for example, the type A w-MDDI transmitter 400, the type B w-MDDI transmitter 500, and/or the type C w-MDDI transmitter 600).

The w-MDDI host/sender can periodically query the underlying underlying layer (e.g., MAC layer) by transmitting the underlying query packet (e.g., MAC query packet) to obtain information on the underlying layer (e.g., such as MAC retransmission) , MAC information such as frame error rate). The host can feed this information back to the application so that the application can increase/decrease its data rate.

The MAC query is a query used to determine the rate supported by the MAC and the heavy traditional meter. The MAC query message includes a message ID, which is a two-byte group containing 16-bit integers without a sign. The message id 0x0 indicates that the packet is a MAC query message. It also includes two bytes of MAC query parameters.

Figure 8 illustrates a method 800 for w-MDDI association. Refer to the various flowcharts to better understand the methods implemented in accordance with the disclosed subject matter. Although the method is shown and described as a series of blocks for the purpose of simplicity of illustration, It should be understood and understood that the claimed subject matter is not limited to the number or order of blocks, as some blocks may occur in a different order than the order depicted and described herein and/or substantially simultaneously with other blocks. In addition, not all the blocks described are required to implement the methods described herein. It should be understood that the functionality associated with these blocks can be implemented by software, hardware, a combination thereof, or any other suitable components (for example, devices, systems, processes, components). In addition, it should be further understood that the methods disclosed in the following and throughout this specification can be stored on a product to facilitate the transportation and delivery of these methods to various devices. Those familiar with the art should understand and understand that the method can alternatively be represented as a series of related states or events, such as in the form of a state diagram.

The method 800 is described from the perspective of the user (eg, user device, mobile phone, laptop, etc.). The method 800 starts at step 802 when a user with a host device initiates a search for a w-MDDI client capable device. The search can be initialized when the user enters an area (for example, a room, a building, etc.) and starts searching for a device with w-MDDI client capabilities. Various mechanisms can be used to allow users to initiate searches. For example, the user interface may provide functionality (eg, buttons on the device, icons on the display screen, etc.) to request a search.

In step 804, the host retrieves a list of devices with w-MDDI client capabilities. According to some aspects, a client-capable device has words corresponding to its name, its capabilities (for example, screen resolution, whether compressed and/or uncompressed packets are acceptable, security capabilities, etc.), status indicators, and other information String identifier. Examples of device information presentation include "Room L-601 cast Video camera monitor is not associated/available", "Living room home theater plasma display is associated/unavailable", "ABC PC keyboard is not associated/available", etc. According to some aspects, w-MDDI transmitter can maintain the search request The list of w-MDDI receivers that responded (for example, in a computer-readable storage medium).

In step 806, the associated device is selected. Various techniques can be used, such as presenting a list of devices on the display and allowing the user to select the device (for example, highlighting the device name and pressing the enter key), providing language commands (for example, speaking the device name or other associated with the desired device) Identifier). In another example, the user can press a button on the user interface of the host to trigger device selection.

In step 808, an "association rejection" message can be received. It should be noted that this message is only received if the association cannot be successfully completed, as indicated by the dotted line. The message can be displayed on a user interface (e.g., a screen) or displayed via other components (e.g., audible via a speaker). This message can be received if the desired device is already associated with another host and therefore refuses to associate.

The "association rejection" message can be received when the device is connected to another host. According to some aspects, the message can be received when the device "sticks" to its previous host or cannot be disassociated from its previous host. In this case, if the user controls the device and is a genuine product user (for example, if the display is not used by any other user), the user can force the device to interact with its previous host through various techniques (for example, resetting the device) Disconnect. For example, the user can press a button on the user interface of the device and try to initiate the association again.

Once the association process is successfully completed, the host and the w-MDDI client-capable device can provide various components to confirm the association. Host/client authentication includes key exchange or other types of security procedures. For example, a host and a device with w-MDDI client capability can reproduce common (short) numbers on their respective displays.

In step 810, information about the association may be received as appropriate, as indicated by the dashed line. Various situations about the association may occur. For example, if the association is unsuccessful, the host display or device display (or other components that provide information (for example, visual, audio)) can reproduce the message corresponding to the "association unsuccessful". In this case, the timer associated with the associated program expires. When the timer expires, the device returns to the state the device was in before the start of the association process (for example, as if no association attempt was made).

Another type of information can be about security capabilities. For example, one or both of the host and the device may not be secure, but may be accepted by both devices to continue unsecure communication. This can happen when one of the devices does not have security capabilities. In this case, a message indicating that the communication is not secure can be displayed on any one or two devices (host and client). According to some aspects, information about conducting insecure communications can be negotiated during the initial capability exchange (e.g., when the device list is received in step 804). In this case, if the user wants to confirm the association (for example, overriding the insecure communication message), the user can press a button on the host or perform an equivalent action to confirm the association.

In another example, if both devices have security capabilities and want to communicate on a secure link and the security check (authentication) is unsuccessful, then about this The message can be reproduced on the display or via other components. If one of the devices wants to use security but the other device does not have security capabilities, a message such as "Security hardware is not available" can be reproduced.

In another example, the information about the association may be a value (for example, a digital association) or other components that confirm the association. If this value is used and the display of both the w-MDDI host and the w-MDDI client-capable device match, it indicates a successful and safe association. In this case, if the user wants to confirm the association, the user can press a button on the host or take similar actions to confirm the association.

If the values do not match, this indicates that the host and the device have not been able to authenticate each other and there may be a "man in the middle". In this situation, the host and the device may time out (for example, the timer associated with the associated program expires). When the device times out, the device returns to the state the device was in before the start of the association process.

The disclosed aspect of the w-MDDI agreement is a provision for dynamic association and disassociation and/or association and communication between a single w-MDDI transmitter and multiple w-MDDI receivers. Figure 9 illustrates a system 900 for service discovery according to the disclosed aspect. The w-MDDI transmitter 902 should obtain a list of w-MDDI receivers 904 that can be associated with the w-MDDI transmitter 902 (for simplicity, only one receiver is illustrated). The associated program is executed via the service discovery program.

The w-MDDI transmitter 902 can be configured to initiate a service discovery process to search for the w-MDDI receiver 904 (eg, receiver service discovery). The discovery process service can be initiated via user interaction or automatically (e.g., when the transmitter 902 recognizes that a new location (e.g., room) has been entered).

The w-MDDI transmitter 902 includes a device list requester 906, which is It is configured to transmit the request of the receiver 904 in the discovery area. For example, the message "Get Neighbor List" can be transmitted to the lower layer to obtain the device (for example, the receiver 904) in the wireless (or wired) neighborhood (for example, the communication area) of the w-MDDI transmitter 902 List. At substantially the same time as when the message is received, the lower layer may respond to the "lower layer neighbor list response" message including the list of devices in the neighborhood of the requesting device (w-MDDI transmitter 902).

The lower-level neighbor list response message includes a message ID, which is two bytes containing 16-bit integers without a sign. Message ID 0x7 identifies the packet as a MAC address response message. It also includes the number of neighbors, which are two bytes that specify the number of neighbors of the current device (transmitter/receiver). It also includes the address of the lower layer (MAC layer) of the neighbor-1-the address of the lower layer (MAC layer address).

The w-MDDI transmitter 902 also includes a service query identifier 908 configured to transmit a "w-MDDI service query" packet to each neighbor (for example, to each individual receiver according to some aspects). The w-MDDI receiver 904 may include a service capability notification program 910 that responds with a "w-MDDI service response" packet that may include the availability and string identifier of the w-MDDI receiver. The packet length of the w-MDDI service response packet can be two bytes containing 16 bits of the total number of bytes in the specified packet (excluding the packet length field) without a positive or negative integer. The archived packet type can be two bytes and can contain 16-bit integers without sign. The packet type 163 identifies the packet as a w-MDDI service response packet. It also includes the receiver MAC address field, which includes the six-byte MAC address of the w-MDDI receiver. Transmitter MAC bit The address field includes the 6-byte MAC address of the w-MDDI transmitter, which can be a broadcast or multicast address when multicast/broadcast services are used. The receiver parameter field can include a 256-byte string identifier of the w-MDDI receiver and its capabilities. In addition, the w-MDDI service response packet includes a CRC field, which is two bytes and contains a 16-bit CRC of all the bytes in the packet (including the packet length field).

The w-MDDI transmitter 902 can wait for the "w-MDDI service response" packet until the timer expires (for example, the value of the service_discovery_timer). If the response is not received before the timer expires, the association fails. The user of the w-MDDI transmitter 902 can select the w-MDDI receiver 904 to be associated if the response is received before the timer expires.

According to some aspects, the w-MDDI transmitter 902 or the w-MDDI receiver 904 can initiate the association process. For example, if the w-MDDI transmitter 902 is a phone and the w-MDDI receiver is a projector/display, the phone (for example, the w-MDDI transmitter) can initiate the association process.

According to some aspects, the w-MDDI receiver 904 can search for the w-MDDI transmitter 902 (for example, transmitter service discovery). The w-MDDI receiver 904 may include an available device requestor (solicitor) 912, which is configured to pass messages to the lower layer (for example, "get the neighbor list") to obtain the wireless (solicitor) in the w-MDDI receiver. Or wired) a list of devices in the neighborhood. The lower layer can respond by providing the "lower layer neighbor list response" of the list of devices in the neighborhood.

Obtaining the neighbor list is a message sent to the lower layer (for example, the MAC layer) to obtain the list of neighbors wirelessly connected to the current node. This message includes Message ID, which is a two-byte group containing 16-bit integers without a sign. The message ID number 0x3 identifies the packet as obtaining the neighbor list message.

Send the obtain lower layer address (obtain MAC address) message to the lower layer to obtain the lower layer address (for example, MAC address) of the w-MDDI node (for example, UWB modem). This message includes a message ID, which is a two-byte group containing 16-bit integers without signs. The message ID number 0x2 identifies the packet as a message of obtaining the lower layer address (obtaining the MAC address).

The host query 914 included in the w-MDDI receiver 904 can be configured to transmit "w-MDDI host query" packets to neighbors. The w-MDDI transmitter 902 may include an availability notification program 916 configured to transmit a "w-MDDI host response" packet to the w-MDDI receiver 904 in response to a query. The "w-MDDI host response" packet can contain the availability and string identifiers of various devices. The user of the w-MDDI receiver 904 can select which w-MDDI transmitter is associated with. If the timer associated with the w-MDDI receiver 904 (for example, service_discovery_timer) expires before the "w-MDDI host response" is received, the association fails.

According to some aspects, if the lower layer supports multicast services, the multicast service can be used to transmit "w-MDDI service query" and "w-MDDI service response" packets and in the case of "receiver service discovery". Send "w-MDDI host query" and "w-MDDI host response" packets in the case of "sender service discovery". The operation when using multicast will be described in further detail below. If the multicast service is not available, broadcast is used. If the broadcasting facility does not exist, unicast can be used.

The w-MDDI transmitter can maintain the response with the w-MDDI service response packet A list of w-MDDI receivers and receiver parameters corresponding to each of the w-MDDI receivers. The w-MDDI receiver may maintain a list of w-MDDI transmitters that have responded with a w-MDDI service response packet and transmitter parameters corresponding to each of the w-MDDI transmitters. These lists can be maintained in separate storage media associated with devices 902 and 904.

According to some aspects, the underlying layer may support multicast. Multicasting can provide efficiency because the message is transmitted to a subset of devices (e.g., identified devices) rather than to all devices in the neighborhood. For service discovery when w-MDDI transmitter 902 searches for w-MDDI receiver 904 (for example, receiver service discovery) and the underlying lower layer supports multicast, w-MDDI available devices can join the multicast group specified by WMDDI_CONTROL_MULTICAST_ADDRESS Group WMDDI_CONTROL_MULTICAST group. The w-MDDI receiver can periodically announce its "w-MDDI service response" packet on this multicast address. The w-MDDI sender wishing to perform service discovery can select the w-MDDI receiver it wishes to associate from the "w-MDDI service response". The w-MDDI sender can also send a "w-MDDI service query" packet to the WMDDI_CONTROL_MULTICAST group and explicitly request a "w-MDDI service response" packet from an individual receiver.

For service discovery when w-MDDI receiver 904 searches for w-MDDI transmitter 902 (for example, sender service discovery) and the underlying lower layer supports multicast, the host intended to be associated with the receiver (for example, w-MDDI Transmitter) can join the WMDDI_CONTROL_MULTICAST group specified by WMDDI_CONTROL_MULTICAST ADDRESS. The w-MDDI sender can advertise (for example, periodically) its "w-MDDI host" on this multicast address Response "packet. The w-MDDI receiver that wants to perform host discovery can select the w-MDDI transmitter that it wants to associate from this "w-MDDI host response". The w-MDDI receiver can also transmit to the WMDDI_CONTROL_MULTICAST group The "w-MDDI host query" packet is explicitly requested by the individual w-MDDI sender for the "w-MDDI host response" packet.

According to some aspects, service discovery can be enabled when the underlying layer is wiMedia UWB MAC. If the underlying layer is wiMedia UWB MAC, the following can be enabled during service discovery. Available devices for Wi-Media receivers include application-specific IE (ASIE) with w-MDDI service response. Similarly, the "w-MDDI transmitter available" device can include ASIE in its beacon containing the w-MDDI host response packet.

FIG. 10 illustrates the application specific IE (ASIE) format 100 in WiMedia MAC. According to some aspects, if the underlying layer is wiMedia UWB MAC, the following can occur during service discovery. For example, the "w-MDDI receiver available" wi-Media device may include an application-specific IE (ASIE) containing a w-MDDI service response. In a similar way, the "w-MDDI transmitter available" device can include ASIE in its beacon containing the w-MDDI host response packet.

The application specifier ID 1002 can be set to wMDDI_wiMedia_ASIESpecifierID. In the case of w-MDDI receiver, set the application-specific data information to "w-MDDI service response packet". Similarly, in the case of w-MDDI transmitter, set the application-specific data information to "w-MDDI host response packet".

The w-MDDI host response packet responds to the w-MDDI service query packet sent by the w-MDDI transmitter. Host response packet provides w-MDDI Availability of the receiver and "string identifier". The packet includes the packet length, which is two bytes containing 16 bits without an integer of the total number of bytes in the specified packet (excluding the packet length field). The two-byte packet type contains a 16-bit integer without a sign. Packet type 167 identifies the packet as<i>w-MDDI service response packet</i>. The receiver MAC address is the six-byte MAC address of the w-MDDI receiver. This can be a multicast or broadcast address depending on whether a multicast or broadcast service is used. It also includes the transmitter MAC address which is the 6-byte MAC address of the W-MDDI transmitter. The transmitter parameter field is w-256-byte string identifier of the MDDI transmitter and its capabilities. The CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet (including the packet length).

Figure 11 illustrates the application-specific detection information element (AS detection IE) 1100 in the wiMedia MAC. When the w-MDDI sender searches for the receiver (for example, receiver service discovery), it sends the "w-MDDI service discovery" message to the lower layer (wiMedia MAC). Send the w-MDDI service discovery message to the lower layer (for example, the wiMedia MAC layer) to obtain w-MDDI service information. The payload of this message is the "w-MDDI service query" packet. When the underlying layer is wiMedia UWB MAC, place this in the application-specific request information field of the application-specific detection IE 1100. The content of this message includes a message ID, which is a two-byte group containing 16-bit integers without a sign. Packet type 0x4 identifies the packet as a service discovery. The packet type is two bytes containing 16-bit integers without a sign. The packet type 162 identifies the packet as a service query packet. It also includes the transmitter parameter field, which is two bytes containing information about the w-MDDI transmitter. The MAC address of the transmitter is w- The six-byte MAC address of the MDDI transmitter and the receiver MAC address can be broadcast addresses. It also includes the two-byte service query option that is the service query option and the two-byte CRC that contains the 16-bit CRC of all the bytes in the packet (including the packet length).

At roughly the same time as when the "w-MDDI service discovery" message is received from the w-MDDI layer, the wi-Media MAC on the w-MDDI transmitter can determine whether it has w-MDDI reception from all its neighbors The valid (not expired) application specific IE (ASIE) information of the device. If there is no valid (or expired) ASIE information, the MAC on the w-MDDI transmitter checks the application specific IE (ASIE) from its neighbor. If some neighbors of the w-MDDI transmitter do not have ASIE information corresponding to w-MDDI, it sends application-specific detection IEs to each of their neighbors. The application-specific detection IE is defined as shown in Figure 11. Set the "application-specific request information" field 1102 to the "w-MDDI service query" packet.

w-MDDI transmitter waits for the time corresponding to the service_discovery_timer for the reception of application-specific IE. wiMedia MAC can send a "w-MDDI service information" packet to the w-MDDI layer for each ASIE received.

The "w-MDDI service information" packet is a message sent from the lower layer (for example, wiMedia MAC) to w-MDDI, which provides the w-MDDI transmitter with the service response that it has received from the w-MDDI receiver and its neighbors News. In wiMedia MAC, the application-specific data in ASIE (application-specific IE) contains w-MDDI service response information. This message includes a message ID, which is a two-byte group containing 16-bit integers without signs. Message ID 0x8 identifies the packet as<i>w-MDDI service information message</i>. The other field is w-MDDI receiver The number, which indicates the number of w-MDDI receivers. This message contains an example of "w-the number of MDDI receivers" in the following fields. The packet length is a 16-bit integer without a sign and two bytes containing the total number of bytes in the specified packet (excluding the packet length field). The packet type is 2 bytes containing 16-bit integer without sign. Packet type 163 identifies the packet as<i>w-MDDI service response packet</i>. The receiver MAC address is the six-byte MAC address of the w-MDDI receiver. The receiver parameter is w-MDDI receiver and its capability 256-byte string identifier. The CRC is a two-byte group containing 16-bit CRC of all the bytes in the packet (including the packet length).

The w-MDDI receiver wishing to initiate service discovery to find the w-MDDI sender (for example, sender service discovery) sends a "w-MDDI host discovery" message to the lower layer (wimedia MAC). At approximately the same time as when the message from the w-MDDI layer is received, the wiMedia MAC on the w-MDDI receiver can determine whether it has any validity (not expired) from the w-MDDI transmitter of its neighbor Application specific IE (ASIE) information. If there are some neighbors and the w-MDDI receiver does not have ASIE information about them, the w-MDDI receiver sends application-specific detection IEs to each of their neighbors. The application-specific detection IE is defined as shown in Figure 11. Set the "application-specific request information" field 1102 to "w-MDDI host query" packet. w-MDDI receiver waits for the time corresponding to the host_discover_timer for the reception of application-specific IE. iMedia MAC can send a "w-MDDI host information" packet to the w-MDDI layer for each ASIE received.

The following will describe the service discovery when the underlying layer is UDP/IP. For receiver service discovery (for example, the sender searches for the receiver) and the underlying layer is UDP/IP, devices with w-MDDI transmitter/receiver capabilities can join the WMDDI_CONTROL_MULTICAST group specified by the WMDDI_CONTROL_MULTICAST_IP multicast address. The available devices of the w-MDDI receiver can advertise their capabilities by sending (for example, periodically) w-MDDI service response packets to the WMDDI_CONTROL_MULTICAST group. When the w-MDDI sender intends to discover the w-MDDI receiver, it sends a "w-MDDI service query packet" to the WMDDI_CONTROL_MULTICAST multicast group on UDP port # WMDDI_UDP_CONTROL_PORT.

The w-MDDI service query packet queries the wireless device to determine whether the device supports w-MDDI receiver functionality. The content of the w-MDDI service query packet includes the packet length, which is two bytes containing the total number of bytes in the specified packet (not including the packet length field), 16 bits without a positive or negative integer. The packet type 162 is a two-byte group containing 16-bit integers without a sign. The packet type 162 identifies the packet as a service query packet. It also includes the transmitter parameter field, which is two bytes containing information about the w-MDDI transmitter. It also includes the MAC address of the transmitter which is the six-byte MAC address of the w-MDDI transmitter and the MAC address of the receiver which is the six-byte MAC address of the w-MDDI receiver. This can be a multicast or broadcast address in the case of using a multicast or broadcast service. It also includes service query options, which are two bytes of service query options. The CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet (including the packet length).

At about the same time as when the "w-MDDI service query" packet is received, all w-MDDI receivers can be added to the UDP port # WMDDI_UDP_ The w-MDDI transmitter of the WMDDI_CONTROL_MULTICAST multicast group on CONTROL_PORT sends back the "w-MDDI service response" packet. The sender can wait for the duration of the service_discovery_timer to be used for the w-MDDI service response packet.

For transmitter service discovery (for example, receiver searching for transmitter) and the underlying layer is UDP/IP, devices with w-MDDI transmitter/receiver capabilities can join the WMDDI_CONTROL_MULTICAST group specified by the WMDDI_CONTROL_MULTICAST_IP multicast address. The available devices of the w-MDDI transmitter can advertise their capabilities by periodically sending w-MDDI service response packets to the WMDDI_CONTROL_MULTICAST group. When the w-MDDI receiver intends to discover the w-MDDI transmitter, it sends a "w-MDDI host query packet" to the WMDDI_CONTROL_MULTICAST multicast group on UDP port # WMDDI_UDP_CONTROL_PORT. Use the w-MDDI host query packet to query the wireless device to determine whether the device supports the w-MDDI receiver functionality.

w-MDDI host query packet includes the packet length field, packet type field, receiver parameter field, transmitter MAC address field, receiver MAC address field, service query option field and CRC field Bit. The packet length field is a two-byte 16-bit integer without a sign containing the total number of bytes in the specified packet (excluding the packet length field). The packet type field is two bytes containing a 16-bit integer without a sign. The packet type 166 identifies the packet as a host query packet. The receiver parameter field is two bytes containing information about the w-MDDI transmitter. The transmitter MAC address field is w-the six-byte MAC address of the MDDI transmitter. this In the case of using a multicast or broadcast service, it can be a multicast or broadcast address. The receiver MAC address field is the six-byte MAC address of the w-MDDI receiver. The service query option field includes two bytes of the service query option. The CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet (including the packet length).

At about the same time as receiving the "w-MDDI host query" packet, all w-MDDI senders can send back "w-MDDI" to the w-MDDI receivers in the WMDDI_CONTROL_MULTICAST multicast group on UDP port # WMDDI_UDP_CONTROL_PORT. The host responds with "packet." The receiver can wait for the duration of the host_discover_timer to be used for w-MDDI host response packets.

According to some aspects, optional security operations can be enabled. If the w-MDDI transmitter and/or w-MDDI receiver are not safe, the resulting operation is not safe. If both the w-MDDI transmitter and the w-MDDI receiver are safe and if any one of them wants safe operation, the resulting operation will be safe. The following table lists the different possibilities regarding the security capabilities of the host and device on which the association takes place. For the remaining possibilities, no association is made.

<tables><img file="TW200915762A_D0001.tif" /></tables>

If safe operation is desired, after completing the association process, a mutual authentication procedure takes place. For safe operation, w-MDDI transmitter and w-MDDI receiver Shared master key. The master key can be exchanged after completing the association process. The master key can be used as the connection key for the entire duration of the association; or the paired temporary key (PTK) can be derived from the autonomous key and can be used. If the underlying lower layer is wiMedia UWB MAC, four-way handshake (handshake) can be used to derive the paired temporary key.

FIG. 12 illustrates a method 1200 for wirelessly communicating high-rate digital data by using a receiver to initiate association. In order to associate the device (for example, the w-MDDI receiver) with the host entity (for example, the w-MDDI transmitter), in step 1202, the w-MDDI receiver sends an association request packet. According to some aspects, the association request packet can be sent by the C2 for the association request when it wishes to associate with the MDDI transmitter after the power of the device is turned on. The association request packet may include packet length, packet type, device parameters, transmitter MAC address, receiver MAC address, association/security options, and CRC fields. The association request packet is sent by C2 in response to the association request when C2 wishes to associate with the MDDI transmitter (for example, after the power is turned on). The packet length can be two bytes with 16 bits without an integer containing the total number of bytes in the specified packet (excluding the packet length field). The packet type can be two bytes in length and contains a 16-bit integer without a sign. Packet type 154 identifies the packet as<i>Association request packet</i>. The device parameters can be two bytes of device-specific parameters. The transmitter MAC address can be the 6-byte MAC address of the w-MDDI transmitter, and the receiver MAC address is the 6-byte MAC address of the w-MDDI receiver. The association/security options are two bytes (bit 0 and bit 1). Bit 0 is the security capability, and is "1" if the security capability exists in the receiver; otherwise, it is "0". Bit 1 is strong security If security is mandatory for the receiver, it is "1"; otherwise, it is "0". The CRC can be two bytes containing the 16-bit CRC of all the bytes in the packet (including the packet length).

At substantially the same time as the sending of the association request packet, the device may enter the "sending association request" state, and at step 1204 may start the association timer. According to some aspects, the association request may contain information about whether the w-MDDI receiver is secure and/or whether security is mandatory for the w-MDDI receiver.

The w-MDDI transmitter shall confirm the association request packet and respond with an association response packet before the association timer reaches a predetermined interval (for example, timeout, expiration). The association response packet may include a client ID that identifies the w-MDDI receiver. According to some aspects, the association request packet includes information about whether the w-MDDI transmitter is secure and/or whether security is mandatory for the w-MDDI transmitter. After transmitting the association response packet, the w-MDDI transmitter can enter the "send association response" state and start the association response timer.

In response to the one sent by C1<i>Association request packet</i>Instead, an association response packet is sent. This packet provides the client ID and display/device ID to C2. This is part of the three-way handshaking association. The packet includes the packet length, which is two bytes of 16 bits without an integer containing the total number of bytes in the specified packet (excluding the packet length field). The packet type field is two bytes containing a 16-bit integer without a sign. Packet type 155 identifies the packet as<i>Associate response packet</i>. It also includes the two-byte client ID allocated for the client ID of C2 and the association of two bytes (bit "0", bit "1" and bit "2")/ Security options. Bit 0 indicates safety capability, and It is set to "1" when the full power exists in the transmitter; and otherwise it is set to "0". Bit 1 indicates that the security is mandatory, and is set to "1" if security is mandatory for the transmitter; and is set to "0" otherwise. Bit 2 indicates whether to include a multicast address. This bit is set to "1" when the multicast address is included with the associated response packet. The CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet (including the packet length).

w-MDDI transmitter and receiver can negotiate their security capabilities and mandatory options with "association request packet" and "association response packet". The association process can proceed or stop based on the possibilities listed in Table 1 described above. If the secure communication option is enabled as a result of the above negotiation, the client ID provided by the w-MDDI transmitter is not authenticated at this point and will only be trusted after the mutual authentication process is completed.

In step 1206, a determination is made as to whether the timer has expired. Since the underlying 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 1200 continues at step 1206 to determine whether the timer has expired. If it is determined in step 1206 that the timer has expired, the method 1200 in step 1202 continues to resend subsequent association request packets. This can be recursive, where many subsequent association request packets can be sent up to a maximum number of times.

According to some aspects, after the association response timer expires, the w-MDDI transmitter can resend the association response packet. According to some aspects, the w-MDDI transmitter can receive data from the w-MDDI receiver whenever it receives When the association request packet is associated, an association response packet is sent.

If the timer has not expired ("No"), then in step 1208, it is determined whether the association response packet has been received. If it is determined in step 1208 that the association response packet has been received ("Yes"), the method 1200 continues at step 1210, and the client capability packet is sent to the w-MDDI transmitter to confirm the association request packet.

In step 1212, a status packet or a client capability packet can be transmitted. The client capability packet can be sent when the w-MDDI receiver receives the associated response packet from the w-MDDI transmitter.

If the security option is enabled, the client capability packet has not yet been authenticated at this point. The content of the client capability packet is only trusted after the mutual authentication is completed in step 1212 (this is optional as indicated by the dashed line). The following will provide additional information about mutual authentication.

After sending the client capability packet, the w-MDDI receiver can enter the associated state (if the security option is not enabled), and the associated w-MDDI receiver can enter the associated state (if the security option is not enabled). If the security option is enabled, the mutual authentication process (described below) should be completed before the w-MDDI transmitter and w-MDDI receiver enter the associated state. In this way, a three-way handshake association is established. According to some aspects, if the association request packet, the association response packet, and/or the client capability packet are lost, they can be retransmitted when the wireless link is stable. Otherwise, the w-MDDI transmitter and w-MDDI receiver will not become associated (for example, they may still be in a disassociated state). According to some aspects, the w-MDDI receiver can send a replacement display capability packet if it has any associated replacement display.

After being associated with a specific w-MDDI transmitter, the w-MDDI receiver can store the lower layer address (MAC address) of the transmitter. After entering the associated state, in step 1214, the w-MDDI receiver should send (for example, periodically, such as once in mac_response_time milliseconds) link state packets (MAC response packets) to the host. The link state packet provides the w-MDDI transmitter with MAC statistics about the w-MDDI receiver MAC (for example, the average number of retransmissions, packet error rate, etc.). The fields included in the link state packet are packet length, packet type, c client ID, average number of retransmissions, frame error rate, physical layer rate and CRC. The packet length is a 16-bit integer without a sign and two bytes containing the total number of bytes in the specified packet (excluding the packet length field). The packet type is two bytes containing 16-bit integers without a sign. The packet type 150 identifies the packet as a MAC response packet. c The client ID is two bytes containing a 16-bit integer without a sign. This depends on the identification code of the package initiator and is the client ID of C1/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 seen in the forward direction. The physical layer rate is the transmission rate on the physical layer. The CRC is a two-byte group containing 16-bit CRC of all the bytes in the packet (including the packet length).

At substantially the same time as the link state packet (MAC response packet) received from the w-MDDI receiver, the w-MDDI transmitter can send a link state packet (MAC response packet) to respond. This packet confirms the reception of the link state packet (MAC response packet) sent by the w-MDDI receiver. It can also provide statistics and parameters of the receiver MAC to the w-MDDI transmitter.

If the w-MDDI receiver does not respond to the lower layer response packet (MAC response packet) sent by it within the duration of mac_response_fail_time milliseconds and receives the transmitter link state packet (transmitter MAC response packet) from the w-MDDI transmitter ), the w-MDDI receiver can recognize that it has been disassociated from the transmitter. It then stops sending link state packets (MAC response packets). If the transmitter does not receive the link state packet (MAC response packet) within the duration of mac_response_fail_time milliseconds, the transmitter enters the disassociation state. When the transmitter or receiver enters the disassociation state, it does not respond to the link state packet/transmitter link state packet (MAC response packet/transmitter MAC response packet) sent by the receiver and transmitter respectively.

The lower layer response (MAC response) is a message from the lower layer (for example, the MAC layer) to the w-MDDI transmitter/receiver. This message indicates the rate supported by the lower layer (for example, MAC), re-traditional meter, etc. The message includes a message ID, which is a two-byte group containing 16-bit integers without a sign. Message ID 0x5 identifies the packet as a MAC response message. The packet also includes the average number of retransmissions, which is the average number of retransmissions for each MAC frame transmitted in the reverse direction. The frame error rate indicates the packet error rate seen in the forward direction and the physical layer rate, which is the transmission rate on the physical layer.

The lower layer address response (MAC address response) provides the lower layer address (for example, MAC address) of the lower layer (for example, UWB modem). This message includes a message ID, which is a two-byte group containing 16-bit integers without signs. Message ID 0x6 identifies the packet as a MAC address response message. It also includes the lower layer (MAC layer) address which is the lower layer address (MAC layer address) of the underlying layer.

After disassociating, the w-MDDI transmitter and receiver need to re-associate before they can start wireless MDDI transmission again. After the w-MDDI receiver has been disassociated from a particular transmitter, it is allowed to associate with any other transmitter. The following describes other information about disassociation.

According to some aspects, the w-MDDI receiver also sends a link state packet (MAC response packet) when the w-MDDI transmitter explicitly requests it via a link query packet (MAC query packet).

The host sends a link query packet to query the MAC information on the transmitter/receiver side. The content of the link query packet includes the packet length, which is two bytes containing 16 bits without an integer of the total number of bytes in the specified packet (excluding the packet length field). The packet type is two bytes containing 16-bit integers without a sign. The packet type 151 identifies the packet as a MAC query packet. c The client ID field is two bytes containing a 16-bit integer without a sign, which is reserved for the ID of the destination client (C2). The MAC query parameter is two bytes, and the CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet (including the packet length).

If the underlying wireless link is an 802.15.3 UWB MAC, after associating with the w-MDDI receiver, the w-MDDI transmitter can be used in the low-latency mode of operation (this will be described in further detail below) Set the CTA for transmission by using the CTA setting packet in the forward and reverse directions.

Figure 13 illustrates a method 1300 for high-rate wireless data communication between a transmitter and a remote receiver. Method 1300 can be used when the w-MDDI transmitter wishes to associate with the w-MDDI receiver. For example, if the w-MDDI transmitter is a telephone and the w-MDDI receiver is a projector, then the w-MDDI transmitter (e.g. For example, telephone) can initiate the association process.

The method 1300 illustrates that the sender initiates the association, and starts with the transmission of the sender association request packet to the remote receiver in step 1302. The sender association request packet is sent by the sender for an association request when it wants to associate with a specific MDDI receiver (for example, after power is turned on). The sender association request packet includes the packet length of two bytes containing 16-bit unsigned integer (which specifies the total number of bytes in the packet (excluding the packet length field)) and the packet length containing 16 bits. The packet type of two bytes with a signed integer. Packet type 158 identifies the packet as<i>Association request packet</i>. 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 association/security options include two bytes (bit "0" and bit "1"). The bit "0" indicates the security capability, and is set to "1" if the security capability exists in the receiver, or set to "0" otherwise. The bit "1" indicates whether security is mandatory. If it is set to "1", the security is mandatory for the receiver, otherwise it is set to "0". The CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet (including the packet length). According to some aspects, the sender association request packet includes information about whether the w_MDDI sender is secure and/or whether the security is mandatory for the w-MDDI sender.

At substantially the same time as the sending of the first association request packet, the sender enters the "send sender association request packet" state, and a timer (for example, an association timer) or other tracking means can be started in step 1304. Track the transmission of the first association request packet and the response from the remote receiver (such as association The time interval between the receipt of the request packet), and in step 1306, it is determined whether the predetermined time interval has been exceeded (for example, the timer has expired). If the timer has expired ("Yes"), it indicates that no association request packet has been received from the remote transmitter, and the method 1300 continues at step 1302, 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,<i>max_sender_association_retry</i>) The number of times. If the timer has not expired ("No"), in step 1308, it is determined whether the association request packet has been received.

If it is determined in step 1308 that the association request packet has not been received ("No"), the method 1300 continues in step 1306 until the timer expires or the association request packet is received. If the association request packet has been received ("Yes"), an association response packet can be sent, which provides the client ID to the remote device.

In response to the one sent by C1<i>Association request packet</i>Instead, an association response packet is sent. At roughly the same time as the transmission of the association response packet, the w-MDDI receiver can enter the "send association request" state and start the association timer. The association response packet can be resent up to the maximum number of times of max-association_retry. According to some aspects, the association response packet includes information about whether the w-MDDI receiver is secure and/or whether the security is mandatory for the receiver.

This packet provides the client ID and display/device ID to C2. This is part of the three-way handshaking association. The associated response packet includes packet length, packet type, client ID and CRC. The packet length is two bytes containing the total number of bytes in the specified packet (excluding the packet length field), which is 16 bits without a sign integer. The packet type is two bytes containing 16-bit integers without a sign. Packet type 155 identifies the packet as<i>Associate response packet</i>. The client ID is two bytes of the client ID allocated for C2, and the CRC is two bytes of the 16-bit CRC containing all the bytes in the packet (including the packet length).

If it is determined in step 1308 that the packet is received ("Yes"), then in step 1312, the w-MDDI transmitter responds with an associated response packet that provides the client ID to the w-MDDI receiver (similar to the above description When the receiver initiates the association). According to some aspects, the association response packet also contains security capabilities and security mandatory information for transmission, thereby confirming the information that was originally sent.

The transmitter may also start a timer such as the association response timer at substantially the same time as the association response packet is sent. The receiver should respond with client capability packets and/or link quality information. Each association response received by the receiver should be responded to with a client capability packet.

If the association response timer expires, the wireless transmitter resends the association response packet for the maximum number of times (for example, association_retry). The sender's association request, association request, association response and client capabilities can constitute a four-way handshaking procedure.

The method 1300 enables the w-MDDI transmitter and receiver to negotiate their security capabilities and mandatory options. The association process can be performed or stopped based on the possibilities in Table 1 as described above. If the secure communication option is implemented as a result of the above negotiation, the client ID provided by the w-MDDI transmitter is not authenticated at this point and will only be trusted after the mutual authentication process is completed.

If the security option is turned on, mutual authentication can be performed, which will be described below. According to some aspects, the receiver associated with a particular transmitter will Do not accept association requests from any other senders. In this case, the w-MDDI receiver can send an association rejection packet to the sender.

Figure 14 illustrates a procedure 1400 for mutual authentication and key exchange. According to this example, the program 1400 is based on the digital association model of the wireless USB. If security operations are required, mutual authentication and key exchange occur between the w-MDDI transmitter 1402 and the w-MDDI receiver 1404. This program is similar to the "digital association program" in wireless USB. The Diffie-Hellman protocol can be used to establish temporary security channels. To prevent man-in-the-middle attacks, the host and the device can each display the value derived from the Diffie-Hellman key, and ask the user to verify that the two values match.

w-MDDI receiver 1404 can generate the latest random key A and calculate PK_D=g^AMod p. A and PK can be banned_DThe value is hard-coded into the device at manufacturing time. w-MDDI receiver 1404 can calculate hash SHA-256 (PK_DN_D) And send the hash to the w-MDDI transmitter 1402 at 1406. N_DIt is the number of digits that the device can display. This hash submits the device to the PK_DAnd N_DThe values are not disclosed until later (after the public key of the w-MDDI transmitter is disclosed).

w-MDDI transmitter 1402 can generate the latest random key B and calculate PKH=g^BMod p. B and PK can be banned_HThe value is hard-coded into the w-MDDI transmitter at manufacturing time. The w-MDDI transmitter 1402 sends PKH to the device at 1408. Device in PK_HIf it is equal to 1 or p-1, the association is aborted.

The w-MDDI receiver 1404 sends a PK to the w-MDDI transmitter at 1410_DAnd N_D. W-MDDI transmitter 1402 in PK_DIf it is equal to 1 or p-1, the association is aborted. W-MDDI transmitter 1402 calculates SHA-256(PK_DN_D)and The verification result is submitted with the hash previously received from the device. The W-MDDDI transmitter 1402 aborts the association if the value does not match. In addition, the W-MDDDI transmitter 1402 calculates the shared key DHKey=SHA-256 (PKDB modulo p). w-MDDI transmitter 1402 calculates the shared key DHKey=SHA-256(PK_H^AMod p).

In order to protect against man-in-the-middle attacks, both parties calculate the common value V=SHA-256(PK_DPK_H "is displayed Summary"), and in which each of the display of a plurality of digits of this number (e.g., two digits, three digits, four digits, etc.) to another user on the display.

The user can manually verify that the w-MDDI transmitter matches the numbers shown on the device (for example, check two displays), and press the w-MDDI transmitter and "ok" on the device (or take a certain value) Effective action). If the user selects "does not match" or the user confirmation is not received on both the w-MDDDI transmitter and the device within the timeout period, the association will be aborted and a failure indication will be displayed to the user. The timeout period can be at least 20 seconds and there is no maximum timeout period.

If the user approves the association, both the w-MDDDI transmitter and the device calculate the master key (PMK) = the first 128 bits of HMAC-SHA-256DHKey ("Paired Master Key"). The w-MDDDI transmitter also sends to the device any remaining non-private information needed to complete the association.

If any other application needs additional keys for whatever purpose, the key derivation key KDK is calculated as KDK=HMAC-SHA-256-DHKey ("key derivation key"). The KDK value can then be used immediately or stored for later use as key material for any other purpose.

According to some aspects, disassociation can occur. For example, if w- If the MDDI transmitter does not receive the link state packet (MAC response packet) from the receiver within mac_response_fail_time milliseconds, it can declare that the receiver is disassociated. The transmitter then removes the entry corresponding to the receiver from the device association table. After entering the disassociation state, the w-MDDI transmitter/receiver does not respond to link state packets (MAC response packets) and transmitter link state packets (transmitter MAC response packets) respectively.

According to some aspects, if the w-MDDI receiver does not respond to the max_MAC_Response_retries packet but receives the transmitter MAC response packet, the w-MDDI receiver enters the disassociation state. If the link state packet (MAC response packet) appears from the receiver after the receiver has been marked as disassociated in the transmitter's device association table, the association process needs to be restarted by the transmitter (for example, the transmitter performs a transmission Start association).

FIG. 15 illustrates the receiver initial disassociation procedure 1500. The w-MDDI receiver 1504 can also be disassociated by sending an explicit disassociation request packet 1506 to the w-MDDI transmitter 1502. w-MDDI transmitter 1502 responds with a disassociation response packet 1508. After receiving this packet, the w-MDDI receiver 1504 enters the disassociation state. The w-MDDI transmitter 1502 then removes the entry corresponding to the w-MDDI receiver 1504 in the device association table.

Figure 16 illustrates a method 1600 for the initial disassociation of a receiver between a user device (e.g., receiver) and a host entity (e.g., transmitter). The method 1600 starts at step 1602 by associating the user device with the host entity. At substantially the same time as the establishment of the association with the host entity, the capability packet is sent in step 1604. The capability package may include one or more capabilities of the user device. The status packet can be transmitted in step 1606. The transmission of the status packet It can be based on a request from the host entity for the packet, either in a periodic manner or when the state changes.

In step 1608, it may be determined that the association is disconnected, and/or in step 1610, it may be determined to stop communication with the host entity. For example, the determination can be made when the wireless receiver has not received the transmitter MAC response packet from the wireless transmitter within a predetermined amount of time. The MAC response packet provides MAC statistics about the wireless receiver's MAC, such as the average number of retransmissions, packet error rate, etc. Packet content can include packet length, packet type, client ID, average transmission times, frame error rate, physical layer rate, and CRC. The MAC response packet can be two bytes in length, and it contains a sixteen-bit integer without a sign that specifies the total number of bytes in the packet (excluding the packet length field). The packet type is two bytes containing sixteen-bit integers without a sign. The packet type 150 identifies the packet as a MAC response packet. The client ID is a two-byte group containing sixteen-bit integers without a sign. This regards which client is the initiator of the packet and is the client ID of C1/C2. The average number of retransmissions can be two bytes and is for each MAC frame transmitted in the reverse direction. The frame error rate can be two bytes, and it is the packet error rate seen in the forward direction. The physical layer rate can be two bytes, and it is the transmission rate on the physical layer. The CRC is a two-byte group containing the 16-bit CRC of all the bytes in the packet (including the packet length).

The transmitter MAC response packet provides the w-MDDI receiver with MAC statistics about the w-MDDI transmitter MAC, such as the average number of retransmissions, packet error rate, etc. This packet is confirmed by the MAC response packet sent by the wireless receiver The packet is sent by the wireless transmitter. The packet contains a packet length field of two bytes, which contains a 16-bit integer without a sign that specifies the total number of bytes in the packet (excluding the packet length field). It also includes a two-byte packet type field, which contains a 16-bit integer without a sign. The packet type 159 identifies the packet as a sender MAC response packet. c The client ID is two bytes containing a 16-bit integer without a sign. This is the client ID of C2 (destination client). The average number of retransmissions is the average number of retransmissions for each MAC frame transmitted in the reverse direction. The frame error rate is the packet error rate seen in the forward direction. The physical layer rate is the transmission rate on the physical layer. The packet also includes the CRC, which is two bytes in length, and contains the 16-bit CRC of all the bytes in the packet (including the packet length).

If either or both of the associations are disconnected or communication should stop, then the user device should be disassociated from the host entity. The disassociation may include sending an explicit disassociation request packet to the wireless transmitter in step 1612. 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 in step 1614. At substantially the same time as when the disassociation response is received, in step 1616, the user device enters the disassociation state.

The disassociation request packet can be sent by the C2 when it wants to disassociate from the wireless transmitter and perform a graceful exit. The disassociation request packet includes a packet length field, which is 2 bytes in length, and the two bytes contain 16 bits that specify the total number of bytes in the packet (excluding the packet length field). Signed integer. The packet type field is two bytes containing a 16-bit integer without a sign. Packet type 156 identifies the packet as<i>Disassociation request packet</i>. The client ID field is two bytes of the client ID allocated for C2. The CRC field is 2 bytes containing the 16-bit CRC of all the bytes in the packet (including the packet length).

Respond to<i>Disassociation request packet</i>Send a disassociation response packet. It has a packet length of two bytes, and the two bytes contain a 16-bit unsigned integer that specifies the total number of bytes in the packet (excluding the packet length field). The packet type is two bytes containing 16-bit integers without a sign. Packet type 157 identifies the packet as<i>Disassociate response packet</i>. The client ID is two bytes of the client ID allocated for C2, and the CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet (including the packet length).

Referring now to Figure 17, the transmitter initiates the disassociation procedure 1700. The transmitter 1702 can disassociate by sending a transmitter disassociation request packet 1706 to the receiver 1704. The receiver 1704 then sends a disassociation request 1708. The sender 1702 confirms by sending a disassociation response 1710 that completes the disassociation procedure.

Figure 18 illustrates a method 1800 for selective disassociation between a transmitter and a remote receiver. In step 1802, an association between the transmitter and the remote receiver can be established. In step 1804, a packet including the capabilities of the remote receiver can be received, and in step 1806, link quality information can be received. In addition, the device association table associated with the transmitter may include the MAC address of the transmitter and the identification of the remote receiver.

In some cases, it may be necessary to interrupt the association between the remote receiver and the transmitter, and in step 1808 it can be made that the transmitter and the remote receiver should be disabled. To determine the communication between devices. For example, if the wireless transmitter is not at a predetermined interval (e.g.,<i>mac_response_fail_</i>When receiving a MAC response packet from the receiver within milliseconds of time), it can declare that the receiver is disassociated, and in step 1810, send a sender disassociation request packet to the receiver. In step 1812, a response to a disassociation request (for example, a disassociation request) is received from the receiver. In step 1814, a disassociation completion confirmation (for example, disassociation response) may be sent to complete the disassociation procedure.

In some aspects, the disassociation request may be explicitly received in step 1816 from the remote receiver. In step 1818, a disassociation response confirmation (for example, a disassociation response) is sent. In step 1820, the identification of the disassociated device is removed from the association table.

The wireless transmitter that initiated the disassociation sends the transmitter disassociation request packet. It includes a packet length field of two bytes, and the two bytes contain a 16-bit integer without a sign that specifies the total number of bytes in the packet (excluding the packet length field). The two-byte packet type field contains a 16-bit integer without a sign. Packet type 161 identifies the packet as<i>Disassociation request packet</i>. The client ID is 2 bytes of the client ID allocated for C2. The CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet (including the packet length).

According to some aspects, all W-MDDI receivers periodically send once in mac_response_time milliseconds<i>Link state packet</i>(<i>MAC response packet)</i>. The host obtains w-MDDI receiver link statistics (receiver-MAC statistics) from these packets. The transmitter also periodically queries the transmitter-MAC to obtain transmitter-side link statistics (MAC statistics). The transmitter can be based on this information The information determines the lower layer rate (MAC rate). This rate information can be passed to the application. This helps the application to scale up/scale down its data rate. The transmitter responds to what it receives from each of the individual w-MDDI receivers<i>Link state packet (MAC response packet)</i>Send to individual receivers<i>Transmitter Link State Packet</i>(<i>Sender MAC response packet)</i>。

According to some aspects, the w-MDDI transmitter passes through the<i>Associate response cover</i>The packet sends the client ID to the w-MDDI receiver. The client ID represents the address identifier of the specific w-MDDI transmitter. The user ID pool is unique to the sender. The new receiver can be assigned any client ID from the free pool. According to some aspects, the w-MDDI receiver can be assigned a client ID that has not been used for a maximum amount of time. (For example, the associated contexts that use the same client ID are separated by a long time). This is to ensure that the user ID is reused as frequently as possible.

Figure 19 illustrates a single wireless transmitter associated with multiple wireless receivers according to the disclosed aspect. In order to fully understand the disclosed aspects, various wired packets and their behavior in wireless technology will now be described. In the wireless communication of high-rate data, no stuffing packet is generated because the stuffing packet is designed to maintain synchronization on the wired link, and therefore it is not necessary for the wireless link.

The client capability packet informs the host of the client capability. In MDDI, the user end should send this packet after forward link synchronization. The client can also send a client capability packet when requested by the host via the reverse link flag in the reverse link encapsulation packet. The client capability packet may contain fields about the link, such as data rate capability before correction, interface type capability, data rate capability after correction, and so on. This package may also contain information about external devices (such as attachment To the field of the display device on the user side. These fields may include the number of replacement displays, bit-mapped width, bit-mapped height, display window width, display window height, color map size, etc.

During the association procedure in wireless MDDI, the receiver can send a client capability packet as a response to the association response packet sent by the wireless transmitter. The wireless receiver (C2) can also send alternative display capability packets when it is associated with any alternative display. The wireless receiver (C2) can send a client capability packet to the transmitter when the state and/or capability of the external device changes (for example, adding a new device, removing an existing device, changing the parameter of an existing device, etc.). Otherwise or in addition, the client capability packet may be sent periodically to help the reliability of the client capability packet. According to some aspects, the w-MDDI receiver can send a client capability packet to the w-MDDI transmitter when the w-MDDI transmitter requests the client capability packet via the C2 flag field of the C2 request packet.

The client request and status packet can be used to send information from the client to the host to allow the host to configure the host-client link in a better way. In the wired MDDI configuration, the user end can send this packet to the host as the first packet in the reverse link encapsulation packet. Otherwise or in addition, the client can send the packet to the host when the host explicitly requests the packet via the reverse link flag in the reverse link encapsulation packet.

In wireless MDDI, the wireless receiver can periodically send a client request and status packet to the wireless transmitter to indicate its CRC error count, and also send a client request and status packet when the state of the external device changes. The wireless receiver can also request the C2 flag field of the packet request via C2 Ask the wireless transmitter of the client request and status packet to send the client request and status packet.

Referring again to FIG. 19, each wireless transmitter 1902 (only one of which is illustrated) can be associated with multiple wireless receivers (illustrated as receiver 1 (R1) 1904, receiver 2 (R2) 1906, and receiver 3 (R3). 1908) Association or communication. The transmitter 1902 and the receivers 1904, 1906, and 1908 may be MDDI transmitters and/or MDDI receivers or other transmitters and receivers that can wirelessly transmit high-rate digital data. Each receiver 1904, 1906, and 1908 may have multiple displays (not shown) and devices (not shown). For example, each receiver may have sixteen displays, although more or less than sixteen may be associated with a single receiver. Each receiver may have a w-MDDI client entity C2.

For example, wireless devices such as wireless displays, wireless mice, wireless keyboards, etc. may have w-MDDI receivers, and each wireless device may be identified as an independent user terminal. From the perspective of the host (for example, the transmitter 1902), each of these clients can be identified by a unique client identification (client ID). Therefore, the client C1 may have a client ID "0". A wireless receiver such as the receiver (R2) 1906 can send a client capability packet to the wireless (C2) transmitter 1902 when the capability of an external device connected to the receiver (R2) 1906 changes. In addition or otherwise, each receiver can periodically send a client capability packet to ensure reliability.

The transmitter 1902 should maintain a device association table such as the table 2000 shown in FIG. 20. Table 2000 illustrates the association between a single wireless transmitter and multiple wireless receivers (for example, user terminals).

Based on this table, packets intended for different receiver clients can be forwarded to Individual devices. Table 2000 illustrates two clients (1 and 2). The MAC address X: Y: Z: P: Q: R and the client ID "C21" are associated with the client #1. The MAC address U: V: W: L: M: N and the client ID "C22" are associated with the client #2. In this way, the transmitter can communicate with the appropriate receiver by accessing the lookup table 2000.

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 (e.g., the transmitter) will usually initiate communication. However, there are situations where the receiver will initiate communication. Therefore, there may be a receiver-initiated association or a transmitter-initiated association.

According to some aspects, if the underlying lower layer supports multicast, then a single w-MDDI transmitter communicating with multiple w-MDDI receivers can utilize multicast support. w-MDDI receiver and transmitter can join WMDDI_CONTROL_MULTICAST group.

W-MDDI transmitters wishing to use multicast facilities should form a multicast group. If there is a centralized server (for example, a DHCP server) that provides a lower-layer multicast address in the case of IP, the w-MDDI sender can obtain the multicast address by lease. This can be performed before the service discovery process or after the service discovery process. The duration of the lease can be short-term (limited to the duration of the association) or it can be relatively long-term (far longer than the duration of the association).

For example, when there is a centralized server, the centralized server should be used to assign addresses. In the absence of a centralized server, each individual sender can individually select a multicast address. In this case, there may be Address conflicts (for example, two transmitters choose the same address). Therefore, there should be an algorithm to relieve multiple transmitters from selecting the same address.

According to various aspects, operations for miMedia UWB Mac can be performed. As mentioned earlier, w-MDDI can operate on any underlying high-speed wireless link. As an example, the following describes the operation of w-MDDI on wiMedia MAC. When the underlying layer is wiMedia UWB MAC, the following can be used to send control packets (for association, disassociation, etc.).

The application-specific IE can be used in the beacon to carry the control packet in the w-MDDI. For example, the application-specific data field in ASIE can be set as a control packet (used for associating, disassociating, etc.). The ASIE packet is shown in Figure 10. Set the ASIE specifier ID to: wMDDI_wiMedia_ASIESpecifierID.

If the application-specific IE cannot be used, the PCA mode can be used to send control packets for association and disassociation when the PCA mode is available and the use of the ASIE element in the beacon is not feasible. If the PCA mode is used, it should use user priority=7, that is, AC=AC_VO.

If you cannot use application-specific IE and PCA, you can use DRP. When using DRP, soft DRP can be used. If the PCA mode is used, it should use user priority=7, that is, AC=AC_VO. In the case where the receiver initiates the association,<i>Association request</i>The MAC header of the packet can be as follows: Frame control: Retry: 0 Frame subtype/transfer ID: When using PCA, b12=0 User priority (b11-b9)=7 (corresponding to voice; for example, AC=AC_VO) When using DRP, b12 = 1 stream index (b11-b9) = (between 8 and 15) frame type (b8-b6): data ACK strategy: 1 (Imm-ACK) security:? Protocol version: 0 (current) Access information: access method: 0 (if PCA is used): 1 (if DRP is used) More frames: set correspondingly Duration: set correspondingly Destination address: sender device Address source address: the device address of the receiver when DRP is used, soft DRP can be used.

Data packets (for example, audio stream packets, video stream packets, etc.) can be reserved using DRP on the forward and reverse links. Traditional MDDI control packets can use PCA mode when available. Otherwise, it shall be reserved using DRP.

Figure 21 illustrates a system 2100 for extending the capabilities of a traditional wired configuration to allow communication over a wireless link. The system 2100 includes a transmitter 2102 that communicates with a receiver 2104 on the forward link. The receiver 2104 communicates with the transmitter 2102 on the reverse link. The transmitter 2102 and the receiver 2104 may be devices that generally communicate on a wired protocol, however, the system 2100 allows these devices to communicate on a wired protocol and/or a wireless protocol (such as on a high-speed wireless link). Although, as should be understood, many transmitters 2102 and receivers 2104 may be included in the system 2100, for the sake of simplicity, it is explained that the communication data signals are transmitted to A single transmitter 2102 of a single receiver 2104.

The transmitter 2102 may include a host 2106, a part of the client (C1) 2108, and a communication component 2110. For example, the host 2106 may be an MDDI host. According to some aspects, the host 2106 may be a component that is disassociated from the transmitter 2102 and connected to the transmitter 2102 via a wired link. A part of the client (C1) 2108 remains on or keeps communicating with the host 2106 for clock synchronization. For example, the client (C1) 2108 may be connected to the host 2106 via a traditional wired link (for example, an MDDI link). The host 2106 can be configured to send or communicate data packets to the client (C1) 2108. These packets can be communicated to the receiver 2104 via a communication component 2110 that can include a modem, such as an ultra-wideband (UWB) modem. Some packets (for example, MDDI round-trip delay measurement packets) are processed by the client (C1) 2108 and communicated to the receiver 2104. Other packets (for example, padding packets) should be discarded by the client (C1) 2108 and not communicated to the receiver 2104. That is, some packets should not be transmitted on the forward wireless link or the reverse wireless link. For example, the stuffing packet is maintained at the timing between the transmitter 2102 and the receiver 2104. These packets can be generated by the transmitter 2102 or the receiver 2104 via respective client parts.

The receiver 2104 may include an interface device 2112 (for example, a display), a part of the client (C2) 2114, and a communication component 2116. According to some aspects, the device 2112 may be a component that is disassociated from the receiver 2104 and connected to the receiver 2104 via, for example, a wired link. The client (C2) 2114 can be connected to the device 2112 via a wired link. The client (C2) 2114 can be configured to process packets received from the transmitter 2102. The receiver 2104 may receive communications from the transmitter 2102 via a communication component 2116 which may include, for example, a UWB modem.

The system 2100 can be configured to operate in one of two modes of operation. These modes include low burden mode and low latency mode. In the low-burden mode, the client (C1) 2108 places the data to be sent (excluding (for example) padding packets and round-trip delay packets) in a buffer that can be included in the communication component 2110 (for example, UWB modem) . The communication component 2110 may periodically request a unidirectional channel time allocation (CTA) from the transmitter 2102 to the receiver 2104 via, for example, the UWB MAC based on the size of the buffer. In the reverse direction (e.g., reverse link), the client (C2) 2114 can place the reverse link data to be sent (e.g., excluding stuffing packets) on the communication component 2116 (e.g., UWB modem). ) In the associated buffer. In the reverse direction, the communication component 2116 may request a reverse direction CTA.

For the low-latency mode, during the initialization phase, the communication component 2110 (e.g., UWB modem) can request in the forward direction<i>m</i>CTA in milliseconds and request in the reverse direction<i>n</i>CTA in milliseconds. The expected ratio of traffic in the forward and reverse directions is<i>m</i>：<i>n</i>,and<i>m</i>Second is corresponding to MDDI forward link transmission rate R_f-mddiThe duration. T_CTAPIs the duration of the CTA period, and<i>T</i>Is the duration of the super frame, which is determined by the applied delay constraint, where: (<i>m</i>＋<i>n</i>)&lt;T_CTAP&lt;T

Referring now to FIG. 22, a system 2200 for communicating via a wired and/or wireless architecture is illustrated. The system 2200 includes a transmitter 2202 and a receiver 2204 that communicate on the forward link (from the transmitter 2202) and/or the reverse link (from the receiver 2204). Communication on the forward link and/or reverse link depends on specific circumstances (e.g. For example, the data to be transmitted, the data rate, the quality of the communication link, the status of each device...) can be performed on the wired protocol and/or on the wireless protocol. Although, as should be understood, many transmitters 2202 and receivers 2204 may be included in the system 2200, a single transmitter 2202 that transmits communication data signals to a single receiver 2206 is described for simplicity.

The transmitter 2202 may include a host component 2206, which is connected to a client (C1) component 2208 and a communication component 2210. The receiver 2204 may include a device 2212 that is connected to a client (C2) component 2214 and a communication component 2216. The client (C1) component 2208 and the client (C2) component 2214 are separate parts of the client.

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

The receiver 2204 may include a decoder component (not shown), which can decode the received signal and/or the data packet therein for processing. After the data packet is successfully decoded, an acknowledgment (ACK) component (not shown) can generate a confirmation indicating the successful decoding of the data packet, which can be sent to the transmitter 2202 for notification The transmitter 2202 receives and decodes the data packet, and therefore does not need to be retransmitted.

The host component 2206 may include a query module 2218 and a measurement module 2220. The query module 2218 can be configured to query the host MAC for the application data rate provided by the media access control (MAC). For wireless communication, the operating rate may depend on the rate of the wireless link. The measurement module 2220 can be configured to determine the forward link rate and the reverse link rate based on, for example, round-trip delay measurements that can be specified in the wireless protocol. According to some aspects, the wireless operating rate can be determined by the smallest of the two rates (forward link rate and reverse link rate), the maximum capability of the host 2206, and the maximum capability of the client (C1) 2208. There should be a minimum allowable rate R_min. If the measured operating rate is below the minimum allowable rate, the transmitter 2202 and/or the receiver 2204 can adjust the operating rate via respective components (for example, the communication components 2210 and/or 2216). The transmitter 2202 can notify the receiver 2204 of the rate at which the communication will be processed.

The client (C2) component 2214 may include a notification program module 2222, which may be configured to notify the transmitter 2202 of the application data rate provided by the MAC. The notification may be based on a query received from the transmitter 2202 (for example, a query sent by the query module 2218). For reverse link packets, the notification program module 2222 can specify the number of bytes required by the receiver 2204 to send on the reverse link in the current frame. The client (C2) component may also include an assigner module 2224, which can be configured to assign communication to various parameters (for example, communication type, communication rate, transmitter, receiver, etc.) associated with the communication Wired agreement or wireless agreement.

The communication component 2216 may include a wired module 2226 and a wireless module 2228. The wired module 2226 can be configured to provide wired functionality, and the wireless module 2228 Can be configured to provide wireless functionality. It is possible to determine whether to use the wireless module 2228 to communicate wirelessly or to use the wired module 2226 to communicate. The determination can be based on a variety of factors, including the operating rate, the type of data transmitted (for example, voice, text, image...), the size of the transmitted data or file, and whether the data is usually transmitted over a wired link or a wireless link. The wired module 2226 and/or the wireless module 2228 may include a buffer, which is used to store content so that if changes are made from one module to another during the communication (for example, wireless to wired, wired to wireless) , The communication will not be lost due to handover issues.

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

According to some aspects, the transmitter 2202 may include components configured to segment sub-frames (not shown), and the receiver 2204 may include components configured to recombine sub-frames (not shown). The maximum length of the MDDI subframe (for example) can be about 65,536 bytes, although it is generally small. The maximum size of the 802.15.3 MAC frame can be approximately 4,096 bytes or approximately 8,192 bytes (when the underlying rate is approximately 480 Mbps). If the underlying physical layer rate is approximately 200 Mbps, the size can be approximately 2,048 bytes. Therefore, the sub-frame may need to be segmented on the transmitter 2202 side and reorganized on the receiver 2204 side to fit the size of the frame. The segmentation and reassembly can be performed by the respective communication components 2210 and 2216 and/or other components associated with the transmitter 2202 and the receiver 2204.

Figure 23 illustrates the method used to extend the traditional wired configuration to allow communication on the wireless link. Another aspect of the letter system 2300. The system 2300 may include a transmitter 2302, which includes a host 2306, a part of a client (C1) 2308, and a communication component 2310. The system 2300 may also include a receiver 2304, which includes a device 2312, a part of the client (C2) 2314, and a communication component 2316. The transmitter 2302 communicates to the receiver 2304 on the forward link, and the receiver 2304 communicates to the transmitter 2302 on the reverse link. As previously explained with respect to the above drawings, although many transmitters 2302 and receivers 2304 may be included in the system 2300, a single transmitter 2302 that transmits communication data signals to a single receiver 2304 is described for the sake of simplicity.

The system 2300 may include a memory 2318 operatively coupled to the receiver 2304. The memory 2318 can store information about the following: the data rate of the packet and/or packet type (for example, the application data rate provided by the MAC, the operating rate of the wireless link...), the operation mode of the packet and/or packet type, and / Or other parameters associated with the transmission of data on a wireless protocol, a wired protocol, or a combination of these protocols. For example, a wired protocol can be used for communication, and a decision can be made to switch to a wireless protocol (or vice versa) during the communication without interruption or termination.

The processor 2320 is operatively connected to the receiver 2304 (and/or the memory 2318) to facilitate the analysis of information about determining whether a specific communication should be sent over a wired protocol or a wireless protocol. The processor 2320 may be a processor dedicated to analyzing and/or generating information communicated to the receiver 2304, a processor controlling one or more components of the system 2300, and/or analyzing and generating information received by the receiver 2304 and A processor that controls one or more components of the system 2300.

The memory 2318 can store protocols associated with data communication rates, operating rates, actions taken to control the communication between the receiver 2304 and the transmitter 2302, etc., so that the system 2300 can use the stored protocols and/or algorithms to achieve Improved communication in wireless networks as described in this article. It should be understood that the data storage (for example, memory) components described herein may be volatile memory or non-volatile memory, or may include both volatile memory and non-volatile memory. As an example and not limitation, non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable PROM (EEPROM), or flash memory body. Volatile memory may include random access memory (RAM), which acts as external cache memory. As an example and not limitation, RAM is available in many forms, such as Synchronous RAM (DRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM) and direct Rambus RAM (DRRAM). The memory 2318 of the disclosed aspect is intended to include (but is not limited to) these and other suitable types of memory.

Figure 24 illustrates a system 2400 for communicating with conventional wired devices over wired or wireless links. The system 2400 is represented as functional blocks, and the functional blocks can be functional blocks representing functions implemented by a processor, software, or a combination thereof (for example, firmware). The system 2400 includes a receiver 2402 that can be configured to receive the operating rate of the communication. This operating rate can be received from, for example, the transmitter or the transmitter host. The operating rate can be set or established in the forward direction and the reverse direction of the communication rate. The system 2400 also includes a wireless communicator 2404 that can be configured to send and/or receive communications over a wireless protocol. wired The communicator 2406 can be configured to send and/or receive communications over a wired protocol.

It should be noted that there may be packets including expanded and/or new packets in the forward and/or reverse direction. For example, in the forward direction, MDDI transmitter information can be added to the packet. This package includes the ability to provide MDDI transmitter-side information to the MDDI client on the receiver side. This information can 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 packet can include about four bytes for the MDDI receiver MAC information and about two bytes for the MDDI receiver client information. However, other extensions It is also possible.

The system 2400 also includes a determiner, which can selectively determine whether to use a wireless communicator to communicate on a wireless protocol or whether to use a wired communicator to communicate on a wired protocol. This determination can be selectively based on various parameters such as the communication operation rate. Other parameters can also be analyzed to make judgments. For example, it can be based on how to send and/or receive specific communications traditionally (e.g., historical analysis), the type of communications (e.g., voice, image, text...), and other related communications, transmitters and/or receivers. Parameters to make a decision.

Figure 25 illustrates an exemplary forward link MDDI data transfer 2500 in a low-burden mode according to the various aspects presented herein. One type of the mode in which the MDDI transmitter 2502 sends data to the MDDI receiver 2504 may be a low-burden mode. In this mode, to optimize the channel allocation time for wirelessly transmitted packets, the channel allocation time is the time it takes for data to be sent from either direction (for example, forward or reverse). The MDDI transmitter 2502 may include part of the user side (C1) 2506, and the MDDI receiver 2504 may include the user side processing (C2) Part of 2508.

The MDDI client (C1) 2506 can place the data to be sent in a buffer (such as on a UWB modem). The data to be sent should exclude unnecessary packets, such as padding packets and round-trip delay packets. As explained in 2512, send the MDDI data to the transmitter MAC 2510. The transmitter MAC 2510 (or UWB MAC) may request at least one CTA from the MDDI transmitter 2502 to the MDDI receiver 2504 in a periodic or continuous manner based on, for example, the size of the buffer.

The transmitter MAC 2510 may request the forward link CTA from the Pico Network Controller (PNC) MAC 2516 at 2514 (e.g., in a periodic manner or a continuous manner). The PNC MAC 2516 can respond to the transmitter MAC 2510 in 2518 with the channel time response code. This response code can indicate whether the data has been successfully communicated. After receiving the successful channel time response code, the transmitter MAC 2510 may send MDDI data to the receiver MAC 2520, as indicated in 2522.

Figure 26 illustrates an exemplary reverse link MDDI data transfer 2600 in a low-burden mode according to the various aspects presented herein. The MDDI receiver 2602 may initiate communication intended for the MDDI transmitter 2604 on the reverse link. The MDDI receiver 2602 may include a part of the client (C2) 2606, and the MDDI transmitter 2604 may include a part of the client (C1) 2608.

The MDDI receiver 2602 may send MDDI data to the receiver MAC 2610, as indicated at 2612. The receiver MAC 2610 may request the reverse link CTA from the PNC MAC 2614 at 2616. The request may correspond to the data that should be sent in the reverse direction. PNC MAC 2614 can use channel time in 2618 Response code to respond. The receiver MAC 2610 can send MDDI data to the transmitter MAC 2622 in the CTA at 2620. As indicated in 2624, the transmitter MAC 2622 may send or give MDDI to the client (C1) 2608 at a certain time before or at substantially the same time before receiving the MDDI data from the receiver MAC 2610 at 2624. material. The MDDI transmitter host 2626 can send and/or receive at least one reverse link package in each frame, as indicated in 2628 and 2630. Can actively send reverse link data without waiting for data requests. The user end can specify the number of bytes it needs to send on the reverse link in the current frame. The host 2626 can allocate the request in the reverse link encapsulation packet accordingly.

Figure 27 illustrates the low-latency mode MDDI connection settings 2700 according to the various aspects proposed in this article. In the low-latency mode, the channel allocation time can be determined based on the interference derived from the data contained in the packets in the forward and reverse directions. The MDDI transmitter 2702 may include parts of the host 2704 and the client (C1) 2706. During the initialization phase, the UWB modem on the transmitter 2702 can send a MAC query at 2710 to the transmitter MAC 2708. A MAC query is a query sent to find the MAC and the rate supported by the traditional meter. The transmitter MAC 2708 can respond to the query at 2712. This response may be a MAC response indicating the rate supported by the MAC re-traditional meter.

The host sends a MAC query packet to query the MAC information on the transmitter/receiver side. The packet length field is a two-byte 16-bit integer without a sign containing the total number of bytes in the specified packet (excluding the packet length field). The packet type field is 2 bytes containing a 16-bit integer without a sign. The packet type 151 identifies the packet as a MAC query packet. use The client ID is a byte containing a 16-bit integer without a sign, which is reserved for the ID of the destination client (C2). The MAC query parameter field is two bytes, and the CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet (including the packet length).

Sender 2702 requests in the forward direction<i>m</i>The CTA in milliseconds is set to 2714 and the request is in the reverse direction<i>n</i>CTA in milliseconds. The expected ratio of traffic in the forward direction and the reverse direction should be<i>m</i>：<i>n</i>. At 2716, a channel time request (CTRq) is sent to the PNC Mac 2718. The channel time response code can be sent in the reverse direction (shown at 2720) and in the forward direction (shown at 2722) and sent to the receiver MAC 2724. The MDDI transmitter 2702 may start the MDDI transmission as described at 2726.

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

In the low-latency mode, reverse link data can be sent during the reserved CTA in the reverse direction. Depending on the arrival time of the reverse link data on the MAC superframe, the transmission can have a maximum delay expressed as follows:<i>T</i>_<i>rl</i>＝<i>ceil</i>[{<i>k</i>*(<i>N/R</i>_<i>1</i>＋<i>RIFS</i>＋<i>H</i>/<i>R</i>_<i>2</i>)＋<i>SIFS</i>＋<i>T</i>_<i>ACK</i>}/<i>n</i>]*<i>T</i>in<i>k</i>It is the average number of retransmissions experienced by the MAC frame.<i>N</i>Is the size of the reverse link packet that should be sent, and<i>n</i>It is the reverse link CTA duration in each super frame.<i>R</i>_<i>1</i>It is the physical layer transmission rate of MDDI data (MAC payload).<i>R</i>_<i>2</i>It is the physical layer transmission rate of PHY, MAC header and preamble.<i>H</i>It is the size of the MAC plus the size of the PHY header plus the size of the preamble.<i>SIFS</i>It is the duration of the interval between short message frames.<i>RIFS</i>It is the duration of the interval between retransmission frames.<i>T</i>_<i>ACK</i>It is the duration of ACK transmission.<i>T</i>Is the duration of the super frame. For the purpose of illustration, suppose the ACK strategy is Imm-ACK. The delay of forward link packets can be determined accordingly<img file="TW200915762A_D0002.tif" />. Given the application delay constraints in the forward link and the reverse link, 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 delay of the forward link packet.

In view of the exemplary systems shown and described, methods that can be implemented according to one or more aspects are provided. Although for the simple purpose of illustration, these methods are shown and described as a series of actions (or functional blocks), it should be understood and understood that these methods are not limited to the sequence of actions, because according to these methods, Some actions may occur in a different order than that shown and described herein and/or at the same time as other actions. In addition, not all the actions described are required to implement the following methods. It should be understood that various actions can be implemented by software, hardware, a combination thereof, or any other suitable components (for example, devices, systems, processes, components) for performing the functionality associated with the actions. It should also be understood that these actions are only used to illustrate the specific aspects presented in this article in a simplified form, and these aspects can be illustrated by a smaller and/or larger number of actions. Those familiar with the art should understand and understand that the method can alternatively be represented as a series of related states or events, such as in the form of a state diagram.

Referring now to FIG. 28, a method 2800 for configuring traditional wired devices to communicate via wired protocols and/or wireless protocols is described. In step 2802, the first part of the user terminal is placed on the MDDI transmitter. MDDI transmitter can be none Online, and can be connected to data sources. The MDDI transmitter may also include an MDDI host, which is connected to or establishes an interface with the user terminal part through, for example, a traditional wired MDDI link.

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

In step 2806, both wired functionality and wireless functionality are provided. This functionality is included on the MDDI receiver so that the MDDI receiver can communicate via wired functionality, wireless functionality, or both.

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

Figure 29 illustrates a method 2900 for determining the operating rate according to one or more disclosed aspects. For example, in wireless MDDI, the MDDI operating rate Partly depends on the rate of the wireless link. The method 2900 for determining the operating rate starts at step 2902, where the host MAC is queried for the available application data rate (for example, the application data rate provided by the MAC). For example, the query can be requested by the MDDI host.

In step 2904, the round-trip delay is measured. The round-trip delay measurement can be used in step 2906 to determine or determine the forward link rate and the reverse link rate. According to some aspects, the round-trip delay measurement can be specified in the wired MDDI protocol that should be used.

In step 2908, the operating rate is calculated. The operating rate can be calculated in part by comparing the forward link rate and the reverse link rate and determining which is the smallest of the two rates. The smallest of these two rates is designated as the operating rate. In some aspects, the smallest of these two rates (forward link rate and reverse link rate) can be further compared with the maximum capability of the MDDI host and the maximum capability of the MDDI client (C1). Assign the minimum or lowest rate based on this comparison as the operating rate.

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

For example, in the above method 2900, the transmitter can query the host MAC through the query module. The transmitter can further measure the round-trip delay, determine the forward link rate and the reverse link rate, and use the measurement module to calculate the operating rate. The transmitter can also send the operating rate to the receiver by using the communication component Device. It should be understood that the above content is only for example purposes, and other components can be utilized in conjunction with one or more aspects proposed in this document.

Referring now to FIG. 30, a method 3000 for communicating in a low-burden mode according to various aspects proposed in this article is described. The forward link is shown on the left side of the diagram and the reverse link is shown on the right side of the diagram.

In step 3002, the forward link data is placed in the buffer. Excluded from the data placed in the buffer may be unnecessary data such as fill packets and/or round-trip delay packets. For example, the data can be placed in the buffer by the MDDI client (C1) on the MDDI transmitter. In step 3004, a one-way CTA is requested (e.g., in a periodic or continuous manner). The UWB MAC can request this information from the MDDI transmitter to the receiver based on, for example, the size of the buffer. In step 3006, forward link data can be sent.

In the reverse direction, the host sends at least one reverse link encapsulation packet for each frame. The user end (for example, the receiver) can specify the number of bytes that should be sent on the reverse link in the current frame. The host (e.g., the sender) can allocate the request in the reverse link encapsulation packet. In step 3008, the reverse link data to be sent is placed in the buffer by, for example, the MDDI client (C2). The buffer can be positioned on the UWB modem of the MDDI receiver. In step 3010, a request for CTA in the reverse direction is sent by, for example, a UWB modem on the MDDI receiver side. The request may be for their CTA in the reverse direction corresponding to the data that should be sent in the reverse direction.

The MDDI client (C2) on the receiver can actively send reverse link data to the client (C1) on the transmitter in step 3012. As explained, in step 3014, the MDDI client (C1) on the transmitter is in a reverse encapsulation packet Send the data it possesses to the MDDI host.

Figure 31 illustrates a method 3100 for communicating in a low-latency mode according to the various aspects presented herein. The forward link is shown on the left side of the diagram and the reverse link is shown on the right side of the diagram. During the initialization phase in low-latency mode, the UWB modem on the transmitter (for example) requests in the forward direction in step 3102<i>m</i>CTA in milliseconds. In step 3104, send in the reverse direction<i>n</i>CTA request in milliseconds. In step 3106, a comparison is made between the CTA and the reverse CTA before receiving in response to the request. The expected ratio of traffic in the forward and reverse directions is<i>m</i>：<i>n</i>. It should be noted that<i>m</i>Milliseconds correspond to MDDI forward link transfer rate R_f-mddiThe duration, and: (<i>m</i>＋<i>n</i>)&lt;<i>T</i>_<i>CTAP</i>&lt;<i>T</i>in<i>T</i>It is the duration of the super frame, which can be determined by the applied delay constraint.

In the reverse direction during the low-latency mode, the reverse link data is sent during the CTA reserved in the reverse direction in step 3108. In step 3110, the duration of the MAC frame can be derived from the applied delay constraints in the forward link and the reverse link. In the following equation,<i>k</i>It is the average number of retransmissions experienced by the MAC frame.<i>N</i>Is the size of the reverse link packet that should be sent, and<i>n</i>It is the reverse link CTA duration in each super frame.<i>R</i>_<i>1</i>It is the physical layer transmission rate of MDDI data (MAC payload).<i>R</i>_<i>2</i>It is the physical layer transmission rate of PHY, MAC header and preamble.<i>H</i>It is the size of the MAC, the size of the PHY header, and the size of the preamble. SIFS is the duration of the interval between short message frames. RIFS is the duration of the interval between retransmission frames.<i>T</i>_<i>ACK</i>Is the duration of the ACK transmission, and<i>T</i>Is the duration of the super frame. For explanatory purposes, assume that the ACK strategy It is Imm-ACK. Various algorithms, methods and/or techniques can be used to determine the delay T of the forward link packet accordingly_f1. Depending on the arrival time of the reverse link data on the MAC superframe, the transmission can have a maximum delay expressed as follows:<i>T</i>_<i>rl</i>＝<i>ceil</i>[{<i>k</i>*(<i>N/R</i>_<i>1</i>＋<i>RIFS</i>＋<i>H</i>/<i>R</i>_<i>2</i>)＋<i>SIFS</i>＋<i>T</i>_<i>ACK</i>}/<i>n</i>]*<i>T</i>

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

When one or more remote user interface client devices (e.g., wireless receivers) wish to associate with a wireless transmitter (e.g., host entity), the method 3200 starts by associating with the host entity in step 3202. The association may include sending a packet requesting the association. The host entity can wirelessly communicate with more than one remote user interface client device at substantially the same time. Once the association with the host entity is established, a capability packet is sent to the host entity in step 3204. The capability package may include one or more capabilities of the remote user interface client device. In step 3206, a status packet is sent to the host entity. The status packet may include link quality information.

According to some aspects, a request for updated status packets is received from the host entity. At roughly the same time as the response is received, the status packet can be updated and sent to the host entity to answer the request. In other aspects, the updated status envelope can be sent periodically or automatically when a status change is detected. Bag.

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

Disassociation from the host entity can also occur when communication between devices should be stopped. If so, the one or more remote user interface client devices can be disassociated from the host entity and enter a disassociation 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, the disassociation response may not be received from the host entity, such as when there is a communication failure or when the link or association between the devices has been broken.

Referring now to FIG. 33, a method 3300 for high-rate wireless digital data communication for user interface data between a transmitter and one or more remote receivers is described. The transmitter initiates the association when it wishes to associate with a specific wireless receiver. For example, if the wireless transmitter is a phone and the wireless receiver is a projector, the phone (for example, the wireless transmitter) will usually start the association process. The transmitter initiated association is similar to the receiver initiated association.

The method 3300 may start at step 3302 when the transmitter associates with one or more remote user interface devices via the transmitter initiation of association. The association may include sending a request to the receiver to establish an association between the devices. The receiver may respond to the request, indicating that the association is possible (for example, the receiver is not associated with another transmitter). At substantially the same time as the device association, a packet including capability information is received from the remote user interface device in step 3304, and link quality information (such as about the reverse link) is received in step 3306. The information can be sent in response to a C2 request packet that can be sent by the wireless transmitter to the receiver to request the receiver to send a client capability packet. The C2 request packet may include packet length, packet type, C2 client ID and C2 flag, and CRC fields. The packet length field is a two-byte 16-bit integer without a sign containing the total number of bytes in the specified packet (excluding the packet length field). The packet type is two bytes containing 16-bit integers without a sign. The packet type 149 identifies the packet as a C2 request packet. The C2 client ID field is a two-byte group containing 16-bit integers without a sign, which is reserved for the ID of C2. The C2 flag field is a byte containing an 8-bit integer without a sign, and it contains a set of flags for requesting information from C2. For example, if the bit is set to 1, 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 the client capability packet from C2. Bit 1 indicates that C1 needs a "client request and status packet" from C2. The CRC field is two bytes containing the 16-bit CRC of all the bytes in the packet (including the packet length).

In some cases, the transmitter may initiate the association, but the receiver may already be associated with a different receiver or may not wish to associate with this transmitter. In this case Next, the client (C2) can send an association rejection packet as a response to the association request (after the power is turned on) when it does not want to associate with the w-MDDI transmitter. The associated rejection packet contains various fields, including packet length, packet type 160, transmitter MAC address, receiver MAC address, reason code, and CRC. The packet length can be two bytes with 16 bits without a sign integer containing the total number of bytes in the specified packet (excluding the packet length field). The packet type can be two bytes containing 16-bit integers without a sign. Packet type 160 identifies the packet as<i>Association rejection packet</i>. The MAC address of the transmitter can be the six-byte MAC address of the W-MDDI transmitter, and the receiver MAC address can be the six-byte MAC address of the W-MDDI receiver. The reason code is a byte (0x1, 0x2, 0x3 or 0x4) indicating the reason for rejection. 0x1 indicates that it has been associated with another transmitter; it can no longer be associated. 0x2 indicates an ongoing association with another transmitter. 0x3 indicates local error and 0x4 is miscellaneous. The CRC is a two-byte group containing 16-bit CRC of all the bytes in the packet (including the packet length).

Another packet that can be sent is the MAC CTA configuration packet 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 and IEEE 802.15.3 MAC. If the MAC protocol allows the transmitter MAC to set the CTA in the reverse direction, the packet will be discarded at the transmitter. Otherwise, it will be forwarded to the receiver. The MAC CTA sets the packet content to include a packet length field, which is a 16-bit integer without a sign and two bytes containing the total number of bytes in the specified packet (excluding the packet length field). The packet type field is two bytes containing a 16-bit integer without a sign. The packet type 152 identifies the packet as a CTA configuration packet. C1 The client ID field is two bytes containing a 16-bit integer without a sign, which is reserved for the host ID-0. The C2 client ID field is a two-byte group containing 16-bit integers without a sign, which is reserved for the ID of C2. The forward CTA parameter is the CTA parameter used for data transmission in the forward direction, and the reverse CTA parameter is the CTA parameter used for data transmission in the reverse direction.

FIG. 34 illustrates an apparatus 3400 for associating an initial device according to various aspects. The device 3400 may be a receiver that is configured to communicate high-rate digital data and is desirably associated with a wireless transmitter or remote host device 3402. The device 3400 may include a memory 3404 that can be configured to store information. The stored information may include the MAC address and/or client ID associated with the device 3400 (as received in the association response packet). For example, the wireless receiver may store the MAC address of the transmitter or remote host device 3402 associated with the device 3400 at substantially the same time as the time associated with a particular wireless transmitter.

The device 3400 may also include a processor 3406 that can be configured to analyze the information stored in the memory 3404. The processor 3406 may further selectively associate the device 3400 with the remote host device 3402. According to some aspects, the processor 3406 may associate the device 3402 with the remote host device 3402 at substantially the same time as receiving the association request packet from the remote host device 3402. However, if no response packet is received from the remote host device 3402 after the predetermined interval and the maximum number of sent association requests has been exceeded, the processor 3406 does not associate the device 3400 with the remote host device 3402.

The device 3400 may further include a communication data component 3408, which can be configured The device MAC statistics are used to update the MAC response packet for transmission to the remote host device 3402. After entering the associated state, the wireless receiver can periodically (such as every<i>mac_response_time</i>Milliseconds) to send a MAC response packet. The host device 3402 can respond by confirming the received packet of the MAC response packet sent by the device 3400. If the device 3400 is at a predetermined time interval (e.g.,<i>mac_response_fail_time</i>If no response is received after the duration of milliseconds), the device 3400 can infer that it has been disassociated from the host device 3402 and stop sending the MAC response packet. The device 3400 and the host device 3402 may become disassociated as described above. According to some aspects, the device 3400 may send a MAC response packet (when specifically requested by the host device 3402 to do so).

The device 3400 and the remote host device 3402 may become disassociated intentionally or unintentionally. For example, the communication link between the device 3400 and the remote user device 3402 can be attributed to a communication failure, the device moving out of each other's range, or the loss of the communication link for other reasons. For example, if a disassociation request packet is received from the remote host device 3402, the processor disassociates the device 3400 from the host device 3402 at substantially the same time as the request is received. In another example, if the status packet is received from the remote host device 3402 in response to the transmitted updated MAC response packet, the processor 3408 will select based on the inference that the device 3400 and the host device 3402 are no longer associated Disassociate.

According to some aspects, the device 3400 can include a display component 3410 that can be configured to compile one or more alternative display information. Alternative display information can be associated with the device 3400. The display component 3410 can be further configured to transmit the one or more alternative display information to the remote host device 3402. For example In other words, if there is an alternative display associated with the wireless receiver, an alternative display capability packet can be sent to the remote host device 3402.

Referring now to FIG. 35, a device 3500 that can be configured to wirelessly communicate high-speed user interface data is illustrated. The device 3500 may include a memory 3502, which may be configured to store information about the identification of the remote user interface device, such as the client ID assigned to the remote device. The processor 3504 can be configured to selectively associate with one or more remote user interface devices based in part on the information stored in the memory 3502. The device 3500 may also include an information component 3506, which may be configured to analyze at least one capability of the one or more remote user interface devices. The capability can be received in the client capability packet. The information component 3506 can be further configured to analyze the link quality information received in the status update packet.

According to some aspects, the device 3500 may include a state timer 3508, 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 3504 can send a subsequent sender association request.

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

Referring now to FIG. 36, a conceptual block diagram of a possible configuration of the terminal 3600 is illustrated. Those who are familiar with this technology will understand that the precise configuration of the terminal 3600 may vary depending on the specific application and the overall design constraints. The processor 3602 can implement the systems and methods disclosed herein.

The terminal 3600 can be implemented by the front-end transceiver 3604 coupled to the antenna 3606. The baseband processor 3608 can be coupled to the transceiver 3604. The baseband processor 3608 can be implemented by a software-based architecture or other types of architectures. The microprocessor can be used as a platform to execute software programs that provide control and overall system management functions in addition to other functions. A digital signal processor (DSP) can be implemented by an embedded communication software layer that executes application-specific algorithms to reduce processing requirements on the microprocessor. The DSP can be used to provide various signal processing functions, such as pilot signal acquisition, time synchronization, frequency tracking, spread spectrum processing, modulation and demodulation functions, and forward error correction.

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

The baseband processor 3608 includes a processor 3602. In the software-based implementation of the baseband processor 3608, the processor 3602 can be a software program running on a microprocessor. However, as those familiar with the art will easily understand, the processor 3602 is not limited to this aspect, and can be implemented by any means known in the art that can perform the various functions described herein, including any hardware Body configuration, software configuration or a combination thereof. The processor 3602 can be coupled to the memory 3612 for storing data.

FIG. 37 illustrates the receiver initiate association procedure 3700 when security is enabled according to the disclosed aspect. The w-MDDI receiver 3704 transmits an association request packet 3706 to the w-MDDI transmitter 3702. At this point, the device is in non-associative state. The w-MDDI receiver 3704 can enter a state of waiting for an association response. The w-MDDI transmitter 3702 can respond with the response packet 3708. If no response is received, many association request packets can be sent (up to the maximum number of retries and before the pre-defined time interval expires). After receiving the association response packet 3708, the client capability packet 3710 is sent from the w-MDDI receiver 3704 to the w-MDDI transmitter. These three packets represent a three-way handshake 3712.

The device can enter the associated state. The device can remain in the associated state until the disassociation request is received/confirmed and/or until no response is received for several link state packets.

According to some aspects, optional mutual authentication/key exchange 3714 may be performed. If there is an available alternative display, the alternative display capability packet 3716 is sent to the w-MDDI transmitter 3702. At 3718, the MAC response packet can be sent to the w-MDDI transmitter.

Figure 38 illustrates the transmitter initiation association procedure 3800 when security is enabled according to the disclosed aspect. The w-MDDI transmitter 3802 transmits a transmitter association request 3806 to the w-MDDI receiver. At this point, the device is in a non-associated state. The device is waiting for an association request. The receiver 3804 can respond to the association request 3808. The w-MDDI transmitter 3802 responds with an association response 3810, and the w-MDDI receiver 3804 sends a client capability packet 3812 (for example, the device is in a state of waiting for client capability). The above four packets are included in the four-way signal exchange 3814.

According to some aspects, optional mutual authentication/key exchange 3816 may be performed. The W-MDDI receiver 3804 can transmit a replacement display capability packet 3818. That After that, the link state response packet 3820 can be transmitted. The w-MDDI transmitter 3802 can provide a transmitter link state packet 3822 to the w-MDDI receiver.

FIG. 39 illustrates the host (transmitter) association state diagram 3900. At 3902, the host is in a non-associated state (for example, there is no association between the host and the client). In order to associate with the client, as indicated by the line 3904, the host sends a request to associate and enters the wait for association request (WAReq) state 3906. According to some aspects, in response to an association request, an association rejection may be received, as indicated at 3908. If the association rejection is received, the host returns to the non-association state 3902.

At roughly the same time as the association request is sent, at 3904, a timer can be started, which indicates the maximum amount of time that the client will be allowed to respond to the request. While waiting for a response from the client, the host can transmit many association requests (for example, retries) up to the maximum number of attempts. The host remains in WAReq state 3906 as long as the timer has not expired and the number of retry attempts has not exceeded the maximum number of retries (MAX_RETRIES), as indicated at 3910. If the timer expires and/or exceeds the maximum number of retry attempts, the host enters the non-associated state at 3912.

In response to the association request, the association request can be received at 3914, and the host moves to the Waiting for Client Capability (WCC) state 3916. According to some aspects, if the association request 3918 is received while the host is in the non-associated state 3902, the host can directly transition from the non-associated state 3902 to the WCC state 3916 (eg, skip the WAReq state 3906).

At roughly the same time as entering WCC state 3916, the host can start a timer to limit the amount of time waiting for a response from the client. As in 3920 As indicated, the host can also send many requests for response to the client capabilities, up to the maximum number of retry attempts (MAX_RETRIES). If the timer expires and/or has exceeded MAX_RETRIES, the host returns to the non-associated state 3902 at 3922.

At approximately the same time as the client capability is received, at 3924, the host enters the associated state 3926. The host can remain in the associated state 3926 until it receives a disassociation request from the user at 3928. At substantially the same time as the disassociation request is received, the host transitions to the unassociated state 3902.

According to some aspects, the timeout 3930 of the link state packet causes the host to move from the associated state 3926 to the non-associated state 3902. In this case, the host has not received the link state packet (MAC response packet) within the duration of mac_response_fail_time milliseconds. Failure to receive a link state packet within a predetermined amount of time indicates that the client is no longer associated with the host. According to some aspects, the host may decide to disassociate (indicated at 3932), and the host transitions from the associated state 3926 to the unassociated state 3902.

Figure 40 illustrates the client association state diagram. At 4002, the client is in a non-associated state. At 4004, the user-side association request is sent, and at 4006, the user-side enters a state of waiting for association response (WAResp). At roughly the same time as the request is sent, at 4004, a timer can be started to allow a limited time interval during which the host waits for an association response. According to some aspects, the user end may enter WAResp state 4006 when 4008 receives a sender association request.

While waiting for the association response, the host can send multiple association requests 4004, up to the maximum number of requests. The host remains in WAResp state 4006, as long as the timer has not expired and the number of retries has not exceeded the maximum number of retries. The number of attempts (MAX_RETRIES), as indicated at 4010. If the timer expires and/or the number of retries exceeds MAX_RETRIES, the host transitions to a non-associated state at 4012.

According to some aspects, an association rejection (indicated at 4014) may be received in response to an association request. The association may be refused when the host is already associated with another client or for other reasons. After receiving the association rejection, the user end enters the non-association state 4002.

The client stays in WAResp state 4006 until the association response is received at 4016. At substantially the same time as when the association response is received, the client enters the association state 4018. The client can remain in the associated state 408 until a disassociation request is received at 4020, until no response is received for a number of link state packets at 4022, and/or until the client (for example, the user) wishes to disassociate from the host at 4024 . If any one of these three events 4020, 4022, 4024 occurs, the user terminal returns to the non-associated state 4002.

FIG. 41 illustrates a system 4100 for wirelessly communicating data at a high rate between a host entity and at least one remote device with wireless MDDI client capability. It should be understood that the system 4100 is represented as including functional blocks, and these functional blocks may be functional blocks representing functions implemented by a processor, software, or a combination thereof (for example, firmware).

The system 4100 includes a logical group 4102, which includes electrical components 4104 for performing a service discovery process to collect information about a plurality of wireless MDDI client-capable devices in a local area. According to some aspects, information about multiple devices with wireless MDDI client capabilities includes string identifiers corresponding to device names, device capabilities, and status indicators. This information is retained locally.

The logical group 4102 also includes an electrical component 4106 for receiving a request associated with at least one of a plurality of wireless MDDI client-capable devices. For example, the request can be received from the user.

In addition, the logical group 4102 includes an electrical component 4108 for determining the security capability of each of a plurality of wireless MDDI client-capable devices and an electrical component 4110 for selectively executing a security association program. For example, the security program can be executed when both devices are security-enabled and security is required for both devices. It also includes an electrical component 4112 for associating with at least one of a plurality of wireless MDDI client-side capable devices.

According to some aspects, the logical group also includes electrical components used to pass messages to the lower layer to obtain a list of devices and electrical components used to receive responses including the list of devices. The logical group also includes an electrical component for transmitting the packet to each of the devices included in the received list and an electrical component for receiving a response containing the string identifier of each of the responding devices .

According to some aspects, the lower layer supports multicast. In this aspect, the logical group includes electrical components for transmitting service query packets to the multicast group to request information from the selected wireless MDDI client-capable device. The multicast group is specified by the multicast address.

In another aspect, the lower layer is wiMedia UWB MAC, and the logical group includes electrical components for receiving application-specific information elements about each of the w-MDDI client-capable devices.

According to some aspects, the lower layer is UDP/IP. In this aspect, the logical group includes electrical components for communicating service query packets to the multicast group on the UDP port. The logical group also includes electrical components used to join the multicast group on the UDP port and electrical components used to receive service responses from each device supporting w-MDDI.

In addition, the system 4100 may include a memory 4114 that stores instructions for executing functions associated with the electrical components 4104, 4106, 4108, 4110, and 4112 or other components. Although shown as being outside the memory 4114, it should be understood that one or more of the electrical components 4104, 4106, 4108, 4110, and 4112 may exist in the memory 4114.

Figure 42 illustrates a system 4200 for wirelessly communicating data at a high rate by a host entity. It should be understood that the system 4200 is represented as including functional blocks, which can be functional blocks representing functions implemented by a processor, software, or a combination thereof (for example, firmware).

The system 4200 includes a logical group 4202, which includes an electrical component 4204 for sending a neighbor list message to the lower layer, and the neighbor list message requests a list of devices in a local area. It also includes an electrical component 4206 for receiving a list of devices in a local area. In addition, the logical group 4202 includes electrical components 4208 for transmitting query packets to each of the devices. An electrical component 4210 for receiving a response including a string identifier of the response device is included. A response is received before the expiration of the predetermined interval.

According to some aspects, the neighbor list message is a "get neighbor list" message, and the list of devices is received from one layer in the "lower-level neighbor list response". According to some aspects, the query packet is "w-MDDI service query" Packet, and the response is a "w-MDDI service response" packet (for example, receiver service discovery). According to other aspects, the query packet is a "w-MDDI host query" packet, and the response is a "w-MDDI host response" packet (for example,'sender service discovery).

If no response is received before the expiration of the predetermined interval, the association is unsuccessful and the previous state is restored. The logical group 4202 also includes electrical components 4212 for associating with the transponder device. According to some aspects, the lower layer supports multicast, and the lower layer is wiMedia UWB MAC and/or UDP/IP. According to some aspects, the logical group 4202 also includes electrical components for performing mutual security authentication.

In addition, the system 4200 may include a memory 4214 that stores instructions for executing functions associated with the electrical components 4204, 4206, 4208, 4210, and 4212 or other components. Although shown as being outside the memory 4214, it should be understood that one or more of the electrical components 4204, 4206, 4208, 4210, and 4212 may be present in the memory 4214.

It should be understood that the aspects described herein can be implemented by hardware, software, firmware, or any combination thereof. When implemented in software, the function can be stored on or transmitted through a computer-readable medium as one or more commands or program codes. Computer-readable media include computer storage media and communication media including any media that facilitates the transfer of computer programs from one location to another. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer. By way of explanation and not limitation, these computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, or may be used to carry or store instructions or data structures The required code components of the form and can be used by general-purpose or special-purpose computers or Any other media accessed by a general-purpose or special-purpose processor. Also, any connection is appropriately referred to as a computer-readable medium. For example, if you use coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave to transmit software from websites, servers, or other remote sources, then coaxial cables, fiber optic cables, etc. Cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwave are included in the definition of media. As used in this article, floppy disks and optical discs include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVD), flexible disks and Blu-ray discs. Disks usually reproduce data magnetically , And optical discs use lasers to optically reproduce data. The combination of the above should also be included in the category of computer-readable media.

General-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices designed to perform the functions described in this article , Discrete gate or transistor logic, discrete hardware components, or any combination thereof to implement or execute various illustrative logics, logic blocks, modules, and circuits described in conjunction with the aspects disclosed herein. The general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in combination with DSP cores, or any other such configuration. In addition, at least one processor may include one or more modules operable to perform one or more of the steps and/or actions described above.

For software implementation, it can be implemented by performing the functions described in this article Modules (for example, programs, functions, etc.) implement the techniques described herein. The software code can be stored in the memory unit and executed by the processor. The memory unit may be implemented in the processor or outside the processor (in this case, the memory unit may be communicatively coupled to the processor via various components known in the art). In addition, at least one processor may include one or more modules operable to perform the functions described herein.

The technology described in this article can be used in various wireless communication systems such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and other systems. The terms "system" and "network" are often used interchangeably. The CDMA system can implement radio technologies such as Universal Terrestrial Radio Access (UTRA) and CDMA2000. UTRA includes broadband-CDMA (W-CDMA) and other variants of CDMA. In addition, CDMA2000 covers IS-2000, IS-95 and IS-856 standards. The TDMA system can implement radio technologies such as the Global System for Mobile Communications (GSM). OFDMA system can implement such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM and other radio technologies. UTRA and E-UTRA are part of the Universal Mobile Telecommunications System (UMTS). 3GPP Long Term Evolution (LTE) is a version of UMTS that uses E-UTRA, which uses OFDMA on the downlink and SC-FDMA on the uplink. UTRA, E-UTRA, UMTS, LTE and GSM are described in documents from an organization named "3rd Generation Partnership Project" (3GPP). In addition, CDMA2000 and UMB are described in documents from an organization named "3rd Generation Partnership Project 2" (3GPP2). In addition, these wireless communication systems may additionally include point-to-point (for example, mobile device pairing Mobile devices) special network systems, which often use unpaired unlicensed spectrum, 802.xx wireless LAN, BLUETOOTH and any other short-range or long-range wireless communication technologies.

In addition, the various aspects or features described herein can be implemented as methods, devices, or products using standard programming and/or engineering techniques. The term "article" when used herein is intended to encompass a computer program that can be accessed from any computer-readable device, carrier, or medium. For example, computer-readable media may include, but are not limited to, magnetic storage devices (for example, hard disks, floppy disks, magnetic stripes, etc.), optical discs (for example, compact discs (CD), digital versatile discs (DVD)) Etc.), smart cards and flash memory devices (for example, EPROM, cards, sticks, key drives, etc.). In addition, various storage media described herein may refer to one or more devices and/or other machine-readable media for storing information. The term "machine-readable medium" may include (but is not limited to) wireless channels and various other media capable of storing, containing, and/or carrying instructions and/or data. In addition, the computer program product may include a computer-readable medium having one or more instructions or program codes operable to enable a computer to perform the functions described herein.

In addition, the steps and/or actions of the method or algorithm described in conjunction with the aspects disclosed in this document can be directly embodied in hardware, a software module executed by a processor, or a combination of both. The software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, scratchpad, hard disk, removable disc, CD-ROM or known in this technology In any other form of storage media. An exemplary storage medium may be coupled to the processor so that the processor can read information from the storage medium or transfer information Write to storage media. In the alternative, the storage medium may be integrated into the processor. In addition, in some aspects, the processor and storage medium may reside in an ASIC. In addition, the ASIC can reside in the user terminal. In the alternative, the processor and the storage medium may reside as discrete components in the user terminal. In addition, in some aspects, the steps and/or actions of the method or algorithm can be stored in a machine readable that can be incorporated into a computer program product as one or any combination or collection of code and/or instructions Media and/or computer-readable media.

Although the foregoing disclosure discusses illustrative aspects and/or aspects, it should be noted that, without departing from the scope of the described aspects and/or aspects as defined by the scope of the additional patent application, it can be carried out in this article Various changes and modifications. Therefore, the described aspect is intended to include all such changes, modifications and changes within the scope of the additional patent application. In addition, although the singular form may be described or claimed for the described aspect and/or the elements of the aspect, unless the restriction on the singular form is clearly stated, the plural form is also contemplated. In addition, unless otherwise stated herein, all or part of any aspect and/or aspect can be utilized in conjunction with all or part of any other aspect and/or aspect.

To the extent that the term "include" is used in the detailed description or the scope of the patent application, the term is intended to be interpreted in a manner similar to the way the term "include" is interpreted as a transition word in the scope of the patent application. Including sexual. In addition, the term "or" means "non-exclusive or" when used in the detailed description of the scope of patent application.

<p>100Systems used to enable traditional line-based devices to communicate wirelessly</p><p>102Transmitter</p><p>104Receiver</p><p>106Data source</p><p>108Interface device</p><p>200Wireless Mobile Display Digital Interface (MDDI) protocol stack</p><p>202Video/Multimedia layer</p><p>204Wireless MDDI (w-MDDI) layer</p><p>206Media Access Control (MAC) layer</p><p>208Physical (PHY) layer</p><p>300Wireless MDDI protocol stack</p><p>302Video/Multimedia layer</p><p>304W-MDDI</p><p>306MAC layer</p><p>308PHY layer</p><p>310User Datagram Protocol (UDP)</p><p>312Internet Protocol (IP)</p><p>400Wireless Transmitter</p><p>402MDDI host</p><p>404Special MDDI Client (C1)</p><p>406Traditional high data rate link</p><p>408Wireless Modem</p><p>500Wireless Transmitter</p><p>502MDDI host</p><p>504Client (C1)</p><p>506High-speed wireless modem</p><p>600Wireless Transmitter</p><p>602Single hardware and/or software entity (w-MDDI transmitter)</p><p>604High-speed wireless modem</p><p>700Wireless Receiver</p><p>702Client (C2)</p><p>704Display</p><p>800Method for w-MDDI association</p><p>900System for service discovery</p><p>902w-MDDI transmitter</p><p>904w-MDDI receiver</p><p>906Parts List Requester</p><p>908Service query identifier</p><p>910Service Capability Notification Program</p><p>912Available Device Requester</p><p>914Host query</p><p>916Availability Notification Program</p><p>1002Application Specifier ID</p><p>1100Application-specific detection information element (AS detection IE)</p><p>1102"Application Specific Request Information" field</p><p>1200Used to transmit high-speed digital data wirelessly by using the receiver to initiate association</p><p>1300Method for high-rate wireless data communication between transmitter and remote receiver</p><p>1400Procedure for mutual authentication and key exchange</p><p>1402w-MDDI transmitter</p><p>1404w-MDDI receiver</p><p>1500Receiver initiates disassociation procedure</p><p>1502w-MDDI transmitter</p><p>1504w-MDDI receiver</p><p>1506Disassociation request packet</p><p>1508Disassociation response packet</p><p>1600A method for the initial disassociation of the receiver between the user device (for example, the receiver) and the host entity (for example, the transmitter)</p><p>1700Sender initiates disassociation procedure</p><p>1702Transmitter</p><p>1706Sender Disassociation Request Packet</p><p>1708Disassociation request</p><p>1710Disassociation response</p><p>1800Method for selective disassociation between transmitter and remote receiver</p><p>1902Wireless Transmitter</p><p>1904Receiver 1 (R1)</p><p>1906Receiver 2 (R2)</p><p>1908Receiver 3 (R3)</p><p>2000table</p><p>2100Systems used to expand the capabilities of traditional wired configurations to allow communication over wireless links</p><p>2102Transmitter</p><p>2104Receiver</p><p>2106Host</p><p>2108Client (C1)</p><p>2110Communication components</p><p>2112Interface device</p><p>2114Client (C2)</p><p>2116Communication components</p><p>2200System for communication via wired and/or wireless architecture</p><p>2202Transmitter</p><p>2204Receiver</p><p>2206Host Components</p><p>2208Client (C1) component</p><p>2210Communication components</p><p>2212Device</p><p>2214Client (C2) Components</p><p>2216Communication components</p><p>2218Query Module</p><p>2220Measurement Module</p><p>2222Notification Program Module</p><p>2224Designator Module</p><p>2226Wired Module</p><p>2228Wireless Module</p><p>2300Used to expand the traditional wired configuration to allow the system to communicate over the wireless link</p><p>2302Transmitter</p><p>2304Receiver</p><p>2306Host</p><p>2308Client (C1)</p><p>2310Communication components</p><p>2312Device</p><p>2314Client (C2)</p><p>2316Communication components</p><p>2318Memory</p><p>2320Processor</p><p>2400System for communicating with traditional wired devices on wired or wireless links</p><p>2402Receiver</p><p>2404Wireless Communicator</p><p>2406Wired Communicator</p><p>2500Exemplary forward link MDDI data transmission</p><p>2502MDDI transmitter</p><p>2504MDDI receiver</p><p>2506MDDI Client (C1)</p><p>2508Client side processing (C2)</p><p>2510Transmitter MAC</p><p>2516Pico Network Controller (PNC) MAC</p><p>2520Receiver MAC</p><p>2600Exemplary reverse link MDDI data transmission</p><p>2602MDDI receiver</p><p>2604MDDI transmitter</p><p>2606Client (C2)</p><p>2608Client (C1)</p><p>2610Receiver MAC</p><p>2614PNC MAC</p><p>2622Transmitter MAC</p><p>2626MDDI transmitter host</p><p>2700MDDI connection setting in low latency mode</p><p>2702MDDI transmitter</p><p>2704Host</p><p>2706Client (C1)</p><p>2708Transmitter MAC</p><p>2714CTA setting</p><p>2718PNC Mac</p><p>2724Receiver MAC</p><p>2800Method for configuring traditional wired devices to communicate via wired and/or wireless protocols</p><p>2900Method for judging operating speed</p><p>3000Method for communication in low-burden mode</p><p>3100Method for communication in low-latency mode</p><p>3200Method for wireless transmission of digital data at high speed</p><p>3300High-speed wireless digital data communication method for user interface data between a transmitter and one or more remote receivers</p><p>3400The device associated with the initial device</p><p>3402Wireless transmitter or remote host device</p><p>3404Memory</p><p>3406Processor</p><p>3408Communication data component</p><p>3410Display Unit</p><p>3500A device that can be configured to wirelessly transmit high-speed user interface data</p><p>3502Memory</p><p>3504Processor</p><p>3506Information component</p><p>3508Status Timer</p><p>3600Terminal</p><p>3602Processor</p><p>3604Front-end transceiver</p><p>3606antenna</p><p>3608Baseband processor</p><p>3610User Interface</p><p>3612Memory</p><p>3700Receiver Start Associated Program</p><p>3702w-MDDI transmitter</p><p>3704W-MDDI receiver</p><p>3706Association Request Packet</p><p>3708Associated Response Packet</p><p>3710Client Capability Packet</p><p>3712Three-way handshaking</p><p>3714Mutual authentication/key exchange</p><p>3716Replacement Display Capability Packet</p><p>3800Sender start associated program</p><p>3802w-MDDI transmitter</p><p>3804Receiver</p><p>3806Sender association request</p><p>3808Association Request</p><p>3810Related response</p><p>3812Client Capability Packet</p><p>3814 Four-way handshaking</p><p>3816Mutual authentication/key exchange</p><p>3818Replacement Display Capability Packet</p><p>3820Link status response packet</p><p>3822Transmitter Link State Packet</p><p>3900Host (transmitter) association status diagram</p><p>3902non-associated state</p><p>3904line</p><p>3906Waiting for association request (WAReq) status</p><p>3916Waiting for client capability (WCC) status</p><p>3918Association Request</p><p>3926association status</p><p>3930Timeout</p><p>4006Waiting for association response (WAResp) status</p><p>4018association status</p><p>4020Event</p><p>4022Event</p><p>4024Event</p><p>4100System for transmitting data wirelessly at a high rate between the host entity and at least one remote device with wireless MDDI client capability</p><p>4102Logical Group</p><p>4104The electrical components used to perform the service discovery process to collect information about multiple wireless MDDI client-capable devices in a local area</p><p>4106An electrical component used to receive a request associated with at least one of a plurality of wireless MDDI client-capable devices</p><p>4108Used to determine the security capability of each of a plurality of wireless MDDI client-capable devices</p><p>4110Electrical components used to selectively execute safety-related procedures</p><p>4112For electrical components associated with at least one of a plurality of wireless MDDI client-capable devices</p><p>4114Memory</p><p>4200System for wireless transmission of data by the host entity at high speed</p><p>4202Logical Group</p><p>4204Electronic components used to send neighbor list messages to lower layers</p><p>4206Electrical components used to receive a list of devices in a local area</p><p>4208Electrical components used to transmit query packets to each of the devices</p><p>4210An electrical component used to receive a response including a string identifier of the response device</p><p>4212For electrical components associated with response devices</p><p>4214Memory</p>

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

Figure 2 illustrates wireless MDDI protocol stacking.

Figure 3 illustrates another wireless MDDI protocol stack.

Figure 4 illustrates a wireless transmitter according to one or more aspects.

Figure 5 illustrates another wireless transmitter including a co-located MDDI host and client (C1).

Figure 6 illustrates another example of a wireless transmitter.

Figure 7 illustrates a wireless receiver according to the disclosed aspect.

Figure 8 illustrates the method used for w-MDDI association.

Figure 9 illustrates a system for service discovery according to the disclosed aspect.

Figure 10 illustrates the application specific IE (ASIE) format.

Figure 11 illustrates the application-specific detection information element (AS detection IE) in wiMedia MAC.

Figure 12 illustrates a method for wirelessly communicating high-rate digital data by using a receiver to initiate association.

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

Figure 14 illustrates the procedure for mutual authentication and key exchange.

Figure 15 illustrates the receiver's initial disassociation procedure.

Figure 16 illustrates the method used to initiate disassociation of the receiver between the user device and the host entity.

Figure 17 illustrates the sender's initial disassociation procedure.

Figure 18 illustrates the selective release between the transmitter and the remote receiver The method of association.

Figure 19 illustrates a single wireless transmitter associated with multiple wireless receivers according to the disclosed aspect.

Figure 20 illustrates an example device association table.

Figure 21 illustrates a system for extending the capabilities of a traditional wired configuration to allow communication over a wireless link.

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

Figure 23 illustrates another aspect of the system for extending the traditional wired configuration to allow communication over a wireless link.

Figure 24 illustrates a system for communicating with conventional wired devices via wired links or wireless links.

Figure 25 illustrates an exemplary forward link MDDI data transfer in a low-burden mode according to the various aspects presented herein.

Figure 26 illustrates exemplary reverse link MDDI data transfer in a low-burden mode according to the various aspects presented herein.

Figure 27 illustrates the low-latency mode MDDI connection settings according to the various aspects proposed in this article.

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

Figure 29 illustrates a method for determining the operating rate based on one or more of the disclosed aspects.

Figure 30 illustrates a method of communicating in a low-burden mode according to the various aspects proposed in this article.

Figure 31 illustrates the communication in the low-latency mode according to the various patterns proposed in this article. The method of faith.

Figure 32 illustrates a method for wirelessly transmitting digital data at a high rate, which can be initiated by the receiver.

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

FIG. 34 illustrates the device associated with the initial device according to various aspects.

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

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

Figure 37 illustrates the receiver initiating association procedure when security is enabled according to the disclosed aspect.

Figure 38 illustrates the transmitter initiating association procedure when security is enabled according to the disclosed aspect.

Figure 39 illustrates the host association state diagram.

Figure 40 illustrates the client association state diagram.

Figure 41 illustrates a system for wirelessly communicating data at a high rate between a host entity and at least one remote device with wireless MDDI client capability.

Figure 42 illustrates a system for wirelessly communicating data at a high rate by a host entity.