JPWO2002025878A1 - データ送受信方法、送信装置、受信装置、送受信システム、およびプログラム - Google Patents

データ送受信方法、送信装置、受信装置、送受信システム、およびプログラム Download PDF

Info

Publication number
JPWO2002025878A1
JPWO2002025878A1 JP2002528967A JP2002528967A JPWO2002025878A1 JP WO2002025878 A1 JPWO2002025878 A1 JP WO2002025878A1 JP 2002528967 A JP2002528967 A JP 2002528967A JP 2002528967 A JP2002528967 A JP 2002528967A JP WO2002025878 A1 JPWO2002025878 A1 JP WO2002025878A1
Authority
JP
Japan
Prior art keywords
transmission
data
terminal
packet
transmission rate
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
JP2002528967A
Other languages
English (en)
Other versions
JP3662907B2 (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 Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial 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 Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Publication of JPWO2002025878A1 publication Critical patent/JPWO2002025878A1/ja
Application granted granted Critical
Publication of JP3662907B2 publication Critical patent/JP3662907B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0015Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
    • H04L1/0017Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy where the mode-switching is based on Quality of Service requirement
    • H04L1/0018Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy where the mode-switching is based on Quality of Service requirement based on latency requirement
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0002Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0023Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the signalling
    • H04L1/0025Transmission of mode-switching indication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/26Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263Rate modification at the source after receiving feedback
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/28Flow control; Congestion control in relation to timing considerations
    • H04L47/283Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

送信端末(10)にて伝播遅延測定部(102)が、中間ノード(12,13,14)のうちボトルネックとなりうる中間ノードの往復伝播遅延時間を、伝播遅延時間測定パケットを用いて測定する。この測定結果に基づき、伝送レート決定部(104)がデータの伝送レートを決定し、決定された伝送レートでデータ送信部(100)がデータを送信する。

Description

技術分野
本発明は、例えばインターネットなどを利用したデータの送受信における、有線、無線が混在した、帯域が非常に大きく変動する環境下でのデータ送受信方法、送信装置、受信装置、送受信システム、およびプログラムに関するものである。
背景技術
イントラネット、インターネットといった、IP(Internet Protocol)ネットワーク上では、接続形態により利用可能な帯域が数Kbps〜数百Mbpsと大きく異なる。しかも、他のフローの影響により、利用可能な帯域が時間的に変動する。このようなネットワークを用いて安定した通信品質を提供するためには、通信経路において確保できる伝送帯域の最大値を見積もり(帯域推定と呼ぶ)、帯域の時間的な変動に応じて送信端末からのデータの伝送レートを変更する(伝送レート制御と呼ぶ)ことが必要となる。特に、UDP(User Datagram Protocol)パケットを用いたデータ伝送は、TCP(Transmission Control Protocol)と異なりトランスポート層においてフロー制御を行わないため、アプリケーション層においてデータの伝送レートを制御する必要がある。さらに、より伝送品質を向上させたい場合には、ルータなどの伝送路上の中間ノードでの帯域保証などが必要になる。
以下では、(1)帯域推定、(2)伝送レート制御、(3)帯域保証について、従来の技術を述べる。
(1)帯域推定の従来技術
帯域推定の従来技術は、大きく分けて、パスチャ(pathchar)方式と、ペアパケット(Pair Packet)方式とが存在する。以下、pathchar方式とPair Packet方式をそれぞれ説明する。
(i) pathchar方式;通信経路における帯域推定方法の1つとして、pathcharが提供されている。これはtracerouteと同様、TTL(Time To Live)フィールドをnにしたパケットを送出することにより、経路上のn番目のルータにICMP(Internet Control Message Protocol)パケットのTTL Expiredメッセージを送信させることで各ルータとの往復伝播遅延時間(RTT:Round Trip Time)を計測するものである(A.B.Downey et al.,”Using pathchar estimate Internet link characteristics”,ACM SIGCOMM’99)。
pathcharによる帯域推定は多くのRTTデータから統計処理によって帯域を推定する。pcharは、さらにこの統計処理方法を工夫することにより、精度向上とともに推定した帯域の信頼度を計算することができる。
(ii) Pair Packet方式;Pair Packet方式による帯域推定は以下のように行われる。すなわち、送信端末は、帯域推定用パケットを連続して受信端末に送信する。帯域推定用パケットは、リンクのパケット処理速度の違いから、ボトルネックリンクを通過したあとに、パケット間に間隔が発生する。この間隔を測定し、帯域推定用パケットのサイズを用いてボトルネックリンクの帯域を計算する(R.L.Carter et al.,”Measuring Bottleneck Link Speed in Packet−Switched Networks”,Technical Report BU−CS−96−006,Computer Science Department,Boston University,March 1996)。 (2)伝送レート制御の従来技術
従来のUDPパケットの伝送レート制御の例として、DAA(Direct Adjustment Algorithm)方式を挙げることができる(D.Sisalem et al.,”The Direct Adjustment Algorithm:A TCP−Friendly Adaptation Scheme”,Technical Report GMD−FOKUS,August 1997.Available from http://www.fokus.gmd.dc/usr/sisalem)。また、LDA(Loss−Delay Based Adjustment Algorithm)方式を挙げることができる(D.Sisalem et al.,”The Loss−Delay Based Adjustment Algorithm:A TCP−Friendly Adaptation Scheme”,in the proceedings of NOSSDAV’98,July,Cambridge,UK)。DAA方式やLDA方式では、データのロス率をRTCP(RTP Control Protocol)を用いて受信端末から送信端末にフィードバックし、パケットロス率や受信端末の受信レートなどに基づいてデータの伝送レートを変更する。
また、送信端末から受信端末までの伝送路に1つの仮想バッファがあるものとみなし、仮想バッファ内に残留しているデータ量を目標バッファ量に近づけるように伝送レートを調整する方式もある(日本国特開平11−308271号公報)。
決定された伝送レートに基づいて送信するデータ量を調整する方法は、リアルタイムデータを送信する場合と、蓄積データを送信する場合とで異なる。例えば、監視カメラの映像を直接配信するようなリアルタイムデータの配信では、エンコーダに直接符号化レートを指示することが可能である。蓄積データの場合には、映像がすでに符号化されているため符号化レートを指示することはできない。したがって、蓄積データの場合には、異なる符号化レートで同一のデータを符号化しておき、決定した伝送レートに最も近い伝送レートで配信する方法が適用されている。例えば、RealVideoは、この方式を採用している(http://service.jp.real.com/help/faq/surestream.html)。
その他、符号化したデータを間引く(映像データならば、フレームを間引くなど)処理を行って配信するか、一旦映像データを復号して指定された符号化レートに符号化しなおすなどの方法により、データ送信量を伝送レートにあわせる方法が考えられている。
(3)帯域保証の従来技術
FTTH(Fiber To The Home)では、最低利用できる帯域の保証と、最大限利用できる帯域を限定する方式が提案されている。
従来技術は以上のとおりであるが、インターネットのような、様々な接続形態が存在し、しかも伝送帯域が変動する伝送路において、安定した伝送品質でデータ伝送を行うことは、上記の従来技術だけでは困難である。例えば、上記従来技術には次に述べるような課題があった。
〈課題1〉
pathchar方式は、32バイトから1472バイトまで32バイト間隔で46種類のサイズのパケットを送信するという1セットを、32セット繰り返す。したがって、リンクの帯域を1箇所測定するのに、1472パケットを送信することになり、推定に多くの時間を要することになる。
〈課題2〉
Pair Packet方式を実際に帯域推定に利用する場合は、帯域推定用のパケットを本来送信したいデータパケットのほかに送信することとなり、伝送帯域を無駄に浪費することとなる。また、実際に帯域推定を行う場合には、帯域推定用のプロトコルをデータパケット送信用のプロトコルとは別に送受信端末に備える必要がある。
〈課題3〉
DAA方式やLDA方式は、伝送レートの計算にパケットのロス率を用いている。これらの方式のように、ロス率に基づいて伝送レート制御を行う方式は、イーサネット(Ethernet)やマルチキャストでは有効である。しかしながら、IPネットワーク上でのエンド−エンド間の通信で、狭帯域の伝送路を利用した場合には、パケットロスの発生から伝送レートの変更までに長時間を要することになる。パケットロスはボトルネックリンクのバッファオーバーフローにより発生するため、受信端末にパケットロスの情報が伝送されるのはオーバーフローしたバッファ内の全てのデータが伝送されるまでかかるからである。
一方、仮想バッファにバッファリングされているデータ量の計算にRTTを用いる手法によれば、バッファオーバーフローが発生する前に伝送レートを調整することができるはずである。しかしながら、伝送路上にある複数のバッファを1つの仮想バッファに近似してしまうため、送信データが複数のバッファに分散している場合と、1つのバッファに集中している場合と、どちらの場合についても同じ動作を行うことになる。このような動作は、データのスループットを向上させたい場合には問題となる。
例えば、複数のバッファに送信データが分散してバッファリングされている場合には、個々のバッファに残留するデータ量が少なく、バッファに余裕があるため、目標バッファ量を大きく設定することでスループットを向上させることができる。また、1つのバッファに集中して送信データがバッファリングされている場合は、バッファに余裕がないため、目標バッファ量を大きく設定してしまうと、バッファオーバーフローが発生し、パケットロスが増大することとなる。
したがって、複数のバッファに分散してデータがバッファリングされている場合と、1つのバッファのみに集中してデータがバッファリングされている場合とで動作を切り替える必要があるが、1つの仮想バッファを考慮するのみでは、動作の切り替えは不可能である。
〈課題4〉
パケットロスが発生した場合には、パケットロスに基づいて伝送レートを変更し、パケットロスが発生していない場合には、レート制御方式の切り替えなどを行うことにより、パケットロスの発生に対して俊敏に対応することができる。しかしながら、そのための具体的な方法は、現在のところ提案されていない。
また、前述の課題3に述べたように、Ethemetやマルチキャストといったネットワークでは、パケットロスに基づいて伝送レート制御を行う方が効果的であるのに対し、エンド−エンド間の通信で、帯域ギャップの大きな伝送路を利用した場合には、前述のような方法を用いた方が効果的である。
このように、伝送路や配送方式によって適したレート制御方式が異なるが、伝送路や配送方式に応じて伝送レート制御を切り替える方式は、提案されていない。
〈課題5〉
一般に伝送レート制御を行う際には、伝送レートの初期値が問題となる。初期値を大きくし過ぎてしまうと、パケットロスが発生し、初期値を小さくし過ぎると、初期段階で帯域を有効に利用できない。
〈課題6〉
FTTHなどでは、伝送すべきコンテンツ(映像、音声、データなど)の符号化レート、バッファリング時間、伝送レートに関しては、考慮されていなかった。そのため、伝送するコンテンツによっては、伝送品質が著しく劣化してしまっていた。
〈課題7〉
送信端末からのデータ伝送を受信端末で制御するプロトコルとして、RTSP(H.Schulzrinne et al.,”Real Time Streaming Protocol”,RFC 2326,Internet Engineering Taskforce,Apr.1998)がある。このプロトコルでは、受信端末がデータ送信の開始、停止などを送信端末に要求し、送信端末が要求に応じてデータ送信の開始、停止を行うことができる。しかしながら、従来の伝送路では、パケットはFIFO(First−In First−Out)キューに入力され、キューがいっぱいで入力できない場合にパケットを廃棄するのが一般的であったため、伝送路が輻輳している場合には、受信端末からの要求が輻輳により遅延、もしくはロスし、データの送信の開始、停止が遅延するという問題があった。特に、受信端末主導で輻輳回避を行うために、異なる伝送レートの映像をRTSPを用いて切り替えるような場合には、受信端末からのデータ送信の開始、停止は低遅延かつ確実に行われる必要がある。データ送信の停止が遅れると、輻輳がさらに悪化し、データ送信の開始が遅れると、受信端末で映像が途切れる結果となる。
TCPに関しても、制御パケット(SYN、FINパケットなど)とデータパケットの区別なく廃棄されると、セッションの確立、開放が遅れることになり、伝送効率の面で問題となる。
〈課題8〉
有線網と無線網とが相互に接続されたネットワークにおいて、例えば有線網に存在するAVサーバから無線網に存在する端末に対してAVデータを伝送する場合、有線網の輻輳を回避するために伝送レート制御が必要である。しかしながら、受信端末において、有線網で発生する輻輳によるパケットロスと無線網で発生する伝送エラーによるパケットロスとを区別することは困難であるため、このような伝送路ではパケットロスに基づいた伝送レート制御方式を適用しても、適切な伝送レート制御を行うことができなかった。輻輳が原因でパケットロスした場合は、輻輳回避のために伝送レートを下げる必要があるが、伝送エラーによるパケットロスに関しては、伝送レートを下げてもパケットロス率が変化しないため、伝送レートを下げる必要はない。
さらに、送信端末−受信端末間のRTTに基づく伝送レート制御方式を適用した場合でも、無線網のRTTが、リンクレイヤレベルでの再送や、ハンドオーバ、ヘッダ圧縮などの処理によって大きく揺らぐため、正確な伝送レート制御は困難であった(西田「無線ネットワークにおけるTCPの改善に関する考察」,モバイルコンピューティングとワイヤレス通信研究会予稿集14−6,pp.39−45,情報処理学会,2000年9月)。
発明の開示
本発明は、このような従来の課題を考慮し、インターネットのような、様々な接続形態が存在し、しかも伝送帯域が変動する伝送路において(特に、従来安定した伝送品質でデータ伝送を行うことが困難であった有線網、無線網の混在する接続形態において)、安定した伝送品質でデータ伝送を行うことを目的とする。
この目的を達成するため、本発明に係る第1のデータ送受信方法は、送信端末と受信端末との間の伝送路上に設けられた中間ノードのうちの全部または一部の中間ノードにおけるデータの受信および/または送信の状態に基づいて、前記送信端末からの伝送レートを決定することとしたものである。
また、本発明に係る第2のデータ送受信方法は、中間ノードで輻輳が発生した場合に、当該輻輳が発生したことを示す輻輳情報を前記中間ノードがデータに付加して受信端末に送信するステップと、当該輻輳情報に基づいて前記受信端末が伝送レートを決定しかつ前記受信端末が送信端末に伝送レートの変更を要求するステップと、当該要求に基づいて前記送信端末がデータ伝送レートを変更するステップとを備えることとしたものである。
また、本発明に係る第3のデータ送受信方法は、送信端末と受信端末との間の伝送路上で、前記送信端末から複数の帯域推定用パケットを所定の間隔で送信し、前記受信端末においてパケット間の到着間隔を測定することで、前記伝送路上の最大利用可能帯域を推定するデータ送受信方法において、前記送信端末からの送信データパケットの一部を前記帯域推定用パケットとして用い、前記送信データパケットのうち帯域推定用として送信された送信データパケットを表す情報を当該送信データパケットに記述しもしくは独立して前記受信端末に送信し、前記受信端末での測定結果を前記送信端末に送信することとしたものである。
また、本発明に係る第4のデータ送受信方法は、輻輳発生時に、データ送受信の制御に関する情報を有するパケットをデータパケットに対して優先的に送信することとしたものである。
発明を実施するための最良の形態
以下では、本発明に係る実施の形態について、図面を参照しつつ説明を行う。
〈実施の形態1〉
本実施の形態は、各中間ノードの送信または受信の状態に基づいて伝送レートを決定する伝送レート制御方式に関し、主として前述の課題3および5を解決するためのものである。
図1は、本実施の形態における全体像を表す図である。送信端末10において、データ送信部100は、キャプチャ、マイク、ファイルといった入力からデータを受け取り、必要なら符号化し、必要ならパケット化して受信端末11にデータパケット送信する手段である。また、送信されたデータパケットのデータ量を測定する手段でもある。また、伝送レート決定部104により決定された伝送レートに基づき、データパケットの伝送レートを調整する手段でもある。データパケットの送信用プロトコルとしては、RTP(Real Time Transport Protocol)といったデータ送信用プロトコルを想定している。
制御情報送受信部101は、データパケットに関する制御情報を受信端末11と送受信する手段である。制御情報としては、パケットロス率、RTT、受信端末11が受信したデータパケットの最大シーケンス番号といった情報を想定している。制御情報送受信用のプロトコルとしては、RTCP(RTP Control Protocol)といったデータ伝送制御用プロトコルを想定している。
伝播遅延測定部102は、中間ノード12,13,14、もしくは受信端末11に対して、例えばPING(Packet Internet Groper)パケットといったRTTの測定可能なパケット(RTT測定パケット)を送信し、RTTを測定する手段である。RTT測定パケットは、全ての中間ノード12〜14および受信端末11に送信してもよいし、過去の測定結果に基づいて、データパケットの残留している可能性の高い中間ノードにのみ送信してもよい。また、指定された閾値より狭いリンク帯域を持つ中間ノードに送信することとしてもよい。RTT自体に代えてRTTの揺らぎを、伝播遅延測定部102が測定することとしてもよい。
帯域情報取得部103は、伝送経路上の、送信端末−中間ノード間、中間ノード−中間ノード間、受信端末−中間ノード間のリンクの帯域(帯域情報と呼ぶ)を取得する手段である。取得方法としては、例えばSNMP(Simple Network Management Protocol)といった機器管理用プロトコルを用いて中間ノードからリンクの帯域情報を取得してもよいし、pchar、pathchar、後述の実施の形態8に示す方法といった、帯域推定方法を用いてもよい。なお、この帯域情報取得部103は、ボトルネックとなるリンクを検出するための手段であるため、ネットワークの構成が明らかであり、ボトルネックリンクがわかっており、かつボトルネックリンクの帯域がわかっているかボトルネックリンクの帯域を知る必要がない場合は備えていなくともよい。
伝送レート決定部104は、データ送信部100、制御情報送受信部101、伝播遅延測定部102、帯域情報取得部103より得られる、受信端末11および中間ノード12〜14との間のRTT、帯域情報、送信したデータパケットのデータ量、各中間ノードに残留している送信データ量などに基づき、データパケットの伝送レートを決定する手段である。
端末制御部105は、これら各部を制御する手段である。
受信端末11において、データ受信部110は、送信端末10からのデータパケットを受信し、必要ならパケットをほどき、必要なら復号化し、モニタ、スピーカ、ファイルといった出力にデータを渡す手段である。
制御情報送受信部111は、データパケットに関する制御情報を送信端末10と送受信する手段である。
伝播遅延測定応答部112は、伝播遅延測定部102から送信されるPINGパケットといったRTT測定パケットに対して応答パケットを送信する手段である。制御情報送受信部111においてRTTが測定可能な場合(例えば、制御情報送信用プロトコルにRTCPを用いた場合など)には、伝播遅延測定応答部112は備えていなくてもよい。
帯域推定応答部113は、送信端末10からの帯域推定用パケットに応答する手段である。帯域情報取得部103が、SNMPといった機器管理用プロトコルを用いて中間ノード12〜14からリンクの帯域情報を取得する場合には、帯域推定応答部113は備えていなくてもよい。また、送信端末10が帯域情報取得部103を備えていない場合にも、帯域推定応答部113を備えていなくともよい。
端末制御部114は、受信端末11における各部を制御する手段である。
中間ノード12は、IPルータのように、受信したデータパケットをあて先に転送するノードである。また、(1)送信する先のリンクの帯域よりも到着レートが高い場合には、データパケットをバッファリングすること、(2)帯域情報通知のための機器管理プロトコルを備える、もしくは帯域推定用パケットに応答すること(送信端末10が帯域情報取得部103を備えていない場合には不要)、(3)認証された、つまり接続が許可された送信端末10からのRTT測定パケットに応答することを想定している。
なお、上記(3)に関して、送信端末を認証する方法としては、RTT測定パケットに応答する送信端末のIPアドレスを登録しておき、RTT測定パケットを受信した際にIPアドレスを確認し、登録されている送信端末にのみ応答するという方法を用いる。
図2は、本実施の形態における、送信端末10の動作を表すフローチャートである。送信端末10は、データを送信する前に帯域情報を取得する(ステップ200)。このステップは、帯域情報取得部103によって行われる。予めボトルネックとなる中間ノードがわかっており、かつボトルネックリンクの帯域がわかっているがボトルネックリンクの帯域の情報が伝送レートを決定する際に不要である場合には、このステップは不要である。
続いて、取得した帯域情報に基づき、データパケットの伝送レートRsndの初期値を決定し、現在の時刻と、制御情報パケットの送信間隔Invlとに基づき、制御情報パケットを送信する時刻Tsndを決定する(ステップ201)。伝送レートの初期値は、ステップ200で得られた帯域情報を用いて、最も狭いリンクの帯域の値とする。これは、課題5の解決にあたる。ステップ200を省いたため、ボトルネックリンクの帯域がわからない場合は、最低伝送レートなどで送信を開始する。伝送レートの初期値の決定は、伝送レート決定部104によって行われ、制御情報パケットの送信時刻の決定は、制御情報送受信部101によって行われる。
続いて、データパケットの送信を開始する(ステップ202)。このステップは、データ送信部100によって行われる。制御情報パケットの送信時刻になった場合には、RTT測定パケットと制御情報パケットを送信する(ステップ203)。RTT測定パケットは、伝播遅延測定部102によって送信され、制御情報パケットは、制御情報送受信部101によって送信される。また、RTT測定パケットの応答が受信された場合には、測定結果を記録する(ステップ204)。このステップは、伝播遅延測定部102によって行われる。また、受信端末11から制御情報パケットを受信した場合には、送信したデータパケットのデータ量、帯域情報、測定されたRTTから、次の伝送レートRnewを決定する(ステップ205)。このステップの動作は、伝送レート決定部104によって行われる。送信端末10は、ステップ203からステップ205を繰り返し、伝送レートを更新していく。
図3は、図2において、伝送レートを決定するステップ(ステップ205)の送信端末10の動作を表すフローチャートである。この動作は、伝送レート決定部104によって行われる。
送信端末10と受信端末11との間に、N個の中間ノードが存在するものとして、送信端末10からk番目の中間ノードをNode(k)とする。送信端末10とNode(k)、Node(k−1)との間の往復伝播遅延時間RTT(k)、RTT(k−1)と、Node(k)のリンクの帯域Rmax(k)から、Node(k)に残留している他のフローを含めた全データ量Btotal(k)を推定する(ステップ300)。ここで、RTTmin(k)は、今までに測定した送信端末10とNode(k)との間のRTTのうちで、最小の値である。データ量Btotal(k)が閾値より大きい場合には、バッファにデータパケットが残留しているものと判定し、閾値よりも小さい場合には、Node(k)にデータパケットが残留していないものと判定する(ステップ301)。
データパケットが残留していないと判定された場合には、Node(k)からの出力レートはNode(k−1)の出力レートと等しいものとして、中間ノードからの送信データパケットの出力レートRout(k)を計算し、Node(k+1)に対する処理に移る(ステップ302)。
データパケットが残留していると判定された場合には、ステップ303からステップ307の処理を行う。
まず、Node(k)にInvlの間に流入した送信端末10の送信データ量Bsnd(k)と、Node(k)にInvlの間に流入した他のフローのデータ量Bother(k)とを計算する(ステップ303)。ここで、Invlは、受信端末11から送信される制御情報パケットの送信時間間隔である。Rsnd(k)は、送信端末10からのデータパケットがNode(k)に流入した入力レートであり、この値は、Node(k−1)の出力レートRout(k−1)に等しい。また、B’total(k)は、前回の測定で得られたNode(k)に残留している他のフローを含めた全データ量である。
続いて、Bsnd(k)とBother(k)との割合と、Node(k)に残留している送信端末10の送信データ量と他のフローのデータ量との割合とが等しい、すなわち、
other(k):Bsnd(k)=Btotal(k)−Best(k):Best(k)
が成立するものとして、送信データパケットの残留量Best(k)を計算する(ステップ304)。
また、Bsnd(k)とBother(k)との割合と、Node(k)からInvlの間に流出した送信データ量と他のフローのデータ量との割合とが等しい、すなわち、
other(k):Bsnd(k)
=(Rmax(k)−Rout(k))・Invl:Rout(k)・Invl
が成立するものとして、Node(k)からの送信データパケットの出力レートRout(k)を計算する(ステップ305)。
続いて、Node(k)に残留している送信データ量が、Invl後に目標データ量Bdesに到達するよう入力レートRinを設定する(ステップ306)。
最後に、Node(k)への入力レートがRinとなるようRnew(k)を求める(ステップ307)。
以上の計算を全ての中間ノードについて行い、Rnew(k)のなかで、最も小さい値を次の伝送レートRnewとする(ステップ308)。
なお、上記で説明した伝送レートの決定方法以外にも、中間ノード−送信端末間のRTTもしくはRTTの揺らぎ(ジッタ)を用いて伝送レートを決定するアルゴリズムや、中間ノードでのパケットロスの情報を利用したアルゴリズムも考えることができる。
例えば、RTTを用いたアルゴリズムとしては、以下が挙げられる。まず、RTT(k)、RTT(k−1)、RTTmin(k)、RTTmin(k−1)を用いて、Node(k)に観測パケットが残留していた時間T(k)を、
T(k)=RTT(k)−RTTmin(k)
−(RTT(k−1)−RTTmin(k−1))
より計算する。
そして、このT(k)がしきい値Tth(中間ノードのデータ残留時間の目標値、ユーザが指定する固定値)に近づくように、Rsnd(k)を、
snd(k)=(1−T(k)/Tth)・Rmax(k)/n+Rrcvより計算する。
ここで、Rmax(k)は、帯域推定において測定されたリンクの最大伝送帯域である。nは、送信レートの増減の割合を決定するパラメータである。この値をn=Nと設定すると、T(k)が常に0の場合(すなわち、常に輻輳が発生していない場合)、Rrcv=0の状態から、最大伝送レートに達するまでにNステップを要することになる。なお、帯域推定を行わず、ユーザがRmax(k)の値を適当に決定することとしてもよい。この場合には、帯域情報取得部103を有する必要がなくなるため、実装が簡便となり、帯域推定を行うための時間を省略できるという利点がある。Rrcvは、受信端末11からのフィードバック情報から計算される受信レートであり、例えば、RTCPを用いてフィードバック情報を受信している場合には、
rcv=P・(Seqmax(j)−Seqmax(j−1))
/I・(1−Loss)
で計算できる。ただし、Pは平均送信パケットサイズ、IはRTCP受信レポートの受信間隔、Seqmax(j)はj番目のRTCP受信レポートの最大シーケンス番号、Lossはパケットロス率である。
以上の計算を全ての中間ノードについて行い、最も小さいRsnd(k)をデータの伝送レートRnewと決定する。
また、RTTの揺らぎを利用したアルゴリズムとしては以下のアルゴリズムが挙げられる。まず、上記で示したT(k)の過去m回の平均値ST(k)と、T(k)の標準偏差J(k)とを用いて、
th(k)=ST(k)+k・J(k)
を計算する。ここで、m、kは定数である。Tth、(k)とT(k)とを比較し、T(k)よりもTth(k)が大きい場合には、Node(k)に対する伝送レートRsnd(k)をRsnd(k)=Rrcv+Bとし、T(k)よりもTth(k)が小さい場合にはRsnd(k)=Rrcv−Bとする。ここで、Bは伝送レートの増減の変動の大きさを決定する値である。上記の計算を全ての中間ノードで行い、最小の値を伝送レートRnewとする。
また、パケットロスの情報を用いた場合には、以下のアルゴリズムを適用できる。まず、パケットロス率を中間ノードから通知するしくみであるものとし、伝送レートRnewを、
new=(現在の伝送レート)・(1−Loss)
と計算する。もしくは、パケットがバッファ溢れによりロスしたことを中間ノードから通知するしくみであるものとし、パケットロスの通知を受信した際に、Rnew=(現在の伝送レート)・αあるいはRnew=(現在の伝送レート)−α’(ここでαあるいはα’は定数)といったように、伝送レートを指数的もしくは加算的に削減する。
なお、上記の例では、全ての中間ノードについてRsnd(k)の計算を行うこととしたが、伝送経路上のボトルネックリンクを選択し、そのリンクに接続された中間ノードにのみRTT測定パケットを送信して上記の計算を行うこととしてもよい。ボトルネックリンクの選択方法としては、例えば、
max(j)<α・min(Rmax(i))
を満たすリンクをボトルネックリンクとみなす方法が考えられる。ここで、min(X(i))は、X(i)の要素の中で、最も小さい値を表す。αはボトルネックリンクの検出感度を表す値であり、この値が大きいほど多くのリンクをボトルネックリンクとして判定する。
〈実施の形態2〉
次に、課題8の解決について説明する。本発明の中間ノードの輻輳状態を利用した伝送レート制御方式を利用すれば、図4に示すような有線網404と無線網405とが相互に接続されたネットワークにおいて、例えば、有線網404上に存在する送信端末401から無線網405上に存在する受信端末403に対して、データを伝送する場合に、無線網405の伝播遅延の揺らぎの影響を受けずに、伝送レート制御を行うことが可能となる。このような接続形態は、携帯電話などの移動体端末が受信端末403となり、サーバ(送信端末)401に接続する場合などが考えられる。すなわち、サーバ401とゲートウェイ402とがEthernetやATM(Asynchronous Transfer Mode)などの有線網404で接続され、ゲートウェイ402と受信端末403とが無線LAN(Local Area Network)やW−CDMA(Wideband Code Division Multiple Access)などの無線網405で接続されている場合である。また、家庭内ネットワークが無線LAN、BlueToothなどにより構成されており、家庭内のネットワークと外部ネットワークとを接続するホームゲートウェイ402などから電話回線などを通じてインターネットに接続されている場合にも、同様の接続形態になる。アプリケーションとしては、ビデオ・オン・デマンドのような映像配信や、TV電話のような双方向の通信を想定している。
より具体的に述べると、通常は有線網404と無線網405とを相互接続するためのゲートウェイ(あるいはルータ)402において輻輳が発生するため、送信端末401とゲートウェイ402との間の輻輳状態を、例えばRTTを利用して測定することで(他の中間ノードを含めてもよい)、送信端末401からの送出量を制御することができる。すなわち、ゲートウェイ402を上記実施の形態1の中間ノード12〜14の1つとみなし、当該中間ノードの状態により伝送レート制御を行うのである。
送信端末401と受信端末403との間で輻輳状態の検出のためにRTT、RTTの揺らぎを測定した場合には、無線網405の揺らぎが大きく輻輳状態の検出を正確に行うことができない場合が多いが、本発明を用いれば、送信端末401とゲートウェイ402との間の有線網404のみのRTT、RTTの揺らぎを測定するため、輻輳の検出を正確に行うことが可能となる。また、パケットロスの原因が有線網404は輻輳、無線網405は伝送エラーであるため、送信端末401と受信端末403との間でパケットロスを観測した場合には、前述の課題8に述べたとおり、適切な伝送レート制御ができないが、本発明を用いれば、送信端末401とゲートウェイ402との間の有線網404のみのパケットロスを観測するため、輻輳によるパケットロスだけを観測することができ、適切な伝送レート制御を行うことが可能である。
なお、図4の形態以外にも、例えば、図5に示すような接続形態や、さらに、有線網、無線網を複数段通過する接続形態が考えられるが、そのような接続形態においても、送信端末と当該送信端末から1つ目のゲートウェイまでの間の有線網にボトルネックリンクが存在し、2つ目以降の有線網にボトルネックリンクが存在しない場合には、本発明の実施は可能である。図5に示される接続形態としては、屋内のネットワークが有線で構築されており、FWA(Fixed Wireless Access)などで外部ネットワークに接続している形態が考えられる。また、自動車の車内ネットワークが有線で構築されており、DSRC(Dedicated Short Range Communication)などで外部ネットワークと接続している場合も同様の接続形態となる。アプリケーションとしては、ビデオ・オン・デマンドのような映像配信や、TV電話のような双方向の通信が考えられる。
なお、図4および図5に示す無線網と有線網とを相互接続したネットワークにおいて、有線網で発生する輻輳に対処してデータ送出量の制御を行うための方法としては、上記の方法の他にも、例えば次の2つが考えられる。
1つ目の方法は、送信端末と受信端末との間で、RTT、パケットロス、ジッタなどのうちの少なくとも1つを測定することでその変動幅や変化期間を計算し、ネットワークにおいて、輻輳が発生している状態にあるのか、あるいはハンドオーバーや伝送エラーなどが発生している状態にあるのかを判断し、前者であると判断した場合には、送信端末は輻輳状態に応じてデータの送出量を制御する方法である。
2つ目の方法は、ゲートウェイなどのルータで輻輳が発生している場合に、輻輳の発生を示すための、IPパケットにおけるECN(Explicit Congestion Notification)フラグを利用して、ルータから受信端末へそれを通知する方法である(ECN方式と呼ぶ)。
まず、送信端末は、同一内容のコンテンツをいくつかの相異なる符号化レートで符号化する。リアルタイムで送信を行う場合には複数のエンコーダでこのような符号化を行い、蓄積コンテンツを利用して送信を行う場合には複数の符号化レートで予め符号化を行っておけばよい。送信端末は、送信される複数の符号化レートをSMIL(Synchronized Multimedia Integration Language)などを用いて受信端末に通知し、受信端末は、そのうちの1つをRTSPなどを用いて選択的に受信する。送信途中で輻輳が発生した場合には、ルータにおいて前述のECNフラグにマークが付されるため、受信端末は、ECNフラグを監視することで輻輳の発生を検知することができる。そして、輻輳の発生が検知されたときには、受信端末がRTSPなどを用いてより低い符号化レートに選択を切り替えて受信(および再生)を行うことで、輻輳状態が緩和される。なお、どの符号化レートへの選択切替を行うのかは、所定期間内に受信されたIPパケットのうち、ECNフラグにマークが付されたIPパケットの個数を所定の閾値と比較するなどして決定すればよい。もちろん、(1)ECNフラグにマークが付されたIPパケットを所定期間内に全く受信しなかった場合や、(2)所定期間内に受信したIPパケットのうちでECNフラグにマークが付されたIPパケットの個数が所定の閾値よりも少なかった場合には、RTSPなどを用いてより高い符号化レートへの選択切替を行うことにより、輻輳の発生を回避しつつ伝送レートを増加させ、高品質のコンテンツ伝送を実現することが可能になる。なお、どの符号化レートへの選択切替を行うのかは、前述の場合と同様、ECNフラグにマークが付されたIPパケットの個数を所定の閾値と比較するなどして決定すればよい。
ECN方式では、ECNフラグを用いることにより、輻輳を明示的に受信端末に通知する。これにより、有線網と無線網とが相互接続された伝送路においても、受信端末が輻輳検出を正確に行うことができるようになり、適切な伝送レート制御を行うことができる。さらに、ECN方式は、受信端末主導で伝送レートを切り替えるため、ユーザ要求の反映が容易であるという効果がある。つまり、伝送レートの変動範囲を受信端末に登録するだけでよい。送信端末主導の伝送レート制御方式の場合には、送信端末に伝送レートの変動範囲を登録する必要があるため、登録用のプロトコルなどが必要になる。さらに、有線網、無線網が複数段接続された接続形態においても、受信端末での輻輳検出が可能となり、適切な伝送レート制御を行うことが可能となる。
図6は、本実施の形態に係るECN方式の全体像を表す概略図である。送信端末60におけるデータ送信部601、端末制御部604、および受信端末61における端末制御部609は、図1と同等である。
データ情報送信部603は、送信端末60が送信可能なデータの伝送レートを通知する手段である。送信端末60が送信可能なデータの伝送レートを記述する記述言語としては、SMILなどを用いればよい。
データ送信制御応答部602は、受信端末61からのデータ送信/停止などの要求を受信し、要求に基づいてデータ送信の開始、停止指示をデータ送信部601に指示し、その要求が受け入れられたかどうかの結果を受信端末61に応答する手段である。送信端末60と受信端末61との間の要求/応答の送受信プロトコルとしては、RTSPなどを用いればよい。
例えば中間ノード62に設けられた輻輳検出部610は、当該中間ノード62のデータの送受信状態を監視し、輻輳が発生した場合には、輻輳が発生したことを表す輻輳情報(フラグなど)をデータパケットに付加して受信端末61に送信する手段である。輻輳情報は、例えばIPパケットのECNフラグを用いて通知すればよい。この輻輳検出部610は、中間ノード62,63,64の全てに搭載されていてもよいし、輻輳の発生しやすい中間ノードにのみ搭載することとしてもよい。
受信端末61において、データ受信部605は、図1のデータ受信部110に、中間ノード62によって付加された輻輳情報を伝送レート決定部608に通知する機能を追加したものである。
データ情報取得部607は、送信端末60が送信可能なデータの伝送レートを取得し、伝送レート決定部608に通知する手段である。
伝送レート決定部608は、通知された輻輳情報と送信端末60が送信可能な伝送レートとに基づき、伝送レートを決定し、データ送信制御要求部606に通知する手段である。
データ送信制御要求部606は、伝送レート決定部608で決定された伝送レートに基づき、データ送信/停止などの要求を送信する手段である。
図7は、本ECN方式の動作の流れを表すシーケンス例である。まず、受信端末61は、送信端末60が送信可能な伝送レートをSMILにより取得する(ステップ701)。図8にこの例で使用するSMILの記述のうち、伝送レートに関する部分を示す。図8をみると、この例では、Stream2を選択した場合には64Kbps(801)、Stream1を選択した場合には128Kbps(802)の2種類の伝送レートでデータの送信が可能であることがわかる。
受信端末61は、受信したSMILの記述に基づき、RTSPのSETUPメソッドを用いて、全ての伝送レートのデータを送信開始可能な状態(Ready状態)にする(ステップ702)。もちろん、データ送信開始の前に必ずしも全ての伝送レートのデータをReady状態にする必要はなく、データ送信開始の前には一部の伝送レートのデータだけReady状態にしておき、他の伝送レートのデータはデータの送信中に必要があればReady状態にすることにしてもよい。
続いて受信端末61は、送信端末60が送信可能な伝送レートのうち、1つを選択してデータ送信の開始を送信端末60に要求する。送信端末60は、要求に応答してデータの送信を開始する(ステップ703)。図7では、データ送信用プロトコルとしてRTPを用い、128Kbpsでデータ(Stream1)の送信を開始している。その後、データ送信中に中間ノード62において輻輳が発生すると、輻輳が発生したことをECNフラグを用いて受信端末61に通知する(ステップ704)。受信端末61は、中間ノード62がセットしたECNフラグに基づいて伝送レートを決定し、伝送レートを変更するために、現在受信しているデータの送信をRTSPのPAUSEメソッドにより一時停止し、現在受信したデータの続きから他の伝送レートのデータを送信するようRTSPのPLAYメソッドを用いて送信端末60に通知する。データの途中からの送信開始は、RTSPのPLAYメソッドに再生範囲を指定するヘッダ(Rangeヘッダ)があるので、それを利用すればよい。送信端末60は、一時停止/再生要求に基づいて、現在送信している伝送レートのデータ送信を一時停止し、他の伝送レートのデータ送信を開始する(ステップ705)。図7では、128Kbpsのデータ(Stream1)の送信を一時停止し、64Kbpsのデータ(Stream2)のデータの送信を開始している。
図9は、伝送レート決定部608が伝送レートを決定するアルゴリズムを示すフローチャートである。まず、送信端末60が送信可能な伝送レートRsnd(j)(1≦j≦N)を取得し、記録する(ステップ901)。この例では、送信端末60が送信可能な伝送レートはN個の離散値であることを想定している。
次に、送信端末60が送信可能な伝送レートのうちの1つを初期伝送レートとして決定し、データ送信制御要求部606に通知する(ステップ902)。続いて、データパケットを受信するたびに、過去N個の受信パケットのうち、ECNフラグの立っていたパケットの数をMとし、その割合L=M/Nを計算する(ステップ903)。ここで、i回目のデータパケットの受信の際に計算されたM、LをそれぞれM(i)、L(i)とし、以下のルールに従い、伝送レートを決定する。
(1) M(i−1)=0かつM(i)≠0ならば、現在受信している伝送レートRよりもαだけ伝送レートを下げる(ステップ904)。ここで、αは固定値である。
(2) L(i)>β(βは0<β<1の定数)の場合には、伝送レートを(現在の伝送レート)・(1−L(i))に下げる。このステップを行ったあとは、伝送レートはI秒間変化させない(ステップ905)。
(3) M(1)(i−K≦l≦i、Kは定数)から、M(i)≒γ・i+δとなる一次近似直線を最小2乗法などにより求め、γがある閾値より大きい場合には、伝送レートを(現在の伝送レート)・C/γ(Cは定数)に下げる。このステップを行った後は、I’秒間このステップを行わない(ステップ906)。このステップは、M(i)が増加傾向にある場合に伝送レートを下げる役割を果たしている。
(4) 伝送レートを変更してI”秒が経過しており、M(i)<θ(θは定数)ならば、伝送レートを(現在の伝送レート)+α’(α’は定数)に増加させる。このステップを行った後は、I”秒間このステップを行わない(ステップ907)。
(5) (1)〜(4)に当てはまらない場合には、伝送レートを変更しない。
以上のステップで決定された伝送レートの値と送信端末60が送信可能な伝送レートとを比較し、最も近い値を伝送レートとして決定し、現在受信している伝送レートと異なる場合には、新しい伝送レートをデータ送信制御要求部606に通知する(ステップ908)。
なお、本実施の形態は、伝送レートを決定する方法を示すものであり、決定された伝送レートに基づいてデータの送信量を調整する方法については、先に従来例に述べたとおりの方法を用いればよい。すなわち、リアルタイムデータであれば、エンコーダに直接符号化レートを指示することで調整が可能であり、蓄積データであれば、複数の符号化レートでデータを符号化しておき、決定された伝送レートに最も近い符号化レートのデータを送信するなどにより調整が可能である。
〈実施の形態3〉
本発明は、1対1のデータ送受信に限定されるものではなく、マルチキャストのような1対Nでのデータ送受信にも利用可能である。マルチキャストの場合にも、図10に示すように、送信端末と複数の受信端末とが、1つのゲートウェイを介して接続している接続形態の場合には、前述の場合と同様、送信端末とゲートウェイとの間のRTT、パケットロス、ジッタなどのうちの少なくとも1つを測定することで、送信端末からのデータの送出量を制御することができる。すなわち、有線網における輻輳状態を測定することにより、このような制御を行うのである。
しかしながら、図11に示すように、送信端末と複数の受信端末とが複数のゲートウェイを介して接続する接続形態で伝送レートを決定する場合には、有線網の伝送経路が1つでないため、上記で述べた伝送レート制御方法だけでは全ての受信端末に最適な伝送レート制御を行うことができない。
本実施の形態は、送信端末と複数のゲートウェイとが接続している接続形態での、伝送レート制御方法を提供するものである。
送信端末と複数の受信端末とが複数のゲートウェイを介して接続している場合には、測定によって得られた複数のゲートウェイでの輻輳状態に応じて、輻輳が発生しているゲートウェイをグループに分割し、グループごとにデータの送出量を調整する。IPv4(Internet Protocol Version 4)においては、そのようなグループの範囲をTTLの値を利用して制限することが可能である。例えば、輻輳の発生している受信端末が属するグループに対してはデータの送出量を減らし、輻輳の発生していないグループに対しては送出量を増やす。このようなグループ分割により、ネットワークにおける輻輳の発生状態に対応したきめ細かなデータ送出量の制御を行うことができる。
図12は、本実施の形態における全体像を示す概略図である。送信端末121は、グループ決定部1201を除いて、図1における送信端末10と同等である。また、受信端末122は、グループ変更部1202を除いて、図1における受信端末11と同等である。
グループ決定部1201は、制御情報送受信部1203で観測された、RTT、パケットロス、ジッタなどの統計情報や、伝播遅延測定部1204で観測された、各中間ノード(複数のゲートウェイを含む)とのRTT、伝送レート決定部1205で決定された伝送レートのうち、少なくとも1つに基づき、受信端末122をグループ分けし、受信端末122にそれぞれが所属するグループを通知する手段である。
グループ変更部1202は、送信端末121から通知されたグループが、自分が現在所属しているグループと異なる場合に、所属するグループを通知されたグループに変更する手段である。
図13は、本実施の形態の動作を表すシーケンス図である。この例では、受信端末AはゲートウェイAに接続されており、受信端末B、CはゲートウェイBに接続されているものとしている。
受信端末A、B、Cは、マルチキャストで映像受信を開始する際に、IGMP(Internet Group Management Protocol)を用いて特定のマルチキャストグループに参加する(ステップ1301)。この例では、各受信端末は最初にグループAに参加する。送信端末121は、受信端末からの制御情報パケットによって、受信端末がマルチキャストグループに参加したことを知ることができる(ステップ1302)。更に、送信端末121は、各受信端末までの伝送経路上のボトルネックとなりうるリンクにRTT観測パケットを送信し、RTTを求める(ステップ1303)。このRTTと、制御情報パケットから得られる受信端末との間のRTT、パケットロス、ジッタなどの情報を用いて、各端末が所属するグループを決定し、受信端末に通知する(ステップ1304)。この例では、受信端末AをグループBに変更する通知を送信している。受信端末Aは、現在所属しているグループと、送信端末121から通知されたグループとが異なるため、グループAをいったん抜けて、グループBに参加しなおす(ステップ1304)。
なお、各マルチキャストグループに対してデータを送信する際の伝送レートは、そのマルチキャストグループに所属する各受信端末に対する伝送レート(上記実施の形態1または2に示した方法で計算できる)の平均値とする。後述するように、伝送レートの変化の傾向が似ている受信端末を同じグループにまとめているため、上記のような単純な伝送レート決定方法でも、そのマルチキャストグループに参加する受信端末がおよそ満足できる伝送レートになる。
図14は、グループ決定部1201の動作を示すフローチャートである。まず、受信端末Aからの制御情報パケットと、受信端末Aへの伝送路上にある中間ノードからのRTT観測パケットとを受信し、上記実施の形態1または2に示す伝送レート制御方法に従って伝送レートRmを決定する(ステップ1401)。続いて、受信端末Aについて過去N回計算された伝送レートRm(i)(1≦i≦N)と、マルチキャストグループj(1≦i≦M、Mは送信端末121の管理しているマルチキャストグループの数)について過去N回計算された伝送レートRo(j,i)から、伝送レートの差Qを計算する(ステップ1402)。Qがある閾値Cよりも小さければ、伝送レートの変化の傾向が近いと判断し、受信端末Aをマルチキャストグループjに変更する(ステップ1403)。QがCよりも大きい場合には、伝送レートの変化の傾向が異なるものとして、受信端末Aをマルチキャストグループjに含めない(ステップ1404)。ステップ1403、1404を、受信端末Aをいずれかのマルチキャストグループに分類するか、全てのマルチキャストグループと伝送レートの変化の傾向を比較するまで繰り返す。全てのマルチキャストグループと伝送レートの変化の傾向を比較しても、Q<Cを満たすマルチキャストグループがない場合には、新しいマルチキャストグループを生成し、受信端末Aをそのグループに変更する(ステップ1405)。
なお、本実施の形態においては、グループ分割を行う方法として、伝送レートの変動の傾向が似ているものをグループ化しているが、より単純に、同じゲートウェイに接続されている受信端末を1つのグループとしてもよい。また、伝送レートの変動の傾向ではなく、パケットロスの傾向、RTTの変動の傾向などが似ているものでグループ化してもよい。
また、本実施の形態においては、伝送レートの決定に送信端末121と中間ノードとの間のRTTを利用していたが、図3の説明の際に述べたとおり、中間ノードとの間のRTTの揺らぎ、中間ノードでのパケットロスに基づいて、伝送レートを決定し、決定された伝送レートに基づいてグループ分割を行うこととしてもよい。
また、送信端末121と受信端末との間のRTT、パケットロス、ジッタなどのうちの少なくとも1つを測定することでその変動幅や変化期間を計算し、ネットワークにおいて、輻輳が発生している状態にあるのか、あるいはハンドオーバーや伝送エラーなどが発生している状態にあるのかを判断し、前者であると判断した場合には、送信端末121は輻輳状態に応じて前述のようなグループ分割を行うこともできる。
また、本実施の形態においては、送信端末121が各受信端末の所属すべきグループを決定し、受信端末がそれに従うという方法により、グループ分割がなされているが、受信端末がグループ決定部1201を保持することにより、受信端末主導でグループ分割を行うことも可能である。例えば、図6に示す構成の受信端末61にグループ決定部1201を追加した構成の場合には、送信端末60が送信可能な伝送レートとマルチキャストアドレスとの組をデータ情報として受信端末61に送信しておき、伝送レート決定部608で決定された伝送レートに基づいて参加するマルチキャストグループを変更するといった方法を用いることにより、受信端末主導のグループ分割も可能である。
また、本実施の形態において、階層符号化を利用したAV伝送が可能である場合には、受信端末において、利用する階層を輻輳状態に応じて決定することもできる。例えば、輻輳の程度が深刻である場合には、最下位の階層のみを利用することにすればよい。
以上述べたとおり、実施の形態1〜3によれば、中間ノードのデータの送受信の状態を考慮した伝送レート制御を行うことで、インターネットのような様々な接続形態で接続されるネットワークにおいても、適切な伝送レート制御を行うことができる。特に、従来適切な伝送レート制御が困難であった、無線LAN、DSRC、W−CDMA、FWA、といった無線網と、Ethernet、ATMといった有線網とが混在する接続形態において、1対1通信、1対N通信(マルチキャスト)によらず、TV電話、ビデオ・オン・デマンドといったアプリケーションで適切な伝送レート制御を行うことができる。
〈実施の形態4〉
本実施の形態は、中間ノードに残留する残留データ量を目標値に近づけようとする際における、中間ノードの状態に応じた目標値変更方式に関し、主として前述の課題3を解決するためのものである。
図15は、本実施の形態における全体像を表す概略図である。同図において、送信端末150は、図1の送信端末10から帯域情報取得部103を削除したものである。受信端末151は、図1の受信端末11から帯域推定応答部113を削除したものである。中間ノード152,153,154は、図1の中間ノード12〜14と同等である。
図16は、本実施の形態における送信端末150の動作を表すフローチャートである。同図は、図2において、帯域情報を取得するステップ(ステップ200)を削除し、伝送レートの初期値を適当な値に設定するよう変更したものに他ならないので、ステップ番号は省略する。
図17は、図16中の伝送レートを決定するステップの動作を表すフローチャートである。この動作は、送信端末150における伝送レート決定部1503の動作である。まず、受信端末151の受信レートRrcvを計算する(ステップ1700)。RTCPを用いて制御情報を送信している場合には、最大シーケンス番号SEQmaxと、パケットロス率Lossと、制御情報パケットの送信間隔Invlとを用いてRrcvを計算できる。ただし、SEQ’maxは、前回のRTCPパケットによって通知された最大シーケンス番号である。
続いて、送信端末150と受信端末151との間の伝送路上に残留しているデータ量Bestを、送信端末150と受信端末151との間のRTTと、Rrcvとを用いて計算する(ステップ1701)。ここで、RTTminは、今までに送信端末150と受信端末151との間で測定したRTTのうちで最小の値を表す。
続いて、送信端末150とNode(k)、Node(k−1)との間の往復伝播遅延時間RTT(k)、RTT(k−1)と、Node(k)のリンクの帯域Rmax(k)とから、Node(k)に残留している他のフローを含めた全データ量Btotal(k)を推定する(ステップ1702)。ここで、RTTmin(k)は、今までに送信端末150とNode(k)との間で測定したRTTのうちで最小の値を表す。このデータ量Btotal(k)が閾値より大きい場合には、Node(k)にデータパケットが残留しているものと判定し、閾値よりも小さい場合には、Node(k)にデータパケットが残留していないものと判定する(ステップ1703)。
判定によってデータパケットが残留しているとされた中間ノードの数nをカウントし、目標データ量Bdesを基本目標データ量Bbaseとnより計算する(ステップ1704)。最後に、受信端末151からの制御情報の送信時間間隔Invlの間に残留データ量がBdesに到達するよう次の伝送レートRnewを決定する(ステップ1705)。
なお、ステップ1704において、目標データ量をBbaseとnにより計算したが、パケットロス率Lossにより、Bdes=Bbase・(1−Loss)と計算することとしてもよい。
〈実施の形態5〉
本実施の形態は、パケットロスが発生しているかいないかにより、伝送レートの決定方法を切り替える方式に関し、主として前述の課題4を解決するためのものである。
本実施の形態における全体像を表す概略図は、図1と同等である。また、本実施の形態における送信端末の動作を示すフローチャートは図2と同等である。
図18は、本実施の形態において、伝送レートを決定するステップ(図2中のステップ205)の動作を表すフローチャートである。まず、パケットロスが発生しているかどうかを制御情報パケットのパケットロス率Lossに基づいて判定する(ステップ1800)。パケットロスが発生したと判定した場合には、パケットロス率Lossと前回の伝送レートR’sndとに基づき、次の伝送レートRnewを決定する(ステップ1801)。なお、ステップ1801に示す方法以外にも、前回の送信レートに基づいて、Rsnd=R’snd・(定数)(ただし、定数は0以上1以下の実数である)としてもよいし、DAA方式やLDA方式といった、パケットロスに基づいたレート制御方式を用いてもよい。パケットロスが発生していないときには、図3に示す方法を用いて伝送レートRne を決定する(ステップ1802)。なお、ステップ1802は、図3に示す方法以外に、図17に示す方法などを用いてもよい。
ステップ1800において、パケットロスが発生したかどうかによって伝送レート制御方式を切り替えるのではなく、現在使用している伝送路や配送方式に基づいて伝送レート制御方式を切り替えてもよい。すなわち、Ethernetやマルチキャストの場合には、ステップ1801を行い、1対1通信で、帯域ギャップの大きい伝送路を使用している場合にはステップ1802を行うこととしてもよい。
〈実施の形態6〉
本実施の形態は、制御情報チャネルとデータチャネルとを用いて帯域推定を行う帯域推定方式に関し、主として前述の課題2を解決するためのものである。
図19は、本実施の形態における全体像を示す概略図である。送信端末1900において、データ送信部1901は、キャプチャ、マイク、ファイルといった入力からデータを受け取り、必要なら符号化し、必要ならパケット化して受信端末1910にデータパケット送信する手段である。また、帯域推定制御部1903の指示により、データパケットを、パケットの送信間隔なしに連続して送信する手段でもある。データの送信用プロトコルとしては、RTPといったデータ送信用プロトコルを想定している。
制御情報送受信部1902は、送信端末1900から送信するデータパケットに関する制御情報を受信端末1910と送受信する手段である。送信端末1900から受信端末1910に送信する制御情報としては、どのデータパケットを帯域推定用として送信したかを示す情報があり、受信端末1910から送信端末1900への情報としては、帯域推定の結果がある。制御情報送信用のプロトコルとしては、TCPを用いてもよいし、RTCPといったデータ伝送制御プロトコルを拡張してもよい。
帯域推定制御部1903は、帯域推定用のパケットとして、データ送信部1901に、データパケットをパケットの送信間隔なしに連続して送信するよう指示する手段である。また、帯域推定用に送信されるパケット(例えば、データパケットをRTPを用いて送信している場合には、送信間隔なしに送信されたパケットの先頭と末尾のシーケンス番号)を制御情報送受信部1902に通知する手段でもある。
端末制御部1904は、送信端末1900の各部を制御する手段である。
受信端末1910において、データ受信部1911は、送信端末1900からの送信データパケットを受信し、必要ならパケットをほどき、必要なら復号化し、モニタ、スピーカ、ファイルといった出力にデータを渡す手段である。
制御情報送受信部1912は、送信データパケットに関する制御情報を送信端末1900と送受信する手段である。
帯域推定部1913は、制御情報送受信部1912において受信される帯域推定用パケットを示す情報に基づき、帯域推定用パケットの到着間隔を測定する手段である。この到着間隔に基づき、伝送帯域を推定し、その結果を制御情報送受信部1912に通知する手段でもある。
端末制御部1914は、受信端末1910の各部を制御する手段である。
図20は、帯域推定を行う際に、制御情報送信用プロトコルとしてTCPを、データパケット送信用のプロトコルとしてRTPをそれぞれ用いた場合の送信端末1900と受信端末1910との間のシーケンス図である。
送信端末1900は、まず、どのデータパケットが帯域推定用のパケットであるかを通知する制御情報パケットを送信する(TCPパケット2000)。同図では、Seq1からSeq2までの間のデータパケットを用いることとしている。続いて、帯域推定用パケットとしてデータパケットを所定の時間間隔で連続して送信する(RTPパケット2001)。所定の時間間隔は、なるべく伝送路上で帯域推定用パケット間に他のパケットが挿入されない程度の短い間隔(当然、0秒を含む)とする。受信端末1910は、送信端末1900から通知された帯域推定用パケットの到着間隔deltaを測定し、これに基づいてボトルネックリンクの帯域R=P/(deltaの平均値)を推定する(ここで、Pはデータパケットのパケットサイズである)。受信端末1910は、測定結果を制御情報パケットを用いて送信する(TCPパケット2002)。
〈実施の形態7〉
本実施の形態は、データパケットに帯域推定フラグを持つ帯域推定方式に関し、主として前述の課題2を解決するためのものである。
図21は、本実施の形態における全体像を表す概略図である。送信端末2100において、データ送信部2101は、キャプチャ、マイク、ファイルといった入力からデータを受け取り、必要なら符号化し、必要ならパケット化して受信端末2110にデータパケット送信する手段である。また、帯域推定制御部2103の指示により、データパケットを、パケットの送信間隔なしに連続して送信する手段でもある。また、帯域推定用パケットとして送信されたデータパケットに、帯域推定用パケットであることを示す帯域推定フラグを立てる手段でもある。データの送信用プロトコルとしては、RTPといったデータ送信用プロトコルを想定している。帯域推定フラグは、RTPのマーカービットフィールド、エクステンションビットフィールドといった、データパケットヘッダの既存のフィールドを利用してもよいし、RTPパケットを拡張して新たなフィールドを定義してもよいし、ペイロードに入力してもよい。なお、帯域推定フラグは、帯域推定用パケットとして送信されるパケット全てのフラグを立てることとしてもよいし、帯域推定用パケットとして送信される先頭のパケットと末尾のパケットにのみ立てることとしてもよい。
推定結果受信部2102は、受信端末2110からの帯域推定の結果を受信する手段である。推定結果送受信用のプロトコルとしては、RTCPといったデータ伝送制御プロトコルを想定している。
帯域推定制御部2103は、データ送信部2101に、帯域推定用パケットとして、データパケットをパケットの間隔なしに連続して送信するよう指示する手段である。
端末制御部2104は、送信端末2100の各部を制御する手段である。
受信端末2110において、データ受信部2111は、送信端末2100からの送信データパケットを受信し、必要ならパケットをほどき、必要なら復号化し、モニタ、スピーカ、ファイルといった出力にデータを渡す手段である。
推定結果送信部2112は、帯域推定部2113において推定されたボトルネックリンクの帯域を、送信端末2100に送信する手段である。推定結果送受信用のプロトコルとしては、RTCPといったデータ伝送制御プロトコルを想定している。
帯域推定部2113は、データパケットの帯域推定フラグをチェックする手段である。また、帯域推定フラグが立っている場合には、データパケットの到着間隔deltaを測定し、この結果に基づいてボトルネックリンクの帯域R=P/(deltaの平均値)(Pはデータパケットのパケットサイズ)を推定し、その結果を推定結果送信部2112に通知する手段でもある。この際、RTPパケットのシーケンス番号Seqの跳びによりパケットロスを検知した場合には、シーケンス番号Seq−1とSeq+1との到着間隔deltaを測定結果に含めないこととする。これは、パケットロスによる推定の誤差をなくすためである。
端末制御部2114は、受信端末2110の各部を制御する手段である。
図22は、帯域推定を行う際に、データパケット送信にRTPを、推定結果の送信にRTCPをそれぞれ用いた場合の、送信端末2100と受信端末2110との間のシーケンス図である。まず、送信端末2100は、帯域推定用のパケットとして、送信間隔なしにデータパケットを送信する(RTPパケット2200)。このとき、データパケットにはそのパケットが帯域推定用であることを示す帯域推定フラグが立てられている。受信端末2110は、データパケットを受信し、データパケットの帯域推定フラグをチェックする。帯域推定フラグが立っている場合には、パケットの到着間隔を測定し、この結果に基づいてボトルネックリンクの帯域を推定する。受信端末2110は、推定結果を送信端末2100に送信する(RTCPパケット2201)。
なお、本実施の形態において、データパケットを送信する前に予めボトルネックリンクの帯域Rを推定したい場合や、帯域推定パケットとしてデータパケットを用いたくない場合には、データをペイロードに含んでいないデータパケットを帯域測定用パケットとして送信し、受信端末2110において帯域推定用パケットの到着間隔のみ測定し、パケットを破棄することとしてもよい。
また、本実施の形態において、帯域推定フラグではなく、帯域推定用パケットを送信した数を表す帯域推定シーケンス番号を用いてもよい。この際、帯域推定シーケンス番号が0である場合には、到着間隔の測定を行わず、0以外になった場合に到着間隔を測定することとする。また、帯域推定シーケンス番号が跳んだことでパケットロスを検出し、ロスしたパケットの前後のパケットを用いて到着間隔を測定しないことで、パケットロスによる推定の誤差をなくすことができる。
〈実施の形態8〉
本実施の形態は、終了条件付き帯域推定方式に関し、主として前述の課題1を解決するためのものである。
図23は、本実施の形態における全体像を示す概略図である。同図において、送信端末2301は、受信端末2302までの経路上に存在する各中間ノード2303,2304に対して、帯域推定用のパケットを送信する。帯域推定用のパケットは、経路上の各中間ノード2303,2304との間のRTTを計測するパケットである。例えば、IPネットワークであれば、TTLフィールドをnにしたIPパケットを送出することにより、経路上のn番目の中間ノードにICMPパケットのTTL Expiredメッセージを送信させることで、各中間ノードとのRTTを計測することができる。
受信端末2302は、送信端末2301から送信された帯域推定用のパケットに対し、応答を送信する。例えば、IPネットワークであれば、送信端末2301からのPINGパケットに対し、応答PINGパケットを送信する。受信端末2302は、送信端末2301が帯域を計測する経路の終端である。
中間ノード2303,2304は、送信端末2301から送信された帯域推定用のパケットに対し、応答を送信する。例えば、IPネットワークであれば、TTLフィールドをnにしたIPパケットを送信端末2301が送信した場合には、経路上のn番目のノードがICMPパケットのTTL Expiredメッセージを送信端末2301に送信する。
リンク2305,2306,2307は、送信端末2301、受信端末2302、各中間ノード2303,2304を接続するEthernet、SLIP(Serial Line Internet Protocol)といったネットワークである。本実施の形態では、このリンクの帯域を推定する。
図24は、送信端末2301が帯域推定を行う際の動作を示すフローチャートである。送信端末2301は、当該送信端末2301に近い順にリンクの帯域の推定を行っていく。全リンクの測定時間Tを指定し、送信端末2301から受信端末2302までの間にN個のリンクが存在するものとし、送信端末2301からk番目のリンクの帯域を以下のとおり推定する。
まず、32バイトから1472バイトまで32バイト間隔46種類のサイズのパケットを中間ノード2303に送信する(ステップ2400)。続いて、パケットサイズをs、最小RTTをtとし、
t=α(k)+β(k)s
となるα(k)およびβ(k)を、最小2乗法を用いて求める(ステップ2401)。なお、より少ない計測点数でより精度の高い結果を得るために、M推定、重み付き最小2乗法といった、他の統計処理を用いてもよい。
α(k)、β(k)の計算結果を、前回の試行の結果で得られたα’(k)、β’(k)と比較し、変化が閾値の範囲内であれば、結果が収束したものと判定する。ただし、k番目のノードの推定終了時刻Tを過ぎた場合には、結果が収束したものと判定する。なお、k番目のノードの推定終了時刻は、(推定開始時刻)+k・T/Nであるものとする(ステップ2402)。
収束していないと判定された場合には、もう一度ステップ2400、2401を繰り返す。なお、収束判定の際に、前回の試行の結果だけでなく、過去複数回の試行の結果と比較して変化が閾値の範囲内であるかどうかを判定してもよい。
ステップ2402において、α(k)、β(k)が収束したと判定された場合には、β(k)とβ(k−1)とを比較する。β(k−1)よりもβ(k)が小さい場合は、推定帯域がマイナスとなるため、β(k−1)、β(k)のどちらかに誤りがあることになる。この誤りを正すために、測定時間が残っている場合には、前のホップに戻って測定をやり直す(ステップ2403)。
β(k)がβ(k−1)よりも大きい場合もしくは測定時刻を過ぎた場合には、正しく測定されたと判定し、リンクの帯域を求める(ステップ2404)。続いて、次のホップがあるなら次のホップの帯域推定に移り、最終ホップへ到達した場合には、処理を終了する(ステップ2405)。
〈実施の形態9〉
本実施の形態は、中間ノード(例えばルータやゲートウェイ)で最低限の帯域を確保して、伝送品質を確保する方式に関し、主として前述の課題6を解決するためのものである。
図25は、本実施の形態における全体像を表す概略図である。送信端末250は、図1に示す送信端末10に、帯域予約部2501を追加したものである。送信端末250と受信端末251との間に介在した中間ノード252は、図1に示す中間ノード12に、帯域制御部2502を追加したものである。
帯域予約部2501は、送信端末250が送信可能な最低伝送レートと、最大伝送レートとを中間ノード252に通知する手段である。また、通知した伝送レートで帯域が確保できたかどうかの結果を受信する手段でもある。
帯域制御部2502は、送信端末250から通知された最低伝送レートで伝送帯域を予約する手段である。また、伝送帯域の予約が不可能である場合には、伝送帯域を確保できないことを送信端末250に通知する手段でもある。
図26は、本実施の形態の動作を表すシーケンス図である。データの送信前に、送信端末250は、当該送信端末250が送信可能な最小伝送レートと最大伝送レートとを中間ノード252に通知する(ステップ2601)。中間ノード252は、通知された伝送レートで伝送帯域を予約し、予約ができたことを送信端末250に通知する(ステップ2602)。送信端末250は、伝送帯域が予約できたことを確認し、データの送信を開始する。この際、送信端末250は、制御情報パケットや、中間ノード252との間のRTTなどから、上記実施の形態1または2で説明した方法で伝送レートを決定し、決定された伝送レートでデータを送信する。輻輳が極端に悪化し、伝送レートを最低値まで下げた場合には、中間ノード252で伝送帯域が予約されているため、最低限の伝送品質を確保することができ(つまり、帯域予約により、パケットロスが発生しない)、乱れのない映像や途切れの少ない音声伝送を実現することが可能となる(ステップ2603)。
なお、本実施の形態では、送信端末250が必要な伝送帯域を通知して伝送帯域の予約を行ったが、送信端末250からの伝送帯域の通知を行わずに本発明を実施することも可能である。例えば、送信端末250の最低伝送レートが決定しているものとして、管理者が中間ノード252で予め予約する帯域を設定することとしても、本発明の実施は可能である。また、中間ノード252におけるデータの送信に使用可能な伝送帯域を予約し、予約された帯域を送信端末250に通知し、送信端末250が、伝送レートの決定をその予約された伝送帯域に基づいて行っても本発明の実施は可能である。ここで、中間ノード252におけるデータの送信に使用可能な伝送帯域は、当該中間ノード252において送信されるデータの種類に基づいていてもよい。
さらに、受信端末251が、送信端末250に要求する最低伝送レートを中間ノード252に通知し、中間ノード252が予約を行うことも可能である。このような予約方法は、受信端末251が要求する最低の映像品質を伝送に反映するのに有効である。
また、受信端末251は、データを再生する前にネットワークの揺らぎを吸収するためにデータを数秒間バッファリングするが、この受信端末251は(バッファリング時間)×(最低伝送レート)のバッファを最低限保持することで、乱れのない映像や途切れの少ない音声伝送を実現することができる。
〈実施の形態10〉
本実施の形態は、制御パケットを優先して送信することで、映像品質を確保する方式に関し、主として前述の課題7を解決するためのものである。
図27は、本実施の形態における全体像を示す概略図である。送信端末271において、データ送信部2701およびデータ送信制御応答部2702は、図6に示すデータ送信部601およびデータ送信制御応答部602とそれぞれ同等である。また、受信端末272において、データ受信部2706およびデータ送信制御要求部2708は、図6に示すデータ受信部605およびデータ送信制御要求部606とそれぞれ同等である。
図27中の優先度付加部2703,2707は、ネットワークに送信するパケットのうち、制御用のパケットに高い優先度を、データパケットに低い優先度を付加する手段である。優先度付加の方法としては、IPパケットのTOSフィールドに、優先度情報を入力するといった方法が挙げられる。
中間ノード273に配置された優先度処理部2705は、高い優先度を付加したパケットを優先的に処理する手段である。この優先度処理部2705により、高い優先度を付加されたパケットは廃棄される確率が低くなり、低遅延で受信端末272に伝送されるようになる。優先度処理の方法として、DiffServを用いてもよい。
上記の構成により、輻輳が発生している場合でも、制御用のパケットを低遅延かつロスすることなく送信することが可能となり、データパケットの送信の停止、開始を低遅延かつ確実に行うことができるようになる。
なお、上記の構成をTCPに適用することにより、TCPのセッションの確立、開放を低遅延かつ確実に行うことが可能となる。例えば、制御パケット(SYN、FINパケット)に対して、廃棄確率が低くなるように優先度を設定することで、TCPのセッションの確立、開放を低遅延かつ確実に行うことが可能となる。
もちろん、このような手法は、端末とサーバとの間の1対1通信だけではなく、複数の端末に放送する1対N通信(マルチキャスト)に対しても適用可能である。
以上、本発明に係る実施の形態1〜10を説明したが、本発明のデータ送受信方法を実現するための送信装置、受信装置、およびこれらを備えた送受信システムも本発明に含まれることは、言うまでもない。
本発明は、上述した本発明の送信装置、受信装置、送受信システムの全部または一部の手段(または、装置、素子、回路、部など)の機能をコンピュータにより実行させるためのプログラムであって、コンピュータと協働して動作するプログラムをも含む。なお、本発明のコンピュータは、CPU(Central Processing Unit)などの純然たるハードウェアに限らず、ファームウェアやOS(Operating System)、さらに周辺機器を含むものであってもよい。
本発明は、上述した本発明のデータ送受信方法の全部または一部のステップ(または、工程、動作、作用など)の動作をコンピュータにより実行させるためのプログラムであって、コンピュータと協働して動作するプログラムをも含む。
また、本発明のプログラムを記録した、コンピュータに読み取り可能な記録媒体も本発明に含まれる。また、本発明のプログラムの一利用形態は、コンピュータにより読み取り可能な記録媒体に記録され、コンピュータと協働して動作する態様であってもよい。また、本発明のプログラムの一利用形態は、伝送媒体中を伝送し、コンピュータにより読み取られ、コンピュータと協働して動作する態様であってもよい。また、記録媒体としては、ROM(Read Only Memory)等が含まれ、伝送媒体としては、インターネット等の伝送媒体、光・電波・音波等が含まれる。
また、本発明の構成は、ソフトウェア的に実現してもよいし、ハードウェア的に実現してもよい。
産業上の利用の可能性
本発明によれば、インターネットのような、様々な接続形態が存在し、しかも伝送帯域が変動する伝送路において、安定した伝送品質で、効率良くデータ伝送を行うことができる。特に、従来安定した伝送品質でデータ伝送を行うことが困難であった有線網、無線網の混在する接続形態においても、本発明を適用することにより、インターネットTV電話、ビデオ・オン・デマンド、放送(マルチキャスト)、ビデオ掲示板などの幅広いアプリケーションにおいて、安定した伝送品質で、効率良くデータ伝送を行うことが可能となる。
【図面の簡単な説明】
図1は、本発明の実施の形態1における全体像を示す概略図である。
図2は、本発明の実施の形態1における送信端末の動作を表すフローチャートである。
図3は、本発明の実施の形態1における伝送レート制御のフローチャートである。
図4は、本発明の実施の形態2における有線網と無線網とが混在する接続形態を表す図である。
図5は、本発明の実施の形態2における有線網と無線網とが混在する他の接続形態を表す図である。
図6は、本発明の実施の形態2における全体像を示す概略図である。
図7は、本発明の実施の形態2における送信端末と受信端末との間のシーケンス図である。
図8は、本発明の実施の形態2における伝送レートに関する情報の記述を示す図である。
図9は、本発明の実施の形態2における伝送レート制御のフローチャートである。
図10は、本発明の実施の形態3におけるマルチキャストでの接続形態を表す図である。
図11は、本発明の実施の形態3におけるマルチキャストでの他の接続形態を表す図である。
図12は、本発明の実施の形態3における全体像を示す概略図である。
図13は、本発明の実施の形態3における送信端末と複数の受信端末との間のシーケンス図である。
図14は、本発明の実施の形態3における複数の受信端末のグループ分割のためのフローチャートである。
図15は、本発明の実施の形態4における全体像を示す概略図である。
図16は、本発明の実施の形態4における送信端末の動作を表すフローチャートである。
図17は、本発明の実施の形態4における伝送レート制御のフローチャートである。
図18は、本発明の実施の形態5における伝送レート制御のフローチャートである。
図19は、本発明の実施の形態6における全体像を示す概略図である。
図20は、本発明の実施の形態6における送信端末と受信端末との間のシーケンス図である。
図21は、本発明の実施の形態7における全体像を示す概略図である。
図22は、本発明の実施の形態7における送信端末と受信端末との間のシーケンス図である。
図23は、本発明の実施の形態8における全体像を示す概略図である。
図24は、本発明の実施の形態8における送信端末の動作を表すフローチャートである。
図25は、本発明の実施の形態9における全体像を示す概略図である。
図26は、本発明の実施の形態9における送信端末と受信端末との間のシーケンス図である。
図27は、本発明の実施の形態10における全体像を示す概略図である。

Claims (19)

  1. 送信端末と受信端末との間の伝送路上に設けられた中間ノードのうちの全部または一部の中間ノードにおけるデータの受信および/または送信の状態に基づいて、前記送信端末からの伝送レートを決定することを特徴とするデータ送受信方法。
  2. 請求項1記載のデータ送受信方法において、
    前記全部または一部の中間ノードと前記送信端末との間の往復伝播遅延時間、往復伝播遅延時間の揺らぎ、中間ノードでのパケットロス、中間ノードのリンクの帯域、過去の伝送レートの少なくとも1つに基づいて、前記送信端末からの伝送レートを決定することを特徴とするデータ送受信方法。
  3. 請求項2記載のデータ送受信方法において、
    前記往復伝播遅延時間、前記往復伝播遅延時間の揺らぎ、前記中間ノードでのパケットロスのうち少なくとも1つ以上の情報を前記送信端末が取得する際に、前記情報の取得が可能な送信端末を前記中間ノードで制限することを特徴とするデータ送受信方法。
  4. 請求項1記載のデータ送受信方法において、
    前記伝送路は、有線区間と無線区間とを有し、
    前記中間ノードの少なくとも1つが前記有線区間と前記無線区間とを接続するゲートウェイであり、
    前記ゲートウェイを含む前記中間ノードにおけるデータの受信および/または送信の状態に基づいて、前記送信端末からの伝送レートを決定することを特徴とするデータ送受信方法。
  5. 請求項4記載のデータ送受信方法において、
    前記無線区間の影響を取り除いた往復伝播遅延時間、往復伝播遅延時間の揺らぎ、パケットロスのうち少なくとも1つに基づいて、前記送信端末からの伝送レートを決定することを特徴とするデータ送受信方法。
  6. 請求項1記載のデータ送受信方法において、
    前記伝送路上の全部または一部のリンクの帯域をデータの送信前に測定することを特徴とするデータ送受信方法。
  7. 請求項1記載のデータ送受信方法において、
    前記送信端末が前記受信端末に対して送信するデータの伝送レートの初期値を、前記伝送路において伝送帯域の最も小さいリンクの帯域とすることを特徴とするデータ送受信方法。
  8. 請求項1記載のデータ送受信方法において、
    前記中間ノードにおける使用可能な伝送帯域を予約し、
    前記伝送レートの決定は、前記予約された伝送帯域に基づいて行われることを特徴とするデータ送受信方法。
  9. 請求項8記載のデータ送受信方法において、
    前記中間ノードにおけるデータの受信および/または送信に使用可能な伝送帯域は、前記中間ノードにおいて受信および/または送信されるデータの種類に基づくことを特徴とするデータ送受信方法。
  10. 中間ノードで輻輳が発生した場合に、当該輻輳が発生したことを示す輻輳情報を前記中間ノードがデータに付加して受信端末に送信するステップと、
    前記輻輳情報に基づいて前記受信端末が伝送レートを決定し、かつ前記受信端末が送信端末に伝送レートの変更を要求するステップと、
    前記要求に基づいて前記送信端末がデータ伝送レートを変更するステップとを備えたことを特徴とするデータ送受信方法。
  11. 送信端末と受信端末との間の伝送路上で、前記送信端末から複数の帯域推定用パケットを所定の間隔で送信し、前記受信端末においてパケット間の到着間隔を測定することで、前記伝送路上の最大利用可能帯域を推定するデータ送受信方法であって、
    前記送信端末からの送信データパケットの一部を前記帯域推定用パケットとして用い、前記送信データパケットのうち帯域推定用として送信された送信データパケットを表す情報を当該送信データパケットに記述しもしくは独立して前記受信端末に送信し、前記受信端末での測定結果を前記送信端末に送信することを特徴とするデータ送受信方法。
  12. 輻輳発生時に、データ送受信の制御に関する情報を有するパケットをデータパケットに対して優先的に送信することを特徴とするデータ送受信方法。
  13. 送信端末と受信端末との間の伝送路上に設けられた中間ノードのうちの全部または一部の中間ノードにおけるデータの受信および/または送信の状態を測定する測定手段と、
    前記受信および/または送信の状態から伝送レートを決定する伝送レート決定手段とを備えたことを特徴とする送信装置。
  14. 請求項13記載の送信装置において、
    前記測定手段は、前記全部または一部の中間ノードと前記送信端末との間の伝播遅延時間または伝播遅延時間の揺らぎを測定することを特徴とする送信装置。
  15. 送信端末が送信可能な伝送レートを取得する手段と、
    データパケットに付加された輻輳情報を検出する手段と、
    前記輻輳情報に基づいて伝送レートを決定する手段と、
    前記決定した伝送レートに基づいてデータ伝送レートの変更を前記送信端末に要求する手段とを備えたことを特徴とする受信端末。
  16. 請求項1〜12のいずれか1項に記載のデータ送受信方法を実現するための送信装置。
  17. 請求項1〜12のいずれか1項に記載のデータ送受信方法を実現するための受信装置。
  18. 請求項1〜12のいずれか1項に記載のデータ送受信方法を実現するための送信装置と、請求項1〜12のいずれか1項に記載のデータ送受信方法を実現するための受信装置とを備えた送受信システム。
  19. 請求項1〜12のいずれか1項に記載のデータ送受信方法を実現するためのプログラム。
JP2002528967A 2000-09-22 2001-08-10 データ送受信方法、送信装置、受信装置、送受信システム、およびプログラム Expired - Fee Related JP3662907B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
JP2000288348 2000-09-22
JP2000288348 2000-09-22
JP2000374857 2000-12-08
JP2000374857 2000-12-08
JP2001051037 2001-02-26
JP2001051037 2001-02-26
PCT/JP2001/006959 WO2002025878A1 (fr) 2000-09-22 2001-08-10 Procede de transmission/reception de donnees, dispositif de transmission, dispositif de reception, systeme de transmission/reception et programme

Publications (2)

Publication Number Publication Date
JPWO2002025878A1 true JPWO2002025878A1 (ja) 2004-02-05
JP3662907B2 JP3662907B2 (ja) 2005-06-22

Family

ID=27344712

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002528967A Expired - Fee Related JP3662907B2 (ja) 2000-09-22 2001-08-10 データ送受信方法、送信装置、受信装置、送受信システム、およびプログラム

Country Status (5)

Country Link
US (1) US20020194361A1 (ja)
EP (1) EP1235392A1 (ja)
JP (1) JP3662907B2 (ja)
AU (1) AU2001277773A1 (ja)
WO (1) WO2002025878A1 (ja)

Families Citing this family (187)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1158615C (zh) * 2001-09-06 2004-07-21 华为技术有限公司 对流媒体服务器实现负载均衡的方法和设备
JP3806931B2 (ja) * 2002-07-30 2006-08-09 ソニー株式会社 情報処理装置および方法、並びにプログラム
EP1526461B1 (en) * 2002-07-30 2018-12-19 Sony Corporation Program, information processing method and device, and data structure
JP2004112113A (ja) * 2002-09-13 2004-04-08 Matsushita Electric Ind Co Ltd リアルタイム通信の適応制御方法、受信報告パケットの連続消失に対する対策方法、受信報告パケットの送出間隔の動的決定装置、リアルタイム通信の適応制御装置、データ受信装置およびデータ配信装置
TW200414737A (en) * 2002-09-27 2004-08-01 Matsushita Electric Ind Co Ltd Contents transmission system
EP1450514A1 (en) * 2003-02-18 2004-08-25 Matsushita Electric Industrial Co., Ltd. Server-based rate control in a multimedia streaming environment
JP3836083B2 (ja) 2003-03-13 2006-10-18 松下電器産業株式会社 メディア配信装置、メディア受信装置、メディア配信方法及びメディア受信方法
JP2004280695A (ja) 2003-03-18 2004-10-07 Sony Corp データ共有システム,送信側端末装置,受信側端末装置,プログラム,送信側端末装置の処理方法
JP2005027208A (ja) * 2003-07-01 2005-01-27 Sony Corp 送信装置および方法、記録媒体、並びにプログラム
EP1671453A4 (en) * 2003-09-10 2010-01-20 Hyperdata Technologies Inc INTERNET PROTOCOL ENHANCER
SE0302685D0 (sv) * 2003-10-07 2003-10-07 Ericsson Telefon Ab L M Method and arrangement in a telecommunication system
JP4306579B2 (ja) * 2003-10-17 2009-08-05 パナソニック株式会社 ホームリンク設定方法、ホームゲートウェイ装置、および移動端末
KR100529931B1 (ko) * 2003-12-09 2005-11-22 엘지전자 주식회사 무선 네트워크망을 통해 통신하는 서버 시스템
EP1645072B1 (en) * 2004-06-04 2007-08-08 Siemens Aktiengesellschaft Dynamic and traffic-driven optimization of message routing to geographical addresses
KR100608821B1 (ko) * 2004-07-22 2006-08-08 엘지전자 주식회사 휴대단말기의 왕복지연시간 측정장치 및 방법
KR100641159B1 (ko) 2004-07-23 2006-11-02 엘지전자 주식회사 Rtcp패킷 기반의 적응적 멀티미디어 데이터 전송률추정방법
GB2417390B (en) * 2004-08-18 2007-11-14 Wecomm Ltd Data packet transmission
GB2417389B (en) * 2004-08-18 2007-10-31 Wecomm Ltd Transmitting data
JP2006074251A (ja) * 2004-08-31 2006-03-16 Advantest Corp フロー制御方法、通信機器、及びtcp通信システム
US8966551B2 (en) 2007-11-01 2015-02-24 Cisco Technology, Inc. Locating points of interest using references to media frames within a packet flow
US9197857B2 (en) 2004-09-24 2015-11-24 Cisco Technology, Inc. IP-based stream splicing with content-specific splice points
US7460476B1 (en) * 2004-10-18 2008-12-02 Ubicom, Inc. Automatic adaptive network traffic prioritization and shaping
US7633869B1 (en) * 2004-10-18 2009-12-15 Ubicom, Inc. Automatic network traffic characterization
US7443801B2 (en) * 2004-10-28 2008-10-28 Telcordia Technologies, Inc. Remote estimation of round-trip delays in a data network
US7760638B2 (en) * 2004-11-29 2010-07-20 Nec Corporation High-throughput communication system, communication terminal, session relay, and communication protocol
US7633879B2 (en) * 2004-12-13 2009-12-15 Cisco Technology, Inc. Method and apparatus for discovering the incoming media path for an internet protocol media session
KR100739172B1 (ko) * 2005-03-03 2007-07-13 엘지전자 주식회사 의사 스트리밍 기술을 이용한 이동 단말기의 동영상 전송방법
JP4257307B2 (ja) 2005-03-14 2009-04-22 富士通株式会社 通信制御システムおよび通信制御方法
US7436772B2 (en) * 2005-03-23 2008-10-14 Microsoft Corporation Available bandwidth estimation
JP4643330B2 (ja) 2005-03-28 2011-03-02 ソニー株式会社 通信処理装置、データ通信システム、および通信処理方法、並びにコンピュータ・プログラム
JP4628194B2 (ja) * 2005-06-14 2011-02-09 株式会社エヌ・ティ・ティ・ドコモ 通信装置、所要時間測定方法及び通信制御方法
JP4598073B2 (ja) * 2005-08-01 2010-12-15 パナソニック株式会社 送信装置および送信方法
US8670309B2 (en) * 2005-09-30 2014-03-11 Alcatel Lucent Method and apparatus for preventing activation of a congestion control process
JP2007104524A (ja) * 2005-10-07 2007-04-19 Kyocera Mita Corp Ipゲートウェイ、通信方法、プログラム及びその記録媒体
JP2007158988A (ja) * 2005-12-08 2007-06-21 Matsushita Electric Ind Co Ltd ルータ装置及びネットワーク障害の判別方法
EP2574057B1 (en) 2006-01-05 2014-01-29 Telefonaktiebolaget L M Ericsson (publ) Media content management
KR101203469B1 (ko) * 2006-02-11 2012-11-21 삼성전자주식회사 패킷 네트워크에서 컷스루 방식으로 노드간 전파 지연 및거리를 정확하고 안전하게 측정하는 방법 및 상기 방법을수행하는 패킷 네트워크 노드
KR101210341B1 (ko) * 2006-02-11 2012-12-10 삼성전자주식회사 패킷 네트워크에서 노드간 전파 지연 및 거리를 정확하고안전하게 측정하는 방법 및 상기 방법을 수행하는 패킷네트워크 노드
US7623474B2 (en) * 2006-02-14 2009-11-24 Cisco Technology, Inc. Techniques for distributing information using multicast subsets
EP1993243B1 (en) 2006-03-16 2012-06-06 Panasonic Corporation Terminal
KR100848128B1 (ko) * 2006-04-24 2008-07-24 한국전자통신연구원 실시간 스트리밍 프로토콜을 이용한 프로그래시브 스트리밍방법
EP2021907A2 (en) * 2006-05-26 2009-02-11 Qualcomm Incorporated Wireless architecture for a traditional wire-based protocol
US9198084B2 (en) 2006-05-26 2015-11-24 Qualcomm Incorporated Wireless architecture for a traditional wire-based protocol
JP5265860B2 (ja) * 2006-09-05 2013-08-14 ソニー株式会社 受信装置
US20080062923A1 (en) * 2006-09-12 2008-03-13 Aruba Wireless Networks System and method for reliable multicast over shared wireless media for spectrum efficiency and battery power conservation
US8731594B2 (en) 2006-09-12 2014-05-20 Aruba Networks, Inc. System and method for reliable multicast transmissions over shared wireless media for spectrum efficiency and battery power conservation
US7930449B2 (en) * 2006-09-14 2011-04-19 Opentv Inc. Method and system for data transmission
US8335873B2 (en) 2006-09-14 2012-12-18 Opentv, Inc. Method and systems for data transmission
US11303684B2 (en) 2006-09-14 2022-04-12 Opentv, Inc. Methods and systems for data transmission
WO2008037397A1 (en) * 2006-09-28 2008-04-03 Koninklijke Kpn N.V. Method and system for selecting a data transmission rate
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
KR20080040956A (ko) * 2006-11-06 2008-05-09 삼성전자주식회사 영상기록 중 수신영상의 상태에 기초하여 영상기록을제어하는 촬영장치 및 그의 영상기록방법
JP4943901B2 (ja) * 2007-03-06 2012-05-30 Kddi株式会社 ハンドオーバのための移動無線通信用のエッジルータ装置及びプログラム
US8543682B2 (en) * 2007-05-02 2013-09-24 Spirent Communications, Inc. Quality of experience indicator for network diagnosis
US7936695B2 (en) 2007-05-14 2011-05-03 Cisco Technology, Inc. Tunneling reports for real-time internet protocol media streams
US8023419B2 (en) 2007-05-14 2011-09-20 Cisco Technology, Inc. Remote monitoring of real-time internet protocol media streams
GB2449944B (en) 2007-06-09 2012-08-08 Wecomm Ltd Supplying applications to mobile devices
US7835406B2 (en) 2007-06-18 2010-11-16 Cisco Technology, Inc. Surrogate stream for monitoring realtime media
US7817546B2 (en) 2007-07-06 2010-10-19 Cisco Technology, Inc. Quasi RTP metrics for non-RTP media flows
US20090016222A1 (en) * 2007-07-12 2009-01-15 Viasat, Inc. Methods and systems for implementing time-slice flow control
US8549099B2 (en) * 2007-07-12 2013-10-01 Viasat, Inc. Methods and systems for javascript parsing
US8171135B2 (en) * 2007-07-12 2012-05-01 Viasat, Inc. Accumulator for prefetch abort
US20100146415A1 (en) * 2007-07-12 2010-06-10 Viasat, Inc. Dns prefetch
US8966053B2 (en) 2007-07-12 2015-02-24 Viasat, Inc. Methods and systems for performing a prefetch abort operation for network acceleration
JP2009055327A (ja) * 2007-08-27 2009-03-12 Hitachi Ltd ネットワークシステム
CN101622900B (zh) 2007-08-28 2012-12-26 松下电器产业株式会社 网络控制装置、方法、以及程序
FR2922391B1 (fr) * 2007-10-15 2009-12-04 Canon Kk Procede et dispositif de transmission de donnees
US9654328B2 (en) 2007-10-15 2017-05-16 Viasat, Inc. Methods and systems for implementing a cache model in a prefetching system
US11876707B2 (en) * 2007-10-24 2024-01-16 Sococo, Inc. Routing virtual area based communications
US8407364B2 (en) * 2007-10-25 2013-03-26 Cisco Technology, Inc. Apparatus and method for providing a congestion measurement in a network
JP4840334B2 (ja) * 2007-11-14 2011-12-21 ブラザー工業株式会社 端末装置、通信システム、プログラム及び方法
CN101675705B (zh) 2007-12-25 2013-06-12 松下电器产业株式会社 通信装置、通信方法
US8005010B2 (en) * 2008-01-30 2011-08-23 At&T Intellectual Property I, L.P. Method and apparatus for providing performance measurement for a network tunnel
EP2255535B1 (en) * 2008-03-12 2015-01-14 Telefonaktiebolaget L M Ericsson (publ) Device and method for adaptation of target rate of video signals
GB0809014D0 (en) * 2008-05-17 2008-06-25 Slever Solutions Ltd Improvements in and relating to the management of data congestion in a data network
US20090300209A1 (en) * 2008-06-03 2009-12-03 Uri Elzur Method and system for path based network congestion management
WO2009150849A1 (ja) 2008-06-12 2009-12-17 パナソニック株式会社 ネットワーク監視装置、バスシステム監視装置、方法、およびプログラム
US7948887B2 (en) * 2008-06-24 2011-05-24 Microsoft Corporation Network bandwidth measurement
US7710976B2 (en) * 2008-07-08 2010-05-04 International Business Machines Corporation Methods, systems and computer program products for packet prioritization based on delivery time expectation
US7860017B2 (en) * 2008-10-27 2010-12-28 Cisco Technology, Inc. Network assessment and fault isolation
US9398089B2 (en) 2008-12-11 2016-07-19 Qualcomm Incorporated Dynamic resource sharing among multiple wireless devices
EP2204954B1 (en) * 2009-01-06 2017-12-27 Alcatel Lucent Optimised bandwidth utilisation in networks
US20100180005A1 (en) * 2009-01-12 2010-07-15 Viasat, Inc. Cache cycling
TWI385587B (zh) * 2009-02-19 2013-02-11 Univ Tunghai Advanced predictive recursive adjustment cooperative allocation method
US8989705B1 (en) 2009-06-18 2015-03-24 Sprint Communications Company L.P. Secure placement of centralized media controller application in mobile access terminal
EP2449727B1 (fr) * 2009-06-30 2020-12-02 Orange Dispositif de commande de l'ouverture de sessions, plateforme de service avec un tel dispositif, procédé, programme d'ordinateur et support d'information associés
US9264248B2 (en) 2009-07-02 2016-02-16 Qualcomm Incorporated System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment
JP5353494B2 (ja) * 2009-07-03 2013-11-27 富士通株式会社 通信装置、および通信方法
CN101646207B (zh) * 2009-08-31 2012-08-08 华为技术有限公司 带宽信息通知方法、业务处理方法、网络节点及通信系统
US9007914B2 (en) * 2009-09-30 2015-04-14 Qualcomm Incorporated Methods and apparatus for enabling rate adaptation across network configurations
JP5196666B2 (ja) * 2009-10-03 2013-05-15 Kddi株式会社 期限時刻までにデータの送信を完了するデータ送信装置、プログラム及び方法
US8301982B2 (en) 2009-11-18 2012-10-30 Cisco Technology, Inc. RTP-based loss recovery and quality monitoring for non-IP and raw-IP MPEG transport flows
JP2011114490A (ja) * 2009-11-25 2011-06-09 Toshiba Corp 放送素材送出装置及びデータ送出方法
US9059914B2 (en) * 2009-12-11 2015-06-16 Nec Corporation Usable bandwidth measurement method, usable bandwidth measurement system, terminal device, and computer-readable recording medium
US9582238B2 (en) 2009-12-14 2017-02-28 Qualcomm Incorporated Decomposed multi-stream (DMS) techniques for video display systems
JP5428834B2 (ja) * 2009-12-21 2014-02-26 富士通株式会社 ネットワークグループ判定装置、ネットワークグループ判定方法、およびネットワークグループ判定プログラム
JP5523130B2 (ja) * 2010-02-08 2014-06-18 キヤノン株式会社 通信装置、通信方法、及びプログラム
US8819714B2 (en) 2010-05-19 2014-08-26 Cisco Technology, Inc. Ratings and quality measurements for digital broadcast viewers
WO2011148748A1 (ja) * 2010-05-28 2011-12-01 日本電気株式会社 伝送装置、帯域制御方法及びコンピュータプログラム
JP5552918B2 (ja) * 2010-06-24 2014-07-16 ソニー株式会社 接続設定方法、カメラシステム及び記憶媒体
US9143457B2 (en) 2010-10-06 2015-09-22 Qualcomm Incorporated Methods and apparatus for ECN receiver driven congestion control
US8923498B2 (en) * 2010-10-26 2014-12-30 Vonage Network, Llc Systems and methods for integrating information from voice over internet protocol systems and social networking systems
WO2012089110A1 (en) * 2010-12-28 2012-07-05 The Chinese University Of Hong Kong Systems and methods to improve performance of tcp over large bandwidth-delay-product networks
US9413803B2 (en) 2011-01-21 2016-08-09 Qualcomm Incorporated User input back channel for wireless displays
US9582239B2 (en) 2011-01-21 2017-02-28 Qualcomm Incorporated User input back channel for wireless displays
US10135900B2 (en) 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
US9787725B2 (en) 2011-01-21 2017-10-10 Qualcomm Incorporated User input back channel for wireless displays
US10108386B2 (en) 2011-02-04 2018-10-23 Qualcomm Incorporated Content provisioning for wireless back channel
US9503771B2 (en) 2011-02-04 2016-11-22 Qualcomm Incorporated Low latency wireless display for graphics
JP5636995B2 (ja) * 2011-02-07 2014-12-10 セイコーエプソン株式会社 ネットワーク通信装置、方法、及びプログラム
JP2012253805A (ja) * 2011-05-12 2012-12-20 Sharp Corp 表示装置、および表示システム
JP5101728B1 (ja) 2011-05-12 2012-12-19 シャープ株式会社 出力システムおよび表示システム
US9021121B2 (en) * 2011-06-17 2015-04-28 Lenovo (Singapore) Pte. Ltd. Setting a rate of data transmission in a peer-to-peer mode
WO2013014246A1 (en) * 2011-07-26 2013-01-31 Nec Europe Ltd. A method for controlling the encoding rate of data traffic and a network
EP2608558A1 (en) * 2011-12-22 2013-06-26 Thomson Licensing System and method for adaptive streaming in a multipath environment
US9525998B2 (en) 2012-01-06 2016-12-20 Qualcomm Incorporated Wireless display with multiscreen service
WO2013119802A1 (en) * 2012-02-11 2013-08-15 Social Communications Company Routing virtual area based communications
US20130262692A1 (en) * 2012-03-28 2013-10-03 Rovi Corp System and Methods of Media Streaming from a Media Server using RTSP with Reduced Delays
US20130262691A1 (en) * 2012-03-28 2013-10-03 Rovi Corp System and Methods of Media Streaming using RTSP with Reduced Delays
US9027102B2 (en) 2012-05-11 2015-05-05 Sprint Communications Company L.P. Web server bypass of backend process on near field communications and secure element chips
US8862181B1 (en) 2012-05-29 2014-10-14 Sprint Communications Company L.P. Electronic purchase transaction trust infrastructure
US9282898B2 (en) 2012-06-25 2016-03-15 Sprint Communications Company L.P. End-to-end trusted communications infrastructure
US9066230B1 (en) 2012-06-27 2015-06-23 Sprint Communications Company L.P. Trusted policy and charging enforcement function
US8649770B1 (en) 2012-07-02 2014-02-11 Sprint Communications Company, L.P. Extended trusted security zone radio modem
US8667607B2 (en) 2012-07-24 2014-03-04 Sprint Communications Company L.P. Trusted security zone access to peripheral devices
US8863252B1 (en) 2012-07-25 2014-10-14 Sprint Communications Company L.P. Trusted access to third party applications systems and methods
US9183412B2 (en) 2012-08-10 2015-11-10 Sprint Communications Company L.P. Systems and methods for provisioning and using multiple trusted security zones on an electronic device
US8954588B1 (en) * 2012-08-25 2015-02-10 Sprint Communications Company L.P. Reservations in real-time brokering of digital content delivery
US9015068B1 (en) 2012-08-25 2015-04-21 Sprint Communications Company L.P. Framework for real-time brokering of digital content delivery
US9215180B1 (en) 2012-08-25 2015-12-15 Sprint Communications Company L.P. File retrieval in real-time brokering of digital content
CN104823419B (zh) * 2012-11-28 2018-04-10 松下知识产权经营株式会社 接收终端及接收方法
WO2014087764A1 (ja) * 2012-12-03 2014-06-12 日本電気株式会社 端末および通信システム
CN102970153B (zh) * 2012-12-04 2015-04-22 福建星网锐捷网络有限公司 组播报文处理方法、装置及系统
JP5998923B2 (ja) * 2012-12-28 2016-09-28 富士通株式会社 プログラム、情報処理装置、及び通信方法
US9161227B1 (en) 2013-02-07 2015-10-13 Sprint Communications Company L.P. Trusted signaling in long term evolution (LTE) 4G wireless communication
US9578664B1 (en) 2013-02-07 2017-02-21 Sprint Communications Company L.P. Trusted signaling in 3GPP interfaces in a network function virtualization wireless communication system
US9104840B1 (en) 2013-03-05 2015-08-11 Sprint Communications Company L.P. Trusted security zone watermark
JP6086000B2 (ja) * 2013-03-11 2017-03-01 株式会社リコー 情報処理装置、通信制御方法及びプログラム
US9613208B1 (en) 2013-03-13 2017-04-04 Sprint Communications Company L.P. Trusted security zone enhanced with trusted hardware drivers
US8881977B1 (en) 2013-03-13 2014-11-11 Sprint Communications Company L.P. Point-of-sale and automated teller machine transactions using trusted mobile access device
US9049013B2 (en) 2013-03-14 2015-06-02 Sprint Communications Company L.P. Trusted security zone containers for the protection and confidentiality of trusted service manager data
US9049186B1 (en) 2013-03-14 2015-06-02 Sprint Communications Company L.P. Trusted security zone re-provisioning and re-use capability for refurbished mobile devices
US9021585B1 (en) 2013-03-15 2015-04-28 Sprint Communications Company L.P. JTAG fuse vulnerability determination and protection using a trusted execution environment
US9191388B1 (en) 2013-03-15 2015-11-17 Sprint Communications Company L.P. Trusted security zone communication addressing on an electronic device
US9374363B1 (en) 2013-03-15 2016-06-21 Sprint Communications Company L.P. Restricting access of a portable communication device to confidential data or applications via a remote network based on event triggers generated by the portable communication device
US8984592B1 (en) 2013-03-15 2015-03-17 Sprint Communications Company L.P. Enablement of a trusted security zone authentication for remote mobile device management systems and methods
US9324016B1 (en) 2013-04-04 2016-04-26 Sprint Communications Company L.P. Digest of biographical information for an electronic device with static and dynamic portions
US9454723B1 (en) 2013-04-04 2016-09-27 Sprint Communications Company L.P. Radio frequency identity (RFID) chip electrically and communicatively coupled to motherboard of mobile communication device
US9171243B1 (en) 2013-04-04 2015-10-27 Sprint Communications Company L.P. System for managing a digest of biographical information stored in a radio frequency identity chip coupled to a mobile communication device
US9060296B1 (en) 2013-04-05 2015-06-16 Sprint Communications Company L.P. System and method for mapping network congestion in real-time
US9838869B1 (en) 2013-04-10 2017-12-05 Sprint Communications Company L.P. Delivering digital content to a mobile device via a digital rights clearing house
US9443088B1 (en) 2013-04-15 2016-09-13 Sprint Communications Company L.P. Protection for multimedia files pre-downloaded to a mobile device
JP6010502B2 (ja) * 2013-05-07 2016-10-19 アンリツネットワークス株式会社 パケット処理方法及びパケット処理装置
US9069952B1 (en) 2013-05-20 2015-06-30 Sprint Communications Company L.P. Method for enabling hardware assisted operating system region for safe execution of untrusted code using trusted transitional memory
US9560519B1 (en) 2013-06-06 2017-01-31 Sprint Communications Company L.P. Mobile communication device profound identity brokering framework
US9183606B1 (en) 2013-07-10 2015-11-10 Sprint Communications Company L.P. Trusted processing location within a graphics processing unit
US9208339B1 (en) 2013-08-12 2015-12-08 Sprint Communications Company L.P. Verifying Applications in Virtual Environments Using a Trusted Security Zone
US9185626B1 (en) 2013-10-29 2015-11-10 Sprint Communications Company L.P. Secure peer-to-peer call forking facilitated by trusted 3rd party voice server provisioning
US9191522B1 (en) 2013-11-08 2015-11-17 Sprint Communications Company L.P. Billing varied service based on tier
US9161325B1 (en) 2013-11-20 2015-10-13 Sprint Communications Company L.P. Subscriber identity module virtualization
US9118655B1 (en) 2014-01-24 2015-08-25 Sprint Communications Company L.P. Trusted display and transmission of digital ticket documentation
JP6331532B2 (ja) * 2014-03-17 2018-05-30 株式会社リコー 伝送管理装置、情報処理方法、プログラム、及び伝送システム
US9226145B1 (en) 2014-03-28 2015-12-29 Sprint Communications Company L.P. Verification of mobile device integrity during activation
US10469404B1 (en) * 2014-05-12 2019-11-05 Google Llc Network multi-level rate limiter
US9230085B1 (en) 2014-07-29 2016-01-05 Sprint Communications Company L.P. Network based temporary trust extension to a remote or mobile device enabled via specialized cloud services
US9444714B2 (en) * 2014-08-07 2016-09-13 Microsoft Technology Licensing, Llc Estimating bandwidth in a network
US9924383B2 (en) * 2014-08-07 2018-03-20 Samsung Electronics Co., Ltd. Method and terminal for transmitting and receiving data according to a transmission speed of data
US9779232B1 (en) 2015-01-14 2017-10-03 Sprint Communications Company L.P. Trusted code generation and verification to prevent fraud from maleficent external devices that capture data
US9838868B1 (en) 2015-01-26 2017-12-05 Sprint Communications Company L.P. Mated universal serial bus (USB) wireless dongles configured with destination addresses
US9801019B2 (en) * 2015-03-16 2017-10-24 Qualcomm Incorporated Adaptive triggering of RTT ranging for enhanced position accuracy
US9473945B1 (en) 2015-04-07 2016-10-18 Sprint Communications Company L.P. Infrastructure for secure short message transmission
US9819679B1 (en) 2015-09-14 2017-11-14 Sprint Communications Company L.P. Hardware assisted provenance proof of named data networking associated to device data, addresses, services, and servers
US10282719B1 (en) 2015-11-12 2019-05-07 Sprint Communications Company L.P. Secure and trusted device-based billing and charging process using privilege for network proxy authentication and audit
US9817992B1 (en) 2015-11-20 2017-11-14 Sprint Communications Company Lp. System and method for secure USIM wireless network access
KR102480856B1 (ko) * 2016-06-17 2022-12-23 삼성전자주식회사 블루투스 기반의 무선 통신 시스템에서 스트리밍 데이터의 통신 방법 및 장치
US10491412B2 (en) * 2016-07-30 2019-11-26 Wipro Limited System and a method for multimultimedia broadcast and multicast services
WO2018072154A1 (zh) 2016-10-19 2018-04-26 华为技术有限公司 检测方法、设备和系统
US10129155B2 (en) * 2016-11-21 2018-11-13 Microsoft Technology Licensing, Llc Delay based congestion control protocol co-existing with TCP
RU2663704C1 (ru) * 2017-05-22 2018-08-08 Федеральное государственное казенное военное образовательное учреждение высшего образования "Академия Федеральной службы охраны Российской Федерации" (Академия ФСО России) Способ измерения показателей качества функционирования сети связи с коммутацией пакетов и устройство для его осуществления
US10499249B1 (en) 2017-07-11 2019-12-03 Sprint Communications Company L.P. Data link layer trust signaling in communication network
WO2019112497A1 (en) * 2017-12-06 2019-06-13 Telefonaktiebolaget Lm Ericsson (Publ) Determining packet loss in a fronthaul link
US11463782B2 (en) * 2018-06-21 2022-10-04 Dish Network L.L.C. User device control of transmission parameters
US10715409B2 (en) * 2018-06-27 2020-07-14 Microsoft Technology Licensing, Llc Heuristics for end to end digital communication performance measurement
JP7485018B2 (ja) * 2020-04-27 2024-05-16 日本電信電話株式会社 コンテンツ配信システム
CN113286279A (zh) * 2021-04-12 2021-08-20 西安中科创达软件有限公司 数据处理方法、装置、设备及存储介质
US20240048497A1 (en) * 2021-04-26 2024-02-08 Mitsubishi Electric Corporation Communication device, communication method, and recording medium
CN114157610B (zh) * 2021-09-16 2022-07-08 北京天德科技有限公司 一种适用于区块链网络的高速网络协议系统及传输方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06338918A (ja) * 1993-05-28 1994-12-06 Nec Corp 非同期転送網におけるバースト帯域予約方法
JP2639335B2 (ja) * 1993-12-22 1997-08-13 日本電気株式会社 Atm網における輻輳制御方式
US5589983A (en) * 1993-12-29 1996-12-31 Eastman Kodak Company Method of manufacturing a diffractive surface profile
EP0667728B1 (en) * 1994-01-14 1999-11-03 International Business Machines Corporation Method for automatically adapting and configuring the speed of an ISDN terminal adapter to either 56 KBPS or 64 KBPS
US5623492A (en) * 1995-03-24 1997-04-22 U S West Technologies, Inc. Methods and systems for managing bandwidth resources in a fast packet switching network
JPH0918514A (ja) * 1995-07-03 1997-01-17 Nippon Telegr & Teleph Corp <Ntt> 可変帯域通信装置
WO1997002685A1 (fr) * 1995-07-03 1997-01-23 Nippon Telegraph And Telephone Corporation Reseau de communications a bande variable
EP0800294B1 (en) * 1996-03-20 2004-08-04 Alcatel Method to control data flow rate, queuing network node and packet switching network
US6192039B1 (en) * 1996-03-25 2001-02-20 Yrp Mobile Telecommunications Key Technology Research Laboratories Co., Ltd. Method for flow control, node and communication network employing the flow control
JP2937867B2 (ja) * 1996-06-25 1999-08-23 日本電気通信システム株式会社 キュー制御方法
JPH10271132A (ja) * 1997-03-27 1998-10-09 Toshiba Corp パケット交換網におけるフロー制御方式
JP2000151692A (ja) * 1998-11-05 2000-05-30 Nec Corp 資源予約装置および方法
US7016971B1 (en) * 1999-05-24 2006-03-21 Hewlett-Packard Company Congestion management in a distributed computer system multiplying current variable injection rate with a constant to set new variable injection rate at source node
US7058723B2 (en) * 2000-03-14 2006-06-06 Adaptec, Inc. Congestion control for internet protocol storage
WO2001077850A1 (en) * 2000-04-06 2001-10-18 Rensselaer Polytechnic Institute System and method of source based multicast congestion control

Also Published As

Publication number Publication date
AU2001277773A1 (en) 2002-04-02
WO2002025878A1 (fr) 2002-03-28
US20020194361A1 (en) 2002-12-19
JP3662907B2 (ja) 2005-06-22
EP1235392A1 (en) 2002-08-28

Similar Documents

Publication Publication Date Title
JP3662907B2 (ja) データ送受信方法、送信装置、受信装置、送受信システム、およびプログラム
US9203886B2 (en) Content rate control for streaming media servers
US7039712B2 (en) Network connection setup procedure for traffic admission control and implicit network bandwidth reservation
KR100537499B1 (ko) 전송제어 파라미터 생성방법 및 프레임 특성에 따른선택적 자동 재전송 방법
US8081609B2 (en) Proxy-based signaling architecture for streaming media services in a wireless communication system
JP2008507204A (ja) 二方向メッセージングネットワークでゾーン間帯域を管理する方法
JP2012005087A (ja) データ伝送システム及び方法
Pyun et al. Wireless measurement based resource allocation for QoS provisioning over IEEE 802.11 wireless LAN
TWI801835B (zh) 往返估算
Hsiao et al. Streaming video over TCP with receiver-based delay control
Singhal et al. Survey on tcp friendly congestion control for unicast and multicast traffic
Arthur et al. The effects of packet reordering in a wireless multimedia environment
US20140003236A1 (en) System and Method for Dynamic Rate Adaptation Based on Real-Time Call Quality Metrics
Chung et al. Mtp a streaming friendly transport protocol
Baraskar Analysis of WebRTC's Google Congestion Control
Singh Protocols and Algorithms for Adaptive Multimedia Systems
El-Marakby et al. Evaluation of the Real-Time Transport Protocol (RTP) for Continuous Media Communications
Shih et al. A transparent loss recovery scheme using packet redirection for wireless video transmissions
Sathyanarayana Multipath Transport Protocols for Real Time Communication Systems
Papadimitriou et al. Assessment of Internet voice transport with TCP
Meng Delay-based Rate Control Algorithms for the Real-time Video Transmission Application
Singh Rate-control for conversational H. 264 video communication in heterogeneous networks
Hammi et al. Some experience on video flow regulation with an active network approach
Parejiya et al. INTERNATIONAL JOURNAL OF ENGINEERING SCIENCES & RESEARCH TECHNOLOGY MULTI-PATH MECHANISM FOR BROADCASTING AUDIO/VIDEO STREAMING BASED ON BANDWIDTH ESTIMATION
Schulzrinne Transport protocols for multimedia

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20040914

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20041110

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20050324

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees