WO2010050022A1 - 配信システム、代理サーバおよび配信方法 - Google Patents

配信システム、代理サーバおよび配信方法 Download PDF

Info

Publication number
WO2010050022A1
WO2010050022A1 PCT/JP2008/069688 JP2008069688W WO2010050022A1 WO 2010050022 A1 WO2010050022 A1 WO 2010050022A1 JP 2008069688 W JP2008069688 W JP 2008069688W WO 2010050022 A1 WO2010050022 A1 WO 2010050022A1
Authority
WO
WIPO (PCT)
Prior art keywords
viewing
distribution
sip server
multicast
content
Prior art date
Application number
PCT/JP2008/069688
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 JP2010535562A priority Critical patent/JPWO2010050022A1/ja
Priority to PCT/JP2008/069688 priority patent/WO2010050022A1/ja
Publication of WO2010050022A1 publication Critical patent/WO2010050022A1/ja
Priority to US13/085,943 priority patent/US20110191404A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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/80—Responding to QoS

Definitions

  • the present invention relates to a distribution system, a proxy server, and a distribution method for distributing content to terminals.
  • a server for example, a content folder or a key station
  • a distribution source of content distribution distributes content to a plurality of terminals (for example, viewer terminals).
  • a content distribution technique multicast transmission of content by IPTV (Internet Protocol Television) broadcasting is performed (see Patent Document 1).
  • IPTV broadcasting a communication path between a content folder and a viewer terminal is set, and multicast distribution of content is performed according to the set path (see Patent Document 2).
  • multicast distribution a technique for stopping distribution when a viewer terminal on the receiving side does not exist is used (see Patent Document 3).
  • an object of the present invention is to prevent the communication band from being occupied by useless packets and improve the quality of the communication service.
  • this system determines whether the number of distribution requests for requesting distribution from terminals in the distribution area is equal to or greater than a predetermined threshold, and the number of distribution requests is predetermined. If it is determined that the number is equal to or greater than the threshold, multicast transmission is performed. If it is determined that the number of distribution requests is smaller than the predetermined threshold, unicast transmission is controlled.
  • the disclosed system prevents communication bandwidth from being occupied by useless packets and improves the quality of communication services.
  • FIG. 1 shows an example of a network configuration that relays IPTV broadcasts.
  • FIG. 2 is an example of forming a multicast distribution route.
  • FIG. 3 is a block diagram illustrating the configuration of the SIP server according to the first embodiment.
  • FIG. 4 is a data configuration example of a viewing request.
  • FIG. 5 is a data configuration example of the viewing request response #U.
  • FIG. 6 is a data configuration example of the viewing request response #M.
  • FIG. 7 is a data configuration example of viewing port change #U.
  • FIG. 8 is a data configuration example of viewing port change #M.
  • FIG. 9 is a data configuration example of a viewing port change #U response.
  • FIG. 10 is a data configuration example of the viewing port change #M response.
  • FIG. 11 is a data configuration example of viewing termination.
  • FIG. 4 is a data configuration example of a viewing request.
  • FIG. 5 is a data configuration example of the viewing request response #U.
  • FIG. 6 is a data
  • FIG. 12 is a data configuration example of viewing termination.
  • FIG. 13 is a diagram illustrating a data configuration example of content distribution management information.
  • FIG. 14 is a diagram for explaining an example of the connection threshold.
  • FIG. 15 is a diagram illustrating an example of a multicast reachable area address list.
  • FIG. 16 is a diagram for explaining the transition of the transmission destination address conversion table.
  • FIG. 17 is a diagram for explaining the transition of the transmission destination address conversion table.
  • FIG. 18 is a diagram for explaining the transition of the transmission destination address conversion table.
  • FIG. 19 is a diagram for explaining the transition of the transmission destination address conversion table.
  • FIG. 20 is a diagram for explaining the transition of the transmission destination address conversion table.
  • FIG. 21 is a diagram for explaining the transition of the transmission destination address conversion table.
  • FIG. 22 is a diagram for explaining an example of connection between multicast domains by the boundary device.
  • FIG. 23 is a diagram for explaining an example of connection between multicast domains by the boundary device.
  • FIG. 24 is a diagram for explaining an example of connection between multicast domains by the boundary device.
  • FIG. 25 is a sequence diagram for forming a multicast route between the viewer and the content folder when the first viewer issues a viewing request.
  • FIG. 26 is a sequence diagram of forming a multicast route between the viewer and the content folder when the viewer issues a viewing request when another viewer has already broadcasted from the desired content folder.
  • FIG. 27 is a sequence diagram of switching from unicast to multicast when it is determined that multicast distribution reduces network traffic over unicast distribution due to an increase in viewers in the multicast domain.
  • FIG. 28 is a sequence diagram of switching from multicast to unicast when it is determined that unicast distribution reduces network traffic rather than multicast distribution due to a decrease in viewers in the multicast domain.
  • FIG. 29 is a sequence diagram of switching from unicast to multicast when it is determined that multicast distribution reduces network traffic over unicast distribution due to an increase in viewers outside the multicast domain.
  • FIG. 30 is a sequence diagram of switching from multicast to unicast when it is determined that unicast distribution reduces network traffic rather than multicast distribution due to a decrease in viewers outside the multicast domain.
  • FIG. 31 is a sequence diagram when notifying the content folder of the end of viewing when the last viewer is a viewer in the multicast domain.
  • FIG. 32 is a sequence diagram when notifying the content folder of the end of viewing when the last viewer is a viewer in the multicast domain.
  • FIG. 33 is a flowchart illustrating the operation of the relay process of the viewing request in the SIP server 10 according to the first embodiment.
  • FIG. 34 is a flowchart illustrating the operation of the relay process of the viewing request response in the SIP server 10 according to the first embodiment.
  • FIG. 35 is a flowchart illustrating the operation of the viewing port change response reception process in the SIP server 10 according to the first embodiment.
  • FIG. 36 is a flowchart illustrating the operation of the relay process for viewing termination in the SIP server 10 according to the first embodiment.
  • FIG. 33 is a flowchart illustrating the operation of the relay process of the viewing request in the SIP server 10 according to the first embodiment.
  • FIG. 34 is a flowchart illustrating the operation of the relay process of the viewing request response in the SIP server 10 according to the first embodiment.
  • FIG. 35 is a flowchar
  • FIG. 37 is a flowchart illustrating the operation of the reception end reception process in the SIP server 10 according to the first embodiment.
  • FIG. 38 is a flowchart illustrating the operation of the viewing request relay process in the SIP server 10 according to the first embodiment.
  • FIG. 39 is a flowchart illustrating the operation of the relay process of the viewing request response in the SIP server 10 according to the first embodiment.
  • FIG. 40 is a flowchart illustrating the operation of the relay process for viewing termination in the SIP server 10 according to the first embodiment.
  • FIG. 41 is a flowchart illustrating the operation of the viewing port change reception process in the SIP server 10 according to the first embodiment.
  • FIG. 42 is a flowchart illustrating the operation of the viewing start request transmission process in the viewing device 40 according to the first embodiment.
  • FIG. 43 is a flowchart illustrating the operation of the viewing request response reception process in the viewing device 40 according to the first embodiment.
  • FIG. 44 is a flowchart illustrating an operation of a reception port change reception process in the viewing device 40 according to the first embodiment.
  • FIG. 45 is a flowchart illustrating the operation of relay processing for viewing termination in the viewing device 40 according to the first embodiment.
  • SYMBOLS 10 SIP server 11 Communication control part 12 Control part 12a Viewer number determination part 12b Transmission control part 13 Storage part 13a Content delivery management information storage part 13b Connection threshold value storage part 13c Multicast arrival area address list 20 Key station 30 Border apparatus 40 Viewing apparatus
  • FIG. 1 shows an example of a network configuration that relays IPTV broadcasts.
  • FIG. 2 is an example of forming a multicast distribution route.
  • FIG. 3 is a block diagram illustrating the configuration of the SIP server according to the first embodiment.
  • FIG. 4 is a data configuration example of a viewing request.
  • FIG. 5 is a data configuration example of the viewing request response #U.
  • FIG. 6 is a data configuration example of the viewing request response #M.
  • FIG. 7 is a data configuration example of viewing port change #U.
  • FIG. 8 is a data configuration example of viewing port change #M.
  • FIG. 9 is a data configuration example of a viewing port change #U response.
  • FIG. 10 is a data configuration example of the viewing port change #M response.
  • FIG. 11 is a data configuration example of viewing termination.
  • FIG. 12 is a data configuration example of viewing termination.
  • FIG. 13 is a diagram illustrating a data configuration example of content distribution management information.
  • FIG. 14 is a diagram for explaining an example of the connection threshold.
  • the content distribution system includes a plurality of SIP servers 10A to 10D, a plurality of key stations (content folders) 20A and 20B, a plurality of boundary devices 30A to 30E, and a plurality of viewer terminals 40A and 40B. Connected via a network.
  • IPTV broadcast RTP packets are multicast distributed from the plurality of key stations 20A and 20B to the viewer apparatuses 40A and 40B connected to the network via the boundary apparatuses 30A to 30E.
  • a multicast distribution path is formed between the key station 20 and the viewer terminal 40 as shown in FIG. That is, in the content distribution system, the SIP server 10 receives a viewing request (indicated as “INVITE” in FIG. 2) issued by the viewer terminal 40, and the path formability between the multicast domains through which the SIP server 10 passes is determined according to the viewing request. Done.
  • a viewing request indicated as “INVITE” in FIG. 2
  • the SIP server 10 includes a communication control unit 11, a control unit 12, and a storage unit 13, and a key station (content folder) 20, a border device 30, a viewer terminal 40 and the like via a network. Connected. The processing of each of these units will be described below.
  • the communication control unit 11 controls communication related to various information exchanged with the connected key station 20, the boundary device 30, and the viewer terminal 40. Specifically, the communication control unit 11 receives a viewing request (see FIG. 4) that is a request for starting viewing from the viewer terminal 20, and receives a viewing request response that is a response to the viewing request (FIGS. 5 and 6). To the viewer terminal.
  • the communication control unit 11 transmits a viewing request response #U or a viewing request response #M as a viewing request response.
  • the communication control unit 11 receives the viewing exchange port #U and the viewing exchange port #U, and transmits the viewing exchange port #U response and the viewing exchange port #U response.
  • the communication control unit 11 receives the viewing end and transmits a viewing end response.
  • the storage unit 13 stores data and programs necessary for various processes performed by the control unit 12, and particularly includes a content distribution management information storage unit 13a, a connection threshold storage unit 13b, and a multicast reachable area address list 13c.
  • the content distribution management information storage unit 13a stores information for managing content distribution. Specifically, as shown in FIG. 13, the content distribution management information storage unit 13a, as content distribution management information, “connection state” indicating whether the connection state is waiting for a response or being connected, and the address of the key station 20 "Content distribution device address" is stored.
  • the content distribution management information storage unit 13a includes, as content distribution management information, a “reception type” indicating a unicast or unicast reception type, an “upstream content reception port” indicating a unicast communication port, "Upstream content receiving port” indicating the upstream port for multicast communication, "Distribution type” indicating the type of distribution by unicast or unicast, "Viewing device list” indicating information regarding the viewing device that is viewing the content, Multicast communication The “downstream content broadcast port” indicating the downstream port is stored.
  • the connection threshold storage unit 13b stores a threshold for determining whether to switch to multicast or unicast. Specifically, as shown in FIG. 14, the connection threshold storage unit 13b switches from “U2M threshold”, which is a threshold used when determining whether to switch from unicast to multicast, and from multicast to unicast. “M2U threshold value”, which is a threshold value used when determining whether or not, is stored.
  • the multicast reachable area address list 13c is a list for determining whether or not a multicast packet can be reached. Specifically, the multicast reachable area address list 13c stores an address list in the multi reachable area as shown in FIG. In other words, if the request is for viewing a content reception port that is not stored in the multicast reachable area address list 13c, unicast transmission is performed assuming that the view is from outside the multicast reachable area.
  • the control unit 12 includes an internal memory for storing a program that defines various processing procedures and necessary data, and executes various processes using these programs.
  • a program that defines various processing procedures and necessary data, and executes various processes using these programs.
  • the viewer number determination unit 12a the transmission control unit, and the like. 12b.
  • the viewer number determination unit 12a determines whether the number of distribution requests for requesting distribution from the viewer terminals 40 in the multicast domain is equal to or greater than a predetermined threshold. Specifically, the viewer number determination unit 12a determines whether or not the increased number of viewers is equal to or greater than the “U2M threshold” stored in the connection threshold storage unit 13b when a viewing request is received from the viewer device. To do.
  • the viewer number determination unit 12a determines whether the decreased number of viewers is smaller than the “M2U threshold value” stored in the connection threshold value storage unit 13b when receiving the end of viewing from the viewer device. Then, the viewer number determination unit 12a notifies the transmission control unit 12b of the determination result.
  • the transmission control unit 13b controls to perform multicast transmission when the number of distribution requests is equal to or greater than a predetermined threshold, and performs unicast transmission when the number of distribution requests is smaller than the predetermined threshold. Control to do.
  • the transmission control unit 12b controls to perform multicast transmission from unicast transmission.
  • the transmission control unit 12b controls to perform multicast transmission from unicast transmission.
  • the transmission control unit 12b assumes that distribution outside the multicast reachable area that is not stored in the multicast reachable area address list 13c is unicast transmission.
  • FIG. 16 is an example when the viewing request is received, and the number of views in the multicast domain to which the own device controls connection exceeds the “U2M threshold”.
  • the SIP server #B when the SIP server #B receives the viewing request and determines that the number of viewings in the multicast domain to which the own device controls connection exceeds the threshold, it notifies the boundary device #A of the multicast relay instruction. and, as a multicast address to the relay destination of the destination address conversion table: adding "I B IP # B".
  • the SIP server #B sequentially receives a unicast address (“I B : viewer A”) to the corresponding device with respect to the boundary device #A. : instructing to stop transmission of the "I B edge device B").
  • the SIP server #C instructs the boundary device 30B to start content reception at the multicast address specified by the viewing port change, and relays the destination address conversion table.
  • the original is changed to: "IP # B I B", "I B boundary apparatus B".
  • FIG. 17 is an example in which the end of viewing is received and the number of views in the multicast domain to which the own device controls connection is smaller than the “M2U threshold”.
  • the SIP server #B receives the end of viewing and determines that the number of views in the multicast domain to which the own device controls connection falls below the threshold value, the SIP server #B notifies the boundary device #A of a multicast relay instruction. Te, unicast address to the relay destination of the destination address translation table ( "I B: viewer a", "I B: edge device B”) Add.
  • the SIP server #B uses a multicast address (“I B : IP # B”) to the corresponding device to the boundary device #A. To stop sending
  • the SIP server #C instructs the boundary device 30B to start content reception at the multicast address specified by the viewing port change, and relays the destination address conversion table.
  • the original is changed to: "boundary apparatus B I B", "I B IP # B" a.
  • FIG. 18 shows the state of the transmission destination address conversion table when the viewing request is received and the number of viewers outside the multicast domain increases and exceeds the “U2M threshold”.
  • FIG. 11 shows the state of the destination address conversion table transition when the viewing end is received and the number of viewers outside the multicast domain decreases and becomes smaller than the “M2U threshold”.
  • FIG. 20 shows the state of the transmission destination address conversion table when the last viewer in the multicast domain finishes viewing.
  • FIG. 21 illustrates a state of the transmission destination address conversion table when a viewer outside the multicast domain finishes viewing. The detailed processing flow will be described in detail in the description of processing described later (FIGS. 25 to 45).
  • the boundary device 20 is applied to an environment where multicast packets from the upstream multicast domain reach the boundary device, and packets addressed to the multicast address #a from the multicast domain #A according to an instruction from the SIP server. Are transmitted to multicast domain #B as a packet addressed to multicast address #b.
  • FIG. 23 is an example applied to an environment where multicast packets from the upstream multicast domain cannot reach the boundary device.
  • the boundary device ⁇ unicasts the packet addressed to the multicast address #a from the multicast domain #A toward the boundary device ⁇ , and the boundary device ⁇ transmits the unicast transmitted packet to the multicast domain. Transmit to #B as a packet addressed to multicast address #b.
  • FIG. 24 is an example applied to an environment in which multicast packets from the upstream multicast domain reach the boundary device.
  • the boundary device ⁇ bounds a packet addressed to the multicast address #a from the multicast domain #A according to an instruction from the SIP server. Relay transmission is performed as it is toward the device ⁇ , and the boundary device ⁇ transmits the transmitted packet as a packet addressed to the multicast address #b into the multicast domain #B.
  • the source address is the address of the key station (multicast packet generator). In both boundary devices, the source address is not changed. A packet addressed to a multicast address not designated for relay is discarded.
  • FIG. 25 is a sequence diagram for forming a multicast route between the viewer and the content folder when the first viewer issues a viewing request.
  • FIG. 26 is a sequence diagram of forming a multicast route between the viewer and the content folder when the viewer issues a viewing request when another viewer has already broadcasted from the desired content folder.
  • FIG. 27 is a sequence diagram of switching from unicast to multicast when it is determined that multicast distribution reduces network traffic over unicast distribution due to an increase in viewers in the multicast domain.
  • FIG. 28 is a sequence diagram of switching from multicast to unicast when it is determined that unicast distribution reduces network traffic rather than multicast distribution due to a decrease in viewers in the multicast domain.
  • FIG. 29 is a sequence diagram of switching from unicast to multicast when it is determined that multicast distribution reduces network traffic over unicast distribution due to an increase in viewers outside the multicast domain.
  • FIG. 30 is a sequence diagram of switching from multicast to unicast when it is determined that unicast distribution reduces network traffic rather than multicast distribution due to a decrease in viewers outside the multicast domain.
  • FIG. 31 is a sequence diagram when notifying the content folder of the end of viewing when the last viewer is a viewer in the multicast domain.
  • FIG. 32 is a sequence diagram when notifying the content folder of the end of viewing when the last viewer is a viewer in the multicast domain.
  • the viewing terminal 40 transmits a viewing request addressed to the key station 40 (see FIG. 42).
  • the viewer terminal 40 transmits a viewing request to the SIP server 10C that manages connection control in the multicast domain to which the own terminal belongs (step S101). Then, the SIP server 10C transmits a viewing request to the SIP server 10B that manages connection control of adjacent multicast domains (step S102).
  • the SIP server 10B transmits the viewing request to the key station 20 via the viewing request (step S103) to the SIP server 10A that manages the connection control of the adjacent multicast domain (step S103).
  • the key station 20 starts broadcasting the content (step S105). Further, the key station 20 carries the IPTV broadcast address information in the viewing request response and returns it (step S106).
  • the SIP server 10A transmits the viewer request response to the SIP server 10B (step S107). Then, the SIP server 10B acquires the multicast address (step S108), and instructs the boundary device 30A to start relaying (step S109). The boundary device 30A starts relaying content into the multicast domain (step S110).
  • the SIP server 10B relays the viewer request response received from the SIP server 10A to the SIP server 10C (step S111). Similarly, the SIP server C acquires a multicast address (step S112), and instructs the boundary device 30B to start relaying (step S113).
  • Boundary device 30B starts relaying content into the multicast domain (step S114). Also, the SIP server 10C relays the viewer request response received from the SIP server 10B to the viewer device 40 (step S115). Thereafter, the viewer apparatus 40 completes establishment of a broadcast path with the key station 20 (see FIG. 43).
  • the viewing terminal 40 requests viewing when another viewer in the multicast domain is viewing will be described with reference to FIG.
  • the viewing terminal 40 transmits a viewing request addressed to the key station 40 (see FIG. 42).
  • the SIP server 10C that manages connection control in the multicast domain to which the viewing terminal 40 belongs receives a viewing request from the viewing terminal 40 (step S201). Then, the SIP server 10C relays the viewing request to the SIP server 10B to the key station 20 (step S202).
  • the SIP server 10B that has received the viewing request transmits a viewing request response to the viewing terminal 40 to the SIP server C (step S203). Further, the SIP server 10C acquires a multicast address (step S204), and instructs the boundary device 30B to start relaying (step S205).
  • the boundary device 30B starts relaying content in the multicast domain (step S206).
  • the SIP server 10C that has received the viewing request response from the SIP server 10B transmits the viewing request response to the viewer terminal 40 (step S207). Thereafter, the listener device 40 completes establishment of a broadcast path with the key station 20.
  • step S301 when the SIP server 10A performs multicast distribution (step S301) and the SIP server B is controlled to perform unicast distribution to the viewing terminals 40A and 40B (steps S302 and 303),
  • the viewing terminal 40B transmits the viewing request to the content folder by the operation of the viewer, the viewing request reaches the SIP server 10B (step S304).
  • the SIP server 10B When the SIP server 10B receives the viewing request and determines that the number of viewings in the multicast domain to which the own device controls connection exceeds the threshold value, the SIP server 10B transmits a viewing port change to all viewing terminals currently viewing ( (See FIG. 33).
  • the SIP server 10B instructs the boundary terminal 30A to start multicast distribution (step S305), and controls to perform multicast transmission (step S306). Further, the SIP server 10B returns a viewing request response to the viewing terminal 40B (step S307).
  • the viewing terminal 40B starts receiving the content at the multicast address specified in the viewing request response (step S314).
  • the viewing terminal 40A When viewing port change is received from the SIP server 10B (step S308), the viewing terminal 40A starts receiving content at the multicast address specified in the viewing request response, and returns the viewing port change response to the SIP server 10B. (Step S310).
  • the SIP server 10C instructs the boundary device 30B to start content reception at the multicast address designated by the viewing port change (step S311), and the viewing port change is performed.
  • the response is returned to the SIP server 10B (step S312).
  • the SIP server 10B sequentially instructs the boundary device to stop transmission with the unicast address to the corresponding device (step S313). Thereafter, the SIP server 10B controls to perform multicast distribution to the viewing terminals 40A and 40B (step S314).
  • the SIP server 10A performs multicast distribution (step S401), and the SIP server B is controlled to perform multicast distribution to the viewing terminals 40A and 40B and the boundary device 20B (step S402).
  • the SIP server 10B receives the viewing end (step S403) and returns a viewing end response (step S404).
  • the SIP server 10B When the SIP server 10B receives the end of viewing and determines that the number of views in the multicast domain to which the own device controls connection falls below the threshold, the SIP server 10B transmits a viewing port change to all viewing terminals that are currently viewing (FIG. 36). In addition, the SIP server 10B instructs the boundary terminal 30A to start unicast distribution (step S405), and controls to perform unicast transmission (step S406).
  • the viewing terminal 40A returns a viewing port change response (step S408), and receives the content at the unicast address specified by the viewing port change. Start (step S414).
  • the SIP server 10C instructs the boundary device 30B to start content reception at the unicast address specified by the viewing port change (step S410).
  • the change response is returned to the SIP server 10B (step S411).
  • the SIP server 10B sequentially instructs the boundary device to stop transmission with the multicast address to the corresponding device (step S412). Thereafter, the SIP server B controls to perform unitycast delivery to the viewing terminals 40A and 40B (steps S414 and S415).
  • step S501 when the SIP server 10A performs multicast distribution (step S501) and the SIP server B is controlled to perform unicast distribution to the viewing terminal 40A (step S502), the SIP server 40C
  • the viewing request transmitted to the content folder by the operation of the viewer outside the multicast domain is transmitted to the SIP server 10B (step S503).
  • the SIP server 10B transmits a viewing port change to all viewing terminals being viewed (see FIG. 33).
  • the SIP server 10B instructs the boundary terminal 30A to start multicast distribution (step S505) and controls to perform multicast transmission (step S506). In addition, the SIP server 10B returns a viewing request response to the SIP server 10C (step S507).
  • the SIP server 10C instructs the boundary device 20B to start relaying with the multicast address specified in the viewing request response (step S508).
  • the viewing terminal 40A When viewing port change is received from the SIP server 10B (step S509), the viewing terminal 40A starts receiving content at the multicast address specified in the viewing request response, and returns the viewing port change response to the SIP server 10B. (Step S510).
  • the SIP server 10B sequentially instructs the boundary device to stop transmission with the unicast address to the corresponding device (step S511). Thereafter, the SIP server B controls to perform multicast distribution to the viewing terminals in the multicast domain and the viewing terminals outside the multicast domain (step S512).
  • the SIP server 10A performs multicast distribution (step S601), and the SIP server B is controlled to perform multicast distribution to the viewing terminals 40A and 40B and the boundary device 20B (step S602). Then, the SIP server 10C transmits the viewing end transmitted to the content folder by the operation of the viewer outside the multicast domain to the SIP server 10B (step S603).
  • the SIP server 10B receives the viewing end and returns a viewing end response to the SIP server 10C (step S604).
  • the SIP server 10C that has received the viewing end response instructs the boundary device 20B to stop relaying (step S605).
  • the SIP server 10B instructs the boundary terminal 30A to start unicast distribution (step S606).
  • the SIP server 10B receives the end of viewing and determines that the number of views has fallen below the threshold, the viewing port change is transmitted to all viewing terminals being viewed (step S607), and unicast transmission is performed. Control is performed (step S608).
  • step S607 when the viewing port change is received from the SIP server 10B (step S607), the viewing terminal 40A returns a viewing port change response (step S609), and receives the content at the unicast address specified by the viewing port change. Start (step S612).
  • the SIP server 10B instructs the boundary device to stop transmission with the multicast address to the corresponding device (step S610), and returns the multicast address (step S610). S611). Thereafter, the SIP server 10B controls to perform unitycast delivery to the viewing terminal 40A (step S612).
  • the SIP server 10A performs multicast distribution (step S701), and the SIP server B is controlled to perform unicast distribution to the viewing terminal 40A (step S702).
  • the SIP server 10B When the SIP server 10B receives the end of viewing from the viewing terminal 40A (step S703), the SIP server 10B determines that the number of views in the multicast domain has disappeared, and instructs the boundary device 20A to stop the distribution of the IPTV broadcast (step S704).
  • the SIP server 10B transmits a viewing end to the SIP server 10A (step S705).
  • the SIP server 10A transmits a viewing end response to the SIP server (step S706).
  • the SIP server 10B transmits the received viewing end response to the viewer terminal 40A (step S707).
  • the SIP server 10A transmits a viewing end to the key station 20, and upon receiving the viewing end, the key station 20 stops the distribution of the IPTV broadcast and transmits a viewing end response to the SIP server 10A.
  • the SIP server 10A performs multicast distribution (step S801), and the SIP server B is controlled to perform unicast distribution to the boundary device 30B (step S802).
  • the SIP server 10B When the SIP server 10B receives the end of viewing from the viewer terminal outside the multicast domain via the SIP server 10C (step S803), the SIP server 10B determines that the number of views in the multicast domain has disappeared and distributes the IPTV broadcast to the boundary device 20A. A stop is instructed (step S804).
  • the SIP server 10B transmits an end of viewing to the SIP server 10A (step S805).
  • the SIP server 10A transmits a viewing end response to the SIP server 10B (step S806).
  • the SIP server 10B transmits the received viewing end response to the viewer terminal outside the multicast domain via the SIP server 10C (step S807).
  • the SIP server 10A transmits a viewing end to the key station 20, and upon receiving the viewing end, the key station 20 stops the distribution of the IPTV broadcast and transmits a viewing end response to the SIP server 10A.
  • FIG. 33 is a flowchart illustrating the operation of the relay process of the viewing request in the SIP server 10 according to the first embodiment.
  • FIG. 34 is a flowchart illustrating the operation of the relay process of the viewing request response in the SIP server 10 according to the first embodiment.
  • FIG. 35 is a flowchart illustrating the operation of the viewing port change response reception process in the SIP server 10 according to the first embodiment.
  • FIG. 36 is a flowchart illustrating the operation of the relay process for viewing termination in the SIP server 10 according to the first embodiment.
  • FIG. 37 is a flowchart illustrating the operation of the reception end reception process in the SIP server 10 according to the first embodiment.
  • FIG. 38 is a flowchart illustrating the operation of the viewing request relay process in the SIP server 10 according to the first embodiment.
  • the SIP server 10 when receiving a viewing request, the SIP server 10 extracts content distribution management information having the same content distribution device (key station) 20 address as the received viewing request to (step S1101), and distributes the content. It is determined whether there is management information (step S1102).
  • the SIP server 10 proceeds to S1108. In addition, when there is content distribution management information (Yes in step S1102), the SIP server 10 generates content distribution management information (step S1103), secures an upstream content reception port of the boundary device 30, and content distribution management information (Step S1104).
  • the SIP server 10 edits the viewing request (step S1105), relays the viewing request to the content distribution device 20 (step S1106), and sets the viewing device address and content reception port of the received viewing request as the content.
  • the distribution management information is stored in the viewing device list (step S1107).
  • the SIP server 10 determines whether or not the number of viewing devices is smaller than the U2M threshold (step S1108). As a result, when the number of viewing devices is smaller than the U2M threshold (Yes at Step S1108), the SIP server 10 starts receiving the port state corresponding to the viewing device of the received viewing request (Step S1109).
  • the SIP server 10 instructs the boundary device 30 to start relaying to the content reception port for receiving and viewing the RTP packet (step S1110), and determines whether the connection state is “connected” (step S1111).
  • connection state is “connected” (Yes at step S1111)
  • the SIP server 10 returns a viewing request response to the viewing device 40 (step S1112), and the connection state is not “connected”. If (No at step S1111), the process ends.
  • the SIP server 10 stops receiving the port state corresponding to the viewing device of the received viewing request (Step S1113), and distributes it. It is determined whether the type is “unicast” (step S1114).
  • the SIP server 10 secures a multicast address and stores it in the downstream content broadcast port of the content distribution management information (Step S1115). It is determined whether the connection state is “connected” (step S1116).
  • the SIP server 10 instructs the boundary device 30 to start relaying the RTP packet to the downstream broadcast content broadcast port (step S1119).
  • the SIP server 10 returns a viewing request response to the viewing device 40 (step S1117), to all the viewing devices 40 in the viewing device list.
  • the viewing port change is transmitted (step S1118), and the boundary device 30 is instructed to start relaying the RTP packet to the downstream broadcast content broadcast port (step S1119).
  • the SIP server 10 determines whether the connection state is “connected” (step S1120). As a result, when the connection state is “connected” (Yes at Step S1120), the SIP server 10 returns a viewing request response to the viewing device 40 (Step S1121). If the connection state is “waiting for response” (No at step S1120), the SIP server 10 ends the process.
  • FIG. 34 is a flowchart illustrating the operation of the relay process of the viewing request response in the SIP server 10 according to the first embodiment.
  • the SIP server 10 when receiving the viewing request response, the SIP server 10 extracts the content distribution management information of the received viewing request response (step S1201), and determines whether there is content distribution management information (step S1202). As a result, if there is no SIP server 10 and content distribution management information (No at step S1202), the process is terminated.
  • the SIP server 10 receives a viewing request response indicating that the received viewing request response receives content at a unicast address (hereinafter referred to as viewing request #U). Is determined (step S1203).
  • the SIP server 10 updates the content management information to unicast (Step S1204), and sends the upstream content to the boundary device 30.
  • An instruction is given to relay the RTP packet addressed to the reception port (step S1205).
  • the SIP server 10 updates the content distribution management information to multicast (Step S1207) and sends it to the boundary device 30 as an upstream content receiving port. An instruction is given to relay the destination RTP packet (step S1208).
  • the SIP server 10 determines whether the distribution type is unicast (step S1209), and when it is unicast (Yes in step S1209), returns the viewing request response #U to all devices in the viewing device list. (Step S1211).
  • the SIP server 10 sends a viewing request response (hereinafter referred to as viewing request #M) in the viewing device list to the effect that content is received at the multicast address. (Step S1210).
  • viewing request #M a viewing request response
  • FIG. 35 is a flowchart illustrating the operation of the viewing port change response reception process in the SIP server 10 according to the first embodiment.
  • the SIP server 10 when receiving the viewing port change response, the SIP server 10 extracts the content distribution management information of the received viewing port change response (step S1501), and determines whether there is content distribution management information (step S1502). ). As a result, if there is no SIP server 10 and content distribution management information (No at step S1502), the process is terminated.
  • the SIP server 10 changes a viewing port change response (hereinafter referred to as a viewing port) to change the received viewing port change response to content reception at a unicast address. It is determined whether it is a change response #U) (step S1503).
  • a viewing port change response hereinafter referred to as a viewing port
  • the SIP server 10 sets the port state corresponding to the viewing device in the received viewing port change response as reception start ( In step S1504), it is determined whether or not reception of ports corresponding to all viewing devices in the viewing device list is started (step S1505).
  • the SIP server 10 stops multicast transmission to the boundary device 30 at the downstream content broadcast port (multicast). Is instructed (step S1506). If the SIP server 10 does not start the port reception for all viewing devices in the viewing device list (No at step S1505), the SIP server 10 ends the process.
  • the SIP server 10 stops receiving the port state corresponding to the viewing device in the received viewing port change response (step S1507). ) Instructs the boundary device 30 to stop the unicast transmission of the received viewing request response to the viewing device (step S1508).
  • FIG. 36 is a flowchart illustrating the operation of the relay process for viewing termination in the SIP server 10 according to the first embodiment.
  • the SIP server 10 when receiving the end of viewing, extracts content distribution management information having content distribution having the same content distribution apparatus address as the received “to” at the end of viewing (step S1701). It is determined whether there is distribution management information (step S1702).
  • the SIP server 10 If there is no content management information (No at Step S1702), the SIP server 10 returns a viewing end response to the viewing device 40 (Step S1706) and ends the process.
  • the SIP server 10 instructs the boundary device 30 to stop relaying to the content reception port of the received viewing device 40 at the end of viewing (step S1703).
  • the viewing device address and the content reception port of the viewing end are deleted from the viewing device list of the content distribution management information (step S1704).
  • the SIP server 10 determines whether or not the number of viewing devices is larger than the M2U threshold (step S1705), and if so (Yes in step S1705), returns a viewing end response to the viewing device 40 (step S1706), and performs processing. finish.
  • the SIP server 10 determines whether the distribution type is “unicast” (Step S1707). As a result, when the distribution type is “multicast” (No at Step S1707), the SIP server 10 secures the multicast address, stores it in the downstream content broadcast port of the content distribution management information (Step S1708), and views it. An end response is returned to the viewing device 40 (step S1709).
  • the SIP server 10 transmits the viewing port change #U to all the viewing devices 40 in the viewing device list (step S1710), and relays the RTP packet to the boundary device 30 to all content reception ports in the viewing device list.
  • the start is instructed (step S1711).
  • the SIP server 10 If the distribution type is “unicast” (Yes at Step S1707), the SIP server 10 returns a viewing end response to the viewing device 40 (Step S1712), and determines whether the viewing device list is “0”. (Step S1713). When the list is “0” (Yes at Step S1713), the SIP server 10 transmits an end of viewing to the content folder (Step S1714), and when the list is not “0” (No at Step S1713). The process is terminated as it is.
  • FIG. 37 is a flowchart illustrating the operation of the reception end reception process in the SIP server 10 according to the first embodiment.
  • the SIP server 10 when receiving the viewing end, deletes the content distribution management information corresponding to the viewing end response (step S1801).
  • FIG. 38 shows the operation of the viewing request relay process in the SIP server 10 according to the first embodiment, in which the multicast packet from the multicast domain where the SIP server manages the viewing connection does not reach the direct relay destination.
  • the SIP server 10 relays and transmits the viewing request to the content distribution apparatus (step S1906), and then receives the viewing request content receiving port. Is in the multicast reachable area address list (step S1907).
  • FIG. 39 shows the operation of relaying the viewing request response in the SIP server 10 according to the first embodiment, and the multicast packet from the multicast domain in which the SIP server manages the viewing connection does not reach the direct relay destination.
  • An example in the case where there is something that is, an example applied when there is a connection between multicast domains in the form illustrated in FIG. 23) is shown.
  • the SIP server 10 determines whether the distribution type is unicast, as in the viewing request response relay process shown in FIG. 34 (step S2008).
  • FIG. 40 illustrates the operation of the viewing end relay process in the SIP server 10 according to the first embodiment, in which the multicast packet from the multicast domain in which the SIP server manages the viewing connection does not reach the direct relay destination.
  • FIG. 39 illustrates an example of the operation of the receiving process of the viewing port change in the SIP server 10 according to the first embodiment.
  • the SIP server 10 when receiving the viewing port change, extracts the received content distribution management information corresponding to the viewing port change (step S2201), and determines whether there is content distribution management information (step S2202). .
  • the SIP server 10 ends the process as it is. If there is content management information (Yes at Step S2202), the SIP server 10 determines whether the received viewing port change is viewing port change #U (Step S2203).
  • the SIP server 10 updates the reception type of the content distribution management information to unicast (step S2204). Then, the SIP server 10 instructs the boundary device 30 to relay the upstream content reception port RTP packet (step S2205), and returns a viewing port change response #U (step S2206).
  • the SIP server 10 updates the reception type of the content distribution management information to multicast (step S2207). Then, the SIP server 10 instructs the border device 30 to relay the upstream content reception port RTP packet (step S2208), and returns a viewing port change response #M (step S2209).
  • FIG. 42 is a flowchart showing the operation of the viewing start request transmission process in the viewing device 40 according to the first embodiment.
  • FIG. 43 is a flowchart illustrating the operation of the viewing request response reception process in the viewing device 40 according to the first embodiment.
  • FIG. 44 is a flowchart illustrating an operation of a reception port change reception process in the viewing device 40 according to the first embodiment.
  • FIG. 45 is a flowchart illustrating the operation of relay processing for viewing termination in the viewing device 40 according to the first embodiment.
  • the viewing device 40 edits the viewing request (step S1001) and transmits the viewing request to the SIP server 10 (step S1002). Then, the viewing device 40 starts reproducing and displaying the content (RTP packet) addressed to the content reception port on the display (step S1003).
  • the viewing device 40 determines whether the received viewing request response is a viewing request response #U (step S1301).
  • the viewing device 40 updates the reception type of the content distribution management information to unicast (step S1302), and receives the content.
  • the content addressed to the port is reproduced and displayed on the display (step S1303).
  • the viewing device 40 updates the reception type of the content reception information to multicast (step S1304), and addresses the content broadcast port. The content is reproduced and displayed on the display (step S1305).
  • the viewing device 40 determines whether the received viewing port change is a viewing port change #U (step S1401).
  • the viewing device 40 updates the information type of the content distribution management information to unicast (step S1402). Then, the viewing device 40 starts reproducing and displaying the content addressed to the content reception port on the display (step S1403), and returns a viewing port change response (step S1404).
  • the viewing device 40 updates the information type of the content reception information to multicast (Step S1405). Then, the viewing device 40 starts reproducing and displaying the content addressed to the content reception port on the display (step S1406), and returns a viewing port change response #M (step S1407).
  • the viewing device 40 edits the viewing end (step S1601).
  • the viewing device 40 transmits a viewing end to the SIP server 10 (step S1602), and stops reproducing and displaying the content addressed to the content reception port on the display (step S1603).
  • the SIP server 10 determines whether or not the number of distribution requests for requesting distribution from terminals in the distribution area is equal to or greater than a predetermined threshold, and the number of distribution requests is equal to or greater than a predetermined threshold. If it is determined, control is performed so as to perform multicast transmission. If it is determined that the number of distribution requests is smaller than a predetermined threshold, unicast transmission is performed. For this reason, it is possible to prevent the communication band from being occupied by useless packets and improve the quality of the communication service.
  • control when distribution information is transmitted outside the distribution area, control is performed so that unicast transmission is performed. It is possible to improve the quality of service.
  • each component of each illustrated device is functionally conceptual and does not necessarily need to be physically configured as illustrated.
  • the specific form of distribution / integration of each device is not limited to that shown in the figure, and all or a part thereof may be functionally or physically distributed or arbitrarily distributed in arbitrary units according to various loads or usage conditions. Can be integrated and configured.
  • the viewer number determination unit 12a and the transmission control unit 12b may be integrated.
  • all or any part of each processing function performed in each device may be realized by a CPU and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic.
  • the content distribution method described in the present embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation.
  • This program can be distributed via a network such as the Internet.
  • the program can also be executed by being recorded on a computer-readable recording medium such as a hard disk, a flexible disk (FD), a CD-ROM, an MO, and a DVD and being read from the recording medium by the computer.
  • a computer-readable recording medium such as a hard disk, a flexible disk (FD), a CD-ROM, an MO, and a DVD and being read from the recording medium by the computer.

