Ip packet/multicast method

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to an IP packet multicast method, and more particularly to an IP packet multicast method in an IMT (International Mobile Telecommunication) -2000 packet system.

【0002】

[Conventional technology]

Figure 1 is a configuration diagram of an example of the IMT-2000 packet system. This configuration diagram is common not only to conventional examples but also to the present invention. With reference to the figure, the IMT-2000 packet system is, for example, an external IP (Internet Protocol) network, that is, one ISP (Internet Service Provider) 7 and one GGSN (GGSN:) which is a gateway station between ISP7. Gateway GPRS Support Node, GPRS: General Packet Radio Service) 5, and two SGSNs (Serving GSN) 4 that temporarily hold subscriber contract information and perform mobile device authentication processing and control of subordinate devices. It consists of 4 RNCs (Radio Network Controller) 3 which are radio base stations, 8 throat B2 which are radio stations, and 3 MS (Mobile Subscriber) 1 which are mobile stations. In addition, one HLR / AuC (Home Location) for holding the contract information of the subscriber fixedly, grasping the location of the mobile station, and calculating the data required for the authentication process. Register / Authentication Center) 6 is attached.

【0003】

That is, ISP7 and GGSN5 are connected by wire, GGSN5 and SGSN4-1 and 4-2 are connected by wire, SGSN4-1 and RNC3-1 are connected by wire, SGSN4-2 and RNC3-2 to 3-4. And are connected. Furthermore, RNC3-1 and throat B2-1 ~ 2-3 are connected by wire, RNC3-2 and throat B2-4 are connected by wire, and RNC3-3 and throat B2-5 and 2 are connected by wire. -6 is connected by wire, and RNC3-4 and throat B2-7 and 2-8 are connected by wire. And the throat B2 and MS1-1 ~ 1-3 are wirelessly connected. The number of ISP7 to MS1 is not limited to this, and can be configured by any number.

【0004】

Next, the call connection procedure in the IMT-2000 packet system will be described. Figure 5 is a float chart showing the call connection procedure in the IMT-2000 packet system. With reference to the figure, after enabling communication with RNC3 by RRC (Radio Resource Control) procedure (S11), MS1 makes a service request (Service Request), which is a GMM (GPRS Mobility Management) protocol signal, to SGSN4. Request service start (S12).

【0005】

On the other hand, SGSN4 authenticates the requested MS1 (S13), and if it can be confirmed that it is a legitimate mobile device as a result, it sends a RANAP signal to RNC3 by a security mode command (Security Mode Command). Instructs the start of concealment processing (S14). Then, after the concealment processing is normally performed, the MS1 requests a call connection by an Active Packet Data Protocol Context Request (SM (Session Management) signal) (S15).

【0006】

An APN (Access Point Name), which is information that identifies the connection destination ISP, is set in this SM signal, and the SGSN4 that receives this SM signal should connect from the APN information using the DNS (Domain Name Server System) procedure. Get IP address information. Then, if the IP address of GGSN5 is successfully acquired, SGSN4 requests RNC3 to set tunneling between RNC3 and SGSN4 by RAB Assignment Request, which is a RANAP signal (S16). ..

【0007】

Next, SGSN4, which confirmed the tunneling setting between RNC3 and SGSN4 by the RANAP signal, is a GTP (GPRS Tunneling protocol) signal to GGSN5 with the IP address obtained by the DNS procedure. Create PDP Context Request (Create PDP) Context Request) is sent to request call settings for MS1 (S17).

【0008】

APN information is also set in this GTP signal, and the received GGSN5 identifies the ISP7 to be called and connected from the APN information. Then, when the connection processing in the GGSN5 is normally performed, the Create PDP Context Response, which is a GTP signal, notifies the SGSN4 that the connection processing has been normally performed (S18). At this point, GGSN5 establishes routing (route selection) information for the relevant MS and manages it as a PDP Context.

【0009】

Next, the response signal from GGSN5 is transmitted to MS1 via SGSN4 by the SM signal Active Packet Data Protocol Context Accept (S19), and MS1 starts packet communication (S20). At this point, SGSN4 establishes routing information for the relevant MS and manages it as a PDP context. This process determines the procedure for encapsulating each call between MS1 and GGSN5 and tunnels.

