(57)【要約】【課題】受信デバイスやその無線ネットワークによって最適に且つ効率的にリソースをセットアップすることができるシステム及び方法を提供する。【解決手段】送信デバイスは交渉したＱｏＳパラメータの幾つかを、セッションセットアップ手続中にそのセッションの受信デバイスへシグナリングする。保証ビットレート、最大ビットレート、及び転送遅延は、受信デバイスへシグナリングされる。新たなセッション記述プロトコル属性は上述したＱｏＳパラメータに対して規定され、これらはセッション開始プロトコルメッセージで実行される。受信デバイスはこれらのＳＤＰ属性を使用して、ＰＤＰアクティベーション中に、それ自身のワイヤレスネットワークとＱｏＳパラメータを交渉することができる。受信デバイスは、これらのパラメータを使用して音声及びビデオのためのジッタバッファのようなリソースをそれに応じて設定することができる。【選択図】図４
2008541532.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディアセッションのためにサービスの質パラメータをシグナリングする方法において、
マルチメディアセッションの生成時に送信デバイスから受信デバイスへサービスの質パラメータを連絡する段階と、
前記受信デバイスによって該受信デバイスと関連するネットワークとパラメータを交渉する段階であって、前記交渉したパラメータは前記送信デバイスからの前記連絡されたサービスの質パラメータに基づく、前記段階と、
前記マルチメディアセッションの間、前記受信デバイスから前記送信デバイスへサービスの質パラメータを連絡する段階と、
を備えることを特徴とする方法。
【請求項２】
前記サービスの質パラメータは、１つ若しくは２つ以上の保証ビットレート、最大ビットレート、及び転送遅延を備える請求項１に記載の方法。
【請求項３】
更に、前記サービスの質パラメータに基づいて前記受信デバイスにおいてリソースを確立する段階を備える請求項１に記載の方法。
【請求項４】
前記リソースは、ジッタバッファ及びメディアエンコーディングパラメータである請求項３に記載の方法。
【請求項５】
前記サービスの質パラメータは、セッション記述プロトコルパラメータである請求項１に記載の方法。
【請求項６】
前記マルチメディアセッションは双方向性である請求項１に記載の方法。
【請求項７】
マルチメディアセッションのためにサービスの質パラメータをシグナリングするシステムにおいて、
マルチメディアセッションの生成時に送信デバイスから受信デバイスへサービスの質パラメータを連絡する手段と、
前記受信デバイスによって該受信デバイスと関連するネットワークとパラメータを交渉する手段であって、前記交渉したパラメータは前記送信デバイスからの前記連絡されたサービスの質パラメータに基づく、前記手段と、
前記マルチメディアセッションの間、前記受信デバイスから前記送信デバイスへサービスの質パラメータを連絡する手段と、
を備えることを特徴とするシステム。
【請求項８】
前記マルチメディアセッションは双方向性である請求項７に記載のシステム。
【請求項９】
前記サービスの質パラメータは、１つ若しくは２つ以上の保証ビットレート、最大ビットレート、及び転送遅延を備える請求項７に記載の方法。
【請求項１０】
更に、前記サービスの質パラメータに基づいて前記受信デバイスにおいてリソースを確立する手段を備える請求項７に記載のシステム。
【請求項１１】
マルチメディアセッションのためにサービスの質パラメータをシグナリングするシステムにおいて、
マルチメディアセッションを開始し且つ通信ネットワークを介してサービスの質パラメータを連絡する送信デバイスと、
受信デバイスであって、該受信デバイスは、前記連絡されたサービスの質パラメータを受信し、前記受信デバイスと関連する無線ネットワークとパラメータを交渉し、サービスの質パラメータを前記送信デバイスへ連絡する、前記受信デバイスと、
を備えることを特徴とするシステム。
【請求項１２】
前記サービスの質パラメータは、１つ若しくは２つ以上の保証ビットレート、最大ビットレート、及び転送遅延を備える請求項１１に記載のシステム。
【請求項１３】
前記受信デバイスは、前記サービスの質パラメータに基づいてリソースを確立する請求項１１に記載のシステム。
【請求項１４】
データをエンコードする際に利用されるコンピュータプログラム製品において、
マルチメディアセッションの生成時に送信デバイスから受信デバイスへサービスの質パラメータを連絡するコンピュータコードと、
前記受信デバイスによって該受信デバイスと関連するネットワークとパラメータを交渉するコンピュータコードであって、前記交渉したパラメータは前記送信デバイスからの前記連絡されたサービスの質パラメータに基づく、前記コンピュータコードと、
前記マルチメディアセッションの間、前記受信デバイスから前記送信デバイスへサービスの質パラメータを連絡するコンピュータコードと、
を備えることを特徴とするコンピュータプログラム製品。
【請求項１５】
前記サービスの質パラメータは、保証ビットレート、最大ビットレート、及び転送遅延のうちのいずれかを備える請求項１４に記載のコンピュータプログラム製品。
【請求項１６】
ネットワークを通じてマルチメディアセッションで通信するデバイスにおいて、
マルチメディアセッションの開始時に受信デバイスへ連絡されるサービスの質パラメータを記憶するメモリと、
前記受信デバイスから許可パラメータを受信し該許可パラメータに従ってマルチメディア通信を可能とするプロセッサと、
を備えることを特徴とするデバイス。
【請求項１７】
前記サービスの質パラメータは、保証ビットレート、最大ビットレート、及び転送遅延のうちのいずれかを備える請求項１６に記載のデバイス。
【請求項１８】
ネットワークを通じてマルチメディアセッションで通信するデバイスにおいて、
送信デバイスから受信したサービスの質パラメータに基づいて関連ネットワークとパラメータを交渉するプロセッサと、
前記送信デバイスから受信した前記サービスの質パラメータに基づいてリソースを確立するプログラムされた命令と、
を備えることを特徴とするデバイス。
【請求項１９】
前記サービスの質パラメータは、保証ビットレート、最大ビットレート、及び転送遅延のうちのいずれかを備える請求項１８に記載のデバイス。
【請求項２０】
前記プロセッサは前記交渉したパラメータを前記送信デバイスに連絡する請求項１８に記載のデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般には、インターネットプロトコル（ＩＰ）マルチメディア通信、更に言えば、ＩＰマルチメディア通信におけるサービスの質の改善及び最適化方法に係る。
【背景技術】
【０００２】
この節は発明の背景を述べることを意図する。ここでの記述は本願によって達成され得る概念を含むが、必ずしも従来より達成されていたものではない。故に、特に示さない限り、この節に述べる事項は請求項の従来技術ではなく、この節に含めることによって従来技術であると認められるものではない。
【０００３】
スリージーピーピー（３ＧＰＰ）は、その技術仕様（ＴＳ）２３．１０７の中で、３Ｇ移動通信におけるサービスの質（ＱｏＳ）に関する概念とアーキテクチャを定義している。ＱｏＳは、データパケットがそれらの伝送中にネットワークでどのように処理されるのかを決定する。例えば、ＱｏＳレベルは、どのパケットがバッファリングされるか、どのパケットがネットワークにおける輻輳中にドロップされるかを決定する。ＱｏＳレベルはまた、どのようなビットレートがメディアストリームのために割当てられるのかを決定する。パケット交換通信のため、ユニバーサル・モバイル・テレコミュニケーション・システム（ＵＭＴＳ）ネットワークは、（ＴＳ２３．１０７では）ＱｏＳクラスとも呼ばれるような、４つの異なるタイプのトラフィッククラスを規定している。これら４つのＱｏＳクラス、若しくは、トラフィッククラスは、対話型（conversational）、ストリーミング、インタラクティブ、バックグラウンド（background）である。これらのトラフィックタイプや異なるＱｏＳ属性（特性）は、３ＧＰＰ  ＴＳ２３．１０７ドキュメントに更に詳細に記載されている。
【０００４】
モバイル端末が他のパーティー（電話の相手）とマルチメディアコール（呼）を確立したいとき、それは、ゲートウェイＧＰＲＳサービングノード（ＧＧＳＮ）とともにパケットデータプロトコル（ＰＤＰ）コンテキストをアクティブにする。ＰＤＰアクティベーション要求メッセージにおいて、端末は、当該端末がそのセッションのために希望する、トラフィッククラスや、最大帯域幅、保証帯域幅（保証された帯域幅）、遅延等のＱｏＳ属性を特定する。（無線インタフェースやコアネットワークにおける）リソースのアベイラビリティやネットワークの負荷に基づいて、ネットワークはＱｏＳをそのモバイル端末に許可する、若しくは、認める。
【０００５】
異なるマルチメディアアプリケーションは異なる特性を有する。例えば、ビデオ会議や音声会議のようなアプリケーションは、リアルタイム若しくはほぼリアルタイムでのデータ（ビデオ若しくは音声ストリーム）の配信を要求する。これらの種類のアプリケーションは、いくらかのパケット喪失には耐えることができる。しかしながら、データベースアクセスやウェブ閲覧のようなアプリケーションについては、配信されるデータが可能な限り正確であること、遅延要求が厳しくないことが、非常に重要である。アプリケーションに基づいて、セッションを開始するユーザは、ＰＤＰコンテキストアクティベーション中に何らかのトラフィッククラスを要求する。このように、ユーザがストリーミングアプリケーションのセットアップを希望した場合、それはストリーミングトラフィックタイプを使用し、ビデオ会議アプリケーションに関しては対話型トラフィックタイプを使用する。クライアントアプリケーションは、また、その特定のアプリケーションについてのセッションのために自身が使用することを望む、保証ビットレート、最大ビットレート、転送遅延等の他のなんらかのＱｏＳパラメータも特定する。
【０００６】
送信者に対し、交渉したＱｏＳパラメータをエンド・エンドでコールにおいて、受信者或いはコールの他のパーティーへシグナリング（信号伝達）させるメカニズムは存在しない。このように、ＳＩＰ／ＳＤＰプロトコルを使用するセッションセットアップ中は、交渉したＱｏＳパラメータをコールの他のパーティーに特定するためのものは存在しない。受信者若しくは発呼された（電話をかけられた）パーティーが、ＳＩＰ  ＩＮＶＩＴＥメッセージを受信して、マルチメディアセッションに加わる際、受信者はそれ自身のネットワークとＱｏＳパラメータを交渉する。受信者は、送信者が交渉したものとは異なるトラフィックタイプクラス（不正確なＱｏＳパラメータを含む）を要求できる。従って、例えば、送信者がインタラクティブ若しくはストリーミングセッション（例えば、ａ  Ｓｅｅ  Ｗｈａｔ  Ｉ  Ｓｅｅ（ＳＷＩＳ）アプリケーション）を所望した場合、受信者は、対話型トラフィッククラスを求めることができる。他の例として、送信者が、初期ＳＩＰ  ＩＮＶＩＴＥメッセージにおいて帯域幅属性を使用して（例えば６４Ｋｂｐｓについて）セッション帯域幅を特定し、その後、それ自身の無線ネットワークと交渉したときに保証帯域幅ＱｏＳパラメータを特定した場合、ネットワークは、送信（発呼する）クライアントに４８Ｋｂｐｓしか割当てることができない。しかしながら、受信者（若しくは、発呼されたパーティー）は、送信者からの初期ＩＮＶＩＴＥメッセージに基づいて、それ自身の無線ネットワークと６４Ｋｂｐｓに関して交渉する。送信者が４８Ｋｂｐｓだけでしか送信しない場合であっても、受信者の無線ネットワークは受信者に対して６４Ｋｂｐｓを許可し、この結果、ネットワークリソースの使用が非効率的になってしまう。もし、送信者が、交渉した保証帯域幅を受信者へシグナリングする能力を有していれば、受信者は、それ自身のネットワークからの適当なリソースを正確に交渉できる。同様に、最大ビットレートパラメータがエンド・ツー・エンドでシグナリングされない場合、受信端末は、最大ビットレート値を不正確に想定し、それを非常に高い値や低い値に設定してしまうこともある。最大ビットレートを非常に高い値にしてしまうと、ネットワークリソースの使用は不十分なものとなり、それを非常に低い値にしてしまうと、パケットが喪失し、また、悪いメディア品質が作り出される。
【０００７】
図１は、ＱｏＳパラメータ（保証及び最大ビットレート）がエンド・ツー・エンドでシグナリングされないときに生じる従来の問題を示した簡易信号ダイアグラムである。端末ＡはＰＤＰコンテキストアクティベーションのためにＳＧＳＮと相互作用し、ＳＧＳＮはＰＤＰコンテキストアクティベーションを実行するＧＧＳＮと相互作用する。図１に示すように、最大ビットレートパラメータはエンド・ツー・エンドでシグナリングされない。端末Ｂは、この結果、最大ビットレートは７２Ｋｂｐｓであり、保証ビットレートは６４Ｋｂｐｓであると想定する。しかしながら、端末Ａは、最大ビットレートを４８Ｋｂｐｓに、保証ビットレートを４０Ｋｂｐｓに設定している。
【０００８】
図２は、送信者と受信者が、異なるタイプのトラフィッククラスを交渉しているシナリオを示す。送信者（端末Ａ）がインタラクティブ若しくはストリーミングトラフィックタイプを選択した場合、受信者は、ストリーミング若しくは対話型トラフィッククラスタイプを使用できる。受信者（端末Ｂ）は、対話型（若しくはストリーミング）トラフィッククラスのためにジッタバッファ値を割当てることもできる。しかしながら、送信者（端末Ａ）は、より大きな遅延を作り出すインタラクティブ若しくはストリーミングトラフィッククラスを交渉したため（それらで折り合いをつけたため）、受信者バッファはアンダーフローしてしまう。なぜなら、それは、非常に厳しい遅延要求を有する、対話型トラフィックタイプについてのジッタバッファを割当てるからである。この形態の結果、受信者に表示されるビデオ品質は悪化する。このように、クライアント端末がそのそれぞれのネットワークとＱｏＳを交渉したとしても、現在のメディア品質は良好なものではない。
【０００９】
現在のところ、アプリケーションのＱｏＳパラメータをマルチメディアストリームの送信者と受信者の間（つまり、送信者及び受信者アプリケーション）で交換できるメカニズムは存在しない。送信者と受信者は、各々が有する、交渉したＱｏＳパラメータについて知っているだけである。
【００１０】
したがって、コールにおいて遅延要求を他のパーティーへシグナリングして、受信者がそれに基づいてそのリソース（ジッタバッファのような）をセットアップし、且つ、それ自身のネットワークから適当なＱｏＳパラメータを交渉できるようにする必要がある。更に、端末によって無線ネットワークと交渉したＱｏＳパラメータ（例えば、保証ビットレート、最大ビットレート、許可遅延）を、セッションにおいて、発呼されたパーティーへシグナリングする必要がある。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
概して、本発明は、受信デバイスやその無線ネットワークによって最適に且つ効率的にリソースをセットアップすることができるシステム及び方法に関する。保証ビットレート、最大ビットレート、及び転送遅延（これらは、ＰＤＰコンテキストアクティベーション中に他のＱｏＳパラメータとともに交渉される）は、受信デバイスへシグナリングされる。新たなセッション記述プロトコル（ＳＤＰ）属性は、上述したＱｏＳパラメータに対して規定され、これらは、セッション開始プロトコル（ＳＩＰ）メッセージで実行される。受信デバイスは、これらのＳＤＰ属性を使用して、ＰＤＰアクティベーション中に、それ自身のワイヤレスネットワークとＱｏＳパラメータを交渉する（若しくは再交渉する）ことができる。受信デバイスは、これらのパラメータを使用して、音声及びビデオのようなメディアストリームのためのジッタバッファのようなリソースをそれに応じて設定することができる。
【課題を解決するための手段】
【００１２】
一つの例示の実施形態は、マルチメディアセッションのためにサービスの質パラメータをシグナリングする方法に関する。この方法は、マルチメディアセッションの生成時に送信デバイスから受信デバイスへサービスの質パラメータを連絡する段階と、前記受信デバイスによって該受信デバイスと関連するネットワークとパラメータを交渉する段階と、前記マルチメディアセッションの間、前記受信デバイスから前記送信デバイスへサービスの質パラメータを連絡する段階と、を含む。前記交渉したパラメータは、前記送信デバイスからの前記連絡されたサービスの質パラメータに基づく。
【００１３】
他の例示の実施形態は、マルチメディアセッションのためにサービスの質パラメータをシグナリングするシステムに関する。このシステムは、マルチメディアセッションの生成時に送信デバイスから受信デバイスへサービスの質パラメータを連絡する手段と、前記受信デバイスによって該受信デバイスと関連するネットワークとパラメータを交渉する手段と、前記マルチメディアセッションの間、前記受信デバイスから前記送信デバイスへサービスの質パラメータを連絡する手段と、を含む。前記交渉したパラメータは、前記送信デバイスからの前記連絡されたサービスの質パラメータに基づく。
【００１４】
他の例示の実施形態は、マルチメディアセッションのためにサービスの質パラメータをシグナリングするシステムに関する。このシステムは、送信デバイスと受信デバイスを含む。送信デバイスは、マルチメディアセッションを開始し且つ通信ネットワークを介してサービスの質パラメータを連絡する。受信デバイスは、前記連絡されたサービスの質パラメータを受信し、前記受信デバイスと関連する無線ネットワークとパラメータを交渉し、サービスの質パラメータを前記送信デバイスへ連絡する。
【００１５】
他の例示の実施形態は、メディア（例えば、音声、及び／又は、ビデオ）エンコーディングの際に利用されるコンピュータプログラム製品に関するものであって、これは、マルチメディアセッションの生成時に送信デバイスから受信デバイスへサービスの質パラメータを連絡するコンピュータコードと、前記受信デバイスによって該受信デバイスと関連するネットワークとパラメータを交渉するコンピュータコードと、前記マルチメディアセッションの間、前記受信デバイスから前記送信デバイスへサービスの質パラメータを連絡するコンピュータコードとを含む。前記交渉したパラメータは、前記送信デバイスからの前記連絡されたサービスの質パラメータに基づく。
【００１６】
他の例示の実施形態は、ネットワークを通じてマルチメディアセッションで通信するデバイスに関する。このデバイスは、マルチメディアセッションの開始時に受信デバイスへ連絡されるサービスの質パラメータを記憶するメモリと、前記受信デバイスから許可パラメータを受信し該許可パラメータに従ってマルチメディア通信を可能とするプロセッサと、を含む。
【００１７】
他の例示の実施形態は、ネットワークを通じてマルチメディアセッションで通信するデバイスに関する。このデバイスは、送信デバイスから受信したサービスの質パラメータに基づいて関連ネットワークとパラメータを交渉するプロセッサと、
前記送信デバイスから受信した前記サービスの質パラメータに基づいてリソースを確立するプログラムされた命令と、を含む。
【発明を実施するための最良の形態】
【００１８】
図３ａ、図３ｂは、送信デバイス１２が、ネットワーク１４を介して受信デバイス１６に連絡を行う通信システム１０を示す。送信デバイス１２は、例えば、３Ｇセルフォン、ハンドヘルドパーソナルデジタルアシスタント、若しくは、マルチメディア通信可能な何らかの他のデバイスであってもよい。ネットワーク１４は、インターネットプロトコル（ＩＰ）通信を処理できる様々なネットワークのいずれであってもよい。受信デバイス１６は、送信デバイス１２が連絡をとっているデバイスという点で、着呼されたパーティーである。
【００１９】
本明細書に記載された例示の実施形態に従って、本発明のシステム及び方法により、受信デバイス１６及びその無線ネットワークは、リソースを最適に且つ効率的にセットアップすることができる。送信デバイス１２は、交渉したＱｏＳパラメータの幾つかを、セッションセットアップ手続中に、そのセッションの受信デバイス１６へシグナリングする。マルチメディアセッションは、単方向性であっても、双方向性であってもよい。単方向性のセッションは、ＳＱＩＳアプリケーションであってもよく、双方向性のセッションは、ビデオ会議アプリケーションであってもよい。セッションが双方向性である場合、更に、受信デバイス１６はＱｏＳパラメータを送信デバイス１２へシグナリングする。
【００２０】
保証ビットレート、最大ビットレート、及び転送遅延（これらは、ＰＤＰコンテキストアクティベーション中に他のＱｏＳパラメータとともに交渉される）は、受信デバイス１６へシグナリングされる。例示した実施形態によれば、新たなセッション記述プロトコル（ＳＤＰ）属性は、上述したＱｏＳパラメータに対して規定され、これらは、セッション開始プロトコル（ＳＩＰ）メッセージで実行される。受信デバイス１６は、これらのＳＤＰ属性を使用して、ＰＤＰコンテキストアクティベーション中に、それ自身のワイヤレスネットワークとＱｏＳパラメータを交渉する（若しくは再交渉する）ことができる。受信デバイスは、これらのパラメータを使用して、音声及びビデオのようなメディアのためのジッタバッファのようなリソースをそれに応じて設定することができる。
【００２１】
図４は、例示の実施形態による、ＱｏＳ  ＳＤＰ属性を用いたシグナリングコールフロー（呼の流れ）を示す。セッション開始プロトコル（ＳＩＰ）は、セッションセットアップのためのシグナリングプロトコルである。ＳＩＰ  ＩＮＶＩＴＥメッセージは、２つのパーティー間のセッションをセットアップするために使用され、セッション記述プロトコル（ＳＤＰ）を用いてセッション及びメディア情報を記述する。ＳＤＰ情報は、２００ＯＫ、ＡＣＫ、又は、ＵＰＤＡＴＥのような、他のＳＩＰメッセージの本体に送信され得る。トランスポート情報（ポート及びＩＰアドレス）に加えて、ＳＤＰはメディア情報（例えば、コーデックやそのパラメータ）を含む。
【００２２】
端末Ａが１つの２００ＯＫ（ＰＲＡＣＫ）メッセージを端末Ｂから受信すると、端末Ａは、ＰＤＰコンテキストアクティベーション手続を開始する。端末Ａは、最大ビットレート、保証ビットレート、及び転送遅延を含んだ、なんらかのＱｏＳパラメータを要求する。ＧＧＳＮは、ネットワーク許可ＱｏＳパラメータを用いて端末Ａに応答を返す。同様に、端末Ｂは、ＰＤＰコンテキストアクティベーション手続を開始し、ネットワークからＱｏＳを要求する。
【００２３】
例示の実施形態によれば、「３ｇｐｐ−保証ビットレート（ｇｕａｒａｎｔｅｅｄｂｉｔｒａｔｅ）」と呼ばれる属性がＳＤＰで規定される。これは、受信デバイスがその無線ネットワークと交渉した、保証された帯域幅を示す。３ｇｐｐ保証ビットレートは、ＳＤＰにおいて、「ａ＝３ｇｐｐ−保証ビットレート；＜値＞」として宣言され得る。ここで、＜値＞は、そのセッションのためにネットワークによって受信デバイスに割当てられた保証されたビットレートをキロビット／秒（若しくは他のいずれかの適当な単位）で示す。
【００２４】
例示の実施形態によれば、「３ｇｐｐ−最大ビットレート（ｍａｘｂｉｔｒａｔｅ）」と呼ばれる属性がＳＤＰで規定される。これは、受信デバイスがその無線ネットワークと交渉した、最大ビットレートを示す。３ｇｐｐ最大ビットレートは、ＳＤＰにおいて、「ａ＝３ｇｐｐ−最大ビットレート；＜値＞」として宣言され得る。ここで、＜値＞は、そのセッションのためにネットワークによって受信デバイスに割当てられた最大ビットレートをキロビット／秒（若しくは他のいずれかの適当な単位）で示す。
【００２５】
例示の実施形態によれば、「３ｇｐｐ−許可遅延（ｇｒａｎｔｅｄｄｅｌａｙ）」と呼ばれる属性がＳＤＰで規定される。これは、送信者が無線ネットワークと交渉した、転送遅延値を示す。遅延属性は、ＳＤＰにおいて、「ａ＝３ｇｐｐ−許可遅延；＜遅延−値（delay-value）＞」として宣言され得る。ここで、遅延-値は、そのセッション中に送信デバイスが使用したい、ミリ秒（若しくは他のいずれかの時間又は空間ドメイン）における遅延である。
【００２６】
一例として、３ｇｐｐ−許可遅延ＳＤＰ属性には、＊や０の値が割当てられてもよい。値＊は、遅延値が未知であり、また、遅延値に保証がなくパケットは異なる転送遅延量を取り得るといった無制約の意味を特定する。インタラクティブ及びバックグラウンドトラフィッククラスに関して、ＵＭＴＳネットワークは、ネットワークリソースや負荷に依存して、その無制約若しくは最大限の努力を課すような、ＰＤＰコンテキスト転送遅延値を割り当るものではない。この場合、ＳＤＰ属性には、＊又は０の値を割当てることができる。
【００２７】
上に規定した１つ又は２つ以上の属性は、ＳＤＰに含めることができる（それはＵＰＤＡＴＥ、２００ＯＫ、又はＡＣＫメッセージのいずれにおいても送信できる）。ここで規定したＱｏＳパラメータは、（新たなセッションを開始するために送信される）初期ＳＩＰ  ＩＮＶＩＴＥメッセージに含めることはできない。３ＧＰＰ  ＩＭＳ（ＩＰマルチメディアサブシステム）コールでは、ＱｏＳパラメータは、送信者が初期ＩＮＶＩＴＥメッセージを送信し、他のパーティーからマルチメディアセッションにて自身が参加したいことを表示するような応答を受信した後にのみ交渉される。
【００２８】
端末ＡがＰＤＰコンテキストアクティベーションアクセプト（承認）メッセージをネットワークから受信したとき、端末Ａは、ここで規定したＱｏＳパラメータをシグナリングするＳＩＰ  ＵＰＤＡＴＥメッセージを送信する。他のパラメータもシグナリングするのが好ましい。ＵＰＤＡＴＥメッセージを受信すると、端末Ｂは、ＰＤＰコンテキストを変更する。双方向性のコールに関しては、端末Ｂも、許可されたＱｏＳパラメータを端末Ａにシグナリングする。ＳＤＰの受信者が上で規定したＱｏＳ属性を理解しない場合、それは、セッションセットアップ手続に何らの否定的な影響を与えることなく、その属性を無視できる。
【００２９】
例示の実施形態によれば、保証された最大のビットレートがエンド・ツー・エンドでシグナリングされ、受信者（及び送信者）ネットワークが、ネットワークリソース（無線及びコアネットワーク）を最適に且つ効率的にセットアップできるという利点がある。更に、例示の実施形態によれば、明らかに良好なメディア品質が提供され、メディアコーディックをデバイスによって連絡された情報を用いて開始することができる。
【００３０】
遅延要求をシグナリングすることによって、受信者側は、リソースをセットアップし、且つ、正確なパラメータを自身のネットワークから要求することができる。例えば、受信者側はメモリバッファ値をセットアップすることができる。ストリーミングやＳＷＩＳのようなマルチメディアアプリケーションでは、そのリソースの確立によって受信デバイスは利点を得る。例えば、ビデオ会議のようなアプリケーションに関して、遅延要求のシグナリングは有用である。なぜなら、セッションの着呼パーティーは、そのセッションのために正確な遅延要求を要求することができるからである。非ＩＭＳ  ＳＩＰネットワークに関して、遅延要求は、送信者によって、特定のアプリケーションのための既知のデフォルト値へ設定され得る。例示の実施形態の他の利点は、ＱｏＳパラメータを双方向モードでエンド・ツー・エンドでシグナリングできる点にある。更に、付加的なＱｏＳパラメータがＳＤＰによって規定される。
【００３１】
本発明の幾つかの実施形態を説明してきたが、本願発明に関係する当業者であれば変更を思いつくだろう。例えば、ＳＤＰとＳＩＰはプロトコルの例である、と理解すべきである。パーティー同士の間の情報は、いずれのプロトコルメッセージを用いても、ＩＳＯ  ＯＳＩ（国際標準化機構、オープンシステムインターコネクション）スタックのいずれのレイヤにおいても、転送され得る。故に、明細書に添付した請求項が、本発明を正確に規定するものである。
【図面の簡単な説明】
【００３２】
【図１】サービスの質（ＱｏＳ）をシグナリングするコールフローの相互関係を示す図。
【図２】ＩＭＳ（ＩＰマルチメディアサブシステム）マルチメディアコール中の不正確なトラフィックタイプの設定を示す図。
【図３ａ】例示の実施形態による通信システムを示す図。
【図３ｂ】例示の実施形態による通信システムを示す図。
【図４】例示の実施形態によるＩＭＳコールセットアップのためのＱｏＳパラメータのエンド・ツー・エンドシグナリングを示す図。
【図１】
2008541532.tif 000003
【図２】
2008541532.tif 000004
【図３ａ】
2008541532.tif 000005
【図３ｂ】
2008541532.tif 000006
【図４】
2008541532.tif 000007
【国際調査報告】
2008541532.tif 000008
2008541532.tif 000009
2008541532.tif 000010
2008541532.tif 000011