JP2021087036A - Receiver, distribution system, and program - Google Patents

Abstract

To suppress amounts of redundant packets and reduce a load on a re-transmission server, in multicast distribution using FEC.SOLUTION: A receiver 10 comprises: a packet analysis unit 13 for detecting lost packets; a recovery propriety determination unit 14 for determining whether or not the number of the lost packets p is equal to or smaller than a recoverable number E; a lost packet recovery unit 15 for recovering recoverable lost packets when p≤E; a packet request information generation unit 21 for generating packet request information when p>E; a packet request information transmission unit 22 for transmitting the packet request information to another receiver in a P2P group; and a request packet reception unit 20 for receiving a request packer from the other receiver. When p≤E is not established after receiving the request packet and the receiver 10 is a representative receiver, a minimal number of packets establishing p≤E of lost packets having not been acquired are acquired from a re-transmission server 40 and are transmitted according to a request from another receiver in the P2P group.SELECTED DRAWING: Figure 3

Description

The present invention relates to a receiving device, a distribution system, and a program.

In distribution using IP (Internet Protocol) multicast, the sender only sends the data once, and the communication device on the route duplicates and transmits the data only to the route where the receiver is, so in large-scale one-to-many distribution. It is generally known to be efficient.

In IP multicast distribution, UDP (User Datagram Protocol) is used as an upper layer protocol, so packet arrival and arrival order are not guaranteed. Therefore, in order to perform reliable distribution, it is necessary to implement error correction, retransmission control, etc. independently at the application layer.

In general, error correction (FEC: Forward Error Correction) that corrects errors that occur in the transmission line on the receiving side and automatic repeat control (ARQ: Automatic Repeat Request) that detects errors and retransmits incorrect data are used. , It is known that high-quality data distribution can be realized (see, for example, Non-Patent Document 1).

Shuji Kubota, "4 groups (mobile / wireless) -1 volume (basic wireless communication) Chapter 5 Application of error correction technology", [online], November 9, 2010, [Search November 20, 2019], Internet <URL: http://www.ieice-hbkb.org/files/04/04gun_01hen_05.pdf>

In delivery using FEC, it is necessary to additionally deliver redundant packets (inspection packets) for recovering lost packets (packet loss). Increasing the amount of redundant packets leads to a decrease in delivery efficiency, and conversely, decreasing the amount of redundant packets makes it impossible to recover lost packets. Therefore, it is necessary to add an appropriate amount of redundant packets according to the communication path. Bandwidth of open networks such as the Internet fluctuates according to the usage rate, but in order to realize high-quality distribution, it is necessary to cope with the temporary increase in packet loss. Therefore, it is necessary to set the amount of redundant packets according to the case where the packet loss rate in the communication path is maximized. Therefore, in the period when the packet loss rate is not maximized, useless redundant packets are delivered, and the delivery efficiency is lowered. Further, in the reliable multicast using ARQ, only the lost packet is retransmitted, so that there is no useless distribution, but a load corresponding to the number of terminals is applied to the retransmitted server.

An object of the present invention made in view of such circumstances is to provide a receiving device, a distribution system, and a program capable of suppressing the amount of redundant packets and reducing the load on the retransmission server in multicast distribution using FEC. To do.

The receiving device according to one embodiment is a receiving device that receives a multicast stream and complements lost packets by P2P (Peer to Peer) communication, and includes a packet analysis unit that detects lost packets when receiving the multicast stream. A recoverability determination unit that determines whether or not the number of lost packets is equal to or less than the maximum number of lost packets that can be recovered by FEC, and a recoverable loss packet when the number of lost packets is equal to or less than the maximum value. A loss packet recovery unit that recovers the packet by FEC, a packet request information generation unit that generates packet request information indicating a lost packet when the number of lost packets is larger than the maximum value, and the packet request information in the P2P group. A packet request information transmitting unit for transmitting to another receiving device and a request packet receiving unit for receiving a request packet which is a packet included in the loss packet indicated by the packet request information from the other receiving device are provided. When the number of lost packets does not fall below the maximum value after receiving the request packet and the receiving device is a representative receiving device representing the P2P group, among the unacquired lost packets, the said The minimum number of packets whose number of lost packets is equal to or less than the maximum value is acquired from the retransmission server, and the acquired lost packets are transmitted at the request of other receiving devices in the P2P group.

