US20090158371A1

US20090158371A1 - System and Method for Communicating Among Multicast Transceivers

Info

Publication number: US20090158371A1
Application number: US12/254,124
Authority: US
Inventors: Lawrence Lo
Original assignee: Avocent Corp
Current assignee: Vertiv IT Systems Inc
Priority date: 2007-10-19
Filing date: 2008-10-20
Publication date: 2009-06-18
Also published as: US8533764B2; US20090241148A1

Abstract

A group identifier can be used to assign blocks of addresses to the various groups of transmitters and receivers communicating on a single wired LAN. For example, a form-based control (e.g., a text entry box, a radio button, a drop-down box, a list box or a combo box) can be provided in a form controlled by a web server internal to the transmitter. The form enables a configuring user to specify to which of multiple (e.g., 4) groups a transmitter and its receivers (e.g., specified by MAC address) are going to belong. The transmitter thereafter can select its own IP address (based on the group number) and the known range of IP addresses available for its receivers. Once the IP addresses have been assigned to the transmitter and receivers, the transmitter can send (1) control data to the receivers at their receiver-specific IP addresses and (2) AV data to their multicast address.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is related to and claims priority to U.S. Provisional Patent Application 60/960,913, filed Oct. 19, 2007, the contents of which are incorporated herein by reference. The present application is further related to U.S. Non-Provisional and Provisional patent application Ser. Nos. 11/896,970 and 60/842,706, filed Sep. 7, 2007 and Sep. 7, 2006, respectively. The contents of those applications are also incorporated herein by reference.

FIELD OF INVENTION

The present invention is directed to a system and method for communicating between plural transmitters and their corresponding groups of receivers. In one such configuration, each transmitter is assigned a range of IP addresses to be assigned to its group of receivers such that the IP addresses of the receivers do not overlap or conflict.

DISCUSSION OF THE BACKGROUND

Keyboard, video and mouse (KVM) switches are known and used in a number of scenarios where a single keyboard and mouse is to control a number of remote computers. Thus, many transmitters (i.e., the remote computers) are connected to a single workstation including a keyboard, a monitor and a mouse. However, a consumer may also wish to operate in a reverse configuration where a single original video and/or audio source is used to control multiple video displays/monitors. Systems where a single video source can control multiple displays include the EMERGE MPX1500 HD MULTIPOINT EXTENDER manufactured and sold by AVOCENT CORPORATION, the assignee of the present application.
When using such a multi-display system, a transmitter (at an originating end) receives audio and/or video from an audio/video source (e.g., a cable/satellite set-top box, a computer, a DVD player (either original definition or high definition), a game console, a CD player or any other electronics device) and converts the audio and/or video signal (hereinafter AV signal) to a digitized, packetized form. The transmitter then forwards (e.g., using at least one packet-switched network) the converted AV signal on to plural receivers which convert the digital AV signal back to its native form.
When establishing “pairings” of transmitters to receivers, a conflict can arise if plural transmitters coexist on the same network and those transmitters all utilize the same preassigned addresses for their corresponding receivers.

BRIEF DESCRIPTION OF THE DRAWINGS

The following description, given with respect to the attached drawings, may be better understood with reference to the non-limiting examples of the drawings, wherein:

FIG. 1 is block diagram of a series of receivers communicating with a corresponding transmitter in order to display substantially the same image on each of the displays/televisions connected to the various receivers;

FIG. 2 is an illustration of an exemplary transmitter (e.g., for use in the system of FIG. 1);

FIG. 3 is an illustration of a menu for setting a set of MAC addresses of receivers that are to be associated with the transmitter;

FIG. 4 is an illustration of an exemplary receiver (e.g., for use in the system of FIG. 1);

FIG. 5 is a block diagram of a portion of the internals of an exemplary transmitter as shown in FIG. 2; and

FIG. 6 is a block diagram of a portion of the internals of an exemplary receiver as shown in FIG. 3.

DISCUSSION OF THE PREFERRED EMBODIMENTS

