WO2021005756A1 - コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム - Google Patents

コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム Download PDF

Info

Publication number
WO2021005756A1
WO2021005756A1 PCT/JP2019/027388 JP2019027388W WO2021005756A1 WO 2021005756 A1 WO2021005756 A1 WO 2021005756A1 JP 2019027388 W JP2019027388 W JP 2019027388W WO 2021005756 A1 WO2021005756 A1 WO 2021005756A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
unicast
multicast
request
communication
Prior art date
Application number
PCT/JP2019/027388
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 US17/625,554 priority Critical patent/US11882340B2/en
Priority to JP2021530431A priority patent/JP7298688B2/ja
Priority to PCT/JP2019/027388 priority patent/WO2021005756A1/ja
Publication of WO2021005756A1 publication Critical patent/WO2021005756A1/ja
Priority to JP2023007138A priority patent/JP7473025B2/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • 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
    • 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/1066—Session management
    • H04L65/1073—Registration or de-registration
    • 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
    • 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/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6408—Unicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64707—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless for transferring content from a first network to a second network, e.g. between IP and wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • 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
    • 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/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments
    • 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]

Definitions

  • This disclosure relates to a method of converting a plurality of unicast traffics having different destinations and the same content identifiers from unicast to multicast and from multicast to unicast.
  • the amount of Internet traffic is increasing year by year, and the increase in video traffic is particularly remarkable.
  • An increase in the amount of traffic on the Internet means an increase in traffic via the network of a telecommunications carrier.
  • content distributors and telecommunications carriers must make capital investment so that congestion does not occur.
  • Non-Patent Document 1 Multicast is effective when delivering the same content to a large number of end users, and consumes less transmission band than when delivering the same content to each end user by unicast. Since the effect increases as the number of end users receiving the content increases, it is suitable for content that is expected to be received by a large number of end users.
  • Patent No. 4665007 "Surveillance Video Transmitter and Method”
  • Patent No. 4814998 "Methods and Devices for Reliable Delivery of Multicast Data”
  • the content distribution service can only be established if there are distribution equipment, a network, and a recipient terminal. Therefore, these devices and equipment must be interconnected.
  • the above-mentioned multicast has a problem regarding this connectivity.
  • connection interface between the distribution facility and the network hereinafter, SNI (Application Service-Network Interface)
  • UNI User-Network Interface
  • IF Interface
  • traffic means that various information for distributing the content is added to the content. For example, when the content is stored in an IP packet and transmitted, the combination of the IP header and the payload in which the content is stored is called traffic.
  • the network portion is preferably multicast from the viewpoint of efficient use of the transmission band described above. Since these are contradictory conditions, a technique for making them compatible is required.
  • the purpose of this disclosure is to enable efficient transfer of content while maintaining the unicast HTTP in the HTTP-based web distribution system.
  • a unicast multicast conversion device that is, a unicast multicast conversion unit (hereinafter referred to as UMC) is provided in the network between the content server that performs web distribution and the receiving terminal.
  • a multicast unicast converter that is, a multicast / unicast converter (hereinafter referred to as MUC) is provided to enable multicast communication in the traffic between the UMC and the MUC. This will promote the reduction of investment in server equipment and network equipment, and will realize higher image quality and stabilization of the delivered video image quality.
  • the content distribution system related to this disclosure is A content distribution system in which the intermediate section between the terminal and the content server in the unicast communication web distribution system is connected using a multicast communication network. It is equipped with a unicast multicast conversion device that converts unicast communication to multicast communication and sends it to the multicast communication network, and a multicast unicast conversion device that converts multicast communication transmitted by the multicast communication network into unicast communication.
  • the multicast unicast converter is A content group in which a plurality of contents are grouped is identified, and the content transmitted by using one or both communication methods of unicast communication and multicast communication is received from the multicast communication network for each content group.
  • a content reception cache unit that stores the content included in the content group, and A unicast transmission unit that transmits the content stored in the content reception cache unit to the terminal based on a request from the terminal, and a unicast transmission unit.
  • the request of the content group including the content corresponding to the request from the terminal can be made by either unicast communication or multicast communication or A content request section that selectively performs both communication methods,
  • the unicast multicast converter A unicast reception cache unit that receives and stores content from the content server using unicast communication, The content group corresponding to the request from the content request unit is read from the unicast reception cache unit, and the read content group is used for the multicast communication by using one or both communication methods of unicast communication and multicast communication.
  • the unicast request unit that is used for the content server and To be equipped.
  • the unicast multicast converter is A unicast multicast converter that is connected to the middle section between a terminal and a content server in a unicast communication web distribution system, converts unicast communication to multicast communication, and sends it to a multicast communication network.
  • a unicast reception cache unit that receives and stores content from the content server using unicast communication, When a request for a content group in which a plurality of contents are grouped is received from a multicast unicast conversion device that converts multicast communication transmitted on the multicast communication network into unicast communication, the content group corresponding to the request is unicast.
  • a content transmission unit that reads from the cast reception cache unit and transmits the read content group to the multicast communication network using one or both of unicast communication and multicast communication.
  • the request of the content group corresponding to the request from the multicast unicast converter is unicasted.
  • the unicast request unit that is used for the content server and To be equipped.
  • the content distribution method is It is a content distribution method executed by a unicast multicast conversion device that is connected to the middle section between a terminal and a content server in a unicast communication web distribution system, converts unicast communication to multicast communication, and sends it to a multicast communication network.
  • Content is received from the content server using unicast communication, and the content is stored in the unicast reception cache unit.
  • the content transmission unit receives a request for a content group in which a plurality of contents are grouped from a multicast unicast conversion device that converts the multicast communication transmitted on the multicast communication network into unicast communication, the content transmission unit responds to the request.
  • the content group is read from the unicast reception cache unit, and the read content group is transmitted to the multicast communication network by using one or both communication methods of unicast communication and multicast communication.
  • the unicast request unit does not store the content group corresponding to the request from the multicast unicast converter in the unicast reception cache unit, the request of the content group corresponding to the request from the multicast unicast converter Is performed on the content server using unicast communication.
  • the content distribution program according to the present disclosure is a program for realizing a computer as each functional unit provided in the unicast multicast converter or the multicast unicast converter according to the present disclosure, and the content according to the present disclosure. It is a program for causing a computer to execute each step provided in the delivery method.
  • An example of the system configuration according to the first embodiment is shown.
  • the sequence of the first embodiment when there is no cache in MUC and UMC is shown.
  • An example of the function of MUC is shown.
  • An example of the function of UMC is shown.
  • the sequence of the tenth embodiment when there is no cache in MUC and UMC is shown.
  • the sequence of the eleventh embodiment when there is no cache in MUC and UMC is shown.
  • a first example of the sequence of the fourteenth embodiment is shown.
  • a second example of the sequence of the fourteenth embodiment is shown.
  • the schematic configuration of the UMC of the fifteenth embodiment is shown.
  • the schematic configuration of the MUC of the fifteenth embodiment is shown.
  • An example of the table image held by the table 801 is shown.
  • An example of the table image held by the table 802 and the table 803 is shown.
  • the content distributed by the content distribution method according to the present disclosure is video content, but in the present disclosure, other content (for example, an image, a Web page, an OS (Operation System)) is assumed. Update files, antivirus software definition files, etc.) can also be distributed.
  • FIG. 1 shows an example of a network configuration including the content distribution method according to the present disclosure.
  • the distribution system according to the present disclosure includes a content server 106, a UMC 105, an MUC 104, and a terminal 107. Further, between the content server 106 and the terminal 107, there is a multicast communication network 102, which is a network capable of multicast communication.
  • the network 101 and the network 103 are separate, but a single network may be used.
  • the UMC 105 is placed at the boundary between the network 103 and the network 102 or the network 102
  • the MUC 104 is placed at the boundary between the network 102 and the network 101 or the network 102.
  • the content server 106 and the terminal 107 communicate with each other using unicast HTTP.
  • the UMC 105 mainly converts the communication from unicast to multicast
  • the MUC 104 mainly converts the communication from multicast to unicast.
  • the present disclosure eliminates the need to change the connection method between the content server 106 and the terminal 107, which is called web distribution.
  • the number of MUC 104 is one or more, and each is connected to zero or more terminals 107.
  • the MUC104 mainly converts the communication from multicast to unicast, but the communication before conversion may include unicast communication or only unicast communication.
  • the UMC 105 mainly converts the communication from unicast to multicast, but the converted communication may include unicast communication or only unicast communication.
  • the system of the present disclosure is substantially equivalent to a multi-stage web proxy system.
  • the present disclosure is a system that adaptively multicasts a part of the communication (between UMC105 and MUC104) in the web proxy system (UMC105 and MUC104 in the present disclosure) which is an application layer.
  • FIG. 2 shows a communication flow when the MUC 104 and the UMC 105 do not have a cache.
  • step S1 The MUC 104 that has received 1 executes step S1.
  • step S1 the MUC 104 receives the HTTP request req. From the terminal 107. Judging that there is no cache corresponding to 1, HTTP request req.
  • UMC105 which is a higher-level proxy server. Transfer 2.
  • the UMC 105 received the HTTP request req. From the MUC 104 in step S2. Judging that there is no cache corresponding to 2, the HTTP request req. To the content server 106. Transfer 3
  • the content server 106 is a req.
  • the content file corresponding to 3 is described in the HTTP response res. 1 to respond to UMC105. res.
  • the UMC 105 that received 1 executes step S3.
  • the UMC105 is res.
  • a cache file is generated using the content file included in 1, and the cache file is returned to the UMC 104.
  • the response from the UMC 105 to the MUC 104 is the HTTP request req. It is a response corresponding to 2, and is an HTTP response res. 2.
  • Response by multicast M-res. 2, or res. Both 2 and M-res2 can be adopted.
  • the MUC 104 that has received 2 or M-res2 executes step S4.
  • the MUC 104 is res. 2 or M-res. Stores the cache file included in 2.
  • the MUC104 sets the cache file stored in the HTTP response res.
  • Reply 3 res. 3 is the HTTP request req. It is a response to the terminal 107 corresponding to 1.
  • the caches of MUC104 and UMC105 are deleted at an appropriate timing from the limitation of the storage capacity of the disk or the like or the distribution policy.
  • this disclosure is a unicast communication, Res. 2 and M-res. Multicast communication.
  • the following effects can be expected by using the two messages together.
  • -Multicast communication reduces unnecessary unicast communication, which reduces network bandwidth and load on servers. This makes it possible to deliver more stable and higher quality video than when only unicast communication is used.
  • an environment where multicast communication is not possible communication by conventional unicast communication can be ensured.
  • an environment that cannot communicate may be a temporary non-communication environment such as the exhaustion of multicast addresses and the number of multicast routes, or the excess of traffic for multicast.
  • a network that dynamically generates a multicast route it is possible to shorten the time until the start of video playback by delivering it by unicast communication prior to the generation of the route.
  • retransmitting a multicast packet due to packet loss in the transmission line, reception error of the receiver (MUC104), etc. means that the multicast packet is transmitted not only to the lost MUC104 but also to other MUC104s. This is because it is desirable to perform retransmission for individual MUC104 in order to reduce the network bandwidth and the load on other MUC104.
  • this system can support not only the distribution of real-time content but also the distribution of low-real-time content by using the cache.
  • FIG. 3 shows an example of the function of the MUC 104 for executing each step in FIG.
  • the MUC 104 includes a content request unit 204, a content reception cache unit 205, and a unicast transmission unit 206.
  • the unicast transmitter 206 receives a request req. From the terminal 107. Based on 1, content reception cache unit 205 to req. The content file corresponding to 1 is read, and the content file is res. 3 is transmitted to the terminal 107.
  • This cache is a file or stream in HTTP. Further, the cache does not have to be a complete file, and only some data can be sequentially transmitted as unicast communication. As a result, the terminal 107 can communicate with the unicast transmission unit 206 of the MUC 104 in the same process as the process of directly transmitting the HTTP request to the content server 106 and receiving the HTTP response.
  • the content request unit 204 reqs the content to the UMC 105 when there is no cache corresponding to the request from the terminal 107.
  • Request in 2.
  • Requests are selectively made by both unicast communication and multicast communication, or by one communication method. For example, this request utilizes an HTTP request and selective requests are distinguished using an HTTP header.
  • the content reception cache unit 205 identifies the content requested from the content request unit 204 into content groups grouped by a plurality of contents, and uses both unicast communication and multicast communication communication or one communication method for each content group. Selectively receive and cache content.
  • the content here is, for example, a file.
  • one program may be composed of multiple files, so when converting to a stream such as multicast, by treating multiple files as one content group, conversion to multicast communication can be performed efficiently. It is possible. That is, when transferring different files of one program, there is an advantage that the transfer can be performed with the same multicast source address and group address.
  • selective reception by both unicast communication and multicast communication communication or one communication method means that, for example, multicast is transferred before the multicast path is established or for some reason. It is conceivable to perform unicast communication in a network that cannot be used, and to perform multicast communication after the multicast path is established.
  • multicast communication is used for content with high broadcastability and immediacy
  • unicast communication is used for content with low error recovery or broadcastability or low immediacy. This makes it possible to efficiently use network equipment and bandwidth.
  • FIG. 4 shows the function of the UMC 105 for executing each step in FIG.
  • the UMC 105 has a unicast request unit 201, a unicast reception cache unit 202, and a content transmission unit 203.
  • the content transmission unit 203 reads the content from the cache based on the request from the MUC 104 and transmits the content to the MUC 104.
  • the MUC 104 selectively transmits both unicast communication and multicast communication, or one of the communication methods, for each content group.
  • the UMC 105 and the MUC 104 cooperate in order to receive both unicast communication and multicast communication, or one or the other selectively.
  • the content reception cache unit 205 provided in the MUC 104 has a mechanism for notifying the UMC 105 whether the target multicast signal can be received.
  • the content transmission unit 203 of the UMC 105 can switch the unicast communication to the multicast communication.
  • the content reception cache unit 205 provided in the MUC 104 receives both the multicast signal and the unicast signal before the multicast path is established. Before the multicast path is established, the content reception cache unit 205 generates a cache by the unicast signal. Since the content reception cache unit 205 has been able to receive the multicast signal, the content reception cache unit 205 can determine that the multicast signal can be received.
  • the content reception cache unit 205 determines that the multicast signal cannot be received.
  • the content request unit 204 specifies a unicast signal and requests the content transmission unit 203.
  • the unicast request unit 201 requests the content from the content server 106 by unicast communication when there is no cache corresponding to the request from the content request unit 204.
  • HTTP is used for this request, and the content server 106 does not need to have a special connection interface with this system, and can be processed in the same manner as receiving a direct HTTP request of a normal terminal 107. ..
  • the unicast reception cache unit 202 receives and caches the content transmitted by the unicast communication from the content server 106 based on the request from the unicast request unit 201.
  • MUC104 there are a plurality of MUC104s. If the MUC104 has no cache, req. Due to 1 cause, req. 2. req. Content is requested from 3 and the content server 106, and res. 1, res. 2 and M-res. 2, res. While creating a cache in step 3, it responds to the terminal 107.
  • the content reception cache unit 205 will return a direct response. Even if it is another MUC104, if the content has been delivered by multicast or the like, a response is similarly returned from the content reception cache unit 205. If it is another MUC104 and the content has not been delivered from UMC105, req. Although 2 is sent, the content of the request is waited for by UMC105, and MUC104 waits for delivery by multicast or unicast. If it is another MUC104 and the content has already been delivered by multicast from UMC105, it is possible that another MUC104 has received a mistake or has not joined the multicast group of IP multicast. Therefore, from UMC105, res. 2 is returned.
  • the unicast reception cache unit 202 generates a content group grouped by a plurality of contents. At this time, the unicast reception cache unit 202 generates a content group identifier for identifying the content groups grouped by a plurality of contents.
  • the unicast reception cache unit 202 generates a content group identifier obtained by extracting a part from the content identifier consisting of the content placement location and the file name. In this way, the same content group may have the same identifier.
  • a URL Uniform Resource Locator
  • the URL consists of a host name, a path, a file name, a query string, and the like.
  • the content group identifier obtained by extracting a part from these content identifiers does not necessarily have to be known, and may be predictable. For example, in “http // Y-HOST / Z-PATH / streams-X-NUMBER.ts", "Y-HOST” matches some host name, Z-PATH matches some path, "X- When “NUMBER” matches some number, those having the same "Y-HOST / Z-PHAT” part are regarded as the same content group.
  • multicast communication may be performed as another content group.
  • a function of listing and grouping a plurality of contents as a video and identifying the content group based on a manifest file indicating the location of the contents may be provided. Good.
  • a manifest file is used to consider multiple files as one content group and to indicate the files to be downloaded. Therefore, it is also possible to analyze the manifest file and make the files described in the manifest into the same content group.
  • the content group identifier which is a subset of that content identifier, must be known or predictable, but when identifying content from a manifest, the content identifier is known. It doesn't have to be.
  • the content identifier of the manifest file may be known, but in the web video distribution system, the extension of the manifest file is known depending on the method such as m3u8 or mpd, so the manifest file is known from the extension. It may be determined that the above is true and the analysis may be performed.
  • the content group may have a function of controlling or distinguishing a multicast group address, a source address, a port number, and a packet priority, and performing multicast communication.
  • IP multicast In IP multicast, in IGMP (Internet Group Management Protocol) and MLD (Multicast Listener Discovery), the same multicast group is identified by using the destination multicast group address, or the source address that is the source is identified. Use to identify.
  • IGMP Internet Group Management Protocol
  • MLD Multicast Listener Discovery
  • the same multicast group address or the source address may be assigned to the same content group for communication.
  • port numbers and packet priorities can be set and distinguished.
  • the packet priority it is conceivable to use the Cos value of Ethernet (registered trademark), IP Precedence of the header of the IP packet, DCSP, or the like.
  • Ethernet registered trademark
  • IP Precedence IP Precedence of the header of the IP packet
  • DCSP DCSP
  • the priority of packets it is possible to give the content group superiority or inferiority as a service.
  • the determination of the content group and the transmission / reception using the multicast communication identifiers are performed by the MUC 104 and the UMC 105, and a part of this information is performed. Alternatively, all can be centrally managed by UMC105 or the like.
  • the MUC 104 can execute the management inquiry in the steps S1 and S4, and the UMC 105 can execute the management inquiry in the steps S2 and S3.
  • the system of the present embodiment includes a function of discriminating between multicast target content and non-target content.
  • the content request unit 204 of the MUC 104 has a function of determining whether the content is the content to be multicast and, if not the content to be multicast, requesting the content from the UMC 105 or the content server 106 by unicast communication.
  • the content transmission unit 203 of the UMC 105 has a function of transmitting the content by unicast when the unicast request is received from the MUC 104.
  • the content using MUC104 or UMC105 as a general web proxy system may coexist.
  • extensions other than moving images can be processed as they are as a web proxy system without moving to the step of performing processing or determination using multicast communication.
  • the system of the present disclosure can simplify the multicast processing and can accept HTTP requests other than the multicast target such as moving images, and can be used as a general-purpose proxy.
  • the system of this embodiment includes a multicast dynamic join / leave function.
  • the content request unit 204 of the MUC 104 determines whether or not the content is participating in the multicast group corresponding to the content group. If not participating, the content request unit 204 sends a participation signal. On the other hand, when there is no request for the content of the content group corresponding to the joined multicast group for a certain period of time, the content request unit 204 sends a withdrawal signal from the multicast group.
  • participation registration and participation withdrawal of the multicast route can be dynamically performed each time a target multicast communication occurs.
  • IGMP and MLD can be used for this dynamic participation registration and withdrawal mechanism.
  • this dynamic participation registration and participation withdrawal it is possible to prevent multicast communication of a content group that has not been viewed among a plurality of MUC104, and it is possible to suppress unnecessary traffic. Further, when the number of registered multicast groups is limited, the number of registered multicast groups can be suppressed. It can also be assumed that a static multicast group is set in the router.
  • the system of this embodiment performs unicast communication before the multicast join.
  • the MUC 104 sends a participation signal and a multicast route to the MUC 104 is established, the content can be distributed to the MUC 104 using the multicast communication.
  • the present disclosure is capable of supporting such a dynamic participation / withdrawal function of multicast of MUC104.
  • the content request unit 204 requests the content from the UMC 105 by unicast communication after sending the participation signal and before the multicast route is established.
  • the content reception cache unit 205 receives the content from the UMC 105 by unicast communication and caches the content.
  • the content transmission unit 203 provided in the UMC 105 transmits the content by unicast when the unicast request is received from the MUC 104.
  • MUC104 is req. In 2, it is possible to explicitly instruct that multicast is not required.
  • UMC105 Upon receiving this message, UMC105 received the unicast communication res. Be sure to respond to 2.
  • UMC105 is a multicast communication M-res. It is also possible to respond by combining 2.
  • the UMC104 is a M-res. Res. Without waiting for the arrival of 2. By receiving 2, a cache is generated.
  • the completion of dynamic participation registration to the multicast group to the router can be easily set by the timer. After the setting timer has elapsed, it is possible to perform the operation on the premise of multicast communication, assuming that the multicast group has been registered in the router.
  • UMC105 is res. 2 and M-res. 2 can be transmitted at the same time.
  • MUC104 M-res. By receiving 2, it can be determined that the dynamic registration of the multicast group to the router is completed.
  • MUC104 determines that multicast communication such as completion of registration to the multicast group is possible, res. In 2, M-res. Of multicast communication. Only 2 can be requested.
  • the system of this embodiment includes an FEC function for multicast communication.
  • the content transmission unit 203 of the UMC 105 may have a function of adding forward error correction code (FEC) information and performing multicast transmission in the multicast transmission function.
  • the content reception cache unit 205 of the MUC 104 has a function of correcting the multicast signal to which the FEC information from the UMC 105 is added based on the FEC information.
  • FEC forward error correction code
  • IP multicast Communication by IP multicast is one-to-many communication, and individual error correction such as automatic repeat request (ARQ) cannot be performed. Therefore, by adding a certain amount of redundant data as FEC information, it is possible to compensate for data defects due to packet loss in the transmission line, packet reception error by the receiver, and the like. As a result, stable communication can be enabled even in an unstable transmission line where packet loss is likely to occur or when the receiver cannot receive stable packets.
  • ARQ automatic repeat request
  • the FEC used for multicast communication may adopt the following configuration.
  • the content information before FEC is added and the added FEC information are multicast-transmitted as different packets.
  • the packet of the content information before the FEC information is added and the packet of the added FEC information are different in part or all of the multicast group address, the source address, the port number, and the packet priority.
  • redundant data of about 10 to 20% increases with respect to the data before adding FEC information.
  • This can be a single content group with the original data, but it can also be separate. This makes it easier to separate processes, and makes it easier to monitor and filter in the network.
  • the system of this embodiment includes an ARQ function for multicast communication.
  • the content request unit 204 of the MUC 104 has an ARQ unicast request function
  • the content reception cache unit 205 has an ARQ unicast reception cache function.
  • the content transmission unit 203 of the UMC 105 has a unicast transmission function.
  • the ARQ unicast request function is a function of transmitting a unicast request to request content using unicast communication when there is a loss in the multicast signal received from UMC105.
  • the ARQ unicast reception cache function is a function of receiving content from the UMC 105 using unicast communication and caching it in the content reception cache unit 205.
  • the content transmission unit 203 of the UMC 105 may have a function of transmitting content by unicast when a unicast request is received from the MUC 104.
  • MUC104 M-res. If the reception signal is not completed in the reception waiting state of 2, it is considered that the cause is packet loss, reception error of MUC104, or the like, and as a result, the signal is lost in MUC104. In this case, the MUC 104 is limited to unicast communication and req. This loss can be supplemented by reissuing 2. This is an automatic repeat request (ARQ) for each file. Compared to ARQ in packet units or block units, ARQ in file units is easier to implement because the HTTP request mechanism can be used.
  • ARQ automatic repeat request
  • this disclosure is a method that is possible because file-based multicasting is implemented based on HTTP.
  • the moving image file may be divided into files in which the playback time is divided into several seconds. In such a case, sufficient efficiency can be maintained even in the retransmission process for each file.
  • a division request may be made in the ARQ of multicast communication.
  • the content request unit 204 of the MUC 104 has a function of requesting a part of the content.
  • the content reception cache unit 205 includes a multicast / unicast mixed reception cache function that receives the content divided into unicast communication and multicast communication from the UMC 105, restores the original content, and then caches the content.
  • the content transmission unit 203 provided in the UMC 105 transmits the content by unicast when receiving a unicast request for a part of the content from the MUC 104.
  • the content request unit 204 is not limited to the file unit, but can also perform ARQ in packet units and block units in which the content is divided into a plurality of blocks.
  • the HTTP request req. It is not appropriate to use 2 from the viewpoint of overhead. Therefore, the content request unit 204 has req. It is preferable to use an ARQ message that is not 2.
  • the content request unit 204 may perform an ARQ using a NACK (non-arrival response confirmation) message. This method is superior in response speed and bandwidth efficiency to file-based ARQ.
  • NACK non-arrival response confirmation
  • the system of this embodiment may carry out ARQ in packet units and block units.
  • a sequence number is assigned to the packet to be ARQ or the block included in the content, and the sequence number is used to determine whether or not the packet is missing and re-request.
  • ARQ in file units and ARQ in packet units and block units can be used together.
  • the system of the present embodiment includes two or more UMC105s, all or part of the plurality of UMC105s operates as a regular system, and all or a part of the UMC105s of the regular system are used in the event of a failure or overload.
  • the function of the UMC105 of the system is replaced by another UMC105 of a regular system or an emergency system.
  • FIG. 5 shows a configuration when there are a plurality of UMC 105s.
  • the plurality of UMCs corresponding to the UMC 105 are 401, 402, and 403. Assuming that 401 and 402 are regular systems and 403 is an emergency system, if the UMC 401 fails or becomes overloaded, all or part of the functions of the UMC 401 can be taken over by the UMC 403.
  • UMC401 and UMC402 are load distribution systems, and for example, the connection destination from MUC104 to UMC401 and 402 can be changed for each content group.
  • the regular system can also be degenerated in the event of a failure.
  • the UMC 402 can take charge of the function of the UMC 401 and the function that the UMC 402 was in charge of before the failure of the UMC 401.
  • the UMC 402 can be in charge of both the processing function of some content groups that the UMC 401 is in charge of and the function that the UMC 402 was in charge of before the UMC 401 is overloaded.
  • Such a function not only makes it possible to improve the system operating rate, but also makes it possible to migrate the system without interrupting the service even when replacing or expanding the system.
  • the system of the present embodiment includes two or more MUC 104s, and when the MUC 104 that receives a request from the terminal 107 is overloaded, sends a signal redirecting to a different MUC 104 to the terminal 107, and the terminal 107 that receives the redirect is transmitted. Sends a request to MUC104 again based on the redirect.
  • FIG. 6 shows an example of the configuration when there are a plurality of MUC 104s.
  • FIG. 7 shows a sequence when there is no cache in MUC and UMC.
  • the plurality of MUCs corresponding to MUC104 are 501 and 502. If the MUC 501 is normally connected to a particular terminal 107 and the MUC 501 is overloaded, the MUC 501 will request the HTTP request req. Of the terminal 107. For 1, HTTP redirect redirect to MUC502. 1 can be transmitted.
  • the MUC 104 performs a permanent redirect if the MUC 501 is unable to respond for the time being or if equipment migration from the MUC 501 is required, otherwise it performs a temporary redirect.
  • a temporary redirect or a permanent redirect can be used by designating the terminal 107 not to cache the file. If the permanent redirect is used by specifying not to cache the previous file, it can be used as a temporary redirect.
  • the content request unit of MUC502 After redirecting from MUC501, if there is no cache in the content reception cache unit of MUC502, the content request unit of MUC502 sends a request to UMC105.
  • the response is stored in the content reception cache unit of the MUC 502 via the UMC 105.
  • terminal 107 receives the response.
  • the peak distribution of the MUC in which the load from the plurality of terminals 107 is likely to be concentrated becomes possible, and the capital investment in the MUC can be suppressed.
  • the MUC 104 that receives the request from the terminal 107 may be overloaded.
  • the system of the present embodiment distributes the load of the MUC 104 by redirecting to the UMC 105 instead of the MUC 104.
  • the unicast transmission unit 206 of the MUC 104 of the present embodiment transmits a message to redirect to the UMC 105 to the terminal 107 of the request transmission source in the case of an overload.
  • the terminal 107 sends a request to the UMC 105 based on the redirect message.
  • the unicast transmission unit 206 of the UMC 105 transmits the content to the terminal 107 by unicast.
  • FIG. 8 shows a sequence when there is no cache in MUC and UMC. If the MUC 104 is normally connected to a particular terminal 107 and the MUC 104 is overloaded, the MUC 104 will request the HTTP request req. Of the terminal 107. 1 to HTTP redirect redirect to UMC105. 1 is transmitted.
  • the UMC 105 Upon receiving the request from the terminal 107, the UMC 105 confirms whether or not the content is stored in the unicast reception cache unit 202. When the content is not stored in the unicast reception cache unit 202, the content is acquired by unicast from the content server 106 and stored in the unicast reception cache unit 202. Then, the content transmission unit 203 transmits the content to the terminal 107 by unicast.
  • the MUC 104 performs a permanent redirect if the MUC 104 cannot respond for the time being or if a facility migration from the MUC 104 is required, otherwise it performs a temporary redirect.
  • a temporary redirect or a permanent redirect can be used by designating the terminal 107 not to cache the file. If the permanent redirect is used by specifying not to cache the previous file, it can be used as a temporary redirect.
  • the unicast reception cache unit 201 of the UMC 105 sends a request to the content server 106, and the unicast reception cache unit 202 of the UMC 105 responds res from the content server 106. .. 1 is received and the content is stored. In this way, the content from the content server 106 goes through the UMC 105 and is res. At 3, the response is made to the terminal 107 using unicast communication. As a result, the peak distribution of the MUC 104 in which the load from the plurality of terminals 107 is likely to be concentrated becomes possible, and the capital investment in the MUC 104 can be suppressed.
  • this terminal 107 does not convert to multicast and is almost the same as the operation of a normal web proxy. Further, the load distribution between MUC 104 and the load distribution from MUC 104 to UMC 105 can be used together. It can be used properly depending on the proximity of the network distance from the terminal 107 and the congestion status of the network passing through.
  • the unicast reception cache unit 202 provided in the UMC 105 may divide and store the content.
  • the content transmission unit 203 provided in the UMC 105 has a function of transmitting to the MUC 104 by multicast or unicast in divided cache units.
  • the content reception cache unit 205 stores the content in divided cache units, and the unicast transmission unit 206 restores the content from the divided cache and unicasts the content to the terminal 107.
  • the file In HTTP, the file is the basic unit of transfer, and the content server 106 to UMC105 sends the HTTP response res. If the multicast communication is started after the file is completely acquired in 1, the delay increases. UMC105 is res. At the stage when the acquisition of the content is started in 1, the file of 1 is divided and cached, and M-res. By starting the multicast communication of 2, the delay can be concealed.
  • the unicast transmission unit 206 may start the unicast transmission to the terminal 107 when the content reception cache unit 205 completes receiving one or more of the divided caches.
  • a file is the basic unit of transfer. Therefore, after the MUC 104 completely acquires the file from the UMC 105, the HTTP response res. From the MUC 104 to the terminal 107.
  • the delay increases. Therefore, when the content reception cache unit 205 provided in the MUC 104 starts acquiring the content, one file is divided and cached in the content reception cache unit 205, and the unicast transmission unit 206 res. It is preferable to start 3. As a result, the present embodiment can hide the delay in the multicast communication network 102.
  • the content reception cache unit 205 provided in the MUC 104 and the unicast reception cache unit 202 provided in the UMC 105 may have a plurality of data storage areas for caching the contents.
  • the content reception cache unit 205 and the unicast reception cache unit 202 are cache files between the data storage areas according to the content usage frequency, access time, cache usage amount of the content group, and settings for the content or the content group. It may have a function to move.
  • the read / write speed of the cache affects the response speed and the load.
  • the cache on the memory has a limited size, it is desirable to have a larger cache in order to improve the delivery efficiency by the cache.
  • the primary cache on the memory and the secondary cache on the disk, the two requirements of speed and capacity can be satisfied.
  • the movement from the primary cache to the secondary cache can be performed according to the usage frequency of the content, the access time, the cache usage amount of the content group, and the setting for the content or the content group.
  • For cache movement according to the content usage frequency for example, a table of the number of times of use is held for each content, and cash out to the secondary cache is controlled according to the number of times of use.
  • the movement of the cache according to the access time is, for example, cached out to the secondary cache by a timer based on the last access time.
  • Moving the cache according to the cache usage of the content group limits the maximum cache amount in a specific single or multiple content groups, for example.
  • the cash out within the content group to which the same control policy is applied is controlled by the usage frequency, access time, and the like of the content. In addition, these settings can also be set for individual contents or content groups.
  • the unicast reception cache unit 202 provided in the UMC 105 receives the content from the content server 107 without depending on the request from the MUC 104.
  • the content is push-delivered from the content server 106 to the UMC 105.
  • the unicast reception cache unit 202 provided in the UMC 105 generates and stores a cache from the received content.
  • the content transmission unit 203 provided in the UMC 105 transmits the content for each content group by using multicast communication or unicast communication.
  • the system up to the above is the HTTP request req. From the terminal 107. Since 1 is the cause and the request and the response are relayed, the delivery delay may be accumulated. In a web video distribution system, it is common to prepare a file having a plurality of levels of image quality as an adaptive bit rate (ABR) and select a file having an image quality to be actively downloaded by the player of the terminal 107. If the delivery delay accumulates, the bandwidth of the network is sufficient, and there is a possibility that the delay will switch to low-quality video.
  • ABR adaptive bit rate
  • the content file is transmitted from the content server 106 to the UMC 105 by push, and is also transmitted from the UMC 105 to the MUC 104 by push multicast or unicast, so that the content file is cached in the MUC 104 before the request from the terminal 107 is made. Can also be created. As a result, the content can be transmitted to the terminal 107 with the shortest response time, and stable delivery with high image quality can be realized.
  • the content request unit 204 provided in the MUC 104 or the unicast request unit 201 provided in the UMC 105 may have a function of requesting the content of the content group.
  • the push from the content server 106 described above requires expansion of the functions of a normal web server. Therefore, the MUC 104 or the UMC 105 may independently request the known contents regardless of the request from the terminal 107.
  • the HTTP request req. 2 may be generated.
  • FIG. 9 shows a case where there is no cache at the start of the sequence.
  • HTTP request req. Upon receiving 2, the UMC 105 received the HTTP request req. From the MUC 104 in step S2. Judging that there is no cache corresponding to 2, the HTTP request req. To the content server 106. Transfer 3
  • the content server 106 is a req.
  • the content file corresponding to 3 is described in the HTTP response res. 1 to respond to UMC105. res.
  • the UMC 105 that received 1 executes step S3.
  • the UMC105 is res.
  • a cache file is generated using the content file included in 1, and the cache file is responsive to MUC104.
  • the response from the UMC 105 to the MUC 104 is the HTTP request req. It is a response corresponding to 2, and is an HTTP response res. 2.
  • Response by multicast M-res. 2, or res. Both 2 and M-res2 can be adopted.
  • step S4 the MUC 104 receives the HTTP request req. From the terminal 107. Judging that there is a cache corresponding to 1, the cache file stored is set to the HTTP response res. Reply 3 res. 3 is the HTTP request req. It is a response to the terminal 107 corresponding to 1.
  • the caches of MUC104 and UMC105 are deleted at an appropriate timing from the limitation of the storage capacity of the disk or the like or the distribution policy.
  • res. 1 is not necessarily res. It does not have to occur after cache creation by 2 or M-res2. req. After 2 res. This is because the time until cache generation can be shortened by generating 1.
  • step S2 the HTTP request req. 3 may be generated.
  • FIG. 10 shows a case where there is no cache at the start of the sequence.
  • HTTP request req The content server 106 that received 3 is req.
  • the content file corresponding to 3 is described in the HTTP response res.
  • UMC105 responds to res.
  • a cache file is generated using the content file included in 1.
  • step S1 the MUC 104 receives the HTTP request req. From the terminal 107. Judging that there is no cache corresponding to 1, HTTP request req. To UMC105, which is a higher-level proxy server. Transfer 2.
  • the UMC 105 executes step S3.
  • the UMC 105 receives the HTTP request req. From the MUC 104. It is determined that there is a cache corresponding to 2, and the cache file is returned to UMC104.
  • the response from the UMC 105 to the MUC 104 is the HTTP request req. It is a response corresponding to 2, and is an HTTP response res. 2.
  • Response by multicast M-res. 2, or res. Both 2 and M-res2 can be adopted.
  • the MUC 104 that has received 2 or M-res2 executes step S4.
  • the MUC 104 is res. 2 or M-res. Stores the cache file included in 2.
  • the MUC104 sets the cache file stored in the HTTP response res.
  • Reply 3 res. 3 is the HTTP request req. It is a response to the terminal 107 corresponding to 1.
  • the caches of MUC104 and UMC105 are deleted at an appropriate timing from the limitation of the storage capacity of the disk or the like or the distribution policy.
  • res. 1 is not necessarily res. It does not have to occur after the cache is created by 3. req. After 3 res. This is because the time until cache generation can be shortened by generating 1.
  • the content can be transmitted to the terminal 107 with the shortest response time without any special extension to the content server 106, and stable delivery with high image quality can be realized.
  • the content request unit 204 provided in the MUC 104 or the unicast request unit 201 provided in the UMC 105 identifies the content generation time in the content server 106. It may be characterized in that it is set, predicted, and synchronized with the content generation time.
  • the content request unit 204 or the unicast request unit 201 analyzes the manifest file to obtain the latest content described in the manifest file or the content predicted to be generated in the short-term future from the rules described in the manifest file. You may generate a request for it.
  • the content can be transmitted to the terminal 107 with the shortest response time without any special extension to the content server, and high-quality and stable distribution can be realized.
  • the content request unit 204 or the unicast request unit 201 may have a function of requesting the content before or after the content requested by the terminal 107.
  • the operator of the terminal 107 may operate the playback bar on the terminal 107 to play the content discontinuously before or after the time in order of the start of the playback. is there.
  • the MUC 104 or UMC 105 may request a file at a time close to the playback time or a file with a statistically high playback frequency in order to realize high-quality and stable distribution.
  • the address management and distribution source may be implemented by UMC105 or other management server. Further, the distribution destinations of the addresses are the content transmission unit 203 in the UMC 105 and the content reception cache unit 205 in the MUC 104.
  • 11 and 12 show the table layout when the UMC 105 has a table of free multicast communication identifiers such as multicast group address, source address, and port number.
  • 801 is a free multicast communication identifier table
  • 802 is a table that stores the multicast communication identifier during multicast communication by the content transmission unit 203
  • 803 is a table that stores the multicast identifier during multicast reception by the content reception cache unit 205. is there.
  • the content transmission unit 203 refers to the table 802 when starting the transmission of the multicast communication, and if there is no multicast identifier corresponding to the corresponding content group, the content transmission unit 203 acquires the multicast identifier from the table 801 and registers it in the table 802.
  • the content reception cache unit 205 starts receiving multicast communication, it refers to Table 803, and if there is no multicast identifier corresponding to the corresponding content group, it acquires the multicast identifier from Table 801 and registers it in Table 803. To do.
  • table 801 After issuing the multicast identifier, writes the usage flag by the assigned content group to the table.
  • FIG. 13 shows a table image held by the table 801. Here, it is shown that the multicast identifier IDM2 is issued to the content group IDG1 and the multicast identifier IDM3 is issued to the content group IDG2, both of which are used by the MUC104, and that the other multicast identifiers are unused. ing.
  • table 803 is a subset of table 802, the multicast identifier may be obtained from table 802 instead of being obtained from table 801.
  • the used MUC in the table 801 may be managed in the table 802.
  • FIG. 13 is schematically shown, and it may be implemented in another form such as a data structure by a list or using a hash to save memory and facilitate table search.
  • FIG. 14 shows an example of the table 802 and the table 803.
  • the multicast identifier IDM2 is used for the content group IDG1
  • the multicast identifier IDM3 is used for the content group IDG2
  • the other parts of the table are shown as empty.
  • the table shown in FIG. 14 is schematically shown, and it may be implemented in another form such as a data structure by a list or using a hash to save memory and facilitate table search.
  • the table 802 is a subset of the table 801 and may be managed by a single table when implemented in the same functional unit.
  • the corresponding content group and the multicast identifier are deleted from the table 803, and the used MUC in the table 801 or the table 802 is deleted. You may delete your own MUC from.
  • the used MUC becomes empty, it is determined that there is no MUC that performs multicast reception. Therefore, the corresponding content group in the used content group column of table 801 and the row of the corresponding content group in table 802 are deleted. By this operation, the multicast identifier can be reused.
  • a configuration may be adopted in which the same IP address is assigned to a plurality of MUC 104s and a request can be transmitted from the terminal 107 to the nearest MUC 104 without distinguishing the plurality of MUC 104s.
  • the request reception interface of the MUC 104 from the terminal 107 may be guided to access the nearest MUC of the terminal 107 by using the routing by IP anycast. This makes it possible to facilitate the management as compared with the management by other methods such as DNS. Further, the attack on the request reception interface of the MUC 104 will be decentralized, and it will be possible to make the attack robust.
  • the content location described in the manifest file may be changed from the content server 106 to the MUC 104, and a request may be made from the terminal 107 to the MUC 104.
  • the actual file name of the video data called the manifest and the file indicating the location of the file are read.
  • the HTTP request req. From the terminal 107. 1 can be changed to MUC104.
  • the manifest file itself is also sent to the terminal 107 by the HTTP request and response, it depends on the terminal 107 that can be obtained from the HTTP request such as the terminal IP address by the content server 106, the header information of the HTTP request, and the query string information of the HTTP request. With the information that can be added from the terminal 107, it becomes easy to individually transmit the manifest file suitable for the viewing environment of the terminal 107 to the terminal 107 and separate them.
  • this embodiment enables more flexible distribution control as compared with the distribution by DNS, and can be closed to the web system to complete the control and facilitate the construction of the system. Further, the change of the request destination by rewriting the manifest file may be combined with another method of changing the request destination.
  • the manifest file may be rewritten by the content server 106 in which the manifest file before rewriting is stored, but another server for rewriting may be used.
  • the content server 106 can realize the request from the terminal 107 to the MUC 104 without directly knowing the position of the MUC 104. This is effective when the management entity of the content server 106 and the MUC 104 are different, and can be realized by the management entity of the MUC 104 managing the manifest file rewriting server.
  • the content server 106 may redirect the request from the terminal 107 to the content server 106 to the MUC 104 to make a request from the terminal 107 to the MUC 104.
  • the corresponding content server 106 determines whether it depends on the terminal 107 that can be obtained from the HTTP request such as the terminal IP address, the header information of the HTTP request, the query string information of the HTTP request, or the information that can be added from the terminal 107. Can HTTP redirect to access MUC104.
  • the temporary redirect or the permanent redirect can be used by designating the terminal 107 not to cache the file. If the permanent redirect is used by specifying not to cache the previous file, it can be used as a temporary redirect. As a result, access to the MUC 104 from the terminal 107 can be realized without rewriting the content itself and while aggregating the primary requests of the terminal 107 on the content server 106. Further, the change of the request destination by this redirect may be combined with another method of changing the request destination.
  • the system shown in FIG. 1 further includes a transfer unit (not shown) for transferring a request for content or a content group.
  • the content server 106 redirects the request from the terminal 107 to the content server 106 to the transfer unit, and the transfer unit redirects the request from the terminal 107 to the transfer unit to the MUC 104.
  • the present embodiment makes a request to the MUC 104 from the terminal 107.
  • the content server 106 performs a primary redirect to another server serving as a transfer unit, and the transfer unit further redirects to the MUC 104.
  • the corresponding content server 106 determines whether it depends on the terminal 107 that can be obtained from the HTTP request such as the terminal IP address, the header information of the HTTP request, the query string information of the HTTP request, or the information that can be added from the terminal 107. Relies on the terminal 107 that can be obtained from the HTTP request such as the terminal IP address, the header information of the HTTP request, the query string information of the HTTP request, and the terminal 107 in the transfer unit. The determination can be made based on the information that can be added from, and the terminal 107 can make an HTTP redirect to access the MUC 104.
  • the content server 106 can realize the request from the terminal 107 to the MUC 104 without directly knowing the position of the MUC 104. This is effective when the management subject of the content server 106 and the MUC 104 are different, and can be realized by the management subject of the MUC 104 managing the server for the transfer unit.
  • This redirect message includes a permanent redirect and a temporary redirect, but in the present embodiment, the temporary redirect or the permanent redirect can be used by designating the terminal 107 not to cache the file. If the permanent redirect is used by specifying not to cache the previous file, it can be used as a temporary redirect.
  • the device of the present disclosure can also be realized by a computer and a program, and the program can be recorded on a recording medium or provided through a network.
  • This disclosure can be applied to the information and communication industry.

