Wireless architecture for traditional wire based protocol

WIRELESS ARCHITECTURE FOR TRADITIONAL WIRE BASED PROTOCOL

FIELD OF THE INVENTION The present invention relates generally to communication systems, and more particularly to enabling conventional wire-based devices to communicate over wireless links and/or wired links.

<b><u>Related applications</u></b>

This application claims priority to U.S. Provisional Application No. 60/951,919, "WIRELESS ARCHITECTURE FOR A TRADITIONAL WIRE-BASED PROTOCOL," filed on July 25, 2007, which is incorporated herein by reference.

<b><u>background</u></b>

Wireless networking systems are used by many to communicate anywhere a user may be located at a particular time (eg, home, office, travel destination, etc.). Wireless communication devices have become smaller and more powerful (eg, increased functionality and/or applications, greater memory capacity) while improving portability and convenience to meet the needs of users. Users have found many uses for wireless communication devices, including cell phones, personal digital assistants (PDAs), and the like. For example, a wireless communication device may include functionality for capturing and processing images (eg, still images, moving pictures, video games, etc.).

Applications and/or functions operating using very high data rates may have high power requirements and/or high current levels. Such power requirements and/or current levels may readily be feasible for devices that communicate using wired protocols. However, wireless communication systems may not have the ability to operate using high data rates. Accordingly, the communication that the user wishes to transmit and/or receive may be restricted in some cases.

Some devices have conventionally only operated with a wired capacity, such as, for example, a mobile display digital interface (MDDI). Thus, a user with such a device may not be able to communicate while on the go (eg, traveling or on the move) and may need to pay additional fees to obtain a wireless device, which may not be possible. . In some situations, a user may decide to operate two devices (one with wired capability and one with wireless capability) to get the benefit of both devices. However, not only the cost associated with the two devices, but also managing both devices may place an excessive burden on the user.

The following description sets forth a simplified summary of one or more features in order to provide a basic understanding of the features of the invention. This Summary is not an exhaustive overview of all features contemplated, and is intended to neither identify key or key constituents of all features nor delineate the scope of any or all features. Its sole purpose is to present some concepts of one or more features in a simplified form as a prelude to the later disclosed embodiments.

In accordance with one or more features and corresponding disclosures, various features are described in connection with service discovery between a wireless MDDI (w-MDDI) host and a w-MDDI client for devices to associate with and utilize each other's functionality. Service discovery may be initiated by the host and/or the client. Service discovery is performed through interaction with an underlying bearer protocol, which may be wiMedia UWB MAC and/or UDP/IP or may support multicasting. Optional mutual authentication may be performed prior to device association.

One aspect relates to a method for wirelessly communicating data between a host entity and at least one remote wireless MDDI client capable device at high speed. The method includes performing a service discovery process to obtain information related to a plurality of wireless MDDI client capable devices in a local area and receiving an instruction to associate with at least one of a plurality of wireless MDDI client capable devices. The method also includes determining security functions of each of the plurality of wireless MDDI client capable devices and optionally performing a security association procedure. Furthermore, the method includes associating with at least one of a plurality of wireless MDDI client capable devices.

Another aspect relates to a wireless communication device including a memory and a processor. The memory holds instructions related to performing a service discovery process to gather information regarding a plurality of wireless MDDI client capable devices in the local area and receiving a request to associate with at least one of the plurality of wireless MDDI client capable devices . The memory also retains instructions for determining respective security functions of the plurality of wireless MDDI client capable devices, performing a security association procedure, and associating with at least one of the plurality of wireless MDDI client capable devices. The processor is coupled to the memory and configured to execute instructions held in the memory.

A further feature relates to a wireless communication device that wirelessly communicates data at high speed. The apparatus includes means for performing a service discovery process to collect information regarding a plurality of MDDI client capable devices in a local area and means for receiving a request to associate with at least one of a plurality of wireless MDDI client capable devices. . The apparatus also provides means for determining a security function of each of a plurality of wireless MDDI client capable devices, means for selectively performing a security association procedure, and means for associating with said at least one device of a plurality of wireless MDDI client capable devices. includes means.

Another aspect relates to a computer program product comprising a computer-readable medium. The computer-readable medium includes a first set of codes for causing 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 codes for causing a computer to receive an instruction to associate with at least one of a plurality of wireless MDDI client capable devices and for causing the computer to determine a security function of each of a plurality of wireless MDDI client capable devices. and a third set of codes. Furthermore, the computer-readable medium includes a fourth set of codes for causing a computer to perform a security association process and a fifth set of codes for causing a computer to associate with the at least one of a plurality of wireless MDDI client capable devices. do.

Another aspect relates to at least one processor configured to communicate data at high speed between a host entity and at least one remote wireless MDDI client capable device. The processor is configured to: 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 second module for receiving an instruction to associate with at least one of the plurality of wireless MDDI client capable devices. Includes 2 modules. The processor also includes a third module for determining a security function of each of the plurality of wireless MDDI client capable devices. Furthermore, the processor includes a fourth module for selectively performing a security association procedure and a fifth module for associating with at least one of the plurality of wireless MDDI client capable devices.

Another aspect relates to a method for wirelessly communicating data with a host entity at high speed. The method includes sending a neighbor list message to a lower layer requesting a list of devices in the local area and receiving a list of devices in the local area. The method also includes sending a host query packet to each of the devices, receiving a response comprising a string identifier for the responding device, and optionally associating with the responding device. A reply 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 configured to execute instructions held by the memory. The memory holds instructions for sending neighbor list messages to lower layers. The Neighbor List message requests a list of devices in the local area. The memory also holds instructions for receiving a list of devices in the local area and sending a host query packet to each of the devices. Further, the memory retains instructions for receiving and optionally associating with the responding device a response comprising a string identifier for the responding device. A response is received before the expiration of the predetermined interval.

Another feature relates to a wireless communication device that wirelessly communicates data at high speed. The apparatus includes means for sending a neighbor list message to a lower layer and means for receiving a list of devices in a local area. The Neighbor List message requests a list of devices in the local area. The apparatus also includes means for sending a host query packet to each of the devices and means for receiving a response comprising a string identifier for the responding device. The response is received prior to expiration of the predetermined interval. Means for associating with the responding device are also included.

Another aspect relates to a computer program product comprising a computer-readable medium. The computer-readable medium includes a first set of codes for causing a computer to send a neighbor list message to a lower layer. The Neighbor List message requests a list of devices in the local area. The computer-readable medium also includes a second set of codes for causing a computer to receive a list of devices in the local area and a third set of codes for causing the computer to send a host query packet to each of the devices. It also includes a fourth set of codes for causing the computer to receive a response comprising a string identifier for the responding device and a fifth set of codes for causing the computer to associate with the responding device. The response is received prior to expiration of the predetermined interval.

Another aspect relates to at least one processor configured to communicate data at a high speed. The processor includes a first module for sending a neighbor list message to a lower layer and a second module for receiving a list of devices in the 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 comprising a string identifier for the responding device. The response is received prior to expiration of the predetermined interval. The processor also includes a fifth module for selectively associating with the responding device.

For the carrying out of the foregoing and related purposes, one or more embodiments incorporate the features fully disclosed herein and specifically recited in the claims. The following embodiments and the accompanying drawings set forth in detail some illustrative features of one or more embodiments. These features represent, however, only a few of the various ways in which the principles of various embodiments of the invention may be employed. Other advantages and novel features will become apparent from the following detailed description when considered in conjunction with the drawings, and the disclosed features are intended to include all such features and their equivalents.

1 is a block diagram of a system for enabling a conventional wire-based device to communicate wirelessly; 2 is a diagram illustrating a wireless MDDI protocol stack; 3 shows another wireless MDDI protocol stack; 4 illustrates a wireless transmitter in accordance with one or more aspects. Figure 5 shows another radio transmitter comprising a co-located MDDI host and client C1; Fig. 6 is a diagram showing another example of a radio transmitter; 7 illustrates a wireless receiver in accordance with features disclosed herein; 8 shows a method for w-MDDI association. 9 illustrates a system for service discovery in accordance with features disclosed herein; 10 is a diagram illustrating an application specific IE (ASIE) format; 11 is a diagram illustrating an application specific probe information element (AS probe IE) of wiMedia MAC; 12 illustrates a method for wirelessly communicating high-speed digital data using receiver-initiated association. 13 illustrates a method for high-speed wireless data communication between a transmitter and a remote receiver; Fig. 14 is a diagram showing a procedure for mutual authentication and key exchange; 15 illustrates a receiver-initiated disassociation procedure; Fig. 16 shows a method for receiver-initiated disassociation between a user device and a host entity; 17 illustrates a transmitter-initiated disassociation procedure. 18 illustrates a method for selective disassociation between a transmitter and a remote receiver; 19 illustrates one radio transmitter associated with a plurality of radio receivers in accordance with features disclosed herein; 20 is a diagram illustrating an exemplary device association table. Fig. 21 shows a system for extending the functionality of a conventional wired configuration to enable communication over a wireless link; 22 illustrates a system for communicating over a wired and/or wireless architecture; 23 is a diagram illustrating another feature of a system for extending a conventional wired configuration to enable communication over a wireless link. 24 is a diagram illustrating a system for communicating with a conventional wired device over a wired link or a wireless link. 25 illustrates an exemplary forward link MDDI data transmission in a low overhead mode in accordance with various features presented herein. 26 illustrates an exemplary reverse link MDDI data transmission in a low overhead mode in accordance with various features presented herein. 27 is a diagram illustrating a low latency mode MDDI connection establishment in accordance with various features presented herein. 28 illustrates a method for configuring a conventional wired device to communicate via a wired protocol and/or a wireless protocol. 29 illustrates a method for determining an operating speed in accordance with one or more features disclosed herein. 30 illustrates a method for communicating in a low overhead mode in accordance with various features disclosed herein. 31 illustrates a method for communicating in a low latency mode in accordance with various features disclosed herein. 32 illustrates a method for wirelessly communicating digital data at high speed, which may be initiated by a receiver. 33 illustrates a method for high-speed wireless digital data communication between one or more remote receivers and transmitters for user interface data. 34 is an illustration of an apparatus for initiating device association in accordance with various aspects of the present invention. 35 depicts an apparatus that may be configured to wirelessly communicate high-speed user interface data. Fig. 36 is a conceptual block diagram of a possible configuration of a terminal; 37 illustrates a receiver initiated association procedure when security is enabled in accordance with features disclosed herein; 38 illustrates a transmitter-initiated association procedure when security is enabled in accordance with features disclosed herein; 39 is a host association state diagram; 40 is a client association state diagram. 41 depicts a system for wirelessly communicating data at high speed between a host entity and at least one remote wireless MDDI client capable device. 42 illustrates a system for wirelessly communicating data with a host entity at high speed;

Various features are disclosed with reference to the drawings. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more features. It will be evident, however, that such feature(s) may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing these features.

As used herein, the terms "component," "module," "system," and the like are intended to refer to a computer-related entity: hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. Illustratively, both an application running on a computing device and the computing device may be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Additionally, these components may execute from various computer-readable media having various data structures stored thereon. Such a component may be, for example, a signal having one or more data packets (eg, one component that interacts with another component on a local system, distributed system and/or network, just as the Internet interacts with other systems via signals). may communicate in a local and/or remote process manner depending on the data from

Furthermore, various features are described herein in the context of a mobile device. A mobile device is a system, a subscriber unit, a subscriber station, a mobile station, a mobile appliance, a wireless terminal, a node, a device, a remote station, a remote terminal, an access terminal, a user terminal, a terminal, a wireless communication device, a wireless communication apparatus, a user agent, a user It may also be called a device or user equipment (UE), and may include some or all of their respective functions. Mobile devices include cell phones, cordless phones, Session Initiation Protocol (SIP) phones, smart phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), laptops, handheld communication devices, handheld computing devices, satellite radios, It may be a wireless modem card and/or other processing device for communicating via a wireless system. Furthermore, various features are described herein in connection with a base station. A base station may be used to communicate with wireless terminal(s) and may also be referred to as an access point, node, Node B, e-NodeB, e-NB or some other network entity, and may provide some or all of the functionality of each of these. may include

Various features or aspects will be presented through a system that may include a number of devices, components, modules, and the like. It should be understood that these various systems may include additional devices, components, modules, etc. and/or may not include some of the devices, components, modules, etc. discussed with respect to the drawings. Combinations of these approaches may also be used.

Referring now to the drawings, FIG. 1 shows a block diagram of a system 100 for enabling a conventional wire-based device to communicate wirelessly. Various features disclosed herein may be applied to universal wireless video, distributed MAC, distributed resource, peer-to-peer wireless MAC, and the like. System 100 includes a transmitter 102 in wired and/or wireless communication with a receiver 104 . Transmitter 102 and receiver 104 may be components that conventionally communicate via wire-based protocols. Although system 100 may include multiple transmitters 102 and receivers 104, one transmitter 102 is shown for transmitting communication data signals to one receiver 104 for simplicity.

Transmitter 102 and receiver 104 may be mobile display digital interface (MDDI) devices. In the detailed description that follows, various features are disclosed in the context of an MDDI device and/or an Institute of Electrical and Electronics Engineers (IEEE) 802.15.3 medium access control (MAC) layer. Those skilled in the art will readily appreciate that these features are similarly applicable to use in a variety of other conventional wire-based protocols. Accordingly, it should be understood that all references to MDDI and/or IEEE 802.15.3 MAC are intended only to describe features of the invention, which may be applied to various scopes.

The communication sent from the transmitter 102 to the receiver 104 is referred to as the forward link (eg, data from the host to the client travels in the forward direction), and the communication sent from the receiver 104 to the transmitter 102 is referred to as the forward link. is referred to as a reverse link (eg, data from a client to a host travels in the reverse direction).

Information transmitted over an MDDI link (eg, forward link, reverse link) is grouped into packets. A plurality of packets are grouped together into sub-frames and the plurality of sub-frames constitute a media frame. Each sub-frame begins with a special packet called a Sub-Frame Header Packet. Reverse link packet transmission is not controlled by the host. Whenever the w-MDDI receiver wants to transmit a packet on the reverse link, the receiver directly transmits the packet to the w-MDDI transmitter via the underlying wireless MAC.

The transmitter 102 may be coupled to a data source 106 (eg, storage, memory, etc.) and the receiver 104 may be coupled to an interface device 108 , such as a display. According to some features, one transmitter 102 may be associated with a plurality of receivers 104 .

According to some features, a transmitter is an MDDI-host that it wishes to associate with one or more MDDI-clients (eg, receiver 104 ). The term "host" is used interchangeably herein with the terms "transmitter" and/or "device" depending on the context in which the term is used. Furthermore, the term "client" is used interchangeably herein with the terms "receiver" and/or "device" depending on the context in which the term is used.

When the MDDI-Host wants to associate with the MDDI-Receiver to wirelessly communicate data between devices at high speed, the host performs a service discovery process. The service discovery process requests information about a plurality of wireless MDDI client capable devices within a local area. During the service discovery process, the w-MDDI host receives information about a number of wireless w-MDDI client capable devices. The information includes a device name, a string identifier corresponding to a function and status indication of the device. This information may be held locally on the w-MDDI host.

According to some features, during the service discovery process, the w-MDDI host sends a message to the lower layer to obtain a list of devices in the local area supporting w-MDDI. The lower layer responds with a list of devices and the w-MDDI host sends a packet to each device included in the received list. Devices wishing to participate transmit a response containing a string identifier for each of the responding devices.

After the service discovery process, the w-MDDI host determines the security capabilities of each wireless w-MDDI client capable device (eg, is client security enabled, or is the client requesting security). The w-MDDI host may present a list of devices and the user may select one or more of the devices. After receiving the selection, the w-MDDI host (if necessary) optionally performs a (mutual) security association procedure and associates with one or more of the wireless MDDI client capable devices.

According to some features, the lower layer supports multicast. If multicast is supported, the w-MDDI host may send a service query packet to the multicast group to request information from the selected wireless MDDI client capable device, the multicast group being specified by the multicast address.

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

