JP2004135307A - データストリームを送信する方法 - Google Patents

Abstract

　　【課題】　　　切り替え動作の待ち時間を最短化し、切り替え判断の誤りからの高速な回復を確保する。
　　【解決手段】　トランスポートプロトコルを用いてビデオサーバ２００とビデオクライアント３００との間でデータストリームを送信する方法であって、ビデオサーバ２００にてデータストリームを単一レートまたはマルチレートのコンテンツストリームの形で利用可能にするステップと、ビデオサーバ２００とビデオクライアント３００との間で接続を確立するステップと、データストリームを選択された符号化レートでビデオクライアント３００に送信するステップと、ビデオサーバ２００にて、送信の間に必要に応じて、データストリームを可変長のデータセグメントに分割するステップと、を有する、データストリームを送信する方法。
　【選択図】　　　図２

Description

　本発明は、送信ホストと受信ホストとの間で、ＴＣＰなどのトランスポートプロトコルを用いてデータストリームを送信する方法に関する。

　送信ホストと受信ホストの間のネットワーク通信において、データパケットの送信は大抵、ベストエフォートベースで行なわれる。通信リンクにおいては、利用可能な帯域幅と現在のリンク状況が変化するゆえに、エンドホストは現在のリンク状況を探りそれへの適応調整を行なうためのメカニズムを備えている。

　第三世代ネットワークの進展と共に、いわゆるストリーミングアプリケーションが重要性を帯びてきている。ストリーミングアプリケーションは、一般に時間遅延に対して弱い映像または音声などの連続したデータのストリームとして理解される。例えば携帯電話などの携帯受信機上でユーザがマルチメディアデータストリームを受信することができるようにするために、送信により届けられるデータが時間的制約を満たすよう、トランスポートメカニズムには幾つかの要件が課される。これらの制約は帯域幅変動と遅延の影響を受けるベストエフォート型環境においては満たすことが難しい。

　帯域幅適応の問題に対処するために、送信ホストにおいて、同一のコンテンツについて符号化レートの異なる幾つかのデータストリームを利用可能に用意することが一般に行なわれている。利用可能な帯域幅に応じて、帯域幅に対するレートの調節を行なうためにデータストリーム間の切り替えがなされる。換言すれば、送信ホストにおいてマルチレートのコンテンツストリームが送信され、利用可能な帯域幅によってストリーム間の切り替え動作がなされる。現在のストリームは受信ホストに対してワンピースで送られる結果、全ての切り替え動作ごとに切り替え時の接続状態が破棄されて、新たな接続セットアップがなされなくてはならない。結果として、この動作は非効率であり、データスループットを低下させる。

　もう一つの選択肢としては、受信ホストに対して一のデータストリームのみを送信し、優先度と時間的制約とに基づいてデータパケットを破棄することも可能である。しかしながら、これはデータの損失に繋がるため、最適のソリューションではない。

　本発明の目的は、切り替え動作の待ち時間を最短化し、切り替え判断の誤りからの高速な回復を確保することである。

　本発明における課題は請求項１に記載される方法により解決される。該方法の好適な実施の形態は様々な従属請求項に記載するところによる。

　本発明の方法は、送信ホストにおけるマルチレートコンテンツデータストリームの存在を想定している。本発明の方法を用いれば、送信中に必要とされるように、アプリケーション層で可変にセグメントされたデータストリーム間で素早く切り替えを行なうことが可能となる。固定のセグメント長のデータストリームを用いる代わりに、ソケットに供給されるデータセグメントは切り替えの前後およびその間において、小さなセグメントにされる。各コンテンツに対して、異なるレートで符号化された幾つかのビデオストリームがビデオサーバに蓄積される。通常の送信状況、すなわち、帯域幅が十分で損失がほとんど目立たないある平衡状態において送信が行なわれる状況の下で、ビデオコンテンツは同一サイズのセグメント（セグメントサイズは符号化レートではなくリンクの関数であるので、ストリームの符号化レートに関わらず）で送信側ＴＣＰソケットに渡される。サーバが、ストリーム切り替えが必要となる可能性がある旨の通知を受けた時のみ（あるいはその他の手段によりそれを知った場合のみ）これらのセグメントのサイズを小さくする。

