JP2007074225A - 通信処理装置、および通信制御方法、並びにコンピュータ・プログラム - Google Patents

Abstract

【課題】 プライオリティベースＱｏＳを適用した通信において、改善された通信制御を実現する装置および方法を提供する。
【解決手段】 ストリーミングデータ配信を行なう通信処理装置（サーバ）において、データ伝送開始時にストリーミングデータ対応のプライオリティより低いプライオリティを設定して通信状況を検証する。例えば、検証点に至るまでの時間と、検証点までに送信したデータ量の再生所要時間との比較に基づいて、データ配信における帯域確保状況を判定し、十分な帯域確保可能と判断した場合に、ストリーミングデータ配信対応のプライオリティに変更する。本構成によって、既存ストリーミングの帯域を奪って既存ストリーミングの遅延を発生させるといった通信妨害を起こすことがなく、良好な通信環境を維持することが可能となる。
【選択図】 図１１

Description

本発明は、通信処理装置、および通信制御方法、並びにコンピュータ・プログラムに関する。特に、プライオリティベースのＱｏＳ（Quality of Service）を適用したデータ通信を行なう構成において、アドミッション・コントロール（Admission Control）を適用し、既存の通信ストリームに対する悪影響を発生させない適格制御を実現する通信処理装置、および通信制御方法、並びにコンピュータ・プログラムに関する。

インターネット、ＬＡＮ等のネットワークを介したデータ通信の普及に伴い、家庭内においても家電機器やコンピュータ、その他の周辺機器をネットワーク接続し、機器間通信を実現したホームネットワークが多く利用されている。ホームネットワークは、例えば、ネットワーク接続機器間でのコンテンツ送受信を可能とし、ユーザに利便性・快適性を提供するものであり、今後、ますます普及することが予測される。

例えば、家庭内に設置したチューナなどの受信部とハードディスクなどの記憶手段を持つ機器をサーバとして設定し、サーバが保持する映画などのコンテンツを、ネットワークを介してユーザの持つＰＣなどのクライアント装置に送信することで、クライアント側でデータ受信を実行しながら再生を行なうといったいわゆるストリーミングデータ配信、再生処理が可能となる。

このようなストリーミングデータ配信を行なうサーバは、エンコードなどのデータ処理を実行して送信データを生成してネットワークに出力する。一方、ストリーミングデータの再生を行なうクライアントは、受信データをバッファに一時蓄積し、その後、順次デコード処理と再生処理を行なう。

しかし、ネットワーク上には複数の通信データが競合する場合がある。このような複数の通信データが競合すると、通信帯域が不足し、ストリーミングデータの配信遅れなどの問題が発生する。競合する通信データの制御構成については様々な提案がなされている。例えば特許文献１は、各通信局が競合して情報伝送を行なう競合伝送領域と、優先的に利用する帯域を設定して情報伝送を行なう優先伝送領域を設定し、通信局におけるバッファ蓄積量に応じて競合伝送領域と優先伝送領域を使い分けて通信を行なう構成を開示している。

また、データ転送品質を保証するための通信制御構成としてＱｏＳ（Quality of Service）が知られている。ＱｏＳは、例えば、各通信データに対して優先度に応じた帯域割り当てを行なう制御を行う。例えば動画像のストリーミングデータ配信においてリアルタイム再生を実現するためには、動画像を構成するパケットを遅延することなく、ストリーミングサーバからストリーミングクライアントに送信することが必要となる。一方、時間的な遅れが許容されるデータパケットもある。このようにネットワーク上を転送する各通信パケットについて、処理優先度を判別して通信制御処理を実行する。

ＱｏＳを提供、すなわちデータ転送の品質保証を実行するための通信制御処理装置としては、例えばネットワーク上に接続されたルータ、スイッチ等のデータ転送制御機器がある。優先度の設定手法には、様々な手法があり、例えば、データフロー単位、すなわち送信元アドレスと送信先アドレスによって特定されるデータフロー単位で優先度を設定する手法や、帯域予約ベースのＱｏＳ、パケットに付加された優先度に従って通信制御を行うプライオリティベースのＱｏＳなど、様々な手法がある。

無線ネットワークに関する標準的な規格の１つであるＩＥＥＥ（The Institute ｏｆ Electrical AND Electronics Engineers）８０２．１Ｄ（８０２．１ｐのプライオリティと呼ばれることもある）では、イーサネット（登録商標）などの有線ＬＡＮにおいて、パケットに付加された優先度に従って通信制御を行うプライオリティベースのＱｏＳの仕組みを規定している。また、Ｗｉ−Ｆｉフォーラムでは、無線ＬＡＮのＱｏＳ規格である８０２．１１ｅのサブセットであるプライオリティベースのＷＭＭ（Ｗｉ-Ｆｙ Multimedia）を規定している。これらプライオリティのＱｏＳ技術は、帯域予約ベースのＱｏＳに比べて、実装が容易なうえ、有効性があり、ホームネットワーク技術の業界標準であるデジタルリビングネットワーク（ＤＬＮ：Digital Living Network）では８０２．１ＤとＷＭＭの双方が採用される見込みである。

しかしながら、例えば、ホームネットワーク技術の業界標準であるデジタルリビングネットワーク（ＤＬＮ）の規定するＤＬＮＡ（Digital Living Network Alliance）ガイドラインに従い、２つのＡＶコンテンツのストリーミングデータ配信を同じ優先度に設定して並列に実行した場合、ネットワーク帯域に２本のストリーミングを伝送するのに十分な帯域がない状態では、２つのストリーミングのいずれもが、クライアント側でリアルタイム再生を行なうのに十分な転送レートを維持することができず、２つのストリーミングデータのいずれもがクライアント側で、再生画像の乱れや、音声途切れを発生させてしまうという問題がある。

このような問題の解決方法として、ネットワーク上の通信トラフィックを統一的に管理し、例えば、新たなストリーミングが開始される際にリアルタイム再生が実現可能な状態にあるか否かを検証し、可能であると判定された場合にのみ、データ配信開始の許可を与えるアドミッション・コントロール（Admission Control）の仕組みが提案されている。しかし、この仕組みは実装が複雑であり具体化されるに至っていない。また、アドミッション・コントロール（Admission Control）のポリシーをどのように運用するかという問題についても未解決であるというのが現状である。
特許公開２００５−１９８００８号公報

本発明は、上述の問題点に鑑みてなされたものであり、プライオリティベースのＱｏＳ（Quality of Service）を適用したデータ通信を行なう構成において、アドミッション・コントロール（Admission Control）を適用し、競合する通信についての適格な制御を実現する通信処理装置、および通信制御方法、並びにコンピュータ・プログラムを提供することを目的とする。

本発明の第１の側面は、
ストリーミングデータの送信処理を実行する通信処理装置であり、
データ通信状況を検証し、該検証結果に応じて送信データに対して設定する優先度情報の変更処理を実行する通信制御部と、
前記優先度情報を付加したデータの出力処理を実行するネットワークインタフェースを有し、
前記通信制御部は、
ストリーミングデータの送信初期期間において、ストリーミングデータに対応する規定優先度より低位の優先度を設定する処理を実行し、予め設定した検証タイミングとしての検証点において、低優先度設定期間のデータ通信状況の検証を実行し、該検証結果に応じて設定優先度の変更処理を行なう構成を有することを特徴とする通信処理装置にある。

さらに、本発明の通信処理装置の一実施態様において、前記通信制御部は、前記検証点における通信状況検証処理として、データ送信開始から検証点までの時間と、データ送信開始から検証点までに送信したデータの再生時間とを比較する下記判定式、
（データ送信開始から検証点までの時間）＜（データ送信開始から検証点までに送信したデータの再生時間）
が成立するか否かを判定し、上記判定式の成立を条件として、ストリーミングデータに対応する規定優先度への設定変更処理を行なう構成を有することを特徴とする。

さらに、本発明の通信処理装置の一実施態様において、前記通信制御部は、前記低優先度設定期間における通信状況の検証処理として、前記検証点における通信状況検証処理として、下記判定式、
（検証点）−（データ送信先クライアントにおけるデコード開始点）＜（検証点までの送信データの再生時間）−（データ送信先クライアントにおけるプリバッファデータの再生時間）
が成立するか否かを判定し、上記判定式の成立を条件として、ストリーミングデータに対応する規定優先度への設定変更処理を行なう構成を有することを特徴とする。

さらに、本発明の通信処理装置の一実施態様において、前記通信制御部は、前記データ送信先クライアントから、該クライアントにおけるプリバッファデータ量、またはデコード開始時間の少なくともいずれかの情報を受領して、前記判定式に基づく検証処理を実行する構成であることを特徴とする。

さらに、本発明の通信処理装置の一実施態様において、前記通信制御部は、前記検証点における通信状況の検証の結果、規定優先度への設定変更処理を実行すべきでないとの判定がなされた場合、送信データの送信ビットレートの低下処理を実行してデータ送信を継続する処理を実行する構成であることを特徴とする。

さらに、本発明の通信処理装置の一実施態様において、前記通信制御部は、前記検証点における通信状況の検証の結果、規定優先度への設定変更処理を実行すべきでないとの判定がなされた場合、データ送信の停止またはユーザに対する通知処理の少なくともいずれかの処理を実行する構成であることを特徴とする。

さらに、本発明の通信処理装置の一実施態様において、前記通信制御部は、ＨＴＴＰに従ったデータ送信処理における送信データ量をＴＣＰスタックに対するＨＴＴＰレスポンスデータ書き込み量に基づいて取得し、該取得した送信データ量に基づいて、通信状況の検証処理を実行する構成であることを特徴とする。