Abstract

本開示は、ＨＴＴＰをベースとしたウェブ配信システムにおいて、ユニキャストであるＨＴＴＰを維持しながら、効率的にコンテンツを転送可能にすることを目的とする。　本開示は、ウェブ配信を行うコンテンツサーバ１０６と端末１０７との間のネットワークにマルチキャスト通信ネットワーク１０２を用いて接続されているユニキャストマルチキャスト変換装置１０５及びマルチキャストユニキャスト変換装置１０４を設け、ユニキャストマルチキャスト変換装置１０５及びマルチキャストユニキャスト変換装置１０４が、複数のコンテンツがグルーピングされているコンテンツグループの転送を、マルチキャストとユニキャストの両方で実行する。

Description

コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム
　本開示は、宛先が異なり、かつ、コンテンツ識別子が同一である複数のユニキャストトラヒックの、ユニキャストからマルチキャストへ、および、マルチキャストからユニキャストへの変換方法に関する。
インターネットのトラヒック量は、年々増加傾向にあり、特に映像トラヒックの増加が著しい。インターネットにおけるトラヒック量の増加は、通信事業者のネットワークを経由するトラヒックの増加を意味する。これに対し、コンテンツ配信事業者および通信事業者は、輻輳などが生じないよう、設備投資を行わなければならない。
　設備投資を抑制するために、ネットワークにおける伝送帯域を効率良く利用する事が挙げられる。
　具体的な方法として、マルチキャストがある（非特許文献１）。マルチキャストは、同一のコンテンツを多数のエンドユーザに配信する場合に有効で、各エンドユーザ宛てにユニキャストで配信する場合と比較して消費する伝送帯域が少ない。受信するエンドユーザが多いほどその効果は高まるため、多数のエンドユーザによる受信が見込まれるコンテンツに向いている。
　この他、監視カメラネットワークにおいて、監視カメラからユニキャストで送信された監視画像を、マルチキャストに変換し、監視拠点に送信する技術も存在する（特許文献１）。
　また、マルチキャストで送信されたコンテンツを、ユニキャストに変換する技術も存在する。例えば、特許文献２では、ＤＳＬ（Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ）によるアクセス回線を経由したトラヒックを宅内において無線ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）にて送信する際に、マルチキャストからユニキャストに変換を行っている。これにより、無線ＬＡＮ区間において、より確実なトラヒック送信を実現している。
特許第４６６５００７号，”監視映像送信装置および方法” 特許第４８１４９９８号，”マルチキャスト・データを信頼できる形で送達するための方法および装置”
　コンテンツ配信サービスは、配信設備、ネットワーク、受信者端末があって初めて成立するものである。よって、これら装置および設備には、相互に接続性が確保されていなければならない。前記したマルチキャストには、この接続性に関する課題がある。
　コンテンツ配信サービスにおいては、配信設備とネットワークとの接続インターフェース（以下、ＳＮＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｅｒｖｅｒ－Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ））、および、ネットワークと受信者端末との接続インターフェース（以下、ＵＮＩ（Ｕｓｅｒ－Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ））において、入出力するトラヒックの条件を整合させる必要がある。これをＩＦ（Ｉｎｔｅｒｆａｃｅ）条件と呼ぶ事がある。入出力するトラヒックをユニキャストとするか、マルチキャストとするかもＩＦ条件に含まれ、サービス提供にあたっては、これを決定する必要がある。
　ここで、トラヒックとは、コンテンツに、そのコンテンツを配信するための各種情報が付加されたものとする。例えば、コンテンツをＩＰパケットに格納して送信する場合は、ＩＰヘッダと、コンテンツが格納されたペイロードを合わせたものをトラヒックと呼ぶ事とする。
　次に、ＳＮＩとＵＮＩのいずれか、あるいは両方のＩＦ条件をマルチキャストとした場合の課題を示す。配信事業者ＡおよびＢからのトラヒックはマルチキャストで送出されているため、トラヒックの消費帯域は配信チャネル数×受信者端末１台分で済み、伝送帯域の削減は実現できている。しかし、このような場合は、配信設備、受信者端末の両方が、マルチキャストに対応した機能を具備する必要が生じる。つまり、マルチキャスト配信が可能な配信設備や、マルチキャストを受信可能な受信者端末が必要となり、そうでない設備、端末は接続する事ができない。
　マルチキャスト配信や受信に対応した装置自体は市中に存在するものの、インターネットトラヒックは、一般的にはユニキャストであるため、マルチキャスト配信や受信に対応させるとなると、そのネットワーク向けに特別な設定が必要となり、運用が煩雑になる。この問題を解決するためには、ＳＮＩとＵＮＩの両方をユニキャストとする事が考えられる。しかし、ネットワーク部分は、前記した伝送帯域の効率的利用の観点から、マルチキャストである事が望ましい。これらは相反する条件であるため、両立させるための技術が必要である。
　そのような技術の一例として、ＳＮＩへユニキャストで入力したコンテンツは、ネットワークではマルチキャストに変換後、多地点に配信したのち、各拠点では再びユニキャストに変換してＵＮＩから出力する事が考えられる。しかし、ユニキャストを前提とする映像配信はＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）や、上位レイヤとしてはＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）を用いることが多い。一方で、マルチキャストはＵＤＰ（Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ）や、上位レイヤとしてはＲＴＰ（Ｒｅａｌ－ｔｉｍｅ　Ｔｒａｎｓｐｏｒｔ　Ｐｒｏｔｏｃｏｌ）などが使われるため、単純なＩＰヘッダの変換では不十分である。
　このような動作は、前記と同様に、市中のユニキャストからマルチキャスト、および、マルチキャストからユニキャストへの変換技術を単に組み合わせるだけでは実現できない。
　そこで本開示では、ＨＴＴＰをベースとしたウェブ配信システムにおいて、ユニキャストであるＨＴＴＰを維持しながら、効率的にコンテンツを転送可能にすることを目的とする。
　本開示は上記の課題を解決するためになされたものであり、ウェブ配信を行うコンテンツサーバと、受信する端末間のネットワークに、ユニキャストマルチキャスト変換装置すなわちユニキャスト・マルチキャスト変換部（以下、ＵＭＣと称する。）と、マルチキャストユニキャスト変換装置すなわちマルチキャスト・ユニキャスト変換部（以下、ＭＵＣと称する。）を設け、そのＵＭＣとＭＵＣ間のトラヒックにおいてマルチキャスト通信を利用可能にする。これにより、サーバ設備、ネットワーク設備の投資軽減を促進し、および配信映像画質の高画質化、安定化を実現する。
　具体的には、本開示に係るコンテンツ配信システムは、
　ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間がマルチキャスト通信ネットワークを用いて接続されているコンテンツ配信システムであって、
　ユニキャスト通信からマルチキャスト通信へ変換し、前記マルチキャスト通信ネットワークへ送出するユニキャストマルチキャスト変換装置と、前記マルチキャスト通信ネットワークで伝送されたマルチキャスト通信をユニキャスト通信へ変換するマルチキャストユニキャスト変換装置と、を備え、
　前記マルチキャストユニキャスト変換装置は、
　複数のコンテンツがグルーピングされているコンテンツグループを識別し、前記コンテンツグループ毎にユニキャスト通信およびマルチキャスト通信のいずれか一方又は双方の通信方式を用いて送信されたコンテンツを前記マルチキャスト通信ネットワークから受信し、前記コンテンツグループに含まれるコンテンツを格納するコンテンツ受信キャッシュ部と、
　前記端末からのリクエストに基づき、前記コンテンツ受信キャッシュ部に格納されているコンテンツを前記端末に送信するユニキャスト送信部と、
　前記端末からのリクエストに対応するコンテンツが前記コンテンツ受信キャッシュ部に格納されていない場合、前記端末からのリクエストに対応するコンテンツを含むコンテンツグループの要求を、ユニキャスト通信及びマルチキャスト通信のいずれか一方又は双方の通信方式で選択的に行うコンテンツリクエスト部と、
　を備え、
　前記ユニキャストマルチキャスト変換装置は、
　前記コンテンツサーバからユニキャスト通信を用いてコンテンツを受信し、格納するユニキャスト受信キャッシュ部と、
　前記コンテンツリクエスト部からのリクエストに対応するコンテンツグループを前記ユニキャスト受信キャッシュ部から読み出し、読み出したコンテンツグループを、ユニキャスト通信およびマルチキャスト通信のいずれか一方又は双方の通信方式を用いて、前記マルチキャスト通信ネットワークに送信するコンテンツ送信部と、
　前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループが前記ユニキャスト受信キャッシュ部に格納されていない場合、前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループの要求を、ユニキャスト通信を用いて前記コンテンツサーバに対して行うユニキャストリクエスト部と、
　を備える。
　具体的には、本開示に係るユニキャストマルチキャスト変換装置は、
　ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間に接続され、ユニキャスト通信からマルチキャスト通信へ変換し、マルチキャスト通信ネットワークへ送出するユニキャストマルチキャスト変換装置であって、
　前記コンテンツサーバからユニキャスト通信を用いてコンテンツを受信し、格納するユニキャスト受信キャッシュ部と、
　前記マルチキャスト通信ネットワークで伝送されたマルチキャスト通信をユニキャスト通信へ変換するマルチキャストユニキャスト変換装置から、複数のコンテンツがグルーピングされているコンテンツグループのリクエストを受信すると、当該リクエストに対応するコンテンツグループを前記ユニキャスト受信キャッシュ部から読み出し、読み出したコンテンツグループを、ユニキャスト通信およびマルチキャスト通信のいずれか一方又は双方の通信方式を用いて、前記マルチキャスト通信ネットワークに送信するコンテンツ送信部と、
　前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループが前記ユニキャスト受信キャッシュ部に格納されていない場合、前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループの要求を、ユニキャスト通信を用いて前記コンテンツサーバに対して行うユニキャストリクエスト部と、
　を備える。
　具体的には、本開示に係るコンテンツ配信方法は、
　ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間に接続され、ユニキャスト通信からマルチキャスト通信へ変換し、マルチキャスト通信ネットワークへ送出するユニキャストマルチキャスト変換装置が実行するコンテンツ配信方法であって、
　前記コンテンツサーバからユニキャスト通信を用いてコンテンツを受信し、当該コンテンツをユニキャスト受信キャッシュ部に格納し、
　コンテンツ送信部が、前記マルチキャスト通信ネットワークで伝送されたマルチキャスト通信をユニキャスト通信へ変換するマルチキャストユニキャスト変換装置から、複数のコンテンツがグルーピングされているコンテンツグループのリクエストを受信すると、当該リクエストに対応するコンテンツグループを前記ユニキャスト受信キャッシュ部から読み出し、読み出したコンテンツグループを、ユニキャスト通信およびマルチキャスト通信のいずれか一方又は双方の通信方式を用いて、前記マルチキャスト通信ネットワークに送信し、
　ユニキャストリクエスト部が、前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループが前記ユニキャスト受信キャッシュ部に格納されていない場合、前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループの要求を、ユニキャスト通信を用いて前記コンテンツサーバに対して行う。
　具体的には、本開示に係るコンテンツ配信プログラムは、本開示に係るユニキャストマルチキャスト変換装置又はマルチキャストユニキャスト変換装置に備わる各機能部としてコンピュータを実現させるためのプログラムであり、本開示に係るコンテンツ配信方法に備わる各ステップをコンピュータに実行させるためのプログラムである。
　本開示によれば、ＨＴＴＰをベースとしたウェブ配信システムにおいて、ユニキャストであるＨＴＴＰを維持しながら、効率的にコンテンツを転送可能にすることができる。
第１の実施形態に係るシステム構成の一例を示す。 ＭＵＣ及びＵＭＣにキャッシュがない場合の第１の実施形態のシーケンスを示す。 ＭＵＣの機能の一例を示す。 ＵＭＣの機能の一例を示す。 第９の実施形態に係るシステムの概略構成図である。 第１０の実施形態に係るシステムの概略構成図である。 ＭＵＣおよびＵＭＣにキャッシュがない場合の第１０の実施形態のシーケンスを示す。 ＭＵＣおよびＵＭＣにキャッシュがない場合の第１１の実施形態のシーケンスを示す。 第１４の実施形態のシーケンスの第１例を示す。 第１４の実施形態のシーケンスの第２例を示す。 第１５の実施形態のＵＭＣの概略構成を示す。 第１５の実施形態のＭＵＣの概略構成を示す。 テーブル８０１が保持するテーブルイメージの一例を示す。 テーブル８０２とテーブル８０３が保持するテーブルイメージの一例を示す。
　以下、本開示の実施形態について、図面を参照しながら詳細に説明する。なお、本開示は、以下に示す実施形態に限定されるものではない。これらの実施の例は例示に過ぎず、本開示は当業者の知識に基づいて種々の変更、改良を施した形態で実施することができる。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。
　また、本説明において、本開示に係るコンテンツ配信方法によって配信されるコンテンツは映像コンテンツであるものと仮定するが、本開示においては、他のコンテンツ（例えば、画像、Ｗｅｂページ、ＯＳ（Ｏｐｅｒａｔｉｏｎ　Ｓｙｓｔｅｍ）のアップデートファイル、ウイルス対策ソフトの定義ファイル等）も配信可能である。
（第１の実施形態）
　図１に、本開示に係るコンテンツ配信方法を備えたネットワーク構成の一例を示す。本開示に係る配信システムは、コンテンツサーバ１０６とＵＭＣ１０５とＭＵＣ１０４と端末１０７を備える。また、コンテンツサーバ１０６と端末１０７の間には、マルチキャスト通信が可能なネットワークであるマルチキャスト通信ネットワーク１０２が存在している。図においては、ネットワーク１０１とネットワーク１０３とは別となっているが、単一のネットワークであってもかまわない。
　また、ＵＭＣ１０５はネットワーク１０３とネットワーク１０２の境界もしくはネットワーク１０２に置かれ、ＭＵＣ１０４はネットワーク１０２とネットワーク１０１の境界もしくはネットワーク１０２に置かれる。
　ＵＭＣ１０５とＭＵＣ１０４がない場合は、コンテンツサーバ１０６及び端末１０７間は、ユニキャストのＨＴＴＰを用いて通信を行っている。本配信システムでは、ＵＭＣ１０５とＭＵＣ１０４が間に入ることによって、ＵＭＣ１０５では、主に通信をユニキャストからマルチキャストへ、ＭＵＣ１０４では主にマルチキャストからユニキャストへその通信を変換する。これにより、本開示は、ウェブ配信というコンテンツサーバ１０６と端末１０７間の接続方法を変更する必要がなくなる。また、ＭＵＣ１０４は１台以上であり、それぞれ０台以上の端末１０７と接続される。
　ここで、ＭＵＣ１０４は、主にマルチキャストからユニキャストへその通信を変換するが、変換前の通信はユニキャスト通信を含む場合やユニキャスト通信のみになることがある。また、ＵＭＣ１０５は、主に、ユニキャストからマルチキャストへその通信を変換するが、変換後の通信はユニキャスト通信を含む場合やユニキャスト通信のみになることもある。ＭＵＣ１０４及びＵＭＣ１０５がユニキャスト通信のみを行う場合は、本開示のシステムは多段のｗｅｂプロキシシステムとほぼ等価である。本開示は、アプリケーション層であるｗｅｂプロキシシステム（本開示にけるＵＭＣ１０５とＭＵＣ１０４）において、その通信の一部（ＵＭＣ１０５とＭＵＣ１０４間）を適応的にマルチキャスト化するシステムである。
　図２に、ＭＵＣ１０４及びＵＭＣ１０５にキャッシュがない場合の通信の流れを示す。
　端末１０７からのＨＴＴＰリクエストｒｅｑ．１はプロキシであるＭＵＣ１０４に送信される。
　ｒｅｑ．１を受信したＭＵＣ１０４は、ステップＳ１を実行する。ステップＳ１において、ＭＵＣ１０４は、端末１０７からのＨＴＴＰリクエストｒｅｑ．１に対応するキャッシュがないと判断し、上位のプロキシサーバであるＵＭＣ１０５へＨＴＴＰリクエストｒｅｑ．２を転送する。同様に、ＵＭＣ１０５は、ステップＳ２において、ＭＵＣ１０４からのＨＴＴＰリクエストｒｅｑ．２に対応するキャッシュがないと判断し、コンテンツサーバ１０６へＨＴＴＰリクエストｒｅｑ．３を転送する。
　コンテンツサーバ１０６は、ｒｅｑ．３に対応するコンテンツファイルを、ＨＴＴＰレスポンスｒｅｓ．１でＵＭＣ１０５へ応答する。ｒｅｓ．１を受信したＵＭＣ１０５は、ステップＳ３を実行する。ステップＳ３において、ＵＭＣ１０５は、ｒｅｓ．１に含まれるコンテンツファイルを用いてキャッシュファイルを生成し、キャッシュファイルをＵＭＣ１０４へ応答する。ここで、ＵＭＣ１０５からＭＵＣ１０４への応答は、ＨＴＴＰリクエストｒｅｑ．２に対応する応答であり、ＨＴＴＰレスポンスｒｅｓ．２、又はマルチキャストによるレスポンスＭ－ｒｅｓ．２、又はｒｅｓ．２及びＭ－ｒｅｓ２の両方、のいずれも採用することができる。
　ｒｅｓ．２又はＭ－ｒｅｓ２を受信したＭＵＣ１０４は、ステップＳ４を実行する。ステップＳ４では、ＭＵＣ１０４は、ｒｅｓ．２又はＭ－ｒｅｓ．２に含まれるキャッシュファイルを格納する。ＭＵＣ１０４は、格納しているキャッシュファイルをＨＴＴＰレスポンスｒｅｓ．３を応答する。ｒｅｓ．３は、ＨＴＴＰリクエストｒｅｑ．１に対応する端末１０７への応答である。なお、ＭＵＣ１０４とＵＭＣ１０５のキャッシュはディスク等の記憶容量の制限、もしくは、配信ポリシから、適切なタイミングで消去される。
　以上のように、本開示は、ユニキャスト通信であるＲｅｓ．２と、マルチキャスト通信であるＭ－ｒｅｓ．２のメッセージを併用することにより、次の効果が期待できる。
　・マルチキャスト通信により、不必要なユニキャスト通信を削減することで、ネットワークの利用帯域およびサーバへの負荷が低減される。これによりユニキャスト通信のみを利用した場合に比べ、より安定的に、より高画質な映像を配信可能とする。
　・マルチキャスト通信が疎通できない環境では、従来のユニキャスト通信による疎通性を確保することができる。疎通できない環境とは、マルチキャスト通信をサポートしていない環境のほか、マルチキャストアドレスやマルチキャストルート数の枯渇や、マルチキャスト用のトラヒック量の超過などの一時的な非疎通環境も考えられる。さらには、動的にマルチキャストルートを生成するネットワークの場合は、そのルートが生成される以前に先んじてユニキャスト通信で配信することで、動画再生開始までの時間の短縮を可能とする。
　・また、ユニキャスト通信をマルチキャスト通信データの再送用としての利用することで、信頼性を向上させることができる。特に、伝送路中のパケットロスや、受信機（ＭＵＣ１０４）の受信ミス等により、マルチキャストパケットを再送することは、ロスをしたＭＵＣ１０４だけでなく、他のＭＵＣ１０４にもマルチキャストパケットを伝送することになりネットワーク帯域や、他のＭＵＣ１０４負荷軽減ため、再送については、個別のＭＵＣ１０４に対して実施するこが望ましいからである。
　・同様に、ｗｅｂベースでは同一のファイルに対して、同一のタイミングで複数の端末１０７からファイルへのリクエストが発生するとは限らない。そのため、特定のＭＵＣ１０４においてキャッシュが消去された後に端末１０７からのリクエストがあった場合は、マルチキャスト通信ではなく、ユニキャスト通信での配信が望ましい。これは、該当ＭＵＣ１０４とは別のＭＵＣ１０４がキャッシュファイルを保持している場合には、その配信が無駄になるからである。
　また、本システムは、リアルタイム性のあるコンテンツの配信だけでなく、キャッシュによって、リアルタイム性の低いコンテンツの配信にも対応が可能となる。
　図３に、図２における各ステップを実行するためのＭＵＣ１０４の機能の一例を示す。ＭＵＣ１０４は、コンテンツリクエスト部２０４と、コンテンツ受信キャッシュ部２０５と、ユニキャスト送信部２０６と、を持つ。
　ユニキャスト送信部２０６は、端末１０７からのリクエストｒｅｑ．１に基づきコンテンツ受信キャッシュ部２０５からｒｅｑ．１に対応するコンテンツファイルを読み出し、ユニキャスト通信で当該コンテンツファイルをｒｅｓ．３で端末１０７に送信する。このキャッシュは、ＨＴＴＰにおけるファイルまたはストリームである。また、キャッシュは完全なファイルでなくてもよく、一部のデータのみでも順次、ユニキャスト通信として送信することができる。これにより、端末１０７からはコンテンツサーバ１０６に直接ＨＴＴＰリクエストを送信および、ＨＴＴＰレスポンスを受信する処理と同様の処理で、ＭＵＣ１０４のユニキャスト送信部２０６と通信が可能となる。
　コンテンツリクエスト部２０４は、端末１０７からのリクエストに対応するキャッシュが無い場合、ＵＭＣ１０５へコンテンツをｒｅｑ．２で要求する。要求は、ユニキャスト通信又はマルチキャスト通信の両方の通信又は片方の通信方式で選択的に行う。例えば、この要求は、ＨＴＴＰリクエストを利用し、選択的要求はＨＴＴＰヘッダを用いて区別する。
　コンテンツ受信キャッシュ部２０５は、コンテンツリクエスト部２０４からリスエストしたコンテンツを、複数のコンテンツでグルーピングしたコンテンツグループに識別し、前記コンテンツグループ毎にユニキャスト通信またはマルチキャスト通信の両方の通信もしくは片方の通信方式で選択的にコンテンツ受信しキャッシュする。ここでのコンテンツは例えば、ファイルである。ウェブ配信システムでは、複数のファイルで１の番組を成すことがあるため、マルチキャスト等のストリームに変換する際に、複数のファイルを１のコンテンツグループとして扱うことで、効率的にマルチキャスト通信に変換が可能である。つまり、１の番組の異なるファイルの転送に際して、同一のマルチキャストのソースアドレス、グループアドレスでその転送を実施できるという利点がある。
　ここで、コンテンツ受信キャッシュ部２０５において、ユニキャスト通信またはマルチキャスト通信の両方の通信もしくは片方の通信方式で選択的に受信するとは、例えば、マルチキャストパスが確立される前もしくは、何らかの理由でマルチキャストが転送できないネットワークにおいてはユニキャスト通信を行い、マルチキャストパスが確立後にはマルチキャスト通信を行うことをなどが考えられる。
　また、何らかの理由でマルチキャスト通信が受信できなかった場合などに、その受信ができなかったＭＵＣ１０４のみにデータを転送する場合である。マルチキャスト通信が受信できなかった場合としては、パケットロス等の受信エラーの他、マルチキャスト受信後にＭＵＣ１０４においてキャッシュアウトして再取得が必要になった場合や、ＵＭＣ１０５からはマルチキャスト配信されていたものの、ＭＵＣ１０４の受信準備ができておらず、データが取得できていない場合などがある。
　このようにマルチキャスト通信とユニキャスト通信を組み合わせることで、同報性、即時性の高いコンテンツはマルチキャスト通信を用い、エラー回復もしくは同報性が低いか、即時性の低いコンテンツはユニキャスト通信を用いることで、ネットワーク設備、帯域を効率的に利用することが可能となる。
　図４に、図２における各ステップを実行するためのＵＭＣ１０５の機能を示す。ＵＭＣ１０５は、ユニキャストリクエスト部２０１と、ユニキャスト受信キャッシュ部２０２と、コンテンツ送信部２０３を持つ。
　コンテンツ送信部２０３は、ＭＵＣ１０４からのリクエストに基づきキャッシュからコンテンツを読み出し、ＭＵＣ１０４へコンテンツを送信する。この際、ＭＵＣ１０４は、コンテンツグループ毎に、ユニキャスト通信またはマルチキャスト通信の両方の通信もしくは片方の通信方式で選択的に送信する。このように、ユニキャスト通信またはマルチキャスト通信の両方の通信もしくは片方もしくは選択的に受信するために、ＵＭＣ１０５とＭＵＣ１０４は連携を行う。
　例えば、ＭＵＣ１０４に備わるコンテンツ受信キャッシュ部２０５は、目的のマルチキャスト信号が受信可能か、ＵＭＣ１０５に通知する機構を持つ。これによりＵＭＣ１０５のコンテンツ送信部２０３は、ユニキャスト通信をマルチキャスト通信に切り替えることができる。
　例えば、ＭＵＣ１０４に備わるコンテンツ受信キャッシュ部２０５は、マルチキャストパスが確立される前に、マルチキャスト信号とユニキャスト信号の両方を受信する。マルチキャストパスが確立する前の場合、コンテンツ受信キャッシュ部２０５は、ユニキャスト信号によりキャッシュを生成する。コンテンツ受信キャッシュ部２０５がマルチキャスト信号を受信できたことで、コンテンツ受信キャッシュ部２０５は、マルチキャスト信号が受信可能であると判定することができる。
　例えば、マルチキャスト信号のみをＵＭＣ１０５が送信し、ＭＵＣ１０４が受信し、ＭＵＣ１０４が受信を一部失敗した場合には、コンテンツ受信キャッシュ部２０５はマルチキャスト信号が受信できないと判定する。この場合、コンテンツリクエスト部２０４は、ユニキャスト信号を指定して、コンテンツ送信部２０３へ要求する。
　ユニキャストリクエスト部２０１は、コンテンツリクエスト部２０４からのリクエストに対応するキャッシュが無い場合にコンテンツサーバ１０６にユニキャスト通信でコンテンツを要求する。例えば、この要求はＨＴＴＰが用いられ、コンテンツサーバ１０６にとっては、本システムとの特別な接続インタフェースを持つ必要がなく、通常の端末１０７の直接ＨＴＴＰリクエストを受けることと同様の処理で済ませることができる。
　ユニキャスト受信キャッシュ部２０２は、ユニキャストリクエスト部２０１からのリクエストに基づき、コンテンツサーバ１０６からユニキャスト通信により送信されたコンテンツを受信し、キャッシュする。
　なお、本開示では、ＭＵＣ１０４は複数あることを想定している。ＭＵＣ１０４にキャッシュがない場合は、ｒｅｑ．１起因で、ｒｅｑ．２、ｒｅｑ．３とコンテンツサーバ１０６へコンテンツをリクエストし、順次ｒｅｓ．１、ｒｅｓ．２およびＭ－ｒｅｓ．２、ｒｅｓ．３でキャッシュを作成しながら、端末１０７へ応答する。
　同一コンテンツに対する他端末からのリクエストは時間差があるため、同一コンテンツへの最初リクエストから遅れてのリクエストは、同一ＭＵＣ１０４であれば、そのコンテンツ受信キャッシュ部２０５から直接応答が返される。別ＭＵＣ１０４であっても、マルチキャスト等によりコンテンツが配信済みであれば、同様にそのコンテンツ受信キャッシュ部２０５から応答が返される。別ＭＵＣ１０４であり、ＵＭＣ１０５からコンテンツが未配信であれば、ＵＭＣ１０５へｒｅｑ．２は送られるものの、そのリクエストのコンテンツに対してはＵＭＣ１０５で待ち合わせを実施し、ＭＵＣ１０４がマルチキャストまたはユニキャストでの配信を待つ。別ＭＵＣ１０４であり、ＵＭＣ１０５からのマルチキャスト等によりコンテンツが配信済みの場合は、別ＭＵＣ１０４が受信ミスまたは、ＩＰマルチキャストのマルチキャストグループへの未参加が考えられるため、ＵＭＣ１０５からはユニキャスト通信によりｒｅｓ．２が返される。
（第２の実施形態）
　本実施形態では、コンテンツグループの識別方法について説明する。ユニキャスト受信キャッシュ部２０２は、複数のコンテンツでグルーピングしたコンテンツグループを生成する。この際、ユニキャスト受信キャッシュ部２０２は、複数のコンテンツでグルーピングしたコンテンツグループに識別するためのコンテンツグループ識別子を生成する。
　例えば、ユニキャスト受信キャッシュ部２０２は、コンテンツの配置場所及びファイル名などからなるコンテンツ識別子から一部を抽出したコンテンツグループ識別子を生成する。このように、同一のコンテンツグループが同一の識別子を有していてもよい。
　例えば、ＨＴＴＰでは、コンテンツを指定する際に、ＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）が用いられる。ＵＲＬは、ｈｏｓｔ名、パス、ファイル名、クエリストリング等からなる。今、下記のＵＲＬの複数のファイルが１の番組を成すとする。
ｈｔｔｐ／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｃｏｎｔｅｎｔｓ１／ｓｔｒｅａｍｓ０００１．ｔｓ
ｈｔｔｐ／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｃｏｎｔｅｎｔｓ１／ｓｔｒｅａｍｓ０００２．ｔｓ
・・・
ｈｔｔｐ／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｃｏｎｔｅｎｔｓ１／ｓｔｒｅａｍｓｘｘｘｘ．ｔｓ
　この場合、例えば、”ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｃｏｎｔｅｎｔｓ１”が同一であれば、同一の番組、すわなち、同一コンテンツグループとする。この場合、「ｈｔｔｐ／／ｗｗｗ２．ｅｘａｍｐｌｅ．ｏｒｇ／ｃｏｎｔｅｎｔｓ１／ｓｔｒｅａｍｓ０００１．ｔｓ」や「ｈｔｔｐ／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｃｏｎｔｅｎｔｓ２／ｓｔｒｅａｍｓ０００１．ｔｓ」は、別のコンテンツグループとして識別される。
　また、これらのコンテンツ識別子から一部を抽出したコンテンツグループ識別子はかならずしも既知である必要はなく、予測可能であればよい。例えば、“ｈｔｔｐ／／Ｙ－ＨＯＳＴ／Ｚ－ＰＡＴＨ／ｓｔｒｅａｍｓ－Ｘ－ＮＵＭＢＥＲ．ｔｓ”において、“Ｙ－ＨＯＳＴ”が何等かのホスト名に合致、Ｚ－ＰＡＴＨが何らかのパスに合致、“Ｘ－ＮＵＭＢＥＲ”が何らかの数に合致する場合のうち、“Ｙ－ＨＯＳＴ／Ｚ－ＰＡＴＨ”部分が同一のものを同一のコンテンツグループであるとする。
　これらは正規表現のマッチングで実装可能である。また、既定のコンテンツグループ識別子または、予想可能なコンテンツグループ識別子でない場合は、その他のコンテンツグループとしてマルチキャスト通信を実施してもよい。
　また、複数のコンテンツでグルーピングしたコンテンツグループに識別するためは、映像として複数のコンテンツをリスト化・グループ化し、そのコンテンツの所在を示すマニフェストファイルを元にコンテンツグループを識別する機能を備えることとしてもよい。
　ウェブ動画配信システムでは、複数のファイルを１つのコンテンツグループにと見なすとともに、ダウンロードすべきファイルを示すために、マニフェストファイルが利用される。そこで、マニフェストファイルを解析し、マニフェストに記載のファイル群を、同一のコンテンツグループとすることもできる。
　コンテンツ識別子から、同一コンテンツグループを識別する場合は、そのコンテンツ識別子の部分集合であるコンテンツグループ識別子が既知または予想可能である必要があるが、マニフェストからコンテンツを識別する場合は、コンテンツ識別子が既知である必要がない。
　また、マニフェストファイルのコンテンツ識別子が既知であってもよいが、ウェブ動画配信システムでは、マニフェストファイルの拡張子は、ｍ３ｕ８や、ｍｐｄ等、方式に応じて既知であることから、拡張子からマニフェストファイルであることを判定し、解析を実施してもよい。
（第３の実施形態）
　本実施形態では、コンテンツグループのマルチキャスト通信の詳細について説明する。コンテンツグループは、マルチキャストグループアドレス、ソースアドレス、ポート番号、パケット優先度を制御または区別し、マルチキャスト通信を行う機能を備えてもよい。
　ＩＰマルチキャストにおける、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）や、ＭＬＤ（Ｍｕｌｔｉｃａｓｔ　Ｌｉｓｔｅｎｅｒ　Ｄｉｓｃｏｖｅｒｙ）では、同一のマルチキャストグループを、宛先であるマルチキャストグループアドレスを用いて識別するか、併せて、送信元であるソースアドレスを用いて識別する。
　そこで、本開示では、これらマルチキャスト通信としてＩＰマルチキャストを用いる場合には、同一コンテンツグループに、同一のマルチキャストグループアドレスまたは、併せてソースアドレスを割り当てて通信を実施してもよい。また、ＩＰマルチキャストとしての同一のマルチキャストグループとすることに加えて、ポート番号や、パケットの優先度を設定、区別することもできる。
　パケットの優先度は、イーサネット（登録商標）のＣｏｓ値や、ＩＰパケットのヘッダのＩＰ　Ｐｒｅｃｅｄｅｎｃｅや、ＤＳＣＰなどを利用する場合が考えられる。ポート番号を区別することで、ＩＰマルチキャストの単一マルチキャストグループを小分けにして利用することや、ファイヤウォール等でフィルタリングが実施しやすくすることが可能となる。必要によりパケットの優先度を区別することで、コンテンツグループにサービスとしての優劣をつけることが可能となる。
　またコンテンツグループの判定や、これに対応する前記マルチキャストグループアドレス、ソースアドレス、ポート番号、パケット優先度などのマルチキャスト通信の識別子を利用した送受信はＭＵＣ１０４や、ＵＭＣ１０５で行われ、これらの情報の一部または全部をＵＭＣ１０５等で集中管理することができる。この場合は、ＭＵＣ１０４では、ステップＳ１やＳ４の実行時に、ＵＭＣ１０５では、ステップＳ２やステップＳ３で管理問い合わせを実施することができる。
（第４の実施形態）
　本実施形態のシステムは、マルチキャスト対象コンテンツと非対象コンテンツの弁別機能を備える。
　ＭＵＣ１０４のコンテンツリクエスト部２０４は、コンテンツがマルチキャスト対象のコンテンツか判断し、マルチキャスト対象ではない場合には、ＵＭＣ１０５またはコンテンツサーバ１０６にユニキャスト通信でコンテンツを要求する機能を備える。ＵＭＣ１０５のコンテンツ送信部２０３は、ＭＵＣ１０４からユニキャストリクエストを受けた場合、ユニキャストでコンテンツを送信する機能を備える。マルチキャスト通信を併用して利用するコンテンツのほか、ＭＵＣ１０４または、ＵＭＣ１０５を一般的なウェブプロキシシステムとして利用するコンテンツを併存させても構わない。
　マルチキャスト通信を利用する場合は、コンテンツグループを識別し、それぞれを異なるマルチキャスト通信とする処理を実施しなければならないが、ウェブプロキシでは、拡張子などを使って、事前の簡易的な処理の分岐が一般的に可能である。例えば、動画以外の拡張子については、マルチキャスト通信を利用する処理や判定を実施するステップに移行せずに、そのままウェブプロキシシステムとして処理することができる。これにより、本開示のシステムは、マルチキャスト化処理を簡易化できると共に、動画などのマルチキャスト化対象以外のＨＴＴＰリクエストを受け付け可能となり、汎用のプロキシとしての利用が可能となる。
（第５の実施形態）
　本実施形態のシステムは、マルチキャストの動的ｊｏｉｎ／ｌｅａｖｅ機能を備える。ＭＵＣ１０４のコンテンツリクエスト部２０４は、コンテンツがマルチキャスト対象のコンテンツである場合、コンテンツグループに対応するマルチキャストグループに参加しているか否かを判定する。未参加の場合、コンテンツリクエスト部２０４は、参加信号を送出する。一方、参加済みのマルチキャストグループに対応するコンテンツグループのコンテンツの要求が一定時間ない場合には、コンテンツリクエスト部２０４は、マルチキャストグループからの離脱信号を送出する。
　ＩＰマルチキャストでは、そのマルチキャストグループのルータへの登録が必要である。本実施形態は、静的な参加登録のほか、対象のマルチキャスト通信が発生する都度に、動的にマルチキャストルートの参加登録、参加離脱を実施することができる。この動的な参加登録、参加離脱の仕組みにはたとえばＩＧＭＰやＭＬＤが利用できる。
　この動的な参加登録、参加離脱によって、複数あるＭＵＣ１０４のうち、視聴がないコンテンツグループのマルチキャスト通信を実施しないことができ、不要なトラヒックを抑制することが可能となる。またマルチキャストグループの登録数に制限がある場合に、その登録数の抑制が可能となる。なお、ルータへ静的なマルチキャストグループの設定を行うことを前提とすることもできる。
（第６の実施形態）
　本実施形態のシステムは、マルチキャストｊｏｉｎ前にユニキャスト通信を行う。マルチキャスト通信ネットワーク１０２では、ＭＵＣ１０４が参加信号を送出し、ＭＵＣ１０４までのマルチキャストルートが確立された後に、ＭＵＣ１０４へのマルチキャスト通信を用いたコンテンツの配信が可能になる。本開示は、このようなＭＵＣ１０４のマルチキャストの動的参加離脱機能への対応が可能である。
　具体的には、コンテンツリクエスト部２０４は、参加信号を送出後、マルチキャストルートが確立される前に、ＵＭＣ１０５にユニキャスト通信でコンテンツを要求する。この場合、コンテンツ受信キャッシュ部２０５は、ＵＭＣ１０５からユニキャスト通信によりコンテンツ受信し、キャッシュする。一方、ＵＭＣ１０５に備わるコンテンツ送信部２０３は、ＭＵＣ１０４からユニキャストリクエストを受けた場合に、ユニキャストでコンテンツを送信する。
　これはルータにマルチキャストグループを動的設定する際に、その伝搬、設定の時間の間についても、コンテンツのＵＭＣ１０５からＭＵＣ１０４へのコンテンツの送受を可能とするものである。この際は、ＭＵＣ１０４はｒｅｑ．２で、明示的にマルチキャスト不要の指示をすることができる。このメッセージを受けたＵＭＣ１０５は、ユニキャスト通信のｒｅｓ．２を必ず応答する。
　また、ＵＭＣ１０５は、マルチキャスト通信のＭ－ｒｅｓ．２を合わせて応答することもできる。この場合、ＵＭＣ１０４は、Ｍ－ｒｅｓ．２の到着を待たずｒｅｓ．２を受信することで、キャッシュを生成する。
　ルータへのマルチキャストグループへ動的な参加登録の完了は、簡易的には、タイマによる設定が可能である。設定タイマ経過後は、ルータへマルチキャストグループの登録が行われたものとして、マルチキャスト通信を前提に動作を実施することができる。
　また、前記のようにＵＭＣ１０５はｒｅｓ．２とＭ－ｒｅｓ．２を同時に送信することもできる。ＭＵＣ１０４では、Ｍ－ｒｅｓ．２を受け取ったことを以て、ルータへのマルチキャストグループの動的な参加登録が完了したと判定することもできる。
　マルチキャストグループへの登録完了等のマルチキャスト通信が可能とＭＵＣ１０４が判定したのちは、ｒｅｓ．２では、マルチキャスト通信のＭ－ｒｅｓ．２のみを要求することができる。
（第７の実施形態）
　本実施形態のシステムは、マルチキャスト通信のＦＥＣ機能を備える。ＵＭＣ１０５のコンテンツ送信部２０３は、マルチキャスト送信機能において、前方誤り訂正符号（ＦＥＣ）情報を付加してマルチキャスト送信する機能を備えていてもよい。この場合、ＭＵＣ１０４のコンテンツ受信キャッシュ部２０５が、ＵＭＣ１０５からのＦＥＣ情報が付加されたマルチキャスト信号を、ＦＥＣ情報に基づいて、訂正する機能を備える。
　ＩＰマルチキャストによる通信は、一対多通信であり、自動再送要求（ＡＲＱ）等の個別の誤り訂正ができない。そこで、ＦＥＣ情報として一定の冗長データを付加することで、伝送路中のパケットロスや、受信機によるパケット受信ミスなどによるデータの欠陥を補うことができる。これによりパケットロスが起こりやすい不安定な伝送路や、受信機が安定的なパケット受信できない場合でも、安定的な通信を可能とすることができる。
　マルチキャスト通信に用いるＦＥＣは、以下の構成を採用してもよい。例えば、ＦＥＣが付加される前のコンテンツ情報と、付加されたＦＥＣ情報を異なるパケットとしてマルチキャスト送信する。この場合、ＦＥＣ情報が付加される前のコンテンツ情報のパケットと前記付加されたＦＥＣ情報のパケットとは、マルチキャストグループアドレス、ソースアドレス、ポート番号、パケット優先度の一部または全部が異なる。
　ＦＥＣはその強度に応じて、ＦＥＣ情報を付加する前のデータに対して、１又は２割前後の冗長データが増える。これを元のデータと単一のコンテンツグループとすることもでるが、別とすることも可能である。これにより、処理を分離しやく、また、ネットワーク中でのモニタや、フィルタリングが容易に実施しやすくなる。
　また、特に優先度の高いパケットは、トータルのネットワーク帯域を設計する必要がある。そのため。元のデータのみを優先度を高くし、ＦＥＣ情報の優先度を相対的に下げたり、反対に、ＦＥＣ情報のみの優先度を高くし、元のデータの優先度を相対的に下げたりすることができる。これにより、有限な高優先パケットを効率的に利用することが可能となる。
（第８の実施形態）
　本実施形態のシステムは、マルチキャスト通信のＡＲＱ機能を備える。ＭＵＣ１０４のコンテンツリクエスト部２０４はＡＲＱユニキャストリクエスト機能を備え、コンテンツ受信キャッシュ部２０５はＡＲＱユニキャスト受信キャッシュ機能を備える。ＵＭＣ１０５のコンテンツ送信部２０３は、ユニキャスト送信機能を備える。
　ＡＲＱユニキャストリクエスト機能は、ＵＭＣ１０５から受信したマルチキャスト信号に損失があった場合に、ユニキャスト通信を用いてコンテンツを要求する旨のユニキャストリクエストを送信する機能である。ＡＲＱユニキャスト受信キャッシュ機能は、ＵＭＣ１０５からユニキャスト通信を用いてコンテンツ受信し、コンテンツ受信キャッシュ部２０５にキャッシュする機能である。ＵＭＣ１０５のコンテンツ送信部２０３は、ＭＵＣ１０４からユニキャストリクエストを受けた場合に、ユニキャストでコンテンツを送信する機能を備えてもよい。
　ＭＵＣ１０４において、Ｍ－ｒｅｓ．２の受信待ち状態で、その受信信号が完成しない場合は、パケットロスやＭＵＣ１０４の受信ミス等が原因として考えられ、結果としてＭＵＣ１０４ではその信号の損失となる。この際には、ＭＵＣ１０４は、ユニキャスト通信に限定してｒｅｑ．２を再発行することで、このロスを補完することができる。これはファイル単位での自動再送要求（ＡＲＱ）である。ファイル単位でのＡＲＱは、パケット単位やブロック単位でのＡＲＱに比べて、ＨＴＴＰリクエストの仕組みが利用できることから、実装が容易である。
　また、本開示が他のマルチキャストシステムと異なり、ＨＴＴＰベースによるファイルベースのマルチキャスト化を実施していることから可能となる方式である。また、動画ファイルは、その再生時間を数秒程度に区切ったファイルに分割されていることがある。このような場合は、ファイル単位での再送処理でも十分な効率が保たれる。
　本実施形態は、マルチキャスト通信のＡＲＱにおいて、分割要求を行ってもよい。例えば、ＭＵＣ１０４のコンテンツリクエスト部２０４は、コンテンツの一部を要求する機能を備える。この場合、コンテンツ受信キャッシュ部２０５は、ＵＭＣ１０５からユニキャスト通信およびマルチキャスト通信に分かれたコンテンツ受信し、元のコンテンツを復元した上でキャッシュするマルチキャスト・ユニキャスト混合受信キャッシュ機能を備える。ＵＭＣ１０５に備わるコンテンツ送信部２０３は、ＭＵＣ１０４からコンテンツの一部のユニキャストリクエストを受けた場合に、ユニキャストでコンテンツを送信する。
　コンテンツリクエスト部２０４は、ファイル単位に限定せず、パケット単位、コンテンツを複数のブロックに分割したブロック単位でのＡＲＱも可能である。この際は、ＨＴＴＰリクエストｒｅｑ．２を用いることは、オーバーヘッドの観点から適切でない。そこでコンテンツリクエスト部２０４は、ｒｅｑ．２ではない、ＡＲＱメッセージを利用することが好ましい。
　コンテンツリクエスト部２０４は、ＮＡＣＫ（未到着応答確認）メッセージを利用したＡＲＱを行ってもよい。この方式は、ファイル単位のＡＲＱよりも、応答の高速性と帯域効率性に優れる。
　本実施形態のシステムは、パケット単位、ブロック単位でのＡＲＱを実施してもよい。この場合には、ＡＲＱを行うパケットや、コンテンツに含まれるブロックに対して順序番号を振り、順序番号により欠落の是非を判定および再要求を実施する。また、ファイル単位のＡＲＱとパケット単位、ブロック単位のＡＲＱを併用することもできる。
（第９の実施形態）
　本実施形態のシステムは、２以上の複数のＵＭＣ１０５を備え、複数のＵＭＣ１０５の全部または一部が常用系として動作し、常用系のＵＭＣ１０５が故障や過負荷の場合に、全部または一部の常用系のＵＭＣ１０５の機能を、他の常用系または非常用系のＵＭＣ１０５で代替する。
　図５に複数のＵＭＣ１０５がある場合の構成を示す。ＵＭＣ１０５に対応する複数のＵＭＣは、４０１、４０２、４０３である。４０１と４０２が常用系であり、４０３が非常用系であるとすると、ＵＭＣ４０１が故障や過負荷になった場合に、ＵＭＣ４０１の機能の全部または一部をＵＭＣ４０３に引き継ぐことができる。
　ＵＭＣ４０１とＵＭＣ４０２は負荷分散系であり、例えば、コンテンツグループ毎にＭＵＣ１０４からＵＭＣ４０１及び４０２への接続先を変更することができる。
　また、常用系は故障時の縮退動作も可能である。例えば、ＵＭＣ４０１が故障時には、ＵＭＣ４０１の機能と、ＵＭＣ４０２がＵＭＣ４０１の故障前から担当していた機能とを、ＵＭＣ４０２が併せて担当することができる。例えば、ＵＭＣ４０２が過負荷時には、ＵＭＣ４０１が担当する一部のコンテンツグループの処理機能と、ＵＭＣ４０２がＵＭＣ４０１の過負荷になる前から担当していた機能とを、ＵＭＣ４０２が併せて担当することができる。
　このような機能は、システム稼働率の向上を可能にするだけでなく、システムの置き換え、拡張においてもサービスを断にすることなく移行することを可能とする。
（第１０の実施形態）
　本実施形態のシステムは、２以上の複数のＭＵＣ１０４を備え、端末１０７からのリクエストを受けたＭＵＣ１０４が過負荷の場合、異なるＭＵＣ１０４へリダイレクトする信号を端末１０７へ送信し、リダイレクトを受信した端末１０７が、リダイレクトに基づき再びＭＵＣ１０４へリクエストを送信する。
　図６に、複数のＭＵＣ１０４がある場合の構成の一例を示す。図７に、ＭＵＣおよびＵＭＣにキャッシュがない場合のシーケンスを示す。ＭＵＣ１０４に対応する複数のＭＵＣは、５０１と５０２である。通常時にＭＵＣ５０１が特定の端末１０７と接続されており、ＭＵＣ５０１が過負荷である場合、ＭＵＣ５０１は、端末１０７のＨＴＴＰリクエストｒｅｑ．１に対して、ＭＵＣ５０２へのＨＴＴＰリダイレクトｒｅｄｉｒｅｃｔ．１を送信することができる。
　リダイレクトには、恒久的リダイレクトと、一時的リダイレクトがある。ＭＵＣ１０４は、当面ＭＵＣ５０１が応答できない場合又はＭＵＣ５０１からの設備移行が必要な場合、恒久的リダイレクトを実施し、それ以外は一時的リダイレクトを実施する。本実施形態は、一時的リダイレクト又は恒久的リダイレクトを、端末１０７に対してファイルのキャッシュをしない指定をして利用することができる。なお、恒久的リダイレクトを前期ファイルのキャッシュをしない指定をして利用した場合には、一時的リダイレクトの用途に利用できる。
　ＭＵＣ５０１からリダイレクト後に、ＭＵＣ５０２のコンテンツ受信キャッシュ部にキャッシュがない場合は、ＭＵＣ５０２のコンテンツリクエスト部は、ＵＭＣ１０５にリクエストを送信する。本実施形態では、ＵＭＣ１０５からコンテンツサーバ１０６にリクエストが転送された後、レスポンスがＵＭＣ１０５を経て、ＭＵＣ５０２のコンテンツ受信キャッシュ部に格納される。これにより、ｒｅｓ．３で端末１０７が応答を受信する。これにより、複数の端末１０７からの負荷が集中しやすいＭＵＣのピーク分散が可能となり、ＭＵＣへの設備投資を抑制することができる。
（第１１の実施形態）
　図１のシステムにおいて、端末１０７からのリクエストを受けたＭＵＣ１０４が過負荷の場合がある。本実施形態のシステムは、ＭＵＣ１０４に代えてＵＭＣ１０５に対してリダイレクトを行うことで、ＭＵＣ１０４の負荷を分散する。
　本実施形態のＭＵＣ１０４のユニキャスト送信部２０６は、過負荷の場合、ＵＭＣ１０５へリダイレクトする旨のメッセージを、リクエストの送信元の端末１０７へ送信する。端末１０７が、リダイレクトメッセージに基づき、ＵＭＣ１０５へリクエストを送信する。ＵＭＣ１０５のユニキャスト送信部２０６は、端末１０７からリクエストを受けた場合に、ユニキャストでコンテンツを端末１０７に送信する。
　図８に、ＭＵＣおよびＵＭＣにキャッシュがない場合のシーケンスを示す。通常時にＭＵＣ１０４が特定の端末１０７に接続されており、ＭＵＣ１０４が過負荷である場合、ＭＵＣ１０４は、端末１０７のＨＴＴＰリクエストｒｅｑ．１に対して、ＵＭＣ１０５へのＨＴＴＰリダイレクトｒｅｄｉｒｅｃｔ．１を送信する。
　ＵＭＣ１０５は、端末１０７からのリクエストを受けると、ユニキャスト受信キャッシュ部２０２にコンテンツが格納されているか否かを確認する。ユニキャスト受信キャッシュ部２０２にコンテンツが格納されていない場合、コンテンツサーバ１０６からユニキャストでコンテンツを取得し、ユニキャスト受信キャッシュ部２０２に格納する。そして、コンテンツ送信部２０３は、コンテンツをユニキャストで端末１０７に送信する。
　リダイレクトには、恒久的リダイレクトと、一時的リダイレクトがある。ＭＵＣ１０４は、当面ＭＵＣ１０４が応答できない場合又はＭＵＣ１０４からの設備移行が必要な場合、恒久的リダイレクトを実施し、それ以外は一時的リダイレクトを実施する。本実施形態は、一時的リダイレクト又は恒久的リダイレクトを、端末１０７に対してファイルのキャッシュをしない指定をして利用することができる。なお、恒久的リダイレクトを前期ファイルのキャッシュをしない指定をして利用した場合には、一時的リダイレクトの用途に利用できる。
　リダイレクト後にＵＭＣ１０５のユニキャスト受信キャッシュ部２０２にキャッシュがない場合は、ＵＭＣ１０５のユニキャストリクエスト部２０１がコンテンツサーバ１０６にリクエストを送信し、ＵＭＣ１０５のユニキャスト受信キャッシュ部２０２がコンテンツサーバ１０６からのレスポンスｒｅｓ．１を受信してコンテンツを格納する。このように、コンテンツサーバ１０６からのコンテンツは、ＵＭＣ１０５を経てｒｅｓ．３で、ユニキャスト通信を用いて端末１０７に応答される。これにより、複数の端末１０７からの負荷が集中しやすいＭＵＣ１０４のピーク分散が可能となり、ＭＵＣ１０４への設備投資を抑制することができる。
　なお、この端末１０７については、マルチキャストへの変換をせず、通常のウェブプロキシの動とほぼ同等である。また、ＭＵＣ１０４同士の負荷分散と、ＭＵＣ１０４からＵＭＣ１０５への負荷分散は併用可能である。端末１０７からのネットワーク距離の近さ、経由するネットワークの輻輳状況により使い分けることが可能である。
（第１２の実施形態）
　ＵＭＣ１０５に備わるユニキャスト受信キャッシュ部２０２は、コンテンツを分割して記憶してもよい。この場合、ＵＭＣ１０５に備わるコンテンツ送信部２０３は、分割したキャッシュ単位で、ＭＵＣ１０４にマルチキャストまたはユニキャストで送信する機能を備える。ＭＵＣ１０４では、分割されたキャッシュ単位でコンテンツ受信キャッシュ部２０５に格納し、ユニキャスト送信部２０６は、分割されたキャッシュからコンテンツを復元し、端末１０７へユニキャスト送信する。
　ＨＴＴＰではファイルが転送の基本単位であり、コンテンツサーバ１０６からＵＭＣ１０５がＨＴＴＰレスポンスｒｅｓ．１でファイルを完全に取得してから、マルチキャスト通信を開始すると、遅延が増える。ＵＭＣ１０５がｒｅｓ．１でコンテンツの取得を開始した段階で、１のファイルを分割してキャッシュし、Ｍ－ｒｅｓ．２のマルチキャスト通信を開始することで、遅延の隠ぺいが可能となる。
　さらに、ＭＵＣ１０４では、分割されたキャッシュをコンテンツ受信キャッシュ部２０５が１以上受信完了した時点で、ユニキャスト送信部２０６が端末１０７へのユニキャスト送信を開始してもよい。
　ＨＴＴＰではファイルが転送の基本単位である。そのため、ＵＭＣ１０５からＭＵＣ１０４がファイルを完全に取得してから、ＭＵＣ１０４から端末１０７へのＨＴＴＰレスポンスｒｅｓ．３の通信を開始すると、遅延が増える。そのため、ＭＵＣ１０４に備わるコンテンツ受信キャッシュ部２０５がコンテンツの取得を開始した段階で、１のファイルを分割してコンテンツ受信キャッシュ部２０５にキャッシュし、ユニキャスト送信部２０６がｒｅｓ．３を開始することが好ましい。これにより、本実施形態は、マルチキャスト通信ネットワーク１０２における遅延の隠ぺいが可能となる。
　ＭＵＣ１０４に備わるコンテンツ受信キャッシュ部２０５及びＵＭＣ１０５に備わるユニキャスト受信キャッシュ部２０２は、コンテンツをキャッシュするデータ保存領域を複数持っていてもよい。この場合、コンテンツ受信キャッシュ部２０５及びユニキャスト受信キャッシュ部２０２は、コンテンツの利用頻度、アクセス時刻、コンテンツグループのキャッシュ使用量、コンテンツまたはコンテンツグループ対する設定に応じて、前記データ保存領域間でキャッシュファイルを移動する機能を備えていてもよい。
　多数の端末１０７と接続されるＭＵＣ１０４や、複数のＭＵＣ１０４や端末１０７へコンテンツを提供するＵＭＣ１０５では、キャッシュの読み書き速度が応答速度や、負荷に影響を及ぼす。高速なキャッシュの読み書きができるほど、多くの端末１０７等を収容しやすい。このようなキャッシュはメモリ上に置くことが望ましい。一方で、メモリ上のキャッシュはサイズに制限があるため、キャッシュによる配信効率の向上のためには、より多くのキャッシュを持つことも望ましい。
　そこで、１次キャッシュをメモリ上に、２次キャッシュをディスク上に配置することで、速度と容量の２つの要件を満たすことができる。ここで１次キャッシュから２次キャッシュの移動は、コンテンツの利用頻度、アクセス時刻、コンテンツグループのキャッシュ使用量、コンテンツまたはコンテンツグループ対する設定に応じて実施することができる。
　コンテンツ利用頻度に応じたキャッシュの移動は、例えば、コンテンツ毎に利用回数のテーブルを保持し、その利用回数に応じて２次キャッシュへのキャッシュアウトを制御する。アクセス時刻に応じたキャッシュの移動は、例えば、最終アクセス時刻をもとにタイマにより２次キャッシュへキャッシュアウトする。コンテンツグループのキャッシュ使用量に応じたキャッシュの移動は、例えば、特定の単一もしくは複数コンテンツグループで最大キャッシュ量を制限する。同一の制御ポリシが適用されるコンテンツグループ内でのキャッシュアウトは、前記のコンテンツの利用頻度、アクセス時間等により制御される。また、これらの設定は、個別のコンテンツもしくはコンテンツグループに対して、設定することもできる。
（第１３の実施形態）
　本実施形態では、ＵＭＣ１０５に備わるユニキャスト受信キャッシュ部２０２は、ＭＵＣ１０４からのリクエストに拠らず、コンテンツサーバ１０７からコンテンツを受信する。例えば、コンテンツがコンテンツサーバ１０６からＵＭＣ１０５にプッシュ配信される。ＵＭＣ１０５に備わるユニキャスト受信キャッシュ部２０２は、受信したコンテンツからキャッシュを生成し、格納する。そして、ＵＭＣ１０５に備わるコンテンツ送信部２０３が、コンテンツグループ毎に、マルチキャスト通信またはユニキャスト通信を用いて、コンテンツを送信する。
　前述までのシステムは、端末１０７からのＨＴＴＰリクエストｒｅｑ．１を起因とし、リクエストとレスポンスをリレーすることから、配信遅延が蓄積する場合がある。ウェブ動画配信システムでは、アダプティブビットレート（ＡＢＲ）として、複数レベルの画質のファイルを用意して、端末１０７のプレイヤで、能動的にダウンロードする画質のファイル選択することが一般的である。配信遅延が蓄積した場合、そのネットワークの帯域は十分であって、遅延から低画質の映像に切り替わる可能性がある。そこで、コンテンツサーバ１０６からプッシュでＵＭＣ１０５へコンテンツファイルを送信し、且つ、ＵＭＣ１０５からＭＵＣ１０４へ同様にプッシュでマルチキャストまたはユニキャストで送信することで、端末１０７からのリクエストが行われる前までにＭＵＣ１０４にキャッシュを作成することもできる。これにより、最短の応答時間でコンテンツを端末１０７に送信することができ、高画質で安定的な配信を実現できる。
（第１４の実施形態）
　端末１０７からのリクエストに拠らず、ＭＵＣ１０４に備わるコンテンツリクエスト部２０４またはＵＭＣ１０５に備わるユニキャストリクエスト部２０１が、コンテンツグループのコンテンツのリクエストする機能を備えていてもよい。
　前述のコンテンツサーバ１０６からのプッシュは、通常のウェブサーバの機能の拡張が必要である。そこで、ＭＵＣ１０４またはＵＭＣ１０５は、既知のコンテンツを、端末１０７からのリクエストによらず、主体的にリクエストしてもよい。
　例えば、図９に示すようにステップＳ１で主体的にＨＴＴＰリクエストｒｅｑ．２を生成する場合がある。なお、図９はシーケンス開始時にキャッシュがない場合である。
　ＨＴＴＰリクエストｒｅｑ．２を受けたＵＭＣ１０５は、ステップＳ２において、ＭＵＣ１０４からのＨＴＴＰリクエストｒｅｑ．２に対応するキャッシュがないと判断し、コンテンツサーバ１０６へＨＴＴＰリクエストｒｅｑ．３を転送する。
　コンテンツサーバ１０６は、ｒｅｑ．３に対応するコンテンツファイルを、ＨＴＴＰレスポンスｒｅｓ．１でＵＭＣ１０５へ応答する。ｒｅｓ．１を受信したＵＭＣ１０５は、ステップＳ３を実行する。ステップＳ３において、ＵＭＣ１０５は、ｒｅｓ．１に含まれるコンテンツファイルを用いてキャッシュファイルを生成し、キャッシュファイルをＭＵＣ１０４へ応答する。ここで、ＵＭＣ１０５からＭＵＣ１０４への応答は、ＨＴＴＰリクエストｒｅｑ．２に対応する応答であり、ＨＴＴＰレスポンスｒｅｓ．２、又はマルチキャストによるレスポンスＭ－ｒｅｓ．２、又はｒｅｓ．２及びＭ－ｒｅｓ２の両方、のいずれも採用することができる。
　ｒｅｓ．２又はＭ－ｒｅｓ２を受信したＭＵＣ１０４は、ｒｅｓ．２又はＭ－ｒｅｓ．２に含まれるキャッシュファイルを格納する。
　次に、端末１０７からのＨＴＴＰリクエストｒｅｑ．１はＭＵＣ１０４に送信される。ｒｅｑ．１を受信したＭＵＣ１０４は、ステップＳ４を実行する。ステップＳ４において、ＭＵＣ１０４は、端末１０７からのＨＴＴＰリクエストｒｅｑ．１に対応するキャッシュがあると判断し、格納しているキャッシュファイルをＨＴＴＰレスポンスｒｅｓ．３を応答する。ｒｅｓ．３は、ＨＴＴＰリクエストｒｅｑ．１に対応する端末１０７への応答である。なお、ＭＵＣ１０４とＵＭＣ１０５のキャッシュはディスク等の記憶容量の制限、もしくは、配信ポリシから、適切なタイミングで消去される。
　なお、ｒｅｓ．１は、必ずしもｒｅｓ．２又はＭ－ｒｅｓ２によるキャッシュ作成後に発生する必要はない。ｒｅｑ．２より後にｒｅｓ．１が発生することで、キャッシュ生成までの時間を短縮できるからである。
　例えば、図１０に示すようにステップＳ２で主体的にＨＴＴＰリクエストｒｅｑ．３を生成する場合がある。なお、図１０はシーケンス開始時にキャッシュがない場合である。
　ＨＴＴＰリクエストｒｅｑ．３を受けたコンテンツサーバ１０６は、ｒｅｑ．３に対応するコンテンツファイルを、ＨＴＴＰレスポンスｒｅｓ．１でＵＭＣ１０５へ応答し、ＵＭＣ１０５は、ｒｅｓ．１に含まれるコンテンツファイルを用いてキャッシュファイルを生成する。
　次に、端末１０７からのＨＴＴＰリクエストｒｅｑ．１はＭＵＣ１０４に送信される。
ｒｅｑ．１を受信したＭＵＣ１０４は、ステップＳ１を実行する。ステップＳ１において、ＭＵＣ１０４は、端末１０７からのＨＴＴＰリクエストｒｅｑ．１に対応するキャッシュがないと判断し、上位のプロキシサーバであるＵＭＣ１０５へＨＴＴＰリクエストｒｅｑ．２を転送する。
　ｒｅｓ．２を受信したＵＭＣ１０５は、ステップＳ３を実行する。ステップＳ３において、ＵＭＣ１０５は、ＭＵＣ１０４からのＨＴＴＰリクエストｒｅｑ．２に対応するキャッシュがあると判断し、キャッシュファイルをＵＭＣ１０４へ応答する。ここで、ＵＭＣ１０５からＭＵＣ１０４への応答は、ＨＴＴＰリクエストｒｅｑ．２に対応する応答であり、ＨＴＴＰレスポンスｒｅｓ．２、又はマルチキャストによるレスポンスＭ－ｒｅｓ．２、又はｒｅｓ．２及びＭ－ｒｅｓ２の両方、のいずれも採用することができる。
　ｒｅｓ．２又はＭ－ｒｅｓ２を受信したＭＵＣ１０４は、ステップＳ４を実行する。ステップＳ４では、ＭＵＣ１０４は、ｒｅｓ．２又はＭ－ｒｅｓ．２に含まれるキャッシュファイルを格納する。ＭＵＣ１０４は、格納しているキャッシュファイルをＨＴＴＰレスポンスｒｅｓ．３を応答する。ｒｅｓ．３は、ＨＴＴＰリクエストｒｅｑ．１に対応する端末１０７への応答である。なお、ＭＵＣ１０４とＵＭＣ１０５のキャッシュはディスク等の記憶容量の制限、もしくは、配信ポリシから、適切なタイミングで消去される。
　なお、ｒｅｓ．１は、必ずしもｒｅｓ．３によるキャッシュ作成後に発生する必要はない。ｒｅｑ．３より後にｒｅｓ．１が発生することで、キャッシュ生成までの時間を短縮できるからである。
　これにより、コンテンツサーバ１０６に特別な拡張をすることなく、最短の応答時間でコンテンツを端末１０７に送信することができ、高画質で安定的な配信を実現できる。
　端末１０７からのリクエストに拠らずにＭＵＣ１０４又はＵＭＣ１０５がコンテンツのリクエストを行う場合、ＭＵＣ１０４に備わるコンテンツリクエスト部２０４又はＵＭＣ１０５に備わるユニキャストリクエスト部２０１は、コンテンツサーバ１０６でのコンテンツ生成時刻を識別、設定、予測して、前記コンテンツ生成時刻に同期することを特徴としてもよい。
　静的なコンテンツの場合はコンテンツに対する既知のＵＲＬがあり、端末１０７からのリクエストによらない、ＭＵＣ１０４またはＵＭＣ１０５によるリクエストを生成できる。ライブ等の未来のコンテンツに対しては、静的な設定によるリクエスト生成はできない場合がある。そのため、コンテンツリクエスト部２０４又はユニキャストリクエスト部２０１は、マニフェストファイルを解析することで、マニフェストファイル記載の最新のコンテンツもしくは、マニフェストファイル記載のルールから短期的未来に生成されると予測されるコンテンツに対してのリクエストを生成してもよい。これにより、ライブ、またはリニア映像配信においても、コンテンツサーバに特別な拡張をすることなく、最短の応答時間でコンテンツを端末１０７に送信することができ、高画質で安定的な配信を実現できる。
　コンテンツに時間順序性があるコンテンツグループの場合、端末１０７からのリクエストがあったコンテンツより前又は後のコンテンツをリクエストする機能を、コンテンツリクエスト部２０４又はユニキャストリクエスト部２０１が備えていてもよい。
　特定のコンテンツの再生が開始されると、端末１０７の操作者は、端末１０７上の再生バーを操作して、再生開始時の時刻順ではなく、前もしくは後ろに時刻不連続に再生する場合がある。このような場合に高画質で安定的な配信を実現するために、再生時刻近傍の時刻のファイルまたは、統計的に再生頻度の高いファイルをＭＵＣ１０４またはＵＭＣ１０５がリクエストしてもよい。
（第１５の実施形態）
　マルチキャスト通信に利用可能なマルチキャストグループアドレス、ソースアドレス、ポート番号等のマルチキャスト通信識別子の未使用の組み合わせを貯めておき、端末１０７からのリクエストに基づく新たなコンテンツグループのコンテンツの通信が発生するたびに、貯めておいたマルチキャスト通信識別子の未使用の組み合わせを割り当て、また、一定時間利用が無い時には前記マルチキャスト通信識別子の利用を停止し、再びマルチキャスト通信識別子の未使用の組み合わせに貯めてもよい。
　アドレス管理及び配布元は、ＵＭＣ１０５又はその他の管理サーバで実施することが考えられる。また、アドレスの配布先は、ＵＭＣ１０５におけるコンテンツ送信部２０３およびＭＵＣ１０４におけるコンテンツ受信キャッシュ部２０５である。
　図１１及び図１２に、ＵＭＣ１０５がマルチキャストグループアドレス、ソースアドレス、ポート番号等の空きマルチキャスト通信識別子のテーブルを持った場合のテーブル配置を示す。８０１が空きマルチキャスト通信識別子テーブル、８０２がコンテンツ送信部２０３によるマルチキャスト通信時にそのマルチキャスト通信識別子を保存しているテーブル、８０３がコンテンツ受信キャッシュ部２０５によるマルチキャスト受信時にそのマルチキャスト識別子を保存しているテーブルである。
　コンテンツ送信部２０３はマルチキャスト通信の送信を始める際、テーブル８０２を参照し、該当コンテンツグループに対応するマルチキャスト識別子がない場合には、テーブル８０１からマルチキャスト識別子を取得し、テーブル８０２に登録する。同様に、コンテンツ受信キャッシュ部２０５はマルチキャスト通信の受信を始める際、テーブル８０３を参照し、該当コンテンツグループに対応するマルチキャスト識別子がない場合には、テーブル８０１からマルチキャスト識別子を取得し、テーブル８０３に登録する。テーブル８０１は、マルチキャスト識別子を払い出したのち、払い出したコンテンツグループによる利用フラグをテーブルに書き込む。
　図１３にテーブル８０１が保持するテーブルイメージを示す。ここでは、マルチキャスト識別子ＩＤＭ２がコンテンツグループＩＤＧ１に対して、マルチキャスト識別子ＩＤＭ３がコンテンツグループＩＤＧ２に対して払い出され、共にＭＵＣ１０４が利用していることを、その他のマルチキャスト識別子は未利用であることを示している。
　なお、テーブル８０３はテーブル８０２の部分集合であるため、テーブル８０１からマルチキャスト識別子を取得するのではなく、テーブル８０２から取得してもかまわない。この場合、テーブル８０１における利用ＭＵＣは、テーブル８０２で管理しても構わない。
　なお、図１３に示すテーブルは模式的に表しており、メモリを節約し、テーブル検索をしやすいようハッシュを利用するか、リストによるデータ構造等他の形態での実装でも構わない。
　図１４にテーブル８０２とテーブル８０３の一例を示す。ここでは、コンテンツグループＩＤＧ１に対してマルチキャスト識別子ＩＤＭ２が、コンテンツグループＩＤＧ２に対してマルチキャスト識別子ＩＤＭ３が利用されていることを示し、テーブルの他の部分は空き示している。
　なお、図１４に示すテーブルは模式的に表しており、メモリを節約し、テーブル検索をしやすいようハッシュを利用するか、リストによるデータ構造等他の形態での実装でも構わない。ここで、テーブル８０２はテーブル８０１の部分集合であり、同一機能部に実装した場合は、単一のテーブルで管理しても構わない。
　また、ＭＵＣ１０４において、コンテンツの利用がない場合には、タイマ等を利用してその利用停止を判定し、テーブル８０３から該当のコンテンツグループとマルチキャスト識別子を削除するとともに、テーブル８０１又はテーブル８０２における利用ＭＵＣから自身のＭＵＣを削除してもよい。利用ＭＵＣが空になると、マルチキャスト受信を行うＭＵＣが無いと判定されるため、テーブル８０１の利用コンテンツグループ列の該当コンテンツグループと、テーブル８０２の該当コンテンツグループの行を削除する。この操作により、マルチキャスト識別子が再利用できる。
（第１６の実施形態）
　複数のＭＵＣ１０４に同一のＩＰアドレスを割り当て、端末１０７からは複数のＭＵＣ１０４を区別せずに最寄りのＭＵＣ１０４にリクエストを送信することができる構成を採用してもよい。
　端末１０７からのＭＵＣ１０４のリクエスト受付インタフェースをＩＰエニーキャストによるルーティングを利用し、端末１０７の最寄りのＭＵＣへアクセスするよう誘導してもよい。これにより、ＤＮＳ等他の方式による管理に比べに、その管理を容易とすることが可能となる。さらに、ＭＵＣ１０４のリクエスト受付インタフェースに対する攻撃も分散化されることになり、攻撃に対して堅牢化することが可能となる。
（第１７の実施形態）
　マニフェストファイルに記載のコンテンツ所在位置を、コンテンツサーバ１０６からＭＵＣ１０４に変更し、端末１０７からのＭＵＣ１０４へリクエストを行うようにしてもよい。
　ウェブの動画配信システムでは、動画の最初の読み込みにあたりマニフェストと呼ばれる動画データの実態ファイル名や、ファイルの場所を示すファイルを読み込む。このマニフェストファイル中の動画データのファイル場所のＭＵＣ１０４へ変更することで、端末１０７からのＨＴＴＰリクエストｒｅｑ．１をＭＵＣ１０４宛に変更することができる。
　マニフェストファイル自体もＨＴＴＰリクエスト、レスポンスにより端末１０７に送信されるため、コンテンツサーバ１０６による端末ＩＰアドレスや、ＨＴＴＰリクエストのヘッダ情報、ＨＴＴＰリクエストのクエリストリング情報等のＨＴＴＰリクエストから取得できる端末１０７に依存するか端末１０７から付加できる情報により、端末１０７の視聴環境にあったマニフェストファイルを端末１０７に個別に送信し分けることも容易になる。
　これにより、本実施形態は、ＤＮＳによる振り分けと比べ、より柔軟な配信制御が可能となるとともに、ウェブシステムに閉じて、制御が完結できシステムの構築が容易になる。また、このマニフェストファイル書き換えによるリクエスト先の変更は、他のリクエスト先の変更方法と組み合わせてもよい。
　マニフェストファイルは、書き換え前のマニフェストファイルが格納されたコンテンツサーバ１０６で書き換えを実施してもよいが、別の書き換え用のサーバを利用しても構わない。これにより、コンテンツサーバ１０６が直接ＭＵＣ１０４の位置を知ることなく、端末１０７からＭＵＣ１０４へのリクエストを実現できる。これは、コンテンツサーバ１０６と、ＭＵＣ１０４の管理主体が異なる場合に有効であり、ＭＵＣ１０４の管理主体がマニフェストファイル書き換えサーバを管理することにより実現できる。
（第１８の実施形態）
　端末１０７からのコンテンツサーバ１０６へのリクエストを、コンテンツサーバ１０６がＭＵＣ１０４へリダイレクトすることにより、端末１０７からのＭＵＣ１０４へのリクエストを行うことを特徴としてもよい。
　該当コンテンツサーバ１０６において、端末ＩＰアドレスや、ＨＴＴＰリクエストのヘッダ情報、ＨＴＴＰリクエストのクエリストリング情報等のＨＴＴＰリクエストから取得できる端末１０７に依存するか端末１０７から付加できる情報により判定を実施し、端末１０７がＭＵＣ１０４へアクセスするためにＨＴＴＰリダイレクトすることができる。
　リダイレクトメッセージには恒久的リダイレクトと一時的リダイレクトがあるが、本実施形態は、一時的リダイレクト又は恒久的リダイレクトを、端末１０７に対してファイルのキャッシュをしない指定をして利用することができる。なお、恒久的リダイレクトを前期ファイルのキャッシュをしない指定をして利用した場合には、一時的リダイレクトの用途に利用できる。これによりコンテンツそのものを書き換えることなしに、また、端末１０７の一次リクエストをコンテンツサーバ１０６に集約しながら、端末１０７からのＭＵＣ１０４へのアクセスを実現できる。また、このリダイレクトよるリクエスト先の変更は、他のリクエスト先の変更方法と組み合わせてもよい。
（第１９の実施形態）
　本実施形態は、図１に示すシステムが、コンテンツ又はコンテンツグループのリクエストを転送する転送部（不図示）を更に備える。本実施形態は、端末１０７からのコンテンツサーバ１０６へのリクエストを、コンテンツサーバ１０６が転送部へリダイレクトし、転送部が端末１０７から転送部へのリクエストをＭＵＣ１０４へリダイレクトする。これにより、本実施形態は、端末１０７からのＭＵＣ１０４へのリクエストを行う。これは、コンテンツサーバ１０６は、転送部となる別サーバに一次リダイレクトを実施し、更に転送部がＭＵＣ１０４へリダイレクトするものである。
　該当コンテンツサーバ１０６において、端末ＩＰアドレスや、ＨＴＴＰリクエストのヘッダ情報、ＨＴＴＰリクエストのクエリストリング情報等のＨＴＴＰリクエストから取得できる端末１０７に依存するか端末１０７から付加できる情報により判定を実施し、端末１０７が転送部へアクセスするためにＨＴＴＰリダイレクトし、更に、転送部において、端末ＩＰアドレスや、ＨＴＴＰリクエストのヘッダ情報、ＨＴＴＰリクエストのクエリストリング情報等のＨＴＴＰリクエストから取得できる端末１０７に依存するか端末１０７から付加できる情報により判定を実施し、端末１０７がＭＵＣ１０４へアクセスするためにＨＴＴＰリダイレクトすることができる。
　これにより、コンテンツサーバ１０６が直接ＭＵＣ１０４の位置を知ることなく、端末１０７からＭＵＣ１０４へのリクエストを実現できる。これは、コンテンツサーバ１０６と、ＭＵＣ１０４の管理主体が異なる場合に有効であり、ＭＵＣ１０４の管理主体が転送部用のサーバを管理することにより実現できる。
　このリダイレクトメッセージには恒久的リダイレクトと一時的リダイレクトがあるが、本実施形態は、一時的リダイレクト又は恒久的リダイレクトを、端末１０７に対してファイルのキャッシュをしない指定をして利用することができる。なお、恒久的リダイレクトを前期ファイルのキャッシュをしない指定をして利用した場合には、一時的リダイレクトの用途に利用できる。
　本開示の装置は、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。
　本開示は情報通信産業に適用することができる。
１０１、１０３：ネットワーク
１０２：マルチキャスト通信ネットワーク
１０４、５０１、５０２：ＭＵＣ
１０５、４０１、４０２、４０３：ＵＭＣ
１０６：コンテンツサーバ
１０７：端末
２０１：ユニキャストリクエスト部
２０２：ユニキャスト受信キャッシュ部
２０３：コンテンツ送信部
２０４：コンテンツリクエスト部
２０５：コンテンツ受信キャッシュ部
２０６：ユニキャスト送信部
８０１、８０２、８０３：テーブル

