Multicast content distribution system, multicast content distribution method, and relay server

Abstract

To provide a multicast content distribution system capable of reducing an amount of packet communication in a multicast content distribution based on network coding.SOLUTION: A relay server 2 of a multicast content distribution system is reported by a requesting node of the number of request packets, a transmission capacity with the requesting node, and a total transmission capacity with nodes from which the requesting node can collect encoded packets, and includes a request packet number calculation unit 22 that calculates, as a new number of request packets, a maximum value among minimum numbers of request packets for each requesting node obtained by multiplying the reported number of request packets by a value obtained by increasing a ratio of the transmission capacity with the requesting node to the total transmission capacity by a predetermined premium rate.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to a multicast content distribution system, a multicast content distribution method, and a relay server. [Background technology]

[0002] Conventionally, multicast content distribution, which simultaneously delivers the same content to multiple client terminals, has been carried out on the Internet based on a packet store-and-forward method, in which packets are received, a route to the destination is determined one by one in the order in which they arrive, and the packets are then forwarded (routed) to the next relay server. However, it is known that this store-and-forward method cannot realize the maximum capacity in multicast communication.In response to this, it is known that the throughput on the network can be improved by using so-called network coding, a method in which multiple packets collected at a relay server are combined and converted (encoded) into another packet before being forwarded (Non-Patent Document 1). In particular, Non-Patent Document 2 shows that the maximum capacity of multicast communication can be achieved by linear network coding, which converts multiple packets by linear combination calculations. In addition, Non-Patent Documents 3 and 4 show that resistance to network configuration changes and failures can be improved by randomly setting the coefficients of the linear combinations in linear network coding. Patent Document 1 and Non-Patent Document 5 propose a multicast content distribution system that uses linear network coding to efficiently utilize network resources.

[0003] On the other hand, these documents do not mention the encryption of data communications to prevent the leakage of content information.Currently, on the Internet, data communications can be encrypted using standard encryption tools at the transport layer, and this is called Transport Layer Security (TLS). In multicast content delivery systems, confidentiality can be improved by encrypting packets using TLS. However, there is a possibility that current TLS can be decrypted by advanced computers such as quantum computers.

[0004] In recent years, it has become possible to guarantee security (information-theoretic security) that cannot be decrypted by any computer by encrypting packets using a method called One Time Pad (OTP) with an encryption key provided from a quantum key distribution (QKD) network (Non-Patent Document 6). [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2006-31693 A [Non-patent literature]

[0006] [Non-Patent Document 1] R. Ahlswede, N. Cai, SR Li, and RW Yeung, “Network information flow,” IEEE Trans. Inf. Theory, vol. 46, no. 5, pp. 1204-1216, Jul. 2000. [Non-Patent Document 2] S.-YR Li, RW Yeung, and N. Cai, “Linear network coding,” IEEE Trans. Inf. Theory, vol. 49, no. 2, pp. 371-381, Feb. 2003. [Non-Patent Document 3] PA Chou, Y. Wu, K. Jain, “Practical Network Coding” in Allerton Conference on Communication, Control, and Computing, Monticello, II, 2003. [Non-Patent Document 4] T. Ho, M. Me´dard, R. Koetter, D. Karger, M. Effros, J. Shi, and B. Leong, “A random linear network coding approach to multicast,” IEEE Trans. Inf. Theory, vol. 52, pp. 4413-4430, Oct. 2006. [Non-Patent Document 5] C. Gkantsidis, PR Rodoriguez, “Network Coding for Large Scale Content Distribution,” IEEE Infocom 2005. [Non-Patent Document 6] Mikio Fujiwara, Masahide Sasaki, "3 Quantum Optical Network Technology 3-1 Current Status of Research and Development of Quantum Key Distribution Networks", National Institute of Information and Communications Technology Research Report, Vol. 63, No. 1, 2017, pp. 9-18 Summary of the Invention [Problem to be solved by the invention]

[0007] In conventional OTP methods, once an encryption key has been used, it cannot be reused, so as the volume of packets exchanged increases, the consumption of encryption keys also increases. On the other hand, when a QKD network is used for multicast content distribution, there is a performance limit to the key generation speed, so as the volume of packet communication increases, there is a problem that encryption keys are depleted. Therefore, an object of the present invention is to provide a multicast content distribution system, a multicast content distribution method, and a relay server that are capable of reducing the amount of packet communication in multicast content distribution. [Means for solving the problem]

[0008] In order to solve the above-mentioned problems, the multicast content distribution system according to the present invention is a multicast content distribution system which includes a distribution server, a plurality of relay servers, and a plurality of client terminals as nodes connected by transmission links, and distributes content as encoded packets obtained by encoding the content using a random linear network coding scheme from the distribution server to the client terminals via the relay servers, and notifies the request destination node of a predetermined number of request packets, a transmission capacity between the request destination node and the node capable of collecting the encoded packets, and notifies the client terminal which collects and restores the encoded packets of the number of request packets, the transmission capacity between the request destination node and the node capable of collecting the encoded packets, and the relay server is notified of a total transmission capacity, calculates a new number of request packets as the maximum value among the minimum numbers of request packets for each requesting node, calculated by multiplying the notified number of request packets by a value obtained by multiplying a ratio of the transmission capacity between the requesting node and the requesting node to the total transmission capacity by a predetermined premium rate, notifies the requesting node of the new number of request packets, the transmission capacity between the requesting node and the total transmission capacity between nodes that can collect the encoded packets, collects the encoded packets, encodes them using a random linear network coding scheme, and relays them to the requesting node, and the distribution server distributes encoded packets obtained by encoding the content using the random linear network coding scheme in accordance with the number of request packets notified from the requesting node.

[0009] According to this configuration, the multicast content distribution system calculates the number of request packets that the node is responsible for in accordance with the transmission capacity of the other nodes, rather than directly requesting the number of request packets from the content requester from the relay server to the requested node. This reduces the number of request packets from the relay server, and reduces the amount of packet communication.

[0010] In order to solve the above-mentioned problems, a multicast content distribution method according to the present invention is a method in which a distribution server, a plurality of relay servers, and a plurality of client terminals are connected as nodes by transmission links, and the method distributes content as encoded packets obtained by encoding the content using a random linear network coding scheme to the client terminals via the relay servers from the distribution server, the encoded packets being distributed to the client terminals, the encoded packets being distributed to the client terminals via the relay servers, the client terminals notifying the request destination node of a predetermined number of request packets, a transmission capacity between the request destination node and the request destination node, and a total transmission capacity between the request destination node and a node capable of collecting the encoded packets, and the relay server notifies the request destination node of the number of request packets, the transmission capacity between the request destination node and the request destination node, and a total transmission capacity between the request destination node and a node capable of collecting the encoded packets from the request source node. The source node is notified of the total transmission capacity between itself and the nodes capable of collecting the encoded packets, calculates a new number of request packets as the maximum value among the minimum numbers of request packets for each request source node, multiplying the notified number of request packets by a value obtained by multiplying the ratio of the transmission capacity between itself and the request source node to the total transmission capacity increased by a predetermined premium rate, and notifies the requested node of the new number of request packets, the transmission capacity between itself and the requested node, and the total transmission capacity between itself and the nodes capable of collecting the encoded packets, and the distribution server distributes encoded packets obtained by encoding the content using a random linear network coding scheme in accordance with the number of request packets notified from the request source node.

[0011] According to this procedure, in the multicast content distribution method, the relay server does not directly request the number of request packets from the content requester to the requested node, but calculates the number of request packets that the node is responsible for depending on the transmission capacity of the other nodes. This reduces the number of request packets from the relay server, and reduces the amount of packet communication.

[0012] In order to solve the above-mentioned problems, a relay server according to the present invention is a relay server in a multicast content distribution system in which a distribution server, a plurality of relay servers, and a plurality of client terminals are connected as nodes by transmission links, and the relay server distributes content to the client terminals by relaying the content from the distribution server to the client terminals, the relay server being notified by a request source node of the number of request packets, a transmission capacity between the request source node and the request source node, and a total transmission capacity between the request source node and a node from which the request source node can collect the encoded packets, and a ratio of the transmission capacity between the request source node and the request source node to the total transmission capacity. the number of request packets is calculated as a new number of request packets by multiplying the notified number of request packets by a value obtained by multiplying the notified number of request packets by a predetermined surcharge rate; a packet collection unit that notifies the requested node of the new number of request packets, the transmission capacity between the requested node and the node capable of collecting the encoded packets, and collects the encoded packets; an encoding unit that encodes the collected encoded packets by a random linear network coding scheme; and a packet distribution unit that distributes the encoded packets encoded by the encoding unit to the requesting node.

[0013] According to this configuration, the relay server does not directly request the number of request packets from the content requester to the request destination node, but calculates the number of request packets that the node is responsible for depending on the transmission capacity of the other nodes. This reduces the number of request packets from the relay server, and reduces the amount of packet communication. Effect of the Invention

[0014] According to the present invention, it is possible to reduce the amount of communication of packets to be transferred in a multicast content distribution system. As a result, the present invention can reduce consumption of encryption keys, for example, even when encrypting packets with one-time pad encryption keys provided between nodes by quantum key distribution. [Brief description of the drawings]

[0015] [Figure 1] 1 is a network configuration diagram showing an example of a multicast content distribution system according to an embodiment of the present invention. [Diagram 2] 2 is a block diagram showing an example of the configuration of the distribution server of FIG. 1; [Figure 3A] 3 is an explanatory diagram for explaining division of content in the division unit of FIG. 2; FIG. [Figure 3B] FIG. 13 is a diagram showing the data structure of a message string after division. [Figure 4] 3 is an explanatory diagram for explaining encoding of a message sequence in the encoding unit of FIG. 2; FIG. [Diagram 5] 2 is a block diagram showing a configuration example of a relay server of FIG. 1. [Figure 6A] FIG. 6 is an explanatory diagram (part 1) for explaining linear network coding in the coding unit of FIG. 5. [Figure 6B] FIG. 6 is an explanatory diagram (part 2) for explaining linear network coding in the coding unit of FIG. 5 . [Figure 7] 2 is a block diagram showing a configuration example of a client terminal of FIG. 1; [Figure 8] 8 is an explanatory diagram for explaining restoration of encoded packets in a packet restoration unit in FIG. 7; [Figure 9A]FIG. 11 is an explanatory diagram for explaining a delivery standby operation of the multicast content delivery system. [Figure 9B] FIG. 2 is an explanatory diagram for explaining a distribution preparation operation of a multicast content distribution system. [Figure 9C] FIG. 2 is an explanatory diagram for explaining the operation of delivery execution in the multicast content delivery system; [Figure 9D] FIG. 11 is an explanatory diagram for explaining a distribution completion operation of the multicast content distribution system. [Figure 10A] FIG. 9D is an explanatory diagram for explaining the operation of step 1 in the delivery execution of FIG. 9C. [Figure 10B] FIG. 9D is an explanatory diagram for explaining the operations of step 2 and step 3 in the delivery execution of FIG. 9C. [Figure 11] FIG. 1 is a network configuration diagram of a multicast content distribution system for explaining a method of calculating the number of request packets. [Figure 12] 13 is a flowchart showing the flow of an operation for calculating the number of request packets. [Figure 13] FIG. 1 is a network configuration diagram of a multicast content distribution system for explaining an application example of content distribution across domains. [Figure 14] 11 is an explanatory diagram for explaining a method of controlling so that a linearly dependent encoded packet is not transferred to an external domain. FIG. [Figure 15] 1 is a network configuration diagram illustrating an example of a multicast content distribution system according to an embodiment. [Figure 16] 13 is a chart showing the values ​​of the number of request packets at each node (distribution server, relay server, client terminal) when the surcharge rate is changed. [Figure 17] 13 is a chart showing the probability of successful restoration of a client terminal when the surcharge rate is changed. [Figure 18] A chart showing the reduction rate of the number of request packets and the OTP encryption key at each node when the surcharge rate is changed is shown. [Figure 19]11 is a table showing the reduction rate of the time required for a client terminal to download content according to the present invention and the conventional method. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] Hereinafter, a multicast content distribution system according to an embodiment of the present invention will be described with reference to the drawings.