According to some features, a w-MDDI client (eg, receiver 104 ) may initiate an association with a w-MDDI host (eg, transmitter 102 ) to wirelessly communicate data at high speed. . The w-MDDI client may transmit a neighbor list message to a lower layer. The Neighbor List message requests a list of devices in the local area. According to some features, the lower layer may support multicasting. According to some features, the lower layer is wiMedia UWB MAC and/or UDP/IP.

Upon receiving a list of devices in the local area (in response to the Neighbor List message), the w-MDDI client sends a host query packet to each device. In response to this message, each device sends a reply containing a string identifier for the replying device. The reply must be received before the expiration of the predetermined interval. The w-MDDI client optionally associates with at least one of the responding devices. If a response is not received before the expiration of the predetermined interval, the association is unsuccessful and the w-MDDI client reverts to its previous state (eg, the state of the w-MDDI client before the association process was started).

Various features disclosed herein may maintain the link and packet structure of MDDI such that advantageous features of MDDI (eg, partial screen updates, user-data packets, control and status packets, etc.) may be maintained. Furthermore, the MDDI protocol may run on a high-speed wireless AMC, which provides peer-to-peer communication. Furthermore, wireless MDDI does not interfere with the functioning of wireless MAC.

2 shows a wireless MDDI protocol stack 200 . The wireless MDDI protocol is generic and can operate in a variety of high-speed wireless technologies. Examples of high-speed wireless technologies include WiMedia Ultra-Wide Band (UWB), Wifi, 1xEVDO, and the like. As shown in the vertical stack 200 , the video/multimedia layer 202 may run on a Wireless MDDI (w-MDDI) layer 204 . Also included is the lower MAC layer 206, which may be 802.11, wiMedia UWB MAC, 802.15.3 UWB MAC, universal high-speed wireless MAC, and the like. The MDDI protocol stack 200 also includes a physical (PHY) layer 208, which may be 802.11, wiMedia UWB, a general purpose high speed wireless PHY, or the like.

The MAC layer 206 and corresponding PHY layer 208 may be any general purpose high speed interface. The illustrated MDDI protocol stack 200 operates on a general purpose high-speed L2, which is a generic term for MAC and link layers in a wireless communication network.

3 shows another wireless MDDI protocol stack 300 . This figure shows the operation of wireless MDDI (W-MDDI) over UDP (User Datagram Protocol) over IP (Internet Protocol), which is another mode in which w-MDDI can operate. A video/multimedia layer 302 is included in the protocol stack 300 . Because W-MDDI 304 is general-purpose, it can run on L2 (MAC layer 306 and PHY layer 308), or other layers (eg, L3, L4). As shown, the W-MDDI 304 is implemented similarly to the application layer.

In this figure, W-MDDI 304 operates over UDP 310 and IP 312, which can be used with media applications (eg, media-players, Voice over Internet Protocol (VoIP), etc.) or real-time client protocols. similar. By having the UDP layer 310 and the IP layer 312, the client and the host can be connected through an Internet connection or other type of connection even though they exist in separate locations. For example, the display may be located in Paris, France, and the host may be located in Dallas, Texas. W-MDDI may be used to transmit a display (eg, multi-media data) to a host over the Internet (or vice versa). This operation may be similar to a remote desktop application, but the illustrated protocol 300 may allow the host to drive communication (eg, display) to the client.

The radio channel can cause packet errors. In the wireless MDDI architecture disclosed herein, it is assumed that the underlying lower layer (eg, wireless MAC) provides a reliability mechanism, such as retransmission of packets, to mitigate the application packet error rate experienced by wireless MDDI. Accordingly, additional reliability mechanisms of the wireless MDDI layer are not discussed herein. However, according to some features, a reliability mechanism may exist in the wireless MDDI layer.

According to some features, when the lower lower layer is UDP/IP, w-MDDI is registered on the standard UDP port WMDDI_UDP_CONTROL_PORT. WMDDI also opens the UDP port WMDDI_UDP_DATA_PORT for data traffic. A w-MDDI transmitter/receiver capable device may join the WMDDI_CONTROL_MULTICAST group with the multicast IP address WMDDI_CONTROL_MULTICAST_IP.

4 illustrates a wireless transmitter 400 in accordance with one or more aspects. The wireless transmitter 400 may be configured to communicate high-speed data, such as digital data. The various wireless systems disclosed herein may include a wireless transmitter and a wireless receiver. The wireless transmitter 400 may include an MDDI host 402 and a special MDDI client (C1; 404). The MDDI client is part of the conventional MDDI client, not all of the conventional MDDI client. The MDDI client (C1) 404 may not be associated with a display or device. Host 402 and client C1 404 may be connected by a conventional high data rate link 406 (eg, an MDDI link). A module comprising a client C1 404 may communicate via a wireless modem 408 (eg, an ultra wide band modem comprising a UWB MAC and a UWB PHY). According to some features, the wireless modem 408 may be any high-speed modem. Host 402 and client C1 404 may be operationally connected with an existing wired link (eg, an MDDI link or a link configured to support high-speed data). According to some features, once the client (C1) 404 and the modem 408 are connected to a wired link, the host 402 may require an upgrade to handle the wireless functionality disclosed in more detail below. The configuration shown in FIG. 4 may be referred to as a "Type A" w-MDDI transmitter.

5 shows another wireless transmitter 500 comprising a co-located MDDI host 502 and a client C1 504 . According to some features, the host 504 and the client C1 504 may be co-located in the same software and/or hardware module. Host 504 and client C1 504 may be coupled to high-speed wireless modem 506 . The configuration shown in FIG. 5 may be referred to as a "Type B" w-MDDI transmitter.

Another example of a wireless transmitter 600 is shown in FIG. 6 , where the host and C1 are integrated (or reduced) into a single hardware and/or software entity 602 (w-MDDI transmitter). A high-speed wireless modem 604 is included to facilitate wireless communication. The configuration shown in FIG. 6 may be referred to as a "Type C" w-MDDI transmitter.

Referring to FIG. 7 , a wireless receiver 700 in accordance with features disclosed herein is shown. The wireless receiver 700 includes an MDDI client processing (C2; 702) that can be coupled with several devices and a display 704 (only one display is shown for simplicity). Client C2 702 may be configured to process and generate high-speed digital data packets. According to some features, the client C2 702 does not have a physical layer of the MDDI stack. According to various features, one MDDI transmitter may be connected to several MDDI receivers.

On the reverse link, an MDDI data packet may be generated by the receiver C2 700 . The MDDI data packet may be transmitted via a UWB modem to a transmitter (eg, Type A w-MDDI transmitter 400, Type B w-MDDI transmitter 500, and/or Type C w-MDDI transmitter 600). have.

The w-MDDI host/transmitter is in the transmission of a lower layer query packet (e.g., MAC Query packet) to obtain lower layer information (e.g., MAC information such as MAC retransmission, frame error rate, etc.) A lower lower layer (eg, MAC layer) may be periodically queried. The host can feed this information back to the application so that the application can step up/step down its data rate.

A MAC query is a query to determine the rates supported by MAC and retransmission statistics. The MAC query message contains a message ID which is 2 bytes containing a 16-bit unsigned integer. A message ID of 0x0 means that the packet is a MAC query packet. In addition, MAC Query Parameters of 2 bytes are included.

8 shows a method 800 for w-MDDI association. Methods that may be implemented in accordance with the disclosed subject matter will be better understood with reference to various flowcharts. Although the methodology has been shown and disclosed as a series of blocks for the sake of simplicity of description, the claimed subject matter is the number of blocks as some blocks may occur in a different order than those shown and disclosed herein and/or may occur substantially concurrently with other blocks. or order is not limited. Furthermore, not all illustrated blocks may be required to implement the methods disclosed herein. It is to be understood that the functionality associated with a block may be implemented by software, hardware, a combination thereof, or any other suitable means (eg, device, system, process, component). Additionally, it should be understood that the methods disclosed hereinafter and throughout this specification may be stored on an article of manufacture to facilitate transmitting and transferring such methods to various devices. Those skilled in the art will appreciate that a method may optionally be represented as a series of interrelated states or events, such as a state diagram.

Method 800 is disclosed from the perspective of a user (eg, user device, cell phone, laptop, etc.). Method 800 begins at 802 when a user having a host device initiates a search for a w-MDDI client-capable device. This search may be initiated when the user enters an area (eg, a room, building, etc.) and initiates a search for a w-MDDI client capable device. Various mechanisms may be used to enable a user to initiate a search. For example, the user interface may provide functionality to request a navigation (eg, a button on a device, an icon on a display screen, etc.).

At 804 , the host retrieves the list of w-MDDI client-capable devices. According to some features, the client-capable devices include strings corresponding to their names, their capabilities (eg, screen resolution, whether compressed and/or uncompressed packets are accepted, security capabilities, etc.), status indications, as well as other information. have an identifier. Examples of the appearance of device information include "Room L-601 Projector Display Unassociated/Available," "Living room Home Theater Plasma display Associated/Unavailable," "ABC PC Keyboard Unassociated/Unavailable", and the like. According to some features, the w-MDDI transmitter may maintain (eg, in a computer-readable storage medium) a list of w-MDDI receivers that have responded to the discovery request.

At 806 , a device to be associated is selected. presenting a list of devices on a display and allowing the user to select a device (e.g., highlighting the device name and pressing enter); providing a verbal command (e.g., device A variety of techniques may be used, such as dictating a name or other identifier associated with the desired device. In another example, the user may press a button on the host's user interface to trigger device selection.

At 808 , an "Association Denied" message may be received. These messages are only received if the association does not complete successfully, as indicated by the dotted line. The message may be displayed on a user interface (eg, a screen) or displayed via other means (eg, audibly through a speaker). This message may be received if the desired device is already associated with another host and thus rejects the association.

An "association denied" message may be received if the device is already connected to another host. According to some features, this message may be received if the device is "stuck" or unable to disassociate from its previous host. In such a situation, if the user is in control of the device and is a true user (eg, unless such display is being used by any other user), the user can use various techniques (eg, reset the device) to allow the device to can be forced to disassociate from the previous host of For example, the user may press a button on the device's user-interface and retry to initiate the association.

Upon successful completion of the association process, both the host and w-MDDI client-capable device may provide various means to establish association. Host/client authentication may involve key exchange or other types of security procedures. For example, both the host and w-MDDI client-capable device can render a (short) common number on their respective displays.

At 810 , a message regarding association may optionally be received, as indicated by a dotted line. Various scenarios of association can occur. For example, if the association is not successful, the host display or device display (or other means of providing information (eg, visual, sound)) may render a message corresponding to "Association Unsuccessful". have. In this situation, the timer associated with the association procedure expires. When the timer times out, the device returns to the state it was in before the association process was initiated (eg, as if there was no association attempt).

Another type of message may be about a security-function. For example, one or both of the host and the device are not security-capable, but may be accepted by both devices to proceed with insecure communication. This may happen if one of the devices does not have a security function. In such a situation, a message may be provided that is displayed on one or both of the devices (host and client) stating that the communication is not secure. According to some features, information about proceeding with non-secure communication may be negotiated during an initial function exchange (eg, when a device list is received at 804 ). In this situation, if the user wants to confirm the association (eg, override the non-secure communication message), the user can press a button on the host or perform a corresponding action to confirm the association. .

In another example, if both devices have secure functionality and want to communicate over a secure link and the secure verification (authentication) is not successful, a message about this may be rendered on the display or via other means. If one of the devices wants to use security, but the other does not have the security capability, a message such as "Security Hardware not Available" may be rendered.

In another example, the message about the association may be a value (eg, a numeric association) or other means of establishing the association. If the value is used and the displays of both the w-MDDI host and w-MDDI client-capable device match, this indicates a successful and secure association. In such a situation, if the user wishes to confirm the association, the user may press a button on the host or take a similar action to confirm the association.

If the values do not match, this indicates that the host and device cannot authenticate each other and there may be a "man in the middle". In such a situation, the host and device may time out (eg, a timer associated with the association procedure has expired). When the device times out, the device returns to the state it was in before the association process was initiated.

The w-MDDI protocol of the disclosed features relates to dynamic association and dissociation and/or regulation to allow one w-MDDI transmitter to associate and communicate with a plurality of w-MDDI receivers. 9 illustrates a system 900 for service discovery in accordance with features disclosed herein. The w-MDDI transmitter 902 should obtain a list of w-MDDI receivers 904 that can be associated with the w-MDDI transmitter 902 (only one receiver is shown for simplicity). This association procedure is performed through the service discovery procedure.

The w-MDDI transmitter 902 may be configured to initiate a service discovery process (eg, receiver service discovery) to discover the w-MDDI receiver 904 . The discovery process service may be initiated through user-interaction or automatically (eg, upon recognizing that the transmitter 902 has entered a new location (eg, a room)).

Included in the w-MDDI transmitter 902 is a device list requestor 906 configured to send a request to discover a receiver 904 within an area. For example, a "Get Neighbor List" message is sent to a device (eg, a receiver 904) in a wireless (or wired) neighborhood (eg, a communication region) of the w-MDDI transmitter 902 . )) can be transmitted to the lower layer to obtain a list of. Substantially at the same time as receiving the message, a "Lower Layer Neighbor List Response" message including a list of devices in the vicinity of the device that the lower layer requests (w-MDDI transmitter 902) can respond with

The lower layer neighbor list response message contains a message ID which is 2 bytes containing a 16-bit unsigned integer. A message ID of 0x7 identifies the packet as a MAC address response message. A number of neighbors may also be included, which is 2 bytes specifying the number of neighbors for the current device (transmitter/receiver). In addition, the lower layer (MAC layer) address of the neighbor -1- lower layer address (MAC layer address) is included.

In addition, a service query identifier 908 configured to send a "w-MDDI Service Query" packet to each neighbor (eg, to each individual receiver in accordance with some feature) may include a w-MDDI Transmitter 902 is included. The w-MDDI receiver 904 includes a service capability notifier 910 that responds with a "w-MDDI Service Response" packet that may include a string identifier and availability for the w-MDDI receiver. can do. The packet length of the w-MDDI Service Response Packet may be 2 bytes containing a 16-bit unsigned integer specifying the total number of bytes in the packet excluding the Packet Length field. The Packet Type field may be 2 bytes and may contain a 16-bit unsigned integer. A packet type of 163 identifies the packet as a w-MDDI service response packet. Also included is a receiver MAC address field containing the 6-byte MAC address of the w-MDDI receiver. The transmitter MAC address field contains the 6-byte MAC address of the w-MDDI transmitter, which may be a broadcast or multicast address if multicast/broadcast service is used. The Receiver Parameters field may include a 256-byte string identifier of the w-MDDI receiver and its function. Furthermore, the w-MDDI service response packet is 2 bytes and includes a CRC field including a 16-bit CRC of all bytes of the packet including the Packet Length field.

The w-MDDI transmitter 902 may wait for the "w-MDDI service response" packet until the timer (eg, the value of service_discovery_timer) expires. If a response is not received before expiration of the timer, the association fails. If the response is received before expiration of the timer, the user of the w-MDDI transmitter 902 can select the w-MDDI receiver 904 to associate with.

According to some features, the w-MDDI transmitter 902 or the w-MDDI receiver 904 may 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 (eg, the w-MDDI transmitter) may initiate the association process.

According to some features, the w-MDDI receiver 904 may discover the w-MDDI transmitter 902 (eg, transmitter service discovery). The w-MDDI receiver 904 is used configured to forward a message (eg, "Get Neighbor List") to lower layers to obtain a list of devices within the wireless (or wired) neighborhood of the w-MDDI receiver. possible device requestor 912 . The lower layer may respond with a "lower layer neighbor list response" providing a list of devices in the neighborhood.

Neighbor list acquisition is a message transmitted to a lower layer (eg, MAC layer) to obtain a list of neighbors wirelessly connected to the current node. This message contains a message ID which is 2 bytes containing a 16-bit unsigned integer. A message ID number of 0x3 identifies the packet as a Get Neighbor List message.