さらに、本発明の第２の側面は、
ストリーミングデータの通信制御方法であり、
ストリーミングデータの送信初期期間において、ストリーミングデータに対応する規定優先度より低位の優先度を設定してデータ送信を実行する低優先度設定データ送信ステップと、
低優先度設定データ送信期間におけるデータ通信状況の検証を、予め設定した検証タイミングとしての検証点において実行する通信状況検証ステップと、
前記通信状況検証ステップの検証結果に応じて、設定優先度の変更処理を行なう優先度変更ステップと、
を有することを特徴とする通信制御方法にある。

さらに、本発明の通信制御方法の一実施態様において、前記通信状況検証ステップは、前記検証点における通信状況検証処理として、データ送信開始から検証点までの時間と、データ送信開始から検証点までに送信したデータの再生時間とを比較する下記判定式、
（データ送信開始から検証点までの時間）＜（データ送信開始から検証点までに送信したデータの再生時間）
が成立するか否かを判定するステップであり、前記優先度変更ステップは、前記判定式の成立を条件として、ストリーミングデータに対応する規定優先度への設定変更処理を行なうステップであることを特徴とする。

さらに、本発明の通信制御方法の一実施態様において、前記通信状況検証ステップは、前記低優先度設定期間における通信状況の検証処理として、前記検証点における通信状況検証処理として、下記判定式、
（検証点）−（データ送信先クライアントにおけるデコード開始点）＜（検証点までの送信データの再生時間）−（データ送信先クライアントにおけるプリバッファデータの再生時間）
が成立するか否かを判定するステップであり、前記優先度変更ステップは、前記判定式の成立を条件として、ストリーミングデータに対応する規定優先度への設定変更処理を行なうステップであることを特徴とする。

さらに、本発明の通信制御方法の一実施態様において、前記通信状況検証ステップは、前記データ送信先クライアントから、該クライアントにおけるプリバッファデータ量、またはデコード開始時間の少なくともいずれかの情報を受領して、前記判定式に基づく検証処理を実行することを特徴とする。

さらに、本発明の通信制御方法の一実施態様において、前記通信制御方法は、さらに、前記通信状況検証ステップにおける通信状況の検証の結果、規定優先度への設定変更処理を実行すべきでないとの判定がなされた場合、送信データの送信ビットレートの低下処理を実行することを特徴とする。

さらに、本発明の通信制御方法の一実施態様において、前記通信制御方法は、さらに、前記通信状況検証ステップにおける通信状況の検証の結果、規定優先度への設定変更処理を実行すべきでないとの判定がなされた場合、データ送信の停止またはユーザに対する通知処理の少なくともいずれかの処理を実行することを特徴とする。

さらに、本発明の通信制御方法の一実施態様において、前記通信状況検証ステップは、ＨＴＴＰに従ったデータ送信処理における送信データ量をＴＣＰスタックに対するＨＴＴＰレスポンスデータ書き込み量に基づいて取得し、該取得した送信データ量に基づいて、通信状況の検証処理を実行することを特徴とする。

さらに、本発明の第３の側面は、
ストリーミングデータの送信処理を実行する通信処理装置において通信制御処理を実行させるコンピュータ・プログラムであり、
ストリーミングデータの送信初期期間において、ストリーミングデータに対応する規定優先度より低位の優先度を設定してデータ送信を実行する低優先度設定データ送信ステップと、
低優先度設定データ送信期間におけるデータ通信状況の検証を、予め設定した検証タイミングとしての検証点において実行する通信状況検証ステップと、
前記通信状況検証ステップの検証結果に応じて、設定優先度の変更処理を行なう優先度変更ステップと、
を有することを特徴とするコンピュータ・プログラムにある。

なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能なコンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。

本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

本発明の構成によれば、ストリーミングデータの配信を行なう通信処理装置（サーバ）は、データ伝送開始時に本来のストリーミングデータ配信に対応するプライオリティより低いプライオリティを設定してデータ送信を開始し、検証点において、低プライオリティ設定期間における通信状況を検証する。例えば、検証点に至るまでの時間と、検証点までに送信したデータ量の再生所要時間との比較に基づいて、クライアントのバッファ枯渇の発生や、ストリーミングデータ配信における帯域確保状況を判定し、この判定に基づいて、十分な帯域確保ができていると判断した場合にのみ、ストリーミングデータ配信に対応する本来のプライオリティ設定しとしたデータ配信を実行する構成としたので、例えば、新たなストリーミングデータの配信を開始しようとする時点で、他のストリーミング配信が実行中である場合、その既存のストリーミング配信の帯域を奪って既存ストリーミング配信の遅延を発生させるといった通信妨害を起こすことがなく、良好な通信環境を維持させることが可能となる。

以下、図面を参照しながら、本発明の通信処理装置、および通信制御方法、並びにコンピュータ・プログラムの詳細について説明する。

まず、図１を参照して、本発明の適用可能なネットワーク構成例について説明する。図１は、コンテンツ配信を実行する通信処理装置としてのサーバＡ１０１，サーバＢ１０２と、サーバに対して処理要求を行なうコンテンツ受信装置としてのクライアントＡ１１１〜クライアントＣ１１３を有するネットワーク、例えばホームネットワーク構成を示している。クライアントＡ１１１〜クライアントＣ１１３としては、例えばＴＶ、パーソナルコンピュータ（ＰＣ）、携帯端末、再生装置など様々な機器が設定可能である。

サーバＡ１０１，サーバＢ１０２と、クライアントＡ１１１〜クライアントＣ１１３間の通信は、例えばルータやブリッジによって構成されるパケット交換機としての通信制御部１０３によって中継、制御される。サーバＡ１０１，サーバＢ１０２と通信制御部１０３は有線ＬＡＮ１００によって接続され、有線ＬＡＮ１００を介した通信を行なう。例えば、ＩＥＥＥ８０２．３ｕ（１００ｂａｓｅ−ＴＸ）に従った有線ＬＡＮ通信を実行する。一方、通信制御部１０３とクライアントＡ１１１〜クライアントＣ１１３との通信は、ＩＥＥＥ１０２．１１ｂ規格による無線ＬＡＮ通信によって実行される。

サーバＡ１０１，サーバＢ１０２は、各クライアントＡ１１１〜クライアントＣ１１３に対して、例えば動画像コンテンツなどのストリーミングデータ配信を実行する。各クライアントＡ１１１〜クライアントＣ１１３においてサーバＡ１０１，サーバＢ１０２から配信されるストリーミングデータをリアルタイム再生するためには、動画像を構成するパケットを遅延することなく、サーバから受信することが必要となる。

通信制御部１０３は、例えばホームルータによって構成される。ホームルータは通常、インターネット接続に用いられるが、ホームネットワーク内接続ではブリッジ機能を提供する。サーバＡ１０１，サーバＢ１０２に蓄積された例えばビデオコンテンツを、クライアントＡ１１１〜クライアントＣ１１３に伝送する場合は、ビデオコンテンツの格納パケットは、通信制御部１０３において、有線ＬＡＮ８０２．３ｕから無線ＬＡＮ８０２．１１ｇの２つのリンク層を介して、無線ＬＡＮ８０２．１１ｇの規格に従った通信名データとして各クライアントＡ１１１〜クライアントＣ１１３に伝送される。

ホームルータ等によって構成される通信制御部１０３は、プライオリティベースのＱｏＳ技術によって、帯域割り当て処理を行なう。すなわち、競合する通信についてプライオリティベースの制御を行う。すなわち、パケットに設定された優先度情報に従った帯域割り当てを行なう。

図１に示すようなネットワークを適用しサーバからクライアントに対してＡＶコンテンツなどのストリーミング配信を実行する構成において、本発明の通信処理装置、すなわちサーバ１０１，１０２は、新たにストリーミングを開始する際に、既にネットワークを介して実行中のストリーミング配信を妨害することのない通信制御を行う。すなわち、既にネットワークを介して実行中のストリーミングデータの再生乱れなどの影響が起きないように、新たにストリーミングを開始するサーバ自身が制御を行なう。以下、本発明の通信処理装置としてのサーバの実行する処理について、詳細に説明する。

まず、プライオリティベースＱｏＳを実現するために検討されている規格と、プライオリティベースＱｏＳを利用した効果について説明する。Ｗｉ−Ｆｉフォーラムが推進するＷＭＭ（Ｗｉ-Ｆｙ Multimedia）では、通信データのプライオリティ（優先度）情報として、ＩＥＥＥ８０２．１Ｄから引用した４つのアクセスカテゴリ（ＡＣ：Access Category）を定義している。これは、８０２．１１ｅのＥＤＣＦ（Enhanced Distributed Coordination Function）の４段階プライオリティに相当する。図２に、ＷＭＭの規定するアクセスカテゴリ（ＡＣ：Access Category）を示す。

図２に示すように、ＷＭＭでは、４つのプライオリティ（優先度）情報としてのアクセスカテゴリを規定している。すなわち、通信データとしての優先度の高い順から、
（ａ）ボイスプライオリティ（ＷＭＭ Ｖｏｉｃｅ Ｐｒｉｉｏｒｉｔｙ）
（ｂ）ビデオプライオリティ（ＷＭＭ Ｖｉｄｅｏ Ｐｒｉｉｏｒｉｔｙ）
（ｃ）ベストエフォートプライオリティ（ＷＭＭ Ｂｅｓｔ Ｅｆｆｏｒｔ Ｐｒｉｉｏｒｉｔｙ）
（ｄ）バックグラウンドプライオリティ（ＷＭＭ Ｂａｃｋｇｒｏｕｎｄ Ｐｒｉｉｏｒｉｔｙ）
以上の４つのアクセスカテゴリを規定している。

例えばプライオリティベースのＱｏＳによる通信制御に基づいたデータ送信を実行するサーバアプリケーションは、伝送するデータパケットに対して、優先度情報としてのアクセスカテゴリ（Access Category）を設定する処理を行なう。さらに、例えば、図１に示すホームルータなどの通信制御部１０３は、サーバから有線ＬＡＮを介してパケットを受け取り、無線ＬＡＮにパケットを送出する際、アプリケーションプログラミング・インタフェース（ＡＰＩ：Application Program Interface）を介して無線ＬＡＮのリンク層にアクセスカテゴリを通知し優先度に従ったデータパケット送出を実行する。