【0010】

The IP packet transmitted by MS1 is repeatedly encapsulated and decapsulated by nodes B2, RNC3, and SGSN4, and finally decapsulated by GGSN5 and transmitted to an external ISP. Note that the contents of the IP packet sent by MS1 are not referenced by the network node on the way. An IP packet transmitted from an external ISP7 to MS1 arrives at MS1 after being repeatedly encapsulated and decapsulated by GGSN5, SGSN4, RNC3, and node B2. The contents of the IP packet are not referenced by the network node on the way, except that the GGSN5 determines which MS1 the packet is addressed to.

【0011】

Here, "tunneling" refers to a process of transferring without making the node in the middle aware of the contents at the time of routing (route selection). That is, it refers to a transfer method in which only the nodes located at both ends of the tunnel are aware of the contents.

【0012】

The "tunneling setting" means exchanging signals between the nodes located at both ends of the tunnel and exchanging valid call identification information only between these two nodes.

【0013】

Specifically, the IP address of SGSN4 and the TEID (Tunnel Endpoint Identifier: TEID S) expected by the SGSN4 side are set in the GTP signal (create PDP context request) 17, and the GTP signal (create PDP context response) 18 Set the IP address of GGSN5 and TEID (TEID G) expected by GGSN5.

【0014】

After that, the data in the direction from SGSN4 to GGSN5 is transmitted to the IP address of GGSN5, and TEID G is set as the header information. On the other hand, the data in the direction from GGSN5 to SGSN4 is transmitted to the IP address of SGSN4, and TEID S is set as the header information. Then, the node (router, etc.) in the middle processes only the IP addresses of GGSN5 and SGSN4. The same procedure is performed for the RANAP signal (RAB assignment request and RAB assignment response) 16.

【0015】

By the way, in general, multicast communication does not require a user action for each data transmission, but transmits information from the network to a mobile device or distributes data to an unspecified number of mobile devices and users. The number of target mobile devices and subscribers is enormous, ranging from millions to tens of millions.

【0016】

The method currently defined as a method for performing multicast communication in the IMT-2000 packet system is that after forming tunneling from MS1 to GGSN5 by the above procedure, a mobile device sends an IGMP (Internet Group Management) to GGSN5 on the tunneling. Protocol) This is achieved by sending a message.

【0017】

In the IMT-2000 packet system, a logical connection for each call is set from the MS to the GGSN, and packet communication is realized by tunneling. Therefore, the multicast packet addressed to the MS received from the external ISP should be delivered by the GGSN. It will be copied for a few minutes and sent to each tunneling.

【0018】

An example thereof is disclosed in Japanese Patent Application Laid-Open No. 10-242962 (hereinafter referred to as Prior Document 1). The technology disclosed in Prior Document 1 receives a message transmitted from a transmitting host by a multicast gateway, copies the required number of the messages, and individually attaches them to a plurality of receiving hosts as IP unicast datagrams. It is to send to.

【0019】

Further, other examples of this type of technology are disclosed in JP-A-10-154980 (hereinafter referred to as Prior Document 2) and JP-A-10-336176 (hereinafter referred to as Prior Document 3). In the technology disclosed in Prior Document 2, the IP multicast address management unit located in the network has a means for managing the IP multicast address used in the IP multicast service and assigning and releasing the IP multicast address. , The IP multicast service is assigned and released between the transmitting host and the IP multicast address management unit via the network.

【0020】

The technology disclosed in Prior Document 3 notifies the client of the start of group communication by IP multicast communication, notifies the management host of a request to participate in group communication, and from the management host to the client to group communication. Notification of acceptance or refusal of participation, execution of group communication between the management host and the client, notification of the request to leave the group communication from the client to the management host, and notification of the withdrawal request from the management host to multiple clients. The end of group communication is broadcast by IP multicast communication.

【0021】

[Problems to be Solved by the Invention]