A Get Lower Layer Address (Get MAC Address) message is sent to the lower layer to obtain the lower layer address (eg, MAC address) of the w-MDDI node (eg, UWB modem). This message contains a message ID which is 2 bytes containing a 16-bit unsigned integer. A message ID number of 0x2 identifies that the packet is a lower layer address (get MAC address) message.

The host query 914 included in the w-MDDI receiver 904 may be configured to send a "w-MDDI host query" packet to the neighbor. The w-MDDI transmitter 902 may include an available notifier 916 configured to send a "w-MDDI host response" packet to the w-MDDI receiver 904 in response to the query. The "w-MDDI Host Response" packet may contain availability and string identifiers for various devices. A user of the w-MDDI receiver 904 may select a w-MDDI transmitter to associate with. If a timer (eg, service_discovery_timer) associated with the w-MDDI receiver 904 expires before receiving the "w-MDDI host response", the association fails.

According to some features, when the multicast service is supported by the lower layer, the multicast service is "w-MDDI service query" and "w-MDDI service response" packets in the case of "Receiver Service Discovery" can be used to send "w-MDDI Host Query" and "w-MDDI Host Response" packets in the case of "Sender Service Discovery". The behavior when using multicast is described in more detail below. If a multicast service is not available, broadcast may be used. If no broadcast facility exists, unicast can be used.

The w-MDDI transmitter may maintain a list of w-MDDI receivers that responded with a w-MDDI service response packet and a receiver parameter corresponding to each of the w-MDDI receivers. The w-MDDI receiver may maintain a list of w-MDDI transmitters that responded with a w-MDDI service response packet and transmitter parameters corresponding to each of them. This list may be maintained on respective storage media associated with devices 902 and 904 .

According to some features, a lower lower layer may support multicasting. Multicasting can provide efficiency because the message is sent to a subset of devices (eg, identified devices) instead of being sent to all devices in the neighborhood. For service discovery when the lower lower layer supports multicast and the w-MDDI transmitter 902 discovers the w-MDDI receiver 904 (eg, receiver service discovery), the w-MDDI capable device is The multicast group specified by WMDDI_CONTROL_MULTICAST_ADDRESS can participate in the WMDDI_CONTROL_MULTICAST group. The w-MDDI receiver may advertise its "w-MDDI service response" packet periodically on this multicast address. A w-MDDI transmitter that wants to perform service discovery may select a w-MDDI receiver to associate with from this "w-MDDI service response". The w-MDDI sender may also explicitly request a "w-MDDI service response" packet from an individual receiver by sending a "w-MDDI service query" packet to the WMDDI_CONTROL_MULTICAST group.

In the case of service discovery when the w-MDDI receiver 904 is searching for the w-MDDI transmitter 902 (eg, transmitter service discovery) and the lower lower layer supports multicast, it wants to associate with the receiver A host (eg, a w-MDDI transmitter) may participate in the WMDDI_CONTROL_MULTICAST group specified by WMDDI_CONTROL_MULTICAST ADDRESS. The w-MDDI sender may advertise (eg, periodically) its "w-MDDI Host Response" packet on this multicast address. A w-MDDI receiver that wants to perform host discovery may select a w-MDDI transmitter it wants to associate with from this "w-MDDI host response". The w-MDDI receiver may also explicitly request a "w-MDDI host response" packet from an individual w-MDDI transmitter by sending a "w-MDDI host query" packet to the WMDDI_CONTROL_MULTICAST group.

According to some features, service discovery may be enabled when the underlying layer is wiMedia UWB MAC. When the lower lower layer is wiMedia UWB MAC, the items disclosed below may be available during service discovery. A wi-Media receiver-capable device includes an Application Specific IE (ASIE) that includes a w-MDDI service response. Similarly, a "w-MDDI transmitter-capable" device may include in its beacon an ASIE comprising a w-MDDI Host Response Packet.

10 shows an application specific IE (ASIE) format 100 of WiMedia MAC. According to some features, when the lower layer is wiMedia UWB MAC, the following may occur during service discovery. For example, a "w-MDDI receiver-capable" wi-Media device may include an application specific IE (ASIE) containing a w-MDDI service response. In a similar manner, a "w-MDDI transmitter-capable" device may include in its beacon an ASIE comprising a w-MDDI Host Response Packet.

Application Specifier ID (Application Specifier ID; 1002) may be set to wMDDI_wiMedia_ASIESpecifierID. In the case of the w-MDDI receiver, the application-specific data information is set to "w-MDDI Service Response Packet". Similarly, in the case of the w-MDDI transmitter, the application-specific data information is set to the "w-MDDI Host Response Packet".

The w-MDDI Host Response Packet responds to the w-MDDI Service Query Packet sent by the w-MDDI Sender. The Host Response Packet provides the w-MDDI receiver's availability and "string identifier". Packets contain a packet length of 2 bytes containing a 16-bit unsigned integer specifying the total number of bytes in the packet, excluding the Packet Length field. The packet type is 2 bytes containing a 16-bit unsigned integer. A packet type of 167 identifies the packet as a w-MDDI service response packet. The receiver MAC address is the 6-byte MAC address of the w-MDDI receiver. This may be a multicast or broadcast address depending on whether a multicast or broadcast service is available. Also included is the transmitter MAC address, which is the 6-byte MAC address of the W-MDDI transmitter. The Transmitter Parameters field is a 256-byte string identifier of the W-MDDI transmitter and its function. The CRC field is 2 bytes containing the 16-bit CRC of the total bytes of the packet including the packet length.

11 illustrates an application specific probe information element (AS probe IE) of the wiMedia MAC 1100 . When the w-MDDI transmitter discovers the receiver (eg, receiver service discovery), a "w-MDDI Service Discover" message is transmitted to the lower layer (wiMedia MAC). The w-MDDI service discovery message is transmitted to a lower layer (eg, wiMedia MAC layer) to obtain w-MDDI service information. The payload of this message is a "w-MDDI Service Query" packet. This is located in the application-specific request information field of the application-specific probe IE 1100 when the lower layer is wiMedia UWB MAC. The content of this message contains the message ID, which is 2 bytes containing a 16-bit unsigned integer. Packet type 0x4 identifies the packet as service discovery. The packet type is 2 bytes containing a 16-bit unsigned integer. A packet type of 162 identifies that the packet is a service query packet. In addition, a transmitter parameter field of 2 bytes including information about the w-MDDI transmitter is included. The receiver MAC address, which may be a broadcast address, and the 6-byte MAC address of the w-MDDI transmitter are the transmitter MAC addresses. Also included is a service query option that is 2 bytes of the service query option, and a CRC of 2 bytes that contains a 16-bit CRC of the total bytes of the packet including the packet length.

At substantially the same time as receiving the "w-MDDI service discovery" message from the w-MDDI layer, the wi-Media MAC on the w-MDDI transmitter determines that the message is valid (not expired) for w-MDDI receivers from all its neighbors. not) can determine whether it has ASIE information. If there is no valid ASIE information (or has expired), the MAC on the w-MDDI transmitter reviews the ASIE from its neighbor. If there are several neighbors of the w-MDDI transmitter that do not have ASIE information corresponding to the w-MDDI, it sends an application specific probe IE to each of these neighbors. The application specific probe IE is defined as shown in FIG. 11 . The "Application-Specific Request Information" field 1102 is set to the "w-MDDI Service Query" packet.

The w-MDDI transmitter waits for a time corresponding to service_discovery_timer for reception of the application-specific IE. The wiMedia MAC may send a "w-MDDI Service Information" packet to the w-MDDI layer for every ASIE received.

A "w-MDDI Service Information" packet is a message sent to w-MDDI by a lower layer (eg, wiMedia MAC) to provide a w-MDDI transmitter with service response information received from a w-MDDI receiver capable neighbor. . In wiMedia MAC, application-specific data of ASIE includes w-MDDI service response information. This message contains a message ID which is 2 bytes containing a 16-bit unsigned integer. A message ID of 0x8 identifies that the packet is a w-MDDI service information message. Another field is the number of w-MDDI receivers indicating the number of w-MDDI receivers. This message contains an instance of "number of w-MDDI receivers" in the following field. A packet length of 2 bytes contains a 16-bit unsigned integer that specifies the total number of bytes in the packet, excluding the Packet Length field. The packet type is 2 bytes containing a 16-bit unsigned integer. A packet type of 163 identifies that the packet is a w-MDDI service response packet. The receiver MAC address is the 6-byte MAC address of the w-MDDI receiver. The receiver parameter is a 256-byte string identifier of the w-MDDI receiver and its function. The CRC is 2 bytes containing the 16-bit CRC of the total bytes of the packet including the packet length.

A w-MDDI receiver that wants to initiate service discovery (eg, transmitter service discovery) to find a w-MDDI transmitter transmits a "w-MDDI host discovery" message to a lower layer (wimedia MAC). Substantially concurrent with receiving the message from the w-MDDI layer, the wiMedia MAC on the w-MDDI receiver determines whether this message has any valid (unexpired) ASIE information for the w-MDDI transmitter from its neighbor. can If there are several neighbors with w-MDDI receivers that do not have ASIE information, an application specific probe IE is sent to each of these neighbors. The application specific probe IE is defined as shown in FIG. 11 . The "Application-Specific Request Information" field 1102 is set to the "w-MDDI Host Query" packet. The w-MDDI receiver waits for a time corresponding to host_discovery_timer for reception of the application-specific IE. The iMedia MAC may send a "w-MDDI Host Information" packet for all ASIEs received to the w-MDDI layer.

The following will explain service discovery when the lower layer is UDP/IP. When receiver service discovery (eg, a transmitter discovering a receiver) and the underlying layer is UDP/IP, a w-MDDI transmitter/receiver capable device may participate in the WMDDI_CONTROL_MULTICAST group specified by the WMDDI_CONTROL_MULTICAST_IP multicast address. A w-MDDI receiver capable device may advertise its capabilities by (eg, periodically) sending a w-MDDI Sender Response Packet to the WMDDI_CONTROL_MULTICAST group. When a w-MDDI transmitter wants to discover a 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 if the device supports the w-MDDI receiver function. The w-MDDI Service Query Packet Content contains a packet length of 2 bytes containing a 16-bit unsigned integer specifying the total number of bytes in the packet, excluding the Packet Length field. Packet type 162 is 2 bytes containing a 16-bit unsigned integer. Packet type 162 identifies the packet as a service query packet. In addition, a transmitter parameter field of 2 bytes including information about the w-MDDI transmitter is included. Also included is the transmitter MAC address, which is the 6-byte MAC address of the w-MDDI transmitter, and the receiver MAC address, which is the 6-byte MAC address of the w-MDDI receiver. This may be a multicast or broadcast address if a multicast or broadcast service is used. Also included is a service query option that is 2 bytes of the service query option. The CRC field is 2 bytes containing the 16-bit CRC of the total bytes of the packet including the packet length.

At about the same time as receiving the "w-MDDI Service Query" packet, all w-MDDI receiver capable devices reply a "w-MDDI Service Response" packet to the w-MDDI sender participating in the WMDDI_CONTROL_MULTICAST multicast group on UDP port # WMDDI_UDP_CONTROL_PORT. do. The transmitter may wait for a service_discovery_timer duration for the w-MDDI service response packet.

If the transmitter service discovery (eg, the receiver discovering the transmitter) and the underlying layer is UDP/IP, the w-MDDI transmitter/receiver capable device may participate in the WMDDI_CONTROL_MULTICAST group specified by the WMDDI_CONTROL_MULTICAST_IP multicast address. A w-MDDI transmitter capable device may advertise its capabilities by periodically sending a w-MDDI service response packet to the WMDDI_CONTROL_MULTICAST group. When a w-MDDI receiver wants to discover a 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. The w-MDDI Host Query Packet is used to query the wireless device to determine whether the device supports the w-MDDI receiver function.

The packet content of the w-MDDI host query packet includes a packet length field, a packet type field, a receiver parameter field, a transmitter MAC address field, a receiver MAC address field, a service query option field, and a CRC field. The Packet Length field is 2 bytes containing a 16-bit unsigned integer that specifies the total number of bytes in the packet, excluding the Packet Length field. The Packet Type field is 2 bytes containing a 16-bit unsigned integer. A packet type of 166 identifies that the packet is a host query packet. The receiver parameter field is 2 bytes containing information about the w-MDDI transmitter. The Transmitter MAC Address field is the 6-byte MAC address of the w-MDDI transmitter. This may be a multicast or broadcast address if a multicast or broadcast service is used. The Receiver MAC Address field is the 6-byte MAC address of the w-MDDI receiver. The service query option field is 2 bytes of the service query option. The CRC field is 2 bytes containing the 16-bit CRC of the total bytes of the packet, including the packet length.

At about the same time that the "w-MDDI Host Query" packet is received, all w-MDDI Sender capable devices reply a "w-MDDI Host Response" packet to the w-MDDI receiver participating in the WMDDI_CONTROL_MULTICAST multicast group on UDP port # WMDDI_UDP_CONTROL_PORT. do. The receiver may wait for the duration of host_discovery_timer for the w-MDDI host response packet.

According to some features, optional security actions may be enabled. If the w-MDDI transmitter and/or the w-MDDI receiver are not security-enabled, the resulting operation is insecure. If both the w-MDDI transmitter and w-MDDI receiver are secure-capable and one of them wants secure operation, the resulting operation is secure. The following table lists the different possibilities for host and device security functions with which associations are made. For the remaining possibilities, the association does not proceed.

<tables num="1"><table><tgroup cols="6"><colspec align="justify" colname="col1" colnum="1" colwidth="1780" /><colspec align="justify" colname="col2" colnum="2" colwidth="1780" /><colspec align="justify" colname="col3" colnum="3" colwidth="1780" /><colspec align="justify" colname="col4" colnum="4" colwidth="1780" /><colspec align="justify" colname="col5" colnum="5" colwidth="1780" /><colspec align="justify" colname="col6" colnum="6" colwidth="1780" /><tbody><row><entry align="justify" nameend="col2" namest="col1">host</entry><entry align="justify" nameend="col4" namest="col3">device</entry><entry align="justify" colname="col5" morerows="1">secure communication </entry><entry align="justify" colname="col6" morerows="1">proceed in association </entry></row><row><entry align="justify" colname="col1">Security Essentials</entry><entry align="justify" colname="col2">security possible</entry><entry align="justify" colname="col3">Security Essentials</entry><entry align="justify" colname="col4">security possible</entry></row><row><entry align="justify" colname="col1">irrelevant</entry><entry align="justify" colname="col2">Yes</entry><entry align="justify" colname="col3">irrelevant</entry><entry align="justify" colname="col4">Yes</entry><entry align="justify" colname="col5">Yes</entry><entry align="justify" colname="col6">Yes</entry></row><row><entry align="justify" colname="col1">no</entry><entry align="justify" colname="col2">irrelevant</entry><entry align="justify" colname="col3">no</entry><entry align="justify" colname="col4">no</entry><entry align="justify" colname="col5">no</entry><entry align="justify" colname="col6">Yes</entry></row><row><entry align="justify" colname="col1">no</entry><entry align="justify" colname="col2">no</entry><entry align="justify" colname="col3">no</entry><entry align="justify" colname="col4">irrelevant</entry><entry align="justify" colname="col5">no</entry><entry align="justify" colname="col6">Yes</entry></row><row><entry align="justify" nameend="col4" namest="col1">the rest</entry><entry align="justify" colname="col5" /><entry align="justify" colname="col6">no</entry></row></tbody></tgroup></table></tables>

If a secure operation is required, the mutual authentication procedure takes place after the association process is complete. For secure operation, the w-MDDI transmitter and the w-MDDI receiver share a master key. The master key can be exchanged after the association process is complete. The master key can be used as the connection key for the entire time of the association; Alternatively, a par-wise temporal key (PTK) may be obtained and used from the master key. When the lower lower layer is wiMedia UWB MAC, a four-way handshake may be used to obtain a PTK.