図３は、ＷＭＭで規定するプライオリティ（優先度）情報としてのアクセスカテゴリを適用した通信処理における効果を示す図である。図３（ａ）は、ＷＭＭで規定するプライオリティ（優先度）情報としてのアクセスカテゴリを適用した通信処理、図３（ｂ）は、アクセスカテゴリを適用しない通信処理における時間経過とともに変更する通信データのスループット遷移を示している。

いずれも、実線がビデオストリーミング、２つの点線がファイル転送に対応する通信のスループットである。通信開始から最初の約１０秒間はビデオストリーミング（実線：１０Ｍｂｐｓ）とファイル転送（点線：１４Ｍｂｐｓ）が十分な帯域（例えば、無線ＬＡＮ全体で３０Ｍｂｐｓ）で転送が行われているが、通信開始から約１０秒の時点で新たな１４Ｍｂｐｓのファイル転送が加わったときの様子を示している。

図３（ａ）に示すＷＭＭで規定するプライオリティ（優先度）情報としてのアクセスカテゴリを適用した通信処理においては、通信開始から約１０秒の時点で新たな１４Ｍｂｐｓのファイル転送が加わった以後においても、実線で示すビデオストリーミングは影響なく転送が行われているが、図３（ｂ）に示すＷＭＭで規定するプライオリティ（優先度）情報としてのアクセスカテゴリを適用しない通信処理においては、新たなファイル転送の影響を受け、実線で示すビデオストリーミングの転送レートが下がっている。

図３（ｂ）に示す例では、ビデオストリーミングは、２つのファイル転送通信によって、利用可能帯域が減少しスループットが低下し、ストリーミング配信を受けるクライアントでは、受信ＡＶデータの再生画像が止まったり音が途切れたりする。

図３（ａ）に示すＷＭＭで規定するプライオリティ（優先度）情報としてのアクセスカテゴリを適用した通信処理においては、実線で示すビデオストリーミングデータの通信パケットに設定される優先度情報としてのアクセスカテゴリが、［ビデオプライオリティ（ＷＭＭ Ｖｉｄｅｏ Ｐｒｉｉｏｒｉｔｙ）］であり、ファイル転送パケットに設定されるアクセスカテゴリ［バックグラウンドプライオリティ（ＷＭＭ Ｂａｃｋｇｒｏｕｎｄ Ｐｒｉｉｏｒｉｔｙ）］より上位の優先度であり、実線で示すビデオストリーミングデータについては、優先的な帯域割り当てが行われ、結果として、ファイル転送の出現による帯域減少を発生させることなくストリーミングデータ配信が継続される。

このように、例えば、ＷＭＭで規定するプライオリティ（優先度）情報としてのアクセスカテゴリを適用した通信処理を実行することで、プライオリティ（優先度）の高い通信データの配信が優先され、十分な帯域の確保が保障されクライアント側での再生エラーの発生を防止できる。

本発明の通信処理においては、このようなプライオリティベースのＱｏＳ技術に基づいて競合通信についてプライオリティベースの制御を行い、さらに、新たにストリーミングを開始するサーバ自身が優先度制御を行なう。すなわち、新たにストリーミングデータの配信を開始しようとするサーバは、既にネットワークを介して実行中のストリーミング配信に対して大きな影響を与えないように通信制御を行う。

図４に、本発明に従ったデータ送信処理を実行する通信処理装置としてのサーバのハードウェア構成例を示す。図４に示す通信処理装置のハードウェア構成は、例えば、図１に示すサーバ１０１またはサーバ１０２の構成である。データ処理、通信処理の全体的制御を実行し、通信制御部として機能するＣＰＵ２０１、各種のデータ処理、通信処理プログラム、ＯＳなどのプログラムの格納領域、プログラム実行のワーク領域などに適用されるメモリ２０２、有線および無線ネットワークを介した通信インタフェースとしてのネットワークＩ／Ｆ２０３、ＡＶデータのデコード処理（例えばＭＰＥＧデコード）を実行するデコーダ２０４、ＡＶデータのエンコード処理を実行するエンコーダ２０５、放送波の受信によってＡＶコンテンツを入力するチューナ２０６、ハードディスクなどのデータ記憶部２０８、データ記憶部に対するデータ入出力制御を実行する記憶部Ｉ／Ｆ２０７を有し、バス２００を介して各処理部のデータ転送が行われる。

例えば、テレビ放送などがチューナ２０６によって受信され、受信された映像および音声を含むＡＶデータは、エンコーダ２０５において例えばＭＰＥＧ２の映像データと、ＭＰＥＧ１−Ａｕｄｉｏ−Ｌａｙｅｒ２の音声データに符号化圧縮され、ＰＳストリームが生成される。エンコード処理によって生成されたＰＳストリームは、記憶部Ｉ／Ｆ２０７を介してハードディスク（ＨＤ）などのデータ記憶部２０８に格納される。これらのデータ処理制御は、メモリ２０２上に記憶されたＯＳやアプリケーションプログラムをＣＰＵ２０１によって実行することで行われる。

ハードディスク等のデータ記憶部２０８に記録されたコンテンツを再生する場合、コンテンツは、データ記憶部２０８から記憶部Ｉ／Ｆ２０７を介して読み出され、デコーダ２０４に転送されて、デコード処理によって伸張され、ＡＶ出力端子からアナログ出力される。ＡＶ出力端子は、例えばテレビに接続されており、記録されたコンテンツの映像、音声を再生することができる。

図４に示す通信処理装置は、さらに、ハードディスク等のデータ記憶部２０８に記録されたコンテンツをネットワークＩ／Ｆ２０３を介して、他のクライアント機器へストリーミング配信するサーバ機能を有しており、これら機能の実現のために、前述したＤＬＮＡ（Digital Living Network Alliance）のガイドラインに準拠したネットワークプロトコルが実装される。

図５にＤＬＮＡのガイドラインの機能コンポーネントを示す。上段から、メディアフォーマット、メディア転送、デバイスディスカバリ制御及びメディア制御、ネットワークスタック、ネットワーク接続の各構成が定義されている。図４に示す通信処理装置（サーバ）は、この図５に示す基本コンポーネントに従ってＤＬＮＡ（Digital Living Network Alliance）のガイドラインに準拠したネットワークプロトコルに従ったデータ通信、すなわちクライアント対するストリーミングデータの配信を実行する機能を持つ。

図４に示す通信処理装置（サーバ）において、ハードディスク等のデータ記憶部２０８に記録されるＡＶコンテンツは、ＤＬＮＡが規定する必須メディアフォーマットであるＭＰＥＧ２ＰＳ＿ＮＴＳＣ（ＭＰＥＧ２ビデオ：解像度７２０ｘ４８０，２９．９７フレーム毎秒、ＭＰＥＧ１オーディオ：Ｌａｙｅｒ２サンプリング周波数４８ｋＨｚ、ステレオ）のメディアフォーマットプロファイルに準拠したコンテンツである。

ＡＶコンテンツは４−１０．８ＭｂｐｓのＭＰＥＧ２ＰＳストリームとしてエンコードされている。ネットワークＩ／Ｆはイーサネット（登録商標）１０ＢＡＳＴ−Ｔ／１００ＢＡＳＴ−ＴＸ（８０２．３ｉ，８０３．３ｕ準拠）を搭載しており、最大１００Ｍｂｐｓの帯域まで伝送に利用することができる。ただし、８０２．１１ｇなどの無線ＬＡＮが伝送経路に存在した場合は、実質２５Ｍｂｐｓくらいの伝送帯域しか利用することができない。また、無線通信の場合は機器の設置環境によって、利用できる帯域は大幅に増減する。１０ＭｂｐｓのＭＰＥＧ２ＰＳストリームの伝送では、通常２本、状況が悪い場合には１本の正常なストリーミング伝送しか行なえない場合がある。

図６を参照して、コンテンツ配信を実行するサーバとしての通信処理装置のＡＶコンテンツのストリーミング伝送のアーキテクチャについて説明する。ストリーミング伝送を担当するアプリケーションは、ＨＴＴＰ（ＲＦＣ−２６１６）準拠のＨＴＴＰサーバとして機能する。例えばコンテンツ配信を希望するクライアントからのコンテンツ要求としてのＨＴＴＰリクエストを、ネットワークを介して受信し、受信したＨＴＴＰリクエストを解釈して、そのリクエストで指定されたコンテンツをハードディスク等のデータ記憶部から読み出して、コンテンツをＨＴＴＰレスポンスのペイロードデータとして格納したＨＴＴＰパケットを生成してクライアントに返信する処理を実行する。

ここでは、ＭＰＥＧデータのビデオコンテンツのストリーミング配信を実行する際のＨＴＴＰレスポンスの場合を例としてデータのカプセル化の説明を行なう。ＨＴＴＰレスポンスは先頭のＨＴＴＰヘッダ部とそれに続くＨＴＴＰボディ部で構成され、ＭＰＥＧデータはＨＴＴＰボディ部として転送される。

図６に示すアプリケーション３０１は、コンテンツ配信を実行する通信処理装置であるサーバの通信制御部として機能するサーバアプリケーションであり、クライアントからのコンテンツ要求としてのＨＴＴＰリクエストを解釈し、リクエストで指定されたコンテンツをハードディスク等のデータ記憶部から読み出して、コンテンツをペイロードとして設定したＨＴＴＰレスポンスデータ３２１を生成する。さらに、ＴＣＰ／ＩＰスタック３０２を構成するＴＣＰスタックのＡＰＩを利用して、ＨＴＴＰレスポンスデータ３２１をＴＣＰスタックに書き込む処理を実行する。

