JP4393933B2 - Group management apparatus and multicast group management method - Google Patents

Description

  The present invention relates to a group management apparatus for managing a multicast group and a multicast group management method.

Conventional data distribution using the Internet or the like is classified into unicast distribution, broadcast distribution, and multicast distribution based on the relationship between the data transmission terminal on the transmission side and the data reception terminal on the reception side.
Unicast distribution is a one-to-one communication in which one data transmitting terminal distributes data to one data receiving terminal. For this reason, the amount of data to be distributed by the data transmitting terminal increases in proportion to the number of data receiving terminals, and when the number of data receiving terminals increases, the load for data distribution processing at the data transmitting terminal and the communication path increases. It gets bigger.
In contrast, broadcast distribution and multicast distribution are one-to-many communication in which one data transmitting terminal distributes data to a large number of data receiving terminals, and thus the above problem does not occur.

  Here, unlike broadcast distribution, multicast distribution is a method of distributing data to a large number of specific partners with a single operation. As an example of multicast distribution, IP multicast that realizes multicast distribution using IP (Internet protocol) is widely known. In IP multicast, a multicast group is configured by assigning a multicast IP address to a group of data receiving terminals that receive the same data. An IP address (hereinafter referred to as “multicast address”) assigned to this multicast group is unique to the group. When a data receiving terminal desires to receive multicast distribution data distributed to a certain multicast group, the data receiving terminal belongs to the multicast group and becomes a group member. Specifically, the data receiving terminal stores information indicating that the data receiving terminal belonging to the multicast group exists under the control by transmitting a request for joining the multicast group to the adjacent group management apparatus. Let Thereby, the data receiving terminal can receive the data distributed from the data transmitting terminal to the multicast group via the group management device or the like.

  Here, IGMP (Internet Group Management Protocol) is used as a multicast group management protocol between the data receiving terminal that receives the multicast distribution data and the group management apparatus. The IGMP router, which is a group management apparatus corresponding to IGMP, has a function for determining whether or not there is a data receiving terminal belonging to the multicast group among the data receiving terminals under its control. .

  Non-patent documents 1 to 3 exist as documents related to IGMP and multicast. IGMP employs an anonymous model that does not specify a data receiving terminal in an IGMP router. In the anonymous model, since each data receiving terminal is not managed one by one, it is possible to reduce the management cost, and as a result, it is possible to ensure scalability when the number of data receiving terminals increases.

  In such an anonymous model of IP multicast, since a data receiving terminal is not specified, there is a problem that it is impossible to charge a user and measure the number of data receivers. Therefore, a technique for authenticating a user who uses a data receiving terminal using IGAP (IGMP for user Authentication Protocol) has been proposed (see, for example, Non-Patent Document 4). The IGAP extends a multicast group join request message (IGMP Membership Report) issued by the data receiving terminal, and authenticates the user who uses the data receiving terminal. Thereby, it is possible to identify the user who uses a data receiving terminal, and has solved the subject with respect to the anonymous model provided by IGMP.

  Since the IGMP router holds only the status of whether or not there is a data receiving terminal (hereinafter also referred to as “group member”) belonging to at least one multicast group, a multicast group withdrawal request from the group member When (IGMP Leave Group) is received, it is necessary to check whether there are other group members. For this purpose, the IGMP router multicasts an IGMP Group-Specific Query to the multicast group, and the data receiving terminal that receives it multicasts another group member by returning the response (IGMP Membership Report). To the IGMP router.

  The above operation is not a problem in a conventional wired LAN (Local Area Network) such as Ethernet (registered trademark), but is a problem in a wireless LAN in which a data receiving terminal moves frequently. Since data receiving terminals in a wireless LAN tend to move frequently, it is necessary to repeat joining and leaving a multicast group with respect to an IGMP router in a subnetwork of the movement source and the movement destination every time the movement occurs. Because. In IGMP, the above-described communication is required every time the user leaves the multicast group, so IGMP is not appropriate in a network such as a wireless LAN.

  Since IGAP performs user authentication for all group members, it is possible to strictly manage group members in an IGAP router which is a group management apparatus. By using these features, IGAP simply responds to the multicast group leave request message (IGMP Leave Group) from the data receiving terminal without checking whether there are any other group members. Provides Fast Leave function to delete management information of data receiving terminal. According to this, there is an advantage that communication for confirming the status of the multicast group member (IGMP Group Specific Query after the IGMP Leave Group) is not required unlike IGMP.

However, in IGAP, in order to perform user authentication for a multicast group join request message (IGMP Membership Report) from a data receiving terminal, when it is not necessary to charge the user or measure the number of data receivers, this communication and processing Sometimes became redundant.
As described above, in IGMP, whenever a group member leaves, communication for confirming the status of other group members is performed. In IGAP, communication for user authentication is performed every time a join request message is received. Therefore, there is a problem that the amount of communication increases regardless of which protocol is used.

  On the other hand, techniques related to multicast group management in mobile communication networks have also been proposed (see, for example, Patent Document 1). In Patent Document 1, each time a mobile communication terminal under a router moves under another router or joins or leaves a multicast group, the router receives information to that effect and updates the group management information. Then, group management is performed for each mobile communication terminal. Such a method of performing group management for each mobile communication terminal cannot solve the above-described problem that the amount of communication increases.

There is also a document in which a technique for reducing the number of response messages after a data receiving terminal receives multicast distribution data is being examined (see, for example, Patent Document 2). However, since the technique described in Patent Document 2 is a technique for reducing the number of responses from data receiving terminals to multicast distribution data, it should be used to reduce the amount of communication for group management, which is a problem here. Is difficult.
JP 2001-177564 A JP 2000-115051 By Thomas Maufer, translated by Hiroyuki Enomoto, “Introduction to IP Multicast”, first edition, Kyoritsu Publishing Co., Ltd., November 2001 Dave Kosiur, translated by Yukio Hamada, “Mastering TCP / IP Multicast”, 1st edition, 2nd edition, November 2000 By Beau Williamson, translated by Comsus, directed by Cisco Systems, "IP Multicast Network Development Guide Vol.1", first edition, July 2001 Nobumasa Hayashi, et al., “IGAP: IGMP for User Authentication Protocol”, Internet-draft, 2003

As described above, in a communication environment in which a data receiving terminal frequently joins and leaves a multicast group, how to reduce the amount of communication necessary for group management becomes a problem.
The present invention has been made in view of the above points, and an object of the present invention is to provide a group management apparatus and a multicast group management method for performing multicast group management while suppressing the traffic.