12 illustrates a method 1200 for wirelessly communicating high-speed digital data using receiver-initiated association. To associate a device (eg, a w-MDDI receiver) with a host entity (eg, a w-MDDI transmitter), an association request packet is transmitted by the w-MDDI receiver at 1202 . According to some features, the association request packet may be transmitted by C2 for an association request when C2 wants to associate with the MDDI transmitter after power-up of the device. 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 for an association request when C2 wants to associate with the MDDI transmitter (eg, after power up). The packet length may be 2 bytes, including a 16-bit unsigned integer specifying the total number of bytes in the packet, excluding the Packet Length field. The packet type may be 2 bytes long and may contain a 16-bit unsigned integer. A packet type of 154 identifies that the packet is an association request packet. A device parameter may be 2 bytes for a device specific parameter. The transmitter MAC address may 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 option is 2 bytes (bit 0 and bit 1). Bit 0 is a security function and is a "1" if the receiver has a security function, otherwise a "0". Bit 1 is a "1" if security-required and security-essential for the receiver, and a "0" otherwise. The CRC may be 2 bytes containing the 16-bit CRC of the total bytes of the packet including the packet length.

At substantially the same time that the association request packet is transmitted, at 1204 the device may enter a "send association request" state and an association timer may be started. According to some features, the association request may include information regarding whether the w-MDDI receiver is security capable and/or whether security is essential for the w-MDDI receiver.

The w-MDDI transmitter shall acknowledge the association request packet and respond with an association response packet before the association timer reaches a predetermined interval (eg timeout, expiration). The association response packet may include a client ID identifying the w-MDDI receiver. According to some features, the association request packet includes information about whether the w-MDDI sender is security-capable and/or whether security is essential for the w-MDDI sender. After sending the association response packet, the w-MDDI transmitter may enter the "send association response" state and start the association response timer.

The association response packet is transmitted in response to the association request packet sent by C1. This packet provides C2 with the Client ID and Display/Device ID. This is part of the three-way handshake association. A packet is 2 bytes containing a 16-bit unsigned integer that specifies the total number of bytes in the packet, excluding the Packet Length field. The Packet Type field is 2 bytes containing a 16-bit unsigned integer. A packet type of 155 identifies that the packet is an association response packet. Also included is the client ID, which is 2 bytes allocated for C2's client ID, and the association/security option, which is 2 bytes (bit "0", bit "1" and bit "2"). Bit 0 indicates a security function and is set to "1" if a security function is present at the transmitter, and to "0" otherwise. Bit 1 indicates security required and is set to "1" if security is essential for the sender, and to "0" otherwise. Bit 2 indicates whether a multicast address is included. This bit is set to "1" if the multicast address was included with the Association Response Packet. The CRC field is 2 bytes containing the 16-bit CRC of the total bytes of the packet including the packet length.

The w-MDDI transmitter and receiver may negotiate their security functions and essential options with "association request packet" and "association response packet". The association process may proceed or stop based on the possibilities listed in Table 1, disclosed 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 is only trusted after the mutual authentication process is complete.

At 1206 a determination is made as to whether the timer has expired. Because the underlying wireless medium may be unreliable, it may be possible for association response packets or other packets to be lost. Accordingly, if an association response packet is not received before expiration of the timer ("no"), the method 1200 proceeds to a determination as to whether the timer of 1206 has expired. If it is determined at 1206 that the timer has expired, the method 1200 proceeds to retransmission of a subsequent Association Response Packet at 1202 . This may be repeated until the number of subsequent association response packets has been transmitted up to a maximum number of times.

According to some features, when the association response timer expires, the w-MDDI transmitter may retransmit the association response packet. According to some features, the w-MDDI transmitter may transmit an association response packet whenever it receives an association request packet from the w-MDDI receiver.

If the timer has not expired ("no"), then at 1208 a determination is made as to whether an association response packet has been received. If at 1208 a determination is made that the Association Response Packet has been received ("Yes"), then the method 1200 proceeds to 1210 and the Client Function Packet is sent to the w-MDDI sender accepting the Association Request Packet.

A status packet or a client function packet may be sent at 1212 . A Client Function Packet may be transmitted when the w-MDDI receiver receives the Association Response Packet from the w-MDDI Sender.

If the security option is enabled, at this point the client function packet is still unauthenticated. The contents of the Client Capability Packet are trusted only after the optional mutual authentication has been completed, as indicated by the dotted line at 1212 . Additional information regarding mutual authentication will be provided below.

After sending the client function packet, the w-MDDI receiver can enter the associated state (unless the security option is enabled) and the associated w-MDDI receiver enters the associated state (unless the security option is enabled). can enter If the security option is enabled, the mutual authentication process (discussed below) must be completed before the w-MDDI transmitter and w-MDDI receiver enter the association state. In this way, there is an established three-way handshake association. According to some features, if the Association Request Packet, Association Response Packet and/or Client Function Packet are lost, they may be retransmitted if the radio link is stable. Otherwise, the w-MDDI transmitter and the w-MDDI receiver are not associated (eg, they may stay in a disassociated state). According to some features, the w-MDDI receiver may transmit the Alternate Display Function Packet if it has any associated alternate displays.

After being associated with a particular w-MDDI transmitter, the w-MDDI receiver may store the lower layer address (MAC address) of the transmitter. After entering the association state, the w-MDDI receiver should send a link state packet (MAC response packet) to the host at 1214 (eg, periodically, such as once every mac_response_time msec). The link state packet provides MAC statistics on the w-MDDI receiver MAC (eg, average number of retransmissions, packet error rate, etc.) to the w-MDDI transmitter. Fields included in the Link State Packet are Packet Length, Packet Type, cClient ID, Average Number of Retransmissions, Frame Error Rate, Physical Layer Rate, and CRC. The Packet Length is 2 bytes containing a 16-bit unsigned integer that specifies the total number of bytes in the packet, excluding the Packet Length field. The packet type is 2 bytes containing a 16-bit unsigned integer. A packet type of 150 identifies that the packet is a MAC response packet. The cClient ID is 2 bytes containing a 16-bit unsigned integer. This is the client ID of C1/C2 according to the identity of the sender of the packet. The average number of retransmissions is the average number of retransmissions for all MAC frames 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 2 bytes containing the 16-bit CRC of the total bytes of the packet, including the packet length.

At substantially the same time as receiving the Link Status Packet (MAC Response Packet) from the w-MDDI Receiver, the w-MDDI Transmitter may respond with a Transmitter Link Status Packet (MAC Response Packet). This packet confirms the reception of the Link State Packet (MAC Response Packet) sent by the w-MDDI receiver. It may also provide statistics and parameters of the receiver MAC to the w-MDDI transmitter.

In response to the lower layer response packet (MAC response packet) sent by the w-MDDI receiver, if it does not receive a transmitter link status packet (sender MAC response packet) from the w-MDDI transmitter for mac_response_fail_time msec duration, the w-MDDI receiver shall It can be recognized that it has been disassociated from the transmitter. The w-MDDI receiver then stops transmitting the Link Status Packet (MAC Response Packet). If the transmitter does not receive a link state packet (MAC response packet) for the duration of mac_response_fail_time msec, the transmitter enters the disassociation state. When a transmitter or receiver enters the disassociation state, it does not respond to the link state packet/transmitter link state packet (MAC response packet/sender MAC response packet) transmitted by the receiver and the transmitter respectively.

A lower layer response (MAC response) is a message from a lower layer (eg MAC layer) to the w-MDDI transmitter/receiver. This message indicates the rate supported by the lower layer (eg MAC), retransmission statistics, etc. The message contains a message ID which is 2 bytes containing a 16-bit unsigned integer. A message ID of 0x5 identifies the packet as a MAC response message. The packet also contains the average number of retransmissions, which is the average number of retransmissions of all MAC frames 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 (eg MAC address) of the lower layer (eg, UWB modem). This message contains a message ID which is 2 bytes containing a 16-bit unsigned integer. A message ID of 0x6 identifies the packet as a MAC address response message. The lower layer (MAC layer) address, which is the lower layer address (MAC layer address) of the lower layer, is also included.

After disassociation, the w-MDDI transmitter and receiver need to be reassociated before they can resume wireless MDDI transmission. After a w-MDDI receiver has disassociated from a particular transmitter, it is allowed to associate with any other transmitter. Additional information regarding disassociation is disclosed below.

According to some features, the w-MDDI receiver also transmits when the w-MDDI transmitter explicitly requests the Link Status Packet (MAC Response Packet) via the Link Query Packet (MAC Query Packet).

A Link Query Packet is sent by the host to query MAC information on the transmitter/receiver side. The content of the Link Query Packet contains a packet length of 2 bytes containing a 16-bit unsigned integer specifying the total number of bytes in the packet, excluding the Packet Length field. The packet type is 2 bytes containing a 16-bit unsigned integer. A packet type of 151 identifies that the packet is a MAC query packet. The cClient ID field is 2 bytes including a 16-bit unsigned integer reserved for the ID of the target client C2. The MAC query parameter is 2 bytes and the CRC field is 2 bytes containing the 16-bit CRC of the total bytes of the packet including the packet length.

If the underlying radio link is an 802.15.3 UWB MAC, after associated with the w-MDDI receiver, the w-MDDI transmitter transmits CTA setup packets in the forward and reverse directions if the operating mode is a low latency mode (which will be described in more detail below). can be used to set the CTA for transmission.

13 illustrates a method 1300 for high-speed wireless data communication between a transmitter and a remote receiver. Method 1300 may be used when a w-MDDI transmitter desires to associate with a w-MDDI receiver. For example, if the w-MDDI transmitter is a phone and the w-MDDI receiver is a projector, the w-MDDI transmitter (eg, phone) may initiate the association process.

Method 1300 depicts a sender initiated association, and begins at 1302 with a sender association request packet being sent to a remote receiver. A Sender Association Request Packet is transmitted for an association request by a transmitter when the transmitter wants to associate with a particular MDDI receiver (eg, after power-up). The Sender Association Request Packet contains a Packet Length that is 2 bytes containing a 16-bit unsigned integer specifying the total number of bytes in the packet, excluding the Packet Length field, and a Packet Type that is 2 bytes containing a 16-bit unsigned integer. A packet type of 158 identifies that the packet is an association request packet. It also contains the receiver MAC address, which is 6 bytes and contains the receiver MAC address, and the transmitter MAC address, which is a byte of the transmitter MAC address. The association/security option contains 2 bytes (bit "0" and bit "1"). Bit "0" indicates the security function and is set to "1" if a security function is present at the receiver, otherwise it is set to "0". Bit "1" indicates whether security is required. Security is mandatory for the receiver if set to "1", otherwise set to "0". The CRC field is 2 bytes containing the 16-bit CRC of the total bytes of the packet including the packet length. According to some features, the transmitter association request packet includes information about whether the w-MDDI transmitter is secureable and/or whether security is mandatory for the w-MDDI transmitter.

At substantially the same time that the first association request packet is transmitted, at 1304 the transmitter enters a "transmitter association request packet transmission" state and a timer (eg, association timer) or other tracking means may be started. An interval of time between transmission of the first association request packet and receipt of a response (eg, association request packet) from a remote receiver is tracked, and at 1306 a predefined time interval has been exceeded (eg, a timer has expired) ) is judged. If the timer expires ("yes"), this indicates that an association request packet has not been received from the remote sender and the method 1300 proceeds to 1302 where a subsequent association request packet is transmitted. Any number of subsequent sender association request packets may be transmitted up to a maximum number of times (eg, max_sender_association_retry). If the timer expires ("no"), a determination is made at 1308 as to whether an association request packet has been received.

If a determination is made at 1308 that an association request packet has not been received ("no"), then the method 1300 proceeds at 1306 until expiration of the timer or until an association request packet is received. If an association request packet has been received ("yes"), an association response packet may be sent providing the remote device with a client ID.

An association response packet is transmitted in response to the association request packet sent by C1. At substantially the same time as sending the Association Response Packet, the w-MDDI receiver may enter a "send association request" state and start an association timer. The association response packet may be retransmitted up to the maximum number of max_association_retry times. According to some features, the association response packet includes information about whether the w-MDDI receiver is secureable and/or whether security is essential for the receiver.

This packet provides C2 with the Client ID and Display/Device ID. This is part of the three-way handshake association. The Association Response Packet contains the Packet Length, Packet Type, Client ID and CRC. The Packet Length is 2 bytes containing a 16-bit unsigned integer that specifies the total number of bytes in the packet, excluding the Packet Length field. The packet type is 2 bytes containing a 16-bit unsigned integer. A packet type of 155 identifies that the packet is an association response packet. The client ID is 2 bytes allocated for the client ID of C2 and the CRC is 2 bytes containing the 16-bit CRC of the total bytes of the packet including the packet length.

If at 1308 it determines that a packet has been received ("yes"), then at 1312 the w-MDDI sender responds with an association response packet providing the client ID to the w-MDDI receiver (similar to the receiver initiated association case described above). . According to some features, the association response packet also includes security essential information and security functions for transmission, confirming the originally transmitted information.

The transmitter may also start a timer, such as an association response timer, at substantially the same time as sending the association response packet. The receiver shall respond with a Client Function Packet and/or Link Quality information. All association responses received by the receiver shall be answered with a Client Function Packet.

When the association response timer expires, the wireless transmitter retransmits the association response packet up to a maximum number of times (eg, association_retry). A transmitter association request, association request, association response and client function may constitute a four-way handshake procedure.

Method 1300 enables w-MDDI transmitters and receivers to negotiate their security functions and required options. The association process may proceed or abort based on the possibilities in Table 1 described above. If the secure communication option is enabled as a result of the above consultation, the client ID provided by the w-MDDI transmitter is not authenticated at this point and is only trusted after the mutual authentication process is completed.

When the security option is turned on, mutual authentication may be performed as disclosed below. According to some features, a receiver associated with a particular transmitter does not grant association requests from any other transmitter. In this situation, the w-MDDI receiver may transmit an association reject packet to the transmitter.

14 illustrates a procedure 1400 for mutual authentication and key exchange. According to this example, the procedure 1400 is based on a numeric association model of Wireless USB. If secure operation is desired, mutual authentication and key exchange occurs between the w-MDDI transmitter 1402 and the w-MDDI receiver 1404 . This procedure is similar to the "numerical association procedure" of Wireless USB. A Diffie-Hellman protocol may be used to establish a temporary secure channel. To protect against man-in-the middle attacks, the host and device can each display a value obtained from the Diffie-Hellman key and the user is asked to verify that the two values match.

The w-MDDI receiver 1404 may generate a fresh random secret A and PK_D = g^A Calculate mod p. A and PK_D A value may be prohibited from being hard coded into the device at manufacturing time. w-MDDI receiver 1404 hash SHA-256 (PK)_D ? N_D) and transmits the hash to the w-MDDI transmitter 1402 at 1406 . N_Dis the number of digits that the device can display. This hash is not revealed until after the public key of the w-MDDI transmitter is revealed, and the device can use the PK without revealing the value._D and N_DStick to the values.

The w-MDDI transmitter 1402 may generate a fresh random secret B and PKH = g^B Calculate mod p. B and PK_H The value may be prohibited from being hard coded into the w-MDDI transmitter at manufacturing time. The w-MDDI transmitter 1402 transmits the PKH to the device at 1408 . PK_HIf is equal to 1 or p-1, the device stops the association.

At 1410 w-MDDI receiver 1404 is PK_D and N_Dto the w-MDDI transmitter. PK_DIf is equal to 1 or p-1, the W-MDDI transmitter 1402 stops association. W-MDDI transmitter 1402 SHA-256 (PK)_D ? N_D) and confirm the result with the hash commitment previously received from the device. If the values do not match, the W-MDDI transmitter 1402 stops association. Further, the W-MDDI transmitter 1402 calculates the shared secret DHKey = SHA-256 (PKDB mod p). The w-MDDI transmitter 1402 sets the shared secret DHKey = SHA-256(PK)_H^A mod p) is calculated.

To defend against man-in-the-middle attacks, both sides have a common value V = SHA-256 (PK_D ? PK_H ? Computes a "displayed digest") and displays to the user some digits of this number (eg, 2 digits, 3 digits, 4 digits, etc.) on their respective displays.