ＴＣＰスタックに書き込まれたアプリケーションデータとしてのＨＴＴＰレスポンスデータ３２１は、ＴＣＰスタックによりＴＣＰパケットに分割され、個々のＴＣＰパケットにＴＣＰヘッダが付加される。さらに、ＴＣＰスタックからＩＰスタックに送られ、ＩＰヘッダが付加されたＩＰパケット３２２が生成される。

さらに、ＩＰパケット３２２は、デバイスドライバ３０３において、イーサネット（登録商標）のイーサヘッダが付加され、イーサフレーム３２３としてイーサネット（登録商標）３０４によって構成されるネットワークに送出される。なお、イーサヘッダの付加はネットワークＩ／ＦのＬＳＩで行われる場合もあるが、ここではＬＳＩの制御を含めてデバイスドライバ３０３によって実行されるものとする。通常のＤＬＮＡガイドライン規定のＡＶコンテンツのストリーミングでは、上述の処理の流れに従って、ＡＶコンテンツのストリーミング伝送が行われる。

本発明では、図６を参照して説明したパケット生成シーケンスにおいて、イーサフレーム３２３のイーサヘッダに、ＩＥＥＥ８０２．１Ｄにおいて規定する通信優先度情報としてのプライオリティを示すプライオリティタグを設定する。本実施例では、ＩＥＥＥ８０２．１Ｄに規定されるプライオリティタグの付加処理をデバイスドライバ３０３において行なう。アプリケーション３０１は、直接、デバイスドライバ３０３を制御して、プライオリティタグの設定を行うことはない。

アプリケーション３０１は、ストリーミング伝送のＨＴＴＰレスポンスを送信するＴＣＰコネクションのＩＰヘッダのＴＯＳフィールドに通信優先度情報としてのプライオリティを示すＤＳＣＰ（Differentiated Service Code Point）が付加されるように、ＴＣＰ／ＩＰスタック３０２のＡＰＩを設定する。

なお、通信優先度情報としてのプライオリティを示すＤＳＣＰはＲＦＣ−２４７４，ＲＦＣ−２４７５で規定されており、ネットワーク層におけるプライオリティによるＱｏＳの規定である。デバイスドライバ３０３は、上位スタックから渡されたデータのＩＰヘッダに付加されたＤＳＣＰプライオリティ値を参照し、ＩＰヘッダに設定されたＤＳＣＰプライオリティ値に対応した８０２．１Ｄのプライオリティタグをイーサヘッダに付加する処理を実行する。

これらの処理の結果として、アプリケーション３０１が所望したストリーミング伝送のイーサフレーム３２３に対してのみ、ＩＥＥＥ８０２．１Ｄに規定するプライオリティタグが付加される。

なお、本実施例では、イーサネット（登録商標）を介した通信処理例を説明しており、イーサネット（登録商標）を介した通信処理を実行する場合の８０２．１Ｄタグのプライオリティタグの付加処理例を説明しているが、例えば無線ＬＡＮを適用した通信（例えばＩＥＥＥ８０２．１１ｇ）を実行する場合はデバイスドライバ３０３において、先に図２を参照して説明したＷＭＭ規定の通信優先度情報（プライオリティ）に相当するアクセスカテゴリ情報を付加する。

デバイスドライバ３０３において、ＷＭＭ規定の通信優先度情報（プライオリティ）に相当するアクセスカテゴリ情報を付加する場合も、デバイスドライバ３０３は、上位スタックから渡されたデータのＩＰヘッダに付加されたＤＳＣＰプライオリティ値を参照し、ＩＰヘッダに設定されたＤＳＣＰプライオリティ値に対応したＷＭＭ規定のアクセスカテゴリ情報をイーサヘッダに付加する処理を実行する。

図７に、ＤＬＮＡなどのホームＡＶネットワークで利用する４段階のプライオリティおよびそれを使用する伝送の種類と、これらの４つのプライオリティと、ＩＥＥＥ８０２．１Ｄにおいて規定されるプライオリティ値（有線ＬＡＮにおいて適用）、およびＷＭＭにおいて規定されるアクセスカテゴリ（無線ＬＡＮにおいて適用）、さらに、ＩＰヘッダのＴＯＳフィールドに通信優先度情報として設定されるプライオリティを示すＤＳＣＰ（ＩＰヘッダに格納）の対応関係を格納したプライオリティ対応テーブルを示す。

図７に示すように、プライオリティ対応テーブルには、有線ＬＡＮ（８０２．３ｉ，３ｕ）や、無線ＬＡＮ（８０２．１１ｂ，１１ｇ，１１ｂ）によって構成されるホームＡＶネットワークに対応する４段階の通信優先度情報としてのプライオリティが登録されている。すなわち、
（ａ）ＱＯＳ＿ＣＯＮＴＲＯＬ
（ｂ）ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ
（ｃ）ＱＯＳ＿ＩＮＴＥＲＡＣＴＩＶＥ
（ｄ）ＱＯＳ＿ＢＡＣＫＧＲＯＵＮＤ
これら４種類のプライオリティである。

ＱＯＳ＿ＣＯＮＴＲＯＬが一番高いプライオリティであり、最も優先的に処理される。ただし、ＱＯＳ＿ＣＯＮＴＲＯＬはＡＶコンテンツの伝送では使用されない。次にＱＯＳ＿ＳＴＲＥＡＭＩＮＧの優先度が高い、これがビデオ、オーディオのＡＶコンテンツのストリーミング伝送で使用される。これらＡＶコンテンツの伝送ではリアルタイム性が求められ、所望のデータレートにて伝送が維持され、低遅延のデータ転送が必要であり、比較的高い優先度に設定される。

次にＱＯＳ＿ＩＮＴＥＲＡＣＴＩＶＥが高い優先度であるが、これは写真などの静止画像の伝送に使用され、ストリーミングデータのようにデータ転送のリアルタイム性は求められないが、静止画表示までにユーザの待ち時間が短い方がよいので、ファイルのダウンロード、コピー、アップロードなどのデータ転送に用いられるＱＯＳ＿ＢＡＣＫＧＲＯＵＮＤより高いプライオリティが設定される。

通常のプライオリティの利用では、伝送データの種類によって、図７に示すプライオリティ対応テーブルに設定された４種類のプライオリティ、すなわち、
（ａ）ＱＯＳ＿ＣＯＮＴＲＯＬ
（ｂ）ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ
（ｃ）ＱＯＳ＿ＩＮＴＥＲＡＣＴＩＶＥ
（ｄ）ＱＯＳ＿ＢＡＣＫＧＲＯＵＮＤ
通信パケットには、これら４種類のプライオリティに対応する通信優先度情報が設定される。

すなわち、先に、図６を参照して説明したように、通信処理を実行するアプリケーション３０１はＴＣＰ／ＩＰスタック３０２のＡＰＩを利用して、ＩＰヘッダのＴＯＳフィールドに通信優先度情報として設定されるプライオリティを示すＤＳＣＰの値を、図７に示す（ａ）〜（ｄ）のいずれか４種類のプライオリティに対応して設定する。すなわち、ＤＳＣＰ値として、［０ｘ３８］、［０ｘ２８］、［０ｘ００］、［０ｘ０８］、のいずれかをＩＰヘッダのＴＯＳフィールドに設定する。

次に、ネットワークＩ／Ｆに対応するデバイスドライバ３０３は、イーサネット（登録商標）を介した通信処理を実行する場合は、ＩＥＥＥ８０２．１Ｄタグのプライオリティタグの付加処理を実行する。この場合、デバイスドライバ３０３は、ＩＰヘッダのＴＯＳフィールドに設定されたＤＳＣＰ値に対応するＩＥＥＥ８０２．１Ｄタグのプライオリティタグの値を図７に示すプライオリティ対応テーブルに従って選択して設定する。すなわち、［７］、［５］、［０］、［１］のいずれかをイーサヘッダに付加する処理を実行する。

例えば、図１に示すネットワーク接続例におけるサーバＡ１０１とクライアントＡ１１１のストリーミング伝送では、本来のストリーミングデータの配信では、プライオリティとして［ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ］が使用される。図７に示すプライオリティ対応テーブルの規定に従い、サーバＡ１０１のアプリケーションはＴＣＰ／ＩＰスタックのＡＰＩを利用して、ＩＰヘッダのＴＯＳフィールドに通信優先度情報として設定されるプライオリティを示すＤＳＣＰの値［０ｘ２８］を設定する。

さらに、デバイスドライバによって、そのストリーミング伝送のイーサフレームに対して、ＩＰヘッダのＴＯＳフィールドに設定されたＤＳＣＰ値［０ｘ２８］に対応するＩＥＥＥ８０２．１Ｄタグのプライオリティタグの値を図７に示すプライオリティ対応テーブルに従って選択して設定する。すなわち、ＩＥＥＥ８０２．１Ｄタグのプライオリティタグ［５］が選択されてイーサヘッダに付加される。

図１に示すサーバＡ１０１からイーサフレームを受信したホームルータ（ブリッジ）等の通信制御部１０３は、そのイーサフレームに設定されたＩＥＥＥ８０２．１Ｄタグのプライオリティ値を解釈し、無線ＬＡＮ８０２．１１ｇに送出する処理を実行する。この処理に際して、図７に示すプライオリティ対応テーブルに基づいて、ＩＥＥＥ８０２．１Ｄタグのプライオリティ値［５］に対応するＷＭＭ規定のアクセスカテゴリ値［ＶＩ］に基づいて、このイーサフレームをＶＩプライオリティとして処理し、それより低いプライオリティ（例えばＢＥ，ＢＫ）の無線ＬＡＮのトラフィックよりも、優先した伝送を実行する。

しかしながら、図１に示すネットワーク接続例において、サーバＡ１０１とクライアントＡ１１１が、１０Ｍｂｐｓのビデオのストリーミング伝送をしている場合に、クライアントＢ１１２とサーバＢ１０２の間で、同じく１０Ｍｂｐｓのビデオストリーミングが開始された場合、これら２つのデータ通信は、同じＱＯＳ＿ＳＴＲＥＡＭＩＮＧのプライオリティに従って処理が実行されることになる、すなわち、通信データの中継、制御を実行するブリッジ等の通信制御部１０３では、これら２つのデータ通信を同等に処理することになる。

