JP2004112113A - リアルタイム通信の適応制御方法、受信報告パケットの連続消失に対する対策方法、受信報告パケットの送出間隔の動的決定装置、リアルタイム通信の適応制御装置、データ受信装置およびデータ配信装置 - Google Patents
リアルタイム通信の適応制御方法、受信報告パケットの連続消失に対する対策方法、受信報告パケットの送出間隔の動的決定装置、リアルタイム通信の適応制御装置、データ受信装置およびデータ配信装置 Download PDFInfo
- Publication number
- JP2004112113A JP2004112113A JP2002269238A JP2002269238A JP2004112113A JP 2004112113 A JP2004112113 A JP 2004112113A JP 2002269238 A JP2002269238 A JP 2002269238A JP 2002269238 A JP2002269238 A JP 2002269238A JP 2004112113 A JP2004112113 A JP 2004112113A
- Authority
- JP
- Japan
- Prior art keywords
- data
- transmission
- reception
- interval
- report packet
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
- H04L47/263—Rate modification at the source after receiving feedback
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- 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
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/10—Flow control between communication endpoints
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate
Abstract
【課題】データ配信を受ける側の装置が配信サーバーに向けて送出する受信報告パケットが消失する事態に対して対策し、伝送路の条件や通信条件に適応した適切なデータ配信を実現すること。
【解決手段】リアルタイムデータの送受信の開始前に、データ配信サーバー３０１とデータ受信装置１０１との間で、受信報告パケットの送出間隔の動的な取り決めを行う。そして、リアルタイムデータの送受信の開始後に、データ送配信サーバー３０１が、取り決められた送出間隔を単位として受信報告パケットの受信状況を監視し、その監視結果に基づいて、データ送信レート等を適応的に制御する。
【選択図】 図４
【解決手段】リアルタイムデータの送受信の開始前に、データ配信サーバー３０１とデータ受信装置１０１との間で、受信報告パケットの送出間隔の動的な取り決めを行う。そして、リアルタイムデータの送受信の開始後に、データ送配信サーバー３０１が、取り決められた送出間隔を単位として受信報告パケットの受信状況を監視し、その監視結果に基づいて、データ送信レート等を適応的に制御する。
【選択図】 図４
Description
【０００１】
【発明の属する技術分野】
本発明は、リアルタイム通信の適応制御方法、受信報告パケットの連続消失に対する対策方法、受信報告パケットの送出間隔の動的決定装置、リアルタイム通信の適応制御装置、データ受信装置およびデータ配信装置に関する。
【０００２】
【従来の技術】
インターネットや無線通信網などのパケット通信回線を通して、画像や音声などのディジタルデータ（マルチメディアデータ）を伝送し、ストリーミングアプリケーションを実行する場合、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で定められているＲＦＣ２３２６またはＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）等のプロトコルにしたがってデータをやり取りする。
【０００３】
ここで、ＲＴＳＰは、マルチメディアデータを再生するクライアントと、マルチメディアデータを保存し提供するサーバーとの間の通信手順や制御方法を定めたプロトコルである。
【０００４】
つまり、ＲＴＳＰによってセッションの開設、切断やメディアの再生要求を行う。ＲＴＳＰを用いたストリーミング制御コマンドの送受信には、現在Ｗｅｂ等によって広く用いられているＴＣＰ／ＩＰが用いられる。
【０００５】
音声や画像といった実際のメディアのデータにはＲＴＰ／ＵＤＰ／ＩＰが用いられることが多い。
【０００６】
次に、ＲＴＰ／ＵＤＰプロトコルについて説明する。
【０００７】
ＲＴＰ／ＵＤＰはリアルタイム用伝送プロトコルであり、音声、画像といったリアルタイムデータの送信に適している。その一方、ＴＣＰと異なりデータが完全に相手に受信されることを保証しない。
【０００８】
サーバーはＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）などの符号化方式で符号化された画像や音楽データをペイロードとして、パケット作成時刻やパケットの順序を表すシーケンス番号などを付与してＲＴＰパケットを構成しクライアントに送信する。
【０００９】
クライアントはサーバーから受信したＲＴＰパケットのペイロードから画像や音楽データを抽出し、再生したり保存したりする。
【００１０】
サーバーは、全てのマルチメディアデータの伝送を終了した場合や、通信を終了したい場合はセッション切断通知パケットをクライアントに送信し、セッションを切断して初期状態に戻る。パケット通信回線では、ネットワークの輻輳やビット誤りのため、パケットが受信できなかったり、正しく受信できなかったりすることがある。特に、重要なパケットが欠落すると画質や音質に著しい劣化を招くことになる。
【００１１】
ＲＴＰパケット中のシーケンス番号にはパケットが生成された順序が連続して記録されているので、この番号をパケット受信毎に確認し、番号の不連続が検出した時点で受信できなかったパケットが存在することを検出することが可能である。
【００１２】
これまで説明したように、ＲＴＰパケットを用いたメディア伝送では、パケットが欠落する可能性がある。サーバーにクライアントの受信状況を通知するため、クライアントはＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ、受信報告）パケットやフィードバックパケットと呼ばれるパケットを必要に応じてクライアントからサーバーに送信する。
【００１３】
このＲＲパケットには、主に、受信装置すなわちクライアントの受信統計情報が記載される。統計情報とは、ＲＴＰパケットロス数やＲＴＰパケット受信時刻のばらつきを表すジッタ等である。
【００１４】
また、サーバーからはクライアントに対して、ＳＲ（送信報告）パケットが送信される。これは、ＳＲとＲＲを使って往復時間を算出するのに用いられる。サーバーはＲＲを受信すると、ＲＲの統計情報によって送信条件を適応的に変化させることができる。
【００１５】
例えば、ＲＲの統計情報によって、伝送路が悪化したことが報告されれば、より低いビットレートのストリームに変更し、輻輳を悪化させることを防いだり、誤り耐性能力を高めて、パケットロスの影響を小さく抑える手段をとることができる。
【００１６】
従来のストリーミング技術におけるシーケンス例を図１１を用いて説明する。
【００１７】
ＳＴ１００１からＳＴ１００３はストリーミングを開始するまでの、ＲＴＳＰ制御コマンドの送受信である。
【００１８】
ＳＴ１００１では、サーバーが提供するメディアに関する情報（ビットレート等）をクライアントに通知する。
【００１９】
クライアントは前記メディアが受信かつ再生可能である場合は、セッション確立を要求する（ＳＴ１００２）。
【００２０】
セッション開設後、クライアントはサーバーに対し、メディアデータの送信を要求する（ＳＴ１００３）。
【００２１】
また、ＳＴ１００４はセッション切断要求及び応答である。ＳＴ１００３からＳＴ１００４の間、サーバーはＲＴＰパケットによるメディアデータの送信を行う。
【００２２】
次に、ＲＴＰパケットについて説明する。すべてのＲＴＰパケットは、ＳＮ＝１のようにＳＮ（順序番号）が付与されている。したがって、ネットワーク上で、ＲＴＰパケットが欠落したり、順序違いになったことをクライアントは知ることができる。
【００２３】
サーバーはメディアデータをＳＮ＝１のパケットから順にクライアントに送信する。サーバーは並行して、ＳＲパケットを定期的に送信する（ＳＲ１、ＳＲ２、ＳＲ３）。
【００２４】
クライアントは、メディアデータとＳＲパケットを受信し、パケット受信統計情報であるＲＲパケットを定期的にサーバーに送信する（ＲＲ１、ＲＲ２、ＲＲ３）。
【００２５】
サーバーは最後のメディアパケット（ＳＮ＝３０２）を送信後、ＢＹＥパケットと呼ばれるパケットを送信し、すべてのメディアパケットを送信終了したことを通知する。
【００２６】
クライアントはＢＹＥパケット受信後、ＲＴＳＰコマンド ＴＥＡＲＤＯＷＮをサーバーに要求し、セッションを切断する。
【００２７】
なお、ＳＮの初期値はランダムに付与されることになっているが、ここでは簡単にするため、初期値を１として説明した。
【００２８】
次に、無線網などのように、パケットが消失する確率が高い伝送路が途中に介在する場合の動作について説明する。
【００２９】
すでに説明したように、ＲＴＰプロトコルでは、相手にパケットが確実に受信されることは保証されない。
【００３０】
したがって、ＲＴＰパケットが正しく受信できない場合がある。例えば、ＳＮ＝２のＲＴＰパケットがロスした場合、データ受信装置はＳＮ＝３を受信するとＳＮ＝２のＲＴＰパケットがロスしたことがわかる。同様にサーバーはＲＲ１パケットが途中でロスした場合、ＲＲ２を受信するとＲＲ１が途中でロスしたことがわかる。
【００３１】
上述したように、マルチメディアデータの配信では、回線の輻輳に対する対策が重要であり、受信端末から受信状況（輻輳発生情報）をデータ配信サーバーに帰還させ、この帰還情報に基づいて、データ送信のレートを変更する等の適応制御を行う技術がある（下記の特許文献１，特許文献２を参照）。
【００３２】
【特許文献１】
特開平１１−２６１９８８号公報
【特許文献２】
特開２００１−１６０８２４号公報
【００３３】
【発明が解決しようとする課題】
上述の特許文献１，２に記載の技術では、受信端末からデータ配信サーバーに戻される受信状況情報（受信報告と同じ目的で使用されていると考えられる）が、サーバーに必ず届くということを前提としている。
【００３４】
したがって、受信端末は受信状況の報告を送出したが、伝送路の輻輳によって、サーバーに戻る途中で消失してしまったり、あるいは、受信端末が携帯端末であって、通信可能区域外になったり、電源がオフされて、もはや通信が不能となってしまった場合には、データ配信サーバーには制御の基礎となる情報が戻ってこないため、まったく対応することができない、という問題が生じる。
【００３５】
つまり、従来のサーバー装置およびクライアント装置においては、ＲＲパケット（受信報告パケット）が消失した場合、その消失したＲＲパケットの統計情報をサーバーを用いることができないので、サーバーは伝送路の悪化が報告されていてもすぐには応答できない。
【００３６】
また、連続してＲＲパケットが消失した場合には、サーバーでは、クライアントがＲＲパケットを送信していないのか、伝送路悪化のためにＲＲパケットが連続して消失したのか区別がつかない。
【００３７】
したがって、サーバーからクライアントに至る伝送路において輻輳が発生している場合であっても、サーバーはパケットを継続して送りつづけ、これにより、輻輳をますます悪化させるという事態が生じるおそれがある。
【００３８】
図１２のシーケンス図を用いて詳細に説明する。
【００３９】
ＳＴ２００１、ＳＴ２００２、ＳＴ２００３、ＳＴ２００４は、図１１と同じであるので説明を省略する。
【００４０】
図１２のシーケンス図では、ネットワークの輻輳または無線網の伝送誤り等の影響によって、いくつかのＲＴＰパケットやＲＴＣＰパケットが消失している。すなわち、ＳＮ＝１９９、２０２のＲＴＰパケットと、ＲＲ２、ＲＲ３のＲＲパケットである。
【００４１】
サーバーはＲＲ１を正しく受信するが、ＲＲ２、ＲＲ３を消失のため受信できない。ＲＲ２やＲＲ３ではそれぞれＳＮ＝１９９、ＳＮ２０２の消失によって生じるパケット廃棄数に関する情報が記載されている。
【００４２】
本来ＲＲ２、ＲＲ３を受信していれば、サーバーはＲＴＰパケットの送出レートを減じる等の処理を行い、さらなる輻輳を防ぐが、ＲＲ２、ＲＲ３が消失したためこれらの処理が一切行えない。
【００４３】
本発明はこのような不都合を考慮してなされたものであり、その目的は、データの配信を受ける側の装置から送出される受信報告パケットが消失してしまうことに対して対策を施し、伝送路の条件や通信条件に適応した適切なデータ配信を実現することにある。
【００４４】
【課題を解決するための手段】
本発明のリアルタイム通信の適応制御方法では、リアルタイムデータの送受信の開始前に、データ送信装置とデータ受信装置との間で、受信報告パケットの送出間隔の取り決めを行い、リアルタイムデータの送受信の開始後に、データ送信装置が、取り決められた前記送出間隔を単位として、前記受信報告パケットの受信状況を監視し、その監視結果に基づいて、データ送信を適応的に制御する。
【００４５】
すなわち、セッション確立時の制御信号を利用するなどして、受信報告パケットの送出間隔を動的に決定し、この間隔で周期的に必ず１回受信報告を行うこと（固定間隔の場合）、あるいは、その間隔内に少なくとも１回は受信報告を行うこと（許容最大間隔の場合）を、データ受信装置に義務付ける。
【００４６】
これにより、データ送信装置は、その間隔を単位とした受信報告パケットの消失状況の監視と、その監視に基づく伝送路や通信の状況の推定が可能となり、適応的なデータ送信の制御を行える。すなわち、ＲＴＰ送出レートを調節することによって輻輳を防ぐことができ、また、データ受信装置が通信不能になってセッションが切断されたと考えられる場合には、ＲＴＰ送出を終了させて無駄なデータを送信することを防ぐことができる。
【００４７】
受信報告パケットの送出間隔の取り決めに際しては、通信の確実を期すべく、信頼性の高いコネクション型のプロトコル（ＴＣＰなど）を用いた転送方式を採用するのが望ましい。
【００４８】
本発明により、受信報告パケットの連続消失に対する対策が可能となる。
【００４９】
また、本発明の受信報告パケットの送出間隔の動的決定装置は、リアルタイム通信における受信報告パケットの送出間隔を動的に決定する送出間隔決定部と、決定された送出間隔を、信頼性の高いコネクション型の転送方式により通信先の装置に送信する送信部と、を有する。
【００５０】
また、本発明のリアルタイム通信の適応制御装置は、受信報告パケットの送出間隔の動的決定装置により決定された送出間隔を単位として、リアルタイムデータの送受信の開始後に、前記受信報告パケットの受信状況を監視する監視部と、その監視結果に基づいて、データの配信を適応的に制御する適応制御部と、を有する。
【００５１】
このような、受信報告パケットの送出間隔の動的決定装置やリアルタイム通信の適応制御装置を、データ配信サーバーやデータ受信端末に設けたり、あるいは通信伝送路上に個別に設けることにより、受信報告パケットの消失という事態も考慮した、回線の輻輳制御や配信データのＱｏＳ制御が可能となる。
【００５２】
また、本発明のデータ受信装置は、受信報告パケットの送出間隔を決定する送出間隔決定部と、決定された送出間隔の情報を、コネクション型の通信プロトコルを用いて通信先に通知することができる制御情報送受信部と、受信報告パケット生成部と、受信報告パケットを、前記送出間隔内で少なくとも１回送出する受信報告パケット送出部と、を具備する。
【００５３】
また、本発明のデータ配信装置は、配信先の装置から通知された、あるいは、自ら決定した受信報告パケットの送出間隔の経過を計測するタイマーと、送出間隔内、あるいはその送出間隔に伝送路の遅延時間を加えた間隔内において受信報告パケットが受信されない回数をカウントするカウンタと、そのカウンタのカウント値を、一または二以上のしきい値と比較し、その比較結果に応じて、前記メディアデータの送信レートを減じる、あるいは、セッションを切断するリアルタイム通信の適応制御部と、を有する。
【００５４】
装置の構成が簡易であり、ＲＴＰ（リアルタイム・プロトコル）の少しの改良により対応できるため、本発明の方法を実施するのは容易である。
【００５５】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照して説明する。
【００５６】
なお、本明細書で使用される「リアルタイムデータ」は、リアルタイム性が要求されるデータのことであり、音声データや映像データを示すメディアデータ（あるいはマルチメディアデータ）と同義語として使用する。
【００５７】
（実施の形態１）
本実施の形態では、データ受信装置が、受信報告をサーバーに送信する固定間隔あるいは許容最大間隔を決定し、信頼性のある伝送方式によって、その間隔の情報をサーバーに通知し、サーバー側で受信報告パケットの消失状況を監視し、その監視結果に基づいて、データ配信を適応制御する。
【００５８】
本実施の形態では、図１に示すような有線通信網と無線通信網を組み合わせたデータ配信システムにおいて、本発明の方法を実施することを想定する。
【００５９】
図１に示すように、移動局５０が、配信サーバー１０から、マルチメディアデータ（画像データや音声データ）の配信を受ける。配信されるマルチメディアデータは、有線ネットワーク２０、ゲートウエイ３０、無線基地局４０を介して移動局５０に送信される。
【００６０】
移動局５０として、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｃｅ）等の携帯端末、携帯電話機、あるいはパーソナルコンピュータが想定される。無線通信の通信状態は受信環境により大きな影響を受けるため、回線の輻輳が発生しやすく、また、通信データの誤り率の増大によって受信信号の品質が低下するおそれがあり、また、電波の届きにくい場所への移動による回線の切断の可能性もある。
【００６１】
移動局５０から配信サーバー１０に向けて送出する受信報告パケットが途中で消失する事態が発生しているにもかかわらず、配信サーバー１０が適応制御を行うことなくデータを送信しつづけると、回線の負担が、ますます重くなってしまう。
【００６２】
よって、本発明の方法による、受信パケットの送出間隔の動的決定を利用したデータ配信の適応制御が有効である。
【００６３】
移動局５０と基地局４０との間の無線通信方式は特に限定されるものではなく、ＣＤＭＡ方式やＧＳＭ方式など、種々、利用することができる。Ｗ−ＣＤＭＡ方式では、マルチメディアデータのリアルタイム配信が可能であるため、本発明の適用が効果的である。
【００６４】
図２は、マルチメディアデータの送受信に用いられるプロトコルスタックを説明するための図である。
【００６５】
図示されるように、ＲＴＰ（リアルタイム・プロトコル）とＵＤＰ（ユーザー・データグラム・プロトコル）がセットになって、トランスポート層のプロトコルを構成する。なお、通信ネットワークＣＮを介してリアルタイム・マルチメディア通信を実現するためには、ＲＴＳＰやＳＤＰといったプロトコルが必要となる。
【００６６】
ネットワーク層のプロトコルとしては、ＩＰ（インターネット・プロトコル）が用いられる。
【００６７】
本発明は、特に、ＲＴＰプロトコルに改良を加えて、受信報告パケットの消失という事態にも対応できるようにするものである。
【００６８】
本発明のマルチメディア・リアルタイム通信における適応制御の主な手順をまとめると、図３に示すようになる。
【００６９】
すなわち、データ配信サーバーと受信端末との間で、受信報告パケットの送信間隔（固定間隔、あるいは許容される最大の間隔）を動的に設定する（ステップ６０）。
【００７０】
次に、データ配信サーバーが、受信端末から送られてくる受信報告パケットの、設定された時間間隔を単位とした受信状況を監視する（ステップ７０）。
【００７１】
次に、受信報告パケットが受信されない回数を、一または二以上のしきい値と比較して、その比較結果に応じて、データ送出レートの変更やセッションの終了等の適応制御を行う（ステップ８０）。
【００７２】
以下、本発明の実施の形態について図面を参照して、より具体的に説明する。
【００７３】
図４は、ストリーミングデータを送受信するデータ配信サーバー／データ受信装置の構成を示すブロック図である。
【００７４】
データ配信サーバー３０１とデータ受信装置１０１は、通信ネットワーク２００を介して、双方向の通信を行う。
【００７５】
まず、データ受信装置（図４の下側に示される）１０１の構成と動作について説明する。
【００７６】
制御情報送受信手段１０２はストリーミングのセットアップ、スタート、ストップ等制御情報を送受信する。
【００７７】
ＴＣＰ送受信手段１０３は、信頼性のある伝送方式であるＴＣＰを用いてインターネットや無線網等のネットワークを通じサーバーと送受信を行う。
【００７８】
ＵＤＰ送受信手段１０９は、非信頼性伝送方式であるＵＤＰを用いてインターネットや無線網等のネットワークを通じサーバーと送受信を行う。
【００７９】
ＲＴＰ受信手段１０８は、サーバーから送信されるメディアデータを受信する。メディア再生手段は、１０８で受信されたＲＴＰパケットに格納されている音声または映像であるメディアデータを再生する。
【００８０】
受信報告パケット生成手段１０５は受信したＲＴＰパケットを監視し、パケット損失や受信時刻のゆらぎを計測し、受信報告パケットを生成する。
【００８１】
ＲＴＣＰ送受信手段１０７は、サーバーから送信される送信報告パケット等を受信し、受信報告パケット生成手段１０５で生成される受信報告パケット等をサーバーに送信する。
【００８２】
受信報告送信間隔決定手段１０４は、受信報告をサーバーに送る一定の送信間隔または許容される最大間隔を決定し、制御情報送受信手段１０２を通じてサーバーに通知すると同時に、決定された間隔を、受信報告パケット生成手段１０５に指示する。
【００８３】
ここで、受信報告パケットの送信間隔を固定とした場合には、その間隔毎に、周期的に、受信報告パケットを送出することがデータ受信装置１０１に義務付けられる。
【００８４】
また、許容最大間隔を用いる場合には、その間隔内のいずれのタイミングでもかまわないが、少なくとも１回の受信報告パケットの送出が、データ受信装置１０１に義務付けされる。
【００８５】
どちらの間隔を用いてもよいが、許容最大間隔を用いる場合には、受信報告パケットの送信タイミングの自由度が高いというメリットがある。
【００８６】
なお、以下の説明では、固定された受信報告送信間隔のパラメータ名として、“ｔｒｒ−ｆｉｘｅｄ−ｉｎｔ”を用いる。また、許容最大受信報告送信間隔のパラメータ名として、“ｔｒｒ−ｍａｘ−ｉｎｔ”を用いる。
【００８７】
次に、データ受信装置１０１の動作について、図５を用いて説明する。
【００８８】
図５は、クライアント１０１の動作を示すシーケンス図である。
【００８９】
従来の動作と同じように、ＳＴ４００１、ＳＴ４００２によってセッションのセットアップを完了する。次に、クライアントにより決定された受信報告パケットを送信する間隔（受信報告送信間隔）をサーバーに送信する。
【００９０】
具体的には、受信報告送信間隔（ここでは、最大許容間隔を用いることとする）のパラメータ名である、ｔｒｒ−ｍａｘ−ｉｎｔ を指定したＲＴＳＰ制御メッセージのＳＥＴ＿ＰＡＲＡＭＥＴＥＲ要求をクライアントからサーバーに送信する。上述のように、ｔｒｒ−ｆｉｘｅｄ−ｉｎｔをパラメータとして用いる（つまり、固定間隔を用いる）ことも可能である。
【００９１】
この場合、「ｔｒｒ−ｍａｘ−ｉｎｔ ＝ ５０００」と指定しているので、クライアントはサーバーに対し、５０００ｍｓ ＝ ５ｓｅｃ 毎に必ず１回受信報告を送ることを通知することになる。
【００９２】
次に、図４の上側に示される、メディアデータの配信サーバー３０１の構成と動作を説明する。
【００９３】
図４に示されるように、制御情報送受信手段３０２は、データ受信装置から要求されるストリーミングのセットアップ、スタート、ストップ等制御情報を送受信する。
【００９４】
ＴＣＰ送受信手段３０３は、信頼性のある伝送方式であるＴＣＰを用いてインターネットや無線網等のネットワークを通じデータ受信装置と送受信を行う。
【００９５】
ＵＤＰ送受信手段３０９は、非信頼性伝送方式であるＵＤＰを用いてインターネットや無線網等のネットワークを通じデータ受信装置と送受信を行う。
【００９６】
ＲＴＰ送信手段３０８は、データ受信装置に対しメディアデータを送信する。メディア格納手段は、３０８で送信するための音声または映像であるメディアデータを格納する。送信報告パケット生成手段３０５はサーバーとデータ受信装置とのデータ往復時間の計測等を行い、送信報告パケットを生成する。
【００９７】
ＲＴＣＰ送受信手段３０７は、データ受信装置から送信される受信報告パケット等を受信し、送信報告パケット生成手段３０５で生成される送信報告パケットをデータ受信装置に送信する。
【００９８】
タイマー３１０は制御情報送受信手段３０２から入力される受信報告送信間隔にジッタを考慮したαを加算した値（β）をセットし、βの間受信報告パケットが受信されない場合は、カウンタ３１１に出力する。
【００９９】
すなわち、このタイマー３１０は、所定間隔内に受信報告パケットが到着したか否かの判定を行う判定手段としても機能する。
【０１００】
なお、最大許容間隔を用いる場合だけなく固定間隔を用いる場合でも、結果的には、その間隔内に受信報告パケットが到着したか否かの判定を行えばよい点で共通するため、どちらの間隔を用いるかにかかわらず、図４に記載される構成によって判定が可能である。
【０１０１】
カウンタ３１１はタイマー３１０からの入力があった場合は１増分する。送出レート調節手段３１２はカウンタがある一定値に達した場合にカウンタから送出レート減少指示が入力され、ＲＴＰパケットの送出レートを減じる。
【０１０２】
セッション切断手段３１３、カウンタの値がさらに大きい一定値に達した場合にカウンタからＲＴＰパケットの送信終了指示が入力され、ＲＴＰパケット送出を終了し、セッションを終了する。
【０１０３】
次に、メディアデータの配信サーバー３０１の動作について、図６を用いて説明する。
【０１０４】
ＳＴ１０００１では、ＳＥＴＵＰ要求をクライアントから受信し、応答（ＯＫ）を送信する。
【０１０５】
続いてＳＥＴ＿ＰＡＲＡＭＥＴＥＲ要求を受信し、ｔｒｒ−ｍａｘ−ｉｎｔ をクライアントから指定された値（５０００ｍｓ）にセットする（ＳＴ１０００２）。ＰＬＡＹ要求を受信し、応答（ＯＫ）を送信した後、クライアントに対しメディアデータを含むＲＴＰパケットの送信を開始する（ＳＴ１０００３）。
【０１０６】
サーバーはＲＴＰパケット送出開始後、クライアントから初めて受信報告パケットを受信する（ＳＴ１０００４）。カウンタを０にセットする（ＳＴ１０００５）。
【０１０７】
タイマーを０にセットし、タイマーをスタートさせる（ＳＴ１０００６）。次に受信報告パケットを受信したかどうか監視し（ＳＴ１０００７）、受信報告パケットを受信した場合は、受信したＲＲパケットに含まれる情報に基づいて送出レートを調整した後（ＳＴ１００１５）、ＳＴ１０００５の処理に戻る。
【０１０８】
ＳＴ１０００７で受信報告パケットを受信しない場合は、ＳＴ１０００８の処理に進む。１ｍｓに１だけ進むタイマーの値 ｔとｔｒｒ−ｍａｘ−ｉｎｔ にＲＴＰパケット受信時刻のばらつきを表すジッタを考慮してαを足した値ｔｒｒ−ｍａｘ−ｉｎｔ ＋ αとの大小を比較する（ＳＴ１０００８）。
【０１０９】
ｔの方が小さければＳＴ１０００７に戻り受信報告パケットの受信を監視し、ｔの方が大きければ受信報告パケットが途中で消失した、あるいは、誤り率が増大した、あるいは未送信と判定し、ＳＴ１０００９に進む。
【０１１０】
ＳＴ１０００９では受信報告パケットが連続して未受信である数を表すカウンタを１増分する。
【０１１１】
そして、ＳＴ１００１０では、カウンタが、例えば、“５”かどうか判定する。すなわち、受信報告パケットの未受信が５回に達しているかを判定する。そして、“５”でない場合は、ＳＴ１０００６に戻り、“５”であれば、現在の送出レートが最小かを判定する（ＳＴ１００１１）。送出レートは段階的に制御されるが、現在のレートが最低のレートであるときは、送出レートをそれ以下とすることはできないから、ＳＴ１００１１における判定がイエスの場合には、ＲＴＰパケットの送出を終了する（ＳＴ１００１４）。
【０１１２】
ＳＴ１００１２ではカウンタが、例えば、“１０”かどうか判定する。“１０”でなければ、クライアントとのセッションは継続されているが、輻輳等の要因によって受信報告パケットが消失したと判定し、ＲＴＰパケットの送出レートを減じることによって、輻輳を悪化させることを防ぐ（ＳＴ１００１３）。
【０１１３】
“１０”であれば、例えば、クライアントが電源を切断した等の要因によって、クライアントとのセッションが一方的に切断されたと判定し、ＲＴＰパケットの送出を終了する（ＳＴ１００１４）。
【０１１４】
ここで、カウンタが増加する仕組みを図５を用いて説明する。
【０１１５】
ＳＴ４００１−ＳＴ４００４は同一であるから説明を省略する。サーバーでは、ＲＲ１を受信後、タイマーが動作する。
【０１１６】
サーバータイマー値には次の式によって定まるβを用いる（β＝あらかじめ通知された受信報告送信間隔＋α）。
【０１１７】
サーバーはβ時間経過ｋしてもＲＲを受信しない場合、カウンタを１増分しカウンタ＝１となる。そのままＲＲを受信しないまま、さらにβ経過するとカウンタがさらに１増分されカウンタ＝２となる。
【０１１８】
ここで、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲで通知するメッセージについて図７を用いて説明する。
【０１１９】
ＳＥＴ＿ＰＡＲＡＭＥＴＥＲで始まる行はＳＥＴ＿ＰＡＲＡＭＥＴＥＲ要求をｒｔｓｐ：／／で指定されたＵＲＬに送信することを表す。ＣＳｅｑ はシーケンス番号であり、ＲＴＳＰセッションでＲＴＳＰメッセージが交換されるたびに１増加される。Ｓｅｓｓｉｏｎは、あるＲＴＳＰセッションを識別するための識別番号である。
【０１２０】
以上はＲＴＳＰヘッダであり、次に１行空行を空けて本文が開始される。本文には、ｔｒｒ−ｍａｘ−ｉｎｔ＝５０００を記述し、サーバーに対して受信報告送信間隔を通知する。
【０１２１】
サーバーはその通知を受信すると、図８に示されるように、ＯＫを返信する。
【０１２２】
なお、本実施の形態においては、受信報告送信間隔を５０００ｍｓの固定値として説明したが、これに限定されるものではない。
【０１２３】
また、上述したように、受信報告送信間隔内において１回は受信報告パケットを送信する最大間隔を指定するのではなく、受信報告送信間隔毎に必ず１回受信報告パケットを送信する固定間隔を指定してもよい。
【０１２４】
（実施の形態２）
本実施の形態では、データ配信サーバーが、受信パケットの送出間隔を決定し、信頼性のある伝送方式によって、その決定された間隔の情報をデータ受信装置に通知する。
【０１２５】
図９は、メディアデータの送信サーバー／データ受信装置の構成を示すブロック図である。
【０１２６】
基本的には、前掲の実施の形態における構成（図４）と同じであり、重複する説明は省略する。
【０１２７】
つまり、図９の下側に示されるデータ受信装置１０１では、受信報告送信間隔決定手段２０４以外は、図４と同じ構成であるので説明を省略する。
【０１２８】
受信報告送信間隔決定手段２０４へは制御情報送受信手段２０２を通じてデータ配信サーバー３０１より受信した受信報告送信間隔の情報が入力される。そして、その受信報告送信間隔に従って、データ受信装置１０１は、受信報告パケット（受信状況を報告するための情報ならば、パケット形式であるか否かは問わない）をデータ配信サーバー３０１に送信する。
【０１２９】
また、図９の上側に示されるデータ配信サーバー３０１においては、受信報告送信間隔決定手段３０４が、データ受信端末がサーバーに受信報告を送信する間隔を決定する。
【０１３０】
そして、制御情報送受信手段３０２に指示してデータ受信装置１０１に、決定された受信報告パケットの送出間隔を送信させ、これと同時に、タイマー３１０を動作させる。
【０１３１】
以上の説明では、リアルタイム通信のプロトコルとしてＲＴＳＰを用いて送出間隔を通知する例について説明したが、プロトコルとしてＳＤＰを用いた場合も同様の構成に、同様の効果を得ることができる。
【０１３２】
図１０は、ＳＤＰ（ＲＦＣ２３２７で規定）に準拠したメディア情報の記述の一例を示す図である。
【０１３３】
従来の記述に対し、「ａ＝ｔｒｒ−ｍａｘ−ｉｎｔ：５０００」が、音声、映像情報のそれぞれに付与され、データ受信装置に送信される。このように、本発明では、基本的には、プロトコルの記述を追加するだけでよく、実現が容易である。
【０１３４】
なお、本発明はストリーミングだけでなく、パケットベース音声通話やパケットベースＴＶ会議にも適用可能である。したがって、本発明のデータ配信装置、データ受信装置は、ＳＩＰまたはＨ．３２３等のパケットベース音声通話端末やパケットベースＴＶ会議端末として利用可能である。
【０１３５】
すなわち、本発明はストリーミングデータの配信だけでなく、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）といった音声通話等にも利用可能である。なお、ＳＩＰ／Ｈ．３２３はパケット通信により、音声通話やＴＶ会議を実現する規格名である。
【０１３６】
【発明の効果】
以上説明したように、本発明によれば、輻輳の発生するネットワークや伝送誤りの発生する無線網等を通じて音声や映像データを送受信する場合、データ受信装置から送信される受信報告の間隔がセッションにより一意に決められており、信頼性のある伝送方式で、サーバーまたはデータ受信装置に送信されるので、サーバーは受信報告の間隔を用いて、セッションが切断された場合には迅速にセッションを切断することができ、伝送路の状況が悪化している場合には迅速にパケット送出レートを減じることにより輻輳を悪化させることを防ぐことができる。
【０１３７】
こにれより、柔軟な輻輳制御を行うことができ、回線の混雑を未然に回避することにも役立ち、このことは、結果的に、配信データのＱｏＳ（サービス品質）を高めることに貢献する。
【図面の簡単な説明】
【図１】マルチメディアデータの配信システム（リアルタイム・データ通信システム）の構成を示すブロック図
【図２】マルチメディア通信（リアルタイム通信）を行う場合の、プロトコルスタックについて説明するための図
【図３】マルチメディア・リアルタイム通信における、本発明の適応制御の主要な手順を示すフロー図
【図４】データ送信サーバー／データ受信装置の構成の一例を示すブロック図
【図５】図４における受信データ装置の動作（データ受信装置において受信報告パケットの送出間隔を決定する場合の具体的な動作）を説明するためのシーケンス図
【図６】図４におけるサーバー側の動作を説明するためのフロー図
【図７】データ受信装置からサーバーへのＲＴＳＰメッセージの内容の一例を示す図
【図８】サーバーからデータ受信装置へのＲＴＳＰ応答の内容の一例を示す図
【図９】データ送信サーバー／データ受信装置の構成の他の例を示すブロック図
【図１０】ＳＤＰ（ＲＦＣ２３２７で規定）に準拠したメディア情報の記述の一例を示す図
【図１１】リアルタイム通信の手順の一例を説明するためのシーケンス図
【図１２】輻輳や伝送誤りのあるネットワーク上でメディア配信を行う場合の手順の一例を示すシーケンス図
【符号の説明】
１０ 配信サーバー
２０ 有線ネットワーク
３０ ゲートウエイ装置
４０ 基地局
５０ 移動局
１０１ データ受信装置
１０２ 制御情報送受信手段
１０３ ＴＣＰ送受信手段
１０４ 受信報告送信間隔決定手段
１０５ 受信報告パケット生成手段
１０６ メディア再生手段
１０７ ＲＴＣＰ送受信手段
１０８ ＲＴＰ受信手段
１０９ ＵＤＰ送受信手段
２００ 通信ネットワーク
３０１ サーバー
３０２ 制御情報送受信手段
３０３ ＴＣＰ送受信手段
３０５ 送信報告パケット生成手段
３０６ メディア格納手段
３０７ ＲＴＣＰ送受信手段
３０８ ＲＴＰ送信手段
３０９ ＵＤＰ送受信手段
３１０ タイマー
３１１ カウンタ
３１２ 送出レート調整手段
３１３ セッション切断手段
【発明の属する技術分野】
本発明は、リアルタイム通信の適応制御方法、受信報告パケットの連続消失に対する対策方法、受信報告パケットの送出間隔の動的決定装置、リアルタイム通信の適応制御装置、データ受信装置およびデータ配信装置に関する。
【０００２】
【従来の技術】
インターネットや無線通信網などのパケット通信回線を通して、画像や音声などのディジタルデータ（マルチメディアデータ）を伝送し、ストリーミングアプリケーションを実行する場合、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で定められているＲＦＣ２３２６またはＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）等のプロトコルにしたがってデータをやり取りする。
【０００３】
ここで、ＲＴＳＰは、マルチメディアデータを再生するクライアントと、マルチメディアデータを保存し提供するサーバーとの間の通信手順や制御方法を定めたプロトコルである。
【０００４】
つまり、ＲＴＳＰによってセッションの開設、切断やメディアの再生要求を行う。ＲＴＳＰを用いたストリーミング制御コマンドの送受信には、現在Ｗｅｂ等によって広く用いられているＴＣＰ／ＩＰが用いられる。
【０００５】
音声や画像といった実際のメディアのデータにはＲＴＰ／ＵＤＰ／ＩＰが用いられることが多い。
【０００６】
次に、ＲＴＰ／ＵＤＰプロトコルについて説明する。
【０００７】
ＲＴＰ／ＵＤＰはリアルタイム用伝送プロトコルであり、音声、画像といったリアルタイムデータの送信に適している。その一方、ＴＣＰと異なりデータが完全に相手に受信されることを保証しない。
【０００８】
サーバーはＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）などの符号化方式で符号化された画像や音楽データをペイロードとして、パケット作成時刻やパケットの順序を表すシーケンス番号などを付与してＲＴＰパケットを構成しクライアントに送信する。
【０００９】
クライアントはサーバーから受信したＲＴＰパケットのペイロードから画像や音楽データを抽出し、再生したり保存したりする。
【００１０】
サーバーは、全てのマルチメディアデータの伝送を終了した場合や、通信を終了したい場合はセッション切断通知パケットをクライアントに送信し、セッションを切断して初期状態に戻る。パケット通信回線では、ネットワークの輻輳やビット誤りのため、パケットが受信できなかったり、正しく受信できなかったりすることがある。特に、重要なパケットが欠落すると画質や音質に著しい劣化を招くことになる。
【００１１】
ＲＴＰパケット中のシーケンス番号にはパケットが生成された順序が連続して記録されているので、この番号をパケット受信毎に確認し、番号の不連続が検出した時点で受信できなかったパケットが存在することを検出することが可能である。
【００１２】
これまで説明したように、ＲＴＰパケットを用いたメディア伝送では、パケットが欠落する可能性がある。サーバーにクライアントの受信状況を通知するため、クライアントはＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ、受信報告）パケットやフィードバックパケットと呼ばれるパケットを必要に応じてクライアントからサーバーに送信する。
【００１３】
このＲＲパケットには、主に、受信装置すなわちクライアントの受信統計情報が記載される。統計情報とは、ＲＴＰパケットロス数やＲＴＰパケット受信時刻のばらつきを表すジッタ等である。
【００１４】
また、サーバーからはクライアントに対して、ＳＲ（送信報告）パケットが送信される。これは、ＳＲとＲＲを使って往復時間を算出するのに用いられる。サーバーはＲＲを受信すると、ＲＲの統計情報によって送信条件を適応的に変化させることができる。
【００１５】
例えば、ＲＲの統計情報によって、伝送路が悪化したことが報告されれば、より低いビットレートのストリームに変更し、輻輳を悪化させることを防いだり、誤り耐性能力を高めて、パケットロスの影響を小さく抑える手段をとることができる。
【００１６】
従来のストリーミング技術におけるシーケンス例を図１１を用いて説明する。
【００１７】
ＳＴ１００１からＳＴ１００３はストリーミングを開始するまでの、ＲＴＳＰ制御コマンドの送受信である。
【００１８】
ＳＴ１００１では、サーバーが提供するメディアに関する情報（ビットレート等）をクライアントに通知する。
【００１９】
クライアントは前記メディアが受信かつ再生可能である場合は、セッション確立を要求する（ＳＴ１００２）。
【００２０】
セッション開設後、クライアントはサーバーに対し、メディアデータの送信を要求する（ＳＴ１００３）。
【００２１】
また、ＳＴ１００４はセッション切断要求及び応答である。ＳＴ１００３からＳＴ１００４の間、サーバーはＲＴＰパケットによるメディアデータの送信を行う。
【００２２】
次に、ＲＴＰパケットについて説明する。すべてのＲＴＰパケットは、ＳＮ＝１のようにＳＮ（順序番号）が付与されている。したがって、ネットワーク上で、ＲＴＰパケットが欠落したり、順序違いになったことをクライアントは知ることができる。
【００２３】
サーバーはメディアデータをＳＮ＝１のパケットから順にクライアントに送信する。サーバーは並行して、ＳＲパケットを定期的に送信する（ＳＲ１、ＳＲ２、ＳＲ３）。
【００２４】
クライアントは、メディアデータとＳＲパケットを受信し、パケット受信統計情報であるＲＲパケットを定期的にサーバーに送信する（ＲＲ１、ＲＲ２、ＲＲ３）。
【００２５】
サーバーは最後のメディアパケット（ＳＮ＝３０２）を送信後、ＢＹＥパケットと呼ばれるパケットを送信し、すべてのメディアパケットを送信終了したことを通知する。
【００２６】
クライアントはＢＹＥパケット受信後、ＲＴＳＰコマンド ＴＥＡＲＤＯＷＮをサーバーに要求し、セッションを切断する。
【００２７】
なお、ＳＮの初期値はランダムに付与されることになっているが、ここでは簡単にするため、初期値を１として説明した。
【００２８】
次に、無線網などのように、パケットが消失する確率が高い伝送路が途中に介在する場合の動作について説明する。
【００２９】
すでに説明したように、ＲＴＰプロトコルでは、相手にパケットが確実に受信されることは保証されない。
【００３０】
したがって、ＲＴＰパケットが正しく受信できない場合がある。例えば、ＳＮ＝２のＲＴＰパケットがロスした場合、データ受信装置はＳＮ＝３を受信するとＳＮ＝２のＲＴＰパケットがロスしたことがわかる。同様にサーバーはＲＲ１パケットが途中でロスした場合、ＲＲ２を受信するとＲＲ１が途中でロスしたことがわかる。
【００３１】
上述したように、マルチメディアデータの配信では、回線の輻輳に対する対策が重要であり、受信端末から受信状況（輻輳発生情報）をデータ配信サーバーに帰還させ、この帰還情報に基づいて、データ送信のレートを変更する等の適応制御を行う技術がある（下記の特許文献１，特許文献２を参照）。
【００３２】
【特許文献１】
特開平１１−２６１９８８号公報
【特許文献２】
特開２００１−１６０８２４号公報
【００３３】
【発明が解決しようとする課題】
上述の特許文献１，２に記載の技術では、受信端末からデータ配信サーバーに戻される受信状況情報（受信報告と同じ目的で使用されていると考えられる）が、サーバーに必ず届くということを前提としている。
【００３４】
したがって、受信端末は受信状況の報告を送出したが、伝送路の輻輳によって、サーバーに戻る途中で消失してしまったり、あるいは、受信端末が携帯端末であって、通信可能区域外になったり、電源がオフされて、もはや通信が不能となってしまった場合には、データ配信サーバーには制御の基礎となる情報が戻ってこないため、まったく対応することができない、という問題が生じる。
【００３５】
つまり、従来のサーバー装置およびクライアント装置においては、ＲＲパケット（受信報告パケット）が消失した場合、その消失したＲＲパケットの統計情報をサーバーを用いることができないので、サーバーは伝送路の悪化が報告されていてもすぐには応答できない。
【００３６】
また、連続してＲＲパケットが消失した場合には、サーバーでは、クライアントがＲＲパケットを送信していないのか、伝送路悪化のためにＲＲパケットが連続して消失したのか区別がつかない。
【００３７】
したがって、サーバーからクライアントに至る伝送路において輻輳が発生している場合であっても、サーバーはパケットを継続して送りつづけ、これにより、輻輳をますます悪化させるという事態が生じるおそれがある。
【００３８】
図１２のシーケンス図を用いて詳細に説明する。
【００３９】
ＳＴ２００１、ＳＴ２００２、ＳＴ２００３、ＳＴ２００４は、図１１と同じであるので説明を省略する。
【００４０】
図１２のシーケンス図では、ネットワークの輻輳または無線網の伝送誤り等の影響によって、いくつかのＲＴＰパケットやＲＴＣＰパケットが消失している。すなわち、ＳＮ＝１９９、２０２のＲＴＰパケットと、ＲＲ２、ＲＲ３のＲＲパケットである。
【００４１】
サーバーはＲＲ１を正しく受信するが、ＲＲ２、ＲＲ３を消失のため受信できない。ＲＲ２やＲＲ３ではそれぞれＳＮ＝１９９、ＳＮ２０２の消失によって生じるパケット廃棄数に関する情報が記載されている。
【００４２】
本来ＲＲ２、ＲＲ３を受信していれば、サーバーはＲＴＰパケットの送出レートを減じる等の処理を行い、さらなる輻輳を防ぐが、ＲＲ２、ＲＲ３が消失したためこれらの処理が一切行えない。
【００４３】
本発明はこのような不都合を考慮してなされたものであり、その目的は、データの配信を受ける側の装置から送出される受信報告パケットが消失してしまうことに対して対策を施し、伝送路の条件や通信条件に適応した適切なデータ配信を実現することにある。
【００４４】
【課題を解決するための手段】
本発明のリアルタイム通信の適応制御方法では、リアルタイムデータの送受信の開始前に、データ送信装置とデータ受信装置との間で、受信報告パケットの送出間隔の取り決めを行い、リアルタイムデータの送受信の開始後に、データ送信装置が、取り決められた前記送出間隔を単位として、前記受信報告パケットの受信状況を監視し、その監視結果に基づいて、データ送信を適応的に制御する。
【００４５】
すなわち、セッション確立時の制御信号を利用するなどして、受信報告パケットの送出間隔を動的に決定し、この間隔で周期的に必ず１回受信報告を行うこと（固定間隔の場合）、あるいは、その間隔内に少なくとも１回は受信報告を行うこと（許容最大間隔の場合）を、データ受信装置に義務付ける。
【００４６】
これにより、データ送信装置は、その間隔を単位とした受信報告パケットの消失状況の監視と、その監視に基づく伝送路や通信の状況の推定が可能となり、適応的なデータ送信の制御を行える。すなわち、ＲＴＰ送出レートを調節することによって輻輳を防ぐことができ、また、データ受信装置が通信不能になってセッションが切断されたと考えられる場合には、ＲＴＰ送出を終了させて無駄なデータを送信することを防ぐことができる。
【００４７】
受信報告パケットの送出間隔の取り決めに際しては、通信の確実を期すべく、信頼性の高いコネクション型のプロトコル（ＴＣＰなど）を用いた転送方式を採用するのが望ましい。
【００４８】
本発明により、受信報告パケットの連続消失に対する対策が可能となる。
【００４９】
また、本発明の受信報告パケットの送出間隔の動的決定装置は、リアルタイム通信における受信報告パケットの送出間隔を動的に決定する送出間隔決定部と、決定された送出間隔を、信頼性の高いコネクション型の転送方式により通信先の装置に送信する送信部と、を有する。
【００５０】
また、本発明のリアルタイム通信の適応制御装置は、受信報告パケットの送出間隔の動的決定装置により決定された送出間隔を単位として、リアルタイムデータの送受信の開始後に、前記受信報告パケットの受信状況を監視する監視部と、その監視結果に基づいて、データの配信を適応的に制御する適応制御部と、を有する。
【００５１】
このような、受信報告パケットの送出間隔の動的決定装置やリアルタイム通信の適応制御装置を、データ配信サーバーやデータ受信端末に設けたり、あるいは通信伝送路上に個別に設けることにより、受信報告パケットの消失という事態も考慮した、回線の輻輳制御や配信データのＱｏＳ制御が可能となる。
【００５２】
また、本発明のデータ受信装置は、受信報告パケットの送出間隔を決定する送出間隔決定部と、決定された送出間隔の情報を、コネクション型の通信プロトコルを用いて通信先に通知することができる制御情報送受信部と、受信報告パケット生成部と、受信報告パケットを、前記送出間隔内で少なくとも１回送出する受信報告パケット送出部と、を具備する。
【００５３】
また、本発明のデータ配信装置は、配信先の装置から通知された、あるいは、自ら決定した受信報告パケットの送出間隔の経過を計測するタイマーと、送出間隔内、あるいはその送出間隔に伝送路の遅延時間を加えた間隔内において受信報告パケットが受信されない回数をカウントするカウンタと、そのカウンタのカウント値を、一または二以上のしきい値と比較し、その比較結果に応じて、前記メディアデータの送信レートを減じる、あるいは、セッションを切断するリアルタイム通信の適応制御部と、を有する。
【００５４】
装置の構成が簡易であり、ＲＴＰ（リアルタイム・プロトコル）の少しの改良により対応できるため、本発明の方法を実施するのは容易である。
【００５５】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照して説明する。
【００５６】
なお、本明細書で使用される「リアルタイムデータ」は、リアルタイム性が要求されるデータのことであり、音声データや映像データを示すメディアデータ（あるいはマルチメディアデータ）と同義語として使用する。
【００５７】
（実施の形態１）
本実施の形態では、データ受信装置が、受信報告をサーバーに送信する固定間隔あるいは許容最大間隔を決定し、信頼性のある伝送方式によって、その間隔の情報をサーバーに通知し、サーバー側で受信報告パケットの消失状況を監視し、その監視結果に基づいて、データ配信を適応制御する。
【００５８】
本実施の形態では、図１に示すような有線通信網と無線通信網を組み合わせたデータ配信システムにおいて、本発明の方法を実施することを想定する。
【００５９】
図１に示すように、移動局５０が、配信サーバー１０から、マルチメディアデータ（画像データや音声データ）の配信を受ける。配信されるマルチメディアデータは、有線ネットワーク２０、ゲートウエイ３０、無線基地局４０を介して移動局５０に送信される。
【００６０】
移動局５０として、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｃｅ）等の携帯端末、携帯電話機、あるいはパーソナルコンピュータが想定される。無線通信の通信状態は受信環境により大きな影響を受けるため、回線の輻輳が発生しやすく、また、通信データの誤り率の増大によって受信信号の品質が低下するおそれがあり、また、電波の届きにくい場所への移動による回線の切断の可能性もある。
【００６１】
移動局５０から配信サーバー１０に向けて送出する受信報告パケットが途中で消失する事態が発生しているにもかかわらず、配信サーバー１０が適応制御を行うことなくデータを送信しつづけると、回線の負担が、ますます重くなってしまう。
【００６２】
よって、本発明の方法による、受信パケットの送出間隔の動的決定を利用したデータ配信の適応制御が有効である。
【００６３】
移動局５０と基地局４０との間の無線通信方式は特に限定されるものではなく、ＣＤＭＡ方式やＧＳＭ方式など、種々、利用することができる。Ｗ−ＣＤＭＡ方式では、マルチメディアデータのリアルタイム配信が可能であるため、本発明の適用が効果的である。
【００６４】
図２は、マルチメディアデータの送受信に用いられるプロトコルスタックを説明するための図である。
【００６５】
図示されるように、ＲＴＰ（リアルタイム・プロトコル）とＵＤＰ（ユーザー・データグラム・プロトコル）がセットになって、トランスポート層のプロトコルを構成する。なお、通信ネットワークＣＮを介してリアルタイム・マルチメディア通信を実現するためには、ＲＴＳＰやＳＤＰといったプロトコルが必要となる。
【００６６】
ネットワーク層のプロトコルとしては、ＩＰ（インターネット・プロトコル）が用いられる。
【００６７】
本発明は、特に、ＲＴＰプロトコルに改良を加えて、受信報告パケットの消失という事態にも対応できるようにするものである。
【００６８】
本発明のマルチメディア・リアルタイム通信における適応制御の主な手順をまとめると、図３に示すようになる。
【００６９】
すなわち、データ配信サーバーと受信端末との間で、受信報告パケットの送信間隔（固定間隔、あるいは許容される最大の間隔）を動的に設定する（ステップ６０）。
【００７０】
次に、データ配信サーバーが、受信端末から送られてくる受信報告パケットの、設定された時間間隔を単位とした受信状況を監視する（ステップ７０）。
【００７１】
次に、受信報告パケットが受信されない回数を、一または二以上のしきい値と比較して、その比較結果に応じて、データ送出レートの変更やセッションの終了等の適応制御を行う（ステップ８０）。
【００７２】
以下、本発明の実施の形態について図面を参照して、より具体的に説明する。
【００７３】
図４は、ストリーミングデータを送受信するデータ配信サーバー／データ受信装置の構成を示すブロック図である。
【００７４】
データ配信サーバー３０１とデータ受信装置１０１は、通信ネットワーク２００を介して、双方向の通信を行う。
【００７５】
まず、データ受信装置（図４の下側に示される）１０１の構成と動作について説明する。
【００７６】
制御情報送受信手段１０２はストリーミングのセットアップ、スタート、ストップ等制御情報を送受信する。
【００７７】
ＴＣＰ送受信手段１０３は、信頼性のある伝送方式であるＴＣＰを用いてインターネットや無線網等のネットワークを通じサーバーと送受信を行う。
【００７８】
ＵＤＰ送受信手段１０９は、非信頼性伝送方式であるＵＤＰを用いてインターネットや無線網等のネットワークを通じサーバーと送受信を行う。
【００７９】
ＲＴＰ受信手段１０８は、サーバーから送信されるメディアデータを受信する。メディア再生手段は、１０８で受信されたＲＴＰパケットに格納されている音声または映像であるメディアデータを再生する。
【００８０】
受信報告パケット生成手段１０５は受信したＲＴＰパケットを監視し、パケット損失や受信時刻のゆらぎを計測し、受信報告パケットを生成する。
【００８１】
ＲＴＣＰ送受信手段１０７は、サーバーから送信される送信報告パケット等を受信し、受信報告パケット生成手段１０５で生成される受信報告パケット等をサーバーに送信する。
【００８２】
受信報告送信間隔決定手段１０４は、受信報告をサーバーに送る一定の送信間隔または許容される最大間隔を決定し、制御情報送受信手段１０２を通じてサーバーに通知すると同時に、決定された間隔を、受信報告パケット生成手段１０５に指示する。
【００８３】
ここで、受信報告パケットの送信間隔を固定とした場合には、その間隔毎に、周期的に、受信報告パケットを送出することがデータ受信装置１０１に義務付けられる。
【００８４】
また、許容最大間隔を用いる場合には、その間隔内のいずれのタイミングでもかまわないが、少なくとも１回の受信報告パケットの送出が、データ受信装置１０１に義務付けされる。
【００８５】
どちらの間隔を用いてもよいが、許容最大間隔を用いる場合には、受信報告パケットの送信タイミングの自由度が高いというメリットがある。
【００８６】
なお、以下の説明では、固定された受信報告送信間隔のパラメータ名として、“ｔｒｒ−ｆｉｘｅｄ−ｉｎｔ”を用いる。また、許容最大受信報告送信間隔のパラメータ名として、“ｔｒｒ−ｍａｘ−ｉｎｔ”を用いる。
【００８７】
次に、データ受信装置１０１の動作について、図５を用いて説明する。
【００８８】
図５は、クライアント１０１の動作を示すシーケンス図である。
【００８９】
従来の動作と同じように、ＳＴ４００１、ＳＴ４００２によってセッションのセットアップを完了する。次に、クライアントにより決定された受信報告パケットを送信する間隔（受信報告送信間隔）をサーバーに送信する。
【００９０】
具体的には、受信報告送信間隔（ここでは、最大許容間隔を用いることとする）のパラメータ名である、ｔｒｒ−ｍａｘ−ｉｎｔ を指定したＲＴＳＰ制御メッセージのＳＥＴ＿ＰＡＲＡＭＥＴＥＲ要求をクライアントからサーバーに送信する。上述のように、ｔｒｒ−ｆｉｘｅｄ−ｉｎｔをパラメータとして用いる（つまり、固定間隔を用いる）ことも可能である。
【００９１】
この場合、「ｔｒｒ−ｍａｘ−ｉｎｔ ＝ ５０００」と指定しているので、クライアントはサーバーに対し、５０００ｍｓ ＝ ５ｓｅｃ 毎に必ず１回受信報告を送ることを通知することになる。
【００９２】
次に、図４の上側に示される、メディアデータの配信サーバー３０１の構成と動作を説明する。
【００９３】
図４に示されるように、制御情報送受信手段３０２は、データ受信装置から要求されるストリーミングのセットアップ、スタート、ストップ等制御情報を送受信する。
【００９４】
ＴＣＰ送受信手段３０３は、信頼性のある伝送方式であるＴＣＰを用いてインターネットや無線網等のネットワークを通じデータ受信装置と送受信を行う。
【００９５】
ＵＤＰ送受信手段３０９は、非信頼性伝送方式であるＵＤＰを用いてインターネットや無線網等のネットワークを通じデータ受信装置と送受信を行う。
【００９６】
ＲＴＰ送信手段３０８は、データ受信装置に対しメディアデータを送信する。メディア格納手段は、３０８で送信するための音声または映像であるメディアデータを格納する。送信報告パケット生成手段３０５はサーバーとデータ受信装置とのデータ往復時間の計測等を行い、送信報告パケットを生成する。
【００９７】
ＲＴＣＰ送受信手段３０７は、データ受信装置から送信される受信報告パケット等を受信し、送信報告パケット生成手段３０５で生成される送信報告パケットをデータ受信装置に送信する。
【００９８】
タイマー３１０は制御情報送受信手段３０２から入力される受信報告送信間隔にジッタを考慮したαを加算した値（β）をセットし、βの間受信報告パケットが受信されない場合は、カウンタ３１１に出力する。
【００９９】
すなわち、このタイマー３１０は、所定間隔内に受信報告パケットが到着したか否かの判定を行う判定手段としても機能する。
【０１００】
なお、最大許容間隔を用いる場合だけなく固定間隔を用いる場合でも、結果的には、その間隔内に受信報告パケットが到着したか否かの判定を行えばよい点で共通するため、どちらの間隔を用いるかにかかわらず、図４に記載される構成によって判定が可能である。
【０１０１】
カウンタ３１１はタイマー３１０からの入力があった場合は１増分する。送出レート調節手段３１２はカウンタがある一定値に達した場合にカウンタから送出レート減少指示が入力され、ＲＴＰパケットの送出レートを減じる。
【０１０２】
セッション切断手段３１３、カウンタの値がさらに大きい一定値に達した場合にカウンタからＲＴＰパケットの送信終了指示が入力され、ＲＴＰパケット送出を終了し、セッションを終了する。
【０１０３】
次に、メディアデータの配信サーバー３０１の動作について、図６を用いて説明する。
【０１０４】
ＳＴ１０００１では、ＳＥＴＵＰ要求をクライアントから受信し、応答（ＯＫ）を送信する。
【０１０５】
続いてＳＥＴ＿ＰＡＲＡＭＥＴＥＲ要求を受信し、ｔｒｒ−ｍａｘ−ｉｎｔ をクライアントから指定された値（５０００ｍｓ）にセットする（ＳＴ１０００２）。ＰＬＡＹ要求を受信し、応答（ＯＫ）を送信した後、クライアントに対しメディアデータを含むＲＴＰパケットの送信を開始する（ＳＴ１０００３）。
【０１０６】
サーバーはＲＴＰパケット送出開始後、クライアントから初めて受信報告パケットを受信する（ＳＴ１０００４）。カウンタを０にセットする（ＳＴ１０００５）。
【０１０７】
タイマーを０にセットし、タイマーをスタートさせる（ＳＴ１０００６）。次に受信報告パケットを受信したかどうか監視し（ＳＴ１０００７）、受信報告パケットを受信した場合は、受信したＲＲパケットに含まれる情報に基づいて送出レートを調整した後（ＳＴ１００１５）、ＳＴ１０００５の処理に戻る。
【０１０８】
ＳＴ１０００７で受信報告パケットを受信しない場合は、ＳＴ１０００８の処理に進む。１ｍｓに１だけ進むタイマーの値 ｔとｔｒｒ−ｍａｘ−ｉｎｔ にＲＴＰパケット受信時刻のばらつきを表すジッタを考慮してαを足した値ｔｒｒ−ｍａｘ−ｉｎｔ ＋ αとの大小を比較する（ＳＴ１０００８）。
【０１０９】
ｔの方が小さければＳＴ１０００７に戻り受信報告パケットの受信を監視し、ｔの方が大きければ受信報告パケットが途中で消失した、あるいは、誤り率が増大した、あるいは未送信と判定し、ＳＴ１０００９に進む。
【０１１０】
ＳＴ１０００９では受信報告パケットが連続して未受信である数を表すカウンタを１増分する。
【０１１１】
そして、ＳＴ１００１０では、カウンタが、例えば、“５”かどうか判定する。すなわち、受信報告パケットの未受信が５回に達しているかを判定する。そして、“５”でない場合は、ＳＴ１０００６に戻り、“５”であれば、現在の送出レートが最小かを判定する（ＳＴ１００１１）。送出レートは段階的に制御されるが、現在のレートが最低のレートであるときは、送出レートをそれ以下とすることはできないから、ＳＴ１００１１における判定がイエスの場合には、ＲＴＰパケットの送出を終了する（ＳＴ１００１４）。
【０１１２】
ＳＴ１００１２ではカウンタが、例えば、“１０”かどうか判定する。“１０”でなければ、クライアントとのセッションは継続されているが、輻輳等の要因によって受信報告パケットが消失したと判定し、ＲＴＰパケットの送出レートを減じることによって、輻輳を悪化させることを防ぐ（ＳＴ１００１３）。
【０１１３】
“１０”であれば、例えば、クライアントが電源を切断した等の要因によって、クライアントとのセッションが一方的に切断されたと判定し、ＲＴＰパケットの送出を終了する（ＳＴ１００１４）。
【０１１４】
ここで、カウンタが増加する仕組みを図５を用いて説明する。
【０１１５】
ＳＴ４００１−ＳＴ４００４は同一であるから説明を省略する。サーバーでは、ＲＲ１を受信後、タイマーが動作する。
【０１１６】
サーバータイマー値には次の式によって定まるβを用いる（β＝あらかじめ通知された受信報告送信間隔＋α）。
【０１１７】
サーバーはβ時間経過ｋしてもＲＲを受信しない場合、カウンタを１増分しカウンタ＝１となる。そのままＲＲを受信しないまま、さらにβ経過するとカウンタがさらに１増分されカウンタ＝２となる。
【０１１８】
ここで、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲで通知するメッセージについて図７を用いて説明する。
【０１１９】
ＳＥＴ＿ＰＡＲＡＭＥＴＥＲで始まる行はＳＥＴ＿ＰＡＲＡＭＥＴＥＲ要求をｒｔｓｐ：／／で指定されたＵＲＬに送信することを表す。ＣＳｅｑ はシーケンス番号であり、ＲＴＳＰセッションでＲＴＳＰメッセージが交換されるたびに１増加される。Ｓｅｓｓｉｏｎは、あるＲＴＳＰセッションを識別するための識別番号である。
【０１２０】
以上はＲＴＳＰヘッダであり、次に１行空行を空けて本文が開始される。本文には、ｔｒｒ−ｍａｘ−ｉｎｔ＝５０００を記述し、サーバーに対して受信報告送信間隔を通知する。
【０１２１】
サーバーはその通知を受信すると、図８に示されるように、ＯＫを返信する。
【０１２２】
なお、本実施の形態においては、受信報告送信間隔を５０００ｍｓの固定値として説明したが、これに限定されるものではない。
【０１２３】
また、上述したように、受信報告送信間隔内において１回は受信報告パケットを送信する最大間隔を指定するのではなく、受信報告送信間隔毎に必ず１回受信報告パケットを送信する固定間隔を指定してもよい。
【０１２４】
（実施の形態２）
本実施の形態では、データ配信サーバーが、受信パケットの送出間隔を決定し、信頼性のある伝送方式によって、その決定された間隔の情報をデータ受信装置に通知する。
【０１２５】
図９は、メディアデータの送信サーバー／データ受信装置の構成を示すブロック図である。
【０１２６】
基本的には、前掲の実施の形態における構成（図４）と同じであり、重複する説明は省略する。
【０１２７】
つまり、図９の下側に示されるデータ受信装置１０１では、受信報告送信間隔決定手段２０４以外は、図４と同じ構成であるので説明を省略する。
【０１２８】
受信報告送信間隔決定手段２０４へは制御情報送受信手段２０２を通じてデータ配信サーバー３０１より受信した受信報告送信間隔の情報が入力される。そして、その受信報告送信間隔に従って、データ受信装置１０１は、受信報告パケット（受信状況を報告するための情報ならば、パケット形式であるか否かは問わない）をデータ配信サーバー３０１に送信する。
【０１２９】
また、図９の上側に示されるデータ配信サーバー３０１においては、受信報告送信間隔決定手段３０４が、データ受信端末がサーバーに受信報告を送信する間隔を決定する。
【０１３０】
そして、制御情報送受信手段３０２に指示してデータ受信装置１０１に、決定された受信報告パケットの送出間隔を送信させ、これと同時に、タイマー３１０を動作させる。
【０１３１】
以上の説明では、リアルタイム通信のプロトコルとしてＲＴＳＰを用いて送出間隔を通知する例について説明したが、プロトコルとしてＳＤＰを用いた場合も同様の構成に、同様の効果を得ることができる。
【０１３２】
図１０は、ＳＤＰ（ＲＦＣ２３２７で規定）に準拠したメディア情報の記述の一例を示す図である。
【０１３３】
従来の記述に対し、「ａ＝ｔｒｒ−ｍａｘ−ｉｎｔ：５０００」が、音声、映像情報のそれぞれに付与され、データ受信装置に送信される。このように、本発明では、基本的には、プロトコルの記述を追加するだけでよく、実現が容易である。
【０１３４】
なお、本発明はストリーミングだけでなく、パケットベース音声通話やパケットベースＴＶ会議にも適用可能である。したがって、本発明のデータ配信装置、データ受信装置は、ＳＩＰまたはＨ．３２３等のパケットベース音声通話端末やパケットベースＴＶ会議端末として利用可能である。
【０１３５】
すなわち、本発明はストリーミングデータの配信だけでなく、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）といった音声通話等にも利用可能である。なお、ＳＩＰ／Ｈ．３２３はパケット通信により、音声通話やＴＶ会議を実現する規格名である。
【０１３６】
【発明の効果】
以上説明したように、本発明によれば、輻輳の発生するネットワークや伝送誤りの発生する無線網等を通じて音声や映像データを送受信する場合、データ受信装置から送信される受信報告の間隔がセッションにより一意に決められており、信頼性のある伝送方式で、サーバーまたはデータ受信装置に送信されるので、サーバーは受信報告の間隔を用いて、セッションが切断された場合には迅速にセッションを切断することができ、伝送路の状況が悪化している場合には迅速にパケット送出レートを減じることにより輻輳を悪化させることを防ぐことができる。
【０１３７】
こにれより、柔軟な輻輳制御を行うことができ、回線の混雑を未然に回避することにも役立ち、このことは、結果的に、配信データのＱｏＳ（サービス品質）を高めることに貢献する。
【図面の簡単な説明】
【図１】マルチメディアデータの配信システム（リアルタイム・データ通信システム）の構成を示すブロック図
【図２】マルチメディア通信（リアルタイム通信）を行う場合の、プロトコルスタックについて説明するための図
【図３】マルチメディア・リアルタイム通信における、本発明の適応制御の主要な手順を示すフロー図
【図４】データ送信サーバー／データ受信装置の構成の一例を示すブロック図
【図５】図４における受信データ装置の動作（データ受信装置において受信報告パケットの送出間隔を決定する場合の具体的な動作）を説明するためのシーケンス図
【図６】図４におけるサーバー側の動作を説明するためのフロー図
【図７】データ受信装置からサーバーへのＲＴＳＰメッセージの内容の一例を示す図
【図８】サーバーからデータ受信装置へのＲＴＳＰ応答の内容の一例を示す図
【図９】データ送信サーバー／データ受信装置の構成の他の例を示すブロック図
【図１０】ＳＤＰ（ＲＦＣ２３２７で規定）に準拠したメディア情報の記述の一例を示す図
【図１１】リアルタイム通信の手順の一例を説明するためのシーケンス図
【図１２】輻輳や伝送誤りのあるネットワーク上でメディア配信を行う場合の手順の一例を示すシーケンス図
【符号の説明】
１０ 配信サーバー
２０ 有線ネットワーク
３０ ゲートウエイ装置
４０ 基地局
５０ 移動局
１０１ データ受信装置
１０２ 制御情報送受信手段
１０３ ＴＣＰ送受信手段
１０４ 受信報告送信間隔決定手段
１０５ 受信報告パケット生成手段
１０６ メディア再生手段
１０７ ＲＴＣＰ送受信手段
１０８ ＲＴＰ受信手段
１０９ ＵＤＰ送受信手段
２００ 通信ネットワーク
３０１ サーバー
３０２ 制御情報送受信手段
３０３ ＴＣＰ送受信手段
３０５ 送信報告パケット生成手段
３０６ メディア格納手段
３０７ ＲＴＣＰ送受信手段
３０８ ＲＴＰ送信手段
３０９ ＵＤＰ送受信手段
３１０ タイマー
３１１ カウンタ
３１２ 送出レート調整手段
３１３ セッション切断手段
Claims (12)
- リアルタイムデータの送受信の開始前に、データ送信装置とデータ受信装置との間で、前記データ受信装置が前記データ送信装置に対して送出すべき受信報告パケットの送出間隔の取り決めを行う第１のステップと、
前記リアルタイムデータの送受信の開始後に、前記データ送信装置が、取り決められた前記送出間隔を単位として、前記受信報告パケットの受信状況を監視する第２のステップと、
前記データ送信装置が、その監視結果に基づいて、データ送信を適応的に制御する第３のステップと、
を有するリアルタイム通信の適応制御方法。 - 請求項１において、
前記第１のステップにおける前記受信報告パケットの送出間隔は、固定された間隔、あるいは、許容される最大の間隔であり、
前記第２のステップでは、前記送出間隔内、あるいは前記送出間隔に伝送路の遅延時間を加えた間隔内に受信報告パケットを受信できなかった回数の情報に基づき、通信伝送路における輻輳の発生、通信伝送路における伝送誤りの発生、または受信装置との通信の不能を推定し、
前記第３のステップでは、データ送信のレートの変更、あるいはデータ送信の中止のいずれかの制御を行うことを特徴とする、リアルタイム通信の適応制御方法。 - 請求項１において、
前記第１のステップにおける前記送出間隔の取り決めには、信頼性の高いコネクション型の転送方式を採用し、前記リアルタイムデータの送受信には、コネクションレス型の転送方式を採用することを特徴とするリアルタイム通信の適応制御方法。 - リアルタイム通信における受信報告パケットの連続消失に対する対策方法であって、
データの送受信に先立ち、セッション確立時の制御信号を利用して、データ送信装置またはデータ受信装置のいずれかが相手側装置に、前記データ受信装置が前記データ送信装置に対して送出すべき受信報告パケットの送出間隔を通知し、これにより、前記データ受信装置に対して、送受信開始後に、前記送出間隔内で少なくとも１回の受信報告パケットの送信を義務付けるステップと、
前記データ送信装置が、前記送出間隔またはその送出間隔に伝送路の遅延時間を加えた間隔を単位として、前記データ受信装置から送られてくる前記受信報告パケットの受信状況を監視し、前記受信報告パケットの消失が連続する場合に、データ送信のレートの変更、あるいはデータ送信の中止のいずれかの適応制御を行うステップと、
を有することを特徴とする、受信報告パケットの連続消失に対する対策方法。 - リアルタイム通信における受信報告パケットの送出間隔を動的に決定する送出間隔決定部と、
決定された送出間隔を、信頼性の高いコネクション型の転送方式により通信先の装置に送信する送信部と、
を有することを特徴とする、受信報告パケットの送出間隔の動的決定装置。 - 請求項５に記載される、受信報告パケットの送出間隔の動的決定装置により決定された送出間隔を単位として、前記リアルタイムデータの送受信の開始後に、前記受信報告パケットの受信状況を監視する監視部と、
その監視結果に基づいて、データの配信を適応的に制御する適応制御部と、
を有することを特徴とするリアルタイム通信の適応制御装置。 - 通信ネットワークを通じて配信されるメディアデータを受信して音声や映像を再生するデータ受信装置であって、
受信報告パケットの送出間隔を決定する送出間隔決定部と、
決定された送出間隔の情報を、コネクション型の通信プロトコルを用いて通信先に通知することができる制御情報送受信部と、
前記受信報告パケット生成部と、
前記受信報告パケットを、前記送出間隔内で少なくとも１回送出する受信報告パケット送出部と、
を具備することを特徴とするデータ受信装置。 - 請求項７において、
前記受信報告パケットの送出間隔は、固定された間隔、あるいは、許容される最大の間隔であることを特徴とするデータ受信装置。 - 請求項７または請求項８において、
前記データ受信装置は、通信機能をもつ携帯機器であることを特徴とするデータ受信装置。 - 通信ネットワークを通じてリアルタイムデータを配信するデータ配信装置であって、
配信先の装置から前記データ配信装置に送信される受信報告パケットの、送出間隔を決定する送出間隔決定部と、
決定された送出間隔の情報を、コネクション型の通信プロトコルを用いて通信先に通知することができる制御情報送受信部と、
前記リアルタイムデータを、コネクションレス型の通信プロトコルを用いて配信することができるデータ配信部と、
を有することを特徴とするデータ配信装置。 - 通信ネットワークを通じてリアルタイムデータを配信するデータ配信装置であって、
配信先の装置から通知された、あるいは、自ら決定した受信報告パケットの送出間隔の経過を計測するタイマーと、
前記送出間隔内、あるいはその送出間隔に伝送路の遅延時間を加えた間隔内において受信報告パケットが受信されない回数をカウントするカウンタと、
そのカウンタのカウント値を、一または二以上のしきい値と比較し、その比較結果に応じて、前記リアルタイムデータの送信レートを減じる、あるいは、セッションを切断するリアルタイム通信の適応制御部と、
を有することを特徴とするデータ配信装置。 - 音声データまたは映像データのいずれかを含むメディアデータを、有線通信網および無線通信網を介してメディア配信サーバーから受信し、再生する機能をもつ携帯端末装置であって、
前記メディア配信サーバーとの間でセッションを確立する段階において、自ら決定した、受信報告パケットを送るべき間隔に関する情報を前記メディア配信サーバーに送信する、あるいは、前記メディア配信サーバーから送られてくる前記受信報告パケットを送るべき間隔に関する情報を受信する、受信パケット送出間隔取り決め手段と、
前記間隔に関する情報に従って、受信報告パケットを前記メディア配信サーバーに送信する、受信報告パケット送信手段と、
を有することを特徴とする携帯端末装置。
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002269238A JP2004112113A (ja) | 2002-09-13 | 2002-09-13 | リアルタイム通信の適応制御方法、受信報告パケットの連続消失に対する対策方法、受信報告パケットの送出間隔の動的決定装置、リアルタイム通信の適応制御装置、データ受信装置およびデータ配信装置 |
| AU2003264433A AU2003264433A1 (en) | 2002-09-13 | 2003-09-16 | Real time communication adaptive control method |
| US10/507,130 US20050105471A1 (en) | 2002-09-13 | 2003-09-16 | Adapative control method in real-time communication |
| CNA038058235A CN1643851A (zh) | 2002-09-13 | 2003-09-16 | 实时通信中的自适应控制方法 |
| PCT/JP2003/011756 WO2004098134A1 (ja) | 2002-09-13 | 2003-09-16 | リアルタイム通信の適応制御方法 |
| EP03816007A EP1560374A4 (en) | 2002-09-13 | 2003-09-16 | ADAPTIVE CONTROL PROCEDURE FOR REAL-TIME COMMUNICATION |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002269238A JP2004112113A (ja) | 2002-09-13 | 2002-09-13 | リアルタイム通信の適応制御方法、受信報告パケットの連続消失に対する対策方法、受信報告パケットの送出間隔の動的決定装置、リアルタイム通信の適応制御装置、データ受信装置およびデータ配信装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004112113A true JP2004112113A (ja) | 2004-04-08 |
Family
ID=32267221
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002269238A Pending JP2004112113A (ja) | 2002-09-13 | 2002-09-13 | リアルタイム通信の適応制御方法、受信報告パケットの連続消失に対する対策方法、受信報告パケットの送出間隔の動的決定装置、リアルタイム通信の適応制御装置、データ受信装置およびデータ配信装置 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20050105471A1 (ja) |
| EP (1) | EP1560374A4 (ja) |
| JP (1) | JP2004112113A (ja) |
| CN (1) | CN1643851A (ja) |
| AU (1) | AU2003264433A1 (ja) |
| WO (1) | WO2004098134A1 (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007072731A (ja) * | 2005-09-06 | 2007-03-22 | Chiba Univ | 乱数生成システム、乱数生成方法及び乱数生成プログラム |
| JP2009246630A (ja) * | 2008-03-31 | 2009-10-22 | Mitsubishi Electric Corp | ホームゲートウェイ装置およびホームゲートウェイ装置の通信品質制御方法 |
| JP2011166380A (ja) * | 2010-02-08 | 2011-08-25 | Canon Inc | 通信装置、通信方法、及びプログラム |
| JP2018508156A (ja) * | 2015-03-09 | 2018-03-22 | ランディス・ギア イノベーションズ インコーポレイテッドＬａｎｄｉｓ＋Ｇｙｒ Ｉｎｎｏｖａｔｉｏｎｓ， Ｉｎｃ． | パケット送信タイミングの動的調整方法 |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070047590A1 (en) * | 2005-08-26 | 2007-03-01 | Nokia Corporation | Method for signaling a device to perform no synchronization or include a synchronization delay on multimedia stream |
| KR100664955B1 (ko) * | 2005-10-20 | 2007-01-04 | 삼성전자주식회사 | 방송 수신 장치의 다운로드 속도를 제어하는 방법 및 이를위한 장치 |
| JP4640824B2 (ja) * | 2006-01-30 | 2011-03-02 | 富士通株式会社 | 通信環境の測定方法、受信装置、及びコンピュータプログラム |
| US7813296B2 (en) * | 2006-12-27 | 2010-10-12 | Telefonaktiebolaget L M Ericsson (Publ) | Adapting transmission and reception time in packet based cellular systems |
| US7991904B2 (en) * | 2007-07-10 | 2011-08-02 | Bytemobile, Inc. | Adaptive bitrate management for streaming media over packet networks |
| US7987285B2 (en) | 2007-07-10 | 2011-07-26 | Bytemobile, Inc. | Adaptive bitrate management for streaming media over packet networks |
| EP2195994A1 (en) * | 2007-09-28 | 2010-06-16 | Telefonaktiebolaget L M Ericsson (publ) | Method of controlling a communication device |
| US20090144438A1 (en) * | 2007-11-30 | 2009-06-04 | General Instrument Corporation | Standards enabled media streaming |
| GB0802294D0 (en) * | 2008-02-07 | 2008-03-12 | British Telecomm | Communications network |
| US8452228B2 (en) * | 2008-09-24 | 2013-05-28 | Apple Inc. | Systems, methods, and devices for associating a contact identifier with a broadcast source |
| US8775665B2 (en) * | 2009-02-09 | 2014-07-08 | Citrix Systems, Inc. | Method for controlling download rate of real-time streaming as needed by media player |
| CA2793960C (en) * | 2010-03-23 | 2018-05-22 | Reversinglabs Corporation | Cloud-based web content filtering |
| US8700221B2 (en) * | 2010-12-30 | 2014-04-15 | Fluid Handling Llc | Method and apparatus for pump control using varying equivalent system characteristic curve, AKA an adaptive control curve |
| EP2719144B1 (en) | 2011-06-10 | 2018-08-08 | Citrix Systems, Inc. | On-demand adaptive bitrate management for streaming media over packet networks |
| WO2012170904A2 (en) | 2011-06-10 | 2012-12-13 | Bytemobile, Inc. | Adaptive bitrate management on progressive download with indexed media files |
| KR101491604B1 (ko) * | 2011-11-02 | 2015-02-13 | 주식회사 케이티 | 다중 채널을 이용한 콘텐츠 제공 방법 및 시스템 |
| CN102377673B (zh) * | 2011-11-04 | 2014-08-06 | 华为技术有限公司 | 一种报文发送方法及发送设备 |
| CN104024965B (zh) | 2011-12-16 | 2018-02-13 | 流体处理有限责任公司 | 用于可变速度泵控制的动态线性控制方法和装置 |
| CN102571457B (zh) * | 2012-02-28 | 2015-09-30 | 华为数字技术（成都）有限公司 | 一种触发旁路设备切换的方法、旁路设备切换方法及装置 |
| EP3190749B1 (en) * | 2014-09-29 | 2019-11-06 | Huawei Technologies Co., Ltd. | Traffic control method and system |
| US9825734B2 (en) * | 2014-12-17 | 2017-11-21 | Cisco Technology, Inc. | VoIP system |
| US9965042B2 (en) * | 2015-03-30 | 2018-05-08 | X Development Llc | Methods and systems for gesture based switch for machine control |
| CN105072014A (zh) * | 2015-08-28 | 2015-11-18 | 浙江大华技术股份有限公司 | 一种多媒体数据传输方法及车载设备、监控服务器 |
| US10454982B1 (en) * | 2016-03-18 | 2019-10-22 | Audio Fusion Systems, Inc. | Monitor mixing system that distributes real-time multichannel audio over a wireless digital network |
| JP6956624B2 (ja) * | 2017-03-13 | 2021-11-02 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ | 情報処理方法、情報処理システム、及びプログラム |
| JP6824212B2 (ja) * | 2018-03-12 | 2021-02-03 | 日本電信電話株式会社 | 断監視終端装置及び断監視方法 |
| CN109818950B (zh) * | 2019-01-18 | 2022-04-22 | 北京和利时系统工程有限公司 | 一种访问控制规则优化方法及装置、计算机可读存储介质 |
| US11606406B1 (en) | 2021-08-24 | 2023-03-14 | Motorola Mobility Llc | Electronic device that mitigates audio/video communication degradation of an image stream of a local participant in a video communication session |
| US11722544B2 (en) * | 2021-08-24 | 2023-08-08 | Motorola Mobility Llc | Electronic device that mitigates audio/video communication degradation of an image stream of a remote participant in a video communication session |
| US11765215B2 (en) * | 2021-08-24 | 2023-09-19 | Motorola Mobility Llc | Electronic device that supports individualized dynamic playback of a live video communication session |
| KR102471228B1 (ko) * | 2022-04-04 | 2022-11-28 | 서울대학교산학협력단 | 네트워크의 패킷 흐름에 대한 공격성 파라미터 동적 제어 방법 및 장치 |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2639335B2 (ja) * | 1993-12-22 | 1997-08-13 | 日本電気株式会社 | Ａｔｍ網における輻輳制御方式 |
| FI940196A (fi) * | 1994-01-14 | 1995-07-15 | Nokia Telecommunications Oy | Menetelmä kanavien allokoimiseksi radiojärjestelmässä, tilaaja-asema ja tukiasema |
| JPH09284746A (ja) * | 1996-04-19 | 1997-10-31 | Sony Corp | 双方向情報伝送システムおよび双方向情報伝送方法 |
| US5918020A (en) * | 1997-02-28 | 1999-06-29 | International Business Machines Corporation | Data processing system and method for pacing information transfers in a communications network |
| US6701372B2 (en) * | 1997-08-22 | 2004-03-02 | Canon Kabushiki Kaisha | Data communication apparatus and method |
| US6487689B1 (en) * | 1999-07-08 | 2002-11-26 | Lucent Technologies Inc. | Receiver initiated recovery algorithm (RIRA) for the layer 2 tunneling protocol (L2TP) |
| JP4101993B2 (ja) * | 1999-12-03 | 2008-06-18 | 三菱電機株式会社 | 有線無線混在網データ配信装置及び有線無線混在網データ配信方法 |
| JP2001320440A (ja) * | 2000-05-02 | 2001-11-16 | Sony Corp | 通信装置及び方法 |
| JP3662907B2 (ja) * | 2000-09-22 | 2005-06-22 | 松下電器産業株式会社 | データ送受信方法、送信装置、受信装置、送受信システム、およびプログラム |
| JP4663100B2 (ja) * | 2000-11-20 | 2011-03-30 | パナソニック株式会社 | サーバー、クライアント、通信開始方法及び通信開始プログラム |
| KR100408525B1 (ko) * | 2001-10-31 | 2003-12-06 | 삼성전자주식회사 | 네트워크에 적응적인 실시간 멀티미디어 스트리밍 시스템및 방법 |
| JP2003250172A (ja) * | 2002-02-25 | 2003-09-05 | Matsushita Electric Ind Co Ltd | 移動通信端末装置 |
-
2002
- 2002-09-13 JP JP2002269238A patent/JP2004112113A/ja active Pending
-
2003
- 2003-09-16 WO PCT/JP2003/011756 patent/WO2004098134A1/ja active Application Filing
- 2003-09-16 EP EP03816007A patent/EP1560374A4/en not_active Withdrawn
- 2003-09-16 AU AU2003264433A patent/AU2003264433A1/en not_active Abandoned
- 2003-09-16 US US10/507,130 patent/US20050105471A1/en not_active Abandoned
- 2003-09-16 CN CNA038058235A patent/CN1643851A/zh active Pending
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007072731A (ja) * | 2005-09-06 | 2007-03-22 | Chiba Univ | 乱数生成システム、乱数生成方法及び乱数生成プログラム |
| JP2009246630A (ja) * | 2008-03-31 | 2009-10-22 | Mitsubishi Electric Corp | ホームゲートウェイ装置およびホームゲートウェイ装置の通信品質制御方法 |
| JP2011166380A (ja) * | 2010-02-08 | 2011-08-25 | Canon Inc | 通信装置、通信方法、及びプログラム |
| US8811180B2 (en) | 2010-02-08 | 2014-08-19 | Canon Kabushiki Kaisha | Communication apparatus and communication method |
| JP2018508156A (ja) * | 2015-03-09 | 2018-03-22 | ランディス・ギア イノベーションズ インコーポレイテッドＬａｎｄｉｓ＋Ｇｙｒ Ｉｎｎｏｖａｔｉｏｎｓ， Ｉｎｃ． | パケット送信タイミングの動的調整方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20050105471A1 (en) | 2005-05-19 |
| CN1643851A (zh) | 2005-07-20 |
| EP1560374A1 (en) | 2005-08-03 |
| WO2004098134A1 (ja) | 2004-11-11 |
| EP1560374A4 (en) | 2005-10-26 |
| AU2003264433A1 (en) | 2004-11-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004112113A (ja) | リアルタイム通信の適応制御方法、受信報告パケットの連続消失に対する対策方法、受信報告パケットの送出間隔の動的決定装置、リアルタイム通信の適応制御装置、データ受信装置およびデータ配信装置 | |
| JP4287376B2 (ja) | ストリーミングメディア | |
| JP4927333B2 (ja) | 帯域幅適応 | |
| US7464172B2 (en) | Simultaneous media playout | |
| CN100525504C (zh) | 多种无线网络融合环境中的多媒体会话服务质量管理方法 | |
| US20100166006A1 (en) | Method, media gateway and system for controlling redundant data packet transmission | |
| JP2006525693A (ja) | マルチメディア・ストリーミングにおけるクライアント速度機能のシグナリング方法 | |
| KR20050104362A (ko) | 통신 제어장치, 통신 단말장치, 서버 장치 및 통신 제어방법 | |
| KR20180031016A (ko) | 전송기측 화상 전화 다운그레이드 | |
| EP1552655A1 (en) | Bandwidth adaptation | |
| JP2008131233A (ja) | ストリーミング通信システム | |
| EP1395020A2 (en) | Method and apparatus for dynamically controlling a real-time multimedia data generation rate | |
| JP3821740B2 (ja) | 音声データ送受信装置 | |
| TWI403197B (zh) | In the wireless broadband network transmission of multimedia streaming user platform, communication systems and methods | |
| Waltermann et al. | A technique for seamless VoIP-codec switching in next generation networks | |
| CN114979080A (zh) | 一种融合局域网和广域网的sip对讲方法、系统、存储装置 | |
| JP2006217167A (ja) | Ｉｐ電話装置およびｉｐアダプタ装置 | |
| US20070115815A1 (en) | Receiver, transmitter and transmission/reception system for media signal | |
| JP2011035700A (ja) | ストリーム配信装置、ストリーム配信システム、ストリーム配信方法およびストリーム配信プログラム | |
| Mazurczyk et al. | Adaptive voip with audio watermarking for improved call quality and security | |
| US8170006B2 (en) | Digital telecommunications system, program product for, and method of managing such a system | |
| KR101384125B1 (ko) | 통신 시스템에서 맥 계층의 서비스 품질 파라미터 생성장치 및 방법 | |
| CN115842900A (zh) | 一种无线信道下的音视频通信优化方法 | |
| Sathyanarayana | Multipath Transport Protocols for Real Time Communication Systems | |
| KR100652768B1 (ko) | Ｉｍｓ 네트워크에서의 단말 사이의 ｉｐ 연결 종료 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050727 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071023 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071220 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080902 |