The user manually verifies that the numbers displayed on the w-MDDI transmitter and device match (e.g. review both displays) and presses "ok" on both the w-MDDI transmitter and device (or any equivalent action) take). If the user selects "does not match" or a user confirmation is not received at both the w-MDDI transmitter and the device within the timeout period, the association is aborted and a failure indication is displayed to the user. The timeout period may be at least 20 seconds without a maximum timeout period.

When the user approves the association, both the w-MDDI transmitter and the device compute the first 128 bits of the master key (PMK) = HMAC-SHA-256DHKey ("pairwise master key"). The w-MDDI transmitter also sends any remaining non-private information requesting to complete the association.

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

According to some features, disassociation may occur. For example, if the w-MDDI transmitter does not receive a link status packet (MAC response packet) from the receiver for mac_response_fail_time msec time, it may declare that the receiver is disassociated. Then, the transmitter 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 the Link State Packet (MAC Response Packet) and the Transmitter Link State Packet (Sender MAC Response Packet) respectively.

According to some features, if the w-MDDI receiver does not receive the sender MAC response packet in response to the max_MAC_Response_retries packet, the w-MDDI receiver enters a disassociation state. If a link state packet (MAC response packet) appears from the receiver after the receiver has been marked as disassociated in the sender's device association table, the association process must be restarted by the transmitter (e.g., the transmitter establishes a transmitter-initiated association). performed).

15 shows a receiver-initiated disassociation procedure 1500 . The w-MDDI receiver 1504 may also send an explicit disassociation request packet 1506 to the w-MDDI transmitter 1502 to dissociate. The w-MDDI transmitter 1502 responds with a Dissociation 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 from the device association table.

16 illustrates a method 1600 for receiver initiated disassociation between a user device (eg, receiver) and a host entity (eg, transmitter). Method 1600 begins at 1602 by associating a user device with a host entity. At substantially the same time that association with the host entity is established, a function packet is transmitted at 1604 . The function packet may include one or more functions of the user device. At 1606 a status packet may be sent. This transmission of a status packet may be based on a request for a packet from a host entity periodically or upon a status change.

A determination may be made at 1608 that the association has been broken and/or a determination may be made at 1610 to cease communication with the host entity. For example, the determination may be made if the wireless receiver does not receive a transmitter MAC response packet from the wireless transmitter within a predetermined time. The MAC Response Packet provides MAC statistics on the radio receiver MAC, such as average number of retransmissions, packet error rate, etc. The packet content may include packet length, packet type, client ID, average number of retransmissions, frame error rate, physical layer rate, and CRC. A MAC Response Packet containing a 16-bit unsigned integer specifying the total number of bytes in the packet, excluding the Packet Length field, may be 2 bytes in length. The packet type is 2 bytes containing a 16-bit unsigned integer. A packet type of 150 identifies that the packet is a MAC response packet. The client ID is 2 bytes containing a 16-bit unsigned integer. This is the client ID of C1/C2 depending on which client is the sender of the packet. The average number of retransmissions for each MAC frame transmitted in the reverse direction may be 2 bytes. The frame error rate can be 2 bytes and is the packet error seen in the forward direction. The physical layer rate can be 2 bytes and is the transfer rate on the physical layer. The CRC is 2 bytes containing the 16-bit CRC of the total bytes of the packet including the packet length.

The Sender MAC Response Packet provides MAC statistics on the w-MDDI transmitter MAC, such as average number of retransmissions, packet error rate and others for the w-MDDI receiver. This packet is sent by the radio transmitter accepting the MAC response packet sent by the radio receiver. This packet contains a Packet Length field that is 2 bytes containing a 16-bit unsigned integer that specifies the total number of bytes in the packet, excluding the Packet Length field. It also contains a Packet Type field that is 2 bytes containing a 16-bit unsigned integer. A packet type of 159 identifies that the packet is a sender MAC response packet. The cClient ID is 2 bytes containing a 16-bit unsigned integer. This is the client ID of the target client, i.e. C2. The average number of retransmissions is the average number of retransmissions for all MAC frames transmitted in the reverse direction. The frame error rate is the packet error rate seen in the forward direction. The physical layer rate is the transmission rate on the physical layer. The packet also contains a 2-byte long CRC containing the 16-bit CRC of all bytes of the packet including the packet length.

If one or both associations are to be broken or communication is to be stopped, the user device must be disassociated from the host entity. Such disassociation may include sending an explicit dissociation request packet to the wireless transmitter at 1612 . If there is still a communication link between the host entity and the user device (eg, all communication is lost), then at 1614 a dissociation response packet is received from the wireless transmitter. At substantially the same time as the dissociation response is received, at 1616 the user device enters the dissociation state.

A Dissociation Request Packet may be sent by C2 when C2 has disassociated with the wireless transmitter and wants a good exit. The Dissociation Request Packet contains a 2-byte long Packet Length field containing a 16-bit unsigned integer that specifies the total number of bytes in the packet, excluding the Packet Length field. The Packet Type field is 2 bytes containing a 16-bit unsigned integer. A packet type of 156 identifies that the packet is a disassociation request packet. The client ID field is 2 bytes allocated for the client ID of C2. The CRC field is 2 bytes containing the 16-bit CRC of the total bytes of the packet including the packet length.

The Dissociation Response Packet is sent in response to the Dissociation Request Packet. This is a 2-byte packet length containing a 16-bit unsigned integer that specifies the total number of bytes in the packet, excluding the Packet Length field. The packet type is 2 bytes containing a 16-bit unsigned integer. A packet type of 157 identifies that the packet is a disassociation response packet. The client ID is 2 bytes allocated for the client ID of C2 and the CRC field is 2 bytes containing the 16-bit CRC of the total bytes of the packet including the packet length.

Referring to FIG. 17 , a transmitter-initiated disassociation procedure 1700 is shown. The transmitter 1702 may be disassociated by sending a transmitter dissociation request packet 1706 to the receiver 1704 . The receiver 1704 then sends a disassociation request 1708 . The transmitter 1702 confirms by sending a dissociation response 1710, which completes the disassociation procedure.

18 illustrates a method 1800 for selective disassociation between a transmitter and a remote receiver. At 1802, an association between the transmitter and the remote receiver may be established. At 1804 a packet including the functionality of the remote receiver may be received, and at 1806 link quality information may be received. Additionally, the MAC address of the transmitter and the ID of the remote receiver may be included in the device association table associated with the transmitter.

In some circumstances, it may be necessary to cease the association between the remote receiver and the transmitter and a determination may be made at 1808 that communication between the transmitter and the remote receiver should be disabled. For example, if the wireless transmitter does not receive a MAC response packet from the receiver within a predetermined interval (e.g., mac_response_fail_time) msec, the receiver may declare that it has been disassociated and at 1810 a transmitter dissociation request packet is sent to the receiver . At 1812 a response to the dissociation request (eg, dissociation request) is received from the receiver. At 1814 a dissociation complete confirmation (eg, dissociation response) may be sent to complete the dissociation procedure.

In some features, a dissociation request may be explicitly received from a remote receiver at 1816 . At 1818 , a disassociation response confirmation (eg, a dissociation response) is sent. At 1820 , the identity of the disassociated device is removed from the association table.

Transmitter Dissociation Request Packet is sent by the wireless transmitter to initiate dissociation. It contains a Packet Length field that is 2 bytes containing a 16-bit unsigned integer that specifies the total number of bytes in the packet, excluding the Packet Length field. The 2-byte Packet Type field contains a 16-bit unsigned integer. A packet type of 161 identifies that the packet is a disassociation request packet. The client ID is 2 bytes allocated for the client ID of C2. The CRC field is 2 bytes containing the 16-bit CRC of the total bytes of the packet including the packet length.

According to some features, all W-MDDI receivers periodically transmit a link status packet (MAC response packet) once every mac_response_time msec. 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 may determine a lower layer rate (MAC rate) based on this information. This speed information can be passed to the application. This can help applications scale up/scale down their data rates. The transmitter sends a Transmitter Link Status Packet (Sender MAC Response Packet) to the respective receiver in response to the Link Status Packet (MAC Response Packet) received from each of the respective w-MDDI receivers.

According to some features, the client IDs are given by the w-MDDI transmitter to the w-MDDI receiver during the association process via an association response packet. The Client ID indicates an address identifier for a particular w-MDDI transmitter. The client ID pool is unique to the sender. A new receiver may be assigned an arbitrary client ID from an empty pool. According to some features, the clientID that has not been used for the longest time is assigned to the w-MDDI receiver (eg, association contexts using the same client ID are spaced apart at long intervals). This is to ensure that the client ID is reused as little as possible.

19 illustrates one radio transmitter associated with a plurality of radio receivers in accordance with features disclosed herein. In order to fully understand the disclosed features, various radio packets of a radio technology and their behavior will be described. Filler packets are not generated in wireless communication of high-speed data because filler packets are designed to maintain synchronization on a wired link and are therefore not needed on a wireless link.

The Client Capability Packet notifies the host of the client's capabilities. In MDDI, the client must send this packet after forward synchronization. The client may also send a Client Function Packet when requested by the host via the Reverse Link Flag in the Reverse Link Encapsulation Packet. The Client Capability Packet may include fields pertaining to the link, such as a pre-calibration data rate function, an interface type function, a post-calibration data rate function, and the like. This packet may also include fields pertaining to an external device, such as a display device attached to the client. These fields may include the number of alternate displays, bitmap width, bitmap height, display window width, display window height, color map size, and the like.

During the association procedure of wireless MDDI, the receiver may transmit a client function packet in response to the association response packet sent by the radio transmitter. The radio receiver C2 may also transmit an Alternate Display Function Packet if the radio receiver C2 is associated with any alternate display. The wireless receiver C2 may transmit a client function packet to the transmitter when there is a change in the state and/or function of the external device (eg, adding a new device, removing an existing device, changing a parameter of an existing device, etc.). Alternatively or additionally, the Client Function Packet may be transmitted periodically to aid in reliability of the Client Function Packet. According to some features, the w-MDDI receiver may transmit the client function packet to the w-MDDI transmitter when the w-MDDI sender requests the client function packet through the C2 flag field of the C2 request packet.

The client request and status packets can be used to send information from the client to the host to enable the host to configure the host-to-client link in a more optimal way. In a wired MDDI configuration, the client may send this packet to the host as the first packet in the Reverse Link Encapsulation Packet. Alternatively or additionally, the client may send this packet to the host when the host explicitly requests it via a Reverse Link Flag in the Reverse Link Encapsulation Packet.

In wireless MDDI, a wireless receiver may send a client request and status packet to a wireless transmitter periodically to indicate when there is a change in the state of an external device and to indicate its own CRC error count. The wireless receiver may also send a client request and status packet to the requesting wireless transmitter via the C2 flag field of the C2 request packet.

Referring back to FIG. 19 , each radio transmitter 1902 (only one shown) is connected to multiple radio receivers (receiver 1 (R1; 1904), receiver 2 (R2; 1906) and receiver 3 (R3; 1908). shown) may be associated with or in communication with. Transmitter 1902 and receivers 1904 , 1906 , 1908 may be MDDI transmitter(s) and/or MDDI receivers or other transmitters and receivers capable of wirelessly communicating high-speed digital data. Each receiver 1904, 1906, 1908 may have multiple displays (not shown) and devices (not shown). For example, each receiver may have 16 displays, but more or fewer than 16 displays may be associated with one receiver. Each receiver may have a w-MDDI client entity C2.

For example, wireless devices (wireless display, wireless mouse, wireless keyboard, etc.) may have a w-MDDI receiver, and each wireless device may be identified as a separate client. From the perspective of the host (eg, transmitter 1902 ), each of these clients can be identified by a unique client ID (client ID). Accordingly, the client C1 may have a client ID of "0". A wireless receiver such as the receiver (R2) 1906 may transmit a client function packet to the wireless (C2) transmitter 1902 when there is a change in the functions of external devices connected to the receiver (R2) 1906 . Additionally or alternatively, each receiver may periodically transmit a Client Function Packet to ensure reliability.

The transmitter 1902 should maintain a device association table, such as the table 2000 shown in FIG. 20 . Table 2000 shows the association of one wireless transmitter with multiple wireless receivers (eg, clients).

Packets for different receiver clients may be delivered to respective devices based on a table. Table 2000 shows two clients 1 and 2 . The association with client #1 is MAC address X:Y:Z:P:Q:R, client ID "C21". The association with client #2 is MAC address U:V:W:L:M:N, client ID "C22". In this way, the transmitter can communicate with the appropriate receiver by accessing the lookup table 2000 .

For a transmitter to communicate with a receiver, a device association must exist. Either device (transmitter or receiver) can initiate the association process. For example, if the wireless transmitter is a phone and the wireless receiver is a projector/display, the phone (eg the transmitter) will normally initiate communication. However, there are cases where the receiver initiates communication. Thus, there may be a receiver-initiated association or a transmitter-initiated association.

According to some features, if the lower lower layer supports multicasting, multicast support may be used for one w-MDDI transmitter communicating with multiple w-MDDI receivers. w-MDDI receivers and transmitters may participate in the WMDDI_CONTROL_MULTICAST group.

The w-MDDI transmitter to use the multicast function must form a multicast group. In the case of IP, if there is a central server that provides a lower layer multicast address (eg, a DHCP server), the w-MDDI transmitter may acquire the multicast address on a lease. This may be performed before the service discovery procedure or after the service discovery procedure. The duration of a loan can be short-term (limited to the duration of the association) or it can be long-term (much longer than the duration of the association).

For example, if there is a central server, the central server should be used to assign addresses. In the absence of a central server, each individual transmitter can individually select a multicast address. In this case, an address conflict (ie, two transmitters choosing the same address) may exist. Therefore, there is a need for an algorithm to alleviate multiple transmitters selecting the same address.

Depending on the various features, it may become possible to operate as a miMedia UWB Mac. As previously mentioned, w-MDDI can operate on any underlying high-speed radio link. As an example, the operation of w-MDDI with wiMedia MAC will be described below. When the lower lower layer is wiMedia UWB MAC, the following content may be used to transmit control packets (for association, disassociation, etc.).

An Application Specific IE may be used in the beacon to carry the control packet in w-MDDI. For example, an application specific data field in an ASIE may be set to a control packet (for association, disassociation, etc.). The ASIE packet is shown in FIG. 10 . The ASIE specifier ID is set to wMDDI_wiMedia_ASIESpecifierID.

If the application specific IE is not available, then it is not feasible to use the ASIE element in the beacon and if the PCA mode is available, control packets for association and dissociation may be transmitted using the PCA mode. If the PCA mode is used, user priority = 7, that is, AC = AC_VO must be used.

If application specific IE and PCA are not available, then DRP may be used. When using DRP, soft DRP may be used. If you use PCA mode, you must use user priority = 7, that is, AC = AC_VO. In the case of receiver-initiated association, the MAC header for the association request packet may be as follows.

Frame Control:

Retry: 0

Frame subtype/ Delivery ID:

When using PCA,

b12 = 0

user priority (b11-b9) = 7 (corresponding to voice; eg, AC = AC_VO)

When using DRP,

b12 = 1

Stream Index (b11-b9) = (between 8 and 15)

Frame Type (b8-b6): Data

ACK policy: 1 (Imm-ACK)

Secure: ?

Protocol Version : 0 (currently)

Access Information:

Access method: 0 (if PCA is used)

: 1 (if DRP is used)

More Frames: set accordingly

Duration: set accordingly

Dest Addr: Dev Addr of the sender

Src Addr: Dev Addr of the receiver

When using DRP, soft DRP may be used.

Data packets (eg, audio stream packets, video stream packets, etc.) may use DRP reservations on the forward and reverse links. Conventional MDDI control packets may use PCA mode if available. Otherwise, you should use DRP reservations.

21 illustrates a system 2100 for extending the functionality of a conventional wired configuration to enable communication over a wireless link. System 2100 includes a transmitter 2102 that communicates with a receiver 2104 over a forward link. Receiver 2104 communicates with transmitter 2102 over a reverse link. While the transmitter 2102 and the receiver 2104 may be devices that generally communicate via a wired protocol, the system 2100 allows such devices to communicate via a wired protocol and/or via a wireless protocol (eg, a high-speed wireless link). make it possible As will be appreciated, multiple transmitter(s) 2102 and receiver(s) 2104 may be included in system 2100 , however, for simplicity one A transmitter 2102 is shown.

