JP2004343698A - マルチメディア・ストリーミング環境におけるサーバベースのレート制御 - Google Patents

マルチメディア・ストリーミング環境におけるサーバベースのレート制御 Download PDF

Info

Publication number
JP2004343698A
JP2004343698A JP2004042053A JP2004042053A JP2004343698A JP 2004343698 A JP2004343698 A JP 2004343698A JP 2004042053 A JP2004042053 A JP 2004042053A JP 2004042053 A JP2004042053 A JP 2004042053A JP 2004343698 A JP2004343698 A JP 2004343698A
Authority
JP
Japan
Prior art keywords
media server
destination terminal
data stream
data
report
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
JP2004042053A
Other languages
English (en)
Other versions
JP3814614B2 (ja
Inventor
Jose Luis Rey
ルイス レイ ホセ
Rolf Hakenberg
ハッケンバーグ ロルフ
Michael Zink
ツィンク ミハエル
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 Holdings Corp
Original Assignee
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 Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Publication of JP2004343698A publication Critical patent/JP2004343698A/ja
Application granted granted Critical
Publication of JP3814614B2 publication Critical patent/JP3814614B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0002—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0023—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the signalling
    • H04L1/0026—Transmission of channel quality indication
    • 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/19—Flow control; Congestion control at layers above the network layer
    • 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H04W28/22—Negotiating communication rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本発明は、メディア・サーバおよび宛先端末を含むセッションベースのストリーミング環境においてマルチメディア・データ・ストリームの伝送データ・レートを制御する方法に関する。本方法では、セッション制御プロトコルがマルチメディア・データ・ストリームを制御するために採用される。本発明はさらに、その方法を実行するメディア・サーバおよびこのメディア・サーバとの通信に適用された宛先端末に関する。さらに、少なくとも１つのメディア・サーバおよび少なくとも１つの宛先端末を含むメディア・ストリーミング・システムが提供される。メディア・ストリーミング環境において、メディア・サーバからマルチメディア・データ・ストリームを受信する宛先端末に透過的な方法でレート制御を提供するために、本発明はすべての処理をサーバに移すことによりＴＦＲＣレート制御アルゴリズムの変型としてサーバベースの実装が提供される。
【選択図】 図１

Description

本発明は、メディア・サーバおよび宛先端末を有するセッションベースのストリーミング環境においてマルチメディア・データ・ストリームの伝送データ・レートを制御する方法であって、セッション制御プロトコルがマルチメディア・データ・ストリームを制御するために採用された方法に関する。本発明はさらに、その方法を実行するメディア・サーバおよびそのメディア・サーバとの通信に適用される宛先端末に関する。さらに、少なくとも１つのメディア・サーバおよび少なくとも１つの宛先端末を有するメディア・ストリーミング・システムが提供される。
ＴＣＰフレンドリー・レート・コントロール（ＴＦＲＣ）は、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）による"TCP Friendly Rate Control（TFRC): Protocol Specification", RFC 3448で規定されているように、インターネット環境において動作し、ＴＣＰトラフィックと競合するユニキャスト・データ・フローのために設計された輻輳制御機構である。ＴＦＲＣは、完全なプロトコルを定める代わりに、アプリケーション・レベルでエンドツーエンドの輻輳制御を組み入れるアプリケーションにおいて、またはエンドポイント輻輳管理との関連で、トランスポート・プロトコルに使用され得る輻輳制御機構を単に指定するものである。ＴＦＲＣでは、パケット・フォーマットあるいは信頼性については触れていない。
ＴＦＲＣは、帯域獲得のためにＴＣＰデータ・フローと競合している場合、適度に公平となるように設計されている。データ・フローは、その伝送データ・レートが同一条件下のＴＣＰデータ・フローの伝送データ・レートの例えば２倍以内であれば「適度に公平」とされる。ただし、ＴＦＲＣは、ＴＣＰに比べて時間の経過に対するスループットの変動がはるかに小さいので、テレフォニーまたはストリーミング・メディアのように比較的平滑な伝送データ・レートが重要になるアプリケーションに一層適している。
ＴＦＲＣは受信機ベースの機構であり、輻輳制御情報（損失イベント・レートなど）の計算を、データ送信機ではなくデータ受信機において行なう。これは、送信機が多数の同時接続を扱う大型サーバでありかつ受信機が計算に使用可能なより多くのメモリとＣＰＵサイクルを備えているようなアプリケーションに非常に適している。さらに、受信機ベースの機構は、マルチキャスト輻輳制御のためのビルディング・ブロックとして、より一層適している。
その輻輳制御機構に関して、ＴＦＲＣは、損失イベント・レートおよびラウンドトリップ・タイムの関数として、許容伝送データ・レートを求めるスループット推定式を直接使用する。ＴＣＰと公平に競合するために、ＴＦＲＣはＴＣＰスループット推定式を使用するが、これはＴＣＰの伝送データ・レートを損失イベント・レート、ラウンドトリップ・タイムおよびパケット・サイズの関数として大まかに示すものである。
損失イベントは、データのウィンドウからの失われたまたはマークされた１つ以上のパケットとして規定されている。ただし、マークされたパケットとは明示的輻輳通知（ＥＣＮ）からの輻輳表示を参照する（Ramakrishnanら著の"The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, IETF参照）。
一般に、ＴＦＲＣの輻輳制御機構は、次のように機能する。受信機は損失イベント・レートを測定し、その情報を送信機にフィードバックする。次に、送信機もこれらのフィードバック・メッセージを使用して、ラウンドトリップ・タイム（tRTT）を測定する。その後、損失イベント・レートpおよびtRTTは次に、ＴＦＲＣのスループット推定式に送り込まれ、許容可能な伝送レートが求められる。最後に送信機は、その伝送レートを計算されたレートに合わせて調整する。
ＴＣＰスループットを損失イベント・レートおよびtRTTの関数として求める現実的な推定式は、ＴＦＲＣでの使用に適している場合もある。ただし、使用されるＴＣＰスループット推定式は、ＴＣＰの再送信タイムアウトの動作を反映する必要がある。これがより高い損失率でＴＣＰスループットを支配しているためである。損失イベント・レートのパラメータに関するスループット推定式における暗黙的な仮定は、損失率または損失イベント・レートが実際に測定される方法との適度な一致である。この一致は、以下に示すスループット推定式および損失率測定機構に対して完全ではないが、実際には、この仮定が十分に近似であることが判明する。スループット推定式は、次のとおりである。
Figure 2004343698
この推定式において、Xcalcはバイト／秒単位の伝送データ・レートであり、sはバイト単位のパケット・サイズを示している。tRTTは秒単位のラウンドトリップ・タイムであり、pは、損失イベントの数を伝送されたパケットの数で割った損失イベント・レートで、０〜１．０の値をとる。損失イベント・レートpの正確かつ安定した測定値を得ることは、ＴＦＲＣにとって最も重要である。損失率の測定は、到達パケットのシーケンス番号からの失われたまたはマークされたパケットの検出に基づいて、受信機において行なわれる。
bは、単一のＴＣＰ肯定応答によって確認されたパケットの数である。ほとんどのＴＣＰ実施態様では、bに２の値をもたらす遅延肯定応答を使用しないので、この数は１に設定することもできる。tRTOは、秒単位のＴＣＰ再送信タイムアウト（ＲＴＯ）値を表している。式はさらに、tRTO= 4×tRTTと設定することで簡略化することができる。tRTOをより正確に計算することも可能であるが、現在の設定で試みたところ、結果として既存のＴＣＰ実施態様で適度な公平性が得られた。もう１つの可能性としては、tRTO= max(4×tRTT, one second)と設定して、再送信タイムアウトで１秒の推奨最小値に適用する方法もある。
図２は、ストリーミング・アプリケーションの従来の使用シナリオを示している。メディア・サーバは、ＵＭＴＳネットワークなどのネットワーク内に位置しており、たとえば要求元のＵＭＴＳクライアント（モバイル端末）にストリーミング・サービスを提供する。ＴＦＲＣレート制御機構において、メディア・サーバから宛先端末またはクライアントに送信されるデータ・パケットは、サーバによる推定ラウンドトリップ・タイムtRTT、伝送されたデータ・パケットの順序を識別するためのシーケンス番号SNi、およびパケットが送信された時刻を示すタイムスタンプtsiなどの情報を含んでいる。
図３は、ＴＦＲＣの例示的な実施態様におけるメディア・サーバ２１および宛先端末２６のエンティティを示している。メディア・サーバ２１は、ＴＦＲＣおよびレート制御セクション２４、ＲＴＰエンティティ２２、および対応するＲＴＣＰエンティティ２３を含んでいるが、両エンティティは通信エンドポイント間のデータ・フローを明らかにするために示されている。宛先端末２６は、これらのエンティティの同等物、ＲＴＰエンティティ２７およびＲＴＣＰエンティティ２８を含んでいる。さらに、宛先端末は、受信データ・パケットを保存するためのバッファ２９を含んでいる。
フィードバック・パケットは、宛先端末２６のＴＦＲＣエンティティ２５において形成され、測定され計算された損失イベント・レートp、宛先端末の推定受信データ・レートXrecv、サーバでの処理遅延tdelayおよびメディア・サーバから受信した最後のデータ・パケットのタイムスタンプtrecvdataなどのパラメータを含んでいる。
メディア・サーバ２１において、フィードバック・パケットに含まれているパラメータの値は、ＴＦＲＣおよびレート制御セクション２４でスループット推定式に「差し込まれ（plugged）」、その結果はメディア・サーバ２１によって使用される新しい送信データ・レートを表す。データ・レートが高くなりすぎることを防ぐため、この式には示されていないがもう１つのパラメータが、新しい伝送データ・レートが決定するごとに毎回使用される。このパラメータは、前述した宛先端末の推定受信データ・レートXrecvである。最後に、メディア・サーバ２１は、ＲＴＰエンティティ２４で計算されたレートと一致するようにその伝送レートを調整する。
ＴＦＲＣは、ＲＴＰのような信頼性の高くないトランスポート・プロトコルを介して、同じリンクを共有する他のＴＣＰ接続に対して公平な方法で、ビデオ・ストリーミングなどのストリーミング・サービスを提供するサーバのビットレートを制御するために開発されたもので、これは受信したストリーム・メディアの品質を著しく劣化させるような急激なレートおよび遅延の変動をもたらすことはない。
しかしながら、ＴＦＲＣは、何らかの処理タスクを実行することおよびそれらの処理結果を標準外で現在のところ存在していないメッセージを用いてやり取りすることをサーバおよびクライアントの両方に要求する実施態様を独自に指定している。
さらに、限られた計算能力、限られたメモリ容量、および限られた供給電力を備えるクライアントのような、シン・クライアントを含むストリーミングシナリオにおいては、クライアントがＴＦＲＣによって推奨されるレート制御方式を実施するためにさらなるリソースを費やすことは望ましくない。加えて、たとえば無線リンクのような低ビットレートで損失の大きいリンクを持つストリーミング環境でＴＦＲＣを実施するときの、ＴＦＲＣに伴うシグナリング・オーバヘッドも望ましくない。
したがって、本発明の目的は、メディア・ストリーミング環境においてレート制御を、メディア・サーバからマルチメディア・データ・ストリームを受信する宛先端末に透過的な方法で提供することである。
この目的は、独立クレームに記載の本発明によって達成される。好ましい実施の形態は、その従属クレームに対する主題である。
有利なことに、前述のスループット推定式を用いて伝送データ・レートを計算するために使用するすべての必要な処理とパラメータの決定とは、メディア・サーバに収集されまたは決定される。そのため、クライアントの処理負荷が軽減される、つまりレート制御が宛先端末に透過的となる。したがって、もはや宛先端末が、ラウンドトリップ・タイムtRTTおよび損失イベント・レートpなどのパラメータを計算しメディア・サーバに伝達する必要はなくなる。さらに、データ配信に使用される標準マルチメディア・ストリーミング・プロトコルおよびデータ配信の制御に使用されるセッション制御プロトコルに拡張を施す必要はない。本発明において、既存のプロトコル・メッセージがメディア・サーバに採用され、伝送データ・レートの計算に必要なパラメータを導き出すからである。
本発明の実施の形態において、メディア・サーバおよび宛先端末を含むセッションベースのストリーミング環境においてマルチメディア・データ・ストリームの伝送データ・レートを制御する方法であって、セッション制御プロトコルがマルチメディア・データ・ストリームを制御するために採用される方法を提供する。この方法は、メディア・サーバにおいて実行される。そして、マルチメディア・ストリーミング・プロトコルに従ってメディア・サーバから宛先端末にマルチメディア・データ・ストリームを伝送するステップと、セッション制御データを宛先端末から受信するステップと、セッション制御データに基づいてマルチメディア・データ・ストリームのデータ・レート値を計算するステップと、計算されたデータ・レート値に基づいてマルチメディア・データ・ストリームのデータ・レートを制御するステップとを含んでいる。
データ・レート値の計算に必要なパラメータを有利に決定できるようにするために、セッション制御データは、マルチメディア・データ・ストリームの伝送に採用されているデータ・パケットの損失を報告するためのタイムスタンプおよび／またはパケット損失報告を含むことができる。
データ・レート値を計算するため、メディア・サーバは、受信したタイムスタンプおよびパケット損失報告ブロックに基づいてメディア・サーバと宛先端末との間の損失イベント・レートおよびラウンドトリップ・タイムを先ず計算することができる。次いで、損失イベント・レートおよびラウンドトリップ・タイムに基づいて、メディア・サーバはデータ・レート値を計算することができる。
メディア・サーバが、データ・レート値の計算にあたって、マルチメディア・データ・ストリームの伝送に使用されるデータ・パケットのサイズを使用する場合は、さらに有利である。
マルチメディア・データ・ストリームを宛先端末に伝送する前に、メディア・サーバはセッションを初期化することができる。セッションを初期化するために、メディア・サーバは報告間隔情報を宛先端末に伝送し、そこで宛先端末からメディア・サーバへのセッション制御データの伝送の時間間隔が報告間隔情報に基づいて決定される。
本発明の他の実施の形態において、セッション制御データは、ＲＴＰ／ＲＴＣＰ仕様に従って宛先端末からメディア・サーバに送信される受信側報告と、パケット損失率を報告するために宛先端末からメディア・サーバに送信される拡張報告と、に含まれる。報告間隔情報は、前記受信側報告の数と前記拡張報告の数の比率を決める報告比率情報を含むことができる。
マルチメディア・データ・ストリームおよびセッション制御データは、データ・パケットで伝送され、データ・パケットはシーケンス番号を含み、さらに、伝送時間と宛先端末に伝送されたデータ・パケットのシーケンス番号とをメモリに保存するステップを含んでいる。
さらに、本発明の実施の形態においては、宛先端末でのバッファの充てん状態を推定することが可能であり、このバッファは受信したマルチメディア・データ・ストリームを格納するために使用される。これにより、メディア・サーバは、推定された充てん状態がバッファ・アンダーランの可能性を示す場合に、マルチメディア・データ・ストリームのデータ・レートを大きくすることも、また推定された充てん状態がバッファオーバーフローの可能性を示す場合は、マルチメディア・データ・ストリームのデータ・レートを小さくすることもできるようになる。
有利なことに、マルチメディア・ストリーミング・プロトコルは、リアルタイムトランスポートプロトコル（ＲＴＰ）であってもよく、セッション制御プロトコルはＲＴＰ制御プロトコル（ＲＴＣＰ）であってもよい。これらのプロトコルを使用すると、データ・レート値を計算するために使用するセッション制御データは、受信側報告、損失報告ブロック、受信側タイムスタンプ報告ブロック、および受信側報告後遅延ブロック遅延の少なくとも１つに含まれる。本発明のこの実施の形態において、セッション制御データは、ＲＴＣＰ仕様に従って伝送されるＲＴＣＰデータ・メッセージに対応する。
本発明の他の実施の形態において、メディア・サーバおよび宛先端末を含むセッションベースのストリーミング環境におけるマルチメディア・データ・ストリームの伝送データ・レートを制御するためのメディア・サーバであって、セッション制御プロトコルがマルチメディア・データ・ストリームを制御するために採用されるメディア・サーバを提供する。このメディア・サーバは、マルチメディア・ストリーミング・プロトコルを使用してメディア・サーバから宛先端末へマルチメディア・データ・ストリームを伝送するための伝送手段と、宛先端末からセッション制御データを受信するための受信手段と、セッション制御データに基づいてマルチメディア・データ・ストリームのデータ・レート値を計算するための計算手段と、計算されたデータ・レート値に基づいてマルチメディア・データ・ストリームのデータ・レートを制御するための制御手段とを含んでいる。メディア・サーバは、前述のレート制御方法を実行するように適用される。
本発明の他の実施の形態では、本発明に係るメディア・サーバとの通信を行なうように適用された宛先端末を提供する。宛先端末は、セッション制御データの伝送の時間間隔および／またはセッション制御データの伝送の比率が決定される報告間隔情報をメディア・サーバから受信するための受信手段と、報告間隔に基づいてセッション制御データをメディア・サーバに伝送するための伝送手段とを含んでいる。
宛先端末はさらに、受信したマルチメディア・データ・ストリームを格納するためのバッファを含んでいる。
本発明は、少なくとも１つのメディア・サーバおよび少なくとも１つの宛先端末を含むメディア・ストリーミング・システムにおいて有利に使用される。
本発明によれば、メディア・ストリーミング環境において、メディア・サーバからマルチメディア・データ・ストリームを受信する宛先端末に透過的な方法でレート制御を提供することができる。
ＴＦＲＣ仕様において、既定の実装では、サーバおよびクライアントがマルチメディア・サーバによって配信されるマルチメディア・ストリームの伝送データ・レートの偏差に対して必要なパラメータの値を見つけ出すために情報を交換する必要があることが記載されている。本発明は、ストリーミング・アプリケーション向けの完全にサーバベースのＴＦＲＣレート制御を開示する。
本発明の実施の形態は、２００２年１１月のT. FriedmanらによるＩＥＴＦインターネットドラフト"RTCP Feedback Extensions"で提案されているフィードバック拡張を使用し、ＲＴＰ／ＲＴＣＰプロトコルに従って説明される。ただし、本発明はこれらの実施の形態に限定されることはない。
一実施の形態において、本発明は、メディア・サーバと宛先端末との間のマルチメディア・データ・ストリームの伝送にマルチメディア・ストリーミング・プロトコルを採用する。一般に、マルチメディア・ストリーミング・プロトコルは、音声、映像、またはシミュレーション・データなどのリアルタイム・データを伝送するアプリケーションに適したエンドツーエンドのネットワーク・トランスポート機能を提供する。
マルチメディア・ストリーミング・プロトコルは、セッション制御データを交換するセッション制御プロトコルによって増強され、メディア・サーバと宛先端末との間のマルチメディア・データ・ストリームを制御する。セッション制御プロトコルにより、大規模マルチキャスト・ネットワークに拡張可能な方法でデータ配信を監視し、最小限の制御および識別機能を提供することができる。マルチメディア・ストリーミング・プロトコルおよびセッション制御プロトコルは、基礎をなすトランスポート層およびネットワーク層から独立するように設計され、トランスレータおよびミキサーの使用をサポートすることができる。
通常、ストリーミング・セッションは、たとえば、マルチメディア・データ・ストリームが伝送される前にリアルタイムストリーミングプロトコル（ＲＴＳＰ）を使用してセットアップされる。このプロトコルは、ストリーミング・セッションの通知、記述、セットアップ、開始、停止および分解に使用される一連の基本要素を規定する。ＲＴＳＰと共にセッション記述プロトコル（ＳＤＰ）が使用されることもある。その後、ストリーミングされるメディアの記述用の言語を規定する。
セッションは、単一の接続の時間中に生じる２つの通信エンドポイント間の一連の対話として定義することができる。通常、一方のエンドポイントがもう一方の指定されたエンドポイントとの接続を要求し、そのエンドポイントが接続に合意して応答すると、両エンドポイントは交代でコマンドおよびデータを交換する。このセッションは両エンドにおいて接続が確立されると開始され、接続が終了するとセッションも終了する。
ここで図を参照すると、図１には、本発明に係るストリーミング環境の使用のシナリオの実施の形態が示されている。メディア・サーバ３１は、たとえば図２に示されるＵＭＴＳネットワークのようなネットワークを通じて宛先端末３６に接続されている。より詳細には、メディア・サーバ３１は、ＲＴＰエンティティ３２および対応するＲＴＣＰエンティティ３３を含んでいるが、これらはメディア・サーバ３１と宛先端末３６との間のデータ・フローを図示するために使用される。さらに、レート制御部３４およびバッファ推定部３５も、メディア・サーバ３１に含まれている。メディア・サーバ３１内のレート制御部３４は、宛先端末３６に配信されるマルチメディア・データ・ストリームの伝送のために計算された伝送データ・レートを使用するようＲＴＰエンティティ３２に指示する。レート制御部３４は、伝送データ・レートの計算に必要な情報を取得するため、ＲＴＣＰエンティティ３３およびバッファ推定部３５に接続される。宛先端末３６は、データ・フローのエンドポイントとしてＲＴＰエンティティ３７および対応するＲＴＣＰエンティティ３８を含んでいる。さらに宛先端末３６は、ＲＴＰパケットの順序が狂って受信されても再配置できるように、受信したＲＴＰパケットを一時的に保存するため、および上位層のアプリケーションまたは復元プログラムにＲＴＰパケットを供給するために、バッファ３９を含むことができる。
メディア・サーバ３１は、たとえばＭＰＥＧ４、ＡＭＲなどを使用して符号化されたＲＴＰカプセル化メディア・パケットを伝送する。さまざまな種類のメディアフォーマットに対するペイロードフォーマット規定が存在する。たとえば、RFC 3016（"RTP Payload Format for MPEG-4 Audio/Visual Streams", Y. Kikuchi他, IETF, 2000年11月を参照）では、ＲＴＰパケットでＭＰＥＧ４音声および映像をカプセル化する方法について説明している。
以下、メディア・サーバ３１の動作についてさらに詳細に説明する。メディア・サーバ３１は、パケットiがメディア・サーバ３１によって伝送された時刻を示すタイプスタンプ値tsiを、たとえばリストまたはハッシュ・テーブルなどのパケットiのシーケンス番号SNiと共に保存する。そのため、タイムスタンプtsiは異なっているので、ＲＴＰパケット自身にあるタイムスタンプと混同されることはない。保存された情報は、パケット損失率pを決定し、ＲＴＰデータ・パケットのラウンドトリップ・タイムtRTTを推定するためにメディア・サーバ３１のレート制御部３４によって使用される。
本発明の一実施の形態によれば、ＴＦＲＣのプロトコル規定と対照的に、pの計算が受信側（宛先端末３６）ではなくメディア・サーバ３１において行なわれることを認識することが重要である。したがって、メディア・サーバ３１は、損失履歴を保持し、損失を損失イベントにマッピングすることもできる。これは、宛先端末３６によって報告される損失を正しい時間間隔にマッピングし、各パケットiの保存されている伝送時間tsiをパケットのシーケンス番号SNiと共に用い、ＴＦＲＣに規定されているように損失イベント・レートpを計算することによって、達成される。これは、損失イベント・レートpを計算する好ましい方法であるが、損失イベント・レートpを決定する方法は他にもあることに留意されたい。
パケット損失は、ＲＴＣＰエンティティ３８を使用することにより、宛先端末３６によって報告される。Friedmanらによって定義されているようにＲＴＣＰフィードバックへの拡張により、伝送中に失われたＲＴＰパケットを指定することができる。たとえば、損失ＲＬＥ報告ブロック（Loss RLE Report Block）により個々のパケット受信および損失イベントに関する詳細な報告が可能になる。損失または受信したＲＴＰパケットのブール・トレースは冗長なものになる可能性があるので、このブロック・タイプによりランレングス符号化を通じてトレースを圧縮することができる。
各ブロックは、その同期ソース識別子（ＳＳＲＣ）によって識別される単一ソースについて報告する。報告を供給している宛先端末３６は、ＲＴＣＰパケットのヘッダーで識別される。トレースの開始および終了ＲＴＰパケットのシーケンス番号は、終了シーケンス番号がトレース内の最後のシーケンス番号に１を加えたものになるようにブロック内で指定される。
したがって、メディア・サーバ３１は、伝送中に失われたパケットのシーケンス番号を判別することができる。シーケンス番号SNiをある特定の時、つまり伝送時刻にマッピングしている保存情報を用い、保存されたタイムスタンプtsiを使用することにより、メディア・サーバ３１はＴＦＲＣ仕様によって使用される損失間隔Iiを決定することができる。損失間隔Iiが決まると、HandleyらによってRFC 3448に示されている規定および式に従って、メディア・サーバ３１のレート制御部３４において損失イベント・レートpが計算される。
さらに、ＲＴＣＰ送信側報告（ＳＲ）が、宛先端末３６のＲＴＣＰエンティティ３８によって送信される受信側報告（ＲＲ）と共に使用され、計算された伝送データ・レートXcalcの計算に対してラウンドトリップ・タイムtRTTを推定する。受信した最後の２つの報告間の相違は、マルチメディア・データ・ストリームの配信の最近の品質を推定するために使用することができる。ＮＴＰタイムスタンプは、受信側報告および送信側報告に含まれており、２つの報告間の間隔にわたるこれらの相違からデータ・レートを計算できるようになっている。さらに、送信側報告および受信側報告のタイムスタンプを用いて、メディア・サーバ３１と宛先端末３６の間のラウンドトリップ・タイムtRTTを決めることができる。
Friedmanらによって提案されているフィードバック拡張を用いると、受信側タイムスタンプ報告ブロック（Receiver Timestamp Report Blocks）が、いわゆる受信側報告後遅延（DLRR: Delay since Last Receiver Report）報告ブロックと共に使用されている場合、宛先端末３６のＲＴＣＰエンティティ３８のラウンドトリップ・タイムtRTTを正確に推定することができる。これらのブロックは、送信側以外でもタイムスタンプを送信できるように、ＲＴＣＰのタイムスタンプ報告を拡張している。これは、ＲＴＣＰ送信側報告からのＮＴＰタイムスタンプ・フィールドを要約する。報告間隔がメディア・サーバ３１から宛先端末３６に、tRTTの関数としてではなく絶対値として与えられるので、宛先端末３６が常にラウンドトリップ・タイムを推定する必要はないことに留意されたい。
ＲＴＰデータ・パケットの平均パケット・サイズsがメディア・サーバ３１に認識されているので、レート制御部３４において上記のスループット推定式を使用して適切な伝送データ・レートXcalcを計算するために必要なパラメータはメディア・サーバ３１で入手可能である。そのため、伝送データ・レートXcalcを決定する処理の全体を、本発明の実施の形態に示すメディア・サーバ３１において行なうことができる。したがって、本発明の実施の形態により、メディア・サーバ３１において、宛先端末３６に対して透過的な方法でマルチメディア・ストリームの伝送データ・レートを制御することができる。
宛先端末３６は、メディア・サーバ３１からの受信ＲＴＰパケットをデカプセル化して、それをバッファ３９に転送する必要がある。これは、ＲＴＰパケットの順序が狂って受信されていた場合にシーケンス番号SNiに基づいてＲＴＰパケットを再配置するために使用され、またメディア・データが上位層の表示アプリケーションまたは復元プログラムに転送されるまでＲＴＰパケットの情報を一時的に保管するために使用される。さらに、宛先端末３６のＲＴＰエンティティ３７は、受信したＲＴＰパケットのシーケンス番号SNiの欠落部分によって損失したＲＴＰパケットを検出する。
ＲＴＣＰエンティティ３８は、損失および確認応答されたパケットについて報告するために使用される。標準ＲＴＣＰメッセージ（受信側報告および送信側報告）は、ＲＴＰ（"RTP: A Transport Protocol for Real-Time Applications", Schulzrinne他, IETF, RFC 1889, 1996年1月を参照）で規定されているように、tRTTを計算するためにメディア・サーバによって使用される。受信パケットおよび損失パケットについて報告する好ましい方法では、Friedmanらによって規定されているように拡張報告（特に損失ＲＬＥ報告ブロック）を使用する。ただし、本発明は、この報告方法に限定されるものではなく、受信および損失ＲＴＰパケットについて報告する代替方法もあることに留意されたい。
宛先端末３６およびメディア・サーバ３１は、ＲＴＰ／ＲＴＣＰ標準に規定されているＲＴＣＰパケットの５秒以上の規則を順守しなくともよい。ＲＴＣＰパケットは、割り当てられたＲＴＣＰ帯域を超えない限りいつでも送信することができる。
さらに、宛先端末３６は、報告間隔についての情報を受け取ることもできる。報告間隔は、メディア・サーバ３１が宛先端末３６にフィードバックを提供することを予測している間隔である。これにより報告間隔は、セッション・セットアップ中に伝達されるが、これについては以下でさらに詳細に説明する。伝達された情報は、たとえば、メディア・サーバと宛先端末の間のtRTTの関数として、または絶対値として表される。
ＴＦＲＣ規定によって提案されているレート制御のサーバベースの実施の形態を提供するために、メディア・サーバ３１はさらに受信レートXrecvを計算することができる。これは、マルチメディア・データ・ストリームを搬送するＲＴＰパケットが宛先端末３６によって受信されるデータ・レートを示し、ＴＦＲＣ仕様のメディア・サーバによって計算される。Xrecvの計算は、ＲＴＰパケットが送信された時間間隔にわたって報告された受信ＲＴＰパケットを明らかにすることによりメディア・サーバ３１において達成される。この場合も同様に、保存されているタイムスタンプtsiおよびメディア・サーバ３１によって記録されている関連シーケンス番号SNiを使用して、ＴＦＲＣ仕様とほぼ同様の方法で受信側データ・レートXrecvの推定値を決めることができる。
前述したように、本発明の実施の形態に係るメディア・サーバ３１は、ＴＦＲＣ方式の原則に従いレート制御部３４において適切な伝送データ・レートを計算するための、メディア・サーバ３１と宛先端末３６間のＲＴＰ／ＲＴＣＰトラフィック・フローからすべての必要な情報を収集することができる。レート制御部３４においてマルチメディア・データ・ストリームの適切な伝送データ・レートを決定した後、メディア・サーバは計算された伝送データ・レート値に従って伝送データ・レートを適用するようＲＴＰエンティティ３２に指示する。本発明の実施の形態によれば、伝送データ・レート制御を提供するために宛先端末３６に「ＴＦＲＣ同等物」（図３のＴＦＲＣエンティティ２５と比較）が必要ないことに留意することが重要である。
ＲＴＰエンティティ３２は、伝送データ・レートの変化をアプリケーション層、つまりマルチメディア・データ・ストリームを提供するアプリケーションに報告することができる。マルチメディア・データ・ストリームを提供しているアプリケーションは、音声および／または映像のストリームのビットレートを変化させることにより伝送データ・レートを上下させて、新しく計算された伝送データ・レート値に適合させる。
さらに他の実施の形態において、メディア・サーバ３１はさらにバッファ推定部３５を含むことができる。バッファ推定部３５は、宛先端末の再生バッファ３９の充てん状態を推定するために使用される。メディア・サーバ３１の伝送データ・レートを、バッファ・アンダーランを防ぐために上げたり、バッファオーバーフローを防ぐために下げたりすることができるように、メディア・サーバ３１内のバッファ推定部３５が宛先端末３６の再生バッファ３９の状態を認識していることが重要である。ＲＴＰパケットがＲＴＰエンティティ３２によって送信されるたびに、パケット・データがフルサイズでバッファ３９に挿入される。理想的な条件下では、各ＲＴＰパケットは、tRTT/2とほぼ等しい時間が経過した後に宛先端末３６に到達する。
さらに、ネットワーク・ジッターの影響ならびに宛先端末３６での再配置およびデコードによる遅延を緩和するためには、多少の時間が必要となるかもしれない。この追加時間は、以下でtjit_decと呼ぶ。時間tdel = tRTT/2 + tjit_decが経過した後、バッファ推定部３５は、パケットが宛先端末３６で処理され、バッファ３９から削除されていると想定する。
ＲＴＣＰ送信側報告の着信間ジッター・フィールドは、ネットワーク輻輳の第２の短期的測定を提供する。パケット損失測定は持続的な輻輳を追跡し、ジッター測定は一時的な輻輳を追跡する。ジッター測定は、パケット損失に至る前に輻輳を指摘する。ＲＴＣＰ受信側報告の着信間ジッター・フィールドは報告時点におけるジッターのスナップショットに過ぎないので、たとえば単一ネットワーク内の、一受信側装置からの経時的な複数の、または複数受信側装置からの報告を分析することが必要になる。
損失パケットに対する再送は発行されないので、宛先端末３６に大量の再生バッファ３９は必要ないことに留意されたい。再送が使用された場合には、tdelをtrtx = (再送の回数)・tRTTずつ、つまり各パケットの望ましい再送の最大数だけ増やす必要がある。
前述のように、ＲＴＰパケットはほぼtjit_decの時間で処理される。宛先端末３６のバッファ３９はさらに、ネットワーク・ジッターおよびデコーダ処理遅延を緩和するために使用される。再送が使用される場合、このバッファ３９のサイズはtrecv_buffer = tjit_dec+ (再送の回数)・tRTTに対応する。ここで、tRTTは、前述のようにメディア・サーバ３１によってではなく、宛先端末３６によって計算されたラウンドトリップ・タイムである。この相違は、わずかなものと見なすことができるので、無視することができる。
本発明のさらに他の実施の形態によれば、マルチメディア・データ・ストリームが伝送される前に、ストリーミング・セッションが通常、リアルタイムストリーミングプロトコル（ＲＴＳＰ）を使用して設定される。このプロトコルは、ストリーミング・セッションの通知、記述、セットアップ、開始、停止、分解に使用される一連の基本要素を規定する。ＲＴＳＰと共にセッション記述プロトコル（ＳＤＰ）が使用されることもある。ＳＤＰは、ストリーミングされているメディアの記述のための言語を規定する。
アルゴリズムが適切に機能するために、セッションのセットアップ時に一部の情報が交換される。宛先端末３６は、メディア・サーバ３１にフィードバック・メッセージ（受信側報告および損失報告の両方）が送信される頻度を認識している必要がある。報告間隔が、セッションの初期化のために伝達される場合もある。本発明の実施の形態において、標準ＲＴＣＰパケット（tRTTの計算に使用される送信側報告および受信側報告）および拡張報告パケット（ＸＲ、損失報告の場合）が送信される。したがって、報告帯域は、標準ＲＴＣＰパケットと拡張報告パケット（伝達された報告間隔によって与えられる）の間で共有される。
さらに本発明の他の実施の形態において、たとえば、損失報告に対する受信側報告（または送信側報告）あるいは拡張報告パケットの頻度を下げることによって、異なる帯域の共用規則を指定することも可能である。たとえば、３つの損失報告を送信した後に１つの受信側報告が送信されるようにすることもできる。帯域共有を指定するための方法は、たとえば以下に説明するような方法で、ＳＤＰの追加属性を使用して実装することもできる。この実施の形態により、送信される標準ＲＴＣＰパケットおよび拡張報告パケットの合計数の比率を指定して前述の報告間隔を規定することができる。
報告間隔は、ＳＤＰプロトコルに従い報告間隔情報を使用してメディア・サーバ３１から宛先端末３６に伝送される。以下にセッション・セットアップの例を示す。この例において、「ＤＴ」は宛先端末３６、「ＭＳ」はメディア・サーバ３１の略である。
DT->MS: DESCRIBE rtsp://foo/twister RTSP/1.0
CSeq: 1

MS->DT: RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 164

v=0
o=- 2890844256 2890842807 IN IP4 172.16.2.93
s=RTSP Session
i=An Example of RTSP Session Usage
a=control:rtsp://foo/twister
t=0 0
m=audio 0 RTP/AVP 0
a=control:rtsp://foo/twister/audio
-----> a=X-reporting-interval:0 3
-----> a=X-reporting-ratio:0 RR=1;XR=1
m=video 0 RTP/AVP 26
a=control:rtsp://foo/twister/video
-----> a=X-reporting-interval:26 3
-----> a=X-reporting-ratio:26 RR=1;XR=1


DT->MS: SETUP rtsp://foo/twister/audio RTSP/1.0
CSeq: 2
Transport: RTP/AVP;unicast;client_port=8000-8001

MS->DT: RTSP/1.0 200 OK
CSeq: 2
Transport: RTP/AVP;unicast;client_port=8000-8001;
server_port=9000-9001
Session: 12345678

DT->MS: SETUP rtsp://foo/twister/video RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8002-8003
Session: 12345678

MS->DT: RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8002-8003;
server_port=9004-9005
Session: 12345678

DT->MS: PLAY rtsp://foo/twister RTSP/1.0
CSeq: 4
Range: npt=0-
Session: 12345678

MS->DT: ....
以上の例から分かるとおり、マークの付いた行は、報告間隔を初期化するために必要な報告間隔情報を示している。行
m=audio 0 RTP/AVP 0
は、番号０を音声に使用されるペイロードタイプ（符号化）にマップする。また、行
m=video 0 RTP/AVP 26
は、番号２６を映像ペイロードタイプにマップする。行
a=X-reporting-interval:0 3
および
a=X-reporting-interval:26 3
における番号３は、音声および映像の報告間隔がラウンドトリップ・タイム値の３倍であることを示している。
X-reporting-ratioの属性を含む行は、受信側報告および拡張報告の比率を報告比率情報として示している。この場合では、両報告がＲＴＣＰ帯域を公平に共有している。
a=X-reporting-ratio:0 RR=1;XR=1
ただし、次の例
a=X-reporting-ratio:0 RR=1;XR=2
においては、拡張報告（ＸＲ）は受信側報告（ＲＲ）の２倍の頻度で送信される。
報告間隔を伝達するための別の方法もあることに留意されたい。さらにもう１つの方法としては、ＲＴＣＰ帯域変更子を使用することが挙げられる。
このＲＴＰ仕様により、ＲＴＣＰ帯域が、アクティブなデータ送信側装置たるものとそうでないものに対して２つの別々のセッション・パラメータに分割されるように、プロファイルを指定することができる。２つのパラメータを使用することで、データ以外の送信側のＲＴＣＰ帯域をゼロに設定し、データの送信側のＲＴＣＰ帯域を非ゼロに設定して、送信側報告が引き続きメディア間同期化のために送信されるようにすることにより、特定のセッションに対してＲＴＣＰ受信報告を完全にオフにすることができる。これは、単一方向リンクで動作しているシステムまたは受信の品質に関するフィードバックを必要としないセッションに適している。
セッション記述プロトコル（ＳＤＰ）は、次の構文を持つオプションの帯域属性を含んでいる。
b=<modifier>:<bandwidth-value>
ここで<modifier>は、帯域の数値の意味を示す単一の英数字の語であり、<bandwidth-value>のデフォルトの単位はキロビット／秒である。この属性は、セッションまたはメディアによって使用される提案帯域を指定する。
代表的なものは、変更子「ＡＳ」（Application Specific Maximumの略）を使用するもので、これはメディア・サーバ３１からの単一のメディア・ストリームの合計帯域を指定するために使用される。さらに２つの帯域変更子が、宛先端末３６の報告間隔を制御するために使用されることがある。
b=RS:<bandwidth-value>
b=RR:<bandwidth-value>
ここで「ＲＳ」は（ＲＴＰ仕様によって規定されているように）アクティブなデータ送信側装置に割り当てられているＲＴＣＰを示し、「ＲＲ」はＲＴＰセッションの他の参加者（宛先端末など）に割り当てられているＲＴＣＰ帯域を示している。帯域割り当ては、送信側報告、受信側報告、ＳＤＥＳ、ＢＹＥ、ＡＰＰ、拡張報告（ＸＲ）、さらに今後規定される新しいタイプを含むすべてのＲＴＣＰパケット・タイプによって消費された合計帯域に適用される。これらの変更子に対する<bandwidth-value>は、ビット／秒単位の整数値である。
これらの帯域変更子は、本発明の他の実施の形態における報告間隔情報を表すもので、宛先端末３６のＲＴＣＰトラフィックに割り当てられているＲＴＣＰ帯域を制限するために使用される。このことは、受信側報告および他のメッセージがこの新しい値によって与えられる周波数でしか送信されないことを意味している。ＲＴＰの組み込みアルゴリズムは、この所定のＲＴＣＰ帯域を使用し、報告間隔を自動的に計算することができる。したがって、実装者は、相応して望ましい報告間隔に集束するＲＴＣＰ帯域値を割り当てることができる。
本発明に係るストリーミング環境の使用シナリオの実施の形態を示す図 ストリーミング環境の従来の使用シナリオの例を示す図 メディア・サーバおよび宛先端末における従来のＴＦＲＣの実施の形態を示す図
符号の説明
３１ メディア・サーバ
３２ ＲＴＰエンティティ
３３ ＲＴＣＰエンティティ
３４ レート制御部
３５ バッファ推定部
３６ 宛先端末
３７ ＲＴＰエンティティ
３８ ＲＴＣＰエンティティ
３９ バッファ

Claims (19)

  1. メディア・サーバおよび宛先端末を含むセッションベースのストリーミング環境においてマルチメディア・データ・ストリームの伝送データ・レートを制御するための方法であって、セッション制御プロトコルが、マルチメディア・データ・ストリームを制御するために採用され、
    マルチメディア・ストリーミング・プロトコルに従ってメディア・サーバから宛先端末へマルチメディア・データ・ストリームを伝送するステップと、
    宛先端末からセッション制御データを受信するステップと、
    セッション制御データに基づいてマルチメディア・データ・ストリームのデータ・レート値を計算するステップと、
    計算されたデータ・レート値に基づいてマルチメディア・データ・ストリームのデータ・レートを制御するステップと、を含み、メディア・サーバにおいて実行される方法。
  2. セッション制御データが、マルチメディア・データ・ストリームの伝送に用いられるデータ・パケットの損失を報告するためのタイムスタンプまたはパケット損失報告ブロックもしくはタイムスタンプおよびパケット損失報告ブロックを含む、請求項１記載の方法。
  3. 計算のステップにおいて、メディア・サーバは、受信したタイムスタンプおよびパケット損失報告ブロックに基づいてメディア・サーバと宛先端末との間の損失イベント・レートおよびラウンドトリップ・タイムを計算する、請求項２記載の方法。
  4. 計算のステップにおいて、メディア・サーバは、損失イベント・レートおよびラウンドトリップ・タイムに基づいてデータ・レート値を計算する、請求項３記載の方法。
  5. メディア・サーバが、マルチメディア・データ・ストリームを伝送するために使用されるデータ・パケットのサイズに基づいてデータ・レート値を計算する、請求項４記載の方法。
  6. マルチメディア・データ・ストリームの伝送のためのセッションを初期化するステップをさらに含む、請求項１から請求項５のいずれかに記載の方法。
  7. 初期化のステップが、宛先端末への報告間隔情報の伝送を含み、宛先端末からメディア・サーバへのセッション制御データの伝送の間の時間間隔が報告間隔情報に基づいて決められる、請求項６記載の方法。
  8. セッション制御データが、ＲＴＰ／ＲＴＣＰ仕様およびパケット損失率を報告するために宛先端末からメディア・サーバに送信される拡張報告に従って、宛先端末からメディア・サーバに送信される受信側報告に含まれる、請求項７記載の方法。
  9. 報告間隔情報が、前記受信側報告の数および前記拡張報告の数の比率を決定する報告比率情報を含む、請求項７または請求項８記載の方法。
  10. マルチメディア・データ・ストリームおよびセッション制御データがデータ・パケットで伝送され、データ・パケットがシーケンス番号を含み、さらに宛先端末に伝送されるデータ・パケットの伝送時間およびシーケンス番号をメモリに保存するステップを含む、請求項１から請求項９のいずれかに記載の方法。
  11. 受信したマルチメディア・データ・ストリームを格納するために使用される、宛先端末におけるバッファの充てん状態を推定するステップと、
    推定された充てん状態がバッファアンダーランの可能性を示す場合、マルチメディア・データ・ストリームのデータ・レートを上げるステップと、
    推定された充てん状態がバッファオーバーフローの可能性を示す場合、マルチメディア・データ・ストリームのデータ・レートを下げるステップと、をさらに含む、請求項１から請求項１０のいずれかに記載の方法。
  12. マルチメディア・ストリーミング・プロトコルがリアルタイムトランスポートプロトコル（ＲＴＰ）であり、セッション制御プロトコルがＲＴＰ制御プロトコル（ＲＴＣＰ）である、請求項１１記載の方法。
  13. データ・レート値を計算するために使用されるセッション制御データが、受信側報告、損失報告ブロック、受信側タイムスタンプ報告ブロックおよび受信側報告後遅延ブロックの少なくとも１つに含まれる、請求項１２記載の方法。
  14. メディア・サーバおよび宛先端末を含むセッションベースのストリーミング環境においてマルチメディア・データ・ストリームの伝送データ・レートを制御するためのメディア・サーバであって、セッション制御プロトコルが、マルチメディア・データ・ストリームを制御するために採用され、
    マルチメディア・ストリーミング・プロトコルを使用してメディア・サーバから宛先端末へマルチメディア・データ・ストリームを伝送する伝送手段と、
    宛先端末からセッション制御データを受信する受信手段と、
    セッション制御データに基づいてマルチメディア・データ・ストリームのデータ・レート値を計算する計算手段と、
    計算されたデータ・レート値に基づいてマルチメディア・データ・ストリームのデータ・レートを制御する制御手段と、を含むメディア・サーバ。
  15. 請求項１から請求項１３のいずれかに記載のステップに従う方法を実行するように適用された、請求項１４記載のメディア・サーバ。
  16. 請求項１４または請求項１５記載のメディア・サーバとの通信を行なうように適用された宛先端末。
  17. セッション制御データの伝送の間の時間間隔および／またはセッション制御データの伝送の比率が決められる報告間隔情報をメディア・サーバから受信する受信手段と、
    報告間隔値に基づいてセッション制御データをメディア・サーバに伝送する伝送手段と、を含む、請求項１６記載の宛先端末。
  18. 受信したマルチメディア・データ・ストリームを格納するバッファをさらに含む、請求項１６または請求項１７記載の宛先端末。
  19. 請求項１４または請求項１５記載の少なくとも１つのメディア・サーバおよび請求項１６から請求項１８のいずれかに記載の少なくとも１つの宛先端末を含む、メディア・ストリーミング・システム。
JP2004042053A 2003-02-18 2004-02-18 マルチメディア・ストリーミング環境におけるサーバベースのレート制御 Expired - Fee Related JP3814614B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP03003162A EP1450514A1 (en) 2003-02-18 2003-02-18 Server-based rate control in a multimedia streaming environment

Publications (2)

Publication Number Publication Date
JP2004343698A true JP2004343698A (ja) 2004-12-02
JP3814614B2 JP3814614B2 (ja) 2006-08-30

Family

ID=32731519

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004042053A Expired - Fee Related JP3814614B2 (ja) 2003-02-18 2004-02-18 マルチメディア・ストリーミング環境におけるサーバベースのレート制御

Country Status (4)

Country Link
US (1) US20050005020A1 (ja)
EP (1) EP1450514A1 (ja)
JP (1) JP3814614B2 (ja)
CN (1) CN1543164A (ja)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008035514A (ja) * 2006-07-26 2008-02-14 Lg Electronics Inc 移動通信端末機によるメッセージ再生方法及び移動通信端末機
JP2011166380A (ja) * 2010-02-08 2011-08-25 Canon Inc 通信装置、通信方法、及びプログラム
JP2011259239A (ja) * 2010-06-09 2011-12-22 Sony Corp 通信処理装置、通信処理システム、通信処理方法及びプログラム
JP2013542629A (ja) * 2010-09-01 2013-11-21 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 局所的輻輳露出
WO2014064890A1 (ja) * 2012-10-24 2014-05-01 パナソニック株式会社 通信システム、受信端末、送信端末、および流量制御方法
US8773982B2 (en) 2010-06-16 2014-07-08 Panasonic Corporation Transmitting terminal and bandwidth estimating method
JP2016072679A (ja) * 2014-09-26 2016-05-09 日本電気株式会社 コンピュータネットワークシステム、サーバ、及び通信制御方法
WO2016189833A1 (ja) * 2015-05-25 2016-12-01 日本電気株式会社 無線基地局、パケット送信装置、及び無線端末、ならびにこれらの制御方法

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7796517B2 (en) * 2004-06-28 2010-09-14 Minghua Chen Optimization of streaming data throughput in unreliable networks
KR100640862B1 (ko) * 2004-08-03 2006-11-02 엘지전자 주식회사 순방향 메시지 전송 중 타임아웃의 동적 제어방법
GB2417391B (en) * 2004-08-18 2007-04-18 Wecomm Ltd Transmitting data over a network
US9621473B2 (en) 2004-08-18 2017-04-11 Open Text Sa Ulc Method and system for sending data
US7660366B2 (en) * 2004-08-30 2010-02-09 Harmonic Inc. Message synchronization over a stochastic network
WO2006054442A1 (ja) 2004-11-17 2006-05-26 Sharp Kabushiki Kaisha 送信装置、受信装置及び通信システム
CN100403794C (zh) * 2004-12-29 2008-07-16 华为技术有限公司 一种实现流媒体业务的视讯终端和方法
US7924714B2 (en) * 2005-01-11 2011-04-12 Panasonic Corporation Communication method and receiving terminal
TWI401918B (zh) * 2005-02-03 2013-07-11 Nokia Corp 傳送指示接收器緩衝架構之緩衝參數信號的通訊方法
US7430681B1 (en) * 2005-03-30 2008-09-30 Teradici Corporation Methods and apparatus for interfacing a drawing memory with a remote display controller
MX2007014744A (es) * 2005-05-24 2008-02-14 Nokia Corp Metodo y aparatos para transmision/recepcion jerarquica en transmision digital.
CN1870514A (zh) * 2005-05-28 2006-11-29 华为技术有限公司 会话服务质量分析的实现方法
US7769880B2 (en) * 2005-07-07 2010-08-03 Microsoft Corporation Carrying protected content using a control protocol for streaming and a transport protocol
US20070189186A1 (en) * 2006-02-14 2007-08-16 Memorylink Corporation Multiplexing of DS1 traffic across wired and wireless Ethernet devices
CN101438540A (zh) * 2006-05-12 2009-05-20 艾利森电话股份有限公司 呼叫接纳控制方法
CA2657617A1 (en) 2006-07-18 2008-01-24 Memorylink Corp. Multiplexing of ds1 traffic across wired and wireless ethernet devices
CN101174995B (zh) 2006-11-03 2010-05-12 中兴通讯股份有限公司 一种多媒体服务性能监测的方法和***
JP4189422B2 (ja) * 2006-11-14 2008-12-03 株式会社東芝 放送ｔｓ配信システム、このシステムに用いられる放送ｔｓ配信装置、ユーザ端末装置及び配信方法
CN100456678C (zh) * 2006-11-28 2009-01-28 华为技术有限公司 为不同类型的终端提供iptv业务的方法和iptv业务***
WO2008067388A1 (en) * 2006-11-29 2008-06-05 Johnson Controls Technology Company Adaptive buffer management for wireless connectivity system
CN101207798B (zh) * 2006-12-18 2010-06-16 中兴通讯股份有限公司 一种基于媒体服务器的视频变形实现方法
US8189616B2 (en) * 2007-01-18 2012-05-29 Telefonaktiebolaget L M Ericsson (Publ) Dividing RTCP bandwidth between compound and non-compound RTCP packets
US8379609B2 (en) * 2007-03-29 2013-02-19 Vixs Systems, Inc. Multimedia client/server system with adjustable data link rate and range and methods for use therewith
US7987285B2 (en) 2007-07-10 2011-07-26 Bytemobile, Inc. Adaptive bitrate management for streaming media over packet networks
US7991904B2 (en) * 2007-07-10 2011-08-02 Bytemobile, Inc. Adaptive bitrate management for streaming media over packet networks
CN101330748B (zh) 2007-07-31 2011-11-30 中兴通讯股份有限公司 一种ip多媒体子***集中业务会话控制路径的切换方法
CN101150763B (zh) * 2007-10-18 2012-06-06 中兴通讯股份有限公司 一种测试WiMAX网络实时传输业务性能的终端和方法
US20090135735A1 (en) * 2007-11-27 2009-05-28 Tellabs Operations, Inc. Method and apparatus of RTP control protocol (RTCP) processing in real-time transport protocol (RTP) intermediate systems
US20090135724A1 (en) * 2007-11-27 2009-05-28 Tellabs Operations, Inc. Method and apparatus of RTP control protocol (RTCP) processing in real-time transport protocol (RTP) intermediate systems
US7903562B2 (en) 2008-02-05 2011-03-08 Lockheed Martin Corporation Method and system for congestion control
KR100958013B1 (ko) * 2008-04-04 2010-05-17 에스케이 텔레콤주식회사 멀티미디어 스트리밍 서비스 제공 시스템 및 방법
WO2010032370A1 (ja) * 2008-09-19 2010-03-25 パナソニック株式会社 伝送レート制御装置及び伝送レート制御方法
US8009560B2 (en) * 2008-12-31 2011-08-30 Microsoft Corporation Detecting and managing congestion on a shared network link
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
US20100250764A1 (en) * 2009-03-31 2010-09-30 Nokia Corporation Method and Apparatus for Signaling Layer Information of Scalable Media Data
US20100250763A1 (en) * 2009-03-31 2010-09-30 Nokia Corporation Method and Apparatus for Transmitting Information on Operation Points
US9088630B2 (en) * 2009-07-13 2015-07-21 Qualcomm Incorporated Selectively mixing media during a group communication session within a wireless communications system
JP5506362B2 (ja) * 2009-12-15 2014-05-28 キヤノン株式会社 送信装置、送信方法
US8340126B2 (en) 2010-06-07 2012-12-25 Lockheed Martin Corporation Method and apparatus for congestion control
CN102137047B (zh) * 2011-03-21 2013-09-25 华中科技大学 一种多参数媒体适配网关及其适配方法
US9288251B2 (en) 2011-06-10 2016-03-15 Citrix Systems, Inc. Adaptive bitrate management on progressive download with indexed media files
CN103828324B (zh) 2011-06-10 2017-11-28 茨特里克斯***公司 用于自适应比特率管理的方法、设备和***
WO2013008053A1 (en) 2011-07-14 2013-01-17 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatuses for efficient battery utilization during content delivery in telecommunication networks
US9386127B2 (en) 2011-09-28 2016-07-05 Open Text S.A. System and method for data transfer, including protocols for use in data transfer
US9009220B2 (en) * 2011-10-14 2015-04-14 Mimecast North America Inc. Analyzing stored electronic communications
US9178778B2 (en) * 2012-03-23 2015-11-03 Avaya Inc. System and method for end-to-end RTCP
US9356917B2 (en) 2012-03-23 2016-05-31 Avaya Inc. System and method for end-to-end encryption and security indication at an endpoint
US9860296B2 (en) 2012-03-23 2018-01-02 Avaya Inc. System and method for end-to-end call quality indication
JP2014075736A (ja) * 2012-10-05 2014-04-24 Sony Corp サーバ装置および情報処理方法
KR102399082B1 (ko) * 2016-03-04 2022-05-17 삼성전자주식회사 적응적 스트리밍 서비스에서 데이터 버퍼링 방법 및 장치
TWI636689B (zh) * 2016-11-25 2018-09-21 財團法人工業技術研究院 影音串流傳輸率決定方法與伺服器
CN110166804B (zh) * 2018-02-11 2021-12-03 华为技术有限公司 实现视频业务的方法、设备、通信***及计算机可读存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6643496B1 (en) * 1998-03-31 2003-11-04 Canon Kabushiki Kaisha System, method, and apparatus for adjusting packet transmission rates based on dynamic evaluation of network characteristics
US6529475B1 (en) * 1998-12-16 2003-03-04 Nortel Networks Limited Monitor for the control of multimedia services in networks
AU2001277773A1 (en) * 2000-09-22 2002-04-02 Matsushita Electric Industrial Co., Ltd. Data transmitting/receiving method, transmitting device, receiving device, transmitting/receiving system, and program
US6996624B1 (en) * 2001-09-27 2006-02-07 Apple Computer, Inc. Reliable real-time transport protocol
DE60216887T2 (de) * 2002-02-13 2007-04-05 Matsushita Electric Industrial Co., Ltd., Kadoma Verfahren zur dynamischen Übertragung von Datenpaketen unter Verwendung von RTP und RTCP Protokollen
US7327708B2 (en) * 2002-04-25 2008-02-05 Inet Technologies, Inc. Multimedia traffic optimization
US7099954B2 (en) * 2002-06-27 2006-08-29 Microsoft Corporation Congestion control mechanism for streaming media

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008035514A (ja) * 2006-07-26 2008-02-14 Lg Electronics Inc 移動通信端末機によるメッセージ再生方法及び移動通信端末機
US8965345B2 (en) 2006-07-26 2015-02-24 Lg Electronics Inc. Mobile communication terminal and method for playing message in real time thereof
US8811180B2 (en) 2010-02-08 2014-08-19 Canon Kabushiki Kaisha Communication apparatus and communication method
JP2011166380A (ja) * 2010-02-08 2011-08-25 Canon Inc 通信装置、通信方法、及びプログラム
JP2011259239A (ja) * 2010-06-09 2011-12-22 Sony Corp 通信処理装置、通信処理システム、通信処理方法及びプログラム
US8773982B2 (en) 2010-06-16 2014-07-08 Panasonic Corporation Transmitting terminal and bandwidth estimating method
JP2013542629A (ja) * 2010-09-01 2013-11-21 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 局所的輻輳露出
WO2014064890A1 (ja) * 2012-10-24 2014-05-01 パナソニック株式会社 通信システム、受信端末、送信端末、および流量制御方法
JPWO2014064890A1 (ja) * 2012-10-24 2016-09-08 パナソニックＩｐマネジメント株式会社 通信システム、受信端末、送信端末、および流量制御方法
US9749384B2 (en) 2012-10-24 2017-08-29 Panasonic Intellectual Property Management Co., Ltd. Communication system, reception terminal, transmission terminal, and flow rate control method
US10212205B2 (en) 2012-10-24 2019-02-19 Panasonic Intellectual Property Management Co., Ltd. Reception terminal
US10547661B2 (en) 2012-10-24 2020-01-28 Panasonic Intellectual Property Management Co., Ltd. Transfer terminal and transfer method performed thereby
JP2016072679A (ja) * 2014-09-26 2016-05-09 日本電気株式会社 コンピュータネットワークシステム、サーバ、及び通信制御方法
WO2016189833A1 (ja) * 2015-05-25 2016-12-01 日本電気株式会社 無線基地局、パケット送信装置、及び無線端末、ならびにこれらの制御方法

Also Published As

Publication number Publication date
EP1450514A1 (en) 2004-08-25
CN1543164A (zh) 2004-11-03
US20050005020A1 (en) 2005-01-06
JP3814614B2 (ja) 2006-08-30

Similar Documents

Publication Publication Date Title
JP3814614B2 (ja) マルチメディア・ストリーミング環境におけるサーバベースのレート制御
US7583666B2 (en) Protocol information processing system and method information processing device and method recording medium and program
RU2305908C2 (ru) Адаптивный способ оценивания скорости передачи мультимедийных данных
US7554922B2 (en) Method and system for providing adaptive bandwidth control for real-time communication
US9191664B2 (en) Adaptive bitrate management for streaming media over packet networks
US7047308B2 (en) System and method for simultaneous media playout
US9154396B2 (en) Passive measurement of available link bandwidth
KR100759954B1 (ko) 멀티미디어 스트리밍에서 클라이언트 레이트 능력을시그널링하는 방법
US20050021830A1 (en) Data communications method and system using buffer size to calculate transmission rate for congestion control
US9282133B2 (en) Communicating control information within a real-time stream
JP2006042334A (ja) 可変ビットレートマルチメディアデータの往復遅延時間測定装置及び方法
CN103944834B (zh) 一种音视频转发控制方法及***
WO2003026233A1 (en) Data communications method and system for transmitting multiple data streams calculating available bandwidth per stream and bit stream trade-off
US20070097987A1 (en) Feedback provision using general nack report blocks and loss rle report blocks
EP1687955B1 (en) Feedback provision using general nack report blocks and loss rle report blocks
KR102491033B1 (ko) 왕복 시간 추정
El-Marakby et al. Evaluation of the Real-Time Transport Protocol (RTP) for Continuous Media Communications
Raj et al. Real Time Communication over Modified UDP Protocol
KR20080094417A (ko) 무선 통신망을 이용한 실시간 멀티미디어 서비스에서 망상황 정보 전송 방법 및 장치

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20050823

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20051021

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20060605

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