JP5147858B2 - 複合および非複合ｒｔｃｐパケット間のｒｔｃｐ帯域幅の分割 - Google Patents

Description

本発明は、複合および非複合ＲＴＣＰ（Ｒｅａｌ Ｔｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、リアルタイム制御プロトコル）パケットに対するＲＴＣＰ帯域幅の利用に関する。

インターネットを介してメディア・フレームを運ぶというリアルタイムアプリケーションでは、殆んど常にリアルタイム・プロトコル（ＲＴＰ）を使用する（「非特許文献１」）。メディア・フレームはＲＴＰパケットにカプセル化されて他のユーザに送信される。ＲＴＰプロトコルはまたひとつの制御プロトコル、即ちリアルタイム制御プロトコル（ＲＴＣＰ）を定める。ＲＴＣＰは、メディア・フローに関する機能を提供し、例えば、
・品質（例えばパケット損失率やパケット到着間隔の揺らぎ）のフィードバック。本フィードバックは、メディアの伝送に適応させるために使用できる。
・異なるメディア間の同期（例えば、音声と画像間の同期（リップシンク）の実現および維持）に必要な情報。
・メディア送信器を特定する情報源記述（ＳＤＥＳ）。
・任意の種類のシグナル伝達であり得て、標準化の必要のない特定用途向けシグナル伝達（ＡＰＰ）。ＲＴＣＰ−ＡＰＰパケットを理解しない受信器はそれを放棄し、ＲＴＰＣパケットの残りの部分の解析を続けることができるよう、ＲＴＣＰは構築される。

送信ＲＴＣＰパケットは相当の帯域幅を必要とする。これらのパケットをメディア・パケットに追加して送信するので、この帯域幅は「オーバヘッド」と見なされる。メディア帯域幅との関係において、オーバヘッドを十分少ないように保つことを保証するため、セッション確立でＲＴＣＰ帯域幅に対する制限をしばしば定義する。通常の定義では、ＲＴＣＰに使用すべき帯域幅の２．５％乃至５％を許容する。

ＡＰＰパケットのみの送信を意図している場合でも、ＲＴＣＰパケットは、ＳＤＥＳに加えて送信器レポートまたは受信器レポートのどちらかを含まなければならないということを要求されるので、従来のＲＴＣＰパケットいわゆる複合ＲＴＣＰパケットはかなり大きい。このことは、かなり低頻度で、しばしば毎秒１つ以下でそのようなパケットを送信するしかない、ということを意味する。しかしながら、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ、インターネット技術タスクフォース、「非特許文献２」）で解決策が議論されており、それによるといわゆる非複合ＲＴＣＰパケット内でＡＰＰパケットのみの送信を許容している。非複合ＲＴＣＰパケットでは、パケット・サイズは著しく削減される。

マルチメディア電話通信のためには、音声に対する適応シグナル伝達を送信するためにＲＴＣＰ−ＡＰＰパケットを使用すべきであると判断されている。適応シグナル伝達は、コーデック・モードの変更、１パケットにもっと多くの又はもっと少ないフレームを詰め込むこと、または場合によりオフセットを持たせてアプリケーション層冗長度を付加するか取り除くこと、を示してもよい。

ＲＴＣＰパケットはしばしばかなり大きく、通常の音声パケットより著しく大きい。例えば、ＡＭＲ１２２（ＡＭＲ＝Ａｄａｐｔｉｖｅ Ｍｕｌｔｉ−Ｒａｔｅ、順応マルチレート）符号化メディアを有する１個のＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ、ＩＰ上の音声）パケットは、ヘッダ圧縮無しで約７２バイトであり、ヘッダ圧縮を適用した場合では典型的には約３５バイトである。複合ＲＴＣＰパケットは、通常はヘッダ圧縮無しで１００−１４０バイト、ヘッダ圧縮ありで８０−１２０バイト程度である。非複合パケットは著しく少ない。ＡＰＰのみを有する非複合ＲＴＣＰパケットは、ヘッダ圧縮無しで５０バイト程度、ヘッダ圧縮ありで約３０バイトである。