[0017] [Configuration of multicast content distribution system] The configuration of a multicast content distribution system 100 will be described with reference to Fig. 1. Fig. 1 shows an example of the configuration of a multicast content distribution system. The multicast content distribution system 100 distributes the same content to a plurality of client terminals simultaneously. The multicast content distribution system 100 is a system based on a store-and-forward method, and is configured with the following nodes: a distribution node s (distribution server 1), multiple relay nodes v (relay server 2), and multiple client nodes c (client terminals 3), all connected by transmission links. In the multicast content distribution system 100, each node generates encoded packets using random linear network coding and transmits and receives the packets between the nodes, thereby distributing the content from the distribution node s to the client node c via the relay node v.

[0018] Here, it is assumed that the multicast content distribution system 100 is configured with subnetworks of domain A and domain B, as an example. The sub-network of domain A is made up of a relay server 2 (relay nodes v1, v2, v3) and a client terminal 3 (client nodes c1, c2, c3). The subnetwork of domain B is composed of relay servers 2 (relay nodes v4 and v5) and client terminals 3 (client nodes c4, c5, and c6). Note that client terminals 3 (client nodes c1, c2, and c3) of domain A also function as relay servers to domain B.

[0019] The distribution server 1 is a source node that distributes content. The distribution server 1 divides the content, encodes the content using random linear network coding, and distributes the resulting encoded packets according to the number of request packets notified by the request source node.

[0020] The relay server 2 relays the content. The relay server 2 calculates its own new number of request packets based on the requested number of request packets and information on the capacity of the transmission link with the connected node (connection information), collects the encoded packets, and relays them to the requested other relay server 2 or client terminal 3. Note that the connection information includes the transmission capacity with the requesting node and the total transmission capacity with the nodes from which the requesting node can collect the encoded packets.

[0021] The client terminal 3 collects the encoded packets and restores the content. The client terminal 3 notifies the requested node of a predetermined number of request packets, the transmission capacity between the requested node and the node capable of collecting the encoded packets, and collects and restores the encoded packets. Some of the client terminals 3 have a function of a relay server. For example, the client nodes c1, c2, and c3 relay content between domains. It is assumed that the encoded packets that are sequentially relayed are encrypted between nodes using a Vernam cipher with a one-time pad encryption key (hereinafter, OTP encryption key).

[0022] The configuration of the multicast content distribution system 100 will now be described in detail.

[0023] [Distribution server] The configuration of the distribution server 1 (distribution node s) will be described with reference to FIG. 2 (and also with reference to FIG. 1 as necessary). The distribution server 1 includes a distribution request processing unit 10, a content preparation unit 11, a storage unit 12, a transfer request receiving unit 13, a packet distribution unit 14, and an encryption unit 15.

[0024] The distribution request processing unit 10 receives a content distribution request from the relay server 2 and prepares for the content distribution. The source of the delivery request is the client terminal 3, and the delivery request processing unit 10 responds to the requested relay server 2. This response is notified to the client terminal 3 that is the source of the delivery request via one or more relay servers 2. Upon receiving the distribution request, the distribution request processing unit 10 instructs the content preparation unit 11 to prepare for content distribution. When the distribution request processing unit 10 is notified by the content preparation unit 11 that the content preparation is complete, the distribution request processing unit 10 notifies the relay server 2 that notified the distribution request of the completion of the preparation.

[0025] The content preparation section 11 prepares data for distributing the requested content as packets. The content preparation unit 11 includes a division unit 110 and an encoding unit 111 . The division unit 110 divides the content requested by the distribution request processing unit 10 into packets for distribution (message sequence). The division unit 110 outputs the divided message sequence to the encoding unit 111 .