Claims (8)

  1. 　ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間がマルチキャスト通信ネットワークを用いて接続されているコンテンツ配信システムであって、
    　ユニキャスト通信からマルチキャスト通信へ変換し、前記マルチキャスト通信ネットワークへ送出するユニキャストマルチキャスト変換装置と、前記マルチキャスト通信ネットワークで伝送されたマルチキャスト通信をユニキャスト通信へ変換するマルチキャストユニキャスト変換装置と、を備え、
    　前記マルチキャストユニキャスト変換装置は、
    　複数のコンテンツがグルーピングされているコンテンツグループを識別し、前記コンテンツグループ毎にユニキャスト通信およびマルチキャスト通信のいずれか一方又は双方の通信方式を用いて送信されたコンテンツを前記マルチキャスト通信ネットワークから受信し、前記コンテンツグループに含まれるコンテンツを格納するコンテンツ受信キャッシュ部と、
    　前記端末からのリクエストに基づき、前記コンテンツ受信キャッシュ部に格納されているコンテンツを前記端末に送信するユニキャスト送信部と、
    　前記端末からのリクエストに対応するコンテンツが前記コンテンツ受信キャッシュ部に格納されていない場合、前記端末からのリクエストに対応するコンテンツを含むコンテンツグループの要求を、ユニキャスト通信及びマルチキャスト通信のいずれか一方又は双方の通信方式で選択的に行うコンテンツリクエスト部と、
    　を備え、
    　前記ユニキャストマルチキャスト変換装置は、
    　前記コンテンツサーバからユニキャスト通信を用いてコンテンツを受信し、格納するユニキャスト受信キャッシュ部と、
    　前記コンテンツリクエスト部からのリクエストに対応するコンテンツグループを前記ユニキャスト受信キャッシュ部から読み出し、読み出したコンテンツグループを、ユニキャスト通信およびマルチキャスト通信のいずれか一方又は双方の通信方式を用いて、前記マルチキャスト通信ネットワークに送信するコンテンツ送信部と、
    　前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループが前記ユニキャスト受信キャッシュ部に格納されていない場合、前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループの要求を、ユニキャスト通信を用いて前記コンテンツサーバに対して行うユニキャストリクエスト部と、
    　を備える、コンテンツ配信システム。
  2. 　前記マルチキャストユニキャスト変換装置に備わる前記コンテンツリクエスト部は、前記端末からのリクエストに対応するコンテンツがマルチキャスト対象のコンテンツであるか否かを判定し、マルチキャスト対象ではない場合には、前記ユニキャストマルチキャスト変換装置に対し、ユニキャスト通信を用いたコンテンツの要求を行い、
    　前記ユニキャストマルチキャスト変換装置に備わる前記コンテンツ送信部は、ユニキャスト通信を用いたコンテンツの要求を受信した場合、前記コンテンツリクエスト部からのリクエストに対応するコンテンツを、ユニキャスト通信を用いて前記マルチキャストユニキャスト変換装置に送信する、
    　請求項１に記載のコンテンツ配信システム。
  3. 　前記マルチキャストユニキャスト変換装置に備わる前記コンテンツリクエスト部は、自装置が前記端末からのリクエストに対応するコンテンツに対応するマルチキャストグループに参加しているか否かを判定し、参加済みの場合、前記端末からのリクエストに対応するコンテンツの要求を、参加済みのマルチキャストグループに対して行い、未参加の場合、前記ユニキャストマルチキャスト変換装置に対し、ユニキャスト通信を用いたコンテンツの要求を行い、
    　前記ユニキャストマルチキャスト変換装置に備わる前記コンテンツ送信部は、ユニキャスト通信を用いたコンテンツの要求を受信した場合、前記コンテンツリクエスト部からのリクエストに対応するコンテンツを、ユニキャスト通信を用いて前記マルチキャストユニキャスト変換装置に送信する、
    　請求項１又は２に記載のコンテンツ配信システム。
  4. 　前記マルチキャストユニキャスト変換装置に備わる前記コンテンツ受信キャッシュ部は、前記ユニキャストマルチキャスト変換装置からマルチキャスト通信を用いて受信したコンテンツグループにおける損失の有無を判定し、損失がある場合、前記コンテンツリクエスト部は、前記ユニキャストマルチキャスト変換装置に対し、ユニキャスト通信を用いたコンテンツの要求を行い、
    　前記ユニキャストマルチキャスト変換装置に備わる前記コンテンツ送信部は、ユニキャスト通信を用いたコンテンツの要求を受信した場合、前記コンテンツリクエスト部からのリクエストに対応するコンテンツを、ユニキャスト通信を用いて前記マルチキャストユニキャスト変換装置に送信する、
    　請求項１から３のいずれかに記載のコンテンツ配信システム。
  5. 　前記ユニキャストマルチキャスト変換装置に備わる前記コンテンツ送信部は、コンテンツを複数のブロックに分割し、分割後のブロック単位でコンテンツを格納し、前記ブロック単位でマルチキャスト又はユニキャストで送信し、
    　前記マルチキャストユニキャスト変換装置に備わる前記コンテンツ受信キャッシュ部は、ブロックを受信すると、ブロックを用いてコンテンツを復元する、
    　請求項１から４のいずれかに記載のコンテンツ配信システム。
  6. 　ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間に接続され、ユニキャスト通信からマルチキャスト通信へ変換し、マルチキャスト通信ネットワークへ送出するユニキャストマルチキャスト変換装置であって、
    　前記コンテンツサーバからユニキャスト通信を用いてコンテンツを受信し、格納するユニキャスト受信キャッシュ部と、
    　前記マルチキャスト通信ネットワークで伝送されたマルチキャスト通信をユニキャスト通信へ変換するマルチキャストユニキャスト変換装置から、複数のコンテンツがグルーピングされているコンテンツグループのリクエストを受信すると、当該リクエストに対応するコンテンツグループを前記ユニキャスト受信キャッシュ部から読み出し、読み出したコンテンツグループを、ユニキャスト通信およびマルチキャスト通信のいずれか一方又は双方の通信方式を用いて、前記マルチキャスト通信ネットワークに送信するコンテンツ送信部と、
    　前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループが前記ユニキャスト受信キャッシュ部に格納されていない場合、前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループの要求を、ユニキャスト通信を用いて前記コンテンツサーバに対して行うユニキャストリクエスト部と、
    　を備える、ユニキャストマルチキャスト変換装置。
  7. 　ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間に接続され、ユニキャスト通信からマルチキャスト通信へ変換し、マルチキャスト通信ネットワークへ送出するユニキャストマルチキャスト変換装置が実行するコンテンツ配信方法であって、
    　前記コンテンツサーバからユニキャスト通信を用いてコンテンツを受信し、当該コンテンツをユニキャスト受信キャッシュ部に格納し、
    　コンテンツ送信部が、前記マルチキャスト通信ネットワークで伝送されたマルチキャスト通信をユニキャスト通信へ変換するマルチキャストユニキャスト変換装置から、複数のコンテンツがグルーピングされているコンテンツグループのリクエストを受信すると、当該リクエストに対応するコンテンツグループを前記ユニキャスト受信キャッシュ部から読み出し、読み出したコンテンツグループを、ユニキャスト通信およびマルチキャスト通信のいずれか一方又は双方の通信方式を用いて、前記マルチキャスト通信ネットワークに送信し、
    　ユニキャストリクエスト部が、前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループが前記ユニキャスト受信キャッシュ部に格納されていない場合、前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループの要求を、ユニキャスト通信を用いて前記コンテンツサーバに対して行う、
    　コンテンツ配信方法。
  8. 　請求項６に記載のユニキャストマルチキャスト変換装置に備わる各機能部としてコンピュータを実現させるためのコンテンツ配信プログラム。
