WO2012011449A1 - プロキシサーバ、中継方法、通信システム、中継制御プログラム、および記録媒体 - Google Patents

プロキシサーバ、中継方法、通信システム、中継制御プログラム、および記録媒体 Download PDF

Info

Publication number
WO2012011449A1
WO2012011449A1 PCT/JP2011/066278 JP2011066278W WO2012011449A1 WO 2012011449 A1 WO2012011449 A1 WO 2012011449A1 JP 2011066278 W JP2011066278 W JP 2011066278W WO 2012011449 A1 WO2012011449 A1 WO 2012011449A1
Authority
WO
WIPO (PCT)
Prior art keywords
proxy server
request
multicast
content
processing unit
Prior art date
Application number
PCT/JP2011/066278
Other languages
English (en)
French (fr)
Inventor
義昭 荻澤
高橋　真毅
Original Assignee
シャープ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by シャープ株式会社 filed Critical シャープ株式会社
Priority to US13/810,715 priority Critical patent/US20130114597A1/en
Priority to JP2012525390A priority patent/JPWO2012011449A1/ja
Priority to EP11809619.7A priority patent/EP2597824A4/en
Priority to CN2011800354373A priority patent/CN103004133A/zh
Publication of WO2012011449A1 publication Critical patent/WO2012011449A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2876—Pairs of inter-processing entities at each side of the network, e.g. split proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching

