Wireless architecture for traditional wire based protocol

(54) Title: WIRELESS ARCHITECTURE FOR TRADITIONAL WIRED PROTOCOL.

(51) Int. Cl .: H04L 29/06; H04W 8/00 (30) Unionist Priority: 7/24/2008 US

12 / 179,411, 7/24/2008 US 12/179,

41125/07/2007 US 60 / 951,919 (73) Holder (s): QUALCOMM INCORPORATED (72) Inventor (s): DINESH DHARMARAJU;

RANGANATHAN KRISHNAN; SOHAM SAETH (74) Attorney (s): MONTAURY PIMENTA, MACHADO & LIOCE (86) International Application: PCT US2008071147 of 25/07/2008 (87) International Publication: WO

2009/015322 of 01/29/2009

<img file="BRPI0814654A2_D0001.tif" />

WIRELESS ARCHITECTURE FOR TRADITIONAL WIRED PROTOCOL

RELATED REQUESTS

This order claims the benefit of United States Provisional Order 60 / 951,919, filed on July 25, 2007, entitled WIRELESS ARCHITECTURE FOR A TRADITIONAL WIRE-BASED PROTOCOL, which is fully incorporated herein by reference.

FUNDAMENTALS

FIELD OF THE INVENTION

The following description refers in general to communication systems and more particularly to enable the communication of traditional wire-based devices via a wireless link and / or a wired link.

DESCRIPTION OF RELATED TECHNIQUE

Wireless networking systems are used by many people for communication wherever the user may be located, at a specific time (for example, home, office, traveling, etc.). Wireless communication devices are increasingly smaller and more powerful (for example, increased functionality and / or applications; greater memory capacity) to meet the needs of users while improving portability and convenience. Users have discovered many uses for wireless communication devices including cell phones, personal digital assistants (PDAs) and the like. For example, wireless communication devices may include functionality to capture and process images (for example, still images, moving images, video games, and the like).

Applications and / or features that operate

2/111 using very high data rates can have substantial power requirements and / or high current levels. Such power requirements and / or current levels are readily available for devices that communicate using a wired protocol. However, wireless communication systems may not be able to operate using high data rates. Thus, the communication that a user wants to send and / or receive can be limited in some situations.

Some devices have traditionally operated only in a wired capacity, such as, for example, a Digital Mobile Display Interface (MDDI). Thus, a user who has such a device may not be able to communicate while mobile (for example, while on the move or on the move) and may need to spend additional expenses to obtain a wireless device, which may not always be practical. In some situations, a user may decide to operate two devices, one with wired capability and one with wireless capability to obtain the benefits of both devices. However, the costs associated with the two devices, as well as maintaining the monitoring of both devices, can impose an undue burden on the user.

SUMMARY OF THE INVENTION which follows presents a simplified summary of one or more aspects to provide a basic understanding of such aspects. This summary is not an extensive overview of all aspects considered, and is not intended to identify essential or crucial elements of all aspects, nor is it intended to outline the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified way as a prelude to the more

Detailed 3/111 that is presented later.

According to one or more aspects and corresponding disclosure thereof, several aspects are described in connection with the service discovery between a wireless MDDI host (w-MDDI) and a w-MDDI client for the devices to associate with each other and use each other's capabilities. Service discovery can be initiated by anyone between the host and / or the customer. Service discovery is accomplished through interaction with an underlying carrier protocol, which can be wiMedia UWM MAC and / or UDP / IP and / or can support multicasting. An optional mutual authentication can be performed before the device is paired.

One aspect concerns a method for wirelessly communicating data at a high rate between a host entity and at least one wireless, remote MDDI capable client device. The method includes performing a service discovery process to obtain information related to a plurality of wireless MDDI capable client devices in a local area and receiving an indication to associate with at least one of the plurality of wireless MDDI capable client devices. The method also includes determining the security capabilities of each of the plurality of wireless MDDI capable client devices and selectively performing a security association procedure. Additionally, the method includes the

<td>Association</td><td>with at least</td><td>one</td><td>of plurality</td><td colspan="2">of devices</td>

<td>from clients</td><td>MDDI capable</td><td>without</td><td>thread.</td><td></td><td></td>

<td colspan="2">Another aspect</td><td>if</td><td>refers to a</td><td>equipment</td><td>in</td>

<td>Communication</td><td>wireless</td><td>what</td><td>includes a</td><td>memory and</td><td>one</td>

<td>processor</td><td>The memory</td><td colspan="2">retain instructions</td><td>related</td><td>The</td>

conducting a service discovery process to compile information related to a plurality of

4/111 wireless MDDI capable client devices in a local area and receive a request to associate with at least one of the plurality of wireless MDDI capable client devices. The memory also retains instructions related to determining the security capabilities of each of the plurality of wireless MDDI capable client devices, performing a security association procedure, and associating with at least one of the plurality of MDDI capable client devices without thread. The processor is attached to the memory and is configured to execute instructions held in memory.

An additional aspect refers to wireless communication equipment that communicates data wirelessly at a high rate. The equipment includes a means to perform a service discovery process to compile information related to a plurality of wireless MDDI capable client devices in a local area and a means to receive a request to associate with at least one of the plurality of MDDI capable devices. wireless MDDI capable customers. Also included in the equipment is a means for determining the security capabilities of each of the plurality of wireless MDDI capable client devices, a means for selectively performing a security association procedure, and a means for associating with at least one of the plurality wireless MDDI capable client devices.

Yet another aspect concerns a computer program product that comprises a computer-readable medium. The computer-readable medium includes a first set of codes to have a computer perform a service discovery process to obtain information related to a plurality of wireless MDDI capable client devices in an area

5/111 location. The computer-readable medium includes a second set of codes to make the computer receive an indication for association with at least one of the plurality of wireless MDDI capable client devices and a third set of codes to make the computer determine the security capabilities of each of the plurality of wireless MDDI capable client devices. In addition, the computer-readable medium includes a fourth set of codes to cause the computer to perform a security association procedure, and a fifth set of codes to cause the computer to associate with at least one of the plurality of capable client devices.

MDDI without

Yet another aspect concerns at least one processor configured to communicate data at a high rate between a host entity and at least one wireless, remote MDDI capable client device.

processor includes a first module to perform a service discovery process to obtain information related to a plurality of wireless MDDI capable client devices in a local area and a second module to receive an indication for association with at least one of the plurality of devices of wireless MDDI capable customers. A third module is also included in the processor to determine the security capabilities of each of the plurality of wireless MDDI capable client devices. In addition, the process includes a fourth module for selectively performing a security association procedure and a fifth module for association with at least one of the plurality of wireless MDDI capable client devices.

Another aspect refers to a method for

6/111 wirelessly communicate data at a high rate with a host entity. The method includes transmitting a neighbor list message to a lower layer, the neighbor list message requests a list of devices in a local area and receiving a list of devices in the local area. 0 method also includes sending a host query packet to each of the devices; receiving a response that includes sequence identifiers for the responsive device, and selectively associating with the responsive device. The response is received before the expiration of a predetermined interval.

Another aspect concerns wireless communication equipment that includes a memory and a processor. The processor is attached to the memory and is configured to execute instructions held in memory. The memory retains instructions related to the transmission of a neighbor list message to a lower layer. The list of neighbors message requests a list of devices in a local area. The memory also retains instructions related to receiving a list of devices in the local area and sending a host query packet to each of the devices. In addition, the memory retains instructions related to receiving a response that includes sequence identifiers for the responsive device and selectively associating with the responsive device. The response is received before the expiration of a predetermined interval.

Yet another aspect concerns wireless communication equipment that communicates data wirelessly at a high rate. The equipment includes a means to send a list of neighbors message to a lower layer and a means to receive a list of devices

7/111 in the local area. The list of neighbors message requests a list of devices in a local area. The apparatus also includes a means for transmitting a host query packet to each of the devices and a means for receiving a response that includes sequence identifiers for the responsive device. The response is received before the expiration of a predetermined interval. A means for associating with the responsive device is also included.

Yet another aspect concerns a computer program product that includes a computer-readable medium. The computer-readable medium includes a first set of codes for having a computer transmit a neighbor list message to a lower layer. The list of neighbors message requests a list of devices in a local area. Also included in the computer-readable medium is a second set of codes to make the computer receive a list of devices in the local area and a third set of codes to make the computer transmit a host query packet to each of the devices. Also included is a fourth set of codes to make the computer receive a response that includes sequence identifiers for the responsive device and a fifth set of codes to make the computer associate with the responsive device. The response is received before the expiration of a predetermined interval; and

A further aspect concerns at least one processor configured to communicate data at a high rate. The process includes a first module for transmitting a neighbor list message to a lower layer and a second module for receiving a list

8/111 of devices in the local area. The list of neighbors message requests a list of devices in a 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 that includes sequence identifiers for the responsive device. The response is received before the expiration of a predetermined interval. A fifth module is also included in the processor for selectively associating with the responsive device.

For the realization of the aforementioned and related purposes, one or more aspects comprise the features described below completely and particularly noted in the claims. The following description and the details detail certain aspects. These resources attached drawings demonstrate in illustratives of one or more are, however, indicative of only a few diverse ways in which the principles of the various aspects can be employed. Other advantages and novel features will become evident from the detailed description below when considered together with the drawings and the revealed aspects are intended to include all such aspects and their equivalents.

BRIEF DESCRIPTION OF THE FIGURES

Figure 1 illustrates a block diagram of a system to enable a wired device

<td colspan="3" rowspan="2">traditional THE</td><td colspan="4">communicate in the way</td><td colspan="3">wireless.</td>

<td>Figure</td><td> 2</td><td>illustrates</td><td>an</td><td>pile of</td><td>protocols</td><td>MDDI</td>

<td>without</td><td>thread.</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td>

<td></td><td></td><td>THE</td><td>Figure</td><td> 3</td><td>illustrates</td><td colspan="2">another stack of</td><td>protocols</td><td>MDDI</td>

<td>without</td><td>thread.</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td>

<td></td><td></td><td>THE</td><td>Figure</td><td> 4</td><td>illustrates</td><td>one</td><td colspan="3">wireless emitter according</td>

with one or more aspects.

9/111

Figure 5 illustrates another wireless emitter that includes a co-located MDDI host and client (Cl).

Figure 6 illustrates another example of a wireless emitter.

Figure 7 illustrates a wireless receiver according to the revealed aspects.

Figure 8 illustrates a method for wMDDI association.

Figure 9 illustrates a system for service discovery according to the revealed aspects.

Figure 10 illustrates an Application Specific IE (ASIE) format.

Figure 11 illustrates an application-specific polling information element (AS polling IE) on wiMedia MAC.

Figure 12 illustrates a method for communicating high-rate digital data wirelessly using

<td>the association</td><td>initiated</td><td>by the receiver.</td><td></td><td></td><td></td>

<td>THE</td><td>Figure 13</td><td>illustrates a method</td><td>for</td><td>Communication</td><td>in</td>

<td>data without:</td><td colspan="2">high rate yarn between</td><td>one</td><td>sender and</td><td>one</td>

<td colspan="2">remote receiver.</td><td></td><td></td><td></td><td></td>

<td>THE</td><td>Figure</td><td>14 illustrates a</td><td colspan="3">procedure for</td>

<td>authentication</td><td>mutual and</td><td>key exchange.</td><td></td><td></td><td></td>

<td>THE</td><td>Figure</td><td>15 illustrates a</td><td colspan="2">procedure</td><td>in</td>

<td>dissociation</td><td>initiated</td><td>by the receiver.</td><td></td><td></td><td></td>

Figure 16 illustrates a method for receiver-initiated decoupling between a user device and a host entity.

Figure 17 illustrates a decoupling procedure initiated by the issuer.

Figure 18 illustrates a method for selective decoupling between a transmitter and a remote receiver.

Figure 19 illustrates a single wireless emitter in

10/111 association with multiple wireless receivers according to the revealed aspects.

Figure 20 illustrates an exemplary device association table.

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

Figure 22 illustrates a system for communication through wired and / or wireless architectures.

Figure 23 illustrates another aspect of a system for extending traditionally wired configurations to allow communication over a wireless link.

Figure 24 illustrates a system for communicating over a wired link or over a wireless link with a traditional wired device.

Figure 25 illustrates an exemplary direct link MDDI data transfer, in low overhead mode, secondary according to the various aspects presented here.

Figure 26 illustrates an exemplary reverse link MDDI data transfer in low overhead, secondary mode, according to the various aspects presented here.

Figure 27 illustrates an MDDI connection configuration in low latency mode according to the various aspects presented here.

Figure 28 illustrates a methodology for configuring a traditionally wired device for communication via a wired protocol and / or a wireless protocol.

Figure 29 illustrates a methodology for determining an operating rate according to one or more aspects revealed.

11/111

Figure 30 illustrates a methodology for communicating in the mode of low secondary expenses according to the various aspects presented here.

Figure 31 illustrates a methodology for communicating in low latency mode according to the different aspects presented here.

Figure 32 illustrates a method for wireless communication of digital data at a high rate, which can be initiated by a receiver.

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

Figure 34 illustrates a device that initiates device association according to the various aspects.

Figure 35 illustrates equipment that can be configured to wirelessly communicate high-rate user interface data.

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

Figure 37 illustrates an association procedure initiated by the receiver when security is enabled according to the revealed aspects.

Figure 38 illustrates an association procedure initiated by the issuer when security is enabled according to the revealed aspects.

Figure 39 illustrates a host association status diagram.

Figure 40 illustrates a customer association status diagram.

Figure 41 illustrates a system for communicating data wirelessly at a high rate between a host entity and at least one client device

12/111 MDDI capable wireless remote.

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

DETAILED DESCRIPTION OF THE INVENTION

Several aspects are now described with reference to the drawings. In the following description, for the purposes of explanation, several specific details are presented to provide a complete understanding of one or more aspects. It may be evident, however, that such an aspect (s) can be practiced without these specific details.

In other instances, well-known device structures are shown in the form of a block diagram to facilitate the description of these aspects.

As used in that order, the terms component, module, system, and refer to a related hardware, firmware, a combination of similar intended computer be it hardware and software, software, or running software. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable, a flow of execution, a program, and / or a computer. As an illustration, both an application running on a computing device and the computing device can be a component. One or more components can reside within a process and / or flow of execution and a component can be located on a computer and / or distributed between two or more computers. In addition, these components can perform various computer-readable media having several data structures stored in them. Components can communicate through local processes and / or

Remote 13/111 such as according to a signal having one or more data packets (for example, data from one component interacting with another component on a local system, distributed system, and / or over a network such as Internet with other systems using the signal).

In addition, several aspects are described here in connection with a mobile device. A mobile device may also be referred to, or may contain some or all of the functionality of a system, subscriber unit, subscriber station, mobile station, mobile, wireless terminal, node, device, remote station, remote end, access terminal , user terminal, wireless communication device terminal, wireless communication equipment, user agent, user device, or user equipment (UE). A mobile device can be a cell phone, a cordless phone, a Session Initiation Protocol (SIP) handset, a smart phone, a local wireless mesh station (WLL), a personal digital assistant (PDA), a laptop, a handheld communication device, a handheld computing device, a satellite radio, a wireless modem card and / or other processing device for communicating over a wireless system. In addition, several aspects are described here in connection with a base station. A base station can be used to communicate with the wireless terminal (s) and can also be named, and can contain some or all of the functionality of an access point, node, Node B, e-NodeB, e-NB, or some other network entity.

Various aspects or features will be presented in terms of the system which may include some devices, components, modules and the like. It must be understood and considered that the various systems can

11/14 include additional devices, components, modules, etc. and / or may not include all devices, components, modules, etc. discussed in connection with the figures. A combination of these approaches can also be used.

Referring now to the drawings, Figure 1

<td>illustrates a diagram</td><td>blocks of a 100 system to</td>

<td>enable a</td><td>traditional wired device if</td>

<td>communicate in the form</td><td>in wire. The various aspects here</td>

revealed can be applied to generic wireless video,

Distributed MACs, distributed resources, non-hierarchical wireless network MACs, and so on. System 100 includes a transmitter 102 in wired and / or wireless communication with a receiver 104. Transmitter 102 and receiver 104 can be components that traditionally communicate via a wired protocol. Although a number of transmitter (s) 102 and receiver (s) 104 may be included in system 100, as will be considered, a single transmitter

102 which transmits communication data signals to a single receiver 104 is illustrated for simplicity purposes.

Transmitter 102 and receiver 104 can be Mobile Display Digital Interface (MDDI) devices. In the following detailed description, several aspects are described in the context of MDDI devices and / or access control layer (MAC) of the Institute of Electrical and Electronic Engineers (IEEE) 802.15.3.

Those skilled in the art will readily find that these aspects are similarly applicable for use in several other traditionally wire-based protocols. Consequently, any reference to an MDDI and / or IEEE 802.15.3 MAC is only intended to illustrate the inventive aspects, with the understanding that such inventive aspects have a wide range of applications.

15/111