このような状況において、ブリッジ等の通信制御部１０３とクライアントＡ１１１〜クライアントＣ１１３を接続する無線ＬＡＮにおいて２つのストリーミング伝送をおこなうのに十分な帯域を確保できない場合は、いずれのストリーミングデータもリアルタイムに伝送されないため、クライアントＡ１１１とクライアントＢ１１２双方のストリーミング再生で絵や音が途切れる現象が起きる。

本発明では、この問題を避けるために、サーバから新たなストリーミングデータの配信を開始する際、一定期間のアドミッションコントロールフェーズ（Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｈａｓｅ）を設け、本来、ストリーミングデータ配信に対応して設定されたプライオリティより低いプライオリティを設定した低プライオリティデータ送信を実行する。

すなわち、一定期間のアドミッションコントロールフェーズにおいて、低プライオリティに設定してデータ送信を実行し、この低プライオリティ設定下でのデータ送信状況を検証して、検証結果に基づいてストリーミング伝送に対応する本来の規定のプライオリティに移行してもよいか否かを判定し、移行が許容されると判断した場合にストリーミング伝送に対応する本来の規定のプライオリティに移行したデータ送信を実行する。

このアドミッションコントロールフェーズ（Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｈａｓｅ）期間は、ストリーミング伝送で使用するプライオリティより低いプライオリティを用いた低プライオリティデータ送信期間であり、この期間であれば、同時に別のストリーミング伝送が行われていたとしても、その既存のデータ伝送に対して与える影響は防止される。すなわち、既存のストリーミング配信がある場合、その既存ストリーミングの帯域を奪ってしまうことがないため、既存のストリーミングを再生しているクライアントの再生画像を乱すといったことが発生しない。

この低プライオリティデータ送信期間を利用し、データ送信者としてのサーバ自身が伝送状態を検査する。すなわち、ストリーミングのプライオリティに切り替えて伝送をおこなうのに十分なネットワーク帯域があるかどうか、つまり、ストリーミングのプライオリティに切り替えて伝送を行った場合に、他の既存のストリーミング伝送に影響を与えないかを検証する。この検証の結果、問題なしとの判定結果が得られた場合に、サーバは、ストリーミングに対応する本来の規定された正しいプライオリティに設定を変更して伝送を開始する。

図８を参照して、アドミッションコントロールフェーズ（Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｈａｓｅ）を設定したデータ送信シーケンスについて説明する。アドミッションコントロールフェーズ（Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｈａｓｅ）の期間は、本来、ストリーミング伝送に対応して設定されるプライオリティより低いプライオリティを設定したデータ送信期間である。

本来、ストリーミング伝送に対応して設定される本来のプライオリティは、図７に示すプライオリティ対応テーブルに設定された４種類のプライオリティ、すなわち、
（ａ）ＱＯＳ＿ＣＯＮＴＲＯＬ
（ｂ）ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ
（ｃ）ＱＯＳ＿ＩＮＴＥＲＡＣＴＩＶＥ
（ｄ）ＱＯＳ＿ＢＡＣＫＧＲＯＵＮＤ
これら４つのプライオリティ中、
（ｂ）ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ
である。

本実施例では、図８に示すデータ送信開始から一定期間（ｔ０〜ｔ１）をアドミッションコントロールフェーズとする。たとえば送信開始から１分程度の予め設定された期間をアドミッションコントロールフェーズとする。

このアドミッションコントロールフェーズでは、本来のストリーミング伝送に対応して設定されるべきプライオリティ［ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ］より低優先度の［ＱＯＳ＿ＩＮＴＥＲＡＣＴＩＶＥ］をプライオリティとして設定したデータ送信を実行する。なお、さらに低優先度の［ＱＯＳ＿ＢＡＣＫＧＲＯＵＮＤ］を利用する構成としてもよい。

本実施例では、データ伝送初期に設定されるアドミッションコントロールフェーズにおいて、［ＱＯＳ＿ＩＮＴＥＲＡＣＴＩＶＥ］を設定プライオリティとしてストリーミングデータ配信処理を実行する。この低プライオリティに設定したデータ送信期間において、データ通信状況を検証する。すなわち、本来のストリーミングのプライオリティ［ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ］に切り替えて伝送をおこなうのに十分なネットワーク帯域があるかどうか、つまり、本来のストリーミングのプライオリティ［ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ］に切り替えて伝送を実行した場合に、他のストリーミング伝送に影響を与えないかを判定する。この検証の結果、問題なしとの判定結果が得られた場合に、サーバは、図８に示す時間（ｔ１）において、ストリーミングに対応する正しいプライオリティ［ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ］に切り替えて伝送を開始する。

図９を参照して、ＨＴＴＰに従ったストリーミングデータ配信を実行するサーバとストリーミングデータ再生を行うクライアントの各コンポーネント構成と処理について説明する。ＤＬＮＡにおける規定と同様、本実施例では、ＨＴＴＰを用いたストリーミング伝送例について説明する。ＨＴＴＰはＴＣＰコネクションを適用しており、ＴＣＰのフロー制御でデータ伝送が行われる。クライアント（受信側）が十分なレートにてデータ受信していない、もしくは、ネットワークに十分な伝送帯域がない場合は、サーバ（送信側）はＴＣＰプロトコルのフロー制御によりデータ送信が抑制され、ＭＰＥＧストリームのビットレートにて伝送を維持することができない。

ＤＬＮＡガイドラインでは、クライアントは、要求コンテンツのＭＰＥＧストリームのビットレートで受信する能力を持つことが義務づけられている。例えば、ＭＰＥＧ２ＰＳコンテンツの場合は、ＭＰＥＧストリームの最大ビットレートは１０．８Ｍｂｐｓと規定されているので、クライアントは１０．８Ｍｂｐｓの転送レートにて受信する能力があると仮定して良い。

つまり、サーバがＭＰＥＧストリームのビットレートにて伝送できない状態が検出された場合、十分なネットワーク帯域が得られないネットワーク状態にあると判定することができる。ＤＬＮＡ規定によれば、クライアントがストリーミング伝送を要求しているか、ダウンロード転送を要求しているかについての判断は、ＨＴＴＰリクエストの伝送に使用されているプライオリティもしくは、ＨＴＴＰリクエストの特定のヘッダを調べることで実現できる。

ＴＣＰのフロー制御はＴＣＰ／ＩＰスタックのソフトウェアで行われる。サーバ５１０において通信制御部として機能するサーバアプリケーション５１１は、クライアントからのＨＴＴＰリクエストにおいて指定されたＡＶコンテンツをデータ記憶部５１６から取得してバッファ５１５を介してＴＣＰ／ＩＰスタック５１４に対してＡＶコンテンツデータを書き込む。すなわち、図６を参照して説明したように、ＴＣＰ／ＩＰスタック５１４を構成するＴＣＰスタックのＡＰＩを利用して、ＨＴＴＰレスポンスデータをＴＣＰスタックに書き込む。

サーバアプリケーション５１１は、このＨＴＴＰレスポンスデータのＴＣＰ／ＩＰスタック５１４に対する書き込み速度を監視する。クライアント（受信側）が十分なレートでデータ受信を実行している場合は、クライアント側で実行されるリアルタイム再生速度に応じた速度で書き込みが実行されることになる。クライアント（受信側）が十分なレートにてデータ受信していない場合や、ネットワークに十分な伝送帯域がない場合は、サーバ（送信側）はＴＣＰプロトコルのフロー制御によりデータ送信が抑制され、ＭＰＥＧストリームのビットレートによる書き込みが実行できなくなる。サーバアプリケーション５１１は、このＨＴＴＰレスポンスパケットのＴＣＰ／ＩＰスタック５１４に対する書き込み速度を監視することで、ストリーミングデータの伝送に十分なネットワーク帯域があるか否かを判断する。

なお、サーバ５１０のＴＣＰ／ＩＰスタック５１４では、先に図６を参照して説明したように、ＴＣＰスタックに書き込まれたアプリケーションデータとしてのＨＴＴＰレスポンスデータ（図６に示すＨＴＴＰレスポンスデータ３２１）を、ＴＣＰパケットに分割し、個々のＴＣＰパケットにＴＣＰヘッダを付加し、さらに、ＴＣＰスタックからＩＰスタックに送られ、ＩＰヘッダを付加したＩＰパケットを生成する。

サーバアプリケーション５１１は、ＩＰヘッダのＴＯＳフィールドに通信優先度情報としてのプライオリティを示すＤＳＣＰ（Differentiated Service Code Point）が付加されるように、ＴＣＰ／ＩＰスタック５１４のＡＰＩを設定する。これにより、ＩＰヘッダにはＤＳＣＰプライオリティが設定される。

本発明に従った処理においては、初期的に設定されるアドミッションコントロールフェーズにおいて、本来のストリーミング伝送に対応して設定されるべきプライオリティ［ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ］より低優先度の［ＱＯＳ＿ＩＮＴＥＲＡＣＴＩＶＥ］に対応するＤＳＣＰ値、すなわち図７に示すテーブルのＤＳＣＰ値［０ｘ００］が設定される。

さらに、ＩＰパケットは、デバイスドライバ５１３において、イーサネット（登録商標）のイーサヘッダが付加され、イーサフレーム（図６に示すイーサフレーム３２３）としてネットワークインタフェース５１２を介してネットワーク５００に出力される。