ＲＦＣ３５５０、Ｓｃｈｕｌｚｒｉｎｎｅ等、ＲＴＰ：Ａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎ、リアルタイム応用のためのトランスポート・プロトコル、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３５５０．ｔｘｔ？ｎｕｍｂｅｒ＝３５５０ Ｊｏｈａｎｓｓｏｎ、Ｗｅｓｔｅｒｌｕｎｄ、Ｓｕｐｐｏｒｔ ｆｏｒ ｎｏｎ−ｃｏｍｐｏｕｎｄ ＲＴＣＰ ｉｎ ＲＴＣＰ ＡＶＰＦ ｐｒｏｆｉｌｅ、ｏｐｐｏｒｔｕｎｉｔｉｅｓ ａｎｄ ｃｏｎｓｅｑｕｅｎｃｅｓ、ＲＴＣＰ ＡＶＰＦプロファイル、機会および結果における非複合ＲＴＣＰのためのサポート、ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｉｄ／ｄｒａｆｔ−ｊｏｈｎａｓｓｏｎ−ａｖｔ−ｒｃｐ−ａｖｐｆ−ｎｏｎ−ｃｏｍｐｏｕｎｄ−００．ｔｘｔ ３ＧＰＰ ＴＳ ２６．１１４．ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ（ＩＭＳ）；Ｍｕｌｔｉｍｅｄｉａ Ｔｅｌｅｐｈｏｎｙ；Ｍｅｄｉａ ｈａｎｄｌｉｎｇ ａｎｄ ｉｎｔｅｒａｃｔｉｏｎ、ＩＰマルチメディア・サブシステム（ＩＭＳ）；マルチメディア電話通信；メディア処理と相互作用、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／Ｓｐｅｃｓ／ｈｔｍｌ−ｉｎｆｏ／２６１１４．ｈｔｍ

幾つかのシステム、例えば、ＨＳＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ Ｐａｃｋｅｔ Ａｃｃｅｓｓ、高速パケットアクセス）に対しては、より小さいサイズの非複合ＲＴＣＰパケットは、劣悪なチャネル条件でもパケットを正しく受信することができる可能性が増加する、ということを意味する。このことは送信適応要求にとって特に有用であり、その理由は、チャネルが劣化するにつれて適応はますます重要になるからである。したがって、ＲＴＣＰパケットのサイズは、適応がいかによく機能するかを決定する。ＲＴＣＰに対する許容帯域幅が一定であるなら、小さいパケットのもう一つの利点は、適応シグナル伝達をもっと頻繁に送信できるということであり、そのことが適応性能をさらに強化する。したがって、できるだけ多くの非複合ＲＴＣＰパケットを送信することは望ましいことである。

他方、例えば、新規の参加者がセッションに入る場合、メディア間の同期およびメディア送信器の特定のため、複合ＲＴＣＰパケットを必要とする。わずかの複合ＲＴＣＰパケットの送信により、より低頻度で同期を機能させ得ることになり、このことは、各メディアに対する再生タイミングは、同期情報を送信する前にかなり外れる可能性があることを意味する。これは知覚品質を減少させ、例えば、リップシンク問題をもたらす。また、わずかの複合ＲＴＣＰパケットの送信により、新規の参加者がセッションに入る場合、メディア送信器を特定する前に長時間を要することになる。これらの機能を強化するため、できるだけ多くの複合パケットを送信することが望ましい。しかしながら、より大きなサイズの複合ＲＴＣＰパケットは次に示す数点の問題をもたらす。
・各送信ブロックは、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌ、無線リンク・プロトコル）プロトコルが許容する大きさであろうし、それは、少なくともメディア・パケットにヘッダ圧縮を使用する場合には、ＶｏＩＰパケットより著しく大きい。このことは、複合ＲＴＣＰパケットが、ブロック誤りの可能性を増加させる、より弱いチャネル符合および／または変調を使用するだろう、ということを意味する。
・ＨＳＰＡのようなシステムでは、数個のＲＬＣ送信ブロックにわたってパケットを分割するであろう。これにより、パケット損失率がさらにもっと増加することになり、それは、ＲＴＣＰパケットを再構築する前にいくつもの送信ブロックを正しく受信しなければならないからである。

それ故、できるだけ多くの非複合ＲＴＣＰパケットを送信することと、できるだけ多くの複合ＲＴＣＰパケットを送信することとの間に対立がおこる。さらに、複合または非復号ＲＴＣＰパケット形式のどちらかに最適化することは、制限された利用可能ＲＴＣＰ帯域幅を両方のパケット形式で使用しなければならないため、他のＲＴＣＰパケット形式の窮乏を暗黙裡にもたらす。

本発明の目的は、複合および非複合ＲＴＣＰパケットの利用可能ＲＴＣＰ帯域幅をよりよく利用することである。

この目的は、添付の特許請求範囲に従って実現される。

簡単には、利用可能ＲＴＣＰ帯域幅を決定すること、チャネル品質を決定すること、および決定したチャネル品質に基づき、複合および非複合ＲＴＣＰパケットで利用可能ＲＴＣＰ帯域幅を分割することにより、本発明は上記目標を実現する。

添付の図面と一緒に取る以下の説明を参照することにより、本発明について、その更なる目的と利点と共に、最もよく理解できるであろう。