Communication sent from transmitter 102 to receiver 104 is referred to as the direct link (for example, data from the host to the client moves in the forward direction) and communication sent from receiver 104 to the transmitter 104 is referred to as the reverse link (for example, data from the client to the host moves in the reverse direction).

The information transmitted via the MDDI link (for example, direct link, reverse link) is grouped into packets. Multiple packages are grouped together in a subframe and multiple subframes constitute a media frame. Each subframe begins with a special package, referred to as a subframe header package. The reverse link packet transmissions are not controlled by the host. Whenever the w-MDDI receiver intends to transmit packets on the reverse link, the receiver sends the packets directly to the w-MDDI sender via an underlying wireless MAC.

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

According to some aspects, the transmitter is a host-MDDI that wishes to associate with one or more MDDIclients (for example, receiver (s) 104). The term host is used here interchangeably with the term emitter and / or device, depending on the context of how that term is used. Additionally, the term customer can be used interchangeably with the terms receiver and / or device, depending on the context of how that term is used.

16/111

If the host MDDI wishes to associate with an MDDI receiver to communicate data wirelessly at a high rate between devices, the host performs a service discovery process. The service discovery process requests information related to a plurality of wireless MDDI capable client devices in a local area. During the service discovery process, the w-MDDI host receives information related to a large number of wireless w-MDDI capable client devices. The information includes a sequence identifier corresponding to a device name, device capabilities, and a status indication. This information can be retained locally on the w-MDDI host.

According to some aspects, during the service discovery process the w-MDDI host transmits a message to a lower layer to obtain a list of devices in a local area that supports w-MDDI. The bottom layer responds with a list of devices and the host w-MDDI sends a packet to each of the devices included in the received list. Devices that wish to participate send a response that contains sequence identifiers to each of the responsive devices.

After the service discovery process, the w-MDDI host determines the security capabilities of each of the wireless w-MDDI capable client devices (for example, client security is enabled, the client requires security). The w-MDDI host can display a list of devices and the user can select one or more of the devices. After receiving the selection, the w-MDDI host selectively performs a (mutual) security association procedure (if necessary) and associates with at least one of the devices

17/111 of wireless MDDI capable customers.

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

If the bottom layer is wiMedia UWB MAC, the w-MDDI host can receive application-specific information elements related to each of the w-MDDI capable client devices. If the bottom layer is UDP / IP, the w-MDDI host transmits a service query packet to a multicast group on a UDP port, joins the multicast group on the UDP port and receives a service response from each device that supports w-MDDI.

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

Right after 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 of the devices. In response to that message, each device transmits a response that includes sequence identifiers to the

18/111 responsive device. The response must be received before the expiration of a predetermined interval. The wMDDI client selectively associates with at least one of the responsive devices. If a response is not received before a predetermined interval has expired, the association is unsuccessful and the w-MDDI client returns to a previous state (for example, the state the wMDDI client was in before starting the process. Association).

The various aspects revealed here can preserve the MDDI link and package structure so that the advantageous features of MDDI (for example, partial screen updates, user data packages, control and status packages, and so on) can be preserved. Additionally, the MDDI protocol can run over high-speed wireless AMC, which provides non-hierarchical network communication. Additionally, wireless MDDI does not interfere with the operation of the wireless MAC.

Figure 2 illustrates a wireless MDDI protocol stack 200. The wireless MDDI protocol is generic and can operate on a variety of high-speed wireless technology. Examples of high-speed wireless technology include WiMedia Ultra Wide Band (UWB), WiFi, lxEVDO, and so on. As illustrated in the vertical stack 200, a video / multimedia layer 202 can run on top of a wireless MDDI layer (w-MDDI) 204. In addition, an underlying MAC layer 206 is included, which can be 802.11, wiMedia UWB MAC, 802.15.3 UWB Mac, a generic, high-speed wireless MAC, and so on. The MDDI 200 protocol stack also includes a Physical (PHY) 208 layer, which can be an 802.11, wiMedia UWB, generic, high-speed wireless PHY, and so on.

19/111

The MAC layer 206 and the corresponding PHY layer 208 can be any high-speed, generic interface. The illustrated MDDI protocol stack 200 is operating over a generic high-speed L2, which is a term for the MAC and Link layer in a wireless communication network.

Figure 3 illustrates another wireless MDDI protocol stack 300. This figure illustrates the operation of wireless MDDI (w-MDDI) over User Datagram Protocol (UDP) over Internet Protocol (IP), which is another way in which the w-MDDI can operate. Included in protocol stack 300 is a video / multimedia layer 302. Since w-MDDI 304 is generic, it can work on top of L2, which is the MAC 306 layer and the PHY 308 layer, or other layers (for example, L3, L4). As illustrated, w-MDDI 304 is working similar to an application layer.

In this figure, w-MDDI 304 is operating on top of UDP 310 and IP 312, which is similar to a media application (for example, media player, Voice over Internet Protocol (VoIP), and so on) or a client protocol in real time. Having a UDP layer 310 and an IP layer 312 that can enable a client and a host to reside in different locations and connect via an Internet connection or other type of connection. For example, a display may be located in Paris, France, and a host may reside in Dallas, Texas. The w-MDDI can be used to transport the display (for example, multimedia data) over the Internet to the host (or vice versa). This operation can be similar to a remote desktop application, however, the illustrated protocol 300 can enable the host to trigger communication to the client (for example, display).

A wireless channel can cause packet errors.

20/111

In the wireless MDDI architecture, revealed here, an assumption is that the underlying lower layer (eg, wireless MAC) provides reliability mechanisms, such as packet retransmission to alleviate the application packet error rate as experienced by Wireless MDDI. Thus, additional reliability mechanisms in the wireless MDDI layer are not discussed here. However, according to some aspects, there may be reliability mechanisms in the wireless MDDI layer.

According to some aspects, when the underlying bottom layer is UDP / IP, w-MDDI is registered on a standard UDP port WMDDI__UDP_CONTROL_PORT. WMDDI also opens a UDP port WMDDI_UDP_DATA_PORT for data traffic. Devices capable of w-MDDI sender / receiver may well associate with a WMDDI_CONTROL_MULTICAST group with multicast IP address WMDDI_CONTROL_MULTICAST_IP.

Figure 4 illustrates a wireless emitter 400 according to one or more aspects. Wireless emitter 400 can be configured to communicate high data rate, such as signal data. The various wireless systems described here may include a wireless transmitter and a wireless receiver. The wireless emitter 400 may include an MDDI host 402 and a special MDDI client (CI) 404. The MDDI client (s) is a portion of a traditional MDDI client, not the full MDDI client. The MDDI (Cl) 404 client could not be associated with a display or device. Host 402 and client (Cl) 404 can be connected over a traditional high data rate link (for example, MDDI link) 406. The client that contains module (Cl) 404 can communicate via a wireless modem 4 08, such as an ultra-wideband modem that includes a UDB MAC, and a UWB PHY. According to some aspects, the 408 wireless modem can be any high-speed modem. 0 host

21/111

402 and the (Cl) 404 client can be operatively connected over an existing wired link, such as an MDDI link or a link configured to support high rate data. According to some aspects, if Client (Cl) 404 and modem 408 were connected to a wired link, host 402 may need to update to handle wireless functionality, which will be described in additional detail below. The configuration illustrated in Figure 4 can be referred to as type A wireless MDDI transmitter (wMDDI).

Figure 5 illustrates another wireless transmitter 500 that includes a co-located MDDI host 502 and a client (Cl) 504. According to some aspects, host 504 and Client Cl 504 can be co-located in the same software module and / or hardware. Host 504 and client (Cl) 504 can be connected to a 506 high-speed wireless modem. The configuration shown in Figure 5 can be referred to as type B w-MDDI transmitter.

Another example of a wireless emitter 600 is illustrated in Figure 6, in which the host and Cl are consolidated (or collapsed) into a single hardware and / or software entity (Emitter w-MDDI) 602. A high-speed wireless modem speed 604 is included to facilitate wireless communication. The configuration illustrated in Figure 6 can be referred to as w-MDDI type C transmitter.

Referring now to Figure 7, a wireless receiver 700 is illustrated according to the disclosed aspects. The wireless receiver 700 includes MDDI (C2) 702 client processing, which can be connected to multiple devices and displays 704 (only one display is shown for simplicity). Client (C2) 702 can be configured to process and generate high-rate digital data packets. According to some aspects, customer (C2) 702 does not

11/22 has a physical layer from an MDDI stack. According to several aspects, a single MDDI transmitter can be connected to several MDDI receivers.

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

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

A MAC query is a query to determine the rate supported by the relay and MAC statistics. The MAC Lookup message includes a message ID that is two bytes that contains a 16-bit unsigned integer. The message ID of 0x0 indicates the packet as a MAC lookup message. Also included are MAC Lookup parameters that are two bytes.

Figure 8 illustrates a method 800 for w-MDDI association. Methodologies that can be implemented according to the revealed study material will be better considered with reference to the various flow charts. Although, for the sake of simplicity of explanation, the methodologies are shown and described as a series of blocks, it should be understood and considered that the claimed study material is not limited by the number or order of the blocks, since some blocks may occur in

23/111 different orders and / or substantially at the same time with other blocks from what is illustrated and described here. In addition, not all illustrated blocks may be required to implement the methodologies described here. It should be considered that the functionality associated with the blocks can be implemented by software, hardware, a combination of them or any other suitable means (for example, device, system, process, component). Additionally, it must be considered additionally that the methodologies disclosed below and throughout this specification can be stored in an industrial product to facilitate transport and transfer of such methodologies to various devices. Those skilled in the art will understand and consider that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram.

Method 800 is described from a user's perspective (for example, user device, mobile phone, laptop, and so on). The 800 method begins, at 802, when a user with a host device initiates a search for w-MDDI capable client devices. The search can be started when a user enters an area (for example, room, building, and so on) and starts searching for w-MDDI capable client devices. Several mechanisms can be used to allow the user to start the search. For example, a user interface can provide functionality (for example, button on the device, icon on a display screen, and so on) to request the search.

In 804, the host retrieves a list of devices from w-MDDI capable clients. According

24/111 some aspects, capable client devices have string identifiers corresponding to their names, their capabilities (for example, screen resolution, whether compressed and / or uncompressed packages can be accepted, security capability, and so on below), a status indication, as well as other information. Examples of the appearance of the device information include: Non-associated / Available Environment L-601 Projector Display, Associated / Not Available Plasma Home Theater Display, Non-associated / Not Available ABC PC Keyboard, and so on . According to some aspects, the w-MDDI emitter

<td>can keep</td><td>a list of</td><td>w-MDDI receivers</td><td>responsive</td><td>The</td>

<td>solicitation</td><td colspan="3">search engines (for example, on a medium</td><td>in</td>

<td>storage</td><td>readable by</td><td>computer).</td><td></td><td></td>

<td>a</td><td>device</td><td>with which</td><td>connect</td><td>is</td>

<td>selected,</td><td>in 806.</td><td>Various techniques</td><td colspan="2">can be</td>

used, such as presenting the device listing on a display and allowing the user to select the device (for example, by highlighting the device name and pressing the enter key), providing a verbal command (for example, speaking the device name or other identifier associated with the desired device). In another example, the user can press a button on a host's user interface to trigger device selection.

In 808, an Association Denied message can be received. It should be noted that this message is received only if the association cannot be completed successfully, as denoted by the dashed line. The message can be displayed on a user interface (for example, screen) or through another means (for example, audibly through a speaker). This message can be received if the desired device is already associated

25/111 to another host and therefore deny the association.

The message Association Denied could be received if the device was already connected to another host. According to some aspects, the message can be received if the device is stuck or cannot dissociate from its previous host. In this situation, if the user is in control of the device and is a genuine user (for example, if this display is not being used by any other user), the user can force the device to dissociate itself from its previous host through various techniques (for example, resetting the device). For example, the user can press a button on the device's user interface and try again to start the association.

When the association process is successfully completed, the host and the w-MDDI capable client device can provide several ways to confirm the association. Client / host authentication can include a key exchange or other type of security procedure. For example, the host and the w-MDDI capable client device can render a common (short) number on their respective displays.

In 810, a message related to the association can optionally be received, as indicated by the dashed line. Several scenarios can occur regarding the association. For example, if the association was unsuccessful, a host display or the device display (or other means of providing information (for example, visual, audio)) can render a message corresponding to the Unsuccessful Association. In this situation, a time recorder associated with the association procedure expires. When the time recorder expires, the device returns to the state in which the devices

26/111 were before the association process started (for example, as if the association attempt was not made).

Another type of message can refer to security-capacity. For example, either or both, the host and the device, are not capable of security, but it is acceptable for both devices to continue with non-secure communication. This could occur if one of the devices is not capable of security. In this situation, a message can be provided which is displayed on either or both devices (host and client) indicating that the communication is not secure. According to some aspects, the information related to proceeding with the insecure communication can be negotiated during an initial capacity change (for example, in 804 when the device listing is received). In this situation, if the user wishes to confirm the association (for example, cancel the unsecured communication message), the user can press a button on the host or perform an equivalent action to confirm the association.

In another example, if both devices are secure and want to communicate over a secure link and the security check (authentication) is unsuccessful, a message related to this can be rendered on a display or through another middle. If one of the devices wishes to use security, but the other device does not have security capabilities, a message such as non-available security hardware can be rendered.

In another example, the message related to the association can be a value (for example, numeric association) or another means of confirming the association. If a value is used and the displays of both devices

27/111 of w-MDDI capable clients and w-MDDI host combine, this indicates a successful and secure association. In this situation, if the user wishes to confirm the association, the user can press a button on the host or perform a similar action to confirm the association.

If the values ​​do not match, it indicates that the host and the device have not been able to authenticate each other and there may be an intermediary. In this situation, the host and the device could expire (for example, a register associated with the association procedure expires). When the devices expire, the devices return to the state the devices were in before the pairing process started.

w-MDDI protocol of the revealed aspects refer to dynamic association and dissociation and / or provision for a single w-MDDI emitter for association and communication with multiple w-MDDI receivers. Figure 9 illustrates a 900 system for service discovery according to the revealed aspects. A w-MDDI 902 transmitter must obtain a list of w-MDDI 904 receivers (only one receiver is illustrated for simplicity) with which the w-MDDI 902 transmitter can associate. This association procedure is performed through a service discovery procedure.

sender w-MDDI 902 can be configured to initiate a service discovery process for searching for w-MDDI 904 receivers (for example, receiver service discovery). The discovery process service can be started through user interaction or automatically (for example, when the issuer 902 has recognized that a new location (for example, room) has been introduced).

Included with the w-MDDI 902 emitter is a device list requestor 906 that is configured to

11/28 transmit a request to 904 discovery receivers in the area. For example, a get neighbors list message can be transmitted to the bottom layer to get a list of devices (for example, 904 receivers) that are in the wireless (or wired) neighborhood (for example, communication area) of the sender w -MDDI 902. Substantially at the same time as receiving the message, the lower layer can respond with a Lower Layer Neighbor List Reply Message that includes a list of devices that are in the vicinity of the requesting device (emitter w-MDDI 902).

The Lower Layer Neighbor List Response Message includes a two-byte message ID that contains a 16-bit unsigned integer. A message ID of 0x7 identifies the packet as a MAC Address Reply message. Some neighbors are also included, which have two bytes that specify the number of neighbors for the current device (sender / receiver). A neighbor's Lower Layer address (MAC layer) is also included - 1- Lower Layer Address (MAC layer address).

Also included in the w-MDDI sender 902 is a service query identifier 908 that is configured to transmit a w-MDDI Service Inquiry packet to each neighbor (for example, to each individual receiver according to some aspects). The wMDDI receiver 904 can include a responsive service capabilities notifier 910 with a w-MDDI Service Response package that can include availability and sequence identifiers for the w-MDDI receiver. The wMDDI Service Response Packet packet length can be two bytes that contains a 16-bit unsigned integer that specifies the total number of

29/111 bytes in the packet, not including the packet length field. A packet type field can be two bytes and can 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 that includes a six-byte MAC address of the w-MDDI receiver. A sender's MAC address field includes a six-byte MAC address of the wMDDI sender, which can be a broadcast or multicast address, if multicast / broadcast services are used. A Receiver Parameters field can include a 256-byte sequence identifier for the w-MDDI receiver and its capabilities. In addition, the service response packet w-MDDI includes a CRC field that is two bytes long and contains a 16-bit CRC of all bytes in the packet, including the Packet Length field.

The w-MDDI 902 issuer can wait for the w-MDDI Service Response package until a time recorder expires (for example, a value from a service_discovery_timer). If the response is not received before the time recorder expires, the association has failed. A user of the w-MDDI 902 transmitter can select a w-MDDI 904 receiver to associate with, if the response is received before the time recorder expires.

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

According to some aspects, the w-MDDI 904 receiver can search for w-MDDI 902 transmitters (for example, sender service discovery). The w-MDDI 904 receiver