The transmitter 2102 may include a host 2106 , a portion of a client C1 2108 , and a communication component 2110 . Host 2106 may be, for example, an MDDI host. According to some features, the host 2106 is a separate component from the transmitter 2102 and may be coupled to the transmitter 2102 via a wired link. A portion of the client (C1) 2108 is maintained on or communicates with the host 2106 for clock synchronization. The client C1 2108 may be connected to the host 2106 via, for example, a conventional wired link (eg, an MDDI link). Host 2106 may be configured to forward or transmit packets of data to client C1 2108 . These packets may be communicated to receiver 2104 via communication component 2110, which may include a modem, such as an ultra wide band (UWB) modem. Some packets (eg, MDDI Round-Trip Delay Measurement Packets) are processed by the client C1 2108 and delivered to the receiver 2104 . Other packets (eg, filler packets) should be dropped by the client C1 2108 and not forwarded to the receiver 2104 . That is, some packets must not be transmitted on the forward radio link or the reverse radio link. For example, the filler packet maintains timing between the transmitter 2102 and the receiver 2104 . Such packets may be generated by the transmitter 2102 or the receiver 2104 through respective client portions.

The receiver 2104 can include an interface device 2112 (eg, a display), a portion of a client C2 2114 , and a communication component 2116 . According to some features, device 2112 may be a separate component from receiver 2104 , and may be coupled to receiver 2104 via a wired link, for example. The client C2 2114 may be connected to the device 2112 via a wired link. Client (C2) 2114 may be configured to process packets received from sender 2102 . Receiver 2104 may receive communications from transmitter 2102 via communication component 2116 (which may include, for example, a UWB modem).

System 2100 may be configured to operate in one of two modes of operation. These modes include a low overhead mode and a low latency mode. In the low overhead mode, the client C1 2108 transmits data to be transmitted (eg, excluding fill packets and round trip delay packets) to the communication component 2110 (eg, a UWB modem). It is placed in a buffer that can be included in . Communication component 2110 may periodically request unidirectional channel time allocations (CTAs) from transmitter 2102 to receiver 2104 based on the size of the buffer, eg, via UWB MAC. In the reverse direction (eg, reverse link), client C2 2114 transmits reverse link data (eg, excluding filler packets) to be transmitted in association with communication component 2116 (eg, UWB modem). It can be placed in a buffer. In the reverse direction, communication component 2116 may request a reverse CTA.

For the low latency mode, during the initialization phase, the communication component 2110 (eg, UWB modem) may request a CTA for m msec in the forward direction and a CTA for n msec in the reverse direction. The expected traffic ratio in the forward and reverse directions is m:n, where m sec is the MDDI forward link transmission ratio (R_f_-_mddi) is the corresponding duration. T_CTAPis the duration of the CTA period and T is the superframe duration, which is determined by the latency constraints of the application.

(m + n) &lt; T_CTAP &lt; T

Referring now to FIG. 22 , shown is a system 2200 for communicating over a wired and/or wireless architecture. System 2200 includes a transmitter 2202 and a receiver 2204 that communicate over a forward link (from a transmitter 2202) and/or a reverse link (from a receiver 2204). Communication over the forward and/or reverse link may be over a wired protocol and/or a wireless protocol depending on the particular circumstances (e.g., the data to be transmitted, the data rate, the quality of the communication link, the state of each device, etc.) . As will be appreciated, multiple transmitter(s) 2202 and receiver(s) 2204 may be included in system 2200 , however, for simplicity one A transmitter 2202 is shown.

The transmitter 2202 can include a communication component 2210 and a host component 2206 coupled to a client (C1) component 2208 . The receiver 2204 can include a communication component 2216 and a device 2212 coupled to a client (C2) component 2214 . Client (C1) component 2208 and client (C2) component 2214 are respective parts of the client.

It will be appreciated by those skilled in the art that the transmitter 2202 and/or the receiver 2204 may include additional components. For example, the transmitter 2202 can include an encoder component (not shown) that modulates and/or encodes a signal according to a suitable wireless communication protocol, which can then be transmitted to a receiver 2204 . have. According to some features, the encoder component may be a speech coder (vocoder) or other type of encoder that uses a speech analyzer that converts an analog waveform into a digital signal. Suitable wireless communication protocols are Orthogonal Frequency Division Multiplexing (OFDM), Orthogonal Frequency Division Multiplexing Access (OFDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Global System for Mobile Communications (GSM), High -Speed Downlink Packet Access), etc., but is not limited thereto.

Receiver 2204 may include a decoder component (not shown) capable of decoding the received signal and/or data packets therein for processing. Upon successful decoding of the data packet, an acknowledgment component (not shown) may generate an ACK indicating successful decoding of the data packet, indicating that the data packet has been received and decoded and thus does not need to be retransmitted. may be sent to the transmitter 2202 to notify the transmitter 2202 that

The host component 2206 can include a query module 2218 and a measurement module 2220 . The query module 2218 may be configured to query the host MAC for the application data rate provided by the medium access control (MAC). For wireless communication, the operating speed may depend on the speed of the wireless link. The measurement module 2220 may be configured to determine the forward link speed and the reverse link speed based on, for example, a round trip delay measurement (which may be wireless protocol specific). According to some characteristics, the wireless operating speed may be determined by the minimum of two speeds (forward link speed and reverse link speed), the maximum capacity of the host 2206 and the maximum capacity of the client C1 2208 . Minimum allowable speed R_minmust exist If the measured operating speed is lower than this minimum allowable speed, the operating speed is set by the transmitter 2202 and/or the receiver 2204 to each component (eg, the communication component 2210 and/or 2216). can be adjusted through The transmitter 2202 may notify the receiver 2204 at which rate the communication will be processed.

The client (C2) component 2214 may include a notifier module 2222 that may be configured to notify the transmitter 2202 of the application data rate provided by the MAC. Such notification may be based on a query received from the transmitter 2202 (eg, a query sent by the query module 2218 ). For a reverse link packet, the notifier module 2222 may specify the number of bytes required by the receiver 2204 to transmit on the reverse link in the current frame. The client C2 component also has an allocator module 2224, which may be configured to assign communications to a wired protocol or a wireless protocol according to various parameters associated with the communications (eg, communication type, speed of communication, transmitter, receiver, etc.) ) may be included.

The communication component 2216 can include a wired module 2226 and a wireless module 2228 . The wired module 2226 may be configured to provide a wired function, and the wireless module 2228 may be configured to provide a wireless function. A determination may be made as to whether to communicate wirelessly using the wireless module 2228 or to communicate using the wired module 2226 . Such determination may include the speed of operation, the type of data being transferred (eg, voice, text, image, etc.), the size of the data or file being transferred, whether the data is typically transferred over a wired or wireless link, and the like. It can be based on a variety of factors. The wired module 2226 and/or the wireless module 2228 may include a buffer for storing content, so that in a communication process, from one module to another (eg, from wireless to wired, from wired to wireless) ) to ensure that communication is not lost due to switchover issues when changes are made.

Information regarding whether the receiver 2204 is communicating over a wired link or a wireless link need not be communicated to the transmitter 2202 . Transmitter 2202 performs its functions in substantially the same manner regardless of the communication method (wired or wireless).

According to some features, the transmitter 2202 may include a component (not shown) configured to fragment sub-frames, and the receiver 2204 may include a component (not shown) configured to recombine the sub-frames. can The maximum length of an MDDI sub-frame may be, for example, about 65,536 bytes, but is generally smaller. The maximum size of the 802.15.3 MAC frame may be approximately 4,096 or approximately 8,192 bytes when the underlying speed is approximately 480 Mbps. When the lower physical layer speed is about 200 Mbps, the size may be about 2,048 bytes. Thus, the sub-frames need to be fragmented at the transmitter 2202 side and recombined at the receiver 2204 side to accommodate the size of the frame. Such fragmentation and recombination may be performed by respective communication components 2210 and 2216 and/or other components associated with transmitter 2202 and receiver 2204 .

23 illustrates another feature of a system 2300 for extending a conventional wired configuration to enable communication over a wireless link. System 2300 can include a transmitter 2302 that includes a host 2306 , a portion of a client C1 2308 and a communication component 2310 . System 2300 can also include a receiver 2304 that includes a device 2312 , a portion of a client C2 2314 and a communication component 2316 . Transmitter 2302 communicates with receiver 2304 on the forward link, and receiver 2304 communicates with transmitter 2302 on the reverse link. As previously described with respect to the figures above, multiple transmitter(s) 2302 and receiver(s) 2304 may be included in system 2300 , however, for simplicity, a communication data signal may be converted into a single receiver 2304 ), one transmitter 2302 is shown.

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

Processor 2320 may be operatively coupled to receiver 2304 (and/or memory 2318) to facilitate analysis of information related to ascertaining whether a particular communication should be transmitted over a wired protocol or a wireless protocol. . The processor 2320 is 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 information received by the receiver 2304 . It may be a processor that analyzes and generates and controls one or more components of system 2300 .