ネットワークのシステム概観を与える簡単なブロック図である。 本発明による方法を要約する簡単なフローチャートである。 本発明による装置を示す簡単なブロック図である。 複合および非複合ＲＴＣＰパケット間で利用可能ＲＴＣＰ帯域幅を分割する方策の図である。 複合および非複合ＲＴＣＰパケット間で利用可能ＲＴＣＰ帯域幅を分割するもう一つの方策の図である。 本発明の一つの実施形態の図式的概観である。 本発明による方法の一つの実施形態の原理を示す図のシーケンスである。 本発明による方法の一つの実施形態を示すフローチャートである。 本発明による装置の一つの実施形態を示すブロック図である。 本発明のもう一つの実施形態の図式的概観である。 本発明による方法のもう一つの実施形態を示すフローチャートである。 本発明による装置のもう一つの実施形態を示すブロック図である。

以下の説明では、同じ参照表示を、同じまたは類似の機能を実行する要素に使用する。

図１はネットワークのシステム概観を与える簡単なブロック図である。メディアはクライアントＡからクライアントＢに送信される。メディアはＲＴＰパケットにカプセル化される。メディアは、会話、オーディオ、ビデオ、テキストまたは何か他のもののように異なる形式をとることができる。クライアントＢは、ＲＴＣＰを使用してフィードバックをクライアントＡに送信する。ほとんどの既存のクライアントが送信する通常のフィードバックは、パケット損失率（ＰＬＲ）およびパケット到着間隔の揺らぎ（以後単に「ジッタ」という）からなる品質フィードバックである。また、特定用途向けフィードバック情報を定義することも可能である。ＰＬＲおよびジッタは、（通常の）ＲＴＣＰ受信器レポート（ＲＴＣＰ ＲＲ）と一緒に送信される。特定用途向けフィードバックはＡＰＰパケットと一緒に送信される。

フィードバック情報は、送信メディアの速度をいかに適応させるか選択するためにクライアントＡにより使用され、その結果、異なるチャネル条件（異なるネットワーク混雑状態レベル）に対して品質を最適化できる。例えば、パケット損失率が高い（これはネットワークが混雑状態にあることを示す）なら、クライアントＡはビット速度を小さくすることを選択できる。他の適応可能性は、各ＲＴＰパケット内で数個のフレームを送信することにより、送信されたパケット速度を小さくすること、または送信されたメディアに誤り耐性を付加することである。

フィードバック情報は、ＰＬＲおよびジッタのような計測結果か、または、例えば、『より遅いコーデック速度に切り替えろ』という直接的適応要求であってもよい。ＭＴＳＩ（Ｍｕｔｉｍｅｄｉａ Ｔｅｌｅｐｈｏｎｙ Ｓｅｒｖｉｃｅ ｆｏｒ ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）、ＩＭＳ（ＩＰマルチメディア・サブシステム）のためのマルメディア電話通信サービス、「非特許文献３」）に対しては、メディアが会話の場合、評価指標の代わりに適応要求を送信するように判断されている（しかしながら、依然としてＰＬＲおよびジッタの評価指標を送信することが許容されている。通常は性能モニタにのみこれらの評価指標を使用するが、この情報を適応にも使用することを禁止するものはなにもない。しかしながら、通常は、メディアを適応させるために、適応要求を使用すべきである）。

複合ＲＴＣＰパケット（複合ＲＴＣＰメッセージとも称する）は、通常は数個の「ＲＴＣＰパケット」を含む。
・送信器レポート（ＳＲ）または受信器レポート（ＲＲ）の少なくとも一つ。
−送信器レポートには、作動中の送信器であるクライアントからの受信フィードバックを含む。
−受信器レポートには、作動中の送信器でないクライアントからの受信フィードバックを含む。
・メディア送信器（名前、ｅメール・アドレス、電話番号等）を特定するＳＤＥＳパケット。
・ＲＴＰ仕様で定義されていない特定用途向け情報を含むＡＰＰパケット。もしＲＴＣＰパケットの受信器がそれを理解しない場合は、ＲＴＣＰパケットの受信器はＡＰＰパケットをスキップできるように、ＲＴＣＰを構築する。

複合ＲＴＣＰパケットは、ＳＲまたはＲＲのどちらか、およびＳＤＥＳを含まなければならないということを、ＲＴＰ仕様における規則は定義している。ＡＰＰパケットは選択的である。

非複合ＲＴＣＰパケットはＡＰＰパケットのみを含んでもよい。

ＲＴＣＰのもっと完全な説明については、非特許文献１を参照されたい。

図２は、本発明による方法を要約する簡単なフローチャートである。方法ステップＭ１は利用可能ＲＴＣＰ帯域幅を決定し、ステップＭ２は現在のチャネル品質を決定し、Ｍ３は、決定したチャネル品質に基づき、複合および非複合ＲＴＣＰパケット間で利用可能帯域幅を分割する。