11/30 can include an available 912 device requestor that is configured to carry a message (for example, Get Neighbor List) to the bottom layer to get a list of devices that are in the wireless (or wired) neighborhood of the receiver w -MDDI. The lower layer can respond with a Lower Layer Neighbor List Response that provides a list of devices that are in the vicinity.

A Get Neighbor List is a message sent to the bottom layer (for example, MAC layer) to get the list of neighbors which are connected wirelessly to the current node. This message includes a two-byte message ID that contains a 16-bit unsigned integer. A message ID number of 0x3 identifies the package 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 (for example, MAC address) of the w-MDDI node (for example, UWB modem). This message includes a two-byte message ID that contains a 16-bit unsigned integer. A message ID number of 0x2 identifies the packet as a Get Lower Layer Address (Get MAC Address) message.

A host query 914, included with the w-MDDI 904 receiver, can be configured to transmit a w-MDDI Host Lookup packet to neighbors. The w-MDDI 902 sender (s) may include a 916 availability notifier that is configured to transmit a w-MDDI Host Response packet to the w-MDDI 904 receiver in response to the query. The Host Response w-MDDI package can contain availability and sequence identifiers for the various devices.

31/111

A user of the w-MDDI 904 receiver can select which w-MDDI transmitter to associate with. If a time recorder (for example, service_discovery_timer) associated with the w-MDDI 904 receiver expires before receiving a w-MDDI Host Response, the association fails.

According to some aspects, if multicast service is supported by the lower layer, the multicast service can be used to transmit w-MDDI Service Inquiry and w-MDDI Service Response packets in the case of Receiver Service Discovery and to send the w-MDDI Host Lookup and w-MDDI Host Response packages in the case of Issuer Service Discovery. The operation when using multicast will be described in further detail below. If multicast service is not available, broadcast can be used. If the broadcast feature is not present, unicast can be used.

The w-MDDI sender can maintain a list of responsive w-MDDI receivers with a w-MDDI service response package and the receiver parameters corresponding to each of the w-MDDI receivers. The w-MDDI receiver can maintain a list of responsive w-MDDI transmitters with a w-MDDI service response package and the sender parameters corresponding to each one. These lists can be maintained on the respective storage media associated with devices 902 and 904.

According to some aspects, the underlying layer can support multicasting. Multicasting can provide efficiency because messages are transmitted to a subset of devices (for example, identified devices), rather than to all devices in the vicinity. For service discovery when the w-MDDI 902 transmitter is looking for receivers

32/111 w-MDDI 904 (for example, Receiver Service discovery) and the underlying lower layer supports multicast, w-MDDI capable devices can associate with a multicast group, WMDDI_CONTROL_MULTICAST group specified by WMDDI_CONTROL_MULTICAST_ADDRESS. W-MDDI receivers can advertise their w-MDDI service response packets periodically at that multicast address. The wMDDI sender who wishes to perform service discovery can choose the w-MDDI receiver with which he wishes to associate from these w-MDDI service responses.

sender w-MDDI can also explicitly request w-MDDI service response packages from individual recipients by sending a w-MDDI service query package to the group

WMDDI CONTROL MULTICAST.

