System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment

The invention claimed in the present application generally relates to the field of communication, and more particularly to the field of wireless communication in a network having a plurality of nodes.

Recent trends in communications have shown that visual content is becoming a more important aspect of both the communications themselves and the devices that enable such communications. For example, displays have become even more essential to the operation of mobile phones in recent years. The Mobile Display Digital Interface (MDDI) protocol is a cost-effective and low-power solution that enables high-speed, short-range communication using display devices such as the display portion of a clamshell type or flip phone. Has been chosen by a large number of manufacturers and users. The MDDI protocol uses a small connector system and thin flexible cables to connect portable computing, communication, and entertainment devices, commonly referred to as hosts and clients, respectively, to the display. However, with the development of ultra-wideband and high-speed wireless technologies such as 802.11n, there is an increasing demand for wireless communication between computing platforms and displays. Wireless USB has been introduced as an option for wireless communication between devices. However, unlike MDDI systems, Wireless USB operates within the framework of the wiMedia UWB MAC, which unfortunately ties the communication protocol very strongly to the underlying MAC structure, complicating the operation of the Wireless USB system. It makes wireless USB systems less than optimal for many applications.

As mentioned above, in a wired MDDI system, the host and client devices are connected by actual cable laying, which forms the basis for the association between the host and the client. However, in wireless systems, there is no automatic physical link that creates an association between the host and the client, which can lead to associations, security, inefficient use of air link bandwidth, as well as various. It can lead to a number of problems with address, packet, and / or communication protocol conflicts from hosts and / or clients.

Therefore, there is a need for systems and / or methods for wireless MDDI communication in the art that ensure proper associations between hosts and clients and efficient and secure communication between them.

The claimed inventions include systems and methods for avoiding conflicts in a wireless mobile display digital interface (WMDDI) environment that includes both host and client devices. In one aspect, the invention claimed in the present application broadcasts a first multicast address by a first host to at least one first client within a predetermined geographic area and a second host. Includes systems and / or methods configured to broadcast a first multicast address to at least one second client within a predetermined geographic area. The system and / or method further determines the priority between the first host and the second host when the second host receives the multicast packet sent by the first host. It can be configured to change to the second multicast address by the lowest priority host of the first and second hosts.

In another aspect, the claimed invention comprises a system and / or method for resolving and / or preventing conflicts in a multicast address digital communication system. Conflict resolution systems and / or methods use a first multicast address broadcast by a first device in a first predetermined geographic area to a second in a predetermined geographic area. The device can include receiving steps, where the first geographic area and the second geographic area are at least partially different from each other. Upon receipt, the second device can rebroadcast the first multicast address within the second predefined geographic area, and the first multicast address is the second predefined. Can be received by a separate third device within the geographic area. In other aspects of the invention claimed in the present application, the third device can then determine whether the first multicast address and the second multicast address are the same and are identical. If, the priority between the first device and the second device can be determined. If the first device is the preferred device, the third device can select and / or generate a separate third multicast address. Similarly, if the second device is the preferred device, the first device can select and / or generate a separate third multicast address, thereby allowing the first predetermined geography. Prevent possible conflicts between devices within the target area and devices within the second predetermined geographic area.

As described in more detail below, by the systems and / or methods described herein, the WMDDI protocol is a high speed radio without interference with the wireless MAC itself, which is a significant drawback to the wireless USB systems described above. It can operate at the top of the MAC. Separating WMDDI from the wireless MAC significantly improves the efficiency and operation of host-client communication while reducing the overall cost of the system described herein. Other features described herein include service discovery capabilities, dynamic association / disconnect capabilities, mutual authentication and key exchange capabilities, link status capabilities, and various specific features for preserving air link bandwidth. Including functions. Other features and advantages of the invention claimed in the present application will be described in detail below with reference to the drawings.