[0026] An example of content division in division section 110 will now be described with reference to FIGS. 3A and 3B. The division unit 110 divides the content into predetermined information units (message sequences) that are collectively processed by the client terminal 3. Here, the message sequence is generally expressed as a sequence whose symbols are elements of a finite field. In the commonly used example of the finite field GF(q), the order q=2 8 = 256 field, whose elements are digital signals with a length of 1 byte. A message string, which is an information unit, is called a generation, and here, as a typical example, one generation of data is composed of ω pieces of data, each of which is 1400 bytes, as shown in Figure 3A. Here, the number of pieces of data that make up a message string, ω, is called the generation size.

[0027] FIG. 3A shows an example in which content is divided into three generations (generation 1, generation 2, and generation 3) with a generation size of ω=6. FIG. 3B shows a vector representation of a message sequence with a certain length z (here, 1400 bytes), a generation size ω, i as the generation number (i=1 to 3), and j as the index within the generation (j=1 to ω). (si) j,k is GF(2 8 ) is 1 byte of data, which is the symbol above. In this way, each message sequence is identified by the attribute information (i, j). In the description of this embodiment, the data for one generation is targeted, and the message sequence is expressed as a vector s j It is assumed that the above expression is expressed as follows:

[0028]

number

[0029] Returning to FIG. 2, the configuration of the distribution server 1 will be described. The encoding unit 111 encodes the message sequence divided by the division unit 110 . The encoding unit 111 performs encoding on the message sequence using a random linear network coding scheme. Random linear network coding is a coding method that linearly combines message sequences using random coefficients to convert them into another sequence. The input and output sequences are called codewords. In the following, the sequence before coding (message sequence) is called the input codeword, and the sequence after coding is called the output codeword.

[0030] The encoding unit 111 generates an encoded packet by pairing an output codeword obtained by linearly combining message sequences using a random number coefficient with the random number coefficient used to generate the output codeword. Here, the encoding in the encoding unit 111 will be described with reference to Fig. 4. Here, the encoding unit 111 receives, as input codewords, a sequence of mutually linearly independent messages (vector s j ) shall be entered. The encoding unit 111 receives an input codeword (vector s j ) corresponding to ω random coefficients r j (j=1~ω).

[0031] The encoding unit 111 encodes the vector s j The input codeword x in For the random coefficient r j By linearly combining the following equation (2) using j′ (s) Let x be the output codeword. out Generate it as:

[0032]

number

number

[0033] In equations (2) and (3), j' indicates the index of the output codeword. However, in distribution node s, index j and index j' are the same. Also, (s) simply indicates that the output codeword is generated in distribution node s.

[0034] Furthermore, the encoding unit 111 encodes the ω random coefficients r j (j=1~ω) is the vector g′ of the following equation (4): j′ (s) (global encoding vector g out ) where g′ j′,z =r j (j′=j=1~ω).

[0035]

number

[0036] The encoding unit 111 encodes the vector x′ generated by the formula (3). j′ (s) (output codeword x out ) and the vector g′ generated in Eq. (4) j′ (s) (global encoding vector g out ) and generate an encoded packet p′ consisting of a pair p′. That is, the encoding unit 111 converts an encoded packet p′, which is a pair of an output codeword and a global encoded vector corresponding to the output codeword, into an encoded packet X′ j′ (s) Generate it as:

[0037]

number

[0038] The encoding unit 111 generates the encoded packet X' j′ (s) is stored in the storage unit 12 in association with the attribute information. Returning to FIG. 2, the configuration of the distribution server 1 will be further explained.

[0039] Upon completing encoding of the requested content, content preparation section 11 notifies distribution request processing section 10 that the content preparation is complete. The storage unit 12 stores the content encoded by the content preparation unit 11, and is a general storage medium such as a semiconductor memory.

[0040] The transfer request receiving unit 13 receives a transfer request for a message sequence of content from the connected relay server 2 . The transfer request includes at least the number of request packets, which is the number of message sequences, and attribute information (i, j) regarding the message sequences already held by the relay server 2. The transfer request receiving unit 13 randomly selects message sequences equal to the number of request packets from among the message sequences not yet held by the requesting relay server 2, and instructs the packet distributor 14 to distribute them.

[0041] The packet delivery unit 14 delivers the message sequence designated by the transfer request reception unit 13 as an encoded packet to the relay server 2 that has made the request. The packet distribution unit 14 reads out the encoded packet stored in the memory unit 12 corresponding to the attribute information as the message string instructed by the transfer request receiving unit 13, encrypts it using the encryption unit 15, and then transmits the encrypted encoded packet to the requested relay server 2. Needless to say, header information such as data length is added to the encoded packet to be transmitted.

[0042] The encryption unit 15 encrypts the encoded packet distributed by the packet distribution unit 14. Here, the encryption unit 15 shares an encryption key (OTP encryption key) with the relay server 2 that has requested the encoded packet by quantum key distribution, and performs encryption by the Vernam cipher. Note that quantum key distribution is an existing technology, and an apparatus for performing quantum key distribution is not shown in the figure. With the above-described configuration, the distribution server 1 can encode the content requested by the relay server 2 using the random linear network coding scheme and distribute the encoded content.

[0043] [Relay Server] Next, the configuration of the relay server 2 (relay node v) will be described with reference to FIG. 5 (and also with reference to FIG. 1 as necessary). The relay server 2 includes a distribution request processing unit 20, a forwarding request receiving unit 21, a request packet number calculation unit 22, a packet collection unit 23, a decryption unit 24, an encoding unit 25, a memory unit 26, a packet distribution unit 27, and an encryption unit 28.

[0044] The distribution request processing unit 20 receives a content distribution request from the client terminal 3 or another relay server 2, and prepares the content for distribution. When the distribution request processing unit 20 receives a content distribution request, it sends a response to the client terminal 3 or another relay server 2 that requested the distribution request, and also sends the distribution request to the connected distribution server 1 or another relay server 2 that is the source of the content distribution. Furthermore, when the delivery request processing unit 20 receives a notification indicating that the delivery preparation of the content has been completed, the delivery request processing unit 20 transmits a notification indicating that the preparation has been completed to the client terminal 3 or relay server 2 that has requested the delivery request. This completes the preparation for the relay server 2 to distribute the content.

[0045] The transfer request receiving unit 21 receives a transfer request for a message sequence (encoded packets) of content from another connected relay server 2 or client terminal 3 (hereinafter, referred to as another node). This transfer request includes at least the number of request packets, which is the number of requested message sequences (encoded packets), attribute information about the message sequences already held by the other requesting node, and information (connection information) about the connection status (availability, transmission capacity) between the other requesting node and adjacent nodes. The transfer request receiving unit 21 outputs the received transfer request to the request packet number calculating unit 22 and the packet delivering unit 27 .

[0046] The request packet number calculation unit 22 calculates the number of request packets that the relay server 2 requests from the content distributor based on the number of request pads included in the transfer request and the connection status of other nodes of the request source. Here, the request packet number calculation unit 22 multiplies the number of request packets by the ratio (proportion) of the transmission capacity between the relay server 2 and the other requesting node to the total transmission capacity between the other requesting node and its adjacent nodes, and further multiplies it by a predetermined surcharge rate to calculate the minimum number of request packets that the relay server 2 will be responsible for. The request packet number calculation unit 22 calculates the minimum number of request packets for each node when transfer requests are made from a plurality of nodes.