　さらに、本発明の方法を用いれば、送信ホストで元の符号化データを修正する必要がなく、またトランスポートプロトコルを修正する必要も無く、さらにまた追加の制御メッセージを導入する必要もないので、該発明の実施は容易である。

　望ましくは、異なるレートのデータストリーム間で切り替えが実行され、データストリームの可変長セグメンテーションが切り替えの瞬間前後においてなされる。これゆえに、旧データストリームから新データストリームへの素早いストリーム切り替えが実行される。さらに望ましくは、切り替え動作が判断誤りからの回復により強くなるよう、そしてより素早い更なる切り替え動作が可能となるよう、切り替えの瞬間およびその前後のセグメンテーションはより細かくなされる。

　有利な効果として、ストリーム間の切り替えステップはフィードバックメッセージ（例えば、ＲＴＳＰコマンド）すなわち、切り替え動作が何時必要になるか、および、切り替え動作に必要な準備を何時行なうか、例えば何時細かなセグメンテーションをスタートするかについてのホスト間通信を伴う。

　データセグメント長、送信されるデータの識別子、あるいは切り替え動作をよりスムーズでデータ損失をより被り難くするストリーム制御コマンドからなるパラメータのうちの少なくとも一つを該フィードバックメッセージが含んでいれば、さらに有利である。

　望ましくは、切り替えの瞬間後はデータセグメント長が段階的に増加されて、アプリケーションとＴＣＰソケット間のインターフェイス通信負荷が小さくなる。

　上述したように、本発明によれば、切り替え動作の待ち時間を最短化し、切り替え判断の誤りからの高速な回復を確保することができる。

　図１は本発明の一実施の形態に係る送信ホストとしてのビデオサーバ（以降、「サーバ」と称する）を受信ホストとして機能するビデオクライアント（以降、「クライアント」と称する）に接続するためのＩＰネットワーク（通信ネットワーク）の基本構成を示す。ＩＰネットワーク１００は、トランスポートプロトコルを用いてサーバ２００とクライアント３００が通信を行なう、例えばＵＭＴＳコアネットワーク、インターネットなどの外部ネットワーク、または内部イントラネットである。例ではＴＣＰがトランスポートプロトコルとして選ばれているが、データの送信に他の如何なるトランスポートプロトコルをも用い得ることは当業者にとって明らかである。

　ここではＴＣＰがサーバ２００とクライアント３００との間でのデータ交換をどのように扱うかについて、より一般的な方法で説明する。

　まず、サーバ２００はデータをプロトコルに転送し、プロトコルにデータをクライアント３００に送るよう命じる必要がある。プログレッシブにデータを読み取って送るために、プロトコルはいわゆるＴＣＰソケットと呼ばれる、追加機能の付された一種のバッファを用いる。一般に、ソケットは通信相手のＩＰアドレス、プロトコル、および用いられるポートにより、明確に特定される。二つのソケットの間で接続が確立されると、例えば、「ソケットを生成」、「トランスポートアドレスにソケットを結合」、「アクセプト」または「接続を終了」、送信者と受信者の間でデータを「送信」、「受信」、または「書き込み」から構成し得るインタフェイスコールの使用により通信を制御できる。

　広く実施されているソケットはＵＮＩＸ　ＢＳＤ　４．２およびＷＩＮＤＯＷＳのＷＩＮＳＯＣＫバージョン２．０であり、同等のインタフェイスコールが実施されている。

　各々のインタフェイスコールはパラメータを有しており、例えば、「送信」コールについての関連パラメータは、ソケットディスクリプタ、送信されるデータの識別子、および、データストリーム長である。データストリームがひとたび一つのコールで渡されると、該データストリームの１ビットも修正することはできない。該データストリームの転送を中途で止める唯一の方法は接続を断つことである。