<figref num="1">FIG. 1 is a schematic block diagram of a system for avoiding and / or resolving conflicts in a WMDDI multicast environment, according to one aspect of the claimed invention.</figref><figref num="2">FIG. 2 is a schematic block diagram of the system hierarchy in a WMDDI multicast environment according to one aspect of the invention claimed in the present application.</figref><figref num="3">FIG. 3 is a diagram of a system for avoiding and / or resolving conflicts in a WMDDI multicast environment, according to one aspect of the claimed invention.</figref><figref num="4">FIG. 4 is a flowchart showing a method for avoiding a conflict in a WMDDI multicast environment according to one aspect of the invention claimed in the present application.</figref><figref num="5">FIG. 5 is a flowchart showing a method for avoiding and / or resolving a conflict in a WMDDI multicast environment according to one aspect of the claimed invention.</figref><figref num="6">FIG. 6 is a flowchart showing a method for avoiding and / or resolving a conflict in a WMDDI multicast environment according to one aspect of the claimed invention.</figref><figref num="7">FIG. 7 is a flowchart showing a method for avoiding and / or resolving a conflict in a WMDDI multicast environment according to one aspect of the claimed invention.</figref><figref num="8">FIG. 8 is a flowchart showing a method for avoiding a conflict in a WMDDI multicast environment according to one aspect of the invention claimed in the present application.</figref>

Detailed explanation

The inventions claimed in the present application are described herein with reference to the accompanying drawings with respect to their preferred features and embodiments. Those skilled in the art of telecommunications should understand that the above description is merely an example, and that the scope of the invention claimed in the present application is defined by the scope of the claims.

As shown in FIG. 1, a system 10 for avoiding and / or resolving conflicts in a WMDDI multicast environment according to one aspect of the claimed invention is a host device capable of wirelessly connecting to a client device 20. Including 12. The host device 12 may include a WMDDI transmitter module 14 and a wireless modem 16, each of which includes at least the features described in more detail below with reference to FIGS. 2-8. At a minimum, it can be connected to a host controller 18 adapted to control communication functions. The host controller 18 can include, for example, any suitable combination of hardware, firmware, or software adapted to control the communication functions of the host device 12. Similarly, the client device 12 can include a WMDDI receiver module 22 and a wireless modem 24, each connected to a client controller 26 adapted to control at least the communication capabilities of the client device 20. It is possible. The client controller 26 also includes hardware, firmware, adapted to control the communication functions of the client device 20, including, for example, at least the functions described in more detail below with reference to FIGS. 2-8. Or any suitable combination of software can be included.

Each host device 12 and client device 20 can have a functional system hierarchy 30, one aspect of which is shown in FIG. The system hierarchy 30 can include, for example, a display / video / multimedia layer 32 layered on top of the WMDDI protocol layer 34. The WMDDI protocol layer 34 is shown superimposed on the high speed wireless MAC layer 36, which can operate on the high speed wireless PHY layer 38. As described in more detail herein, the WMDDI protocol layer 34 is, but is not limited to, a service discovery function, a dynamic association / disconnection function, a mutual authentication and key exchange function, and a link status function. , As well as multiple features, including various specific features for preserving air link bandwidth.

As shown in FIG. 3, in one preferred embodiment of the invention claimed in the present application, the system 10 allows the first host H1 to be within a predetermined geographical area, i.e., the signal range of the first host H1. It is configured to be adapted to broadcast the first multicast address to at least one of the client devices C1. System 10 further causes the second host H2 to broadcast the first multicast address to at least one second client C2 within the same geographic area, and further, the first host H1 and the first. Host H2 of 2 decides the priority when the second host H2 receives the multicast address packet sent by the first host H1, thereby avoiding possible multicast address conflicts. It can be configured to be configured to do so. Depending on the priority between the first host H1 and the second host H2, system 10 will have the second multicast address with the lowest priority of the first host H1 or the second host H2. Can be configured to resolve existing and / or possible multicast address conflicts.

These and other aspects of the invention claimed in the present application help alleviate conflicts in a wider WMDDI system where there are multiple hosts and multiple clients, all within the same predetermined geographic area. .. For example, with two hosts A and C and two clients B and D, in a typical WMDDI system, hosts A and C may have insecure communications and / or conflicts, depending on the multicast address chosen. May have. Nodes A and B listening to each other If nodes B and C are within the listening range of each other and nodes C and D are within the listening range of each other, then nodes A and D share the same multicast address and they share the same multicast address. It can be linked if there is no way to determine the proper priority and multicast address selection between the two hosts A and C. As such, aspects of the invention patented herein are selected multicasts from the starting host to the client (first hop) and from the client to at least the second host (second hop). It involves a two-hop transmission of the address, so that the second host knows the choice of multicast address and, in the options of the second host, depends on the device priority (eg, associated with them). Multicast addresses can be rejected or accepted (based on their respective media access control addresses). As described in more detail herein, the second host either avoids conflicts through denial of multicast addresses and selection of unique addresses, or determines preferred addresses and uses their existing addresses. Adapted to resolve existing conflicts by retaining or by selecting a new address in response to the priority of each device.