Further, in one embodiment, the receiving device recovers by FEC in the packet request information receiving unit that receives the packet request information from another receiving device and the loss packet indicated by the packet request information in the other receiving device. A request packet transmission unit that transmits only the minimum number of packets required for the above to the other receiving device may be provided.

Further, in one embodiment, the request packet transmission unit satisfies the minimum number of lost packets indicated by the packet request information that can be recovered by the FEC in the other receiving device. If not, all of the retained packets among the lost packets indicated by the packet request information may be transmitted to the other receiving device.

Further, in one embodiment, the packet request information transmitting unit transmits the packet request information using a WebRTC (Web Real-Time Communication) data channel, and the request packet receiving unit is a WebRTC data channel. May be used to receive the request packet.

Further, the distribution system according to the embodiment is a distribution system including the receiving device and a server that transmits the multicast stream to the receiving device, and a P2P group is generated by the plurality of receiving devices, and the P2P group is generated. The server transmits the data packet to all the receiving devices in the P2P group, divides the redundant packet generated by the same code word into the number of receiving devices in the P2P group, and divides the divided redundant packet into the number of receiving devices. It is transmitted to each of the receiving devices in the P2P group.

Further, the program according to the embodiment causes the computer to function as the receiving device.

According to the present invention, even when the packet loss rate is high in data distribution that requires high reliability, the amount of redundant packets is suppressed in order to ensure reliability by complementation between receiving devices or complementation by a retransmission server. Is possible. Further, by recovering the lost packet that cannot be recovered by FEC by complementing between the receiving devices, it is possible to reduce the load on the retransmission server.

It is a figure which shows the outline of the distribution system which concerns on one Embodiment. It is a figure which shows the structure of the FEC block which concerns on one Embodiment. It is a block diagram which shows the structural example of the receiving apparatus which concerns on one Embodiment. It is a figure explaining the complementation of the loss packet in the distribution system which concerns on one Embodiment. It is a flowchart which shows the processing procedure about the packet reception in the receiving apparatus which concerns on one Embodiment. It is a flowchart which shows the processing procedure about the packet transmission in the receiving apparatus which concerns on one Embodiment.

Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

FIG. 1 is a diagram showing an outline of a distribution system according to an embodiment. The distribution system 1 shown in FIG. 1 includes a distribution server 30, a retransmission server 40, a group generation server 50, and a plurality of receiving devices 10. In the present embodiment, the distribution server 30, the retransmission server 40, and the group generation server 50 are distinguished from each other, but some or all of them may be configured as an integrated server.

The distribution server 30 and the plurality of receiving devices 10 are installed on a network (multicast compatible network) that supports multicast routing. When there are a plurality of multicast-compatible networks, a distribution server 30 is installed for each multicast-compatible network. The retransmission server 40 and the group generation server 50 are installed on a network accessible from all the receiving devices 10. This network does not necessarily support multicast routing. However, by installing the retransmission server 40 in the multicast-compatible network, it is expected that the influence of delay due to traffic congestion on the Internet at the time of retransmission to the receiving device 10 can be suppressed because the retransmission server 40 does not pass through the open Internet route. Communication between the retransmission server 40 and the receiving device 10 is assumed to be reliable communication by HTTP (Hypertext Transfer Protocol) using TCP (Transmission Control Protocol), but is not limited to this. ..

The group generation server 50 determines a group (hereinafter, referred to as “P2P group”) that is composed of a plurality of receiving devices 10 and performs P2P communication with respect to the receiving device 10 that has been accessed. Further, the group generation server 50 determines one or more receiving devices (representative receiving devices) 10 representing the P2P group for each P2P group. The group generation server 50 can arbitrarily determine the P2P group and the representative receiving device 10. The group generation server 50 may determine the receiving device 10 whose throughput exceeds the threshold value as the representative receiving device 10 among the plurality of receiving devices 10 constituting the P2P group. The group generation server 50 may have a signaling function for each receiving device 10 to start P2P communication, a STUN (Session Traversal Utilities for NATs) function, and the like, or another server may have it. ..