[0047] Then, the request packet number calculation unit 22 determines the maximum value of the calculated plurality of minimum numbers of request packets as the number of request packets that the relay server 2 includes in the transfer request. Since encoded packets are collected from multiple nodes, the number of packets to be transferred can be reduced by calculating the number of request packets according to the transmission capacity. Also, by increasing the number of request packets calculated according to the transmission capacity using a surcharge rate, the probability of successful restoration of content in the client terminal 3 can be increased. Note that there is a trade-off between reducing the number of packets according to the transmission capacity and increasing the probability of successful restoration using the surcharge rate, so it is preferable to set an appropriate surcharge rate through simulation for the network configuration. The method for calculating the number of request packets will be described in detail later. The request packet number calculation unit 22 outputs the calculated number of request packets to the packet collection unit 23 .

[0048] The packet collection unit 23 requests encoded packets (message sequences) of the number of request packets calculated by the request packet number calculation unit 22 from the connected distribution server 1 or another relay server 2, and collects the encoded packets. The packet collection unit 23 transmits a transfer request including the number of request packets, attribute information on the message sequences already held, and information (connection information) on the connection status (availability, transmission capacity) between the relay server 2 and adjacent nodes of the relay server 2, to the connected distribution server 1 or another relay server 2 that relays the content. The packet collection unit 23 outputs the collected encoded packets to the descrambling unit 24 .

[0049] The decryption unit 24 decrypts the encrypted encoded packets collected by the packet collection unit 23 . Here, the decryption unit 24 shares an encryption key (OTP encryption key) with the node that is the transfer source of the encoded packet by quantum key distribution, and decrypts the Vernam cipher. Note that quantum key distribution is an existing technology, and an apparatus for performing quantum key distribution is not shown in the figure. The descrambling unit 24 outputs the descrambled encoded packet to the encoding unit 25 .

[0050] The encoding unit 25 encodes the encoded packets (message sequence) collected by the packet collection unit 23 and decrypted by the decryption unit 24 into a new sequence using a random linear network coding scheme. The encoding unit 25 linearly combines the encoded packets, which are the collected input codewords, using random coefficients, and converts them into output codewords of a different sequence. Furthermore, the encoding unit 25 generates an encoded packet by pairing an output codeword with the random number coefficient used to generate the output codeword.

[0051] 6A and 6B, the encoding in the encoding unit 25 will be described. As shown in FIG. 6A, the relay server 2 is a node v, and the node v outputs ω(=6) linearly independent output code words x′ from nodes v′, v″, and v′′. out and the global coding vector g′ out Let us collect an encoded packet p′ containing Then, the encoding unit 25 outputs the output codeword x′ as shown in FIG.out The index j is reassigned to the new input codeword x in (vector x j (v) )

[0052]

number

[0053] The encoding unit 25 encodes the input codeword x in (vector x j (v) ) corresponding to ω random coefficients r j (j=1~ω). The encoding unit 25 encodes the input codeword x in For the random coefficient r j Using the above, we perform a linear combination of the following equation (7) to obtain the new vector x′ in equation (8). j (v) Let x be the output codeword. out Generate it as:

[0054]

number

number

[0055] In equations (7) and (8), j represents the index of the output codeword. Furthermore, the encoding unit 25 generates a global encoding vector g′ as shown in FIG. out The index j is reassigned to the new global coding vector g in (vector g j (v) )

[0056]

number

[0057] The encoding unit 25 encodes the global encoding vector g in For the same random coefficient r used in Eq. (7), j Using the above, we perform a linear combination of the following equation (10) to obtain the new vector g′ in equation (11). j (v) Let g be the global encoding vector. out Generate it as:

[0058]

number

number

[0059] The encoding unit 25 encodes the vector x′ generated by the formula (8) j (v) (output codeword x out ) and the vector g′ generated in Eq. (11) j (v) (global encoding vector g out ) and generate an encoded packet p consisting of a pair. That is, the encoding unit 25 converts an encoded packet p, which is a pair of an output codeword and a corresponding global encoded vector, into an encoded packet X′ j (v) Generate it as:

[0060]

number

[0061] The encoding unit 25 generates the encoded packet X' j (v) is stored in the storage unit 26 in association with the attribute information. Returning to FIG. 5, the description of the configuration of the relay server 2 will be continued. The storage unit 26 stores the encoded packets that have been decrypted by the decryption unit 24 and encoded by the encoding unit 25, and is a general storage medium such as a semiconductor memory.

[0062] The packet distributor 27 distributes the message string designated by the transfer request receiver 21 as an encoded packet to another node that has requested it. The packet distribution unit 27 reads out the encoded packets stored in the memory unit 26, with the number of request packets being the maximum number among the message strings not yet held by other nodes based on the attribute information, encrypts them using the encryption unit 28, and then transmits the encrypted encoded packets to the other nodes that have requested them. Needless to say, header information such as data length is added to the encoded packet to be transmitted.

[0063] The encryption unit 28 encrypts the encoded packet distributed by the packet distribution unit 27. Here, the encryption unit 28 shares an encryption key (OTP encryption key) with other nodes that have requested the encoded packet by quantum key distribution, and performs encryption by the Vernam cipher.

[0064] With the above-described configuration, the relay server 2 can encode the content requested by other nodes using random linear network coding and distribute the encoded content. In addition, the relay server 2 adjusts the number of request packets sent to the content requester according to the transmission capacity between nodes, thereby reducing the amount of packets transferred between nodes. This allows the relay server 2 to reduce consumption of the OTP encryption key used for encryption.

[0065] [Client terminal] Next, the configuration of the client terminal 3 (client node c) will be described with reference to FIG. 7 (and also with reference to FIG. 1 as appropriate). The client terminal 3 includes a distribution request unit 30, a packet collection unit 31, a descrambling unit 32, a storage unit 33, and a packet restoration unit .

[0066] The distribution request unit 30 transmits a distribution request to the connected relay server 2 in response to a content request from an external source. If no response is received within a predetermined time after transmitting the delivery request, the delivery request unit 30 transmits the delivery request to another relay server 2. By receiving the response, the distribution request unit 30 recognizes that the distribution server 1, which is the source of the content distribution, is in operation. Furthermore, after receiving the response, the distribution request unit 30 receives a notification of completion of preparation, thereby recognizing that preparation of the distribution server 1 is complete, and instructs the packet collection unit 31 to start a content transfer request.

[0067] The packet collection unit 31 requests a predetermined number of requested packets of encoded packets (message sequences) from the connected relay server 2 at a predetermined transfer request interval, and collects the encoded packets. This transfer request includes the number of requested packets, attribute information on the encoded packets (message sequences) already held, and information (connection information) on the connection status (availability, transmission capacity). Here, the packet collection unit 31 requests and receives encoded packets for each generation. When the packet collection unit 31 is instructed by the packet restoration unit 34 about an encoded packet that is not yet held, the packet collection unit 31 transmits a transfer request to the connected relay server 2 . The packet collection unit 31 outputs the collected encoded packets to the descrambling unit 32 .

[0068] The decryption unit 32 decrypts the encrypted encoded packets collected by the packet collection unit 31 . Here, the decryption unit 32 shares an encryption key (OTP encryption key) with the node that is the transfer source of the encoded packet by quantum key distribution, and decrypts the Vernam cipher. The descrambling unit 32 stores the descrambled encoded packet in the storage unit 33 . The storage unit 33 stores the encoded packets decrypted by the decryption unit 32, and is a general storage medium such as a semiconductor memory.

[0069] The packet restoration unit 34 restores the encoded packets stored in the storage unit 33 to content data. The packet restoration unit 34 restores the data of one generation's worth of content stored in the storage unit 33 by restoration processing using the random linear network coding method. If the packet recovery unit 34 fails to recover the data, the packet collection unit 31 deletes the encoded packet from the storage unit 33, and instructs the packet collection unit 31 to collect the packet.

[0070] Here, the restoration technique of the packet restoration unit 34 will be described with reference to FIG. Here, it is assumed that the packet recovery unit 34 performs recovery from an encoded packet p that is made up of ω (=6) input codewords that are linearly independent of one another and a global encoded vector. The packet recovery unit 34 recovers the global coding vector (vector g j (v) ) and the input codeword (vector x j (v) ) and the message sequence (vector s j ) can be solved by the simultaneous equations shown in the following equation (13).