　しかしながら、接続を終了するためには、アプリケーションは明示的に「終了」コールを発さなければならない。インタフェイスコールは、例えばＦＴＰにおいて、待ち行列に入れることができる。ファイルを要求されると、ＦＴＰサーバはこの送信のために二つのインタフェイスコール、すなわち、ソケット、データストリームの識別子、およびデータストリーム長を示す「送信」コールとソケットを特定する「終了」コールとを発する。該二つのインタフェイスコールは待ち行列に入れられ、「送信」コールが終了すると、待ち行列内の次のキューが「終了」コールであるため、接続は不可逆的に断たれる。

　または、例えばＴＥＬＮＥＴの場合には、接続が確立され、ソケットは入力データ、すなわち、キーボード上でタイプされるコマンドを待つように設定される。

　当然のことながら、サーバ２００が「送信」コールのみを発し、クライアント３００が終了するのを待つようにアプリケーションを構成することも可能である。しかしながら、このようにすることは一般的ではない。

　また、ＴＣＰプロトコルはソケットにおけるイベントについてのある情報を非同期的にシグナリングするための手段を提供するものと想定されている。仕様においてはしばしば、該情報はエラーメッセージとなっている。他の場合では、送信、受信、またはその他のインタフェイスコールの処理終了に関する情報がある。

　図１を再度参照するに、サーバ２００は、例えば、ＭＰＥＧ４圧縮されたデータストリーム、すなわち、単一レートストリームまたはマルチレートストリームの形でＴＣＰソケットに利用可能にされた、所与のビデオコンテンツを提供する。ここでの記載、さらに以降の記載のために、マルチレートストリームは、異なる符号化レートによる同一のビデオコンテンツを有する一または複数のデータストリームと定義される。ＭＰＥＧデータストリームはＴＣＰソケットに送られる。その後、ＩＰプロトコルによって、データはクライアント３００に送信される。送信の再生、一時停止、停止などの動作の実行には、例えばＲＴＳＰなどのストリーム制御プロトコルが用いられる。

　サーバ２００の基本構成を表す図２を参照するに、サーバ２００は一般的に、ＭＰＥＧサーバアプリケーション２１０、ＲＴＳＰブロック（以降、「ＲＴＳＰ」と称する）２２０、およびＴＣＰソケットブロック（以降、「ＴＣＰソケット」と称する）２３０から構成されている。ＭＰＥＧサーバアプリケーション２１０においては、ビデオコンテンツはバッファ２１１に異なる符号化レートで利用可能に蓄えられる。ＲＴＳＰ２２０から「再生」、「一時停止」、「接続解除」または「レート変更」などのストリーム制御ＲＴＳＰコマンドを受け取るスイッチ２１２は、ＭＰＥＧファイルの形式でＴＣＰソケット２３０に送られるデータストリームの一つを選択する。

　サーバ２００およびクライアント３００において、ＲＴＳＰ以外のストリーム制御プロトコルを用いることができることは当業者にとって明らかである。ストリーム制御プロトコルは一般に再生、早送り、巻き戻し、一時停止、停止の機能の実行を指示する。さらに、マルチレートコンテンツが利用可能であれば、より高い、またはより低い符号化レートへの切り替えを指示することができる。

　サーバ２００が、所望のレートで符号化されている選択されたコンテンツを含むファイルの要求を受け取ると、ＭＰＥＧサーバアプリケーション２１０は、ファイルが事前にセグメントされている各々のセグメントを例えば連続的な送信コールなどの連続的なインタフェイスコールによって、順次、ＴＣＰソケット２３０に送る。現在のＦＴＰアプリケーションとは異なり、各々のデータ送信プロセスが完了した後にも接続は解除されない。データ接続は終了されないままであるため、セグメントが送信されるたびに新たな接続を立ち上げる必要が無い。これに従って、ＴＣＰソケット２３０は、クライアント３００への送信のために最適と考えられるパケットデータユニット（ＰＤＵ）を、これらのセグメントを用いて形成する。

　接続を確立すると、ＴＣＰソケット２３０はセグメントサイズセレクタ２３１において、チャネル帯域幅の考慮の下、サーバ２００がリンクに最適と考えるデータストリームのためのセグメントサイズを選択し、送信を開始する。