In order to solve the above problem, the invention described in claim 1 is directed to a group management apparatus that relays multicast distribution data to a data receiving terminal existing under its own apparatus, and the data belonging to a certain multicast group. Among the receiving terminals, the token assigning means for assigning a token to at least one data receiving terminal, and the data receiving terminal to which the token is assigned exist under its own device, and belong to the certain multicast group A token member management unit that manages whether or not the token allocation target state is in a state, and the token member management unit determines that the data receiving terminal to which the token is allocated is not in the token allocation target state Next, the token for deallocating the token to the data receiving terminal Comprising a Kung deallocation means, while the token to at least one data receiving terminal is assigned a multicast distribution data relay means for relaying multicast distribution data to the data receiving terminal belonging to the certain multicast group The token allocating means selects a data receiving terminal to which the token is to be allocated from among data receiving terminals confirmed to belong to the certain multicast group by transmitting an inquiry message to the certain multicast group. determining to provide a group management apparatus according to claim Rukoto.

According to the present invention, the token assigning means of the group management device provides a token to at least one data receiving terminal among the data receiving terminals that belong to the own device and belong to a certain multicast group. The token member managing means manages whether the data receiving terminal to which the token is assigned is in the token assignment target state, and the token deallocating means is for the data receiving terminal to which the token is assigned. When it is determined that the token allocation target state is not found, the allocation of the token to the data receiving terminal is canceled, and the multicast distribution data relay unit is configured to transmit the token while the token is allocated to at least one data receiving terminal. Multi to data receiving terminals belonging to a multicast group In order to relay the data to be distributed, the group management device can perform group management only with the traffic for managing the state of the data receiving terminal to which the token is allocated, and the traffic for the group management. Can be suppressed.
Further, according to the present invention, the token assigning means of the group management device determines the data receiving terminal to which the token should be assigned from the data receiving terminals confirmed to belong to the multicast group. Therefore, an attempt to allocate the token to a data receiving terminal that is no longer under the control of the group or that has left the multicast group will not fail, so that unnecessary traffic can be reduced.

According to a second aspect of the present invention, in the group management device according to the first aspect, the token allocating unit allocates the token deallocated by the token deallocating unit to another data receiving terminal. And
According to the present invention, the token allocating unit of the group management apparatus allocates the token deallocated by the token deallocating unit to another data receiving terminal. The status of the other data receiving terminal to which the token is assigned can be managed, and it is possible to strictly manage whether there is a data receiving terminal belonging to the certain multicast group under the control. Become.

  According to a third aspect of the present invention, in the group management device according to the first or second aspect, the token allocating unit is configured such that the data receiving terminal is continuously present under its own device, and The time continuously belonging to a certain multicast group, the past time when the data receiving terminal is under the control of the own device and belonging to the certain multicast group, the model of the data receiving terminal, The data receiving terminal to which the token is to be allocated is determined according to at least one of the following.

  According to the present invention, the token allocating means of the group management device receives data to be allocated the token according to at least one of a time continuously belonging to the certain multicast group, the accumulated time, and the model. In order to determine a terminal, the token can be allocated to a data receiving terminal that continuously belongs to the certain multicast group, a data receiving terminal that has a long accumulated time, or a data receiving terminal of a model that does not move frequently. . For this reason, the group management apparatus can reduce the communication amount for group management associated with joining and leaving, and the communication amount for reallocating the token to another data receiving terminal.

  According to a fourth aspect of the present invention, in the group management device according to any one of the first to third aspects, the token allocating unit is under the control of the own device and belongs to the certain multicast group. Determining the number of data receiving terminals to which the token should be assigned according to at least one of the number of data receiving terminals that are present and the average time that the data receiving terminals are continuously present under its own device. To do.

  According to the present invention, the token allocating means of the group management device determines the number of data receiving terminals to which the token should be allocated according to at least one of the number of the data receiving terminals and the average time. The token assigning means can determine the optimum number of data receiving terminals to which the token should be assigned in accordance with the number of data receiving terminals under the control and the movement status. For this reason, since the group management apparatus can manage only the optimum number of data receiving terminals, multicast group management can be performed while suppressing the traffic.

According to a fifth aspect of the present invention, in the group management device according to any one of the first to fourth aspects, the token member management unit is configured to transmit the data only to a data receiving terminal to which the token is assigned. A response message to the message received from the receiving terminal is returned.
According to the present invention, the token member management means of the group management device returns a response message to the message received from the data receiving terminal only to the data receiving terminal to which the token is assigned. The message exchange with the assigned data receiving terminal can be managed accurately so that no message is lost, while the reply message is not returned to the data receiving terminal to which the token is not assigned. be able to. Therefore, the group management apparatus can manage the multicast group while reducing the traffic.

According to a sixth aspect of the present invention, in the group management device according to any one of the first to fifth aspects, the token member management unit is configured to transmit the data only to a data receiving terminal to which the token is assigned. A message for confirming whether or not the receiving terminal is in the token allocation target state is transmitted.
According to the present invention, the token member management means of the group management apparatus confirms whether or not the data receiving terminal is in the token assignment target state only for the data receiving terminal to which the token is assigned. For the data receiving terminal to which the token is assigned, the data receiving terminal to which the token is assigned is managed to determine whether it is in the token assignment target state, while for the data receiving terminal to which the token is not assigned. Sending messages can be omitted. Therefore, the group management apparatus can perform multicast group management while reducing the traffic.

The invention according to claim 7 is the multicast group management method performed by the group management device, wherein at least one data among the data reception terminals that are under the group management device and belong to a certain multicast group. A token allocating step for allocating tokens to the receiving terminal, a state of the data receiving terminal to which the token is allocated does not exist under the group management device, and a state that does not belong to the certain multicast group When it is found that the state is at least one of the above, a token deallocating step for deallocating a token to the data receiving terminal, and a token deallocated in the token deallocating step, And there is a certain Among the data receiving terminal belonging to the cast group, and token reallocation step of allocating to any one of the data receiving terminal, while assigned the token to at least one data receiving terminal, belonging to the certain multicast group A multicast distribution data relay step for relaying multicast distribution data to a data receiving terminal , and by sending an inquiry message to the multicast group by the token allocation step, A group management method is provided , wherein a data receiving terminal to which the token is to be allocated is determined from data receiving terminals confirmed to be present.
According to the present invention, the group management device can perform multicast group management only with the traffic for managing the state of the data receiving terminal to which the token is allocated, and can reduce the traffic for multicast group management. Can be suppressed.

  According to the present invention, the group management apparatus allocates a token to at least one data receiving terminal among the data receiving terminals that are under its control and belong to a certain multicast group, and the token is In order to manage whether or not the allocated data receiving terminal is in the token allocation target state, multicast group management can be performed only with the traffic for managing the status of the data receiving terminal to which the token is allocated. The amount of communication for multicast group management can be suppressed.