図３は、本発明による装置を示す簡単なブロック図である。検出器１０は利用可能ＲＴＣＰ帯域幅を検出する。検出器１２はチャネル品質を検出する。ＲＴＣＰ帯域幅デバイダ１４はこれらの２個のパラメータを使用して、複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケット間で利用可能なＲＴＣＰ帯域幅を分割する。この分割は、以下でさらに詳細に説明するように、チャネル品質に依存するであろう。

以下の方法で説明した方法と装置を使用してもよい。
・チャネル条件が良好である場合、通常の複合ＲＴＣＰパケットにもっと多くの帯域幅を割り付け、非複合ＲＴＣＰパケットにより少ない帯域幅を割り付ける。これは、例えばメディア間の同期を維持するであろうし、メディア送信器を特定する前の遅延を削減する。しかしながら、大きなサイズのＲＴＣＰパケットは、パケットがより大きいので、送信できるパケット数を削減し、これにより、より少ない頻度で送信適応を行うことができることになる。他方、チャネル条件が良好である場合、適応の重要性はより低い。
・チャネル品質が劣化する場合、非複合ＲＴＣＰパケットにより広い帯域幅を割り付け、それ故、これらのパケットを正しく受信する可能性を増加する。また、これにより、さらに頻繁な適応要求を送信することが可能になる。多分、これは、例えば同期に害を与えるであろう。しかしながら、この状況では、良好なメディア品質を維持するため、送信適応は他の性能特性よりさらに重要と見なされる。

図４は、複合および非複合ＲＴＣＰパケット間で利用可能ＲＴＣＰ帯域幅を分割する方策の図である。この例では、非複合ＲＴＣＰパケットに対する許容帯域幅は、不良なチャネル条件では高く、複合ＲＴＣＰパケットに対しては低い。チャネル品質が向上するにつれて、この状況は連続的なかたちで逆転する。二つの領域間の境界線ＢＬは、不良チャネル品質から良好チャネル品質へ変化する（例では減少する）関数である。注意すべきは、両形式のパケットに対する許容帯域幅の和は一定（破線）である、ということである。チャネル品質を含む数学的表現、またはルックアップ・テーブルで、本関数を表わしてもよい。

図５は、複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケット間で利用可能なＲＴＣＰ帯域幅を分割するもう一つの方策の図である。この例では、二つの領域の境界線ＢＬは、不良チャネル品質から良好チャネル品質へ減少する、区分的に一定な関数である。典型的には、ルックアップ・テーブルで、そのような区分的に一定な関数を表わす。

数種の方法で、チャネル条件またはチャネル品質を測定できる。適切な測定の例は、Ｃ／Ｉ（チャネル対干渉比）、Ｃ／Ｎ（チャネル対雑音比）、ＣＱＩ（チャネル品質インジケータ、ＨＳＰＡで使用）、ＰＬＲ（パケット損失率）およびジッタである。また、これらのメジャの数個を複合メジャに合成することも実現可能である。

複合および非複合ＲＴＣＰパケット間で利用可能ＲＴＣＰ帯域幅を分割する方策は、異なるチャネル条件に対する２種類のパケット形式に対するスループットの統計値を分析して決定する。これは、実際のまたは擬似のシステムのいずれかで行うことができる。ひとたびこの方策（図４および図５の曲線に対応）を決定すると、チャネル品質の関数として、２種類のパケット形式に対する許容帯域幅が決定される。

上記に概説した原理を、クライアントの一部であるＲＴＣＰ送信器に実装する。数種の方法で本着想を実装でき、そのうちの幾つかについて、以下にさらに詳細に説明する。

一つの実施形態では、前もって、即ち、セッション確立時またはセッションを変更するときに、複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケットそれぞれに対する送信間隔を決定する。一般的には、この実施形態は、以下に概説するステップに従う。
１．ＲＴＣＰ送信器は利用可能な全ＲＴＣＰ帯域幅に関する情報を受信する。
２．利用可能な全ＲＴＣＰ帯域幅が与えられ、さらに複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケット間で、どのように帯域幅を分割（チャネル品質で決定）すべきかが与えられていると、ＲＴＣＰ送信器は、複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケットそれぞれに対して送信間隔関数を決定する。送信間隔関数はチャネル品質に依存する。一つの例を以下に示す。
ａ．チャネル品質がＸより良好なら、複合ＲＴＣＰパケットに対する送信間隔を１秒に設定し、非複合ＲＴＣＰパケットに対する送信間隔を０．３３３秒に設定する。
ｂ．チャネル品質がＸより悪いなら、複合ＲＴＣＰパケットに対する送信間隔を２秒に設定し、非複合ＲＴＣＰパケットに対する送信間隔を０．１秒に設定する。
３．ＲＴＣＰ送信器は現在のチャネル品質に関する情報を受信する。
４．上記のステップで与えられるように、決定した送信間隔および現在のチャネル品質に従い、ＲＴＣＰ送信器は複合および非複合ＲＴＣＰパケットを生成する。上記と同じ例を仮定して、送信器は以下を送信する。
ａ．チャネル品質がＸより良好なら、毎秒１個の複合ＲＴＣＰパケットと、その間に２個の非複合ＲＴＣＰパケットを送信する。
ｂ．チャネル品質がＸより悪いなら、１秒おきに１個の複合ＲＴＣＰパケットと、その間に１９個の非複合ＲＴＣＰパケットを送信する。