For service discovery when the wMDDI 904 receiver is looking for a w-MDDI 902 sender (for example, underlying bottom discovery supports multicast, hosts (for example, w-MDDI emitters) wishing to associate with receivers can join the specified WMDDI_CONTROL_MULTICAST group fur

WMDDI CONTROL MULTICAST ADDRESS. W-MDDI senders can advertise (for example, wMDDI host response packets at that multicast address. The w-MDDI receiver wishing to perform host discovery can choose the w-MDDI sender it wants to associate with from these responses of host w-MDDI. The w-MDDI receiver can also explicitly request the w-MDDI host response packets from the individual wMDDI emitters by transmitting a w-MDDI host query packet to the group

WMDDI CONTROL MULTICAST.

33/111

According to some aspects, service discovery can be enabled when the underlying layer is a wiMedia UWB MAC. If the underlying bottom layer is a wiMedia UWB MAC, the following can be enabled during service discovery. WiMedia receiver-capable devices include an Application Specific IE (ASIE) containing the w-MDDI service response. Similarly, w-MDDI emitter-capable devices can include an ASIE in their flags containing the w-MDDI host response packet.

Figure 10 illustrates an Application Specific IE (ASIE) format 100 on WiMedia MAC. According to some aspects, if the underlying layer is wiMedia UWM 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 the w-MDDI service response. In a similar way, w-MDDI emitter-capable devices can include an ASIE in their flags containing the wMDDI host packet.

A Specified Application ID 1002 can be established for w-MDDI receiver, wMDDI_wiMedia_ASIESpecifierlD.

Data of the information

Specifies is established for

W-MDDI service. Similarly, in the

In case of

Application

Response Package case of emitters of w—

MDDI, the Data from

Application

Specifies established for host response packet w—

MDDI

Host response packet w-MDDI responds to the

W-MDDI service sent by the w-MDDI issuer. 0 Pack of

Host Response provides the availability and sequence identification of the w-MDDI receiver. A length of

34/111

Two-byte packet containing a 16-bit unsigned integer that specifies the total number of bytes in the packet, not including the packet length field. A two-byte packet type contains a 16-bit unsigned integer. A packet type of 167 identifies the packet as a w-MDDI service response packet. A MAC Receiver address is a six-byte MAC address of the w-MDDI receiver. This can be a multicast or broadcast address, depending on whether multicast or broadcast services are used. Also included is a MAC Issuer Address which is a 6-byte MAC address of the w-MDDI issuer. A Sender Parameters field is a 256-byte string identifier for the w-MDDI sender and its capabilities. A CRC field is two bytes that contains a 16-bit CRC of all bytes in the packet including the Packet Length.

Figure 11 illustrates an application-specific polling information element (AS polling IE) on wiMedia MAC 1100. When the sender w-MDDI searches for receivers (for example, receiver service discovery), a Discover Service w- MDDI is sent to the lower layer (wiMedia MAC). The Discover w-MDDI Service message is sent to the lower layer (for example, wiMedia MAC layer) to obtain the w-MDDI service information. The payload for this message is the w-MDDI service query package. This is placed in the IE Specific Application Request information 1100 application probing information field when the underlying layer is wiMedia UWB MAC. The content of that message includes a Message ID that is two bytes that contains a 16-bit unsigned integer. A package type of 0x4 identifies the package as a Discover Service. A Package Type has two bytes that contain an integer without

35/111 16-bit signal. A package type of 162 identifies the package as a service query package. Also included is a Sender Parameters field which is two bytes that contain information about the w-MDDI sender. A Sender MAC address is a six-byte MAC address of the wMDDI sender and a receiver MAC address, which can be the broadcast address. Service Query Options are also included, which are two bytes of service query options and a CRC, which are two bytes that contain a 16-bit CRC of all bytes in the packet including the Packet Length.

Substantially at the same time as receiving the w-MDDI Service Discovery message from the w-MDDI layer, the wi-Media MAC at the w-MDDI sender can determine whether it has valid Application Specific IE (ASIE) information (no -expired) for w-MDDI receivers from all of its neighbors. If there is no valid (or unexpired) ASIE information, the MAC at the issuer w-MDDI reviews the Specific Application IEs (ASIEs) from its neighbors. If there are any neighbors of the w-MDDI sender that do not have the ASIE information corresponding to the w-MDDI, it sends the Specific Application Polling IEs to each of these neighbors. The Specific Application Polling IEs are defined as shown in Figure 11. The Specific Application Request Information field 1102 is established for the wMDDI service query package.

The issuer w-MDDI waits for a time corresponding to service_discovery_timer to receive the IEs of Specific Application. The wiMedia MAC can send a w-MDDI service information packet to the wMDDI layer for each ASIE received.

A w-MDDI service pack is a

36/111 message sent by the lower layer (for example, wiMedia MAC) to w-MDDI providing the w-MDDI sender with the service response information it received from the w-MDDI capable receiver neighbors. In wiMedia MAC, the application data specified in the ASIE (application specific IE) contains the Service Response information w-MDDI. This message includes a message ID, which is two bytes that contain a 16-bit unsigned integer. A message ID of 0x8 identifies the package as a w-MDDI service information message. Another field is the number of w-MDDI receivers, which indicates the number of wMDDI receivers. This message contains the number of w-MDDI receiver instances in the following fields. Packet Length, which is two bytes that contain a 16-bit unsigned integer that specifies the total number of bytes in the packet, not including the packet length field. A Packet Type is 2 bytes that contain an integer without a 16-bit ending. A packet type of 163 identifies the packet as a w-MDDI service response packet. A Receiver MAC address is a 6-byte MAC address of the w-MDDI receiver. A Receiver Parameter is a 256-byte sequence identifier for the w-MDDI receiver and its capabilities. CRC are two bytes that contain a 16-bit CRC of all bytes in the packet including the Packet Length.

A w-MDDI receiver that wants to initiate a service discovery to find w-MDDI senders (for example, Sender Service Discovery) sends a w-MDDI Host Discovery message to the bottom layer (wiMedia MAC). Substantially at the same time as receiving the message from the w-MDDI layer, the wiMedia MAC on the w-MDDI receiver can determine whether it has any Application Specific IE (ASIE) information

37/111 valid (unexpired) for w-MDDI emitters from their neighbors. If there are any neighbors for which the w-MDDI receiver does not have ASIE information, it sends application-specific polling IEs to each of these neighbors. Application-specific polling IEs are defined as shown in Figure 11. The Application-specific Request Information field 1102 is established for the Host Inquiry package w-MDDI. The w-MDDI receiver waits for a time corresponding to the host_discovery_timer for the receipt of IEs of Specific Application. The iMedia MAC can send a w-MDDI host information packet to the w-MDDI layer for each received ASIE.

when the underlying layer

For discovery of

The following will describe the service discovery is UDP / IP.

Service of

Receiver (for example, receivers) and the underlying sender layer looking for UDP / IP, w-MDDI capable sender / receiver devices can associate with a WMDDI_CONTROL_MULTICAST group specified by the WMDDI CONTROL MULTICAST IP multicast address. W-MDDI capable receiver devices can advertise their capabilities by sending (for example, periodically) w-MDDI service to the group a w-MDDI sender intends to send a packet of to the multicast group UDP port # of w-MDDI service query response packet from WMDDI_CONTROL_MULTICAST. When you discover a w-MDDI receiver, consult w-MDDI service WMDDI_CONTROL_MULTICAST in

WMDDI_UDP_CONTROL_PORT.

The Query Package is a wireless device to determine if the device supports w-MDDI receiver functionality. The content of

Service Query Package w-MDDI includes a package length that is two bytes that contain an integer

38/111 unsigned 16-bit that specifies the total number of bytes in the packet not including the packet length field. A Packet Type 162 is two bytes that contain an unsigned 16-bit integer. A Package Type of 162 identifies the package as a Service Inquiry package. Also included is a field of Emitter Parameters which are two bytes that contain information about the w-MDDI emitter. Also included is a sender MAC address which is a six-byte MAC address of the w-MDDI sender and a receiver MAC address which is a six-byte MAC address of the w-MDDI receiver. This can be a multicast or broadcast address if multicast or broadcast services are used. Service Query Options are also included which are two bytes of service query options. A CRC field is two bytes that contain a 16-bit CRC of all bytes in the packet including the Packet Length.

At approximately the same time as receiving the w-MDDI Service Inquiry packet, all w-MDDI capable receiver devices send the w-MDDI service response packets back to the w-MDDI sender that joins the multicast group WMDDI_CONTROL_MULTICAST on UDP port # WMDDI_UDP_CONTROL_PORT. The sender can wait for the service_discovery_timer time duration for the w-MDDI service response packages.

For Sender Service discovery (for example, receiver looking for senders) and the underlying layer is UDP / IP, w-MDDI capable sender / receiver devices can associate with the WMDDI_CONTROL_MULTICAST group specified by the WMDDI_CONTROL_MULTICAST_IP multicast address. W-MDDI capable sender devices can advertise their capabilities by periodically sending a service response packet

39/111 w-MDDI for the WMDDI_CONTROL_MULTICAST group. When the w-MDDI receiver wants to discover a w-MDDI sender, it sends a w-MDDI host query packet to the multicast group WMDDI_CONTROL_MULTICAST on UDP port # WMDDI_UDP_CONTROL_PORT. The w-MDDI Host Lookup Package is used to query a wireless device to determine whether that device supports w-MDDI receiver functionality.

w-MDDI Host Query Packet package content includes a packet length field, a packet type field, receiver parameter field, Sender MAC address field, Receiver MAC address field, a Service Query Options, and a CRC field. The packet length field is two bytes that contain a 16-bit unsigned integer that specifies the total number of bytes in the packet, not including the packet length field. 0 Packet Type field is two bytes that contain a 16-bit unsigned integer. A package type of 166 identifies the package as a Host query package. The receiver parameter field is two bytes that contain information about the sender w-MDDI. The Sender MAC address field is the six-byte MAC address of the w-MDDI sender. This can be a multicast or broadcast address, if multicast or broadcast services are used. The Receiver MAC address field is the six-byte MAC address of the w-MDDI receiver. The Service Query Options field includes two bytes of service query options. The CRC field is two bytes that contain a 16-bit CRC of all bytes in the packet, including the packet length.

At approximately the same time that you receive the w-MDDI Host Query package, all

40/111 w-MDDI capable sender devices send w-MDDI host response packets back to w-MDDI receivers that associate with the WMDDI_CONTROL_MULTICAST multicast group on UDP port # WMDDI_UDP_CONTROL_PORT. The receiver can wait for the host_discovery_timer time duration for the w-MDDI host response packets.

According to some aspects, an optional secure operation can be enabled. If the w-MDDI transmitter and / or the w-MDDI receiver are not capable of security, the resulting operation is unsafe. If both the w-MDDI transmitter and the w-MDDI receiver are capable of safety and if either of them wants safety operation, the resulting operation is safe. The following table lists the different possibilities with respect to the device and host security capabilities in which the association proceeds. With the rest of the possibilities, the association will not continue.

Table 1

<td colspan="2">Host</td><td colspan="2">Device</td><td rowspan="2">Communication secure</td><td rowspan="2">Proceed with association</td>

<td>Safety Mandatory</td><td>Able to Safety</td><td>Safety Mandatory</td><td>Able to Safety</td>

<td>Does not matter</td><td>Yes</td><td>Does not matter</td><td>Yes</td><td>Yes</td><td>Yes</td>

<td>No</td><td>Does not matter</td><td>No</td><td>No</td><td>No</td><td>Yes</td>

<td>No</td><td>No</td><td>No</td><td>Does not matter</td><td>No</td><td>Yes</td>

<td colspan="4">Rest of Cases</td><td></td><td>No</td>

If secure operation is desired, after the association process is complete, a mutual authentication procedure occurs. For safe 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

41/111 as the connection key for the entire lifetime of the association; or paired time keys (PTKs) can be derived from the master key and can be used. If the underlying bottom layer is wiMedia UWB MAC, a four-way handshake can be used to derive the time switches in pairs.

Figure 12 illustrates a method 1200 for communicating high rate digital data wirelessly using receiver initiated association. To associate the device (eg, w-MDDI receiver) with a host entity (eg, w-MDDI sender), an Association Request Packet is sent, at 1202, by the w-MDDI receiver. According to some aspects, the Association Request Package can be sent to an association request by C2 when it wishes to associate itself with the MDDI issuer after the device is turned on. The Membership Request Package can include a Packet Length, Packet Type, Device Parameters, Sender MAC Address, Receiver MAC Address, Association / Security Options, and CRC Fields. The Membership Request Package is sent for Membership Request by C2 when C2 wishes to associate with the MDDI issuer (for example, after calling). The packet length can be two bytes that contain a 16-bit unsigned integer that specifies the total number of bytes in the packet, not including the packet length field. The Packet Type can be two bytes in length and contain a 16-bit unsigned integer. A package type of 154 identifies the package as a membership request package. Device parameters can be two bytes for device-specific parameters. The sender's MAC address can be a six-byte MAC address of the w-MDDI sender and

42/111 the receiver MAC address is a 6-byte MAC address of the w-MDDI receiver. The Association / Security Options are two bytes (bit 0 and bit 1). Bit 0 is Security Capability and is 1 if security capability is present on the receiver; otherwise it is 0. Bit 1 is Mandatory Security and is 1 if security is mandatory for the receiver; otherwise it is 0. The CRC can be two bytes that contain a 16-bit CRC of all bytes in the packet including the Packet Length.

Substantially at the same time that the membership request packet is sent, the device can enter a status of Submit Membership Request and an association time recorder can be initiated at 1204. According to some aspects, the Membership Request may contain information related to whether the w-MDDI receiver is safe and / or whether security is mandatory for the w-MDDI receiver.

The w-MDDI issuer must confirm the Membership Request Package and respond with an Membership Response Package before the membership time recorder reaches a predetermined interval (for example, expiring or expiring). The Membership Response Package can include a Client ID that identifies the w-MDDI receiver. According to some aspects, the Membership Application Package includes information related to whether the w-MDDI issuer is capable of security and / or whether security is mandatory for the w-MDDI issuer. After transmitting the Association Response Packet, the wMDDI issuer can enter an Association Response Sent status and initiate an Association Time Recorder.

The Membership Response Package is sent in response to the Membership Request Package sent by Cl. This package provides C2 with the Customer ID and

43/111 device / display. This is part of the three-way handshake association. The packet includes a Packet Length which is two bytes that contain a 16-bit unsigned integer that specifies the total number of bytes in the packet not including the packet length field. A Packet Type field is two bytes that contain an unsigned 16-bit integer. A package type of 155 identifies the package as an association response package. Also included is a Client ID which is two bytes allocated for C2 Client ID and Security / Membership Options which are two bytes (Bit 0, Bit 1, and Bit 2). Bit 0 indicates Safety Capacity and is set to 1 if the safety capacity is present at the transmitter; and otherwise set to 0. Bit 1 indicates Mandatory Security which is set to 1 if security is mandatory for the issuer; and set to 0 otherwise. Bit 2 indicates whether a Multicast Address is included. This bit is set to 1 if the multicast address is included with the Association Response packet. A CRC field is two bytes that contain a 16-bit CRC of all bytes in the packet including the Packet Length.

The w-MDDI sender and receiver are able to negotiate their security capabilities and mandatory options with the Membership Request Package and Membership Response Package. The association process can proceed or be interrupted based on the possibilities listed in Table 1, described above. If the security communication option is enabled as a result of the above negotiations, the Client ID provided by the issuer w-MDDI is not authenticated at this point and will be trusted only after the mutual authentication process is completed.

44/111

A determination is made, in 1206, as to whether the time recorder has expired. Since the underlying wireless medium may be unreliable, it is possible that the Membership Response Package or other packages may be lost. Therefore, if the Association Response Package was not received (NO) before the time recorder expired, method 1200 continues, at 1206, with a determination as to whether the time recorder has expired. If, at 1206, it is determined that the time recorder has expired, method 1200 continues, at 1202 with a subsequent membership request packet being resent. This can be recursive in that some subsequent Membership Request Packs can be sent up to a maximum number of times.

According to some aspects, upon expiration of the Membership Response Recorder, the issuer w-MDDI can resend the Membership Response Package. According to some aspects, the w-MDDI sender can send an Association Response Package whenever it receives an Association Request Package from the w-MDDI receiver.

If the time recorder has not expired (NO), a determination is made, in 1208, as to whether the Membership Response Package has been received. If the determination, in 1208, is that the Association Response Package has been received (YES), method 1200 continues, in 1210, and a Customer Capacity Package is sent to the issuer w-MDDI confirming the Request Package Association.

A status pack or Client Capacity Pack can be transmitted in 1212. The Client Capacity Pack can be sent when the wMDDI receiver receives an Association Response Pack from

45/111 a w-MDDI transmitter.

If the security option is enabled, the Client Capacity Pack is not yet authenticated at that point. The contents of the Customer Capacity Pack are only trusted after mutual authentication is completed in 1212, which is optional as denoted by the dashed line. Additional information related to mutual authentication will be provided below.

After submitting the Client Capacity Pack, the w-MDDI receiver can enter an associated state (if the security option is not enabled) and the associated w-MDDI receiver can enter an associated state (if the security option does not enabled). If the security option is enabled, the mutual authentication process (described below) must be completed before the wMDDI sender and w-MDDI receiver enter an Associated State. In this way, a three-way handshake association is established. According to some aspects, if the Membership Request Pack, Membership Response Pack and / or Customer Capacity Packs are lost, they can be retransmitted if the wireless link is stable. Otherwise, the w-MDDI emitter and the w-MDDI receiver do not become associated (for example, they can remain in a decoupled state). According to some aspects, the w-MDDI receiver can send an Alternative Display Capacity Pack if it has any alternative displays associated with it.

After being associated with a specific w-MDDI sender, the w-MDDI receiver can store the sender's lower layer address (MAC address). After entering the associated state, the w-MDDI receiver must send (for example, periodically such as once on mac_response_time msec) Link Status Packets (Packets

46/111 MAC Response) to the host, in 1214. 0

Link Status provides the MAC with statistics about the w-MDDI receiver MAC (for example, average number of retransmissions, packet error rate, and so on), for the w-MDDI sender.

The fields included in the

Link Status Packets are packet length, packet type, cCLient ID, average number of retransmissions, frame error rate, physical layer rate, and CRC. The packet length is two bytes that contain a 16-bit unsigned integer that specifies the total number of bytes in the packet, not including the packet length field. The packet type is two bytes that contain an unsigned 16-bit integer. A packet type of 150 identifies the packet as a MAC response packet. The cCLient ID is two bytes that contain an unsigned 16-bit integer. This is the C1 / C2 Client ID, depending on the identity of the creator of the package. The average number of retransmissions is the average number of retransmissions for each MAC frame transmitted in the reverse direction. The rate

<td>Error</td><td>in</td><td>Framework is</td><td>the rate</td><td>error</td><td>of package</td><td>View</td><td>at</td>

<td>direction</td><td>in</td><td>advance. THE</td><td>Rate of</td><td>Layer</td><td>Physics is</td><td>the rate</td><td>in</td>

<td colspan="2">streaming</td><td>in the layer</td><td>physics.</td><td>0 CRC</td><td>are two</td><td>bytes</td><td>what</td>

<td>contain</td><td>one</td><td>16 CRC</td><td>bits of</td><td>all</td><td colspan="3">the bytes in the packet,</td>

including Packet Length.

Substantially at the same time as receiving a

Link Status Pack (MAC Response Pack) from the w-MDDI receiver, the w-MDDI sender can respond with a Sender Link Status Pack (MAC Response Pack). This package acknowledges receipt of the Link Status Package (MAC Response Package). This packet confirms receipt of the Link Status Packet (MAC Response Packet) which was sent by the w-MDDI receiver. It can also provide MAC statistics and parameters

47/111 receiver for the w-MDDI transmitter.

If the w-MDDI receiver does not receive a Sender Link Status Packet (Sender MAC Response Packet) from the w-MDDI sender in response to a Lower Layer Response Packet (MAC Response Packet) that was sent for the duration of mac_response_fail_time msec, the w-MDDI receiver can see that it has been decoupled from the sender. It then stops sending the Link Status Packet (MAC Response Packets). If the sender does not receive a Link Status Pack (MAC Response Pack) for the duration of mac_response_fail_time msec, the sender enters the decoupled state. When the sender or receiver enters a decoupled state, it does not respond to the Link Status Packets / Sender Link Status Packets (Sender MAC Response Packets / MAC Response Packets) sent by the receiver and sender, respectively .

A lower layer response (MAC Response) is a message from the lower layer (for example, MAC layer) to the w-MDDI sender / receiver. This message indicates the rate supported by the lower layer (for example, MAC), retransmission statistics, and so on. The message includes a Message ID which is two bytes that contain an unsigned 16-bit integer. A message ID of 0x5 identifies the packet as a MAC Reply message. The package also includes an average number of retransmissions, which is the average number of retransmissions for each MAC frame transmitted in the reverse direction. A Frame Error Rate indicates the packet error rate seen in the forward direction and a Physical Layer Rate, which is the transmission rate at the physical layer.

<td></td><td>An</td><td>answer</td><td>in</td><td>Address</td><td>in</td><td>layer</td><td>bottom</td>

<td>(answer</td><td>in</td><td>Address</td><td>MAC)</td><td>provides the</td><td colspan="3">layer address</td>

<td>bottom</td><td>(per</td><td>example,</td><td colspan="2">MAC address)</td><td>gives</td><td>layer</td><td>bottom</td>

48/111 (for example, UWB modem). This message includes a message ID, which is two bytes that contain a 16-bit unsigned integer. A message ID of 0x6 identifies the packet as a MAC Address Reply message. Also included is a Lower Layer address (MAC layer) which is the lower layer address (MAC layer address) of the underlying layer.

After being decoupled, the w-MDDI sender and receiver do not need to re-associate before they can start wireless MDDI transfers again. After the w-MDDI receiver has been decoupled from a specific sender, it is allowed to associate with another sender. Additional information related to decoupling is described below.

According to some aspects, the w-MDDI receiver also sends a Link Status Pack (MAC Response Pack) when the w-MDDI sender explicitly requests it via a Link Lookup Pack (MAC lookup pack).

The Link Consultation Package is sent by the host to consult MAC information from the sender / receiver side. The content of the Link Query Package includes Packet Length, which is two bytes that contain a 16-bit unsigned integer that specifies the total number of bytes in the packet, not including the packet length field. Packet type are two bytes that contain a 16-bit unsigned integer. A packet type of 151 identifies the packet as a MAC query packet. A cClientID field is two bytes that contain a 16-bit unsigned integer reserved for the target client ID (C2). MAC Lookup Parameters are two bytes and a CRC field is two bytes that contain a 16-bit CRC of all bytes in the packet including the

49/111

Packet Length.

If the underlying wireless link is 802.15.3 UWB MAC, after being associated with a w-MDDI receiver, the wMDDI issuer can configure the CTAs for transfer using the CTA configuration package in the forward and reverse directions if the mode of operation is the low latency mode (which will be described in further detail below).

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

Method 1300 illustrates an association initiated by the issuer and begins, in 1302, with the transmission of an Issuer Association Request Package to a remote receiver. The Issuer Association Request Package is sent for association request by the issuer when it wishes to associate with a specific MDDI receiver (for example, after the call). 0 Issuer Association Request Package includes a two-byte packet length that contains a 16-bit unsigned integer that specifies the total number of bytes in the packet not including the packet length field and a two-byte Packet Type which contain a 16-bit unsigned integer. A package type of 158 identifies the package as an association request package. Also included is a receiver MAC address that is six bytes and includes the receiver MAC address, and a sender MAC address that is bytes of the sender MAC address. Options

50/111

Association / Security includes two bytes (Bit 0 and Bit 1). Bit 0 indicates the safety capability and is set to 1 if the safety capability is present on the receiver or is set to 0 otherwise. Bit 1 indicates whether security is mandatory. If set to 1, security is mandatory for the receiver, otherwise it is set to 0. A CRC field is two bytes that contain a 16 bis CRC of all bytes in the packet including the Packet Length. According to some aspects, the Issuer Association Application Package includes information on whether the w-MDDI issuer is security-enabled and / or whether security is mandatory for the w-MDDI issuer.

Substantially at the same time that the first membership request packet is sent, the sender enters a Sent Issuer Association Request Packet state and a time recorder (for example, membership time recorder) or other means of monitoring can be started at 1304. The time interval between the transmission of the first association request packet and the receipt of a response from the remote receiver, such as an Association Request Packet, is monitored and, in 1306, a determination is made to the predefined time interval has been exceeded (for example, the time recorder has expired). If the time recorder has expired (YES), this indicates that the Membership Request Package was not received from the remote issuer and method 1300 continues, at 1302, where a subsequent membership request package is sent. Any number of subsequent Issuer Association Request packages can be sent up to a maximum number of times (for example, max_sender_association_retry). If the

51/111 time recorder has not expired (NO), a determination is made, in 1308, of whether the Membership Request Package has been received.

If the determination, in 1308, was that Membership Application Package was not received (NO), method 1300 continues, in 1306, until the time recorder expires or Membership Application Package is received. If the Association Request Package has been received (YES), an Association Response Package can be sent that provides a Client ID to the remote device.

Membership Response Package is sent in response to the Membership Request Package sent by Cl. Substantially at the same time as transmitting the Membership Response Packet, the w-MDDI receiver can enter a Requested Membership Request state and send an Association Time Recorder. The Association Response Package can be resubmitted up to a maximum of max-association_retry times. According to some aspects, the Association Response Package includes information related to whether the w-MDDI receiver is security enabled and / or whether security is mandatory for the receiver.

This package provides C2 with the Client ID and the Display / Device ID. This is part of the three-way handshake association. The Membership Response Package contains a Package Length, a Package Type, a Customer ID, and a CRC. The Packet Length is two bytes that contain a 16-bit unsigned integer that specifies the total number of bytes in the packet not including the packet length field. The Packet Type is two bytes that contain an unsigned 16-bit integer. A package type of 155 identifies the package as a package of

52/111 association response. The Client ID is two bytes allocated to the C2 Client ID and the CRC is two bytes that contain a 16-bit CRC of all bytes in the packet including the Packet Length.

If the determination in 1308 is that the packet is received (YES), in 1312, the sender w-MDDI responds with an Association Response Pack providing a customer ID to the w-MDDI receiver (similar to the association case initiated by the receiver described above). According to some aspects, the Association Response Package also contains the security capacity and security information required for the transfer, confirming the information that was originally sent.

The issuer may also initiate a time recorder, such as an Association_Response time recorder, substantially at the same time as sending the Association Response Package. The receiver must respond with a Customer Capacity Pack and / or Link Quality Information. Each Association Response Received by the recipient must be answered with a Customer Capacity package.

If the Association Response time recorder expires, the wireless sender resends the Association Response packet a maximum number of times (for example, association_retry). The Issuer Membership Request, Membership Request, Membership Response and Customer Capability may constitute a four-way handshake procedure.

Method 1300 enables the w-MDDI sender and the receiver to negotiate their security capacity and mandatory security options. The association process can continue or be interrupted based on the possibilities in Table 1, as described above. If the

53/111 secure communication is enabled as a result of the above negotiations, the Client ID provided by the issuer wMDDI is not authenticated at this point and will be trusted only after the mutual authentication process is completed.

If the security option is enabled, mutual authentication can be performed, which will be described below. According to some aspects, a receiver that is associated with a specific issuer will not accept requests for association from any other issuer. In this situation, the w-MDDI receiver can send a Denied Association Package to the sender.

Figure 14 illustrates a procedure 1400 for mutual authentication and key exchange. According to this example, procedure 1400 is based on a wireless USB numeric association model. If a security operation is required, mutual authentication and key exchange occur between the w-MDDI 1402 sender and the wMDDI 1404 receiver. This procedure is similar to the numerical association procedure on the wireless USB. A DiffieHellman protocol can be used to establish a temporary secure channel. To protect against an intermediary attack, the host and the device can individually display a value that is derived from the Diffie-Hellman keys and the user is asked to verify that the two values ​​match.

The w-MDDI 1404 receiver can generate a new random A secret and compute PK_D = g^/'mod p. The A and PK values_Dmay be prohibited in terms of being permanently encrypted on the device at the time of manufacture. The w-MDDI 1404 receiver can compute the SHA-256 hash (PK_D| | N_D) and send the hash in 1406, to the issuer w-MDDI 1402. N_D is the number of digits that the device is able to display. This hash submits the device to PK values_D and N_D, without

54/111 the values ​​are revealed until later, after the public key of the issuer w-MDDI is revealed.

emitter w-MDDI 1402 can generate a new random B secret and compute PKH = g^B mod p. The B and

PK_H may be prohibited in terms of permanent coding at the w-MDDI transmitter at the time of manufacture. The issuer wMDDI 1402 sends PKH to the device in 1408. The device aborts the association if PK_H is equal to 1 or p1.

The w-MDDI 1404 receiver sends PK_D and N_D for the issuer w-MDDI, in 1410. The issuer W-MDDI 1402 aborts the association if PK_D is equal to 1 or p-1. The W-MDDI 1402 transmitter computes SHA-256 (PK_D | | N_D) and verifies the result with the hash commitment received from the device 15 previously. The transmitter W-MDDDI 1402 aborts the association if the values ​​do not match. Additionally, the WMDDDI 1402 transmitter computes the shared secret DHKey = SHA256 (PKDB mod p). The issuer w-MDDI 1402 computes the shared secret DHKey = SHA-256 (PK_H^The mod p).

To protect against intermediary attacks, both sides compute a common value V = SHA-256 (PK_DI IPK_HII digestion displayed) and display a few digits (for example, two digits, three digits, four digits, and so on) of that number to the user on their respective displays.

A user can manually check their numbers shown on the w-MDDI transmitter and device combine (for example, by analyzing both displays) and press ok (or perform some equivalent action) on both, the 30 w-MDDDI transmitter and the device. If the user selects do not match or if confirmation by the user is not received on both the sender w-MDDDI and the device without an expiration period, then the association is aborted and a

55/111 fault indication is displayed to the user. The expiration period can be at least 20 seconds with no maximum expiration period.

If the user approves the association, the sender wMDDDI and device both compute the Master Key (PMK) = the first 128 bits of HMAC-SHA-256DHKey (Master Key in Pairs). The w-MDDDI sender also sends the device any remaining non-private information it needs to complete the association.

If any other applications need additional keys for whatever purpose, then a KDK key bypass key is computed as KDK = HMAC-SHA-256 ~ DHKey (key bypass key). The KDK value can then be used immediately or saved for later use as the switching material for any other purpose.

According to some aspects, decoupling can occur. For example, if the w-MDDI sender does not receive a Link Status Packet (MAC Response packet) from a receiver at mac_response_fail_time msec, it can declare the receiver as decoupled. The sender then removes the entry corresponding to the receiver from the device association table. After entering the decoupled state, the w-MDDI sender / receiver does not respond to the Link Status Pack (MAC Response Pack) and Sender Link Status Pack (Sender MAC Response Pack) respectively.

According to some aspects, if the wMDDI receiver does not receive the Sender MAC Response Packets in response to the max_MAC_Response_retries packets, the w-MDDI receiver enters the decoupled state. If a Link Status Pack (MAC Response Pack) appears from a receiver after it has been marked as decoupled

56/111 in the sender's device association table, the association process needs to be restarted by the sender (for example, the sender performs an association initiated by the sender).

Figure 15 illustrates a decoupling procedure initiated by receiver 1500. The w-MDDI 1504 receiver can also decouple by sending an explicit Decoupling Request Packet 1506 to the wMDDI 1502 sender. The w-MDDI 1502 sender responds with a Packet of Dissociation Response 1508. After receiving this packet, the 1504 w-MDDI receiver enters a dissociation state. 0 sender w-MDDI 1502, then removes the entry corresponding to the w-MDDI 1504 receiver in the device association table.

Figure 16 illustrates a method 1600 for decoupling initiated by the receiver between a user device (for example, receiver) and a host entity (for example, sender). The 1600 method begins, in 1602, with the association of the user device with a host entity. Substantially at the same time that the association with the host entity is established, a capacity packet is sent in 1604. The capacity pack can include one or more capabilities of the user device. A status packet can be transmitted in 1606. Such transmission of the status packet can be based on a request for the packet from the host entity, periodically, or when a status changes.

In 1608, a determination can be made that the association is interrupted and / or in 1610, it can be decided to stop communication with the host entity. For example, the determination can be made if the wireless receiver does not receive a sender's MAC Response Packet from the

57/111 wireless transmitter in a predetermined period of time. A MAC Response Packet provides MAC statistics on the wireless receiver MAC, such as the average number of retransmissions, packet error rate, and so on.

0 packet content can include a packet length, packet type, Client ID, average number of transmissions, frame error rate, physical layer rate, CRC. The MAC Response Packet can be two bytes in length that contains an unsigned 16 10 bit integer that specifies the total number of bytes in the packet, not including the packet length field. The packet type is two bytes that contain an unsigned 16-bit integer. A packet type of 150 identifies a packet as a MAC response packet. The Client ID is 15 two bytes that contain a 16-bit unsigned integer. This is the C1 / C2 Customer ID depending on which customer is the creator of the package. The average number of retransmissions can be two bytes and for each MAC frame transmitted in the reverse direction. The 20 frame error rate can be two bytes and the packet error rate sent in the forward direction. A physical layer rate can be two bytes and is the transmission rate at the physical layer. The CRC is two bytes that contain a 16-bit CRC of all bytes in the packet including the length of 25 packets.

The Sender MAC Response Packet provides the MAC with statistics about the w-MDDI sender MAC, such as the average number of retransmissions, packet error rate, and so on for the w-MDDI receiver. This packet is sent by the wireless sender confirming the Packet

MAC response sent by the wireless receiver. The packet contains a two-byte Packet Length field that contains a 16-bit unsigned integer that specifies the number

58/111 total bytes in the packet, not including the packet length field. Also included is a two-byte Packet Type field that contains a 16-bit unsigned integer. A packet type of 159 identifies the packet as a sender MAC response packet. A cClient ID is two bytes that contain an unsigned 16-bit integer. This is the Client ID of C2, the target client. 0 average number of retransmissions is the average number of retransmissions for each MAC frame transmitted in the reverse direction. A Frame Error Rate is the packet error rate seen in the forward direction. A Physical Layer Rate is the transmission rate at the physical layer. Also included in the pack is a CRC that is two bytes in length that contains a 16-bit CRC of all bytes in the packet including the Packet Length.

If either, or both, device association is disrupted or user communication must be decoupled from the host.

Such decoupling may include stoppage, that of the entity sending a

Explicit Decoupling Request Package, in 1612, for the wireless emitter. If there is still a communication link between the host entity and the user device (for example, all communication has been lost), a Decoupling Response Packet is received from the wireless emitter in 1614. Substantially at the same time in which the dissociation response is received, the user device enters a dissociation state in 1616.

The Decoupling Request Package can be sent by C2 when it wishes to disassociate itself from the wireless emitter and make an elegant output. Included in the Decoupling Request Package is a Packet Length field that is two bytes in length that contains a

59/111 16-bit unsigned integer specifying the total number of bytes in the packet not including the packet length field. A Packet Type field is two bytes that contain an unsigned 16-bit integer. A package type of 156 identifies the package as a decoupling request package. A Customer ID field is two bytes allocated for C2's Customer ID. The CRC field is two bytes that contain a 16-bit CRC of all bytes in the packet including the Packet Length.

The Decoupling Response Package is sent in response to the decoupling request package. It has a two-byte Packet Length that contains a 16-bit unsigned integer that specifies the total number of bytes in the packet not including the packet length field. A packet type is two bytes that contain a 16-bit unsigned integer. A package type of 157 identifies the package as a decoupling response package. A Client ID is two bytes allocated for a C2 Client ID and a CRC field is two bytes that contain a 16-bit CRC of all bytes in the packet including the packet length.

Referring now to Figure 17, a decoupling procedure initiated by sender 1700 is illustrated. Sender 1702 can disassociate by sending a Dissociation Request Package from Sender 1706 to receiver 1704. Receiver 1704 then sends a Dissociation Request 1708. Issuer 1702 confirms by sending a 1710 Dissociation Response, which completes the dissociation procedure.

Figure 18 illustrates a 1800 method for selective decoupling between a transmitter and a remote receiver. In 1802, an association between a transmitter and a remote receiver can be established. A package that includes

60/111 capacity of the remote receiver can be received, in 1804, and link quality information can be received, in 1806. In addition, a MAC address of the sender and an identification of the remote receiver can be included in a table of 5 device association associated with the sender.

In some situations, it might be necessary to discontinue the association between the remote receiver and the sender and a determination can be made, in 1808, that communication between the sender and the remote receiver must be disabled. For example, if a wireless sender does not receive a MAC response packet from a receiver in a predetermined range msec (for example, mac_response_faÍl_ti.me), decoupled it can declare the receiver as e in 1810, a Packet of

Request

Dissociation from the sender is sent to the receiver. The response to the dissociation request (for example, from the receiver in 1812. A confirmation of completion of dissociation (for example, Dissociation Response) can be

<td>sent in</td><td> 1814,</td><td>to complete the</td><td>procedure</td><td>in</td>

<td>dissociation.</td><td></td><td></td><td></td><td></td>

<td>In</td><td>some</td><td>aspects, a</td><td>solicitation</td><td>in</td>

decoupling can be received explicitly, in 1816, the

<td>from one</td><td>remote receiver</td><td>. In</td><td>1818, a</td><td>confirmation</td><td>in</td>

<td>response from</td><td>dissociation</td><td>(per</td><td>example,</td><td>answer</td><td>in</td>

<td>Dissociation)</td><td>is sent. In</td><td> 1820</td><td colspan="2">, an identification</td><td>of</td>

dissociated device is removed from an association table.

The Issuer Decoupling Request Package is sent by the wireless issuer initiating the Decoupling. It includes a two-byte Packet Length field that contains a 16-bit unsigned integer that

61/111 specifies the total number of bytes in the packet not including the packet length field. A two-byte Packet Type field that contains a 16-bit unsigned integer. A package type of 161 identifies the package as a decoupling request package. An ID of

Client is two bytes allocated for C2 Client ID.

A CRC field is two bytes that contain a 16-bit CRC of all bytes in the packet including the Packet Length.

According to some aspects, all W-MDDI receivers periodically send a Link Status Package (MAC Response package) once in mac_response_time msec. The host obtains the w-MDDI receiver link statistics (receiver-MAC statistics) from these packets. The sender also periodically consults the MAC-sender to obtain the link statistic from the sender's side (MAC statistics). The issuer can determine the lower layer rate (MAC rate) based on this information. This rate information can be passed on to the application. This can help the application to increase or decrease its data rate. The sender sends a

Sender Link Status Packet (Sender MAC Response Packet) for individual receivers in response to the Link Status Packet (MAC Response Packet) it receives from each of the individual w-MDDI 25 receivers.

According to some aspects, Customer IDs are provided by the w-MDDI sender to the w-MDDI receiver during the association process via the Association Response Package. Customer IDs denote the 30 addressing identifiers with respect to a specific w-MDDI issuer. The customer ID association is unique for an issuer. Any new customer ID can be allocated to a new recipient from the association

62/111 free. According to some aspects, the client ID that has not been used for the longest period of time is assigned to a w-MDDI receiver, (for example, association contexts using the same client ID are separated by a long period of time) . This is to ensure that customer IDs are reused as often as possible.

Figure 19 illustrates a single wireless transmitter associating with multiple wireless receivers according to the revealed aspects. To fully consider the revealed aspects, several wired packages and their behavior in wireless techniques will now be described. The filler packets are not generated in high-rate wireless data communication because the filler packets are designed to maintain synchronization over the wired link and are therefore required with a wireless link.

A Client Capacity Pack informs the host about the client's capabilities. In MDDI, the client must send this packet after direct link synchronization. The client can also send the client capacity packet when requested by the host via reverse link flags in a reverse link encapsulation packet. The customer capacity package may contain fields that belong to the link such as pre-calibration data rate capacity, interface type capacity, post-calibration data rate capacity, and the like. This package can also contain fields pertaining to external devices, such as a display device connected to the customer. Such fields can include the number of alternative displays, a bitmap width, a bitmap height, display window width, display window height, color map size, and so on.

63/111

During a wireless MBDI association procedure, the receiver can send the Customer Capacity Package as a response to an Association Response Package sent by the wireless sender. The wireless receiver (C2) can also send an alternative display capability pack if it is associated with any alternative displays. The wireless receiver (C2) can send a Client Capacity Pack to the sender when there is a change in the status and / or capabilities of external devices (for example, a new device being added; an existing device being removed; an existing device, and so on). Alternatively or in addition, the customer capacity package can be sent periodically to assist in the reliability of the customer capacity packages. According to some aspects, a wMDDI receiver can send a client capacity packet to a w-MDDI sender when the w-MDDI sender requests it through the C2 flags field of a C2 Request packet.

A client request and status package can be used to send information from a client to a host to allow the host to configure the host / client link in a more optimal way. In a wired MDDI configuration, the client can send this packet to the host as a first packet in a reverse link encapsulation packet. The client can alternatively or additionally send this packet to the host when the host explicitly requests it via reverse link flags in a reverse link encapsulation packet.

In wireless MDDI, the wireless receiver can periodically send a Status and Request Packet

64/111 Client to the wireless issuer to indicate its CRC Error Count and also when there is a change in the status of external devices. The wireless receiver can also send a Client Request and Status Packet to the wireless sender by requesting it via the C2 flags field of a C2 request packet.

With reference again to Figure 19, each wireless transmitter 1902 (of which only one is illustrated) can associate or communicate with multiple wireless receivers, illustrated as receiver 1 (Rl) 1904, receiver 2 (R2) 1906, and receiver 3 (R3) 1908. Sender 1902 and receivers 1904, 1906, 1908 can be MDDI transmitters and / or MDDI receivers or other transmitters and receivers that can communicate high-rate digital data wirelessly. Each receiver 1904, 1906, 1908 can have multiple displays (not shown) and devices (not shown). For example, each receiver can have 16 displays, although more or less than 16 can be associated with a single receiver. Each receiver can have a w-MDDI client C2 entity.

For example, wireless devices, such as a wireless display, wireless mouse, wireless keyboard, wireless keyboard, and so on, can have a w-MDDI receiver, and each wireless device can be identified as a separate customer. From the perspective of a host (for example, issuer 1902), each of these customers can be identified by a unique customer identification (Customer ID). Therefore, customer Cl can have a Customer ID of 0. The wireless receiver, like the receiver (R2) 1906, can send a customer capacity packet to the wireless transmitter (C2) 1902 when there is a change in the capabilities of external devices connected to the receiver (R2) 1906. Additionally or alternatively ,

65/111 each receiver can send a customer capacity packet periodically to ensure reliability.

sender 1902 must maintain a device association table, such as the table 2000 shown in Figure 20. Table 2000 illustrates an association of a single wireless sender with multiple wireless receivers (for example, client).

Packages destined for a different receiver client can be sent to the respective devices based on the table. Table 2000 illustrates two customers (1 and 2). Associated with Client # 1 is the MAC address X: Y: Z: P: Q: R, and a Client ID C21. Associated with Client # 2 is the MAC address U: V: W: L: M: N and Client ID C22. In such a way, the sender can communicate with the appropriate receiver by accessing the 2000 query table.

For the sender to communicate with a receiver, there must be a device association. Any device (sender or receiver) can initiate the association process. For example, if a wireless transmitter is a phone and a wireless receiver is a projector / display, the phone (for example, transmitter) would typically initiate communication. However, there are situations where a receiver would initiate communication. Thus, there may be an association initiated by the receiver or an association initiated by the sender.

According to some aspects, if the underlying lower layer supports multicasting, multicast support can be used with a single w-MDDI emitter communicating with multiple w-MDDI receivers. W-MDDI receivers and senders can be associated with the WMDDI_CONTROL_MULTICAST group.

The w-MDDI sender who wishes to use the multicast feature must form a multicast group. If there is

66/111 a centralized server that provides lower layer multicast addresses (for example, a DHCP server) in the case of IP, the w-MDDI issuer can obtain a multicast address on a lease. This can be done before the service discovery procedure or after the service discovery procedure. The duration of the lease may be short term (limited to the duration of the association) or it may be longer term (much longer than the duration of the association).

For example, when there is a centralized server, the centralized server must be used to assign the addresses. In the absence of a centralized server, each individual issuer can choose a multicast address individually. In that case, there could be addresses colliding (for example, two senders choosing the same address). Thus, there must be an algorithm to alleviate the problem of multiple senders by choosing the same address.

According to several aspects, the operation with miMedia UWB MAC can be enabled. As previously mentioned, w-MDDI can operate on any underlying high-speed wireless link. As an example, the following describes the operation of w-MDDI with miMedia UWB MAC. When the underlying bottom layer is miMedia UWB MAC, the following can be used to send the control packets (for association, decoupling and so on).

An Application Specific IE can be used on the flags to transport the control packages in w-MDDI. For example, the Application Specific Data field in ASIE can be established for control packages (for association, decoupling, etc.). The ASIE package is shown in Figure 10. The ASIE specifier ID is set to: wMMDI_wiMedia_ASIESpecifierlD.

67/111

If the Specific Application IE cannot be used, the control packages for association and decoupling can be sent using the PCA mode if it is available and if it is not practical to use the ASIE elements in the flags. If using PCA mode, they must use user priority = 7 ie AC = AC_VO.

If Application Specific IE and PCA cannot be used, DRP can be used. When using DRP, temporary DRPs can be used. If using PCA mode, they must use user priority = 7, that is, AC = AC_VO. The MAC header for an Association Request package in the case of Association Initiated by the Receiver may be as follows:

Frame Control:

Retry: 0

Frame subtype / Delivery ID:

When using PCA, bl2 = 0 user priority (bll-b9) = 7 (corresponding to the voice; for example, AC = AC_VO)

When using DRP, bl2 = 1 Flow index (bll-b9) = (between 8 and 15)

Frame Type (b8-b6): Data

ACK Policy: 1 (Imm-ACK)

Safe: ?

Protocol Version: 0 (currently)

68/111

Access Information:

Access method: 0 (if PCA is used): 1 (if DRP is used)

More Tables: established accordingly

Duration: established accordingly

Destination Address: Dev address of the sender

Src Address: Dev Address of Receiver

When using DRP, temporary DRP can be used.

Data packets (for example, audio stream packets, video stream packets, and so on) can use DRP reservations on the links, forward and reverse. Traditional MDDI control packages can use PCA mode if available. Otherwise, they must use DRP reservations.

Figure 21 illustrates a 2100 system to extend the capabilities of a traditionally wired configuration to allow communication over a wireless link. The 2100 system includes a transmitter 2102 that communicates with a receiver 2104 via a direct link. Receiver 2104 communicates with transmitter 2102 via a reverse link. Transmitter 2102 and receiver 2104 can be devices that generally communicate via a wired protocol, however, the 2100 system allows such devices to communicate via the wired protocol and / or through a wireless protocol, such as through a high speed wireless link. Although a number of transmitter (s) 2102 and receiver (s) 2104 may be included

69/111 in the system

2100, as will be considered, a single transmitter 2102 that transmits communication data signals to a single receiver 2104 is illustrated for the sake of simplicity.

Transmitter 2102 may include a host 2106, a client portion (CI) 2108, and a communication component 2110. Host 2106 may be an MDDI host, for example. According to some aspects, host 2106 may be a separate component from transmitter 2102 and connected to transmitter 2102 via a wired link. A client portion (CI) 2108 is kept on or in communication with host 2106 for clock synchronization. Client (Cl) 2108 can be connected to host 2106 via a traditional wired link (eg, MDDI link), for example. Host 2106 can be configured to send or communicate data packets to the client (CI) 2108. These packets can be communicated to receiver 2104 via communication component 2110, which can include a modem, such as an ultra-wideband modem ( UWB). Some packages (for example, MDDI round trip delay package) are processed by the customer (Cl) 2108 and communicated to the receiver 2104. Other packages (for example, filler packages) must be discarded by the customer (Cl) 2108 and not communicated to receiver 2104. This means that some packets must not be transmitted on either the direct wireless link or the reverse wireless link. A filler pack, for example, maintains the timing between transmitter 2102 and receiver 2104. Such packets can be generated either by transmitter 2102 or receiver 2104 through respective customer portions.

Receiver 2104 may include an interface device 2112 (for example, display), a portion of

70/111 client (C2) 2114, and a communication component 2116.

According to some aspects, device 2112 can be a separate component from receiver 2104 and connected to receiver 2104 via, for example, a wired link. The client (C2) 2114 can be connected to the device 2112 through a wired link. Client (C2) 2114 can be configured to process a packet received from the transmitter

2102. The receiver 2104 can receive communication from the transmitter

2102 through the communication component 2116 which can include, for example, a UDB modem.

system 2100 can be configured to operate in one of two operating modes.

These modes include a low overhead mode and a low latency mode. In low overhead mode, the client (Cl)

2108 places the filling data and the forward storage packets which can be included in the communication

2110 (for example, UWB modem).

Communication

2110, packages and return), in component

The component of a through a UWB MAC, for example, can periodically request unidirectional channel time allocations (CTA) from transmitter 2102 to receiver 2104 based on the size of the store. In a reverse direction (for example, reverse link), the customer (C2) 2114 can place the reverse link data that must be sent (excluding filler packets, for example), in a storage associated with the communication component 2116 (for example example, UWB modem). In the reverse direction, the communication component 2116 can request CTAs in the reverse direction.

For low latency mode, during an initialization phase, the communication component 2110 (for example, UWB modem) can request a CTA for m msec in the forward direction and a CTA for n msec in the reverse direction.

71/111

The expected ratio of traffic in forward and reverse directions is m: neither sec is the duration corresponding to the MDDI direct link transfer rate of Rf__mddi. T_CTap is the duration of the CTA period and T is a superframe duration, which is determined by the application's latency restrictions where:

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

Referring now to Figure 22, a 2200 system for communication through wired and / or wireless architectures is illustrated. The 2200 system includes a transmitter 2202 and a receiver 2204 that communicate via a direct link (from transmitter 2202) and / or a reverse link (from receiver 2204). Communication via the direct link and / or the reverse link can be via a wired protocol and / or via a wireless protocol depending on the specific situation (for example, data to be transmitted; data rates; quality of the communication link ; status of each device, etc.). Although some transmitters 2202 and receivers 2204 may be included in the 2200 system, as will be considered, a single transmitter 2202 that transmits communication data signals to a single receiver 2206 is illustrated for the sake of simplicity.

transmitter 2202 may include a host component 2206 connected to a client component (C1) 2208 and a communication component 2210. The receiver 2204 may include a device 2212 connected to a client component (C12) 2214 and a communication component 2216 Customer component (Cl) 2208 and customer component (C2) 2214 are respective portions of a customer.

It will be understood by those skilled in the art that transmitter 2202 and / or receiver 2204 may include additional components. For example, transmitter 2202

72/111 can include an encoding component (not shown) that can modulate and / or encode signals according to a suitable wireless communication protocol whose signals can be transmitted to the 2204 receiver. According to some aspects, the encoding component can be a voice encoder (vocoder) that uses a speech analyzer to convert analog waveforms into digital signals or another type of encoder. Suitable wireless communication protocols may include, but are not limited to, Orthogonal Frequency Division Multiplexing (OFDM), Orthogonal Frequency Division Multiplexing Access (OFDMA), Code Division Multiple Access (CDMA), Access Time Division Multiple (TDMA), Global System for Mobile Communications (GSM), High Speed ​​Downlink Packet Access (HSDPA), and the like.

Receiver 2204 can include a decoder component (not shown) that can decode a received signal and / or data packet there for processing. Shortly after the successful decoding of a data packet, a confirmation component (not shown) can generate a confirmation that indicates successful decoding of the data packet, which can be sent to transmitter 2202 to inform transmitter 2202 of that the data packet was received and decoded and therefore does not need to be retransmitted.

host component 2206 can include a query module 2218 and a measurement module 2220. query module 2218 can be configured to query a host access control (MAC) for an application data rate that the MAC provides . For wireless communication, the rate of operation may depend on the rate of the wireless link. The 2220 measuring module can be

73/111 configured to determine the direct link rate and the reverse link rate based, for example, on a round trip delay measurement that can be specified in the wireless protocol. According to some aspects, the wireless operation rate can be determined by the minimum of the two rates (direct link rate and reverse link rate), the maximum host capacity 2206, and the maximum client capacity (Cl) 2208. There must be a minimum allowable fee R_mi_n. If the measured operating rate is below this minimum allowable rate, the operating rate can be adjusted by transmitter 2202 and / or receiver 2204 through respective components (for example, communication components 2210 and / or 2216). Transmitter 2202 can notify receiver 2204 of the rate at which the communication will be processed.

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

communication component 2216 can include a wired module 2226 and a wireless module 2228. The module

74/111 wired

2226 can be configured to provide wired functionality and the wireless module

2228 can be configured to provide wireless functionality.

A determination can be made in the direction of wireless communication using the wireless module

2228 or communication by sliding the 2226 wired module. This based on a variety of determining factors can include the rate of operation, the type of data being transmitted (by voice, text, image, being transmitted, via a wired module, a link store

2226 for etc.), the size of the data if the data is typically wired or from a link without or example, wire communicated files, etc. The and / or wireless module 2228 may include storing content so that if a change is made during module communication to another module (for example, from wireless to wired, wired to wireless) communication due to problems of

Information communicating via wire does not need to be transmitter in the same way or wirelessly).