デバイスドライバ５１３は、上位スタックから渡されたデータのＩＰヘッダに付加されたＤＳＣＰプライオリティ値を参照し、ＩＰヘッダに設定されたＤＳＣＰプライオリティ値に対応した８０２．１Ｄのプライオリティタグをイーサヘッダに付加する処理を実行する。なお、ネットワークインタフェース５１２を介した出力が無線ＬＡＮを適用した通信（例えばＩＥＥＥ８０２．１１ｇ）を実行する場合はデバイスドライバ５１３において、先に図２を参照して説明したＷＭＭ規定の通信優先度情報（プライオリティ）に相当するアクセスカテゴリ情報が付加される。

いずれの場合も、データ伝送の初期に実行されるアドミッションコントロールフェーズでは、本来のストリーミング伝送に対応して設定されるべきプライオリティ［ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ］より低優先度の［ＱＯＳ＿ＩＮＴＥＲＡＣＴＩＶＥ］に対応するＤＳＣＰ値［０ｘ００］に対応する８０２．１Ｄのプライオリティタグ［０］、またはＷＭＭ規定のアクセスカテゴリ情報［ＢＥ］（図７参照）が設定される。

クライアント５２０は、ネットワークＩ／Ｆ５２２を介して、サーバの送信する例えばイーサフレームを受信し、デバイスドライバ５２３において、イーサフレームからＩＰパケットを取り出し、ＴＣＰ／ＩＰスタック５２４において、ＩＰパケットからＨＴＴＰレスポンスデータを取得し、ＨＴＴＰレスポンスデータに格納されたＭＰＥＧコンテンツとしてのＡＢストリームデータをパッファ５２５に格納した後、ＭＰＥＧデコーダ５２６においてデコード処理してＡＶストリームの再生、出力を実行する。これらの処理はクライアントアブリケーション５２１によって制御されて実行される。

サーバ５１０側のから送信されるコンテンツのデータ量が、クライアント５２０側でのコンテンツ再生データ量とバランスすることで、ストリーミングデータ配信および再生が成功し、クライアント側で再生データが停止することのない遅れのない再生処理が実現される。

送信コンテンツであるＭＰＥＧ２ストリームのエンコードビットレートが一定、すなわちコンスタント・ビットレート（Constant Bit rate）でエンコードされているコンテンツを送信する場合は、サーバ５１０のアプリケーション５１１はＴＣＰ／ＩＰスタック５１４に対するＨＴＴＰレスポンスパケットの書き込み速度を監視し、書き込み速度情報に基づいて、クライアント５２０が、送信コンテンツをデコード再生するに十分な転送レートで送信されているかを正確に判断することができる。これは、ＴＣＰ／ＩＰスタック５１４に対するＨＴＴＰレスポンスパケットの書き込み速度が、クライアント５２０におけるコンテンツのデコード再生速度と対応するからである。

しかし、サーバ５１０から送信するコンテンツであるＭＰＥＧ２ストリームのエンコードビットレートが変化するバリアブルビットレート（Variable Bit rate）コンテンツを送信する場合は、ＴＣＰ／ＩＰスタック５１４に対するＨＴＴＰレスポンスパケットの書き込み速度情報と、クライアント５２０におけるコンテンツのデコード再生速度と対応しない。

このような、バリアブルビットレート（Variable Bit rate）コンテンツを送信する場合は、ＴＣＰ／ＩＰスタック５１４に対するＨＴＴＰレスポンスパケットの書き込み速度のみに依存して、転送ビットレートが固定ビットレートを超えているか否か、すなわちサーバからのコンテンツ送信量がクライアント側の再生コンテンツ量に足りているかを判断するのは適当ではない。

本発明では、このようなバリアブルビットレート（Variable Bit rate）コンテンツを送信する場合においても、クライアント側のリアルタイム再生が保証されるように処理を行なう。図１０は、ＨＴＴＰによるストリーミング伝送時の伝送ビットレートの変化を示したものである。横軸は経過時間（Ｔ）、縦軸はサーバが送出するデータの転送ビットレートを示す。

すべてのクライアントは、ストリーミング伝送途中にネットワーク輻輳に備えて、デコードを開始する前に、バッファに対して受信データをある程度、予備蓄積するプリバッファリングをおこなう。このプリバッファリング処理が実行されるため、ストリームデータの伝送開始時には多くのデータがサーバから一度に伝送される。図１０に示す時間Ｔ１〜Ｔ２がプリバッファリング期間に相当する。

その後、クライアントがデコードを開始するとデータ転送は伝送しているストリームのビットレートに追随して変動する。図１０に示す時間Ｔ２以降が、クライアントによるデコード、再生時間に相当する。時間Ｔ１〜Ｔ２部分は、プリバッファリング時に転送されたデータ量であるが、ストリーミング伝送の途中で、このデータを再生するのに要する時間以上、クライアントのバッファが枯渇するとデコードは破綻し、動画像の絵や音が止まったりする現象が起こる。

このことから、本発明の通信処理装置としてのサーバは、以下の［判定式１］が成立している間は、十分なネットワークの帯域があり、クライアントのバッファ枯渇は起きていないと判断する。
［判定式１］
（検証点）−（クライアントのデコード開始点）＜（検証点まで転送した総データを再生するのに要する時間）−（プリバッファリングされたデータを再生するのに要する時間）

上記式について、図１０を参照して説明する。図１０において、検証点を時間（Ｔ３）とする。クライアントのデコード開始点は時間（Ｔ２）である。「検証点まで転送した総データを再生するのに要する時間」は、時間Ｔ１〜Ｔ３においてサーバが送信した総データ量である。これは、図に示すデータＡとＢの総和、すなわちＡ＋Ｂである。「プリバッファリングされたデータを再生するのに要する時間」は、図に示すデータＡの再生に要する時間である。

すなわち、上記の［判定式１］は、図１０において、
（時間［Ｔ３〜Ｔ２］）＜（データＡ＋Ｂの再生時間）−（データＡの再生時間）
であり、上記式において、
（データＡ＋Ｂの再生時間）−（データＡの再生時間）＝（データＢの再生時間）
であるので、結果としては、
（時間［Ｔ３〜Ｔ２］）＜（データＢの再生時間）
が成立するか否かを判定することになる。この式が成立すれば、クライアントのバッファ枯渇は起きておらず、ストリーミングデータ配信、再生が成功していると判定する。

しかしながら、通常は、サーバはクライアントのデコード開始点、すなわち、図１０における時間（Ｔ２）を判断できない。従って、プリバッファリングされるデータ量（Ａ）も知ることができないが、クライアントがＨＴＴＰリクエスト時に、プリバッファリングするデータ量（バイト数）もしくはプリバッファリングするデータの再生時間を、サーバに対して特定のＨＴＴＰヘッダにて通知する設定として、上記の［判定式１］を適用して、ストリーミングデータの配信、再生処理が可能な十分なデータ送信が実行されているかを判定する構成としてもよい。

このように、クライアント側から、
プリバッファリングするデータ量（バイト数）、あるいは、
プリバッファリングするデータの再生時間、
これらのいずれかの情報をサーバが受領する構成とすれば、上記の判定式１を適用した処理が実現される。

先に、図８を参照して説明したアドミッションコントロールフェーズの終了点（ｔ１）を検証点、すなわち、図１０における検証点（Ｔ３）として設定し、サーバは、この時間において、上記の［判定式１］を適用した検証判定処理を実行する。

サーバが、アドミッションコントロールフェーズの終了点において、上記［判定式１］が成立していると判定した場合は、ストリーミングデータ配信に十分な帯域が確保できると判断し、ストリーミングデータの配信に対応する本来のプライオリティ、すなわち、［ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ］に対応するプライオリティの設定変更を行なってストリーミングデータの配信を継続する。

アドミッションコントロールフェーズの終了点である検証点において、上記［判定式１］が成立していないと判定した場合は、ストリーミングデータ配信に十分な帯域が確保できていないと判断し、そのまま、アドミッションコントロールフェーズを継続する。すなわち、ストリーミングデータの配信に対応する本来のプライオリティ以下のプライオリティ設定での送信を継続する。あるいはユーザ通知処理やデータ送信の中止を行なう構成としてもよい。

なお、ストリーミングデータの配信に対応する本来のプライオリティ、すなわち、［ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ］に対応するプライオリティの設定変更を行なってストリーミングデータの配信を継続する場合は、まず、サーバアプリケーションによって、ＩＰヘッダのＴＯＳフィールドに設定する通信優先度情報としてのプライオリティを示すＤＳＣＰ（Differentiated Service Code Point）の設定が変更され、その後、デバイスドライバにおいて、イーサネット（登録商標）のイーサヘッダの付加に際して、ＩＰヘッダに付加されたＤＳＣＰプライオリティ値を参照し、ＩＰヘッダに設定されたＤＳＣＰプライオリティ値に対応した８０２．１Ｄのプライオリティタグの変更、または、ＷＭＭ規定の通信優先度情報（プライオリティ）に相当するアクセスカテゴリ情報の変更処理が行われることになる。

このプライオリティ変更処理によって、ストリーミングデータは、本来のプライオリティに従って、例えば図１に示す通信制御部１０３においてＱｏＳ制御されて配信されることになる。

しかし、前述したように、上記の［判定式１］を適用できるのは、クライアント側から、
プリバッファリングするデータ量（バイト数）、あるいは、
プリバッファリングするデータの再生時間、
これらのいずれかの情報をサーバが受領する構成とした場合であり、クライアントがこれらの情報を提供する設定でない場合は、対処できず汎用的でない。

以下、このようなクライアント側からの情報通知を受けない場合においても対応可能な処理例について説明する。以下で説明する処理例は、クライアントにおけるプリバッファリング時間を無視してストリーミングデータの配信状況を判定する処理例である。

クライアントにおけるコンテンツのプリバッファリング時間、すなわち、図１０に示す時間（Ｔ１〜Ｔ２）は、通常１秒くらいであるので、これを無視できるとして、検出時間（Ｔ３）を常にサーバ伝送開始後、所定時間、例えば１分で行う設定とする。すなわち、図１０に示す例において、伝送開始（Ｔ１）からの経過時間のみを計測して、予め定めた検証点（例えば伝送開始から１分）で、検証を実行する。