Turning to FIG. 1, a multi-display system 100 includes a transmitter 110 (at an originating end) that receives audio and/or video (e.g., high-definition video) from an audio/video source 120 (e.g., a cable/satellite set-top box, a computer, a DVD player (either original definition or high definition), a game console, a CD player or any other electronics device) and converts the audio and/or video signal (hereinafter AV signal) to a digitized, packetized form. (For those AV signals that are input in to the transmitter 110 in digital form already, the transmitter need not digitize the AV signal but instead simply captures and stores it in digital form.) The transmitter 110 then forwards (e.g., using at least one packet-switched network including at least one router 150) the converted AV signal on to plural receivers 130 a-130 c which convert the digital AV signals back to their native form and output them to display devices connected to AV connectors (260 of FIG. 4) via AV cables. As would be appreciated by those of ordinary skill in the art, the number of receivers 130 may be other than as illustrated, and in one embodiment includes up to 8 or up to 16 different receivers per transmitter.
As shown in FIG. 2, a transmitter 110 may include at least one digital AV communications interface 210 (e.g., an Ethernet interface) over which the digitized AV signal (received over the AV interface 220, such as a universal interface supporting HDMI, VGA and/or RGB) is sent from the transmitter to the receivers. The at least one digital AV communications interface 210 may also exchange other information with the receivers 130 as described in greater detail below. The illustrated transmitter 110 further includes at least one configuration port (e.g., illustrated as a serial port 240 and an Ethernet port 230) which can be used to configure the transmitter with configuration information (e.g., port addresses and which receivers are to be “paired” with the transmitter). For example, a configuring computer may be coupled to the Ethernet port 230 (using a regular or cross-over Ethernet cable), thereby providing a direct connection between the transmitter and the configuring computer. A configuration tool (e.g., a web browser) on the configuring computer can then be used to receive configuration information and/or menus and/or forms from the transmitter 110 and to transmit updates to the configuration information to the transmitter 110. Any number of data transfer protocols (e.g., HTTP, FTP, gopher or WebDAV) can be used to carry information over any number of communications protocols (e.g., TCP/IP, RDP/IP, UDP/IP, multicast, NetBIOS).
In one embodiment, the transmitter 110 is configured via a web browser to include the MAC addresses of the receivers 130 that are to be paired with the transmitter 110. For example, a user configuring the transmitter may read the MAC addresses off of a set of receivers and enter them into a form (as shown in FIG. 3) that is generated by a web server internal to the transmitter 110 (as shown in FIG. 5) so that the transmitter knows what receivers to respond to and/or communicate with. Later, when a receiver 130 starts and broadcasts a message on the network, only the transmitter 110 that has been configured with the receiver's MAC address will respond to the broadcast. In response to the broadcast message, the transmitter 110 can provide the receiver 130 with an IP address, similar to the procedure used in DHCP (RFC 2131, incorporated herein by reference) or DHCP for IPv6 (RFC 3315, incorporated herein by reference). The transmitter 110 can assign the IP addresses for the receivers in its group either statically (such that the receiver with MAC address MAC₁always gets the first IP address in the transmitter's group of receiver addresses and the receiver with MAC address MAC₂always gets the second IP address in the group, no matter when they start compared to each other or the other receivers in the group) or dynamically (such that the receiver that starts first gets the first IP address in the transmitter's group of receiver addresses and the receiver that starts second gets the second IP address in the group, regardless of the order in which those MAC addresses are stored internal to the transmitter's configuration memory).
In order to ease the setup process for unskilled users, it is possible to preallocate or preassign the IP addresses that the transmitter and receivers are to use. For example, the transmitter 110 may be preassigned the IP address 192.168.1.1, and the up to “n” receivers in a group may be preassigned the addresses: 192.168.1.2 to 192.168.1.(n+1). However, while this reduces configuration time when a single transmitter and its receivers are used on a wired LAN, it causes conflicts if multiple transmitters and their receivers are to share the same wired LAN.
In order to address the problem of preassigned IP address conflicts, it is possible to allow each transmitter and each receiver to be separately programmed on an IP address-by-IP address basis. For example, using the method described above, a configuring computer uses a direct connection, such as with an Ethernet cable between the configuring computer and the transmitter or receiver, and a web browser to update the IP address stored in the configuration information stored internally within the transmitter or receiver (via the web server internal to the transmitter or receiver). However, if users are allowed to assign arbitrary addresses to each transmitter and each receiver, it may be cumbersome to remember which addresses have been assigned to which set of devices.
Instead, using the techniques described herein, a group identifier can be used to assign blocks of addresses to the various groups of transmitters and receivers. For example, using the programming technique described above for programming a transmitter, a form-based control (e.g., a text entry box, a radio button, a drop-down box, a list box or a combo box) can be provided in a web-based or other form controlled by the web server internal to the transmitter. (A portion of an exemplary form is shown in FIG. 3.) The form enables a configuring user to specify which of multiple (e.g., 4) groups a transmitter and its receivers (e.g., specified by MAC address) are going to belong. The transmitter 110 thereafter can select its own IP address (based on the group number) and known the range of IP addresses available for its receivers. In an exemplary embodiment IP addresses are assigned as follows:
IP address of the transmitter in group g=192.168.1. ((g−1)*32)
IP address of receiver 1 in group g=192.168.1. ((g−1)*32)+1
. . .
IP address of receiver r in group g=192.168.1. ((g−1)*32)+r, where r<30
Multicast IP address for all receivers in group g=192.168.1. ((g−1)*32)+31.
The multicast address can be used for all data that is common to all receivers (e.g., the audio and/or video that is to be displayed by all receivers). Additional details about realtime communications can be found in RFC1889 and RFC3550, and details about extending RTP to support multicast communications can be found in Internet Engineering Task Force, INTERNET-DRAFT, “draft-parnes-rtp-ext-srm-00.txt,” dated Nov. 16, 1996, by Peter Parnes, and entitled “RTP extension for Scalable Reliable Multicast.” The contents of those documents are incorporated herein by reference. It should be understood that the multicast address may be based on a different subnet than the direct IP addresses.
In another exemplary embodiment, IP addresses are assigned as one of a set of internal IP addresses (e.g., 192.168.1.x where x is defined as follows):