However, the above-mentioned conventional techniques (including the prior document 1) have the following problems. The first problem is that the information managed by the GGSN (the number of PDP Contexts) becomes enormous in order to realize multicast communication, and it is difficult to simultaneously realize communication with a large number of mobile devices. In addition, SGSN and RNC have similar problems to varying degrees. The second problem is that even though the multicast data has exactly the same content, it is transmitted for each call, which puts pressure on the transmission capacity of the network and affects other non-multicast traffic. The means for solving these problems are not disclosed in the above-mentioned prior documents 2 and 3.

【0022】

Therefore, an object of the present invention is to provide an IP packet multicast method that reduces the amount of information managed by a GGSN or the like and does not overwhelm the transmission capacity of the network.

【0023】

[Means for solving problems]

In order to solve the above problems, the present invention is an IP packet multicast method for performing multicast communication from an external IP network to a plurality of lowest-level nodes via a plurality of stages of nodes forming a hierarchical structure. Then, the first step of sequentially transmitting the participation request to the multicast group from the lowest node to the upper node following the hierarchical structure, and the upper node in which the participation request is not a new participation request. The second step of adding the information of the lowest node to the multicast group at the upper node and the multicast to which the information of the lowest node is added when transmitted to the user. It is characterized by including a third step of delivering a multicast packet from the highest-level node to the lowest-level node for the group.

【0024】

According to the present invention, each node manages only the lower-level note to be multicast, instead of managing the lowest-level note to be multicast one by one. Therefore, it is possible to reduce the amount of information managed by the GGSN or the like and obtain an IP packet multicast method that does not overwhelm the transmission capacity of the network.

【0025】

BEST MODE FOR CARRYING OUT THE INVENTION

Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. First, the first embodiment will be described. The configuration of the IMT-2000 packet system in which the present invention is executed is the same as that of the above-mentioned conventional example (see FIG. 1). That is, referring to FIG. 1, this packet system is a mobile station MS1-1 to 1-3 that intends to participate in multicast, a radio station Nod B2-1 to 2-8, and a radio base station. At the gateway station between RNC3-1 ~ 3-4, SGSN4-1 and 4-2, which temporarily retains subscriber contract information and controls mobile device authentication processing and subordinate devices, and ISP7. A GGSN5, HLR / AuC6 for fixedly holding subscriber contract information, grasping the location of mobile stations, and calculating data required for authentication processing, and ISP7, which is an external IP network. It consists of.

【0026】

In the present invention, mobile stations MS1, node B2, RNC3, SGSN4 and GGSN5 are referred to as "network nodes" or simply "nodes". These network nodes already have the ability to achieve one-to-one packet communication rather than multicast. Since the method of realizing one-to-one packet communication is the same as that of the above-mentioned conventional example, the description thereof will be omitted.

【0027】

Next, the operation (participation in the multicast group) of the first embodiment will be described. In the present invention, it is not necessary to form tunneling from the MS to the GGSN in advance before performing multicast communication as in the conventional case (see FIG. 5). FIG. 2 is a float showing the operation of participating in the multicast group of the first embodiment.

【0028】

With reference to the figure, first, the MS1 wishing to join the multicast group sends a multicast join request to RNC3 together with the information identifying the multicast group to join (S31). Upon receiving this participation request, RNC3 checks for the requested multicast group whether there is a lower network already registered, in this case MS1 (S32), and if a new participation occurs. If it is a request (YES in S32), send a multicast join request to the upper network, in this case SGSN4 (S33). Then, the same procedure is performed between RNC3 and SGSN4 and between SGSN4 and GGSN5 (S34).

【0029】

As a result, each network device including MS1 participating in the multicast group in the lower level has a PDP (Packet Data Protocol) context for each multicast group (S36), and the lower level to be distributed. Memorize the throat.

【0030】

On the other hand, if the multicast join request is not a new request (NO in S32), only the process of adding the information of the corresponding lower node to the PDP context held for each multicast group (S37). I do.

【0031】

Then, when the GGSN5 receives the data to be multicasted, the GGSN5 refers to the PDP context of the corresponding multicast group and sends the multicast packet only to the registered SGSN4. By performing the same procedure as SGSN4 and RNC3, multicast packets can be delivered to all MS1s participating in the multicast group.

【0032】