Switching.

about whether the receiver is not lost

2204 is whether a wired link or a communicated to the link transmitter without

2202. THE

2202 performs its functions substantially independently of the communication method (wired according to some aspects, transmitter 2202 may include a component configured to fragment a subframe (not shown) configured component example, it is

802.15.3 and receiver 2204 can include one to reassemble the subframe (not the maximum of an MDDI subframe, as it can be approximately 65,536 generally smaller. The maximum size

MAC can be approximately bytes, although of a

4,096 approximately 8,192 bytes, if the underlying frame rate or de is approximately 480 Mbps.

The size can be

75/111 approximately underlying is

2,048 bytes if the physical layer rate is approximately 200 Mbps. Thus, the subframe may need to be fragmented on the side of the transmitter 2202 and reassembled on the side of the receiver 2204 to accommodate the reassembly of communication, frame size components. Such fragmentation and be carried out through respective, 2210 and 2216; and / or associated components by means of others to the 2202 transmitter, and the receiver

2204.

Figure 23 illustrates another aspect of a system

2300 to extend traditionally wired configurations to allow communication over a wireless link. The 2300 system may include a transmitter 2302 that includes a host 2306, a customer portion (Cl) 2308, and a communication component 2310. The 2300 system may also include a receiver 2304 that includes a 2312 device, a portion of a client (C2) 2314, and a communication component 2316. Transmitter 2302 communicates with receiver 2304 over a direct link and receiver 2304 communicates with transmitter 2302 over a reverse link. As noted earlier with reference to the figures above, although a number of transmitters 2302 and receivers 2304 can be included in the system 2300, a single transmitter 2302 that transmits communication data signals to a single receiver 2304 is illustrated for simplicity.

The system 2300 can include a memory 2318 operatively coupled to the receiver 2304. The memory 2318 can store information related to a data rate for a packet and / or a type of packet (for example, application data rate provided by the MAC, rate wireless link operation, etc.), operation mode for a package and / or package type, and / or other parameters associated with the

76/111 data transmission through a wireless protocol, through a wired protocol, or a combination of these protocols. For example, a wired protocol can be used for communication and a decision can be made to communicate a wireless protocol during communication, or vice versa, without interruption or termination.

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

Memory 2318 can store protocols associated with data communication rates, operating rates, performing action to control communications between receiver 2304 and transmitter 2302, etc., such that the system 2300 can employ stored protocols and / or algorithms for improved communication over a wireless network as described here. It should be considered that the data storage components (for example, memories) described herein may be either volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. As an example, and not as a limitation, non-volatile memory may include read memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM), which acts as

77/111 external cache memory. As an example, and not as a limitation, RAM is available in many forms such as synchronous RAM (DRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), data rate, dual SDRAM (DDR SDRAM), optimized SDRAM (ESDRAM ), DRAM Synchlink (SLDRAM), and RAM RAM direct (DRRAM). Memory 2318 of the disclosed aspects is intended to be understood, without being limited to these and other suitable types of memory.

Figure 24 illustrates a 2400 system for communication over a wired link or a wireless link with a traditional wired device. The 2400 system is represented as function blocks, which can be function blocks that represent functions implemented by a processor, software or a combination of them (for example, firmware). The 2400 system includes a receiver 2402 that can be configured to receive an operating fee for communication. This transaction fee can be received, for example, from an issuer or an issuer host. The operating rate can configure or establish the communication rate in both the forward and reverse direction. The 2400 system also includes a wireless communicator 2404 that can be configured to send and / or receive communication via a wireless protocol. A wired communicator 2406 can be configured to send and / or receive communication via a wired protocol.

It should be noted that in the forward and / or reverse direction there may be package extensions and / or new packages. For example, in a forward direction, MDDI sender information can be added to a package. This packet extension can provide an MDDI client at the receiver end with information from the MDDI sender side. This information can include the rate at which the

78/111 host MDDI and client must operate on the issuer's side. In the reverse direction, extensions to a client capacity package can include approximately four bytes for MDDI receiver MAC information and approximately two bytes for MDDI receiver client information, however other extensions are also possible.

Also included in the 2400 system is a determinator that can selectively determine whether to use the wireless communicator for communication via the wireless protocol or to use the wired communicator for communication via the wired protocol . Such determination can be made selectively based on several parameters, such as the communication operation rate. Other parameters can also be analyzed to make the determination. For example, the determination can be made based on how the specific communication has traditionally been sent and / or received (for example, historical analysis), the type of communication (for example, voice, image, text, etc.), as well as other parameters related to the communication, the sender, and / or the receiver.

Figure 25 illustrates an exemplary direct link 2500 MDDI data transfer in low overhead mode according to the various aspects presented here. One type of mode for an MDDI 2502 transmitter to send data to an MDDI 2504 receiver can be a low overhead mode. In this mode, a packet sent wirelessly is optimized for channel allocation time, which is the time it takes for data to be sent from any direction (for example, forward or reverse). The MDDI 2502 transmitter can include a customer (C1) 2506 portion and the MDDI 2504 receiver can include a (C2) 2508 customer processing portion.

79/111

An MDDI (Cl) 2506 client can place data to be sent in a storage, such as a UWD modem. The data to be sent should exclude unnecessary packets, such as filling packets and round-trip delay packets, for example. MDDI data is sent to a 2510 issuer MAC, as illustrated in 2512. The 2510 sender MAC (or MAC UWD) can periodically or continuously request at least one CTA from the MDDI 2502 sender to the MDDI 2504 receiver based, for example, on the size of the store.

2510 sender MAC can request, in 2514, direct link CTAs (for example, periodically or continuously) from a MAC 2516 piconet (PNC) controller. PNC MAC 2516 can respond to sender MAC 2510 with a response code of channel time at 2518. This response code can indicate whether the data has been successfully communicated. After a successful channel time response code is received, the sender MAC 2510 can send the MDDI data to a 2520 receiver MAC, as indicated in 2522.

Figure 26 illustrates an exemplary reverse link MDDI data transfer 2600 in low overhead mode according to the various aspects presented here. An MDDI 2602 receiver can initiate, via a reverse link, communication destined for an MDDI 2604 sender. The MDDI 2602 receiver can include a client portion (C2) 2606 and MDDI 2604 sender can include a customer portion (Cl) 2608 .

The MDDI receiver 2602 can send MDDI data to a 2610 receiver MAC, as indicated in 2612. The 2610 receiver MAC can request reverse link CTAs from a 2616 MAC, at 2616. The request can match the data that must be sent in the direction

80/111 reverse. PNC MAC 2614 can respond, in 2618, with a channel time response code. Receiver MAC 2610 can, in 2620, send MDDI data in CTAs to sender MAC 2622. As indicated in 2624, sender MAC 2622 may have sent or provided MDDI data to customer (Cl) 2608, in 2624, in some time before or substantially the same time as receiving MDDI data from the 2610 receiver MAC. A host of MDDI 2626 sender can send and / or receive at least one reverse link encapsulation to each frame, as indicated in 2628 in 2630. Reverse link data can be sent proactively, without waiting for a data request. The client can specify the number of bytes that it needs to send on the reverse link in the current frame. Host 2626 can correspondingly allocate the request in the reverse link encapsulation packet.

Figure 27 illustrates a low latency 2700 MDDI connection configuration according to the various aspects presented here. In low latency mode, the channel allocation time can be ascertained based on an inference derived from the data contained in packets in both the forward and reverse directions. An MDDI issuer 2702 may include a host 2704 and a portion of a client (CI) 2706. During an initialization phase, a UWB modem at transmitter 2702 can send a MAC query, at 2710, to a MAC transmitter 2708. A MAC query is a query sent to find out the rate supported by the MAC and relay statistics. Sender MAC 2708 can respond to the query at 2712. This response can be a MAC response that indicates the rate supported by the MAC relay statistic.

A MAC query packet is sent by the

81/111 host to query MAC information from the sender / receiver side. A Packet Length field is two bytes that contain a 16-bit unsigned integer that specifies the total number of bytes in the packet not including the packet length field. A Package Type field is two bytes that contain a 16-bit unsigned integer. A packet type of 151 identifies the packet as a MAC query packet. A client ID is bytes that contain a 16-bit unsigned integer reserved for the target client ID (C2). The MAC Lookup Parameters field is two bytes and a CRC field is two bytes that contain a 16-bit CRC of all bytes in the packet including the Packet Length.

Emitter 2702 requests a CTA 2714 setting for m msec in the forward direction and a CTA for n msec in the reverse direction. The expected rate of traffic in the forward and reverse directions must be m: n. At 2716, a channel time request (CTRq) is sent to a PNC MAC 2718. A channel time response code can be sent in the reverse direction, shown in 2720, and in the forward direction, shown in 2722 and sent to a MAC 2724 receiver. The MDDI issuer 2702 can initiate an MDDI transfer, as illustrated in 2726.

The duration corresponding to the Rf-mddi MDDI direct link transfer rate is m sec, and then T is the superframe duration determined by the application's latency restrictions, the following formula applies:

m + n &lt;Tctap &lt;f

In low latency mode, reverse link data can be sent during reserved CTAs in the reverse direction. Depending on the arrival time of the reverse link data in relation to the MAC superframe, the transfer may have a maximum latency expressed as:

82/111

T_ri = ceil [{k * {N / Ri + RIFS + H / R₂) + SIFS + T_ACK} / n] * T where k is the average number of retransmissions expected by a MAC frame. N is the size of the reverse link packet that must be sent and n is the duration of the reverse link CTA in each superframe. R₂ is the physical layer transmission rate of the MDDI data (MAC payload) R₂ is the transmission rate of the physical layer of the PHY, MAC headers and the preamble. H is the size of the MAC plus the size of the PHY header plus the size of the preamble. SIFS is the short spacing between frames. RIFS is the duration of spacing between frames, of retransmission. T_B.Ck is duration of the transmission of

ACK. T is the superframe duration.

For the sake of explanation, ACK policy is assumed to be mm-ACK.

The latency of the direct link packets, T_fl, can be determined accordingly.

Given the application latency restrictions on the forward and reverse links, the frame time duration

MAC can be derived accordingly. For example, and / or techniques can be used to derive the duration of various algorithms, methods, time of the MAC frame and / or the latency of the direct link packets.

Due to the exemplary systems shown and described, methodologies which can be implemented according to one or more aspects are provided. Although, for the sake of simplicity of explanation, the methodologies are shown and described as a series of actions (or function blocks), it should be understood and considered that the methodologies are not limited by the order of actions, since some actions can, according to these methodologies, occur in different orders and / or simultaneously with other actions from those shown and described here. In addition, not all illustrated actions may be required to implement the following methodologies. It should

83/111 be considered that the various actions can be implemented by software, hardware, a combination of them or any other suitable means (for example, device, system, process, component) to carry out the functionality associated with the actions. It must also be considered that the actions are only to illustrate certain aspects presented here in a simplified form and that these aspects can be illustrated by a smaller and / or greater number of actions. Those skilled in the art will understand and consider that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram.

Referring now to Figure 28, a 2800 methodology for configuring a traditionally wired device for communication via a wired protocol and / or a wireless protocol is illustrated. In 2802, a first portion of a customer is placed on an MDDI issuer. The MDDI transmitter can be wireless and can be connected to a data source. 0 MDDI sender can also include an MDDI host connected to or interfaced to the client portion using, for example, a traditional wired MDDI link.

In 2804, a second portion of the customer is placed in an MDDI receiver, which can be a wireless MDDI receiver. The MDDI receiver can be connected to a device, which can be, for example, a display. The customer portion placed on the MDDI sender and the customer portion placed on the MDDI receiver are separate portions of the same customer. It should be noted that the respective portions of the customer can be portions represented by a processor, software or combination thereof (for example, firmware).

Both wired and wireless functionality are provided in 2806. This

84/111 functionality is included in the MDDI receiver, enabling the MDDI receiver to communicate via wired functionality, wireless functionality, or both.

As an example and not as a limitation, an MDDI receiver can be a mobile device that can receive a communication, such as a movie that is shown on a CRT screen or display. The mobile device can also be connected to a wall-mounted display, allowing the film to be displayed on the wall so that others can view the images. If the mobile device is multifunctional, it can broadcast the film on the display and can substantially at the same time receive or send a voice communication, different from the voice communication associated with the film. Thus, a user of the mobile device can conduct a separate communication from the film. An example where this could be used is when a user's child is watching a movie and the user wants to answer the phone and walk away. Thus, the film can be displayed via wired functionality and at the same time substantially the user can communicate via wireless functionality.

Figure 29 illustrates a 2900 methodology for determining an operating rate according to one or more revealed aspects. In a wireless MDDI, for example, the rate of MDDI operation depends, in part, on the rate of the wireless link. The 2900 method for determining an operating rate begins, at 2902, where a host MAC is queried in terms of an available application data rate (for example, the application data rate that the MAC provides). The query can be requested by an MDDI host, for example.

In 2904, a round trip delay is measured. THE

85/111 round trip delay measurement can be used, in 2906, to determine or ascertain a direct link rate and a reverse link rate. According to some aspects, the round trip delay measurement can be specified in a wired MDDI protocol that must be used.

An operating fee is computed at 2908. The operating fee can be computed based in part on comparing the direct link rate and reverse link rate and determining which is the minimum of the two rates. The minimum of these two fees can be referred to as the operating fee. In some respects, the minimum of these two fees may be referred to as the transaction fee. In some respects, the minimum of these two fees (direct link fee and reverse link fee) can be purchased additionally with both, the maximum capacity of an MDDI host and the maximum capacity of an (Cl) MDDI client. The minimum or lowest rate based on this comparison is assigned as the operating rate.

There must be a minimum allowable fee R_mi_n, which can be established or predetermined based on the communication parameters. If the computed operating rate is less than the minimum allowable rate, adjustments can be made to increase the rate. In 2910, the transaction fee is communicated or sent to a receiver (for example, receiver

<td>MDDI) for</td><td colspan="2">notify the recipient</td><td>on</td><td>the rate at which</td><td>The</td>

<td>Communication</td><td>will continue.</td><td></td><td></td><td></td><td></td>

<td>At</td><td>methodology</td><td>above</td><td> 2900,</td><td>for example,</td><td>one</td>

<td>transmitter</td><td>can consult</td><td colspan="2">the host</td><td>MAC through</td><td>one</td>

consultation module. The transmitter can additionally measure the round-trip delay; ascertain the rate of direct and reverse link; and compute the rate of operation using a measurement module. The transmitter can also send the operating rate to the receiver using a component of

86/111 communication. It should be understood that the above is for example only and that other components can be used in connection with one or more aspects presented here.

Referring now to Figure 30, a 3000 methodology for low overhead mode communication is illustrated according to the various aspects presented here. The direct link is shown on the left side of the figure and the reverse link is shown on the right side of the figure.

In 3002, direct link data is placed in a store. Excluded from the data placed in the store may be unnecessary data such as filling packets and / or round-trip delay packets. This data can be placed in the store via an MDDI client (Cl) at an MDDI issuer, for example. In 3004, unidirectional CTAs are requested (for example, periodically or continuously). A MAC UWB can request this information from the MDDI sender to a receiver based, for example, on the size of the store. Direct link data can be sent in 3006.

In the reverse direction, a host sends at least one reverse link encapsulation packet to each frame. A customer (for example, receiver) can specify the number of bytes that must be sent on the reverse link in the current frame. The host (for example, sender) can allocate the request in a reverse link encapsulation packet. In 3008, the reverse link data that must be sent is placed in a store using, for example, an MDDI client (C2). The store can be located on a UWB modem from an MDDI receiver. A request for CTAs in reverse direction is sent, in 3010, using, for example, a UWB modem on the side of the MDDI receiver. THE

87/111 request can be for those CTAs in the reverse direction corresponding to the data that must be sent in the reverse direction.

An MDDI client at the receiver (C2) can proactively send the reverse link data to the client at the sender (Cl) in 3012. As illustrated, in 3014, an MDDI client at the sender (Cl) sends the data he has to the MDDI host in the reverse encapsulation package.

Figure 31 illustrates a 3100 methodology for communicating in low latency mode according to the various aspects presented here. The direct link is shown on the left side of the figure and the reverse link is shown on the right side of the figure. During an initialization phase in low frequency mode, a UWB modem at the sender, for example, requests, in 3102, a CTA for m msec in the forward direction. At 3104, a CTA request for n msec is sent in the reverse direction. A comparison of the forward and reverse CTAs received in response to requests is made in 3106. The expected ratio of traffic in forward and reverse directions is ia: n. It should be noted that m msec is the duration corresponding to the direct link transfer rate MDDI of Rf-mddi and:

(m + n) &lt;Tctap k T where T is the superframe duration, which can be determined by the application's latency restrictions.

In the reverse direction during a low latency mode, reverse link data is sent, in 3108, during the CTAs reserved in the reverse direction. At 3110, a MAC frame time duration can be derived from the application latency restrictions on the forward and reverse links. In the following equation, k is the average number of retransmissions experienced by a MAC frame. N is the size of the reverse link packet that must be sent en

88/111 is the reverse link CTA duration in each superframe. Ri is the physical layer transmission rate of MDDI data (MAC payload). R₂ is the transmission rate of the physical layer of the PHY, MAC and preamble headers. H is the size of the MAC and the size of the PHY header and the size of the preamble. SIFS is the duration of spacing between frames. RIFS is the duration of the spacing duration between frames, transmission of the retransmission. T_B.Ck is

ACK and T is the duration of the superframe.

For explanatory purposes, it is assumed that direct ACK, T_fl, be lmm-ACK. The latency of the link packets can 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 transfer may have a maximum expressed as:

T_rl = ceil [{k * (N / R₂ + RIFS + H / R₂) + SIFS + a latency

T_ACK} / n] * T

Referring now to the drawings, it illustrates a 3200 method for communicating digital data at a high rate, which

Figure 32 wirelessly initiated by a receiver. The can be 3200 method can facilitate wireless communication between a host entity (for example, sender) and one or more remote user interface client devices (for example, receivers).

Wireless communication can include user interface data or other data.

When one or more client devices (without host entity) the 3200 method starts, in step 3202, through association with the host entity. Such an association may include association.

wirelessly entity with more sending a packet requesting the host can communicate on than a remote device

89/111 user interface client at substantially the same time. When the association is established with the host entity, a capacity packet is sent to the host entity, at 3204. The capacity pack can include one or more capabilities of the remote user interface client device. In 3206, a status packet is sent to the host entity. The status package can include link quality information.

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

association between one or more user interface client devices, remote, host entity may be interrupted due to a communication failure, the devices moving out of reach, or based on other factors. It can be determined that an association is terminated if a status packet within a substantially host entity is not received at a predetermined period. For example, at the same time that a host entity status package is requested, a time recorder can be started. The time recorder can be configured to monitor an interval from the moment the request is sent. The interval can be predetermined and must be long enough to allow the request to be received at the host entity and for the host entity to respond. If the time recorder expires (for example, the response does not

<img file="BRPI0814654A2_D0002.tif" />

is received within the predetermined range), the one or more remote user interface client devices can be decoupled from the host entity.

Decoupling from the host entity can also occur if a device is interrupted.

remote, they can decouple from the sending state of a host and the response entity from the communication devices

If communication between them is the case, the interface of the host entity of decoupling. Dissociation can request dissociation in order to receive a host dissociation response.

host dissociation, or if a one or a user, and enter include the entity from

According to some aspects, it could not be received from such as when there is a link failure it has been broken.

Referring now to method 3300 for high rate communication between remotes for data initiates the association of a sender or association between

Figure 33, data on an interface when a specific wireless receiver is illustrated. By wire is a telephone and the telephone receiver (for example, would initiate the process by the sender is similar to

The 3300 issuer method is associated with the user interface, initiated by the issuer.

the digital one or more user.

want if example, if wireless is wireless receivers

The transmitter associates with a wireless transmitter) a transmitter without a projector, the typically association. The association initiated association initiated by the receiver.

can start in 3302 when one with one or more remote devices, through

Such an association may result in a request to the receiver that an association include sending and an association be established between the devices. The receiver can respond to the request, indicating that the association is

91/111 possible (for example, that the receiver is not associated with another sender). Substantially at the same time that the devices are paired, a packet that includes capacity information is received, in 3304, from the remote user interface device and, in 3306, the link quality information is received, as in a reverse link. The information can be sent in response to a C2 Request Packet which can be sent by the wireless sender to the receiver requesting that the receiver send the client capacity packet. The C2 Request Package can include Package Length, Package Type, Customer ID C2 and C2 flags and CRC fields. The Packet Length field is two bytes that contain a 16-bit unsigned integer that specifies the total number of bytes in the packet, not including the packet length field. The Packet Type is two bytes that contain an unsigned 16-bit integer. A package type of 149 identifies the package as a C2 request package. The C2 Client ID field is two bytes that contain an unsigned 16-bit integer reserved for C2 ID. 0 flag field C2 is a byte containing an unsigned 8-bit integer containing a set of flags to request information from C2. For example, if a bit is set to 1, then Cl requests the specified information from the client. If the bit is set to 0, then Cl does not need the information from C2. Bit 0 indicates that Cl needs the client capacity packet from C2. Bit 1 indicates that Cl needs the Status and Client Request Package from C2. The CRC field is two bytes that contain a 16-bit CRC of all bytes in the packet including the Packet Length.

In some situations, the issuer may initiate a

92/111 association, but the receiver may already be associated with a different receiver or may not wish to associate with that sender. In this situation, an Association Denial Package can be sent by the customer (C2) as a response to an association request when he does not wish to associate with the Issuer W-MDDI (after calling). The Association Deny Package contains several fields including Packet Length, Packet Type 160, Sender MAC Address, Receiver MAC Address, a Reason Code, and CRC. The Packet Length can be two bytes that contain a 16-bit unsigned integer that specifies the total number of bytes in the packet not including the packet length field. The Packet Type can be two bytes that contain a 16-bit unsigned integer. A package type of 160 identifies the package as a denial of association package. The Sender MAC Address can be a six-byte MAC Address of the W-MDDI sender and the Receiver MAC Address can be a six-byte MAC Address of the W-MDDI Receiver. The Reason Code is a byte indicating the reason for the negation (0x1, 0x2, 0x3, or 0x4). 0x1 indicates already associated with another issuer / issuers; can no longer associate. 0x2 indicates the association in progress with another issuer. 0x3 indicates local error and 0x4 is mixed. The CRC is two bytes that contain a 16-bit CRC of all bytes in the packet including the Packet Length.

Another package that can be sent is a MAC CTA Establishment Package that is used by the host to establish CTAs in forward and reverse directions. This can be used in the low latency operating mode of wMDDI with IEEE 802.15.3 MAC. If the MAC protocol allows the issuing MAC to establish CTAs in the reverse direction, then that packet will be dropped at the issuer. Otherwise, it will be sent to the recipient. The content of the

93/111

MAC CTA Establishment Packet includes the Packet Length field which is two bytes containing an unsigned 16-bit integer specifying the total number of bytes in the packet, not including the packet length field. A Packet Type field is two bytes that contain an unsigned 16-bit integer. A package type of 152 identifies the package as a CTA configuration package. 0 CIClientID field is two bytes that contain a 16-bit unsigned integer for host ID - 0. A C2ClientID field is two bytes that contain a 16-bit unsigned integer reserved for C2 ID. The forward CTA parameters are CTA parameters for data transfer in the forward direction and the reverse CTA parameters are CTA parameters for data transfer in the reverse direction.

Figure 34 illustrates a 3400 device that initiates the device association according to the different aspects. The 3400 device can be a receiver configured to communicate high-rate digital data and which wishes to associate with a wireless transmitter or remote host device 3402. The 3400 device can include a 3404 memory that can be configured to store information. Such stored information may include a MAC address associated with the 3400 device and / or a Customer ID (as received in an Association Response Package). For example, at substantially the same time as being associated with a specific wireless transmitter, the wireless receiver can store the MAC address of the transmitter, or remote host device 3402 with which the 3400 equipment is associated.

A 3406 processor can also be included in the 3400 equipment, which can be configured to analyze the information stored in the 3404 memory. The 3406 processor

94/111 can additionally selectively associate the 3400 equipment with the remote host device 3402.

According to some aspects, processor

3406 can associate the equipment

3402 with remote host device 3402 substantially at the same time as receiving an associated request packet from remote host device 3402. However, a response packet is not received from remote host device 3402 after a predetermined interval and a maximum number of association requests sent has been exceeded, processor 3406 does not associate equipment 3400 with remote host device 3402.

The 3400 equipment may also include a communication data component 3408 that can be configured to update a MAC Response Package with the MAC statistics of equipment for transmission to the remote host device 3402. After entering an associated state, the wireless receiver you can periodically, like every mac_response_time msec, send a MAC Response Packet. Host device 3402 can respond with a packet that acknowledges receipt of the MAC Response Packet sent by device 3400. If device 3400 does not receive a response after the predetermined time interval (for example, duration of mac_response_full_time msec), device 3400 could deduce that it has been decoupled from the host device 3402 and stops sending the MAC Response Packet. Equipment 3400 and host device 3402 can become decoupled, as described above. According to some aspects, the 3400 device sends a MAC Response Packet when specifically requested to do so by the host device 3402.

95/111

Equipment 3400 and remote host device 3402 can become decoupled, either intentionally or unintentionally. For example, a communication link may be lost between equipment 3400 and remote user device 3402 due to a communication failure, devices moving out of range, or for other reasons. For example, if a decoupling request packet is received from remote host device 3402, the processor decouples equipment 3400 from host device 3402 substantially at the same time as receiving the request. In another example, if a status packet is not received from remote host device 3402 in response to the updated MAC response packet transmitted, processor 3408 will selectively decouple based on the inference that equipment 3400 and host device 3402 they should no longer be associated.

According to some aspects, the 3400 equipment may include a 3410 display component that can be configured to compile one or more alternative display information. The alternative display information can be associated with the 3400 device. The 3410 display component can additionally be configured to transmit one or more alternative display information to the remote host device 3402. For example, if there are alternative displays associated with the wireless receiver, an Alternative Display Capacity Pack can be sent to the remote host device 3402.

Referring now to Figure 35, a 3500 device is illustrated which can be configured to wirelessly communicate high rate user interface data. The 3500 device may include a 3502 memory

96/111 that can be configured to store information related to an identification of a remote user interface device, such as a Client ID assigned to the remote device. A 3504 processor can be configured to selectively associate with one or more remote user interface devices based in part on information stored in memory 3502.

The 3500 equipment may also include an information component 3506 that can be configured to analyze at least one capability of one or more remote user interface devices. The capacity can be received in a customer capacity package. The information component 3506 can additionally be configured to analyze the link quality information data received in a status update package.

According to some aspects, equipment 3500 may include a status recorder 3508 that can be configured to determine whether a response to the issuer association request is received within a predefined interval. If the response is not received within a predefined interval, a subsequent issuer association request can be sent by the 3504 processor.

If decoupling from the remote user interface device is desired, the 3504 processor can selectively disassociate from the remote device. For example, the 3504 processor can selectively decouple if the link quality information data indicates that the quality of a communication link has fallen below a predetermined threshold.

Referring now to Figure 36, a conceptual block diagram of a possible configuration is illustrated

97/111 of a 3600 terminal. As those skilled in the art will consider, the exact configuration of the 3600 terminal may vary depending on the specific application and overall design restrictions. The 3602 processor can implement the systems and methods disclosed here.

Terminal 3600 can be implemented with a 3604 front-end transceiver coupled to a 3606 antenna. A 3608 baseband processor can be coupled to the 3604 transceiver. The 3608 baseband processor can be implemented with a software-based architecture, or other type of architectures. A microprocessor can be used as a platform to run software programs that, among other functions, provide global system management and control functions. A digital signal processor (DSP) can be implemented with an integrated communication software layer, which executes application-specific algorithms to reduce the processing demands on the microprocessor. The DSP can be used to provide signal processing functions such as pilot signal acquisition, time synchronization, frequency monitoring, spectral spread processing, modulation and demodulation functions, and early error correction.

The 3600 terminal can also include several 3610 user interfaces coupled to the 3608 baseband processor. The 3610 user interfaces can include a keyboard, mouse, touch screen, video, doorbell, vibrator, speaker, microphone, camera and / or others input / output devices.

The 3608 baseband processor comprises a 3602 processor. In a software-based implementation of the 3608 baseband processor, the 3602 processor can be a software program running on a

98/111 microprocessor. However, as those skilled in the art will easily consider the 3602 processor is not limited to this aspect, and can be implemented through any means known in the art, including any hardware configuration, software configuration, or any combination thereof, able to perform the various functions described here. The 3602 processor can be coupled to the 3612 memory for data storage.

Figure 37 illustrates an association procedure initiated by the 3700 receiver when security is enabled according to the revealed aspects. A w-MDDI 3704 receiver transmits a 3706 association request packet to a w-MDDI 3702 sender. At that point the devices are in a non-association state. The w-MDDI 3704 receiver can enter an association response waiting state. The w-MDDI 3702 issuer can respond with a 3708 Membership Response Package. If a response is not received, a number of membership request packets can be sent, up to a maximum number of retries and before the expiration of a predefined time interval. Right after receiving the 3708 membership response packet, a 3710 Client Capacity Packet is sent from the 3704 w-MDDI receiver to the w-MDDI sender. These three packages represent a 3712 handshake.

Devices can enter an associated state. Devices can remain in the associated state until a decoupling request is received / confirmed and / or until there are no responses received for various LinkStatus packets.

According to some aspects, an optional 3714 mutual key / authentication exchange can be performed. An alternative display capacity pack 3716 is sent to the w-MDDI 3702 transmitter, if displays

99/111 alternatives available. In 3718, response packages

MAC can be sent to the w-MDDI transmitter.

Figure 38 illustrates an association procedure initiated by the 3800 issuer when sequencing is enabled according to the revealed aspects. A w-MDDI 3802 transmitter transmits a 3806 transmitter association request to a w-MDDI receiver. At that point, the devices are in an unassociated state. The device is in an association request waiting state. The 3804 receiver can respond with a 3808 association request. The sender w-MDDI 3802 responds with an association response 3810 and a client capacity packet 3818 is sent by the w-MDDI receiver 3804 (for example, device in standby for client capabilities). The four packages mentioned above are included in a 3814 four-way handshake.

According to some aspects, an optional 3816 mutual key exchange / authentication can be performed. The w-MDDI 3804 receiver can transmit an alternative display capability packet 3818. Thereafter, link status response packets 3820 can be transmitted. The w-MDDI sender 3802 can provide the sender link status packets 3822 to the w-MDDI receiver.

Figure 39 illustrates a host association (emitter) diagram

3900. At 3902, host is in an unassociated state (for example, there is no association between the host and a customer). To associate with a customer, indicated by line 3904, the host sends a request for membership and enters a state of Waiting for Membership Request (WAReq) 3906. According to some aspects, in response to the membership request, an Association Denied could be received, as indicated in 3908. If an Association

100/111

Denied is received, the host returns to the non-associated state 3902.

Substantially at the same time that the membership request is submitted, in 3904, a time recorder can be started which indicates a maximum period of time that the client will be allowed to respond to the request.

While waiting for the response from the client, the host could transmit some association requests (for example, retries) up to a maximum number of retries.

host remains in the state

WAReq 3906 as long as the time recorder has not expired and the number of retries has not exceeded the maximum number of retries indicated in 3910.

If the time recorder expires and / or the maximum number of retries is exceeded, the host enters an unassociated state at 3912.

In response to the membership request, a Membership Request can be received in 3914 and the host moves to a Customer Capability Waiting (WCC) 3916 state. According to some aspects, the host may change from the non- associated 3902 directly to WCC state 3916 if a 3918 Membership Request is received while the host is in non-associated state 3902 (for example, skipping the WAReq 3906 state).

Substantially at the same time as entering the WCC 3916 state, the host can initiate a time recorder to limit the time period waiting for a response from the client. The host could also send a number of requests for a client capacity response, up to a maximum number of retries (MAX_RETRIES), as indicated in 3920. If the

101/111 time recorder expires and / or the MAX RETRIES have been exceeded, the host, at 3922, returns to the non-associated state 3902.

Substantially at the same time as receiving Customer Capabilities, in

3924, the host enters associated state 3926. The host may remain in associated state 3926 until a Request for

Dissociation is received, in

3928, from the customer.

Substantially at the same time as receiving the

Dissociation Request, the host changes to non-associated state 3902.

According to some aspects, an interruption in a LinkStatus 3930 packet causes the host to change from an associated state 3926 to an unassociated state 3902.

In this situation, the host has not received a Packet of

Link Status (MAC Response Pack) for the duration of mac_response_fail_time msec. link status for one

Failure to receive a packet at a predefined time period indicates that the client is no longer associated with the host.

According to some aspects, the host may decide to dissociate, indicated in 3932, and the host changes from the associated state 3926 to the non-associated state

3902.

Figure 40 illustrates a customer association status diagram. In 4002, the customer is in a non-associated state. A customer association request is sent in 4004 and the customer enters a state of waiting for response from association (WAResp) in 4006.

Substantially at the same time as the request is sent, in

4004, a time recorder can be started to allow a limited amount of time during which the host waits for the Association Response. According to some aspects, the customer can enter the state

WAResp

102/111

4006 when an Issuer Association Application is received in 4008.

While waiting for the Membership Response, host could send multiple membership requests

4004, up to a maximum number of requests.

host remains in the WAResp state

4006 provided the time recorder has not expired and the number of retries has not exceeded a maximum number of retries (MAX RETRIES) as indicated in 4010.

If the time recorder expires and / or the number of retries exceeds MAX RETRIES, the host changes to the non-associated state at 4012.

According to some aspects, a denied association could be received, indicated in 4014 in a request for membership. The association could if the host was already associated with another for other reasons. Right after receiving the response to be denied customer or

Association

Denied, the client enters non-associated state 4002.

The customer remains in the WAResp 4006 state until an Association Response is received in 4016. Substantially at the same time as receiving the Association Response, the customer enters an associated 4018 state. The customer can remain in the associated state 408 until a decoupling request is received, in 4020, until no response has been received by multiple Link Status packages in 4022, and / or until the customer (for example, user ) wishes to dissociate from the host in 4024. If any of these three events 4020, 4022, 4024 occurs, the client returns to the non-associated state 4002.

Figure 41 illustrates a 4100 system for wirelessly communicating data at a high rate between a host entity and at least one remote wireless MDDI capable client device. Should be considered

103/111 that the 4100 system is represented as including function blocks, which can be function blocks that represent functions implemented by a processor, software, or combination thereof (for example, firmware).

A logical grouping 4102 is included in the 4100 system that includes an electrical component 4104 to perform a service discovery process to compile information related to a plurality of wireless MDDI capable client devices in a local area. According to some aspects, information related to a plurality of wireless MDDI capable client devices includes a sequence identifier corresponding to a device name, device capabilities, and a status indication, where the information is retained locally.

Also included in logical grouping 4102 is an electrical component 4106 for receiving a request for association with at least one of the plurality of wireless MDDI capable client devices. The request can be received from a user, for example.

In addition, logical grouping 4102 includes an electrical component 4108 to determine the security capabilities of each of the various wireless MDDI capable client devices and an electrical component 4110 to selectively perform a security association procedure. For example, the security procedure can be performed if both devices are security enabled and security is required for both devices. Also included is a 4112 electrical component for association with at least one of the plurality of wireless MDDI capable client devices.

According to some aspects, the logical grouping also includes an electrical component to transmit

104/111 a message to a lower layer to obtain a list of devices and an electrical component to receive a response which includes the list of devices. Also included in the logical grouping is an electrical component for transmitting a packet for each of the devices included in the received list and an electrical component for receiving a response that contains sequence identifiers for each of the responsive devices.

According to some aspects, the lower layer supports multicast. In that regard, the logical grouping includes an electrical component for transmitting a service query packet to a multicast group to request information from a selected wireless MDDI capable client device. The multicast group is specified by a multicast address.

In another aspect, the bottom layer is wiMedia UWB MAC and the logical grouping includes an electrical component to receive application specific information elements related to each of the w-MDDI capable client devices.

According to some aspects, the bottom layer is UDP / IP. In this respect, the logical grouping includes an electrical component for communicating a service inquiry packet to a multicast group on a UDP port. Also included in the logical grouping is an electrical component for association with the multicast group on the UDP port and an electrical component for receiving a service response from each device that supports w-MDDI.

In addition, the 4110 system may include a 4114 memory that holds instructions for performing functions associated with electrical components 4104, 4106, 4108, 4110, and 4112, or other components. Although shown to be external to memory 4114, it should be understood that one or more

105/111 plus electrical components 4104, 4106, 4108, 4110, and 4112 may exist within memory 4114.

Figure 42 illustrates a 4200 system for communicating data wirelessly at a high rate with a host entity. It should be considered that the system

4200 is represented as including function blocks, which can be function blocks that represent functions implemented by a processor, software, or combination thereof (for example, firmware).

A logical grouping is included in the 4200 system

4202 which includes an electrical component 4204 to send a neighbor list message to a lower layer, neighbor list message requests a list in a local area.

An electrical component is also included

4206 to receive a list of devices in the local area.

In addition, logic group 4202 includes an electrical component

4208 to transmit a query packet to each of the devices. An electrical component

4210 to receive a response that includes sequence identifiers for the responsive device is included. The response is received before the expiration of a predetermined interval.

According to some aspects, the neighbor list message is a Get Neighbor List message and the device list is received from a lower Layer Neighbor List layer in a Reply

<td>Bottom</td><td colspan="2">. In</td><td>wake up</td><td colspan="2">with some</td><td colspan="2">aspects,</td>

<td>Query</td><td>is</td><td>one</td><td>package</td><td>in</td><td>Query</td><td>in</td><td>Service</td>

<td>answer</td><td>is</td><td>one</td><td>package</td><td>in</td><td>answer</td><td>in</td><td>Service</td>

The

Receiver Service Discovery).