Memory 2318 may store protocols associated with data communication rates, operating rates, actions for controlling communication between receiver 2304 and transmitter 2302, etc. may make available stored protocols and/or algorithms for obtaining enhanced communication of A data storage (eg, memory) component described herein may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. By way of example and not limitation, non-volatile memory may include read only memory ( ROM), programmable ROM ( PROM ), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which acts as external cache memory. By way of example and not limitation, RAM may include synchronous RAM (DRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchronized DRAM (SLDRAM), and It is available in various forms such as direct Rambus RAM (DRRAM). Memory 2318 of the disclosed features is intended to include, but is not limited to, these and other suitable types of memory.

24 shows a system 2400 for communicating with a conventional wired device over a wired link or a wireless link. System 2400 is represented by functional blocks, which may be functional blocks representing functions implemented by a processor, software, or a combination thereof (eg, firmware). System 2400 includes a receiver 2402 that may be configured to receive an operating rate for communication. This operating rate may be received, for example, from the transmitter or the transmitter host. The operating speed may set up or set the speed of communication in both forward and reverse directions. System 2400 also includes a wireless communicator 2404 that may be configured to transmit and/or receive communications via wireless protocols. Wired communicator 2406 may be configured to transmit and/or receive communications over a wired protocol.

There may be packet extensions and/or new packets in the forward and/or reverse direction. For example, MDDI transmitter information may be added to the packet in the forward direction. This packet extension may provide MDDI transmitter-side information to an MDDI client at the receiver end. This information may include the speed at which the MDDI host and client should operate on the transmitter side. In the reverse direction, the extension to the Client Function Packet may include about 4 bytes for the MDDI Receiver MAC information and about 2 bytes for the MDDI Receiver Client information, although other extensions are also possible.

System 2400 also includes a determiner capable of selectively determining whether to use a wireless communicator to communicate via a wireless protocol or a wired communicator to communicate via a wired protocol. Such determination may optionally be made based on various parameters such as speed of communication operation. Other parameters may also be analyzed to make a decision. For example, the manner in which a particular communication has been conventionally transmitted and/or received (eg, historical analysis), the type of communication (eg, voice, image, text, etc.), as well as the communication, transmitter and/or receiver A determination may be made based on other relevant parameters.

25 illustrates an exemplary forward link MDDI data transmission 2500 in a low overhead mode, in accordance with various features presented herein. One type of mode for the MDDI transmitter 2502 to pass data to the MDDI receiver 2504 may be a low overhead mode. In this mode, packets transmitted over the air are optimized for a channel assignment time, which is the time it takes for data to be transmitted in either direction (eg, forward or reverse). The MDDI transmitter 2502 may include a portion of the client (C1) 2506 and the MDDI receiver 2504 may include a portion of the client processing (C2; 2508).

The MDDI client (C1) 2506 may place the data to be transmitted in a buffer (eg, on the UWB modem). The data to be transmitted should exclude unnecessary packets such as fill capit and round trip delay packets, for example. The MDDI data is transmitted to the transmitter MAC 2510 as shown at 2512 . The transmitter MAC 2510 (or UWB MAC) requests at least one CTA from the MDDI transmitter 2502 to the MDDI receiver 2504, eg, periodically or continuously based on the size of the buffer.

The transmitter MAC 2510 may request (eg, periodically or continuously) a forward link CTA from the piconet controller (PNC) MAC 2516 at 2514 . The PNC MAC 2516 may respond to the transmitter MAC 2510 with a channel time response code at 2518 . This response code may indicate whether the data was delivered successfully. After a successful channel time response code is received, the transmitter MAC 2510 may transmit MDDI data to the receiver MAC 2520 as indicated at 2522 .

26 illustrates an exemplary reverse link MDDI data transmission 2600 in a low overhead mode, in accordance with various features presented herein. The MDDI receiver 2602 may initiate communication to the MDDI transmitter 2604 on the reverse link. The MDDI receiver 2602 may include a portion of a client (C2; 2606) and the MDDI transmitter 2604 may include a portion of a client (C1; 2608).

The MDDI receiver 2602 may transmit MDDI data to the receiver MAC 2610 as indicated at 2612 . The receiver MAC 2610 may request a reverse link CTA from the PNC MAC 2614 at 2616 . This request may correspond to data to be transmitted in the reverse direction. The PNC MAC 2614 may respond with a channel time response code at 2618 . The receiver MAC 2610 may transmit the MDDI data to the CTA at 2620 to the transmitter MAC 2622 . As indicated at 2624 , the transmitter MAC 2622 may have sent or given the MDDI data to the client ( C1 ; 2608 ) at 2624 at substantially the same time as or some time prior to receiving the MDDI data from the receiver MAC 2610 . The MDDI transmitter host 2626 may transmit and/or receive at least one reverse link encapsulation per frame as indicated at 2628 and 2630 . Reverse link data can be transmitted proactively without having to wait for data requests. The client may specify the number of bytes the client needs to transmit on the reverse link in the current frame. Host 2626 may correspondingly assign this request to a Reverse Link Encapsulation Packet.

27 illustrates a low latency mode MDDI connection establishment 2700 in accordance with various features presented herein. In the low latency mode, the channel allocation time can be ascertained based on inferences obtained from data contained in packets in both the forward and reverse directions. The MDDI transmitter 2702 may include a host 2704 and a portion of a client C1 2706 . During the initialization phase, the UWB modem on the transmitter 2702 may send a MAC query to the transmitter MAC 2708 at 2710 . A MAC query is a query sent to find out retransmission statistics and rates supported by the MAC. The transmitter MAC 2708 may respond to the query at 2712 . This response may be a MAC response indicating retransmission statistics and a rate supported by the MAC.

A MAC query packet is sent by the host to query the MAC information of the transmitter/receiver side. The Packet Length field is 2 bytes containing a 16-bit unsigned integer that specifies the total number of bytes in the packet excluding the Packet Length field. The Packet Type field is two 2 bytes containing a 16-bit unsigned integer. Packet type 151 identifies that the packet is a MAC query packet. The client ID is bytes containing a 16-bit unsigned integer reserved for the ID of the target client C2. The MAC Query Parameters field is 2 bytes, and the CRC field is 2 bytes containing the 16-bit CRC of all bytes in the packet including the packet length.

The transmitter 2702 requests CTA establishment 2714 for m msec in the forward direction and CTA for n msec in the reverse direction. The expected traffic ratio for forward and reverse should be m:n. At 2716 , a channel time request (CTRq) is sent to the PNC Mac 2718 . The channel time response code may be transmitted in the reverse direction 2720 and forward direction 2722 , and may be transmitted to the receiver MAC 2724 . The MDDI transmitter 2702 may initiate an MDDI transmission as shown at 2726 .

MDDI Forward Link Baud Rate (R_f_-_mddi) is m sec, and if T is the superframe duration determined by the latency constraint of the application, the following formula applies.

m + n &lt; T_CTAP &lt; T

In low latency mode, reverse link data may be transmitted during CTA reserved for reverse. Depending on the arrival time of the reverse link data in relation to the MAC super frame, the transmission may have a maximum latency expressed as

T_rl = ceil[{k * ( N / R₁ + RIFS + H/R₂) + SIFS + T_ACK} /n] * T

where k is the average number of retransmissions experienced by the MAC frame. N is the size of the reverse link packet to be transmitted and n is the reverse link CTA duration in each super frame. R₁is the physical layer data rate (MAC payload) of MDDI data. R₂is the physical layer data rate of the PHY, MAC header, and preamble. H is the size of the MAC plus the size of the PHY header plus the size of the preamble. SIFS is a short inter-frame spacing duration. RIFS is the interval duration between retransmission frames. T_ACKis the duration of the transmission of the ACK. T is the superframe duration. For the purpose of explanation, it is assumed that the ACK policy is Imm-ACK. The latency of the forward link packet (T_fl) can be determined accordingly. Given the application latency constraints of the forward and reverse links, the duration of the MAC frame can be obtained accordingly. For example, various algorithms, methods, and/or techniques may be used to obtain the duration of a MAC frame and/or the latency of a forward link packet.

A method is provided that may be implemented in accordance with one or more aspects with reference to the example systems shown and described. For simplicity of explanation, a method has been shown and described as a series of acts (or functional blocks), but since some acts may occur in a different order and/or with other acts than those shown and described in accordance with this method, the method is not It will be understood that it is not limited by the order of the operations. Also, not all illustrated operations may be required to implement the method below. It will be understood that the various operations may be implemented by software, hardware, combinations thereof, or any other suitable means (eg, device, system, process, component) for performing a function associated with the operations. It will also be understood that acts are merely illustrative of some features presented herein in a simplified form, which features may be described by fewer and/or more acts. Those skilled in the art will appreciate that a method may optionally be represented as a series of interrelated states or events, such as in a state diagram.

Referring now to FIG. 28 , illustrated is a method 2800 for configuring a conventional wired device to communicate via a wired protocol and/or a wireless protocol. At 2802 , a first portion of the client is located at the MDDI transmitter. The MDDI transmitter may be wireless and may be coupled to a data source. The MDDI transmitter may also include an MDDI host, which is connected or interfaced to the client part, for example by means of a conventional wired MDDI link.

At 2804 , a second portion of the client is located at an MDDI receiver, which may be a wireless MDDI receiver. The MDDI receiver may be coupled to a device, which may be, for example, a display. The portion of the client located at the MDDI transmitter and the portion of the client located at the MDDI receiver are separate portions of the same client. It should be understood that each part of the client may be implemented by a processor, software, or a combination thereof (eg, firmware).

Both wired and wireless functions are provided on the 2806. This function is included in the MDDI receiver to allow the MDDI receiver to communicate via wired function, wireless function, or both functions.

By way of example and not limitation, the MDDI receiver may be a mobile device capable of receiving communications (eg, a CRT screen or movie displayed on a display, etc.). The mobile device can also be connected to a wall-mounted display, allowing movies to be displayed on the wall for others to view. When the mobile device is versatile, the mobile device can broadcast a movie on a display and receive or transmit voice communications other than voice communications associated with the movie at substantially the same time. Thus, the user of the mobile device can have separate communication with the movie. One example where this can be used is when the user's child is watching a movie, and the user answers the phone and wants to walk away. Thus, the movie can be displayed through the wired function, and substantially simultaneously the user can communicate through the wireless function.

29 illustrates a method 2900 for determining an operating speed in accordance with one or more features disclosed herein. In wireless MDDI, for example, the MDDI operating speed depends in part on the speed of the wireless link. The method 2900 for determining an operating rate begins at 2902, where the host MAC is queried for available application data rates (eg, application data rates provided by the MAC). The query may be requested by the MDDI host, for example.

At 2904, a round trip delay is measured. The round trip delay measurements may be used at 2906 to determine or ascertain forward link speed and reverse link speed. According to some embodiments, the round trip delay measurement may be specified in the wired MDDI protocol to be used.

The operating speed is calculated at 2908. The operating speed may be calculated based in part on comparing the forward link speed and the reverse link speed and determining which of the two speeds is the minimum. The minimum of these two speeds can be designated as the operating speed. In some features, the minimum of these two speeds (forward link speed and reverse link speed) may further be compared to both the maximum capacity of the MDDI host and the maximum capacity of the MDDI client C1. A minimum or lowest speed based on this comparison may be determined as the operating speed.

Minimum allowable speed R_minmust exist, which may be set or predetermined based on the communication parameters. If the calculated operating speed is lower than the minimum allowable speed, an adjustment may be made to increase the speed. At 2910, the operating rate is communicated or transmitted to a receiver (eg, an MDDI receiver) to inform the receiver of the rate at which the communication will proceed.

In the method 2900, for example, the transmitter may query the host MAC via a query module. The transmitter may further use the measurement module to measure the round trip delay, determine the forward and reverse link speeds, and calculate the operating speed. The transmitter may also use a communication component to transmit an operating rate to the receiver. It should be understood that the above is for illustrative purposes only and that other components may be used with one or more features presented herein.

Referring now to FIG. 30 , illustrated is a method 3000 for communicating in a low overhead mode in accordance with various features presented herein. The forward link is shown on the left side of the figure, and the reverse link is shown on the right side of the figure.

At 3002, forward link data is placed in a buffer. Excluded from data placed in the buffer may be unnecessary data such as fill packets and/or round trip delay packets. This data may be placed in a buffer, for example by the MDDI client C1 on the MDDI transmitter. At 3004, a unidirectional CTA is requested (eg, periodically or continuously). The UWB MAC may request this information from the MDDI transmitter to the receiver, for example based on the size of the buffer. Forward link data may be transmitted at 3006 .

In the reverse direction, the host sends at least one Reverse Link Encapsulation Packet per frame. A client (eg, a receiver) may specify in the current frame the number of bytes that should be transmitted on the reverse link. A host (eg, a sender) may assign the request to a Reverse Link Encapsulation Packet. At 3008, the reverse link data to be transmitted is placed in a buffer, for example by the MDDI client C2. The buffer may be located in the UWB modem of the MDDI receiver. A request for reverse CTA is transmitted at 3010, for example, by a UWB modem at the MDDI receiver side. The request may be for a CTA in the reverse direction corresponding to data to be transmitted in the reverse direction.

The MDDI client C2 on the receiver may proactively transmit reverse link data to the client C1 on the transmitter at 3012 . As shown, at 3014 , the MDDI client C1 on the transmitter sends its own data to the MDDI host in a reverse encapsulation packet.

31 illustrates a method 3100 for communicating in a low latency mode in accordance with various features presented herein. The forward link is shown on the left side of the figure, and the reverse link is shown on the right side of the figure. During the initialization phase of the low latency mode, the UWB modem on the transmitter side requests a CTA for m msec in the forward direction, for example at 3102 . At 3104, a CTA request for n msec in the reverse direction is transmitted. A comparison of forward and reverse CTAs received in response to the request is made at 3106 . The expected traffic ratio for forward and reverse is m:n. m msec is the MDDI forward link rate (R_f_-_mddi) is the duration corresponding to

(m + n) &lt; T_CTAP &lt; T

, where T is the superframe duration, which may be determined by the latency constraints of the application.

In the reverse direction during low latency mode, reverse link data is transmitted during the reverse reserved CTA at 3108 . At 3110, the duration of the MAC frame may be obtained from application latency constraints of the forward and reverse links. In the following equation, k is the average number of retransmissions experienced by the MAC frame. N is the size of the reverse link packet to be transmitted, and n is the reverse link CTA duration in each superframe. R₁is the physical layer data rate (MAC payload) of MDDI data. R₂is the physical layer data rate of the PHY, MAC header, and preamble. H is the size of the MAC, the size of the PHY header, and the size of the preamble. SIFS is the short interframe interval duration. RIFS is the interval duration between retransmission frames. T_ACKis the duration of transmission of the ACK, and T is the superframe duration. For the purpose of explanation, it is assumed that the ACK policy is Imm-ACK. The latency of the forward link packet (T_fl) may be determined accordingly using various algorithms, methods and/or techniques. Depending on the arrival time of the reverse link data in relation to the MAC superframe, the transmission may have a maximum latency expressed as

T_rl = ceil[{k * ( N / R₁ + RIFS + H/R₂) + SIFS + T_ACK} /n] * T

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

When one or more remote user interface client devices (eg, wireless receivers) desire to associate with a wireless transmitter (eg, host entity), method 3200 begins by associating with the host entity at 3202 . Such association may include sending a packet requesting association. The host entity may wirelessly communicate substantially concurrently with more than one remote user interface client device. Once the association is established with the host entity, at 3204 a function packet is sent to the host entity. The function packet may include one or more functions of the remote user interface device. At 3206, a status packet is sent to the host entity. The status packet may include link quality information.

According to some features, a request is received from a host entity for an updated status packet. Substantially at the same time as the response is received, the status packet may be updated and sent to the host entity in response to the request. In another aspect, the updated status packet may be automatically sent periodically or when a status change is detected.

The association between the one or more remote user interface client devices and the host entity may be broken due to a communication failure or device moving out of range, or based on other factors. An association may be determined to be broken if a host entity status packet is not received within a predetermined period. For example, a timer may be started at substantially the same time that the Host Entity Status Packet is requested. A timer may be set to track an interval from the time the request was sent. The interval may be predetermined and should be long enough for a request to be received at the host entity and the host entity to respond. If the timer expires (eg, a response is not received within a predetermined interval), the one or more remote user interface client devices may be disassociated from the host entity.

Dissociation from the host entity may also occur when communication between devices should be interrupted. In such case, the one or more remote user interface client devices may disassociate from the host entity and enter a disassociated state. Dissociation may include sending a dissociation request to a host entity and receiving a dissociation response from the host entity. According to some features, a dissociation response may not be received from the host entity, for example in the event of a communication failure or in the event of a link or association broken between devices.

Referring now to FIG. 33 , illustrated is a method 3300 for high-speed wireless digital data communication between one or more remote receivers and transmitters for user interface data. A transmitter initiates an association when it wishes to associate with a particular radio receiver. For example, if the wireless transmitter is a phone and the wireless receiver is a projector, the phone (eg, wireless transmitter) will typically initiate the association process. A transmitter-initiated association is similar to a receiver-initiated association.

Method 3300 may begin at 3302 when a transmitter associates with one or more remote user interface devices via a transmitter initiated association. Such association may include sending a request to the receiver to cause an association to be established between the devices. The receiver may indicate, in response to this request, that association is possible (eg, the receiver is not associated with another transmitter). At substantially the same time as the devices are associated, a packet including capability information is received from the remote user interface device at 3304 , and link quality information is received (eg, over the reverse link) at 3306 . Information may be sent in response to a C2 request packet that may be sent by the wireless transmitter to the receiver requesting the receiver to transmit a client function packet. The C2 request packet may include packet length, packet type, C2 client ID, C2 flag and CRC fields. The Packet Length field is 2 bytes containing a 16-bit unsigned integer that specifies the total number of bytes in the packet excluding the Packet Length field. The packet type is 2 bytes containing a 16-bit unsigned integer. A packet type of 149 identifies that the packet is a C2 request packet. The C2 Client ID field is 2 bytes containing a 16-bit unsigned integer reserved for C2's ID. The C2 Flags field is one byte containing an 8-bit unsigned integer containing a set of flags for requesting information from C2. For example, if one bit is set to 1, C1 requests specific information from the client. If that bit is set to 0, C1 does not need that information from C2. Bit 0 indicates that C1 needs a Client Function Packet from C2. Bit 1 indicates that C1 needs a "Client Request and Status Packet" from C2. The CRC field is 2 bytes containing the 16-bit CRC of all bytes in the packet including the packet length.

In some situations, a transmitter may initiate an association but the receiver may already be associated with a different receiver or may not want to associate with this transmitter. In this situation, if the client C2 does not want to associate with the w-MDDI transmitter (after power is turned on), an Association Denial Packet will be sent by the client C2 in response to the association request. can The Association Reject Packet contains various fields including Packet Length, Packet Type 160, Transmitter MAC Address, Receiver MAC Address, Reason Code and CRC. The Packet Length is 2 bytes containing 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 2 bytes containing a 16-bit unsigned integer. A packet type of 160 identifies that the packet is an association reject packet. The transmitter Mac address may be the 6 byte MAC address of the W-MDDI transmitter, and the receiver MAC address may be the 6 byte MAC address of the W-MDDI receiver. The reason code is one byte indicating the reason for the rejection (0x1, 0x2, 0x3 or 0x4). 0x1 indicates that it has already been associated with another transmitter and cannot be associated any more. 0x2 indicates that association with another transmitter is in progress. 0x3 indicates a local error, and 0x4 is miscellaneous. The CRC field is 2 bytes containing the 16-bit CRC of all bytes in the packet including the packet length.

Another packet that may be transmitted is the MAC CTA Setup Packet used by the host to establish CTAs in the forward and reverse directions. It can be used in low latency mode of operation of w-MDDI with IEEE 802.15.3 MAC. If the MAC protocol allows the sender MAC to establish a reverse CTA, this packet will be dropped at the sender. Otherwise, this packet will be sent to the receiver. The content of the MAC CTA Setup Packet includes a Packet Length field which is 2 bytes containing a 16-bit unsigned integer that specifies the total number of bytes in the packet, excluding the Packet Length field. The Packet Type field is two 2 bytes containing a 16-bit unsigned integer. A packet type of 152 identifies that the packet is a CTA setup packet. The C1 Client ID field is 2 bytes containing a 16-bit unsigned integer reserved for the host's ID. The C2 Client ID field is 2 bytes containing a 16-bit unsigned integer reserved for C2's ID. Forward CTA (Forward CTA) parameters are CTA parameters for data transmitted in the forward direction, and Reverse CTA (Reverse CTA) parameters are CTA parameters for data transmitted in the reverse direction.

34 illustrates an apparatus 3400 for initiating device association in accordance with various aspects of the present invention. Apparatus 3400 is configured to communicate high-speed digital data and may be a wireless transmitter or receiver that it wishes to associate with a remote host device 3402 . Device 3400 may include memory 3404 that may be configured to store information. Such stored information may include a MAC address and/or a client ID (as received in an association response packet) associated with the device 3400 . For example, at substantially the same time as being associated with a particular wireless transmitter, the wireless receiver may store the MAC address of the remote host device 3402 or transmitter with which the apparatus 3400 is associated.

Device 3400 may also include a processor 3406 that may be configured to analyze information stored in memory 3404 . The processor 3406 may further selectively associate the apparatus 3400 with a remote host device 3402 . According to some features, the processor 3406 can associate the apparatus 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 packets are received from the remote host device 3402 after a predetermined interval and the maximum number of association requests sent is exceeded, the processor 3406 does not associate the apparatus 3400 with the remote host device 3402 . does not

Apparatus 3400 can further include a communication data component 3408 that can be configured to update MAC response packets with device MAC statistics for transmission to a remote host device 3402 . After entering the association state, the wireless receiver may transmit a MAC response packet periodically (eg, every mac_response_time msec). The host device 3402 may respond with a packet acknowledging receipt of the MAC response packet sent by the apparatus 3400 . If the device 3400 does not receive a response after a predetermined time interval (eg, a mac_response_fail_time msec period), the device 3400 can infer that it has disassociated from the host device 3402 and Stop sending. Apparatus 3400 and host device 3402 may be disassociated as described above. According to some features, the apparatus 3400 may transmit a MAC response packet when specifically requested by the host device 3402 .

Apparatus 3400 and remote host device 3402 may be intentionally or unintentionally disassociated. For example, the communication link between the apparatus 3400 and the remote user device 3402 may be lost due to a communication failure, devices moving out of range of each other, or other reasons. For example, if a dissociation request packet is received from the remote host device 3402 , the processor disassociates the apparatus 3400 from the remote host device 3402 substantially concurrently with receipt of the request. In another example, if a status packet is not received from remote host device 3402 in response to the transmitted update MAC response packet, processor 3408 indicates that apparatus 3400 and host device 3402 are no longer associated. It can be selectively disassociated based on inference.

According to some features, device 3400 may include a display component 3410 that may be configured to compile one or more alternate display information. Alternative display information may be associated with device 3400 . Display component 3410 may further be configured to communicate one or more alternative display information to remote host device 3402 . For example, if there is an alternate display associated with the wireless receiver, an Alternate Display Capability Packet may be transmitted to the remote host device 3402 .

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

According to some features, the apparatus 3500 may include a status timer 3508 that may be configured to determine whether a response to the transmitter association request has been received within a predefined interval. If a response is not received within a predefined interval, a next transmitter association request may be sent by the processor 3504 .

If dissociation from the remote user interface device is desired, the processor 3504 can selectively disassociate the remote device. For example, the processor 3504 may selectively disassociate if 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 terminal 3600 is shown. As will be appreciated by those skilled in the art, the detailed configuration of terminal 3600 may vary depending on the particular application and overall design constraints. Processor 3602 may implement the systems and methods disclosed herein.

Terminal 3600 may be implemented with front end transceiver 3604 coupled to antenna 3606 . The baseband processor 3608 may be coupled to the transceiver 3604 . The baseband processor 3608 may be implemented in a software-based architecture or other type of architecture. A microprocessor may be used as a platform for executing software programs that provide, among other things, control and overall system management functions. A digital signal processor (DSP) may be implemented as an embedded communications software layer, which executes application specific algorithms to reduce processing requirements on the microprocessor. DSPs 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.

Terminal 3600 may also include various user interfaces 3610 coupled to baseband processor 3608 . User interface 3610 may include a keyboard, mouse, touch screen, display, ringer, vibrator, audio speaker, microphone, camera, and/or other input/output device.

The baseband processor 3608 may include a processor 3602 . In a software-based implementation of the baseband processor 3608, the processor 3602 may be a software program running on a microprocessor. However, as those of ordinary skill in the art will readily appreciate, the processor 3602 is not limited to these features, and is capable of performing the various functions described herein by any means known in the art (any hardware configuration, software configuration, or a combination thereof). included) can be implemented. Processor 3602 may be coupled to memory 3612 for storage of data.