There is no one-to-one relationship between SGSN4 and its superior GGSN5, and N-to-M (N and M are positive integers) can be connected. Therefore, a means is needed to determine the GGSN5 to which the multicast join request should be sent. Therefore, in order to identify the GGSN5 to which the SGSN4 sends the participation request, the GGSN5 that manages the relevant multicast group using DNS (Domain Name Server System) based on the information that identifies the multicast group. Get an IP address.

【0033】

Next, the operation (release from the multicast group) of the first embodiment will be described. First, before going into the explanation, I will briefly explain the meaning of "disengagement from the multicast group". After receiving the multicast information, each MS1 issues a cancellation request to the upper network to end the reception. Then, when a release request comes to the upper network from all the MSs in the multicast group (that is, when the last release request comes), the upper network is the multicast group. To delete. On the other hand, if the release request comes from only some MSs (that is, when the last release request has not come), the MS that made the release request is deleted from the multicast group.

【0034】

FIG. 3 is a float showing the operation of releasing from the multicast group of the first embodiment. Referring to the figure, first, MS1 sends a multicast cancellation request to RNC3 together with information identifying the multicast group to be canceled (S51). The RNC3 that received this multicast release request checks whether it is the last release request for the requested multicast group (S52), and if it is the last release request (yes in S52), it is higher. Network, in this case sending a multicast cancellation request to SGSN4 (S53).

【0035】

Then, the network device that received the last release request, in this case RNC3, deletes the PDP context held for each multicast group (S57). Then, the same procedure is performed between RNC3 and SGSN4 and between SGSN4 and GGSN5 (S54).

【0036】

On the other hand, if the multicast release request is not the last release request, each node deletes the information of the corresponding lower node from the PDP context managed for each multicast group (S55).

【0037】

[Example]

Next, examples of the present invention will be described. First, the first embodiment will be described. The first embodiment is about participation in a multicast group. FIG. 4 is a schematic explanatory view of the first embodiment. The same components as those in FIG. 1 are assigned the same number, and the description thereof will be omitted.

【0038】

In this embodiment, the multicast group 1 consisting of MS1, MS2 and MS3 and the multicast group 2 consisting of MS4 and MS5 are registered in the PDP context of RNC3-1, and the PDP of RNC3-2. It is assumed that the multicast group 3 consisting of MS6, MS7 and MS8 is registered in the context.

【0039】

As an example, a case where MS9 not registered in these multicast groups 1 to 3 wishes to participate in the multicast group 3 and a case where the MS9 wishes to participate in the multicast group 1 will be described. Refer to Fig. 2 for the explanation.

【0040】

First, a case where MS9 wishes to participate in Multicast Group 3 will be described. The MS9 wishing to join the multicast group sends a multicast join request to RNC3-1 along with information identifying the multicast group it wants to join (S31). Upon receiving this participation request, RNC3-1 checks whether the requested multicast group 3 is registered in its own PDP context (S32). Since multicast group 3 is not registered in RNC3-1 (YES in S32), a multicast participation request is sent to the upper network, in this case SGSN4-1 (S33).

【0041】

The SGSN4-1 that received this multicast join request checks whether or not RNC3 in which the multicast group 3 is registered exists under the information that is received at the same time and identifies the multicast group that the multicast group wants to join. However, since there is no RNC3 other than RNC3-1 under SGSN4-1 (YES in S34-1), a multicast participation request is sent to GGSN5 (S34-2).

【0042】

The GGSN5 that receives this multicast join request checks whether SGSN4 in which the multicast group 3 is registered exists under the information that is received at the same time and identifies the multicast group that the multicast group wants to join. Then, since RNC3-2 in which multicast group 3 is registered exists in SGSN4-2 under it (NO in S34-3), GGSN5 adds SGSN4-2 information to its own PDP context (NO). S34-4). Then, GGSN5 sends a multicast registration response to SGSN4-2 (S34-5).

【0043】

Upon receiving this multicast registration response, SGSN4-2 adds RNC3-2 information to its PDP context (S34-6, S34-7). SGSN4-2 then sends a multicast registration response to RNC3-2 (S35).

【0044】

Upon receiving this multicast registration response, RNC3-2 adds MS9 to the multicast group 3 registered in its own PDP context (S36, S37). Then, RNC3-2 sends a multicast registration response to MS-9 (S38).