As shown in Diagram 40 of Figure 3, the first host H1 attempts to initiate a session with one or more clients and selects and broadcasts the selected Multicast Address (MA2). At the same time, the second host H2 is initiating its own session with the second client C2 using the selected multicast address, MA1. If the first host H1 also attempts to select MA1 as its multicast address, the first host H1 may unintentionally initiate a session with the second client C2. To avoid this situation, the first host H1 broadcasts its MA2 message to at least the first client C1 within a predetermined geographic area. In response, the first client C1 hops MA2 to at least the second host H2. If at least the second client C2 and the second host H2 are in session on MA1 and MA2 are the same, and the address of the second host H2 is greater than the address of the first host H1. If large, the second host H2 responds to the first client C1 with a Multicast Address Reject (RMA) message, and the multicast address reject (RMA) message is sent by the first host H1. , The first host H1 chooses a different multicast address by knowing that there is an existing broadcast with the chosen address and that the second host H2 has priority at that particular address. It hops back to the first host H1 so that it can. Alternatively, if MA2 is different from MA1, there is no conflict between the first host H1 and the second host H2 for an immediate session. Furthermore, since each of the first host H1 and the second host H2 knows each other's multicast addresses, each host

With reference to FIG. 1 again, the host device 12 can be configured to act as the first host H1 and the second host H2, and the client device 20 is the first client C1 and the second. Can be configured to act as client C2 of. As mentioned above, each of the host device 12 and the client device 20 can include a host controller 18 and a client controller 26, respectively, and each of the controllers performs and performs the methods described herein. Configured for operation. Controllers 18 and 26 can be implemented in hardware, firmware, software, and / or a combination thereof. In a hardware implementation, for example, a processing unit can be an application specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), or a field programmable device. Implemented within gate arrays (FPGAs), processors, microcontrollers, microprocessors, electronic devices, other device units designed to perform the functions described herein, and / or combinations thereof. Can be done.

In the firmware and / or software implementation of aspects of the invention claimed in the present application, the system and / or method is implemented using modules (eg, procedures, functions, etc.) that perform the functions described herein. Can be done. Any machine-readable medium that clearly embodies the instructions can be used in implementing the methods described herein. For example, software code may be stored in memory, eg, in memory executed by controllers 18 and 26 associated with one of host device 12 or client device 20. it can. Memory can be implemented inside or outside the processor. As used herein, the term "memory" refers to any type of long-term, short-term, volatile, non-volatile, or other memory, any particular type of memory or number of memories, or. The memory is not limited to the type of medium in which it is stored.

As shown in FIG. 4, in one aspect of the invention claimed in the present application, a method for selecting a multicast address to avoid conflicts in a digital communication system is predetermined by a first host. Includes step S102, which describes broadcasting the first multicast address to at least one first client in the geographic area. In step S104, the method describes that the second host broadcasts the first multicast address to at least one second client within a predetermined geographic area, and in step S106, the method , Describe that when the second host receives a multicast packet sent by the first host, it determines the priority between the first host and the second host. The method of this preferred embodiment of the invention claimed in the present application further describes changing to a second multicast address by the lowest priority host of the first and second hosts S108. including.

In one variant of the method of the embodiment shown in FIG. 4, the method further steps to detect by the first host that at least one second client is within a predetermined geographic area. Can include. The step of detecting at least one second client can be performed according to the two-hop principle described with respect to FIG. The method is to receive the first broadcast multicast address from the first host by at least one second client and the second received first multicast address in the first hop count. It can further include a step of rebroadcasting to the host. As mentioned above with respect to FIG. 3, the systems and methods described herein are within a WMDDI network by minimizing the possibility of multicast address conflicts between two or more host devices. Serves the function of notifying, streamlining, and prioritizing communications.

Further details of the exemplary method described herein are shown in the flowchart of FIG. FIG. 5 primarily relates to a suitable method for the host device 12 functioning in system 10 as shown in FIG. In step S110, host H1 is powered up, and in step S112, host H1 selects the multicast address G1. After detecting a new client in step S114, in step S116, host H1 sends its chosen multicast address (PMA) message in the manner described above. After sending the PMA, the host serves in step S118 to set an upper limit on the amount of time that host H1 will wait to know if multicast group address G1 is already in use by the preferred host. , Start the multicast conflict resolution timer. In step S120, the method describes either waiting for a multicast address deny packet or expiring the multicast conflict resolution timer. In step S122, the method shown in FIG. 5 queries whether a multicast address deny (G1) has been received. If the answer is negative, the method proceeds to step S128 and asks if the multicast conflict resolution timer has expired. If the multicast conflict resolution timer has expired, in step S130, the method describes holding the multicast group address G1 as the MAC address for the host's session. If the multicast conflict resolution timer has not expired, the method returns to step S120 above.