Next, embodiments of the present invention will be described with reference to the drawings. In each drawing referred to in the following description, the same reference numerals are given to the same parts as in the other drawings.
[1. Constitution]
FIG. 1 shows a configuration of a multicast group management system 10 according to the embodiment of the present invention. As shown in FIG. 1, the multicast group management system 10 includes a network including a group management device 20 that manages a multicast group and a plurality of data reception terminals 30 that are subordinate to the group management device 20. Here, “the data receiving terminal 30 exists under the group management device 20” means that the group management device 20 and the data receiving terminal 30 are connected to be communicable, and the group management device 20 is connected to the data receiving terminal 30. This is a state where data distribution is relayed. Examples of such a network include Ethernet (registered trademark), a wireless LAN, and a mobile communication network. The group management device 20 is, for example, a router. In this case, the data receiving terminal 30 on the subnetwork managed by the router is the data receiving terminal 30 existing under the router. The data receiving terminal 30 is, for example, a mobile communication terminal or a personal computer (hereinafter referred to as “PC”). In the following description, when it is necessary to distinguish a plurality of data receiving terminals 30, they are described as a data receiving terminal 301, a data receiving terminal 302, a data receiving terminal 303,.

  FIG. 2 shows an example of a network configuration including the multicast group management system 10 and other related devices. The group management device 20 is connected to a data relay device 40 that relays data distribution, and the group management device 20 itself also has the function of the data relay device 40. The group management device 20 and the data relay device 40 are connected to each other and form a network such as the Internet. The data transmission terminal 50 is connected to the data relay device 40 and can distribute data to the network via the data relay device 40.

  Next, the configuration of the group management apparatus 20 will be described in detail. The group management device 20 includes a CPU (Central Processing Unit), a ROM (Read Only Memory), a RAM (Random Access Memory), a hard disk, a communication interface, and an internal clock, and is a general computer hardware resource. It has. In addition, software resources such as data and programs are stored in the ROM, RAM, and hard disk.

  As software resources stored in the hard disk of the group management device 20, for example, there is a group management table for managing members of a multicast group. The group management table is a table for managing management information regarding the data receiving terminals 30 that exist under the group management apparatus 20 and belong to the multicast group. The group management table is created for each multicast group.

  FIG. 3 shows an example of the group management table. As shown in the figure, the group management table is provided with a terminal field, a status field, a token information field, and a time field. Information for uniquely identifying the data receiving terminal 30 such as an IP address is recorded in the terminal field. In the status field, information indicating the status of the group management device 20 with respect to the data receiving terminal 30, for example, information indicating the contents of the exchanged messages and communication status is recorded. In the token information field, information indicating whether or not a token that plays a major role in the present invention is assigned to the data receiving terminal 30 is recorded. In the time field, time information indicating the time when these fields are updated is recorded. Hereinafter, information including “terminal”, “state”, “token information”, and “time” recorded in these fields is referred to as “management information”. Further, the group management table is associated with information for identifying a multicast group (not shown), and this information identifies which multicast group is a table for managing the group management table. Is possible.

  Next, the “token” in the present invention will be described. The “token” in the present invention is information assigned to at least one data receiving terminal 30 among the data receiving terminals 30 that are under the group management apparatus 20 and belong to a certain multicast group. The data receiving terminal 30 to which the token is assigned is strictly managed such as the status of joining the multicast group and the status of movement from the subordinate of the group management device 20.

  Information included in the token includes an ID for uniquely identifying the token, a multicast address to which the token is applied, an expiration date, and the like. In some cases, the electronic signature of the group management apparatus 20 may be included. Hereinafter, the data receiving terminal 30 to which the token is assigned is also referred to as “token member”, and the data receiving terminal 30 to which no token is assigned is also referred to as “non-token member”.

The hard disk of the group management device 20 stores a program for recording management information in the group management table and a program for assigning tokens to the data receiving terminal 30.
By operating these hardware resources and software resources in cooperation, the token allocation unit 21, the token member management unit 22, the token allocation release unit 23, and the multicast distribution data relay unit 24 shown in FIG. This is realized in the group management apparatus 20.

  The token allocation unit 21 allocates a token to at least one data receiving terminal 30 among subordinate data receiving terminals 30 belonging to a certain multicast group. As a specific token allocation procedure, the token allocation unit 21 transmits a join response message (Join Response) including a token to the data receiving terminal 30 to the data receiving terminal 30 to which the token is to be allocated. Thus, when receiving a join response confirmation message (Join Response ACK) from the data receiving terminal 30, the token assigning unit 21 indicates that a token has been assigned to the data receiving terminal 30 in the token information field of the group management table. The information “Yes” is recorded.

In addition, when the token allocation canceling unit 23 cancels the token allocation to the data receiving terminal 30, the token allocation unit 21 allocates the token that has been allocated to another data receiving terminal 30 that can be allocated.
The token assigning unit 21 has a function of determining the data receiving terminal 30 to which a token is to be assigned. Based on various information, the token allocation unit 21 determines to allocate a token to the data receiving terminal 30 that is expected not to leave the multicast group for the longest time and to move from the subordinate.

  As an example of a specific determination method, the token allocation unit 21 responds to the “duration” in which the data receiving terminal 30 continues to exist under the group management device 20 and belongs to a certain multicast group. Thus, the data receiving terminal 30 to which the token is to be assigned is determined. For example, the token allocation unit 21 grants a token to the data receiving terminal 30 having the longest “duration”. This is because the data receiving terminal 30 belonging to the longest multicast group is expected to continue in the same state in the future. Here, “duration” is calculated using time information recorded in the time field of the group management table.

  As another example of the determination method, the token allocating unit 21 determines whether the data receiving terminal 30 exists under the group management apparatus 20 and belongs to a certain multicast group in the past “cumulative time”. The data receiving terminal 30 to which a token is to be assigned is determined. As a method of calculating “cumulative time”, for example, the group management apparatus 20 stores the update history of the group management table in the hard disk. Then, the token allocation unit 21 calculates, for each data receiving terminal 30, the accumulated time that the data receiving terminal 30 belonged to a certain multicast group, based on the time information included in the update history. Based on the calculation result, the token allocation unit 21 determines to allocate a token to the data receiving terminal 30 having the longest accumulated time.

  As another example of the determination method, the token assigning unit 21 determines the data receiving terminal 30 to which a token is to be assigned according to the model of the data receiving terminal 30. Specifically, the group management apparatus 20 records model information included in a message transmitted from the data receiving terminal 30 on a hard disk. The token allocating unit 21 refers to the model information and determines the data receiving terminal 30 of the model that is expected to have the smallest movement amount as the data receiving terminal 30 to which the token is to be allocated. For example, the token assigning unit 21 determines a data receiving terminal 30 to which a token is to be assigned, that is, a PC rather than a mobile phone and a desktop PC rather than a notebook PC.

  The token assigning unit 21 has a function of determining the number of data receiving terminals 30 to which a token should be assigned for each multicast group. As a determination method, the token allocation unit 21 is subordinate to the group management apparatus 20 and the number of data receiving terminals 30 to which tokens should be allocated according to the number of data receiving terminals 30 belonging to a certain multicast group. To decide. For example, when the number of subordinate data receiving terminals 30 belonging to a certain multicast group exceeds a predetermined number, the token allocating unit 21 sets the number of data receiving terminals 30 to which a token is to be allocated to the certain multicast group to two. To decide.

  As another determination method, the token allocation unit 21 changes the number of data reception terminals 30 to which tokens should be allocated based on the average time that the data reception terminals 30 are continuously present under the group management device 20. You may do it. For example, when the average time is shorter than a predetermined threshold, the token assigning unit 21 determines that the data receiving terminal 30 existing on the subordinate network has a strong tendency to move, and the data receiving terminal 30 to which the token is to be assigned. May be increased. By increasing the number of token members in this way, the message transmitted by the group management apparatus 20 even when there are many inconsistencies between the group members recorded in the group management table and the group members that actually exist under the group members. Since the probability of obtaining a response to is increased, it is possible to solve the problem of leave latency.

  Note that the token assigning unit 21 may assign tokens to all the data receiving terminals 30 belonging to a subordinate multicast group depending on circumstances. In this case, the group management device 20 and the data receiving terminal 30 perform one-to-one state management, and strict group member management is possible. Such a management method is effective when the number of group members is small. However, if the number of group members increases, scalability problems will occur. In this case, the management method is to reduce the number of tokens to be given and give tokens to only some group members. Is good.

  The token member management unit 22 manages whether or not the data receiving terminal 30 to which the token is allocated by the token allocation unit 21 is in the “token allocation target state”. Here, the “token allocation target state” means that the data receiving terminal 30 to which a token corresponding to a certain multicast group is allocated continuously exists under the group management apparatus 20 and is in the certain multicast group. The state that belongs. Therefore, when the data receiving terminal 30 to which a token corresponding to a certain multicast group is assigned does not exist under the group management device 20, that is, the data receiving terminal 30 is under the control of another group management device 20. When the mobile terminal is moved or powered off, the data receiving terminal 30 is not in the “token allocation target state”. In addition, even when the data receiving terminal 30 transmits a leave request message (Leave Request) to leave a certain multicast group, the data receiving terminal 30 is not in the “token allocation target state”. .

  Specific methods for managing the “token allocation target state” by the token member management unit 22 include the following methods. The token member management unit 22 returns a response message to the received message only to the data receiving terminal 30 to which the token is assigned, and manages the message so as not to be lost. Examples of messages received from the data receiving terminal 30 include a join request message (Join Request) and a leave request message (Leave Request). Note that the “data receiving terminal 30 to which a token is allocated” includes the data receiving terminal 30 that is determined as a token allocation target. As another management method, the token member management unit 22 transmits a state confirmation message (Hello) for confirming the state only to the data receiving terminal 30 to which the token is assigned.