Each receiving device 10 creates a P2P communication connection with a full mesh to the other receiving devices 10 in the P2P group. For example, by using WebRTC for P2P communication, it is possible to relatively easily realize a connection with a receiving device 10 having a different network segment and NAT traversal. When using WebRTC, the arrival and order are guaranteed by setting the Channel Type of the data channel to DATA # CHANNEL # RELIABLE (0x00). A communication protocol other than WebRTC may be used for P2P communication.

The distribution server 30 distributes the multicast stream with FEC to the receiving device 10 at the distribution time. The distribution server 30 adds the FEC block number and the sequential number in the FEC block as header information to all the packets of the multicast stream to be distributed. The multicast stream distributed by the distribution server 30 may be moving image data or program data for system update or the like.

FIG. 2 is a diagram showing a configuration of an FEC block transmitted by the distribution server 30. FIG. 2A shows a general example of delivering a data packet and a redundant packet in one stream to the receiving device 10 in the P2P group. FIG. 2B shows an example in which data packets and redundant packets are individually delivered to the receiving device 10 in the P2P group.

In the distribution example shown in FIG. 2A, the distribution server 30 receives the same FEC block (data packets DATA1-1 to DATA1-5 and redundant packets PARITY1-6, PARITY1-7) in all the receiving devices in the P2P group. It transmits to 10 (reception device 10-1 and reception device 10-2).

In the distribution example shown in FIG. 2B, the distribution server 30 transmits the data packet to all the receiving devices 10 in the P2P group by one IP multicast stream as in FIG. 2A. Regarding the redundant packet, the distribution server 30 divides the redundant packet generated by the same code word (for example, the read / multicast code) into the number of receiving devices 10 in the P2P group, and divides the divided redundant packet into different IPs. The multicast stream is transmitted to each of the receiving devices 10 in the P2P group. The receiving device 10 in the P2P group receives the divided individual redundant packets.

That is, in the distribution example shown in FIG. 2B, for the data packets DATA1-1 to DATA1-5, one is one for all the receiving devices 10 (receiving devices 10-1 and receiving devices 10-2) in the P2P group. Send by IP multicast stream. For redundant packets, redundant packets PARITY 1-6 to PARITY 1-9 generated with the same codeword are divided, redundant packets PARITY 1-6 and PARITY 1-7 are transmitted to the receiving device 10-1, and redundant packets PARITY 1-8, PARITY 1-9 is transmitted to the receiving device 10-2. It is not necessary to divide the redundant packet evenly according to the number of receiving devices 10 in the P2P group. For example, the redundant packet PARITY 1-6 is transmitted to the receiving device 10-1, and the redundant packets PARITY 1-7 to PARITY 1-9 are transmitted. It may be transmitted to the receiving device 10-2.

As shown in FIG. 2B, by dividing the redundant packets and delivering them individually, the correction capability of the FEC is increased by increasing the number of redundant packets as a whole. Therefore, the load on the retransmission server 40 can be further reduced. Although the traffic increases on the upper route close to the distribution server 30, the number of packets received from the distribution server 30 by one of the receiving devices 10 is the same as in FIG. 2A, so that each receiving device 10 Delivery efficiency can be the same.

The receiving device 10 is a device capable of P2P communication with each other via WebRTC or the like via the Internet. The receiving device 10 may be a high-performance NAS (Network Attached Storage) installed in a home, a business office, or the like, or an edge server installed in a station building, a base station, or the like which is a telecommunications carrier's equipment. You may.

The receiving device 10 receives the multicast stream from the distribution server 30 and detects the lost packet due to the sequential number gap (discontinuity). When the receiving device 10 detects that the last packet of the FEC block has been delivered, it determines whether recovery is possible based on the number of lost packets in the FEC block and the like. As a result of the recovery possibility determination, if recovery is not possible, the lost packet is complemented by P2P communication (complementation between devices), and further complementation is performed from the retransmission server 40 as necessary. The details of the completion process will be described later.

FIG. 3 is a block diagram showing a configuration example of the receiving device 10. The receiving device 10 shown in FIG. 3 includes a content information management unit 11, a multicast stream receiving unit 12, a packet analysis unit 13, a recovery possibility determination unit 14, a lost packet recovery unit 15, a packet management storage unit 16, and the like. Packet request information receiving unit 17, packet request information analysis unit 18, request packet transmitting unit 19, request packet receiving unit 20, packet request information generating unit 21, packet request information transmitting unit 22, and group configuration information acquisition. A unit 23, a group generation unit 24, and a group management unit 25 are provided.