Landscapes

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

Abstract

　ＳＩＰサーバ（１０）は、視聴者装置から視聴要求を受信した場合に、増加した視聴者数が接続閾値記憶部（１３ｂ）に記憶されている「Ｕ２Ｍ閾値」以上であるか判定し、また、視聴者装置から視聴終了を受信した場合に、減少した視聴者数が「Ｍ２Ｕ閾値」より小さいか判定する。その結果、ＳＩＰサーバ（１０）は、配信要求の数が「Ｕ２Ｍ閾値」以上であると判定された場合には、マルチキャスト送信するように制御し、また、配信要求の数が「Ｍ２Ｕ閾値」より小さいと判定された場合には、ユニキャスト送信するように制御する。

Description

配信システム、代理サーバおよび配信方法
　この発明は、コンテンツを端末に配信する配信システム、代理サーバおよび配信方法に関する。
　従来より、コンテンツ配信の配信元であるサーバ（例えば、コンテンツフォルダ、キー局）が、複数の端末（例えば、視聴者端末）にコンテンツを配信する技術が知られている。例えば、コンテンツ配信技術として、ＩＰＴＶ（Internet　Protocol　Television）放送によるコンテンツのマルチキャスト送信が実施されている（特許文献１参照）。
　ＩＰＴＶ放送では、コンテンツフォルダと視聴者端末との間の通信経路を設定し、設定された経路にしたがって、コンテンツのマルチキャスト配信が行われる（特許文献２参照）。また、このようなマルチキャスト配信において、受信側の視聴者端末が存在しない場合には、配信を停止する技術が利用されている（特許文献３参照）。
特開２００７－６８１２９号公報 特開２００２－６４５５８号公報 特開２００４－２２８９６８号公報
　ところで、上記のコンテンツを配信する技術では、視聴者数が少ない場合でも、マルチキャスト配信でパケット送信を行うので、無駄なパケットによる通信帯域の占有が中継網内で発生し、通信サービスの品質を阻害するという課題があった。
　そこで、この発明は、無駄なパケットによる通信帯域の占有を防止し、通信サービスの品質を向上することを目的とする。
　上述した課題を解決し、目的を達成するため、このシステムは、配信領域内における端末からの配信を要求する配信要求の数が所定の閾値以上であるかを判定し、配信要求の数が所定の閾値以上であると判定された場合には、マルチキャスト送信するように制御し、また、配信要求の数が所定の閾値より小さいと判定された場合には、ユニキャスト送信するように制御する。
　開示のシステムは、無駄なパケットによる通信帯域の占有を防止し、通信サービスの品質を向上する。
図１は、ＩＰＴＶ放送の中継を行うネットワーク構成例である。 図２は、マルチキャスト配信経路を形成する例である。 図３は、実施例１に係るＳＩＰサーバの構成を示すブロック図である。 図４は、視聴要求のデータ構成例である。 図５は、視聴要求応答＃Ｕのデータ構成例である。 図６は、視聴要求応答＃Ｍのデータ構成例である。 図７は、視聴ポート変更＃Ｕのデータ構成例である。 図８は、視聴ポート変更＃Ｍのデータ構成例である。 図９は、視聴ポート変更＃Ｕ応答のデータ構成例である。 図１０は、視聴ポート変更＃Ｍ応答のデータ構成例である。 図１１は、視聴終了のデータ構成例である。 図１２は、視聴終了のデータ構成例である。 図１３は、コンテンツ配信管理情報のデータ構成例を示す図である。 図１４は、接続閾値の例を説明するための図である。 図１５は、マルチキャスト到達区域内アドレスリストの例を示す図である。 図１６は、送信先アドレス変換テーブルの遷移を説明するための図である。 図１７は、送信先アドレス変換テーブルの遷移を説明するための図である。 図１８は、送信先アドレス変換テーブルの遷移を説明するための図である。 図１９は、送信先アドレス変換テーブルの遷移を説明するための図である。 図２０は、送信先アドレス変換テーブルの遷移を説明するための図である。 図２１は、送信先アドレス変換テーブルの遷移を説明するための図である。 図２２は、境界装置によるマルチキャストドメイン間の接続例を説明するための図である。 図２３は、境界装置によるマルチキャストドメイン間の接続例を説明するための図である。 図２４は、境界装置によるマルチキャストドメイン間の接続例を説明するための図である。 図２５は、最初の視聴者が視聴要求を発したときの視聴者とコンテンツフォルダ間のマルチキャスト経路形成のシーケンス図である。 図２６は、所望のコンテンツフォルダからの放送を他の視聴者がすでに行っている場合の視聴者が視聴要求を発したときの視聴者とコンテンツフォルダ間のマルチキャスト経路形成のシーケンス図である。 図２７は、マルチキャストドメイン内の視聴者の増加により、ユニキャスト配信よりマルチキャスト配信がネットワークのトラヒックを低減すると判断した場合のユニキャストからマルチキャストへの切り換えシーケンス図である。 図２８は、マルチキャストドメイン内の視聴者の減少により、マルチキャスト配信よりユニキャスト配信がネットワークのトラヒックを低減すると判断した場合のマルチキャストからユニキャストへの切り換えシーケンス図である。 図２９は、マルチキャストドメイン外の視聴者の増加により、ユニキャスト配信よりマルチキャスト配信がネットワークのトラヒックを低減すると判断した場合のユニキャストからマルチキャストへの切り換えシーケンス図である。 図３０は、マルチキャストドメイン外の視聴者の減少により，マルチキャスト配信よりユニキャスト配信がネットワークのトラヒックを低減すると判断した場合のマルチキャストからユニキャストへの切り換えシーケンス図である。 図３１は、最後の視聴者がマルチキャストドメイン内の視聴者であった場合の視聴終了をコンテンツフォルダへ通知する場合のシーケンス図である。 図３２は、最後の視聴者がマルチキャストドメイン内の視聴者であった場合の視聴終了をコンテンツフォルダへ通知する場合のシーケンス図である。 図３３は、実施例１に係るＳＩＰサーバ１０における視聴要求の中継処理の動作を示すフローチャートである。 図３４は、実施例１に係るＳＩＰサーバ１０における視聴要求応答の中継処理の動作を示すフローチャートである。 図３５は、実施例１に係るＳＩＰサーバ１０における視聴ポート変更応答の受信処理の動作を示すフローチャートである。 図３６は、実施例１に係るＳＩＰサーバ１０における視聴終了の中継処理の動作を示すフローチャートである。 図３７は、実施例１に係るＳＩＰサーバ１０における視聴終了の受信処理の動作を示すフローチャートである。 図３８は、実施例１に係るＳＩＰサーバ１０における視聴要求の中継処理の動作を示すフローチャートである。 図３９は、実施例１に係るＳＩＰサーバ１０における視聴要求応答の中継処理の動作を示すフローチャートである。 図４０は、実施例１に係るＳＩＰサーバ１０における視聴終了の中継処理の動作を示すフローチャートである。 図４１は、実施例１に係るＳＩＰサーバ１０における視聴ポート変更の受信処理の動作を示すフローチャートである。 図４２は、実施例１に係る視聴装置４０における視聴開始要求送信処理の動作を示すフローチャートである。 図４３は、実施例１に係る視聴装置４０における視聴要求応答の受信処理の動作を示すフローチャートである。 図４４は、実施例１に係る視聴装置４０における視聴ポート変更の受信処理の動作を示すフローチャートである。 図４５は、実施例１に係る視聴装置４０における視聴終了の中継処理の動作を示すフローチャートである。
符号の説明
　１０　ＳＩＰサーバ
　１１　通信制御部
　１２　制御部
　１２ａ　視聴者数判定部
　１２ｂ　送信制御部
　１３　記憶部
　１３ａ　コンテンツ配信管理情報記憶部
　１３ｂ　接続閾値記憶部
　１３ｃ　マルチキャスト到達区域内アドレスリスト
　２０　キー局
　３０　境界装置
　４０　視聴装置
　以下に添付図面を参照して、この発明に係る配信システム、代理サーバおよび配信方法の実施例を詳細に説明する。
　以下の実施例では、実施例１に係るコンテンツ配信システム、ＳＩＰサーバの構成および処理の流れを順に説明し、最後に実施例１による効果を説明する。
［ＳＩＰサーバの構成］
　まず最初に、図１を用いて、コンテンツ配信システムおよびＳＩＰサーバ１０の構成を説明する。図１は、ＩＰＴＶ放送の中継を行うネットワーク構成例である。図２は、マルチキャスト配信経路を形成する例である。図３は、実施例１に係るＳＩＰサーバの構成を示すブロック図である。図４は、視聴要求のデータ構成例である。図５は、視聴要求応答＃Ｕのデータ構成例である。図６は、視聴要求応答＃Ｍのデータ構成例である。
　図７は、視聴ポート変更＃Ｕのデータ構成例である。図８は、視聴ポート変更＃Ｍのデータ構成例である。図９は、視聴ポート変更＃Ｕ応答のデータ構成例である。図１０は、視聴ポート変更＃Ｍ応答のデータ構成例である。図１１は、視聴終了のデータ構成例である。図１２は、視聴終了のデータ構成例である。
　図１３は、コンテンツ配信管理情報のデータ構成例を示す図である。図１４は、接続閾値の例を説明するための図である。図１５は、マルチキャスト到達区域内アドレスリストの例を示す図である。図１６～図２１は、送信先アドレス変換テーブルの遷移を説明するための図である。図２２～図２４は、境界装置によるマルチキャストドメイン間の接続例を説明するための図である。
　まず、図１を用いて、実施例１に係るＳＩＰサーバ１０を含むコンテンツ配信システムについて説明する。同図に例示するようにコンテンツ配信システムは、複数のＳＩＰサーバ１０Ａ～１０Ｄ、複数のキー局（コンテンツフォルダ）２０Ａ、２０Ｂ、複数の境界装置３０Ａ～３０Ｅ、複数の視聴者端末４０Ａ、４０Ｂを有し、ネットワークを介して接続される。
　かかるコンテンツ配信システムでは、複数のキー局２０Ａ、２０Ｂからネットワークに接続された視聴者装置４０Ａ、４０Ｂへ境界装置３０Ａ～３０Ｅを介してＩＰＴＶ放送のＲＴＰパケットがマルチキャスト配信されている。
　また、コンテンツ配信システムでは、図２に示すように、キー局２０と視聴者端末４０との間でマルチキャスト配信経路が形成される。つまり、コンテンツ配信システムでは、視聴者端末４０が発した視聴要求（図の２では、「ＩＮＶＩＴＥ」と記載）をＳＩＰサーバ１０が受信し、視聴要求に従い、経由するマルチキャストドメイン間で経路形性が行われる。
　続いて、図３を用いて、図１に示したＳＩＰサーバ１０の構成を説明する。同図に示すように、このＳＩＰサーバ１０は、通信制御部１１、制御部１２、記憶部１３を有し、ネットワークを介してキー局（コンテンツフォルダ）２０、境界装置３０、視聴者端末４０と接続される。以下にこれらの各部の処理を説明する。
　通信制御部１１は、接続されるキー局２０、境界装置３０、視聴者端末４０との間でやり取りする各種情報に関する通信を制御する。具体的には、通信制御部１１は、視聴者端末２０からの視聴開始の要求である視聴要求（図４参照）を受信し、視聴要求の応答である視聴要求応答（図５、図６）を視聴者端末に送信する。
　視聴要求は、図４に示すように、視聴要求先のキー局２０のアドレス「ｔｏ＝コンテンツ配信装置アドレス」、要求元の視聴装置２０のアドレス「ｆｒｏｍ＝視聴者装置アドレス」とともに、ユニキャスト配信のコンテンツを受信するポートを示す「ｓｄｐ　ｉｎ＝コンテンツ受信ポート」とを情報として有する。
　また、通信制御部１１は、視聴要求応答として、視聴要求応答＃Ｕまたは視聴要求応答＃Ｍを送信する。視聴要求応答＃Ｕは、図５に示すように、キー局２０のアドレスとして「ｔｏ＝コンテンツ配信装置アドレス」、視聴装置２０のアドレスとして「ｆｒｏｍ＝視聴者装置アドレス」とともに、ユニキャスト配信のコンテンツを受信するポートを示す「ｓｄｐ　ｉｎ＝コンテンツ受信ポート」とを情報として有する。
　また、視聴要求応答＃Ｍは、図６に示すように、「ｔｏ＝コンテンツ配信装置アドレス」、「ｆｒｏｍ＝視聴者装置アドレス」とともに、マルチキャスト配信のコンテンツを受信するポートを示す「ｓｄｐｏｕｔ＝下流コンテンツ放送ポート」とを情報として有する。
　また、通信制御部１１は、視聴交換ポート＃Ｕをおよび視聴交換ポート＃Ｕを受信し、視聴交換ポート＃Ｕ応答をおよび視聴交換ポート＃Ｕ応答を送信する。視聴交換ポート＃Ｕは、図７に示すように、「ｔｏ＝視聴者装置アドレス」、「ｆｒｏｍ＝コンテンツ配信装置アドレス」とともに、視聴装置４０におけるコンテンツ受信ポートの変更を指示する「ｓｄｐ　ｉｎ＝コンテンツ受信ポート」とを情報として有する。
　また、視聴交換ポート＃Ｍは、図８に示すように、「ｔｏ＝視聴者装置アドレス」、「ｆｒｏｍ＝コンテンツ配信装置アドレス」とともに、視聴装置４０のコンテンツ受信ポートを変更を指示する「ｓｄｐ　ｏｕｔ＝下流コンテンツ放送ポート」とを情報として有する。
　視聴交換ポート＃Ｕは、図９に示すように、「ｔｏ＝コンテンツ配信装置アドレス」、「ｆｒｏｍ＝視聴者装置アドレス」とともに、視聴装置４０のコンテンツ受信ポートの変更を指示する「ｓｄｐ　ｉｎ＝コンテンツ受信ポート」とを情報として有する。
　また、視聴交換ポート＃Ｍは、図１０に示すように、「ｔｏ＝コンテンツ配信装置アドレス」、「ｆｒｏｍ＝視聴者装置アドレス」とともに、視聴装置４０のコンテンツ受信ポートの変更を指示する「ｓｄｐ　ｏｕｔ＝下流コンテンツ放送ポート」とを情報として有する。
　また、通信制御部１１は、視聴終了を受信し、視聴終了応答を送信する。視聴終了および視聴終了応答は、図１１および図１２に示すように、「ｔｏ＝コンテンツ配信装置アドレス」、「ｆｒｏｍ＝視聴者装置アドレス」の視聴が終了する旨を示している。
　記憶部１３は、制御部１２による各種処理に必要なデータおよびプログラムを格納するが、特に、コンテンツ配信管理情報記憶部１３ａ、接続閾値記憶部１３ｂ、マルチキャスト到達区域内アドレスリスト１３ｃを有する。
　コンテンツ配信管理情報記憶部１３ａは、コンテンツの配信を管理する情報を記憶する。具体的には、コンテンツ配信管理情報記憶部１３ａは、図１３に示すように、コンテンツ配信管理情報として、接続状態が応答待ちまたは接続中であるかを示す「接続状態」、キー局２０のアドレスとして「コンテンツ配信装置アドレス」を記憶する。
　また、コンテンツ配信管理情報記憶部１３ａは、コンテンツ配信管理情報として、ユニキャストまたはユニキャストでの受信する種別を示す「受信種別」、ユニキャストの通信用のポートを示す「上流コンテンツ受信ポート」、マルチキャスト通信用の上流ポートを示す「上流コンテンツ受信ポート」、ユニキャストまたはユニキャストで配信する種別を示す「配信種別」、コンテンツを視聴中の視聴装置に関する情報を示す「視聴装置リスト」、マルチキャスト通信用の下流ポートを示す「下流コンテンツ放送ポート」を記憶する。
　接続閾値記憶部１３ｂは、マルチキャストまたはユニキャストに切り替えるか否か判定するための閾値を記憶する。具体的には、接続閾値記憶部１３ｂは、図１４に示すように、ユニキャストからマルチキャストに切り替えるか否かを判断する場合に用いられる閾値である「Ｕ２Ｍ閾値」と、マルチキャストからユニキャストに切り替えるか否かを判断する場合に用いられる閾値である「Ｍ２Ｕ閾値」とを記憶する。
　マルチキャスト到達区域内アドレスリスト１３ｃは、マルチキャストパケットの到達可否を判断するリストである。具体的には、マルチキャスト到達区域内アドレスリスト１３ｃは、図１５に示すように、マルチ到達区域内のアドレスリストを記憶している。つまり、マルチキャスト到達区域内アドレスリスト１３ｃに記憶されていないコンテンツ受信ポートの視聴要求である場合には、マルチキャスト到達区域外からの視聴であるとしてユニキャスト送信する。
　制御部１２は、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行するが、特に、視聴者数判定部１２ａ、送信制御部１２ｂを有する。
　視聴者数判定部１２ａは、マルチキャストドメイン内における視聴者端末４０からの配信を要求する配信要求の数が所定の閾値以上であるかを判定する。具体的には、視聴者数判定部１２ａは、視聴者装置から視聴要求を受信した場合に、増加した視聴者数が接続閾値記憶部１３ｂに記憶されている「Ｕ２Ｍ閾値」以上であるか判定する。
　また、視聴者数判定部１２ａは、視聴者装置から視聴終了を受信した場合に、減少した視聴者数が接続閾値記憶部１３ｂに記憶されている「Ｍ２Ｕ閾値」より小さいか判定する。そして、視聴者数判定部１２ａは、判定の結果を送信制御部１２ｂに通知する。
　送信制御部１３ｂは、配信要求の数が所定の閾値以上である場合には、マルチキャスト送信を行うように制御し、また、配信要求の数が所定の閾値より小さい場合には、ユニキャスト送信を行うように制御する。
　具体的には、送信制御部１２ｂは、視聴者数が「Ｕ２Ｍ閾値」以上である旨の判定結果を視聴者数判定部１２ａから受信すると、ユニキャスト送信からマルチキャスト送信を行うように制御する。また、送信制御部１２ｂは、視聴者数が「Ｍ２Ｕ閾値」より小さい旨の判定結果を視聴者数判定部１２ａから受信すると、ユニキャスト送信からマルチキャスト送信を行うように制御する。
　また、送信制御部１２ｂは、マルチキャスト到達区域内アドレスリスト１３ｃに記憶されていないマルチキャスト到達区域外への配信は、ユニキャストでの送信とする。
　ここで図１６～図２１の例を用いて、送信制御処理として、境界装置３０の送信先アドレス変換テーブルを変更する処理について説明する。図１６の例は、視聴要求を受信し、自機が接続制御するマルチキャストドメイン内の視聴数が「Ｕ２Ｍ閾値」を超過した場合の例である。
　同図に示すように、ＳＩＰサーバ＃Ｂは、視聴要求を受信し、自機が接続制御するマルチキャストドメイン内の視聴数が閾値を超過したと判定すると、マルチキャスト中継指示を境界装置＃Ａに通知して、送信先アドレス変換テーブルの中継先にマルチキャストアドレスとして「ＩＢ：ＩＰ＃Ｂ」を追加する。
　そして、ＳＩＰサーバ＃Ｂは、視聴端末＃Ａ、ＳＩＰサーバ＃Ｃから視聴ポート変更応答が届くと、順次境界装置＃Ａに対して該当装置へのユニキャストアドレス（「ＩＢ：視聴者Ａ」、「ＩＢ：境界装置Ｂ」）での送信の停止を指示する。
　また、ＳＩＰサーバ＃Ｃは、ＳＩＰサーバ＃Ｂから視聴ポート変更が届くと、視聴ポート変更で指定されたマルチキャストアドレスでのコンテンツ受信の開始を境界装置３０Ｂに指示し、送信先アドレス変換テーブルの中継元の「ＩＢ：境界装置Ｂ」を「ＩＢ：ＩＰ＃Ｂ」に変更する。
　また、図１７の例は、視聴終了を受信し、自機が接続制御するマルチキャストドメイン内の視聴数が「Ｍ２Ｕ閾値」より小さい場合の例である。同図に示すように、ＳＩＰサーバ＃Ｂは、視聴終了を受信し、自機が接続制御するマルチキャストドメイン内の視聴数が閾値を下回ったと判定すると、マルチキャスト中継指示を境界装置＃Ａに通知して、送信先アドレス変換テーブルの中継先にユニキャストアドレス（「ＩＢ：視聴者Ａ」、「ＩＢ：境界装置Ｂ」）を追加する。
　そして、ＳＩＰサーバ＃Ｂは、視聴端末＃Ａ、ＳＩＰサーバ＃Ｃから視聴ポート変更応答が届くと、境界装置＃Ａに対して該当装置へのマルチキャストアドレス（「ＩＢ：ＩＰ＃Ｂ」）での送信の停止を指示する。
　また、ＳＩＰサーバ＃Ｃは、ＳＩＰサーバ＃Ｂから視聴ポート変更が届くと、視聴ポート変更で指定されたマルチキャストアドレスでのコンテンツ受信の開始を境界装置３０Ｂに指示し、送信先アドレス変換テーブルの中継元の「ＩＢ：ＩＰ＃Ｂ」を「ＩＢ：境界装置Ｂ」に変更する。
　また、図１８の例では、視聴要求を受信し、マルチキャストドメイン外視聴数が増加して「Ｕ２Ｍ閾値」を超過した場合の送信先アドレス変換テーブル遷移の様子を示しており、図１９の例では、視聴終了を受信し、マルチキャストドメイン外視聴数減少して「Ｍ２Ｕ閾値」より小さくなった場合の送信先アドレス変換テーブル遷移の様子を示している。
　また、図２０では、マルチキャストドメイン内の最後の視聴者が視聴を終了した場合の送信先アドレス変換テーブル遷移の様子を示している。また、図２１の例では、マルチキャストドメイン外の視聴者が視聴を終了した場合の送信先アドレス変換テーブル遷移の様子を示している。なお、詳しい処理の流れについては、後述する処理の説明に詳しく記載する（図２５～図４５）。
　ここで、境界装置２０によるマルチキャストドメイン間の接続例を図２２～図２４に例示する。図２２の例では、境界装置２０は、上流マルチキャストドメインからのマルチキャストパケットが境界装置に到達する環境に適用し、ＳＩＰサーバからの指示によりマルチキャストドメイン＃Ａからのマルチチャストアドレス＃ａ宛のパケットを、マルチキャストドメイン＃Ｂ内へマルチキャストアドレス＃ｂ宛のパケットとして送信する。
　そして、境界装置２０あて先アドレスのみ変更し、送信元アドレスは、変更しない。また、中継を指定されていないマルチキャストアドレス宛のパケットは、廃棄する。
　また、図２３の例は、上流マルチキャストドメインからのマルチキャストパケットが境界装置に到達できない環境に適用される例である。ＳＩＰサーバからの指示によりマルチキャストドメイン＃Ａからのマルチチャストアドレス＃ａ宛のパケットを境界装置αが境界装置βへ向けユニキャスト送信し、そのユニキャスト送信されたパケットを境界装置βがマルチキャストドメイン＃Ｂ内へマルチキャストアドレス＃ｂ宛のパケットとして送信する。
　そして、両境界装置とも、あて先アドレスのみ変更し、送信元アドレスは、変更しない。また、中継を指定されていないマルチキャストアドレス宛のパケットは、廃棄する。
　また、図２４の例は、上流マルチキャストドメインからのマルチキャストパケットが境界装置に到達する環境に適用される例である。境界装置αと境界装置βとが（物理的または論理的に）直接接続される構成においてＳＩＰサーバからの指示によりマルチキャストドメイン＃Ａからのマルチチャストアドレス＃ａ宛のパケットを境界装置αが境界装置βへ向けそのまま中継送信し、その送信されたパケットを境界装置βがマルチキャストドメイン＃Ｂ内へマルチキャストアドレス＃ｂ宛のパケットとして送信する。
　このとき、送信元アドレスは、キー局（マルチキャストパケットの生成元）のアドレスとする。そして両境界装置とも、送信元アドレスは、変更しない。また、中継を指定されていないマルチキャストアドレス宛のパケットは、廃棄することとする。
［マルチキャスト配信システムによる処理］
　次に、図２５～３２を用いて、実施例１に係るマルチキャスト配信システムによる全体の処理を説明する。図２５は、最初の視聴者が視聴要求を発したときの視聴者とコンテンツフォルダ間のマルチキャスト経路形成のシーケンス図である。図２６は、所望のコンテンツフォルダからの放送を他の視聴者がすでに行っている場合の視聴者が視聴要求を発したときの視聴者とコンテンツフォルダ間のマルチキャスト経路形成のシーケンス図である。図２７は、マルチキャストドメイン内の視聴者の増加により、ユニキャスト配信よりマルチキャスト配信がネットワークのトラヒックを低減すると判断した場合のユニキャストからマルチキャストへの切り換えシーケンス図である。
　図２８は、マルチキャストドメイン内の視聴者の減少により、マルチキャスト配信よりユニキャスト配信がネットワークのトラヒックを低減すると判断した場合のマルチキャストからユニキャストへの切り換えシーケンス図である。図２９は、マルチキャストドメイン外の視聴者の増加により、ユニキャスト配信よりマルチキャスト配信がネットワークのトラヒックを低減すると判断した場合のユニキャストからマルチキャストへの切り換えシーケンス図である。
　図３０は、マルチキャストドメイン外の視聴者の減少により，マルチキャスト配信よりユニキャスト配信がネットワークのトラヒックを低減すると判断した場合のマルチキャストからユニキャストへの切り換えシーケンス図である。図３１は、最後の視聴者がマルチキャストドメイン内の視聴者であった場合の視聴終了をコンテンツフォルダへ通知する場合のシーケンス図である。図３２は、最後の視聴者がマルチキャストドメイン内の視聴者であった場合の視聴終了をコンテンツフォルダへ通知する場合のシーケンス図である。
　まず、最初の視聴者が視聴要求する場合について説明する。視聴者がキー局２０の番組を選択して視聴開始操作を行うと、視聴端末４０は、キー局４０宛の視聴要求を送信する（図４２参照）。
　つまり、図２５に示すように、視聴者端末４０は、自機が属するマルチキャストドメイン内の接続制御を管理するＳＩＰサーバ１０Ｃへ視聴要求を送信する（ステップＳ１０１）。そして、ＳＩＰサーバ１０Ｃは、隣接のマルチキャストドメインの接続制御を管理するＳＩＰサーバ１０Ｂへ視聴要求を送信する（ステップＳ１０２）。
　そして、ＳＩＰサーバ１０Ｂは、隣接のマルチキャストドメインの接続制御を管理するＳＩＰサーバ１０Ａへ視聴要求を経由して（ステップＳ１０３）、キー局２０へ視聴要求を送信する（ステップＳ１０４）。視聴要求を受信したキー局２０は、コンテンツの放送を開始する（ステップＳ１０５）。また、キー局２０は、視聴要求応答にＩＰＴＶ放送のアドレス情報を搭載し、返送する（ステップＳ１０６）。
　続いて、ＳＩＰサーバ１０Ａは、視聴者要求応答をキー局２０から受信すると、ＳＩＰサーバ１０Ｂに視聴者要求応答を送信する（ステップＳ１０７）。そして、ＳＩＰサーバ１０Ｂは、マルチキャストアドレスを取得し（ステップＳ１０８）、境界装置３０Ａに中継開始を指示する（ステップＳ１０９）。境界装置３０Ａは、マルチキャストドメイン内へコンテンツの中継を開始する（ステップＳ１１０）。
　また、ＳＩＰサーバ１０Ｂは、ＳＩＰサーバ１０Ａから受信した視聴者要求応答をＳＩＰサーバ１０Ｃに中継する（ステップＳ１１１）。ＳＩＰサーバＣは、同様に、マルチキャストアドレスを取得し（ステップＳ１１２）、境界装置３０Ｂに中継開始を指示する（ステップＳ１１３）。
　境界装置３０Ｂは、マルチキャストドメイン内へコンテンツの中継を開始する（ステップＳ１１４）。また、ＳＩＰサーバ１０Ｃは、ＳＩＰサーバ１０Ｂから受信した視聴者要求応答を視聴者装置４０に中継する（ステップＳ１１５）。その後、視聴者装置４０は、キー局２０との放送経路の確立を完了する（図４３参照）。
　続いて、マルチキャストドメイン内の他の視聴者が視聴している場合に、視聴端末４０が視聴要求するについて図２６を用いて説明する。視聴者がキー局２０の番組を選択して視聴開始操作を行うと、視聴端末４０は、キー局４０宛の視聴要求を送信する（図４２参照）。
　その後、図２６に示すように、視聴端末４０が属するマルチキャストドメイン内の接続制御を管理するＳＩＰサーバ１０Ｃは、視聴端末４０から視聴要求を受信する（ステップＳ２０１）。そして、ＳＩＰサーバ１０Ｃは、視聴要求をキー局２０宛にＳＩＰサーバ１０Ｂへ中継する（ステップＳ２０２）。
　そして、視聴要求を受け付けたＳＩＰサーバ１０Ｂは、視聴要求応答を視聴端末４０宛にＳＩＰサーバＣへ送信する（ステップＳ２０３）。また、ＳＩＰサーバ１０Ｃは、マルチキャストアドレスを取得し（ステップＳ２０４）、境界装置３０Ｂに中継開始を指示する（ステップＳ２０５）。
　そして、境界装置３０Ｂは、コンテンツの中継をマルチキャストドメイン内に開始する（ステップＳ２０６）。また、ＳＩＰサーバ１０Ｂから視聴要求応答を受信したＳＩＰサーバ１０Ｃは、視聴者端末４０へ視聴要求応答を送信する（ステップＳ２０７）。その後、聴者装置４０は、キー局２０との放送経路の確立を完了する。
　次に、マルチキャストドメイン内の視聴者の数が増大し、ユニキャスト配信からマルチキャスト配信に切り換える場合の動作について図２７を用いて説明する。
　同図に示すように、ＳＩＰサーバ１０Ａがマルチキャスト配信を行い（ステップＳ３０１）、ＳＩＰサーバＢが視聴端末４０Ａ、４０Ｂにユニキャスト配信を行うように制御している場合に（ステップＳ３０２、３０３）、視聴端末４０Ｂは、視聴者の操作によって視聴要求をコンテンツフォルダ宛に送信すると、ＳＩＰサーバ１０Ｂへ視聴要求が届く（ステップＳ３０４）。
　そして、ＳＩＰサーバ１０Ｂは、視聴要求を受信し、自機が接続制御するマルチキャストドメイン内の視聴数が閾値を超過したと判定すると、視聴中の全視聴端末へ向け、視聴ポート変更を送信する（図３３参照）。
　また、ＳＩＰサーバ１０Ｂは、境界端末３０Ａに対してマルチキャスト配信の開始を指示し（ステップＳ３０５）、マルチキャスト送信をするように制御する（ステップＳ３０６）。また、ＳＩＰサーバ１０Ｂは、視聴端末４０Ｂへ視聴要求応答を返送する（ステップＳ３０７）。
　続いて、視聴端末４０Ｂは、ＳＩＰサーバ１０Ｂから視聴要求応答が届くと（ステップＳ３０７）、視聴要求応答で指定されたマルチキャストアドレスでのコンテンツ受信を開始する（ステップＳ３１４）。
　また、視聴端末４０Ａは、ＳＩＰサーバ１０Ｂから視聴ポート変更が届くと（ステップＳ３０８）、視聴要求応答で指定されたマルチキャストアドレスでのコンテンツ受信を開始し、視聴ポート変更応答をＳＩＰサーバ１０Ｂへ返送する（ステップＳ３１０）。
　ＳＩＰサーバ１０Ｃは、ＳＩＰサーバ１０Ｂから視聴ポート変更が届くと（ステップＳ３０９）、視聴ポート変更で指定されたマルチキャストアドレスでのコンテンツ受信の開始を境界装置３０Ｂに指示し（ステップＳ３１１）、視聴ポート変更応答をＳＩＰサーバ１０Ｂへ返送する（ステップＳ３１２）。
　そして、ＳＩＰサーバ１０Ｂは、視聴端末４０Ａ、ＳＩＰサーバ１０Ｃから視聴ポート変更応答が届くと、順次境界装置に対して該当装置へのユニキャストアドレスでの送信の停止を指示する（ステップＳ３１３）。その後、ＳＩＰサーバ１０Ｂは、視聴端末４０Ａ、４０Ｂにマルチキャスト配信を行うように制御している（ステップＳ３１４）。
　次に、マルチキャストドメイン内の視聴者の数が減少し、マルチキャスト配信からユニキャスト配信に切り換える場合の動作について図２８を用いて説明する。
　同図に示すように、ＳＩＰサーバ１０Ａがマルチキャスト配信を行い（ステップＳ４０１）、ＳＩＰサーバＢが視聴端末４０Ａ、４０Ｂ、境界装置２０Ｂにマルチキャスト配信を行うように制御している（ステップＳ４０２）。そして、視聴端末４０Ｂが視聴者の操作によって視聴終了をコンテンツフォルダ宛に送信すると、ＳＩＰサーバ１０Ｂは、視聴終了を受信し（ステップＳ４０３）、視聴終了応答を返信する（ステップＳ４０４）。
　そして、ＳＩＰサーバ１０Ｂは、視聴終了を受信し、自機が接続制御するマルチキャストドメイン内の視聴数が閾値を下回ったと判定すると、視聴中の全視聴端末へ向け、視聴ポート変更を送信する（図３６参照）。また、ＳＩＰサーバ１０Ｂは、境界端末３０Ａに対してユニキャスト配信の開始を指示し（ステップＳ４０５）、ユニキャスト送信をするように制御する（ステップＳ４０６）。
　続いて、視聴端末４０Ａは、ＳＩＰサーバ１０Ｂから視聴ポート変更が届くと（ステップＳ４０７）、視聴ポート変更応答を返送し（ステップＳ４０８）、視聴ポート変更で指定されたユニキャストアドレスでのコンテンツ受信を開始する（ステップＳ４１４）。
　ＳＩＰサーバ１０Ｃは、ＳＩＰサーバ１０Ｂから視聴ポート変更が届くと（ステップＳ４０９）、視聴ポート変更で指定されたユニキャストアドレスでのコンテンツ受信の開始を境界装置３０Ｂに指示し（ステップＳ４１０）、視聴ポート変更応答をＳＩＰサーバ１０Ｂへ返送する（ステップＳ４１１）。
　そして、ＳＩＰサーバ１０Ｂは、ＳＩＰサーバ１０Ｃから視聴ポート変更応答が届くと、順次境界装置に対して該当装置へのマルチキャストアドレスでの送信の停止を指示する（ステップＳ４１２）。その後、ＳＩＰサーバＢは、視聴端末４０Ａ、４０Ｂにユニチキャスト配信を行うように制御している（ステップＳ４１４、Ｓ４１５）。
　次に、マルチキャストドメイン外の視聴者の数が減少し、ユニキャスト配信からマルチキャスト配信に切り換える場合の動作について図２９を用いて説明する。
　同図に示すように、ＳＩＰサーバ１０Ａがマルチキャスト配信を行い（ステップＳ５０１）、ＳＩＰサーバＢが視聴端末４０Ａにユニキャスト配信を行うように制御している場合に（ステップＳ５０２）、ＳＩＰサーバ４０Ｃは、マルチキャストドメイン外の視聴者の操作によってコンテンツフォルダ宛に送信された視聴要求をＳＩＰサーバ１０Ｂへ送信する（ステップＳ５０３）。
　そして、ＳＩＰサーバ１０Ｂは、視聴要求を受信し、視聴数が閾値を超過したと判定すると、視聴中の全視聴端末へ向け、視聴ポート変更を送信する（図３３参照）。
　また、ＳＩＰサーバ１０Ｂは、境界端末３０Ａに対してマルチキャスト配信の開始を指示し（ステップＳ５０５）、マルチキャスト送信をするように制御する（ステップＳ５０６）。また、ＳＩＰサーバ１０Ｂは、ＳＩＰサーバ１０Ｃへ視聴要求応答を返送する（ステップＳ５０７）。
　また、ＳＩＰサーバ１０Ｃは、ＳＩＰサーバ１０Ｂから視聴要求応答が届くと（ステップＳ５０７）、視聴要求応答で指定されたマルチキャストアドレスでの中継開始を境界装置２０Ｂに指示する（ステップＳ５０８）。
　また、視聴端末４０Ａは、ＳＩＰサーバ１０Ｂから視聴ポート変更が届くと（ステップＳ５０９）、視聴要求応答で指定されたマルチキャストアドレスでのコンテンツ受信を開始し、視聴ポート変更応答をＳＩＰサーバ１０Ｂへ返送する（ステップＳ５１０）。
　そして、ＳＩＰサーバ１０Ｂは、視聴端末４０Ａから視聴ポート変更応答が届くと、順次境界装置に対して該当装置へのユニキャストアドレスでの送信の停止を指示する（ステップＳ５１１）。その後、ＳＩＰサーバＢは、マルチキャストドメイン内の視聴端末およびマルチキャストドメイン外の視聴端末へマルチキャスト配信を行うように制御している（ステップＳ５１２）。
　次に、マルチキャストドメイン外の視聴者の数が減少し、マルチキャスト配信からユニチキャスト配信に切り換える場合の動作について図３０を用いて説明する。
　同図に示すように、ＳＩＰサーバ１０Ａがマルチキャスト配信を行い（ステップＳ６０１）、ＳＩＰサーバＢが視聴端末４０Ａ、４０Ｂ、境界装置２０Ｂにマルチキャスト配信を行うように制御している（ステップＳ６０２）。そして、ＳＩＰサーバ１０Ｃは、マルチキャストドメイン外の視聴者の操作によってコンテンツフォルダ宛に送信された視聴終了をＳＩＰサーバ１０Ｂへ送信する（ステップＳ６０３）。
　そして、ＳＩＰサーバ１０Ｂは、視聴終了を受信し、ＳＩＰサーバ１０Ｃへ視聴終了応答を返信する（ステップＳ６０４）。視聴終了応答を受信したＳＩＰサーバ１０Ｃは、中継停止を境界装置２０Ｂに指示する（ステップＳ６０５）。
　また、ＳＩＰサーバ１０Ｂは、境界端末３０Ａに対してユニキャスト配信の開始を指示する（ステップＳ６０６）。そして、ＳＩＰサーバ１０Ｂは、視聴終了を受信し、視聴数が閾値を下回ったと判定すると、視聴中の全視聴端末へ向け、視聴ポート変更を送信し（ステップＳ６０７）、ユニキャスト送信をするように制御する（ステップＳ６０８）。
　続いて、視聴端末４０Ａは、ＳＩＰサーバ１０Ｂから視聴ポート変更が届くと（ステップＳ６０７）、視聴ポート変更応答を返送し（ステップＳ６０９）、視聴ポート変更で指定されたユニキャストアドレスでのコンテンツ受信を開始する（ステップＳ６１２）。
　そして、ＳＩＰサーバ１０Ｂは、視聴端末４０Ａから視聴ポート変更応答が届くと、境界装置に対して該当装置へのマルチキャストアドレスでの送信の停止を指示し（ステップＳ６１０）、マルチキャストアドレスを返却する（ステップＳ６１１）。その後、ＳＩＰサーバ１０Ｂは、視聴端末４０Ａにユニチキャスト配信を行うように制御している（ステップＳ６１２）。
　次に、マルチキャストドメイン内の最後の視聴者が視聴を終了した場合の動作について図３１を用いて説明する。
　同図に示すように、ＳＩＰサーバ１０Ａがマルチキャスト配信を行い（ステップＳ７０１）、ＳＩＰサーバＢが視聴端末４０Ａにユニキャスト配信を行うように制御している（ステップＳ７０２）。
　ＳＩＰサーバ１０Ｂは、視聴終了を視聴端末４０Ａから受信すると（ステップＳ７０３）、マルチキャストドメイン内の視聴数が無くなったと判断し、境界装置２０ＡにＩＰＴＶ放送の配信の停止を指示する（ステップＳ７０４）。
　そして、ＳＩＰサーバ１０Ｂは、ＳＩＰサーバ１０Ａへ視聴終了を送信する（ステップＳ７０５）。視聴終了を受信したＳＩＰサーバ１０Ａは、視聴終了応答をＳＩＰサーバに送信する（ステップＳ７０６）。そして、ＳＩＰサーバ１０Ｂは、受信した視聴終了応答を視聴者端末４０Ａに送信する（ステップＳ７０７）。ＳＩＰサーバ１０Ａおよび１０Ｂｈａ，視聴終了応答を受信すると、コンテンツ配信管理情報の格納域を開放する。
　その後、ＳＩＰサーバ１０Ａがキー局２０に視聴終了を送信し、キー局２０は、視聴終了を受信すると、ＩＰＴＶ放送の配信を停止し、視聴終了応答をＳＩＰサーバ１０Ａへ送信する。
　次に、マルチキャストドメイン外の視聴者が視聴を終了した場合の動作について図３２を用いて説明する。
　同図に示すように、ＳＩＰサーバ１０Ａがマルチキャスト配信を行い（ステップＳ８０１）、ＳＩＰサーバＢが境界装置３０Ｂにユニキャスト配信を行うように制御している（ステップＳ８０２）。
　ＳＩＰサーバ１０Ｂは、ＳＩＰサーバ１０Ｃを介してマルチキャストドメイン外の視聴者端末から視聴終了を受信すると（ステップＳ８０３）、マルチキャストドメイン内の視聴数が無くなったと判断し、境界装置２０ＡにＩＰＴＶ放送の配信の停止を指示する（ステップＳ８０４）。
　そして、ＳＩＰサーバ１０Ｂは、ＳＩＰサーバ１０Ａへ視聴終了を送信する（ステップＳ８０５）。視聴終了を受信したＳＩＰサーバ１０Ａは、視聴終了応答をＳＩＰサーバ１０Ｂに送信する（ステップＳ８０６）。そして、ＳＩＰサーバ１０Ｂは、受信した視聴終了応答をＳＩＰサーバ１０Ｃを介してマルチキャストドメイン外の視聴者端末に送信する（ステップＳ８０７）。
　その後、ＳＩＰサーバ１０Ａがキー局２０に視聴終了を送信し、キー局２０は、視聴終了を受信すると、ＩＰＴＶ放送の配信を停止し、視聴終了応答をＳＩＰサーバ１０Ａへ送信する。
［ＳＩＰサーバによる処理］
　次に、図３３～図４１を用いて、実施例１に係るＳＩＰサーバ１０による処理を説明する。図３３は、実施例１に係るＳＩＰサーバ１０における視聴要求の中継処理の動作を示すフローチャートである。図３４は、実施例１に係るＳＩＰサーバ１０における視聴要求応答の中継処理の動作を示すフローチャートである。図３５は、実施例１に係るＳＩＰサーバ１０における視聴ポート変更応答の受信処理の動作を示すフローチャートである。図３６は、実施例１に係るＳＩＰサーバ１０における視聴終了の中継処理の動作を示すフローチャートである。図３７は、実施例１に係るＳＩＰサーバ１０における視聴終了の受信処理の動作を示すフローチャートである。図３８は、実施例１に係るＳＩＰサーバ１０における視聴要求の中継処理の動作を示すフローチャートである。
　まず、実施例１に係るＳＩＰサーバ１０における視聴要求の中継処理の動作について図３３を用いて説明する。同図に示すように、ＳＩＰサーバ１０は、視聴要求を受信すると、受信した視聴要求のｔｏと同じコンテンツ配信装置（キー局）２０アドレスをもつコンテンツ配信管理情報を取り出し（ステップＳ１１０１）、コンテンツ配信管理情報があるか判定する（ステップＳ１１０２）。
　そして、ＳＩＰサーバ１０は、コンテンツ管理情報がない場合には（ステップＳ１１０２否定）、Ｓ１１０８まで進む。また、ＳＩＰサーバ１０は、コンテンツ配信管理情報がある場合には（ステップＳ１１０２肯定）、コンテンツ配信管理情報を生成し（ステップＳ１１０３）、境界装置３０の上流コンテンツ受信ポートを確保し、コンテンツ配信管理情報へ記憶する（ステップＳ１１０４）。
　続いて、ＳＩＰサーバ１０は、視聴要求を編集し（ステップＳ１１０５）、視聴要求をコンテンツ配信装置２０へ向け中継送信して（ステップＳ１１０６）、受信した視聴要求の視聴装置アドレスとコンテンツ受信ポートをコンテンツ配信管理情報の視聴装置リストに記憶する（ステップＳ１１０７）。
　そして、ＳＩＰサーバ１０は、視聴装置数がＵ２Ｍ閾値より小さいか判定する（ステップＳ１１０８）。その結果、ＳＩＰサーバ１０は、視聴装置数がＵ２Ｍ閾値より小さい場合には（ステップＳ１１０８肯定）、受信した視聴要求の視聴装置対応のポート状態を受信開始とする（ステップＳ１１０９）。
　そして、ＳＩＰサーバ１０は、境界装置３０へＲＴＰパケットを受信視聴要求のコンテンツ受信ポートあてに中継開始を指示し（ステップＳ１１１０）、接続状態が「接続中」であるか判定する（ステップＳ１１１１）。
　その結果、ＳＩＰサーバ１０は、接続状態が「接続中」である場合には（ステップＳ１１１１肯定）、視聴要求応答を視聴装置４０へ返信し（ステップＳ１１１２）、接続状態が「接続中」でない場合には（ステップＳ１１１１否定）、そのまま処理を終了する。
　Ｓ１１０８の説明に戻って、ＳＩＰサーバ１０は、視聴装置数がＵ２Ｍ閾値以上である場合には（ステップＳ１１０８否定）、受信視聴要求の視聴装置対応のポート状態を受信停止とし（ステップＳ１１１３）、配信種別が「ユニキャスト」であるか判定する（ステップＳ１１１４）。
　その結果、ＳＩＰサーバ１０は、配信種別が「ユニキャスト」である場合には（ステップＳ１１１４肯定）、マルチキャストアドレスを確保し、コンテンツ配信管理情報の下流コンテンツ放送ポートに記憶して（ステップＳ１１１５）、接続状態が「接続中」であるか判定する（ステップＳ１１１６）。
　その結果、ＳＩＰサーバ１０は、接続状態が「応答待ち」である場合には（ステップＳ１１１６否定）、境界装置３０へＲＴＰパケットを下流放送コンテンツ放送ポート宛てに中継開始を指示する（ステップＳ１１１９）。
　また、ＳＩＰサーバ１０は、接続状態が「接続中」である場合には（ステップＳ１１１６肯定）、視聴要求応答を視聴装置４０へ返し（ステップＳ１１１７）、視聴装置リスト内の全ての視聴装置４０へ視聴ポート変更を送信して（ステップＳ１１１８）、境界装置３０へＲＴＰパケットを下流放送コンテンツ放送ポート宛てに中継開始を指示する（ステップＳ１１１９）。
　Ｓ１１１４の説明に戻って、ＳＩＰサーバ１０は、配信種別がマルチキャストである場合には（ステップＳ１１１４否定）、接続状態が「接続中」であるか判定する（ステップＳ１１２０）。その結果、ＳＩＰサーバ１０は、接続状態が「接続中」である場合には（ステップＳ１１２０肯定）、視聴要求応答を視聴装置４０へ返す（ステップＳ１１２１）。また、ＳＩＰサーバ１０は、接続状態が「応答待ち」である場合には（ステップＳ１１２０否定）、そのまま処理を終了する。
　続いて、図３４は、実施例１に係るＳＩＰサーバ１０における視聴要求応答の中継処理の動作を示すフローチャートである。同図に示すように、ＳＩＰサーバ１０は、視聴要求応答を受信すると、受信視聴要求応答のコンテンツ配信管理情報を取り出し（ステップＳ１２０１）、コンテンツ配信管理情報があるか判定する（ステップＳ１２０２）。その結果、ＳＩＰサーバ１０、コンテンツ配信管理情報がない場合には（ステップＳ１２０２否定）、処理を終了する。
　そして、ＳＩＰサーバ１０は、コンテンツ配信管理情報がある場合には（ステップＳ１２０２肯定）、受信した視聴要求応答がユニキャストアドレスでのコンテンツ受信を行う旨の視聴要求応答（以下、視聴要求＃Ｕ）であるか判定する（ステップＳ１２０３）。
　その結果、ＳＩＰサーバ１０は、受信した視聴要求応答が視聴要求応答＃Ｕである場合には（ステップＳ１２０３肯定）、コンテンツ管理情報をユニキャストに更新し（ステップＳ１２０４）、境界装置３０へ上流コンテンツ受信ポート宛ＲＴＰパケットを中継するように指示する（ステップＳ１２０５）。
　また、ＳＩＰサーバ１０は、受信した視聴要求応答が視聴要求応答＃Ｕでない場合には（ステップＳ１２０３否定）、コンテンツ配信管理情報をマルチキャストに更新し（ステップＳ１２０７）、境界装置３０へ上流コンテンツ受信ポート宛ＲＴＰパケットを中継するように指示する（ステップＳ１２０８）。
　そして、ＳＩＰサーバ１０は、配信種別がユニキャストであるか判定し（ステップＳ１２０９）、ユニキャストである場合には（ステップＳ１２０９肯定）、視聴要求応答＃Ｕを視聴装置リスト内全ての装置に返す（ステップＳ１２１１）。
　また、ＳＩＰサーバ１０は、配信種別がマルチキャストであるか場合には（ステップＳ１２０９否定）、マルチキャストアドレスでのコンテンツ受信を行う旨の視聴要求応答（以下、視聴要求＃Ｍ）を視聴装置リスト内全ての装置に返す（ステップＳ１２１０）。
　続いて、図３５は、実施例１に係るＳＩＰサーバ１０における視聴ポート変更応答の受信処理の動作を示すフローチャートである。同図に示すように、ＳＩＰサーバ１０は、視聴ポート変更応答を受信すると、受信した視聴ポート変更応答のコンテンツ配信管理情報を取り出し（ステップＳ１５０１）、コンテンツ配信管理情報があるか判定する（ステップＳ１５０２）。その結果、ＳＩＰサーバ１０、コンテンツ配信管理情報がない場合には（ステップＳ１５０２否定）、処理を終了する。
　そして、ＳＩＰサーバ１０は、コンテンツ配信管理情報がある場合には（ステップＳ１５０２肯定）、受信した視聴ポート変更応答がユニキャストアドレスでのコンテンツ受信に変更する旨の視聴ポート変更応答（以下、視聴ポート変更応答＃Ｕ）であるか判定する（ステップＳ１５０３）。
　その結果、ＳＩＰサーバ１０は、受信した視聴ポート変更応答が視聴ポート変更応答＃Ｕである場合には（ステップＳ１５０３肯定）、受信した視聴ポート変更応答の視聴装置対応のポート状態を受信開始とし（ステップＳ１５０４）、視聴装置リスト内の全ての視聴装置対応のポート受信開始か判定する（ステップＳ１５０５）。
　その結果、ＳＩＰサーバ１０は、視聴装置リスト内の全ての視聴装置対応のポート受信開始である場合には（ステップＳ１５０５肯定）、境界装置３０へ下流コンテンツ放送ポート（マルチキャスト）でのマルチキャスト送信の停止を指示する（ステップＳ１５０６）。また、ＳＩＰサーバ１０は、視聴装置リスト内の全ての視聴装置対応のポート受信開始でない場合には（ステップＳ１５０５否定）、処理を終了する。
　また、ＳＩＰサーバ１０は、受信した視聴ポート変更応答が視聴ポート変更応答＃Ｕでない場合には（ステップＳ１５０３否定）、受信した視聴ポート変更応答の視聴装置対応のポート状態を受信停止とし（ステップＳ１５０７）、境界装置３０へ受信視聴要求応答の視聴装置へのユニキャスト送信の停止を指示する（ステップＳ１５０８）。
　続いて、図３６は、実施例１に係るＳＩＰサーバ１０における視聴終了の中継処理の動作を示すフローチャートである。同図に示すように、ＳＩＰサーバ１０は、視聴終了を受信すると、受信した視聴終了の「ｔｏ」と同じコンテンツ配信装置アドレスをもつコンテンツ配信をもつコンテンツ配信管理情報を取り出し（ステップＳ１７０１）、コンテンツ配信管理情報があるか判定する（ステップＳ１７０２）。
　そして、ＳＩＰサーバ１０は、コンテンツ管理情報がない場合には（ステップＳ１７０２否定）、視聴終了応答を視聴装置４０へ返して（ステップＳ１７０６）、処理を終了する。
　また、ＳＩＰサーバ１０は、コンテンツ管理情報がある場合には（ステップＳ１７０２肯定）、境界装置３０へ受信した視聴終了の視聴装置４０のコンテンツ受信ポート宛の中継停止を指示し（ステップＳ１７０３）、受信視聴終了の視聴装置アドレスとコンテンツ受信ポートをコンテンツ配信管理情報の視聴装置リストから削除する（ステップＳ１７０４）。
　そして、ＳＩＰサーバ１０は、視聴装置数がＭ２Ｕ閾値よりも大きいか判定し（ステップＳ１７０５）、大きい場合には（ステップＳ１７０５肯定）視聴終了応答を視聴装置４０へ返して（ステップＳ１７０６）、処理を終了する。
　また、ＳＩＰサーバ１０は、視聴装置数がＭ２Ｕ閾値以下である場合には（ステップＳ１７０５否定）、配信種別が「ユニキャスト」であるか判定する（ステップＳ１７０７）。その結果、ＳＩＰサーバ１０は、配信種別が「マルチキャスト」である場合には（ステップＳ１７０７否定）、マルチキャストアドレスを確保し、コンテンツ配信管理情報の下流コンテンツ放送ポートに記憶して（ステップＳ１７０８）、視聴終了応答を視聴装置４０へ返す（ステップＳ１７０９）。
　そして、ＳＩＰサーバ１０は、視聴装置リスト内の全ての視聴装置４０へ視聴ポート変更＃Ｕを送信し（ステップＳ１７１０）、境界装置３０へＲＴＰパケットを視聴装置リストへの全コンテンツ受信ポート宛に中継開始を指示する（ステップＳ１７１１）。
　また、ＳＩＰサーバ１０は、配信種別が「ユニキャスト」である場合には（ステップＳ１７０７肯定）、視聴終了応答を視聴装置４０へ返し（ステップＳ１７１２）、視聴装置リストが「０」であるか判定する（ステップＳ１７１３）。そして、ＳＩＰサーバ１０は、リストが「０」である場合には（ステップＳ１７１３肯定）、コンテンツフォルダへ視聴終了を送信し（ステップＳ１７１４）、リストが「０」でない場合には（ステップＳ１７１３否定）、そのまま処理を終了する。
　続いて、図３７は、実施例１に係るＳＩＰサーバ１０における視聴終了の受信処理の動作を示すフローチャートである。同図に示すように、ＳＩＰサーバ１０は、視聴終了を受信すると、視聴終了応答に対応するコンテンツ配信管理情報を消滅させる（ステップＳ１８０１）。
　続いて、図３８は、実施例１に係るＳＩＰサーバ１０における視聴要求の中継処理の動作であって、直接の中継先にＳＩＰサーバが視聴接続を監理するマルチキャストドメインからのマルチキャストパケットが到達しないものが存在する場合の例（つまり、図２３に例示する形態のマルチキャストドメイン間接続が存在する場合に適用される例）を示す。同図に示すように、ＳＩＰサーバ１０は、図３３に示した視聴要求の中継処理と同様に、視聴要求をコンテンツ配信装置へ向け中継送信した後（ステップＳ１９０６）、受信視聴要求のコンテンツ受信ポートがマルチキャスト到達区域内アドレスリストにあるか判定する（ステップＳ１９０７）。
　続いて、図３９は、実施例１に係るＳＩＰサーバ１０における視聴要求応答の中継処理の動作であって、直接の中継先にＳＩＰサーバが視聴接続を監理するマルチキャストドメインからのマルチキャストパケットが到達しないものが存在する場合の例（つまり、図２３に例示する形態のマルチキャストドメイン間接続が存在する場合に適用される例）を示す。同図に示すように、ＳＩＰサーバ１０は、視聴要求応答を受信すると、図３４に示した視聴要求応答の中継処理と同様に、配信種別がユニキャストであるか判定する（ステップＳ２００８）。
　その結果、ＳＩＰサーバ１０は、配信種別がマルチキャストである場合には（ステップＳ２００８否定）、視聴要求応答＃Ｍを視聴装置リスト内の「到達域＝域内」の全ての装置へマルチキャストでコンテンツを受信するように返信する（ステップＳ２００９）。
　そして、ＳＩＰサーバ１０は、視聴要求応答＃Ｍを視聴装置リスト内の「到達域＝域外」の全ての装置へユニキャストでコンテンツを受信するように返す（ステップＳ２０１０）。
　続いて、図４０は、実施例１に係るＳＩＰサーバ１０における視聴終了の中継処理の動作であって、直接の中継先にＳＩＰサーバが視聴接続を監理するマルチキャストドメインからのマルチキャストパケットが到達しないものが存在する場合の例（つまり、図２３に例示する形態のマルチキャストドメイン間接続が存在する場合に適用される例）を示す。同図に示すように、ＳＩＰサーバ１０は、視聴終了を受信すると、図３６に示した視聴終了の中継処理と同様に、視聴終了応答を視聴装置４０へ返した後（ステップＳ２１０８）、接続装置リスト内の「到達域＝域外」の全ての視聴装置４０へ視聴ポート変更＃Ｕを送信する（ステップＳ２１０９）。
　続いて、図３９は、実施例１に係るＳＩＰサーバ１０における視聴ポート変更の受信処理の動作の例を示す。同図に示すように、ＳＩＰサーバ１０は、視聴ポート変更を受信すると、受信した視聴ポート変更対応のコンテンツ配信管理情報を取り出し（ステップＳ２２０１）、コンテンツ配信管理情報があるか判定する（ステップＳ２２０２）。
　そして、ＳＩＰサーバ１０は、コンテンツ管理情報がない場合には（ステップＳ２２０２否定）、そのまま処理を終了する。また、ＳＩＰサーバ１０は、コンテンツ管理情報がある場合には（ステップＳ２２０２肯定）、受信した視聴ポート変更が視聴ポート変更＃Ｕであるか判定する（ステップＳ２２０３）。
　その結果、ＳＩＰサーバ１０は、受信した視聴ポート変更が視聴ポート変更＃Ｕである場合には（ステップＳ２２０３肯定）、コンテンツ配信管理情報の受信種別をユニキャストに更新する（ステップＳ２２０４）。そして、ＳＩＰサーバ１０は、境界装置３０へ上流コンテンツ受信ポートＲＴＰパケットを中継するように指示し（ステップＳ２２０５）、視聴ポート変更応答＃Ｕを返す（ステップＳ２２０６）。
　また、ＳＩＰサーバ１０は、受信した視聴ポート変更が視聴ポート変更＃Ｕでない場合には（ステップＳ２２０３否定）、コンテンツ配信管理情報の受信種別をマルチキャストに更新する（ステップＳ２２０７）。そして、ＳＩＰサーバ１０は、境界装置３０へ上流コンテンツ受信ポートＲＴＰパケットを中継するように指示し（ステップＳ２２０８）、視聴ポート変更応答＃Ｍを返す（ステップＳ２２０９）。
［視聴装置による処理］
　次に、図４２～４５を用いて、実施例１に係る視聴装置４０による処理を説明する図４２は、実施例１に係る視聴装置４０における視聴開始要求送信処理の動作を示すフローチャートである。図４３は、実施例１に係る視聴装置４０における視聴要求応答の受信処理の動作を示すフローチャートである。図４４は、実施例１に係る視聴装置４０における視聴ポート変更の受信処理の動作を示すフローチャートである。図４５は、実施例１に係る視聴装置４０における視聴終了の中継処理の動作を示すフローチャートである。
　まず、図４２を用いて実施例１に係る視聴装置４０における視聴開始要求送信処理の動作を説明する。同図に示すように、視聴装置４０は、視聴者が開始操作を行うと、視聴要求を編集し（ステップＳ１００１）、ＳＩＰサーバ１０へ視聴要求を送信する（ステップＳ１００２）。そして、視聴装置４０は、コンテンツ受信ポート宛のコンテンツ（ＲＴＰパケット）をディスプレイに再生表示を開始する（ステップＳ１００３）。
　次に、図４３を用いて実施例１に係る視聴装置４０における視聴要求応答の受信処理の動作を説明する。同図に示すように、視聴装置４０は、視聴要求応答を受信すると、受信した視聴要求応答が視聴要求応答＃Ｕであるか判定する（ステップＳ１３０１）。
　その結果、視聴装置４０は、受信した視聴要求応答が視聴要求応答＃Ｕである場合には（ステップＳ１３０１肯定）、コンテンツ配信管理情報の受信種別をユニキャストに更新し（ステップＳ１３０２）、コンテンツ受信ポート宛のコンテンツをディスプレイに再生表示する（ステップＳ１３０３）。
　また、視聴装置４０は、受信した視聴要求応答が視聴要求応答＃Ｍである場合には（ステップＳ１３０１否定）、コンテンツ受信情報の受信種別をマルチキャストに更新し（ステップＳ１３０４）、コンテンツ放送ポート宛のコンテンツをディスプレイに再生表示する（ステップＳ１３０５）。
　次に、図４４を用いて実施例１に係る視聴装置４０における視聴ポート変更の受信処理の動作を説明する。同図に示すように、視聴装置４０は、視聴ポート変更を受信すると、受信した視聴ポート変更が視聴ポート変更＃Ｕであるか判定する（ステップＳ１４０１）。
　その結果、視聴装置４０は、受信した視聴ポート変更が視聴ポート変更＃Ｕである場合には（ステップＳ１４０１肯定）、コンテンツ配信管理情報の情報種別をユニキャストに更新する（ステップＳ１４０２）。そして、視聴装置４０は、コンテンツ受信ポート宛のコンテンツをディスプレイに再生表示を開始して（ステップＳ１４０３）、視聴ポート変更応答を返す（ステップＳ１４０４）。
　また、視聴装置４０は、受信した視聴ポート変更が視聴ポート変更＃Ｕでない場合には（ステップＳ１４０１否定）、コンテンツ受信情報の情報種別をマルチキャストに更新する（ステップＳ１４０５）。そして、視聴装置４０は、コンテンツ受信ポート宛のコンテンツをディスプレイに再生表示を開始して（ステップＳ１４０６）、視聴ポート変更応答＃Ｍを返す（ステップＳ１４０７）。
　次に、図４５を用いて実施例１に係る視聴装置４０における視聴終了の中継処理の動作を説明する。同図に示すように、視聴装置４０は、視聴者が視聴を止める操作を行うと、視聴終了を編集する（ステップＳ１６０１）。
　そして、視聴装置４０は、ＳＩＰサーバ１０へ視聴終了を送信し（ステップＳ１６０２）、コンテンツ受信ポート宛のコンテンツをディスプレイに再生表示することを停止する（ステップＳ１６０３）。
[実施例１の効果]
　上述してきたように、ＳＩＰサーバ１０は、配信領域内における端末からの配信を要求する配信要求の数が所定の閾値以上であるかを判定し、配信要求の数が所定の閾値以上であると判定された場合には、マルチキャスト送信するように制御し、また、配信要求の数が所定の閾値より小さいと判定された場合には、ユニキャスト送信する。このため、無駄なパケットによる通信帯域の占有を防止し、通信サービスの品質を向上することが可能である。
　また、実施例１によれば、配信領域外へ配信情報を送信する場合には、ユニキャスト送信するように制御するので、配信領域外での無駄なパケットによる通信帯域の占有を防止し、通信サービスの品質を向上することが可能である。
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では実施例２として本発明に含まれる他の実施例を説明する。
（１）システム構成等
　図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、視聴者数判定部１２ａと送信制御部１２ｂを統合してもよい。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
　また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することが
（２）プログラム
　なお、本実施例で説明したコンテンツ配信方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