The token member management unit 22 strictly manages whether or not the data receiving terminal 30 to which the token is allocated is in the “token allocation target state” by exchanging messages as described above.
The token deallocating unit 23 allocates a token to the data receiving terminal 30 when it is determined by the management by the token member managing unit 22 that the data receiving terminal 30 to which the token is allocated is not in the “token allocation target state”. Is released. As a specific deallocation method, the token deallocation unit 23 updates the token information field for the data receiving terminal 30 in the group management table to “No”.

  While the token is allocated to at least one data receiving terminal 30, the multicast distribution data relay unit 24 relays the multicast distribution data to the data receiving terminal 30 belonging to the multicast group corresponding to the token. Whether or not a token corresponding to a certain multicast group is assigned to at least one data receiving terminal 30 is determined based on management information in which “Yes” is described in the token status field of the group management table of the certain multicast group. It is judged by whether or not it exists.

[2. Operation]
Hereinafter, a multicast group management method in the multicast group management system 10 will be described with reference to the drawings.
In the multicast group management method according to the present invention, among the data receiving terminals 30 existing under the group management device 20, there is a data receiving terminal 30 that desires to receive multicast distribution data distributed to a certain multicast group. Provide a method to manage whether or not to do.

(Token allocation process when first group member joins)
FIGS. 5 to 8 are diagrams for explaining an operation procedure of token allocation processing performed when the data receiving terminal 301 joins a certain multicast group (here, “multicast group A”) as the first group member. It is.
Since the data receiving terminal 301 is the first group member, the group management table for the multicast group A is not created on the hard disk of the group management apparatus 20 at the time when this procedure is executed. Here, it is assumed that one token is allocated to members of the multicast group A under the group management apparatus 20.

First, the data receiving terminal 301 transmits a join request message (Join Request) to the group management apparatus 20 to notify that it desires to receive data distributed to the multicast group A (FIGS. 5 and 5). 6 step S1).
The group management apparatus 20 that has received the Join Request checks whether or not the multicast group A group management table exists on the hard disk. Here, since there is no group management table for multicast group A, the group management apparatus 20 knows that data receiving terminal 301 is the first group member in multicast group A. Then, the group management device 20 creates a group management table for the multicast group A (step S2 in FIG. 5).

  At the same time, the multicast distribution data relay unit 24 of the group management device 20 constructs a multicast distribution path using a multicast routing protocol such as PIM (Protocol Independent Multicast) in order to relay the multicast distribution data addressed to the multicast group A. (Step S3 in FIG. 5). The multicast distribution data relay unit 24 relays the multicast distribution data to the data receiving terminals 301 belonging to the multicast group A. As a result, the data receiving terminal 301 can receive the multicast distribution data.

  When receiving the Join Request, the group management device 20 creates an area for describing management information of the data receiving terminal 301 in the group management table. Then, the group management apparatus 20 records information “301” for identifying the data receiving terminal 301 in the terminal field of the created area, and records information “Join Received” indicating that the Join Request has been received in the status field. Then, “No” is recorded in the token information field, and the time “11:30” at which the Join Request is received is recorded in the time field (step S4 in FIGS. 5 and 6).

  Here, the token assigning unit 21 of the group management apparatus 20 needs to assign at least one token to the group member of the multicast group A, but the Join from the data receiving terminal 301 that is the first group member of the multicast group A now. Since Request is received, it is decided to allocate a token to the data receiving terminal 301. Then, the token allocation unit 21 generates a token including a token ID for uniquely identifying the token and a multicast address for identifying the multicast group A.

The token member management unit 22 returns a join response message (Join Response) including the generated token to the data receiving terminal 301 (step S5 in FIGS. 5 and 7). Next, the token member management unit 22 records information “Join Response Sent” indicating that the Join Response has been transmitted in the status field of the group management table (step S6 in FIGS. 5 and 7).
The data receiving terminal 301 that has received the Join Request returns a join response confirmation message (Join Response ACK) (Step S7 in FIGS. 5 and 8).

The token member management unit 22 of the group management apparatus 20 that has received the Join Response ACK records information “Connected” indicating that the Join Response ACK has arrived in the status field of the group management table. Furthermore, the token member management unit 22 records “Yes” in the token information field because it has been confirmed that the token has successfully arrived at the data receiving terminal 301 (step S8 in FIGS. 5 and 8).
With the above operation, the group management apparatus 20 can complete the token allocation to the data receiving terminal 301 that is the first group member of the multicast group A and the confirmation response.