この変化の図式的概観を図６に与える。

複合ＲＴＣＰパケットはまた、非複合ＲＴＣＰパケットに含まれる情報（ＡＰＰパケット）を含んでもよく、これにより、所与の例において、複合ＲＴＣＰパケットが非複合ＲＴＣＰパケットを置き換えるであろうことに注意すべきである。これは、複合ＲＴＣＰパケット間の送信間隔が、たまたま、非複合ＲＴＣＰパケット間の送信間隔の倍数であるという事実の結果である。しかしながら、これは必要な特徴ではない。

図７は、本発明による方法のこの実施形態の原理を示す図のシーケンスである。図７（ａ）は、単一の遷移点Ｘを持つチャネル品質の簡単で区分的に一定な関数に対する、複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケット間の利用可能なＲＴＣＰ帯域幅の分割を示す。この分割は、図７（ｂ）および図７（ｃ）に示す（チャネル品質の）２個の帯域幅関数をもたらす。図７（ｄ）および図７（ｅ）は対応する送信間隔関数である（これらは基本的に逆帯域幅関数である）。図７ではＢＷ＝帯域幅であり、ＴＩ＝送信間隔である。

図８は、本発明による方法の送信間隔関数に基づく実施形態を示すフローチャートである。ステップＳ１は全利用可能ＲＴＣＰ帯域幅を決定する。これを使用して、ステップＳ２で、チャネル品質の関数として複合および非複合ＲＴＣＰパケットの許容帯域幅を決定する。許容帯域幅間の割合は、通常は、利用可能な全ＲＴＣＰ帯域幅に依存しない。しかしながら、幾つかの応用では、これらの割合を、利用可能な全ＲＴＣＰ帯域幅に依存させることは、望ましい可能性がある。例えば、狭い利用可能な全ＲＴＣＰ帯域幅に比較し、広い利用可能な全ＲＴＣＰ帯域幅に対しては、複合パケットの許容帯域幅の割合を増加させる（および非複合ＲＴＣＰパケットの許容帯域幅の割合を減少させる）ことは、望ましい可能性がある。ステップＳ３は、チャネル品質の関数として、複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケットの送信間隔関数を決定する。ステップＳ４は現在のチャネル品質を決定し、これをステップＳ５で使用して、送信間隔関数から現在の送信間隔を決定する。ステップＳ６は、もう一つのＲＴＣＰパケットの送信を可能とするため、最後のＲＴＣＰパケットを送信してから十分な時間が経過したかどうかを（現在の送信間隔を使用して）テストする。まず、複合ＲＴＣＰパケットの送信を可能とするため、十分な時間が経過したかどうかをテストする。もしそうなら、ステップＳ７で、複合ＲＴＣＰパケットを生成し、送信する。そうでなければ、非複合ＲＴＣＰパケットの送信を可能とするため、十分な時間が経過したかどうかをテストする。もしそうなら、ステップＳ８で、非複合ＲＴＣＰパケットを生成し、送信する。どちらのテストも成功しない場合、ステップＳ９で、パケットの送信を遅延させ、ＲＴＣＰパケットを生成しない。ステップＳ７、Ｓ８およびＳ９の一つを実行した後、処理過程はステップＳ４にもどる。

送信間隔関数は、本実施形態における関心の関数であるので、チャネル品質および利用可能な全ＲＴＣＰ帯域幅から直接に送信間隔関数を獲得する単一のステップとして、ステップＳ２およびＳ３を実装してもよい。