この検証点（Ｔ３）〜サーバの伝送開始点（Ｔ１）と、検証点まで転送した総データを再生するのに要する時間から、判定式を生成する。すなわち、以下の［判定式２］である。
［判定式２］
（検証点）−（サーバの伝送開始点）＜（検証点まで転送した総データを再生するのに要する時間）

上記式について、図１０を参照して説明する。
（検証点）−（サーバの伝送開始点）は、図１０における時間Ｔ３−Ｔ１である。
（検証点まで転送した総データを再生するのに要する時間）は、送信データ（Ａ＋Ｂ）を再生するのに要する時間である。

これは、クライアント側で、プリバッファされているデータＡと、デコード再生開始後のデータＢの総量の再生時間が、（検証点）−（サーバの伝送開始点）より長いか否かを判定する式である。すなわち、伝送開始から検証点に至るまでの時間と、検証点までに送信したデータ量の再生所要時間との比較に基づいて、クライアントのバッファ枯渇の発生や、ストリーミングデータ配信における十分な帯域確保状況を判定する。

上記［判定式２］が成立した場合、クライアントのバッファ枯渇は起きておらず、ストリーミングデータ配信、再生が成功していると判定する。なお、上記の［判定式２］を適用することで、結果として、１分間の平均的な伝送状態を検査するというメリットもある。

最後に、図１１に示すフローチャートを参照して、本発明の通信処理装置、すなわちサーバの実行するストリーミング伝送処理の処理シーケンスについて説明する。なお、図１１に示す処理は、データ送信処理を実行するサーバの通信制御部の処理、具体的にはサーバアプリケーションの処理として実行される。

まず、ステップＳ１０１において、サーバはクライアントからのＨＴＴＰリクエストの受信を待機する。ステップＳ１０２において、クライアントからのコンテンツ要求を伴うＨＴＴＰリクエストを受信したと判定すると、ステップＳ１０３に進み、ＨＴＴＰのＴＣＰコネクションプライオリティを［ＱｏＳ＿ＩＮＴＥＲＡＣＴＩＶＥ］に設定する。すなわち、図８他を参照して説明したアドミッションコントロールフェーズの処理を開始し、ストリーミンクデータ配信に対応するプライオリティ［ＱｏＳ＿ＳＴＲＥＡＭＩＮＧ］より低いプライオリティの設定処理を行なう。

ステップＳ１０４において、ＴＣＰのソケットに対してＨＴＴＰレスポンスヘッダデータを書き込み、ステップＳ１０５において、クライアントから受信したＨＴＴＰリクエストに指定されたコンテンツデータをハードディスク等から取得して、ＴＣＰのソケットに対してＨＴＴＰレスポンスの書き込み処理を実行する。これらの処理は、図６を参照して説明したアプリケーション３０１のＴＣＰ／ＩＰスタック３０２に対するＨＴＴＰレスポンスの書き込み処理に相当する。

この書き込み処理データに基づいて、図６に示すＴＣＰ／ＩＰスタック３０２によるＩＰパケット生成、デバイスドライバ３０３におけるイーサフレーム等の生成がなされた後、クライアントに送信される。図１１に示す処理は、サーバアプリケーションの実行処理であり、これらの処理については省略してある。

サーバアプリケーションは、ステップＳ１０３〜１０５におけるプライオリティ設定と、ＴＣＰスタックに対するＨＴＴＰレスポンスデータの書き込み処理を実行すると、ステップＳ１０６において、データ送信開始、すなわち、ＴＣＰスタックに対するＨＴＴＰレスポンスデータの書き込み処理開始からの経過時間を計測し、予め定めた検証時間になったか否かを判定する。この検証時間は、図８を参照して説明したデータ伝送開始字に設定されるアドミッションコントロールフェーズの終了時間であり、図１０での検証点の時間に相当する。例えばデータの伝送開始から１分の時点である。

ステップＳ１０６において、検証時間でないと判定された場合は、ステップＳ１０９に進み、全てのファイルデータの送信が完了していない限り、ステップＳ１０５のデータ書き込み処理を継続する。

ステップＳ１０６において、検証時間であると判定した場合、すなわち、図１０に示す検証点に到達したと判定した場合は、ステップＳ１０７に進み、
データ送信時間（ｎ）＜（ｎ）までの全送信データの再生時間
が成立するか否かを判定する。
これは、前述の［判定式２］に相当する判定処理である。データ送信時間（ｎ）は、サーバからのデータ送信開始から、検証時間までの時間であり、
図８においては、ｔ０〜ｔ１、
図１０においては、Ｔ１〜Ｔ３、
に相当する。
（ｎ）までの全送信データの再生時間は、
図１０におけるデータ（Ａ＋Ｂ）の再生時間に相当する。

ステップＳ１０７において、
データ送信時間（ｎ）＜（ｎ）までの全送信データの再生時間
が成立すると判定された場合は、クライアント側のバッファデータの枯渇は起きておらず、ストリーミングデータ配信に十分な帯域が確保できると判断し、ステップＳ１０８に進み、アドミッションコントロールフェーズを終了してストリーミングデータの配信に対応する本来のプライオリティ、すなわち、［ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ］に対応するプライオリティの設定変更を行なってストリーミングデータの配信を継続する。

さらに、ステップＳ１０９に進み、全てのファィルデータの送信が完了したか否かの判定を実行して、全てのファィルデータの送信が完了するまで、［ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ］に対応するプライオリティの設定での送信を継続する。

一方、ステップＳ１０７において、
データ送信時間（ｎ）＜（ｎ）までの全送信データの再生時間
が成立しないと判定された場合は、クライアント側のバッファデータの枯渇が発生し、ストリーミングデータ配信に十分な帯域が確保できていない可能性があると判断し、ストリーミングデータの配信に対応する本来のプライオリティ、すなわち、［ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ］に対応するプライオリティの設定変更を実行することなく、ステップＳ１０９に進み、通信完了まで、［ＱＯＳ＿ＩＮＴＥＲＡＣＴＩＶＥ］とした低プライオリティの設定のまま通信を継続する。

なお、フローには示していないが、ステップＳ１０７において、
データ送信時間（ｎ）＜（ｎ）までの全送信データの再生時間
が成立しないと判定された場合は、十分な帯域確保によるストリーミングデータの配信が困難であることをユーザに通知する処理や、通信を終了する処理を実行する構成としてもよい。

このように、本発明の構成では、新たなストリーミング配信を行なうサーバが、データ伝送開始時に本来のストリーミングデータ配信に対応するプライオリティより低いプライオリティの設定期間としてのアドミッションコントロールフェーズを設定し、アドミッションコントロールフェーズの終了時点を検証点として、この検証点に至るまでの時間と、検証点までに送信したデータ量の再生所要時間との比較に基づいて、クライアントのバッファ枯渇の発生や、ストリーミングデータ配信における十分な帯域確保状況を判定し、この判定に基づいて、十分な帯域確保ができていると判断した場合にのみ、ストリーミングデータ配信に対応する本来のプライオリティ設定しとしたデータ配信を実行する構成とした。

本構成により、例えば、新たなストリーミングデータの配信を開始しようとする時点で、他のストリーミング配信が実行中である場合、その既存のストリーミング配信の帯域を奪って既存ストリーミング配信のデータ配信遅延を発生させるといった通信妨害を起こすことがない。従って、既存ストリーミングデータの再生、視聴を実行しているクライアントに迷惑を及ぼすことがない。

なお、上述した実施例ではＨＴＴＰによるストリーミング伝送によって、サーバ側で転送レートを行う方法を示したが、ＲＴＰによるストリーミング転送においてもＲＴＣＰなどによりクライアントがサーバに転送状態をフィードバックする仕組みがある場合は、十分なネットワーク帯域があるかの判断をサーバ側で行なうことが可能である。

また、上述した実装例では、アドミッションコントロールフェーズでは、設定プライオリティとして、［ＱＯＳ＿ＩＮＴＥＲＡＣＴＩＶＥ］を使用し、静止画のファイル転送に用いられるプライオリティを利用したが、例えば、［ＱＯＳ＿ＩＮＴＥＲＡＣＴＩＶＥ］と［ＱＯＳ＿ＳＴＲＥＡＭＩＮＧ］の中間のプライオリティを新たに設定して、この新規プライオリティをアドミッションコントロールフェーズに利用する専用プラオリティとする構成としてもよい。ただし、この場合は各リンク層の規格において、それに対応するプライオリティ値を定義する必要がある。

また、上述した実装例では、ハードディスク上に蓄積されたＭＰＥＧストリームをそのまま伝送することを前提としてしたが、例えば、検証点においてネットワーク帯域が足りないと判定された場合、トランスレータなどのハードウェアによる元のストリームからビットレートを減少させたストリームをリアルタイムで生成し、小さい帯域でのデータ伝送においてもストリーミング配信、再生が可能となるように伝送ストリームのビットレートを適応させたのち、ストリーミング本来のプライオリティに移行する処理を実行する構成としてもよい。

さらに、上述した実装例では、アドミッションコントロールフェーズの終了時の検証点における検証結果に基づいて、プライオリティの変更を行なうか否かを決定する構成としているが、単純にストリーミング開始時に数秒の間は低いプラオリティで伝送し、その後は自動的にストリーミング本来のプライオリティに移行する構成としてもよい。図１０を参照して説明したようにプリバッファリングによって一時的な転送レートの上昇が発生するが、この期間において、低いプライオリティを使用することで、他のストリーミングに影響を与えるのを回避することができる。

以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。

なお、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。

例えば、プログラムは記録媒体としてのハードディスクやＲＯＭ（Read Only Memory)に予め記録しておくことができる。あるいは、プログラムはフレキシブルディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することができる。

なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。

なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

