JPWO2014064890A1 - 通信システム、受信端末、送信端末、および流量制御方法 - Google Patents
通信システム、受信端末、送信端末、および流量制御方法 Download PDFInfo
- 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
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
CCNをベストエフォート型のネットワークに適用して実時間ストリームのパケットを伝送する場合において、伝送性能の低下を防ぐことができる受信端末。受信端末(200)は、受信端末(200)と、送信端末から送信された実時間ストリームのパケットをキャッシュして転送する転送端末と、の間の利用可能帯域である、第1の利用可能帯域と、受信端末(200)と送信端末との間の利用可能帯域である、第2の利用可能帯域と、を推定する利用可能帯域推定部(205)と、推定された第1の利用可能帯域に基づく頻度で、転送端末に対してパケットの転送の要求を行うことにより、転送端末に対して、第1の利用可能帯域を利用してパケットを転送させ、推定された第2の利用可能帯域を送信端末に対して通知することにより、送信端末に対して、第2の利用可能帯域を利用してパケットを送信させる、RTCP−R制御部(206)と、を有する。
Description
本発明は、実時間ストリームのパケットを伝送する通信システム、および、この通信システムで使用される受信端末、送信端末、および流量制御方法に関する。
近年、非特許文献1に記載のCCN(Content Centric Network:コンテンツ中心型ネットワーク)と呼ばれる技術が注目されている。CCNは、コンテンツをコンテンツの名前に基づいて管理するコンテンツ配信基盤である。
CCNでは、配信の対象となる各コンテンツ、もしくは、コンテンツを分割した各データに対して、予め名前が付与される。コンテンツを取得する受信端末は、「インタレストパケット(interest packet)」と呼ばれるパケットを発行する。インタレストパケットとは、コンテンツの名前(以下「コンテンツ名」という)を指定してコンテンツの送信を要求するパケットである。
コンテンツを出版した端末(送信端末)は、インタレストパケットを受信すると、当該インタレストパケットが指定するコンテンツ名に対応するコンテンツを、受信端末へ送信する。これにより、各受信端末は、コンテンツの所在が分からなくても、コンテンツ名に基づいてコンテンツを取得することができる。
また、CCNのメリットとして、過去にコンテンツの転送を行ったルータからコンテンツを取得可能である点が挙げられる。CCNにおいて、各ルータは、送信端末から受信端末へと転送するコンテンツを、キャッシュ(一定時間蓄積)する。そして、各ルータは、受信したインタレストパケットが指定するコンテンツをキャッシュしている場合、当該コンテンツを受信端末へ送信する。これにより、CCNでは、送信端末から当該ルータまでのコンテンツの伝送を再度行うことなく、コンテンツを受信端末へ送信することができる。
CCNにおける流量制御(フロー制御)の手法は、例えば、非特許文献1、特許文献1、および非特許文献3に記載されている。
非特許文献1に記載の流量制御は、TCP(Transmission Control Protocol)がACK(acknowledgement)を返送するのと同等のタイミングで、コンテンツを細かく分割したパーツ毎に、インタレストパケットを発行する。
このような流量制御によれば、受信端末は、TCPのACKが返送されるのと同等のタイミングで、コンテンツを取得することができる。
また、特許文献1および非特許文献3に記載の流量制御は、CCN上でVOIP(Voice Over IP)を実現するVoice Over CCNにおける、流量制御である。Voice Over CCNにおいて、各端末は、呼制御情報を、CCNのインタレストパケットを用いて伝送する。そして、各端末は、呼のネゴシエーションを行い、音声のRTP(Real-time Transport Protocol)パケットを送受信する準備を行う。受信端末は、音声データに対するインタレストパケットを定期的に発行する。送信端末は、インタレストパケットを受信する毎に、音声データを細かく分割したデータを格納したパケットを、順次、受信端末へ送信する。以下、音声データを分割したデータを格納したパケットは、「データパケット」という。
このような流量制御によれば、受信端末は、音声の実時間ストリームを、一定レートで取得することができる。また、上述の通り、CCNのルータは、実時間ストリームをキャッシュする。このため、最初にデータパケットの受信を開始した受信端末とは別の受信端末(以下、「他の受信端末」という)は、当該データパケットに対するインタレストパケットを発行する。このことにより、他の受信端末は、データパケットを、送信端末ではなくルータから取得することができる。
このように、CCNは、非特許文献1に記載の流量制御、および、特許文献1および非特許文献3に記載の流量制御を適用することにより、コンテンツを効率的に配布することができる。したがって、上述の流量制御を適用したCCNは、特に、実時間ストリームの配布に好適である。
ところで、近年、インターネットでは、動画ファイルや音声ファイルなど実時間ストリームのやり取りが活発に行われるようになってきている。このため、動画ファイルや音声ファイルなど実時間ストリームの伝送では、インターネットへのCCNの適用が期待される。
ところが、インターネットは、サービスの品質(QoS)が保証されないベストエフォート型ネットワーク(best effort network)であり、トラフィックが互いに競合している。このため、インターネットにおいて各送信端末が利用可能な帯域は、変動する。
このようなネットワークを介した実時間ストリームの伝送には、実時間ストリームのパケットがネットワークへ送出される流量を制御して、パケット落ちを防ぐ必要がある。実時間ストリームのパケットの流量を制御するためには、データ送信に利用することが可能な帯域(以下「利用可能帯域」という)を推定する手法が用いられる。そして、かかる流量の制御には、推定した利用可能帯域を利用してパケットが送信されるように実時間ストリームのエンコーダの符号量を制御する手法が、用いられる。
このような、ベストエフォート型ネットワークにおける適応流量制御のための帯域推定の手法は、例えば、非特許文献2に記載されている。
非特許文献2に記載のTFRC(TCP Friendly Rate Control)は、送信端末と受信端末の間の、往復時間RTT(Round Trip Time)および損失イベント率pを、計測する。そして、TFRCは、計測された往復時間RTTおよび損失イベント率pを、以下の式(1)に代入することにより、利用可能帯域の推定値[bps]Xcalを計算する。なお、式(1)において、sは、パケットサイズ[バイト]を示し、Rは、往復時間RTTの代表値[秒]を示し、t_RTOは、再送タイムアウトを示す。再送タイムアウトt_RTOは、4Rである。
このようにして推定された利用可能帯域を利用したコンテンツの送信では、TCP公平性が保たれるような、流量制御を行うことができる。すなわち、ベストエフォート型ネットワークは、非特許文献2に記載の流量制御を適用することにより、TCP公平性が保たれた状態での実時間ストリーム配信を実現することができる。
以上のように、CCNを対象とした特許文献1および非特許文献3と、ベストエフォート型ネットワークを対象とした非特許文献2とでは、異なる流量制御が提案されている。そこで、インターネットなどのベストエフォート型ネットワークでは、CCNを用いて映像音声データなどの実時間ストリームを伝送する場合、TFRCの帯域推定手法をCCN上に実装し、その推定値に基づいた流量制御が考えられる。
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.
しかしながら、実際には、上述のタイミングでインタレストパケットを発行するCCNに対して、上位層における流量制御であるTFRCを実装した場合、TFRCにおける利用可能帯域の推定を正しく行うことができない。
この理由は、下位層の流量制御(TCPと同等の動作を行うCCNのプロトコル動作)と上位層の流量制御(TFRC)とが、干渉することになるためである。そして、これにより、それぞれの流量制御は、設計意図の通りに流量制御が行われず、結果として、伝送性能が劣化してしまうためである。すなわち、従来技術は、CCNをベストエフォート型ネットワークに適用して実時間ストリームのパケットを伝送する場合、伝送性能が低下するという課題を有する。
本発明の目的は、CCNをベストエフォート型のネットワークに適用して実時間ストリームのパケットを伝送する場合において、伝送性能の低下を防ぐことである。
本開示の通信システムは、実時間ストリームのパケットを送信する送信端末と、前記パケットを転送する転送端末と、前記パケットを受信する受信端末と、を有する通信システムであって、前記転送端末は、前記送信端末から送信された前記パケットをキャッシュするキャッシュ部と、前記受信端末からの要求に応じて、前記キャッシュ部にキャッシュされた前記パケットを前記受信端末へ転送する転送スタックと、を有し、前記受信端末は、前記受信端末と前記転送端末との間の利用可能帯域である第1の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第2の利用可能帯域と、を推定する利用可能帯域推定部と、前記転送端末が推定された前記第1の利用可能帯域を利用して前記パケットの転送を行うように、前記転送端末に対して前記パケットの転送の要求を行い、推定された前記第2の利用可能帯域を前記送信端末に対して通知するRTCP−R制御部と、を有し、前記送信端末は、前記受信端末から通知された前記第2の利用可能帯域を利用して、前記パケットの送信を行う送信スタックと、を有する。
本開示の受信端末は、実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける前記受信端末であって、前記受信端末と前記転送端末との間の利用可能帯域である第1の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第2の利用可能帯域と、を推定する利用可能帯域推定部と、推定された前記第1の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第1の利用可能帯域を利用して前記パケットを転送させ、推定された前記第2の利用可能帯域を前記送信端末に対して通知することにより、前記送信端末に対して、前記第2の利用可能帯域を利用して前記パケットを送信させる、RTCP−R制御部と、を有する。
本開示の送信端末は、実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける前記送信端末であって、前記実時間ストリームのデータを格納した前記パケットを送信する送信スタックと、前記受信端末と前記転送端末との間の利用可能帯域である第1の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第2の利用可能帯域と、を推定し、推定された前記第1の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第1の利用可能帯域を利用して前記パケットを転送させる前記受信端末から、前記第2の利用可能帯域の通知を受けるRTCP−S制御部と、前記送信スタックに対して、前記受信端末から通知された前記第2の利用可能帯域を利用して前記パケットの送信を行わせる送信帯域推定部と、を有する。
本開示の流量制御方法は、実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける流量制御方法であって、前記受信端末において、前記受信端末と前記転送端末との間の利用可能帯域である第1の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第2の利用可能帯域と、を推定するステップと、前記受信端末において、推定された前記第1の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第1の利用可能帯域を利用して前記パケットを転送させ、推定された前記第2の利用可能帯域を前記送信端末に対して通知することにより、前記送信端末に対して、前記第2の利用可能帯域を利用して前記パケットを送信させるステップと、を有する。
本開示によれば、CCNをベストエフォート型ネットワークに適用して実時間ストリームのパケットを伝送する場合において、伝送性能の低下を防ぐことができる。
本発明の各実施の形態の説明に先立ち、本発明が生まれた背景について説明する。具体的には、CCNをベストエフォート型ネットワークに適用して実時間ストリームのパケットを伝送する場合において発生する、伝送性能の低下の原因解析とその解決方法について、説明する。
上記性能劣化が発生する原因としては、2つの現象が存在する。
背景技術で説明した往復時間RTTの計測は、送信端末がパケットに送信時刻を刻印し、受信端末が当該パケットの受信時刻を送信端末に返送し、送信端末が、送信時刻と受信時刻との差を算出することにより、行われる。ところが、下位層でTCPと同等のタイミングでパケットが伝送されていると、下位層のCCNのプロトコルスタックでは、パケットの送信が待たされることがある。これは、下位層において、TCPの輻輳ウインドウ制御と同等の動作が行われるためである。
このように、往復時間RTTの計測値は、下位層のCCNのプロトコルスタックで待たされた時間の分、大きくなる。往復時間RTTは、上述の式(1)において、分母に用いられる項である。したがって、上位層におけるTFRCによる利用可能帯域の推定値は、実際の利用可能帯域よりも小さくなる(第1の現象)。
一方、下位層がTCPと同等の動作を行うことによって、最大のスループットを得るには、常に送るべきデータが用意されていることが前提となっている。ところが、下位層がパケットを送信すべきタイミングにあるにもかかわらず、送信すべきパケットが用意されていない場合、下位層プロトコルにとっては、パケット送信の機会を損失することになる。例えば、複数のTCPフローが単一のボトルネックリンクを共有しているような場合、特定のフローに送るべきデータが存在しないタイミングが存在すると、その特定のフローは、パケット送信の機会を損失する。
したがって、上述のように、上位層における利用可能帯域の推定値が、実際の利用可能帯域(下位層で期待する帯域)を下回る場合、送りたくても送るべきパケットが存在しないことになる。すなわち、下位層プロトコルでは、本来得ることができるはずのスループット(TCP公平なスループット)が、得られないことになる(第2の現象)。
図1は、下位層の流量制御(TCPと同等の動作を行うCCNのプロトコル動作)が行われる場合のスループットの時間変化と、上位層の流量制御(TFRC)が行われる場合のスループットの時間変化とを、示した図である。
TCPでは、輻輳回避モードとなると、ロスが発生するまで直線的に送信量(輻輳ウインドウ)を増加し、ロスが発生すると送信量を半減させるという動作が繰り返される。したがって、図1に示すように、TCPのスループット101は、直角三角形状(鋸形状)の変化を繰り返す。
一方、TFRCでは、損失イベント率pの計算や往復時間RTTの計算は、指数荷重移動平均が用いられることにより、過去の値に引きずられる。したがって、図1に示すように、TFRCのスループット102は、滑らかな増減を繰り返す。なお、TCPのスループット101の平均値、および、TFRCのスループット102の平均値は、所定の一定値103に近づく。
TCPのスループット101がTFRCのスループット102より低い区間では、上述の第1の現象が発生する。そして、TFRCのスループット102がTCPのスループット101より低い区間では、上述の第2の現象が発生する。
このように、下位層の流量制御と上位層の流量制御とを単純に組み合わせるのみでは、これらの異なる流量制御が互いに干渉し合い、実時間ストリームの伝送性能の低下をもたらすことになる。そして、その結果、受信端末が再生する映像音声などのコンテンツの品質は、低下する。
そこで、本発明は、受信端末とパケットを転送する転送端末との間の利用可能帯域を推定し、その推定結果に基づいて、下位層の流量制御を行う。そして、本発明は、受信端末とパケットの送信元である送信端末との間の利用可能帯域とを推定し、その推定結果に基づいて、上位層の流量制御を行う。これにより、本発明は、下位層の流量制御と上位層の流量制御とが互いに悪影響を及ぼすのを防ぐ。すなわち、本発明は、CCNをベストエフォート型ネットワークに適用した実時間ストリームのパケットの伝送において、伝送性能の低下を防止する。
以下、本発明の各実施の形態について、図面を参照して詳細に説明する。
(実施の形態1)
本発明の実施の形態1は、本発明の基本的態様の一例である。
本発明の実施の形態1は、本発明の基本的態様の一例である。
より具体的には、本実施の形態は、送信端末、転送端末、および受信端末を有する通信システムに関するものである。ここで、送信端末は、実時間ストリームのパケットを送信する端末(出版元、Publisher)である。転送端末は、送信端末から送信されたパケットをキャッシュして転送する端末である。受信端末は、転送端末から転送されたパケットを受信する端末である。
図2は、本実施の形態に係る通信システムの各装置の構成を示すブロック図である。
図2において、通信システム300は、送信端末400、転送端末(CCNルータ)510、および受信端末200を有する。
転送端末510は、キャッシュ部511および転送スタック512を有する。
キャッシュ部511は、送信端末400から送信されたパケットをキャッシュする。
転送スタック512は、受信端末200からの要求に応じて、キャッシュ部511にキャッシュされたパケットを受信端末200へ転送する。
受信端末200は、受信スタック201、利用可能帯域推定部205、およびRTCP−R制御部206を有する。
受信スタック201は、受信端末200と転送端末510との間でパケットの受信を含む通信を行う。
利用可能帯域推定部205は、受信端末200と転送端末510との間の利用可能帯域である第1の利用可能帯域と、受信端末200と送信端末400との間の利用可能帯域である第2の利用可能帯域とを推定する。
RTCP−R制御部206は、転送端末510が推定された第1の利用可能帯域を利用してパケットの転送を行うように、転送端末510に対してパケットの転送の要求を行う。また、RTCP−R制御部206は、推定された第2の利用可能帯域を送信端末400に対して通知する。この通知は、例えば、受信スタック201および転送端末510を介して行われる。
送信端末400は、送信スタック401、RTCP−S制御部406、および送信帯域推定部407を有する。
送信スタック401は、実時間ストリームのデータを格納したパケットを送信する。
RTCP−S制御部406は、受信端末から、第2の利用可能帯域の通知を受ける。
送信帯域推定部407は、送信スタック401に対して、受信端末200から通知された第2の利用可能帯域を利用してパケットの送信を行わせる。
また、受信端末200、送信端末400、および転送端末510は、図示しないが、例えば、CPU(Central Processing Unit)、制御プログラムを格納したROM(Read Only Memory)などの記憶媒体、RAM(Random Access Memory)などの作業用メモリ、および通信回路などを、それぞれ有する。この場合、上記した各部の機能は、CPUが制御プログラムを実行することにより実現される。
このような本実施の形態に係る通信システム300は、受信端末200と転送端末510との間の利用可能帯域に基づいた転送端末510の流量制御を、実現することができる。そして、本実施の形態に係る通信システム300は、かかる流量制御と併せて、受信端末200と送信端末400との間の利用可能帯域の推定値に基づいた送信端末400の流量制御を、実現することができる。
送信端末400、転送端末510、および受信端末200は、例えば、それぞれCCNに対応した端末とすることができる。この場合、転送端末510の流量制御は、上述の下位層の流量制御(TCPと同等の動作を行うCCNのプロトコル動作)であり、送信端末400の流量制御は、上述の上位層の流量制御(TFRC)である。したがって、受信端末200と転送端末510との間の利用可能帯域に基づいた転送端末510の流量制御を行うことにより、上述の第1の現象を回避することができる。また、受信端末200と送信端末400との間の利用可能帯域の推定値に基づいた送信端末400の流量制御を行うことにより、送信端末400で推定帯域に則したデータの生成量が制御しやすくなる。すなわち、かかる流量制御により、上述の第2の現象を回避することができる。
すなわち、本実施の形態に係る受信端末200は、インターネットなどのベストエフォート型ネットワークでCCNを下位層に適用した場合でも、上位層の流量制御の性能を劣化させることがない帯域推定を可能にする。下位層のCCNの流量制御が上位層の流量制御を妨げないため、TCP公平性が上位層で保証される。これにより、受信端末200は、TCP公平性を満たしながら、映像音声などの実時間ストリームの流量をネットワークの混雑度合に応じて適応的に制御し、適切な送信レートが実現されるようにすることができる。
すなわち、本実施の形態に係る受信端末200は、CCNをベストエフォート型ネットワークに適用して実時間ストリームのパケットを伝送する場合において、伝送性能の低下を防ぐことができる。
なお、CCNに対応したルータ(以下「CCNルータ」という)にキャッシュされた実時間ストリームは、既に送信端末から出版されて蓄積されたものである。このようなキャッシュ済みのストリームの送信には、CCNルータから受信端末への利用可能帯域は影響するが、送信端末からCCNルータへの利用可能帯域は影響しない。これにより、キャッシュ済みのストリームについては、送信端末による本来の送信レートよりも高いレートで受信することが可能となり、受信端末において本来の再生速度よりも速い速度で再生することが可能である。
例えば、他の受信端末がインタレストパケットを2倍の頻度で発行すれば、データパケットは、倍速でルータ上のキャッシュから伝送されてくる。そして、他の受信端末が受信したデータパケットから抽出した音声データを、音の高さを調整しながら倍速再生させれば、他の受信端末のユーザは、音声データの最後まで、後から追い付いて聞くことができる。
したがって、Voice Over CCNでは、既に開始されている会話に、第三者が途中から参加するようなアプリケーションを、構築することができる。
このようなアプリケーションにおいて、送信端末からCCNルータへと実時間ストリームを送信するのに適した送信レートと、CCNルータから受信端末へと実時間ストリームを送信するのに適した送信レートとは、必ずしも一致しない。したがって、本実施の形態に係る受信端末200は、このようなアプリケーションに好適である。
(実施の形態2)
本発明の実施の形態2は、本発明の具体的態様の一例である。
本発明の実施の形態2は、本発明の具体的態様の一例である。
より具体的には、本実施の形態は、CCNに対応した送信端末、CCNに対応した転送端末、およびCCNに対応した受信端末を含む通信システムにおける、CCNに対応した受信端末に関するものである。ここで、送信端末は、実時間ストリームである映像データのパケットを送信(出版)する端末である。転送端末は、送信端末から送信されたパケットをキャッシュして転送するルータである。受信端末は、転送端末から転送されたパケットを受信する端末である。
まず、本実施の形態に係る通信システムの構成について説明する。
<通信システムの構成>
図3は、本実施の形態に係る通信システムの構成の一例を示すシステム構成図である。
図3は、本実施の形態に係る通信システムの構成の一例を示すシステム構成図である。
図3において、通信システム300は、送信端末400、第1の受信端末2001、および第2の受信端末2002を有する。これらの端末は、CCNネットワーク500に接続されている。
CCNネットワーク500は、CCNに対応した複数の転送端末(以下「CCNルータ」という)510と、CCNに対応していない複数の転送端末(以下「非CCNルータ」という)520とを有する。そして、CCNネットワーク500は、これらを接続する複数のネットワーク回線530を有する。
第1の受信端末2001および第2の受信端末2002は、同一のCCNルータである第1のCCNルータ5101に接続している。すなわち、送信端末400から第1の受信端末2001へと至る経路と、送信端末400から第2の受信端末2002へと至る経路とは、第1のCCNルータ5101まで共通しており、第1のCCNルータ5101において枝分かれしている。
CCNネットワーク500は、CCNネットワークであり、図示する以外にも多数の端末が接続され、多数の端末が互いにネットワーク回線530の帯域を共有する、ベストエフォート型ネットワークである。
CCNネットワーク500における競合トラフィックとしては、現在のインターネットと同様に、HTTP(Hyper Text Transfer Protocol)、あるいは、FTP(File Transfer Protocol)などの、いわゆるTCPのトラフィックが大半を占めているものとする。すなわち、CCNネットワーク500は、TCP公平性が要求されるネットワークである。
第1の受信端末2001および第2の受信端末2002は、同一の構成を有するため、これらを、適宜、「受信端末200」としてまとめて説明する。送信端末400、受信端末200、およびCCNルータ510の構成については、後述する。非CCNルータ520は、従来のルータなどの転送端末と同様の構成を有しているため、これの構成についての説明を省略する。また、CCNに対応したノードである、送信端末400、CCNルータ510、および受信端末200は、適宜、「CCNノード」と総称する。
また、受信端末200は、上述のVoice Over CCNを用いて、映像データの配信を受けるものとする。すなわち、受信端末200は、映像データを細かく分割したデータ(以下「分割データ」という)のそれぞれに対して、順次、インタレストパケットを発行するものとする。
<通信方式の概要>
次に、通信システム300における通信方式の概要について説明する。
次に、通信システム300における通信方式の概要について説明する。
通信システム300において、CCNの転送の対象となる全ての実時間データストリームには、予め名前が付与されている。実時間データストリームに付与された名前は、以下、「コンテンツ名」という。
<コンテンツ名の例>
図4は、コンテンツ名の一例を示す図である。
図4は、コンテンツ名の一例を示す図である。
図4に示すように、コンテンツ名610は、ユーザ/アプリケーション提供元名(user/app supplied name)領域611と、バージョニング・セグメンテーション(versioning & Segmentation)領域612とから成る。ユーザ/アプリケーション提供名領域611は、グローバリルータブル名(globally-routable name)領域613と、機関名(organizational name)領域614とからなる。バージョニング・セグメンテーション領域612は、慣習的にあるいは自動的に決定される部分(conventional/automatic)である。なお、コンテンツ名610は、例えば、バイナリエンコーディングされて使用される。
コンテンツを取得する受信端末200は、コンテンツ名を指定して、コンテンツの送信を要求するインタレストパケットを発行する。
なお、本実施の形態において、コンテンツ名は、元の映像データの出版元の識別情報と、呼を特定するID(Call-ID)と、分割データの通番(RTPの通番)と、タイムスタンプと、を含む名前空間である。
<インタレストパケットの構成例>
図5は、インタレストパケットの構成の一例を示す模式図である。
図5は、インタレストパケットの構成の一例を示す模式図である。
図5に示すように、インタレストパケット620は、コンテンツ名(content name)621、セレクタ(selector)622、およびノンス(nonce)623を含む。コンテンツ名621は、インタレストパケット620の送信元が返信を要求する対象として指定する映像データの分割データのコンテンツ名である。ノンス623は、使い捨て乱数値である。セレクタ622は、要求の優先度、発行元のフィルタ、スコープなどである。
このようなインタレストパケット620は、映像データの分割データを指定し、指定した分割データの配信が、インタレストパケット620の送信元によって要求されていることを示すことができる。なお、図示しないが、インタレストパケット620には、インタレストパケット620の送信元を示す情報その他が付与されている。
インタレストパケットが指定する分割データを保持(キャッシュを含む)しているCCNノードは、インタレストパケットを受信すると、指定された分割データ(主信号)を格納したパケットを生成する。分割データを格納したパケットは、以下、「データパケット」という。そして、当該CCNノードは、生成したデータパケットを、インタレストパケットの送信元へ送信する。
<データパケットの構成例>
図6は、データパケットの構成の一例を示す模式図である。
図6は、データパケットの構成の一例を示す模式図である。
図6に示すように、データパケット630は、コンテンツ名(content name)631、署名(signature)632、署名済み情報(signed Info)633、およびデータ(data)634を含む。
データ634は、データパケット630が格納する分割データである。コンテンツ名631は、データパケット630が格納する分割データのコンテンツ名である。署名632は、データパケット630が格納する分割データに対する、ダイジェスト・アルゴリズム(digest algorithm)、あるいは、ウィットネス(witness)などによる電子署名である。署名済み情報633は、署名済みの、出版元ID、キーロケータ(key locator)、遅延時間(stale time)などを含む。
このようなデータパケット630は、分割データが真正であることを証明しつつ、映像データの分割データを格納して伝送することができる。なお、図示しないが、データパケット630には、データパケット630送信元および送信先を示す情報その他が付与されている。
このような通信方式により、通信システム300の各受信端末200は、コンテンツの所在が分からなくても、コンテンツ名に基づいて、コンテンツを取得することができる。
次に、受信端末200、送信端末400、およびCCNルータ510のそれぞれの構成について説明する。
図7は、受信端末200、送信端末400、およびCCNルータ510の構成の一例を示すブロック図である。
<受信端末の説明>
図7において、受信端末200は、CCN受信スタック201、受信側通話制御アプリ203、受信側呼制御変換部202、RTP−R変換部204、映像デコーダ207、利用可能帯域推定部205、およびRTCP−R制御部206を有する。
図7において、受信端末200は、CCN受信スタック201、受信側通話制御アプリ203、受信側呼制御変換部202、RTP−R変換部204、映像デコーダ207、利用可能帯域推定部205、およびRTCP−R制御部206を有する。
CCN受信スタック201は、CCNのプロトコル動作を行い、特に、データインタレストパケットの送信に対応して、データパケットの受信を行う。本実施の形態において、CCN受信スタック201は、コンテンツ名を指定したインタレストパケットを連続して発行し、データパケットを取得することにより、映像データのストリーミング伝送を実現する。CCN受信スタック201は、受信したデータパケットを、RTP−R変換部204へ出力する。また、CCN受信スタック201は、インタレストパケットの発行時刻と、データパケットの到着時刻とを、記録し、RTP−R変換部204へ通知する。
受信側呼制御変換部202は、CCN受信スタック201を介して、他のCCNノードとの呼を確立し、通信で使用するコーデックおよびポート番号等を確定する。すなわち、受信側呼制御変換部202は、SIP(Session Initiation Protocol)による通信制御を、CCNのインタレストパケットに乗せて、他のCCNノードと交換する(非特許文献3参照)。
受信側通話制御アプリ203は、通信制御アプリケーションであり、受信側呼制御変換部202を介して、CCN受信スタック201に対し、他のCCNノードとの通信の開始および終了を指示する。また、受信側通話制御アプリ203は、CCN受信スタック201および映像デコーダ207に対し、追い付き再生の開始および終了を指示する。追い付き再生の詳細については、後述する。
RTP−R変換部204は、CCN受信スタック201から入力されたデータパケットから、分割データを抽出し、RTPの通番の順序に従って、抽出した分割データを、映像デコーダ207へ出力する。また、RTP−R変換部204は、受信端末200と、CCN受信スタック201により行われた他のCCNノードとの間の通信から、受信端末200と当該他のCCNノードとの間の損失イベント率PおよびRTTを算出する。そして、RTP−R変換部204は、算出した損失イベント率Pおよび往復時間RTTを、利用可能帯域推定部205へ出力する。
損失イベント率Pは、例えば、データパケットの通番の隔たりを監視することによってデータパケットの損失を検出し、データパケットの損失から、非特許文献3に記載の手法を用いて、算出することができる。
また、往復時間RTTは、例えば、インターネット関連技術の標準化団体であるIETF(Internet Engineering Task Force)が発行したRFC3550に記載された手法を用いて、算出することができる。かかる手法は、送信側SR(Sender Report)の送信時刻を記録し、RR(Receiver Report)によって受信側から返送される情報に基づいて、往復時間RTTを算出する手法である。受信側から返送される情報は、例えば、タイムスタンプ、および、受信端末200内部でのSR受信からRR送信までの間の遅延時間の情報(DLSR:Delay since Last SR)である。
以下の説明において、それぞれの受信端末200が取得の目的とする映像データを保持(キャッシュを含む)している、CCNノードのうち、受信端末200に最も近接するCCNノードは、「近接CCNノード」という。どのCCNノードが近接CCNノードとなるかは、取得の目的となる映像データ、受信端末200のCCNネットワーク500との接続位置、および、CCNネットワーク500における当該映像データの保持状態の変化、に応じて異なる。
また、受信端末200と近接CCNノードとの間の損失イベント率Pは、「近接損失イベント率Pn」(第1の損失イベント率)という。受信端末200と近接CCNノードとの間(図7に示す矢印641の区間)の往復時間RTTは、「近接往復時間RTTn」(第1のRTT)という。受信端末200と送信端末400との間(図7に示す矢印642の区間)の損失イベント率Pは、「通常損失イベント率Ps」(第2の損失イベント率)という。受信端末200と送信端末400との間の往復時間RTTは、「通常往復時間RTTs」(第2のRTT)という。
利用可能帯域推定部205は、入力された損失イベント率Pおよび往復時間RTTから、上述の式(1)を用いて、受信端末200と対応するCCNノードとの間の利用可能帯域の推定値Xcalを算出する。そして、利用可能帯域推定部205は、算出した利用可能帯域の推定値Xcalを、RTCP−R制御部206へ出力する。
以下の説明において、近接損失イベント率Pnおよび近接往復時間RTTnから算出された、受信端末200と近接CCNノードとの間の利用可能帯域の推定値Xcalは、「近接帯域推定値Xcaln」(第1の利用可能帯域)という。通常損失イベント率Psおよび通常往復時間RTTsから算出された、受信端末200と送信端末400との間の利用可能帯域の推定値Xcalは、「通常帯域推定値Xcals」(第2の利用可能帯域)という。
なお、利用可能帯域推定部205は、近接帯域推定値Xcalnを、受信側通話制御アプリ203にも通知する。これは、後述の追い付き再生のためである。
RTCP−R制御部206は、近接CCNノードが近接帯域推定値Xcalnにより示される帯域を利用してデータパケットの転送を行うように、近接CCNノードに対してデータパケットの転送の要求を行う。より具体的には、RTCP−R制御部206は、近接帯域推定値Xcalnを、CCN受信スタック201へ出力する。そして、RTCP−R制御部206は、CCN受信スタック201に対して、取得の対象となる映像データの分割データをコンテンツ名により指定したインタレストパケットを、近接帯域推定値Xcalnに対応する間隔で順次送信させる。
また、RTCP−R制御部206は、通常帯域推定値Xcalsを、CCN受信スタック201を介して、送信端末400に対して通知する。この結果、後述するが、送信端末400は、通常帯域推定値Xcalsが示す帯域を利用して、映像データの分割データの送信を行う。この分割データは、上述の通り、CCN受信スタック201およびRTP−R変換部204を介して、映像デコーダ207へ入力される。
なお、RTCP−R制御部206は、通常帯域推定値Xcalsに加えて、通常帯域推定値Xcals以外の付加情報を送信端末400に対して通知してもよい。付加情報は、例えば、映像データのうち再生中のデータ部分が格納されていたデータパケットのタイムスタンプ、当該データパケットの通番、送信端末400と受信端末200との間の往復時間RTT、を示す情報等を含む。
映像デコーダ207は、RTP−R変換部204から入力された分割データから基の映像データをデコードし、デコードされた映像データを、受信端末200に接続された映像表示装置やレコーダなどの映像出力装置(図示せず)へ出力する。また、映像デコーダ207は、デコード中の映像データのデータ量を、例えば、データパケットのヘッダ情報から取得し、受信側通話制御アプリ203へ通知する。これは、後述の追い付き再生のためである。
なお、利用可能帯域と遅延(往復時間RTTの半分)との積は、送信端末400と受信端末200との間と、CCNルータ510と受信端末200との間で、異なることになる。
<送信端末の説明>
図7において、送信端末400は、CCN送信スタック401、送信側通話制御アプリ403、送信側呼制御変換部402、映像エンコーダ404、RTP−S変換部405、RTCP−S制御部406、および送信帯域推定部407を有する。
図7において、送信端末400は、CCN送信スタック401、送信側通話制御アプリ403、送信側呼制御変換部402、映像エンコーダ404、RTP−S変換部405、RTCP−S制御部406、および送信帯域推定部407を有する。
CCN送信スタック401は、CCNのプロトコル動作を行い、特に、インタレストパケットの受信に対応して、データパケットの送信を行う。
なお、RTCP−S制御部406は、受信端末200から通常帯域推定値Xcalsを通知される。このとき、CCN送信スタック401は、送信帯域推定部407の機能により、通常帯域推定値Xcalsを利用してデータパケットの送信を行うことになる。
送信側呼制御変換部402は、CCN送信スタック401を介して、他のCCNノードとの呼を確立し、通信で使用するコーデックおよびポート番号等を確定する。すなわち、送信側呼制御変換部402は、SIPによる通信制御を、CCNのデータパケットに乗せて、他のCCNノードと交換する(非特許文献3参照)。
送信側通話制御アプリ403は、通信制御アプリケーションであり、送信側呼制御変換部402を介して、CCN送信スタック401に対し、他のCCNノードとの通信の開始および終了を指示する。
映像エンコーダ404は、カメラや映像再生機などの映像入力装置(図示せず)から、映像の実時間データ(映像データ)を入力する。映像エンコーダ404は、後述する送信帯域推定部407から通知される目標ビットレートに従って、入力された映像データのエンコードを行う。そして、映像エンコーダ404は、エンコードされた映像データを、RTP−S変換部405へ出力する。
RTP−S変換部405は、映像エンコーダ404から入力された映像データを、複数の分割データに分割する。RTP−S変換部405は、分割データに対して、RTPの通番、タイムスタンプ、マーカビットなどの情報を記載したRTPパケットヘッダを付与し、コンテンツ名との対応付けを行って、CCNのデータパケットを生成する。そして、RTP−S変換部405は、生成したデータパケットを、CCN送信スタック401を介して、受信端末200へ送信する。
RTCP−S制御部406は、CCN送信スタック401を介して、受信端末200のRTCP−R制御部206から、通常帯域推定値Xcalsの通知を受ける。そして、RTCP−S制御部406は、通知された通常帯域推定値Xcalsを、送信帯域推定部407へ出力する。なお、RTCP−S制御部406は、上述の付加情報を通知された場合、当該付加情報を併せて送信帯域推定部407へ出力してもよい。
送信帯域推定部407では、RTCP−S制御部406から入力された、少なくとも通常帯域推定値Xcalsを含む情報に基づいて、通常帯域推定値Xcalsの送信元である受信端末200に対して採用すべき帯域を決定する。そして、送信帯域推定部407は、決定した帯域を利用して映像データの送信(パケットの送信)が行われるような、エンコーディングの目標ビットレートを、映像エンコーダ404に通知する。
なお、送信帯域推定部407は、受信端末200から通知された通常帯域推定値Xcalsを、そのまま、通常帯域推定値Xcalsの送信元である受信端末200に適用すべき帯域に決定することもある。この場合、結果的に、送信帯域推定部407は、CCN送信スタック401に対し、受信端末200から通知された通常帯域推定値Xcalsを利用してデータパケットの送信を間接的に行わせることになる。
<CCNルータの説明>
図7において、CCNルータ510は、キャッシュ部511およびCCN転送スタック512を有する。
図7において、CCNルータ510は、キャッシュ部511およびCCN転送スタック512を有する。
キャッシュ部511は、送信端末400から送信されたデータパケットのうち、過去にCCNルータ510が転送を行ったデータパケットの複製をキャッシュする。
CCN転送スタック512は、CCNのプロトコル動作を行う。すなわち、CCN転送スタック512は、受信端末200から送信されたインタレストパケットを受信し、対応するデータパケットがキャッシュ部511にキャッシュされていない場合、受信したインタレストパケットを転送する。
また、CCN転送スタック512は、送信端末400から送信されたデータパケットを、そのデータパケットの送信先である受信端末200に対して転送する。また、CCN転送スタック512は、そのデータパケットの複製を、キャッシュ部511にキャッシュさせる。そして、CCN転送スタック512は、受信端末200からの要求に応じて、キャッシュ部511にキャッシュされたデータパケットを、その受信端末200へ転送する。
すなわち、CCN転送スタック512は、受信端末200から送信されたインタレストパケットを受信する。そして、CCN転送スタック512は、対応するデータパケットがキャッシュ部511にキャッシュされている場合、そのデータパケットを、インタレストパケットの送信元へ返信する。
なお、受信端末200、送信端末400、およびCCNルータ510は、図示しないが、例えば、CPU、制御プログラムを格納したROMなどの記憶媒体、RAMなどの作業用メモリ、および通信回路などを、それぞれ有する。この場合、上記した各部の機能は、CPUが制御プログラムを実行することにより実現される。
次に、受信端末200、送信端末400、およびCCNルータ510のそれぞれの動作について説明する。
<受信端末の動作説明>
図8は、受信端末200の動作の一例を示すフローチャートである。
図8は、受信端末200の動作の一例を示すフローチャートである。
まず、ステップS1100において、RTP−R変換部204は、近接帯域推定値Xcalnおよび通常帯域推定値Xcalsを推定するタイミング(以下「帯域推定タイミング」という)が到来したか否かを判断する。帯域推定タイミングは、例えば、タイマーなどを用いて計測される所定のタイムアウト時間が経過したタイミングや、CCN受信スタック201がデータパケットを受信したタイミングである。
RTP−R変換部204は、RTPパケットが受信された場合、RTP−R変換部204自身がこれを検知し、RTCPパケットが受信された場合、CCN受信スタック201からの通知によりこれを検知する。タイムアウト時間は、パケットが長時間到着しなかったことを検知するために設定されるものであり、例えば100msである。
RTP−R変換部204は、帯域推定タイミングが到来した場合(S1100:YES)、ステップS1200へ進む。また、RTP−R変換部204は、帯域推定タイミングが到来していない場合(S1100:NO)、後述のステップS1300へ進む。
ステップS1200において、受信端末200は、RTP−R変換部204、利用可能帯域推定部205、およびRTCP−R制御部206において、帯域推定処理を行う。帯域推定処理は、近接帯域推定値Xcalnおよび通常帯域推定値Xcalsを推定するための処理である。なお、帯域推定処理については、後述する。
ステップS1300において、CCN受信スタック201は、処理TICKが到来したか否かを判断する。処理TICKとは、所定の時間長さ毎に定期的に到来するタイミングである。所定の時間長さは、組み込み端末で広く用いられているLinux(登録商標)OSの場合、4msあるいは1msが一般的である。但し、所定の時間長さは、この値に限定されず、通常帯域推定値Xcalsと同等もしくはそれ以下であればよい。
CCN受信スタック201は、処理TICKが到来した場合(S1300:YES)、ステップS1400へ進む。CCN受信スタック201は、処理TICKが到来していない場合(S1300:NO)、後述のステップS1500へ進む。
ステップS1400において、CCN受信スタック201は、インタレストパケット発行処理を行う。インタレストパケット発行処理は、近接帯域推定値Xcalnが示す帯域を最大限に利用してインタレストパケットを発行する処理である。より具体的には、指定された帯域幅でデータパケットを受信するようにインタレストパケットを発行するために、いわゆるトークンバケツ方式を用いて、トークンの発行数を制御する処理である。なお、インタレストパケットの発行処理については、後述する。
図8のステップS1500において、RTP−R変換部204は、ユーザ操作等により処理の終了を指示されたか否かを判断する。
RTP−R変換部204は、処理の終了を指示されていない場合(S1500:NO)、ステップS1100へ戻る。また、RTP−R変換部204は、処理の終了を指示された場合(S1500:YES)、一連の処理を終了する。
<受信端末200の帯域推定処理>
図9は、受信端末200の帯域推定処理(図8のステップS1200)の一例を示すフローチャートである。
図9は、受信端末200の帯域推定処理(図8のステップS1200)の一例を示すフローチャートである。
まず、ステップS1201において、RTP−R変換部204は、帯域推定タイミングの到来が、RTPパケットの受信またはタイムアウトにより発生した事象であるか否かを判断する。
RTP−R変換部204は、帯域推定タイミングの到来がRTPパケットの受信またはタイムアウトにより発生した事象ではない場合(S1201:NO)、ステップS1202へ進む。また、RTP−R変換部204は、帯域推定タイミングの到来がRTPパケットの受信またはタイムアウトにより発生した事象である場合(S1201:YES)、ステップS1203へ進む。
ステップS1202において、RTP−R変換部204は、帯域推定タイミングの到来がRCTPパケットの受信により発生した事象であるか否かを判断する。
RTP−R変換部204は、帯域推定タイミングの到来がRCTPパケットの受信により発生した事象である場合(S1202:YES)、ステップS1204へ進む。また、RTP−R変換部204は、帯域推定タイミングの到来がRCTPパケットの受信により発生した事象ではない場合(S1202:NO)、図8の処理へ戻る。
ステップS1204において、RTP−R変換部204は、受信したRCTPパケットが送信端末400から送信されたものか否かを判断する。
RTP−R変換部204は、受信したRCTPパケットが送信端末400から送信されたものである場合(ステップS1204:YES)、ステップS1205へ進む。また、RTP−R変換部204は、受信したRCTPパケットが送信端末400から送信されたものではない場合(S1204:NO)、ステップS1206へ進む。
ステップS1205において、RTP−R変換部204は、RCTPパケットから通常往復時間RTTsを算出(計測)する。そして、RTP−R変換部204は、算出した通常往復時間RTTsを、他の処理から参照可能なメモリ領域に、パラメータRsに用いられる値として格納して、図8の処理へ戻る。パラメータRsは、送信端末400へ通知する通常往復時間RRTsを決定するためのパラメータであり、計測された複数の通常往復時間RRTsの荷重移動平均値である。
ステップS1206において、RTP−R変換部204は、受信したパケットを破棄して、図8の処理へ戻る。
すなわち、RTP−R変換部204は、送信端末400から送信されたRCTPパケットを受信する毎に、通常往復時間RTTsを計測し、計測値を、パラメータRsに格納する。
一方、ステップS1203において、RTP−R変換部204は、受信した帯域推定タイミングの到来が近接CCNノードからのRTPパケットの受信により発生した事象であるか否かを判断する。
RTP−R変換部204は、帯域推定タイミングの到来が近接CCNノードからのRTPパケットの受信により発生した事象である場合(S1203:YES)、ステップS1207へ進む。また、RTP−R変換部204は、帯域推定タイミングの到来が近接CCNノードからのRTPパケットの受信により発生した事象ではない場合(S1203:NO)、ステップS1208へ進む。
この判断は、例えば、送信端末400のIPアドレスとパケットの送信元IPアドレスとが一致するか否かによって判断することができる。すなわち、RTP−R変換部204は、パケットの送信元IPアドレスが信端末400のIPアドレスと一致しない場合、受信したパケットが近接CCNノードから送信されたデータパケットであると判断することができる。なお、データの内容の信頼性は、非特許文献1で開示されているパケット毎の認証や暗号化を用いて検査してもよい。
ステップS1207において、RTP−R変換部204は、RTPパケットから近接往復時間RTTnを算出(計測)する。そして、RTP−R変換部204は、算出した近接往復時間RTTnを、他の処理から参照可能なメモリ領域に、パラメータRnに用いられる値として格納する。パラメータRnは、インタレストパケットの送信頻度の決定に用いられる近接往復時間RTTnを決定するためのパラメータであり、計測された複数の近接往復時間RTTnの荷重移動平均値である。
そして、ステップS1208において、RTP−R変換部204は、近接損失イベント率Pnおよび通常損失イベント率Psを算出する。
より具体的には、RTP−R変換部204は、パケット通番を記録しておき、パケット通番の隔たり、および、タイムアウトの有無から、パケットロスの有無を判断する。そして、RTP−R変換部204は、非特許文献3に記載の手法により、近接損失イベント率Pnおよび通常損失イベント率Psを算出する。
損失イベント率とは、1往復時間RTT期間以内に発生した複数の損失を、一つの損失イベント率として計算する率である。近接損失イベント率Pnおよび通常損失イベント率Psは、それぞれ、パラメータRn、Rsを往復時間とみなして、算出を行う。
RTP−R変換部204は、近接往復時間RTTn(パラメータRn)を用いて、近接損失イベント率Pnを算出する。また、RTP−R変換部204は、通常往復時間RTTs(パラメータRs)を用いて、通常損失イベント率Psを算出する。そして、RTP−R変換部204は、これらの算出結果を、他の処理から参照可能なメモリ領域に記録する。
そして、ステップS1209において、利用可能帯域推定部205は、近接往復時間RTTnおよび近接損失イベント率Pnを式(1)に代入して、近接帯域推定値Xcalnを算出する。
そして、ステップS1210において、RTCP−R制御部206は、インタレストパケットの発行のために、算出された近接帯域推定値Xcalnを、CCN受信スタック201に通知する。この通知は、上位層の帯域推定および流量制御の仕組みにより算出された値を、下位層に通知する役割を果たしている。このようにして通知された近接帯域推定値Xcalnに従ってインタレストパケットを送信した場合は、受信端末200と近接CCNノードとの間のTCP公平性が、上位層によって保証されることになる。
そして、ステップS1211において、利用可能帯域推定部205は、通常往復時間RTTsおよび通常損失イベント率Psを式(1)に代入して、通常帯域推定値Xcalsを算出する。
そして、ステップS1212において、RTCP−R制御部206は、算出された通常帯域推定値Xcalsを、RTCPパケットの送信によって、送信端末400に通知して、図8の処理へ戻る。
より具体的には、RTCP−R制御部206は、通常帯域推定値Xcalsを、通信システム300で予め定義された所定の形式のRTCPパケット(以下「帯域推定用RTCPパケット」という)に乗せて、送信端末400に送信する。この際、RTCP−R制御部206は、帯域推定用RTCPパケットにより、受信したパケットの通番と現在再生中の映像データのタイムスタンプを、併せて送信する。
この帯域推定用RTCPパケットは、実験的実装において、RTCPのAPP形式を使って独自に拡張された形式のパケットであってもよいし、特定の形式のレポートとして別途定義される形式のパケットであってもよい。
ここで、通番やタイムスタンプを併せて送信端末400に送信する理由は、受信端末200が追い付き再生を行っているか否かを、送信端末400に知らせるためである。その理由は、RTCPパケットが、過去に送信された映像データをCCNルータ510から取得して再生している受信端末200からのフィードバックであるのか、実時間再生を行っている受信端末200からのフィードバックであるのか、を区別するためである。
<インタレストパケット発行処理>
図10は、インタレストパケット発行処理(図8のステップS1400)の一例を示すフローチャートである。
図10は、インタレストパケット発行処理(図8のステップS1400)の一例を示すフローチャートである。
まず、ステップS1401において、CCN受信スタック201は、本処理の初期化が完了しているか否かを判断する。
CCN受信スタック201は、本処理の初期化が完了していない場合(S1401:NO)、ステップS1402へ進む。また、CCN受信スタック201は、本処理の初期化が完了している場合(S1401:YES)、ステップS1403へ進む。
ステップS1402において、CCN受信スタック201は、パラメータTokenに、値0を代入し、パラメータTICKに、次回本処理が動作するまでの時間を定義する定数を代入する。パラメータTICKには、例えば、1ms毎に動作すること(Hz=1000)を示す値が代入される。
そして、ステップS1403において、CCN受信スタック201は、パラメータTokenに、パラメータTICKと近接帯域推定値Xcalnとの積を足し上げる。
そして、ステップS1404において、CCN受信スタック201は、パラメータTokenが、パケットサイズS[byte]をビット換算したパケットサイズ換算値S*8[bit]以上であるか否かを判断する。
CN受信スタック201は、パラメータTokenが、パケットサイズ換算値S*8[bit]以上である場合(S1404:YES)、ステップS1405へ進む。また、CN受信スタック201は、パラメータTokenが、パケットサイズ換算値S*8[bit]未満である場合(S1404:NO)、ステップS1406へ進む。
ステップS1405において、CCN受信スタック201は、インタレストパケットを発行し、パラメータTokenからパケットサイズ換算値S*8[bit]を差し引き、ステップS1404へ戻る。このパラメータTokenから差し引く値は、インタレストパケットを発行した分に見合う値である。
すなわち、CCN受信スタック201は、パラメータTokenがパケットサイズを超えている間は、パラメータTokenがパケットサイズ未満になるまで、インタレストパケットの発行を行う。
ここで、CCN受信スタック201によるトークンバケツ処理は、一般のトークンバケツ処理と異なる。この異なる点は、パケットサイズ(S)が、受信端末200が発行するインタレストパケットのサイズではなく、受信端末200が受信するデータパケットのサイズである点である。
一般のトークンバケツ処理は、受信端末200が発行するインタレストパケットの流量を制御するために用いられる。これに対し、CCN受信スタック201によるトークンバケツ処理は、近接CCNノードから受信端末200までの間の利用可能帯域を利用する(埋める)ために必要十分な量のデータパケットを、連続的に取得する制御のために、用いられる。つまり、CCN受信スタック201によるトークンバケツ処理は、必要十分な量のデータパケットが、連続的に取得されるように、インタレストパケットの発行を行う。
すなわち、CCN受信スタック201が行うトークンバケツ処理は、一般的に制御の対象となる流量の方向とは逆方向の流量を、制御するようになっている。
なお、パケットサイズS[byte]は、通信の開始時に、送信側通話制御アプリ403と受信側通話制御アプリ203との間で交換される呼制御情報により決定されるメディア種別に基づいて、静的に決定されてもよい。
例えば、CCN受信スタック201は、1500バイトのパケット長で通信するビデオデータの場合、S=1500とする。
あるいは、例えば、CCN受信スタック201は、受信するパケットのパケット長を統計的に算出し、算出結果を、パケットサイズS[byte]として採用する。具体的には、例えば、CCN受信スタック201は、過去n個(nは正の整数)のデータパケットのパケット長に対して、指数加重平均を適用して得られる値を用いる。
あるいは、例えば、CCN受信スタック201は、受信したデータパケットのパケット長を、配列、リスト、あるいはキューなど形式で記憶領域に順次記録する。そして、CCN受信スタック201は、ステップS1404、S1405の処理が行われる毎に、記憶領域の先頭(過去)から、記録された値を、順次採用する。
そして、ステップS1406において、CCN受信スタック201は、本処理が次のTICK時間経過後に起動するようにタイマーにフックし、図8の処理へ戻る。
<送信端末の動作説明>
図11は、送信端末の動作の一例を示すフローチャートである。
図11は、送信端末の動作の一例を示すフローチャートである。
まず、ステップS2001において、RTCP−S制御部406は、RTCPパケットを受信したか否かを判断する。
RTCP−S制御部406は、RTCPパケットを受信した場合(S2001:YES)、ステップS2002へ進む。また、RTCP−S制御部406は、RTCPパケットを受信していない場合(S2001:NO)、後述のステップS2013へ進む。
ステップS2002において、RTCP−S制御部406は、初回のRTCPパケット受信処理であるか否かを判断する。
RTCP−S制御部406は、RTCP−S制御部406は、初回のRTCPパケット受信処理である場合(S2002:YES)、ステップS2003へ進む。また、RTCP−S制御部406は、初回のRTCPパケット受信処理ではない場合(S2002:NO)、ステップS2004へ進む。
ステップS2003において、RTCP−S制御部406は、過去に作成された受信端末200のリストをクリアする。受信端末200のリストは、複数の端末に対する送信を行っている場合に利用するリストであり、受信端末200の情報を格納する構造体のリストである。本ステップにおいて、RTCP−S制御部406は、かかるリストの内容を増加させることができる状態に初期化する。また、RTCP−S制御部406は、記憶領域に記憶する次回推定値通知時刻を、初回の処理を行った時刻である現在時刻にTICK時間を付加した時刻に、初期化する。
そして、ステップS2004において、RTCP−S制御部406は、受信したRTCPパケットがRFC3550に準拠したパケットであるかどうかを判断する。
RTCP−S制御部406は、受信したRTCPパケットがRFC3550に準拠したパケットである場合(S2004:YES)、ステップS2005へ進む。また、RTCP−S制御部406は、受信したRTCPパケットがRFC3550に準拠したパケットではない場合(S2004:NO)、ステップS2006へ進む。
ステップS2005において、RTCP−S制御部406は、受信したRTCPパケットを、RFC3550に準拠する形で処理する。かかる処理は、典型的な受信者レポートの処理などである。
そして、ステップS2006において、RTCP−S制御部406は、受信したRTCPパケットが、上述の通帯域推定用RTCPパケットであるか否かを判断する。
RTCP−S制御部406は、受信したRTCPパケットが、帯域推定用RTCPパケットである場合(S2006:YES)、ステップS2007へ進む。また、RTCP−S制御部406は、受信したRTCPパケットが、帯域推定用RTCPパケットではない場合(S2006:NO)、後述のステップS2013へ進む。
ステップS2007において、RTCP−S制御部406は、受信した帯域推定用RTCPパケットの送信元が、初めての送信元であるか否か判断する。初めての送信元とは、これまでに帯域推定用RTCPパケットを送信端末400に送信したことがないCCNノードである。
RTCP−S制御部406は、受信した帯域推定用RTCPパケットの送信元が初めての送信元である場合(S2007:YES)、ステップS2008へ進む。また、RTCP−S制御部406は、受信した帯域推定用RTCPパケットの送信元が、初めての送信元ではない場合(S2007:NO)、ステップS2009へ進む。
ステップS2008において、RTCP−S制御部406は、受信端末200のリストに、受信した帯域推定用RTCPパケットの送信元のIPアドレスを追加する。
そして、ステップS2009において、RTCP−S制御部406は、受信した帯域推定用RTCPパケットから、帯域推定用RTCPパケットに格納された通常帯域推定値Xcalsを抽出する。また、RTCP−S制御部406は、受信した帯域推定用RTCPパケットの送信元のIPアドレスを、受信端末200のリストで探索する。そして、RTCP−S制御部406は、リストの要素のうち該当するものに、抽出した通常帯域推定値Xcalsを記録する。
なお、RTCP−S制御部406は、帯域推定用RTCPパケットに含まれるタイムスタンプおよび通番や、帯域推定用RTCPパケットから算出される通常往復時間RTTsを、併せて受信端末200のリストに記録してもよい。
そして、ステップS2010において、RTCP−S制御部406は、送信端末400の現在時刻を取得し、現在時刻が、記憶領域に記憶している次回推定値通知時刻を超過(経過)しているか否かを判断する。
RTCP−S制御部406は、RTCP−S制御部406は、現在時刻が次回推定値通知時刻を超過していない場合(S2010:NO)、ステップS2010の判断処理を繰り返す。そして、RTCP−S制御部406は、現在時刻が次回推定値通知時刻を超過すると(S2010:YES)、ステップS2011へ進む。
ステップS2011において、送信帯域推定部407は、受信端末200のリストにおいて、記録されている通常帯域推定値Xcalsのうち最低値を検索する。送信帯域推定部407は、検索された最低値を、上位層の流量制御に採用する通常帯域推定値Xcalsに決定する。そして、送信帯域推定部407は、決定した通常帯域推定値Xcalsを、次回のエンコードで採用する目標ビットレートを決定するための情報として、映像エンコーダ404に通知する。
なお、通常帯域推定値Xcalsの最低値を検索する際、送信帯域推定部407は、タイムスタンプ、通番、および通常往復時間RTTsなどの情報を利用して、通常帯域推定値Xcalsを読み飛ばしてもよい。すなわち、送信帯域推定部407は、追い付き再生を行っている受信端末200からの通常帯域推定値Xcalsを無視してもよい。あるいは、送信帯域推定部407は、通常往復時間RTTs以内にインタレストパケットを発行してきていない受信端末200からの通常帯域推定値Xcalsを、無視してもよい。
また、映像エンコーダ404は、通知された通常帯域推定値Xcalsから、パケットヘッダオーバヘッド見合い分、データパケット損失時の再送パケット見合い分、およびFECなどの冗長符号分のビットレートのうち、一部または全部を、減算してもよい。そして、映像エンコーダ404は、かかる減算が行われた後の値から、目標ビットレートを決定してもよい。
そして、ステップS2012において、RTCP−S制御部406は、次回推定値通知時刻を決定し、記憶する。
そして、ステップS2013において、RTP−S変換部405は、ユーザ操作等により処理の終了を指示されたか否かを判断する。
RTP−S変換部405は、処理の終了を指示されていない場合(S2013:NO)、ステップS2001へ戻る。また、RTP−S変換部405は、処理の終了を指示された場合(S2013:YES)、一連の処理を終了する。
<CCNルータの動作説明>
図12は、CCNルータ510の動作の一例を示すフローチャートである。
図12は、CCNルータ510の動作の一例を示すフローチャートである。
まず、ステップS3001において、CCN転送スタック512は、送信端末400から送信されたデータパケットを受信したか否かを判断する。CCN転送スタック512は、データパケットを受信した場合(S3001:YES)、ステップS3002へ進む。また、CCN転送スタック512は、データパケットを受信していない場合(S3001:NO)、ステップS3003へ進む。
ステップS3002において、CCN転送スタック512は、受信したデータパケットを、その送信先である受信端末200に向けて転送する。また、CCN転送スタック512は、受信したデータパケットを、複製して、キャッシュ部511にキャッシュする。
そして、ステップS3003において、CCN転送スタック512は、受信端末200から送信されたインタレストパケットを受信したか否かを判断する。CCN転送スタック512は、インタレストパケットを受信した場合(S3003:YES)、ステップS3004へ進む。また、CCN転送スタック512は、インタレストパケットを受信していない場合(S3003:NO)、後述のステップS3007へ進む。
ステップS3004において、CCN転送スタック512は、受信したインタレストパケットが送信を要求するデータパケットが、キャッシュ部511にキャッシュされているか否かを判断する。CCN転送スタック512は、該当するデータパケットがキャッシュされていない場合(S3004:NO)、ステップS3005へ進む。また、CCN転送スタック512は、該当するデータパケットがキャッシュされている場合(S3004:YES)、ステップS3006へ進む。
ステップS3005において、CCN転送スタック512は、予め保持する名前空間の経路表(FIB: Forwarding Information Base)に従って、受信したインタレストパケットを、他のCCNノードへ転送する。例えば、このインタレストパケットは、最終的に、送信端末400まで到達する。
ステップS3006において、CCN転送スタック512は、受信したインタレストパケットが要求するデータパケットを、キャッシュ部511から取得し、インタレストパケットの送信元へ返信する。
そして、ステップS3007において、CCN転送スタック512は、ユーザ操作等により処理の終了を指示されたか否かを判断する。CCN転送スタック512は、処理の終了を指示されていない場合(S3007:NO)、ステップS3001へ戻る。また、CCN転送スタック512は、処理の終了を指示された場合(S3007:YES)、一連の処理を終了する。
なお、CCN転送スタック512は、通常のルータと同じ機能をも備えている。すなわち、CCN転送スタック512は、ユニキャストパケットの転送においては、転送先IPアドレスを用いて、IP転送用の経路表(FIB)を探索し、適切なインターフェイスに転送する。例えば、受信端末200から送信端末400に向けて送信されたRTCPパケットは、このIP転送用の経路表に基づいて、送信端末400に向けて転送される。
<追い付き再生の説明>
次に、追い付き再生の詳細について説明する。
次に、追い付き再生の詳細について説明する。
上述の受信側通話制御アプリ203は、利用可能帯域推定部205から通知された近接帯域推定値Xcalnと、映像デコーダ207から通知された映像データのデータ量とに基づいて、映像データの取得再生手法を決定する。ここで、映像データの取得再生手法には、再生時刻を早めて再生することや、映像データを構成するピクチャの一部を間引いて(スキップして)の取得することが含まれる。
受信端末200が上述の「他の受信端末」である場合、取得の目的となるデータパケットは、既に近接CCNノードにキャッシュされている。
このため、受信端末200は、近接CCNノードから受信端末200への利用可能帯域が大きい場合、データパケットを、送信端末400が送信したレートよりも高いレートで受信することが可能である。例えば、受信側通話制御アプリ203は、近接帯域推定値Xcalnが、映像データのデータ量を倍にしたときに必要な帯域以上である場合、インタレストパケットを通常の倍の頻度で発行するように、CCN受信スタック201に指示する。
これにより、例えば、映像データが会議の中継データである場合、会議の途中から、それまでの会議の内容を倍速で再生し、会議に途中から参加することが可能となる。
また、受信端末200は、近接CCNノードから受信端末200への利用可能帯域が小さい場合、データパケットを、送信端末400が送信したレートよりも低いレートでなければ受信することができない。したがって、受信側通話制御アプリ203は、例えば、近接帯域推定値Xcalnが、映像データのデータ量に必要な帯域未満である場合、映像データを、静止画のコマ送りとなるようにスキップして取得するようにする。より具体的には、受信側通話制御アプリ203は、インタレストパケットをスキップして発行するように、CCN受信スタック201に指示する。
これにより、再生される映像データの品質は低下するものの、TCP公平性を保ちつつ、映像データを取得して再生することが可能となる。
ここで、図3を参照しながら、追い付き再生が行われる場合のシステム300の動作の概要について説明する。
以下の説明においては、まず、映像データが、第1の受信端末2001によって送信端末400から初めて取得され、その直後に、第2の受信端末2002によって取得される場合を、例として用いる。
まず、送信端末400と第1の受信端末2001とが、非特許文献3に開示されているVoice Over CCNの呼制御と同様の手順により、呼を確立する。すなわち、第1の受信端末2001が発行した、通常のSIPによる呼制御のメッセージ(Session Description Protocolにより記述)が、CCNのインタレストパケットによって、送信端末400に運ばれる。
そして、映像データの分割データは、第1の受信端末2001が連続的に、RTPの通番を指定したインタレストパケットを発行することにより、送信端末400から第1の受信端末2001へと運ばれる。
言い換えると、映像データの分割データは、呼を特定するIDおよび通番と、タイムスタンプを含む名前空間とが定義される。そして、CCNネットワーク500は、その名前空間の出版元は送信端末400であるとして、運用される。その上で、第1の受信端末2001から、連続的に分割データに対するインタレストパケットが発行される。これにより、分割データを格納したパケットは、送信端末400から第1の受信端末2001へと転送される。
このようにして、送信端末400から第1の受信端末2001への映像データの伝送は、実現される。
この場合、第1の受信端末2001にとって、近接CCNノードは、CCNネットワーク500の中のCCNルータ510(例えば共通のCCNノード)ではなく、送信端末400となる。これは、CCNネットワーク500の中のCCNルータ510および非CCNルータ520のいずれも、分割データをまだキャッシュしていないためである。
この結果、インタレストパケットは、送信端末400まで転送されて到達し、分割データを格納したデータパケットは、送信端末400から返送される。
このように、送信端末400が近接CCNノードである場合、近接往復時間RTTnは、通常往復時間RTTsと一致する。また、近接損失イベント率Pnは、通常損失イベント率Psと、一致する。
すなわち、送信端末400が近接CCNノードである場合、受信端末200が発行するインタレストパケットの単位時間あたりの数は、上位層のTFRCにより算出される推定帯域から算出できるデータパケットの単位時間あたりの受信数と一致する。
受信端末200は送信端末400に対して、通常帯域推定値Xcalsを通知する。送信端末400は、この通常帯域推定値Xcalsに見合う目標ビットレートに基づいてエンコードおよび伝送を行うので、TFRCに基づいたレート制御を行うことになる。すなわち、TCP公平性は、上位層のTFRCによって保証される。
そして、第2の受信端末2002が、映像データの追い付き再生を開始したとする。第2の受信端末2002は、送信端末400と第1の受信端末2001との間で行われている実時間ストリーミング伝送に追い付くために、本来の速度よりも高速に映像データを取得して再生する。すなわち、第2の受信端末2002は、早送りで映像データを再生するか、ピクチャをスキップする形で、映像データを再生する。
このような早送り再生動作は、受信側通話制御アプリ203が映像デコーダ207に指示することにより、可能となる。
<下位層における分割データの取得について>
ここで、下位層における分割データの取得がどのように行われるかについて説明する。
ここで、下位層における分割データの取得がどのように行われるかについて説明する。
第2の受信端末2002にとって、近接CCNノードは、第1のCCNルータ5101となる。なぜなら、送信端末400と第1の受信端末2001との間で、既に映像データの伝送は行われており、そのデータパケットは、第1のCCNルータ5101にキャッシュされているからである。
なお、非特許文献3には、キャッシュのライフタイムを端末間の往復時間RTTに限定する運用が開示されているが、本願では、キャッシュのライフタイムをセッション時間として使用する。すなわち、呼が開始してから終了するまでの間、データパケットは第1のCCNルータ5101に維持される。
このように、第2の受信端末2002は、第2の受信端末2002が参加した時刻までの間に送信端末400と第1の受信端末2001の間で伝送されてきた映像データを、第1のCCNルータ5101から取得することができる。
このとき、第2の受信端末2002において、近接往復時間RTTnは、通常往復時間RTTsよりも小さい値となる。
近接往復時間RTTnが通常往復時間RTTsよりも小さい値となる場合は、パケットロスの発生が、通常往復時間RTTsと比較して長い時間間隔で発生していることが想定される。これは、例えば、帯域推定が正常に動作している場合に多く観測される。この場合は、近接帯域推定値Xcalnと通常帯域推定値Xcalsとを比較すると、近接帯域推定値Xcalnの方が大きくなる。これは、式(1)の分母に往復時間RTTの項があることから、明らかである。
すなわち、第2の受信端末2002は、送信端末400が映像データの送信に利用した帯域よりも大きい帯域を利用して、映像データを取得することが可能となる。なお、この場合においても、第2の受信端末で2002では、TFRCに基づいて近接CCNノード510の送信量を調整するため、インタレスパケットの発行量の調整が行われている。このため、TCP公平性は満たされる。
このようにして、第2の受信端末2002は、最初からの映像データを第1のCCNルータ5101から取得することができ、映像データの追い付き再生を行うことができる。
このとき、送信端末400は、第1の受信端末2001および第2の受信端末2002の両方から、通常帯域推定値Xcalsのフィードバックを、RTCPパケットにより受けている。送信端末400は、この両者の通常帯域推定値Xcalsのうち、値が小さい方を採用して映像エンコーダを制御してもよいし、後発の第2の受信端末2002からの通常帯域推定値Xcalsを無視してもよい。
送信端末400は、受信端末200からRTCPパケットに付加して返送される上述の付加情報を、受信端末200間で比較して、どの通常帯域推定値Xcalsを無視するかを決定すればよい。
例えば、送信端末400は、再生中のデータの通番が示す時刻と、現在エンコード中のデータの通番が示す時刻との差を、送信端末400とRTCPパケットの送信元との間の往復時間RTTと比較する。そして、送信端末400は、時刻の差が往復時間RTTよりも大きい場合、第2の受信端末2002の通常帯域推定値Xcalsを無視する。
一方、送信端末400は、時刻の差が往復時間RTT以下である場合、第2の受信端末2002の再生タイミングが本来の再生タイミング(伝送タイミング)に追い付いたと判断する。そして、送信端末400は、第2の受信端末2002の通常帯域推定値Xcalsを、上述の最小値判定の対象に入れる。
なお、第2の受信端末2002の再生タイミングが本来の再生タイミングに追い付いた時点で、第2の受信端末2002にとっての近接CCNノードは、送信端末400となる。
第2の受信端末2002は、例えば、近接往復時間RTTnと通常往復時間RTTsとが一致したか否かを判断することにより、送信端末400が近接CCNノードとなったことを検知することができる。したがって、第2の受信端末2002は、送信端末400が近接CCNノードとなったとき、その旨を送信端末400に通知してもよい。そして、送信端末400は、この通知をトリガにして、第2の受信端末2002からのフィードバックに含まれる通常帯域推定値Xcalsを最低値の探索対象に含めるようにしてもよい。
なお、第2の受信端末2002と第1のCCNルータ5101との間が輻輳している場合には、近接帯域推定値Xcalnが大きくならず、再生速度を上げることができない。このような場合、第2の受信端末2002は、上述の通り、映像データをスキップして取得することができる。
また、第2の受信端末2002は、映像データと音声データとの2ストリームを取得しているような場合は、音声データは間引かずに全て取得し、映像データのみを間引いて取得するように指示してもよい。これにより、第2の受信端末2002は、第2の受信端末2002と第1のCCNルータ5101との間のネットワーク回線におけるTCP公平性を満たしながら、必要なデータを取得することができる。
<変形例1の説明>
次に、受信端末200が、映像データの追い付き再生を行っている最中に、近接CCNノードが変化する場合においても、近接往復時間RTTnを計測することができることについて説明する。
次に、受信端末200が、映像データの追い付き再生を行っている最中に、近接CCNノードが変化する場合においても、近接往復時間RTTnを計測することができることについて説明する。
図13は、通信システムの他の構成の第1の例を示すシステム構成図であり、図3に対応するものである。図3と同一部分には同一符号を付し、これについての説明を省略する。
図13において、第2の受信端末2002は、例えば、2つのネットワーク接続インターフェイス(CCNの用語ではフェイス:faces)を備えているものとする。そして、図13に示すように、第2の受信端末2002は、第1のCCNルータ5101だけでなく、第2のCCNルータ5102にも接続されている。
第2の受信端末2002のフェイスは、例えば、無線LANのインターフェイス、あるいは、LTE/WIMAXなどの公衆無線のインターフェイスとすることができる。したがって、例えば、第1のCCNルータ5101は、無線LANの基地局のルータであり、第2のCCNルータ5102は、WIMAXの網内のルータである。
ここで、第2の受信端末2002が取得の目的とする実時間ストリームのデータパケットが、既に、第1のCCNルータ5101および第2のCCNルータ5102の両方にキャッシュされていたとする。但し、第2の受信端末2002と第1のCCNルータ5101との間の往復時間RTTの方が、第2の受信端末2002と第2のCCNルータ5102との間の往復時間RTTよりも短いものとする。
図14は、図13の例、つまり、2つの近接CCNノードがコンテンツを保持している場合の、近接往復時間RTTnの計測の様子を示す模式図である。
非特許文献1に記載されているように、CCNにおいて、インタレストパケットを発行するCCNノードは、全てフェイスから、インタレストパケットを同時に発行する。したがって、第2の受信端末2002は、インタレストパケットをそれぞれのフェイスに発行する。その際、第2の受信端末2002は、インタレストパケットを特定する情報(例えば、名前、もしくは通番など名前の一部)と、インタレストパケット送信時刻とを記録する(S4001)。それぞれのフェイスから発行されたインタレストパケットは、第1のCCNルータ5101および第2のCCNルータ5102の両方に送信される(S4002、S4003)。
この例では、第1のCCNルータ5101および第2のCCNルータ5102の両方がデータパケットをキャッシュしている。したがって、第1のCCNルータ5101および第2のCCNルータ5102は、それぞれ、データパケットをそれぞれ第2の受信端末2002に返信する(S4004、S4005)。
ところが、この例では、第1のCCNルータ5101から返信されたデータパケットの方が、第2のCCNルータ5102から返信されたデータパケットよりも先に、第2の受信端末2002に到達する(S4006、S4007)。第2の受信端末2002は、インタレストパケットの送信時刻と、先に受信した第1のCCNルータ5101からのデータパケットの受信時刻との差から、近接往復時間RTTnを算出する(S4008)。第2の受信端末2002は、算出した近接往復時間RTTnを、データパケットに付随する形で内部メモリにて管理してもよいし、インタレストパケットを発行する名前空間に関連付ける形で内部メモリにて管理してもよい。
そして、第2の受信端末2002は、重複して到着したデータパケットのうち、後から到着した第2のCCNルータ5102からのデータパケットを、破棄する(S4009)。
このように動作することにより、各受信端末200は、複数のCCNルータ510と接続している場合でも、受信端末200と近接CCNノートとの間の往復時間RTTである近接往復時間RTTnを計測することができる。
このように、受信端末200は、映像データの追い付き再生を行っている最中に、近接CCNノードが変化する場合においても、近接往復時間RTTnを計測することができる。
例えば、追い付き再生を行っている場合、インタレストパケットの単位時間当たりの発行数は、送信端末400による単位時間当たりのデータパケット発行数よりも多い。過去のデータパケットに対するインタレストパケットが発行されている間は、かかるデータパケットはCCNルータ510にキャッシュされている。このため、近接CCNノードは、当該CCNルータ510となり、近接往復時間RTTnは小さくなる。
一方、再生が実時間伝送に追い付いた場合、CCNルータ510には、データパケットがキャッシュされていない。このため、近接CCNノードは、送信端末400となる。そして、インタレストパケットは、送信端末400まで転送され、近接往復時間RTTnは大きくなる(通常帯域推定値Xcalsに一致する)。また、近接CCNノードが変更されたことは、データパケットの送信元IPアドレスを観測することにより、容易に検知することができる。
<変形例2の説明>
次に、通信システム300が、輻輳に対してもTCP公平性が満たされるように流量制御を行うことについて説明する。
次に、通信システム300が、輻輳に対してもTCP公平性が満たされるように流量制御を行うことについて説明する。
図15は、通信システムの他の構成の第2の例を示すシステム構成図であり、図3に対応するものである。図3と同一部分には同一符号を付し、これについての説明を省略する。
図15に示すように、第1のCCNルータ5101には、第1〜第3の受信端末2001〜2003が接続していたとする。また、第3のCCNルータ5103には、第1および第2の送信端末4001、4002が接続していたとする。
第3のCCNルータ5103と第1のCCNルータ5101とは、第1のネットワーク回線5301および第2のネットワーク回線5302を介して接続されている。第1の受信端末2001は、第3のネットワーク回線5303を介して第1のCCNルータ5101に接続されている。第2の受信端末2002は、第4のネットワーク回線5304を介して第1のCCNルータ5101に接続されている。第3の受信端末2003は、第5のネットワーク回線5305を介して第1のCCNルータ5101に接続されている。第1〜第5のネットワーク回線5301〜5305のそれぞれの帯域は、2Mbpsと仮定する。
第1の送信端末4001は、第1の送信端末4001と第1の受信端末2001および第2の受信端末2002との間で、呼の通信を行っているものとする。この通信は、「第1の通信」いう。第1の通信が行われている状態で、第2の送信端末4002は、第2の送信端末4002と第3の受信端末2003との間で、新たな呼の通信を開始したとする。この通信は、「第2の通信」という。
第1の通信および第2の通信は、第1および第2のネットワーク回線5301、5302を共有している。第1の通信のみが行われており、第2の通信が開始されていない間、第1の送信端末4001は、回線帯域の2Mbpsをほぼ完全に利用して通信を行っている。
ところが、第2の通信の通信が開始されると、第1の通信、第2の通信の双方では、一時的にパケットロスが観測される。このとき、第1の通信を行っている第1および第2の受信端末2001、2002では、通常損失イベント率Psの上昇を観測し、通常帯域推定値Xcalsを小さい値で算出する。この値は、第1の送信端末4001にフィードバックされ、第1の通信のエンコードレート(伝送レート)を低下させる。
また、第2の通信を行っている第3の受信端末2003は、同様に、通常帯域推定値Xcalsを、小さい値で算出する。この値は、第2の送信端末4002にフィードバックされ、第2の通信のエンコードレート(伝送レート)を低下させる。
すなわち、第1の通信および第2の通信は、適切に、第1および第2のネットワーク回線5301、5302を分け合うことができる。なお、上記説明では、TFRCで制御されたストリームが2本競合するケースを見てきたが、TCPで制御された通信を含む複数の通信の間で競合が発生している場合でも同様である。
このように、通信システム300は、TFRCが有する帯域を分け合う機能を有し、輻輳に対してもTCP公平性が満たされるように流量制御を行うことができる。
以上のように、本実施の形態に係る通信システム300は、受信端末200と近接CCNノードとの間の利用可能帯域を推定し、推定された帯域を利用して近接CCNノードからのデータ転送が行われるように流量制御を行う。また、本実施の形態に係る通信システム300は、利用可能帯域を推定し、推定された帯域を利用して送信端末400からのデータ送信が行われるように流量制御を行う。すなわち、本実施の形態に係る通信システム300は、TCP公平性を実現する上位層のTFRCベースの帯域推定を阻害しないように、CCNのインタレストパケットの単位時間当たりの発行数を調整する。
これにより、本実施の形態に係る通信システム300は、上位層の帯域推定(TFRC)が下位層の流量制御(CCN)に影響されることなく、TFRCによりTCP公平性を保持した状態で、実時間ストリーム伝送を継続することができる。すなわち、本実施の形態に係る通信システム300は、インターネットのようなベストエフォート型ネットワークにCCNを適用し、映像、音声等の実時間ストリームを、パケット落ちが発生しないように適応的に流量を制御することができる。
そして、本実施の形態に係る通信システム300は、他の受信端末200がCCNルータ510上のキャッシュから実時間ストリームを取得する際、他の受信端末200とCCNルータ510との間のネットワークの混雑度合いに応じた流量制御を行うことができる。すなわち、本実施の形態に係る通信システム300は、他の受信端末が映像音声の実時間ストリームの伝送の途中あるいは終了後に、伝送のセッションに参加するようなユースケースにおいても、適切に流量制御を行うことができる。
なお、以上説明した各実施の形態では、受信端末が取得の目的とする実時間ストリームが映像データである場合を例としたが、当該実時間ストリームは、これに制限されない。例えば、テレビ会議において双方向に送受信される音声データにも、本発明を適用することができる。
また、上位層における帯域推定にTFRCを用いた場合を例としたが、上位層の帯域推定の手法は、これに制限されない。例えば、TFRCから派生した他の帯域推定手法や、BCC(Binomial Congestion Control)など、他の帯域推定手法にも、本発明を適用することができる。
本開示の通信システムは、実時間ストリームのパケットを送信する送信端末と、前記パケットを転送する転送端末と、前記パケットを受信する受信端末と、を有する通信システムであって、前記転送端末は、前記送信端末から送信された前記パケットをキャッシュするキャッシュ部と、前記受信端末からの要求に応じて、前記キャッシュ部にキャッシュされた前記パケットを前記受信端末へ転送する転送スタックと、を有し、前記受信端末は、前記受信端末と前記転送端末との間の利用可能帯域である第1の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第2の利用可能帯域と、を推定する利用可能帯域推定部と、前記転送端末が推定された前記第1の利用可能帯域を利用して前記パケットの転送を行うように、前記転送端末に対して前記パケットの転送の要求を行い、推定された前記第2の利用可能帯域を前記送信端末に対して通知するRTCP−R制御部と、を有し、前記送信端末は、前記受信端末から通知された前記第2の利用可能帯域を利用して、前記パケットの送信を行う送信スタックと、を有する、
また、上記通信システムにおいて、前記送信端末、前記転送端末、および前記受信端末は、それぞれCCN対応の端末であり、前記要求は、前記実時間ストリームの名称を指定して前記実時間ストリームの返信を要求するパケットであるインタレストパケットの送信により行われてもよい。
本開示の受信端末は、実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける前記受信端末であって、前記受信端末と前記転送端末との間の利用可能帯域である第1の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第2の利用可能帯域と、を推定する利用可能帯域推定部と、推定された前記第1の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第1の利用可能帯域を利用して前記パケットを転送させ、推定された前記第2の利用可能帯域を前記送信端末に対して通知することにより、前記送信端末に対して、前記第2の利用可能帯域を利用して前記パケットを送信させる、RTCP−R制御部と、を有する。
また、上記受信端末において、前記送信端末、前記転送端末、および前記受信端末は、それぞれCCN対応の端末であり、前記要求は、前記実時間ストリームの名称を指定して前記実時間ストリームの返信を要求するパケットであるインタレストパケットの送信により行われてもよい。
また、上記受信端末は、前記受信端末と前記転送端末との間で前記パケットの受信を含む通信を行う受信スタックと、前記受信スタックにより行われた前記受信端末と前記転送端末との間の通信から、前記受信端末と前記転送端末との間の損失イベント率である第1の損失イベント率と、前記受信端末と前記転送端末との間のRTTである第1のRTTと、を算出するRTT−R変換部と、を更に有し、前記利用可能帯域推定部は、前記受信スタックが受信した前記パケットから、前記受信端末と前記送信端末との間の損失イベント率である第2の損失イベント率と、前記受信端末と前記送信端末との間のRTTである第2のRTTと、を算出し、算出された前記第1の損失イベント率および算出された前記第1のRTTから、前記第1の利用可能帯域を推定し、算出された前記第2の損失イベント率および算出された前記第2のRTTから、前記第2の利用可能帯域を推定し、前記RTCP−R制御部は、前記受信スタックに対して、前記インタレストパケットを、推定された前記第1の利用可能帯域に基づく前記頻度で、前記転送端末に対して送信することを指示してもよい。
また、上記受信端末において、前記RTT−R変換部は、前記受信スタックが受信した前記パケットから、前記実時間ストリームのデータを抽出し、抽出された前記データから前記実時間ストリームを再生する実時間ストリーム再生部(映像デコーダ)、を更に有し、前記RTCP−R制御部は、前記第2の利用可能帯域が、前記送信端末が前記パケットの送信に利用している帯域である第2の実利用帯域よりも大きいか否かを判定し、前記第1の利用可能帯域が前記第2の実利用帯域よりも大きいことを条件として、前記実時間ストリーム再生部に対して、前記実時間ストリームを、本来の再生速度よりも速い速度で再生することを許可してもよい。
また、上記受信端末は、前記受信スタックが受信した前記パケットから、前記実時間ストリームを再生する実時間ストリーム再生部(映像デコーダ)、を更に有し、前記RTCP−R制御部は、前記第2の利用可能帯域が、前記送信端末が前記パケットの送信に利用している帯域である第2の実利用帯域よりも小さいか否かを判定し、前記第1の利用可能帯域が前記第2の実利用帯域よりも大きいことを条件として、前記受信スタックに対して、前記実時間ストリームを構成する一連の前記パケットを間引いて要求するように指示してもよい。
本発明の一態様にかかる送信端末は、実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける前記送信端末であって、前記実時間ストリームのデータを格納した前記パケットを送信する送信スタックと、前記受信端末と前記転送端末との間の利用可能帯域である第1の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第2の利用可能帯域と、を推定し、推定された前記第1の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第1の利用可能帯域を利用して前記パケットを転送させる前記受信端末から、前記第2の利用可能帯域の通知を受けるRTCP−S制御部と、前記送信スタックに対して、前記受信端末から通知された前記第2の利用可能帯域を利用して前記パケットの送信を行わせる送信帯域推定部と、を有する。
本開示の流量制御方法は、実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける流量制御方法であって、前記受信端末において、前記受信端末と前記転送端末との間の利用可能帯域である第1の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第2の利用可能帯域と、を推定するステップと、前記受信端末において、推定された前記第1の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第1の利用可能帯域を利用して前記パケットを転送させ、推定された前記第2の利用可能帯域を前記送信端末に対して通知することにより、前記送信端末に対して、前記第2の利用可能帯域を利用して前記パケットを送信させるステップと、を有する。
2012年10月24日出願の特願2012−234682の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
本発明は、CCNをベストエフォート型のネットワークに適用して実時間ストリームのパケットを伝送する場合において、伝送性能の低下を防ぐことができる、通信システム、受信端末、送信端末、および流量制御方法として有用である。
200 受信端末
201 CCN受信スタック
202 受信側呼制御変換部
203 受信側通話制御アプリ
204 RTP−R変換部
205 利用可能帯域推定部
206 RTCP−R制御部
207 映像デコーダ
300 通信システム
400 送信端末
401 CCN送信スタック
402 送信側呼制御変換部
403 送信側通話制御アプリ
404 映像エンコーダ
405 RTP−S変換部
406 RTCP−S制御部
407 送信帯域推定部
500 CCNネットワーク
510 CCNルータ
511 キャッシュ部
512 CCN転送スタック
520 非CCNルータ
530 ネットワーク回線
201 CCN受信スタック
202 受信側呼制御変換部
203 受信側通話制御アプリ
204 RTP−R変換部
205 利用可能帯域推定部
206 RTCP−R制御部
207 映像デコーダ
300 通信システム
400 送信端末
401 CCN送信スタック
402 送信側呼制御変換部
403 送信側通話制御アプリ
404 映像エンコーダ
405 RTP−S変換部
406 RTCP−S制御部
407 送信帯域推定部
500 CCNネットワーク
510 CCNルータ
511 キャッシュ部
512 CCN転送スタック
520 非CCNルータ
530 ネットワーク回線
Claims (9)
- 実時間ストリームのパケットを送信する送信端末と、前記パケットを転送する転送端末と、前記パケットを受信する受信端末と、を有する通信システムであって、
前記転送端末は、
前記送信端末から送信された前記パケットをキャッシュするキャッシュ部と、
前記受信端末からの要求に応じて、前記キャッシュ部にキャッシュされた前記パケットを前記受信端末へ転送する転送スタックと、を有し、
前記受信端末は、
前記受信端末と前記転送端末との間の利用可能帯域である第1の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第2の利用可能帯域と、を推定する利用可能帯域推定部と、
前記転送端末が推定された前記第1の利用可能帯域を利用して前記パケットの転送を行うように、前記転送端末に対して前記パケットの転送の要求を行い、推定された前記第2の利用可能帯域を前記送信端末に対して通知するRTCP−R制御部と、を有し、
前記送信端末は、
前記受信端末から通知された前記第2の利用可能帯域を利用して、前記パケットの送信を行う送信スタックと、を有する、
通信システム。 - 前記送信端末、前記転送端末、および前記受信端末は、それぞれCCN(コンテンツ中心型ネットワーク)対応の端末であり、
前記要求は、前記実時間ストリームの名称を指定して前記実時間ストリームの返信を要求するパケットであるインタレストパケットの送信により行われる、
請求項1に記載の通信システム。 - 実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける前記受信端末であって、
前記受信端末と前記転送端末との間の利用可能帯域である第1の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第2の利用可能帯域と、を推定する利用可能帯域推定部と、
推定された前記第1の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第1の利用可能帯域を利用して前記パケットを転送させ、推定された前記第2の利用可能帯域を前記送信端末に対して通知することにより、前記送信端末に対して、前記第2の利用可能帯域を利用して前記パケットを送信させる、RTCP−R制御部と、を有する、
受信端末。 - 前記送信端末、前記転送端末、および前記受信端末は、それぞれCCN(コンテンツ中心型ネットワーク)対応の端末であり、
前記要求は、前記実時間ストリームの名称を指定して前記実時間ストリームの返信を要求するパケットであるインタレストパケットの送信により行われる、
請求項3に記載の受信端末。 - 前記受信端末と前記転送端末との間で前記パケットの受信を含む通信を行う受信スタックと、
前記受信スタックにより行われた前記受信端末と前記転送端末との間の通信から、前記受信端末と前記転送端末との間の損失イベント率である第1の損失イベント率と、前記受信端末と前記転送端末との間のRTTである第1のRTTと、を算出するRTT−R変換部と、を更に有し、
前記利用可能帯域推定部は、
前記受信スタックが受信した前記パケットから、前記受信端末と前記送信端末との間の損失イベント率である第2の損失イベント率と、前記受信端末と前記送信端末との間のRTTである第2のRTTと、を算出し、算出された前記第1の損失イベント率および算出された前記第1のRTTから、前記第1の利用可能帯域を推定し、算出された前記第2の損失イベント率および算出された前記第2のRTTから、前記第2の利用可能帯域を推定し、
前記RTCP−R制御部は、
前記受信スタックに対して、前記インタレストパケットを、推定された前記第1の利用可能帯域に基づく前記頻度で、前記転送端末に対して送信することを指示する、
請求項4に記載の受信端末。 - 前記RTT−R変換部は、
前記受信スタックが受信した前記パケットから、前記実時間ストリームのデータを抽出し、
抽出された前記データから前記実時間ストリームを再生する実時間ストリーム再生部(映像デコーダ)、を更に有し、
前記RTCP−R制御部は、
前記第2の利用可能帯域が、前記送信端末が前記パケットの送信に利用している帯域である第2の実利用帯域よりも大きいか否かを判定し、前記第1の利用可能帯域が前記第2の実利用帯域よりも大きいことを条件として、前記実時間ストリーム再生部に対して、前記実時間ストリームを、本来の再生速度よりも速い速度で再生することを許可する、
請求項5に記載の受信端末。 - 前記受信スタックが受信した前記パケットから、前記実時間ストリームを再生する実時間ストリーム再生部(映像デコーダ)、を更に有し、
前記RTCP−R制御部は、
前記第2の利用可能帯域が、前記送信端末が前記パケットの送信に利用している帯域である第2の実利用帯域よりも小さいか否かを判定し、前記第1の利用可能帯域が前記第2の実利用帯域よりも大きいことを条件として、前記受信スタックに対して、前記実時間ストリームを構成する一連の前記パケットを間引いて要求するように指示する、
請求項5に記載の受信端末。 - 実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける前記送信端末であって、
前記実時間ストリームのデータを格納した前記パケットを送信する送信スタックと、
前記受信端末と前記転送端末との間の利用可能帯域である第1の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第2の利用可能帯域と、を推定し、推定された前記第1の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第1の利用可能帯域を利用して前記パケットを転送させる前記受信端末から、前記第2の利用可能帯域の通知を受けるRTCP−S制御部と、
前記送信スタックに対して、前記受信端末から通知された前記第2の利用可能帯域を利用して前記パケットの送信を行わせる送信帯域推定部と、を有する、
送信端末。 - 実時間ストリームのパケットを送信する送信端末と、前記送信端末から送信された前記パケットをキャッシュして転送する転送端末と、前記転送端末から転送された前記パケットを受信する受信端末と、を有する通信システムにおける流量制御方法であって、
前記受信端末において、前記受信端末と前記転送端末との間の利用可能帯域である第1の利用可能帯域と、前記受信端末と前記送信端末との間の利用可能帯域である第2の利用可能帯域と、を推定するステップと、
前記受信端末において、推定された前記第1の利用可能帯域に基づく頻度で、前記転送端末に対して前記パケットの転送の要求を行うことにより、前記転送端末に対して、前記第1の利用可能帯域を利用して前記パケットを転送させ、推定された前記第2の利用可能帯域を前記送信端末に対して通知することにより、前記送信端末に対して、前記第2の利用可能帯域を利用して前記パケットを送信させるステップと、を有する、
流量制御方法。
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 (11)
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 |
US9749384B2 (en) * | 2012-10-24 | 2017-08-29 | Panasonic Intellectual Property Management Co., Ltd. | Communication system, reception terminal, transmission terminal, and flow rate control method |
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 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America | 通信制御装置、通信制御方法及び通信制御システム |
JP6373437B1 (ja) * | 2017-03-29 | 2018-08-15 | パナソニック株式会社 | 通信装置、通信システムおよびコンテンツ収集方法 |
JP7460569B2 (ja) | 2021-03-05 | 2024-04-02 | Kddi株式会社 | コンテンツ配信ネットワークの転送装置及びプログラム |
Citations (4)
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)
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 |
US20070198739A1 (en) * | 2001-01-19 | 2007-08-23 | Streamworks Technologies, 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 |
JP5025655B2 (ja) * | 2006-10-02 | 2012-09-12 | パナソニック株式会社 | 流量制御方法、ならびにそれに使用する送信端末およびパケット転送システム |
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 | 삼성전자주식회사 | 컨텐츠 중심 네트워크(ccn)에서 단말 및 허브의 통신 방법 및 컨텐츠 중심 네트워크를 위한 단말 |
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 |
JP5746359B2 (ja) * | 2010-11-01 | 2015-07-08 | インターデイジタル パテント ホールディングス インコーポレイテッド | 動的なスペクトル管理 |
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 |
US9357437B2 (en) * | 2011-04-28 | 2016-05-31 | Intel Corporation | Methods and arrangements for communications in low power wireless networks |
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 |
KR101620246B1 (ko) * | 2011-10-24 | 2016-05-23 | 코닌클리즈케 케이피엔 엔.브이. | 콘텐츠의 보안 배포 |
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 |
US9298669B2 (en) * | 2012-04-13 | 2016-03-29 | Futurewei Technologies, Inc. | Systems and methods for 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 |
CN104380753B (zh) * | 2012-04-26 | 2018-05-18 | 华为技术有限公司 | 用于表示自适应流媒体的分段加密和密钥衍生的系统和方法 |
US9749384B2 (en) * | 2012-10-24 | 2017-08-29 | Panasonic Intellectual Property Management Co., Ltd. | Communication system, reception terminal, transmission terminal, and flow rate control method |
-
2013
- 2013-10-02 US US14/435,410 patent/US9749384B2/en active Active
- 2013-10-02 JP JP2014543132A patent/JP6187780B2/ja active Active
- 2013-10-02 WO PCT/JP2013/005880 patent/WO2014064890A1/ja active Application Filing
- 2013-10-02 CN CN201380054877.2A patent/CN104782091B/zh active Active
-
2017
- 2017-07-21 US US15/657,004 patent/US10212205B2/en active Active
-
2019
- 2019-01-04 US US16/240,518 patent/US10547661B2/en active Active
Patent Citations (4)
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 |
---|---|
US20150304380A1 (en) | 2015-10-22 |
US10547661B2 (en) | 2020-01-28 |
US10212205B2 (en) | 2019-02-19 |
US20170324798A1 (en) | 2017-11-09 |
JP6187780B2 (ja) | 2017-08-30 |
CN104782091A (zh) | 2015-07-15 |
WO2014064890A1 (ja) | 2014-05-01 |
CN104782091B (zh) | 2017-09-22 |
US20190141108A1 (en) | 2019-05-09 |
US9749384B2 (en) | 2017-08-29 |
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) | 受信端末及び受信方法 | |
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 | |
KR102491033B1 (ko) | 왕복 시간 추정 | |
JP4237608B2 (ja) | データ通信装置及びデータ通信システム | |
JP5523163B2 (ja) | 送信装置、送信方法、プログラム | |
Arthur et al. | The effects of packet reordering in a wireless multimedia environment | |
JP3848222B2 (ja) | 再送方法 | |
Singh | Protocols and Algorithms for Adaptive Multimedia Systems | |
Ahsan | Multipath RTP: Applying Multipath Communication to Real-time Applications | |
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 | |
Singh | Rate-control for conversational H. 264 video communication in heterogeneous 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 |