図８では、現在のチャネル品質を決定するステップＳ４に戻るループがある。これは、利用可能な全ＲＴＣＰ帯域幅が一定に維持され、通常はセッション中では維持される（それはセッション設定中に決定される）ことを前提とする。しかしながら、幾つかの状況では、全利用可能ＲＴＣＰ帯域幅はセッション中に変化してもよい。幾つかの例を以下に示す。
・一つの無線技術から、もっと厳しいシステム制限を持つもう一つの無線技術にハンドオーバを実行するなら、利用可能な全ＲＴＣＰ帯域幅を削減してもよい。これは、例えば、ＨＳＰＡからＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ、ＧＳＭ進化型高速データレート）またはＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅｓ、汎用パケット無線サービス）にハンドオーバする場合に起こり得る。
・もし例えば、ユーザがサービスを変更するなら、使用するサービスが音声のみである限り、幾つかの動作はＲＴＣＰに対して殆んど帯域幅を割付けなくてもよい。ユーザが同じセッション中にビデオ電話通信に切り換えるなら、（リップシンクを獲得するため）会話とビデオを同期させることは望ましいことである。ＲＴＣＰメッセージの中で要求される情報を送信し、ビデオ・ストリームと音声ストリームの両方に対してＲＴＣＰ帯域幅を割付ける必要があるだろう。

システムがそのような状況に対処しなければならないなら、図８における処理過程は全ての過程をステップＳ１にループ・バックし、少なくとも時々は、利用可能な全ＲＴＣＰ帯域幅を変更できる新規の動作境界を明らかにしなければならない。

図９は、本発明による装置の一つの実施形態を示すブロック図である。図は、図３におけるＲＴＣＰ帯域幅デバイダ１４をさらに詳細にした実施形態を示す。検出器１０からの全ＲＴＣＰ帯域幅と検出器１２からの現在のチャネル品質とがＲＴＣＰ送信間隔計算器１６に転送され、ＲＴＣＰ送信間隔計算器１６は、所定の送信間隔関数に基づいて、複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケットに対する現在の送信間隔を計算する。これらの送信間隔をＲＴＣＰ送信タイミング・ユニット１８に転送し、ＲＴＣＰ送信タイミング・ユニット１８は、いつ次のＲＴＣＰパケットを送信すべきか、それは複合ＲＴＣＰパケットまたは非複合ＲＴＣＰパケットのどちらであるべきか、を決定する制御信号を生成する。この制御信号は、フィードバック・チャネルで送信するフィードバック情報を保持するバッファ２２に接続されるスイッチ２０を制御する。バッファを、あるスイッチ位置では、複合ＲＴＣＰパケット生成器２４に接続し、他のスイッチ位置では、非複合ＲＴＣＰパケット生成器２６に接続する。生成器２４、２６からの出力パケットをＲＴＣＰストリーム形成器２８で連結する。

もう一つの実施形態は、各ＲＴＣＰパケット形式の帯域幅制限を決定し、どれだけ多くの帯域幅を使用しているかをモニタし、次のＲＴＣＰパケットが複合ＲＴＣＰパケットまたは非複合ＲＴＣＰパケットのどちらであるべきかを判断する。一般的に、この実施形態は、以下に概説するステップに従う。
１．ＲＴＣＰ送信器は、各ＲＴＣＰパケット形式のため、チャネル品質の関数として、全利用可能ＲＴＣＰ帯域幅に関する情報を受信し、帯域幅制限を決定する。
２．ＲＴＣＰ送信器は、現在のチャネル品質の関する情報を受信する。
３．ＲＴＣＰ送信器は、決定した複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケットのサイズをモニタする。
４．ＲＴＣＰ送信器は、各ＲＴＣＰパケット形式に使用する帯域幅がどれだけかを計算可能とするため、前に送信したＲＴＣＰパケットについての情報をストアする。
５．現在のチャネル品質を仮定し、ＲＴＣＰ送信器は、複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケットそれぞれに使用可能な帯域幅がどれだけかを決定する。
６．ＲＴＣＰ送信器は、
ａ．複合ＲＴＣＰパケットの使用帯域幅が、複合ＲＴＣＰパケットに現在許容される帯域幅より狭いならば、複合ＲＴＣＰパケットを生成し、または、
ｂ．非複合ＲＴＣＰパケットの使用帯域幅が、非複合ＲＴＣＰパケットに現在許容される帯域幅より狭いならば、非複合ＲＴＣＰパケットを試製し、または、
ｃ．使用帯域幅が複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケット各々に許容される帯域幅を超えているなら、複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケットのどちらも生成しない。

この変化の図式的概観を図１０に示す。