TABLE 1

group 1	group 2	group 3	group 4

transmitter	1	2	3	4
receiver #1	5	6	7	8
receiver #2	9	10	11	12
. . .
receiver #r	(r)*4 + 1	(r)*4 + 2	(r)*4 + 3	(r)*4 + 4
multicast receiver	(r + 1)*4 + 1	(r + 1)*4 + 2	(r + 1)*4 + 3	(r + 1)*4 + 4
address

While the above discusses addresses of the various groups remaining on the same subnet, group numbers may cause all or part of the addresses associated with a first group to be on a different subnet than all or part of the addresses associated with a second group. For example, IP addresses are assigned as 192.168.sn.x where sn.x is defined as follows:

TABLE 2

group 1	group 2	group 3	group 4

transmitter	1.1	2.1	3.1	4.1
receiver #1	1.2	2.2	3.2	4.2
receiver #2	1.3	2.3	3.3	4.3
. . .
receiver #r	1.r + 1	2.r + 1	3.r + 1	4.r + 1
multicast receiver	1.r + 2	2.r + 2	3.r + 2	4.r + 2
address

Therefore, by specifying a different group number for each transmitter and its receivers, IP address conflicts can be avoided without having to separately program IP addresses or ranges for each group.
In yet another embodiment, rather than configuring each transmitter with a list of all receivers that a transmitter is to be paired with (as one might do if one knew all the receivers in advance), a transmitter 110 may instead be configured (using its internal web server) with just its group number but no receiver MAC addresses. Later, each receiver is configured (e.g., by a configuring computer connected to the receiver 130 by a cable connected to Ethernet port 210, as shown in FIG. 4) with the MAC address of the transmitter to which it is to be paired using a server (e.g., web server) internal to the receiver 130 (as shown in FIG. 6).
After the receiver is disconnected from the configuring computer and connected to the network to be used (e.g., as in the network of FIG. 1), the receiver then can use the stored MAC address of the transmitter to request an IP address from the transmitter. The transmitter can then dynamically add the receiver to its list of corresponding (or paired) receivers (assuming that there are not already the maximum number of receivers paired to that transmitter) and send to that receiver the receiver's IP address from within the transmitter's block or group of IP addresses. The transmitter 130 may also send to the receiver other needed information as well (e.g., the multicast address for the AV data, the IP address of the transmitter, the resolution of the video data and/or the resolution at which the video should be output, the type of display that the receiver is connected to and/or the group number of the group). The receiver 130 would then begin receiving video data via the same communications port (e.g., Ethernet port 210) that it received the configuration information (as shown in FIG. 6) or possibly a different port if the receiver 130 is configured with multiple ports and/or a wireless interface.
Accordingly, because receivers can be pre-specified at the transmitter (e.g., using MAC addresses) or added dynamically by configuring the receiver with the transmitter's address (e.g., MAC address), the examples above of dynamic address allocation should be understood to include both techniques. Therefore, “receiver 1” above can refer to either (1) a receiver which is considered the first of a group (e.g., by virtue of its position in the list of corresponding MAC addresses of receivers) or (2) the first receiver associated with the transmitter that requests an address from that transmitter.
Furthermore, the method by which the transmitter assigns addresses to itself, receivers and multicast addresses need not be an algorithm as described above (e.g., IP address of receiver r in group g=192.168.1. ((g−1)*32)+r, where r<30). Instead, the addresses can be assigned by a lookup table that is loaded into each transmitter. For example, a 64 by 64 table of 16 bit values could be indexed as a two dimensional array/table of addresses similar to the format of Table 2 such that 8 bits represent the subnet “sn” and 8 bits represent the machine number x such that the result is an IP address of the form 192.168.sn.x. Special values, such as zero, could be stored in entries that are not possible or unwanted. Also, the first entry of each row (or column) of the table would be used as the transmitter's address and the last entry would be the multicast address. New or updated tables can be programmed into the transmitter by uploading a file from a configuring computer to the server internal to the transmitter (which may then need to update its non-volatile memory (e.g., flash memory) and/or reboot).
Once the IP addresses have been assigned to the transmitter and receivers, the transmitter can send (1) control data to the receivers at their receiver-specific IP addresses and (2) AV data to their multicast address. Moreover, due to the dynamic nature of the configuration techniques described herein, transmitters and receivers can be reconfigured without directly connecting them back to a configuring computer using a dedicated connection (e.g., a cross-over cable). Instead, all the transmitters in the network may be connected to the same control network (e.g., using a separate router to reduce traffic) and addressed using the corresponding IP address of the transmitter based on its group number. Similarly, a receiver receiving video from the transmitter in group 1 may later be changed (under the control of that transmitter which knows the receiver's IP address or any other device that knows the IP address and optionally authentication information of the receiver) to instead be paired with a transmitter from a different group (e.g., group 2). Once the receiver is reset, it would begin the process again of obtaining a new IP address (this time from the transmitter of group 2) and then begin displaying the video being transmitted from the transmitter of group 2.
As discussed above, to address the need for security, the internal web servers of the transmitter and or receivers may require that a configuring computer authenticate itself to the internal web server before being allowed to make changes in the memory of the internal web server. For example, a user of the configuring computer may have to provide a username and password matching a username and password stored in/with the internal web server.
As would be appreciated by those of ordinary skill in the art, a transmitter and its receivers may be factory set to include a specific group number (e.g., group 1). In such a configuration, if there is only that one transmitter and its receivers on the network, then there is no need to reprogram the group number of the transmitter and receivers as there will be no address conflicts.
While certain configurations of structures have been illustrated for the purposes of presenting the basic structures of the present invention, one of ordinary skill in the art will appreciate that other variations are possible which would still fall within the scope of the appended claims. The systems and techniques described herein can be incorporated into the EMERGE MPX1500 HD MULTIPOINT EXTENDER manufactured and sold by AVOCENT CORPORATION, the assignee of the present application. Additional information about the EMERGE MPX1500 HD MULTIPOINT EXTENDER can be found in Emerge® MPX1500 HD Multipoint Extender Installer/User Guide (590-906-501A), the contents of which are incorporated herein by reference.

Claims

1. A video transmitter for communicating with plural video receivers for connecting to corresponding video display devices, the transmitter comprising:

a memory for storing a group number of the transmitter;

an internal server for receiving requests from the plural receivers for dynamically assigned IP addresses and for dynamically assigning IP addresses based on the group number of the transmitter; and

a first communications interface for receiving the requests from the plural receivers for dynamically assigned IP addresses and for sending the dynamically assigning IP addresses to the plural receivers.

2. The video transmitter as claimed in claim 1, wherein the internal server comprises a web server.

3. The video transmitter as claimed in claim 1, wherein the first communications interface comprises an Ethernet interface.

4. The video transmitter as claimed in claim 1, wherein the memory further stores a multicast address for simultaneously communicating video data with the plural receivers; and

wherein the communications interface sends the multicast address to the plural receivers.

5. The video transmitter as claimed in claim 1, wherein the internal server receives a request to change the group number of the transmitter and updates the memory in response to the received request.

6. The video transmitter as claimed in claim 5, wherein the internal server receives the request to change the group number of the transmitter via a second communications interface, different than the first communications interface.

7. The transmitter as claimed in claim 1, wherein the memory further stores a MAC address of each receiver to which the transmitter is to provide a dynamically assigned IP address; and

wherein the internal server ignores requests from receivers that do not have a corresponding MAC address in the memory.

8. The video transmitter as claimed in claim 1, wherein the internal server receives a request to update a MAC address of a receiver to be associated with the transmitter and updates the memory in response to the received request.

9. A video system comprising:

plural video receivers for connecting to corresponding video display devices; and

a transmitter for communicating with plural video receivers, the transmitter comprising:

a memory for storing a group number of the transmitter;

a first internal server for receiving requests from the plural receivers for dynamically assigned IP addresses and for dynamically assigning IP addresses based on the group number of the transmitter; and

10. The video system as claimed in claim 9, wherein the first internal server comprises a web server.

11. The video system as claimed in claim 9, wherein the first communications interface comprises an Ethernet interface.

12. The video system as claimed in claim 9, wherein the memory further stores a multicast address for simultaneously communicating video data with the plural receivers; and

13. The video system as claimed in claim 9, wherein the first internal server receives a request to change the group number of the transmitter and updates the memory in response to the received request.

14. The video transmitter as claimed in claim 13, wherein the internal server receives the request to change the group number of the transmitter via a second communications interface, different than the first communications interface.

15. The video system as claimed in claim 9, wherein each of the plural receivers further comprise a second internal server for receiving requests to update a MAC address of the transmitter from which to obtain a dynamically assigned IP address.