[0071]

number

[0072] With the above-described configuration, the client terminal 3 can restore the random linear network coded content transferred from the distribution server 1 via the relay server 2. In addition, when the client terminal 3 is configured to have the functions of the relay server 2, the client terminal 3 may be configured by adding the transfer request receiving unit 21, the request packet number calculation unit 22, the encoding unit 25, the packet distribution unit 27 and the encryption unit 28 described in FIG. 5.

[0073] [Operation of multicast content distribution system] Next, the operation of the multicast content distribution system 100 will be described with reference to FIGS. 9A to 9D (and also with reference to FIGS. 1, 2, 5, and 7 as appropriate). The operation flow of the multicast content distribution system 100 consists of four stages: (1) distribution standby, (2) distribution preparation, (3) distribution execution, and (4) distribution completion.

[0074] (1) Waiting for delivery As shown in FIG. 9A, in the distribution waiting stage, a client node c (c4 in this case) that wants to acquire content transmits a distribution request to a connected relay node v (v4 in this case) by means of a distribution request unit 30. Then, the relay node v4 receives the delivery request through the delivery request processing unit 20, transmits the delivery request to a connected peripheral node (here, the client node c1 having the function of a relay server), and responds to the requesting client node c4. If there is no response within a predetermined time, the requesting node transmits the delivery request to another connected node (here, the relay node v5).

[0075] In this manner, by repeating a distribution request and a response, the distribution request reliably reaches distribution node s, which is the source of the content. The distribution node s receives the distribution request and responds to the requesting node by the distribution request processing unit 10. At this time, the distribution node s does not need to know the requesting node of the initial distribution request.

[0076] (2) Distribution preparation As shown in FIG. 9B, in the distribution preparation stage, after the distribution node s, which is the source of the content distribution, responds to the distribution request, the dividing section 110 of the content preparation section 11 divides the content into predetermined information units (message sequences), and generates a set (generation) of data by aggregating the message sequences into predetermined numbers (see FIG. 3A). The distribution node s encodes the divided message sequence using a random linear network coding method by the encoding unit 111 of the content preparation unit 11, and registers (stores) the encoded message sequence in the memory unit 12 in association with attribute information (i, j) consisting of an index i that identifies the message sequence and an index j that identifies the generation. After the distribution node s registers the content as generation data using the content preparation unit 11, it sends a notification (preparation complete) to the relay node v (here, v1) to which the content requested for distribution is to be transferred, indicating that preparation for accepting the request is complete. The relay node v and the client node c having the function of a relay server receive the notification of preparation completion by the distribution request processing unit 20, and sequentially transmit the requested content to the node to which it is to be transferred.

[0077] In this way, by repeatedly receiving and transmitting the preliminary part completion notification, the client node c (c4 in this case) which is the requester of the content receives a preliminary part completion notification from the distribution request unit 30. This allows the client node c to confirm that the content is ready for distribution.

[0078] (3) Execution of distribution As shown in FIG. 9C, in the delivery execution stage, each node (client node c, relay node v) transmits a transfer request for an encoded packet in which a message string is encoded to an adjacent node. The node that receives the transfer request executes the following three steps (step 1, step 2, step 3) to distribute the encoded packet from distribution node s to client node c that sent the transfer request.

[0079] [Step 1] In step 1, the number of encoded packets (number of request packets) collected by the own node is calculated. Note that, since the number of request packets of client node c is equal to the number of generation sizes, client node c does not calculate the number of request packets in step 1. In the relay node v, the request packet number calculation unit 22 calculates the number of request packets based on the number of request packets and the connection information in the request source node. A node that receives a transfer request notifies the source node of the encoded packet of the transfer request, which includes the number of request packets of its own and information (connection information) regarding the connection status with adjacent nodes (availability, transmission capacity).

[0080] Here, the operation of step 1 will be described in a more generalized manner with reference to Fig. 10A. In Fig. 10A, relay nodes and client nodes are not distinguished from each other, and are represented as nodes u, u', v, v', v'', w, w', and w'' on the network. Node v receives a transfer request (request packet count R (u) ) and the connection information, the number of request packets R (v) The method for calculating the number of request packets will be described later. Node v sends a request to multiple adjacent nodes w, w', and w'' (number of request packets R (v) ) and its own connection information, and requests the transfer of the encoded packet (S1 in FIG. 10A). The node that receives the request, for example, node w, receives the number of request packets R, which is the number of encoded packets that the node w should collect. (w) The same is done for the requested nodes w' and w''. That is, node v functions as a node that receives a transfer request from node u, and also functions as a node that sends a transfer request to nodes w, w', and w''. In this way, each node calculates the number of request packets in an autonomous and distributed manner.

[0081] [Step 2] In step 2, the node that receives the forwarding request encodes the unforwarded encoded packets that it has collected using the random linear network encoding scheme in the encoding unit 25, encrypts them using the OTP encryption key, and transmits them to the requester of the forwarding request.

[0082] [Step 3] In step 3, the node that has received the encrypted encoded packet decrypts the packet using descrambling unit 24 and holds the encrypted packet. Here, the operations of steps 2 and 3 will be described in a more generalized manner with reference to Fig. 10B. In Fig. 10B, like Fig. 10A, relay nodes and client nodes are not distinguished, and are represented as nodes u, u', v, v', v'', w, w', w'' on the network.

[0083] Node w, which received a transfer request from node v in S1 of FIG. 10A, counts the number of collected packets P (w) and the number of packets already transferred P (w→v) Compare with. And P (w) >P (w→v) In this case, node w sends to node v, the source of the forwarding request, a codeword (vector x′ j (w) ) and the associated global coding vector (vector g′ j (w) ) and the encoded packet X j (w) to node v (S2 in FIG. 10B). In addition, P (w) ≦P (w→v) In this case, node w informs node v that it does not have any packets to forward.

[0084]

number

[0085] When forwarding, node w sends the encoded packet X j (w) is encrypted using the OTP encryption key. Node v decrypts the OTP and checks whether the set of the encoded packet transferred from node w and the encoded packet it already holds are linearly independent. If they are not linearly independent, node v discards the transferred encoded packet. On the other hand, if they are linearly independent, node v holds the transferred encoded packet (S3 in FIG. 10B). This held encoded packet waits for transfer to the next node. Here, node v has the number of collected encoded packets P (w) is the number of request packets R (w) Verify that this is the case. P (w) R (w) If it is less than, node v repeats the forwarding request to the surrounding nodes w, w', and w''. Similar to nodes w and v, the same processes (S2', S3') as step 2 (S2) and step 3 (S3) are repeated for nodes v and u.

[0086] In this way, the transfer of encoded packets is repeated sequentially according to the value of the number of request packets calculated in step 1, so that client node c collects one generation's worth of encoded packets necessary to restore the content.

[0087] (4) Delivery complete 9D, the client node c restores one generation's worth of content data from the collected encoded packets using the packet restoration unit 34. The client node c restores the entire content by performing restoration for all generations. That is, the client node c receives the encoded packet X j (v) After decrypting the OTP, we collect the linearly independent input codewords (vector x j(v) ) and the associated global coding vector (vector g j (v) ) and the output codeword (vector x′ j (c) ) and the associated global coding vector (vector g′ j (c) ) (j=1 to 6) and restore it. As a result, client node c receives w (=6) message sequences (vector s j )(j=1~6) are restored. If the restoration fails, (3) the delivery execution step is repeated. Through the above operations, the client node c can restore the content data for all generations and obtain the content.

[0088] [Calculation method for the number of request packets] Next, with reference to Figures 11 and 12, a method will be described in which the relay node v (relay server 2) or the client node c (client terminal 3) having the function of a relay server calculates the number of request packets in the request packet number calculation unit 22.