Claims (6)

  1. 　配信情報を複数の端末が属する配信領域に配信する配信サーバと、前記配信情報を前記配信領域間で中継する中継サーバと、当該中継サーバが前記配信領域間を中継するように制御する代理サーバとを有する配信システムであって、
    　代理サーバが、配信領域内における端末からの配信を要求する配信要求の数が所定の閾値以上であるかを判定する視聴者数判定部と、
    　代理サーバが、前記判定部によって前記配信要求の数が所定の閾値以上であると判定された場合には、マルチキャスト送信するように前記配信サーバまたは前記中継サーバを制御し、また、前記判定部によって前記配信要求の数が所定の閾値より小さいと判定された場合には、ユニキャスト送信するように前記配信サーバまたは前記中継サーバを制御する送信制御部と、
    　を備えることを特徴とする配信システム。
  2. 　前記送信制御部は、前記配信領域外へ前記配信情報を送信する場合には、ユニキャスト送信するように前記配信サーバまたは前記中継サーバを制御することを特徴とする請求項１に記載の配信システム。
  3. 　配信領域内における端末からの配信を要求する配信要求の数が所定の閾値以上であるかを判定する視聴者数判定部と、
    　前記判定部によって前記配信要求の数が所定の閾値以上であると判定された場合には、マルチキャスト送信するように制御し、また、前記判定部によって前記配信要求の数が所定の閾値より小さいと判定された場合には、ユニキャスト送信するように制御する送信制御部と、
    　を備えることを特徴とする代理サーバ。
  4. 　前記送信制御部は、前記配信領域外へ前記配信情報を送信する場合には、ユニキャスト送信するように制御することを特徴とする請求項３に記載の代理サーバ。
  5. 　配信領域内における端末からの配信を要求する配信要求の数が所定の閾値以上であるかを判定する視聴者数判定ステップと、
    　前記判定ステップによって前記配信要求の数が所定の閾値以上であると判定された場合には、マルチキャスト送信するように制御し、また、前記判定ステップによって前記配信要求の数が所定の閾値より小さいと判定された場合には、ユニキャスト送信するように制御する送信制御ステップと、
    　を含んだことを特徴とする配信方法。
  6. 　前記送信制御ステップは、前記配信領域外へ前記配信情報を送信する場合には、ユニキャスト送信するように制御することを特徴とする請求項５に記載の配信方法。