(Subscription of second and subsequent group members)
Next, an operation procedure when the data receiving terminal 302 joins the multicast group A as the second and subsequent group members will be described with reference to FIG. 9 and FIG.
Similarly to the data receiving terminal 301, the data receiving terminal 302 transmits a join request message (Join Request) to the group management apparatus 20, thereby requesting reception of multicast distribution data distributed to the multicast group A. (Step S11 in FIGS. 9 and 10). This procedure is the same as when first joining a group member.

  The group management apparatus 20 that has received the Join Request checks whether a group management table for managing the multicast group A has already been created. Here, since the group management table for multicast group A has already been created on the hard disk of the group management apparatus 20 and management information relating to the data receiving terminal 301 is recorded in the group management table, the data receiving terminal 302 Are the second and subsequent group members in multicast group A. The group management device 20 adds management information of the data receiving terminal 302 to the group management table of the multicast group A. Specifically, the group management apparatus 20 creates an area for recording management information of the data receiving terminal 302 in the group management table. Then, the group management apparatus 20 records information “302” for identifying the data receiving terminal 302 in the terminal field of the created area, records “Join Received” in the status field, and “No” in the token information field. Is recorded, and the time “11:34” when the Join Request is received is recorded in the time field (step S12 in FIGS. 9 and 10).

When the group management apparatus 20 receives a Join Request from the second and subsequent group members, it is not necessary to allocate a token to the second and subsequent group members, and thus the process ends here.
Since the data receiving terminal 301 is already a member of the multicast group A, the data receiving terminal 302 can receive the multicast distribution data from the time when the Join Request is transmitted.

(Token allocation cancellation processing when a token member leaves)
FIGS. 11 to 16 show that when the data receiving terminal 301 as a token member does not wish to receive multicast distribution data addressed to the multicast group A or moves out of the group management device 20, it leaves the multicast group A. It is a figure which shows the operation | movement procedure of the token allocation cancellation | release process at the time of doing. Here, the description starts from the state in which the data receiving terminal 303 and the data receiving terminal 304 are also recorded as group members in the group management table of the multicast group A.
The data receiving terminal 301 transmits a leave request message (Leave Request) to the group management apparatus 20 to notify that it is desired to leave the multicast group A (step S21 in FIGS. 11 and 12). This Leave Request includes information regarding the token that the data receiving terminal 301 releases.

  The token member management unit 22 of the group management apparatus 20 that has received the leave request refers to the group management table, and “Yes” is recorded in the token information field for the data reception terminal 301. It is determined that this is a leave request from the receiving terminal 301. Then, the token member management unit 22 updates the status field for the data receiving terminal 301 in the group management table with information “Leave Request Received” indicating that the Leave Request has been received from the data receiving terminal 301. Further, the token member management unit 22 determines whether or not the received information regarding the token is correct information. For example, the token member management unit 22 performs a general tampering check and a sender validity check. For example, as an example of a token tampering check method, there is a method of using a message authentication code generated by using a keyed hash function as a token or adding it as token attached information. As a result of the determination, if it is determined that the token is correct, the token member management unit 22 determines that the data receiving terminal 301 is no longer in the “token allocation target state”.

Thereby, the token deallocating unit 23 changes the token information field of the data receiving terminal 301 to “No”, thereby returning the token, that is, deallocating the token to the data receiving terminal 301. Is recorded (step S22 in FIGS. 11 and 12).
Thereafter, the token member management unit 22 of the group management apparatus 20 returns a leave request confirmation message (Leave Request ACK) to the data receiving terminal 301 (step S23 in FIGS. 11 and 13). And the token member management part 22 of the group management apparatus 20 deletes the management information regarding the data receiving terminal 301 recorded in the group management table (step S24 in FIGS. 11 and 13).
The above procedure completes the withdrawal of the data receiving terminal 301, which is a token member, from the multicast group A.

<Granting tokens to other terminals>
Here, since the token has a feature that it is assigned to at least one data receiving terminal 30 among the multicast group members, the token assigning unit 21 of the group management apparatus 20 is assigned to the data receiving terminal 301. The token needs to be allocated to another data receiving terminal 30.
Therefore, when there is a data receiving terminal 30 recorded as a group member in the group management table of multicast group A (step S31 in FIG. 14; Yes), the token allocation unit 21 of the group management apparatus 20 The management information including the most past time information is searched from the management table, and the data receiving terminal 30 corresponding to the searched management information is selected as the next token member (step S33 in FIG. 14).

  If no other data receiving terminal 30 is recorded in the group management table (step S31 in FIG. 14; No), the group member of the multicast group A does not exist under this point. For this reason, the token member management unit 22 deletes the group management table itself from the hard disk. Thereby, the multicast distribution data relay unit 24 stops relaying the distribution data to the multicast group A (step S32 in FIG. 14).

  Here, as shown in FIG. 15, there is a data receiving terminal 30 recorded as a group member in the group management table (step S31 in FIG. 14; Yes), and the time recorded in the time field of the group management table. From the information, it can be seen that the data receiving terminal 302 belongs to the multicast group A as a group member under the longest time. For this reason, the token allocation unit 21 selects the data receiving terminal 302 as the next token member (step S33 in FIG. 14).

  Next, a process for assigning a token to the data receiving terminal 302 selected as the next token member will be described. The token allocation unit 21 of the group management apparatus 20 returns a join response message (Join Response) including the token to the data receiving terminal 302 that is to become the next token member (step S34 in FIGS. 14 and 15). Further, the token member management unit 22 of the group management device 20 records “Join Response Sent” as information indicating that the Join Response has been transmitted in the status field for the data receiving terminal 302 of the group management table (FIGS. 14 and FIG. 14). 15 step S35).

The data receiving terminal 302 that has received the Join Response returns a join response confirmation message (Join Response ACK) (Step S36 in FIGS. 14 and 16).
Upon receiving the Join Response ACK, the token member management unit 22 of the group management apparatus 20 records “Connected” as information indicating that the join response confirmation is completed in the status field for the data receiving terminal 302 of the group management table. Further, since it has been confirmed that the token has successfully arrived at the data receiving terminal 302 by the Join Response ACK, the token allocation unit 21 records “Yes” in the token information field for the data receiving terminal 302 (FIGS. 14 and 14). 16 step S37).

  When the token allocation to the data receiving terminal 301 that is a token member is canceled by the token allocation cancellation unit 23 by the above operation, the token allocation unit 21 of the group management apparatus 20 receives the data to be the next token member. A token can be assigned to the terminal 302.