The content information management unit 11 manages the time and the IP multicast group address, generates a reception preparation trigger before the distribution start time, and outputs the reception preparation trigger to the multicast stream reception unit 12 and the group generation unit 24. The distribution start time may be managed by the content information management unit 11, or the distribution schedule may be stored in a storage unit (not shown).

When the reception preparation trigger is input from the content information management unit 11, the multicast stream receiving unit 12 starts listening to the corresponding multicast stream. Then, the multicast stream receiving unit 12 receives the multicast stream from the distribution server 30, and outputs the received multicast stream to the packet analysis unit 13.

The packet analysis unit 13 analyzes the multicast stream input from the multicast stream reception unit 12, and detects the lost packet at the time of receiving the multicast stream by the gap of the sequential number. When the packet analysis unit 13 detects a lost packet, the packet analysis unit 13 notifies the recovery possibility determination unit 14 of the sequential number of the lost packet and the number of lost packets. If the packet analysis unit 13 does not detect the lost packet, the packet analysis unit 13 stores the packet in the packet management storage unit 16.

The recovery possibility determination unit 14 determines whether or not the loss packet can be recovered by FEC when the packet analysis unit 13 detects the loss packet and the request packet reception unit 20 receives the request packet. For example, in the case of FEC using the Reed-Solomon code, it is determined that recovery is possible when the number of lost packets is half or less of the number of redundant packets. When the recovery possibility determination unit 14 determines that the lost packet can be recovered, the recovery possibility determination unit 14 notifies the loss packet recovery unit 15. When the recovery possibility determination unit 14 determines that the lost packet cannot be recovered, the recovery possibility determination unit 14 notifies the packet request information generation unit 21 of the sequential number of the lost packet and the number of lost packets.

The loss packet recovery unit 15 recovers the lost packet determined to be recoverable by the recovery possibility determination unit 14 by FEC, and outputs the recovered packet to the packet management storage unit 16.

The packet management storage unit 16 accumulates the received complete packets (for lost packets, the recovered packets), and manages each packet by the FEC block number and the sequential number.

The packet request information receiving unit 17 receives packet request information indicating a lost packet from another receiving device 10 in the P2P group, and outputs the received packet request information to the packet request information analysis unit 18. Here, the packet request information indicating the lost packet is information indicating the FEC block number and the sequential number of the lost packet, and the ID (identification number) of the receiving device 10 requesting the packet.

The packet request information analysis unit 18 analyzes the packet request information input from the packet request information receiving unit 17, and determines the FEC block number and sequential number of the packet to be transmitted, and the source (packet transmission destination) of the packet request information. Notify the request packet transmission unit 19 of the ID of the receiving device 10.

Upon receiving the notification from the packet request information analysis unit 18, the request packet transmission unit 19 identifies the corresponding packet from the FEC block number and the sequential number. Then, the request packet transmission unit 19 acquires only the minimum number of packets required for recovery by the FEC from the packet management storage unit 16 among the lost packets indicated by the packet request information in the receiving device 10 that is the source of the packet request information. To do. Further, the request packet transmission unit 19 acquires network information (information necessary for actually transmitting by IP) from the group management unit 25. Then, the request packet transmission unit 19 transmits the packet acquired from the packet management storage unit 16 to the receiving device 10 of the transmission source of the packet request information.

Upon receiving the unrecoverable notification from the recoverability determination unit 14, the packet request information generation unit 21 generates packet request information including the FEC block number and sequential number of the lost packet and the ID of the receiving device (own device) 10. , The packet request information is output to the packet request information transmission unit 22.

The packet request information transmission unit 22 acquires packet request information from the packet request information generation unit 21. Further, the packet request information transmission unit 22 acquires network information from the group management unit 25. Then, the packet request information transmission unit 22 transmits the packet request information acquired from the packet request information generation unit 21 to another receiving device 10 determined based on the network information. When the own device is the representative receiving device 10, the packet request information transmitting unit 22 transmits the packet request information to another receiving device 10 or the retransmission server 40.

The request packet receiving unit 20 receives a request packet from another receiving device 10 in the P2P group. Here, the request packet is a packet included in the loss packet indicated by the packet request information generated by the packet request information generation unit 21. When the own device is the representative receiving device 10, the request packet receiving unit 20 can also receive the request packet from the retransmission server 40.