以上、説明したように、本発明の構成によれば、ストリーミングデータの配信を行なう通信処理装置（サーバ）は、データ伝送開始時に本来のストリーミングデータ配信に対応するプライオリティより低いプライオリティを設定してデータ送信を開始し、検証点において、低プライオリティ設定期間における通信状況を検証する。例えば、検証点に至るまでの時間と、検証点までに送信したデータ量の再生所要時間との比較に基づいて、クライアントのバッファ枯渇の発生や、ストリーミングデータ配信における帯域確保状況を判定し、この判定に基づいて、十分な帯域確保ができていると判断した場合にのみ、ストリーミングデータ配信に対応する本来のプライオリティ設定しとしたデータ配信を実行する構成としたので、例えば、新たなストリーミングデータの配信を開始しようとする時点で、他のストリーミング配信が実行中である場合、その既存のストリーミング配信の帯域を奪って既存ストリーミング配信の遅延を発生させるといった通信妨害を起こすことがなく、良好な通信環境を維持させることが可能となる。

本発明の適用可能なネットワーク構成例を示す図である。 ＷＭＭの規定するアクセスカテゴリ（ＡＣ：Access Category）を示す図である。 ＷＭＭで規定するプライオリティ（優先度）情報としてのアクセスカテゴリを適用した通信処理における効果を示す図である。 本発明に従ったデータ送信処理を実行する通信処理装置としてのサーバのハードウェア構成例を示す図である。 ＤＬＮＡのガイドラインの機能コンポーネントを示す図である。 コンテンツ配信を実行するサーバとしての通信処理装置のＡＶコンテンツのストリーミング伝送のアーキテクチャについて説明する図である。 ＤＬＮＡなどのホームＡＶネットワークで利用する４段階のプライオリティおよび伝送種類、各設定値を格納したプライオリティ対応テーブルを示す図である。 アドミッションコントロールフェーズ（Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｈａｓｅ）を設定したデータ送信シーケンスについて説明する図である。 ＨＴＴＰに従ったストリーミングデータ配信を実行するサーバとストリーミングデータ再生を行うクライアントの各コンポーネント構成と処理について説明する図である。 ＨＴＴＰによるストリーミング伝送時の伝送ビットレートの変化を示す図である。 サーバの実行するストリーミング伝送処理の処理シーケンスについて説明するフローチャートを示す図である。

符号の説明

１００ ネットワーク
１０１ サーバ
１０２ サーバ
１０３ 通信制御部
１１１〜１１３ クライアント（ＰＣ）
２００ バス
２０１ ＣＰＵ
２０２ メモリ
２０３ ネットワークＩ／Ｆ
２０４ デコーダ
２０５ エンコーダ
２０６ チューナ
２０７ 記憶部Ｉ／Ｆ
２０８ データ記憶部
３０１ アプリケーション
３０２ ＴＣＰ／ＩＰスタック
３０３ デバイスドライバ
３０４ イーサネット（登録商標）
３２１ ＨＴＴＰレスポンスデータ
３２２ ＩＰパケット
３２３ イーサフレーム
５１０ サーバ
５１１ サーバアプリケーション
５１２ ネッサワークＩ／Ｆ
５１３ デバイスドライバ
５１４ ＴＣＰ／ＩＰスタック
５１５ バッファ
５２０ クライアント
５２１ クライアントアプリケーション
５２２ ネッサワークＩ／Ｆ
５２３ デバイスドライバ
５２４ ＴＣＰ／ＩＰスタック
５２５ バッファ
５２６ ＭＰＥＧデコーダ

Claims (15)

1. ストリーミングデータの送信処理を実行する通信処理装置であり、
   データ通信状況を検証し、該検証結果に応じて送信データに対して設定する優先度情報の変更処理を実行する通信制御部と、
   前記優先度情報を付加したデータの出力処理を実行するネットワークインタフェースを有し、
   前記通信制御部は、
   ストリーミングデータの送信初期期間において、ストリーミングデータに対応する規定優先度より低位の優先度を設定する処理を実行し、予め設定した検証タイミングとしての検証点において、低優先度設定期間のデータ通信状況の検証を実行し、該検証結果に応じて設定優先度の変更処理を行なう構成を有することを特徴とする通信処理装置。
2. 前記通信制御部は、
   前記検証点における通信状況検証処理として、
   データ送信開始から検証点までの時間と、データ送信開始から検証点までに送信したデータの再生時間とを比較する下記判定式、
   （データ送信開始から検証点までの時間）＜（データ送信開始から検証点までに送信したデータの再生時間）
   が成立するか否かを判定し、上記判定式の成立を条件として、ストリーミングデータに対応する規定優先度への設定変更処理を行なう構成を有することを特徴とする請求項１に記載の通信処理装置。
3. 前記通信制御部は、
   前記低優先度設定期間における通信状況の検証処理として、
   前記検証点における通信状況検証処理として、下記判定式、
   （検証点）−（データ送信先クライアントにおけるデコード開始点）＜（検証点までの送信データの再生時間）−（データ送信先クライアントにおけるプリバッファデータの再生時間）
   が成立するか否かを判定し、上記判定式の成立を条件として、ストリーミングデータに対応する規定優先度への設定変更処理を行なう構成を有することを特徴とする請求項１に記載の通信処理装置。
4. 前記通信制御部は、
   前記データ送信先クライアントから、該クライアントにおけるプリバッファデータ量、またはデコード開始時間の少なくともいずれかの情報を受領して、前記判定式に基づく検証処理を実行する構成であることを特徴とする請求項３に記載の通信処理装置。
5. 前記通信制御部は、
   前記検証点における通信状況の検証の結果、規定優先度への設定変更処理を実行すべきでないとの判定がなされた場合、送信データの送信ビットレートの低下処理を実行してデータ送信を継続する処理を実行する構成であることを特徴とする請求項１に記載の通信処理装置。
6. 前記通信制御部は、
   前記検証点における通信状況の検証の結果、規定優先度への設定変更処理を実行すべきでないとの判定がなされた場合、データ送信の停止またはユーザに対する通知処理の少なくともいずれかの処理を実行する構成であることを特徴とする請求項１に記載の通信処理装置。
7. 前記通信制御部は、
   ＨＴＴＰに従ったデータ送信処理における送信データ量をＴＣＰスタックに対するＨＴＴＰレスポンスデータ書き込み量に基づいて取得し、該取得した送信データ量に基づいて、通信状況の検証処理を実行する構成であることを特徴とする請求項１に記載の通信処理装置。
8. ストリーミングデータの通信制御方法であり、
   ストリーミングデータの送信初期期間において、ストリーミングデータに対応する規定優先度より低位の優先度を設定してデータ送信を実行する低優先度設定データ送信ステップと、
   低優先度設定データ送信期間におけるデータ通信状況の検証を、予め設定した検証タイミングとしての検証点において実行する通信状況検証ステップと、
   前記通信状況検証ステップの検証結果に応じて、設定優先度の変更処理を行なう優先度変更ステップと、
   を有することを特徴とする通信制御方法。
9. 前記通信状況検証ステップは、
   前記検証点における通信状況検証処理として、
   データ送信開始から検証点までの時間と、データ送信開始から検証点までに送信したデータの再生時間とを比較する下記判定式、
   （データ送信開始から検証点までの時間）＜（データ送信開始から検証点までに送信したデータの再生時間）
   が成立するか否かを判定するステップであり、
   前記優先度変更ステップは、
   前記判定式の成立を条件として、ストリーミングデータに対応する規定優先度への設定変更処理を行なうステップであることを特徴とする請求項８に記載の通信制御方法。
10. 前記通信状況検証ステップは、
    前記低優先度設定期間における通信状況の検証処理として、
    前記検証点における通信状況検証処理として、下記判定式、
    （検証点）−（データ送信先クライアントにおけるデコード開始点）＜（検証点までの送信データの再生時間）−（データ送信先クライアントにおけるプリバッファデータの再生時間）
    が成立するか否かを判定するステップであり、
    前記優先度変更ステップは、
    前記判定式の成立を条件として、ストリーミングデータに対応する規定優先度への設定変更処理を行なうステップであることを特徴とする請求項８に記載の通信制御方法。
11. 前記通信状況検証ステップは、
    前記データ送信先クライアントから、該クライアントにおけるプリバッファデータ量、またはデコード開始時間の少なくともいずれかの情報を受領して、前記判定式に基づく検証処理を実行することを特徴とする請求項１０に記載の通信制御方法。
12. 前記通信制御方法は、さらに、
    前記通信状況検証ステップにおける通信状況の検証の結果、規定優先度への設定変更処理を実行すべきでないとの判定がなされた場合、送信データの送信ビットレートの低下処理を実行することを特徴とする請求項８に記載の通信制御方法。
13. 前記通信制御方法は、さらに、
    前記通信状況検証ステップにおける通信状況の検証の結果、規定優先度への設定変更処理を実行すべきでないとの判定がなされた場合、データ送信の停止またはユーザに対する通知処理の少なくともいずれかの処理を実行することを特徴とする請求項８に記載の通信制御方法。
14. 前記通信状況検証ステップは、
    ＨＴＴＰに従ったデータ送信処理における送信データ量をＴＣＰスタックに対するＨＴＴＰレスポンスデータ書き込み量に基づいて取得し、該取得した送信データ量に基づいて、通信状況の検証処理を実行することを特徴とする請求項８に記載の通信制御方法。
15. ストリーミングデータの送信処理を実行する通信処理装置において通信制御処理を実行させるコンピュータ・プログラムであり、
    ストリーミングデータの送信初期期間において、ストリーミングデータに対応する規定優先度より低位の優先度を設定してデータ送信を実行する低優先度設定データ送信ステップと、
    低優先度設定データ送信期間におけるデータ通信状況の検証を、予め設定した検証タイミングとしての検証点において実行する通信状況検証ステップと、
    前記通信状況検証ステップの検証結果に応じて、設定優先度の変更処理を行なう優先度変更ステップと、
    を有することを特徴とするコンピュータ・プログラム。

Images