(Leaving non-token members)
FIG. 17 and FIG. 18 illustrate an operation procedure when the data receiving terminal 303 which is a non-token member leaves the multicast group A.
At the time of starting this procedure, it is assumed that the management information shown in FIG. 16 is recorded in the group management table.
First, the data receiving terminal 303 transmits a leave request message (Leave Request) to the group management apparatus 20 to notify that it is desired to stop receiving data distributed to the group members of the multicast group A (see FIG. 17 and step S41 in FIG.

  As shown in the group management table of FIG. 16, the group management device 20 that has received the Leave Request records “No” in the token information field for the data reception terminal 303, and thus the data reception terminal that is a non-token member. It is determined that this is a Leave Request from 303. Then, the group management apparatus 20 deletes the management information related to the data receiving terminal 303 from the group management table (step S42 in FIGS. 17 and 18). With the above operation, the procedure for leaving the non-token member is completed.

(Token member Keep Alive)
As described above, the token allocation unit 21 of the group management apparatus 20 divides the multicast group members existing under the group into token members and non-token members. Then, the token member management unit 22 performs a confirmation response to the exchange of each message regarding the token member, and performs strict membership management. Thus, the token member management unit 22 strictly manages that the token member is in the “token allocation target state”. On the other hand, a feature of the present invention is to ensure scalability in the group management apparatus 20 by minimizing the message exchange for non-token members and not performing strict management.

Accordingly, the token member management unit 22 of the group management apparatus 20 periodically checks the status of the token member in addition to sending a confirmation response, and determines whether the token member belongs to the multicast group under its control. That is, it is necessary to strictly manage whether or not the token member is in the “token allocation target state”.
A Keep Alive procedure for confirming that the token member is in the “token allocation target state” will be described with reference to FIGS. 19 and 20.

In FIG. 19, the token member management unit 22 of the group management device 20 periodically transmits a status confirmation message (Hello) to the token members (step S51 in FIG. 19). Hello is transmitted to the token member according to a predetermined timer.
The data receiving terminal 302 that is the token member that has received Hello returns a status confirmation response message (Hello ACK) as a Hello response (Step S52 in FIG. 20).
Through the above operation, the token member management unit 22 of the group management apparatus 20 can confirm that the data receiving terminal 302 that is a token member is in the “token allocation target state”.

  If the token member management unit 22 of the group management apparatus 20 transmits Hello to the token member but does not respond after waiting for a certain timeout period, the token member is no longer in the “token allocation target state”. to decide. As a result, the token deallocating unit 23 deallocates the token to the token member. Specifically, the token deallocating unit 23 deletes the token member management information from the group management table. Next, the token allocation unit 21 detects that the token allocation has been released, and performs token allocation processing for other group members under the control according to the procedure shown in FIG. As a result, the token allocating unit 21 performs control so that at least one token member exists on the subnetwork under the control.

(Sudden withdrawal of non-token members)
For the non-token member, since the confirmation response to the Join Request or the Leave Request is not performed, and the state confirmation by Keep Alive is not performed, the subscription status of the data receiving terminal 30 managed by the group management table of the group management device 20; Often, the actual subscription status of the data receiving terminal 30 does not match.
For example, in a mobile network such as a wireless LAN in which the data receiving terminal 30 moves frequently, the data receiving terminal 30 that is a non-token member is under the control of another group management apparatus 20 without transmitting a leave request. Naturally, it will move. Further, a case where the data receiving terminal 30 suddenly loses power may be considered. At that time, the group management apparatus 20 has a state in which the subscription status managed by the group management table held by the group management device 20 does not match the actual subscription status. As a case where such a state becomes a problem, there is an example in which a non-token member is assigned a token and changes to a token member as shown in FIG.

The operation procedure when the data receiving terminal 302 no longer exists when the group management apparatus 20 transmits a Join Response in step S34 of FIGS. 14 and 15 will be described with reference to FIG.
FIG. 21 illustrates a situation in which the data receiving terminal 302 is absent without issuing a leave request due to power interruption or movement. In such a case, the token member management unit 22 of the group management apparatus 20 issues a Join Response, but since there is no response (reply) to the Join Response, the data receiving terminal 302 is not in the “token allocation target state”. Judge. Then, the token deallocating unit 23 deletes the management information regarding the data receiving terminal 302 from the group management table.
Thereafter, the token allocating unit 21 of the group management apparatus 20 executes a procedure for allocating tokens to other terminals shown in FIG. 14 in order to perform a procedure for giving tokens to the other data receiving terminals 30.

(Membership Query)
When the sudden detachment of the non-token member spreads to many data receiving terminals 30, there will be a large number of data receiving terminals 30 that do not reply to a Join Response as described with reference to FIG. In such a case, the token allocation unit 21 of the group management apparatus 20 may continuously transmit a Join Response to the data receiving terminal 30 in order to allocate a token to the data receiving terminal 30.

  As a specific example, even if the group management device 20 knows that there are a large number of group members under the management information recorded in the group management table, such as power-off or movement of the group members For the reason, there may be a case where all the group members that are known to exist under the own device 20 do not actually exist. In such a case, the token allocation unit 21 of the group management apparatus 20 tries to give tokens to all the data receiving terminals 30 recorded as group members in the group management table in order, and waits for a reply. The situation of continuing will occur. In such an example, when the group management device 20 does not need to relay the multicast distribution data, a problem of leave latency occurs in which the relay of the data continues, resulting in the network utilization efficiency. Cause a significant decrease in

From the above, the token allocation unit 21 of the group management apparatus 20 may multicast the subscriber inquiry message (Membership Query) to the entire network instead of the Join Response.
FIG. 22 shows an example in which the group management device 20 confirms a multicast group member using Membership Query. When receiving the Membership Query, the data receiving terminal 30 starts a timer within the range of the maximum response time (Max Response Time) designated by the group management device 20, and when the timer expires, the group management device 20 Again send a Join Request.

As a result, the group management apparatus 20 can confirm which data receiving terminal 30 is present as a group member. As described above, the token allocation unit 21 can use the Membership Query in order to match the subscription status of the group member managed in the group management table with the actual subscription status.
The token allocation unit 21 of the group management apparatus 20 can determine whether to use a Membership Query instead of transmitting a Join Response to each data receiving terminal 30. For example, when the timeout for Join Response occurs more than a certain number of times, it is highly likely that the subscription status of the group member managed in the group management table does not match the actual subscription status. Therefore, a determination method in which the token allocation unit 21 uses Membership Query can be considered.

  The group management device 20 may periodically check the subscription status of the subordinate data receiving terminals 30 using a Membership Query. For example, in the case of the group management apparatus 20 used in a network in which the data receiving terminal 30 such as a wireless LAN moves frequently, a contrivance such as shortening the time interval for issuing a Membership Query can be considered.

(Status mismatch due to missing message)
Messages are exchanged between the data receiving terminal 30 and the group management device 20 as token members when joining a multicast group, Join Request → Join Response → Join Response ACK, and leaving a multicast group Leave Request → Leave Request ACK If any message is missing, it can be dealt with by retransmission.

  For example, when Join Response is lost for some reason when joining a multicast group, the token member management unit 22 of the group management apparatus 20 grasps the situation by not returning Join Response ACK. Then, the token member management unit 22 of the group management apparatus 20 copes with the missing message by retransmitting the Join Response. The same applies when the Join Response ACK is missing.

Similarly, even when a leave request or leave request ACK is missing, the data receiving terminal 30 can detect a missing data by not receiving a leave request ACK for the leave request. The data receiving terminal 30 that has detected the missing data can deal with the missing message by retransmitting the Leave Request.
However, in the case of a non-token member, since there is no response from the group management apparatus 20 to any of the Join Request and Leave Request transmitted by the non-token member, even if those messages are missing, they are missing. May not be detected.

  For example, when the Join Request of the data receiving terminal 30 that should become the token member that issued the Join Request for joining the first multicast group is missing, the data receiving terminal 30 may receive distribution of the multicast distribution data. Since this is not possible, the data receiving terminal 30 can make a determination to retransmit the Join Request.

  On the other hand, when the Join Request transmitted by the non-token member is missing, the non-token member can receive the multicast distribution data even though the message has not actually reached the group management apparatus 20. For this reason, a mismatch between the subscription status of the group member managed in the group management table and the actual subscription status occurs. In such a case, a situation occurs in which the data receiving terminal 30 is not actually recognized by the group management device 20 even though it is a group member. It is also possible that the relay will be stopped. In such a case, the data receiving terminal 30 needs to take measures such as determining that an abnormality has occurred due to the end of reception of the multicast distribution data and transmitting a Join Request again.

  When the group management device 20 determines that the last group member has left in view of the occurrence of the above situation, the group member remaining using the Membership Query before the data relay is stopped You may inquire whether or not it exists. In this way, the group management device 20 does not stop relaying multicast data to non-token members.

(Receiving messages from non-group members)
If the group subscription status managed in the group management table of the group management device 20 and the actual group subscription status of the data receiving terminal 30 do not match, the data receiving terminal 30 is not a member of a multicast group. , Join Response, Hello, or Membership Query may be received.

In such a case, since the data receiving terminal 30 ignores the message, as a result, the group management apparatus 20 determines that the data receiving terminal 30 does not exist. Can be matched to the actual group subscription status. However, in the method of causing the group management device 20 to time out by ignoring, there is a time lag from when the group management device 20 transmits a message until the group management table is updated.
Therefore, when the data receiving terminal 30 is not a member of a certain multicast group but receives a Join Response, Hello, or Membership Query for the group, the data receiving terminal 30 may return a negative response (NACK) to the Join Response, Hello, or Membership Query. By returning NACK, the group management apparatus 20 can quickly grasp the mismatch.

(Destination address of each message)
FIG. 23 summarizes the list of each message described above.
Since the Join Request is transmitted from the data receiving terminal 30 to the group management apparatus 20, the unicast address of the group management apparatus 20 is the destination. Alternatively, a multicast group address for the group management apparatus 20 group may be assigned in advance and used as a destination address. Alternatively, if there is an anycast address assigned for the group management device 20, it may be used as the destination address.

The Join Response is transmitted from the group management apparatus 20 to the data receiving terminal 30, and the unicast address of the data receiving terminal 30 is used as the destination address.
The Join Response ACK is transmitted from the data receiving terminal 30 to the group management apparatus 20, and there are three types of destination address setting methods as in the Join Response.

  Since Leave Request is transmitted from the data receiving terminal 30 to the group management device 20, the destination is the unicast address of the group management device 20. Alternatively, a multicast group address for the group management apparatus 20 group may be assigned in advance and used as a destination address. Alternatively, if there is an anycast address assigned for the group management device 20, it may be used as the destination address.

Leave Request ACK is transmitted from the group management apparatus 20 to the data receiving terminal 30, and the unicast address of the data receiving terminal 30 is used as its destination address.
Since the Membership Query is a message transmitted from the group management apparatus 20 to the data receiving terminal 30 that is a member of the multicast group, the multicast address is used as the destination.

Since Hello is transmitted from the group management apparatus 20 to the data receiving terminal 30, the unicast address of the data receiving terminal 30 is used as the destination address.
However, as described above, there may be a plurality of token members. Therefore, in order to send a Hello message to all token members, a multicast group for token members may be set as the destination.

  Since Hello ACK is transmitted from the data receiving terminal 30 to the group management device 20, the unicast address of the group management device 20 is the destination. Alternatively, a multicast group address for the group management apparatus 20 group may be assigned in advance and used as a destination address. Alternatively, if there is an anycast address assigned for the group management device 20, it may be used as the destination address.

(Summary)
As described above, the group management apparatus 20 can reduce the amount of communication for group management by strictly managing only the data receiving terminal 30 to which the token is assigned. Further, the group management device 20 strictly manages the data receiving terminal 30 to which the token is assigned, so that the data belonging to the multicast group depends on whether or not the token is assigned to at least one data receiving terminal 30. It can be determined whether or not the receiving terminal 30 exists under the subordinate. This eliminates the need for transmitting a message for confirming whether or not there are group members under the control as in the prior art. As described above, according to the present invention, it is possible to perform multicast group management with reduced communication volume.

  In a mobile environment such as a wireless LAN, the data receiving terminal 30 moves frequently, and the period belonging to the multicast group under the group management apparatus 20 is normally considered to be shortened. For this reason, the data receiving terminal 30 that moves frequently is not assigned a token, thereby preventing strict management. On the other hand, tokens are assigned to some data receiving terminals 30 that have little movement and belong to the multicast group and are strictly managed. By performing such group management, it is possible to prevent unnecessary communication due to joining and leaving that occurs when the data receiving terminal 30 moves.

[3. Modified example]
Although the embodiments of the present invention have been described above, the present invention is not limited to such embodiments, and various modifications can be made within the scope of the technical idea. As modifications, for example, the following can be considered.
(1) As a token allocation method by the token allocation unit 21 in the above-described embodiment, the token allocation unit 21 transmits a Join Response including information on tokens to the data reception terminal 30, thereby causing the data reception terminal 30 to Although the token is stored, the present invention is not limited to this. For example, a Join Response that does not include information regarding tokens may be transmitted to the data receiving terminal 30 and information indicating that a token has been assigned to the data receiving terminal 30 may be recorded in the group management table.

(2) In the above-described embodiment, the token is basically described as being given to the data receiving terminal 30 that first joins a certain multicast group. However, the present invention is not limited to this. For example, when a request to join the same multicast group with no group member is received from two data receiving terminals 30 with a difference of 1 second, the token allocating unit 21 Depending on the model, it may be determined which data receiving terminal 30 the token is allocated to.

(3) In the above-described embodiment, the data receiving terminal 30 is basically assumed to transmit a leave request message (Leave Request) when moving from the subordinate of the group management device 20, but this is not limited to this. There is no limit. When the data receiving terminal 30 moves from the subordinate of the group management device 20, when the leave request message (Leave Request) is not transmitted, the group management device 20 transmits a subscriber inquiry message (Membership Query), or The position information of the data receiving terminal 30 may be received to determine whether or not the data receiving terminal 30 exists under the subordinate.

(4) The type of message in the above-described embodiment is an example, and any message may be used as long as the message fulfills the same function. In addition, the method for managing the “token allocation target state” and the type of message used for management are merely examples, and any method that can strictly manage the “token allocation target state” Any method may be used.

(5) In the above-described embodiment, the group management table is described as being created for each multicast group. However, all the multicast groups may be managed by one group management table. The data structure of the group management table is an example, and for example, a multicast address field may be provided as multicast group identification information.

  It can be used for multicast group management. In particular, when used in a communication environment in which many group members frequently move, the amount of communication required for group management can be greatly reduced.

1 is a configuration diagram of a multicast group management system 10 according to an embodiment of the present invention. It is a figure which shows an example of the network structure containing the multicast group management system 10 concerning the embodiment. It is a figure which shows an example of the group management table which concerns on the embodiment. It is a figure which shows the function structure of the group management apparatus 20 which concerns on the embodiment. It is a flowchart which shows the operation | movement procedure of the token allocation process performed when the data receiving terminal 301 based on the embodiment joins a multicast group as the first group member. It is a figure which shows the state of a group management table when the data reception terminal 301 which concerns on the embodiment transmits the subscription request message. It is a figure which shows the state of a group management table when the group management apparatus 20 which concerns on the embodiment transmits the joining response message to the data receiving terminal 301. FIG. It is a figure which shows the state of a group management table when the data reception terminal 301 which concerns on the embodiment transmits the subscription response confirmation message. It is a flowchart which shows the operation | movement procedure in case the data receiving terminal 302 based on the embodiment joins a multicast group as the 2nd group member after. It is a figure which shows the state of a group management table when the data receiving terminal 302 which concerns on the embodiment transmits the subscription request message. It is a flowchart which shows the operation | movement procedure of the token allocation cancellation | release process performed when the data receiving terminal 301 which concerns on the embodiment leaves | separates from a multicast group. It is a figure which shows the state of a group management table when the data receiving terminal 301 which is a token member based on the embodiment transmits the leaving request message. It is a figure which shows the state of a group management table when the group management apparatus 20 which concerns on the embodiment transmits the leaving request confirmation message. It is a flowchart which shows the operation | movement procedure of the token allocation process after the token allocation cancellation based on the embodiment. It is a figure which shows the state of a group management table when the group management apparatus 20 which concerns on the embodiment transmits the joining response message to the data receiving terminal 302. FIG. It is a figure which shows the state of a group management table when the data reception terminal 302 which concerns on the embodiment transmits the subscription response confirmation message. It is a flowchart which shows the operation | movement procedure in case the data receiving terminal 303 which is a non-token member based on the embodiment leaves | separates from a multicast group. It is a figure which shows the state of a group management table when the data receiving terminal 303 which is a non-token member based on the embodiment transmits the leaving request message. It is a figure which shows the state of a group management table when the group management apparatus 20 which concerns on the embodiment transmits the status confirmation message to the data receiving terminal 302 which is a token member. It is a figure which shows the state of a group management table when the data reception terminal 302 which concerns on the embodiment transmits the state confirmation response message to the group management apparatus 20. It is a figure for demonstrating a state when the group management apparatus 20 which concerns on the embodiment tries to allocate a token to a non-existing member. It is a figure which shows the state of a group management table when the group management apparatus 20 which concerns on the embodiment has transmitted the subscriber inquiry message with respect to the subordinate data receiving terminal 30. FIG. It is a figure for demonstrating the kind of message which concerns on the embodiment.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Multicast group management system 20 Group management apparatus 21 Token allocation part 22 Token member management part 23 Token allocation release part 24 Multicast delivery data relay part 30,301,302,303,304 Data receiving terminal 40 Data relay apparatus 50 Data transmission terminal

Claims (7)

In a group management device that relays multicast distribution data to a data receiving terminal existing under its own device,
Token allocation means for allocating a token to at least one data receiving terminal among the data receiving terminals belonging to a certain multicast group;
Token member management means for managing whether or not the data receiving terminal to which the token is allocated is in a token allocation target state that is under the control of the own device and belongs to the certain multicast group;
A token deallocating unit for deallocating a token to the data receiving terminal when the token member managing unit determines that the data receiving terminal to which the token is allocated is not in the token allocation target state;
Multicast distribution data relay means for relaying multicast distribution data to data receiving terminals belonging to the certain multicast group while the token is assigned to at least one data receiving terminal ;
The token allocation means includes
By sending a query message to the multicast group to which the certain, from the data receiving terminal confirmed to belong to the certain multicast groups, and characterized that you determine the data receiving terminal should be allocated the token Group management device. The group management device according to claim 1, wherein the token allocating unit allocates the token deallocated by the token deallocating unit to another data receiving terminal. The token allocation means includes
The time at which the data receiving terminal is continuously present under its own device and continuously belongs to the certain multicast group,
Past accumulated time that the data receiving terminal exists under its own device and belongs to the certain multicast group, and
The group management device according to claim 1, wherein a data receiving terminal to which the token is to be assigned is determined according to at least one of a model of the data receiving terminal. The token allocation means includes
The number of data receiving terminals that are under the control of the own device and belong to the certain multicast group;
4. The number of data receiving terminals to which the token is to be allocated is determined according to at least one of an average time in which the data receiving terminal continues to be under its control. 5. The group management apparatus according to claim 1. The token member management means includes:
5. The group management apparatus according to claim 1, wherein a response message to a message received from the data receiving terminal is returned only to the data receiving terminal to which the token is assigned. The token member management means includes:
The message for confirming whether or not the data receiving terminal is in the token assignment target state is transmitted only to the data receiving terminal to which the token is assigned. The group management apparatus according to claim 1.   In the multicast group management method performed by the group management device,
  A token allocation step of allocating a token to at least one data receiving terminal among the data receiving terminals existing under the group management device and belonging to a certain multicast group;
  When it is found that the state of the data receiving terminal to which the token is assigned is at least one of a state that does not exist under the group management device and a state that does not belong to the certain multicast group A token deallocating step for deallocating a token to the data receiving terminal;
  A token that is deallocated in the token deallocating step and is allocated to any one of the data receiving terminals that are under the group management apparatus and belong to the certain multicast group A reassignment step;
  A multicast distribution data relay step for relaying multicast distribution data to data receiving terminals belonging to the certain multicast group while the token is allocated to at least one data receiving terminal;
  Have
  By transmitting an inquiry message addressed to the certain multicast group in the token allocation step, a data receiving terminal to which the token should be allocated is determined from data receiving terminals confirmed to belong to the certain multicast group. And a group management method.

Images