37 illustrates a receiver initiated association procedure 3700 when security is enabled in accordance with features disclosed herein. The w-MDDI receiver 3704 sends an association request packet 3706 to the w-MDDI transmitter 3702 . At this time, the devices are in a non-associated state. The w-MDDI receiver 3704 may enter an association response waiting state. The w-MDDI transmitter 3702 may respond with an association response packet 3708 . If no response is received, multiple association request packets may be sent up to a maximum number of restarts before expiration of a predefined time interval. Upon receiving the association response packet 3708 , a client function packet 3710 may be transmitted from the w-MDDI receiver 3704 to the w-MDDI transmitter. These three packets represent a three-way handshake 3712.

Devices may enter an associated state. Devices may remain in the associated state until a disassociation request is received/acknowledged and/or until no response is received for some link state packets.

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

38 illustrates a transmitter initiated association procedure 3800 when security is enabled in accordance with features disclosed herein. The w-MDDI transmitter 3802 sends a transmitter association request 3806 to the w-MDDI receiver. At this time, the devices are in a non-associated state. The device is in an association request waiting state. The receiver 3804 may respond with an association request 3808 . The w-MDDI transmitter 3802 responds with an association response 3810 , and a client capability packet 3812 is transmitted by the w-MDDI receiver 3804 (eg, the device is in a client capability dash state). The four packets are included in the 4-way handshake 3814 .

According to some features, an optional mutual authentication/key exchange 3816 may be performed. The W-MDDI receiver 3804 may send an Alternate Display Function Packet 3818 . Thereafter, a link state response packet 3820 may be transmitted. The w-MDDI transmitter 3802 may provide a transmitter link status packet 3822 to the w-MDDI receiver.

39 shows a host (transmitter) association state diagram 3900 . At 3902 , the host is in a disassociated state (eg, no association between the host and the client exists). To associate with a client, as indicated by line 3904 , the host sends a request to associate and enters a WaitingForAssociationRequest (WAReq) state 3906 . According to some features, in response to the association request, an association rejection may be received as indicated at 3908 . If an association rejection is received, the host returns to unassociated state 3902 .

Substantially concurrently with the association request being sent, a timer may be started at 3904 indicating the maximum time the client will be allowed to respond to the request. While waiting for a response from the client, the host may send multiple association requests (eg, retries) up to the maximum number of attempts. If the timer has not timed out and the number of retries has not exceeded the maximum number of retries (MAX_RETRIES), the host remains in WAReq state 3906 as indicated at 3910 . If the timer times out and/or the maximum number of retries is exceeded, the host enters the disassociated state at 3912 .

In response to the association request, an association request may be received at 3914 and the host moves to a WaitingForClientCapabilities (WCC) state 3916 . According to some features, the host may transition directly from the disassociated state 3902 to the WCC state 3916 if an association request 3918 is received while the host is in the disassociated state 3902 (eg, WAReq). Skip state (3906)).

Substantially concurrent with entering WCC state 3916, the host may start a timer to limit the amount of time to wait for a response from the client. The host may also send multiple requests for client function responses up to the maximum number of retries (MAX_RETRIES) as indicated at 3920 . If the timer times out and/or times out or MAX_RETRIES is exceeded, the host enters the disassociated state 3902 at 3922 .

Substantially concurrent with receiving the client function, at 3924 the host enters the association state 3926 . The host may remain in the associated state 3926 until a dissociation request is received from the client at 3928 . Substantially concurrent with receiving the disassociation request, the host transitions to a disassociated state 3902 .

According to some features, a timeout on the link state packet 3930 causes the host to move from the associated state 3926 to the non-associated state 3902 . In this situation, the host did not receive a link status packet (MAC response packet) for a period of mac_response_fail_time msec. Not receiving a link state packet for a predefined amount of time indicates that the client is no longer associated with the host. According to some features, the host may decide to disassociate as indicated at 3932 , and the host transitions from the associated state 3926 to the unassociated state 3902 .

40 shows a client association state diagram. At 4002, the client is in a disassociated state. A client association request is sent at 4004 , and the client enters a WaitingForAssociationResponse (WAResp) state at 4006 . Substantially concurrent with sending the request, a timer may be started at 4004 to allow the host to wait for an association response for a limited time interval. According to some features, the client may enter WAResp state 4006 when a transmitter association request is received at 4008 .

While waiting for an association response, the host may send multiple association requests 4004 up to the maximum number of requests. If the timer has not timed out and the number of retries has not exceeded the maximum number of retries (MAX_RETRIES), the host remains in the WAResp state 4006 as indicated at 4010 . If the timer times out and/or times out or exceeds the maximum number of retries MAX_RETRIES, the host transitions to the disassociated state at 4012 .

According to some features, in response to the association request, an association rejection may be received at 4014 . Associations may be rejected if the host is already associated with another client or for other reasons. Upon receipt of the association rejection, the client enters the unassociated state 4002 .

The client remains in WAResp state 4006 until an association response is received at 4016 . Substantially concurrent with receiving the association response, the client enters association state 4018 . The client waits until a dissociation request is received at 4020, until no responses are received for some link state packets at 4022, and/or at 4024 when the client (eg, user) wants to dissociate from the host. It may be maintained in the associated state 408 until . If any of these three events 4020 , 4022 , 4024 occur, the client returns to the unassociated state 4002 .

41 illustrates a system 4100 for wirelessly communicating data at high speed between a host entity and at least one remote wireless MDDI client capable device. System 4100 is represented as including functional blocks, which may be functional blocks representing functions implemented by a processor, software, or a combination thereof (eg, firmware).

The system 4100 includes a logical grouping 4102 that includes an electrical component 4104 for performing a service discovery process for gathering information related to a plurality of wireless MDDI client capable devices within a local area. According to some features, the information related to the plurality of wireless MDDI client capable devices includes a device name, a string identifier corresponding to a function and status indication of the device, the information being held locally.

Logical grouping 4102 also includes an electrical component 4106 for receiving a request to associate with at least one of a plurality of wireless MDDI client capable devices. The request may be received, for example, from a user.

Furthermore, logical grouping 4102 includes an electrical component 4108 for determining a security function of each of the plurality of wireless MDDI client capable devices and an electrical component 4110 for selectively performing a security association procedure. For example, a security procedure may be performed if all devices are secure and security is required for all devices. An electrical component 4112 for associating with at least one of a plurality of wireless MDDI client capable devices is also included.

According to some features, the logical group also includes an electrical component for forwarding a message to a lower layer to obtain a list of devices and an electrical component for receiving a response comprising the list of devices. The logical grouping also includes an electrical component for sending a packet to each of the devices included in the received list and an electrical component for receiving a response comprising a string identifier for each of the responding devices.

According to some features, the lower layer supports multicast. In this aspect, the logical group includes an electrical component for sending a service query packet to the multicast group to request information from the selected wireless MDDI client capable device. A multicast group is specified by a multicast address.

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

According to some features, the lower layer is UDP/IP. In this aspect, the logical group includes an electrical component for forwarding the service query packet to the multicast group on the UDP port. The logical group also includes an electrical component for joining the multicast group on the UDP port and an electrical component for receiving a service response from each device supporting w-MDDI.

Additionally, system 4100 can include a memory 4114 that holds instructions for executing functions associated with electrical components 4104 , 4106 , 4108 , 4110 and 4112 or other components. Although shown as being external to memory 4114 , it will be understood that one or more of electrical components 4104 , 4106 , 4108 , 4110 and 4112 may reside within memory 4114 .

42 illustrates a system 4200 for wirelessly communicating data with a host entity at high speed. The system 4200 is represented as including functional blocks, which may be functional blocks representing functions implemented by a processor, software, or a combination thereof (eg, firmware).

The system 4200 includes a logical grouping 4202 that includes an electrical component 4204 for sending a neighbor list message to a lower layer requesting a list of devices in the local area. An electrical component 4206 for receiving a list of devices in the local area is also included. Furthermore, logical grouping 4202 includes an electrical component 4208 for sending a query packet to each of the devices. An electrical component 4210 for receiving a response including a string identifier for the responding device is also included. A response is received before the expiration of the predetermined interval.

According to some features, the neighbor list message is a "Get Neighbor List" message, and the list of devices is received in a "Lower Layer Neighbor List Response" from a lower layer. According to some features, the query packet is a "w-MDDI service query" packet and the response is a "w-MDDI service response" packet (eg, discover receiver service). According to some other features, the query packet is a "w-MDDI host query" packet and the response is a "w-MDDI host response" packet (eg, sender service discovery).

If a response is not received before the expiration of the predetermined interval, the association is unsuccessful and the previous state is resumed. Logical grouping 4202 also includes electrical components 4212 for associating with the responsive device. According to some features, the lower layer supports multicasting and is wiMedia UWB MAC and/or UDP/IP. According to some features, logical grouping 4202 also includes electrical components for performing mutual security authentication.

Additionally, system 4200 can include a memory 4214 that holds instructions for executing functions associated with electrical components 4204 , 4206 , 4208 , 4210 and 4212 or other components. Although shown as being external to memory 4214 , it will be understood that one or more of electrical components 4204 , 4206 , 4208 , 4210 and 4212 may reside within memory 4214 .

It will be understood that the features described herein may be implemented by hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transferring a computer program from one place to another. A storage medium may be any available medium that can be accessed by a general purpose or special purpose computer. By way of example and not limitation, such computer-readable media may contain RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage device, or desired program code means of instructions or data structures. It may be used for storage or transport in any form and may include a general purpose or special purpose computer, or any other medium that can be accessed by a general purpose or special purpose processor. Also, any connection may be properly termed a computer-readable medium. For example, if the Software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio and microwave, coaxial Cables, fiber optic cables, twisted pair, DSL, or wireless technologies such as infrared, radio and microwave are included in the definition of a medium. The disks (disk and disc) used herein include compact disc (CD), laser disk, optical disk, digital versatile disc (DVD), floppy disk, and blu-ray disc. Usually, the data is reproduced magnetically, and the disc (discs) is optically reproduced data with a laser. Combinations of the above should also be included within the scope of computer-readable media.

The various illustrative logic, logic blocks, modules, and circuits described in conjunction with the features disclosed herein may be general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or as described herein. It may be implemented or implemented in other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the specified functions. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may be implemented as a combination of computing devices (eg, a combination of a DSP and a microprocessor, a plurality of microprocessors, a DSP core and one or more microprocessors, or other such configuration). Additionally, at least one processor may include one or more modules operable to perform one or more of the steps and/or operations described above.

For a software implementation, the techniques described herein may be implemented as modules (eg, procedures, functions, etc.) that perform the functions described herein. The software code may be stored in a memory unit and executed by a processor. The memory unit may be implemented within the processor or external to the processor, in which case the memory unit may be communicatively coupled to the processor through various means known in the art. Furthermore, at least one processor may include one or more modules operable to perform the functions described herein.

The techniques described herein may be used for a variety of wireless communication systems, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and other systems. The terms "system" and "network" are often used interchangeably. A CDMA system may implement a radio technology such as Universal Terrestrial Radio Access (UTRA), CDMA2000, or the like. UTRA includes Wideband-CDMA (W-CDMA) and other variants of CDMA. Furthermore, CDMA2000 covers the IS-2000, IS-95 and IS-856 standards. The TDMA system may implement a radio technology such as Global System for Mobile Communications (GSM). OFDMA systems include Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM® It is possible to implement a wireless technology such as UTRA and E-UTRA are part of the Universal Mobile Telecommunication System (UMTS). 3GPP Long Term Evolution (LTE) is a release of UMTS using E-UTRA, which uses OFDMA in the downlink and SC-FDMA in the uplink. UTRA, E-UTRA, UMTS, LTE and GSM are described in documents from an organization named "3rd Generation Partnership Project" (3GPP). Additionally, CDMA2000 and UMB are described in documents from an organization named "3rd Generation Partnership Project 2" (3GPP2). Furthermore, these wireless communication systems additionally often include peer-to-peer (e.g., mobile- two-mobile) ad hoc network system.

Moreover, various embodiments or features described herein may be implemented in a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. As used herein, the term "article of manufacture" is intended to include a computer program accessible from any computer-readable device, carrier, or medium. For example, computer-readable media include magnetic storage devices (eg, hard disks, floppy disks, magnetic strips, etc.), optical disks (eg, compact disks (CDs), digital versatile disks (DVDs), etc.) , smart cards, and flash memory devices (eg, EPROMs, cards, sticks, key drives, etc.). Additionally, the various storage media described herein may be representative of 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, holding, and/or carrying instruction(s) and/or data. Additionally, a computer program product may comprise a computer readable medium having one or more instructions or code operable to cause a computer to perform the functions described herein.

Furthermore, steps and/or operations of a method or algorithm described in conjunction with the features disclosed herein may be implemented directly in hardware, as a software module executed by a processor, or as a combination thereof. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. Optionally, the storage medium may be embodied in the processor. Further, in some features, the processor and storage medium may be in an ASIC. Additionally, the ASIC may reside in the user terminal. Optionally, the processor and storage medium may reside in discrete components of the user terminal. Additionally, in some features, the steps and/or operations of a method or algorithm are one or any set of instructions and/or codes on a machine-readable medium and/or computer-readable medium, which may be included in a computer program product. It can reside in a combination.

While the foregoing disclosure discusses exemplary features and/or features, various changes and modifications may be made thereto without departing from the scope of the described features and/or features as defined by the appended claims. Accordingly, the features described are intended to cover all such alterations, modifications and variations that fall within the scope of the appended claims. Furthermore, although described features and/or elements of features may be described and claimed in the singular, the plural is also contemplated unless limitations to the singular are explicitly stated. Additionally, any feature and/or part or all of a feature may be used in conjunction with any or all other feature and/or feature, except where stated otherwise.

As used in the specification or claims, the term "comprises" is intended to be inclusive in a manner analogous to the term "comprising" as would be interpreted when "comprising" is used as a conjunction in a claim. Furthermore, the term "or" as used in the specification or claims is intended to be "non-exclusive or".