　始めは、前の切り替え判断が誤っていた場合に更なる切り替え動作が実行されるまでの待ち時間が長くなることを避けるよう、切り替え動作中およびその前後においてはセグメントサイズが小さくされる。その後、接続時間にわたり、データセグメントサイズは徐々に大きくすることができる。

　そして、利用可能なリンク帯域幅に変化がある場合には、クライアント３００が例えばＲＴＳＰメッセージを用いて、切り替え動作が起き得ることを示し、サーバ２００はより細かなセグメンテーションを始める（セグメントサイズは利用可能なリンク帯域幅の関数である）。こうして、サーバ２００は異なる符号化レートのデータストリーム間で切り替えを行なう。この切り替えは初期情報に基づいて行なわれ、その後、クライアント３００からのフィードバックにより制御される。または、これはサーバ２００により決定され得るが、そうするとサーバ２００に処理要件を課することとなる。また、サーバ２００とクライアント３００とで制御メカニズムを組み合わせることも可能である。サーバ２００またはクライアント３００が厳密にどのようにして切り替え動作を行なう判断をなすか、または予期される切り替えを示すかについては、本発明の対象範囲とするところでない。

　クライアント（ＴＣＰストリーミングクライアント）３００の基本構成は図３に示されている。クライアント３００は一般に、ＴＣＰソケットブロック（以降、「ＴＣＰソケット」と称する）３１０、アプリケーション層バッファ（図３では「バッファ」と称する）３２０、該アプリケーション層バッファ３２０のためのバッファマネージャ（図３では「マネージャ」と称する）３３０、ＭＰＥＧクライアントアプリケーション３４０、ディスプレイ３５０、および、ＲＴＳＰブロック（以降、「ＲＴＳＰ」と称する）３６０から構成される。

　クライアント３００は可変長のデータセグメントが入力されてきたときにこれを処理する。これへの応答として、クライアント３００は肯定応答（ＡＣＫ）を送り、さらにリンクから可能な最大ビットレートを得ながら、ＴＣＰソケット３１０のオーバーフローを防ぐためのフロー制御を行なう。これを行なうため、ＴＣＰソケット３１０はサーバ２００に対し、各々の肯定応答と共に、ＴＣＰソケット３１０が一杯になるまでにどれだけの量のデータを受けられるかをＴＣＰプロトコルヘッダのウインドウフィールドを用いて示す。必要であれば、クライアント３００は零ウインドウをシグナリングし、サーバ２００に対して、接続を維持しつつもクライアント３００が許可するまでデータ送信が行なわれない「持続」モードに入ることを伝える。持続モードおよびウインドウフィールドのシグナリングはＴＣＰプロトコルの基本機能である。ＴＣＰソケット３１０がまだデータを受ける容量を余している場合には、その旨をサーバ２００にシグナリングする。ストリーミング制御コマンドはＲＴＳＰコマンドを用いて、サーバ２００にシグナリングされる。

　「プレイアウトバッファ」とも称されるアプリケーション層バッファ３２０はＴＣＰソケット３１０よりデータを受け取り、これをＭＰＥＧクライアントアプリケーション３４０に送る。アプリケーション層バッファ３２０のためのバッファマネージャ３３０はＭＰＥＧクライアントアプリケーション３４０よりフレーム要求を受け取り、アプリケーション層バッファ３２０の状態を考慮して、ソケット要求を発する。バッファマネージャ３３０は、したがって、ＴＣＰソケット３１０が新しいデータをアプリケーション層バッファ３２０に届けることができるビットレートと該アプリケーション層バッファ３２０がＭＰＥＧクライアントアプリケーション３４０に蓄積内容を掃き出して空にするビットレートが確実にマッチするようにする。バッファマネージャ３３０の厳密な制御メカニズムについては、本発明の対象範囲とするところでない。

　最後に、ＭＰＥＧクライアントアプリケーション３４０から、データがユーザのために可視化するためにディスプレイ３５０に転送される。

　このように、本実施の形態によれば、切り替えの瞬間およびその前後に利用可能なリンク帯域幅によって、データのセグメンテーションが細かくなされ、データストリームのセグメントサイズが小さくされるので、送信中に必要に応じて、アプリケーション層で可変にセグメントされたデータストリーム間で素早く切り替えを行なうことができ、切り替え動作の待ち時間を最短化し、切り替え判断の誤りからの高速な回復を確保することができる。