[0089] FIG. 11 shows a network in an example configuration of a multicast content distribution system 100, in which the transmission capacity of the transmission links shown by thick lines between nodes is 40 (no unit), and the transmission capacity of the transmission links shown by thin lines between nodes is 1 (no unit). FIG. 12 shows the flow of operations for calculating the number of request packets. The request packet number calculation unit 22 calculates the number of request packets by executing three procedures (procedure 1, procedure 2, and procedure 3) described below.

[0090] (Step 1) A client node or a relay node notifies a neighboring relay node connected thereto of the number of request packets and connection information by means of a transfer request (S100, S101). Here, an example will be described in which the relay node v1 is notified of the number of request packets and connection information as a transfer request from client nodes ci (i=1, 2, 3) in a predetermined time period. The client node ci sends a transfer request to the neighboring relay nodes v1, v2, v3, v4, and v5 connected thereto.

[0091] The transfer request is made by the request packet count R (c1) In addition, it contains information about packets already held by the client node c1 and connection information. Number of request packets R (c1) is the target number of the total number of encoded packets to be collected. In the following, the client node c1 has no collected packets and requires a generation size of ω (=6) encoded packets for decoding. (c1) For example, let us assume that =ω(=6). If there is a generation that has already been collected, that generation is also notified by the transfer request, so that the encoded packets of the generation that have already been collected are not transferred again.

[0092] The connection information includes the capacity (transmission capacity) of the transmission link between the requesting node and the requested node, and the sum (total transmission capacity) of the capacities of the transmission links between the requesting node and the surrounding nodes. In the example of Fig. 11, client node c1, which is a requesting node, is individually connected to relay nodes v1, v2, and v3 by transmission links each having a transmission capacity of 40. Client node c1 is also individually connected to relay nodes v4 and v5 by transmission links each having a transmission capacity of 1. It is assumed that these transmission links are currently available. In this case, the total transmission capacity of the transmission links between the requesting node (client node c1) and the surrounding nodes (v1, v2, v3, v4, v5) is 122 (=40×3+1×2).

[0093] (Step 2) The relay node that has been notified of the transfer request and the connection information calculates the number of request packets that should be collected from each request source node. Here, the relay node v1 will be described as an example. It is assumed that the relay node v1 has been notified of the number of request packets and connection information from client nodes ci (i=1, 2, 3) in a predetermined time period.

[0094] The relay node v1 calculates, for each client node ci (i=1, 2, 3), the ratio (transmission capacity ratio) of the total transmission capacity (total inbound capacity) of the transmission links of the client node ci to the transmission capacity of the transmission link between the relay node v1 and the client node ci (S102), and calculates the minimum number of request packets R min(v1←ci) (S103). Note that if a decimal value occurs in formula (15), the calculation is rounded up.

[0095]

number

[0096] Furthermore, the relay node v1 has the minimum number of request packets R calculated by Equation (15). min(v1←ci) By multiplying the minimum number of request packets by a preset rate as shown in the following formula (16), the number of request packets R (v1←ci) If a decimal point occurs in formula (16), the calculation shall be rounded up.

[0097]

number

[0098] It is not necessary to calculate the formulas (15) and (16) individually, but they may be calculated at once as in the following formula (17).

[0099]

number

[0100] As a result, the relay node v1 receives the request packets R (v1←c1) ,R (v1←c2) ,R (v1←c3) Calculate. In the example of FIG. 11, for example, if the premium rate is set to 1.3, then according to formula (15), R min(v1←ci) = 6 × (40 / 122) = 1.98 (rounded up to 2), and by formula (16), R (v1←ci) =2×1.3=2.6 (rounded up to 3). Similarly to the relay node v1, the relay nodes v2 and v3 also collect the number of request packets R (v2←c1) ,R (v2←c2) ,R (v2←c3) , R (v3←c1) ,R (v3←c2) ,R (v3←c3) Calculate.

[0101] (Step 3) The relay node that has been notified of the number of request packets and the connection information determines, as a request source node, the number of request packets to be notified to the requested node. The relay node determines the maximum number of request packets calculated for each request source in step 2 as the number of request packets that it will notify the requested node. Here, the relay node v1 collects the number of request packets R (v1←ci) , R to be collected for client node c2 (v2←ci) , R to be collected for client node c3 (v3←ci) Max(R (v1←ci) ,R (v2←ci) ,R (v3←ci) )) is the number of request packets R (v1) Select as. In the example of Figure 11, client nodes c1, c2, and c3 are equivalent, so R(v1) =3.

[0102] Here, the reason for introducing the surcharge rate in equation (16) in step 2 is as follows. The client node c1 sets the target number of the total number of encoded packets to be collected as R (c1) However, for client node c1 to successfully restore the content, R (c1) The codewords (vector x j ) must be linearly independent of each other. On the other hand, relay nodes v1, v2, and v3 receive the request packets R (v1) ,R (v2) ,R (v3) The client node c1 will then transfer the encoded packets, with the upper limit set to R, to the client node c1. (c1) Even if we collect all the codewords (vector x j ) are not necessarily linearly independent of each other. Therefore, by setting a premium rate greater than 1, the client node c1 can (c1) codewords (vector x j ) can be increased.

[0103] The larger the premium rate, the better from the viewpoint of improving the probability of successful recovery (improving linear independence), but the smaller the premium rate, the better in order to reduce consumption of the OTP encryption key (reducing the total number of times encoded packets are transferred). The probability of successful recovery also depends on the generation size (ω) and the transmission capacity. Therefore, the value of the premium rate may be set to a value that reaches a preset target value by estimating the probability of successful restoration through simulation or the like. In this way, the relay node v1 does not use a fixed value for the number of request packets, but uses a value that is reset based on the number of request packets from the request source node and the connection information. Therefore, even when the state changes over time, for example when a failure occurs, the multicast content distribution system 100 can deal with the situation flexibly in an autonomous and distributed manner.

[0104] [Example of content distribution across domains] Next, with reference to FIG. 13, an application example of content distribution across domains in the multicast content distribution system 100 will be described. Specifically, in the multicast content distribution system 100, when client nodes c4, c5, and c6 belonging to domain B request distribution of content data via relay nodes v4 and v5, how step 1 (S1) of (3) distribution execution described in FIG. 10A proceeds will be described.

[0105] First, the client node c1 sends the request packet count R (c1) The neighboring relay nodes are notified that there are six relay nodes v1, v2, and v3, and that, as connection information, inputs from relay nodes v1, v2, and v3 can be accepted by transmission links with a transmission capacity of 40, and inputs from relay nodes v4 and v5 can be accepted by transmission links with a transmission capacity of 1 (S11).

[0106] The relay node v1 collects the number of request packets R (v1←c1) is calculated as 3 by rounding up the formula (17) (S12). (v1←c2) ,R (v1←c3) There are also three.

[0107] The client node c4 receives the request packet count R (c4) The relay nodes v4 and v5 are notified of the number of inputs, which is six, and that, as connection information, inputs from the relay nodes v4 and v5 can be accepted by transmission links with a transmission capacity of 40 (S13).

[0108] The relay node v4 collects the number of request packets R (v4←c4) is calculated as 4 by rounding up the formula (17) (S14). (v4←c5) ,R (v4←c6) There are also four. The relay node v4 receives the request packet count R (v4←c4) ,R (v4←c5) ,R (v4←c6) Max(R (v4←c4) ,R (v4←c5) ,R (v4←c6) )) are the number of request packets of relay node v4, R (v4) (S15). The relay node v4 receives the number of request packets R (v4) The neighboring client nodes and relay nodes are notified that the number of nodes c1, c2, and c3 is four, and that the connection information indicates that inputs from the client nodes c1, c2, and c3 and the relay node v1 can be accepted by a transmission link with a transmission capacity of 1 (S16).