example, w-MDDI and w-MDDI (per package of

According to other aspects, the consultation package is a package of

Host Consultation w-MDDI and the answer is a package of

Host Response w-MDDI (for example,

Discovery of

106/111

Issuer Service).

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

In addition, the 4200 system may include a 4214 memory that holds instructions for performing functions associated with electrical components 4204, 4206, 4208, 4210, and 4212, or other components. While shown to be external in memory 4214, it should be understood that one or more electrical components 4204, 4206, 4208, 4210, and 4212 may exist within memory 4214.

It should be understood that the aspects described here can be implemented by hardware, software, firmware or any combination thereof. When implemented in software, functions can be stored in, or transmitted via, one or more instructions or code in a computer-readable medium. Computer-readable media include computer storage media and communication media including any medium that facilitates the transfer of a computer program from one place to another. The storage media can be any available media that can be accessed by a common or special use computer. As an example, and not as a limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disc storage media,

107/111 magnetic disk or other magnetic storage devices, or any other medium that can be used to transport or store medium of desired code in the form of instructions or program structures given and that can be accessed by a computer in common use or special-use processor, or a common-use or special-use processor.

In addition, any connection is properly called a computer-readable medium.

For example, if the software is downloaded from a website

Network, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line, or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, cable optical fibers, twisted pair of wires,

DSL, or wireless technologies such as infrared, radio, and microwave, are included in the definition of medium.

Disk and floppy disk, as used herein, include compact disk versatile digital disk (CD), laser disk, optical disk,

<td colspan="2">(DVD), floppy disk</td><td>and</td><td>disco</td>

<td>normally</td><td>reproduce</td><td>the</td><td>Dice</td>

<td>what disks</td><td>reproduce</td><td>the</td><td>discs</td>

magnetically,

Combinations optically with blu-ray where floppies while lasers.

of those mentioned above should also be included in the scope of computer-readable media.

The various illustrative logics, logic blocks, modules, and circuits disclosed herein can be described in connection with the aspects to be implemented or carried out with a common use processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC) , an array of field programmable ports (FPGA) or other programmable logic device, transistor logic or discrete port, discrete hardware components, or any combination thereof, designed to perform the functions described here. A processor to use