The group configuration information acquisition unit 23 transmits network information (for example, SDP, ICE Candidate, etc.) required for starting P2P communication from another receiving device 10 to a server having a signaling function (for example, a group generation server 50). The acquired network information is output to the group generation unit 24.

When the group generation unit 24 receives the reception preparation trigger from the content information management unit 11, the group generation unit 24 transmits the network information input from the group configuration information acquisition unit 23 via a server having a signaling function (for example, the group generation server 50). Is transmitted to the receiving device 10 of the above, and a connection is generated. Further, the group generation unit 24 notifies the group management unit 25 of the session information regarding the receiving device 10 constituting the P2P group, and thereafter the session information is managed by the group management unit 25.

The group management unit 25 manages sessions such as connection / disconnection of P2P communication connections. Further, the group management unit 25 notifies the request packet transmission unit 19 and the packet request information transmission unit 22 of the network information of the P2P group including the session information. When the own device is the representative receiving device 10, the group management unit 25 notifies the packet request information transmitting unit 22 of the network information of the receiving device 10 or the retransmission server 40 in the P2P group.

Next, complementation of lost packets in the distribution system 1 will be described with reference to FIG.

As a result of the recovery possibility determination by the FEC, the receiving device 10 creates packet request information when recovery is not possible, and transmits the packet request information to other receiving devices 10 in the P2P group by P2P communication. The receiving device 10 that has received the packet request information transmits the loss packet indicated by the packet request information up to the minimum number that the receiving device 10 of the transmission source can recover by FEC. As a result, lost packets are complemented between devices, and unnecessary communication costs can be reduced.

In the example shown in FIG. 4, the receiving devices 10-1 to 10-3 exist in the P2P group, and the receiving device 10-1 is used as the representative receiving device. Further, the receiving device 10-1 loses DATA1-1 to DATA1-4, the receiving device 10-2 loses DATA1-2 to DATA1-4, and the receiving device 10-3 loses DATA1-1, DATA1-3, It is assumed that DATA1-4 is lost and only one lost packet can be recovered by the redundant packets PARITY1-6 and PARITY1-7. Since the receiving device 10-1 has 4 lost packets, it is determined that the lost packets cannot be recovered by FEC, and the receiving device receives packet request information indicating that DATA1-1 to DATA1-4 are lost packets. It is transmitted to 10-2 (step S101). The receiving device 10-2, which has received the packet request information from the receiving device 10-1, transmits the held DATA1-1 out of the DATA1-1 to DATA1-4 to the receiving device 10-1 (step S102).

When the reception of the lost packet is completed by the inter-device complementation, the receiving device 10 again determines whether recovery is possible by FEC, updates the packet request information if recovery is not possible, and refers to another receiving device 10 in the P2P group. Attempt inter-device complementation.

In the example shown in FIG. 4, since the receiving device 10-1 still has lost three packets of DATA1-2 to DATA1-4, it is determined that the lost packet cannot be recovered by FEC, and DATA1-2 to 2 Packet request information indicating that DATA1-4 is a lost packet is transmitted to the receiving device 10-3 (step S103). The receiving device 10-3, which has received the packet request information from the receiving device 10-1, transmits the held DATA1-2 out of the DATA1-2 to DATA1-4 to the receiving device 10-1 (step S104).

If recovery is not possible even after executing the inter-device complement operation for all other receiving devices 10 in the P2P group, the same operation is performed for the other receiving devices 10 again until recovery is possible. repeat. However, when the own device is the representative receiving device 10, the packet request information is sent to the retransmission server 40. The retransmission server 40 transmits the minimum number of packets that can be recovered by FEC.

In the example shown in FIG. 4, since the receiving devices 10-1 to the receiving devices 10-3 all lose DATA1-3 and DATA1-4, the DATA1-3 and DATA1-4 are complemented by the inter-device complementation. I can't. Therefore, the representative receiving device 10-1 transmits packet request information indicating that DATA1-3 and DATA1-4 are lost packets to the retransmission server 40 (step S105). When the receiving device 10-1 complements any one of DATA1-3 and DATA1-4, the number of remaining lost packets becomes 1, so that the receiving device 10-1 can be recovered by FEC. The retransmission server 40 that has received the packet request information from the representative receiving device 10-1 transmits DATA1-3 to the representative receiving device 10-1 as the minimum packet that can be recovered by the FEC in the representative receiving device 10-1. (Step S106). The representative receiving device 10-1 transmits DATA1-3 acquired from the retransmission server 40 at the request of the receiving device 10-1 or the receiving device 10-2.