[0109] The relay node v1 collects the number of request packets R (v1←v4) is calculated as 2 by rounding up the formula (17) (S17). The relay node v1 receives the request packet count R (v1←c1) ,R (v1←c2) ,R (v1←c3) ,R (v1←v4) Max(R (v1←c1) ,R (v1←c2) ,R (v1←c3) ,R (v1←v4) )) are the number of request packets of relay node v1, R (v1) (S18).

[0110] Then, the relay node v1 (similarly to v2 and v3) repeats a transfer request to the distribution node s until collection of three linearly independent encoded packets is completed. In accordance with step 2 (S2) of (3) distribution execution described in FIG. 10B, distribution node s randomly linear network codes the encoded packets it holds and forwards them to each of relay nodes v1, v2, and v3 (S19). In this manner, a transfer request is sent across domains, and the encoded packets are transferred.

[0111] [Method for controlling transmission of linearly dependent coded packets to an external domain] Next, with reference to FIG. 14, a method of controlling the multicast content distribution system 100 so that linearly-dependent encoded packets are not transferred to an external domain will be described. Since the client nodes c1, c2, and c3 in domain A are closer to the distribution node s than the client nodes c4, c5, and c6 in domain B, the content data can be restored more quickly. Once the content data can be decrypted, the client nodes c1, c2, and c3 of domain A can then act as distribution nodes for domain A. Therefore, the client in domain A controls the total number of encoded packets to be transferred to each relay node in domain B so that it is equal to or less than the total number of linearly independent encoded packets that it possesses.

[0112] 14 shows an example of distribution of content data consisting of generations with a generation size of ω=10. Here, it is assumed that a client node c1 in domain A holds 10 linearly independent encoded packets. In this case, the client node c1 distributes and transfers the 10 encoded packets it holds to the relay nodes v4 and v5 without duplication. For example, the client node c1 transfers 6 packets to the relay node v4 and 4 packets to the relay node v5. As a result, client nodes c4, c5, and c6 in domain B can reliably collect 10 linearly independent encoded packets from relay nodes v4 and v5.

[0113] More generally, when a source node forwards encoded packets to an external domain, the source node controls the forwarding so as not to forward a total number of packets to a group of nodes belonging to the external domain that exceeds the number of linearly independent encoded packets held by the source node. This allows the multicast content distribution system 100 to reduce the number of times encoded packets are transferred.

[0114] [Evaluation of the Examples] The evaluation results for the examples of the present invention will be described with reference to FIGS. The multicast content distribution system 100 shown in FIG. 15 is a network made up of transmission links (thick lines) with a transmission capacity of 800 Mbits / sec and transmission links (thin lines) with a transmission capacity of 10 kbits / sec.

[0115] In the multicast content delivery system 100, transmission links are established from a delivery node (delivery server) s to three relay nodes (relay servers) v1, v2, and v3 in domain A. Mesh-shaped transmission links are established from these relay nodes to three client nodes (client terminals) c1, c2, and c3. Mesh-shaped transmission links are also established from the client nodes belonging to domain A to relay nodes v4 and v5 in domain B. Mesh-shaped transmission links are also established from the relay nodes v4 and v5 in domain B to client nodes c4, c5, and c6 in domain B. In addition, thick transmission links are also established from the relay nodes v1 and v3 in domain A to the relay nodes v4 and v5 in domain B, respectively. Only thin transmission links are connected to the client node c3. On the other hand, the relay node v2 is not connected to the relay node belonging to domain B. When data is transferred using these transmission links, packets (encoded packets) are encrypted by using the same amount of OTP encryption keys. The direction of the arrow indicates the direction in which the packets are transferred. When there are arrows on both sides, it is assumed that bidirectional transfer is possible. Here, it is assumed that each node cannot receive packet transfers from multiple nodes at the same time.

[0116] In this embodiment, the generation size ω is set to 100, and the effect of the present invention is illustrated by a statistical evaluation based on a large number of content distribution trials. The total number of transfers and distribution time are evaluated by randomly changing the coefficients of the random linear combinations at each node for each trial.

[0117] FIG. 16 is a chart showing the values ​​of the number of request packets at each node (distribution node, relay node, client node) calculated according to the basic procedure according to the present invention. Each client node requests encoded packets of a generation size ω=100, but the number of encoded packets actually received from the relay node generally exceeds the requested number. This is because the relay node forwards more encoded packets than necessary to ensure that the client node can reliably collect linearly independent codewords for the generation size (ω=100) as close to 100% as possible. To achieve this, the relay node multiplies the minimum number of encoded packets it needs to collect (collection multiplier 1) by a surcharge rate of 1 or more to calculate the number of encoded packets it should collect, i.e., the number of request packets. FIG. 16 shows the calculated numbers of request packets for four different surcharge rates.

[0118] Below is an example of calculating the number of request packets when the surcharge rate is Domain A: 2.1 and Domain B: 1.4. In relay node v4, R (v4←c1) is calculated by rounding up the number of request packets of client node c1 × transmission capacity / total transmission capacity × premium rate = 100 × 800 / 4000 × 1.4, (v4←c1) =28. R (v4←c2) is calculated by rounding up the number of request packets of client node c2 × transmission capacity / total transmission capacity × premium rate = 100 × 800 / 4000 × 1.4, (v4←c2) =28. R(v4←c3) is calculated by rounding up the number of request packets of client node c3 × transmission capacity / total transmission capacity × premium rate = 100 × 0.01 / 0.05 × 1.4, (v4←c3) =28. R (v4←c4) is calculated by rounding up the number of request packets of client node c4 × transmission capacity / total transmission capacity × premium rate = 100 × 800 / 1600 × 1.4, (v4←c4) =70. R (v4←c5) is calculated by rounding up the number of request packets of client node c5 × transmission capacity / total transmission capacity × premium rate = 100 × 800 / 1600 × 1.4, (v4←c5) =70. R (v4←c6) is calculated by rounding up the number of request packets of client node c6 × transmission capacity / total transmission capacity × premium rate = 100 × 800 / 1600 × 1.4, (v4←c6) =70.

[0119] In addition, the relay node v4 does not make a forwarding request to the client nodes c4, c5, and c6 in its own domain B, so the number of request packets R (v4) The number of request packets from client nodes c4, c5, and c6 is not used in the calculation. From the above maximum values, the number of request packets of the relay node v4, R (v4) = 70. Similarly, the relay node v5 also (v5) =70.

[0120] In the relay node v1, R (v1←c1) is calculated by rounding up the number of request packets of client node c1 × transmission capacity / total transmission capacity × premium rate = 100 × 800 / 4000 × 2.1, (v1←c1) =42. R (v1←c2) is calculated by rounding up the number of request packets of client node c2 × transmission capacity / total transmission capacity × premium rate = 100 × 800 / 4000 × 2.1, (v1←c2) =42. R(v1←c3) is calculated by rounding up the number of request packets of client node c3 × transmission capacity / total transmission capacity × premium rate = 100 × 0.01 / 0.05 × 2.1, (v1←c3) =42. R (v1←v4) is calculated by rounding up the number of request packets of relay node v4 × transmission capacity / total transmission capacity × premium rate = 70 × 800 / 2400.01 × 2.1, (v1←v4) =49. From the above maximum values, the number of request packets of relay node v1 is R (v1) = 49. Similarly, the relay node v3 also (v3) =49.

[0121] In relay node v2, R (v2←c1) is calculated by rounding up the number of request packets of client node c1 × transmission capacity / total transmission capacity × premium rate = 100 × 800 / 4000 × 2.1, (v2←c1) =42. R (v2←c2) is calculated by rounding up the number of request packets of client node c2 × transmission capacity / total transmission capacity × premium rate = 100 × 800 / 4000 × 2.1, (v2←c2) =42. R (v2←c3) is calculated by rounding up the number of request packets of client node c3 × transmission capacity / total transmission capacity × premium rate = 100 × 0.01 / 0.05 × 2.1, (v2←c3) =42. From the above maximum values, the number of request packets of relay node v2, R (v2) =42.