108/111 common can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In addition, at least one processor may comprise one or more modules operable to perform one or more of the steps and / or actions written above.

For a software implementation, the techniques described here can be implemented with modules (for example, procedures, functions and so on) that perform the functions described here. The software codes can be stored in memory units and executed by processors. The memory unit can be implemented inside the processor or external to the processor, in which case it can be connected communicatively to the processor through various means as is known in the art. Additionally, at least one processor can include one or more modules operable to perform the functions described here.

The techniques described here can be used for various 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 can implement radio technology such as Universal Terrestrial Radio Access (UTRA), CDMA2000, etc. UTRA includes Broadband CDMA (W-CDMA) and other CDMA variants. Additionally, CDMA2000 covers the IS-2000, IS-95 and IS-856 standards. A TDMA system can implement radio technology such as Global System

109/111 for Mobile Communications (GSM). An OFDMA system can implement radio technology such as UTRA Evolved (E-UTRA),

Ultra Mobile Broadband (UMB)

IEEE 802.11 (Wifi), IEEE

802.16 (WiMAX), IEEE

802.20,

Flash-OFDM®, etc.

UTRA and

E-UTRA constitute part of the

Universal Mobile Telecommunication (UMTS).

Long Evolution

Term (LTE)

3GPP is a version of UMTS that uses E-UTRA, which employs

