JPWO2014064890A1 - 通信システム、受信端末、送信端末、および流量制御方法 - Google Patents

通信システム、受信端末、送信端末、および流量制御方法 Download PDF

Info

Publication number
JPWO2014064890A1
JPWO2014064890A1 JP2014543132A JP2014543132A JPWO2014064890A1 JP WO2014064890 A1 JPWO2014064890 A1 JP WO2014064890A1 JP 2014543132 A JP2014543132 A JP 2014543132A JP 2014543132 A JP2014543132 A JP 2014543132A JP WO2014064890 A1 JPWO2014064890 A1 JP WO2014064890A1
Authority
JP
Japan
Prior art keywords
terminal
packet
transfer
receiving terminal
transmission
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
JP2014543132A
Other languages
English (en)
Other versions
JP6187780B2 (ja
Inventor
衛一 村本
衛一 村本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Management Co Ltd
Original Assignee
Panasonic Intellectual Property Management Co Ltd
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 Panasonic Intellectual Property Management Co Ltd filed Critical Panasonic Intellectual Property Management Co Ltd
Publication of JPWO2014064890A1 publication Critical patent/JPWO2014064890A1/ja
Application granted granted Critical
Publication of JP6187780B2 publication Critical patent/JP6187780B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

ＣＣＮをベストエフォート型のネットワークに適用して実時間ストリームのパケットを伝送する場合において、伝送性能の低下を防ぐことができる受信端末。受信端末（２００）は、受信端末（２００）と、送信端末から送信された実時間ストリームのパケットをキャッシュして転送する転送端末と、の間の利用可能帯域である、第１の利用可能帯域と、受信端末（２００）と送信端末との間の利用可能帯域である、第２の利用可能帯域と、を推定する利用可能帯域推定部（２０５）と、推定された第１の利用可能帯域に基づく頻度で、転送端末に対してパケットの転送の要求を行うことにより、転送端末に対して、第１の利用可能帯域を利用してパケットを転送させ、推定された第２の利用可能帯域を送信端末に対して通知することにより、送信端末に対して、第２の利用可能帯域を利用してパケットを送信させる、ＲＴＣＰ−Ｒ制御部（２０６）と、を有する。

Description

本発明は、実時間ストリームのパケットを伝送する通信システム、および、この通信システムで使用される受信端末、送信端末、および流量制御方法に関する。
近年、非特許文献１に記載のＣＣＮ（Content Centric Network：コンテンツ中心型ネットワーク）と呼ばれる技術が注目されている。ＣＣＮは、コンテンツをコンテンツの名前に基づいて管理するコンテンツ配信基盤である。
ＣＣＮでは、配信の対象となる各コンテンツ、もしくは、コンテンツを分割した各データに対して、予め名前が付与される。コンテンツを取得する受信端末は、「インタレストパケット（interest packet）」と呼ばれるパケットを発行する。インタレストパケットとは、コンテンツの名前（以下「コンテンツ名」という）を指定してコンテンツの送信を要求するパケットである。
コンテンツを出版した端末（送信端末）は、インタレストパケットを受信すると、当該インタレストパケットが指定するコンテンツ名に対応するコンテンツを、受信端末へ送信する。これにより、各受信端末は、コンテンツの所在が分からなくても、コンテンツ名に基づいてコンテンツを取得することができる。
また、ＣＣＮのメリットとして、過去にコンテンツの転送を行ったルータからコンテンツを取得可能である点が挙げられる。ＣＣＮにおいて、各ルータは、送信端末から受信端末へと転送するコンテンツを、キャッシュ（一定時間蓄積）する。そして、各ルータは、受信したインタレストパケットが指定するコンテンツをキャッシュしている場合、当該コンテンツを受信端末へ送信する。これにより、ＣＣＮでは、送信端末から当該ルータまでのコンテンツの伝送を再度行うことなく、コンテンツを受信端末へ送信することができる。
ＣＣＮにおける流量制御（フロー制御）の手法は、例えば、非特許文献１、特許文献１、および非特許文献３に記載されている。
非特許文献１に記載の流量制御は、ＴＣＰ（Transmission Control Protocol）がＡＣＫ（acknowledgement）を返送するのと同等のタイミングで、コンテンツを細かく分割したパーツ毎に、インタレストパケットを発行する。
このような流量制御によれば、受信端末は、ＴＣＰのＡＣＫが返送されるのと同等のタイミングで、コンテンツを取得することができる。
また、特許文献１および非特許文献３に記載の流量制御は、ＣＣＮ上でＶＯＩＰ（Voice Over IP）を実現するＶｏｉｃｅ Ｏｖｅｒ ＣＣＮにおける、流量制御である。Ｖｏｉｃｅ Ｏｖｅｒ ＣＣＮにおいて、各端末は、呼制御情報を、ＣＣＮのインタレストパケットを用いて伝送する。そして、各端末は、呼のネゴシエーションを行い、音声のＲＴＰ（Real-time Transport Protocol）パケットを送受信する準備を行う。受信端末は、音声データに対するインタレストパケットを定期的に発行する。送信端末は、インタレストパケットを受信する毎に、音声データを細かく分割したデータを格納したパケットを、順次、受信端末へ送信する。以下、音声データを分割したデータを格納したパケットは、「データパケット」という。
このような流量制御によれば、受信端末は、音声の実時間ストリームを、一定レートで取得することができる。また、上述の通り、ＣＣＮのルータは、実時間ストリームをキャッシュする。このため、最初にデータパケットの受信を開始した受信端末とは別の受信端末（以下、「他の受信端末」という）は、当該データパケットに対するインタレストパケットを発行する。このことにより、他の受信端末は、データパケットを、送信端末ではなくルータから取得することができる。
このように、ＣＣＮは、非特許文献１に記載の流量制御、および、特許文献１および非特許文献３に記載の流量制御を適用することにより、コンテンツを効率的に配布することができる。したがって、上述の流量制御を適用したＣＣＮは、特に、実時間ストリームの配布に好適である。
ところで、近年、インターネットでは、動画ファイルや音声ファイルなど実時間ストリームのやり取りが活発に行われるようになってきている。このため、動画ファイルや音声ファイルなど実時間ストリームの伝送では、インターネットへのＣＣＮの適用が期待される。
ところが、インターネットは、サービスの品質（ＱｏＳ）が保証されないベストエフォート型ネットワーク（best effort network）であり、トラフィックが互いに競合している。このため、インターネットにおいて各送信端末が利用可能な帯域は、変動する。
このようなネットワークを介した実時間ストリームの伝送には、実時間ストリームのパケットがネットワークへ送出される流量を制御して、パケット落ちを防ぐ必要がある。実時間ストリームのパケットの流量を制御するためには、データ送信に利用することが可能な帯域（以下「利用可能帯域」という）を推定する手法が用いられる。そして、かかる流量の制御には、推定した利用可能帯域を利用してパケットが送信されるように実時間ストリームのエンコーダの符号量を制御する手法が、用いられる。
このような、ベストエフォート型ネットワークにおける適応流量制御のための帯域推定の手法は、例えば、非特許文献２に記載されている。
非特許文献２に記載のＴＦＲＣ（TCP Friendly Rate Control）は、送信端末と受信端末の間の、往復時間ＲＴＴ（Round Trip Time）および損失イベント率ｐを、計測する。そして、ＴＦＲＣは、計測された往復時間ＲＴＴおよび損失イベント率ｐを、以下の式（１）に代入することにより、利用可能帯域の推定値［ｂｐｓ］Ｘｃａｌを計算する。なお、式（１）において、ｓは、パケットサイズ［バイト］を示し、Ｒは、往復時間ＲＴＴの代表値［秒］を示し、ｔ＿ＲＴＯは、再送タイムアウトを示す。再送タイムアウトｔ＿ＲＴＯは、４Ｒである。
Figure 2014064890
このようにして推定された利用可能帯域を利用したコンテンツの送信では、ＴＣＰ公平性が保たれるような、流量制御を行うことができる。すなわち、ベストエフォート型ネットワークは、非特許文献２に記載の流量制御を適用することにより、ＴＣＰ公平性が保たれた状態での実時間ストリーム配信を実現することができる。
以上のように、ＣＣＮを対象とした特許文献１および非特許文献３と、ベストエフォート型ネットワークを対象とした非特許文献２とでは、異なる流量制御が提案されている。そこで、インターネットなどのベストエフォート型ネットワークでは、ＣＣＮを用いて映像音声データなどの実時間ストリームを伝送する場合、ＴＦＲＣの帯域推定手法をＣＣＮ上に実装し、その推定値に基づいた流量制御が考えられる。
米国特許出願公開第２００９／０２８５２０９号明細書
V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, R. L. Braynard (PARC) "Networking Named Content", Italy, CoNEXT 2009, December, 2009. M. Handley, S. Floyd, J. Padhye, J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC3448, January 2003 V. Jacobson, D. K. Smetters, N. H. Briggs, M. F. Plass, P. Stewart, J. D. Thornton, R. L. Braynard (PARC), "VoCCN: Voice Over Content-Centric Networks", ReArch ’09, Italy, December, 2009.
しかしながら、実際には、上述のタイミングでインタレストパケットを発行するＣＣＮに対して、上位層における流量制御であるＴＦＲＣを実装した場合、ＴＦＲＣにおける利用可能帯域の推定を正しく行うことができない。
この理由は、下位層の流量制御（ＴＣＰと同等の動作を行うＣＣＮのプロトコル動作）と上位層の流量制御（ＴＦＲＣ）とが、干渉することになるためである。そして、これにより、それぞれの流量制御は、設計意図の通りに流量制御が行われず、結果として、伝送性能が劣化してしまうためである。すなわち、従来技術は、ＣＣＮをベストエフォート型ネットワークに適用して実時間ストリームのパケットを伝送する場合、伝送性能が低下するという課題を有する。
本発明の目的は、ＣＣＮをベストエフォート型のネットワークに適用して実時間ストリームのパケットを伝送する場合において、伝送性能の低下を防ぐことである。
本開示の通信システムは、実時間ストリームのパケットを送信する送信端末と、前記パケットを転送する転送端末と、前記パケットを受信する受信端末と、を有する通信システムであって、前記転送端末は、前記送信端末から送信された前記パケットをキャッシュするキャッシュ部と、前記受信端末からの要求に応じて、前記キャッシュ部にキャッシュされた前記パケットを前記受信端末へ転送する転送スタックと、を有し、前記受信端末は、前記受信端末と前記転送端末との間の利用可能帯域である第１の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第２の利用可能帯域と、を推定する利用可能帯域推定部と、前記転送端末が推定された前記第１の利用可能帯域を利用して前記パケットの転送を行うように、前記転送端末に対して前記パケットの転送の要求を行い、推定された前記第２の利用可能帯域を前記送信端末に対して通知するＲＴＣＰ−Ｒ制御部と、を有し、前記送信端末は、前記受信端末から通知された前記第２の利用可能帯域を利用して、前記パケットの送信を行う送信スタックと、を有する。
本開示の受信端末は、実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける前記受信端末であって、前記受信端末と前記転送端末との間の利用可能帯域である第１の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第２の利用可能帯域と、を推定する利用可能帯域推定部と、推定された前記第１の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第１の利用可能帯域を利用して前記パケットを転送させ、推定された前記第２の利用可能帯域を前記送信端末に対して通知することにより、前記送信端末に対して、前記第２の利用可能帯域を利用して前記パケットを送信させる、ＲＴＣＰ−Ｒ制御部と、を有する。
本開示の送信端末は、実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける前記送信端末であって、前記実時間ストリームのデータを格納した前記パケットを送信する送信スタックと、前記受信端末と前記転送端末との間の利用可能帯域である第１の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第２の利用可能帯域と、を推定し、推定された前記第１の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第１の利用可能帯域を利用して前記パケットを転送させる前記受信端末から、前記第２の利用可能帯域の通知を受けるＲＴＣＰ−Ｓ制御部と、前記送信スタックに対して、前記受信端末から通知された前記第２の利用可能帯域を利用して前記パケットの送信を行わせる送信帯域推定部と、を有する。
本開示の流量制御方法は、実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける流量制御方法であって、前記受信端末において、前記受信端末と前記転送端末との間の利用可能帯域である第１の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第２の利用可能帯域と、を推定するステップと、前記受信端末において、推定された前記第１の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第１の利用可能帯域を利用して前記パケットを転送させ、推定された前記第２の利用可能帯域を前記送信端末に対して通知することにより、前記送信端末に対して、前記第２の利用可能帯域を利用して前記パケットを送信させるステップと、を有する。
本開示によれば、ＣＣＮをベストエフォート型ネットワークに適用して実時間ストリームのパケットを伝送する場合において、伝送性能の低下を防ぐことができる。
下位層の流量制御におけるスループットの時間変化および上位層の流量制御におけるスループットの時間変化を示す図 本発明の実施の形態１に係る通信システムの各装置の構成を示すブロック図 本発明の実施の形態２に係る通信システムの構成の一例を示すシステム構成図 本発明の実施の形態２におけるコンテンツ名の一例を示す図 本発明の実施の形態２におけるインタレストパケットの構成の一例を示す模式図 本発明の実施の形態２におけるデータパケットの構成の一例を示す模式図 本発明の実施の形態２に係る各装置の構成の一例を示すブロック図 本発明の実施の形態２に係る受信端末の動作の一例を示すフローチャート 本発明の実施の形態２に係る受信端末の帯域推定処理の一例を示すフローチャート 本発明の実施の形態２におけるインタレストパケット発行処理の一例を示すフローチャート 本発明の実施の形態２に係る送信端末の動作の一例を示すフローチャート 本発明の実施の形態２に係るＣＣＮルータ（転送端末）の動作の一例を示すフローチャート 本発明の実施の形態２に係る通信システムの他の構成の第１の例を示すシステム構成図 本発明の実施の形態２における近接往復時間ＲＴＴｎの計測の様子を示す模式図 本発明の実施の形態２に係る通信システムの他の構成の第２の例を示すシステム構成図
本発明の各実施の形態の説明に先立ち、本発明が生まれた背景について説明する。具体的には、ＣＣＮをベストエフォート型ネットワークに適用して実時間ストリームのパケットを伝送する場合において発生する、伝送性能の低下の原因解析とその解決方法について、説明する。
上記性能劣化が発生する原因としては、２つの現象が存在する。
背景技術で説明した往復時間ＲＴＴの計測は、送信端末がパケットに送信時刻を刻印し、受信端末が当該パケットの受信時刻を送信端末に返送し、送信端末が、送信時刻と受信時刻との差を算出することにより、行われる。ところが、下位層でＴＣＰと同等のタイミングでパケットが伝送されていると、下位層のＣＣＮのプロトコルスタックでは、パケットの送信が待たされることがある。これは、下位層において、ＴＣＰの輻輳ウインドウ制御と同等の動作が行われるためである。
このように、往復時間ＲＴＴの計測値は、下位層のＣＣＮのプロトコルスタックで待たされた時間の分、大きくなる。往復時間ＲＴＴは、上述の式（１）において、分母に用いられる項である。したがって、上位層におけるＴＦＲＣによる利用可能帯域の推定値は、実際の利用可能帯域よりも小さくなる（第１の現象）。
一方、下位層がＴＣＰと同等の動作を行うことによって、最大のスループットを得るには、常に送るべきデータが用意されていることが前提となっている。ところが、下位層がパケットを送信すべきタイミングにあるにもかかわらず、送信すべきパケットが用意されていない場合、下位層プロトコルにとっては、パケット送信の機会を損失することになる。例えば、複数のＴＣＰフローが単一のボトルネックリンクを共有しているような場合、特定のフローに送るべきデータが存在しないタイミングが存在すると、その特定のフローは、パケット送信の機会を損失する。
したがって、上述のように、上位層における利用可能帯域の推定値が、実際の利用可能帯域（下位層で期待する帯域）を下回る場合、送りたくても送るべきパケットが存在しないことになる。すなわち、下位層プロトコルでは、本来得ることができるはずのスループット（ＴＣＰ公平なスループット）が、得られないことになる（第２の現象）。
図１は、下位層の流量制御（ＴＣＰと同等の動作を行うＣＣＮのプロトコル動作）が行われる場合のスループットの時間変化と、上位層の流量制御（ＴＦＲＣ）が行われる場合のスループットの時間変化とを、示した図である。
ＴＣＰでは、輻輳回避モードとなると、ロスが発生するまで直線的に送信量（輻輳ウインドウ）を増加し、ロスが発生すると送信量を半減させるという動作が繰り返される。したがって、図１に示すように、ＴＣＰのスループット１０１は、直角三角形状（鋸形状）の変化を繰り返す。
一方、ＴＦＲＣでは、損失イベント率ｐの計算や往復時間ＲＴＴの計算は、指数荷重移動平均が用いられることにより、過去の値に引きずられる。したがって、図１に示すように、ＴＦＲＣのスループット１０２は、滑らかな増減を繰り返す。なお、ＴＣＰのスループット１０１の平均値、および、ＴＦＲＣのスループット１０２の平均値は、所定の一定値１０３に近づく。
ＴＣＰのスループット１０１がＴＦＲＣのスループット１０２より低い区間では、上述の第１の現象が発生する。そして、ＴＦＲＣのスループット１０２がＴＣＰのスループット１０１より低い区間では、上述の第２の現象が発生する。
このように、下位層の流量制御と上位層の流量制御とを単純に組み合わせるのみでは、これらの異なる流量制御が互いに干渉し合い、実時間ストリームの伝送性能の低下をもたらすことになる。そして、その結果、受信端末が再生する映像音声などのコンテンツの品質は、低下する。
そこで、本発明は、受信端末とパケットを転送する転送端末との間の利用可能帯域を推定し、その推定結果に基づいて、下位層の流量制御を行う。そして、本発明は、受信端末とパケットの送信元である送信端末との間の利用可能帯域とを推定し、その推定結果に基づいて、上位層の流量制御を行う。これにより、本発明は、下位層の流量制御と上位層の流量制御とが互いに悪影響を及ぼすのを防ぐ。すなわち、本発明は、ＣＣＮをベストエフォート型ネットワークに適用した実時間ストリームのパケットの伝送において、伝送性能の低下を防止する。
以下、本発明の各実施の形態について、図面を参照して詳細に説明する。
（実施の形態１）
本発明の実施の形態１は、本発明の基本的態様の一例である。
より具体的には、本実施の形態は、送信端末、転送端末、および受信端末を有する通信システムに関するものである。ここで、送信端末は、実時間ストリームのパケットを送信する端末（出版元、Publisher）である。転送端末は、送信端末から送信されたパケットをキャッシュして転送する端末である。受信端末は、転送端末から転送されたパケットを受信する端末である。
図２は、本実施の形態に係る通信システムの各装置の構成を示すブロック図である。
図２において、通信システム３００は、送信端末４００、転送端末（ＣＣＮルータ）５１０、および受信端末２００を有する。
転送端末５１０は、キャッシュ部５１１および転送スタック５１２を有する。
キャッシュ部５１１は、送信端末４００から送信されたパケットをキャッシュする。
転送スタック５１２は、受信端末２００からの要求に応じて、キャッシュ部５１１にキャッシュされたパケットを受信端末２００へ転送する。
受信端末２００は、受信スタック２０１、利用可能帯域推定部２０５、およびＲＴＣＰ−Ｒ制御部２０６を有する。
受信スタック２０１は、受信端末２００と転送端末５１０との間でパケットの受信を含む通信を行う。
利用可能帯域推定部２０５は、受信端末２００と転送端末５１０との間の利用可能帯域である第１の利用可能帯域と、受信端末２００と送信端末４００との間の利用可能帯域である第２の利用可能帯域とを推定する。
ＲＴＣＰ−Ｒ制御部２０６は、転送端末５１０が推定された第１の利用可能帯域を利用してパケットの転送を行うように、転送端末５１０に対してパケットの転送の要求を行う。また、ＲＴＣＰ−Ｒ制御部２０６は、推定された第２の利用可能帯域を送信端末４００に対して通知する。この通知は、例えば、受信スタック２０１および転送端末５１０を介して行われる。
送信端末４００は、送信スタック４０１、ＲＴＣＰ−Ｓ制御部４０６、および送信帯域推定部４０７を有する。
送信スタック４０１は、実時間ストリームのデータを格納したパケットを送信する。
ＲＴＣＰ−Ｓ制御部４０６は、受信端末から、第２の利用可能帯域の通知を受ける。
送信帯域推定部４０７は、送信スタック４０１に対して、受信端末２００から通知された第２の利用可能帯域を利用してパケットの送信を行わせる。
また、受信端末２００、送信端末４００、および転送端末５１０は、図示しないが、例えば、ＣＰＵ（Central Processing Unit）、制御プログラムを格納したＲＯＭ（Read Only Memory）などの記憶媒体、ＲＡＭ（Random Access Memory）などの作業用メモリ、および通信回路などを、それぞれ有する。この場合、上記した各部の機能は、ＣＰＵが制御プログラムを実行することにより実現される。
このような本実施の形態に係る通信システム３００は、受信端末２００と転送端末５１０との間の利用可能帯域に基づいた転送端末５１０の流量制御を、実現することができる。そして、本実施の形態に係る通信システム３００は、かかる流量制御と併せて、受信端末２００と送信端末４００との間の利用可能帯域の推定値に基づいた送信端末４００の流量制御を、実現することができる。
送信端末４００、転送端末５１０、および受信端末２００は、例えば、それぞれＣＣＮに対応した端末とすることができる。この場合、転送端末５１０の流量制御は、上述の下位層の流量制御（ＴＣＰと同等の動作を行うＣＣＮのプロトコル動作）であり、送信端末４００の流量制御は、上述の上位層の流量制御（ＴＦＲＣ）である。したがって、受信端末２００と転送端末５１０との間の利用可能帯域に基づいた転送端末５１０の流量制御を行うことにより、上述の第１の現象を回避することができる。また、受信端末２００と送信端末４００との間の利用可能帯域の推定値に基づいた送信端末４００の流量制御を行うことにより、送信端末４００で推定帯域に則したデータの生成量が制御しやすくなる。すなわち、かかる流量制御により、上述の第２の現象を回避することができる。
すなわち、本実施の形態に係る受信端末２００は、インターネットなどのベストエフォート型ネットワークでＣＣＮを下位層に適用した場合でも、上位層の流量制御の性能を劣化させることがない帯域推定を可能にする。下位層のＣＣＮの流量制御が上位層の流量制御を妨げないため、ＴＣＰ公平性が上位層で保証される。これにより、受信端末２００は、ＴＣＰ公平性を満たしながら、映像音声などの実時間ストリームの流量をネットワークの混雑度合に応じて適応的に制御し、適切な送信レートが実現されるようにすることができる。
すなわち、本実施の形態に係る受信端末２００は、ＣＣＮをベストエフォート型ネットワークに適用して実時間ストリームのパケットを伝送する場合において、伝送性能の低下を防ぐことができる。
なお、ＣＣＮに対応したルータ（以下「ＣＣＮルータ」という）にキャッシュされた実時間ストリームは、既に送信端末から出版されて蓄積されたものである。このようなキャッシュ済みのストリームの送信には、ＣＣＮルータから受信端末への利用可能帯域は影響するが、送信端末からＣＣＮルータへの利用可能帯域は影響しない。これにより、キャッシュ済みのストリームについては、送信端末による本来の送信レートよりも高いレートで受信することが可能となり、受信端末において本来の再生速度よりも速い速度で再生することが可能である。
例えば、他の受信端末がインタレストパケットを２倍の頻度で発行すれば、データパケットは、倍速でルータ上のキャッシュから伝送されてくる。そして、他の受信端末が受信したデータパケットから抽出した音声データを、音の高さを調整しながら倍速再生させれば、他の受信端末のユーザは、音声データの最後まで、後から追い付いて聞くことができる。
したがって、Ｖｏｉｃｅ Ｏｖｅｒ ＣＣＮでは、既に開始されている会話に、第三者が途中から参加するようなアプリケーションを、構築することができる。
このようなアプリケーションにおいて、送信端末からＣＣＮルータへと実時間ストリームを送信するのに適した送信レートと、ＣＣＮルータから受信端末へと実時間ストリームを送信するのに適した送信レートとは、必ずしも一致しない。したがって、本実施の形態に係る受信端末２００は、このようなアプリケーションに好適である。
（実施の形態２）
本発明の実施の形態２は、本発明の具体的態様の一例である。
より具体的には、本実施の形態は、ＣＣＮに対応した送信端末、ＣＣＮに対応した転送端末、およびＣＣＮに対応した受信端末を含む通信システムにおける、ＣＣＮに対応した受信端末に関するものである。ここで、送信端末は、実時間ストリームである映像データのパケットを送信（出版）する端末である。転送端末は、送信端末から送信されたパケットをキャッシュして転送するルータである。受信端末は、転送端末から転送されたパケットを受信する端末である。
まず、本実施の形態に係る通信システムの構成について説明する。
＜通信システムの構成＞
図３は、本実施の形態に係る通信システムの構成の一例を示すシステム構成図である。
図３において、通信システム３００は、送信端末４００、第１の受信端末２００１、および第２の受信端末２００２を有する。これらの端末は、ＣＣＮネットワーク５００に接続されている。
ＣＣＮネットワーク５００は、ＣＣＮに対応した複数の転送端末（以下「ＣＣＮルータ」という）５１０と、ＣＣＮに対応していない複数の転送端末（以下「非ＣＣＮルータ」という）５２０とを有する。そして、ＣＣＮネットワーク５００は、これらを接続する複数のネットワーク回線５３０を有する。
第１の受信端末２００１および第２の受信端末２００２は、同一のＣＣＮルータである第１のＣＣＮルータ５１０１に接続している。すなわち、送信端末４００から第１の受信端末２００１へと至る経路と、送信端末４００から第２の受信端末２００２へと至る経路とは、第１のＣＣＮルータ５１０１まで共通しており、第１のＣＣＮルータ５１０１において枝分かれしている。
ＣＣＮネットワーク５００は、ＣＣＮネットワークであり、図示する以外にも多数の端末が接続され、多数の端末が互いにネットワーク回線５３０の帯域を共有する、ベストエフォート型ネットワークである。
ＣＣＮネットワーク５００における競合トラフィックとしては、現在のインターネットと同様に、ＨＴＴＰ（Hyper Text Transfer Protocol）、あるいは、ＦＴＰ（File Transfer Protocol）などの、いわゆるＴＣＰのトラフィックが大半を占めているものとする。すなわち、ＣＣＮネットワーク５００は、ＴＣＰ公平性が要求されるネットワークである。
第１の受信端末２００１および第２の受信端末２００２は、同一の構成を有するため、これらを、適宜、「受信端末２００」としてまとめて説明する。送信端末４００、受信端末２００、およびＣＣＮルータ５１０の構成については、後述する。非ＣＣＮルータ５２０は、従来のルータなどの転送端末と同様の構成を有しているため、これの構成についての説明を省略する。また、ＣＣＮに対応したノードである、送信端末４００、ＣＣＮルータ５１０、および受信端末２００は、適宜、「ＣＣＮノード」と総称する。
また、受信端末２００は、上述のＶｏｉｃｅ Ｏｖｅｒ ＣＣＮを用いて、映像データの配信を受けるものとする。すなわち、受信端末２００は、映像データを細かく分割したデータ（以下「分割データ」という）のそれぞれに対して、順次、インタレストパケットを発行するものとする。
＜通信方式の概要＞
次に、通信システム３００における通信方式の概要について説明する。
通信システム３００において、ＣＣＮの転送の対象となる全ての実時間データストリームには、予め名前が付与されている。実時間データストリームに付与された名前は、以下、「コンテンツ名」という。
＜コンテンツ名の例＞
図４は、コンテンツ名の一例を示す図である。
図４に示すように、コンテンツ名６１０は、ユーザ／アプリケーション提供元名（user/app supplied name）領域６１１と、バージョニング・セグメンテーション（versioning & Segmentation）領域６１２とから成る。ユーザ／アプリケーション提供名領域６１１は、グローバリルータブル名（globally-routable name）領域６１３と、機関名（organizational name）領域６１４とからなる。バージョニング・セグメンテーション領域６１２は、慣習的にあるいは自動的に決定される部分（conventional/automatic）である。なお、コンテンツ名６１０は、例えば、バイナリエンコーディングされて使用される。
コンテンツを取得する受信端末２００は、コンテンツ名を指定して、コンテンツの送信を要求するインタレストパケットを発行する。
なお、本実施の形態において、コンテンツ名は、元の映像データの出版元の識別情報と、呼を特定するＩＤ（Call-ID）と、分割データの通番（ＲＴＰの通番）と、タイムスタンプと、を含む名前空間である。
＜インタレストパケットの構成例＞
図５は、インタレストパケットの構成の一例を示す模式図である。
図５に示すように、インタレストパケット６２０は、コンテンツ名（content name）６２１、セレクタ（selector）６２２、およびノンス（nonce）６２３を含む。コンテンツ名６２１は、インタレストパケット６２０の送信元が返信を要求する対象として指定する映像データの分割データのコンテンツ名である。ノンス６２３は、使い捨て乱数値である。セレクタ６２２は、要求の優先度、発行元のフィルタ、スコープなどである。
このようなインタレストパケット６２０は、映像データの分割データを指定し、指定した分割データの配信が、インタレストパケット６２０の送信元によって要求されていることを示すことができる。なお、図示しないが、インタレストパケット６２０には、インタレストパケット６２０の送信元を示す情報その他が付与されている。
インタレストパケットが指定する分割データを保持（キャッシュを含む）しているＣＣＮノードは、インタレストパケットを受信すると、指定された分割データ（主信号）を格納したパケットを生成する。分割データを格納したパケットは、以下、「データパケット」という。そして、当該ＣＣＮノードは、生成したデータパケットを、インタレストパケットの送信元へ送信する。
＜データパケットの構成例＞
図６は、データパケットの構成の一例を示す模式図である。
図６に示すように、データパケット６３０は、コンテンツ名（content name）６３１、署名（signature）６３２、署名済み情報（signed Info）６３３、およびデータ（data）６３４を含む。
データ６３４は、データパケット６３０が格納する分割データである。コンテンツ名６３１は、データパケット６３０が格納する分割データのコンテンツ名である。署名６３２は、データパケット６３０が格納する分割データに対する、ダイジェスト・アルゴリズム（digest algorithm）、あるいは、ウィットネス（witness）などによる電子署名である。署名済み情報６３３は、署名済みの、出版元ＩＤ、キーロケータ（key locator）、遅延時間（stale time）などを含む。
このようなデータパケット６３０は、分割データが真正であることを証明しつつ、映像データの分割データを格納して伝送することができる。なお、図示しないが、データパケット６３０には、データパケット６３０送信元および送信先を示す情報その他が付与されている。
このような通信方式により、通信システム３００の各受信端末２００は、コンテンツの所在が分からなくても、コンテンツ名に基づいて、コンテンツを取得することができる。
次に、受信端末２００、送信端末４００、およびＣＣＮルータ５１０のそれぞれの構成について説明する。
図７は、受信端末２００、送信端末４００、およびＣＣＮルータ５１０の構成の一例を示すブロック図である。
＜受信端末の説明＞
図７において、受信端末２００は、ＣＣＮ受信スタック２０１、受信側通話制御アプリ２０３、受信側呼制御変換部２０２、ＲＴＰ−Ｒ変換部２０４、映像デコーダ２０７、利用可能帯域推定部２０５、およびＲＴＣＰ−Ｒ制御部２０６を有する。
ＣＣＮ受信スタック２０１は、ＣＣＮのプロトコル動作を行い、特に、データインタレストパケットの送信に対応して、データパケットの受信を行う。本実施の形態において、ＣＣＮ受信スタック２０１は、コンテンツ名を指定したインタレストパケットを連続して発行し、データパケットを取得することにより、映像データのストリーミング伝送を実現する。ＣＣＮ受信スタック２０１は、受信したデータパケットを、ＲＴＰ−Ｒ変換部２０４へ出力する。また、ＣＣＮ受信スタック２０１は、インタレストパケットの発行時刻と、データパケットの到着時刻とを、記録し、ＲＴＰ−Ｒ変換部２０４へ通知する。
受信側呼制御変換部２０２は、ＣＣＮ受信スタック２０１を介して、他のＣＣＮノードとの呼を確立し、通信で使用するコーデックおよびポート番号等を確定する。すなわち、受信側呼制御変換部２０２は、ＳＩＰ（Session Initiation Protocol）による通信制御を、ＣＣＮのインタレストパケットに乗せて、他のＣＣＮノードと交換する（非特許文献３参照）。
受信側通話制御アプリ２０３は、通信制御アプリケーションであり、受信側呼制御変換部２０２を介して、ＣＣＮ受信スタック２０１に対し、他のＣＣＮノードとの通信の開始および終了を指示する。また、受信側通話制御アプリ２０３は、ＣＣＮ受信スタック２０１および映像デコーダ２０７に対し、追い付き再生の開始および終了を指示する。追い付き再生の詳細については、後述する。
ＲＴＰ−Ｒ変換部２０４は、ＣＣＮ受信スタック２０１から入力されたデータパケットから、分割データを抽出し、ＲＴＰの通番の順序に従って、抽出した分割データを、映像デコーダ２０７へ出力する。また、ＲＴＰ−Ｒ変換部２０４は、受信端末２００と、ＣＣＮ受信スタック２０１により行われた他のＣＣＮノードとの間の通信から、受信端末２００と当該他のＣＣＮノードとの間の損失イベント率ＰおよびＲＴＴを算出する。そして、ＲＴＰ−Ｒ変換部２０４は、算出した損失イベント率Ｐおよび往復時間ＲＴＴを、利用可能帯域推定部２０５へ出力する。
損失イベント率Ｐは、例えば、データパケットの通番の隔たりを監視することによってデータパケットの損失を検出し、データパケットの損失から、非特許文献３に記載の手法を用いて、算出することができる。
また、往復時間ＲＴＴは、例えば、インターネット関連技術の標準化団体であるＩＥＴＦ（Internet Engineering Task Force）が発行したＲＦＣ３５５０に記載された手法を用いて、算出することができる。かかる手法は、送信側ＳＲ（Sender Report）の送信時刻を記録し、ＲＲ（Receiver Report）によって受信側から返送される情報に基づいて、往復時間ＲＴＴを算出する手法である。受信側から返送される情報は、例えば、タイムスタンプ、および、受信端末２００内部でのＳＲ受信からＲＲ送信までの間の遅延時間の情報（DLSR:Delay since Last SR）である。
以下の説明において、それぞれの受信端末２００が取得の目的とする映像データを保持（キャッシュを含む）している、ＣＣＮノードのうち、受信端末２００に最も近接するＣＣＮノードは、「近接ＣＣＮノード」という。どのＣＣＮノードが近接ＣＣＮノードとなるかは、取得の目的となる映像データ、受信端末２００のＣＣＮネットワーク５００との接続位置、および、ＣＣＮネットワーク５００における当該映像データの保持状態の変化、に応じて異なる。
また、受信端末２００と近接ＣＣＮノードとの間の損失イベント率Ｐは、「近接損失イベント率Ｐｎ」（第１の損失イベント率）という。受信端末２００と近接ＣＣＮノードとの間（図７に示す矢印６４１の区間）の往復時間ＲＴＴは、「近接往復時間ＲＴＴｎ」（第１のＲＴＴ）という。受信端末２００と送信端末４００との間（図７に示す矢印６４２の区間）の損失イベント率Ｐは、「通常損失イベント率Ｐｓ」（第２の損失イベント率）という。受信端末２００と送信端末４００との間の往復時間ＲＴＴは、「通常往復時間ＲＴＴｓ」（第２のＲＴＴ）という。
利用可能帯域推定部２０５は、入力された損失イベント率Ｐおよび往復時間ＲＴＴから、上述の式（１）を用いて、受信端末２００と対応するＣＣＮノードとの間の利用可能帯域の推定値Ｘｃａｌを算出する。そして、利用可能帯域推定部２０５は、算出した利用可能帯域の推定値Ｘｃａｌを、ＲＴＣＰ−Ｒ制御部２０６へ出力する。
以下の説明において、近接損失イベント率Ｐｎおよび近接往復時間ＲＴＴｎから算出された、受信端末２００と近接ＣＣＮノードとの間の利用可能帯域の推定値Ｘｃａｌは、「近接帯域推定値Ｘｃａｌｎ」（第１の利用可能帯域）という。通常損失イベント率Ｐｓおよび通常往復時間ＲＴＴｓから算出された、受信端末２００と送信端末４００との間の利用可能帯域の推定値Ｘｃａｌは、「通常帯域推定値Ｘｃａｌｓ」（第２の利用可能帯域）という。
なお、利用可能帯域推定部２０５は、近接帯域推定値Ｘｃａｌｎを、受信側通話制御アプリ２０３にも通知する。これは、後述の追い付き再生のためである。
ＲＴＣＰ−Ｒ制御部２０６は、近接ＣＣＮノードが近接帯域推定値Ｘｃａｌｎにより示される帯域を利用してデータパケットの転送を行うように、近接ＣＣＮノードに対してデータパケットの転送の要求を行う。より具体的には、ＲＴＣＰ−Ｒ制御部２０６は、近接帯域推定値Ｘｃａｌｎを、ＣＣＮ受信スタック２０１へ出力する。そして、ＲＴＣＰ−Ｒ制御部２０６は、ＣＣＮ受信スタック２０１に対して、取得の対象となる映像データの分割データをコンテンツ名により指定したインタレストパケットを、近接帯域推定値Ｘｃａｌｎに対応する間隔で順次送信させる。
また、ＲＴＣＰ−Ｒ制御部２０６は、通常帯域推定値Ｘｃａｌｓを、ＣＣＮ受信スタック２０１を介して、送信端末４００に対して通知する。この結果、後述するが、送信端末４００は、通常帯域推定値Ｘｃａｌｓが示す帯域を利用して、映像データの分割データの送信を行う。この分割データは、上述の通り、ＣＣＮ受信スタック２０１およびＲＴＰ−Ｒ変換部２０４を介して、映像デコーダ２０７へ入力される。
なお、ＲＴＣＰ−Ｒ制御部２０６は、通常帯域推定値Ｘｃａｌｓに加えて、通常帯域推定値Ｘｃａｌｓ以外の付加情報を送信端末４００に対して通知してもよい。付加情報は、例えば、映像データのうち再生中のデータ部分が格納されていたデータパケットのタイムスタンプ、当該データパケットの通番、送信端末４００と受信端末２００との間の往復時間ＲＴＴ、を示す情報等を含む。
映像デコーダ２０７は、ＲＴＰ−Ｒ変換部２０４から入力された分割データから基の映像データをデコードし、デコードされた映像データを、受信端末２００に接続された映像表示装置やレコーダなどの映像出力装置（図示せず）へ出力する。また、映像デコーダ２０７は、デコード中の映像データのデータ量を、例えば、データパケットのヘッダ情報から取得し、受信側通話制御アプリ２０３へ通知する。これは、後述の追い付き再生のためである。
なお、利用可能帯域と遅延（往復時間ＲＴＴの半分）との積は、送信端末４００と受信端末２００との間と、ＣＣＮルータ５１０と受信端末２００との間で、異なることになる。
＜送信端末の説明＞
図７において、送信端末４００は、ＣＣＮ送信スタック４０１、送信側通話制御アプリ４０３、送信側呼制御変換部４０２、映像エンコーダ４０４、ＲＴＰ−Ｓ変換部４０５、ＲＴＣＰ−Ｓ制御部４０６、および送信帯域推定部４０７を有する。
ＣＣＮ送信スタック４０１は、ＣＣＮのプロトコル動作を行い、特に、インタレストパケットの受信に対応して、データパケットの送信を行う。
なお、ＲＴＣＰ−Ｓ制御部４０６は、受信端末２００から通常帯域推定値Ｘｃａｌｓを通知される。このとき、ＣＣＮ送信スタック４０１は、送信帯域推定部４０７の機能により、通常帯域推定値Ｘｃａｌｓを利用してデータパケットの送信を行うことになる。
送信側呼制御変換部４０２は、ＣＣＮ送信スタック４０１を介して、他のＣＣＮノードとの呼を確立し、通信で使用するコーデックおよびポート番号等を確定する。すなわち、送信側呼制御変換部４０２は、ＳＩＰによる通信制御を、ＣＣＮのデータパケットに乗せて、他のＣＣＮノードと交換する（非特許文献３参照）。
送信側通話制御アプリ４０３は、通信制御アプリケーションであり、送信側呼制御変換部４０２を介して、ＣＣＮ送信スタック４０１に対し、他のＣＣＮノードとの通信の開始および終了を指示する。
映像エンコーダ４０４は、カメラや映像再生機などの映像入力装置（図示せず）から、映像の実時間データ（映像データ）を入力する。映像エンコーダ４０４は、後述する送信帯域推定部４０７から通知される目標ビットレートに従って、入力された映像データのエンコードを行う。そして、映像エンコーダ４０４は、エンコードされた映像データを、ＲＴＰ−Ｓ変換部４０５へ出力する。
ＲＴＰ−Ｓ変換部４０５は、映像エンコーダ４０４から入力された映像データを、複数の分割データに分割する。ＲＴＰ−Ｓ変換部４０５は、分割データに対して、ＲＴＰの通番、タイムスタンプ、マーカビットなどの情報を記載したＲＴＰパケットヘッダを付与し、コンテンツ名との対応付けを行って、ＣＣＮのデータパケットを生成する。そして、ＲＴＰ−Ｓ変換部４０５は、生成したデータパケットを、ＣＣＮ送信スタック４０１を介して、受信端末２００へ送信する。
ＲＴＣＰ−Ｓ制御部４０６は、ＣＣＮ送信スタック４０１を介して、受信端末２００のＲＴＣＰ−Ｒ制御部２０６から、通常帯域推定値Ｘｃａｌｓの通知を受ける。そして、ＲＴＣＰ−Ｓ制御部４０６は、通知された通常帯域推定値Ｘｃａｌｓを、送信帯域推定部４０７へ出力する。なお、ＲＴＣＰ−Ｓ制御部４０６は、上述の付加情報を通知された場合、当該付加情報を併せて送信帯域推定部４０７へ出力してもよい。
送信帯域推定部４０７では、ＲＴＣＰ−Ｓ制御部４０６から入力された、少なくとも通常帯域推定値Ｘｃａｌｓを含む情報に基づいて、通常帯域推定値Ｘｃａｌｓの送信元である受信端末２００に対して採用すべき帯域を決定する。そして、送信帯域推定部４０７は、決定した帯域を利用して映像データの送信（パケットの送信）が行われるような、エンコーディングの目標ビットレートを、映像エンコーダ４０４に通知する。
なお、送信帯域推定部４０７は、受信端末２００から通知された通常帯域推定値Ｘｃａｌｓを、そのまま、通常帯域推定値Ｘｃａｌｓの送信元である受信端末２００に適用すべき帯域に決定することもある。この場合、結果的に、送信帯域推定部４０７は、ＣＣＮ送信スタック４０１に対し、受信端末２００から通知された通常帯域推定値Ｘｃａｌｓを利用してデータパケットの送信を間接的に行わせることになる。
＜ＣＣＮルータの説明＞
図７において、ＣＣＮルータ５１０は、キャッシュ部５１１およびＣＣＮ転送スタック５１２を有する。
キャッシュ部５１１は、送信端末４００から送信されたデータパケットのうち、過去にＣＣＮルータ５１０が転送を行ったデータパケットの複製をキャッシュする。
ＣＣＮ転送スタック５１２は、ＣＣＮのプロトコル動作を行う。すなわち、ＣＣＮ転送スタック５１２は、受信端末２００から送信されたインタレストパケットを受信し、対応するデータパケットがキャッシュ部５１１にキャッシュされていない場合、受信したインタレストパケットを転送する。
また、ＣＣＮ転送スタック５１２は、送信端末４００から送信されたデータパケットを、そのデータパケットの送信先である受信端末２００に対して転送する。また、ＣＣＮ転送スタック５１２は、そのデータパケットの複製を、キャッシュ部５１１にキャッシュさせる。そして、ＣＣＮ転送スタック５１２は、受信端末２００からの要求に応じて、キャッシュ部５１１にキャッシュされたデータパケットを、その受信端末２００へ転送する。
すなわち、ＣＣＮ転送スタック５１２は、受信端末２００から送信されたインタレストパケットを受信する。そして、ＣＣＮ転送スタック５１２は、対応するデータパケットがキャッシュ部５１１にキャッシュされている場合、そのデータパケットを、インタレストパケットの送信元へ返信する。
なお、受信端末２００、送信端末４００、およびＣＣＮルータ５１０は、図示しないが、例えば、ＣＰＵ、制御プログラムを格納したＲＯＭなどの記憶媒体、ＲＡＭなどの作業用メモリ、および通信回路などを、それぞれ有する。この場合、上記した各部の機能は、ＣＰＵが制御プログラムを実行することにより実現される。
次に、受信端末２００、送信端末４００、およびＣＣＮルータ５１０のそれぞれの動作について説明する。
＜受信端末の動作説明＞
図８は、受信端末２００の動作の一例を示すフローチャートである。
まず、ステップＳ１１００において、ＲＴＰ−Ｒ変換部２０４は、近接帯域推定値Ｘｃａｌｎおよび通常帯域推定値Ｘｃａｌｓを推定するタイミング（以下「帯域推定タイミング」という）が到来したか否かを判断する。帯域推定タイミングは、例えば、タイマーなどを用いて計測される所定のタイムアウト時間が経過したタイミングや、ＣＣＮ受信スタック２０１がデータパケットを受信したタイミングである。
ＲＴＰ−Ｒ変換部２０４は、ＲＴＰパケットが受信された場合、ＲＴＰ−Ｒ変換部２０４自身がこれを検知し、ＲＴＣＰパケットが受信された場合、ＣＣＮ受信スタック２０１からの通知によりこれを検知する。タイムアウト時間は、パケットが長時間到着しなかったことを検知するために設定されるものであり、例えば１００ｍｓである。
ＲＴＰ−Ｒ変換部２０４は、帯域推定タイミングが到来した場合（Ｓ１１００：ＹＥＳ）、ステップＳ１２００へ進む。また、ＲＴＰ−Ｒ変換部２０４は、帯域推定タイミングが到来していない場合（Ｓ１１００：ＮＯ）、後述のステップＳ１３００へ進む。
ステップＳ１２００において、受信端末２００は、ＲＴＰ−Ｒ変換部２０４、利用可能帯域推定部２０５、およびＲＴＣＰ−Ｒ制御部２０６において、帯域推定処理を行う。帯域推定処理は、近接帯域推定値Ｘｃａｌｎおよび通常帯域推定値Ｘｃａｌｓを推定するための処理である。なお、帯域推定処理については、後述する。
ステップＳ１３００において、ＣＣＮ受信スタック２０１は、処理ＴＩＣＫが到来したか否かを判断する。処理ＴＩＣＫとは、所定の時間長さ毎に定期的に到来するタイミングである。所定の時間長さは、組み込み端末で広く用いられているＬｉｎｕｘ（登録商標）ＯＳの場合、４ｍｓあるいは１ｍｓが一般的である。但し、所定の時間長さは、この値に限定されず、通常帯域推定値Ｘｃａｌｓと同等もしくはそれ以下であればよい。
ＣＣＮ受信スタック２０１は、処理ＴＩＣＫが到来した場合（Ｓ１３００：ＹＥＳ）、ステップＳ１４００へ進む。ＣＣＮ受信スタック２０１は、処理ＴＩＣＫが到来していない場合（Ｓ１３００：ＮＯ）、後述のステップＳ１５００へ進む。
ステップＳ１４００において、ＣＣＮ受信スタック２０１は、インタレストパケット発行処理を行う。インタレストパケット発行処理は、近接帯域推定値Ｘｃａｌｎが示す帯域を最大限に利用してインタレストパケットを発行する処理である。より具体的には、指定された帯域幅でデータパケットを受信するようにインタレストパケットを発行するために、いわゆるトークンバケツ方式を用いて、トークンの発行数を制御する処理である。なお、インタレストパケットの発行処理については、後述する。
図８のステップＳ１５００において、ＲＴＰ−Ｒ変換部２０４は、ユーザ操作等により処理の終了を指示されたか否かを判断する。
ＲＴＰ−Ｒ変換部２０４は、処理の終了を指示されていない場合（Ｓ１５００：ＮＯ）、ステップＳ１１００へ戻る。また、ＲＴＰ−Ｒ変換部２０４は、処理の終了を指示された場合（Ｓ１５００：ＹＥＳ）、一連の処理を終了する。
＜受信端末２００の帯域推定処理＞
図９は、受信端末２００の帯域推定処理（図８のステップＳ１２００）の一例を示すフローチャートである。
まず、ステップＳ１２０１において、ＲＴＰ−Ｒ変換部２０４は、帯域推定タイミングの到来が、ＲＴＰパケットの受信またはタイムアウトにより発生した事象であるか否かを判断する。
ＲＴＰ−Ｒ変換部２０４は、帯域推定タイミングの到来がＲＴＰパケットの受信またはタイムアウトにより発生した事象ではない場合（Ｓ１２０１：ＮＯ）、ステップＳ１２０２へ進む。また、ＲＴＰ−Ｒ変換部２０４は、帯域推定タイミングの到来がＲＴＰパケットの受信またはタイムアウトにより発生した事象である場合（Ｓ１２０１：ＹＥＳ）、ステップＳ１２０３へ進む。
ステップＳ１２０２において、ＲＴＰ−Ｒ変換部２０４は、帯域推定タイミングの到来がＲＣＴＰパケットの受信により発生した事象であるか否かを判断する。
ＲＴＰ−Ｒ変換部２０４は、帯域推定タイミングの到来がＲＣＴＰパケットの受信により発生した事象である場合（Ｓ１２０２：ＹＥＳ）、ステップＳ１２０４へ進む。また、ＲＴＰ−Ｒ変換部２０４は、帯域推定タイミングの到来がＲＣＴＰパケットの受信により発生した事象ではない場合（Ｓ１２０２：ＮＯ）、図８の処理へ戻る。
ステップＳ１２０４において、ＲＴＰ−Ｒ変換部２０４は、受信したＲＣＴＰパケットが送信端末４００から送信されたものか否かを判断する。
ＲＴＰ−Ｒ変換部２０４は、受信したＲＣＴＰパケットが送信端末４００から送信されたものである場合（ステップＳ１２０４：ＹＥＳ）、ステップＳ１２０５へ進む。また、ＲＴＰ−Ｒ変換部２０４は、受信したＲＣＴＰパケットが送信端末４００から送信されたものではない場合（Ｓ１２０４：ＮＯ）、ステップＳ１２０６へ進む。
ステップＳ１２０５において、ＲＴＰ−Ｒ変換部２０４は、ＲＣＴＰパケットから通常往復時間ＲＴＴｓを算出（計測）する。そして、ＲＴＰ−Ｒ変換部２０４は、算出した通常往復時間ＲＴＴｓを、他の処理から参照可能なメモリ領域に、パラメータＲｓに用いられる値として格納して、図８の処理へ戻る。パラメータＲｓは、送信端末４００へ通知する通常往復時間ＲＲＴｓを決定するためのパラメータであり、計測された複数の通常往復時間ＲＲＴｓの荷重移動平均値である。
ステップＳ１２０６において、ＲＴＰ−Ｒ変換部２０４は、受信したパケットを破棄して、図８の処理へ戻る。
すなわち、ＲＴＰ−Ｒ変換部２０４は、送信端末４００から送信されたＲＣＴＰパケットを受信する毎に、通常往復時間ＲＴＴｓを計測し、計測値を、パラメータＲｓに格納する。
一方、ステップＳ１２０３において、ＲＴＰ−Ｒ変換部２０４は、受信した帯域推定タイミングの到来が近接ＣＣＮノードからのＲＴＰパケットの受信により発生した事象であるか否かを判断する。
ＲＴＰ−Ｒ変換部２０４は、帯域推定タイミングの到来が近接ＣＣＮノードからのＲＴＰパケットの受信により発生した事象である場合（Ｓ１２０３：ＹＥＳ）、ステップＳ１２０７へ進む。また、ＲＴＰ−Ｒ変換部２０４は、帯域推定タイミングの到来が近接ＣＣＮノードからのＲＴＰパケットの受信により発生した事象ではない場合（Ｓ１２０３：ＮＯ）、ステップＳ１２０８へ進む。
この判断は、例えば、送信端末４００のＩＰアドレスとパケットの送信元ＩＰアドレスとが一致するか否かによって判断することができる。すなわち、ＲＴＰ−Ｒ変換部２０４は、パケットの送信元ＩＰアドレスが信端末４００のＩＰアドレスと一致しない場合、受信したパケットが近接ＣＣＮノードから送信されたデータパケットであると判断することができる。なお、データの内容の信頼性は、非特許文献１で開示されているパケット毎の認証や暗号化を用いて検査してもよい。
ステップＳ１２０７において、ＲＴＰ−Ｒ変換部２０４は、ＲＴＰパケットから近接往復時間ＲＴＴｎを算出（計測）する。そして、ＲＴＰ−Ｒ変換部２０４は、算出した近接往復時間ＲＴＴｎを、他の処理から参照可能なメモリ領域に、パラメータＲｎに用いられる値として格納する。パラメータＲｎは、インタレストパケットの送信頻度の決定に用いられる近接往復時間ＲＴＴｎを決定するためのパラメータであり、計測された複数の近接往復時間ＲＴＴｎの荷重移動平均値である。
そして、ステップＳ１２０８において、ＲＴＰ−Ｒ変換部２０４は、近接損失イベント率Ｐｎおよび通常損失イベント率Ｐｓを算出する。
より具体的には、ＲＴＰ−Ｒ変換部２０４は、パケット通番を記録しておき、パケット通番の隔たり、および、タイムアウトの有無から、パケットロスの有無を判断する。そして、ＲＴＰ−Ｒ変換部２０４は、非特許文献３に記載の手法により、近接損失イベント率Ｐｎおよび通常損失イベント率Ｐｓを算出する。
損失イベント率とは、１往復時間ＲＴＴ期間以内に発生した複数の損失を、一つの損失イベント率として計算する率である。近接損失イベント率Ｐｎおよび通常損失イベント率Ｐｓは、それぞれ、パラメータＲｎ、Ｒｓを往復時間とみなして、算出を行う。
ＲＴＰ−Ｒ変換部２０４は、近接往復時間ＲＴＴｎ（パラメータＲｎ）を用いて、近接損失イベント率Ｐｎを算出する。また、ＲＴＰ−Ｒ変換部２０４は、通常往復時間ＲＴＴｓ（パラメータＲｓ）を用いて、通常損失イベント率Ｐｓを算出する。そして、ＲＴＰ−Ｒ変換部２０４は、これらの算出結果を、他の処理から参照可能なメモリ領域に記録する。
そして、ステップＳ１２０９において、利用可能帯域推定部２０５は、近接往復時間ＲＴＴｎおよび近接損失イベント率Ｐｎを式（１）に代入して、近接帯域推定値Ｘｃａｌｎを算出する。
そして、ステップＳ１２１０において、ＲＴＣＰ−Ｒ制御部２０６は、インタレストパケットの発行のために、算出された近接帯域推定値Ｘｃａｌｎを、ＣＣＮ受信スタック２０１に通知する。この通知は、上位層の帯域推定および流量制御の仕組みにより算出された値を、下位層に通知する役割を果たしている。このようにして通知された近接帯域推定値Ｘｃａｌｎに従ってインタレストパケットを送信した場合は、受信端末２００と近接ＣＣＮノードとの間のＴＣＰ公平性が、上位層によって保証されることになる。
そして、ステップＳ１２１１において、利用可能帯域推定部２０５は、通常往復時間ＲＴＴｓおよび通常損失イベント率Ｐｓを式（１）に代入して、通常帯域推定値Ｘｃａｌｓを算出する。
そして、ステップＳ１２１２において、ＲＴＣＰ−Ｒ制御部２０６は、算出された通常帯域推定値Ｘｃａｌｓを、ＲＴＣＰパケットの送信によって、送信端末４００に通知して、図８の処理へ戻る。
より具体的には、ＲＴＣＰ−Ｒ制御部２０６は、通常帯域推定値Ｘｃａｌｓを、通信システム３００で予め定義された所定の形式のＲＴＣＰパケット（以下「帯域推定用ＲＴＣＰパケット」という）に乗せて、送信端末４００に送信する。この際、ＲＴＣＰ−Ｒ制御部２０６は、帯域推定用ＲＴＣＰパケットにより、受信したパケットの通番と現在再生中の映像データのタイムスタンプを、併せて送信する。
この帯域推定用ＲＴＣＰパケットは、実験的実装において、ＲＴＣＰのＡＰＰ形式を使って独自に拡張された形式のパケットであってもよいし、特定の形式のレポートとして別途定義される形式のパケットであってもよい。
ここで、通番やタイムスタンプを併せて送信端末４００に送信する理由は、受信端末２００が追い付き再生を行っているか否かを、送信端末４００に知らせるためである。その理由は、ＲＴＣＰパケットが、過去に送信された映像データをＣＣＮルータ５１０から取得して再生している受信端末２００からのフィードバックであるのか、実時間再生を行っている受信端末２００からのフィードバックであるのか、を区別するためである。
＜インタレストパケット発行処理＞
図１０は、インタレストパケット発行処理（図８のステップＳ１４００）の一例を示すフローチャートである。
まず、ステップＳ１４０１において、ＣＣＮ受信スタック２０１は、本処理の初期化が完了しているか否かを判断する。
ＣＣＮ受信スタック２０１は、本処理の初期化が完了していない場合（Ｓ１４０１：ＮＯ）、ステップＳ１４０２へ進む。また、ＣＣＮ受信スタック２０１は、本処理の初期化が完了している場合（Ｓ１４０１：ＹＥＳ）、ステップＳ１４０３へ進む。
ステップＳ１４０２において、ＣＣＮ受信スタック２０１は、パラメータＴｏｋｅｎに、値０を代入し、パラメータＴＩＣＫに、次回本処理が動作するまでの時間を定義する定数を代入する。パラメータＴＩＣＫには、例えば、１ｍｓ毎に動作すること（Ｈｚ＝１０００）を示す値が代入される。
そして、ステップＳ１４０３において、ＣＣＮ受信スタック２０１は、パラメータＴｏｋｅｎに、パラメータＴＩＣＫと近接帯域推定値Ｘｃａｌｎとの積を足し上げる。
そして、ステップＳ１４０４において、ＣＣＮ受信スタック２０１は、パラメータＴｏｋｅｎが、パケットサイズＳ［byte］をビット換算したパケットサイズ換算値Ｓ＊８［bit］以上であるか否かを判断する。
ＣＮ受信スタック２０１は、パラメータＴｏｋｅｎが、パケットサイズ換算値Ｓ＊８［bit］以上である場合（Ｓ１４０４：ＹＥＳ）、ステップＳ１４０５へ進む。また、ＣＮ受信スタック２０１は、パラメータＴｏｋｅｎが、パケットサイズ換算値Ｓ＊８［bit］未満である場合（Ｓ１４０４：ＮＯ）、ステップＳ１４０６へ進む。
ステップＳ１４０５において、ＣＣＮ受信スタック２０１は、インタレストパケットを発行し、パラメータＴｏｋｅｎからパケットサイズ換算値Ｓ＊８［bit］を差し引き、ステップＳ１４０４へ戻る。このパラメータＴｏｋｅｎから差し引く値は、インタレストパケットを発行した分に見合う値である。
すなわち、ＣＣＮ受信スタック２０１は、パラメータＴｏｋｅｎがパケットサイズを超えている間は、パラメータＴｏｋｅｎがパケットサイズ未満になるまで、インタレストパケットの発行を行う。
ここで、ＣＣＮ受信スタック２０１によるトークンバケツ処理は、一般のトークンバケツ処理と異なる。この異なる点は、パケットサイズ（Ｓ）が、受信端末２００が発行するインタレストパケットのサイズではなく、受信端末２００が受信するデータパケットのサイズである点である。
一般のトークンバケツ処理は、受信端末２００が発行するインタレストパケットの流量を制御するために用いられる。これに対し、ＣＣＮ受信スタック２０１によるトークンバケツ処理は、近接ＣＣＮノードから受信端末２００までの間の利用可能帯域を利用する（埋める）ために必要十分な量のデータパケットを、連続的に取得する制御のために、用いられる。つまり、ＣＣＮ受信スタック２０１によるトークンバケツ処理は、必要十分な量のデータパケットが、連続的に取得されるように、インタレストパケットの発行を行う。
すなわち、ＣＣＮ受信スタック２０１が行うトークンバケツ処理は、一般的に制御の対象となる流量の方向とは逆方向の流量を、制御するようになっている。
なお、パケットサイズＳ［byte］は、通信の開始時に、送信側通話制御アプリ４０３と受信側通話制御アプリ２０３との間で交換される呼制御情報により決定されるメディア種別に基づいて、静的に決定されてもよい。
例えば、ＣＣＮ受信スタック２０１は、１５００バイトのパケット長で通信するビデオデータの場合、Ｓ＝１５００とする。
あるいは、例えば、ＣＣＮ受信スタック２０１は、受信するパケットのパケット長を統計的に算出し、算出結果を、パケットサイズＳ［byte］として採用する。具体的には、例えば、ＣＣＮ受信スタック２０１は、過去ｎ個（ｎは正の整数）のデータパケットのパケット長に対して、指数加重平均を適用して得られる値を用いる。
あるいは、例えば、ＣＣＮ受信スタック２０１は、受信したデータパケットのパケット長を、配列、リスト、あるいはキューなど形式で記憶領域に順次記録する。そして、ＣＣＮ受信スタック２０１は、ステップＳ１４０４、Ｓ１４０５の処理が行われる毎に、記憶領域の先頭（過去）から、記録された値を、順次採用する。
そして、ステップＳ１４０６において、ＣＣＮ受信スタック２０１は、本処理が次のＴＩＣＫ時間経過後に起動するようにタイマーにフックし、図８の処理へ戻る。
＜送信端末の動作説明＞
図１１は、送信端末の動作の一例を示すフローチャートである。
まず、ステップＳ２００１において、ＲＴＣＰ−Ｓ制御部４０６は、ＲＴＣＰパケットを受信したか否かを判断する。
ＲＴＣＰ−Ｓ制御部４０６は、ＲＴＣＰパケットを受信した場合（Ｓ２００１：ＹＥＳ）、ステップＳ２００２へ進む。また、ＲＴＣＰ−Ｓ制御部４０６は、ＲＴＣＰパケットを受信していない場合（Ｓ２００１：ＮＯ）、後述のステップＳ２０１３へ進む。
ステップＳ２００２において、ＲＴＣＰ−Ｓ制御部４０６は、初回のＲＴＣＰパケット受信処理であるか否かを判断する。
ＲＴＣＰ−Ｓ制御部４０６は、ＲＴＣＰ−Ｓ制御部４０６は、初回のＲＴＣＰパケット受信処理である場合（Ｓ２００２：ＹＥＳ）、ステップＳ２００３へ進む。また、ＲＴＣＰ−Ｓ制御部４０６は、初回のＲＴＣＰパケット受信処理ではない場合（Ｓ２００２：ＮＯ）、ステップＳ２００４へ進む。
ステップＳ２００３において、ＲＴＣＰ−Ｓ制御部４０６は、過去に作成された受信端末２００のリストをクリアする。受信端末２００のリストは、複数の端末に対する送信を行っている場合に利用するリストであり、受信端末２００の情報を格納する構造体のリストである。本ステップにおいて、ＲＴＣＰ−Ｓ制御部４０６は、かかるリストの内容を増加させることができる状態に初期化する。また、ＲＴＣＰ−Ｓ制御部４０６は、記憶領域に記憶する次回推定値通知時刻を、初回の処理を行った時刻である現在時刻にＴＩＣＫ時間を付加した時刻に、初期化する。
そして、ステップＳ２００４において、ＲＴＣＰ−Ｓ制御部４０６は、受信したＲＴＣＰパケットがＲＦＣ３５５０に準拠したパケットであるかどうかを判断する。
ＲＴＣＰ−Ｓ制御部４０６は、受信したＲＴＣＰパケットがＲＦＣ３５５０に準拠したパケットである場合（Ｓ２００４：ＹＥＳ）、ステップＳ２００５へ進む。また、ＲＴＣＰ−Ｓ制御部４０６は、受信したＲＴＣＰパケットがＲＦＣ３５５０に準拠したパケットではない場合（Ｓ２００４：ＮＯ）、ステップＳ２００６へ進む。
ステップＳ２００５において、ＲＴＣＰ−Ｓ制御部４０６は、受信したＲＴＣＰパケットを、ＲＦＣ３５５０に準拠する形で処理する。かかる処理は、典型的な受信者レポートの処理などである。
そして、ステップＳ２００６において、ＲＴＣＰ−Ｓ制御部４０６は、受信したＲＴＣＰパケットが、上述の通帯域推定用ＲＴＣＰパケットであるか否かを判断する。
ＲＴＣＰ−Ｓ制御部４０６は、受信したＲＴＣＰパケットが、帯域推定用ＲＴＣＰパケットである場合（Ｓ２００６：ＹＥＳ）、ステップＳ２００７へ進む。また、ＲＴＣＰ−Ｓ制御部４０６は、受信したＲＴＣＰパケットが、帯域推定用ＲＴＣＰパケットではない場合（Ｓ２００６：ＮＯ）、後述のステップＳ２０１３へ進む。
ステップＳ２００７において、ＲＴＣＰ−Ｓ制御部４０６は、受信した帯域推定用ＲＴＣＰパケットの送信元が、初めての送信元であるか否か判断する。初めての送信元とは、これまでに帯域推定用ＲＴＣＰパケットを送信端末４００に送信したことがないＣＣＮノードである。
ＲＴＣＰ−Ｓ制御部４０６は、受信した帯域推定用ＲＴＣＰパケットの送信元が初めての送信元である場合（Ｓ２００７：ＹＥＳ）、ステップＳ２００８へ進む。また、ＲＴＣＰ−Ｓ制御部４０６は、受信した帯域推定用ＲＴＣＰパケットの送信元が、初めての送信元ではない場合（Ｓ２００７：ＮＯ）、ステップＳ２００９へ進む。
ステップＳ２００８において、ＲＴＣＰ−Ｓ制御部４０６は、受信端末２００のリストに、受信した帯域推定用ＲＴＣＰパケットの送信元のＩＰアドレスを追加する。
そして、ステップＳ２００９において、ＲＴＣＰ−Ｓ制御部４０６は、受信した帯域推定用ＲＴＣＰパケットから、帯域推定用ＲＴＣＰパケットに格納された通常帯域推定値Ｘｃａｌｓを抽出する。また、ＲＴＣＰ−Ｓ制御部４０６は、受信した帯域推定用ＲＴＣＰパケットの送信元のＩＰアドレスを、受信端末２００のリストで探索する。そして、ＲＴＣＰ−Ｓ制御部４０６は、リストの要素のうち該当するものに、抽出した通常帯域推定値Ｘｃａｌｓを記録する。
なお、ＲＴＣＰ−Ｓ制御部４０６は、帯域推定用ＲＴＣＰパケットに含まれるタイムスタンプおよび通番や、帯域推定用ＲＴＣＰパケットから算出される通常往復時間ＲＴＴｓを、併せて受信端末２００のリストに記録してもよい。
そして、ステップＳ２０１０において、ＲＴＣＰ−Ｓ制御部４０６は、送信端末４００の現在時刻を取得し、現在時刻が、記憶領域に記憶している次回推定値通知時刻を超過（経過）しているか否かを判断する。
ＲＴＣＰ−Ｓ制御部４０６は、ＲＴＣＰ−Ｓ制御部４０６は、現在時刻が次回推定値通知時刻を超過していない場合（Ｓ２０１０：ＮＯ）、ステップＳ２０１０の判断処理を繰り返す。そして、ＲＴＣＰ−Ｓ制御部４０６は、現在時刻が次回推定値通知時刻を超過すると（Ｓ２０１０：ＹＥＳ）、ステップＳ２０１１へ進む。
ステップＳ２０１１において、送信帯域推定部４０７は、受信端末２００のリストにおいて、記録されている通常帯域推定値Ｘｃａｌｓのうち最低値を検索する。送信帯域推定部４０７は、検索された最低値を、上位層の流量制御に採用する通常帯域推定値Ｘｃａｌｓに決定する。そして、送信帯域推定部４０７は、決定した通常帯域推定値Ｘｃａｌｓを、次回のエンコードで採用する目標ビットレートを決定するための情報として、映像エンコーダ４０４に通知する。
なお、通常帯域推定値Ｘｃａｌｓの最低値を検索する際、送信帯域推定部４０７は、タイムスタンプ、通番、および通常往復時間ＲＴＴｓなどの情報を利用して、通常帯域推定値Ｘｃａｌｓを読み飛ばしてもよい。すなわち、送信帯域推定部４０７は、追い付き再生を行っている受信端末２００からの通常帯域推定値Ｘｃａｌｓを無視してもよい。あるいは、送信帯域推定部４０７は、通常往復時間ＲＴＴｓ以内にインタレストパケットを発行してきていない受信端末２００からの通常帯域推定値Ｘｃａｌｓを、無視してもよい。
また、映像エンコーダ４０４は、通知された通常帯域推定値Ｘｃａｌｓから、パケットヘッダオーバヘッド見合い分、データパケット損失時の再送パケット見合い分、およびＦＥＣなどの冗長符号分のビットレートのうち、一部または全部を、減算してもよい。そして、映像エンコーダ４０４は、かかる減算が行われた後の値から、目標ビットレートを決定してもよい。
そして、ステップＳ２０１２において、ＲＴＣＰ−Ｓ制御部４０６は、次回推定値通知時刻を決定し、記憶する。
そして、ステップＳ２０１３において、ＲＴＰ−Ｓ変換部４０５は、ユーザ操作等により処理の終了を指示されたか否かを判断する。
ＲＴＰ−Ｓ変換部４０５は、処理の終了を指示されていない場合（Ｓ２０１３：ＮＯ）、ステップＳ２００１へ戻る。また、ＲＴＰ−Ｓ変換部４０５は、処理の終了を指示された場合（Ｓ２０１３：ＹＥＳ）、一連の処理を終了する。
＜ＣＣＮルータの動作説明＞
図１２は、ＣＣＮルータ５１０の動作の一例を示すフローチャートである。
まず、ステップＳ３００１において、ＣＣＮ転送スタック５１２は、送信端末４００から送信されたデータパケットを受信したか否かを判断する。ＣＣＮ転送スタック５１２は、データパケットを受信した場合（Ｓ３００１：ＹＥＳ）、ステップＳ３００２へ進む。また、ＣＣＮ転送スタック５１２は、データパケットを受信していない場合（Ｓ３００１：ＮＯ）、ステップＳ３００３へ進む。
ステップＳ３００２において、ＣＣＮ転送スタック５１２は、受信したデータパケットを、その送信先である受信端末２００に向けて転送する。また、ＣＣＮ転送スタック５１２は、受信したデータパケットを、複製して、キャッシュ部５１１にキャッシュする。
そして、ステップＳ３００３において、ＣＣＮ転送スタック５１２は、受信端末２００から送信されたインタレストパケットを受信したか否かを判断する。ＣＣＮ転送スタック５１２は、インタレストパケットを受信した場合（Ｓ３００３：ＹＥＳ）、ステップＳ３００４へ進む。また、ＣＣＮ転送スタック５１２は、インタレストパケットを受信していない場合（Ｓ３００３：ＮＯ）、後述のステップＳ３００７へ進む。
ステップＳ３００４において、ＣＣＮ転送スタック５１２は、受信したインタレストパケットが送信を要求するデータパケットが、キャッシュ部５１１にキャッシュされているか否かを判断する。ＣＣＮ転送スタック５１２は、該当するデータパケットがキャッシュされていない場合（Ｓ３００４：ＮＯ）、ステップＳ３００５へ進む。また、ＣＣＮ転送スタック５１２は、該当するデータパケットがキャッシュされている場合（Ｓ３００４：ＹＥＳ）、ステップＳ３００６へ進む。
ステップＳ３００５において、ＣＣＮ転送スタック５１２は、予め保持する名前空間の経路表（FIB: Forwarding Information Base）に従って、受信したインタレストパケットを、他のＣＣＮノードへ転送する。例えば、このインタレストパケットは、最終的に、送信端末４００まで到達する。
ステップＳ３００６において、ＣＣＮ転送スタック５１２は、受信したインタレストパケットが要求するデータパケットを、キャッシュ部５１１から取得し、インタレストパケットの送信元へ返信する。
そして、ステップＳ３００７において、ＣＣＮ転送スタック５１２は、ユーザ操作等により処理の終了を指示されたか否かを判断する。ＣＣＮ転送スタック５１２は、処理の終了を指示されていない場合（Ｓ３００７：ＮＯ）、ステップＳ３００１へ戻る。また、ＣＣＮ転送スタック５１２は、処理の終了を指示された場合（Ｓ３００７：ＹＥＳ）、一連の処理を終了する。
なお、ＣＣＮ転送スタック５１２は、通常のルータと同じ機能をも備えている。すなわち、ＣＣＮ転送スタック５１２は、ユニキャストパケットの転送においては、転送先ＩＰアドレスを用いて、ＩＰ転送用の経路表（ＦＩＢ）を探索し、適切なインターフェイスに転送する。例えば、受信端末２００から送信端末４００に向けて送信されたＲＴＣＰパケットは、このＩＰ転送用の経路表に基づいて、送信端末４００に向けて転送される。
＜追い付き再生の説明＞
次に、追い付き再生の詳細について説明する。
上述の受信側通話制御アプリ２０３は、利用可能帯域推定部２０５から通知された近接帯域推定値Ｘｃａｌｎと、映像デコーダ２０７から通知された映像データのデータ量とに基づいて、映像データの取得再生手法を決定する。ここで、映像データの取得再生手法には、再生時刻を早めて再生することや、映像データを構成するピクチャの一部を間引いて（スキップして）の取得することが含まれる。
受信端末２００が上述の「他の受信端末」である場合、取得の目的となるデータパケットは、既に近接ＣＣＮノードにキャッシュされている。
このため、受信端末２００は、近接ＣＣＮノードから受信端末２００への利用可能帯域が大きい場合、データパケットを、送信端末４００が送信したレートよりも高いレートで受信することが可能である。例えば、受信側通話制御アプリ２０３は、近接帯域推定値Ｘｃａｌｎが、映像データのデータ量を倍にしたときに必要な帯域以上である場合、インタレストパケットを通常の倍の頻度で発行するように、ＣＣＮ受信スタック２０１に指示する。
これにより、例えば、映像データが会議の中継データである場合、会議の途中から、それまでの会議の内容を倍速で再生し、会議に途中から参加することが可能となる。
また、受信端末２００は、近接ＣＣＮノードから受信端末２００への利用可能帯域が小さい場合、データパケットを、送信端末４００が送信したレートよりも低いレートでなければ受信することができない。したがって、受信側通話制御アプリ２０３は、例えば、近接帯域推定値Ｘｃａｌｎが、映像データのデータ量に必要な帯域未満である場合、映像データを、静止画のコマ送りとなるようにスキップして取得するようにする。より具体的には、受信側通話制御アプリ２０３は、インタレストパケットをスキップして発行するように、ＣＣＮ受信スタック２０１に指示する。
これにより、再生される映像データの品質は低下するものの、ＴＣＰ公平性を保ちつつ、映像データを取得して再生することが可能となる。
ここで、図３を参照しながら、追い付き再生が行われる場合のシステム３００の動作の概要について説明する。
以下の説明においては、まず、映像データが、第１の受信端末２００１によって送信端末４００から初めて取得され、その直後に、第２の受信端末２００２によって取得される場合を、例として用いる。
まず、送信端末４００と第１の受信端末２００１とが、非特許文献３に開示されているＶｏｉｃｅ Ｏｖｅｒ ＣＣＮの呼制御と同様の手順により、呼を確立する。すなわち、第１の受信端末２００１が発行した、通常のＳＩＰによる呼制御のメッセージ（Session Description Protocolにより記述）が、ＣＣＮのインタレストパケットによって、送信端末４００に運ばれる。
そして、映像データの分割データは、第１の受信端末２００１が連続的に、ＲＴＰの通番を指定したインタレストパケットを発行することにより、送信端末４００から第１の受信端末２００１へと運ばれる。
言い換えると、映像データの分割データは、呼を特定するＩＤおよび通番と、タイムスタンプを含む名前空間とが定義される。そして、ＣＣＮネットワーク５００は、その名前空間の出版元は送信端末４００であるとして、運用される。その上で、第１の受信端末２００１から、連続的に分割データに対するインタレストパケットが発行される。これにより、分割データを格納したパケットは、送信端末４００から第１の受信端末２００１へと転送される。
このようにして、送信端末４００から第１の受信端末２００１への映像データの伝送は、実現される。
この場合、第１の受信端末２００１にとって、近接ＣＣＮノードは、ＣＣＮネットワーク５００の中のＣＣＮルータ５１０（例えば共通のＣＣＮノード）ではなく、送信端末４００となる。これは、ＣＣＮネットワーク５００の中のＣＣＮルータ５１０および非ＣＣＮルータ５２０のいずれも、分割データをまだキャッシュしていないためである。
この結果、インタレストパケットは、送信端末４００まで転送されて到達し、分割データを格納したデータパケットは、送信端末４００から返送される。
このように、送信端末４００が近接ＣＣＮノードである場合、近接往復時間ＲＴＴｎは、通常往復時間ＲＴＴｓと一致する。また、近接損失イベント率Ｐｎは、通常損失イベント率Ｐｓと、一致する。
すなわち、送信端末４００が近接ＣＣＮノードである場合、受信端末２００が発行するインタレストパケットの単位時間あたりの数は、上位層のＴＦＲＣにより算出される推定帯域から算出できるデータパケットの単位時間あたりの受信数と一致する。
受信端末２００は送信端末４００に対して、通常帯域推定値Ｘｃａｌｓを通知する。送信端末４００は、この通常帯域推定値Ｘｃａｌｓに見合う目標ビットレートに基づいてエンコードおよび伝送を行うので、ＴＦＲＣに基づいたレート制御を行うことになる。すなわち、ＴＣＰ公平性は、上位層のＴＦＲＣによって保証される。
そして、第２の受信端末２００２が、映像データの追い付き再生を開始したとする。第２の受信端末２００２は、送信端末４００と第１の受信端末２００１との間で行われている実時間ストリーミング伝送に追い付くために、本来の速度よりも高速に映像データを取得して再生する。すなわち、第２の受信端末２００２は、早送りで映像データを再生するか、ピクチャをスキップする形で、映像データを再生する。
このような早送り再生動作は、受信側通話制御アプリ２０３が映像デコーダ２０７に指示することにより、可能となる。
＜下位層における分割データの取得について＞
ここで、下位層における分割データの取得がどのように行われるかについて説明する。
第２の受信端末２００２にとって、近接ＣＣＮノードは、第１のＣＣＮルータ５１０１となる。なぜなら、送信端末４００と第１の受信端末２００１との間で、既に映像データの伝送は行われており、そのデータパケットは、第１のＣＣＮルータ５１０１にキャッシュされているからである。
なお、非特許文献３には、キャッシュのライフタイムを端末間の往復時間ＲＴＴに限定する運用が開示されているが、本願では、キャッシュのライフタイムをセッション時間として使用する。すなわち、呼が開始してから終了するまでの間、データパケットは第１のＣＣＮルータ５１０１に維持される。
このように、第２の受信端末２００２は、第２の受信端末２００２が参加した時刻までの間に送信端末４００と第１の受信端末２００１の間で伝送されてきた映像データを、第１のＣＣＮルータ５１０１から取得することができる。
このとき、第２の受信端末２００２において、近接往復時間ＲＴＴｎは、通常往復時間ＲＴＴｓよりも小さい値となる。
近接往復時間ＲＴＴｎが通常往復時間ＲＴＴｓよりも小さい値となる場合は、パケットロスの発生が、通常往復時間ＲＴＴｓと比較して長い時間間隔で発生していることが想定される。これは、例えば、帯域推定が正常に動作している場合に多く観測される。この場合は、近接帯域推定値Ｘｃａｌｎと通常帯域推定値Ｘｃａｌｓとを比較すると、近接帯域推定値Ｘｃａｌｎの方が大きくなる。これは、式（１）の分母に往復時間ＲＴＴの項があることから、明らかである。
すなわち、第２の受信端末２００２は、送信端末４００が映像データの送信に利用した帯域よりも大きい帯域を利用して、映像データを取得することが可能となる。なお、この場合においても、第２の受信端末で２００２では、ＴＦＲＣに基づいて近接ＣＣＮノード５１０の送信量を調整するため、インタレスパケットの発行量の調整が行われている。このため、ＴＣＰ公平性は満たされる。
このようにして、第２の受信端末２００２は、最初からの映像データを第１のＣＣＮルータ５１０１から取得することができ、映像データの追い付き再生を行うことができる。
このとき、送信端末４００は、第１の受信端末２００１および第２の受信端末２００２の両方から、通常帯域推定値Ｘｃａｌｓのフィードバックを、ＲＴＣＰパケットにより受けている。送信端末４００は、この両者の通常帯域推定値Ｘｃａｌｓのうち、値が小さい方を採用して映像エンコーダを制御してもよいし、後発の第２の受信端末２００２からの通常帯域推定値Ｘｃａｌｓを無視してもよい。
送信端末４００は、受信端末２００からＲＴＣＰパケットに付加して返送される上述の付加情報を、受信端末２００間で比較して、どの通常帯域推定値Ｘｃａｌｓを無視するかを決定すればよい。
例えば、送信端末４００は、再生中のデータの通番が示す時刻と、現在エンコード中のデータの通番が示す時刻との差を、送信端末４００とＲＴＣＰパケットの送信元との間の往復時間ＲＴＴと比較する。そして、送信端末４００は、時刻の差が往復時間ＲＴＴよりも大きい場合、第２の受信端末２００２の通常帯域推定値Ｘｃａｌｓを無視する。
一方、送信端末４００は、時刻の差が往復時間ＲＴＴ以下である場合、第２の受信端末２００２の再生タイミングが本来の再生タイミング（伝送タイミング）に追い付いたと判断する。そして、送信端末４００は、第２の受信端末２００２の通常帯域推定値Ｘｃａｌｓを、上述の最小値判定の対象に入れる。
なお、第２の受信端末２００２の再生タイミングが本来の再生タイミングに追い付いた時点で、第２の受信端末２００２にとっての近接ＣＣＮノードは、送信端末４００となる。
第２の受信端末２００２は、例えば、近接往復時間ＲＴＴｎと通常往復時間ＲＴＴｓとが一致したか否かを判断することにより、送信端末４００が近接ＣＣＮノードとなったことを検知することができる。したがって、第２の受信端末２００２は、送信端末４００が近接ＣＣＮノードとなったとき、その旨を送信端末４００に通知してもよい。そして、送信端末４００は、この通知をトリガにして、第２の受信端末２００２からのフィードバックに含まれる通常帯域推定値Ｘｃａｌｓを最低値の探索対象に含めるようにしてもよい。
なお、第２の受信端末２００２と第１のＣＣＮルータ５１０１との間が輻輳している場合には、近接帯域推定値Ｘｃａｌｎが大きくならず、再生速度を上げることができない。このような場合、第２の受信端末２００２は、上述の通り、映像データをスキップして取得することができる。
また、第２の受信端末２００２は、映像データと音声データとの２ストリームを取得しているような場合は、音声データは間引かずに全て取得し、映像データのみを間引いて取得するように指示してもよい。これにより、第２の受信端末２００２は、第２の受信端末２００２と第１のＣＣＮルータ５１０１との間のネットワーク回線におけるＴＣＰ公平性を満たしながら、必要なデータを取得することができる。
＜変形例１の説明＞
次に、受信端末２００が、映像データの追い付き再生を行っている最中に、近接ＣＣＮノードが変化する場合においても、近接往復時間ＲＴＴｎを計測することができることについて説明する。
図１３は、通信システムの他の構成の第１の例を示すシステム構成図であり、図３に対応するものである。図３と同一部分には同一符号を付し、これについての説明を省略する。
図１３において、第２の受信端末２００２は、例えば、２つのネットワーク接続インターフェイス（ＣＣＮの用語ではフェイス：faces）を備えているものとする。そして、図１３に示すように、第２の受信端末２００２は、第１のＣＣＮルータ５１０１だけでなく、第２のＣＣＮルータ５１０２にも接続されている。
第２の受信端末２００２のフェイスは、例えば、無線ＬＡＮのインターフェイス、あるいは、ＬＴＥ／ＷＩＭＡＸなどの公衆無線のインターフェイスとすることができる。したがって、例えば、第１のＣＣＮルータ５１０１は、無線ＬＡＮの基地局のルータであり、第２のＣＣＮルータ５１０２は、ＷＩＭＡＸの網内のルータである。
ここで、第２の受信端末２００２が取得の目的とする実時間ストリームのデータパケットが、既に、第１のＣＣＮルータ５１０１および第２のＣＣＮルータ５１０２の両方にキャッシュされていたとする。但し、第２の受信端末２００２と第１のＣＣＮルータ５１０１との間の往復時間ＲＴＴの方が、第２の受信端末２００２と第２のＣＣＮルータ５１０２との間の往復時間ＲＴＴよりも短いものとする。
図１４は、図１３の例、つまり、２つの近接ＣＣＮノードがコンテンツを保持している場合の、近接往復時間ＲＴＴｎの計測の様子を示す模式図である。
非特許文献１に記載されているように、ＣＣＮにおいて、インタレストパケットを発行するＣＣＮノードは、全てフェイスから、インタレストパケットを同時に発行する。したがって、第２の受信端末２００２は、インタレストパケットをそれぞれのフェイスに発行する。その際、第２の受信端末２００２は、インタレストパケットを特定する情報（例えば、名前、もしくは通番など名前の一部）と、インタレストパケット送信時刻とを記録する（Ｓ４００１）。それぞれのフェイスから発行されたインタレストパケットは、第１のＣＣＮルータ５１０１および第２のＣＣＮルータ５１０２の両方に送信される（Ｓ４００２、Ｓ４００３）。
この例では、第１のＣＣＮルータ５１０１および第２のＣＣＮルータ５１０２の両方がデータパケットをキャッシュしている。したがって、第１のＣＣＮルータ５１０１および第２のＣＣＮルータ５１０２は、それぞれ、データパケットをそれぞれ第２の受信端末２００２に返信する（Ｓ４００４、Ｓ４００５）。
ところが、この例では、第１のＣＣＮルータ５１０１から返信されたデータパケットの方が、第２のＣＣＮルータ５１０２から返信されたデータパケットよりも先に、第２の受信端末２００２に到達する（Ｓ４００６、Ｓ４００７）。第２の受信端末２００２は、インタレストパケットの送信時刻と、先に受信した第１のＣＣＮルータ５１０１からのデータパケットの受信時刻との差から、近接往復時間ＲＴＴｎを算出する（Ｓ４００８）。第２の受信端末２００２は、算出した近接往復時間ＲＴＴｎを、データパケットに付随する形で内部メモリにて管理してもよいし、インタレストパケットを発行する名前空間に関連付ける形で内部メモリにて管理してもよい。
そして、第２の受信端末２００２は、重複して到着したデータパケットのうち、後から到着した第２のＣＣＮルータ５１０２からのデータパケットを、破棄する（Ｓ４００９）。
このように動作することにより、各受信端末２００は、複数のＣＣＮルータ５１０と接続している場合でも、受信端末２００と近接ＣＣＮノートとの間の往復時間ＲＴＴである近接往復時間ＲＴＴｎを計測することができる。
このように、受信端末２００は、映像データの追い付き再生を行っている最中に、近接ＣＣＮノードが変化する場合においても、近接往復時間ＲＴＴｎを計測することができる。
例えば、追い付き再生を行っている場合、インタレストパケットの単位時間当たりの発行数は、送信端末４００による単位時間当たりのデータパケット発行数よりも多い。過去のデータパケットに対するインタレストパケットが発行されている間は、かかるデータパケットはＣＣＮルータ５１０にキャッシュされている。このため、近接ＣＣＮノードは、当該ＣＣＮルータ５１０となり、近接往復時間ＲＴＴｎは小さくなる。
一方、再生が実時間伝送に追い付いた場合、ＣＣＮルータ５１０には、データパケットがキャッシュされていない。このため、近接ＣＣＮノードは、送信端末４００となる。そして、インタレストパケットは、送信端末４００まで転送され、近接往復時間ＲＴＴｎは大きくなる（通常帯域推定値Ｘｃａｌｓに一致する）。また、近接ＣＣＮノードが変更されたことは、データパケットの送信元ＩＰアドレスを観測することにより、容易に検知することができる。
＜変形例２の説明＞
次に、通信システム３００が、輻輳に対してもＴＣＰ公平性が満たされるように流量制御を行うことについて説明する。
図１５は、通信システムの他の構成の第２の例を示すシステム構成図であり、図３に対応するものである。図３と同一部分には同一符号を付し、これについての説明を省略する。
図１５に示すように、第１のＣＣＮルータ５１０１には、第１〜第３の受信端末２００１〜２００３が接続していたとする。また、第３のＣＣＮルータ５１０３には、第１および第２の送信端末４００１、４００２が接続していたとする。
第３のＣＣＮルータ５１０３と第１のＣＣＮルータ５１０１とは、第１のネットワーク回線５３０１および第２のネットワーク回線５３０２を介して接続されている。第１の受信端末２００１は、第３のネットワーク回線５３０３を介して第１のＣＣＮルータ５１０１に接続されている。第２の受信端末２００２は、第４のネットワーク回線５３０４を介して第１のＣＣＮルータ５１０１に接続されている。第３の受信端末２００３は、第５のネットワーク回線５３０５を介して第１のＣＣＮルータ５１０１に接続されている。第１〜第５のネットワーク回線５３０１〜５３０５のそれぞれの帯域は、２Ｍｂｐｓと仮定する。
第１の送信端末４００１は、第１の送信端末４００１と第１の受信端末２００１および第２の受信端末２００２との間で、呼の通信を行っているものとする。この通信は、「第１の通信」いう。第１の通信が行われている状態で、第２の送信端末４００２は、第２の送信端末４００２と第３の受信端末２００３との間で、新たな呼の通信を開始したとする。この通信は、「第２の通信」という。
第１の通信および第２の通信は、第１および第２のネットワーク回線５３０１、５３０２を共有している。第１の通信のみが行われており、第２の通信が開始されていない間、第１の送信端末４００１は、回線帯域の２Ｍｂｐｓをほぼ完全に利用して通信を行っている。
ところが、第２の通信の通信が開始されると、第１の通信、第２の通信の双方では、一時的にパケットロスが観測される。このとき、第１の通信を行っている第１および第２の受信端末２００１、２００２では、通常損失イベント率Ｐｓの上昇を観測し、通常帯域推定値Ｘｃａｌｓを小さい値で算出する。この値は、第１の送信端末４００１にフィードバックされ、第１の通信のエンコードレート（伝送レート）を低下させる。
また、第２の通信を行っている第３の受信端末２００３は、同様に、通常帯域推定値Ｘｃａｌｓを、小さい値で算出する。この値は、第２の送信端末４００２にフィードバックされ、第２の通信のエンコードレート（伝送レート）を低下させる。
すなわち、第１の通信および第２の通信は、適切に、第１および第２のネットワーク回線５３０１、５３０２を分け合うことができる。なお、上記説明では、ＴＦＲＣで制御されたストリームが２本競合するケースを見てきたが、ＴＣＰで制御された通信を含む複数の通信の間で競合が発生している場合でも同様である。
このように、通信システム３００は、ＴＦＲＣが有する帯域を分け合う機能を有し、輻輳に対してもＴＣＰ公平性が満たされるように流量制御を行うことができる。
以上のように、本実施の形態に係る通信システム３００は、受信端末２００と近接ＣＣＮノードとの間の利用可能帯域を推定し、推定された帯域を利用して近接ＣＣＮノードからのデータ転送が行われるように流量制御を行う。また、本実施の形態に係る通信システム３００は、利用可能帯域を推定し、推定された帯域を利用して送信端末４００からのデータ送信が行われるように流量制御を行う。すなわち、本実施の形態に係る通信システム３００は、ＴＣＰ公平性を実現する上位層のＴＦＲＣベースの帯域推定を阻害しないように、ＣＣＮのインタレストパケットの単位時間当たりの発行数を調整する。
これにより、本実施の形態に係る通信システム３００は、上位層の帯域推定（ＴＦＲＣ）が下位層の流量制御（ＣＣＮ）に影響されることなく、ＴＦＲＣによりＴＣＰ公平性を保持した状態で、実時間ストリーム伝送を継続することができる。すなわち、本実施の形態に係る通信システム３００は、インターネットのようなベストエフォート型ネットワークにＣＣＮを適用し、映像、音声等の実時間ストリームを、パケット落ちが発生しないように適応的に流量を制御することができる。
そして、本実施の形態に係る通信システム３００は、他の受信端末２００がＣＣＮルータ５１０上のキャッシュから実時間ストリームを取得する際、他の受信端末２００とＣＣＮルータ５１０との間のネットワークの混雑度合いに応じた流量制御を行うことができる。すなわち、本実施の形態に係る通信システム３００は、他の受信端末が映像音声の実時間ストリームの伝送の途中あるいは終了後に、伝送のセッションに参加するようなユースケースにおいても、適切に流量制御を行うことができる。
なお、以上説明した各実施の形態では、受信端末が取得の目的とする実時間ストリームが映像データである場合を例としたが、当該実時間ストリームは、これに制限されない。例えば、テレビ会議において双方向に送受信される音声データにも、本発明を適用することができる。
また、上位層における帯域推定にＴＦＲＣを用いた場合を例としたが、上位層の帯域推定の手法は、これに制限されない。例えば、ＴＦＲＣから派生した他の帯域推定手法や、ＢＣＣ（Binomial Congestion Control）など、他の帯域推定手法にも、本発明を適用することができる。
本開示の通信システムは、実時間ストリームのパケットを送信する送信端末と、前記パケットを転送する転送端末と、前記パケットを受信する受信端末と、を有する通信システムであって、前記転送端末は、前記送信端末から送信された前記パケットをキャッシュするキャッシュ部と、前記受信端末からの要求に応じて、前記キャッシュ部にキャッシュされた前記パケットを前記受信端末へ転送する転送スタックと、を有し、前記受信端末は、前記受信端末と前記転送端末との間の利用可能帯域である第１の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第２の利用可能帯域と、を推定する利用可能帯域推定部と、前記転送端末が推定された前記第１の利用可能帯域を利用して前記パケットの転送を行うように、前記転送端末に対して前記パケットの転送の要求を行い、推定された前記第２の利用可能帯域を前記送信端末に対して通知するＲＴＣＰ−Ｒ制御部と、を有し、前記送信端末は、前記受信端末から通知された前記第２の利用可能帯域を利用して、前記パケットの送信を行う送信スタックと、を有する、
また、上記通信システムにおいて、前記送信端末、前記転送端末、および前記受信端末は、それぞれＣＣＮ対応の端末であり、前記要求は、前記実時間ストリームの名称を指定して前記実時間ストリームの返信を要求するパケットであるインタレストパケットの送信により行われてもよい。
本開示の受信端末は、実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける前記受信端末であって、前記受信端末と前記転送端末との間の利用可能帯域である第１の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第２の利用可能帯域と、を推定する利用可能帯域推定部と、推定された前記第１の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第１の利用可能帯域を利用して前記パケットを転送させ、推定された前記第２の利用可能帯域を前記送信端末に対して通知することにより、前記送信端末に対して、前記第２の利用可能帯域を利用して前記パケットを送信させる、ＲＴＣＰ−Ｒ制御部と、を有する。
また、上記受信端末において、前記送信端末、前記転送端末、および前記受信端末は、それぞれＣＣＮ対応の端末であり、前記要求は、前記実時間ストリームの名称を指定して前記実時間ストリームの返信を要求するパケットであるインタレストパケットの送信により行われてもよい。
また、上記受信端末は、前記受信端末と前記転送端末との間で前記パケットの受信を含む通信を行う受信スタックと、前記受信スタックにより行われた前記受信端末と前記転送端末との間の通信から、前記受信端末と前記転送端末との間の損失イベント率である第１の損失イベント率と、前記受信端末と前記転送端末との間のＲＴＴである第１のＲＴＴと、を算出するＲＴＴ−Ｒ変換部と、を更に有し、前記利用可能帯域推定部は、前記受信スタックが受信した前記パケットから、前記受信端末と前記送信端末との間の損失イベント率である第２の損失イベント率と、前記受信端末と前記送信端末との間のＲＴＴである第２のＲＴＴと、を算出し、算出された前記第１の損失イベント率および算出された前記第１のＲＴＴから、前記第１の利用可能帯域を推定し、算出された前記第２の損失イベント率および算出された前記第２のＲＴＴから、前記第２の利用可能帯域を推定し、前記ＲＴＣＰ−Ｒ制御部は、前記受信スタックに対して、前記インタレストパケットを、推定された前記第１の利用可能帯域に基づく前記頻度で、前記転送端末に対して送信することを指示してもよい。
また、上記受信端末において、前記ＲＴＴ−Ｒ変換部は、前記受信スタックが受信した前記パケットから、前記実時間ストリームのデータを抽出し、抽出された前記データから前記実時間ストリームを再生する実時間ストリーム再生部（映像デコーダ）、を更に有し、前記ＲＴＣＰ−Ｒ制御部は、前記第２の利用可能帯域が、前記送信端末が前記パケットの送信に利用している帯域である第２の実利用帯域よりも大きいか否かを判定し、前記第１の利用可能帯域が前記第２の実利用帯域よりも大きいことを条件として、前記実時間ストリーム再生部に対して、前記実時間ストリームを、本来の再生速度よりも速い速度で再生することを許可してもよい。
また、上記受信端末は、前記受信スタックが受信した前記パケットから、前記実時間ストリームを再生する実時間ストリーム再生部（映像デコーダ）、を更に有し、前記ＲＴＣＰ−Ｒ制御部は、前記第２の利用可能帯域が、前記送信端末が前記パケットの送信に利用している帯域である第２の実利用帯域よりも小さいか否かを判定し、前記第１の利用可能帯域が前記第２の実利用帯域よりも大きいことを条件として、前記受信スタックに対して、前記実時間ストリームを構成する一連の前記パケットを間引いて要求するように指示してもよい。
本発明の一態様にかかる送信端末は、実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける前記送信端末であって、前記実時間ストリームのデータを格納した前記パケットを送信する送信スタックと、前記受信端末と前記転送端末との間の利用可能帯域である第１の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第２の利用可能帯域と、を推定し、推定された前記第１の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第１の利用可能帯域を利用して前記パケットを転送させる前記受信端末から、前記第２の利用可能帯域の通知を受けるＲＴＣＰ−Ｓ制御部と、前記送信スタックに対して、前記受信端末から通知された前記第２の利用可能帯域を利用して前記パケットの送信を行わせる送信帯域推定部と、を有する。
本開示の流量制御方法は、実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける流量制御方法であって、前記受信端末において、前記受信端末と前記転送端末との間の利用可能帯域である第１の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第２の利用可能帯域と、を推定するステップと、前記受信端末において、推定された前記第１の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第１の利用可能帯域を利用して前記パケットを転送させ、推定された前記第２の利用可能帯域を前記送信端末に対して通知することにより、前記送信端末に対して、前記第２の利用可能帯域を利用して前記パケットを送信させるステップと、を有する。
２０１２年１０月２４日出願の特願２０１２−２３４６８２の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
本発明は、ＣＣＮをベストエフォート型のネットワークに適用して実時間ストリームのパケットを伝送する場合において、伝送性能の低下を防ぐことができる、通信システム、受信端末、送信端末、および流量制御方法として有用である。
２００ 受信端末
２０１ ＣＣＮ受信スタック
２０２ 受信側呼制御変換部
２０３ 受信側通話制御アプリ
２０４ ＲＴＰ−Ｒ変換部
２０５ 利用可能帯域推定部
２０６ ＲＴＣＰ−Ｒ制御部
２０７ 映像デコーダ
３００ 通信システム
４００ 送信端末
４０１ ＣＣＮ送信スタック
４０２ 送信側呼制御変換部
４０３ 送信側通話制御アプリ
４０４ 映像エンコーダ
４０５ ＲＴＰ−Ｓ変換部
４０６ ＲＴＣＰ−Ｓ制御部
４０７ 送信帯域推定部
５００ ＣＣＮネットワーク
５１０ ＣＣＮルータ
５１１ キャッシュ部
５１２ ＣＣＮ転送スタック
５２０ 非ＣＣＮルータ
５３０ ネットワーク回線

Claims (9)

  1. 実時間ストリームのパケットを送信する送信端末と、前記パケットを転送する転送端末と、前記パケットを受信する受信端末と、を有する通信システムであって、
    前記転送端末は、
    前記送信端末から送信された前記パケットをキャッシュするキャッシュ部と、
    前記受信端末からの要求に応じて、前記キャッシュ部にキャッシュされた前記パケットを前記受信端末へ転送する転送スタックと、を有し、
    前記受信端末は、
    前記受信端末と前記転送端末との間の利用可能帯域である第１の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第２の利用可能帯域と、を推定する利用可能帯域推定部と、
    前記転送端末が推定された前記第１の利用可能帯域を利用して前記パケットの転送を行うように、前記転送端末に対して前記パケットの転送の要求を行い、推定された前記第２の利用可能帯域を前記送信端末に対して通知するＲＴＣＰ−Ｒ制御部と、を有し、
    前記送信端末は、
    前記受信端末から通知された前記第２の利用可能帯域を利用して、前記パケットの送信を行う送信スタックと、を有する、
    通信システム。
  2. 前記送信端末、前記転送端末、および前記受信端末は、それぞれＣＣＮ（コンテンツ中心型ネットワーク）対応の端末であり、
    前記要求は、前記実時間ストリームの名称を指定して前記実時間ストリームの返信を要求するパケットであるインタレストパケットの送信により行われる、
    請求項１に記載の通信システム。
  3. 実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける前記受信端末であって、
    前記受信端末と前記転送端末との間の利用可能帯域である第１の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第２の利用可能帯域と、を推定する利用可能帯域推定部と、
    推定された前記第１の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第１の利用可能帯域を利用して前記パケットを転送させ、推定された前記第２の利用可能帯域を前記送信端末に対して通知することにより、前記送信端末に対して、前記第２の利用可能帯域を利用して前記パケットを送信させる、ＲＴＣＰ−Ｒ制御部と、を有する、
    受信端末。
  4. 前記送信端末、前記転送端末、および前記受信端末は、それぞれＣＣＮ（コンテンツ中心型ネットワーク）対応の端末であり、
    前記要求は、前記実時間ストリームの名称を指定して前記実時間ストリームの返信を要求するパケットであるインタレストパケットの送信により行われる、
    請求項３に記載の受信端末。
  5. 前記受信端末と前記転送端末との間で前記パケットの受信を含む通信を行う受信スタックと、
    前記受信スタックにより行われた前記受信端末と前記転送端末との間の通信から、前記受信端末と前記転送端末との間の損失イベント率である第１の損失イベント率と、前記受信端末と前記転送端末との間のＲＴＴである第１のＲＴＴと、を算出するＲＴＴ−Ｒ変換部と、を更に有し、
    前記利用可能帯域推定部は、
    前記受信スタックが受信した前記パケットから、前記受信端末と前記送信端末との間の損失イベント率である第２の損失イベント率と、前記受信端末と前記送信端末との間のＲＴＴである第２のＲＴＴと、を算出し、算出された前記第１の損失イベント率および算出された前記第１のＲＴＴから、前記第１の利用可能帯域を推定し、算出された前記第２の損失イベント率および算出された前記第２のＲＴＴから、前記第２の利用可能帯域を推定し、
    前記ＲＴＣＰ−Ｒ制御部は、
    前記受信スタックに対して、前記インタレストパケットを、推定された前記第１の利用可能帯域に基づく前記頻度で、前記転送端末に対して送信することを指示する、
    請求項４に記載の受信端末。
  6. 前記ＲＴＴ−Ｒ変換部は、
    前記受信スタックが受信した前記パケットから、前記実時間ストリームのデータを抽出し、
    抽出された前記データから前記実時間ストリームを再生する実時間ストリーム再生部（映像デコーダ）、を更に有し、
    前記ＲＴＣＰ−Ｒ制御部は、
    前記第２の利用可能帯域が、前記送信端末が前記パケットの送信に利用している帯域である第２の実利用帯域よりも大きいか否かを判定し、前記第１の利用可能帯域が前記第２の実利用帯域よりも大きいことを条件として、前記実時間ストリーム再生部に対して、前記実時間ストリームを、本来の再生速度よりも速い速度で再生することを許可する、
    請求項５に記載の受信端末。
  7. 前記受信スタックが受信した前記パケットから、前記実時間ストリームを再生する実時間ストリーム再生部（映像デコーダ）、を更に有し、
    前記ＲＴＣＰ−Ｒ制御部は、
    前記第２の利用可能帯域が、前記送信端末が前記パケットの送信に利用している帯域である第２の実利用帯域よりも小さいか否かを判定し、前記第１の利用可能帯域が前記第２の実利用帯域よりも大きいことを条件として、前記受信スタックに対して、前記実時間ストリームを構成する一連の前記パケットを間引いて要求するように指示する、
    請求項５に記載の受信端末。
  8. 実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける前記送信端末であって、
    前記実時間ストリームのデータを格納した前記パケットを送信する送信スタックと、
    前記受信端末と前記転送端末との間の利用可能帯域である第１の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第２の利用可能帯域と、を推定し、推定された前記第１の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第１の利用可能帯域を利用して前記パケットを転送させる前記受信端末から、前記第２の利用可能帯域の通知を受けるＲＴＣＰ−Ｓ制御部と、
    前記送信スタックに対して、前記受信端末から通知された前記第２の利用可能帯域を利用して前記パケットの送信を行わせる送信帯域推定部と、を有する、
    送信端末。
  9. 実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける流量制御方法であって、
    前記受信端末において、前記受信端末と前記転送端末との間の利用可能帯域である第１の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第２の利用可能帯域と、を推定するステップと、
    前記受信端末において、推定された前記第１の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第１の利用可能帯域を利用して前記パケットを転送させ、推定された前記第２の利用可能帯域を前記送信端末に対して通知することにより、前記送信端末に対して、前記第２の利用可能帯域を利用して前記パケットを送信させるステップと、を有する、
    流量制御方法。
JP2014543132A 2012-10-24 2013-10-02 通信システム、受信端末、送信端末、および流量制御方法 Active JP6187780B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2012234682 2012-10-24
JP2012234682 2012-10-24
PCT/JP2013/005880 WO2014064890A1 (ja) 2012-10-24 2013-10-02 通信システム、受信端末、送信端末、および流量制御方法

Publications (2)

Publication Number Publication Date
JPWO2014064890A1 true JPWO2014064890A1 (ja) 2016-09-08
JP6187780B2 JP6187780B2 (ja) 2017-08-30

Family

ID=50544276

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014543132A Active JP6187780B2 (ja) 2012-10-24 2013-10-02 通信システム、受信端末、送信端末、および流量制御方法

Country Status (4)

Country Link
US (3) US9749384B2 (ja)
JP (1) JP6187780B2 (ja)
CN (1) CN104782091B (ja)
WO (1) WO2014064890A1 (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11277598B2 (en) * 2009-07-14 2022-03-15 Cable Television Laboratories, Inc. Systems and methods for network-based media processing
WO2014064890A1 (ja) * 2012-10-24 2014-05-01 パナソニック株式会社 通信システム、受信端末、送信端末、および流量制御方法
KR101882727B1 (ko) * 2013-08-08 2018-07-27 삼성전자주식회사 컨텐츠 중심 네트워크를 구성하는 단말 장치 및 이의 통신 방법
US10063476B2 (en) * 2014-03-28 2018-08-28 Research & Business Foundation Sungkyunkwan University Content centric networking system providing differentiated service and method of controlling data traffic in content centric networking providing differentiated service
JP6348377B2 (ja) * 2014-08-27 2018-06-27 Kddi株式会社 コンテンツ配信ネットワークの通信装置及びプログラム
JP6478379B2 (ja) * 2014-08-29 2019-03-06 日本放送協会 映像送信装置
US10193662B2 (en) * 2014-09-19 2019-01-29 Panasonic Intellectual Property Corporation Of America Router, terminal, and congestion control method for router and terminal
US10003507B2 (en) * 2016-03-04 2018-06-19 Cisco Technology, Inc. Transport session state protocol
JP6674856B2 (ja) * 2016-07-27 2020-04-01 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 通信制御装置、通信制御方法及び通信制御システム
JP6373437B1 (ja) * 2017-03-29 2018-08-15 パナソニック株式会社 通信装置、通信システムおよびコンテンツ収集方法
CN109218122B (zh) * 2017-06-30 2022-04-29 华为技术有限公司 一种实现传输性能检测的方法、装置和系统
JP7460569B2 (ja) 2021-03-05 2024-04-02 Kddi株式会社 コンテンツ配信ネットワークの転送装置及びプログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002077263A (ja) * 2000-09-04 2002-03-15 Matsushita Electric Ind Co Ltd 送受信方法
JP2004516693A (ja) * 2000-05-17 2004-06-03 アメリカ オンライン インコーポレーテッド 通信帯域幅の自動検出に基づく通信コンテンツの選択
JP2004343698A (ja) * 2003-02-18 2004-12-02 Matsushita Electric Ind Co Ltd マルチメディア・ストリーミング環境におけるサーバベースのレート制御
WO2010138041A1 (en) * 2009-05-29 2010-12-02 Telefonaktiebolaget L M Ericsson (Publ) Methods, apparatuses and computer program products for media recording

Family Cites Families (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5870535A (en) * 1997-05-12 1999-02-09 Lexmark International, Inc. Method and apparatus for building rasterized lines of bitmap data to be printed using a piecewise-linear direct memory access addressing mode of retrieving bitmap data line segments
US8554940B2 (en) * 2001-01-19 2013-10-08 Single Touch Interactive, Inc. System and method for routing media
US20040264368A1 (en) * 2003-06-30 2004-12-30 Nokia Corporation Data transfer optimization in packet data networks
EP1528722A1 (en) * 2003-10-31 2005-05-04 Siemens Mobile Communications S.p.A. Fast signalling procedure for streaming services quality of service management in wireless networks
US10985811B2 (en) * 2004-04-02 2021-04-20 Rearden, Llc System and method for distributed antenna wireless communications
US20150319486A1 (en) * 2004-07-16 2015-11-05 Virginia Innovation Sciences, Inc. Method and apparatus for cross-layer optimization in multimedia communications with different user terminals
US20140071818A1 (en) * 2004-07-16 2014-03-13 Virginia Innovation Sciences, Inc. Method and system for efficient communication
US8503371B2 (en) * 2005-06-16 2013-08-06 Qualcomm Incorporated Link assignment messages in lieu of assignment acknowledgement messages
US8280982B2 (en) * 2006-05-24 2012-10-02 Time Warner Cable Inc. Personal content server apparatus and methods
US9386327B2 (en) * 2006-05-24 2016-07-05 Time Warner Cable Enterprises Llc Secondary content insertion apparatus and methods
US9094257B2 (en) * 2006-06-30 2015-07-28 Centurylink Intellectual Property Llc System and method for selecting a content delivery network
US8199653B2 (en) * 2006-08-22 2012-06-12 Embarq Holdings Company, Llc System and method for communicating network performance information over a packet network
WO2008041434A1 (fr) * 2006-10-02 2008-04-10 Panasonic Corporation Procédé de commande de flux, dispositif de terminal émetteur utilisé dans celui-ci, dispositif de terminal récepteur et système de transfert par paquets
US8456986B2 (en) * 2006-12-13 2013-06-04 Viasat, Inc. Video and data network load balancing
US8576858B2 (en) * 2006-12-13 2013-11-05 Viasat, Inc. Multiple transmission paths for hierarchical layers
US9137821B2 (en) * 2007-05-02 2015-09-15 Qualcomm Incorporated Flexible signaling of resources on a control channel
US8155063B2 (en) * 2008-04-28 2012-04-10 Apple Inc. Apparatus and methods for transmission and reception of data in multi-antenna systems
US8386622B2 (en) * 2008-05-16 2013-02-26 Palo Alto Research Center Incorporated Method and apparatus for facilitating communication in a content centric network
US8165118B2 (en) * 2008-05-19 2012-04-24 Palo Alto Research Center Incorporated Voice over content centric networks
JP4737243B2 (ja) * 2008-07-11 2011-07-27 ソニー株式会社 集積回路装置及びデータ伝送システム
US8924460B2 (en) * 2008-12-19 2014-12-30 International Business Machines Corporation Method and system of administrating a peer-to-peer file sharing network
WO2010093647A2 (en) * 2009-02-10 2010-08-19 Interdigital Patent Holdings, Inc. Spectrum management across diverse radio access technologies
CN101924742B (zh) * 2009-06-16 2014-07-30 华为技术有限公司 媒体传输方法及设备、媒体存储方法及设备
US11277598B2 (en) * 2009-07-14 2022-03-15 Cable Television Laboratories, Inc. Systems and methods for network-based media processing
EP2299757A3 (en) * 2009-09-22 2014-08-27 Nokia Corporation Cognitive control radio access information via database or cognitive pilot channel
WO2011043017A1 (ja) * 2009-10-08 2011-04-14 日本電気株式会社 コンテンツ配信システム
US8923293B2 (en) * 2009-10-21 2014-12-30 Palo Alto Research Center Incorporated Adaptive multi-interface use for content networking
US8285298B2 (en) * 2009-12-23 2012-10-09 At&T Mobility Ii Llc Chromatic scheduler for network traffic with disparate service requirements
US8504718B2 (en) * 2010-04-28 2013-08-06 Futurewei Technologies, Inc. System and method for a context layer switch
KR101688857B1 (ko) * 2010-05-13 2016-12-23 삼성전자주식회사 컨텐츠 중심 네트워크(ｃｃｎ)에서 단말 및 허브의 통신 방법 및 컨텐츠 중심 네트워크를 위한 단말
US8773982B2 (en) * 2010-06-16 2014-07-08 Panasonic Corporation Transmitting terminal and bandwidth estimating method
EP2620028B1 (en) * 2010-09-23 2020-04-29 BlackBerry Limited System and method for dynamic coordination of radio resources usage in a wireless network environment
US9020487B2 (en) * 2010-10-14 2015-04-28 At&T Mobility Ii Llc Over-the-air content management of wireless equipment in confined-coverage wireless networks
KR20170058451A (ko) * 2010-11-01 2017-05-26 인터디지탈 패튼 홀딩스, 인크 동적 스펙트럼 관리
KR20120092072A (ko) * 2011-02-10 2012-08-20 주식회사 팬택 무선통신 시스템에서 기기내 공존 간섭을 조정하는 장치 및 방법
FR2972884A1 (fr) * 2011-03-15 2012-09-21 France Telecom Procede de communication dans un reseau de communication avec acheminement par nom
US8589996B2 (en) * 2011-03-16 2013-11-19 Azuki Systems, Inc. Method and system for federated over-the-top content delivery
KR101451061B1 (ko) * 2011-04-28 2014-10-15 인텔 코포레이션 저 전력 무선 네트워크에서 통신을 위한 방법 및 장치
US9379970B2 (en) * 2011-05-16 2016-06-28 Futurewei Technologies, Inc. Selective content routing and storage protocol for information-centric network
US8855969B2 (en) * 2011-06-27 2014-10-07 International Business Machines Corporation Frequency guard band validation of processors
US9191459B2 (en) * 2011-07-12 2015-11-17 Futurewei Technologies, Inc. Method and apparatus for seamless mobility techniques in content-centric network
US8837511B2 (en) * 2011-08-12 2014-09-16 Futurewei Technologies, Inc. Seamless mobility schemes in names-data networking using multi-path routing and content caching
US8694675B2 (en) * 2011-09-01 2014-04-08 Futurewei Technologies, Inc. Generalized dual-mode data forwarding plane for information-centric network
US9078176B2 (en) * 2011-09-29 2015-07-07 Electronics And Telecommunications Research Institute System and method for multi-hierarchical cell configuration
WO2013060695A1 (en) * 2011-10-24 2013-05-02 Koninklijke Kpn N.V. Secure distribution of content
KR20130093813A (ko) * 2012-01-12 2013-08-23 삼성전자주식회사 컨텐츠 중심 네트워크에서 컨텐츠의 세그먼트를 프리패칭하는 대상 노드의 통신 방법 및 그 대상 노드
US10181049B1 (en) * 2012-01-26 2019-01-15 Hrl Laboratories, Llc Method and apparatus for secure and privacy-preserving querying and interest announcement in content push and pull protocols
US8762570B2 (en) * 2012-02-21 2014-06-24 Futurewei Technologies, Inc. Method and apparatus for adaptive forwarding strategies in content-centric networking
US9049251B2 (en) * 2012-02-28 2015-06-02 Futurewei Technologies, Inc. Method and apparatus for internet protocol based content router
WO2013155484A1 (en) * 2012-04-13 2013-10-17 Huawei Technologies Co., Ltd. Synchronizing content tables between routers
US9253087B2 (en) * 2012-04-24 2016-02-02 Futurewei Technologies, Inc. Principal-identity-domain based naming scheme for information centric networks
EP2842339A1 (en) * 2012-04-26 2015-03-04 Huawei Technologies Co., Ltd System and method for signaling segment encryption and key derivation for adaptive streaming
WO2014064890A1 (ja) * 2012-10-24 2014-05-01 パナソニック株式会社 通信システム、受信端末、送信端末、および流量制御方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004516693A (ja) * 2000-05-17 2004-06-03 アメリカ オンライン インコーポレーテッド 通信帯域幅の自動検出に基づく通信コンテンツの選択
JP2002077263A (ja) * 2000-09-04 2002-03-15 Matsushita Electric Ind Co Ltd 送受信方法
JP2004343698A (ja) * 2003-02-18 2004-12-02 Matsushita Electric Ind Co Ltd マルチメディア・ストリーミング環境におけるサーバベースのレート制御
WO2010138041A1 (en) * 2009-05-29 2010-12-02 Telefonaktiebolaget L M Ericsson (Publ) Methods, apparatuses and computer program products for media recording

Also Published As

Publication number Publication date
US10547661B2 (en) 2020-01-28
JP6187780B2 (ja) 2017-08-30
WO2014064890A1 (ja) 2014-05-01
CN104782091B (zh) 2017-09-22
US10212205B2 (en) 2019-02-19
CN104782091A (zh) 2015-07-15
US20150304380A1 (en) 2015-10-22
US20190141108A1 (en) 2019-05-09
US9749384B2 (en) 2017-08-29
US20170324798A1 (en) 2017-11-09

Similar Documents

Publication Publication Date Title
JP6187780B2 (ja) 通信システム、受信端末、送信端末、および流量制御方法
KR101054132B1 (ko) 패킷 교환 스트리밍을 위한 품질 메트릭 보고 방법
KR101099800B1 (ko) 미디어 서버로의 피드백 제공 방법
JP4448341B2 (ja) 帯域制御プログラム、方法およびエンド・システム
TWI594641B (zh) 保留通訊網路中交接之應用識別資訊的系統及方法
Matsuzono et al. Low latency low loss streaming using in-network coding and caching
JP5094593B2 (ja) 送信装置、受信装置、及び方法、プログラム
US20110058554A1 (en) Method and system for improving the quality of real-time data streaming
JP5207895B2 (ja) 送信装置、受信装置、及び方法、プログラム
JP4969342B2 (ja) 受信端末及び受信方法
JP5565121B2 (ja) 通信処理装置、通信処理システム、通信処理方法及びプログラム
Kim et al. A transmission control SCTP for real-time multimedia streaming
KR101405455B1 (ko) 서브 플로우를 기반으로 네트워크를 관리하기 위한 장치
JP2006109325A (ja) 通信システム、通信装置、およびプログラム
Singh et al. Rate-control for conversational video communication in heterogeneous networks
JP4237608B2 (ja) データ通信装置及びデータ通信システム
Arthur et al. The effects of packet reordering in a wireless multimedia environment
JP2011035700A (ja) ストリーム配信装置、ストリーム配信システム、ストリーム配信方法およびストリーム配信プログラム
JP2004153610A (ja) 動画像配信方法、無線端末、動画像配信制御装置、及び動画像配信システム
KR102491033B1 (ko) 왕복 시간 추정
Singh Protocols and Algorithms for Adaptive Multimedia Systems
Lai et al. Retransmission mechanism for partially reliable transport protocols based on multimedia applications transmission
Arsan An integrated software architecture for bandwidth adaptive video streaming
Chow et al. A novel approach to supporting multipoint-to-point video transmission over wireless ad hoc networks
Carlberg et al. Video Conferencing-Session and Transmission Control

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160721

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170711

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170718

R151 Written notification of patent or utility model registration

Ref document number: 6187780

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151