図１１は、本発明による方法の実施形態に基づく送信帯域幅関数を示すフローチャートである。ステップＰ１は全利用可能ＲＴＣＰ帯域幅を決定する。これを使用して、ステップＰ２で、チャネル品質の関数として複合および非複合ＲＴＣＰパケットの許容帯域幅を決定する。許容帯域幅間の割合は、典型的には、利用可能な全ＲＴＣＰ帯域幅に依存しない。しかしながら、幾つかの応用では、これらの割合を、利用可能な全ＲＴＣＰ帯域幅に依存させることは、望ましい可能性がある。例えば、狭い利用可能な全ＲＴＣＰ帯域幅に比較して、広い利用可能な全ＲＴＣＰ帯域幅に対して、複合パケットに対する許容帯域幅の割合を増加させる（非複合ＲＴＣＰパケットに対する許容帯域幅の割合を減少させる）ことは、望ましい可能性がある。ステップＰ３は現在のチャネル品質を決定し、これをステップＰ４で使用し、前に送信した各形式のＲＴＣＰパケットに関する格納した情報を使用して、各ＲＴＣＰパケットのための残りの帯域幅を計算する。ステップＰ５は、各形式のＲＴＣＰパケットを送信するため、残りの帯域幅のどれが十分かどうかを（各形式に対する現在の残りの送信帯域幅を使用して）テストする。まず、複合ＲＴＣＰパケットの送信を可能とするのに十分な利用可能な帯域幅があるかどうかをテストする。もしそうであれば、ステップＰ６で複合ＲＴＣＰパケットを生成して送信し、また、複合パケットのために格納し使用した対応する帯域幅を更新する。そうでなければ、非複合ＲＴＣＰパケットの送信を可能とするのに十分な利用可能帯域幅があるかどうかをテストする。もしそうであれば、ステップＰ７で非複合ＲＴＣＰパケットを生成して送信し、また、非複合パケットのために格納し使用した対応する帯域幅を更新する。どちらのテストも成功しない場合、ステップＰ８で、パケットの送信を遅延させ、ＲＴＣＰパケットを生成しない。ステップＰ６、Ｐ７およびＰ８の一つを実行した後、処理過程はステップＰ３にもどる。

もし、ＲＴＣＰパケットの送信に常に十分な帯域幅があることを保証する、十分に長いクロック・サイクルを持つ外部クロックにより、図１１のループが駆動されるなら、ステップＰ８を省略してもよい。

セッション中に利用可能な全ＲＴＣＰ帯域幅を変更することが予期されるなら、図１１の処理過程は、少なくとも時々ステップＰ１にループ・バックしなければならないであろう。この件に関しては、上記図５に対するコメントを参照されたい。

図１２は、本発明による装置のもう一つの実施形態を示すブロック図である。検出器１０からの利用可能なＲＴＣＰ帯域幅と検出器１２からの現在のチャネル品質とをＲＴＣＰ送信帯域幅計算器３０に転送し、所定の送信帯域幅関数の基づいて、複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケットに対する現在の許容送信帯域幅を計算する。これらの許容送信帯域幅をＲＴＣＰパケット形式選択器３２に転送し、次にどのパケット形式を送信すべきか判断する。また、選択器３２は、既に送信したＲＴＣＰパケットに関する情報を格納し、更新する、使用された帯域幅計算器３４から、各パケット形式に既に使用したＲＴＣＰ帯域幅に関する情報を受信する。特定の時間区間にわたってそのパケット形式に割り当てたビット数を追跡することにより、パケット形式に使用した帯域幅を計算できる。各パケット形式に許容した帯域幅と使用した帯域幅間の差異を使用して、選択器３２は送信すべき次のパケット形式を選択し、それによりスイッチ２０を制御する。もし両方のパケット形式とも、もう一つのパケットの送信を可能とするのに十分な残りの帯域幅を持っているなら、それらの中の一つに、より高い優先度をあたえてもよい。例えば、まず、複合ＲＴＣＰパケットに対する帯域幅を消費してもよい。

上記の実施形態を、例えば、以下に示す異なる方法で変更してもよい。
・複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケット両方の送信間隔を決定する代わりに、それら（複合または非複合）の中のどちらかの一つを決定し、他のパケット形式（非複合および複合それぞれ）に残りを使用することは可能である。もちろん、セッション設定で定義される帯域幅制限を破らないように、使用する帯域幅をモニタしなければならない。
・複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケット両方の使用帯域幅をモニタする代わりに、それら（複合または非複合）の中の一つの使用帯域幅をモニタし、他のＲＴＣＰパケット形式（非複合および複合それぞれ）の許容帯域幅の残りを使用することは可能である。

説明した実施形態における各種のブロックの機能は、典型的には、一つ以上のマイクロプロセッサまたはマイクロ／シグナル・プロセッサの組合せと対応するソフトウエアによって獲得される。

本発明は数個の利点を持ち、そのうちの幾つかを下記に示す。
・チャネル条件が良好な場合、メディア間で良好な同期を維持する。チャネル条件が良好な場合、メディア送信器を特定する前の遅延は短く保たれる。
・劣化したチャネル条件に対して、即ち、最も重要な問題が良好なメディア品質を維持することである場合、適応性能を改善する。
・異なるチャネル条件に対して、性能を最適化することが可能である。