The representative receiving device 10 takes the lost packet from the retransmission server 40 into the P2P group, and complements the lost packet between the devices, so that all the receiving devices 10 in the P2P group recover all the packets in the FEC block. It becomes possible. Since the retransmission server 40 holds all the packets, finally by this operation, all the receiving devices 10 can recover the lost packets. Since only the representative receiving device 10 in the P2P group acquires the packet from the retransmission server 40, the load on the retransmission server 40 can be reduced. Further, the packet acquired from the retransmission server 40 is not distributed by the representative receiving device 10 to all the receiving devices 10 in the P2P group, but is shared by the device-to-device complementation, so that the load on the representative receiving device 10 is also reduced. be able to.

Next, a processing procedure related to packet reception in the receiving device 10 will be described with reference to FIG.

In step S201, the receiving device 10 generates a reception preparation trigger by the content information management unit 11. The receiving device 10 automatically accesses the group generation server 50 before the distribution start time.

In step S202, when the group generation server 50 generates the P2P group, the group generation unit 24 causes the group generation unit 24 to generate the PeerID, which is the connection ID in the P2P group, and the number of connected receiving devices 10 in the P2P group. Peer_num is registered.

In step S203, the receiving device 10 starts receiving the multicast stream by the multicast stream receiving unit 12.

In step S204, the receiving device 10 receives the packet by the packet analysis unit 13.

In step S205, the receiving device 10 analyzes the FEC block number from the header information of the packet by the packet analysis unit 13 and compares it with the FEC block number BL currently being processed to receive the FEC block of the FEC block number BL. Check if it is completed. When the reception of the FEC block having the FEC block number BL is completed, the packet analysis unit 13 starts processing the FEC block having the FEC block number BL.

In step S206, the receiving device 10 determines the presence or absence of lost packets by the packet analysis unit 13. That is, it is determined whether or not the number of lost packets p is 0. When the receiving device 10 determines in step S206 that there is a lost packet, the process proceeds to step S207, and when it is determined in step S206 that there is no lost packet, the receiving device 10 proceeds to the process in step S215.

In step S207, the receiving device 10 determines whether or not the lost packet can be recovered by FEC by the recovery possibility determination unit 14. That is, the recoverability determination unit 14 determines whether or not the number of lost packets p is equal to or less than the maximum value (recoverable number) E of the number of lost packets that can be recovered by FEC. If the receiving device 10 determines in step S207 that the number of lost packets p is equal to or less than the recoverable number E, the process proceeds to step S214, and in step S207 it is determined that the number of lost packets p is larger than the recoverable number E. If so, the process proceeds to step S208.

In step S208, the receiving device 10 generates packet request information by the packet request information generating unit 21, and the packet request information transmitting unit 22 identifies the packet request information by another receiving device 10 (Peer ID) in the P2P group. It is transmitted to the receiving device 10). Then, the request packet receiving unit 20 receives and acquires k request packets from the other receiving device 10. When the group management unit 25 receives the transmission end flag indicating that the transmission of the request packet is completed from the other receiving device 10, the group management unit 25 updates the number of lost packets to pk and increments the PeerID. Then, when it is still necessary to supplement the lost packet, the group management unit 25 determines the receiving device 10 in the P2P group to be the transmission destination of the packet request information. The receiving device 10 sequentially performs inter-device complementation within the P2P group. The receiving device 10 ends the inter-device complementation when the number of lost packets p is equal to or less than the recoverable number E, or when the inter-device complementation is performed with all the receiving devices 10 in the P2P group.

In step S209, the receiving device 10 determines whether or not the lost packet can be recovered by FEC by performing inter-device complementation by the recovery possibility determination unit 14. That is, the recoverability determination unit 14 determines whether or not the number of lost packets p is equal to or less than the recoverable number E. If the receiving device 10 determines in step S209 that recovery is possible, the process proceeds to step S214, and if it is determined in step S209 that recovery is not possible, the receiving device 10 proceeds to step S210.