Definitions

  • the present invention relates to a proxy server of a transmission apparatus that relays data transmitted from a transmission apparatus to a communication apparatus based on a request from a communication apparatus such as a reproduction apparatus or a proxy server of the reproduction apparatus, and a relay method in such a proxy server About.
  • the present invention also relates to a relay control program for operating a computer as such a proxy server, and a recording medium storing the relay control program.
  • the present invention relates to a communication system including at least such a proxy server, a communication device, and a transmission device.
  • static content such as text data and still image data is transmitted and received by unicast communication using the http (s) protocol or the like.
  • moving image content and audio content are often transmitted and received by unicast communication.
  • Patent Document 1 a distribution method by sequentially downloading the MPEG (Moving Picture Expert Group) MP4 file format (Patent Document 1) and a MPEG ISO Media File Format format fragment video format Examples of the distribution method used (Patent Document 2).
  • MPEG Motion Picture Expert Group
  • Patent Document 2 a distribution method by sequentially downloading the MPEG ISO Media File Format format fragment video format Examples of the distribution method used (Patent Document 2).
  • data transmission / reception by unicast communication is performed after establishing a connection between a communication source and a communication destination, and thus has an advantage of high reliability of data transmission / reception.
  • the distribution server distributes moving image content individually to each client device that has issued a distribution request.
  • the network bandwidth load increases when a distribution request is received from a single client device at a time.
  • the distribution server needs to establish connections with a large number of playback devices at a time, there is a problem that the processing load of the distribution server itself increases.
  • the present invention has been made in view of the above problems, and a main object thereof is to realize a proxy server of a transmission apparatus capable of suppressing a network bandwidth load due to data transmitted from the transmission apparatus. is there.
  • the proxy server is a proxy server that caches content transmitted from a transmission device in response to a request from the communication device in a storage unit and relays the content to the communication device.
  • the proxy server When it is detected that the first request to transmit the content by unicast communication is sent from the communication device to the transmission device, the proxy server performs the content by multicast communication instead of the transmission device.
  • the communication device when receiving a second request to transmit the content using multicast communication from the communication device and information indicating that the content can be transmitted to the communication device.
  • Registration means for registering the content in a multicast group and the content cached in the storage unit Using Yasuto communication is characterized in that it comprises a relay means for relaying to each communication device registered in the multicast group.
  • the first request is an HTTP request message
  • the transmission unit transmits the HTTP request message including the information as header information.
  • a value indicating a multicast group address may be included.
  • the proxy server receives information indicating that the content transmitted from the transmission device can be transmitted by multicast communication instead of the transmission device in response to a request from the communication device. Send to communication device.
  • the proxy server uses the multicast communication to transmit the content to the communication device instead of the transmission device. Send to.
  • the proxy server can distribute the content to the plurality of communication devices by multicast communication.
  • the proxy server of the present invention has an effect that the bandwidth load of the network due to the data transmitted from the transmission device can be suppressed.
  • the relay method caches content transmitted from a transmission device in response to a request from a communication device in a storage unit and relays the content to the communication device.
  • the proxy server performs multicast communication instead of the transmission device.
  • a registration step of registering the communication device in a multicast group, and the content cached in the storage unit It is characterized in that it contains a relay step of relaying to each communication device registered in the multicast group using the multicast communication.
  • the relay method of the present invention has the same operation and effect as the proxy server of the present invention.
  • the proxy server of the present invention has an effect that it is possible to suppress the network bandwidth load due to the data transmitted from the transmission device.
  • FIG. 1 is a sequence diagram showing the first half of all the processing steps that are performed from when a client device issues a video content distribution request to when the distribution of video content to the client device is completed between the devices of the distribution system of FIG. 1. is there.
  • FIG. 3 is a sequence diagram showing the first half of all the processing steps that are performed from when a client device issues a video content distribution request to when the distribution of video content to the client device is completed between the devices of the distribution system of FIG. 1. is there.
  • FIG. 3 is a sequence diagram showing the latter half of all processing steps performed between the devices of the distribution system of FIG. 1 from when the client device issues a video content distribution request to when the distribution of the video content to the client device is completed. is there. It is a figure which shows an example of the message transmitted in the process process which the sequence of FIG. 6 and FIG. 7 represents.
  • (A) is a figure which shows the request message which a client apparatus transmits
  • (b) is a figure which shows the response message which a delivery server transmits.
  • (A) is a figure which shows the response message which the proxy server of a delivery server transmits.
  • FIG. 3 is a diagram specifically showing how the proxy server of the distribution server converts video content data transmitted as an HTTP response message into a multicast packet in the distribution system of FIG. 1.
  • FIG. 2 is a diagram schematically showing communication processing between devices in the distribution system of FIG. 1.
  • FIG. 2 is a sequence diagram showing a flow of processing between devices when a client device receives an instruction to interrupt reproduction of video content from a user in the distribution system of FIG. 1.
  • 2 is a flowchart illustrating an operation of an HTTP processing unit provided in a proxy server of a client device in the distribution system of FIG. 1.
  • 2 is a flowchart illustrating an operation of a multicast processing unit included in a proxy server of a client device in the distribution system of FIG. In the distribution system of FIG.
  • FIG. 1 shows the operation
  • . 2 is a flowchart illustrating an operation of a multicast processing unit included in a proxy server of a client device in the distribution system of FIG.
  • FIG. 7 is a flowchart illustrating an operation of an HTTP processing unit provided in a proxy server of the distribution server in the distribution system of FIG. 1 and performed when a JOIN message is received.
  • 2 is a flowchart showing an operation of a client device in the distribution system of FIG. FIG.
  • FIG. 3 is a diagram illustrating an example of an HTTP response message transmitted to a client device when a multicast packet is lost during multicast communication in the distribution system of FIG. 1.
  • the client device when the client device records the content being played back simultaneously, it is a flowchart showing a process of complementing the movie fragment missing by multicast communication with the movie fragment of the missing part acquired by HTTP communication.
  • . 2 is a flowchart illustrating an operation performed by a client device when receiving an instruction from a user to interrupt reproduction of video content in the distribution system of FIG. 1. It is a figure which shows a prior art and shows the delivery system in which each of several client apparatuses receives the data of a video content separately from a delivery server.
  • FIG. 3 is a sequence diagram illustrating an operation example when a client device newly issues a video content distribution request in a state where multicast distribution has already been performed in the distribution system of FIG. 1.
  • FIG. 2 is a sequence diagram illustrating an operation example when video content to be played back on a client device is switched in the distribution system of FIG. 1.
  • FIG. 1 is a diagram showing an overall configuration of a distribution system 1 according to the present embodiment.
  • the distribution system 1 includes N client devices 100 (100-1, 100-2,..., 100-N) and proxy servers 200 (200-1, 200-2,. 200-N), a distribution server 300, and a proxy server 250 of the distribution server 300.
  • a proxy server 250 and a distribution server 300 form a distribution side network (LAN), and client devices 100-1 to 100-N and proxy servers 200-1 to 200- 200-N forms a reproduction-side network (LAN).
  • the two LANs are separated by a backbone network 500, and proxy servers 200-1 to 200-N and 250 are connected to the backbone network 500.
  • the backbone network 500 is assumed to be a network in which no router is interposed between the proxy server 200 and the proxy server 250.
  • the distribution server 300 can distribute video contents of a plurality of channels.
  • the client device 100 receives a channel designation from the user via an operation unit (not shown)
  • the video content of the designated channel (hereinafter also referred to as “target video content”) is delivered from the delivery server 300. It has become.
  • the distribution request from the client device 100 and the video content distributed from the distribution server 300 are first transmitted to the corresponding proxy server.
  • FIG. 2 is a diagram schematically showing communication processing between the respective devices while the video content is distributed from the distribution server 300 to the client devices 100-1 to 100-N in the distribution system 1.
  • right and left thin arrows indicate video content requests and responses according to the HTTP protocol (that is, unicast communication).
  • thick arrows indicate transmission of video content by multicast communication.
  • video content is transmitted within each LAN using a request / response mechanism of HTTP (Hypertext Transfer Protocol) protocol, which is one of data transmission protocols.
  • HTTP Hypertext Transfer Protocol
  • the video content is exchanged in the MIME multipart format (simply referred to as “multipart format”) defined by the HTTP protocol.
  • the video content is distributed by multicast communication in the backbone network.
  • the proxy server 250 can distribute the data (a packet of video content) once to a plurality of proxy servers 200 belonging to the destination multicast group. ing.
  • the client device 100 includes an HTTP processing unit 101 and a playback unit 102.
  • the HTTP processing unit 101 sends a video content distribution request (request message) in units of media segments (each unit obtained by dividing video content at fixed time intervals, simply abbreviated as “MS” in each figure). Is transmitted to the proxy server 200.
  • the HTTP processing unit 101 receives video content from the proxy server 200 as a response message in a multi-part format in which each video segment is a media segment unit and each of which is a movie fragment (fragment) described later.
  • the playback unit 102 plays back video content by reading each media segment received by the HTTP processing unit 101.
  • the proxy server 200 includes an HTTP processing unit 201, a cache unit 202, and a multicast processing unit 203.
  • the HTTP processing unit 201 transfers the distribution request received from the client device 100 to the proxy server 250 with the proxy server 200 as a transmission source, or reads the received data from the cache unit 202 and transmits it to the client device 100. Or
  • the cache unit 202 is a cache memory that holds data.
  • the multicast processing unit 203 requests the proxy server 250 to join and leave the multicast group.
  • the multicast processing unit 203 receives data transmitted by multicast communication and converts it into an HTTP response message format.
  • the proxy server 250 includes an HTTP processing unit 251, a cache unit 252, a multicast processing unit 253, and a multicast group information storage unit 254.
  • the HTTP processing unit 251 relays the distribution request received from the proxy server 200 to the distribution server 300.
  • the HTTP processing unit 251 can multicast the target video content to the response message of the target video content sent from the distribution server 300. It relays to the proxy server 200 after adding header information indicating that it exists.
  • the HTTP processing unit 251 performs multicast distribution of the target video content when there is a proxy server 200 belonging to a multicast group (hereinafter, also referred to as “target multicast group”) to which the target video content is to be multicast distributed.
  • target multicast group a multicast group
  • the proxy server 250 itself is used as a request source, and response messages of each media segment of the target video content are sequentially acquired from the distribution server 300 and cached in the cache unit 252.
  • the cache unit 252 is a cache memory that holds data.
  • the cache unit 252 holds the response message transmitted from the distribution server 300.
  • the multicast processing unit 253 Upon receiving a request for participation in the target multicast group from the proxy server 200-i (i: any value from 1 to N), the multicast processing unit 253 assigns the address of the proxy server 200-i to the target multicast group. Are recorded in the multicast group information storage unit 254. Further, when the multicast processing unit 253 receives a request to leave the target multicast group from the proxy server 200-i, the multicast processing unit 253 sets the address of the proxy server 200-i recorded as belonging to the target multicast group to the multicast group. Delete from the information storage unit 254.
  • the multicast processing unit 253 sequentially transmits HTTP response messages recorded in the cache unit 252 in a packet in a format that allows multicast distribution (FIG. 10). And will be described later with reference to FIG. 11) and distributed to the proxy server 200 to be multicast distributed.
  • the multicast group information storage unit 254 is a nonvolatile memory.
  • the multicast group information storage unit 254 holds, for each of a plurality of multicast groups determined for each video content, the address of a communication device that is a transmission destination belonging to the multicast group.
  • the distribution server 300 includes an HTTP processing unit 301 and a memory unit 302.
  • the HTTP processing unit 301 reads the media segment of the video content requested to be distributed from the memory unit 302 and transmits it to the proxy server 250 as a multipart response message with each movie fragment as a part.
  • the memory unit 302 holds video contents of a plurality of channels.
  • the detailed configurations of the client device 100, the proxy servers 200 and 250, and the distribution server 300 have been described above. Before describing the operation of the distribution system 1, refer to FIGS. 4 and 5 for the above-described movie fragments and media segments. However, it will be described below.
  • FIG. 4 is a diagram schematically showing the relationship between the video content bit stream (Contents.mp4) and each movie fragment obtained by dividing and storing the bit stream.
  • FIG. 5 is a diagram schematically showing the relationship between the media segment and each movie fragment constituting the media segment.
  • bit stream is divided and stored in a plurality of movie fragments.
  • mdat is bit stream data divided.
  • Each movie fragment corresponds to a unit portion obtained by dividing a bit stream by a certain period.
  • a fragment video format defined by ISO Media File Format is assumed as a movie fragment.
  • the top movie fragment (fragment 1) in the bit stream of the MP4 file includes a moov header 41b.
  • the moov header 41b is configured to hold meta information (such as initialization information) regarding the entire bit stream for reproducing video.
  • Subsequent movie fragments (fragments 2, 3,...) In the bit stream of the MP4 file include a moof header 42b.
  • the moof header 42b of each movie fragment is a header for meta information for reproducing the video of the movie fragment.
  • Each movie fragment includes media data (video data) mdat in addition to the header.
  • media data mdat of each movie fragment partial data in a period corresponding to the movie fragment is stored. For example, when the fragment is data obtained by dividing a bit stream in units of one second, the media data mdat of fragment 1 stores video data for one second from the start of video content reproduction.
  • the media segment is composed of a plurality of movie fragments.
  • the media segment also corresponds to a unit portion obtained by dividing content data by a certain period. Further, in the present embodiment, this media segment is handled as content data stored in one response data. That is, the media segment is a unit of content data acquired by one request.
  • the length of the period corresponding to one media segment is an integral multiple of the length of the period corresponding to one movie fragment. (However, this is a case where the length of the movie fragment is fixed, and when the length of the movie fragment is variable, it is not limited to an integral multiple).
  • a period corresponding to one media segment is assumed to be 30 seconds, and a length of a period corresponding to one movie fragment is assumed to be 1 second.
  • 6 and 7 are sequence diagrams showing the first half and the second half of the above operation, respectively.
  • the HTTP processing unit 251 of the proxy server 250 adds header information indicating that multicast distribution is possible only when the target video content is being distributed to four or more devices. ing. Further, it is assumed that the target video content is already being distributed to the three client devices 100-2 to 100-4 before the operation starts, and the client device 100-1 newly issues a target video content distribution request. And
  • the client device 100-1 transmits an HTTP request 41 (first request) requesting the first media segment of the target video content to the proxy server 200-1 (S01).
  • the request 41 is data as shown in FIG. 8A.
  • the client apparatus 100-1 is connected to the proxy server 200-1 by keep alive. ing. That is, the client device 100-1 is kept connected even after receiving a response to the request 41.
  • the HTTP processing unit 201 of the proxy server 200-1 transmits the request 41 received from the client device 100-1 to the proxy server 250 after setting its own IP address as the transmission source (S02). Then, the HTTP processing unit 251 of the proxy server 250 connects to the distribution server 300 by keep alive, and relays the request 41 to the distribution server 300 (S03).
  • the HTTP processing unit 301 of the distribution server 300 Upon receiving the request 41, the HTTP processing unit 301 of the distribution server 300 reads the target video content from the memory unit 302, generates a response message 51 as shown in FIG. 8B, and transmits it to the proxy server 250 (S04). .
  • X-Segment-Fragment-Index: 1/60 indicates the index value of the media segment. That is, X-Segment-Fragment-Index: 1/60 indicates that the target video content is composed of 60 media segments, and this response message is data of the first media segment.
  • ⁇ binary-data: fragment-01 ⁇ ” to “ ⁇ binary-data: fragment-30 ⁇ ” indicate 30 movie fragments constituting the first media segment.
  • the HTTP processing unit 251 of the proxy server 250 that has received the response message 51 checks the request frequency of the target video content from the client device 100 (S05). That is, the HTTP processing unit 251 counts how many times the request 41 for the same target video content is received within a certain period.
  • the HTTP processing unit 251 since the number of client apparatuses 100 is four client apparatuses 100-1 to 100-4 and the request frequency is a certain level or higher, header information indicating that multicast distribution is possible is added to the response message 51. As a result, a response message 51a as shown in FIG. 9A is generated (S06).
  • the character string (character string starting with “X-alternative-cast”) surrounded by a broken-line frame indicates the added header information.
  • the header information of X-alternative-cast has the following format.
  • ⁇ distribution format> indicates a content distribution method
  • FIG. 9A indicates "multicast” which is multicast distribution.
  • ⁇ delivery address> (“224.1.1.1” in FIG. 9A) when the delivery format is multicast delivery indicates a multicast address.
  • the multicast address generally describes a class D IP multicast group address.
  • ⁇ TTL> indicates a packet valid period (time to live). This sets the transmission range within the network.
  • ⁇ TTL> indicates a packet valid period (time to live). This sets the transmission range within the network.
  • ⁇ TTL> it is necessary to set ⁇ TTL> to a large value when multicast data is distributed across the router. Since there is no router in the backbone network 500, the value of ⁇ TTL> is “1”.
  • ⁇ Session ID> and ⁇ Session name> are used to identify a session.
  • the HTTP processing unit 251 transmits the generated response message 51a to the proxy server 200-1 (S07).
  • the HTTP processing unit 201 of the proxy server 200-1 that has received the response message 51a confirms that the header information of “X-alternative-cast” is present (S08), notifies the multicast processing unit 203 to that effect, and The response message 51a is converted into the original response message 51 and transmitted to the client device 100-1 (S09). Note that the playback unit 102 of the client device 100-1 that has received the response message 51 starts playback of the target video content.
  • the HTTP processing unit 201 of the proxy server 200-1 transmits a multicast reception request (JOIN message 42 requesting participation in the target multicast group) as illustrated in FIG. 9B to the proxy server 250 (S10).
  • the JOIN message 42 (second request) and the LEAVE message 43 described later are HTTP messages in the form of a GET request, as shown in FIGS. 9B and 9C.
  • a character string indicating participation in the multicast group and a character string indicating leaving from the multicast group are assigned. That is, “JOIN” is assigned to the JOIN message 42, and “LEAVE” is assigned to the LEAVE message 43.
  • the HTTP processing unit 251 of the proxy server 250 that has received the JOIN message 42 returns a response message and records the address of the proxy server 200-1 in the multicast group information storage unit 254 as belonging to the target multicast group (S11). ).
  • the HTTP processing unit 251 that has received the JOIN message in S10 acquires the media segment of the target video content (S12) and records it in the cache unit 252 (S13).
  • the processes in S12 and S13 are then repeated. That is, the processes of S12 and S13 are performed for all media segments constituting the target video content.
  • the period which repeats the process of S12 is not specifically limited. That is, the process of S12 may be repeated at a cycle shorter than the playback time in the client device 100 of one media segment.
  • the multicast processing unit 253 sequentially converts the response message 51 of the media segment recorded in the cache unit 252 into a multicast packet (S14).
  • the multicast packet includes a UDP header part, an RTP header part, and an RTP data part.
  • a more specific structure of the multicast packet will be described below with reference to FIGS. 10 (a) and 10 (b).
  • FIG. 10A shows the format of a UDP packet that constitutes a multicast packet.
  • the UDP header portion of the UDP packet includes a multicast packet transmission source port number, a multicast packet transmission destination port number, a UDP packet length, and a checksum field for packet consistency.
  • the data portion of the UDP packet has a variable length.
  • FIG. 10 (b) shows the format of the RTP packet that constitutes the data (datagram) portion of the UDP packet. A part of the response message 51 is recorded in the RTP data portion (payload data) of the RTP packet.
  • a sequence number indicating a transmission order of multicast packets and a time stamp are stored in the RTP header portion of the RTP packet.
  • the time stamp of the RTP packet stores the value of the smallest time stamp (X-timestamp) among the response messages 51 whose part is included in the RTP data portion of the RTP packet. For example, when a part of the response message 51 corresponding to the second media segment is included in the RTP data part, “30” is stored in the time stamp of the RTP header part.
  • the left part of FIG. 11 schematically shows converted multicast packets 52-1, 52-2, 52-3,... Also, the right part in FIG. 11 shows the data of the header part in the HTTP response message 51 (51-1, 51-2%) And the data of each part of the body part as payload data in which multicast packet. It schematically shows whether it is stored.
  • the multicast processing unit 253 reads the response message 51-1 of the media segment from the cache unit 252, the “file name of the target video content” and the “index value of the media segment” in the character string of the Content-Location header of the response message 51. "(That is,” / content1 / 1 ") is extracted and stored as payload data in the first multicast packet 52-1.
  • the multicast processing unit 253 stores the header portion of the message 51-1 in the next multicast packet 52-2 as payload data.
  • the multicast processing unit 253 stores the data of the body part of the message 51-1 as payload data in the subsequent multicast packet 52-3. More specifically, the multicast processing unit 253 stores the movie fragment included in each part in one or a plurality of multicast packets 52 according to the data size of the movie fragment. The multicast processing unit 253 performs the same processing for each message 51 after the message 51-2.
  • the binary data of the movie fragment included in each part is stored in the multicast packet 52 so that the head part always matches the head part of the payload of the multicast packet 52.
  • the binary data of the movie fragment included in each part is stored in the multicast packet 52 so that the end portion always matches the end portion of the payload of the multicast packet 52. That is, binary data of a plurality of movie fragments are not stored in one multicast packet.
  • the multicast processing unit 253 stores appropriate values in the above-described UDP header part, RTP header part, and RTP data part in the header part of the multicast packet, as well as an IP multicast address (multicast group address) in the IP header part. "224.1.1.1" is stored.
  • the multicast processing unit 253 sequentially distributes the multicast packet 52 converted as described above to the proxy server 200-1 (S15).
  • the multicast processing unit 203 of the proxy server 200-1 collectively converts the plurality of multicast packets 52 distributed in S15 into a response message 51 of a media segment (S16) and caches it in the cache unit 202 (S17).
  • the processes of S15 to S17 are repeated thereafter. That is, the processes of S12 and S13 are performed for all media segments constituting the target video content.
  • the client device 100-1 subsequently transmits an HTTP request 41 requesting the second media segment of the target video content to the proxy server 200-1 (S18).
  • the HTTP processing unit 201 of the proxy server 200-1 Upon receiving the request 41, the HTTP processing unit 201 of the proxy server 200-1 reads the response message 51 of the second media segment from the cache unit 202 (S19). When the response message 51 is not cached in the cache unit 202 at the time when the reading is attempted, the HTTP processing unit 201 waits until the response message 51 is cached before reading.
  • the HTTP processing unit 201 that has read the response message 51 transmits the response message 51 to the client device 100-1.
  • the processes of S18 and S19 are also sequentially performed on the subsequent third and subsequent media segments.
  • the distribution server 300 receives a request 41 for requesting the last media segment from the proxy server 250.
  • the HTTP processing unit 301 of the distribution server 300 transmits to the proxy server 250 a response message 51 ′ in which the header of “Connection: Close” is added to the header of the normal response message 51 as the response message of the last media segment ( S20).
  • the HTTP processing unit 251 confirms that the character string “Connection: Close” is present in the header of the response message 51 ′, it recognizes that the connection state with the distribution server 300 has been released (S ⁇ b> 21).
  • the multicast processing unit 253 converts the response message 51 'cached in the cache unit 252 into the multicast packet 52 and transmits it to the proxy server 200-1 (S22).
  • the multicast processing unit 203 of the proxy server 200-1 collectively converts the plurality of multicast packets 52 distributed in S22 into a response message 51 'of the media segment and caches it in the cache unit 202.
  • the multicast processing unit 203 confirms that the header of “Connection: Close” is present in the header of the cached response message 51 ′.
  • the HTTP processing unit 201 of the proxy server 200-1 When the client apparatus 100-1 transmits an HTTP request 41 requesting a subsequent media segment to the proxy server 200-1, the HTTP processing unit 201 of the proxy server 200-1 that has received the request 41 responds to the response of the media segment.
  • the message 51 ′ is read from the cache unit 202.
  • the HTTP processing unit 201 reading the response message 51 ′ confirms that the header has a “Connection: Close” header (S23)
  • the connection state with -1 is released (S24).
  • the client device 100-1 recognizes that the connection state with the proxy server 200 has been released. Therefore, the playback of the target video content is completed when the playback unit 102 finishes playback of the media segment (that is, the last media segment of the target video content) of the response message 51 '.
  • the multicast processing unit 203 that has confirmed that the header “Connection: Close” is present in the header of the response message 51 ′ notifies the HTTP processing unit 201 to that effect, and the HTTP processing unit 201 displays the message shown in FIG. ) Multicast reception end notification (LEAVE message requesting leaving from the target multicast group) 43 as shown in FIG.
  • the HTTP processing unit 251 of the proxy server 250 that has received the LEAVE message 43 returns a response and confirms that the received message is the LEAVE message 43 (S26).
  • the HTTP processing unit 251 deletes the address of the proxy server 200-1 in the multicast group information storage unit 254 recorded as belonging to the target multicast group (S27).
  • the proxy server 200-1 is excluded from the multicast group to which the target video content is to be distributed by multicast.
  • the processing from S22 onward is performed on the client apparatuses 100-2 to 100-4 and the proxy servers 200-2 to 200-4. That is, the video reproduction of the target video content is completed also in the client devices 100-2 to 100-4, and the proxy servers 200-2 to 200-4 are excluded from the multicast group to which the target video content is to be distributed by multicast.
  • the HTTP processing unit 201 and the multicast processing unit 203 confirm that the header of “Connection: Close” is present in the header of the response message 51 ′. Instead, the HTTP processing unit 201 and the multicast processing unit 203 refer to the X-Media-Segment-index header in the header part, and the media segment index value (“1” in FIG. 8B) and the target It may be confirmed whether or not the value indicating the number of media segments constituting the video content (“60” in FIG. 8B) becomes the same value. If the values are the same, the HTTP processing unit 201 may notify the multicast processing unit 203 to that effect and cause the multicast processing unit 203 to transmit a LEAVE message.
  • FIG. 13 is a sequence diagram showing a flow of processing between the devices when the client device 100-1 receives an instruction to interrupt the reproduction of the video content from the user.
  • the reproduction unit 102 of the client device 100-1 interrupts reproduction of the target video content.
  • the HTTP processing unit 101 transmits a request 41 ′ in which the header of “Connection: Close” is added to the header part of the HTTP request 41 requesting the next media segment to the proxy server 200-1 (S 28).
  • the HTTP processing unit 201 of the proxy server 200-1 Upon receiving the request 41 ', the HTTP processing unit 201 of the proxy server 200-1 confirms that the header "Connection: Close” is added to the header part of the request 41' (S29). Then, the HTTP processing unit 201 reads the response message 51 of the media segment from the cache unit 202, transmits it to the client device 100-1, and releases the connection state with the client device 100-1.
  • the HTTP processing unit 201 that has confirmed that the header of “Connection: Close” has been added notifies the multicast processing unit 203 that it has been added (S30).
  • the HTTP processing unit 201 transmits a LEAVE message 43 for requesting leaving from the target multicast group as shown in FIG. 9C to the proxy server 250 (S31).
  • the HTTP processing unit 251 of the proxy server 250 that has received the LEAVE message 43 returns a response to the proxy server 200 and confirms that the received message is the LEAVE message 43 (S32).
  • the HTTP processing unit 251 deletes the address of the proxy server 200-1 in the multicast group information storage unit 254 recorded as belonging to the target multicast group (S33).
  • the proxy server 200-1 is excluded from the multicast group to which the target video content is to be distributed by multicast.
  • the multicast processing unit 253 When there are no more devices belonging to the target multicast group, the multicast processing unit 253 notifies the HTTP processing unit 251 to that effect. Then, the HTTP processing unit 251 transmits the HTTP message to the distribution server 300 with the header “Connection: Close” added to the header (S34). As a result, the connection state between the distribution server 300 and the proxy server 250 is released.
  • FIG. 14 is a flowchart showing the operation of the HTTP processing unit 201.
  • the HTTP processing unit 201 receives a media segment request 41 from the client device 100 (S1101).
  • the HTTP processing unit 201 determines whether any data is cached in the cache unit 202 (S1102).
  • the HTTP processing unit 201 When it is determined that some data is cached in the cache unit 202 (YES in S1102), the HTTP processing unit 201 receives the request URI (in the example of FIG. 8A, "/ content1 /" in the request 41) received in S1101. 1 ") is read out (S1107). The HTTP processing unit 201 then sends a response message corresponding to this request URI (the response message corresponding to “/ content1 / 1” in the example of FIG. 8A) of the target video content whose file name is content1. The response message of the first media segment is read from the cache unit 202 (S1108). Thereafter, the process proceeds to S1109.
  • the HTTP processing unit 201 transmits the request 41 to the proxy server 250 (S1103), and then sends a corresponding response message. Received from the proxy server 250 (S1104).
  • the HTTP processing unit 201 determines whether or not the received response message includes header information (X-alternative-cast header) indicating that the proxy server 250 can transmit the content by multicast communication (S1105). ). If it is determined that it is not included (NO in S1105), the process proceeds to S1109, and if it is determined that it is included (YES in S1105), the process proceeds to S1106.
  • header information X-alternative-cast header
  • the HTTP processing unit 201 issues an instruction to perform multicast reception (notification of a received multicast address), and in S1118, performs transmission / reception of the JOIN message with the proxy server 250, and proceeds to S1110.
  • the HTTP processing unit 201 In S1109, the HTTP processing unit 201 generates a response message to be transmitted to the client apparatus 100, and the process proceeds to S1110.
  • the HTTP processing unit 201 determines whether the request 41 received in S1101 includes a communication end notification (“Connection: Close” header). If it is determined that a communication end notification is included (YES in S1110), the HTTP processing unit 201 notifies the multicast processing unit 203 of the end of multicast reception (S1111), and proceeds to S1112. On the other hand, when it is determined that the communication end notification is not included (NO in S1110), the process proceeds to S1112.
  • the HTTP processing unit 201 determines whether or not a communication end notification (“Connection: Close” header) is included in the response received in S1104. If it is determined that a communication end notification is included (YES in S1112), the process proceeds to S1119. In S1119, the HTTP processing unit 201 performs transmission / reception of the LEAVE message 43 with the proxy server 250, and the process proceeds to S1115.
  • the HTTP processing unit 201 determines whether or not the response received in S1104 is a response of the last media segment (S113). That is, referring to the X-Media-Segment-index header of the header part, it is determined whether or not the media segment index value and the value indicating the number of media segments constituting the target video content are the same value.
  • the HTTP processing unit 201 adds a communication end notification to the response message generated in S1109 (S1115). Then, the HTTP processing unit 201 transmits a response message including a communication end notification to the client device 100 (S1116), releases the connection state with the client device 100 (S1117), and ends the processing.
  • FIG. 15 is a flowchart showing the operation of the multicast processing unit 203.
  • the multicast processing unit 203 receives a notification to start multicast reception from the HTTP processing unit 201 (S1201).
  • the multicast processing unit 203 performs initialization for receiving multicast data. Specifically, in order to receive multicast distribution (in response to a query periodically transmitted from the proxy server 250), a multicast group address is acquired from the HTTP processing unit 201 (S1202).
  • the multicast processing unit 203 sequentially receives the multicast packets (S1203), and converts the plurality of packets received in S1205 into response messages in the media segment HTTP format (S1204).
  • the multicast processing unit 203 caches the response message obtained by the conversion in the cache unit 202 (S1205), and refers to the X-Media-Segment-index header of the header part included in the response message (S1206). ). That is, it is determined whether or not the index value of the media segment and the value indicating the number of media segments constituting the target video content are the same value.
  • the multicast processing unit 203 When the multicast processing unit 203 has not received all data of the target video content (NO in S1207), that is, the index value of the media segment and the value indicating the number of media segments constituting the target video content are If not the same value, the process returns to S1203.
  • the multicast processing unit 203 notifies the HTTP processing unit 201 that the multicast reception has ended, and ends the processing.
  • the HTTP processing unit 251 receives the request for the media segment of the target video content from the proxy server 200 (S1301).
  • the HTTP processing unit 251 transmits the received request to the distribution server 300 (S1302), and receives a response corresponding to the request from the distribution server 300 (S1303).
  • the HTTP processing unit 251 determines whether or not the target video content is already being distributed by multicast (S1304). That is, the HTTP processing unit 251 refers to the multicast group information storage unit 254 and determines whether there is a proxy server 200 that participates in the target multicast group.
  • the HTTP processing unit 251 confirms the request frequency of the target video content from the client device 100.
  • the process in S1305 is the same as the process in S05 in FIG. That is, the HTTP processing unit 251 counts how many times the request 41 for the same target video content is received within a certain period.
  • the HTTP processing unit 251 counts it as a request for the same target video content. For example, when a request 41 including “content 1/2” and a request 41 including “content 1/3” are received, both are counted as requests for the same target video content.
  • the HTTP processing unit 251 In S1306, the HTTP processing unit 251 generates an X-alternative-cast header that uses ⁇ distribution method> as multicast distribution, and adds the X-alternative-cast to the header part of the response message transmitted from the distribution server 300 in S1304. Add a header.
  • ⁇ distribution address> of the X-alternative-cast header is a multicast group address used for distribution of the target video content when the target video content is already being distributed in multicast.
  • the HTTP processing unit 251 uses an unused class D multicast group address as ⁇ distribution address>.
  • the HTTP processing unit 251 transmits a response message to the proxy server 200, and proceeds to S1308.
  • the HTTP processing unit 251 determines whether the target video content is already being distributed by multicast (S1309). If it is determined that the target video content is already being distributed by multicast (YES in S1309), the process proceeds to S1311. Also, if the JOIN message is not received from the proxy server 200 within a certain period (NO in S1308), the process proceeds to S1311.
  • the HTTP processing unit 251 connects to the distribution server 300 by keep alive, and sends each response message of the target video content from the distribution server 300.
  • the acquisition process (details will be described later with reference to FIG. 18) is started (S1310).
  • the HTTP processing unit 251 determines whether or not the “Connection: Close” header is included in the header part of the response message acquired from the distribution server 300 (S1311).
  • the HTTP processing unit 251 waits until a LEAVE message is received from the proxy server 200 (S1312), and ends the processing after the reception. .
  • the process proceeds to S1313.
  • the HTTP processing unit 251 determines whether or not the multicast distribution end is notified from the multicast processing unit (S1313). If it is determined that the end of multicast distribution has not been notified (NO in S1313), the process ends.
  • the HTTP processing unit 251 releases the connection state with the distribution server (S1314) and ends the process.
  • the HTTP processing unit 251 generates a URI of a request to be transmitted to the distribution server 300 next based on the response message received immediately before from the distribution server 300 (S1501). For example, if the end of the Content-Location of the response message received immediately before from the distribution server 300 is “/ content1 / 1”, “/ content1 / 2” is generated as the URI of the request.
  • the HTTP processing unit 251 transmits a request to the distribution server 300 (S1502) and receives a response from the distribution server 300 (S1503).
  • the HTTP processing unit 251 caches the response received from the distribution server 300 in the cache unit 252 in association with the URI information of the request transmitted in S1502 (S1504).
  • the HTTP processing unit 251 determines whether or not all response messages of the target video content (content whose file name is “content1”) have been received (S1505). If it is determined that there is a response message that has not been received (NO in S1505), the process returns to S1501. On the other hand, if it is determined that all response messages have been received (YES in S1505), the process ends.
  • the multicast processing unit 253 acquires a JOIN message from the HTTP processing unit 251 (S1401).
  • the multicast processing unit 253 identifies the target multicast group based on the file name of the target video content included in the JOIN message, and registers the address of the proxy server 200 that transmitted the JOIN message in the target multicast group. . (S1402).
  • the multicast processing unit 253 reads the response message from the cache unit 252 (S1403) and converts it into a plurality of multicast packets (S1404).
  • the multicast processing unit 253 delivers a plurality of multicast packets obtained by the conversion to the proxy server 200 (S1405).
  • the multicast processing unit 253 determines whether or not a LEAVE message has been received from the HTTP processing unit 251 (S1406). If it is determined that the LEAVE message has not been received (NO in S1406), the process returns to S1403.
  • the multicast processing unit 253 deletes the address of the proxy server 200 that has transmitted the LEAVE message from the target multicast group (S1407), and proceeds to S1408.
  • the multicast processing unit 253 determines whether there is another proxy server 200 belonging to the target multicast group. If it is determined that it exists (YES in S1408), the process returns to S1403.
  • the multicast processing unit 253 notifies the HTTP processing unit 251 that multicast distribution of the target video content has ended (multicast distribution end) (S1409), and the process ends.
  • the HTTP processing unit 101 of the client device 100 transmits a request for the media segment of the target video content to the proxy server 200 (S1701), and receives a response from the proxy server 200 (S1702).
  • the HTTP processing unit 101 determines whether or not the moov header is included in the response message received in S1702 (S1703). If it is determined that the moov header is included (YES in S1703), the process proceeds to S1704. If it is determined that the moov header is not included (NO in S1703), the process proceeds to S1705.
  • the playback unit 102 performs initialization processing necessary for playback of the target video content by referring to the moov header.
  • the left part in FIG. 20 shows a response message transmitted from the distribution server 300 to the proxy server 250, and the right part in FIG. 20 shows the response message transmitted to the client apparatus 100.
  • a plurality of multicast packets 52 converted from the response message shown on the left side in FIG. 20 are transmitted to the proxy server 200, but some packets 52 may be lost while passing through the backbone network 500.
  • the packet 52 constituting the movie fragment 03 and the movie fragment 04 is missing, and the response 51 received by the client device 100 is data in which the movie fragment 03 and the movie fragment 04 are missing.
  • the reason why only the movie fragment 03 and the movie fragment 04 are missing is that the response 51 is a response message in a multi-part format with the movie fragment as each part. Further, the fact that the two movie fragments of the movie fragment 03 and the movie fragment 04 have been lost, as shown in FIG. 20, although the movie fragment is one-second data in this embodiment, Since the difference between the included time stamps (X-Timestamp: 1.00 of movie fragment 02 and X-Timestamp: 4.00 of movie fragment 05) is 3 seconds instead of 1 second, the playback unit 102 can detect it. It has become.
  • the HTTP processing unit 101 determines whether or not to complement the missing part. That is, based on a setting made in advance by the user via an operation unit (not shown) (setting of whether a media segment should be played after complementing a missing part or a media segment should be played without complementing the missing part) Then, it is determined whether or not the missing part is to be complemented.
  • the playback unit 102 adjusts the playback time of Movie Fragment data in the received media segment (S1707). That is, the Movie Fragment data in the media segment describes the MovieFragment playback start time in X-Timestamp, and the client acquires MovieFragment data at the time to be played back from the X-Timesamp and plays it back. If a defect occurs in the media segment, there is no MovieFragment at the time to be played, and playback seems to stop, so the X-Timestamp value is adjusted and Movie Fragment continues (in time) To do.
  • the X-Timestamp of the movie fragment 05 is acquired as 2.00 so as to be continuous from the movie fragment 02. Then, the X-Timestamp of subsequent movie fragments is adjusted to be continuous in the same manner. Moreover, you may adjust at the time of reproduction
  • control is performed so that the last frame (still image) constituting the movie fragment is reproduced for one second thereafter.
  • the playback unit 102 records information indicating that playback should be performed for 2 seconds in the moof header of the previous movie fragment.
  • the HTTP processing unit 101 transmits a request to acquire the movie fragment of the missing part to the proxy server 200 (S1708), and proceeds to S1709.
  • the request for acquiring the missing movie fragment may be a request for a media segment including the missing movie fragment, or may be a request for acquiring only the missing movie fragment.
  • the URI of the request to obtain only the missing movie fragment is / ⁇ file name of the target video content> / ⁇ index number of the media segment> / ⁇ the number of the movie fragment in the media segment. Value indicating whether or not> For example, if the time stamp (X-timestamp) of the missing movie fragment is 45, the URI of the request is / content1 / 2/16.
  • the playback unit 102 determines whether the HTTP processing unit 101 has already acquired the movie fragment of the missing part corresponding to the request of S1708 (S1709). ). If it is determined that it has been acquired (YES in S1709), the playback unit 102 complements the missing movie fragment with the acquired new movie fragment (replaces it with a new movie fragment) (S1710). After the process of S1710, the process proceeds to S1713.
  • the playback unit 102 adjusts the playback time of Movie Fragment data in the received media segment (S1711).
  • the process of S1711 is the same process as the process of S1707.
  • the playback unit 102 sequentially plays back each movie fragment of the media segment received in S1702 (S1712). After the process of S1712, the process proceeds to S1714.
  • the playback unit 102 sequentially plays back each movie fragment of the media segment received in S1702 (or after complementing in S1710), and proceeds to S1714.
  • the reproducing unit 102 determines whether or not the reproduced media segment should be stored in a storage unit (not shown). In other words, the playback unit 102 determines that it should be stored when receiving an instruction to record the target video content from the user via the operation unit, and has not received an instruction to record. If it is, it is determined that it should not be accumulated.
  • the reproduced media segment is accumulated in the storage unit (S1716). After the process of S1716, the process proceeds to S1717. On the other hand, if it is determined that it should not be accumulated (NO in S1714), the process proceeds to S1717.
  • the playback unit 102 determines whether the media segment played back in S1713 is the last media segment of the target video content. If it is determined that it is not the last media segment (NO in S1717), the process returns to S1701. On the other hand, if it is determined that it is the last media segment (YES in S1717), the process proceeds to S1718.
  • the HTTP processing unit 101 releases the connection state with the proxy server 200, ends the reproduction of the target video content, and proceeds to S1719.
  • the playback unit 102 determines whether or not each media segment of the target video content has been recorded. If it is determined that the recording has been made (YES in S1719), the data complementing process in S1720 is performed, and the process ends. If it is determined that no recording has been made (NO in S1719), the process ends.
  • FIG. 21 is a flowchart showing the flow of data supplement processing of the client device 100.
  • the playback unit 102 of the client device 100 determines whether or not there is a missing part in the media segment played back in S1713 (S1801). If it is determined that a missing part exists (S1801), a request for obtaining a movie fragment of a missing part has already been issued in S1708, but the HTTP processing unit 101 has already obtained a movie fragment of a missing part corresponding to this request. It is determined whether or not it has been acquired (S1802). If it is determined that the movie fragment of the missing part has been acquired (YES in S1802), the process proceeds to S1803, and if it is determined that the movie fragment of the missing part has not yet been acquired (NO in S1802), the process proceeds to S1804. .
  • the HTTP processing unit 101 determines whether or not to complement the missing part. That is, based on a setting made in advance by the user via an operation unit (not shown) (setting whether to complement after completion of reproduction of the entire target video content or to complement during reproduction of the target video content) It is determined whether or not to complement.
  • the HTTP processing unit 101 determines whether or not a movie fragment of a missing part should be acquired.
  • the HTTP processing unit 101 determines that the movie fragment of the missing part should be acquired when an instruction to reproduce the media segment is provided without complementing the missing part, and the missing part is determined. If an instruction to reproduce the media segment is given after complementation, it is determined that the movie fragment of the missing part should not be acquired.
  • the HTTP processing unit 101 acquires the movie fragment of the missing part from the proxy server 200 (S1805), and proceeds to S1806. On the other hand, if it is determined that the movie fragment of the missing part should not be acquired (NO in S1804), the data complementing process is terminated.
  • the playback unit 102 complements the missing movie fragment with the new movie fragment acquired in S1708 or S1806, and ends the data complementing process.
  • the client device 100 acquires the movie fragment of the missing part from the proxy server 200 when the missing part exists in the received media segment.
  • the client device 100 can play the media segment with the missing portion being complemented.
  • the target video content can be recorded in a complete state by accumulating the media segment with the missing part complemented. it can.
  • the playback unit 102 of the client device 100 determines whether or not a playback interruption instruction has been received from the user (S1902).
  • the HTTP processing unit 101 If it is determined that a reproduction interruption instruction has been received (in S1902), the HTTP processing unit 101 then generates a request with a “Connection: Close” header added to the header as a request to be transmitted to the proxy server 200. (S1903).
  • the HTTP processing unit 101 transmits the request generated in S1903 to the proxy server 200 (S1904).
  • a live video input from a live camera (not shown) to the distribution server 300 is distributed live to the client device 100 as target video content. Further, since the live video input to the distribution server 300 is recorded in the memory unit 302 and distributed live, the client device 100 distributes the VOD distribution of the target video content from the distribution server 300 after the live distribution ends. It is possible to receive.
  • FIG. 24 is a sequence diagram showing the above operation example of the distribution system 1. In FIG. 24, descriptions of the operations of the client devices 100-2 to 100-4 and the proxy servers 200-2 to 200-4 are omitted.
  • the multicast processing unit 253 of the proxy server 250 transmits the multicast packet 52 of the target video content to the proxy server 200 (S40).
  • the HTTP processing unit 201 of the proxy server 200 sends the response 51 of the media segment to S40.
  • the response packet 51 is generated using the multicast packet 52 received in step S1 and the response 51 is transmitted to the client device 100-1 (S42).
  • the client device 100-5 transmits a request 43 for the target video content to the proxy server 200-5 (S43).
  • the request 43 is a request used to request transmission of the entire target video content. That is, the request 43 is different from the request 41 used for requesting transmission of a designated media segment in the target video content.
  • the HTTP processing unit 201 of the proxy server 200-5 Upon receiving the request 43, the HTTP processing unit 201 of the proxy server 200-5 relays the request 43 to the proxy server 250 (S44).
  • the HTTP processing unit 251 of the proxy server 250 Upon receiving the request 43, the HTTP processing unit 251 of the proxy server 250 confirms the URI (“/ content1 /”) of the request (S45). That is, it is determined whether or not the target video content (content whose file name is “content1”) has already been distributed by multicast (that is, whether or not a communication device belonging to the target multicast group already exists).
  • the proxy servers 200-1 to 200-4 belong to the target multicast group, it is determined that multicast distribution is being performed.
  • the HTTP processing unit 251 that has determined that the target video content is distributed by multicast generates an X-alternative-cast header. Then, the HTTP processing unit 251 sends the response message 51 of the latest media segment cached in the cache unit 252 (the media segment with an index value of t) to the X-- An alternative-cast header is added (S46).
  • the HTTP processing unit 251 transmits a response message 51 'including an X-alternative-cast header to the proxy server 200-5 (S47).
  • the HTTP processing unit 201 of the proxy server 200-5 converts the response message 51 'into the response message 51 and transmits it to the client device 100-5 (S48).
  • the playback unit 102 of the client device 100-5 plays back the response message 51 of the latest media segment (the media segment with the index value t) received by the HTTP processing unit 101. As a result, the client device 100-5 starts to reproduce the live video.
  • the HTTP processing unit 201 of the proxy server 200-5 transmits a multicast reception request (JOIN message) 42 to the proxy server 250 (S49).
  • the HTTP processing unit 251 of the proxy server 250 transmits a response to the JOIN message 42 to the proxy server 200-5 (S50). Further, the HTTP processing unit 251 records the address of the proxy server 200-5 in the multicast group information storage unit 254 as belonging to the target multicast group (S51).
  • the multicast processing unit 253 transmits the multicast packet 52 of the media segment whose index value is t + 1 or later to the proxy servers 200-1 to 200-5 (S52).
  • the HTTP processing unit 101 of the client device 100-5 that has received the response message 51 of the media segment with the index value t sends a request 41 for requesting the next media segment (with the index value t + 1) to the proxy server 200. -5 (S53), and receives the response 51 (media segment with index value t + 1) corresponding to the request 41 (S54).
  • the client device 100-5 repeats the processes of S53 and S54 for the subsequent media segments (index values t + 2, t + 3,).
  • the processing load of the distribution server 300 and the network load between the distribution server 300 and the proxy server 250 can be suppressed. Therefore, the target video content is efficiently distributed from the distribution server 300 to each client device 100.
  • the client device 100 can record simultaneously with the reproduction of the target video content in accordance with an instruction from the user.
  • the client device 100-5 when the client device 100-5 is set to record the target video content, the client device 100-5 has a media segment whose index value is t or later in the target video content. Will be accumulated.
  • the client device 100-5 acquires and accumulates t ⁇ 1 responses 51 by transmitting the request 41 of the media segment whose index value is t before the target video content to be VOD distributed after the live distribution is completed.
  • the entire target video content distributed live can be efficiently recorded.
  • proxy server 250 As described above, in the proxy server 250 of the distribution system 1, when the HTTP processing unit 251 detects that the request 41 requesting the target video content is sent from the proxy server 200, the proxy 250 replaces the proxy server 300. The server 250 transmits X-alternative-cast information indicating that the target video content can be transmitted by multicast communication to the proxy server 200. In addition, when the multicast processing unit 253 receives the JOIN message 42 from the proxy server 200, the multicast processing unit 253 registers the proxy server 200 in the target multicast group. Then, the multicast processing unit 253 relays the target video content in the cache unit 252 to each proxy server 200 registered in the target multicast group using multicast communication.
  • the distribution server 300 when the number of client devices 100 to which the target video content is distributed is three (the frequency of receiving distribution requests is less than a certain level), the distribution server 300, as shown in FIG. With respect to the segment, the distribution request is received three times and a response of the media segment is returned each time.
  • the distribution server 300 when the number of client devices 100 to which the target video content is distributed reaches a predetermined number (four) (the frequency of receiving a distribution request becomes more than a certain level), then the distribution server 300 can complete the process of receiving a distribution request and returning a response of a media segment for a media segment having the same content. Therefore, the processing load on the distribution server 300 and the network load between the distribution server 300 and the proxy server 250 are suppressed.
  • the proxy server 250 when the number of client devices 100 to which the target video content is distributed is three (the frequency of receiving the distribution request is less than a certain level), the proxy server 250 also has the same content media. With respect to the segment, the distribution request is received three times and a response of the media segment is returned each time.
  • the proxy server 250 when the number of client devices 100 to which the target video content is distributed reaches a predetermined number (four) (the frequency of receiving the distribution request becomes more than a certain level), the proxy server 250 , Media segments can be multicasted. That is, the data amount of data transmitted by the proxy server 250 in order to distribute media segments having the same contents to the four client apparatuses 100 is the data amount of one media segment. Therefore, the bandwidth load in the area close to the proxy server 250 in the backbone network is suppressed.
  • the media segment is transmitted from the distribution server 300 to the proxy server 250 in the MIME multi-part format in which each part is a movie fragment, and the proxy server 250 may transmit all of one part (movie fragment) or A part of data is stored in one multicast packet for multicast distribution. Therefore, even if one multicast packet is lost during transmission of a large number of multicast packets, the effect of the drop only affects one movie fragment. Accordingly, it is possible to cause the client device 100 to stably reproduce the video content.
  • the proxy server 200 joins and leaves the multicast group by transmitting an IGMP JOIN message and a LEAVE message.
  • IGMP is a protocol used when a multimedia router routes multicast data in IP broadcasting (IP multicast).
  • a multimedia router is configured to grasp whether or not there is a host device participating in a multicast group using IGMP.
  • the multimedia router transmits multicast data to host devices participating in the multicast group. Therefore, in order for the host device to receive certain multicast data, it is necessary to transmit an IGMPIGJOIN message requesting participation in the multicast group to which the multicast data is transmitted to the multimedia router.
  • the host device needs to respond to a query (IGMP-QUERY) transmitted from the multimedia router at regular intervals (transmit IGMP-REPORT). Furthermore, in order not to receive the multicast data, the host device needs to send an IGMP LEAVE message requesting to leave the multicast group that is the transmission destination of the multicast data.
  • IGMP-QUERY a query transmitted from the multimedia router at regular intervals
  • the multimedia router needs to perform various processes such as a process for joining the host device to the multicast group, a process for sending a query, and a process for leaving the host device from the multicast group.
  • the process of removing the host device from the multicast group is a time-consuming process. This is because, when the multimedia router receives the IGMP LEAVE message, it checks whether there is another host device to which the multicast data should be transmitted by a query, and then stops the transmission of the multicast data.
  • multimedia data is transmitted to the host device for a while after the host device transmits the IGMP LEAVE message.
  • channel zapping is performed while a host device is receiving multicast distribution of video content, not only multicast data of the video content of the channel switching destination but also multicasting of the video content of the channel switching source for a while. Data will also be sent. In other words, since a certain bandwidth is generally compensated for multicast distribution, there is a problem that the network bandwidth is wasted in channel zapping.
  • the multicast group having the video content of the channel switching destination as the transmission destination of the host device It is also possible to participate.
  • another problem arises that a time lag occurs between the stop of playback of the video content of the channel switching source and the start of playback of the video content of the channel switch destination.
  • the distribution system 1 while the video content having the file name “content1” (also referred to as “switching source video content”) is being played back on the client device 100-1, the file name of the video content to be played back is received from the user. It is assumed that a channel switching instruction to switch to “content2” video content (also referred to as “switched video content”) is issued. Further, it is assumed that the proxy server 250 has already multicast-distributed the switching destination video content to other client devices 100 before the channel switching instruction is issued.
  • FIG. 25 is a sequence diagram showing the above operation example.
  • the proxy server 200 that receives the request 41 of the switching source video content from the client device 100-1 receives the response 51a from the proxy server 250, and sends the switching source video content to the destination of multicast distribution.
  • An IGMP JOIN message requesting participation in the multicast group (referred to as “switching source multicast group”) is transmitted to the proxy server 200 (S50).
  • the multicast processing unit 253 Upon receiving the IGMP25JOIN message, the multicast processing unit 253 starts transmission of the multicast packet 52 of the switching source video content toward the proxy server 200 (S51). Thereafter, the response 51 of the switching source video content is distributed from the proxy server 200-1 to the client device 100-1 in the same manner as in the first embodiment (the processing of S51 to S54 below is repeated). .
  • the multicast processing unit 203 of the proxy server 200-1 collectively converts the plurality of multicast packets 52 distributed in S51 into the response 51 of the media segment (S52) and caches it in the cache unit 202 (S53). .
  • the HTTP processing unit 201 reads the corresponding response 51 from the cache unit 202 (S54). ) To the client device 100-1.
  • the client apparatus 100-1 instructs the channel switching from the user via the operation unit. Suppose you received it.
  • the HTTP processing unit 101 of the client device 100-1 that has received the channel switching instruction transmits a request 41 ′ of the switching source video content (that is, a request with the “Connection: Close” header added) to the proxy server 200 ( S55).
  • the HTTP processing unit 101 transmits a request 41 of the switching destination video content to the proxy server 200 (S56).
  • the HTTP processing unit 201 of the proxy server 200-1 When the HTTP processing unit 201 of the proxy server 200-1 newly receives the switching destination video content request 41 in S56, it determines whether or not the switching source video content request 41 'has been received. Here, since the request 41 'is received in S55, it is determined that the request URI has been changed (S57). Since it is determined that the request URI has been changed, the HTTP processing unit 201 relays the request 41 to the proxy server 250 (S60).
  • the multicast processing unit 203 transmits an IGMP LEAVE message requesting leaving from the switching source multicast group to the proxy server 250 (S58).
  • the multicast processing unit 253 of the proxy server 250 starts processing for leaving the proxy server 200-1 from the switching source multicast group (S59). As described above, since this process requires a certain time, the multicast packet 52 of the switching source video content is transmitted to the proxy server 200-1 for a while. In this case, the proxy server 200-1 discards the multicast packet 52.
  • the HTTP processing unit 251 of the proxy server 250 that has received the request 41 relays the request 41 to the distribution server 300 (S61).
  • the HTTP processing unit 251 sets ⁇ delivery address> in the response message 51 as the address of the switching destination multicast group.
  • An X-alternative-cast header is added (S62), and a response 51 ′ is generated.
  • the HTTP processing unit 251 transmits the response 51 'of the switching destination video content to the proxy server 200-1 (S63).
  • the HTTP processing unit 201 of the proxy server 200-1 Upon receiving the response 51 ', the HTTP processing unit 201 of the proxy server 200-1 transmits the response 51 of the switching destination video content to the client device 100-1 (S64). From this time point, reproduction of the switching destination video content is started in the client device 100-1.
  • the multicast processing unit 203 transmits an IGMP JOIN message requesting participation in the switching destination multicast group to the proxy server 250.
  • the multicast packet 52 of the switching destination video content is distributed to the proxy server 200.
  • the timing at which the multicast processing unit 203 transmits an IGMP JOIN message requesting participation in the switching destination multicast group to the proxy server 250 is when the multicast processing unit 203 determines that the IGMP JOIN message should be transmitted. It is desirable to be.
  • the multicast processing unit 203 determines that the IGMP JOIN message should be transmitted when a certain time has elapsed since the multicast packet 52 of the switching source video content is no longer received and discarded, and the certain time has elapsed. It is desirable to determine that the IGMP JOIN message should not be sent at the timing before
  • the HTTP processing unit 201 When the HTTP processing unit 201 receives the request 41 of the switching destination video content (second content) in S56, the response of the switching source video content (first content) to be transmitted to the client device 100-1.
  • a “Connection: Close” header may be added to 51 and transmitted to the client apparatus 100-1. In this case, the connection state established between the client device 100-1 and the proxy server 200 in order to relay the switching source video content is released immediately after the response is transmitted.
  • the client device 100 when channel switching is performed, the client device 100 performs the switching source video content request 41 ′ (HTTP request including the “Connection: Close” header) and the switching destination. If the video content request 41 is transmitted to the proxy server 200, playback of the switching destination video content can be started immediately. Further, the network bandwidth between the client device 100 and the proxy server 200 is not compressed during the channel switching.
  • the switching source video content request 41 ′ HTTP request including the “Connection: Close” header
  • the client of the distribution system 1 receives the video content by multicast communication (that is, transmits an IGMP LEAVE message requesting to leave the switching source multicast group to the multimedia router at the time of channel zapping).
  • the device 100 has an effect that it is possible to achieve both the quick reproduction of the switching destination video content and the suppression of the network bandwidth load on the client device 100 side.
  • the switching destination video content can be quickly played back, if the switching destination video content is a live video content that has already been distributed live, the user can view the live video at an early timing. Can do.
  • the channel is switched between the client device 100 of the present embodiment and the conventional client device, and then the switching destination. There may be a case where the difference in time required to start playing the video content further widens.
  • the client device cannot allow the user to view the video until the encoded key frame data is acquired and decoded.
  • IP multicast distribution multicast packets may be lost during transmission. That is, when the client device directly receives the multicast packet of the switching destination video content as in the prior art, there is a possibility that the start of playback of the switching destination video content is delayed due to the lack of the key frame due to the loss of the multicast packet.
  • the client device 100 of the present embodiment as described above, communication reliability is consistently established between the client device 100 and the distribution server 300 until the playback of the switching destination video content is started after the channel is switched. It is performed by highly reliable HTTP communication. In other words, until the switching destination video content is started to be played, the lack of key frames does not occur in the process of distributing the switching destination video content from the distribution server 300 to the client device 100. Therefore, the client device 100 according to the present embodiment can reliably start the reproduction of the switching destination video content quickly even when the switching destination video content is compressed and encoded.
  • the distribution server 300 or the proxy server 250 is configured to be able to process the X-Transport-Speed header, and the client device 100 transmits an HTTP request including the X-Transport-Speed header to the proxy server 200.
  • the X-Transport-Speed header is a header for requesting the HTTP server to transmit data at a transmission rate corresponding to the value specified by the header.
  • the client device 100 can receive the data of the switching destination video content at high speed by setting a large value as the X-Transport-Speed header. Therefore, the client device 100 can start the reproduction of the switching destination video content more quickly even when the key frame is not included in the head portion of the data of the switching destination video content.
  • the proxy server 250 plays the role of a multimedia router (that is, no multimedia router exists on the communication path between the proxy server 200 and the proxy server 250).
  • the backbone network 500 may be a network in which a multimedia router is interposed between the proxy server 200 and the proxy server 250.
  • the proxy server 200 transmits a notification such as IGMP JOIN or IGMP LEAVE to the multimedia router closest to the proxy server 200 among the multimedia routers on the communication path with the proxy server 250.
  • the client device 100 issues a request for target video content in units of media segments.
  • the client device 100 may issue a request in units of the entire target video content.
  • the proxy server 250 converts the request received from the proxy server 200 into a request in units of media segments.
  • the HTTP processing unit 251 receives a request for the entire target video content (a request message beginning with “GET / content1 / 1 HTTP / 1.1”), it starts with “GET / content1 / 1 HTTP / 1.1”.
  • a request 41 is generated and transmitted to the distribution server 300, and a corresponding response is received.
  • the HTTP processing unit 251 generates a request 41 that starts with “GET / content1 / t / HTTP / 1.1”, transmits the request 41 to the distribution server 300, and receives a corresponding response. This is repeated until the entire target video content is received.
  • the proxy server 250 when the proxy server 250 receives the request 41 from the proxy server 200 and does not perform multicast distribution, the request 41 is relayed to the distribution server 300. However, the multicast distribution is performed. In such a state, the proxy server 250 may be operated as follows.
  • the proxy server 250 if the response 51 corresponding to the request 41 is cached in the cache unit 252 when the request 41 is received from the proxy server 200, the proxy server 250 generates the cached response 51 (or the response 51).
  • the response 51 ′) may be transmitted to the proxy server 200.
  • the IP address of each device is an address defined by IPv4.
  • the present invention is not limited to this. That is, the IP address of each device may be an address defined by IPv6.
  • the proxy server 250 may perform multicast distribution using a multicast distribution method defined for networks configured with IPv6.
  • the client device 100 determines whether or not a missing part exists in the received media segment, and acquires data of the missing part when it is determined that the missing part exists (that is, the missing part data). Although it is assumed that a distribution request for a movie fragment (or a media segment including a missing part) is made, this processing may be performed by the proxy server 200 of the client device 100. Further, the proxy server 200 may use a packet retransmission technique, FEC (Forward Error Correction), or the like in order to acquire data of a missing part.
  • FEC Forward Error Correction
  • the proxy server 200 is a proxy server for a plurality of client devices 100
  • the defective portion can be efficiently detected rather than causing each client device 100 to individually acquire the missing portion data. Data can be acquired.
  • the accumulated amount of the response 51 to be cached exceeds the storage capacity of the cache unit 202, and the multicast packet 52 that is multicast-distributed from the proxy server 250 thereafter is stored. It may be destroyed.
  • the proxy server 200 determines that the request 41 The response 51 can be acquired from the proxy server 250 by relaying.
  • the client device 100 can grasp which media segment has not been acquired during the certain period, it can reacquire all the media segments that have not been obtained during the certain period.
  • the proxy server 200 operates as follows in order to prevent the accumulated amount of data cached in the cache unit 202 from exceeding the storage capacity of the cache unit 202. You may let them.
  • the multicast processing unit 203 of the proxy server 200 determines that the amount of data cached in the cache unit 202 exceeds a certain threshold, one of the hierarchized media segments that the multicast packet 52 configures. It is also possible to extract only the data of the part hierarchy, convert it into a response message, and cache it in the cache part 202. For example, when the media segment that the multicast packet 52 comprises is composed of a base layer and an enhancement layer, a response message in which only the base layer is extracted may be cached in the cache unit 202.
  • the multicast processing unit 203 determines that the amount of data cached in the cache unit 202 has exceeded a certain threshold, a part of media segments composed of a plurality of quality data included in the multicast packet 52 Only the quality data may be extracted and converted into a response message and cached in the cache unit 202.
  • the media segment included in the multicast packet 52 includes one-segment data and 13-segment data
  • a response message obtained by extracting only the one-segment data may be cached in the cache unit 202.
  • the HTTP processing unit 201 of the proxy server 200 reads the response 51 cached in the cache unit 202, and displays information indicating a tier that can be provided, quality (bit rate), and the like in the header part of the response 51 or By adding to each part of the multipart, the hierarchy (or quality) to be acquired by the client apparatus 100 can be changed.
  • Each block of the client device 100, the proxy servers 200 and 250, and the distribution server 300 (300 ′) may be realized in hardware by a logic circuit formed on an integrated circuit (IC chip), or may be a CPU ( It may be realized by software using a Central Processing Unit.
  • the client device 100, the proxy servers 200 and 250, and the distribution server 300 include a CPU that executes instructions of a program that realizes each function, a ROM (Read Memory) that stores the program, and a RAM that expands the program. (Random Access Memory), a storage device (recording medium) such as a memory for storing the program and various data, and the like.
  • An object of the present invention is to obtain program codes (execution format program, intermediate code program, source program) of control programs for the client device 100, the proxy servers 200 and 250, and the distribution server 300, which are software for realizing the functions described above.
  • the computer-readable recording medium is supplied to the client device 100, the proxy servers 200 and 250, and the distribution server 300, and the computer (or CPU or MPU) reads the program code recorded on the recording medium. It can also be achieved by executing.
  • Examples of the recording medium include tapes such as magnetic tapes and cassette tapes, magnetic disks such as floppy (registered trademark) disks / hard disks, and disks including optical disks such as CD-ROM / MO / MD / DVD / CD-R.
  • IC cards including memory cards
  • semiconductor memories such as mask ROM / EPROM / EEPROM / flash ROM, or PLD (Programmable logic device) or FPGA (Field Programmable Gate Array) Logic circuits can be used.
  • the program code may be supplied to the client device 100, the proxy servers 200 and 250, and the distribution server 300 via a communication network.
  • the communication network is not particularly limited as long as it can transmit the program code.
  • the Internet intranet, extranet, LAN, ISDN, VAN, CATV communication network, virtual private network (Virtual Private Network), telephone line network, mobile communication network, satellite communication network, etc. can be used.
  • the transmission medium constituting the communication network may be any medium that can transmit the program code, and is not limited to a specific configuration or type.
  • wired lines such as IEEE 1394, USB, power line carrier, cable TV line, telephone line, ADSL (Asymmetric Digital Subscriber Line) line, infrared rays such as IrDA and remote control, Bluetooth (registered trademark), IEEE 802.11 wireless, HDR ( It can also be used by wireless such as High Data Rate, NFC (Near Field Communication), DLNA (Digital Living Network Alliance), mobile phone network, satellite line, and terrestrial digital network.
  • wired lines such as IEEE 1394, USB, power line carrier, cable TV line, telephone line, ADSL (Asymmetric Digital Subscriber Line) line, infrared rays such as IrDA and remote control, Bluetooth (registered trademark), IEEE 802.11 wireless, HDR ( It can also be used by wireless such as High Data Rate, NFC (Near Field Communication), DLNA (Digital Living Network Alliance), mobile phone network, satellite line, and terrestrial digital network.
  • wired lines such as IEEE 1394, USB, power line carrier, cable TV line, telephone line, ADSL (Asymmetric Digital Subscriber Line) line,
  • the transmission device is configured to be capable of transmitting a plurality of different contents in response to a request from the communication device.
  • the proxy server of the present invention when the proxy server of the present invention receives a request to transmit content by unicast communication from a large number of communication devices in a short period of time for the same content, It is possible to relay to a large number of communication devices by multicast communication.
  • the same content is received from only a small number of communication devices as a request to transmit the content by unicast communication, the content is relayed to the small number of communication devices by unicast communication.
  • the proxy server can maintain a good balance between the suppression of the network bandwidth load by multicast communication and the stable transmission by unicast communication according to the status of the network bandwidth load. Play.
  • the transmission device is configured to sequentially transmit each piece of divided data obtained by dividing the content into a plurality of pieces in response to a request from the communication device, and the relay unit of the proxy server It is desirable to sequentially relay each divided data cached in the storage unit to the communication device.
  • the proxy server has an additional effect that multicast communication can be performed more efficiently.
  • the content is preferably video content, and the video content is preferably composed of a plurality of movie fragments.
  • the proxy server has an additional effect of enabling fine playback control of the video content in the playback device that plays back the content.
  • the video content transmitted from the transmitting device is multipart data including one movie fragment in each part.
  • the proxy server has an additional effect that it can acquire data lost in the communication device in a short period of time.
  • the proxy server in each part, not only the one movie fragment but also the one movie fragment among the plurality of movie fragments, the number of the playback device that plays the video content is to be played back. It is desirable that the indicated value is included.
  • the said proxy server makes the communication apparatus which received the data of multipart format determine whether the value which shows the said what order should be reproduced
  • the proxy server is configured such that the relay means relays video content to be relayed to each communication device by transmitting a plurality of packets to each communication device by multicast communication.
  • Each preferably includes at least one movie fragment in whole or in part.
  • the communication device even when N packets out of M packets transmitted by the proxy server to the communication device by multicast communication are lost during transmission, the communication device has MN pieces. The above movie fragments can be received.
  • the proxy server has an additional effect that even if a considerable number of packets are lost during transmission, the communication device can acquire the lost data in a short period of time.
  • the proxy server functions as the communication device that transmits the first request to the proxy server (transmission-side proxy server), and responds to the first request received from the reproduction device that reproduces the content.
  • the second request is sent to the transmitting proxy server.
  • a proxy server provided with first determination means for determining whether or not to transmit is also included in the scope of the present invention.
  • the proxy server performs multicast communication from the transmission side proxy server only when the first determination unit determines that the second request should be transmitted to the transmission side proxy server. To receive content.
  • the proxy server can appropriately select whether to suppress network bandwidth load by multicast communication or to ensure stable transmission by unicast communication.
  • the proxy server maintains a connection state established with the playback device for relaying the content while the relay means relays the content to the playback device.
  • a connection established with the playback device to relay the first content when receiving a first request to transmit the second content while relaying the content to the playback device It is desirable to release the state.
  • the proxy server immediately ends the processing related to the first content when the playback device switches the content to be played back from the first content to the second content. Can do.
  • the proxy server can further reduce the processing load due to the switching of the content of the playback device.
  • the proxy server when the proxy server receives the first request that the second content should be transmitted while the first content is being relayed to the playback device, the first content is A transmission means for transmitting a request for releasing the own device from the multicast group to which each relayed communication device belongs to the transmitting proxy server, and a certain time after the first content is not transmitted to the own device. And a second determination means for determining whether or not the second determination means determines whether the second determination means determines that a certain time has elapsed. It is desirable to determine that the request should be sent to the sender proxy server.
  • the proxy server when the playback device switches the content to be played back from the first content to the second content, the proxy server has both the first content and the second content. It is possible to suppress the unnecessary bandwidth load on the network between the proxy servers, in which multicast communication is received from the transmission side proxy server.
  • the present invention can also be realized as a communication system including each proxy server, the playback device, and the transmission device.
  • a program for operating the proxy server according to the present invention characterized in that the computer functions as each of the above-mentioned means, and a computer readable recording the relay control program Such recording media are also included in the scope of the present invention.
  • the communication system according to the present invention can be widely used as a video distribution system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

　プロキシ（２５０）は、プロキシ（２００）からの映像リクエストの検出時に、サーバ（３００）の代理で自身がマルチキャストで映像を送信できる旨を示す情報を該プロキシに送信する処理部（２５１）とプロキシ（２００）からのＪＯＩＮメッセージ受信時に該プロキシをマルチキャストグループに登録する処理部（２５３）とを備える。処理部（２５３）はキャッシュ（２５２）の映像を登録済の各プロキシにマルチキャストで中継する。

Description

プロキシサーバ、中継方法、通信システム、中継制御プログラム、および記録媒体
　本発明は、再生装置または再生装置のプロキシサーバといった通信装置からの要求に基づいて送信装置から送信されたデータを、通信装置に中継する送信装置のプロキシサーバ、およびそのようなプロキシサーバにおける中継方法に関する。また、本発明は、そのようなプロキシサーバとしてコンピュータを動作させる中継制御プログラム、および、該中継制御プログラムを記憶している記録媒体に関する。さらに、本発明は、そのようなプロキシサーバと、通信装置と、送信装置と、を少なくとも含む通信システムに関する。
　近年、インターネットに対する需要が急速に高まるにしたがって、テキストや静止画等の静的コンテンツで構成されたＷＥＢページを見るだけでなく、動画コンテンツおよび音声コンテンツを、ストリーミング配信を受けて鑑賞することを望むユーザが増えてきている。
　一般に、テキストデータや静止画データ等の静的コンテンツは、http(s)プロトコル等によるユニキャスト通信により送受信されるようになっている。また、動画コンテンツおよび音声コンテンツもユニキャスト通信により送受信されることが多い。
　ユニキャスト通信により動画コンテンツを配信する配信方式として、MPEG（Moving Picture Expert Group）のMP4ファイルフォーマットを順次ダウンロードさせることによる配信方式（特許文献１）や、MPEGのISO Media File Formatのフラグメント映像形式を用いた配信方式（特許文献２）等が挙げられる。
　一般にユニキャスト通信によるデータの送受信は、通信元と通信先とでコネクションを確立した上で行われるため、データの送受信の信頼性が高いというメリットがある。
日本国特許公開公報「特開２００５－１１０２４４号公報（２００５年４月２１日公開）」 日本国特許公開公報「特開２００７－１７３９８７号公報（２００７年７月５日公開）」
　しかしながら、上記従来のようなユニキャスト通信による配信方式では、図２３において矢印で示したように、配信サーバは、配信要求を出した各クライアント装置に対して個別に動画コンテンツを配信するため、多数のクライアント装置から一度に配信要求を受けた場合にネットワークの帯域負荷が高まるという問題がある。また、配信サーバは、一度に多数の再生装置とコネクションを確立する必要があるため、配信サーバ自体の処理負荷も高まるという問題がある。
　本発明は上記の問題を鑑みてなされたものであり、その主な目的は、送信装置から送信されるデータによるネットワークの帯域負荷を抑えることが可能な、送信装置のプロキシサーバを実現することにある。
　本発明に係るプロキシサーバは、上記課題を解決するために、通信装置からの要求に応じて送信装置から送信されるコンテンツを、記憶部にキャッシュするとともに上記通信装置に中継するプロキシサーバであって、ユニキャスト通信によりコンテンツを送信すべき旨の第１の要求が上記通信装置から上記送信装置に送られたことを検出した場合に、上記送信装置の代わりに該プロキシサーバがマルチキャスト通信により該コンテンツを送信可能であることを示す情報を上記通信装置に送信する送信手段と、上記通信装置からマルチキャスト通信を用いて上記コンテンツを送信すべき旨の第２の要求を受信した場合に、上記通信装置をマルチキャストグループに登録する登録手段と、上記記憶部にキャッシュされた該コンテンツを、マルチキャスト通信を用いて上記マルチキャストグループに登録された各通信装置に中継する中継手段と、を備えていることを特徴としている。
　上記プロキシサーバは、例えば、上記第１の要求がＨＴＴＰリクエストメッセージであり、上記送信手段が、上記情報をヘッダ情報として含むＨＴＴＰレスポンスメッセージとして送信するようになっており、上記ヘッダ情報には、上記マルチキャストグループのアドレスを示す値が含まれるように構成することができる。
　上記の構成によれば、上記プロキシサーバは、通信装置からの要求に応じて上記送信装置から送信されるコンテンツを、上記送信装置の代わりに自身がマルチキャスト通信により送信可能であることを示す情報を通信装置に送信する。そして、上記プロキシサーバは、マルチキャスト通信を用いて上記コンテンツを送信すべき旨の要求を上記通信装置から受信した場合に、上記送信装置の代わりに自身がマルチキャスト通信を用いて上記コンテンツを上記通信装置に送信する。
　したがって、複数の通信装置から上記送信装置に対してユニキャスト通信によるコンテンツの配信要求があった場合に、上記プロキシサーバは、上記複数の通信装置に対してマルチキャスト通信によりコンテンツを配信することができる。
　これにより、複数の通信装置から上記送信装置に対してユニキャスト通信によるコンテンツの配信要求があった場合に、上記送信装置からユニキャスト通信により個別に送信された各コンテンツをそのまま中継する従来のプロキシサーバに比べ、本発明のプロキシサーバは、送信装置から送信されるデータによるネットワークの帯域負荷を抑えることができるという効果を奏する。
　本発明に係る中継方法は、上記課題を解決するために、通信装置からの要求に応じて送信装置から送信されるコンテンツを、記憶部にキャッシュするとともに上記通信装置に中継するプロキシサーバにおける中継方法であって、ユニキャスト通信によりコンテンツを送信すべき旨の第１の要求が上記通信装置から上記送信装置に送られたことを検出した場合に、上記送信装置の代わりに該プロキシサーバがマルチキャスト通信により該コンテンツを送信可能であることを示す情報を上記通信装置に送信する送信工程と、上記通信装置からマルチキャスト通信を用いて上記コンテンツを送信すべき旨の第２の要求を受信した場合に、上記通信装置をマルチキャストグループに登録する登録工程と、上記記憶部にキャッシュされた該コンテンツを、マルチキャスト通信を用いて上記マルチキャストグループに登録された各通信装置に中継する中継工程と、を含んでいることを特徴としている。
　上記の構成によれば、本発明の中継方法は、本発明のプロキシサーバと同様の作用効果を奏する。
　以上のように、本発明のプロキシサーバは、送信装置から送信されるデータによるネットワークの帯域負荷を抑えることができるという効果を奏する。
本発明の実施形態に係る配信システムの全体構成を示した図である。 図１の配信システムにおいて、配信サーバからクライアント装置に映像コンテンツが配信されている間の各装置間の通信処理を模式的に示した図である。 図１の配信システムを構成する各装置の詳細な構成を示した機能ブロック図である。 映像コンテンツのビットストリームと、ムービーフラグメントと、の関係を模式的に示した図である。 メディアセグメントと、ムービーフラグメントと、の関係を模式的に示した図である。 図１の配信システムの各装置間において、クライアント装置が映像コンテンツの配信要求を出してから、クライアント装置への映像コンテンツの配信が完了するまでに行われる全処理工程の前半部分を示すシーケンス図である。 図１の配信システムの各装置間において、クライアント装置が映像コンテンツの配信要求を出してから、クライアント装置への映像コンテンツの配信を完了するまでに行われる全処理工程の後半部分を示すシーケンス図である。 図６および図７のシーケンスが表わす処理工程の中で送信されるメッセージの一例を示す図である。（ａ）はクライアント装置が送信するリクエストメッセージを示す図であり、（ｂ）は配信サーバが送信するレスポンスメッセージを示す図である。 図６および図７のシーケンスが表わす処理工程の中で送信されるメッセージの別の一例を示す図である。（ａ）は配信サーバのプロキシサーバが送信するレスポンスメッセージを示す図である。また、（ｂ）および（ｃ）は、それぞれ、クライアント装置のプロキシサーバが送信するＨＴＴＰメッセージ形式のマルチキャストグループのＪＯＩＮメッセージおよびＬＥＡＶＥメッセージを示している。 （ａ）～（ｃ）は、図１の配信システムにおいて、配信サーバのプロキシサーバからクライアント装置のプロキシサーバに対して送信されるマルチキャストパケットの構造を示す図である。 図１の配信システムにおいて、配信サーバのプロキシサーバが、どのようにしてＨＴＴＰのレスポンスメッセージとして送信された映像コンテンツのデータをマルチキャストのパケットに変換するかを具体的に示した図である。 図１の配信システムにおいて、各装置間の通信処理を模式的に示した図である。（ａ）は配信要求を出しているクライアント装置の数が３つである場合の図であり、（ｂ）は配信要求を出しているクライアント装置の数が３つである場合の図である。 図１の配信システムにおいて、映像コンテンツの再生を中断する旨の指示をクライアント装置がユーザから受けた場合における、各装置間の処理の流れを示すシーケンス図である。 図１の配信システムにおいて、クライアント装置のプロキシサーバが備えるＨＴＴＰ処理部の動作を示すフローチャートである。 図１の配信システムにおいて、クライアント装置のプロキシサーバが備えるマルチキャスト処理部の動作を示すフローチャートである。 図１の配信システムにおいて、配信サーバのプロキシサーバが備えるＨＴＴＰ処理部が行う動作を示すものであり、クライアント装置のプロキシサーバを送信先とするレスポンスメッセージを受信した場合に行う動作を示すフローチャートである。 図１の配信システムにおいて、クライアント装置のプロキシサーバが備えるマルチキャスト処理部の動作を示すフローチャートである。 図１の配信システムにおいて、配信サーバのプロキシサーバが備えるＨＴＴＰ処理部の動作を示すものであり、ＪＯＩＮメッセージを受信した場合に行う動作を示すフローチャートである。 図１の配信システムにおいて、クライアント装置の動作を示すフローチャートである。 図１の配信システムにおいて、マルチキャスト通信中にマルチキャストパケットが欠損した場合に、クライアント装置に送信されるＨＴＴＰのレスポンスメッセージの一例を示す図である。 図１の配信システムにおいて、クライアント装置が、再生中のコンテンツを同時に録画する場合に、マルチキャスト通信により欠損したムービーフラグメントを、ＨＴＴＰ通信により取得した欠損部のムービーフラグメントにより補完する処理を示すフローチャートである。 図１の配信システムにおいて、映像コンテンツの再生を中断する旨の指示をユーザから受けた場合に、クライアント装置が行う動作を示すフローチャートである。 従来技術を示すものであり、複数のクライアント装置の各々が配信サーバから個別に映像コンテンツのデータを受信する配信システムを示す図である。 図１の配信システムにおいて、マルチキャスト配信がすでに行われている状態で新たにクライアント装置が映像コンテンツの配信要求を出した場合の動作例を示すシーケンス図である。 図１の配信システムにおいて、クライアント装置で再生する映像コンテンツを切り替えた場合の動作例を示すシーケンス図である。
　（実施形態１）
　本発明の一実施形態に係る配信システムについて図面を参照しながら説明する。
　図１は、本実施形態に係る配信システム１の全体構成を示した図である。配信システム１は、Ｎ台のクライアント装置１００（１００－１、１００－２、・・、１００－Ｎ）と、各クライアント装置１００のプロキシであるプロキシサーバ２００（２００－１、２００－２、・・、２００－Ｎ）と、配信サーバ３００と、配信サーバ３００のプロキシサーバ２５０と、を含むシステムである。
　図１に示すように、配信システム１では、プロキシサーバ２５０と、配信サーバ３００と、により配信側ネットワーク（ＬＡＮ）が形成され、クライアント装置１００－１～１００－Ｎと、プロキシサーバ２００－１～２００－Ｎと、により、再生側ネットワーク（ＬＡＮ）が形成されている。また、２つのＬＡＮは、基幹ネットワーク５００により隔てられており、基幹ネットワーク５００には各プロキシサーバ２００－１～２００－Ｎ、２５０が接続されている。
　なお、本実施形態では、基幹ネットワーク５００は、プロキシサーバ２００とプロキシサーバ２５０と間にルーターが介在しないネットワークを想定している。
　また、配信システム１では、配信サーバ３００が複数のチャンネルの映像コンテンツを配信可能になっている。そして、クライアント装置１００では、図示しない操作部を介してチャンネルの指定をユーザから受けると、指定されたチャンネルの映像コンテンツ（以下、「対象映像コンテンツ」とも称する）が配信サーバ３００から配信されるようになっている。クライアント装置１００からの配信要求、および配信サーバ３００から配信される映像コンテンツは、まず、対応するプロキシサーバに向けて送信されるようになっている。
　図２は、配信システム１において、配信サーバ３００からクライアント装置１００－１～１００－Ｎに映像コンテンツが配信されている間の各装置間の通信処理を模式的に示した図である。図２において右向きおよび左向きの細い矢印はＨＴＴＰプロトコル（すなわち、ユニキャスト通信）による映像コンテンツの要求および応答を示している。また、図２において、太い矢印はマルチキャスト通信による映像コンテンツの伝送を示している。
　図２に示すように、配信システム１では、各ＬＡＮ内では、データ伝送プロトコルの１つであるHTTP（Hypertext Transfer Protocol）プロトコルのリクエスト・レスポンスの仕組みを用いて、映像コンテンツが送信される。また、このとき、映像コンテンツは、HTTPプロトコルで規定されているMIMEマルチパート形式（単に「マルチパート形式」と称する）でやりとりされる。
　さらに、図２に示すように、配信システム１では、基幹ネットワーク内において、映像コンテンツがマルチキャスト通信により配信されるようになっている。マルチキャスト通信を用いることにより、プロキシサーバ２５０は、データ（映像コンテンツのパケット）を一度送信するだけで、当該データを、送信先のマルチキャストグループに属する複数のプロキシサーバ２００に向けて配信できるようになっている。
　以下では、図３を参照しながら、クライアント装置１００、プロキシサーバ２００、プロキシサーバ２５０および配信サーバ３００についての詳細な構成を説明する。
　（クライアント装置１００）
　クライアント装置１００は、ＨＴＴＰ処理部１０１および再生部１０２を備えている。
　ＨＴＴＰ処理部１０１は、後述するメディアセグメント（映像コンテンツを一定時間ごとに分割して得られる各単位、各図中において単に「ＭＳ」とも略称する）単位で、映像コンテンツの配信要求（リクエストメッセージ）をプロキシサーバ２００に送信する。
　また、ＨＴＴＰ処理部１０１は、映像コンテンツをメディアセグメント単位で、後述するムービーフラグメント（フラグメント）を各パートとするマルチパート形式のレスポンスメッセージとしてプロキシサーバ２００から受信する。
　再生部１０２は、ＨＴＴＰ処理部１０１が受信した各メディアセグメントを読み出すことにより映像コンテンツを再生する。
　（プロキシサーバ２００）
　プロキシサーバ２００は、ＨＴＴＰ処理部２０１、キャッシュ部２０２、およびマルチキャスト処理部２０３を備えている。
　ＨＴＴＰ処理部２０１は、クライアント装置１００から受信した配信要求を、プロキシサーバ２００を送信元としてプロキシサーバ２５０に転送したり、配信要求を受けたデータをキャッシュ部２０２から読み出してクライアント装置１００に送信したりする。
　キャッシュ部２０２は、データを保持するキャッシュメモリである。
　マルチキャスト処理部２０３は、マルチキャストグループへの参加およびマルチキャストグループからの離脱をプロキシサーバ２５０に要求する。また、マルチキャスト処理部２０３は、マルチキャスト通信により伝送されてきたデータを受信してＨＴＴＰレスポンスメッセージの形式に変換する。
　（プロキシサーバ２５０）
　プロキシサーバ２５０は、ＨＴＴＰ処理部２５１、キャッシュ部２５２、マルチキャスト処理部２５３、およびマルチキャストグループ情報記憶部２５４を備えている。
　ＨＴＴＰ処理部２５１は、プロキシサーバ２００から受信した配信要求を配信サーバ３００に中継する。また、ＨＴＴＰ処理部２５１は、所定の台数以上の通信装置に対象映像コンテンツを配信中の場合に、配信サーバ３００から送られてきた対象映像コンテンツのレスポンスメッセージに、対象映像コンテンツをマルチキャスト配信可能であることを示すヘッダ情報を付加した上でプロキシサーバ２００に中継する。
　さらに、ＨＴＴＰ処理部２５１は、対象映像コンテンツをマルチキャスト配信すべきマルチキャストグループ（以下、「対象マルチキャストグループ」とも称する）に所属するプロキシサーバ２００が存在する場合（すなわち、対象映像コンテンツをマルチキャスト配信すべきプロキシサーバ２００が存在する場合）には、プロキシサーバ２５０自身をリクエスト元として対象映像コンテンツの各メディアセグメントのレスポンスメッセージを配信サーバ３００から順に取得し、キャッシュ部２５２にキャッシュするようになっている。
　キャッシュ部２５２は、データを保持するキャッシュメモリである。キャッシュ部２５２は、配信サーバ３００から送信されたレスポンスメッセージを保持する。
　マルチキャスト処理部２５３は、対象マルチキャストグループへの参加の要求をプロキシサーバ２００－ｉ（ｉ：１～Ｎの任意の値）から受け付けると、プロキシサーバ２００－ｉのアドレスを対象マルチキャストグループに所属しているものとしてマルチキャストグループ情報記憶部２５４に記録する。また、マルチキャスト処理部２５３は、対象マルチキャストグループからの離脱の要求をプロキシサーバ２００－ｉから受け付けると、対象マルチキャストグループに所属しているものとして記録されているプロキシサーバ２００－ｉのアドレスをマルチキャストグループ情報記憶部２５４から削除する。
　さらに、マルチキャスト処理部２５３は、対象映像コンテンツをマルチキャスト配信すべきプロキシサーバ２００が存在する場合、キャッシュ部２５２に記録されているＨＴＴＰのレスポンスメッセージを、順次、マルチキャスト配信可能な形式のパケット（図１０および図１１を参照して後述する）に変換してマルチキャスト配信すべきプロキシサーバ２００に配信する。
　マルチキャストグループ情報記憶部２５４は、不揮発性のメモリである。マルチキャストグループ情報記憶部２５４は、映像コンテンツ毎に定められた複数のマルチキャストグループの各々について、当該マルチキャストグループに所属する送信先の通信装置のアドレスを保持するようになっている。
　（配信サーバ３００）
　配信サーバ３００は、ＨＴＴＰ処理部３０１およびメモリ部３０２を備えている。
　ＨＴＴＰ処理部３０１は、配信要求された映像コンテンツのメディアセグメントをメモリ部３０２から読み出して、ムービーフラグメントを各パートとするマルチパート形式のレスポンスメッセージとしてプロキシサーバ２５０に送信する。
　メモリ部３０２は、複数のチャンネルの映像コンテンツを保持している。
　以上、クライアント装置１００、プロキシサーバ２００、２５０および配信サーバ３００の詳細な構成について説明したが、配信システム１の動作を説明する前に、前述したムービーフラグメントおよびメディアセグメントについて図４および図５を参照しながら以下に説明する。
　（メディアセグメントおよびムービーフラグメントについて）
　最初に図４を参照しながらムービーフラグメントについて説明する。
　図４は、映像コンテンツのビットストリーム(Contents.mp4)と、ビットストリームを分割・格納した各ムービーフラグメントと、の関係を模式的に示した図である。また、図５は、メディアセグメントと、メディアセグメントを構成する各ムービーフラグメントと、の関係を模式的に示した図である。
　図４に示すように、ビットストリームは、分割されて複数のムービーフラグメントに格納される。図中、mdatが分割されたビットストリームデータである。各ムービーフラグメントは、ビットストリームを一定期間単位で区切った単位部分に対応している。本実施形態では、ムービーフラグメントとして、ISO Media File Format で規定されるフラグメント映像形式を想定している。
　MP4ファイルのビットストリームにおける先頭のムービーフラグメント（フラグメント１）には、moovヘッダ４１ｂが含まれている。moovヘッダ４１ｂは、映像を再生するためのビットストリーム全体に関するメタ情報（初期化情報など）を保持するようになっている。MP4ファイルのビットストリームにおける後続のムービーフラグメント（フラグメント２、３、・・）には、moofヘッダ４２ｂが含まれている。各ムービーフラグメントのmoofヘッダ４２ｂは、当該ムービーフラグメントの映像を再生するためのメタ情報をヘッダである。
　そして、各ムービーフラグメントには、ヘッダの他にメディアデータ（映像自体のデータ）mdatが含まれている。各ムービーフラグメントのメディアデータmdatには、該ムービーフラグメントに対応する期間における部分データがそれぞれ格納されている。例えば、フラグメントが１秒単位でビットストリームを区切ったデータである場合、フラグメント１のメディアデータmdatには、映像コンテンツの再生開始から１秒間分の映像データが格納されている。
　次に図５を参照しながらメディアセグメントについて説明する。
　図５に示すように、メディアセグメントは複数のムービーフラグメントから構成されている。メディアセグメントも、コンテンツデータを一定期間単位で区切った単位部分に対応している。さらに、本実施形態では、このメディアセグメントを、１つのレスポンスデータに格納されるコンテンツデータとして扱う。即ち、メディアセグメントは、一度のリクエストで獲得されるコンテンツデータの単位となっている。
　また、メディアセグメントが複数のムービーフラグメントから構成されることからわかるように、１つのメディアセグメントに対応する期間の長さは、１つのムービーフラグメントに対応する期間の長さの整数倍となっている（ただし、これはムービーフラグメントの長さが固定の場合であり、ムービーフラグメントの長さが可変の場合は整数倍には限られない）。なお、次に説明する動作例では、１つのメディアセグメントに対応する期間を３０秒とし、１つのムービーフラグメントに対応する期間の長さを１秒として説明する。
　（配信システム１の動作例１）
　次に、クライアント装置１００が対象映像コンテンツの配信要求を出してからクライアント装置１００への対象映像コンテンツの配信が完了するまでに配信システム１で行われる動作の一具体例について図６～図１２を参照しながら説明する。
　図６および図７は、それぞれ、上記動作の前半部分および後半部分を示すシーケンス図である。
　なお、この動作例では、プロキシサーバ２５０のＨＴＴＰ処理部２５１は、４台以上の装置に対象映像コンテンツを配信中の場合に限り、マルチキャスト配信可能であることを示すヘッダ情報を付加するようになっている。また、動作の開始前に、すでに３台のクライアント装置１００－２～１００－４に対象映像コンテンツを配信中であるものとし、新たにクライアント装置１００－１が対象映像コンテンツの配信要求を出すものとする。
　最初に、クライアント装置１００－１は、対象映像コンテンツの先頭のメディアセグメントを要求するＨＴＴＰのリクエスト４１（第１の要求）をプロキシサーバ２００－１に送信する（Ｓ０１）。このリクエスト４１は、図８（ａ）に示すようなデータであるが、図８（ａ）からわかるように、クライアント装置１００－１は、プロキシサーバ２００－１とキープアライブで接続するようになっている。すなわち、クライアント装置１００－１は、リクエスト４１に対するレスポンスの受信後も接続状態を保つようになっている。
　次に、プロキシサーバ２００－１のＨＴＴＰ処理部２０１は、クライアント装置１００－１から受信したリクエスト４１を、自身のＩＰアドレスを送信元として設定した上でプロキシサーバ２５０に送信する（Ｓ０２）。そして、プロキシサーバ２５０のＨＴＴＰ処理部２５１は、配信サーバ３００にキープアライブにより接続し、リクエスト４１を配信サーバ３００に中継する（Ｓ０３）。
　リクエスト４１を受けた配信サーバ３００のＨＴＴＰ処理部３０１は、メモリ部３０２から対象映像コンテンツを読み出し、図８（ｂ）に示すようなレスポンスメッセージ５１を生成してプロキシサーバ２５０に送信する（Ｓ０４）。
　図８（ｂ）において、レスポンスメッセージ５１内の”www.sample.com”は配信サーバ３００のホストドメイン名を示しており、”content1”は対象映像コンテンツのファイル名を示している。また、X-Segment-Fragment-Index:1/60は、メディアセグメントのインデックス値を示している。すなわち、X-Segment-Fragment-Index:1/60は、対象映像コンテンツが６０個のメディアセグメントから構成され、このレスポンスメッセージが１つ目のメディアセグメントのデータであることを示している。
　さらに、「{binary-data:fragment-01}」～「{binary-data:fragment-30}」の部分は、１つ目のメディアセグメントを構成する３０個のムービーフラグメントを示している。
　レスポンスメッセージ５１を受信したプロキシサーバ２５０のＨＴＴＰ処理部２５１は、対象映像コンテンツのクライアント装置１００からの要求頻度を確認する（Ｓ０５）。すなわち、ＨＴＴＰ処理部２５１は、一定期間内に同一の対象映像コンテンツに対するリクエスト４１を何回受信したかをカウントする。ここでは、クライアント装置１００の台数がクライアント装置１００－１～１００－４の４台であり要求頻度が一定以上であるため、レスポンスメッセージ５１にマルチキャスト配信可能であることを示すヘッダ情報を付加することにより図９（ａ）に示すようなレスポンスメッセージ５１ａを生成する（Ｓ０６）。
　図９（ａ）において破線の枠で囲んだ文字列（”X-alternative-cast”から始まる文字列）は、付加したヘッダ情報を示している。
　X-alternative-castのヘッダ情報は、次の書式を取るようになっている。
<配信形式>://<配信アドレス＞/<TTL>?session_id=<セッションID>?session_name=<セッション名>
　ここで、<配信形式>は、コンテンツの配信方法を示しており、図９（ａ）では、マルチキャスト配信である“multicast”を示している。また、配信形式がマルチキャスト配信である場合における＜配信アドレス＞（図９（ａ）で”224.1.1.1”）は、マルチキャストアドレスを示している。マルチキャストアドレスは、一般的に、クラスＤのIPマルチキャストグループアドレスを記述する。
　また、＜ＴＴＬ＞は、パケットの有効期間(time to live)を示している。これは、ネットワーク内の伝達範囲を設定する。プロキシサーバ２００とプロキシサーバ２５０との間にルーターが含まれているネットワークにおいて、ルーターを超えてマルチキャストデータを配信する際に＜ＴＴＬ＞を大きな値に設定する必要があるが、本実施形態では、基幹ネットワーク５００にルーターが介在しないので＜ＴＴＬ＞の値は”1”となっている。また、＜セッションID>および<セッション名>は、セッションを識別するために用いられる。
　Ｓ０６の処理の後、ＨＴＴＰ処理部２５１は、生成したレスポンスメッセージ５１ａをプロキシサーバ２００－１に送信する（Ｓ０７）。
　レスポンスメッセージ５１ａを受信したプロキシサーバ２００－１のＨＴＴＰ処理部２０１は、”X-alternative-cast”のヘッダ情報があることを確認すると（Ｓ０８）、その旨をマルチキャスト処理部２０３に通知するとともに、レスポンスメッセージ５１ａを元のレスポンスメッセージ５１に変換してクライアント装置１００－１に送信する（Ｓ０９）。なお、レスポンスメッセージ５１を受信したクライアント装置１００－１の再生部１０２は、対象映像コンテンツの再生を開始することになる。
　その後、プロキシサーバ２００－１のＨＴＴＰ処理部２０１は、図９（ｂ）に示すようなマルチキャスト受信要求（対象マルチキャストグループへの参加を要求するJOINメッセージ４２）をプロキシサーバ２５０に送信する（Ｓ１０）。JOINメッセージ４２（第２の要求）および後述するLEAVEメッセージ４３は、図９（ｂ）および図９（ｃ）に示すように、ＧＥＴリクエスト形式のＨＴＴＰメッセージである。JOINメッセージ４２およびLEAVEメッセージ４３のヘッダ部のX-alternative-multicast-set ヘッダには、それぞれ、マルチキャストグループへの参加を示す文字列、および、マルチキャストグループからの離脱を示す文字列が付与される。すなわち、JOINメッセージ42には”JOIN”が付与され、LEAVEメッセージ43には”LEAVE”が付与される。
　JOINメッセージ４２を受信したプロキシサーバ２５０のＨＴＴＰ処理部２５１は、レスポンスメッセージを返却するとともに、プロキシサーバ２００－１のアドレスを対象マルチキャストグループに所属するものとしてマルチキャストグループ情報記憶部２５４に記録する（Ｓ１１）。
　一方、Ｓ１０でJOINメッセージを受信したＨＴＴＰ処理部２５１は、対象映像コンテンツのメディアセグメントを取得して（Ｓ１２）、キャッシュ部２５２に記録する（Ｓ１３）。Ｓ１２およびＳ１３の処理は、その後繰り返し行われる。すなわち、対象映像コンテンツを構成する全メディアセグメントについてＳ１２およびＳ１３の処理が行われる。なお、Ｓ１２の処理を繰り返す周期は特に限定されない。すなわち、１つのメディアセグメントのクライアント装置１００における再生時間よりも短い周期でＳ１２の処理を繰り返せばよい。
　一方、ステップＳ１１の処理を終えた後、マルチキャスト処理部２５３は、キャッシュ部２５２に記録されたメディアセグメントのレスポンスメッセージ５１を順次、マルチキャストのパケットに変換する（Ｓ１４）。
　ここで、Ｓ１４の処理の詳細について図１０および図１１を参照しながら以下に説明する。
　最初にマルチキャストパケットのフォーマットについて図１０を参照して説明する。
　マルチキャストパケットは、図１０（ｃ）に示すように、ＵＤＰヘッダ部と、ＲＴＰヘッダ部と、ＲＴＰデータ部と、を含んでいる。マルチキャストパケットのより具体的な構造を図１０（ａ）および図１０（ｂ）を参照して説明すると以下の通りである。
　図１０（ａ）は、マルチキャストのパケットを構成するＵＤＰパケットのフォーマットを示している。ＵＤＰパケットのＵＤＰヘッダ部には、マルチキャストパケットの送信元のポート番号、マルチキャストパケットの送信先のポート番号、ＵＤＰパケットのパケット長、パケットの整合性を取るためのチェックサムのフィールドがある。ＵＤＰパケットのデータ部は可変長になっている。
　図１０（ｂ）はＵＤＰパケットのデータ（データグラム）部分を構成するＲＴＰパケットのフォーマットを示している。ＲＴＰパケットのＲＴＰデータ部（ペイロードデータ）には、レスポンスメッセージ５１の一部が記録されるようになっている。
　また、ＲＴＰパケットのＲＴＰヘッダ部には、マルチキャストパケットの送信順序を示すシーケンス番号と、タイムスタンプと、が格納される。ここで、ＲＴＰパケットのタイムスタンプには、該ＲＴＰパケットのＲＴＰデータ部にその一部が含まれるレスポンスメッセージ５１のうち、最も小さいタイムスタンプ(X-timestamp)の値が格納される。例えば、ＲＴＰデータ部に２つ目のメディアセグメントに対応するレスポンスメッセージ５１の一部が含まれる場合、ＲＴＰヘッダ部のタイムスタンプには「３０」が格納される。
　次に、図１１を参照して、マルチキャスト処理部２５３がＨＴＴＰのレスポンスメッセージ５１をどのようにマルチキャストパケットに変換するかについて具体的に説明する。
　図１１中の左側部分は、変換後のマルチキャストパケット５２－１、５２－２、５２－３、・・・を模式的に示している。また、図１１中の右側部分は、ＨＴＴＰのレスポンスメッセージ５１（５１－１、５１－２・・・）内のヘッダ部分のデータとボデイ部分の各パートのデータとがどのマルチキャストパケットにペイロードデータとして格納されるかを模式的に示している。
　マルチキャスト処理部２５３は、メディアセグメントのレスポンスメッセージ５１－１をキャッシュ部２５２から読み出すと、レスポンスメッセージ５１のContent-Locationヘッダの文字列中で「対象映像コンテンツのファイル名」および「メディアセグメントのインデックス値」の部分（すなわち、”/content1/1”）を抽出して、最初のマルチキャストパケット５２－１にペイロードデータとして格納する。
　そして、マルチキャスト処理部２５３は、メッセージ５１－１のうち、ヘッダ部分を次のマルチキャストパケット５２－２にペイロードデータとして格納する。
　さらに、マルチキャスト処理部２５３は、メッセージ５１－１のボディ部分のデータを後続するマルチキャストパケット５２－３・・にペイロードデータとして格納していく。より具体的には、マルチキャスト処理部２５３は、各パートに含まれるムービーフラグメントを、ムービーフラグメントのデータサイズに応じて１または複数のマルチキャストパケット５２に格納する。マルチキャスト処理部２５３は、メッセージ５１－２以降の各メッセージ５１についても同様の処理を行う。
　なお、各パートに含まれるムービーフラグメントのバイナリデータは先頭部分がマルチキャストパケット５２のペイロードの先頭部分と必ず一致するようにマルチキャストパケット５２に格納される。同様に、各パートに含まれるムービーフラグメントのバイナリデータは末尾部分がマルチキャストパケット５２のペイロードの末尾部分と必ず一致するようにマルチキャストパケット５２に格納される。すなわち、複数のムービーフラグメントのバイナリデータが１つのマルチキャストパケットに格納されないようになっている。
　また、マルチキャスト処理部２５３は、マルチキャストパケットのヘッダ部分には、前述したＵＤＰヘッダ部、ＲＴＰヘッダ部、およびＲＴＰデータ部に適切な値を格納する他、ＩＰヘッダ部にＩＰマルチキャストアドレス（マルチキャストグループアドレス）である”224.1.1.1”を格納するようになっている。
　マルチキャスト処理部２５３は、以上のようにして変換したマルチキャストパケット５２を、順次、プロキシサーバ２００－１に配信する（Ｓ１５）。
　プロキシサーバ２００－１のマルチキャスト処理部２０３は、Ｓ１５にて配信された複数のマルチキャストパケット５２をまとめて、メディアセグメントのレスポンスメッセージ５１に変換し（Ｓ１６）、キャッシュ部２０２にキャッシュする（Ｓ１７）。Ｓ１５～Ｓ１７の処理は、その後繰り返し行われる。すなわち、対象映像コンテンツを構成する全メディアセグメントについてＳ１２およびＳ１３の処理が行われる。
　一方、クライアント装置１００－１は、続けて、対象映像コンテンツの２番目のメディアセグメントを要求するＨＴＴＰのリクエスト４１をプロキシサーバ２００－１に送信する（Ｓ１８）。
　リクエスト４１を受信したプロキシサーバ２００－１のＨＴＴＰ処理部２０１は、２番目のメディアセグメントのレスポンスメッセージ５１をキャッシュ部２０２から読み出す（Ｓ１９）。なお、ＨＴＴＰ処理部２０１は、読み出しを試行した時点でキャッシュ部２０２にレスポンスメッセージ５１がキャッシュされていない場合、レスポンスメッセージ５１がキャッシュされるまで待機してから読み出す。
　レスポンスメッセージ５１を読み出したＨＴＴＰ処理部２０１は、レスポンスメッセージ５１をクライアント装置１００－１に送信する。このＳ１８、Ｓ１９の処理も、続きの３番目以降のメディアセグメントに対して順次行われる。
　その後、配信サーバ３００が最後のメディアセグメントを要求するリクエスト４１をプロキシサーバ２５０から受け付けたものとする。
　配信サーバ３００のＨＴＴＰ処理部３０１は、最後のメディアセグメントのレスポンスメッセージとして、通常のレスポンスメッセージ５１のヘッダ部に”Connection:Close”のヘッダを付加したレスポンスメッセージ５１’をプロキシサーバ２５０に送信する（Ｓ２０）。
　ＨＴＴＰ処理部２５１は、レスポンスメッセージ５１’のヘッダ部に”Connection:Close”の文字列があることを確認すると、配信サーバ３００との接続状態が解除されたことを認識する（Ｓ２１）。
　そして、マルチキャスト処理部２５３は、キャッシュ部２５２にキャッシュされたレスポンスメッセージ５１’をマルチキャストパケット５２に変換してプロキシサーバ２００－１に送信する（Ｓ２２）。
　プロキシサーバ２００－１のマルチキャスト処理部２０３は、Ｓ２２にて配信された複数のマルチキャストパケット５２をまとめて、メディアセグメントのレスポンスメッセージ５１’に変換し、キャッシュ部２０２にキャッシュする。なお、マルチキャスト処理部２０３は、キャッシュしたレスポンスメッセージ５１’のヘッダ部に”Connection:Close”のヘッダがあることを確認する。
　クライアント装置１００－１は、続きのメディアセグメントを要求するＨＴＴＰのリクエスト４１をプロキシサーバ２００－１に送信すると、リクエスト４１を受信したプロキシサーバ２００－１のＨＴＴＰ処理部２０１は、そのメディアセグメントのレスポンスメッセージ５１’をキャッシュ部２０２から読み出す。
　レスポンスメッセージ５１’を読み出したＨＴＴＰ処理部２０１は、ヘッダ部に”Connection:Close”のヘッダがあることを確認すると（Ｓ２３）、レスポンスメッセージ５１’をクライアント装置１００－１に送信するとともにクライアント装置１００－１との接続状態を解除する（Ｓ２４）。これにより、クライアント装置１００－１は、プロキシサーバ２００との接続状態が解除されたことを認識する。したがって、再生部１０２が、このレスポンスメッセージ５１’のメディアセグメント（すなわち、対象映像コンテンツの最後のメディアセグメント）の再生を終えた時点で、対象映像コンテンツの再生が完了することになる。
　一方、レスポンスメッセージ５１’のヘッダ部に”Connection:Close”のヘッダがあることを確認したマルチキャスト処理部２０３は、その旨をＨＴＴＰ処理部２０１に通知し、ＨＴＴＰ処理部２０１は、図９（ｃ）に示すようなマルチキャスト受信終了通知（対象マルチキャストグループからの離脱を要求するLEAVEメッセージ）４３をプロキシサーバ２５０に送信する。
　LEAVEメッセージ４３を受信したプロキシサーバ２５０のＨＴＴＰ処理部２５１は、レスポンスを返却し、受信したメッセージがLEAVEメッセージ４３であることを確認する（Ｓ２６）。
　そして、ＨＴＴＰ処理部２５１は、対象マルチキャストグループに所属するものとして記録されている、マルチキャストグループ情報記憶部２５４内のプロキシサーバ２００－１のアドレスを削除する（Ｓ２７）。これにより、プロキシサーバ２００－１が対象映像コンテンツをマルチキャスト配信すべきマルチキャストグループから外れることになる。
　なお、同様に、クライアント装置１００－２～１００－４およびプロキシサーバ２００－２～２００－４に対しても、Ｓ２２以降の処理が施される。すなわち、クライアント装置１００－２～１００－４においても対象映像コンテンツの映像再生が完了し、プロキシサーバ２００－２～２００－４が対象映像コンテンツをマルチキャスト配信すべきマルチキャストグループから外れることになる。
　このようにして、対象マルチキャストグループに所属していた全装置が所属から外れるので、対象マルチキャストグループのマルチキャストグループアドレスとして使用していた”224.1.1.1”を別の映像コンテンツをマルチキャスト配信する際に使用できることになる。
　以上、配信システム１の動作例を図６および図７のシーケンス図を用いて説明した。
　ところで、Ｓ２３にて、ＨＴＴＰ処理部２０１およびマルチキャスト処理部２０３が、レスポンスメッセージ５１’のヘッダ部に”Connection:Close”のヘッダがあることを確認するものとした。これに代えて、ＨＴＴＰ処理部２０１およびマルチキャスト処理部２０３は、ヘッダ部のX-Media-Segment-indexヘッダを参照し、メディアセグメントのインデックス値（図８（ｂ）において”1”）と、対象映像コンテンツを構成するメディアセグメントの個数を示す値(図８（ｂ）において”60”)が同値になったか否かを確認するようにしてもよい。そして、同値である場合、ＨＴＴＰ処理部２０１は、その旨をマルチキャスト処理部２０３に通知することにより、マルチキャスト処理部２０３にLEAVEメッセージを送信させてもよい。
　（クライアント装置で映像コンテンツの再生を中断した場合の配信システム１の動作）
　次に、ユーザからの再生中断指示によって、クライアント装置１００－１が対象映像コンテンツの再生を中断する場合の配信システム１の動作について図１３を参照しながら以下に説明する。ここでは、クライアント装置１００－１が配信サーバ３００から対象映像コンテンツの配信を受けている唯一の装置であることを前提として説明する。
　図１３は、映像コンテンツの再生を中断する旨の指示をクライアント装置１００－１がユーザから受けた場合における、各装置間の処理の流れを示すシーケンス図である。
　図１３に示すように、図示しない操作部を通じて再生中断指示を受け付けると、クライアント装置１００－１の再生部１０２は対象映像コンテンツの再生を中断する。また、ＨＴＴＰ処理部１０１は、次のメディアセグメントを要求するＨＴＴＰのリクエスト４１のヘッダ部に”Connection:Close”のヘッダを付加したリクエスト４１’をプロキシサーバ２００－１に送信する（Ｓ２８）。
　リクエスト４１’を受信したプロキシサーバ２００－１のＨＴＴＰ処理部２０１は、リクエスト４１’のヘッダ部に”Connection:Close”のヘッダが付加されていることを確認する（Ｓ２９）。そして、ＨＴＴＰ処理部２０１は、メディアセグメントのレスポンスメッセージ５１をキャッシュ部２０２から読み出して、クライアント装置１００－１に送信するとともに、クライアント装置１００－１との接続状態を解除する。
　また、”Connection:Close”のヘッダが付加されていることを確認したＨＴＴＰ処理部２０１は、付加されている旨をマルチキャスト処理部２０３に通知する（Ｓ３０）。加えて、ＨＴＴＰ処理部２０１は、図９（ｃ）に示すような対象マルチキャストグループからの離脱を要求するLEAVEメッセージ４３をプロキシサーバ２５０に送信する（Ｓ３１）。
　LEAVEメッセージ４３を受信したプロキシサーバ２５０のＨＴＴＰ処理部２５１は、レスポンスをプロキシサーバ２００に返却するとともに、受信したメッセージがLEAVEメッセージ４３であることを確認する（Ｓ３２）。
　そして、ＨＴＴＰ処理部２５１は、対象マルチキャストグループに所属するものとして記録されている、マルチキャストグループ情報記憶部２５４内のプロキシサーバ２００－１のアドレスを削除する（Ｓ３３）。これにより、プロキシサーバ２００－１が対象映像コンテンツをマルチキャスト配信すべきマルチキャストグループから外れることになる。
　対象マルチキャストグループに所属する装置が存在しなくなると、マルチキャスト処理部２５３は、ＨＴＴＰ処理部２５１にその旨を通知する。そして、ＨＴＴＰ処理部２５１は、ヘッダ部に”Connection:Close”のヘッダを付加してHTTPメッセージを配信サーバ３００に送信する（Ｓ３４）。これにより、配信サーバ３００とプロキシサーバ２５０との接続状態が解除されることになる。
　以上、配信システム１全体の処理の流れを動作例として説明したが、以下では、配信システム１を構成する各装置の動作について図１４～図２２を参照しながら説明する。
　〔プロキシサーバ２００の動作〕
　最初に、クライアント装置１００のプロキシサーバ２００の動作について説明するが、ＨＴＴＰ処理部２０１とマルチキャスト処理部２０３とに分けて動作を説明する。
　（ＨＴＴＰ処理部２０１の動作）
　ＨＴＴＰ処理部２０１の動作について図１４を参照しながら説明する。図１４は、ＨＴＴＰ処理部２０１の動作を示すフローチャートである。
　図１４に示すように、ＨＴＴＰ処理部２０１は、クライアント装置１００からメディアセグメントのリクエスト４１を受信する（Ｓ１１０１）。
　次に、ＨＴＴＰ処理部２０１は、キャッシュ部２０２に何らかのデータがキャッシュされているか否かを判定する（Ｓ１１０２）。
　キャッシュ部２０２に何らかのデータがキャッシュされていると判定した場合（Ｓ１１０２においてＹＥＳ）、ＨＴＴＰ処理部２０１は、Ｓ１１０１にて受信したリクエスト４１からリクエストＵＲＩ（図８（ａ）の例では”/content1/1”）を読み出す（Ｓ１１０７）。そして、ＨＴＴＰ処理部２０１は、このリクエストＵＲＩに対応するレスポンスメッセージ（図８（ａ）の例の”/content1/1”に対応するレスポンスメッセージは、ファイル名がcontent1であるような対象映像コンテンツの先頭メディアセグメントのレスポンスメッセージ）をキャッシュ部２０２から読み出す（Ｓ１１０８）。その後、Ｓ１１０９に進む。
　一方、キャッシュ部２０２に何もデータがキャッシュされていないと判定した場合（Ｓ１１０２においてＮＯ）、ＨＴＴＰ処理部２０１は、リクエスト４１をプロキシサーバ２５０に送信し（Ｓ１１０３）、その後、対応するレスポンスメッセージをプロキシサーバ２５０から受信する（Ｓ１１０４）。
　ＨＴＴＰ処理部２０１は、受信したレスポンスメッセージにプロキシサーバ２５０がマルチキャスト通信により該コンテンツを送信可能であることを示すヘッダ情報（X-alternative-castヘッダ）が含まれているか否かを判定する（Ｓ１１０５）。含まれていないと判定した場合（Ｓ１１０５においてＮＯ）、Ｓ１１０９に進み、含まれていると判定した場合（Ｓ１１０５においてＹＥＳ）、Ｓ１１０６に進む。
　Ｓ１１０６において、ＨＴＴＰ処理部２０１は、マルチキャスト受信を行うための指示（受信するマルチキャストアドレスの通知）を行い、Ｓ１１１８にて、JOINメッセージの送受信をプロキシサーバ２５０と行い、Ｓ１１１０に進む。
　Ｓ１１０９において、ＨＴＴＰ処理部２０１は、クライアント装置１００に送信すべきレスポンスメッセージを生成し、Ｓ１１１０に進む。
　Ｓ１１１０において、ＨＴＴＰ処理部２０１は、Ｓ１１０１にて受信したリクエスト４１に通信終了通知（”Connection:Close”ヘッダ）が含まれているか否かを判定する。通信終了通知が含まれていると判定した場合（Ｓ１１１０においてＹＥＳ）、ＨＴＴＰ処理部２０１は、マルチキャスト受信の終了をマルチキャスト処理部２０３に通知し（Ｓ１１１１）、Ｓ１１１２に進む。一方、通信終了通知が含まれていないと判定した場合（Ｓ１１１０においてＮＯ）、Ｓ１１１２に進む。
　Ｓ１１１２において、ＨＴＴＰ処理部２０１は、Ｓ１１０４にて受信したレスポンスに通信終了通知（”Connection:Close”ヘッダ）が含まれているか否かを判定する。通信終了通知が含まれていると判定した場合（Ｓ１１１２においてＹＥＳ）、Ｓ１１１９に進む。Ｓ１１１９において、ＨＴＴＰ処理部２０１は、LEAVEメッセージ４３の送受信をプロキシサーバ２５０と行い、Ｓ１１１５に進む。
　一方、通信終了通知が含まれていないと判定した場合（Ｓ１１１０においてＮＯ）、Ｓ１１１３に進む。Ｓ１１１３において、ＨＴＴＰ処理部２０１は、Ｓ１１０４にて受信したレスポンスが最後のメディアセグメントのレスポンスであるか否かを判定する（Ｓ１１３）。すなわち、ヘッダ部のX-Media-Segment-indexヘッダを参照し、メディアセグメントのインデックス値と、対象映像コンテンツを構成するメディアセグメントの個数を示す値と、が同値であるか否かを判定する。
　最後のメディアセグメントであると判定した場合（Ｓ１１１３においてＹＥＳ）、Ｓ１１１５に進む。一方、最後のメディアセグメントでないと判定した場合（Ｓ１１１３においてＮＯ）、Ｓ１１０９にて生成したレスポンスメッセージをそのままクライアント装置１００に送信し（Ｓ１１１４）、Ｓ１１０１に戻る。
　Ｓ１１１５において、ＨＴＴＰ処理部２０１は、Ｓ１１０９にて生成したレスポンスメッセージに通信終了通知を付加する（Ｓ１１１５）。そして、ＨＴＴＰ処理部２０１は、通信終了通知を含むレスポンスメッセージをクライアント装置１００に送信し（Ｓ１１１６）、クライアント装置１００との接続状態を解除して（Ｓ１１１７）、処理を終了する。
　（マルチキャスト処理部２０３の動作）
　マルチキャスト処理部２０３の動作について図１５を参照しながら説明する。なお、ここで説明する動作は、前述したＳ１１０６の処理をＨＴＴＰ処理部２０１が行った場合に開始される動作である。
　図１５は、マルチキャスト処理部２０３の動作を示すフローチャートである。最初に、マルチキャスト処理部２０３は、マルチキャスト受信を開始する旨の通知をＨＴＴＰ処理部２０１から受信する（Ｓ１２０１）。
　その後、マルチキャスト処理部２０３は、マルチキャストデータ受信のため、初期化を行う。具体的には、マルチキャスト配信を受けるため（プロキシサーバ２５０から定期的に送信されるクエリーに応答するため）に、ＨＴＴＰ処理部２０１からマルチキャストグループアドレスを取得する（Ｓ１２０２）。
　その後、マルチキャスト処理部２０３は、マルチキャストのパケットを順次受信し（Ｓ１２０３）、Ｓ１２０５にて受信した複数のパケットを、メディアセグメントのHTTP形式のレスポンスメッセージに変換する（Ｓ１２０４）。
　その後、マルチキャスト処理部２０３は、変換により得られたレスポンスメッセージをキャッシュ部２０２にキャッシュする（Ｓ１２０５）とともに、レスポンスメッセージに含まれているヘッダ部のX-Media-Segment-indexヘッダを参照する（Ｓ１２０６）。すなわち、メディアセグメントのインデックス値と、対象映像コンテンツを構成するメディアセグメントの個数を示す値と、が同値であるか否かを判定する。
　マルチキャスト処理部２０３が対象映像コンテンツの全データの受信を完了していない場合（Ｓ１２０７においてＮＯ）、すなわち、メディアセグメントのインデックス値と、対象映像コンテンツを構成するメディアセグメントの個数を示す値と、が同値でない場合、Ｓ１２０３に戻る。
　一方、マルチキャスト処理部２０３が対象映像コンテンツの全データの受信を完了した場合（Ｓ１２０７においてＹＥＳ）、Ｓ１２０８に進む。
　Ｓ１２０８において、マルチキャスト処理部２０３は、ＨＴＴＰ処理部２０１にマルチキャスト受信が終了した旨を通知し、処理を終了する。
　〔プロキシサーバ２５０の動作〕
　次に、配信サーバ３００のプロキシサーバ２５０の動作について説明するが、ＨＴＴＰ処理部２５１とマルチキャスト処理部２５３とに分けて動作を説明する。
　（ＨＴＴＰ処理部２５１の動作）
　ＨＴＴＰ処理部２５１の動作を図１６および図１８を参照して説明する。
　ＨＴＴＰ処理部２５１は、プロキシサーバ２００から対象映像コンテンツのメディアセグメントのリクエストを受信する（Ｓ１３０１）。
　次に、ＨＴＴＰ処理部２５１は、受信したリクエストを配信サーバ３００に送信し（Ｓ１３０２）、該リクエストに対応するレスポンスを配信サーバ３００から受信する（Ｓ１３０３）。
　ＨＴＴＰ処理部２５１は、対象映像コンテンツをすでにマルチキャスト配信中であるか否かを判定する（Ｓ１３０４）。すなわち、ＨＴＴＰ処理部２５１は、マルチキャストグループ情報記憶部２５４を参照し、対象マルチキャストグループに参加しているプロキシサーバ２００が存在するか否かを判定する。
　対象映像コンテンツをマルチキャスト配信中であると判定した場合（Ｓ１３０４においてＹＥＳ）、Ｓ１３０６に進む。一方、対象映像コンテンツをマルチキャスト配信中でないと判定した場合（Ｓ１３０４においてＮＯ）、Ｓ１３０５に進む。
　Ｓ１３０５において、ＨＴＴＰ処理部２５１は、対象映像コンテンツのクライアント装置１００からの要求頻度を確認する。このＳ１３０５の処理は、図６のＳ０５の処理と同じ処理である。すなわち、ＨＴＴＰ処理部２５１は、一定期間内に同一の対象映像コンテンツに対するリクエスト４１を何回受信したかをカウントする。ここで、ＨＴＴＰ処理部２５１は、リクエスト４１に含まれるURIのうちコンテンツのファイル名”content1”が同一であれば、同一の対象映像コンテンツに対するリクエストとしてカウントするようになっている。例えば、“content1/2”を含むリクエスト４１と、”content1/3“を含むリクエスト４１と、を受信した場合、両者が同一の対象映像コンテンツに対するリクエストとしてカウントされる。
　同一の対象映像コンテンツに対するリクエストを一定期間内に受信した回数が所定の回数以上である場合（Ｓ１３０５においてＹＥＳ）、Ｓ１３０６に進む。一方、同一の対象映像コンテンツに対するリクエストを一定期間内に受信した回数が所定の回数未満である場合（Ｓ１３０５においてＮＯ）、Ｓ１３０７に進む。
　Ｓ１３０６において、ＨＴＴＰ処理部２５１は、＜配信方式＞をマルチキャスト配信とするX-alternative-castヘッダを生成して、Ｓ１３０４にて配信サーバ３００から送信されたレスポンスメッセージのヘッダ部にX-alternative-castヘッダを付加する。ここで、X-alternative-castヘッダの＜配信アドレス＞は、すでに対象映像コンテンツをマルチキャスト配信中である場合、対象映像コンテンツの配信に使用しているマルチキャストグループアドレスとなる。一方、対象映像コンテンツをマルチキャスト配信中でない場合、ＨＴＴＰ処理部２５１は、＜配信アドレス＞として、未使用である任意のクラスＤのマルチキャストグループアドレスを使用する。
　Ｓ１３０７において、ＨＴＴＰ処理部２５１は、レスポンスメッセージをプロキシサーバ２００に送信し、Ｓ１３０８に進む。
　ＨＴＴＰ処理部２５１は、プロキシサーバ２００からJOINメッセージを受信した場合（Ｓ１３０８においてＹＥＳ）、対象映像コンテンツをすでにマルチキャスト配信中であるか否かを判定する（Ｓ１３０９）。対象映像コンテンツをすでにマルチキャスト配信中であると判定した場合（Ｓ１３０９においてＹＥＳ）、Ｓ１３１１に進む。また、プロキシサーバ２００から一定期間内にJOINメッセージを受信しなかった場合（Ｓ１３０８においてＮＯ）にも、Ｓ１３１１に進む。
　一方、対象映像コンテンツをすでにマルチキャスト配信中であると判定した場合（Ｓ１３０９においてＹＥＳ）、ＨＴＴＰ処理部２５１は、配信サーバ３００とキープアライブで接続し、配信サーバ３００から対象映像コンテンツの各レスポンスメッセージを取得する処理（図１８を用いて詳細を後述する）を開始する（Ｓ１３１０）。
　Ｓ１３１０において、ＨＴＴＰ処理部２５１は、配信サーバ３００から取得するレスポンスメッセージのヘッダ部に”Connection:Close”ヘッダが含まれているか否かを判定する（Ｓ１３１１）。
　”Connection:Close”ヘッダが含まれていると判定した場合（Ｓ１３１１においてＹＥＳ）、ＨＴＴＰ処理部２５１は、プロキシサーバ２００からLEAVEメッセージを受信するまで待機して（Ｓ１３１２）、受信後に処理を終了する。
　一方、”Connection:Close”ヘッダが含まれていないと判定した場合（Ｓ１３１１においてＮＯ）、Ｓ１３１３に進む。ＨＴＴＰ処理部２５１は、マルチキャスト処理部からマルチキャスト配信終了が通知されたか否かを判定する（Ｓ１３１３）。マルチキャスト配信終了が通知されていないと判定された場合（Ｓ１３１３においてＮＯ）、そのまま処理を終了する。
　一方、マルチキャスト配信終了が通知されたと判定した場合（Ｓ１３１３においてＹＥＳ）、ＨＴＴＰ処理部２５１は、配信サーバとの接続状態を解除し（Ｓ１３１４）、処理を終了する。
　前述した、配信サーバ３００から対象映像コンテンツの各レスポンスメッセージを取得する処理について、図１８を参照して説明する。
　最初に、ＨＴＴＰ処理部２５１は、配信サーバ３００から直前に受信したレスポンスメッセージに基づき、次に配信サーバ３００に送信すべきリクエストのＵＲＩを生成する（Ｓ１５０１）。例えば、配信サーバ３００から直前に受信したレスポンスメッセージのContent-Locationの末尾が”/content1/1”である場合、”/content1/2”をリクエストのＵＲＩとして生成する。
　次に、ＨＴＴＰ処理部２５１は、配信サーバ３００にリクエストを送信し（Ｓ１５０２）、配信サーバ３００からレスポンスを受信する（Ｓ１５０３）。
　そして、ＨＴＴＰ処理部２５１は、配信サーバ３００から受信したレスポンスを、Ｓ１５０２にて送信したリクエストのＵＲＩ情報と関連づけて、キャッシュ部２５２にキャッシュする（Ｓ１５０４）。
　最後に、ＨＴＴＰ処理部２５１は、対象映像コンテンツ(ファイル名が”content1”のコンテンツ)の全レスポンスメッセージを受信したか否かを判定する（Ｓ１５０５）。受信していないレスポンスメッセージがあると判定した場合（Ｓ１５０５においてＮＯ）、Ｓ１５０１に戻る。一方、全レスポンスメッセージを受信したと判定した場合（Ｓ１５０５においてＹＥＳ）、処理を終了する。
　（マルチキャスト処理部２５３の動作）
　マルチキャスト処理部２５３の動作について図１７を参照しながら説明する。なお、ここで説明する動作は、前述したＳ１３０８においてＨＴＴＰ処理部２５１がJOINメッセージを受信したときに開始される動作である。
　最初に、マルチキャスト処理部２５３は、JOINメッセージをＨＴＴＰ処理部２５１から取得する（Ｓ１４０１）。
　次に、マルチキャスト処理部２５３は、JOINメッセージに含まれている対象映像コンテンツのファイル名に基づいて対象マルチキャストグループを特定し、対象マルチキャストグループに、JOINメッセージを送信したプロキシサーバ２００のアドレスを登録する。（Ｓ１４０２）。
　次に、マルチキャスト処理部２５３は、キャッシュ部２５２からレスポンスメッセージを読み出して（Ｓ１４０３）、複数のマルチキャストパケットに変換する（Ｓ１４０４）。
　そして、マルチキャスト処理部２５３は、変換により得られた複数のマルチキャストパケットをプロキシサーバ２００に配信する（Ｓ１４０５）。
　その後、マルチキャスト処理部２５３は、ＨＴＴＰ処理部２５１からLEAVEメッセージを受け取ったか否かを判定する（Ｓ１４０６）。LEAVEメッセージを受け取っていないと判定した場合（Ｓ１４０６においてＮＯ）、Ｓ１４０３に戻る。
　一方、LEAVEメッセージを受け取ったと判定した場合（Ｓ１４０６においてＹＥＳ）、マルチキャスト処理部２５３は、そのLEAVEメッセージを送信したプロキシサーバ２００のアドレスを対象マルチキャストグループから削除し（Ｓ１４０７）、Ｓ１４０８に進む。
　Ｓ１４０８において、マルチキャスト処理部２５３は、対象マルチキャストグループに所属する他のプロキシサーバ２００が存在するか否かを判定する。存在すると判定した場合（Ｓ１４０８においてＹＥＳ）、Ｓ１４０３に戻る。
　存在しないと判定した場合（Ｓ１４０８においてＮＯ）、マルチキャスト処理部２５３が対象映像コンテンツのマルチキャスト配信を終了したこと（マルチキャスト配信終了）をＨＴＴＰ処理部２５１に通知して（Ｓ１４０９）、処理を終了する。
　〔クライアント装置１００の動作〕
　（クライアント装置１００の動作その１）
　次に、クライアント装置１００が対象映像コンテンツの再生指示をユーザから受け付けてから対象映像コンテンツ全体の再生が完了するまでのクライアント装置１００の動作について、図１９～図２１を参照しながら以下に説明する。
　クライアント装置１００のＨＴＴＰ処理部１０１は、対象映像コンテンツのメディアセグメントのリクエストをプロキシサーバ２００に送信し（Ｓ１７０１）、プロキシサーバ２００からレスポンスを受信する（Ｓ１７０２）。
　ＨＴＴＰ処理部１０１は、Ｓ１７０２にて受信したレスポンスメッセージにmoovヘッダが含まれているか否かを判定する（Ｓ１７０３）。moovヘッダが含まれていると判定した場合（Ｓ１７０３においてＹＥＳ）、Ｓ１７０４に進み、moovヘッダが含まれていないと判定した場合（Ｓ１７０３においてＮＯ）、Ｓ１７０５に進む。
　Ｓ１７０４において、再生部１０２は、moovヘッダを参照することにより、対象映像コンテンツの再生に必要な初期化処理を行う。
　Ｓ１７０５において、Ｓ１７０２にて受信したレスポンスメッセージのX-Timestampの値を参照することにより、メディアセグメント内に欠損部（欠損したムービーフラグメント）が存在するか否かを判定する。
　ここで、ムービーフラグメントの欠損について図２０を参照して説明する。図２０中の左側部分は、配信サーバ３００からプロキシサーバ２５０に送信されるレスポンスメッセージを示しており、図２０中の右側部分は、クライアント装置１００に送信されるレスポンスメッセージを示している。
　図２０中の左側部分に示すレスポンスメッセージから変換された複数のマルチキャストパケット５２は、プロキシサーバ２００に送信されるが、基幹ネットワーク５００を通過する過程で一部のパケット５２が欠落する場合がある。図２０の例では、ムービーフラグメント０３およびムービーフラグメント０４を構成するパケット５２が欠落しており、クライアント装置１００が受信するレスポンス５１は、ムービーフラグメント０３およびムービーフラグメント０４が欠損したデータとなっている。
　なお、ムービーフラグメント０３およびムービーフラグメント０４のみが欠損したデータとなるのは、レスポンス５１は、ムービーフラグメントを各パートとするマルチパート形式のレスポンスメッセージであるからである。また、ムービーフラグメント０３およびムービーフラグメント０４の２つのムービーフラグメントが欠損したことは、図２０に示すように、ムービーフラグメントが本実施形態では１秒間のデータであるにもかかわらず、隣接する各パートに含まれるタイムスタンプ（ムービーフラグメント０２のX-Timestamp:1.00と、ムービーフラグメント０５のX-Timestamp:4.00と、）の差が１秒でなく３秒であることから、再生部１０２が検出できるようになっている。
　Ｓ１７０２にて受信したレスポンスメッセージに欠損部が存在しないと判定された場合（Ｓ１７０５においてＮＯ）、Ｓ１７１３に進み、欠損部が存在すると判定された場合（Ｓ１７０５においてＹＥＳ）、Ｓ１７０６に進む。
　Ｓ１７０６において、ＨＴＴＰ処理部１０１は、欠損部を補完するか否かを判定する。すなわち、図示しない操作部を介して予めユーザにより行われた設定（欠損部を補完した上でメディアセグメントを再生すべきか、欠損部を補完せずにメディアセグメントを再生すべきか、の設定）に基づいて、欠損部を補完するか否かを判定する。
　欠損部を補完しないと判定した場合（Ｓ１７０６においてＮＯ）、再生部１０２は、受信したメディアセグメント内のMovie Fragmentデータの再生時間を調整する（Ｓ１７０７）。すなわち、メディアセグメント内のMovie Fragmentデータには、X-TimestampにてMovieFragmentの再生開始時間が記述されており、クライアントは、X-Timesampから再生すべき時刻のMovieFragmentデータを取得し再生を行う。メディアセグメント内に欠損が生じると、再生すべき時刻のMovieFragmentが存在せず、再生が停止してしまうように見えるため、X-Timestampの値を調整して、Movie Fragmentが(時間的に)連続するようにする。例えば、ムービーフラグメント０５のX-Timestampを、ムービーフラグメント０２から連続するように、2.00として取得する。そして、以降のムービーフラグメントのX-Timestampも同様に連続するように調整する。また、再生時に調整してもよい。例えば、欠損したムービーフラグメントが対象映像コンテンツのｔ秒目からｔ＋１秒目までに再生すべきムービーフラグメントである場合、再生部１０２は、欠損したムービーフラグメントのひとつ前のムービーフラグメントがｔ－１秒目からｔ＋１秒目までの２秒間再生されるよう（例えば、（ａ）ひとつ前のムービーフラグメントが１／２倍速再生されるよう、あるいは、（ｂ）ひとつ前のムービーフラグメントが最初の１秒間通常再生され、その後の１秒間該ムービーフラグメントを構成する最後のフレーム（静止画像）が再生されるよう）制御を行う。この制御としては、例えば、再生部１０２は、上記ひとつ前のムービーフラグメントのmoofヘッダに２秒間再生すべき旨の情報を記録する処理が挙げられる。Ｓ１７０７の処理の後、Ｓ１７１３に進む。
　一方、欠損部を補完すると判定した場合（Ｓ１７０６においてＮＯ）、ＨＴＴＰ処理部１０１は、欠損部のムービーフラグメントを取得するリクエストをプロキシサーバ２００に送信し（Ｓ１７０８）、Ｓ１７０９に進む。欠損したムービーフラグメントを取得するリクエストは、欠損したムービーフラグメントを含むようなメディアセグメントのリクエストであってもよいし、欠損したムービーフラグメントのみを取得するリクエストであってもよい。
　欠損したムービーフラグメントのみを取得するリクエストのURIは、例えば、/＜対象映像コンテンツのファイル名＞/＜メディアセグメントのインデックス番号＞/＜欠損したムービーフラグメントが該メディアセグメント内の何番目のムービーフラグメントであるかを示す値＞のように構成される。例えば、欠損したムービーフラグメントのタイムスタンプ(X-timestamp)が４５である場合、リクエストのURIは、/content1/2/16となる。
　Ｓ１７０２にて受信したメディアセグメントの再生を開始すべき時刻になると、再生部１０２は、Ｓ１７０８のリクエストに対応する欠損部のムービーフラグメントをすでにＨＴＴＰ処理部１０１が取得したか否かを判定する（Ｓ１７０９）。取得したと判定した場合（Ｓ１７０９においてＹＥＳ）、再生部１０２は、欠損したムービーフラグメントを、取得した新たなムービーフラグメントにより補完する（新たなムービーフラグメントに置き換える）（Ｓ１７１０）。Ｓ１７１０の処理の後、Ｓ１７１３に進む。
　一方、まだ取得していないと判定した場合（Ｓ１７０９においてＹＥＳ）、再生部１０２は、受信したメディアセグメント内のMovie Fragmentデータの再生時間を調整する（Ｓ１７１１）。このＳ１７１１の処理は、Ｓ１７０７の処理と同様の処理である。
　その後、再生部１０２は、Ｓ１７０２にて受信したメディアセグメントの各ムービーフラグメントを順次再生する（Ｓ１７１２）。Ｓ１７１２の処理の後、Ｓ１７１４に進む。
　Ｓ１７１３にて、再生部１０２は、Ｓ１７０２にて受信した（あるいはＳ１７１０で補完後の）メディアセグメントの各ムービーフラグメントを順次再生し、Ｓ１７１４に進む。
　Ｓ１７１４において、再生部１０２は、再生したメディアセグメントを図示しない記憶部に蓄積すべきか否かを判定する。すなわち、再生部１０２は、操作部を介してユーザから対象映像コンテンツを録画すべき旨の指示を受けていた場合には蓄積すべきであると判定し、録画すべき旨の指示を受けていなかった場合には蓄積すべきでないと判定する。
　再生したメディアセグメントを蓄積すべきであると判定された場合（Ｓ１７１４においてＹＥＳ）、Ｓ１７１５にて後述するデータ補完処理が行われた後、再生したメディアセグメントを記憶部に蓄積する（Ｓ１７１６）。Ｓ１７１６の処理の後、Ｓ１７１７に進む。一方、蓄積すべきでないと判定された場合（Ｓ１７１４においてＮＯ）、Ｓ１７１７に進む。
　Ｓ１７１７において、再生部１０２は、Ｓ１７１３にて再生したメディアセグメントが対象映像コンテンツの最後のメディアセグメントであるか否かを判定する。最後のメディアセグメントではないと判定された場合（Ｓ１７１７においてＮＯ）、Ｓ１７０１に戻る。一方、最後のメディアセグメントであると判定された場合（Ｓ１７１７においてＹＥＳ）、Ｓ１７１８に進む。
　Ｓ１７１８において、ＨＴＴＰ処理部１０１は、プロキシサーバ２００との接続状態を解除して対象映像コンテンツの再生を終了し、Ｓ１７１９に進む。
　Ｓ１７１９において、再生部１０２は、対象映像コンテンツの各メディアセグメントを録画したか否かを判定する。録画したと判定した場合（Ｓ１７１９においてＹＥＳ）、Ｓ１７２０のデータ補完処理を行い、処理を終了する。録画していないと判定した場合（Ｓ１７１９においてＮＯ）、そのまま処理を終了する。
　（データ補完処理について）
　Ｓ１７１５およびＳ１７２０にて行われるデータ補完処理の流れについて図２１を参照しながら以下に説明する。図２１は、クライアント装置１００のデータ補完処理の流れを示すフローチャートである。
　図２１に示すように、クライアント装置１００の再生部１０２は、Ｓ１７１３において再生されたメディアセグメントの中に欠損部が存在するか否かを判定する（Ｓ１８０１）。欠損部が存在すると判定された場合（Ｓ１８０１）、Ｓ１７０８にて既に欠損部のムービーフラグメントを取得するリクエストが出されているが、このリクエストに対応する欠損部のムービーフラグメントをすでにＨＴＴＰ処理部１０１が取得したか否かを判定する（Ｓ１８０２）。欠損部のムービーフラグメントを取得済みであると判定された場合（Ｓ１８０２においてＹＥＳ）、Ｓ１８０３に進み、欠損部のムービーフラグメントをまだ取得していないと判定された場合（Ｓ１８０２においてＮＯ）、Ｓ１８０４に進む。
　Ｓ１８０３において、ＨＴＴＰ処理部１０１は、欠損部を補完するか否かを判定する。すなわち、図示しない操作部を介して予めユーザにより行われた設定（対象映像コンテンツ全体の再生を完了した後に補完するか、対象映像コンテンツの再生中に補完するかの設定）に基づいて、欠損部を補完するか否かを判定する。
　欠損部を補完すると判定された場合（Ｓ１８０３においてＹＥＳ）、Ｓ１８０６に進む。一方、欠損部を補完しないと判定された場合（Ｓ１８０３においてＮＯ）、データ補完処理を終了する。
　Ｓ１８０４において、ＨＴＴＰ処理部１０１は、欠損部のムービーフラグメントを取得すべきか否かを判定する。ここで、ＨＴＴＰ処理部１０１は、欠損部を補完せずにメディアセグメントを再生すべき旨の指示が出ていた場合には欠損部のムービーフラグメントを取得すべきであると判定し、欠損部を補完した上でメディアセグメントを再生すべき旨の指示が出ていた場合には欠損部のムービーフラグメントを取得すべきでないと判定するようになっている。
　欠損部のムービーフラグメントを取得すべきであると判定された場合（Ｓ１８０４においてＹＥＳ）、ＨＴＴＰ処理部１０１は、欠損部のムービーフラグメントをプロキシサーバ２００から取得し（Ｓ１８０５）、Ｓ１８０６に進む。一方、欠損部のムービーフラグメントを取得すべきでないと判定された場合（Ｓ１８０４にＮＯ）、データ補完処理を終了する。
　Ｓ１８０６において、再生部１０２は、欠損したムービーフラグメントを、Ｓ１７０８またはＳ１８０６にて取得した新たなムービーフラグメントにより補完し、データ補完処理を終了する。
　以上、クライアント装置１００の動作を説明した。以上の説明からわかるように、クライアント装置１００は、受信したメディアセグメントに欠損部が存在する場合に、欠損部のムービーフラグメントをプロキシサーバ２００から取得する。ここで、クライアント装置１００は、欠損部を含むメディアセグメントを再生する前に欠損部のムービーフラグメントを取得した場合には、欠損部を補完した状態でメディアセグメントを再生することができる。また、欠損部を含むメディアセグメントの再生後に欠損部のムービーフラグメントを取得した場合には、欠損部を補完した状態でメディアセグメントを蓄積することにより、完全な状態で対象映像コンテンツを録画することができる。
　（クライアント装置１００の動作その２）
　次に、クライアント装置１００が対象映像コンテンツを再生中に再生中断指示をユーザから受け付けた場合のクライアント装置１００の動作について、図２２を参照しながら以下に説明する。
　クライアント装置１００の再生部１０２が対象映像コンテンツ中の再生中（Ｓ１９０１）、随時、再生部１０２は、再生中断指示をユーザから受け付けたか否かを判定する（Ｓ１９０２）。
　再生中断指示を受け付けたと判定された場合（Ｓ１９０２において）、ＨＴＴＰ処理部１０１は、次に、プロキシサーバ２００に送信すべきリクエストとしてヘッダ部に”Connection:Close”ヘッダを付与されたリクエストを生成する（Ｓ１９０３）。
　その後、ＨＴＴＰ処理部１０１は、Ｓ１９０３にて生成したリクエストをプロキシサーバ２００に送信する（Ｓ１９０４）。
　Ｓ１９０４にて送信したリクエストに対応するレスポンスを受信すると、そのレスポンスのメディアセグメントを再生し終えた時点で対象映像コンテンツの再生を終了（中断）する（Ｓ１９０５）。
　（配信システム１の動作例２）
　次に、クライアント装置１００が対象映像コンテンツの配信要求を出した場合に配信システム１で行われる動作の別の一具体例について、図２４を参照しながら説明する。
　この動作例では、動作の開始時点においてすでにクライアント装置１００－１～１００－４の４台のクライアント装置１００が対象映像コンテンツのマルチキャスト配信を配信サーバ３００から受け付けているものとし、新たにクライアント装置１００－５が対象映像コンテンツの配信要求を出すものとする。
　また、この動作例では、図示しないライブカメラから配信サーバ３００に入力されているライブ映像が、対象映像コンテンツとしてクライアント装置１００にライブ配信されている。また、配信サーバ３００に入力されるライブ映像はメモリ部３０２に記録された上でライブ配信されるため、ライブ配信が終了した後に、クライアント装置１００は、対象映像コンテンツのＶＯＤ配信を配信サーバ３００から受けることが可能になっている。
　図２４は、配信システム１の上記動作例を示すシーケンス図である。なお、図２４では、クライアント装置１００－２～１００－４およびプロキシサーバ２００－２～２００－４の動作の記載は省略している。
　プロキシサーバ２５０のマルチキャスト処理部２５３は、対象映像コンテンツのマルチキャストパケット５２をプロキシサーバ２００に送信する（Ｓ４０）。
　次に、クライアント装置１００－１は、対象映像コンテンツのメディアセグメントのリクエスト４１をプロキシサーバ２００に送信する（Ｓ４１）と、プロキシサーバ２００のＨＴＴＰ処理部２０１は、当該メディアセグメントのレスポンス５１を、Ｓ４０にて受信したマルチキャストパケット５２を用いて生成し、クライアント装置１００－１にレスポンス５１を送信する（Ｓ４２）。
　次に、クライアント装置１００－５が対象映像コンテンツのリクエスト４３をプロキシサーバ２００－５に送信する（Ｓ４３）。ここで、リクエスト４３は、対象映像コンテンツ全体の送信を要求するために用いられるリクエストである。すなわち、リクエスト４３は、対象映像コンテンツ中の指定されたメディアセグメントの送信を要求するために用いられるリクエスト４１とは異なっている。
　リクエスト４３を受信したプロキシサーバ２００－５のＨＴＴＰ処理部２０１は、リクエスト４３をプロキシサーバ２５０に中継する（Ｓ４４）。
　リクエスト４３を受信したプロキシサーバ２５０のＨＴＴＰ処理部２５１は、リクエストのURI(“/content1/”)を確認する（Ｓ４５）。すなわち、対象映像コンテンツ（ファイル名が”content1”のコンテンツ）をすでにマルチキャスト配信しているか否か（すなわち、対象マルチキャストグループに所属する通信装置がすでに存在するか否か）を判定する。ここでは、プロキシサーバ２００－１～２００－４が対象マルチキャストグループに所属しているので、マルチキャスト配信していると判定する。
　対象映像コンテンツをマルチキャスト配信していると判定したＨＴＴＰ処理部２５１は、X-alternative-castヘッダを生成する。そして、ＨＴＴＰ処理部２５１は、キャッシュ部２５２にキャッシュ済みの最新のメディアセグメント（インデックス値がｔのメディアセグメントとする）のレスポンスメッセージ５１に、＜配信アドレス＞を対象マルチキャストグループのアドレスとするX-alternative-castヘッダを付与する（Ｓ４６）。
　そして、ＨＴＴＰ処理部２５１は、X-alternative-castヘッダを含むレスポンスメッセージ５１’をプロキシサーバ２００－５に送信する（Ｓ４７）。
　プロキシサーバ２００－５のＨＴＴＰ処理部２０１は、レスポンスメッセージ５１’をレスポンスメッセージ５１に変換してクライアント装置１００－５に送信する（Ｓ４８）。クライアント装置１００－５の再生部１０２は、ＨＴＴＰ処理部１０１が受信した最新のメディアセグメント（インデックス値ｔのメディアセグメント）のレスポンスメッセージ５１を再生する。これにより、クライアント装置１００－５はライブ映像の再生を開始することになる。
　一方、プロキシサーバ２００－５のＨＴＴＰ処理部２０１は、マルチキャスト受信要求（JOINメッセージ）４２をプロキシサーバ２５０に送信する（Ｓ４９）。
　プロキシサーバ２５０のＨＴＴＰ処理部２５１は、JOINメッセージ４２を受信すると、JOINメッセージ４２に対するレスポンスをプロキシサーバ２００－５に送信する（Ｓ５０）。さらに、ＨＴＴＰ処理部２５１は、プロキシサーバ２００－５のアドレスを対象マルチキャストグループに所属するものとして、マルチキャストグループ情報記憶部２５４に記録する（Ｓ５１）。
　以降、マルチキャスト処理部２５３は、インデックス値がｔ＋１以降のメディアセグメントのマルチキャストパケット５２をプロキシサーバ２００－１～２００－５に送信するようになる（Ｓ５２）。
　一方、Ｓ４８にて、インデックス値ｔのメディアセグメントのレスポンスメッセージ５１を受信したクライアント装置１００－５のＨＴＴＰ処理部１０１は、次の（インデックス値ｔ＋１の）メディアセグメントを要求するリクエスト４１をプロキシサーバ２００－５に送信し（Ｓ５３）、リクエスト４１に対応するレスポンス５１（インデックス値ｔ＋１のメディアセグメント）を受信する（Ｓ５４）。
　以降、後続するメディアセグメント（インデックス値ｔ＋２、ｔ＋３、・・）について、クライアント装置１００－５は、Ｓ５３とＳ５４との処理を繰り返すことになる。
　以上の動作例２の説明からわかるように、プロキシサーバ２５０から対象映像コンテンツのマルチキャスト配信が行われている場合には、クライアント装置１００からの対象映像コンテンツの配信要求が配信サーバ３００に到達しないようになっている。
　したがって、配信サーバ３００から対象映像コンテンツが配信されるクライアント装置１００の台数が増えたとしても、配信サーバ３００の処理負荷および配信サーバ３００とプロキシサーバ２５０との間のネットワークの負荷が抑えられる。したがって、配信サーバ３００から各クライアント装置１００に効率的に対象映像コンテンツが配信されることになる。
　また、すでに説明したように、クライアント装置１００は、ユーザからの指示に応じて対象映像コンテンツの再生と同時に録画をすることもできるようになっている。上記動作例２において、クライアント装置１００－５が対象映像コンテンツの録画を行うよう設定されていた場合には、クライアント装置１００－５には、対象映像コンテンツのうちインデックス値がｔ以降のメディアセグメントが蓄積されることになる。
　したがって、クライアント装置１００－５は、ライブ配信終了後にＶＯＤ配信される対象映像コンテンツについて、インデックス値がｔ以前のメディアセグメントのリクエスト４１を送信してｔ－１個のレスポンス５１を取得および蓄積することにより、ライブ配信された対象映像コンテンツ全体を効率良く録画することができる。
　（プロキシサーバ２５０の利点）
　以上のように、配信システム１のプロキシサーバ２５０において、ＨＴＴＰ処理部２５１は、プロキシサーバ２００から対象映像コンテンツを要求するリクエスト４１が送られたことを検出した場合に、配信サーバ３００の代わりにプロキシサーバ２５０がマルチキャスト通信により対象映像コンテンツを送信可能であることを示すX-alternative-cast情報をプロキシサーバ２００に送信する。また、マルチキャスト処理部２５３は、プロキシサーバ２００からＪＯＩＮメッセージ４２を受信した場合にプロキシサーバ２００を対象マルチキャストグループに登録する。そして、マルチキャスト処理部２５３は、キャッシュ部２５２の対象映像コンテンツを、対象マルチキャストグループに登録された各プロキシサーバ２００にマルチキャスト通信を用いて中継する。
　すなわち、対象映像コンテンツが配信されるクライアント装置１００が３台である（配信要求を受ける頻度が一定未満である）ときには、配信サーバ３００は、図１２（ａ）に示すように、同一内容のメディアセグメントについて、配信要求を３回受けてその度にメディアセグメントのレスポンスを返す。一方、図１２（ｂ）に示すように、対象映像コンテンツが配信されるクライアント装置１００が所定の台数（４台）になる（配信要求を受ける頻度が一定以上になる）と、その後、配信サーバ３００は、同一内容のメディアセグメントについて、配信要求を受けてメディアセグメントのレスポンスを返す処理を１回で済ませることができる。したがって、配信サーバ３００の処理負荷、および配信サーバ３００とプロキシサーバ２５０との間のネットワークの負荷が抑えられることになる。
　また、図１２（ａ）に示すように、対象映像コンテンツが配信されるクライアント装置１００が３台である（配信要求を受ける頻度が一定未満である）ときには、プロキシサーバ２５０も、同一内容のメディアセグメントについて、配信要求を３回受けてその度にメディアセグメントのレスポンスを返す。一方、図１２（ｂ）に示すように、対象映像コンテンツが配信されるクライアント装置１００が所定の台数（４台）になる（配信要求を受ける頻度が一定以上になる）と、プロキシサーバ２５０は、メディアセグメントをマルチキャスト配信することができる。すなわち、４台のクライアント装置１００に同一内容のメディアセグメントを配信するためにプロキシサーバ２５０が送信するデータのデータ量は、メディアセグメント１つ分のデータ量となる。したがって、基幹ネットワークの特にプロキシサーバ２５０に近接する領域の帯域負荷が抑えられることになる。
　さらに、上述したように、メディアセグメントは各パートをムービーフラグメントとするＭＩＭＥマルチパート形式で配信サーバ３００からプロキシサーバ２５０に送信されるが、プロキシサーバ２５０は、１つのパート（ムービーフラグメント）の全部または一部のデータを１つのマルチキャストパケットに格納してマルチキャスト配信するようになっている。したがって、多数のマルチキャストパケットの伝送中に１つのマルチキャストパケットが欠落しても、欠落の影響は１つのムービーフラグメントにしか及ばないようになっている。従って、クライアント装置１００に安定して映像コンテンツを再生させることができるようになっている。
　（実施形態２）
　本実施形態では、プロキシサーバ２００は、IGMPのJOINメッセージおよびLEAVEメッセージを送信することにより、マルチキャストグループへの参加およびマルチキャストグループからの離脱を行うようになっている。
　IGMPとは、ＩＰ放送（ＩＰマルチキャスト）において、マルチメディアルーターがマルチキャストデータのルーティングを行う際に用いるプロトコルである。
　一般に、マルチメディアルーターは、マルチキャストグループに参加しているホスト機器が存在するか否かをIGMPを利用して把握するように構成されている。マルチメディアルーターは、マルチキャストグループに参加しているホスト機器に対してマルチキャストデータを送信する。このため、ホスト機器が、あるマルチキャストデータを受信するためには、そのマルチキャストデータの送信先となるマルチキャストグループへの参加を要求するIGMP JOINメッセージをマルチメディアルーターに対して送信する必要がある。
　また、ホスト機器は、マルチキャストデータを継続して受信するためには、一定期間ごとにマルチメディアルーターから送信されるクエリー（IGMP QUERY）に応答する(IGMP REPORTを送信する)必要がある。さらに、ホスト機器は、マルチキャストデータを受信しないようにするために、そのマルチキャストデータの送信先となるマルチキャストグループからの離脱を要求するIGMP LEAVEメッセージをする必要がある。
　このため、マルチメディアルーターは、ホスト機器をマルチキャストグループに参加させる処理、クエリーの送信処理、ホスト機器をマルチキャストグループから離脱させる処理等の各種処理を行うことが必要である。
　このうち、ホスト機器をマルチキャストグループから離脱させる処理は時間を要する処理となっている。これは、マルチメディアルーターは、IGMP LEAVEメッセージを受信すると、マルチキャストデータを送信すべき他のホスト機器が存在するか否かをクエリーにより確認してから、マルチキャストデータの送信を停止するためである。
　したがって、ホスト機器がIGMP LEAVEメッセージを送信してからもしばらくの間、ホスト機器に向けてマルチメディアデータが送信されることになる。
　このため、ホスト機器がある映像コンテンツのマルチキャスト配信を受けている間にチャンネルザッピングが行われると、しばらくの間、チャンネル切換先の映像コンテンツのマルチキャストデータだけでなく、チャンネル切換元の映像コンテンツのマルチキャストデータも送信されることになる。すなわち、マルチキャスト配信では一般に一定の帯域幅が補償されているため、チャンネルザッピングの際にはネットワークの帯域が無駄に圧迫されるという問題がある。
　ここで、ネットワークの帯域圧迫の問題を回避するために、ホスト機器にチャンネル切換元の映像コンテンツのマルチキャストデータが送信されなくなってから、ホスト機器をチャンネル切換先の映像コンテンツを送信先とするマルチキャストグループに参加させることも可能である。ただし、この場合には、チャンネル切換元の映像コンテンツの再生を停止してからチャンネル切換先の映像コンテンツの再生を開始するまでにタイムラグが発生するという別の問題が生じることになる。
　以下、本実施形態における配信システム１の動作例について図２５を参照しながら以下に説明する。なお、本実施形態では、クライアント装置１００－１において、ファイル名が”content1”の映像コンテンツ（「切換元映像コンテンツ」とも称する）を再生中に、ユーザから、再生すべき映像コンテンツをファイル名が”content2”の映像コンテンツ（「切換先映像コンテンツ」とも称する）に切り替えるチャンネル切換の指示が出されるものとする。また、チャンネル切換の指示が出される前に、プロキシサーバ２５０は、切換先映像コンテンツを他のクライアント装置１００にすでにマルチキャスト配信しているものとする。
　図２５は、上記動作例を示すシーケンス図である。実施形態１に示したように、クライアント装置１００－１から切換元映像コンテンツのリクエスト４１を受けたプロキシサーバ２００は、プロキシサーバ２５０からレスポンス５１ａを受信し、切換元映像コンテンツをマルチキャスト配信の送信先とするマルチキャストグループ（「切換元マルチキャストグループ」と称する）への参加を要求するIGMP JOINメッセージをプロキシサーバ２００に送信する（Ｓ５０）。
　IGMP JOINメッセージを受信したマルチキャスト処理部２５３は、プロキシサーバ２００に向けて切換元映像コンテンツのマルチキャストパケット５２の送信（Ｓ５１）を開始する。その後、実施形態１と同様の方法で（以下のＳ５１～Ｓ５４の処理が反復されて）プロキシサーバ２００－１からクライアント装置１００－１に切換元映像コンテンツのレスポンス５１が配信されていくことになる。
　すなわち、プロキシサーバ２００－１のマルチキャスト処理部２０３は、Ｓ５１にて配信された複数のマルチキャストパケット５２をまとめて、メディアセグメントのレスポンス５１に変換し（Ｓ５２）、キャッシュ部２０２にキャッシュする（Ｓ５３）。
　一方、クライアント装置１００－１は、切換元映像コンテンツのメディアセグメントを要求するリクエスト４１をプロキシサーバ２００－１に送信すると、ＨＴＴＰ処理部２０１は、対応するレスポンス５１をキャッシュ部２０２から読み出して（Ｓ５４）、クライアント装置１００－１に送信する。
　上記Ｓ５１～Ｓ５４の処理が繰り替えされている間（すなわち、クライアント装置１００－１で切換元映像コンテンツを再生中）に、クライアント装置１００－１が操作部を介してユーザから上記チャンネル切換の指示を受けたものとする。
　チャンネル切換の指示を受け付けたクライアント装置１００－１のＨＴＴＰ処理部１０１は、切換元映像コンテンツのリクエスト４１’（すなわち、”Connection:Close”ヘッダが付加されたリクエスト）をプロキシサーバ２００に送信する（Ｓ５５）。
　同時に、ＨＴＴＰ処理部１０１は、切換先映像コンテンツのリクエスト４１をプロキシサーバ２００に送信する（Ｓ５６）。
　プロキシサーバ２００－１のＨＴＴＰ処理部２０１は、Ｓ５６にて新たに切換先映像コンテンツのリクエスト４１を受信すると、切換元映像コンテンツのリクエスト４１’を受信したか否かを判定する。ここでは、Ｓ５５にてリクエスト４１’を受信しているので、リクエストＵＲＩが変更になったと判定する（Ｓ５７）。リクエストＵＲＩが変更になったと判定したので、ＨＴＴＰ処理部２０１は、リクエスト４１をプロキシサーバ２５０に中継する（Ｓ６０）。
　一方、Ｓ５６にてＨＴＴＰ処理部２０１がリクエスト４１’を受信したので、マルチキャスト処理部２０３は、切換元マルチキャストグループからの離脱を要求するIGMP LEAVEメッセージをプロキシサーバ２５０に送信する（Ｓ５８）。
　プロキシサーバ２５０のマルチキャスト処理部２５３は、プロキシサーバ２００－１を切換元マルチキャストグループからの離脱させる処理を開始する（Ｓ５９）。前述したようにこの処理には一定の時間を要するため、しばらくの間、切換元映像コンテンツのマルチキャストパケット５２はプロキシサーバ２００－１に向けて送信されることになる。この場合、プロキシサーバ２００－１は、マルチキャストパケット５２を破棄することになる。
　一方、リクエスト４１を受信したプロキシサーバ２５０のＨＴＴＰ処理部２５１は、リクエスト４１を配信サーバ３００に中継する（Ｓ６１）。
　切換先映像コンテンツはすでにマルチキャスト配信されているため、ＨＴＴＰ処理部２５１は、リクエスト４１に対応するレスポンス５１を配信サーバ３００から受信すると、レスポンスメッセージ５１に＜配信アドレス＞を切換先マルチキャストグループのアドレスとするX-alternative-castヘッダを付与して（Ｓ６２）、レスポンス５１’を生成する。
　その後、ＨＴＴＰ処理部２５１は、切換先映像コンテンツのレスポンス５１’をプロキシサーバ２００－１に送信する（Ｓ６３）。
　レスポンス５１’を受信したプロキシサーバ２００－１のＨＴＴＰ処理部２０１は、切換先映像コンテンツのレスポンス５１をクライアント装置１００－１に送信する（Ｓ６４）。この時点からクライアント装置１００－１において切換先映像コンテンツの再生が開始される。
　そして、マルチキャスト処理部２０３は、切換先マルチキャストグループへの参加を要求するIGMP JOINメッセージをプロキシサーバ２５０に送信する。これにより、プロキシサーバ２００には、切換先映像コンテンツのマルチキャストパケット５２が配信されるようになる。ここで、マルチキャスト処理部２０３が切換先マルチキャストグループへの参加を要求するIGMP JOINメッセージをプロキシサーバ２５０に送信するタイミングは、マルチキャスト処理部２０３がIGMP JOINメッセージを送信すべきであると判定した時であることが望ましい。具体的には、マルチキャスト処理部２０３が切換元映像コンテンツのマルチキャストパケット５２を受信および破棄しなくなってから一定時間経過したことをもってIGMP JOINメッセージを送信すべきであると判定し、上記一定時間が経過する前のタイミングではIGMP JOINメッセージを送信すべきでないと判定することが望ましい。
　なお、Ｓ５６にてＨＴＴＰ処理部２０１が切換先映像コンテンツ（第２のコンテンツ）のリクエスト４１を受信した場合に、クライアント装置１００－１に送信すべき切換元映像コンテンツ（第１のコンテンツ）のレスポンス５１に”Connection:Close”ヘッダが付加した上で、クライアント装置１００－１に送信するようにしてもよい。この場合、レスポンスの送信直後のタイミングで、切替元映像コンテンツを中継するためにクライアント装置１００－１とプロキシサーバ２００との間で確立されていた接続状態が解除されることになる。
　以上のように、本実施形態の配信システム１では、チャンネル切換が行われた場合にクライアント装置１００は、切換元映像コンテンツのリクエスト４１’（”Connection:Close”ヘッダを含むHTTPリクエスト）と切換先映像コンテンツのリクエスト４１とをプロキシサーバ２００に送信すれば、すぐに切換先映像コンテンツの再生を開始することができる。また、チャンネル切換の間にクライアント装置１００とプロキシサーバ２００とのネットワークの帯域も圧迫されることはない。
　したがって、映像コンテンツをマルチキャスト通信によって受信する（すなわち、チャンネルザッピングの際に切換元マルチキャストグループから離脱を要求するIGMP LEAVEメッセージをマルチメディアルーターに送信する）従来のクライアント装置に比べ、配信システム１のクライアント装置１００は、切換先映像コンテンツの素早い再生と、クライアント装置１００側のネットワーク帯域負荷の抑制と、を両立させることができるという効果を奏する。
　また、切換先映像コンテンツを素早く再生することが可能であるので、切換先映像コンテンツがすでにライブ配信されているライブ映像のコンテンツであるような場合に、ユーザに早いタイミングでライブ映像を視聴させることができる。
　さらに、映像コンテンツが、例えば、H.264で規定された圧縮方式により圧縮符号化されている場合、本実施形態のクライアント装置１００と、上記従来のクライアント装置とで、チャンネル切換されてから切換先映像コンテンツの再生を開始するまでに要する時間の差がさらに広がる場合がある。
　すなわち、映像コンテンツが圧縮符号化されている場合、例えば、クライアント装置は、符号化されたキーフレームのデータを取得してデコードするまで映像をユーザに視聴させることができない。ＩＰマルチキャスト配信では、伝送中にマルチキャストパケットが欠損する可能性がある。すなわち、従来のようにクライアント装置が切換先映像コンテンツのマルチキャストパケットを直接受信する場合には、マルチキャストパケットの欠損によるキーフレームの欠如により、切換先映像コンテンツの再生開始が遅れる可能性がある。
　一方、本実施形態のクライアント装置１００では、前述したように、チャンネル切換されてから切換先映像コンテンツの再生を開始するまでは、クライアント装置１００と配信サーバ３００との間は一貫して通信の信頼性の高いＨＴＴＰ通信により行われる。すなわち、切換先映像コンテンツの再生を開始するまでは、配信サーバ３００からクライアント装置１００に切換先映像コンテンツが配信される過程で、キーフレームの欠如が発生することはない。したがって、本実施形態のクライアント装置１００は、切換先映像コンテンツが圧縮符号化されている場合であっても、確実に素早く切換先映像コンテンツの再生を開始することができる。
　なお、配信サーバ３００またはプロキシサーバ２５０をX-Transport-Speedヘッダの処理が可能なように構成し、クライアント装置１００が、X-Transport-Speedヘッダを含むＨＴＴＰリクエストをプロキシサーバ２００に送信することが望ましい。X-Transport-Speedヘッダは、ヘッダで指定した値に応じた伝送速度でデータを伝送するようＨＴＴＰサーバに要求するためのヘッダである。
　この場合、クライアント装置１００は、X-Transport-Speedヘッダとして大きな値を設定することにより、高速で切換先映像コンテンツのデータを受信することが可能である。このため、クライアント装置１００は、切換先映像コンテンツのデータの先頭部分にキーフレームが含まれていない場合であっても、より素早く切換先映像コンテンツの再生を開始することができる。
　なお、プロキシサーバ２５０がマルチメディアルーターの役割を果たす（すなわち、プロキシサーバ２００とプロキシサーバ２５０との間の通信経路上にマルチメディアルーターが存在しない）前提で本実施形態を説明した。ただし、基幹ネットワーク５００としては、プロキシサーバ２００とプロキシサーバ２５０との間にマルチメディアルーターが介在しているようなネットワークも想定される。この場合、プロキシサーバ２００は、プロキシサーバ２５０との通信経路上にあるマルチメディアルーターのうち最もプロキシサーバ２００に近いマルチメディアルーターにIGMP JOINやIGMP LEAVE等の通知を送信することになる。
　（付記事項１）
　実施形態１および２では、クライアント装置１００がメディアセグメント単位で対象映像コンテンツのリクエストを出すものとしたが、クライアント装置１００は、対象映像コンテンツ全体を単位としてリクエストを出すようにしてもよい。この場合、プロキシサーバ２５０は、プロキシサーバ２００から受信したリクエストを、メディアセグメント単位のリクエストに変換することになる。
　例えば、ＨＴＴＰ処理部２５１は、対象映像コンテンツ全体のリクエスト(冒頭が”GET /content1/1 HTTP/1.1”で始まるリクエストメッセージ)を受信した場合に、”GET /content1/1 HTTP/1.1”で始まるリクエスト４１を生成して配信サーバ３００に送信し、対応するレスポンスを受信する。
　その後、ＨＴＴＰ処理部２５１は、”GET /content1/t/ HTTP/1.1”で始まるリクエスト４１を生成して配信サーバ３００に送信し、対応するレスポンスを受信するという処理を、２以上のｔについてｔをインクリメントしながら対象映像コンテンツ全体を受信するまで繰り返すことになる。
　（付記事項２）
　実施形態１および２では、プロキシサーバ２５０がプロキシサーバ２００からリクエスト４１を受信したときに、マルチキャスト配信を行っていなければ、リクエスト４１を配信サーバ３００に中継するものとしたが、マルチキャスト配信を行っていない状態でプロキシサーバ２５０を以下のように動作させてもよい。
　すなわち、プロキシサーバ２５０は、プロキシサーバ２００からリクエスト４１を受信したときにリクエスト４１に対応するレスポンス５１がキャッシュ部２５２にキャッシュされている場合には、キャッシュされているレスポンス５１（またはレスポンス５１から生成したレスポンス５１’）をプロキシサーバ２００に送信するようにしてもよい。
　（付記事項３）
　実施形態１および２では、各装置のIPアドレスがIPv4で規定されるアドレスであるものとして説明したが、これに限定されない。すなわち、各装置のIPアドレスはIPv6で規定されるアドレスであってもよい。この場合、プロキシサーバ２５０は、IPv6で構成されるネットワークを対象として規定されたマルチキャスト配信方式を用いてマルチキャスト配信を行ってもよい。
　（付記事項４）
　実施形態１では、クライアント装置１００が、受信したメディアセグメントに欠損部が存在するか否かを判定し、欠損部が存在すると判定した場合に、欠損部のデータを取得する（すなわち、欠損部のムービーフラグメント（または欠損部を含むメディアセグメント）の配信要求を出す）ものとしたが、この処理をクライアント装置１００のプロキシサーバ２００が行ってもよい。また、プロキシサーバ２００は、欠損部のデータを取得するために、パケット再送信技術やＦＥＣ（Ｆｏｒｗａｒｄ　Ｅｒｒｏｒ　Ｃｏｒｒｅｃｔｉｏｎ）等を利用してもよい。
　このようにすることにより、プロキシサーバ２００が複数のクライアント装置１００の代理サーバとなっている場合に、各クライアント装置１００に個別に欠損部のデータの取得を行わせるよりも効率的に欠損部のデータを取得することができる。
　（付記事項５）
　実施形態１および２において、クライアント装置１００とプロキシサーバ２００との間のネットワークの障害が発生する場合等に、クライアント装置１００から送信されたリクエスト４１がしばらくプロキシサーバ２００に届かなかったり、プロキシサーバ２００から送信されたレスポンス５１がクライアント装置１００に届かなくなったりして、一定期間映像コンテンツを適切に受信できない場合がある。
　このような場合、上記一定期間の間にプロキシサーバ２００では、キャッシュされるレスポンス５１の累積量がキャッシュ部２０２の記憶容量を超えてしまい、以降にプロキシサーバ２５０からマルチキャスト配信されるマルチキャストパケット５２を破棄してしまうことがある。
　ただし、このような場合であっても、上記一定期間の後に、クライアント装置１００から、キャッシュ部２０２にキャッシュされていないレスポンス５１を要求するリクエスト４１を受信した場合に、プロキシサーバ２００は、リクエスト４１を中継することでプロキシサーバ２５０からレスポンス５１を取得することができる。また、クライアント装置１００は、上記一定期間の間にどのメディアセグメントを取得できなかったかを把握できるので、上記一定期間の間に取得できなかった全メディアセグメントを再取得することができる。
　なお、映像コンテンツが基本レイヤと拡張レイヤとからなる階層化されたコンテンツ（スケーラブルコンテンツ）として提供される場合、または、複数の品質（異なる複数のビットレート、解像度またはフレームレート）のデータを有するコンテンツ（例えば、１３セグとワンセグ）として提供される場合、プロキシサーバ２００は、キャッシュ部２０２にキャッシュするデータの累積量がキャッシュ部２０２の記憶容量を超えるのを抑制するために、以下のように動作させてもよい。
　すなわち、プロキシサーバ２００のマルチキャスト処理部２０３は、キャッシュ部２０２にキャッシュされているデータ量が一定の閾値を超過したと判定した場合に、マルチキャストパケット５２が構成する階層化されたメディアセグメントのうち一部の階層のデータのみを抽出してレスポンスメッセージに変換し、キャッシュ部２０２にキャッシュするようにしてもよい。例えば、マルチキャストパケット５２が構成するメディアセグメントが基本レイヤと拡張レイヤからなる場合、基本レイヤのみを抽出したレスポンスメッセージをキャッシュ部２０２にキャッシュするようにしてもよい。
　さらに、マルチキャスト処理部２０３は、キャッシュ部２０２にキャッシュされているデータ量が一定の閾値を超過したと判定した場合に、マルチキャストパケット５２が構成する複数の品質のデータからなるメディアセグメントのうち一部の品質のデータのみを抽出してレスポンスメッセージに変換し、キャッシュ部２０２にキャッシュするようにしてもよい。例えば、マルチキャストパケット５２が構成するメディアセグメントがワンセグのデータと１３セグのデータとからなる場合、ワンセグのデータのみを抽出したレスポンスメッセージをキャッシュ部２０２にキャッシュするようにしてもよい。
　なお、この場合、プロキシサーバ２００のＨＴＴＰ処理部２０１は、キャッシュ部２０２にキャッシュされたレスポンス５１を読み出すとともに、提供可能な階層や品質（ビットレート）等を示す情報を、レスポンス５１のヘッダ部またはマルチパートの各パートの部分に付加することにより、クライアント装置１００に取得すべき階層（または品質）を変更させることができる。
　（プログラム、記憶媒体）
　クライアント装置１００、プロキシサーバ２００、２５０、及び配信サーバ３００（３００’）の各ブロックは、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェア的に実現してもよい。
　後者の場合、クライアント装置１００、プロキシサーバ２００、２５０及び配信サーバ３００は、各機能を実現するプログラムの命令を実行するＣＰＵ、上記プログラムを格納したＲＯＭ（Read Only Memory）、上記プログラムを展開するＲＡＭ（Random Access Memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるクライアント装置１００、プロキシサーバ２００、２５０、及び配信サーバ３００の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記クライアント装置１００、プロキシサーバ２００、２５０、及び配信サーバ３００に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
　上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ類、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ－ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ－Ｒ等の光ディスクを含むディスク類、ＩＣカード（メモリカードを含む）／光カード等のカード類、マスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ類、あるいはＰＬＤ（Programmable logic device）やＦＰＧＡ（Field Programmable Gate Array）等の論理回路類などを用いることができる。
　また、上記プログラムコードは、通信ネットワークを介してクライアント装置１００、プロキシサーバ２００、２５０、及び配信サーバ３００に供給してもよい。この通信ネットワークは、プログラムコードを伝送可能であればよく、特に限定されない。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、この通信ネットワークを構成する伝送媒体も、プログラムコードを伝送可能な媒体であればよく、特定の構成または種類のものに限定されない。例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ（Asymmetric Digital Subscriber Line）回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩＥＥＥ８０２．１１無線、ＨＤＲ（High Data Rate）、ＮＦＣ（Near Field Communication）、ＤＬＮＡ（Digital Living Network Alliance）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。
　なお、ここで開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
　以上のように、本発明のプロキシサーバでは、上記通信装置が複数存在し、上記送信装置が上記通信装置からの要求に応じて相異なる複数のコンテンツを送信可能に構成されており、上記送信手段が、同一のコンテンツについて一定期間内に一定数以上の通信装置から上記第１の要求が送られたことを検出した場合に限り、上記情報を上記通信装置に送信することが望ましい。
　上記の構成によれば、本発明のプロキシサーバは、同一のコンテンツについて、短期間の間に多数の通信装置からユニキャスト通信によりコンテンツを送信すべき旨の要求を受けた場合に、当該コンテンツをマルチキャスト通信により上記多数の通信装置に中継することができる。また、同一のコンテンツについて、少数の通信装置からしかユニキャスト通信によりコンテンツを送信すべき旨の要求を受けていない場合には、当該コンテンツをユニキャスト通信により上記少数の通信装置に中継する。
　したがって、上記プロキシサーバは、ネットワークの帯域負荷の状況に応じて、マルチキャスト通信によるネットワークの帯域負荷の抑制と、ユニキャスト通信による安定した伝送と、のバランスを良好に維持することができるというさらなる効果を奏する。
　上記送信装置が、上記通信装置からの要求に応じて、上記コンテンツを複数に分割することにより得られる各分割データを順次送信するように構成されており、上記プロキシサーバの上記中継手段は、上記記憶部にキャッシュされた各分割データを上記通信装置に順次中継することが望ましい。
　上記の構成によれば、プロキシサーバは、より効率的にマルチキャスト通信を行うことができるというさらなる効果を奏する。
　上記プロキシサーバでは、上記コンテンツは映像コンテンツであり、上記映像コンテンツは複数のムービーフラグメントから構成されていることが望ましい。
　上記の構成によれば、上記プロキシサーバは、上記コンテンツを再生する再生装置における上記映像コンテンツの細かな再生制御を可能にするというさらなる効果を奏する。
　上記プロキシサーバでは、上記送信装置から送信される上記映像コンテンツが、各パートが１つの上記ムービーフラグメントを含むマルチパート形式のデータであることが望ましい。
　上記の構成によれば、上記プロキシサーバから上記映像コンテンツが伝送される過程で、１つのパートのデータが欠損した場合であっても、上記通信装置が受信できないムービーフラグメントは１つとなる。
　したがって、プロキシサーバは、上記通信装置に欠損したデータを短期間で取得させることができるというさらなる効果を奏する。
　上記プロキシサーバでは、各パートには、上記１つのムービーフラグメントだけでなく、上記複数のムービーフラグメントのうち、当該１つのムービーフラグメントを、上記映像コンテンツを再生する再生装置が何番目に再生すべきかを示す値も含まれていることが望ましい。
　上記の構成によれば、上記プロキシサーバは、マルチパート形式のデータを受信した通信装置に、受信した各パートに上記何番目に再生すべきかを示す値が含まれているか否かを判定させることにより、欠損したムービーフラグメントを容易に把握させることができるというさらなる効果を奏する。
　上記プロキシサーバは、上記中継手段が、マルチキャスト通信により複数のパケットを各通信装置に送信することにより、各通信装置に中継すべき映像コンテンツを中継するように構成されており、上記複数のパケットの各々には、たかだか１つのムービーフラグメントの全体または一部のデータが含まれていることが望ましい。
　上記の構成によれば、上記プロキシサーバがマルチキャスト通信により通信装置に送信したＭ個のパケットのうちＮ個のパケットが伝送中に欠損した場合であっても、上記通信装置は、Ｍ－Ｎ個以上のムービーフラグメントを受信することができる。
　したがって、上記プロキシサーバは、伝送中に相当数のパケットが欠損した場合であっても、上記通信装置に欠損したデータを短期間で取得させることができるというさらなる効果を奏する。
　なお、上記プロキシサーバ（送信側プロキシサーバ）に対し上記第１の要求を送信する上記通信装置として機能するプロキシサーバであって、上記コンテンツを再生する再生装置から受信した上記第１の要求に応じて当該コンテンツを上記再生装置に中継する中継手段と、上記再生装置から受信した上記第１の要求を中継することにより上記情報を受信したときに、上記第２の要求を上記送信側プロキシサーバに送信すべきか否かを判定する第１の判定手段と、を備えているプロキシサーバも本発明の範疇に含まれる。
　上記の構成によれば、上記プロキシサーバは、上記第１の判定手段が上記第２の要求を上記送信側プロキシサーバに送信すべきであると判定した場合に限り、送信側プロキシサーバからマルチキャスト通信によりコンテンツを受信する。
　したがって、上記プロキシサーバは、状況に応じて、マルチキャスト通信によりネットワークの帯域負荷の抑制をするか、ユニキャスト通信により安定した伝送を確保するか、を適宜選択することができるという効果を奏する。
　また、上記プロキシサーバは、上記中継手段が、上記再生装置に上記コンテンツを中継している間、該コンテンツの中継のために上記再生装置と確立した接続状態を保つようになっており、第１のコンテンツを上記再生装置に中継している間に第２のコンテンツを送信すべき旨の第１の要求を受信した場合に、上記第１のコンテンツを中継するために上記再生装置と確立した接続状態を解除することが望ましい。
　上記の構成によれば、上記プロキシサーバは、上記再生装置が上記第１のコンテンツから上記第２のコンテンツに再生するコンテンツを切り替えた場合に、上記第１のコンテンツに関する処理をすぐに終了することができる。
　したがって、上記プロキシサーバは、上記再生装置の上記コンテンツの切換による処理負荷を低減させることができるというさらなる効果を奏する。
　また、上記プロキシサーバは、上記第１のコンテンツを上記再生装置に中継している間に上記第２のコンテンツを送信すべき旨の第１の要求を受信した場合に、上記第１のコンテンツが中継されている各通信装置が所属するマルチキャストグループから自装置を解除する旨の要求を上記送信側プロキシサーバに送信する送信手段と、上記第１のコンテンツが自装置に送信されなくなってから一定時間が経過したか否かを判定する第２の判定手段と、をさらに備え、上記第１の判定手段は、一定時間が経過したと上記第２の判定手段が判定した場合に、上記第２の要求を上記送信側プロキシサーバに送信すべきであると判定することが望ましい。
　上記の構成によれば、上記プロキシサーバは、上記再生装置が上記第１のコンテンツから上記第２のコンテンツに再生するコンテンツを切り替えた場合において、上記第１のコンテンツおよび上記第２のコンテンツの双方をマルチキャスト通信により上記送信側プロキシサーバから受信するというプロキシサーバ間のネットワークの無駄な帯域負荷を抑制することができるというさらなる効果を奏する。
　なお、本発明は、上記各プロキシサーバと、上記再生装置と、上記送信装置と、を含む通信システムとしても実現することができる。また、本発明に係るプロキシサーバを動作させるためのプログラムであって、コンピュータを上記の各手段として機能させることを特徴とする中継制御プログラム、および、その中継制御プログラムを記録した、コンピュータが読み取り可能な記録媒体も本発明の範疇に含まれる。
　本発明に係る通信システムは、映像配信システムとして広く利用することができる。
　１００　　　　　　　　　　　　クライアント装置（再生装置、通信装置）
　１００－１、１００－２　　　　クライアント装置
　１１０　　　　　　　　　　　　　ＨＴＴＰ処理部
　１２０　　　　　　　　　　　　　再生部
　２００　　　　　　　　　　　　クライアント装置のプロキシサーバ（通信装置）
　２００－１、２００－２　　　　クライアント装置のプロキシサーバ
　２０１　　　　　　　　　　　　　ＨＴＴＰ処理部（中継手段）
　２０２　　　　　　　　　　　　　キャッシュ部
　２０３　　　　　　　　　　　　　マルチキャスト処理部（送信手段、第１の判定手段、第２の判定手段）
　２５０　　　　　　　　　　　　配信サーバのプロキシサーバ
　２５１　　　　　　　　　　　　　ＨＴＴＰ処理部（送信手段）
　２５２　　　　　　　　　　　　　キャッシュ部（記憶部）
　２５３　　　　　　　　　　　　　マルチキャスト処理部（登録手段、中継手段）
　２５４　　　　　　　　　　　　　マルチキャストグループ情報記憶部
　３００　　　　　　　　　　　　配信サーバ
　３０１　　　　　　　　　　　　　ＨＴＴＰ処理部
　３０２　　　　　　　　　　　　　メモリ部

Claims (17)

  1. 　通信装置からの要求に応じて送信装置から送信されるコンテンツを、記憶部にキャッシュするとともに上記通信装置に中継するプロキシサーバであって、
    　ユニキャスト通信によりコンテンツを送信すべき旨の第１の要求が上記通信装置から上記送信装置に送られたことを検出した場合に、上記送信装置の代わりに該プロキシサーバがマルチキャスト通信により該コンテンツを送信可能であることを示す情報を上記通信装置に送信する送信手段と、
    　上記通信装置からマルチキャスト通信を用いて上記コンテンツを送信すべき旨の第２の要求を受信した場合に、上記通信装置をマルチキャストグループに登録する登録手段と、
    　上記記憶部にキャッシュされた該コンテンツを、マルチキャスト通信を用いて上記マルチキャストグループに登録された各通信装置に中継する中継手段と、を備えていることを特徴とするプロキシサーバ。
  2. 　請求項１に記載のプロキシサーバであって、
    　上記通信装置は複数存在し、
    　上記送信装置は上記通信装置からの要求に応じて相異なる複数のコンテンツを送信可能に構成されており、
    　上記送信手段は、同一のコンテンツについて一定期間内に一定数以上の通信装置から上記第１の要求が送られたことを検出した場合に限り、上記情報を上記通信装置に送信することを特徴とするプロキシサーバ。
  3. 　請求項１または２に記載のプロキシサーバであって、
    　上記第１の要求はＨＴＴＰリクエストメッセージであり、
    　上記送信手段は、上記情報をヘッダ情報として含むＨＴＴＰレスポンスメッセージとして送信するようになっており、
    　上記ヘッダ情報には、上記マルチキャストグループのアドレスを示す値が含まれていることを特徴とするプロキシサーバ。
  4. 　請求項１から３のいずれか１項に記載のプロキシサーバであって、
    　上記送信装置は、上記通信装置からの要求に応じて、上記コンテンツを複数に分割することにより得られる各分割データを順次送信するように構成されており、
    　上記中継手段は、上記記憶部にキャッシュされた各分割データを上記通信装置に順次中継することを特徴とするプロキシサーバ。
  5. 　請求項１から４のいずれか１項に記載のプロキシサーバであって、
    　上記コンテンツは映像コンテンツであり、
    　上記映像コンテンツは複数のムービーフラグメントから構成されていることを特徴とするプロキシサーバ。
  6. 　請求項５に記載のプロキシサーバであって、
    　上記送信装置から送信される上記映像コンテンツは、各パートが１つの上記ムービーフラグメントを含むマルチパート形式のデータであることを特徴とするプロキシサーバ。
  7. 　請求項６に記載のプロキシサーバであって、
    　各パートには、上記１つのムービーフラグメントだけでなく、上記複数のムービーフラグメントのうち、当該１つのムービーフラグメントを、上記映像コンテンツを再生する再生装置が何番目に再生すべきかを示す値も含まれていることを特徴とするプロキシサーバ。
  8. 　請求項５から７のいずれか１項に記載のプロキシサーバであって、
    　上記中継手段は、マルチキャスト通信により複数のパケットを各通信装置に送信することにより、各通信装置に中継すべき映像コンテンツを中継するように構成されており、
    　上記複数のパケットの各々には、たかだか１つのムービーフラグメントの全体または一部のデータが含まれていることを特徴とするプロキシサーバ。
  9. 　請求項１から８のいずれか１項に記載のプロキシサーバである送信側プロキシサーバに対し上記第１の要求を送信する上記通信装置として機能するプロキシサーバであって、
    　上記コンテンツを再生する再生装置から受信した上記第１の要求に応じて当該コンテンツを上記再生装置に中継する中継手段と、
    　上記再生装置から受信した上記第１の要求を中継することにより上記情報を受信したときに、上記第２の要求を上記送信側プロキシサーバに送信すべきか否かを判定する第１の判定手段を備えていることを特徴とするプロキシサーバ。
  10. 　請求項９に記載のプロキシサーバであって、
    　上記中継手段は、上記再生装置に上記コンテンツを中継している間、該コンテンツの中継のために上記再生装置と確立した接続状態を保つようになっており、
    　上記中継手段は、第１のコンテンツを上記再生装置に中継している間に第２のコンテンツを送信すべき旨の第１の要求を受信した場合に、上記第１のコンテンツを中継するために上記再生装置と確立した接続状態を解除することを特徴とするプロキシサーバ。
  11. 　請求項１０に記載のプロキシサーバであって、
    　上記第１のコンテンツを上記再生装置に中継している間に上記第２のコンテンツを送信すべき旨の第１の要求を受信した場合に、上記第１のコンテンツが中継されている各通信装置が所属するマルチキャストグループから自装置を解除する旨の要求を上記送信側プロキシサーバに送信する送信手段と、
    　上記第１のコンテンツが自装置に送信されなくなってから一定時間が経過したか否かを判定する第２の判定手段と、をさらに備え、
    　上記第１の判定手段は、一定時間が経過したと上記第２の判定手段が判定した場合に、上記第２の要求を上記送信側プロキシサーバに送信すべきであると判定することを特徴とするプロキシサーバ。
  12. 　上記コンテンツを再生する再生装置と、請求項１から８のいずれか１項に記載のプロキシサーバと、請求項９から１１のいずれか１項に記載のプロキシサーバと、上記通信装置と、を含む通信システム。
  13. 　通信装置からの要求に応じて送信装置から送信されるコンテンツを、記憶部にキャッシュするとともに上記通信装置に中継するプロキシサーバにおける中継方法であって、
    　ユニキャスト通信によりコンテンツを送信すべき旨の第１の要求が上記通信装置から上記送信装置に送られたことを検出した場合に、上記送信装置の代わりに該プロキシサーバがマルチキャスト通信により該コンテンツを送信可能であることを示す情報を上記通信装置に送信する送信工程と、
    　上記通信装置からマルチキャスト通信を用いて上記コンテンツを送信すべき旨の第２の要求を受信した場合に、上記通信装置をマルチキャストグループに登録する登録工程と、
    　上記記憶部にキャッシュされた該コンテンツを、マルチキャスト通信を用いて上記マルチキャストグループに登録された各通信装置に中継する中継工程と、を含んでいることを特徴とする中継方法。
  14. 　請求項１から８のいずれか１項に記載のプロキシサーバを動作させるプログラムであって、コンピュータを上記各手段として機能させるための中継制御プログラム。
  15. 　請求項１４に記載の中継制御プログラムが記録されているコンピュータ読み取り可能な記録媒体。
  16. 　請求項９から１１のいずれか１項に記載のプロキシサーバを動作させるプログラムであって、コンピュータを上記各手段として機能させるための中継制御プログラム。
  17. 　請求項１６に記載の中継制御プログラムが記録されているコンピュータ読み取り可能な記録媒体。
PCT/JP2011/066278 2010-07-20 2011-07-15 プロキシサーバ、中継方法、通信システム、中継制御プログラム、および記録媒体 WO2012011449A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US13/810,715 US20130114597A1 (en) 2010-07-20 2011-07-15 Proxy server, relay method, communication system, relay control program, and recording medium
JP2012525390A JPWO2012011449A1 (ja) 2010-07-20 2011-07-15 プロキシサーバ、中継方法、通信システム、中継制御プログラム、および記録媒体
EP11809619.7A EP2597824A4 (en) 2010-07-20 2011-07-15 PROXY SERVER, RELAY METHOD, COMMUNICATION SYSTEM, RELAY CONTROL PROGRAM, AND RECORDING MEDIUM
CN2011800354373A CN103004133A (zh) 2010-07-20 2011-07-15 代理服务器、中继方法、通信系统、中继控制程序、及记录介质

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010163366 2010-07-20
JP2010-163366 2010-07-20

Publications (1)

Publication Number Publication Date
WO2012011449A1 true WO2012011449A1 (ja) 2012-01-26

Family

ID=45496871

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/066278 WO2012011449A1 (ja) 2010-07-20 2011-07-15 プロキシサーバ、中継方法、通信システム、中継制御プログラム、および記録媒体

Country Status (5)

Country Link
US (1) US20130114597A1 (ja)
EP (1) EP2597824A4 (ja)
JP (1) JPWO2012011449A1 (ja)
CN (1) CN103004133A (ja)
WO (1) WO2012011449A1 (ja)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140092327A (ko) * 2011-10-12 2014-07-23 브로드피크 게이트웨이, 방법, 컴퓨터 프로그램, 및 대응하는 저장 수단
WO2014158707A1 (en) * 2013-03-14 2014-10-02 Apple Inc. Media delivery service protocol to support large numbers of client with error failover processes
KR101902323B1 (ko) * 2017-03-14 2018-09-28 주식회사 세연테크 멀티채널 프록시 ip카메라 및 이를 이용한 감시 시스템
KR101904050B1 (ko) * 2017-03-21 2018-10-04 주식회사 세연테크 프록시 ap카메라 및 이를 이용한 감시 시스템
JP2018170770A (ja) * 2018-06-01 2018-11-01 株式会社インフォシティ コンテンツ配信システム
JP2019118119A (ja) * 2019-02-26 2019-07-18 株式会社インフォシティ コンテンツ配信システム
JPWO2021005756A1 (ja) * 2019-07-10 2021-01-14
WO2021014591A1 (ja) * 2019-07-23 2021-01-28 日本電信電話株式会社 コンテンツ配信システム、マルチキャストユニキャスト／マルチキャストマルチキャスト変換装置、マルチキャストユニキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5760600B2 (ja) * 2011-03-31 2015-08-12 ソニー株式会社 通信装置、受信装置、通信方法、および通信システム
JP5823615B2 (ja) * 2011-08-16 2015-11-25 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． データフロー再利用送信のための方法、複製ポイント装置及びシステム
US9519614B2 (en) * 2012-01-10 2016-12-13 Verizon Digital Media Services Inc. Multi-layer multi-hit caching for long tail content
CN102869003A (zh) * 2012-08-28 2013-01-09 中兴通讯股份有限公司 一种异构网络下业务内容分发的方法、业务管理平台
US9432204B2 (en) * 2013-08-24 2016-08-30 Nicira, Inc. Distributed multicast by endpoints
US9602385B2 (en) 2013-12-18 2017-03-21 Nicira, Inc. Connectivity segment selection
US9602392B2 (en) 2013-12-18 2017-03-21 Nicira, Inc. Connectivity segment coloring
US9794079B2 (en) 2014-03-31 2017-10-17 Nicira, Inc. Replicating broadcast, unknown-unicast, and multicast traffic in overlay logical networks bridged with physical networks
US9794855B2 (en) 2014-10-01 2017-10-17 At&T Intellectual Property I, L.P. Facilitation of geographically addressed data streaming
US10158682B2 (en) * 2015-09-23 2018-12-18 Adobe Systems Incorporated Power efficient multimedia content streaming based on a server push
US10152080B2 (en) 2015-09-23 2018-12-11 Adobe Systems Incorporated Power efficient multimedia content streaming based on media segment duration
EP3398073B1 (en) * 2016-02-10 2023-03-29 Mobileiron, Inc. Securely storing and distributing sensitive data in a cloud-based application
TWI758680B (zh) * 2019-01-31 2022-03-21 日商日本電氣股份有限公司 資料中繼裝置、方法、發送系統及程式
EP3932082A1 (en) 2019-02-27 2022-01-05 British Telecommunications public limited company Multicast assisted delivery
US10778457B1 (en) 2019-06-18 2020-09-15 Vmware, Inc. Traffic replication in overlay networks spanning multiple sites
GB2598295B (en) 2020-08-19 2023-02-22 British Telecomm Content delivery
WO2022178762A1 (en) * 2021-02-25 2022-09-01 Huawei Technologies Co., Ltd. Ad-hoc multicast delivery of unicast services
US11784922B2 (en) 2021-07-03 2023-10-10 Vmware, Inc. Scalable overlay multicast routing in multi-tier edge gateways

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000155712A (ja) * 1998-11-19 2000-06-06 Nippon Telegr & Teleph Corp <Ntt> 分散キャッシュ配送方法及び分散キャッシュ配送プログラムを記憶した媒体
JP2004215052A (ja) * 2003-01-07 2004-07-29 Nec Nexsolutions Ltd 情報配信システム及び情報配信方法
JP2005110244A (ja) 2003-09-27 2005-04-21 Lg Electronics Inc マルチメディアストリーミングサービスシステム及びその方法
JP2007173987A (ja) 2005-12-19 2007-07-05 Canon Inc マルチメディアデータ送受信システム、及び装置、又はプログラム
JP2008311947A (ja) * 2007-06-14 2008-12-25 Panasonic Corp コンテンツ配信システム、コンテンツサーバ、端末、コンテンツ配信方法、プログラムおよび記録媒体

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6658463B1 (en) * 1999-06-10 2003-12-02 Hughes Electronics Corporation Satellite multicast performance enhancing multicast HTTP proxy system and method
JP2001283015A (ja) * 2000-03-29 2001-10-12 Nippon Columbia Co Ltd コンテンツデータ配信システムおよび方法
US7237034B2 (en) * 2000-09-18 2007-06-26 Openwave Systems Inc. Method and apparatus for controlling network traffic
JP3881182B2 (ja) * 2001-03-09 2007-02-14 株式会社エヌ・ティ・ティ・ドコモ 中継方法および代理サーバ装置
US7174384B2 (en) * 2001-07-31 2007-02-06 Dinastech Ipr Limited Method for delivering large amounts of data with interactivity in an on-demand system
US20030195964A1 (en) * 2002-04-10 2003-10-16 Mane Pravin D. Managing multicast sessions
US7623497B2 (en) * 2002-04-15 2009-11-24 Qualcomm, Incorporated Methods and apparatus for extending mobile IP
US7657644B1 (en) * 2002-05-10 2010-02-02 Netapp, Inc. Methods and apparatus for streaming media multicast
US7281058B1 (en) * 2002-10-09 2007-10-09 Juniper Networks, Inc. Delivering and receiving multicast content across a unicast network
US7586938B2 (en) * 2003-10-24 2009-09-08 Microsoft Corporation Methods and systems for self-describing multicasting of multimedia presentations
KR100643292B1 (ko) * 2005-04-29 2006-11-10 삼성전자주식회사 세션 개시 프로토콜 단말기 사용자의 주소 정보 관리 방법및 이를 위한 서버
US7593326B2 (en) * 2005-06-29 2009-09-22 International Business Machines Corporation Method and apparatus for managing bandwidth requirements for video on demand services
JP5277158B2 (ja) * 2006-04-11 2013-08-28 トムソン ライセンシング データ受信方法、修復方法および対応する端末
US20080134266A1 (en) * 2006-11-24 2008-06-05 Young-Seok Kang Digital broadcasting system and error correction method thereof
JP4984917B2 (ja) * 2007-01-26 2012-07-25 日本電気株式会社 マルチキャスト通信システムおよび方法
US8489702B2 (en) * 2007-06-22 2013-07-16 Apple Inc. Determining playability of media files with minimal downloading
US8064449B2 (en) * 2007-10-15 2011-11-22 Media Patents, S.L. Methods and apparatus for managing multicast traffic
US8387102B1 (en) * 2008-12-22 2013-02-26 Qurio Holdings, Inc. Method and system for minimizing a number of data streams
US20130124683A1 (en) * 2010-07-20 2013-05-16 Sharp Kabushiki Kaisha Data distribution system, data distribution method, data relay device on distribution side, and data relay device on reception side

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000155712A (ja) * 1998-11-19 2000-06-06 Nippon Telegr & Teleph Corp <Ntt> 分散キャッシュ配送方法及び分散キャッシュ配送プログラムを記憶した媒体
JP2004215052A (ja) * 2003-01-07 2004-07-29 Nec Nexsolutions Ltd 情報配信システム及び情報配信方法
JP2005110244A (ja) 2003-09-27 2005-04-21 Lg Electronics Inc マルチメディアストリーミングサービスシステム及びその方法
JP2007173987A (ja) 2005-12-19 2007-07-05 Canon Inc マルチメディアデータ送受信システム、及び装置、又はプログラム
JP2008311947A (ja) * 2007-06-14 2008-12-25 Panasonic Corp コンテンツ配信システム、コンテンツサーバ、端末、コンテンツ配信方法、プログラムおよび記録媒体

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2597824A4

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140092327A (ko) * 2011-10-12 2014-07-23 브로드피크 게이트웨이, 방법, 컴퓨터 프로그램, 및 대응하는 저장 수단
KR101999237B1 (ko) 2011-10-12 2019-07-11 브로드피크 게이트웨이, 방법, 컴퓨터 프로그램, 및 대응하는 저장 수단
JP2015501569A (ja) * 2011-10-12 2015-01-15 ブロードピーク ゲートウェイ、並びにゲートウェイに対応する方法、コンピュータプログラム、及び記憶手段
US9917916B2 (en) 2013-03-14 2018-03-13 Apple Inc. Media delivery service protocol to support large numbers of client with error failover processes
TWI558180B (zh) * 2013-03-14 2016-11-11 蘋果公司 用於運用容錯移轉程序支援大量用戶端之媒體傳送服務協定
WO2014158707A1 (en) * 2013-03-14 2014-10-02 Apple Inc. Media delivery service protocol to support large numbers of client with error failover processes
KR101902323B1 (ko) * 2017-03-14 2018-09-28 주식회사 세연테크 멀티채널 프록시 ip카메라 및 이를 이용한 감시 시스템
KR101904050B1 (ko) * 2017-03-21 2018-10-04 주식회사 세연테크 프록시 ap카메라 및 이를 이용한 감시 시스템
JP2018170770A (ja) * 2018-06-01 2018-11-01 株式会社インフォシティ コンテンツ配信システム
JP2019118119A (ja) * 2019-02-26 2019-07-18 株式会社インフォシティ コンテンツ配信システム
JPWO2021005756A1 (ja) * 2019-07-10 2021-01-14
JP2023033600A (ja) * 2019-07-10 2023-03-10 日本電信電話株式会社 コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム
JP7298688B2 (ja) 2019-07-10 2023-06-27 日本電信電話株式会社 コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム
US11882340B2 (en) 2019-07-10 2024-01-23 Nippon Telegraph And Telephone Corporation Content distribution system, unicast multicast converter, content distribution method and content distribution program
JP7473025B2 (ja) 2019-07-10 2024-04-23 日本電信電話株式会社 コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム
WO2021014591A1 (ja) * 2019-07-23 2021-01-28 日本電信電話株式会社 コンテンツ配信システム、マルチキャストユニキャスト／マルチキャストマルチキャスト変換装置、マルチキャストユニキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム
JPWO2021014591A1 (ja) * 2019-07-23 2021-01-28
JP7298690B2 (ja) 2019-07-23 2023-06-27 日本電信電話株式会社 コンテンツ配信システム、マルチキャストユニキャスト／マルチキャストマルチキャスト変換装置、マルチキャストユニキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム

Also Published As

Publication number Publication date
CN103004133A (zh) 2013-03-27
US20130114597A1 (en) 2013-05-09
EP2597824A4 (en) 2014-02-26
JPWO2012011449A1 (ja) 2013-09-09
EP2597824A1 (en) 2013-05-29

Similar Documents

Publication Publication Date Title
WO2012011449A1 (ja) プロキシサーバ、中継方法、通信システム、中継制御プログラム、および記録媒体
JP5791893B2 (ja) 以前の伝送データを用いた、ビデオ・コンテンツ及びサービスのブロードキャストの受信のための方法及びデバイス
KR102120525B1 (ko) 통신 장치, 통신 데이터 생성 방법, 및 통신 데이터 처리 방법
CN110915180A (zh) 低时延媒体摄取系统、设备和方法
WO2012096372A1 (ja) コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造
JPWO2012011467A1 (ja) データ配信システム、データ配信方法、配信側データ中継装置、及び受信側データ中継装置
CN106464932A (zh) 多播流传输
JP6329964B2 (ja) 送信装置、送信方法、受信装置、及び、受信方法
WO2012011490A1 (ja) コンテンツ取得装置、コンテンツ送信装置、コンテンツ送受信システム、データ構造、制御方法、制御プログラム、及び記録媒体
KR102247976B1 (ko) 통신 장치, 통신 데이터 생성 방법, 및 통신 데이터 처리 방법
WO2015107786A1 (ja) 通信装置、通信データ生成方法、および通信データ処理方法
KR102137858B1 (ko) 송신 장치, 송신 방법, 수신 장치, 수신 방법 및 프로그램
WO2012011466A1 (ja) 中継装置、中継方法、通信システム、中継制御プログラム、および記録媒体
KR20160138044A (ko) 미디어 데이터를 스트리밍하기 위한 목표된 광고 삽입
KR102176404B1 (ko) 통신 장치, 통신 데이터 생성 방법, 및 통신 데이터 처리 방법
JP2010161550A (ja) 映像コンテンツ受信装置、および映像コンテンツ受信方法
JPWO2005027439A1 (ja) メディアストリームのマルチキャスト配信方法及び装置
KR101829064B1 (ko) Ｄａｓｈ 규격의 미디어 데이터와 ｍｍｔ 전송 시스템과의 연동 방법 및 그 장치
JP2008016894A (ja) 送信装置及び受信装置
Robinson Live streaming ecosystems
WO2015064384A1 (ja) 送信装置、送信方法、受信装置、及び、受信方法
EP3588847A1 (en) Multicast signal transmitting and receiving method and device
TW200906185A (en) A network unit, a central distribution control unit and a computer program product

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11809619

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13810715

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2012525390

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2011809619

Country of ref document: EP