PCT/JP2008/069688 2008-10-29 2008-10-29 配信システム、代理サーバおよび配信方法 WO2010050022A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2010535562A JPWO2010050022A1 (ja) 2008-10-29 2008-10-29 配信システム、代理サーバおよび配信方法
PCT/JP2008/069688 WO2010050022A1 (ja) 2008-10-29 2008-10-29 配信システム、代理サーバおよび配信方法
US13/085,943 US20110191404A1 (en) 2008-10-29 2011-04-13 Delivery system, agent server, and delivery method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2008/069688 WO2010050022A1 (ja) 2008-10-29 2008-10-29 配信システム、代理サーバおよび配信方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/085,943 Continuation US20110191404A1 (en) 2008-10-29 2011-04-13 Delivery system, agent server, and delivery method

Publications (1)

Publication Number Publication Date
WO2010050022A1 true WO2010050022A1 (ja) 2010-05-06

Family

ID=42128401

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2008/069688 WO2010050022A1 (ja) 2008-10-29 2008-10-29 配信システム、代理サーバおよび配信方法

Country Status (3)

Country Link
US (1) US20110191404A1 (ja)
JP (1) JPWO2010050022A1 (ja)
WO (1) WO2010050022A1 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011259160A (ja) * 2010-06-08 2011-12-22 Nippon Telegr & Teleph Corp <Ntt> 配信方式の切り替えを行う同報システム及びその制御方法
JP2012004948A (ja) * 2010-06-18 2012-01-05 Nec Corp 通信中継装置、通信中継システムおよび通信中継方法
JP2013046175A (ja) * 2011-08-23 2013-03-04 Nippon Telegr & Teleph Corp <Ntt> マルチキャスト配信方法及び送信装置
WO2014148277A1 (ja) * 2013-03-19 2014-09-25 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
CN105210372A (zh) * 2013-05-22 2015-12-30 索尼公司 内容供应装置、内容供应方法、程序以及内容供应***
WO2019176402A1 (ja) * 2018-03-16 2019-09-19 日本電気株式会社 マルチキャスト制御装置、マルチキャスト制御方法、及び非一時的なコンピュータ可読媒体
JP2021053182A (ja) * 2019-09-30 2021-04-08 株式会社コロプラ プログラム、方法、および配信端末

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8804721B2 (en) 2011-08-31 2014-08-12 International Business Machines Corporation Multi-stream communication
EP2670109B1 (en) * 2012-06-01 2015-07-29 Alcatel Lucent Method, system and devices for multimedia delivering in content delivery networks
US9571540B2 (en) * 2013-09-19 2017-02-14 Verizon Patent And Licensing Inc. Broadcast/multicast offloading and recommending of infrastructural changes based on usage tracking
EP3146735B1 (en) * 2014-05-23 2018-06-27 Sony Corporation A method, apparatus and system for delivering content
WO2023155154A1 (en) * 2022-02-18 2023-08-24 Zte Corporation Method for traffic relay from network to ue

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000181836A (ja) * 1998-12-11 2000-06-30 Nippon Telegr & Teleph Corp <Ntt> 情報配信方法及び情報配信プログラムを記録した記録媒体
JP2004080130A (ja) * 2002-08-12 2004-03-11 Nippon Telegr & Teleph Corp <Ntt> 無線ネットワークシステム、無線基地局および通信方法
JP2004178031A (ja) * 2002-11-25 2004-06-24 Hitachi Ltd 資源配信方法及びシステム

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5831973A (en) * 1995-10-11 1998-11-03 Mitsubishi Denki Kabushiki Kaisha Multicast connection control method and apparatus
US5983278A (en) * 1996-04-19 1999-11-09 Lucent Technologies Inc. Low-loss, fair bandwidth allocation flow control in a packet switch
US6151633A (en) * 1998-04-20 2000-11-21 Sun Microsystems, Inc. Method and apparatus for routing and congestion control in multicast networks
US6615236B2 (en) * 1999-11-08 2003-09-02 Worldcom, Inc. SIP-based feature control
US6850488B1 (en) * 2000-04-14 2005-02-01 Sun Microsystems, Inc. Method and apparatus for facilitating efficient flow control for multicast transmissions
US7054902B2 (en) * 2001-10-23 2006-05-30 Packeteer, Inc. Multicast delivery systems and methods
US20070168523A1 (en) * 2005-04-11 2007-07-19 Roundbox, Inc. Multicast-unicast adapter
US7525965B1 (en) * 2005-06-30 2009-04-28 Sun Microsystems, Inc. Trick play for multicast streams
US7889732B2 (en) * 2005-12-22 2011-02-15 Alcatel-Lucent Usa, Inc. Method for converting between unicast sessions and a multicast session
US20080040500A1 (en) * 2006-08-11 2008-02-14 Veodia, Inc. Method and apparaatus for distributing a media stream

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000181836A (ja) * 1998-12-11 2000-06-30 Nippon Telegr & Teleph Corp <Ntt> 情報配信方法及び情報配信プログラムを記録した記録媒体
JP2004080130A (ja) * 2002-08-12 2004-03-11 Nippon Telegr & Teleph Corp <Ntt> 無線ネットワークシステム、無線基地局および通信方法
JP2004178031A (ja) * 2002-11-25 2004-06-24 Hitachi Ltd 資源配信方法及びシステム

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011259160A (ja) * 2010-06-08 2011-12-22 Nippon Telegr & Teleph Corp <Ntt> 配信方式の切り替えを行う同報システム及びその制御方法
JP2012004948A (ja) * 2010-06-18 2012-01-05 Nec Corp 通信中継装置、通信中継システムおよび通信中継方法
JP2013046175A (ja) * 2011-08-23 2013-03-04 Nippon Telegr & Teleph Corp <Ntt> マルチキャスト配信方法及び送信装置
WO2014148277A1 (ja) * 2013-03-19 2014-09-25 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
JPWO2014148277A1 (ja) * 2013-03-19 2017-02-16 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
US10165035B2 (en) 2013-03-19 2018-12-25 Saturn Licensing Llc Content supplying device, content supplying method, program, and content supplying system
CN105210372A (zh) * 2013-05-22 2015-12-30 索尼公司 内容供应装置、内容供应方法、程序以及内容供应***
US9942619B2 (en) 2013-05-22 2018-04-10 Saturn Licensing Llc Content supply device, content supply method, program, and content supply system
CN105210372B (zh) * 2013-05-22 2019-05-17 索尼公司 内容供应装置、内容供应方法、程序以及内容供应***
WO2019176402A1 (ja) * 2018-03-16 2019-09-19 日本電気株式会社 マルチキャスト制御装置、マルチキャスト制御方法、及び非一時的なコンピュータ可読媒体
US11395106B2 (en) 2018-03-16 2022-07-19 Nec Corporation Multicast control device, multicast control method, and non-transitory computer readable medium
JP2021053182A (ja) * 2019-09-30 2021-04-08 株式会社コロプラ プログラム、方法、および配信端末