In step S210, the receiving device 10 advances the process to step S211 if it is a representative receiving device, and returns the process to step S208 if it is not a representative receiving device.

In step S211 the receiving device 10 generates packet request information by the packet request information generation unit 21.

In step S212, the receiving device 10 transmits the packet request information to the retransmission server 40 by the packet request information transmitting unit 22.

In step S213, the receiving device 10 receives the request packet from the retransmission server 40 by the request packet receiving unit 20. The retransmission server 40 transmits the minimum number of packets that can be recovered by FEC. That is, the receiving device 10 receives from the retransmission server 40 the minimum number of unacquired lost packets in which the number of lost packets p is equal to or less than the recoverable number E.

In step S214, the receiving device 10 performs recovery processing by FEC by the loss packet recovery unit 15.

In step S215, the receiving device 10 stores a complete lossless FEC block by the packet management storage unit 16.

Next, with reference to FIG. 6, a processing procedure relating to packet transmission in the receiving device 10 will be described.

In step S301, the receiving device 10 receives and acquires the packet request information from the other receiving device 10 by the packet request information receiving unit 17.

In step S302, the receiving device 10 analyzes the packet request information by the packet request information analysis unit 18.

In step S303, the receiving device 10 waits until the processing of step S207 of FIG. 5 is completed with respect to the FEC block including the lost packet indicated by the packet request information. If it is determined in step S207 that recovery is possible, the process waits until step S214.

In step S304, the receiving device 10 uses the request packet transmitting unit 19 to put the packets held in the packet request information (packets stored in the packet management storage unit 16) into the array P [x]. Register and obtain the number N of lost packets indicated by the packet request information. Here, the size of the array P [x] is N.

In step S305, the receiving device 10 determines whether or not the number N of the retained packets among the lost packets indicated by the packet request information is 0 by the request packet transmitting unit 19. If the receiving device 10 determines in step S305 that the number of packets N is not 0 (the corresponding packet exists), the process proceeds to step S306, and the number of packets N is 0 in step S305 (the corresponding packet does not exist). ), The process proceeds to step S307.

In step S306, the request packet transmission unit 19 causes the request packet transmission unit 19 to perform the minimum number (pe) of the lost packets indicated by the packet request information required for recovery by the FEC in the reception device 10 that is the source of the packet request information. Only the packet of the above is transmitted to the receiving device 10 which is the source of the packet request information. When the number N of the lost packets indicated by the packet request information is less than the minimum number N that can be recovered by the FEC in the receiving device 10 of the transmission source, the request packet transmission unit 19 (N <p). In the case of −E), all (N) packets held out of the lost packets indicated by the packet request information are transmitted to the receiving device 10 that is the source of the packet request information.

In step S307, the receiving device 10 transmits a transmission end flag indicating that the transmission of the request packet is completed by the request packet transmission unit 19.

<Program>
The receiving device 10 is a computer that stores a program that describes the processing contents that realize each function in a storage unit, and reads and executes this program by a processor such as a CPU (Central Processing Unit) or a DSP (Digital Signal Processor). It may be. Further, at least a part of these processing contents may be realized by hardware.

For example, the program for functioning as the receiving device 10 causes the computer to execute all or part of the processes of steps S201 to S215 described with reference to FIG. Further, the program for functioning as the receiving device 10 causes the computer to execute all or part of the processes of steps S301 to S307 described with reference to FIG.

The program may also be recorded on a computer-readable recording medium. Using such a recording medium, it is possible to install the program on the computer. Here, the recording medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, but may be, for example, a recording medium such as a CD-ROM or a DVD-ROM. The program can also be provided by download over the network.

As described above, when the receiving device 10 or the program detects the lost packet when receiving the multicast stream, the receiving device 10 or the program recovers the lost packet if it can be recovered by FEC. If it cannot be recovered, the lost packet is complemented by P2P communication with another receiving device 10 in the P2P group to which the user belongs. If it cannot be complemented by P2P communication, the representative receiving device 10 requests the retransmission server 40 for the lost packet and incorporates it into the P2P group. The receiving device 10 in the P2P group completely recovers the data by taking the lost packet into its own device by P2P communication.