[0122] The optimal premium rate may be determined by a trade-off between the probability of successful recovery at the client node and the effect of reducing the number of times the encoded packets are transferred, that is, the effect of reducing the consumption of the OTP encryption key. FIG. 17 shows the results of evaluating the relationship between the premium rate and the probability of successful restoration at each of the client nodes c1, c2, c3, c4, c5, and c6. The evaluation results are based on 50 trials, in which the coefficients of the random linear combinations were randomly varied.

[0123] As shown in Figure 17, when the premium rate is 1.66 in domain A and 1.0 in domain B, the probability of successful restoration for client nodes belonging to domain B is only 82.7%, which is not large. However, by simply increasing the premium rate to 1.81 in domain A and 1.1 in domain B, the average probability of successful restoration for all client nodes can be 98.7%, which is close to 99%. Furthermore, if the premium rate is increased to 2.0 in domain A and 1.2 in domain B, the probability of successful restoration in domain B can be increased to 100.0%.

[0124] FIG. 18 shows the reduction rate of the number of request packets and the OTP encryption key at each node in the case of different surcharge rates. Here, the generation size is ω=100, and the content data amount is 1.4 MByte (number of generations: 10).

[0125] The reduction rate represents the ratio of the amount of OTP encryption keys consumed in a multicast content distribution system of the conventional method to the amount of OTP encryption keys consumed in the multicast content distribution system of the present invention. The conventional method does not perform the random linear network coding and optimization of the number of request packets of the present invention. In addition, in the conventional method, each relay node collects encoded packets of the generation size (ω=100) in the same way as the client node so that the encoded packets are distributed evenly. Therefore, the total number of transfers of encoded packets (total consumption of OTP encryption keys) is 100×11 nodes=1100. The numbers for each node in the table indicate the number of request packets.

[0126] For example, if the premium rate is 1.66 for domain A and 1.0 for domain B, the total number of request packets is 802, and the reduction rate is a large value of 27.1%. In that case, as shown in Fig. 17, some client nodes will have a lower probability of successful recovery. On the other hand, if the premium rate is set to 2.1 in domain A and 1.4 in domain B, the probability of successful decryption is 99.3% (FIG. 17), but the reduction rate drops to 20.0%. The optimal value is considered to be the premium rate of 2.0 for domain A and 1.2 for domain B, resulting in a reduction rate of 23.6% and an overall probability of successful restoration of 100% (Figure 17). As described above, since the optimal premium rate depends greatly on the network configuration, it is desirable to set the optimal premium rate in advance by simulation.

[0127] FIG. 19 shows the reduction rate of the time required for a client node to download content between the present invention and the conventional method. In Fig. 19, the request interval is the time interval between transfer requests between nodes. Note that the generation size is ω=100, the content data amount is 140 kBytes, and the premium rate is 2.1 for domain A and 1.4 for domain B. As shown in Fig. 19, in the present invention, the number of times encoded packets are transferred is reduced, and as a result, the time required to complete delivery is reduced. In the assumed network configuration, a reduction rate of 4.8% is achieved when the request interval for transfer requests is 200 msec. The reduction effect by application is remarkable in client nodes c4, c5, and c6 in domain B. [Explanation of symbols]

[0128] 100 Multicast Content Distribution System 1. Distribution server (distribution node) 10. Delivery request processing section 11 Content Preparation Department 110 Split section 111 Encoding section 12 Storage section 13 Transfer request reception unit 14 Packet Delivery Unit 15 Encryption section 2 Relay server (relay node) 20 Delivery request processing unit 21 Transfer request reception unit 22 Request packet count calculation unit 23 Packet Collection Unit 24 Decryption Unit 25 Encoding section 26 Memory section 27 Packet Distribution Unit 28 Encryption section 3 Client terminal (client node) 30 Delivery request section 31 Packet Collection Unit 32 Decryption section 33 Storage section 34 Packet recovery section

Claims

1. A multicast content distribution system in which a distribution server, a plurality of relay servers, and a plurality of client terminals are connected as nodes by a transmission link, and content is encoded by a random linear network coding method into encoded packets, and the encoded packets are distributed from the distribution server to the client terminals via the relay servers, the client terminal notifying the requested node of a predetermined number of request packets, a transmission capacity between the requested node and the client terminal, and a total transmission capacity between the requested node and a node capable of collecting the encoded packets, and collecting and restoring the encoded packets; The request source node notifies the number of request packets, a transmission capacity between the request source node and the node, and a total transmission capacity between the request source node and a node capable of collecting the encoded packets; calculating, as a new number of request packets, a maximum value among the minimum numbers of request packets for each request source node, which is obtained by multiplying a ratio of a transmission capacity between the request source node and the request source node to the total transmission capacity by a predetermined premium rate and the notified number of request packets; notifying the requested node of the new number of request packets, a transmission capacity between the requested node and the node capable of collecting the encoded packets, and a total transmission capacity between the requested node and the node; the relay server that collects the encoded packets, encodes them using a random linear network coding scheme, and relays them to a requesting node; the distribution server that distributes encoded packets obtained by encoding the content using a random linear network coding scheme according to the number of request packets notified from a request source node; A multicast content distribution system comprising:

2. The multicast content distribution system according to claim 1, characterized in that, when relaying the encoded packets to a group of nodes in an external domain, the relay server distributes the encoded packets in an order without duplication so that the total number of encoded packets to be distributed to the group of nodes does not exceed the number of encoded packets that the relay server holds.

3. A multicast content distribution system according to claim 1 or 2, characterized in that, between nodes relaying the encoded packets, each node encrypts the encoded packets using a Vernam cipher with a one-time pad encryption key.

4. A multicast content distribution method in which a distribution server, a plurality of relay servers, and a plurality of client terminals are connected as nodes by a transmission link, and content is encoded by a random linear network coding scheme into encoded packets, and the encoded packets are distributed from the distribution server to the client terminals via the relay servers, the method comprising: The client terminal includes: notifying the requested node of a predetermined number of request packets, a transmission capacity between the requested node and the node capable of collecting the encoded packets, and a total transmission capacity between the requested node and the node; The relay server includes: The request source node notifies the number of request packets, a transmission capacity between the request source node and the node, and a total transmission capacity between the request source node and a node capable of collecting the encoded packets; calculating, as a new number of request packets, a maximum value among the minimum numbers of request packets for each request source node, which is obtained by multiplying a ratio of a transmission capacity between the request source node and the request source node to the total transmission capacity by a predetermined premium rate and the notified number of request packets; notifying the requested node of the new number of request packets, a transmission capacity between the requested node and the node capable of collecting the encoded packets, and a total transmission capacity between the requested node and the node; The distribution server includes: The content is encoded by a random linear network coding method, and the encoded packets are distributed according to the number of request packets notified from the request source node. A multicast content distribution method comprising:

5. A multicast content distribution system in which a distribution server, a plurality of relay servers, and a plurality of client terminals are connected as nodes by a transmission link, and content is encoded by a random linear network coding scheme into encoded packets, and the encoded packets are distributed from the distribution server to the client terminals via the relay servers, the relay server comprising: a request packet number calculation unit which is notified by the request source node of the number of request packets, a transmission capacity between the request source node and the request source node, and a total transmission capacity between the request source node and nodes capable of collecting the encoded packets, and which calculates as a new number of request packets a maximum value among the minimum numbers of request packets for each request source node, which is obtained by multiplying a ratio of a transmission capacity between the request source node and the total transmission capacity by a predetermined premium rate and the notified number of request packets; a packet collection unit that notifies the requested node of the new number of request packets, a transmission capacity between the requested node and the node capable of collecting the encoded packets, and collects the encoded packets; An encoding unit that encodes the collected encoded packets using a random linear network coding scheme; a packet distribution unit that distributes the encoded packet encoded by the encoding unit to a request source node; A relay server comprising:

Images