Also Published As

Publication number Publication date
US20110191404A1 (en) 2011-08-04
JPWO2010050022A1 (ja) 2012-03-29

Similar Documents

Publication Publication Date Title
WO2010050022A1 (ja) 配信システム、代理サーバおよび配信方法
JP4886500B2 (ja) データ転送装置、及びそのシステム
US7296091B1 (en) System and method for receiving over a network a broadcast from a broadcast source
CN108235042B (zh) 一种多人网络直播方法、装置、加入装置、***、服务器和计算机可读存储介质
JP4861473B2 (ja) コンテンツ配信システム
US20050220132A1 (en) Multicast
WO2009076817A1 (zh) 实现多终端协同控制播放视频数据的方法和播放控制代理
US8203989B2 (en) Distributing content in a communication network
JP4712095B2 (ja) 通信方法および無線通信システム
JP2006270588A (ja) マルチキャスト通信方法及びホームエージェント及び移動ノード
JP2008160196A (ja) Ｉｐ放送受信方法及び受信端末
KR20110009077A (ko) 멀티웨이 피어 투 피어 매체 스트리밍을 위한 방법, 멀티웨이 매체 스트리밍을 위한 방법 및 컴퓨터 판독 가능한 매체
EP2214431B1 (en) Method, system and device for service switching
CN102469294A (zh) 一种视频会议的动态调整媒体内容的方法和***
JP2003169314A (ja) ゲートウェイ装置及び情報配信システム
JP6699231B2 (ja) 情報配信装置、情報配信プログラム、通信端末、通信処理プログラム及び情報配信システム
KR20120051466A (ko) 방송 프로그램 전송 요청 방법 및 이에 대한 방송 프로그램 전송 방법
JP3836843B2 (ja) 情報網を介して複数のチャネルによって配信されるコンテンツを一つの端末によって受信する方法
JP5262675B2 (ja) 映像配信システムおよびユニキャスト型多地点映像配信方法
JP2007180960A (ja) マルチキャスト制御装置
KR100592874B1 (ko) 멀티캐스트 방식의 ｉｐ 방송 방법 및 시스템
JP2004200946A (ja) 放送配信システム
JP2009284268A (ja) マルチキャスト放送システムおよび受信機
CN101483532B (zh) 一种媒体流复制的方法、***及设备
JP5225394B2 (ja) ネットワーク経由でｔｖコンテンツを配信する方法およびシステム

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010535562

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08877733

Country of ref document: EP

Kind code of ref document: A1