With such a configuration, even when the packet loss rate is high, the amount of redundant packets can be suppressed because reliability is ensured by complementation between devices or complementation by the retransmission server 40. That is, it is possible to achieve both high reliability and distribution efficiency. Further, the load on the retransmission server 40 can be reduced by recovering the lost packet that cannot be recovered by FEC by complementing the devices. Therefore, it is possible to suppress the retransmission explosion even at the time of large-scale distribution, and it is possible to ensure scalability.

Further, the receiving device 10 may send and receive packet request information and request packets with another receiving device 10 by using the data channel of WebRTC. By using WebRTC, it is possible to easily realize P2P communication including NAT traversal.

Further, the distribution server 30 transmits the data packet to all the receiving devices 10 in the P2P group, and divides the redundant packet generated by the same codeword into the number of receiving devices 10 in the P2P group. The redundant packets may be transmitted to the receiving devices 10 in the P2P group, respectively. With this configuration, although all the network flow rates for the redundant packets are generated on the route close to the distribution server 30, the network flow rate is only for the divided redundant packets on the route close to the receiving device 10, so the network flow rate is not divided. It is possible to suppress the traffic on the route closer to the receiving device 10 as compared with the case of transmitting to.

Although the above embodiments have been described as typical examples, it will be apparent to those skilled in the art that many modifications and substitutions can be made within the spirit and scope of the present invention. Therefore, the present invention should not be construed as being limited by the above-described embodiments, and various modifications and modifications can be made without departing from the scope of claims. For example, it is possible to combine a plurality of the constituent blocks or processing steps described in the embodiment into one, or to divide one into a plurality of pieces.

1 Distribution system 10 Receiver 11 Content information management unit 12 multicast stream reception unit 13 Packet analysis unit 14 Recovery availability judgment unit 15 Loss packet recovery unit 16 Packet management storage unit 17 Packet request information reception unit 18 Packet request information analysis unit 19 Request packet Transmission unit 20 Request packet reception unit 21 Packet request information generation unit 22 Packet request information transmission unit 23 Group configuration information acquisition unit 24 Group generation unit 25 Group management unit 30 Distribution server 40 Retransmission server 50 Group generation server

Claims (6)

A receiving device that receives a multicast stream and complements lost packets by P2P communication.
A packet analysis unit that detects lost packets when receiving a multicast stream,
A recovery possibility determination unit that determines whether or not the number of lost packets is equal to or less than the maximum number of lost packets that can be recovered by FEC.
A loss packet recovery unit that recovers recoverable lost packets by FEC when the number of lost packets is equal to or less than the maximum value.
A packet request information generation unit that generates packet request information indicating a lost packet when the number of lost packets is larger than the maximum value.
A packet request information transmitting unit that transmits the packet request information to other receiving devices in the P2P group, and a packet request information transmitting unit.
A request packet receiving unit that receives a request packet, which is a packet included in the loss packet indicated by the packet request information, from the other receiving device.
When the number of lost packets does not fall below the maximum value after receiving the request packet and the receiving device is a representative receiving device representing the P2P group, among the unacquired lost packets, the said A receiving device that acquires the minimum number of packets in which the number of lost packets is equal to or less than the maximum value from the retransmission server, and transmits the acquired lost packets at the request of another receiving device in the P2P group. A packet request information receiver that receives packet request information from other receiving devices,
A request packet transmission unit that transmits only the minimum number of packets required for recovery by FEC in the other receiving device among the lost packets indicated by the packet request information to the other receiving device.
The receiving device according to claim 1. When the number of lost packets indicated by the packet request information is less than the minimum number that can be recovered by the FEC in the other receiving device, the request packet transmitting unit performs the packet. The receiving device according to claim 2, wherein all of the retained packets among the lost packets indicated by the request information are transmitted to the other receiving device. The packet request information transmission unit transmits the packet request information by using the data channel of WebRTC.
The receiving device according to any one of claims 1 to 3, wherein the request packet receiving unit receives the request packet by using the data channel of WebRTC. A distribution system including the receiving device according to any one of claims 1 to 4 and a server that transmits the multicast stream to the receiving device.
A P2P group is generated by the plurality of receiving devices,
The server transmits the data packet to all the receiving devices in the P2P group, divides the redundant packet generated by the same code word into the number of receiving devices in the P2P group, and divides the redundant packet. Is transmitted to each of the receiving devices in the P2P group. A program for operating a computer as a receiving device according to any one of claims 1 to 4.

Images