　本発明に係るデータストリームを送信する方法は、切り替え動作の待ち時間を最短化し、切り替え判断の誤りからの高速な回復を確保する効果を有し、送信ホストと受信ホストとの間で、ＴＣＰなどのトランスポートプロトコルを用いてデータストリームを送信する方法として有用である。

本発明の一実施の形態に係る方法を実施することができるＩＰネットワークにより接続されたビデオサーバとビデオクライアントの基本構成を示す図 本発明の一実施の形態に係る方法が実施される送信ホストとしてのビデオサーバの構成を示すブロック図 本発明の一実施の形態に係る方法が実施されるビデオサーバと通信を行なう受信ホストとしてのビデオクライアントの構成を示すブロック図

符号の説明

　１００　ＩＰネットワーク
　２００　ビデオサーバ
　２１０　ＭＰＥＧサーバアプリケーション
　２１１　バッファ
　２１２　スイッチ
　２２０、３６０　ＲＴＳＰブロック
　２３０、３１０　ＴＣＰソケットブロック
　２３１　セグメントサイズセレクタ
　３００　ビデオクライアント
　３２０　アプリケーション層バッファ（バッファ）
　３３０　バッファマネージャ（マネージャ）
　３４０　ＭＰＥＧクライアントアプリケーション
　３５０　ディスプレイ

Claims (11)

1. 　トランスポートプロトコルを用いて送信ホストと受信ホストとの間でデータストリームを送信する方法であって、
   　送信ホストにてデータストリームを単一レートまたは同一コンテンツを有し異なる符号化レートのマルチレートのコンテンツストリームの形で利用可能にするステップと、送信の間、送信ホストと受信ホストとの間で接続を確立するステップと、同一コンテンツのデータストリームを選択された符号化レートで受信ホストに送信するステップと、送信ホストにてデータストリームを、確立された接続の間に必要に応じて可変長のデータセグメントに分割するステップと、
   　を有することを特徴とする、データストリームを送信する方法。
2. 　異なるレートのデータストリーム間で切り替えを行なうステップと、切り替えの瞬間時前後にデータストリームの可変セグメンテーションを行なうステップと、をさらに有することを特徴とする請求項１記載のデータストリームを送信する方法。
3. 　データストリームは切り替えの瞬間時前後に、より細かくセグメントされることを特徴とする請求項１または請求項２記載のデータストリームを送信する方法。
4. 　ストリーム間で切り替えを行うステップはフィードバックメッセージを伴うことを特徴とする請求項２記載のデータストリームを送信する方法。
5. 　フィードバックメッセージは、データセグメント長、送信されるデータの識別子またはストリーム制御コマンドからなるパラメータの少なくとも一つのシグナリングを含むことを特徴とする請求項４記載のデータストリームを送信する方法。
6. 　受信ホストはストリーム切り替えが必要なときに送信ホストと通信を行うことを特徴とする請求項１から請求項５のいずれかに記載のデータストリームを送信する方法。
7. 　送信ホストは切り替えの瞬間のタイミングを通信リンクの利用可能な帯域幅によって決定することを特徴とする請求項１から請求項６のいずれかに記載のデータストリームを送信する方法。
8. 　データセグメントの長さは切り替えの瞬間後に徐々に増加されることを特徴とする請求項１から請求項７のいずれかに記載のデータストリームを送信する方法。
9. 　受信ホストでの受信データストリームは一時的に内部バッファに蓄積されることを特徴とする請求項１から請求項８のいずれかに記載のデータストリームを送信する方法。
10. 　受信ホストは内部バッファの状態によって送信ホストにストリーム制御コマンドを発することを特徴とする請求項１から請求項９のいずれかに記載のデータストリームを送信する方法。
11. 　可変セグメンテーションを行うステップにおけるデータストリームのデータセグメントのサイズは利用可能なリンク帯域幅の関数であることを特徴とする請求項１記載のデータストリームを送信する方法。

Images