PCT/JP2019/027388 2019-07-10 2019-07-10 コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム WO2021005756A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US17/625,554 US11882340B2 (en) 2019-07-10 2019-07-10 Content distribution system, unicast multicast converter, content distribution method and content distribution program
JP2021530431A JP7298688B2 (ja) 2019-07-10 2019-07-10 コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム
PCT/JP2019/027388 WO2021005756A1 (ja) 2019-07-10 2019-07-10 コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム
JP2023007138A JP7473025B2 (ja) 2019-07-10 2023-01-20 コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2019/027388 WO2021005756A1 (ja) 2019-07-10 2019-07-10 コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム

Publications (1)

Publication Number Publication Date
WO2021005756A1 true WO2021005756A1 (ja) 2021-01-14

Family

ID=74114468

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/027388 WO2021005756A1 (ja) 2019-07-10 2019-07-10 コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム

Country Status (3)

Country Link
US (1) US11882340B2 (ja)
JP (2) JP7298688B2 (ja)
WO (1) WO2021005756A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230275949A1 (en) * 2020-06-30 2023-08-31 Lg Electronics Inc. Method and apparatus for processing multicast signal

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006303965A (ja) * 2005-04-21 2006-11-02 Kddi Corp コンテンツ伝送装置
JP2008092239A (ja) * 2006-10-02 2008-04-17 Mitsubishi Electric Corp マルチキャスト通信を用いた映像配信システム
US20130007825A1 (en) * 2007-06-04 2013-01-03 At&T Intellectual Property L, L.P. System and Method of Delivering Video Content
JP2019075741A (ja) * 2017-10-18 2019-05-16 日本電信電話株式会社 トラヒック変換方法、配信システム、ユニキャスト・マルチキャスト変換装置、マルチキャスト・ユニキャスト変換装置、ユニキャスト・マルチキャスト変換プログラム、及びマルチキャスト・ユニキャスト変換プログラム

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020001310A1 (en) 2000-06-29 2002-01-03 Khanh Mai Virtual multicasting
BRPI0621810A2 (pt) 2006-06-27 2011-12-20 Thomson Licensing Método e aparelho para distribuir dados em difusão seletiva de forma confiável
JP4665007B2 (ja) 2008-03-28 2011-04-06 パナソニック株式会社 監視映像送信装置および方法
JPWO2012011449A1 (ja) 2010-07-20 2013-09-09 シャープ株式会社 プロキシサーバ、中継方法、通信システム、中継制御プログラム、および記録媒体
EP2815557B1 (en) * 2012-02-16 2018-03-21 Telefonaktiebolaget LM Ericsson (publ) P2p streaming support
WO2013127423A1 (en) * 2012-02-27 2013-09-06 Telefonaktiebolaget L M Ericsson (Publ) Apparatus and method for streaming content
EP2741471A1 (en) * 2012-12-07 2014-06-11 Alcatel Lucent Method, system and devices for content caching and delivering in IP networks
CN105409183B (zh) * 2013-08-23 2018-11-16 华为技术有限公司 用于在html5应用中实现任何网络功能客户端或服务器的系统和设备
JP2015170323A (ja) * 2014-03-10 2015-09-28 株式会社東芝 配信装置、及び配信方法
US9414095B1 (en) * 2015-04-10 2016-08-09 Ses S.A. Linear video distribution methods, systems, and devices
CN106412701A (zh) * 2015-07-23 2017-02-15 株式会社Ntt都科摩 视频传输方法、接入设备和网络设备
US9848317B2 (en) * 2015-11-25 2017-12-19 Viasat, Inc. Multicast handover for mobile communications
JP6177957B1 (ja) 2016-03-29 2017-08-09 西日本電信電話株式会社 マルチキャスト用コントロールサーバ及びマルチキャスト制御システム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006303965A (ja) * 2005-04-21 2006-11-02 Kddi Corp コンテンツ伝送装置
JP2008092239A (ja) * 2006-10-02 2008-04-17 Mitsubishi Electric Corp マルチキャスト通信を用いた映像配信システム
US20130007825A1 (en) * 2007-06-04 2013-01-03 At&T Intellectual Property L, L.P. System and Method of Delivering Video Content
JP2019075741A (ja) * 2017-10-18 2019-05-16 日本電信電話株式会社 トラヒック変換方法、配信システム、ユニキャスト・マルチキャスト変換装置、マルチキャスト・ユニキャスト変換装置、ユニキャスト・マルチキャスト変換プログラム、及びマルチキャスト・ユニキャスト変換プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
OKUYAMA, TAKAFUMI ET AL.: "High definition and high reality CDN technology, Real-time large-capacity distribution technology", NTT GIJUTSU JOURNAL, vol. 30, no. 6, 1 June 2018 (2018-06-01), pages 64 - 67 *

