JP2010154547A - パケット化データのビットレートの適合化とデータパケットの再送信との間の連携 - Google Patents
パケット化データのビットレートの適合化とデータパケットの再送信との間の連携 Download PDFInfo
- Publication number
- JP2010154547A JP2010154547A JP2010029129A JP2010029129A JP2010154547A JP 2010154547 A JP2010154547 A JP 2010154547A JP 2010029129 A JP2010029129 A JP 2010029129A JP 2010029129 A JP2010029129 A JP 2010029129A JP 2010154547 A JP2010154547 A JP 2010154547A
- Authority
- JP
- Japan
- Prior art keywords
- server
- client
- buffer
- data packet
- bit rate
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 230000006978 adaptation Effects 0.000 title claims abstract description 55
- 239000000872 buffer Substances 0.000 claims abstract description 257
- 230000005540 biological transmission Effects 0.000 claims abstract description 78
- 230000007547 defect Effects 0.000 claims abstract description 68
- 238000000034 method Methods 0.000 claims description 39
- 238000004590 computer program Methods 0.000 claims description 13
- 230000002950 deficient Effects 0.000 claims description 2
- 230000006870 function Effects 0.000 description 13
- 238000012546 transfer Methods 0.000 description 9
- 238000012545 processing Methods 0.000 description 8
- 230000008859 change Effects 0.000 description 7
- 230000008569 process Effects 0.000 description 7
- 238000004891 communication Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000011664 signaling Effects 0.000 description 3
- 230000001934 delay Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000000717 retained effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000003745 diagnosis Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
-
- 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
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
-
- 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/0009—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
-
- 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/0014—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the source coding
-
- 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
-
- 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
-
- 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1874—Buffer management
- H04L1/1877—Buffer management for semi-reliable protocols, e.g. for less sensitive applications like streaming video
-
- 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1809—Selective-repeat protocols
-
- 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/188—Time-out mechanisms
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Computer Security & Cryptography (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
【課題】パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善する。
【解決手段】第1のビットレートを用いてサーバからクライアントへデータパケットを送信し、送信済みデータパケットをサーババッファに格納し、次いで送信済みデータパケットをクライアントバッファに格納し、上記サーバへの送信中に、送信済みデータパケットの欠陥に関する欠陥情報を通知し、上記通知された欠陥情報を上記サーバにより分析して、上記サーババッファに格納したデータパケットの再送信が必要かどうかを判定し、さらに、上記クライアントバッファの状態に関するクライアントバッファ情報を上記サーバへ通知し、上記クライアントバッファ情報を上記サーバにより分析して、データパケットの再送信が必要かどうかの決定を行う。
【選択図】図2
【解決手段】第1のビットレートを用いてサーバからクライアントへデータパケットを送信し、送信済みデータパケットをサーババッファに格納し、次いで送信済みデータパケットをクライアントバッファに格納し、上記サーバへの送信中に、送信済みデータパケットの欠陥に関する欠陥情報を通知し、上記通知された欠陥情報を上記サーバにより分析して、上記サーババッファに格納したデータパケットの再送信が必要かどうかを判定し、さらに、上記クライアントバッファの状態に関するクライアントバッファ情報を上記サーバへ通知し、上記クライアントバッファ情報を上記サーバにより分析して、データパケットの再送信が必要かどうかの決定を行う。
【選択図】図2
Description
本発明は、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するための、方法、システム、クライアント、サーバ、コンピュータプログラムおよびコンピュータプログラム製品に関する。
ストリーミングとは、第1の側面において、データネットワークを介してメディアストリームがクライアントへ送信される間に、クライアント側に設けられているアプリケーションが、音声ストリーム、オーディオストリームおよびビデオストリームのようなこれらの同期メディアストリームの再生を連続的に行い得ることをいう。第2の側面において、ストリーミングとは、通話用アプリケーションのようなリアルタイムの低遅延アプリケーションでもある。
ストリーミングサービスの最上位に位置付けることができるアプリケーションは、オン・デマンドおよびライブの情報配信用アプリケーションに分類することができる。第1のカテゴリの例としては、音楽用およびニュース・オンデマンド用アプリケーションがある。ラジオ番組とテレビ番組のライブの配信は第2のカテゴリの例である。リアルタイムの低遅延用アプリケーションとしては、例えば、マルチメディア(テレビ)電話やボイス・オーバーIPおよび任意のタイプの通話用マルチメディアアプリケーションなどがある。
固定インターネットプロトコル(IP)ネットワークを介するストリーミングは今日ではすでに主要なアプリケーションとなっている。インターネット技術特別調査委員会(IETF)と、ワールドワイドウェブコンソーシアム(W3C)とが、固定IPストリーミングサービスで使用する1組のプロトコルを開発しているのものの、完全な標準化ストリーミング用フレームワークはまだ規定されていない。第3世代パートナプロジェクト(3GPP)が開発した規格に準拠する第3世代(3G)移動通信システムの場合、3Gパケット交換型ストリーミングサービスは、例えば、ダウンロード型アプリケーションとマルチメディアコンテンツなどの3Gマルチメディア・メッセージサービス(MMS)と通話ストリーミングサービスと間のギャップを満たすものである。PSSについては、技術仕様3GPP TS26.234V0.3.0“透過的エンドツーエンドパケット交換型ストリーミングサービス(PSS);プロトコル並びにコーデック(リリース6)TSG−SA4 PSM SWG内部作業用ドラフト”(以後本明細書でTS26.234として示す)に詳細な記載がある。
PSSによって、移動ストリーミング用アプリケーションが可能となり、端末装置の複雑さが通話サービスに必要な複雑さに比べて少なくなる。というのは、メディア入力装置およびエンコーダが不要となり、かつ、さらに複雑さの少ないプロトコルを利用できるからである。PSSには、基本セットのストリーミング制御プロトコルと、トランスポートプロトコルと、メディアコーデックと、シーン記述プロトコルとが含まれている。
TS26.234から採った図1は、コンテンツサーバすなわちメディアサーバとクライアント間での、ストリーミング可能コンテンツとストリーミング不能コンテンツ双方の転送を制御するPSSプロトコルスタックを概略的に描く図である。
例えば、ストリーミングを目的として作成されたものではない(端末装置に保存されたMMSクリップなどの)マルチメディアコンテンツ、静止画像、ビットマップ・グラフィックとベクトル・グラフィック、テキスト、時間調節テキスト(timedtext)および合成オーディオのようなストリーミング不能コンテンツ106が、ハイパーテキスト転送プロトコル(HTTP)107によって転送される。上記ハイパーテキスト転送プロトコルは、基底に在るトランスポート制御プロトコル(TCP)108と、さらに基底に在るIP105のサービスとを利用するプロトコルである。
ビデオ、オーディオおよび音声のようなストリーミング可能コンテンツ101は、アダプテーション層103のリアルタイムトランスポートプロトコル(RTP)102のペイロード形式へまず変換される。前記RTPは、基底に在るユーザデータグラムプロトコル(UDP)104のサービスを利用することによって、リアルタイムデータまたはストリーミングデータの送信手段を提供し、該ユーザデータグラムプロトコルはさらに、基底に在るIPプロトコル105のサービスを利用する。
IETFコメント要求(RFC)ドキュメント1889に指定されているRTP102“RTP:リアルタイムアプリケーション用トランスポートプロトコル”には、双方向型オーディオおよびビデオのような、リアルタイム特性を有するデータ用のエンドツーエンド配信サービスが記載されている。上記サービスにはペイロードタイプ識別子と、シーケンス番号と、タイムスタンプと、配信モニタとが含まれる。RTPそれ自体は、タイムリな配信や別のサービス品質の保証を行うメカニズムを何も提供せずに上記を行う下位層サービスに依拠している。RTPは、配信を保証したり、順番を誤った配信を防止したり、あるいは、基底に在るネットワークが信頼性の高いものであり、パケットを順番に配信するものであることを仮定したりするものではない。RTPに含まれているシーケス番号によって、受信機が送信機のパケットシーケンスの再構成を行うことが可能になるが、例えばビデオの復号化の際などに必ずしも順番にパケットを復号化することなく、上記シーケンス番号を用いてパケットの適切な位置を決定するために使用することができる。
サービス品質をモニタし、RTPに基づいて行われている現在進行中のセッション時の参加者に関する情報を伝えるRTP制御プロトコル(RTCP)は、実際にデータを搬送するRTP102と密接にリンクしている。RTCPは、データパケットの場合と同じ配信メカニズムを利用するセッションのすべての参加者への周期的送信制御パケットに基づくものである。RTCPは、データ転送の品質に関するフィードバック情報を出力する。このフィードバック情報の出力は、トランスポートプロトコルとしてのRTPの役割の不可欠な部分であり、別のトランスポートプロトコルのフロー制御機能および輻輳状態制御機能に関係するものである。上記フィードバック情報をデータ転送時の障害診断に直接役立てることも可能である。上記フィードバック機能はRTCP送信機リポートおよび受信機リポートによって実行される。
RTCPが出力した品質フィードバックに基づいて、PSSは、送信中にRTPパケットが紛失した際に遭遇する品質の低下を和らげるRTPの再送信方式を提供する。紛失パケットがRTCPベースの品質フィードバックによって示され、サーバからクライアントへの効率の良い再送信が行われる。この再送信は、或る送信深度までサーバがすでに送信したRTPパケットの格納を必要とし、例えば最後の5秒内で送信されたすべてのRTPパケットをサーバ側のRTPパケット送信バッファに格納して、これらRTPパケットの再送信のケースを考慮する必要がある。
ストリーミング不能コンテンツの場合、HTTP107の組み込み型セッションの確立機能と、制御処理機能とがあればコンテンツを転送するために十分であるのに対して、ストリーミング可能コンテンツの場合、例えば、RTP/UDP/IPを介してコンテンツサーバからクライアントへ転送されるストリーミングビデオの開始、停止および中断を行うために、高度のセッション確立と制御プロトコルとを使用する必要がある。このタスクは、リアルタイムストリーミングプロトコル(RTSP)109により実行され、このリアルタイムストリーミングプロトコルは基底に在るTCP108か、基底に在るUDP104かのいずれかを使用する。少なくともストリーミングセッションを確立するために、RTSPはプレゼンテーション記述110を必要とする。このようなプレゼンテーション記述110は、例えば、セッション記述プロトコル(SDP)ファイルの形で利用可能にされる。前記SDPファイルには、例えば、セッション名並びに著者と、提示すべきメディアタイプと、例えばアドレスと、ポートと、フォーマット等々の前記メディアを受信するための情報と、メディアのビットレートなどのセッション記述とが含まれる。
PSSには複数のプロトコルと機能とが含まれ、このプロトコルと機能とを利用して、PSSセッションは、送信レートとコンテンツレート(ビットレートなど)とを利用可能なネットワークリソースに適合させることが可能となる。このレート適合化の目標は、言うまでもなく、メディアの中断のない再生を維持しながら、利用可能なリソースを有するエンドユーザにできる限り最高の品質を経験させることである。レートの適合化は、利用可能なネットワークリソースの推定と、利用可能なネットワークリンクレートへの送信レートの適合化とを必要とする。上記レートの適合化によって、ネットワークバッファのオーバフローを防止することが可能となり、それによってパケット損失の回避が可能となる。送信済みメディアのリアルタイムのプロパティを考慮して、メディアの着信が遅すぎて無用のものならないようにする必要がある。このことは、メディアのコンテンツレート(コンテンツのビットレートなど)の送信レートの適合を必要とする。
サーバができるだけ多くのデータをそのままクライアントバッファの中へ配信できるようにしながら、クライアントが有用なデータを破棄しなければならなくなる結果が生じるバッファのオーバフローを回避するために、クライアントバッファのフィードバックを行うための機能がPSSの範囲で定義される。こうすることによって、サーバは、クライアント側でのバッファの処理状況を子細にモニタし、サーバ側ができることを行って、クライアントのバッファのアンダフローの回避を図るようにすることが可能となる。クライアントは、サーバが利用できるバッファ空間の量と、所望の目標レベルの保護とを指定する。所望のレベルの保護が達成されると、サーバは、メディア品質を高める上記保護レベルの維持に必要なリソースを上回る任意のリソースを利用することが可能となる。サーバはバッファフィードバック情報を利用して、バッファのアンダフロー並びにその結果として生じる再生の中断を回避するためにメディア品質を下げる必要があるかどうかの判定を行うことが可能となる。サーバに対して、レートの適合化を行う1つの方法は、複数の符号化済みバージョンの同じコンテンツを保持することであり、該符号化ビットレートが識別基準としての役割を果たすことになる。この場合、クライアントバッファの状態に依存して違った形で符号化された符号化済みコンテンツ間で切替えを行うことによってレートの適合化を行うようにしてもよい。
PSS用のレートの適合化は、送信レートおよびコンテンツレートがサーバによって制御されるという意味でサーバ中心のものとなる。サーバは、クライアントとネットワークの状態に関する情報ソースとしてRTCPとRTSPとを利用する。
PSSにおいてレートの適合化を処理するために、クライアントバッファのフィードバック信号の機能がPSSクライアントとPSSサーバとによってサポートされていることが望ましい。クライアントバッファのフィードバック信号の機能をサポートするPSSクライアントとPSSサーバに対して、少なくとも以下の部分を実現することが望ましい。
− クライアントがレートの適合化のためにRTSPを通じてサーバへ出力する(バイトなどで表わされる)バッファサイズの信号送信。
− クライアントバッファ内で最も古いパケットのシーケンス番号(“最も古いバッファ済みシーケンス番号”OBSN)のRTCPを介する、サーバへの信号送信。このOBSN情報は、例えば、RTCPアプリケーション(APP)パケットの形でクライアントからサーバへ送信してもよい。
− クライアントがレートの適合化のためにRTSPを通じてサーバへ出力する(バイトなどで表わされる)バッファサイズの信号送信。
− クライアントバッファ内で最も古いパケットのシーケンス番号(“最も古いバッファ済みシーケンス番号”OBSN)のRTCPを介する、サーバへの信号送信。このOBSN情報は、例えば、RTCPアプリケーション(APP)パケットの形でクライアントからサーバへ送信してもよい。
上記バッファサイズと、OBSNパラメータとを用いて、並びに、RTCP受信機リポートの中に予め含まれている“最大受信シーケンス番号”HRSNによって、サーバは、最後に受信されたRTCPリポートの送信時刻におけるクライアントバッファ内のバイト数を算出することができる。
上記算出したクライアントバッファの充填レベルに基づいて、サーバはバッファのオーバフローを回避することが可能となる。この充填レベルによって、サーバはバッファレベルの低下時点を検出し、それによってアンダフローの防止を試みるように反応することが可能にもなる。最大シーケンス番号のパケットのタイムスタンプと、最も古いシーケンス番号のパケットのタイムスタンプと、信号送信されていれば、最も古いシーケンス番号のパケットの再生の遅延とを参照することによって、クライアントバッファがアンダフローする前の時点をサーバにより推定することが可能となる。クライアントがアンダフローする前の推定時刻の正確さは再生の遅延によって改善される。例えば、低いフレームレートのビデオの場合、再生の遅延によって、クライアント側でのバッファ処理時間の合計が著しい影響を受ける可能性がある。
これに対して、PSSにおけるレートの適合化機能とRTPの再送信機能との組み合わせは問題を引き起こす原因になる。
第1に、サーバがクライアントから受信したフィードバック情報に基づいてクライアントへ転送するパケットストリームのビットレートを変更することによりレートの適合化を行うとき、サーバによってその送信バッファのメモリ内容の一括消去が行われる。このような一括消去処理は、RTPの再送信方式の適切な機能に厳しい干渉を引き起こしたり、それを作動不能にしたりさえするものである。この再送信方式は、RTPパケットの損失に起因して生じる可能性のある将来のRTPパケットの再送信が行われるケースを考慮して或る一定の送信深度に対してすでに送信済みのRTPパケットの格納に基づいている。例えば、前記一括消去に起因してサーバ側ではもはや利用不能となったRTPパケットの再送信が必要となった場合、前記サーバは、(例えば適切なRTPパケットを見つけるためにサーバ3GPファイル内のヒントトラックによる再反復を介して)前記RTPパケットを再度取得する必要が生じる場合があり、この再度の取得が追加の遅延を引き起こす原因になったり、再度の取得が全く不可能になったりする場合があり得る。前記RTPパケットの前記遅延または前記不足は、前記RTPの最上位で実行しているアプリケーションに直接影響を与えることになり、例えば、関係するストリーミングメディアの再生がフリーズしたり、機能停止が生じたりする可能性さえある。
(例えば、RTCP APPパケットを介する)レートの適合化というコンテキストでクライアントがリポートするOBSNの方が、RTPの再送信というコンテキストで再送信用として要求されるRTPパケットのシーケンス番号よりも大きくなったり、あるいは、該シーケンス番号に非常に近いものであったりする場合には、別の問題が生じることになる。前記リポートされたOBSNにより特定されるRTPパケットは、復号化を行う目的のために、(例えば表示のために待機するためにポストデコーダバッファ入れられるなどの)クライアントがRTPパケットバッファから取り出す対象となる第1のRTPパケットである。したがって、リポートされたOBSNよりも小さなシーケンス番号を持つRTPパケットの再送信はいずれも不要となり、このような再送信は帯域幅の浪費となる。
3GPP TS 26.234、"Transparent end‐to‐end Packet‐switched Streaming Service (PSS); Protocols and codecs"、V6.3.0、2005年3月
IETF、RFC 1889、"RTP: A Transport Protocol for Real‐Time Applications"、1996年1月
上述の問題を考慮して、特に、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するための、方法、システム、クライアントサーバ、コンピュータプログラムおよびコンピュータプログラム製品を提供することが本発明の目的である。
本発明の第1の態様によれば、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善する方法であって、第1のビットレートを用いてサーバからクライアントへデータパケットを送信し、前記送信されたデータパケットの少なくとも1つを少なくとも1つのサーババッファに少なくとも一時的に格納し、前記送信されたデータパケットのうちの少なくとも1つのデータパケットをクライアントバッファに少なくとも一時的に格納し、前記サーバへの前記送信中に、前記送信されたデータパケットの少なくとも1つの欠陥に関する欠陥情報を通知し、前記通知された欠陥情報を前記サーバにより分析して、前記サーババッファに格納された少なくとも1つのデータパケットを前記サーバから前記クライアントへ再送信する必要があるかどうかを判定し、前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知し、第2のビットレートで前記サーバから前記クライアントへデータパケットを送信し、ここで、前記第2のビットレートは、前記クライアントバッファ情報に基づいて少なくとも部分的に決定され、前記第1のビットレートで送信され、前記サーババッファにされる少なくとも1つのデータパケットは、前記第2のビットレートで前記サーバから前記クライアントへの前記データパケットの前記送信が始まるとき、前記サーババッファにさらに格納されること、を有する方法が提案される。
前記データパケットは、例えばデータビットなどの情報搬送用シンボルから成るデータストリームの論理的単位または物理的単位を表わすものであってもよいし、データストリームの変調された表現であってもよい。例えば、前記データストリームは、少なくとも部分的にリアルタイム・トランスポートプロトコルRTPに基づいて、ストリーミングセッション時に前記サーバから前記クライアントへ送信されるメディアストリームであってもよい。これに対応して、前記サーバは、その場合、コンテンツサーバまたはストリーミングメディアサーバであってもよく、前記クライアントはストリーミングクライアントであってもよい。さらに前記データパケットはRTPパケットであってもよい。この場合、ユニキャストモードまたはマルチキャストモードで前記ストリーミングを実行してもよい。さらに一般的な意味では、前記サーバおよびクライアントはデータ送信システムにおける送信機と受信機と理解してもよい。前記データパケットの前記送信は、プロトコルによって実行および/または制御される物理的または論理的送信であってもよい。物理的送信媒体は、無線接続か、有線接続かのいずれかの媒体であってもよく、あるいは無線および有線のセグメントから成るものであってもよい。前記データパケットの前記送信は第1のビットレートで実行され、該送信は論理的送信または物理的送信を意味するものであってもよい。例えば、上記ビットレートは、ソース量および/または前記データパケットのコンテンツに対して実行されるチャネル符号化の量によって、あるいは、前記データパケットの送信に使用する送信チャネルまたはベアラの個数および/または送信容量によって決定してもよい。
前記サーバ側では、前記クライアントへ送信される少なくとも1つのデータが少なくとも一時的にサーババッファに格納される。このバッファは再送信用バッファを表わし、例えば、自動再送信要求プロトコルの制御によって、あるいは、リアルタイム・トランスポート制御プロトコルRTCPのサービスに基づいて、クライアント側で正しく受信されなかったデータパケットを上記再送信用バッファから新規に送信することも可能である。前記サーババッファ内での前記少なくとも1つのデータパケットの前記格納は、所定時刻または動的に適合させた時刻後に前記少なくとも1つのパケットによって前記サーババッファから取り出されるようにした時間制限のある格納にしてもよい。
前記クライアント側では、前記クライアントへ送信された、および、前記クライアント側で受信された少なくとも1つのデータパケットが前記クライアントバッファに少なくとも一時的に格納される。前記クライアントバッファから、前記クライアント内の格納済みデータパケットを別の処理へ導くことも可能であり、例えば、アプリケーションによって前記クライアントバッファから前記データパケットを再生することも可能である。前記クライアントバッファは、データパケットが前記クライアントバッファ側に着信する際に用いるレートの変動(サーバとクライアント間での物理的および論理的送信媒体の送信特性(遅延、損失)に起因して生じる変動)を可能にする補償バッファとして機能することも可能である。
前記クライアントは欠陥情報を前記サーバへ通知し、前記欠陥情報は前記サーバから前記前記クライアントへのデータパケットの送信中の少なくとも1つのデータパケットの欠陥に関係する。例えば、前記欠陥が1乃至いくつかのデータパケットの損失または破損を示す場合もある。欠陥情報の1例として、正しく受信した最後のデータパケットの(例えばシーケンス番号のような)識別子の通知を挙げることができる。特に所定時刻が過ぎてしまっている場合、前記データパケットサーバが1乃至いくつかのパケットを前記受信機側で正しく受信していないことを前記欠陥情報から導き出し、次いで、データパケットの再送信を試みるようにしてもよい。前記通知は、例えば、リアルタイム・トランスポート制御プロトコルなどのプロトコルに基づくものであってもよい。前記欠陥情報に基づいて、前記サーバは、すでに送信済みで、しかも破損または紛失したデータパケットの再送信が必要かどうかを判定することも可能である。次いで、前記サーババッファから上記データパケットをフェッチし、新しく前記クライアントへ送信するようにしてもよい。
前記クライアントは、前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知する。このクライアントバッファ情報は、例えば、クライアントバッファの中に残されている容量であってもよいし、あるいは、前記クライアントバッファに格納されたある特定のデータパケットのシーケンス番号、特に前記クライアントバッファに格納された最も古いデータパケット、すなわち、別の処理を行うために前記クライアントバッファからまだ読み出されていないデータパケットであって、前記クライアントバッファに格納されたすべてのデータパケットの中で最大の格納時間を有するデータパケットのシーケンス番号を表わすものであってもよい。これに対応して、前記最も古いデータパケットは、別の処理を行うために前記クライアントバッファから読み出すべき次のデータパケットとなる。
前記通知されたクライアントバッファ情報に基づいて、前記サーバは前記第1のビットレートを第2のビットレートへ変更する。このパケット化データのビットレートの適合化ステップは、例えば前記クライアントバッファのオーバフローやアンダフローの回避のために必要となる場合もあるし、ソース量および/または前記データパケットのコンテンツに対して実行されるチャネル符号化の量、あるいは、前記データパケットの送信に使用する送信チャネルまたはベアラの個数および/または送信容量を必要とする場合もある。
本発明の第1の態様によれば、前記第2のビットレートで前記サーバから前記クライアントへの前記データパケットの前記送信が始まるとき、前記第1のビットレートで送信され前記サーババッファに格納された少なくとも1つのデータパケットが前記サーババッファにさらに格納される。したがって、ビットレートを変更するとき、第1のビットレートで送信されたデータパケットを含むサーババッファは、従来技術によるシステムでの場合のようには一括消去されないことになる。これとは対照的に、第1のビットレートで転送された格納済みのデータパケットは前記サーババッファ内に保持され、例えば、通知された欠陥情報に依存して決まる場合がある継続時間の後、前記サーババッファから削除される。こうすることによって、第2のビットレートでデータパケットの送信がすでに始まっているときでさえ、第1のビットレートで送信されたデータパケットのために再送信が必要である限り、データパケットの再送信の成功は可能となる。従来技術の場合とは対照的に、本発明によれば、第1のビットレートで送信された破損データパケットや紛失データパケットが、第1のビットレートから第2のビットレートへのパケット化データのビットレートの適合化のインスタンスで、前記サーババッファの一括消去に起因してサーババッファ内で再送信用として利用不能となるケースはもはや生じる可能性はなくなり、したがって、前記データパケットによるアプリケーションの遅延や中断が回避されることになる。
本発明の第1の態様の推奨実施形態によれば、前記通知された欠陥情報に基づいて前記サーバが決定した継続時間の間、前記第1のビットレートで送信され、前記サーババッファに格納された前記少なくとも1つのデータパケットが前記サーババッファに格納される。上記処理は前記サーババッファの期限切れ時間内にデータパケットを割り当てることにより達成可能である。
本発明の第1の態様の推奨実施形態によれば、前記第1のビットレートで送信され、前記サーババッファに格納された前記少なくとも1つのデータパケットの前記サーババッファからの除去は、前記通知されたクライアントバッファ情報に応じて決まることになる。前記少なくとも1つのデータパケットは、前記データパケットの再送信がもはや必要でなくなくなったり、役に立たなくなったりしたと前記クライアントバッファ情報から判定された場合、例えばサーババッファから削除してもよい。
本発明の第1の態様の推奨実施形態によれば、前記クライアントバッファ情報は前記クライアントバッファに格納された最も古いデータパケットの識別子である。前記“古い”という用語は、前記データパケットがクライアントバッファに格納された場合のタイムインスタンスに関係するものと理解すべきである。前記識別子は、例えば前記最も古いデータパケットのシーケンス番号であってもよい。
本発明の第1の態様の推奨実施形態によれば、前記サーバから前記クライアントへの前記データパケットの前記送信は、リアルタイム・トランスポートプロトコルRTPに少なくとも部分的に基づいて行われ、前記欠陥情報および前記クライアントバッファ情報の前記信号送信は、リアルタイム・トランスポート制御プロトコルRTCPに少なくとも部分的に基づいて行われる。この時、前記データパケットはRTPパケットとなり、例えば、RTCPアプリケーションAPPパケットを用いることによって、最も古いバッファシーケンス番号OBSNなどの前記クライアントバッファ情報の通知を行うことも可能となる。
本発明の第1の態様の推奨実施形態によれば、3GPPパケット交換ストリーミングサービスPSSに従って、前記データパケットは、前記サーバから前記クライアントへ送信されるメディアストリームと関連づけられる。
本発明の第1の態様によれば、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するためのさらに別のシステムと、クライアントと、サーバとがさらに提案される。
本発明の第1の態様の推奨実施形態によれば、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善する方法がさらに提案され、該方法は、第1のビットレートでサーバからクライアントへデータパケットを送信し、前記送信されたデータパケットの少なくとも1つを少なくとも1つのサーババッファに少なくとも一時的に格納し、前記送信されたデータパケットの少なくとも1つをクライアントバッファに少なくとも一時的に格納し、前記サーバへの前記送信中に、前記送信済みデータパケットの少なくとも1つの欠陥に関する欠陥情報を通知し、前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知し、ここで、前記通知されたクライアントバッファ情報は前記サーバにより分析されて、前記データパケットの前記送信の前記第1のビットレートが第2のビットレートへ変更され、前記通知された欠陥情報と、前記通知されたクライアントバッファ状態情報とに基づいて、データパケットの再送信が必要かどうかを判定し、データパケットの再送信の必要性が判定された場合のみ、前記サーババッファに格納された少なくとも1つのデータパケットを前記サーバから前記クライアントへ再送信すること、を有する。
前記データパケットは、例えばデータビットなどの情報搬送用シンボルから成るデータストリームの論理的単位または物理的単位を表わすものであってもよいし、データストリームの変調された表現であってもよい。例えば、前記データストリームは、少なくとも部分的にリアルタイム・トランスポートプロトコルRTPに基づいて、ストリーミングセッション時に前記サーバから前記クライアントへ送信されるメディアストリームであってもよい。これに対応して、前記サーバは、その場合、コンテンツサーバまたはストリーミングメディアサーバであってもよく、前記クライアントはストリーミングクライアントであってもよい。さらに前記データパケットはRTPパケットであってもよい。この場合、ユニキャストモードまたはマルチキャストモードで前記ストリーミングを実行してもよい。さらに一般的な意味では、前記サーバおよびクライアントはデータ送信システムにおける送信機と受信機と理解してもよい。前記データパケットの前記送信は、プロトコルによって実行および/または制御される物理的または論理的送信であってもよい。物理的送信媒体は、無線接続か、有線接続かのいずれかの媒体であってもよく、あるいは無線および有線のセグメントから成るものであってもよい。前記データパケットの前記送信は第1のビットレートで実行され、該送信は論理的送信または物理的送信を意味するものであってもよい。例えば、上記ビットレートは、ソース量および/または前記データパケットのコンテンツに対して実行されるチャネル符号化の量によって、あるいは、前記データパケットの送信に使用する送信チャネルまたはベアラの個数および/または送信容量によって決定してもよい。
前記サーバ側では、前記クライアントへ送信される少なくとも1つのデータが少なくとも一時的にサーババッファに格納される。このバッファは再送信用バッファを表わし、例えば、自動再送信要求プロトコルの制御によって、あるいは、リアルタイム・トランスポート制御プロトコルRTCPのサービスに基づいて、クライアント側で正しく受信されなかったデータパケットを上記再送信用バッファから新規に送信することも可能である。前記サーババッファ内での前記少なくとも1つのデータパケットの前記格納は、所定時刻または動的に適合させた時刻後に前記少なくとも1つのパケットによって前記サーババッファから取り出されるようにした時間制限のある格納にしてもよい。
前記クライアント側では、前記クライアントへ送信された、および、前記クライアント側で受信された少なくとも1つのデータパケットが前記クライアントバッファに少なくとも一時的に格納される。前記クライアントバッファから、前記クライアント内の格納済みデータパケットを別の処理へ導くことも可能であり、例えば、アプリケーションによって前記クライアントバッファから前記データパケットを再生することも可能である。前記クライアントバッファは、データパケットが前記クライアントバッファ側に着信する際に用いるレートの変動(サーバとクライアント間での物理的および論理的送信媒体の送信特性(遅延、損失)に起因して生じる変動)を可能にする補償バッファとして機能することも可能である。
前記クライアントは欠陥情報を前記サーバへ通知し、前記欠陥情報は前記サーバから前記前記クライアントへのデータパケットの送信中の少なくとも1つのパケットの欠陥に関係する。例えば、前記欠陥が1乃至いくつかのデータパケットの損失または破損を示す場合もある。欠陥情報の1例として、正しく受信した最後のデータパケットの(例えばシーケンス番号のような)識別子の通信を挙げることができる。特に所定時刻が過ぎてしまっている場合、前記データパケットサーバが1乃至いくつかのパケットを前記受信機側で正しく受信していないことを前記欠陥情報から導き出し、次いで、データパケットの再送信を試みるようにしてもよい。前記通知は、例えばリアルタイム・トランスポート制御プロトコルRTPなどのプロトコルに基づくものであってもよい。
前記クライアントは、前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知する。このクライアントバッファ情報は、例えば、クライアントバッファの中に残されている容量であってもよいし、あるいは、前記クライアントバッファに格納されたある特定のデータパケットのシーケンス番号、特に前記クライアントバッファに格納された最も古いデータパケット、すなわち、別の処理を行うために前記クライアントバッファからまだ読み出されていないデータパケットであって、前記クライアントバッファに格納されたすべてのデータパケットの中で最大の格納時間を有するデータパケットのシーケンス番号を表わすものであってもよい。これに対応して、前記最も古いデータパケットは、別の処理を行うために前記クライアントバッファから読み出すべき次のデータパケットとなる。
前記通知されたクライアントバッファ情報に基づいて、前記サーバは前記第1のビットレートを第2のビットレートへ変更することも可能である。このパケット化データのビットレートの適合化ステップは、例えば前記クライアントバッファのオーバフローやアンダフローの回避のために必要となる場合もあるし、ソース量および/または前記データパケットのコンテンツに対して実行されるチャネル符号化の量、あるいは、前記データパケットの送信に使用する送信チャネルまたはベアラの個数および/または送信容量を必要とする場合もある。
本発明の第2の態様によれば、データパケットの再送信が必要であると決定された場合のみ、前記サーバから前記クライアントへの、前記サーババッファに格納された少なくとも1つのデータパケットの再送信が実行され、この決定は、前記信号送信済みの欠陥情報および前記信号送信されたクライアントバッファ状態情報に基づいて行われる。従来技術の場合とは対照的に、再送信に関する決定は単に通知された欠陥情報に基づいて行われるにすぎず、したがって、本発明の第2の態様によれば、通知されたクライアントバッファ情報は上記決定時にも考慮されることになる。例えば、前記欠陥情報によって或る一定のデータパケットの再送信の必要性が示された場合でも、前記クライアントバッファ情報によって、特定のデータパケットの再送信が不要であることがそれでも示される場合がある。その理由として、例えば、上記データパケットが前記クライアントバッファにすでに格納されていたり、すでに格納されてしまっていて、少し前にさらに処理されてしまっていたり、あるいは、該データパケットが、再送信に成功した場合でさえ、前記クライアント側への着信が遅すぎて無価値なものになっていたりする理由が挙げられる。したがって、本発明の第2の態様によれば、データパケットの再送信と、パケット化データのビットレートの適合化とを組み合わせた従来技術のシステムで生じるデータパケットの無用な再送信の完全な回避が可能となる。
本発明の第2の態様の推奨実施形態によれば、前記送信中に欠陥を受けた少なくとも1つのデータパケットのシーケンス番号の決定が前記欠陥情報によって可能となり、前記クライアントバッファ情報が、前記クライアントバッファに格納された最も古いデータパケットのシーケンス番号であり、データパケットの再送信が必要かどうかの前記決定が、前記少なくとも1つの破損データパケットと、前記最も古いデータパケットとの前記シーケンス番号の差に応じて決まることになる。これによって、例えば、前記最も古いデータパケットよりも新しいデータパケットのみを再送信するように要求することによって、不必要な再送信の回避が可能となる。上記要求は、時間と共に増加するデータパケットのシーケンス番号に対して前記破損データパケットの再送信を行うために、前記破損データパケットと前記最も古いデータパケットとの前記シーケンス番号の前記差が0よりも大きいものでなければならないというという要求につながるものである。
本発明の第2の態様の推奨実施形態によれば、前記サーババッファに格納されたデータパケットは、該サーババッファの関連するデータパケットのシーケンス番号と、前記最も古いデータパケットの前記シーケンス番号との差に応じて削除される。例えば、前記最も古いデータパケットよりも小さなシーケンス番号を有する(すなわち、前記クライアントバッファ内の前記最も古いデータパケットよりも古い)すべてのデータパケットを除去できれば好適なものとなる。次いで、前記差が0よりも小さくなれば、前記データパケットは削除される。
本発明の第2の態様の推奨実施形態によれば、前記サーバから前記クライアントへの前記データパケットの前記送信は、リアルタイム・トランスポートプロトコルRTPに少なくとも部分的に基づいて行われ、前記欠陥情報および前記クライアントバッファ情報の前記信号送信は、リアルタイム・トランスポート制御プロトコルRTCPに少なくとも部分的に基づいて行われる。この時、前記データパケットはRTPパケットとなり、例えば、RTCPアプリケーションAPPパケットを用いることによって、最も古いバッファシーケンス番号OBSNなどの前記クライアントバッファ情報の信号送信を行うことも可能となる。
本発明の第2の態様の推奨実施形態によれば、3GPPパケット交換ストリーミングサービスPSSに従って、前記データパケットは、前記サーバから前記クライアントへ送信されるメディアストリームと関連づけられる。
本発明の第2の態様の推奨実施形態によれば、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するためのさらに別のシステムと、クライアントと、サーバとがさらに提案される。
本発明によれば、上述の方法ステップのうちのいずれかをプロセッサに実行にさせるように作動可能な命令を有するコンピュータプログラムがさらに提案される。
上述の方法ステップのうちのいずれかをプロセッサに実行にさせるように作動可能な命令を有するコンピュータプログラムを含むコンピュータプログラム製品がさらに提案される。
本明細書で後述する実施形態から、本発明の上記局面並びにその他の局面は明らかにし、該実施形態を参照しながら解明することにする。
本発明は、パケット化データビットレートの変更の際、サーバがその再送信用バッファを一括消去しないように要求することによって、および、クライアントからフィードバックされたクライアントバッファ情報によって再送信パケットが実際に必要である旨が示された場合にのみ、データパケットを再送信するように要求することによって、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携の改善を提案するものである。以下、第3世代パートナプロジェクト(3GPP)パケット交換型ストリーミングサービス(PSS)というコンテキストで本発明の例示の実施形態を提示することにする。しかし、本発明は決してPSSでのアプリケーションに限定されるものではなく、パケット化データのビットレートの適合化と、データパケットの再送信とをまとめて実行するすべての種類の通信システムにおいても同様に良好に利用可能であることに留意されたい。
図2は、本発明に基づいて、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するための、例示システム20の基本構成要素を描く図である。上記システムはサーバ21とクライアント22とを備え、RTPデータパケットはストリーミングセッション時に前記サーバ21から前記クライアント22へストリームされる。このようなストリーミングセッションの1例として、例えばインターネットサーバから移動電話へのビデオのダウンロードが挙げられ、その際、前記ダウンロード処理と同時にビデオストリームが移動電話で再生される。
前記サーバ21は、例えばコンテンツサーバや、他の任意の種類の格納媒体(サーバ21内に置かれていても良い)からデータストリームを受信し、エンコーダインスタンス210において、前記データストリームを一連のリアルタイム・トランスポートプロトコル(RTP)パケットに符号化するものである。この符号化は、例えば異なるビットレートを用いた、ビットストリームなどのデータストリーム間での切替え処理を含むものであってもよい。次いで、前記RTPパケットは送信インスタンス211の中へ転送され、送信インスタンス211は、送信チャネルを介して前記クライアント22内の受信インスタンスへ前記RTPパケットを送信する。この送信は論理回路として理解すべきものである。すなわち前記RTPデータパケットは、サーバ21とクライアント22間での物理的送信を実行する下位プロトコル層へ渡されることによって実際に送信されることになる。したがって、前記送信インスタンス211は、例えば前記クライアント22内のピアエンティティ225と通信を行うRTPエンティティを表わすものであってもよい。上記送信済みRTPパケットは、送信インスタンス211によってビットレートに応じて再送信用バッファ214-1〜214-3にそれぞれ格納される。これらのビットレートごとの再送信用バッファ214-1〜214-3は、入出力(I/O)インタフェース213-1〜213-3を介して前記送信インスタンス211がアクセス可能なバッファである。図2の本例では、3つの異なるビットレートがサポートされていて、実際に、データパケットのシーケンス番号により特定される7個のデータパケットが、前記サーバ21から前記クライアント22へ送信され、これに対応して前記ビットレートごとの再送信用バッファ214-1〜214-3の中に該7個のデータパケットが格納されることになる。RTPパケットSN=1とSN=2は前記最大ビットレートで送信され、再送信用バッファ214-3に格納される。次いで、前記最大ビットレートからさらに低いビットレートへのビットレートの変更が行われ、この変更ビットレートで、RTPパケットSN=3、SN=4、SN=5が送信され、再送信用バッファ214-2に格納される。さらに低いビットレートへさらなる変更を行った後、RTPパケットSN=6とSN=7とが送信され、再送信用バッファ214-1に格納される。クライアントバッファ情報(本例ではRTCP APPパケット内の前記クライアント22から信号送信された最も古いバッファシーケンス番号)に基づいて、ビットレートの適合化/再送信制御インスタンス212により前記ビットレートの前記変更が開始される。上記OBSNと、前記クライアントバッファサイズ(セッション確立中に信号送信されたものなど)と、最大受信シーケンス番号(HRSN、RTCP受信機リポートの形で信号送信されたもの)とに基づいて、前記ビットレートの適合化/再送信制御インスタンス212は、前記クライアントバッファ224を遠隔制御して、オーバフローおよび/またはアンダフローの回避を図る。前記ビットレートの適合化/再送信制御インスタンス212は、それぞれ、例えば異なるビットストリームを用いて、前記エンコーダへ異なるビットレート間の切替え命令を出すことにより前記エンコーダ210を制御して、ビットレートの変更を図るようにするものである。前記ビットレートの適合化/再送信制御インスタンス212は、前記入出力インタフェース213-1〜213-3をさらに制御して、異なるビットレートを有する前記RTPパケットの正しい再送信用バッファ214-1〜214-3への格納を保証する。さらに、前記再送信用バッファ214-1〜214-3に格納されているRTPパケットの再送信を行う必要がある場合、この必要性は、前記クライアント22から出される設定の欠陥情報に基づいて、前記ビットレートの適合化/再送信制御インスタンス212により決定され、前記ビットレートの適合化/再送信制御インスタンス212は、前記再送信用バッファ214-1〜214-3から前記送信インスタンス211への、対応するRTPパケットの転送制御も行うことになる。本例によれば紛失RTPパケットに関する情報である前記欠陥情報は、前記クライアントバッファ情報の場合と同様、受信インスタンス215によって前記クライアント225から受信される。前記送信インスタンス211の場合と同じように、前記受信インスタンス215もまた論理回路と理解すべきである。すなわち、例えば前記RTCPを介して上記クライアントバッファ情報と、上記欠陥情報との信号送信を行うようにしてもよく、この場合、前記受信インスタンス215は、前記クライアント22内のピアエンティティ221と通信を行うRTCPエンティティを表わすことになる。
前記クライアント22は、受信インスタンス225を介して前記サーバ21から送信された前記RTPパケットを受信する。該受信インスタンス225は、例えばRTPエンティティであってもよい。前記エンティティ225において、前記RTPパケットが(破損などの)損傷を受けていないかどうかのチェックが簡単なチェックサムなどにより行われる。前記RTPパケットは、損傷を受けていなければ、入出力インタフェース223を介してクライアントバッファ224に格納される。前記クライアント22内のビットレートの適合化/再送信制御インスタンス222は、例えば正しく受信された最後のデータパケットのSNなどの損傷RTPパケットに関する情報を前記受信インスタンス225から受信し、例えばHRSNとOBSNの実際の値などのクライアントバッファ状態の情報を前記クライアントバッファ224から受信する。前記ビットレートの適合化/再送信制御インスタンス222は、前記欠陥情報と、前記クライアントバッファ情報の送信インスタンス221を介する前記サーバ21へのフィードバックをトリガする。該サーバ21は再度プロトコルエンティティとして理解してもよい。さらに、前記ビットレートの適合化/再送信制御インスタンス222は、前記入出力インタフェース223を制御して、前記クライアントバッファ224からデコーダインスタンス220へのRTPパケットの転送をトリガすることも可能であり、前記RTPパケットは、該デコーダインスタンス220において、異なるビットレートを用いて(ビットストリームなどの)元のデータストリームへの復号化を行う。本例では、前記クライアントバッファ内の前記OBSNはOBSN=3であり、前記クライアントバッファにはさらにRTPパケットSN=4が含まれる。このように、RTPパケットSN=1とSN=2とはすでに受信され、前記クライアントバッファ224に格納され、前記クライアントバッファ224から読み出され、そして再生用として前記デコーダ220により復号化されている。しかし、RTPパケットSN=5、SN=6およびSN=7は、再送信用バッファ214-1内にこれらRTPパケットが格納されていることが示すように、すでにサーバ21によって送信されているにもかかわらず、まだ前記クライアントバッファ224には格納されていない。
次に、サーバ21からクライアント22への転送中、RTPパケットSN=5が破損若しくは紛失した場合について考察する。この破損若しくは紛失に関する情報は、前記クライアント22の前記ビットレートの適合化/再送信制御インスタンス222によって、前記サーバ21の前記ビットレートの適合化/再送信制御インスタンス212へ信号送信され、RTPパケットSN=5の再送信が図られる。このRTPパケットSN=5の再送信は、該RTPパケットSN=5が前記再送信用バッファ214-1〜214-3のうちの1つのバッファにまだ格納されていることを要件とする。しかし、RTPパケットSN=3、SN=4、SN=5が中間のビットレートを用いて送信されたこと、並びに、これらRTPパケットの送信後、RTPパケットSN=6およびSN=7の送信のためにさらに低いビットレートへの変更が生じたことに留意されたい。従来技術によれば、このような変更は、通常再送信用バッファ214-1〜214-3のメモリ内容の一括消去を引き起こす原因となる。すなわちバッファに格納されているすべてのRTPパケットが即座に削除される。従来技術のこのアプローチは、本事例では問題を生じることとになる。というのは、前記すべての再送信用バッファ214-1〜214-3のメモリ内容の一括消去により、現在再送信を必要とするRTPパケットSN=5が含まれている再送信用バッファ214-2のメモリ内容も一括消去され、前記サーバ21による上記RTPパケットの再送信を拒否するか、前記サーバがコンテンツソースから該RTPパケットを再取得できるようになるまで遅延するかのいずれかへ導かれることになり、これによって新たな符号化などが組み込まれる可能性が生じるからである。したがって、本発明は、その第一の態様によれば、ビットレートの変更時に、前記再送信用バッファ214-1〜214-3が即座に一括消去されずに、これら再送信用バッファのRTPパケットがさらに保持されなければならないことを要件とするものである。したがって、本発明によれば、RTPパケットSN=5の送信時に用いたビットレートが、RTPパケットSN=6とSN=7との送信時に用いたビットレートへ変更されたにもかかわらず、RTPパケットSN=5は再送信用バッファ214-2の中に含まれることになる。
したがって、本発明の第1の態様は、前記ビットレートの適合化と再送信との連携を改善することである。この連携はサーバ側で容易に実現され、かつ、クライアント側での変更を必要としない。システムの最適性のレベルに応じて、ビットレートの変更後にサーバの再送信用バッファのメモリ内容の一括消去を行ってはならない、あるいは、一括消去を行わない方が望ましい旨の要求が行われる場合がある。例えばRTCPフィードバック情報やOBSNから導き出すことが可能なRTPパケットの日付が期限切れになった後、前記サーバは、その再送信用バッファ214-1〜214-3から単一のRTPパケットを除去することを許される場合がある。
次に、RTPパケットSN=3が送信中に破損した場合について考察する。従来技術によるシステムでは、このような状況では前記RTPパケットSN=3の再送信がトリガされることになる(この場合、RTPパケットSN=3が前記サーバ内の再送信用バッファ214-1〜214-3にまだ格納されていると仮定しているが、この仮定は、前記サーバ21において本発明の第1の態様を適用するか、しないに関りなく、例えば再送信用バッファ214-2のメモリ内容の一括消去を引き起こしたかもしれないビットレートの変更が行われなかった場合の仮定である)。しかし、前記クライアントバッファ224内にRTPパケットSN=3がすでに正しく格納されていることを示す前記クライアントバッファ224のOBSN=3に従えば、RTPパケットSN=3の再送信は実際には不要となる。例えば、前記欠陥情報のフィードバックの避けられない遅延と、前記RTPパケットの再送信の避けられない遅延並びに結果として生じるタイム・アウトに起因して、正しいバージョンおよび破損バージョンのRTPパケットSN=3がクライアント22側で異なるタイムインスタンスで受信された場合、上記状況が生じる可能性がある。別の例では、前記RTPパケットの再送信が成功したときでさえ、クライアント22内で次に処理(例えば再生)する前記OBSNと、再送信の対象となる前記RTPパケットの前記SNとの間のシーケンス番号の差が過度に小さいため、前記クライアント22側での該RTPパケットの受信が遅くなりすぎることを前記OBSNが示す場合もある。
従来技術では、前記OBSNに関する情報は、ビットレートの適合化についてしか考慮されず、再送信については考慮されていなかった。したがって、本発明の第2の態様によれば、RTPパケットを送信する前に、(破損RTPパケットに関する)欠陥情報と、(OBSNに関する)クライアントバッファ情報との双方の情報を考慮することが提案される。
したがって、本発明の上記第2の態様によって、ビットレートの適合化と再送信との連携も改善されることになる。この連携はサーバサイト側でも容易に実現され、クライアントサイト側での変更を必要としない。システムの最適性のレベルに応じて、クライアントが再送信を要求したパケットがすでにクライアントバッファ224内に含まれていることが認知されたり、クライアント側への着信が遅すぎて、クライアントにとって無価値であることが認知されたりした場合、サーバは、パケットを再送信してはならない、あるいは再送信を行わない方が望ましい旨の要求が行われる場合がある。サーバがOBSNをさらに利用して、OBSNの数以下の複数のSNを含むRTPパケットをその再送信用バッファ214-1〜214-3から除去するように図ることも可能であり、このことは本発明の第1の態様をサーバ内で実行する場合にも同様に特段の利点となる。
図3は、本発明に基づいて、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するための、サーバ側で行われる方法ステップの例示フローチャートを表わす図である。第1のステップ301でサーバ側のビットレートを設定する。このビットレートは、例えばRTPを介して、例えばサーバからクライアントへ送信されるビットストリームのビットレートである。このビットレートは、前記送信用として定義されたデフォルト値であってもよく、さらに、該ビットレートは、前記クライアントからのフィードバック情報に基づいて、送信中にさらに微調整を行うことが可能であり、それによって前記クライアントバッファ内でバッファのオーバフローやアンダフローが生じないように保証することを図るものである。第2のステップ302で、例えばRTPパケットなどのデータパケットを前記ビットストリームから生成し、次いで、ステップ303で前記クライアントへ送信する。ステップ304で、前記設定済みビットレートに従ってビットレートごとのサーババッファ(再送信用バッファ)に送信済みデータパケットを格納する。例えば再送信すべき破損データパケットのSNや、前記クライアント側で正しく受信された最後のデータパケットのSNなどの欠陥情報を、例えばRTCPを介して前記クライアントから送信し、次いでステップ305で前記サーバ側で受信する。同様に、ステップ306で、例えばOBSNなどのクライアントバッファ情報を前記サーバ側で受信する。前記欠陥情報とクライアントバッファ情報との双方に基づいて、データパケットの再送信が実際に必要かどうかをステップ307で判定する。データパケットの再送信が実際に必要であると判定された場合、ステップ308でデータパケットの再送信を実行する。データパケットの再送信が必要でない場合、あるいは、再送信が行われた後の場合、ステップ309でビットレートの変更が必要かどうかのチェックを行う。データパケットの再送信の必要性は、例えばOBSNなどの、ステップ306で受信したクライアントバッファ情報に少なくとも部分的に基づいて決定され、次いで、クライアントバッファサイズ並びにHRSNに関するさらなる情報を利用して前記チェックを行うことが可能となる。クライアントバッファのオーバフローまたはアンダフローを避けるためにビットレートの変更が必要であると判定された場合、ステップ310でビットレートを変更する。このステップの後、あるいは、変更が不要と判定された場合、例えばパケットの期限の時間をオーバーしていたり、ステップ306で受信したクライアントバッファ情報によって上記データパケットの再送信がもはや有効でないことが示されていたりするような理由のために、ビットレートごとのサーババッファからいずれかのパケットを除去して良いかどうかをステップ311でさらにチェックする。データパケットを除去すべき旨の判定が行われた場合、ステップ312でこの除去を実行する。この除去の実行後、もしくは、除去を実行しない場合、上記方法は元のステップ302へジャンプし、クライアントへ送信すべきさらに別のデータパケットが作成される。
図4は、本発明に基づいて、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するための、クライアント側で行う方法ステップの例示フローチャートを表わす図である。第1のステップ401で、例えばRTPパケットなどのデータパケットをクライアント側で受信する。ステップ402で、例えばチェックサムや別のエラー検出コードの処理を行うことによって、あるいは、パケットの受信シーケンス内に欠落したSNが存在するかどうかのチェックを行うことによって、データパケットを正しく受信したか、破損を受けたか、あるいは紛失したかのチェックを行う。正しく受信されたと判定された場合、ステップ403でデータパケットをクライアントバッファに格納する。正しく受信されたと判定されなかった場合、ステップ404で、データパケットを送信したサーバへ欠陥情報を通知する。上記とは別に、データパケットが正しく受信された旨の判定がステップ402で行われたかどうかにかかわりなく、前記クライアント側で正しく受信した最後のデータパケットのSNのような欠陥情報を前記サーバへ信号送信してもよい。ステップ405で、例えばOBSNのようなクライアントバッファ情報をクライアントバッファから決定し、ステップ406でサーバへ通知する。次いで、ステップ407で、例えばクライアントバッファからデータパケットをフェッチし、復号化し、あるいは、再生することによって、該データパケットのさらなる処理を行う。最終的に、本方法は元のステップ401へジャンプし、そこでさらに別のデータパケットの受信が行われる。
以上、推奨実施形態により本発明を説明した。当業者にとっては明白な代替方法および変更例が存在し、添付の請求項の範囲と精神から逸脱することなく実現可能であることを付記しておく。特に、本発明は3GPP PSSにおける利用に限定されるものではなく、ビットレートの適合化と再送信を使用するすべてのタイプの無線通信システムおよび/または有線通信システムにおいても同様に好適に利用可能である。
Claims (21)
- パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善する方法であって、
第1のビットレートを用いてサーバからクライアントへデータパケットを送信し、
前記送信されたデータパケットの少なくとも1つを少なくとも1つのサーババッファに少なくとも一時的に格納し、
前記送信されたデータパケットのうちの少なくとも1つのデータパケットをクライアントバッファに少なくとも一時的に格納し、
前記サーバへの前記送信中に、前記送信されたデータパケットの少なくとも1つの欠陥に関する欠陥情報を通知し、前記通知された欠陥情報を前記サーバにより分析して、前記サーババッファに格納された少なくとも1つのデータパケットを前記サーバから前記クライアントへ再送信する必要があるかどうかを判定し、
前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知し、
第2のビットレートで前記サーバから前記クライアントへデータパケットを送信し、ここで前記第2のビットレートは、前記クライアントバッファ情報に基づいて少なくとも部分的に決定され、前記第1のビットレートで送信され前記サーババッファに格納される少なくとも1つのデータパケットは、前記第2のビットレートで前記サーバから前記クライアントへの前記データパケットの前記送信が始まるとき、前記サーババッファにさらに格納されること、を有する方法。 - 前記第1のビットレートで送信され前記サーババッファに格納された前記少なくとも1つのデータパケットは前記通知された欠陥情報に基づいて前記サーバが決定した継続時間の間、前記サーババッファに格納される請求項1に記載の方法。
- 前記第1のビットレートで送信され前記サーババッファに格納された前記少なくとも1つのデータパケットの前記サーババッファからの取り出しが、前記通知されたクライアントバッファ情報に応じて決まる請求項1に記載の方法。
- 前記クライアントバッファ情報が、前記クライアントバッファに格納された最も古いデータパケットの識別子である請求項1に記載の方法。
- 前記サーバから前記クライアントへの前記データパケットの前記送信が、リアルタイム・トランスポートプロトコルRTPに少なくとも部分的に基づいて行われ、前記欠陥情報および前記クライアントバッファ情報の前記通知は、リアルタイム・トランスポート制御プロトコルRTCPに少なくとも部分的に基づいて行われる請求項1に記載の方法。
- 前記データパケットは、3GPPパケット交換型ストリーミングサービスPSSに従って、前記サーバから前記クライアントへ送信されるメディアストリームに関連づけられる請求項1に記載の方法。
- パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するシステムであって、
サーバと、
クライアントとを備え、
データパケットが第1のビットレートを用いて前記サーバから前記クライアントへ送信され、
前記送信されたデータパケットの少なくとも1つが少なくとも1つのサーババッファに少なくとも一時的に格納され、
前記送信されたデータパケットの少なくとも1つがクライアントバッファに少なくとも一時的に格納され、
前記サーバへの前記送信中に、前記送信されたデータパケットの少なくとも1つの欠陥に関する欠陥情報が通知され、
前記通知された欠陥情報が前記サーバにより分析されて、前記サーババッファに格納された少なくとも1つのデータパケットを前記サーバから前記クライアントへ再送信する必要があるかどうかが判定され、
前記クライアントバッファの状態に関するクライアントバッファ情報が前記サーバへ通知され、
データパケットが第2のビットレートで前記サーバから前記クライアントへ送信され、
前記第2のビットレートが前記クライアントバッファ情報に基づいて少なくとも部分的に決定され、
前記第1のビットレートを用いて送信され前記サーババッファに格納された少なくとも1つのデータパケットは、前記第2のビットレートで前記サーバから前記クライアントへの前記データパケットの前記送信が始まるとき、前記サーババッファにさらに格納されるシステム。 - パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するクライアントであって、
第1のビットレートでサーバから前記クライアントへ送信されたデータパケットを受信するために設けられた手段であって、前記送信されたデータパケットの少なくとも1つのデータパケットが少なくとも1つのサーババッファに少なくとも一時的に格納される、手段と、
前記送信されたデータパケットの少なくとも1つをクライアントバッファに少なくとも一時的に格納するために設けられた手段と、
前記サーバへの前記送信中に、前記送信されたデータパケットの少なくとも1つの欠陥に関する欠陥情報を通知するために設けられた手段であって、前記通知された欠陥情報は前記サーバにより分析されて、前記サーババッファに格納されたデータパケットの少なくとも1つを前記サーバから前記クライアントへ再送信する必要があるかどうかを判定する、手段と、
前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知するために設けられた手段と、
第2のビットレートで前記サーバから前記クライアントへ送信されたデータパケットを受信するために設けられた手段であって、前記第2のビットレートは、前記クライアントバッファ情報に基づいて少なくとも部分的に決定され、前記第2のビットレートで前記サーバから前記クライアントへの前記データパケットの前記送信が始まるとき、前記第1のビットレートで送信され前記サーババッファに格納された少なくとも1つのデータパケットが前記サーババッファにさらに格納される、手段と、を備えるクライアント。 - パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するサーバであって、
第1のビットレートで前記サーバからクライアントへデータパケットを送信するために設けられた手段であって、前記送信されたデータパケットの少なくとも1つはクライアントバッファに少なくとも一時的に格納される、手段と、
前記送信されたデータパケットの少なくとも1つを少なくとも1つのサーババッファに少なくとも一時的に格納するために設けられた手段と、
前記送信中に、前記送信されたデータパケットの少なくとも1つの欠陥に関して通知された欠陥情報を受信するために設けられた手段であって、前記通知された欠陥情報は前記サーバにより分析されて前記サーババッファに格納された少なくとも1つのデータパケットを前記サーバから前記クライアントへ再送信する必要があるかどうかを判定する手段と、
前記クライアントバッファの状態に関して通知されたクライアントバッファ情報を受信するために設けられた手段と、
第2のビットレートで前記サーバから前記クライアントへデータパケットを送信するために設けられた手段であって前記第2のビットレートが前記クライアントバッファ情報に基づいて少なくとも部分的に決定され、前記第2のビットレートで前記サーバから前記クライアントへの前記データパケットの前記送信が始まるとき、前記第1のビットレートで送信され前記サーババッファに格納された少なくとも1つのデータパケットが前記サーババッファにさらに格納される、手段と、を備えるサーバ。 - パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善する方法であって、
第1のビットレートでサーバからクライアントへデータパケットを送信し、
前記送信されたデータパケットの少なくとも1つを少なくとも1つのサーババッファに少なくとも一時的に格納し、
前記送信されたデータパケットの少なくとも1つをクライアントバッファに少なくとも一時的に格納し、
前記サーバへの前記送信中に、前記送信済みデータパケットの少なくとも1つの欠陥に関する欠陥情報を通知し、
前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知し、ここで、前記通知されたクライアントバッファ情報は前記サーバにより分析されて、前記データパケットの前記送信の前記第1のビットレートが第2のビットレートへ変更され、
前記通知された欠陥情報と、前記通知されたクライアントバッファ状態情報とに基づいて、データパケットの再送信が必要かどうかを判定し、
データパケットの再送信の必要性が判定された場合のみ、前記サーババッファに格納された少なくとも1つのデータパケットを前記サーバから前記クライアントへ再送信すること、を有する方法。 - 前記送信中に欠陥を受けた少なくとも1つのデータパケットのシーケンス番号の決定が前記欠陥情報によって可能となり、前記クライアントバッファ情報が、前記クライアントバッファに格納された最も古いデータパケットのシーケンス番号であり、データパケットの再送信が必要かどうかの前記決定が、前記少なくとも1つの破損データパケットと、前記最も古いデータパケットとの前記シーケンス番号の差に応じて決まる請求項10に記載の方法。
- 前記サーババッファに格納されたデータパケットが、該データパケットの関連するシーケンス番号と、前記最も古いデータパケットの前記シーケンス番号の差に応じて削除される請求項11に記載の方法。
- 前記サーバから前記クライアントへの前記データパケットの前記送信が、リアルタイム・トランスポートプロトコルRTPに少なくとも部分的に基づいて行なわれ、前記欠陥情報および前記クライアントバッファ情報の前記通知が、リアルタイム・トランスポート制御プロトコルRTCPに少なくとも部分的に基づいて行なわれる請求項10に記載の方法。
- 前記データパケットは、3GPPパケット交換型ストリーミングサービスPSSに従って、前記サーバから前記クライアントへ送信されるメディアストリームと関連づけられる請求項10に記載の方法。
- パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するシステムであって、
サーバと、
クライアントとを備え、
データパケットがサーバからクライアントへ送信され、
前記送信されたデータパケットのうちの少なくとも1つが少なくとも1つのサーババッファに少なくとも一時的に格納され、
前記送信されたデータパケットの少なくとも1つがクライアントバッファに少なくとも一時的に格納され、
前記送信中に、前記送信されたデータパケットの少なくとも1つの欠陥に関する欠陥情報が前記サーバへ通知され、
前記クライアントバッファの状態に関するクライアントバッファ情報が前記サーバへ通知され、
前記通知されたクライアントバッファ情報が前記サーバにより分析されて、前記データパケットの前記送信の前記第1のビットレートが第2のビットレートへ変更され、
前記通知された欠陥情報と、前記通知されたクライアントバッファ状態情報とに基づいて、データパケットの再送信が必要かどうかが判定され、
データパケットの再送信の必要性が判定された場合のみ、前記サーババッファに格納された少なくとも1つのデータパケットが前記サーバから前記クライアントへ再送信される、システム。 - パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するクライアントであって、
第1のビットレートでサーバからクライアントへ送信されるデータパケットを受信するために設けられた手段であって、前記送信されたデータパケットの少なくとも1つが少なくとも1つのサーババッファに少なくとも一時的に格納される、手段と、
前記送信されたデータパケットのうちの少なくとも1つのデータパケットをクライアントバッファに少なくとも一時的に格納するために設けられた手段と、
前記サーバへの前記送信中に、前記送信されたデータパケットの少なくとも1つの欠陥に関する欠陥情報を通知するために設けられた手段と、
前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知するために設けられた手段であって、前記通知されたクライアントバッファ情報は前記サーバにより分析されて、前記データパケットの前記送信の前記第1のビットレートが第2のビットレートへ変更される、手段と、
前記サーババッファに格納され前記サーバから前記クライアントへ再送信された少なくとも1つのデータパケットを受信するために設けられた手段であって、前記少なくとも1つのデータパケットはデータパケットの再送信の必要性が判定された場合のみ、再送信され、前記判定は、前記通知された欠陥情報と、前記通知されたクライアントバッファ状態情報とに基づいて行われる、手段と、を備えたクライアント。 - パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するサーバであって、
第1のビットレートで前記サーバからクライアントへデータパケットを送信するために設けられた手段であって、前記送信されたデータパケットのうちの少なくとも1つがクライアントバッファに格納される、手段と、
前記送信されたデータパケットのうちの少なくとも1つを少なくとも1つのサーババッファに少なくとも一時的に格納するために設けられた手段と、
前記サーバへの前記送信中に、前記送信されたデータパケットの少なくとも1つの欠陥に関する通知された欠陥情報を受信するために設けられた手段と、
前記サーバとつながる前記クライアントバッファの状態に関する通知されたクライアントバッファ情報を受信するために設けられた手段であって、前記通知されたクライアントバッファ情報は前記サーバにより分析されて、前記データパケットの前記送信の前記第1のビットレートが第2のビットレートに変更される、手段と、
前記通知された欠陥情報と、前記通知されたクライアントバッファ状態情報とに基づいて、データパケットの再送信が必要かどうかを判定するために設けられた手段と、
前記サーババッファに格納された少なくとも1つのデータパケットを前記サーバから前記クライアントへ再送信するために設けられた手段であって、データパケットの再送信の必要性が判定された場合にのみ再送信が行なわれる、手段と、を備えたサーバ。 - プロセッサに請求項1の方法ステップを実行させることの可能な命令を含むコンピュータプログラム。
- プロセッサに請求項1の方法ステップを実行させることの可能な命令を含むコンピュータプログラムを備えたコンピュータプログラム製品。
- プロセッサに請求項10の方法ステップを実行させることの可能な命令を含むコンピュータプログラム。
- プロセッサに請求項10の方法ステップを実行させることの可能な命令を含むコンピュータプログラムを備えたコンピュータプログラム製品。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/846,958 US20050254508A1 (en) | 2004-05-13 | 2004-05-13 | Cooperation between packetized data bit-rate adaptation and data packet re-transmission |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007512587A Division JP2007537640A (ja) | 2004-05-13 | 2005-05-11 | パケット化データのビットレートの適合化とデータパケットの再送信との間の連携 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2010154547A true JP2010154547A (ja) | 2010-07-08 |
Family
ID=34968108
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007512587A Pending JP2007537640A (ja) | 2004-05-13 | 2005-05-11 | パケット化データのビットレートの適合化とデータパケットの再送信との間の連携 |
JP2010029129A Withdrawn JP2010154547A (ja) | 2004-05-13 | 2010-02-12 | パケット化データのビットレートの適合化とデータパケットの再送信との間の連携 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007512587A Pending JP2007537640A (ja) | 2004-05-13 | 2005-05-11 | パケット化データのビットレートの適合化とデータパケットの再送信との間の連携 |
Country Status (7)
Country | Link |
---|---|
US (1) | US20050254508A1 (ja) |
EP (1) | EP1745629A1 (ja) |
JP (2) | JP2007537640A (ja) |
KR (2) | KR20070009739A (ja) |
CN (1) | CN1957576A (ja) |
AU (1) | AU2005242613A1 (ja) |
WO (1) | WO2005112382A1 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012222530A (ja) * | 2011-04-06 | 2012-11-12 | Sony Corp | 受信装置及び方法、並びにプログラム |
JP2020053979A (ja) * | 2016-01-25 | 2020-04-02 | ヴァレンス セミコンダクター リミテッド | 高速適応型デジタルキャンセラ |
Families Citing this family (68)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7295549B2 (en) * | 2003-02-14 | 2007-11-13 | Ntt Docomo, Inc. | Source and channel rate adaptation for VoIP |
US8868772B2 (en) | 2004-04-30 | 2014-10-21 | Echostar Technologies L.L.C. | Apparatus, system, and method for adaptive-rate shifting of streaming content |
US7818444B2 (en) | 2004-04-30 | 2010-10-19 | Move Networks, Inc. | Apparatus, system, and method for multi-bitrate content streaming |
JP4355638B2 (ja) * | 2004-09-15 | 2009-11-04 | 日本電気通信システム株式会社 | 通信ネットワーク、ゲートウェイ装置及びそれらに用いる遅延測定方法並びにそのプログラム |
CN101057438A (zh) | 2004-10-12 | 2007-10-17 | 阿瓦雷公司 | 电信环境中的资源共享 |
DE602005009755D1 (de) * | 2005-04-11 | 2008-10-23 | Ericsson Telefon Ab L M | Technik zur steuerung von datenpaketübermittlungen von daten mit variabler bitrate |
JP4597770B2 (ja) * | 2005-05-25 | 2010-12-15 | 京セラ株式会社 | 無線通信方法および無線通信装置 |
US8842555B2 (en) * | 2005-10-21 | 2014-09-23 | Qualcomm Incorporated | Methods and systems for adaptive encoding of real-time information in packet-switched wireless communication systems |
US20070239820A1 (en) * | 2005-11-23 | 2007-10-11 | Nokia Corporation | System and method for providing quality feedback metrics for data transmission in rich media services |
JP5200204B2 (ja) | 2006-03-14 | 2013-06-05 | ディブエックス リミテッド ライアビリティー カンパニー | 高信頼性システムを含む連合型デジタル権限管理機構 |
BRPI0709871B1 (pt) | 2006-04-12 | 2019-10-15 | Tq Delta, Llc. | Retransmissão de pacote e compartilhamento de memória |
JP4280272B2 (ja) * | 2006-05-31 | 2009-06-17 | 株式会社東芝 | 情報処理装置 |
US20070299936A1 (en) * | 2006-06-27 | 2007-12-27 | Borgendale Kenneth W | Interactively streaming data from a database in a high speed, low latency data communications environment |
US8296778B2 (en) * | 2006-06-27 | 2012-10-23 | International Business Machines Corporation | Computer data communications in a high speed, low latency data communications environment |
US8122144B2 (en) | 2006-06-27 | 2012-02-21 | International Business Machines Corporation | Reliable messaging using redundant message streams in a high speed, low latency data communications environment |
US20070300234A1 (en) * | 2006-06-27 | 2007-12-27 | Eliezer Dekel | Selecting application messages from an active feed adapter and a backup feed adapter for application-level data processing in a high speed, low latency data communications environment |
US8676876B2 (en) * | 2006-06-27 | 2014-03-18 | International Business Machines Corporation | Synchronizing an active feed adapter and a backup feed adapter in a high speed, low latency data communications environment |
US20070300235A1 (en) * | 2006-06-27 | 2007-12-27 | Eliezer Dekel | Reliable messaging using a message stream in a high speed, low latency data communications environment |
US20080104266A1 (en) * | 2006-10-25 | 2008-05-01 | Eliezer Dekel | Reliable messaging using message streams in a high speed, low latency data communications environment |
US20080114938A1 (en) * | 2006-11-14 | 2008-05-15 | Borgendale Kenneth W | Application Message Caching In A Feed Adapter |
US20080114839A1 (en) * | 2006-11-14 | 2008-05-15 | Borgendale Kenneth W | Version Control for Application Message Models |
US8695015B2 (en) | 2006-12-06 | 2014-04-08 | International Business Machines Corporation | Application message conversion using a feed adapter |
US20080140550A1 (en) * | 2006-12-07 | 2008-06-12 | Berezuk John F | Generating a global system configuration for a financial market data system |
US20080141273A1 (en) * | 2006-12-11 | 2008-06-12 | Borgendale Kenneth W | Accessing Application Message Data In A Messaging Environment |
US8327381B2 (en) * | 2006-12-12 | 2012-12-04 | International Business Machines Corporation | Referencing message elements in an application message in a messaging environment |
US8850451B2 (en) * | 2006-12-12 | 2014-09-30 | International Business Machines Corporation | Subscribing for application messages in a multicast messaging environment |
US20080137830A1 (en) * | 2006-12-12 | 2008-06-12 | Bhogal Kulvir S | Dispatching A Message Request To A Service Provider In A Messaging Environment |
US20080141275A1 (en) * | 2006-12-12 | 2008-06-12 | Borgendale Kenneth W | Filtering Application Messages In A High Speed, Low Latency Data Communications Environment |
KR20080082843A (ko) * | 2007-03-09 | 2008-09-12 | 삼성전자주식회사 | 데이터 패킷 손실의 보상을 위한 클라이언트 및 시스템,그리고 그 방법 |
JP4382830B2 (ja) * | 2007-03-16 | 2009-12-16 | 富士通株式会社 | パケット転送装置 |
US7917912B2 (en) * | 2007-03-27 | 2011-03-29 | International Business Machines Corporation | Filtering application messages in a high speed, low latency data communications environment |
FR2916925B1 (fr) * | 2007-05-30 | 2009-07-17 | Alcatel Lucent Sas | Procede et dispositif de tamponnage de paquets de donnees transmis via une communication plesiochrone. |
JP4983435B2 (ja) * | 2007-06-27 | 2012-07-25 | 富士通株式会社 | パケット通信品質計測装置及び方法 |
US20090006559A1 (en) * | 2007-06-27 | 2009-01-01 | Bhogal Kulvir S | Application Message Subscription Tracking In A High Speed, Low Latency Data Communications Environment |
US8797850B2 (en) * | 2008-01-10 | 2014-08-05 | Qualcomm Incorporated | System and method to adapt to network congestion |
US7971099B2 (en) * | 2008-04-02 | 2011-06-28 | International Business Machines Corporation | Method for enabling faster recovery of client applications in the event of server failure |
US8325800B2 (en) | 2008-05-07 | 2012-12-04 | Microsoft Corporation | Encoding streaming media as a high bit rate layer, a low bit rate layer, and one or more intermediate bit rate layers |
US8379851B2 (en) | 2008-05-12 | 2013-02-19 | Microsoft Corporation | Optimized client side rate control and indexed file layout for streaming media |
US7860996B2 (en) | 2008-05-30 | 2010-12-28 | Microsoft Corporation | Media streaming with seamless ad insertion |
US8681806B2 (en) * | 2008-06-23 | 2014-03-25 | Koninklijke Philips N.V. | Method for communicating in a network and radio stations associated |
US8265140B2 (en) | 2008-09-30 | 2012-09-11 | Microsoft Corporation | Fine-grained client-side control of scalable media delivery |
CN101741509B (zh) * | 2008-11-17 | 2013-01-09 | 华为技术有限公司 | 速率适配方法、装置及系统 |
JP5681641B2 (ja) | 2009-01-07 | 2015-03-11 | ソニック アイピー, インコーポレイテッド | オンラインコンテンツのためのメディアガイドの特異的、収集的および自動的な生成 |
CN101719809B (zh) * | 2009-11-25 | 2012-10-10 | 中兴通讯股份有限公司 | 一种媒体数据包丢包恢复的方法及系统 |
EP2507995A4 (en) | 2009-12-04 | 2014-07-09 | Sonic Ip Inc | SYSTEMS AND METHODS FOR TRANSPORTING ELEMENTARY BIT TRAIN CRYPTOGRAPHIC MATERIAL |
US20110191446A1 (en) * | 2010-01-29 | 2011-08-04 | Clarendon Foundation, Inc. | Storing and streaming media content |
US8930740B2 (en) * | 2010-02-23 | 2015-01-06 | Rambus Inc. | Regulation of memory IO timing using programmatic control over memory device IO timing |
US9247312B2 (en) | 2011-01-05 | 2016-01-26 | Sonic Ip, Inc. | Systems and methods for encoding source media in matroska container files for adaptive bitrate streaming using hypertext transfer protocol |
US9467708B2 (en) | 2011-08-30 | 2016-10-11 | Sonic Ip, Inc. | Selection of resolutions for seamless resolution switching of multimedia content |
US8909922B2 (en) | 2011-09-01 | 2014-12-09 | Sonic Ip, Inc. | Systems and methods for playing back alternative streams of protected content protected using common cryptographic information |
US8964977B2 (en) | 2011-09-01 | 2015-02-24 | Sonic Ip, Inc. | Systems and methods for saving encoded media streamed using adaptive bitrate streaming |
US9276989B2 (en) * | 2012-03-30 | 2016-03-01 | Adobe Systems Incorporated | Buffering in HTTP streaming client |
US10356143B2 (en) | 2012-10-10 | 2019-07-16 | Samsung Electronics Co., Ltd. | Method and apparatus for media data delivery control |
US20140161061A1 (en) * | 2012-12-10 | 2014-06-12 | Xg Technology, Inc. | Hybrid arq system using a sliding purge window for wireless networks |
US9313510B2 (en) | 2012-12-31 | 2016-04-12 | Sonic Ip, Inc. | Use of objective quality measures of streamed content to reduce streaming bandwidth |
US9191457B2 (en) | 2012-12-31 | 2015-11-17 | Sonic Ip, Inc. | Systems, methods, and media for controlling delivery of content |
US10397292B2 (en) | 2013-03-15 | 2019-08-27 | Divx, Llc | Systems, methods, and media for delivery of content |
US9906785B2 (en) | 2013-03-15 | 2018-02-27 | Sonic Ip, Inc. | Systems, methods, and media for transcoding video data according to encoding parameters indicated by received metadata |
US9094737B2 (en) | 2013-05-30 | 2015-07-28 | Sonic Ip, Inc. | Network video streaming with trick play based on separate trick play files |
US9967305B2 (en) * | 2013-06-28 | 2018-05-08 | Divx, Llc | Systems, methods, and media for streaming media content |
US9866878B2 (en) | 2014-04-05 | 2018-01-09 | Sonic Ip, Inc. | Systems and methods for encoding and playing back video at different frame rates using enhancement layers |
WO2017144643A1 (en) * | 2016-02-26 | 2017-08-31 | Net Insight Intellectual Property Ab | Retransmission of data in packet networks |
CN106454395B (zh) * | 2016-09-20 | 2018-10-12 | 北京百度网讯科技有限公司 | 在服务器中用于自适应提供多码率流媒体的方法及装置 |
CN109792444B (zh) * | 2016-09-30 | 2022-11-15 | 网络洞察力知识产权公司 | 实况内容分发系统中的播出缓冲 |
US10498795B2 (en) | 2017-02-17 | 2019-12-03 | Divx, Llc | Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming |
US10631200B2 (en) | 2017-06-28 | 2020-04-21 | Qualcomm Incorporated | System and method for packet transmission |
TWI758680B (zh) * | 2019-01-31 | 2022-03-21 | 日商日本電氣股份有限公司 | 資料中繼裝置、方法、發送系統及程式 |
CN114095796A (zh) * | 2020-07-30 | 2022-02-25 | 中国移动通信集团终端有限公司 | 无效重传包减少方法、装置、设备及计算机存储介质 |
Family Cites Families (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5036518A (en) * | 1988-11-02 | 1991-07-30 | Tseung Lawrence C N | Guaranteed reliable broadcast network |
JPH06311160A (ja) * | 1993-04-21 | 1994-11-04 | Hitachi Ltd | 無線通信方式及び無線端末装置 |
US5444718A (en) * | 1993-11-30 | 1995-08-22 | At&T Corp. | Retransmission protocol for wireless communications |
US6122275A (en) * | 1996-09-26 | 2000-09-19 | Lucent Technologies Inc. | Real-time processing for virtual circuits in packet switching |
US5918002A (en) * | 1997-03-14 | 1999-06-29 | Microsoft Corporation | Selective retransmission for efficient and reliable streaming of multimedia packets in a computer network |
US6031818A (en) * | 1997-03-19 | 2000-02-29 | Lucent Technologies Inc. | Error correction system for packet switching networks |
JP4203140B2 (ja) * | 1997-03-25 | 2008-12-24 | パナソニック株式会社 | ストリームデータ転送方法およびシステム |
JPH11163947A (ja) * | 1997-09-22 | 1999-06-18 | Toshiba Corp | ゲートウェイ装置、無線端末装置、ルータ装置および通信ネットワークのゲートウェイ制御方法 |
US6212240B1 (en) * | 1998-06-24 | 2001-04-03 | Motorola, Inc. | Method and apparatus for conveying data between communication devices |
JP2003324496A (ja) * | 1998-11-30 | 2003-11-14 | Matsushita Electric Ind Co Ltd | データ伝送方法,及びパケットデータ構造 |
EP1361690B1 (en) * | 2000-03-02 | 2006-01-11 | Matsushita Electric Industrial Co., Ltd. | Method and apparatus for retransmitting data packets based on channel conditions |
JP2001257715A (ja) * | 2000-03-09 | 2001-09-21 | Nippon Hoso Kyokai <Nhk> | 蓄積送信端末 |
WO2001099355A1 (fr) * | 2000-06-23 | 2001-12-27 | Mitsubishi Denki Kabushiki Kaisha | Procede et systeme de retransmission de paquets |
US6999432B2 (en) * | 2000-07-13 | 2006-02-14 | Microsoft Corporation | Channel and quality of service adaptation for multimedia over wireless networks |
WO2002045372A2 (en) * | 2000-11-29 | 2002-06-06 | British Telecommunications Public Limited Company | Transmitting and receiving real-time data |
KR100365183B1 (ko) * | 2000-12-07 | 2002-12-16 | 에스케이 텔레콤주식회사 | 비동기 이동 통신 시스템의 물리 계층에서의 적응 코딩을이용한 데이터 전송 방법 및 기지국 장치 |
US6985453B2 (en) * | 2001-02-15 | 2006-01-10 | Qualcomm Incorporated | Method and apparatus for link quality feedback in a wireless communication system |
KR100493084B1 (ko) * | 2001-05-04 | 2005-06-03 | 삼성전자주식회사 | 이동통신시스템에서 멀티미디어 서비스를 위한 초기전송및 재전송 장치 및 방법 |
KR20030004978A (ko) * | 2001-07-07 | 2003-01-15 | 삼성전자 주식회사 | 이동 통신시스템에서 초기전송 및 재전송 방법 |
JP2003069613A (ja) * | 2001-08-27 | 2003-03-07 | Nippon Telegr & Teleph Corp <Ntt> | データ品質保証システム |
JP3757857B2 (ja) * | 2001-12-12 | 2006-03-22 | ソニー株式会社 | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
US6700867B2 (en) * | 2001-12-20 | 2004-03-02 | Motorola, Inc. | Method and system for reduced memory hybrid automatic repeat request |
US7287206B2 (en) * | 2002-02-13 | 2007-10-23 | Interdigital Technology Corporation | Transport block set transmission using hybrid automatic repeat request |
EP1830511B1 (en) * | 2003-10-09 | 2014-12-03 | Panasonic Corporation | Communication method and apparatus for timing the detection of communication-medium characteristics |
-
2004
- 2004-05-13 US US10/846,958 patent/US20050254508A1/en not_active Abandoned
-
2005
- 2005-05-11 WO PCT/IB2005/001439 patent/WO2005112382A1/en active Application Filing
- 2005-05-11 KR KR1020067026135A patent/KR20070009739A/ko active Application Filing
- 2005-05-11 KR KR1020087023885A patent/KR20080093462A/ko not_active Application Discontinuation
- 2005-05-11 CN CNA2005800150949A patent/CN1957576A/zh active Pending
- 2005-05-11 EP EP05741039A patent/EP1745629A1/en not_active Withdrawn
- 2005-05-11 AU AU2005242613A patent/AU2005242613A1/en not_active Abandoned
- 2005-05-11 JP JP2007512587A patent/JP2007537640A/ja active Pending
-
2010
- 2010-02-12 JP JP2010029129A patent/JP2010154547A/ja not_active Withdrawn
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012222530A (ja) * | 2011-04-06 | 2012-11-12 | Sony Corp | 受信装置及び方法、並びにプログラム |
JP2020053979A (ja) * | 2016-01-25 | 2020-04-02 | ヴァレンス セミコンダクター リミテッド | 高速適応型デジタルキャンセラ |
JP7338117B2 (ja) | 2016-01-25 | 2023-09-05 | ヴァレンス セミコンダクター リミテッド | 高速適応型デジタルキャンセラ |
Also Published As
Publication number | Publication date |
---|---|
EP1745629A1 (en) | 2007-01-24 |
AU2005242613A1 (en) | 2005-11-24 |
WO2005112382A1 (en) | 2005-11-24 |
CN1957576A (zh) | 2007-05-02 |
US20050254508A1 (en) | 2005-11-17 |
KR20080093462A (ko) | 2008-10-21 |
JP2007537640A (ja) | 2007-12-20 |
KR20070009739A (ko) | 2007-01-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2010154547A (ja) | パケット化データのビットレートの適合化とデータパケットの再送信との間の連携 | |
JP4414311B2 (ja) | マルチメディアストリーミングサービスシステム及びその方法 | |
JP3757857B2 (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
KR100967377B1 (ko) | 데이터 통신 시스템, 데이터 송신 장치, 데이터 수신 장치, 데이터 통신 방법, 및 컴퓨터 프로그램을 기록한 매체 | |
EP3108639B1 (en) | Transport accelerator implementing extended transmission control functionality | |
KR101242663B1 (ko) | 패킷 송신 장치, 통신 시스템 및 컴퓨터 판독가능한 기록매체 | |
KR100705432B1 (ko) | 미디어 스트리밍 | |
US9473406B2 (en) | On-demand adaptive bitrate management for streaming media over packet networks | |
US9525874B2 (en) | Transmitting apparatus and transmission method | |
US20150271231A1 (en) | Transport accelerator implementing enhanced signaling | |
WO2011137837A1 (zh) | 一种快速频道切换时获取关键信息的方法、装置和系统 | |
CN114051173B (zh) | 一种基于rtp扩展头部的视频帧可靠传输方法、装置及设备 | |
JP2005051299A (ja) | パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法 | |
KR100631516B1 (ko) | 스트리밍 시스템 및 적응적 대역 할당 방법 | |
KR100624854B1 (ko) | 미디어 재전송 장치 및 방법 | |
JP2005136547A (ja) | 通信システム、受信装置および方法、送信装置および方法、記録媒体、並びにプログラム | |
CN117014608A (zh) | 视频流码率调整方法、装置、计算机设备和存储介质 | |
WO2018157352A1 (zh) | 一种基于流媒体纠偏算法的无线传输技术 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20100706 |