Returning to step S122, if a multicast address deny (G1) was received, the method is that host H1 is the source host address (eg MAC address) H2 is the address of host H1, i.e. its own address. Proceed to step S124, which states that it confirms that it has priority. Upon confirmation, the method proceeds to step S126, where step S126 states that the method selects a multicast address G2 different from G1, after which the method returns to step S116 and is newly elected. Send a multicast address (G2) packet. The exemplary method shown in Figure 5 serves to ensure that the hosts have different priorities as well as multicast addresses. Thus, in system 10 as described above, each host is ensured to be assigned the proper priorities, and each multicast address is ensured to be unique within a predetermined geographic area. The above steps are being performed to achieve this.

FIG. 6 shows a method suitable for a recipient such as host device 12 or client device 20 as shown in system 10 described with respect to FIG. In step S140, the method example describes receiving the selected multicast address (G1), and in step S142, the method example is of a different group in which the devices already have the same group address G1. Inquire whether you are a member or not. If the answer is negative, the method proceeds to step S160, which is described in more detail below. If the answer is affirmative, the method proceeds to step S144 to determine if the address of the host initiating the multicast group (eg, MAC address) has priority over the existing host on the device. Inquire.

As mentioned above, the method of the invention claimed in the present application ensures both the priority and uniqueness of the multicast address. Thus, if the answer to the priority inquiry S144 is affirmative, the method example queries whether the device is also the second host H2. If the answer is affirmative, in step S150 host H2 elects another multicast address G2 different from G1 for its group, and then in step S152 elected as described above. Initiate a procedure that sends a multicast address (G2). If the answer to query S146 is negative, the device forwards the selected multicast address to host H2. If the answer to the priority inquiry S144 is negative, then H1 has no priority over H2, so in step S154, the method example is whether the client device is also the second host H2. Inquire whether or not. If the response is negative, the example method proceeds to step S158, which describes forwarding the selected multicast address packet to host H2. If the response to inquiry S154 is affirmative, in step S156, host H2 broadcasts a multicast-denied packet targeting host H1 by including the unicast address of H2's own host.

As mentioned above, in order to prevent unintentional associations between clients and hosts that are not necessarily within the same geographic area, the methods of the invention claimed in this application involve at least a two-hop communication process. Use. Therefore, in step S160, the method example describes incrementing the number of hops in a selected multicast address packet to ensure that a predetermined number of hops are achieved. For example, in step S162, the method example queries whether the number of hops is less than two. If the response is affirmative, the method proceeds to step S164, incrementing the number of hops in the selected multicast address packet and broadcasting to the next hop next to the client device. On the other hand, if the number of hops is 2 or more, the method example proceeds to step S166, and the selected multicast address packet is discarded because both the priority and uniqueness functions are implemented.

FIG. 7 shows another example of a method that can be used by a packet receiver such as a host or client device in the type of system described herein. In step S180, a method example describes the step of receiving a selected multicast address (G1) packet. In step S182, the method queries whether the receiver is a member of a different group that already has the same group address G1. If the query in step S182 is answered negative, the example method proceeds to step S196, which describes the step of forwarding the selected multicast address packet to host H2. If the answer to the inquiry in step S182 is affirmative, the method proceeds to step S184 to further inquire whether the receiving device is the second host H2. If the answer to the query in step S184 is negative, the method proceeds to step S194 and the selected multicast address is forwarded to host H2.

Alternatively, if the answer to the query in step S184 is affirmative, the method proceeds to step S186 and the address of the host initiating the multicast group (eg MAC address) is host H2, which is the host for the current group. Inquire whether or not you have priority for the address of. If the response to the query in step S186 is negative, in step S192 host H2 broadcasts a multicast address denial packet destined for host H1 by including the address of host H2 with a number of hops equal to zero. If the response to the query in step S186 is affirmative, in step S188 host H2 chooses an alternative multicast address G2 that is different from G1 for its own multicast group. After selecting the new multicast address G2, the method initiates a procedure in step S190 for host H2 to send the selected multicast address (G2).