OFDM on the downlink and SC-FDMA on the uplink. UTRA, EUTRA, UMTS,

LTE and

GSM are described in the documents from an organization called the 3-Year Partnership Project^The

Generation (3GPP). In addition, CDMA2000 and UMB are described in the documents from an organization called Project 2 of Partnership of 3^The Generation (3GPP2). In addition, such wireless communication systems may additionally include non-hierarchical ad hoc network systems (for example, mobile to mobile) often using unlicensed, unpaired spectra, 802.xx wireless LAN, BLUETOOTH and any other communication technologies wireless, short-range or long-range.

In addition, several aspects or features described here can be implemented as a method, equipment, or industrial product using standard engineering and / or engineering techniques. The term industrial product as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or medium. For example, computer-readable media may include, but are not limited to, magnetic storage devices (eg, hard disk, floppy disk, magnetic strips, etc.), optical discs (eg, laser disc (CD), digital disc (DVD), etc.), smart cards, flash memory devices (eg EPROM, card, stick, key unit, etc.).

110/111

In addition, various storage media described herein may represent one or more devices and / or other machine-readable media for storing information. The term machine readable medium may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or transporting instruction (s) and / or data. In addition, a computer program product may include a computer-readable medium having one or more instructions or operable codes to cause a computer to perform the functions described herein.

In addition, the steps and / or actions of a method or algorithm described in connection with the aspects disclosed herein can be incorporated directly into hardware, a software module executed by a processor, or a combination of the two. The software module can reside in memory

RAM, flash memory, ROM memory, EPROM memory, memory

EEPROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

An exemplary storage medium can be coupled to the processor, such that the processor can read information from the storage medium and write information to it. Alternatively, the storage medium can be integral to the processor.

Additionally, in some respects, the processor and the storage medium may reside in an ASIC. Additionally, the ASIC can reside on a user terminal. Alternatively, the processor and the storage medium can reside as discrete components in a user terminal. Additionally, in some respects, the steps and / or actions of a method or algorithm may reside as one or as any combination or set of codes and / or

111/111 instructions in a machine-readable medium, and / or a computer-readable medium, which can be incorporated into a computer program product.

Although the previous disclosure discusses illustrative aspects and / or aspects, it should be noted that several changes and modifications could be made to it without departing from the scope of the described aspects and / or the aspects as defined by the attached claims. Consequently, it is intended that the aspects described cover all such changes, modifications and variations that fall within the scope of the attached claims. In addition, although elements of the described aspects and / or aspects can be described or claimed in the singular, the plural is considered unless limitation to the singular is explicitly stated. In addition, all or a portion of any aspect and / or aspect may be used with all or a portion of any other aspect and / or aspect, unless otherwise stated.

To the extent that the term includes is used in the detailed description or in the claims, it is intended that such a term is inclusive in a manner similar to the term comprising as understood is interpreted when it is used as a transitional word in a claim. In addition, the term or as used in the detailed description of the claims is intended to be one or non-exclusive.