当業者は理解するであろうが、添付の特許請求項が定める本発明の範囲から逸脱ことなしに、本発明に各種の修正および変更を行うことは可能である。

略語
ＡＭＲ 順応マルチレート
ＡＰＰ 特定用途向けＲＴＣＰパケット
Ｃ／Ｉ チャネル対干渉比
Ｃ／Ｎ チャネル対雑音比
ＣＱＩ チャネル品質インジケータ
ＥＤＧＥ ＧＳＭ進化型高速データレート
ＧＰＲＳ 汎用パケット無線サービス
ＨＳＰＡ 高速パケットアクセス
ＩＰ インターネット・プロトコル
ＩＥＴＦ インターネット技術タスクフォース
ＩＭＳ ＩＰマルチメディア・サブシステム
ＭＴＳＩ ＩＭＳのためのマルメディア電話通信サービス
ＰＬＲ パケット損失率
ＲＬＣ 無線リンク・プロトコル
ＲＲ 受信器レポート
ＲＴＣＰ リアルタイム制御プロトコル
ＲＴＰ リアルタイム・プロトコル
ＳＤＥＳ 情報源記述
ＳＲ 送信器レポート
ＶｏＩＰ ＩＰ上の音声

Claims (10)

1. 複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケットに対するＲＴＣＰ帯域幅の利用を制御する方法であって、
   利用可能なＲＴＣＰ帯域幅を決定するステップと、
   チャネル品質を決定するステップと、
   決定した前記チャネル品質に基づき、複合ＲＴＣＰパケットと非複合ＲＴＣＰパケットとの間で前記利用可能なＲＴＣＰ帯域幅を分割するステップと
   を含むことを特徴とする方法。
2. チャネル品質が良好になるのに応じて、複合ＲＴＣＰパケットに増大した許容帯域幅を割り付けるステップを含むことを特徴とする請求項１に記載の方法。
3. チャネル品質が良好になるのに応じて、非複合ＲＴＣＰパケットに減少した許容帯域幅を割り付けるステップを含むことを特徴とする請求項１に記載の方法。
4. 第一の送信間隔で複合ＲＴＣＰパケットを、第二の送信間隔で非複合ＲＴＣＰパケットを生成するステップを含み、前記第一および第二の送信間隔は、決定した前記利用可能なＲＴＣＰ帯域幅および決定した前記チャネル品質に依存することを特徴とする請求項２または３に記載の方法。
5. 残りのＲＴＣＰ帯域幅が、複合ＲＴＣＰパケット送信のために十分な帯域幅であれば複合ＲＴＣＰパケットを生成し、残りのＲＴＣＰ帯域幅が、非複合ＲＴＣＰパケットの送信のために十分な帯域幅であれば非複合ＲＴＣＰパケットを生成するステップを含むことを特徴とする請求項２または３に記載の方法。
6. 複合ＲＴＣＰパケットおよび非複合ＲＴＣＰパケットのためのＲＴＣＰの利用を制御する装置であって、
   利用可能なＲＴＣＰ帯域幅を決定する帯域幅検出器（１０）と、
   チャネル品質を決定するチャネル品質検出器（１２）と、
   帯域幅検出器とチャネル品質検出器とに接続される帯域幅デバイダ（１４）とを含み、前記帯域幅デバイダは、決定した前記チャネル品質に基づき、複合ＲＴＣＰパケットと非複合ＲＴＣＰパケットとの間で利用可能ＲＴＣＰ帯域幅を分割する
   ことを特徴とする装置。
7. 前記帯域幅デバイダ（１４）は、チャネル品質が良好になるのに応じて、複合ＲＴＣＰパケットに割り付ける帯域幅を増加させることを特徴とする請求項６に記載の装置。
8. 前記帯域幅デバイダ（１４）は、チャネル品質が良好になるのに応じて、非複合ＲＴＣＰパケットに割り付ける帯域幅を減少させることを特徴とする請求項６に記載の装置。
9. 第一の送信間隔で複合ＲＴＣＰパケットを、第二の送信間隔で非複合ＲＴＣＰパケットを生成する手段（１６、１８、２０、２２、２４、２６）を含み、前記第一および第二の送信間隔は、決定した前記利用可能なＲＴＣＰ帯域幅および決定した前記チャネル品質に依存することを特徴とする請求項７または８に記載の装置。
10. 残りのＲＴＣＰ帯域幅が、複合ＲＴＣＰパケットの送信のために十分な帯域幅であれば複合ＲＴＣＰパケットを生成し、残りのＲＴＣＰ帯域幅が、非複合ＲＴＣＰパケットの送信のために十分な帯域幅であれば非複合ＲＴＣＰパケットを生成する手段（２０、２２、２４、２６、３０、３２、３４）を含むことを特徴とする請求項７または８に記載の装置。

Images