To prevent unintentional associations between clients and hosts that are not necessarily within the same geographic area, as in the method examples described above, the method of the invention claimed in the present application is at least two-hop communication. Use a process. Therefore, in step S198, the method example describes incrementing the number of hops in a selected multicast address packet to ensure that a predetermined number of hops are achieved. For example, in step S200, the method example queries whether the number of hops is less than two. If the response is affirmative, the method proceeds to step S202, incrementing the number of hops in the selected multicast address packet and broadcasting to the next hop next to the device. On the other hand, if the number of hops is 2 or more, the method example proceeds to step S204, and the selected multicast address packet is discarded because both the priority and uniqueness functions are implemented.

Another example of a method available by a packet receiver, such as a host or client device, in the types of systems described herein is shown in FIG. Specifically, the example method shown in FIG. 8 is available by a device that is a member of multicast group G1 initiated by host H2, in which case the device is a multicast packet from a different host H1. Either received a beacon, signal, or packet indicating that host H1 started a different group at the same address G1. This can happen if two different groups are in wireless contact with each other, either because of mobility or changes in the wireless environment. The example method shown in FIG. 8 begins at step S210 where the device detects a dual multicast group (G1). In step S212, the example method queries whether the receiving device is host H2. If the response is negative, in step S222, the example method generates a selected multicast address (G1) with one hop number instead of H1 and sends it to host H2. It is stated that the host H2 is notified of a possible conflict with the group G1 address.

If the response to the query in step S212 is affirmative, the receiving device is also host H2. In that case, the method example further inquires in step S214 whether the host H1 has priority over the host H2. If the response to the query in step S214 is affirmative, the example method proceeds to step S216, where host H2 chooses an alternative multicast address G2 different from G1 for its own multicast group. At step S218, host H2 initiates a procedure for sending the chosen multicast address (G2) to its own multicast group. If the response to the query in step S214 is negative, host H2 sends or broadcasts a multicast address deny packet to H1 by including the address of host H2, thereby host H1 for its own group. Ensure that you choose a different multicast address.

Although various aspects and features of the invention claimed in the present application have been described with respect to multicast addresses, it is appreciated that the principles of the invention claimed in the present application are equally suitable for other types of radio addresses. Those skilled in the art will easily understand. For example, the systems and methods described herein can be applied to special nodes such as hosts that collectively define multicast groups and any node network with a unique identifier. As a non-limiting example, aspects and features of the invention patented herein include, for example, wireless personal area networks (WPAN), wireless local area networks (WLAN), including WiFi and fixed wireless data networks. IEEE 802.11 series networks and Internet protocols, including wireless metropolitan area networks (WiMAX), as well as both Global Systems for Mobile Communications (GSM®) and personal communication services (PCS) networks. It can be used in all types of wireless networks, including those supported by IP) addressing. Those skilled in the art will appreciate that the various aspects and features of the invention described herein can be readily applied to at least the types of communication protocols and networks described above.

Unless explicitly stated otherwise, as is clear from the above description, "compute", "computing", "calculating", "selecting", "forming". , "Enable", "Suppress", "Locate", "Exit", "Identify", "Start", "Detect", "Get", "Host", Descriptions using terms such as "maintain", "represent", "estimate", "reduce", "associate", "receive", "send", "determine", etc. are described herein. Throughout, within computing platform processors, memory, registers, and / or other information storage, transmission, reception, and / or display devices, physical electronic and / or magnetic quantities and / or other physical Refers to the actions and / or processes that can be performed by a computing platform, such as a computer or similar electronic computing device, that manipulates and / or transforms data expressed as a quantity. Such actions and / or processing can be performed by the computing platform, for example, under the control of machine-readable instructions stored in the storage medium. Such machine-readable instructions are stored, for example, in a storage medium included as part of a computing platform (eg, included as part of a processing circuit or outside such processing circuit). Can be equipped with software or firmware. Further, unless explicitly stated otherwise, the processes described herein with reference to a flow chart or otherwise also include, for example, the host device 12 and client device 20 detailed above. Some or all of them can be run and / or controlled by computing platforms, including.

The above description relates to selected embodiments and preferred examples of the systems and methods of the invention claimed in the present application. It should be understood by those skilled in the art that these descriptions are exemplary in nature and that the intent and scope of the claims claimed in the present application are defined with respect to the following claims. is there.