【0045】

Next, a case where MS9 wishes to participate in multicast group 1 will be described. The MS9 wishing to join the multicast group sends a multicast join request to RNC3-1 along with information identifying the multicast group it wants to join (S31). Upon receiving this participation request, RNC3-1 checks whether the requested multicast group 3 is registered in its own PDP context (S32). Then, since multicast group 1 is registered in RNC3-1 (NO in S32), MS9 is added to multicast group 1 registered in its own PDP context (S37). Then, RNC3-2 sends a multicast registration response to MS-9 (S38).

【0046】

Next, the second embodiment will be described. In the second embodiment, a class D IP address is used as information for identifying the multicast group. IP addresses are divided into class A, class B, class C, etc. according to the Internet standard. These three are the addresses used for general communication. Class D addresses are defined by the Internet standard as "multicast addresses" and are already in use in the pure Internet world. A host terminal (eg, MS) that connects to the Internet sends an assertion of participation to the corresponding class D address in order to participate in a particular multicast group, and subsequent packets addressed to that address are sent. When it is sent, it captures the packet into its own terminal.

【0047】

Next, a third embodiment will be described. In the third embodiment, APN (Access Point Name) is used as information for identifying the multicast group. APN is an access point name defined in the 3GPP standard. That is, the APN is information for identifying the external network to which the mobile device wants to connect in normal transmission, and takes the form of a domain name such as OOOO.ne.jp.

【0048】

Next, the fourth embodiment will be described. The fourth embodiment is a means for determining whether or not the RNC3 receives the multicast cancellation request from the MS1 and is the last cancellation request. RNC3 instructs the multicast group that requested the cancellation to send the multicast participation request again. The multicast packet for the multicast group is used for this instruction. Then, if the multicast group participation request from MS1 cannot be received within a certain period of time, RNC3 determines that MS1 participating in the multicast group no longer exists. From this, it can be seen that the release request from MS1 is the last release request.

【0049】

Next, the fifth embodiment will be described. In the fourth embodiment, RNC3 instructed MS1 to send the multicast participation request again every time the multicast cancellation request from MS1 came, but in the fifth embodiment, whether or not the multicast cancellation request from MS1 comes. Regardless, RNC3 instructs MS1 to send the multicast join request again at regular intervals.

【0050】

[Effect of the invention]

According to the present invention, it is an IP packet multicast method that performs multicast communication from an external IP network to a plurality of lowest-level nodes via a plurality of stages of nodes forming a hierarchical structure, and is the lowest-level. The first step of sequentially transmitting the participation request to the multicast group from the throat to the upper throat following the hierarchical structure, and the participation request being transmitted to the upper throat which is not a new participation request. In this case, for the second step of adding the information of the lowest node to the multicast group at the upper node and the multicast group to which the information of the lowest node is added. IP packet multicast that reduces the amount of information managed by GGSN etc. and does not overwhelm the transmission capacity of the network because it includes the third step of delivering the multicast packet from the highest node to the lowest node. It becomes possible to obtain a method.

【0051】

Specifically, the first effect is that the amount of call control information to be managed by RNC, SGSN, and GGSN can be suppressed. The reason is that the GGSN does not manage the mobile devices to be multicast one by one according to the present invention, but only the lower nodes to be multicast (SGSN for GGSN, RNC for SGSN, MS for RNC). This is because it is managed by the computer.

【0052】

The second effect is that the amount of traffic between RNC, SGSN, and GGSN can be suppressed. The reason is that according to the present invention, only one multicast packet having the same content is sent to the same node.

[Simple explanation of drawings]

[Figure 1]

It is a block diagram of an example of an IMT-2000 packet system.

[Figure 2]

It is a float which shows the operation of participation in the multicast group of the first embodiment.

[Fig. 3]

It is a float which shows the operation of the release from the multicast group of the first embodiment.

[Fig. 4]

It is a schematic explanatory drawing of the 1st Example.

[Fig. 5]

This is a float that shows the call connection procedure in the IMT-2000 packet system.

[Explanation of symbols]

1 Mobile station (MS) 2 throat B 3 RNC 4 SGSN 5 GGSN 6 HLR / AuC 7 ISP