Also Published As

Publication number Publication date
US11882340B2 (en) 2024-01-23
US20220295155A1 (en) 2022-09-15
JP7473025B2 (ja) 2024-04-23
JP2023033600A (ja) 2023-03-10
JPWO2021005756A1 (ja) 2021-01-14
JP7298688B2 (ja) 2023-06-27

Similar Documents

Publication Publication Date Title
US8762535B2 (en) Managing TCP anycast requests
US7450580B2 (en) Application layer multicast system and intermediate node therefor
JP3942033B2 (ja) ポイントツーポイントパケット交換向きのネットワークにおけるマルチキャスト方法
US9191459B2 (en) Method and apparatus for seamless mobility techniques in content-centric network
US10200747B2 (en) Computer network providing redundant data traffic control features and related methods
CN103166959B (zh) 一种多径实时传输控制系统及方法
JP2008079175A (ja) フレーム転送システム
JP2004140539A (ja) 情報ルーティング方式および情報中継装置
KR20100057828A (ko) 무선 메시 네트워크들에서의 콘텐츠 서비스들에 관한 통합된 피어-투-피어 및 캐시 시스템
WO2007033363A2 (en) System and method for providing packet connectivity between heterogeneous networks
JP2005159430A (ja) パケット配信方法、情報中継装置及びネットワークシステム
JP2005027243A (ja) ディジタル・コンテンツ配信システム、ディジタル・コンテンツ配信方法、そのためのサーバ、クライアント、サーバとしてコンピュータを制御するためのコンピュータ実行可能なプログラムおよびクライアントとしてコンピュータを制御するためのコンピュータ実行可能なプログラム
JP4476839B2 (ja) データ配信システム、中継装置、データ配信方法
JP7473025B2 (ja) コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム
US20050074010A1 (en) Method and apparatus for exchanging routing information in distributed router system
JP5373969B2 (ja) ネットワークにおける進行中のデータ配信時のセッション切り換え
JP4063786B2 (ja) マルチキャストパケット配信システム
JP7298690B2 (ja) コンテンツ配信システム、マルチキャストユニキャスト／マルチキャストマルチキャスト変換装置、マルチキャストユニキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム
JP2004297180A (ja) マルチキャスト配送システム及び方法
Nugraha et al. Multicast communication for video broadcasting service over IPv4 network using IP option
JP2006121593A (ja) サーバ装置、データ配信方法およびプログラム
KR20070078755A (ko) 대용량 콘텐츠 전송을 위한 네트워크 제어시스템
Nugraha et al. Multicast communication for scalable video application using IP option
WO2006085377A1 (ja) データ配信方法及び端末
KR20080052336A (ko) 경로 기반 시그널링을 지원하는 가입자망과 ｍｐｌｓｌｓｐ 기반 전달망에서의 시그널링 메시지 처리 방법

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: 19936932

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021530431

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19936932

Country of ref document: EP

Kind code of ref document: A1