JP2007527634A - モバイルネットワーク内における動的なメディア認可 - Google Patents

Abstract

モバイルネットワーク内における複数のメディアストリームを有するセッション（ユーザ又はモバイル端末間における接続）（図２）の動的なメディア認可とＱＯＳクラスのさらに良好な管理のための解決策を有するネットワークインターフェイスアーキテクチャが提供され、この結果、セッション期間中にメディアストリームが修正される場合に（新しいものが起動され、既存のものが削除される場合）、その同一のセッションに属するメディアストリームの伝送遅延の差を除去するべく、セッションのトラフィッククラスが、その同一セッションに属するメディアフローによる最上位のトラフィッククラスの要求によって規定され、この結果、エンドユーザが知覚する接続品質が改善される。

Description

本発明は、エンドツーエンドのサービス品質（ＱｏＳ）管理を含むモバイルネットワークに関するものであり、更に詳しくは、モバイルネットワーク内における複数の異なるタイプのメディアストリームを有するセッション（ユーザ又はモバイル端末間又はモバイル端末とサーバ間における接続）の動的なメディア認可（ａｕｔｈｏｒｉｚａｔｉｏｎ）とＱｏＳクラスの管理に関するものである。

すべてのＧＳＭ（汎欧州移動通信システム）及び第３世代のＧＳＭネットワークが含まれる、３ＧＰＰ（第３世代パートナーシッププロジェクト）仕様書によって標準化されているネットワークなどの最近のモバイルネットワークは、例えば、モバイルデータネットワークサービスやＩＰマルチメディアサービスを含む通信サービスを提供するべく、デジタルセルラネットワークとパーソナル通信システムのシームレスな統合体になっている。

それぞれの３ＧＰＰシステムは、一般パケット無線サービス（ＧＰＲＳ）及びグローバル展開のための拡張データレート（ＥＤＧＥ）技術を使用する、あるいは、周波数分割多重（ＦＤＤ）及び時分割多重（ＴＤＤ）の両方で動作可能なユニバーサル地上無線アクセス（ＵＴＲＡ）をサポートする、コアネットワーク及び無線アクセスネットワークのインフラストラクチャを含むことができる。コアネットワーク（ＣＮ）は、ユーザトラフィック及び関連するシグナリング用に提供されているＣＮエンティティを有する回線交換（ＣＳ）及びパケット交換（ＰＳ）ドメインと、ＩＰマルチメディアサービス用に提供されているコアネットワーク（ＣＮ）エンティティを有するＩＰマルチメディアサブシステム（ＩＭＳ）に論理的に分割可能である。ホーム加入者サーバ（ＨＳＳ）、ホーム位置レジスタ（ＨＬＲ）、認証センタ（ＡｕＣ）、ビジタ位置レジスタ（ＶＬＲ）、及び装置識別レジスタ（ＥＩＲ）などのいくつかのＣＮエンティティは、ＰＳ及びＣＳドメインに共通であるが、移動交換局（ＭＳＣ）やゲートウェイＭＳＣなどのその他のＣＮエンティティは、移動局との間の回線交換サービスを処理するべく、ＣＳドメインに固有であり、ゲートウェイＧＰＲＳ（一般パケット無線サービス）サポートノード（ＧＧＳＮ）とサービングＧＳＮ（ＳＧＳＮ）は、移動局との間のパケット伝送を処理するべく、ＰＳドメインに固有である。

ＩＰマルチメディアサービスの場合には、ＩＭＳに関連するシグナリングのＰＤＰ（パケットデータプロトコル、例えばＩＰ）コンテキストの確立、登録、及びＩＭＳセッションのその他の手順が含まれる、呼セッション制御機能（ＣＳＣＦ）に関係する手順を処理するべく、ＣＳＣＦなどの機能的ＩＭＳエンティティを提供可能である。ＣＳＣＦは、ＩＰマルチメディアサブシステム（ＩＭＳ）内において、ユーザ装置（ＵＥ）（即ち、ユーザがネットワークにアクセスできるようにするモバイル端末などの装置）用の第１コンタクトポイントとしての役目を果すべくＰ−ＣＳＣＦ（プロキシＣＳＣＦ）として機能したり、ネットワーク内においてセッションの状態を処理するべく、Ｓ−ＣＳＣＦ（サービングＣＳＣＦ）としての役目を果したり、そのネットワーク事業者の加入者又は所定のサービスエリア内のローミング加入者宛てのすべてのＩＭＳ接続用の事業者のネットワーク内におけるコンタクトポイントとしての役目を果すべく、Ｉ−ＣＳＣＦ（問い合わせ用ＣＳＣＦ）として機能することができる。３ＧＰＰ技術仕様書（ＴＳ） ２３．００２、Ｖ５．９．０（２００２年１２月）「ネットワークアーキテクチャ」、３ＧＰＰ ＴＳ ２３．１０１、Ｖ４．０．０（２００２年４月）「ＵＭＴＳアーキテクチャ概要」、３ＧＰＰ ＴＳ ２３．１１０、Ｖ４．０．０（２００１年４月）「ＵＭＴＳアクセス階層、サービス及び機能」、及び３ＧＰＰ技術仕様書（ＴＳ）２３．２２８、Ｖ６．０．１（２００３年１月）「ＩＰマルチメディアサブシステム（ＩＭＳ）」を参照されたい。すべての３ＧＰＰ（ＧＳＭ／３Ｇ）仕様書は、ｆｔｐ：／／ｆｔｐ．３ｇｐｐ．ｏｒｇ／ｓｐｅｃｓのサーバから得ることができ、ここからダウンロード可能であり、引用により、これらの内容は、本明細書に包含される。又、３ＧＰＰ仕様書（これには、新規又は変更された機能を有する所定の３ＧＰＰ仕様書のさまざまな版が含まれる）を生成、維持管理、及び更新するためのメカニズムに関しては、３ＧＰＰ技術仕様書（ＴＳ）２１．９００、Ｖ５．０．１（２００２年９月）「技術仕様書グループ作業方法」を参照されたい。

３ＧＰＰ ＴＳ ２９．２０７、Ｖ．５．２．０（２００２年１２月）「Ｇｏインタフェースによるポリシー制御」、第５版、３ＧＰＰ ＴＳ２３．２０７、Ｖ．５．６．０（２００２年１２月）「エンドツーエンドサービス品質（ＱｏＳ）の概念及びアーキテクチャ」、第５版、及び３ＧＰＰ ＴＳ ２９．２０８ Ｖ．５．２．０（２００２年１２月）「エンドツーエンドサービス品質（ＱｏＳ）のシグナリングフロー」、第５版、に記述されているように、複数のメディアストリームを有するセッションのサービス品質（ＱｏＳ）クラスの管理を監視し、２つのユーザ（モバイル端末）間又はモバイル端末とサーバ間における所定のメディアフローの最大認可トラフィッククラスが含まれる、セッション及びメディア関連情報に基づいてポリシーを決定した後に、Ｇｏインターフェイスを介して、ＧＧＳＮと決定情報を交換するべく、ポリシー決定機能（ＰＤＦ）が既に標準化されている。このようなＰＤＦは、３ＧＰＰ仕様書の第５版（２００２年１２月）に記述されているように、Ｐ−ＣＳＣＦ内に一体化することも可能であり、或いは、３ＧＰＰ仕様書の第６版（２００３年１月）に記述されているように、Ｐ−ＣＳＣＦとは別個のネットワーク要素として実装することも可能である。

一般に、ユーザ装置（ＵＥ）（例えば、モバイル端末）間又はモバイル端末とサーバ間にセッション（接続）が確立され、このセッションが修正される（例えば、双方向オーディオ及び単方向ビデオから単方向ビデオのみに）場合には、ＰＤＦによってトラフィッククラスが修正される（会話型からストリーミングに）。これは、ユーザ装置（ＵＥ）（例えば、モバイル端末）間又はモバイル端末とサーバ間に確立されているセッションが、双方向オーディオフローと単方向ビデオフローを有しているためである。双方向オーディオフローは、リアルタイムの会話に使用されるものであり、従って、これには、遅延の小さなリアルタイムトラフィッククラス、即ち、ＣＯＮＶＥＲＳＡＴＩＯＮＡＬ（会話型）トラフィッククラスが必要である。一方、単方向ビデオフローは、動画を一方向にのみ転送するのに使用されるものであり、このような単方向リアルタイムビデオフローの場合には、送信者が応答の受信を期待していないため、相対的に大きな伝送遅延及び遅延変動（即ち、ジッタ）が許容されている。この結果、単方向リアルタイムフローは、典型的には、ＳＴＲＥＡＭＩＮＧ（ストリーミング）トラフィッククラスを実際には、使用している。セッションが修正される場合には、即ち、双方向オーディオフロー及び単方向ビデオフローのいずれかが終了し、セッションから除去されると、これに応じて、ＰＤＦによってそのセッションのベアラリソースのトラフィッククラスを修正する必要がある。例えば、ＣＯＮＶＥＲＳＡＳＩＯＮＡＬトラフィッククラスを有する双方向オーディオフローがセッションから除去される場合には、デフォルト設定の要件としてＳＴＲＥＡＭＩＮＧトラフィッククラスを有する単方向ビデオフローが、そのセッションにおける「最上位のトラフィッククラス」となる。この結果、ＰＤＦは、このセッションのベアラのトラフィッククラスをＣＯＮＶＥＲＳＡＳＩＯＮＡＬトラフィッククラスからＳＴＲＥＡＭＩＮＧトラフィッククラスに修正（即ち、ダウングレード）する。

しかしながら、これらのトラフィッククラスにおいては、受信端末内のバッファサイズなどのいくつかのパラメータが異なっており、固有の伝送遅延の変化を伴うトラフィッククラスの修正により、受信端末又はサーバにおいて、バッファのアンダーフローが発生することになり、この結果、エンドユーザが知覚する接続品質が低下する。

双方向（例えばオーディオ）ストリームを有する既存のセッションに、単方向（例えばビデオ）ストリームが追加される場合には、別の大きな問題が生じる可能性がある。単方向ビデオストリームのシグナリングされたトラフィッククラス要求は、典型的には、ストリーミングであるのに対して、双方向セッションのトラフィッククラスは、会話型である。それらのメディアストリームが時間的な関係を具備している場合には（例えば、オーディオストリーム内において、ビデオストリームについて口頭説明している場合）、トラフィッククラスの違いのために伝送遅延に差が生じ（これは、伝送における遅延及び遅延ジッタの差を補償するための受信機内のバッファ長の差に起因するものである）、この結果、エンドユーザが知覚する接続品質が低下することになるのである。

従って、１つのセッション（ユーザ又はモバイル端末間又はモバイル端末とサーバ間における接続）が複数の異なるタイプのメディアストリームを有することができるすべてのシステムに適用可能であると共に、モバイルネットワーク内における複数の異なるタイプのメディアストリームを有するセッション（ユーザ又はモバイル端末間又はモバイル端末とサーバ間における接続）の動的なメディアの認可とサービス品質（ＱｏＳ）クラスの良好な管理に関係する解決策に対するニーズが存在しており、このために、同一のセッションに属するメディアストリームの伝送遅延の差を除去すべく、セッション期間中に１つ又は複数のメディアストリームが修正される場合に（新しいものが起動され、既存のものが削除される場合に）、セッションのトラフィッククラスを、その同一のセッションに属するメディアフローによる最上位のトラフィッククラスの要件によって規定し、これにより、エンドユーザが知覚する接続品質を改善する。

本発明の様々な態様は、モバイルネットワーク内における複数の異なるタイプのメディアストリームを有するセッション（ユーザ又はモバイル端末間又はモバイル端末とサーバ間における接続）の動的なメディア認可とサービス品質（ＱｏＳ）クラスの良好な管理のための解決策を対象とするものであり、この解決策によれば、同一セッションに属するメディアストリームの伝送遅延の差を除去するべく、セッション期間中に１つ又は複数のメディアストリームが修正される場合に（新規のものが起動され、既存のものが削除される場合）、セッションのトラフィッククラスが、その同一セッションに属するメディアフローによる最上位のトラフィッククラスの要件によって規定され、この結果、エンドユーザが知覚する接続品質が改善される。

本発明の一態様によれば、２つのモバイル端末間又はモバイル端末とサーバ間におけるセッションの所定のメディアフローの最大認可トラフィッククラスを決定するべく、モバイルネットワークにポリシー決定機能（ＰＤＦ）が提供される。このようなＰＤＦは、通信リンクを介して２つのモバイル端末間又はモバイル端末とサーバ間においてセッションが確立並びに修正される際に、複数の異なるタイプのメディアストリーム内において最上位のトラフィッククラスを必要としている１つ又はいくつかのメディアストリームが、そのセッションから除去されるかどうかを判定し、その最上位のトラフィッククラスを必要としている１つ又はいくつかのメディアストリームがセッションから除去される場合に、そのセッションの残りのメディアストリームに使用されるトラフィッククラスを維持するべく構成されている。

本発明の別の態様によれば、ポリシー決定機能（ＰＤＦ）は、通信リンクを介して２つのモバイル端末間又はモバイル端末とサーバ間においてセッションが確立又は修正される場合に、双方向ストリームを有するセッションに単方向ストリームが追加されるかどうかを判定し、通信リンクを介した２つのモバイル端末間又はモバイル端末とサーバ間におけるセッションの所定のメディアフローの最大認可トラフィッククラスを決定するべくモバイルネットワーク内における双方向ストリームを有するセッションに単方向ストリームが追加される場合には、そのセッションのメディアストリームのいずれかに割り当てられている最上位のトラフィッククラスを、そのセッションの存続期間にわたって、そのセッションのすべてのメディアストリームに適用するように構成される。

本発明の更に別の態様によれば、モバイルネットワークによって実行される際に、２のモバイル端末間又はモバイル端末とサーバ間におけるセッションの所定のメディアフローの最大認可トラフィッククラスを決定する方法を実行する命令を有するコンピュータ可読媒体が提供され、この方法は、通信リンクを介して２つのモバイル端末間又はモバイル端末とサーバ間においてセッションが確立又は修正される場合に、双方向ストリームを有するセッションに単方向ストリームが追加されるかどうかを判定する段階と、双方向ストリームを有するセッションに単方向ストリームが追加される場合には、そのセッションの存続期間にわたって、そのセッションのすべてのメディアストリームに対して、そのセッションのメディアストリームのいずれかに割り当てられる最上位のトラフィッククラスを適用する段階と、を含んでいる。

以下、一例として添付されている図面を参照し、本発明について更に具体的に説明する。

本発明、並びに本発明に付随する利点の多くについては、添付の図面との関連で、以下の詳細な説明を参照することにより、容易に明らかとなり、十分に理解することができよう。尚、添付図面においては、類似の参照符号によって同一又は類似のコンポーネントを示している。

本発明は、例えば、第２世代及び第３世代の汎欧州移動通信システム（ＧＳＭ）ネットワーク、インターネット、イントラネット、ローカルエリアネットワーク（ＬＡＮ）、及びＡＴＭに基づいた通過ネットワークなどの通過ネットワーク、公衆交換電話網（ＰＳＴＮ）、ＩＳＤＮ、ＩＰネットワーク／ＬＡＮ、Ｘ．２５、及び公衆陸上移動通信ネットワーク（ＰＬＭＮ）などの終端ネットワーク、相互接続されたシステム及びこのようなモバイルネットワークにおけるシステム間の音声、メッセージ、データ、及び画像転送に使用される関連プロトコルを含む複数の異なるタイプのメディアストリームをサポートするあらゆるタイプのネットワークに適用可能である。しかし、簡単にするために、以下においては、主に、ＩＰマルチメディアサービスを提供するＩＰマルチメディアサブシステム（ＩＭＳ）を含む単純なマルチメディアネットワークを中心として説明することとする。

ここで、添付図面中の図１を注目すれば、３ＧＰＰ仕様書の第５版によるＩＰマルチメディアサービスを含む通信サービスを提供するネットワークシステムアーキテクチャの例が示されている。この図１に示されているように、ネットワークシステムアーキテクチャ１００は、例えば、発信元のユーザ装置（ＵＥ）１１０、終端ユーザ装置（ＵＥ）１２０又は、この逆、並びに、これらのユーザ装置（ＵＥ）１１０／１２０を接続するべく構成され、公衆陸上移動通信ネットワーク（ＰＬＭＮ）１３２、１つ又は複数の通過ネットワーク１３４、及び終端ネットワーク１３６などの単一ネットワーク又は様々なネットワークにまたがる通信リンク１３０を広範に含むことができる。ユーザ装置（ＵＥ）１１０／１２０は、ユーザがネットワークサービスにアクセスできるようにする任意の装置又はユーザ端末であってよく、これには、例えば、３ＧＰＰ ＴＳ ２４．００２、Ｖ５．０．０（２００１年１２月）、第５版、に規定されているＧＳＭ用のリモートサーバ又はモバイル端末が含まれる。

それぞれのＵＥ１１０／１２０は、例えば、無線伝送及び関連機能を実行するべく構成されたモバイル終端（ＭＴ）１１２、端末装置（ＴＥ）１１４、及び端末適合機能（ＴＡＦ）１１６を含むことが可能であり、これには、通信サービスをサポートするエンドツーエンドアプリケーションを含むことができる。

通過ネットワーク１３４には、インターネット、イントラネット、ローカルエリアネットワーク（ＬＡＮ）、又はＡＴＭに基づいた通過ネットワークが含まれるが、しかし、これらに限定されるものではない。終端ネットワーク１３６は、公衆交換電話網（ＰＳＴＮ）、ＩＳＤＮ、ＩＰネットワーク／ＬＡＮ、Ｘ．２５、又はその他の公衆陸上移動通信ネットワーク（ＰＬＭＮ）が含まれるが、しかし、これらに限定されるものではない。

図２は、３ＧＰＰ仕様書の第５版によるモバイルネットワーク内のＩＭＳ機能エンティティのインターフェイスアーキテクチャの例を示している。この図２に示されているように、ゲートウェイＧＰＲＳ（一般パケット無線サービス）サポートノード（ＧＧＳＮ）２１０と、プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）２２０が、コアネットワークの一部を構成するネットワークエンティティを表している。ＧＧＳＮ２１０を使用することにより、ＵＥ１１０／１２０（例えば移動局）との間のパケット伝送を処理し、Ｐ−ＣＳＣＦ２２０を使用することにより、所定のＵＥ１１０／１２０用の第１コンタクトポイントとして機能すると共に、セッション管理サービスとＣＳＣＦ関連手順を提供しているが、これには、ＩＰマルチメディアサブシステム（ＩＭＳ）関連シグナリングのＰＤＰ（パケットデータプロトコル、例えばＩＰ）コンテキストを確立する段階、登録、及びＩＭＳセッションのその他の手順が含まれる。

ＵＥ１１０が、ＩＭＳセッションのパラメータをネゴシエートするためのＳＤＰ（セッション記述プロトコル）シグナリングを含むＳＩＰ（セッション開始プロトコル）メッセージを発行又は受信した場合に、ＩＭＳセッションを監視し、Ｐ−ＣＳＣＦ２２０から得られたＩＭＳセッション及びメディア関連情報に基づいて、２つのユーザ（例えばモバイル端末）間又はモバイル端末とサーバ間における所定のメディアフローの最大認可トラフィッククラスに関する決定が含まれるポリシー決定を行った後に、３ＧＰＰ ＴＳ ２９．２０７、Ｖ５．２．０（２００２年１２月）「Ｇｏインタフェースによるポリシー制御」、第５版、に記述されているように、Ｇｏインターフェイスを介してＧＧＳＮ２１０と決定情報を交換するべく、３ＧＰＰ仕様書の第５版（２００２年１２月）に従って、ポリシー決定機能（ＰＤＦ）２２２がＰ−ＣＳＣＦ２２０内に一体化される。さらに、それぞれのＰＤＰ（パケットデータプロトコル、例えばＩＰ）コンテキストごとに許容されているＩＭＳセッションは１つのみである。或いは、この代わりに、３ＧＰＰ仕様書の第６版（２００３年１月）に記述されているように、Ｐ−ＣＳＣＦ２２０とは別個のネットワーク要素に、ＰＤＦを実装することも可能である。

前述のように、３ＧＰＰ仕様書の第５版に記述されているように、このＰＤＦ２２２を使用することにより、ＩＭＳセッションのＩＭＳレベルとＧＰＲＳベアラレベルを結合（ｂｉｎｄ）する結合情報（ｂｉｎｄｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）（特に、認可トークン）の組を生成し、ユーザ装置（ＵＥ）１１０を介して、この結合情報をＧＧＳＮ２１０に送信することができる。この結合情報は、ＰＤＰ（パケットデータプロトコル、例えばＩＰ）コンテキストをＩＭＳセッションの１つ又は複数のメディアコンポーネント（ＩＰフロー）に関連付けるものであり、ＧＧＳＮ２１０は、この結合情報を使用することにより、ＰＤＦ２２２から、サービスベースのローカルポリシー（ＳＢＬＰ）情報を要求する。この結合情報には、典型的には、（１）ＳＩＰ／ＳＤＰシグナリングの期間にＰ−ＣＳＣＦ２２０によりＵＥ１１０に送信される認可トークンと、（２）ＵＥ１１０、ＧＧＳＮ２１０及びＰＤＦ２２２が、ＳＩＰセッションと関連する１つ又は複数のＩＰメディアフローを一意に識別するのに使用する１つ以上のフロー識別子（これは、Ｐ−ＣＳＣＦ／ＰＤＦから結合情報を受信した後に、ＵＥ１１０が追加可能である）と、が含まれている。

このような結合情報を受信すると、ＧＧＳＮ２１０を使用することにより、ＵＥ１１０から受信した結合情報の組から（認可トークンから）ＰＤＦアドレスを探索し、正しいＰＤＦを識別して、ＵＥ１１０が要求しているＰＤＰコンテキストの動作が、ＩＭＳレベル上の先行するネゴシエーションに従っていることを検証する。

ＧＧＳＮ２１０内においては、ポリシー実行点（ＰＥＰ）２１２が、サービスベースのローカルポリシー（ＳＢＬＰ）制御に関してＰＤＰと通信する論理エンティティである。簡単化のために、ＧＧＳＮ２１０は、特に明記しない限り、このＰＥＰ２１２を暗黙のうちに含んでいるものと仮定している。ＧＧＳＮ２１０は、ＰＤＦ２２２に対して要求を送信し、決定内容をＰＤＦ２２２から受信する。ＧＧＳＮ２１０は、ＰＤＦの決定のポリシー決定データをキャッシング可能であり、このデータを後で使用することにより、ＰＤＦ２２２との更なるやり取りを必要とすることなしに、ＰＤＰコンテキスト修正用のサービス品質（ＱｏＳ）認可に関するポリシー制御決定をＧＧＳＮ２１０が行うことを可能にするローカルポリシーを決定することができる。ＧＧＳＮ内のＳＢＬＰのＰＥＰ機能については、３ＧＰＰ ＴＳ ２９．２０７、Ｖ．５．２．０（２００２年１２月）「Ｇｏインタフェースによるポリシー制御」、第５版、に記述されており、本引用により、この内容は、本明細書に包含されるため、本明細書においては、この説明を省略する。

また、ＵＥ１１０及びＧＧＳＮ２１０は、いずれも、３ＧＰＰ ＴＳ ２３．２０７、Ｖ５．６．０（２００２年１２月）「エンドツーエンドサービス品質（ＱｏＳ）の概念とアーキテクチャ」、第５版、並びに、３ＧＰＰ ＴＳ ２９．２０８、Ｖ５．２．０（２００２年１２月）「エンドツーエンドサービス品質（ＱｏＳ）シグナルフロー」、第５版、に記述され、引用により、本明細書に包含されている、ＩＰサービス品質（ＩＰ ＱｏＳ）エンドツーエンド機能及び関連シグナリングフローを管理するメカニズムを含むことが可能である。例えば、ＵＥ１１０は、クライアントアプリケーション（図示されてはいない）、ＩＰベアラサービス（ＢＳ）マネージャ（図示されてはいない）、変換／マッピング機能（図示されてはいない）、並びに、オプションとして、ＵＭＴＳベアラサービス（ＢＳ）マネージャ（図示されてはいない）を含むことができる。同様に、ＧＧＳＮ２１０も、ＩＰ ＢＳマネージャ（図示されてはいない）、変換／マッピング機能（図示されてはいない）、並びに、オプションとして、ＵＭＴＳ ＢＳ マネージャ（図示されてはいない）を含むことができる。ＩＰ ＢＳマネージャは、典型的には、標準的なＩＰメカニズムを使用することにより、ＩＰベアラサービスを管理する。変換／マッピング機能は、ＵＭＴＳベアラサービス内において使用されるメカニズム及びパラメータとＩＰベアラサービス内において使用されるメカニズム及びパラメータ間の相互作用を提供し、ＩＰ ＢＳマネージャとやり取りする。ＵＭＴＳ ＢＳマネージャは、標準的なＵＭＴＳメカニズムを使用することにより、ＵＭＴＳ（ユニバーサル移動通信システム）ベアラサービスと、ＵＭＴＳベアラサービスのＱｏＳ管理機能を管理する。

一般に、セッション（接続）は、ユーザ装置（ＵＥ）（例えばＩＰマルチメディアストリームを送受信する能力を有するモバイル端末）間又はモバイル端末とサーバ間において確立される。そして、このユーザ装置（ＵＥ）（例えばモバイル端末）間又はモバイル端末とサーバ間に確立されたセッションは、例えば、双方向オーディオフローと単方向ビデオフローを有している。双方向オーディオフローは、リアルタイムの会話に使用されるものであり、従って、これは、遅延の小さなリアルタイムのトラフィッククラス、即ち、ＣＯＮＶＥＲＳＡＴＩＯＮＡＬトラフィッククラスを必要とする。単方向ビデオフローは、動画を一方向にのみ転送するのに使用される。送信者が応答の受信を期待していないため、この種の単方向リアルタイムビデオフローは、相対的に大きな伝送遅延と遅延変動（即ち、ジッタ）を許容する。この結果、単方向リアルタイムフローは、典型的には、ＳＴＲＥＡＭＩＮＧトラフィッククラスが実際には使用される。ＣＯＮＶＥＲＳＡＴＩＯＮＡＬトラフィッククラスは、通信の当事者（即ち、モバイル端末又はモバイル端末とサーバ間）が受ける遅延を最小にするべく、小さな最大伝送遅延及び遅延変動によって特徴付けられているのに対して、ＳＴＲＥＡＭＩＮＧトラフィッククラスは、リアルタイム応答を期待するリアルタイムの２方向通信が存在していないため、相対的に大きな最大伝送遅延及び遅延変動によって特徴付けられている。この結果、ＣＯＮＶＥＲＳＡＴＩＯＮＡＬトラフィッククラスは、「下位トラフィッククラス」として知られているＳＴＲＥＡＭＩＮＧトラフィッククラスに対して「上位トラフィッククラス」として知られている。

３ＧＰＰ ＴＳ ２３．１０７によれば、ＩＮＴＥＲＡＣＴＩＶＥ（双方向型）トラフィッククラスやＢＡＣＫＧＲＯＵＮＤ（背景）トラフィッククラスなど、このセッションの例において必要とされ得るその他のトラフィッククラスも存在している。例えば、ＩＮＴＥＲＡＣＴＩＶＥトラフィッククラスは、ＳＴＲＥＡＭＩＮＧトラフィッククラスよりも更に大きな伝送遅延とジッタを許容することを特徴としており、従って、これは、ＳＴＲＥＡＭＩＮＧトラフィククラスよりも更に「下位のトラフィッククラス」である。そして、ＢＡＣＫＧＲＯＵＮＤトラフィッククラスは、更に大きな伝送遅延及びジッタを許容することを特徴としており、従って、これは、ＩＮＴＥＲＡＣＴＩＶＥトラフィッククラスよりも更に下位のトラフィッククラスである。しかしながら、このセッションの例におけるオーディオ及びビデオストリームは、同一のベアラ（例えば、ネットワークシステム内の１つのＰＤＰコンテキスト）によって搬送することも可能であると共に、互いの間に時間的な関係を具備することも可能であり、これは、セッション全体のベアラリソースが、そのセッションの「最上位のトラフィッククラス」に応じて、ＣＯＮＶＥＲＳＡＴＩＯＮＡＬトラフィッククラスを具備することを意味している。

時間の経過に伴って、セッションは変化し得る、即ち、通信の当事者（即ち、モバイル端末又はモバイル端末とサーバ間）が、例えば、セッション内の単方向ビデオフローを維持したまま、そのセッション内の双方向オーディオフローの終了を所望できる。それに応じて、セッションのベアラリソースのトラフィッククラスをＰＤＦによって修正する必要がある。例えば、セッションが修正され、ＣＯＮＶＥＲＳＡＴＩＯＮＡＬトラフィッククラスを有する双方向オーディオフローがセッションから除去された場合には、デフォルト設定の要件としてＳＴＲＥＡＭＩＮＧトラフィッククラスを有する単方向ビデオフローが、そのセッションの「最上位トラフィッククラス」を有する。この結果、ＰＤＦは、そのセッションのベアラのトラフィッククラスを、ＣＯＮＶＥＲＳＡＴＩＯＮＡＬトラフィッククラスからＳＴＲＥＡＭＩＮＧトラフィッククラスに修正（即ち、ダウングレード）する。

しかしながら、セッションが修正され（例えば、双方向オーディオ及び単方向ビデオから単方向ビデオのみに）、トラフィッククラスが、ＰＤＦ２２２によって変更される（例えば、会話からストリーミングに）場合に、これらのＱｏＳクラス間において、受信端末内のバッファサイズなどのいくつかのパラメータが異なっているため、伝送遅延の変化を伴うトラフィッククラスの修正により、受信端末において、バッファのアンダーフローが発生し、この結果、エンドユーザが知覚する接続品質が低下することになる。

例えば、セッション（接続）が確立されると、モバイル端末又はモバイル端末及びサーバが、双方向音声ストリームによって通信を開始する。この時点で、ＰＤＦ２２２は、この音声ストリームに対して、ＣＯＮＶＥＲＳＡＴＩＯＮＡＬに等しい最大認可トラフィッククラスを割り当てる。そして、時間の経過に伴って、モバイル端末又は、モバイル端末及びサーバの１つが、この通信に、ビデオストリームを追加することを決定し、またこのビデオストリームは単方向である。この時点で、ＰＤＦ２２２は、このセッション（接続）に属しているＩＰマルチメディアフローの現在の組をチェックし、ビデオストリームに対して、「ＣＯＮＶＥＲＳＡＴＩＯＮＡＬ」に等しい最大認可トラフィッククラスを割り当てることを決定する。このクラスが選択された理由は、「ＣＯＮＶＥＲＳＡＴＩＯＮＡＬ」トラフィッククラスにまで認可されている既存の双方向メディアフローが既に存在しているためである。この結果、音声及びビデオストリームの両方を受信するモバイル端末又はサーバは、オーディオ−ビデオの同期を得ることができる。そして、時間の経過に伴って、２つのモバイル端末、又は、モバイル端末とサーバが、音声通信を停止して、単方向のビデオ伝送を継続することを決定する。この時点で、ＰＤＦ２２２は、このセッションに属しているＩＰマルチメディアフローの現在の組をチェックし（この通信に残っているのは、単方向ビデオフローのみである）、その最大認可トラフィッククラスを「ＳＴＲＥＡＭＩＮＧ」に修正することを決定する。この理由は、単方向メディアフローは、常に「ＳＴＲＥＡＭＩＮＧ」に等しい最大認可トラフィッククラスを取得するためである。

しかしながら、最大認可トラフィッククラスが、「ＣＯＮＶＥＲＳＡＴＩＯＮＡＬ」から「ＳＴＲＥＡＭＩＮＧ」に変更されると、この変更により、そのビデオストリームを受信するモバイル端末又はサーバに問題が発生することになろう。具体的には、この変更により、ＰＤＰコンテキストの再ネゴシエーションが発生することになろう、そしてこの場合には、トラフィッククラスが異なるのみならず、転送遅延も異なる。この結果、相対的に大きな転送遅延により、受信側のモバイル端末において、頻繁なかつ繰返しのバッファアンダーフローを生じることになり、不連続なメディアの結果として、エンドユーザが知覚する品質が低下することになろう。この理由は、モバイル端末又はサーバのバッファが、「ＳＴＲＥＡＭＩＮＧ」トラフィッククラスの転送遅延にではなく、「ＣＯＮＶＥＲＳＡＴＩＯＮＡＬ」トラフィッククラスの転送遅延に応じて、その大きさが決められるためである。

また、双方向（例えばオーディオ）ストリームを有する既存のセッションに単方向（例えば、ビデオ）ストリームが追加された場合には、更に大きな問題が発生する可能性がある。単方向ビデオストリームのシグナリングされたトラフィッククラスは、典型的には、ストリーミングであるのに対して、双方向セッションのトラフィッククラスは、会話型である。これらのメディアストリームが、時間的な関係を具備している場合には（例えばオーディオストリームにおけるビデオストリームの口頭説明）、トラフィッククラスの違いによって伝送遅延の差が生じ（これは、伝送における遅延及び遅延ジッタの差を補償するための受信機におけるバッファ長の差に起因するものである）、この結果、エンドユーザが知覚する接続品質が低下することになる。

例えば、セッション（接続）が、単方向フローによって開始されたとしよう。この時点で、ＰＤＦ２２２は、最大認可トラフィッククラスとして、「ＳＴＲＥＡＭＩＮＧ」を割り当てることになる。そして、時間の経過に伴って、この通信に対して、双方向音声呼フローが追加される。この時点で、ＰＤＦ２２２は、この音声フローに対して「ＣＯＮＶＥＲＳＡＴＩＯＮＡＬ」に等しい最大認可トラフィッククラスを割り当てる。また、ＰＤＦ２２２は、第１の既存のストリームの最大認可トラフィッククラスをチェックし、これを「ＣＯＮＶＥＲＳＡＴＩＯＮＡＬ」にアップグレードする。いくつかのケースにおいては特に、ＩＰマルチメディアストリームが関係しており、同期化を必要としている場合には、このアップグレードにより、ＩＰマルチメディアフローのＰＤＰコンテキストの再ネゴシエーションがトリガされることになろう。しかし、大部分のケースにおいては、アップグレードは不要である。

次に、図３を見てみると、本発明の実施例によるＩＭＳ機能エンティティのインターフェイスアーキテクチャの例が示されている。この図３に示されているインターフェイスアーキテクチャは、好都合なことに、トラフィッククラスが変更された際に発生する問題を回避するべく、最上位トラフィッククラスを必要とするメディアストリームがセッションから除去される場合に、そのセッションに使用されているトラフィッククラスを、即ち、ＩＰマルチメディアストリームの残りのものについて維持すると共に、既存のセッションにメディアストリームが追加された際に発生する問題を回避するべく、そのセッションのメディアストリームのいずれかに割り当てられている最上位（リアルタイム、即ち、会話型、ストリーミング）トラフィッククラスを、そのセッションの存続期間にわたって、そのセッションのすべての（リアルタイム）メディアストリームに割り当てる。

図３に示されているように、アルゴリズム３１０は、ＰＤＦ２２２が、Ｐ−ＣＳＣＦ２２０内に一体化されるか、或いは、Ｐ−ＣＳＣＦ２２０とは別個のネットワークエンティティのままであるかとは無関係に、ＰＤＦ２２２の一部として実装可能である。このアルゴリズム３１０においては、セッション（接続）の存続期間中における１つ又は複数のマルチメディアフローの除去を、以前に割り当てられた最大認可トラフィッククラスをダウングレードしないように、規定することが可能であり、同様に、メディアフローの追加に関しても、そのセッション（接続）のすべての（リアルタイム）フローに対して、それらのフローの最大トラフィッククラスを割り当てるべく、規定することができる。このアルゴリズム３１０の使用は、１つのセッションが複数の異なるタイプのメディアストリームを有することが可能であると共に、例えば、３ＧＰＰ ＴＳ ２３．２０７、Ｖ５．６．０（２００２年１２月）「エンドツーエンドサービス品質（ＱｏＳ）の概念及びアーキテクチャ」、第５版、及び３ＧＰＰ ＴＳ ２９．２０８、Ｖ５．２．０（２００２年１２月）「エンドツーエンドサービス品質（ＱｏＳ）のシグナリングフロー」、第５版、に従っている将来のあらゆるマルチメディアネットワークを含むすべてのシステムに適用することができる。

同一セッションに属するメディアストリームの伝送遅延の差を除去することにより、リアルタイムメディアストリームの同期化を改善することも可能であり、この結果、エンドユーザが知覚する品質が改善される。セッション内のいくつかのメディアストリームに割り当てられたＱｏＳクラスが、必要なレベルを上回る可能性があり、この結果、ネットワークの全体としての容量が低下すると共に、潜在的にエンドユーザの接続コストが上昇するという欠点が存在し得る。

例えば、ユーザ／ＵＥが、１つ又は複数の単方向ストリーミングフローにより、セッションを開始したり、相対的に下位のトラフィッククラスフローを有するセッションを拡張したとしよう。この時点で、ＰＤＦ２２２は、最大認可トラフィッククラスとして、その関連するメディアフローに対して、「ＳＴＲＥＡＭＩＮＧ」を割り当てる。その後、このセッションの存続期間中に、ユーザ／ＵＥが、この同一のセッション内において、双方向（例えばオーディオ）フローを開始する。この時点において、ＰＤＦ２２２は、このオーディオフローに対して、「ＣＯＮＶＥＲＳＡＴＩＯＮＡＬ」に等しい最大認可トラフィッククラスを割り当てる。また、ＰＤＦ２２２は、１つ又は複数の既存のストリームの最大認可トラフィッククラスを再チェックする。単方向ストリーミングフローは、双方向会話型フローの以前に既に開始されていたものであり、従って、これは、恐らく、双方向会話型フローと時間的な関係を具備しておらず、既存のメディアフローを新しい双方向フローのトラフィッククラス値にアップグレードすることは不要であろう。セッション内のいくつかのメディアストリームに割り当てられたＱｏＳクラスが、必要なレベルを上回る可能性があり、この結果、ネットワークの全体的な容量が低下すると共に、潜在的にエンドユーザの接続コストが上昇するため、このようなアップグレードは望ましくない。

しかしながら、まず、１つ又は複数の単方向ストリーミングフローが始まり、これが、後の１つ又は複数の双方向フローとは独立していると見なされる場合には、即ち、時間的な関係が存在していない場合には、アップグレードを回避することができる。この場合には、双方向会話型メディアストリームが追加された場合に、同期化は不要である、即ち、トラフィッククラスは、「ＳＴＲＥＡＭＩＮＧ」に留まることになる。ＩＭＳシステム内において、異なるトラフィック／ＱｏＳクラスを有するフローは、別個のＰＤＰコンテキストを使用することになる）。或いは、この代わりに、双方向会話型フローが、まず始まり、このセッションに、後から単方向ストリーミングフローが追加された場合には、この単方向ストリーミングフローは、その双方向フローに依存していると考えられる、即ち、これらの間には、時間的な関係が存在している。この場合には、同期化が必要であり、即ち、単方向ストリーミングフローのトラフィッククラスが、双方向フローのトラフィッククラスと同一の値、即ち、「ＣＯＮＶＥＲＳＡＴＩＯＮＡＬ」）に、設定される（ＰＤＦ２２２によって）ことになる。（ＩＭＳシステム内において、異なるトラフィック／ＱｏＳクラスを有するフローは、共通のＰＤＰコンテキスト又は別個のＰＤＰコンテキストを使用可能である）。

図３に示されているように、ＰＤＦ２２２は、２つのユーザ又はモバイル端末間或いはモバイル端末とサーバ間における接続の所定のメディアフローの最大認可トラフィッククラスを判定するべく構成可能である。このＰＤＦ２２２内のアルゴリズム３１０の例には、次の内容を含むことができる。

（Ｉｆ）所定のフローＸに対して最大認可トラフィッククラスが既に割り当てられるなら、（ｔｈｅｎ）セッション（接続）の存続期間中１つ又は複数のメディアフローの追加又は除去により、フローＸの以前に割り当てられている最大認可トラフィッククラスは変化しない。

また、マッピング規則は、適切な最大認可ＱｏＳクラスをストリーミングサービスに割り当てることができるように、３ＧＰＰ ＴＳ ２９．２０８、Ｖ５．２．０（２００２年１２月）「エンドツーエンドサービス品質（ＱｏＳ）のシグナリングフロー」、第５版、に従う必要がある。図３に示されているように、ＰＤＦ２２２は、セッションが起動又は修正される場合に、このマッピング規則を利用することにより、メディアコンポーネントごとに適切な最大認可ＱｏＳを取得可能である。しかしながら、将来のサービスを制限することなく、且つ、誤用、不正行為、及び非効率を回避できることを確実にするように、正しいマッピングを規定することが必要である。一般に、ストリーミングサービスは、データフローの方向と（単方向である）、メディアのタイプ（オーディオ又はビデオである）と、によって特徴付け可能である。この結果、１つのセッションに属しているすべてのメディアコンポーネントを分析することができる。例えば、すべてのオーディオ及びビデオメディアコンポーネントが単方向であって、同一方向を具備している場合には、そのアプリケーションは、ストリーミングと見なすことが可能であり、この結果、ストリーミング用のＱｏＳ限度を最大認可ＱｏＳとして適用することができる。

次に、図４〜図７を参照すれば、マッピング規則の例が示されている。例えば、図４は、本発明の一実施例によるメディアストリームが単方向であって同一の方向を具備している場合の２つのユーザ装置（モバイル端末）間において稼働するセッションの例を示している。図５は、本発明の一実施例によるメディアストリームが単方向であって同一の方向を具備していない場合の２つのユーザ装置（モバイル端末）間において稼働するセッションの例を示している。図６は、本発明の一実施例による１つのメディアストリームが双方向であって、もう１つのメディアストリームが単方向である場合の２つのユーザ装置（モバイル端末）間において稼働するセッションの例を示している。最後に、図７は、本発明の一実施例による１つのメディアストリームが双方向（非オーディオ／ビデオ）であって、もう１つのメディアストリームが単方向（オーディオ／ビデオ）である場合の２つのユーザ装置（モバイル端末）間において稼働するセッションの例を示している。

具体的には、図４においては、メディアストリーム（オーディオ及びビデオ）が、単方向であって、同一の方向を具備している場合には、メディアフロー認可は、「ＳＴＲＥＡＭＩＮＧ」となる。図５においては、メディアストリームが、単方向であって、同一の方向を具備していない場合には、メディアフロー認可は、「ＣＯＮＶＥＲＳＡＴＩＯＮＡＬ」となる。図６においては、１つのメディアストリームが双方向であり、もう１つのメディアストリームが単方向である場合には、メディアフロー認可は、「ＣＯＮＶＥＲＳＡＴＩＯＮＡＬ」となる。図７においては、１つのメディアストリームが双方向（非オーディオ／ビデオ）であって、もう１つのメディアストリームが単方向（オーディオ／ビデオ）である場合には、メディアフロー認可は、アプリケーションに対しては、「ＣＯＮＶＥＲＳＡＴＩＯＮＡＬ」であり、ビデオに対しては、「ＳＴＲＥＡＭＩＮＧ」となろう。

マッピング規則を拡張することにより、必要なサービスに応じて、最大認可ＱｏＳクラスの正しい割り当てを確実なものとすることができる。ＳＤＰパラメータの最大認可ＱｏＳに対するマッピングを規定する規則を拡張することにより、例えば、同一方向を具備する「オーディオ」又は「ビデオ」タイプの単方向メディアコンポーネントの場合におけるストリーミングクラスに対するマッピングが可能になる。以下は、図２及び図３に示されているように、ＵＥ１１０（例えばモバイル端末又はサーバ）及びＰＤＦ２２２が利用可能なマッピング規則の例である。具体的には、表＃１は、ＰＤＦ２２２内においてメディアコンポーネントごとに最大認可データレートと最大認可サービス品質（ＱｏＳ）クラスを導出するマッピング規則の例を示している。このようなマッピング規則の例は、コンピュータ可読媒体上に保存又は、提供されるソフトウェアモジュールとしてパッケージ化可能であり、或いは、インターネットからのダウンロードによって提供したり、又は、図２及び図３に示されているように、ＰＤＦ２２２内に一体化することも可能である。この表＃１と関連し、表＃２は、ＵＥ１１０（例えばモバイル端末又はサーバ）内においてメディアコンポーネントごとに最大認可帯域幅と最大認可トラフィッククラスを導出するマッピング規則の例を示している。同様に、このようなマッピング規則も、コンピュータ可読媒体上に保存又は、提供されるソフトウェアモジュールとしてパッケージ化可能であり、或いは、インターネットからダウンロードによって提供したり、又は、図２及び図３に示されているように、ＵＥ１１０（例えばモバイル端末又はサーバ）内に一体化可能である。

ＰＤＦ２２２は、継続中のセッションごとに、メディアコンポーネントごとに認可ＩＰ ＱｏＳパラメータを保存する。ＧＧＳＮ２１０が、１つ又は複数のメディアコンポーネントを搬送する起動／修正されたＰＤＰコンテキストの認可ＵＭＴＳ ＱｏＳパラメータを要求した場合には、ＰＤＦ２２２は、認可ＩＰ ＱｏＳパラメータを算出するように、例えば、表＃１に示されているマッピング規則を使用することができる。

ＵＥ１１０は、継続中のセッションごとに、メディアコンポーネントごとに認可ＵＭＴＳ ＱｏＳパラメータを保存する。ＰＤＰコンテキストを起動又は修正する前に、ＵＥ１１０は、要求された保証ビットレートＵＬ／ＤＬ（トラフィッククラスが会話型又はストリーミングである場合）又は要求された最大ビットレートＵＬ／ＤＬ（トラフィッククラスが双方向型又は背景である場合）が、（マッピング規則に従って算出された）ＰＤＰコンテキストごとの最大認可帯域幅ＵＬ／ＤＬを超過していないことをチェック可能である。さらに、ＵＥ１１０は、要求されたＵＭＴＳ ＱｏＳパラメータトラフィッククラスが、（マッピング規則に従って算出された）ＰＤＰコンテキストごとの最大認可トラフィッククラスを超過しないようにチェックすることが可能である。

前述のように、本発明の一実施例によるネットワークインターフェイスアーキテクチャは、モバイルネットワーク内における複数の異なるタイプのメディアストリームを有するセッション（ユーザ又はモバイル端末間又はモバイル端末とサーバ間における接続）の動的なメディア認可とＱｏＳクラスの良好な管理のための解決策を提供し、この結果、同一のセッションに属するメディアストリームの伝送遅延の差を除去するべく、そのセッション期間中に複数の異なるタイプのメディアストリームの中の１つ又はいくつかのメディアストリームが修正される場合に（新しいものが起動され、既存のものが削除される場合）、セッションのトラフィッククラスが、その同一のセッションに属するメディアフローによる最上位のトラフィッククラスの要求によって規定され、これにより、エンドユーザが知覚する接続品質が改善されることになる。また、同一のセッションに属するメディアストリームの伝送遅延の差を除去することにより、リアルタイムメディアストリームの同期化を改善することも可能であり、この結果、エンドユーザが知覚する品質が改善される。

本発明の実施例と考えられるものについて図示並びに説明してきたが、当業者であれば、本発明の範囲を逸脱することなしに、様々な変更又は修正を加えることが可能であり、その要素を等価物によって置換可能であることを理解できるであろう。さらに、本発明の主要な範囲を逸脱することなしに、多くの変更を加えることによって特定の状況を本発明の教示内容に適合させることも可能である。従って、本発明は、本発明を実施するための最良の形態として開示された特定の実施例に限定されるものではなく、本発明には、添付の請求項の範囲内に属するすべての実施例が含まれている。

３ＧＰＰ仕様書の第５版によるＩＰマルチメディアサービスを含む通信サービスを提供するネットワークシステムアーキテクチャの例を示す図である。 ３ＧＰＰ仕様書の第５版によるＩＭＳ機能エンティティのインターフェイスアーキテクチャの例を示す図である。 本発明の実施例によるＩＭＳ機能エンティティのインターフェイスアーキテクチャの例を示す図である。 本発明の実施例による、メディアストリームが単方向であって、同一方向を具備している場合に、新しいマッピング規則を使用して２つのユーザ装置（モバイル端末）間又はモバイル端末とサーバ間において動作するセッションの例を示す図である。 本発明の実施例による、メディアストリームが単方向であるが、同一方向を具備していない場合に、新しいマッピング規則を使用して２つのユーザ装置（モバイル端末）間又はモバイル端末とサーバ間において動作するセッションの例を示す図である。 本発明の実施例による、１つのメディアストリームが双方向であって、もう１つののメディアストリームが単方向である場合に、新しいマッピング規則を使用して２つのユーザ装置（モバイル端末）間又はモバイル端末とサーバ間において動作するセッションの例を示す図である。 本発明の実施例による、１つのメディアストリームが双方向（非オーディオ／ビデオ）であって、もう１つのメディアストリームが単方向（オーディオ／ビデオ）である場合に、新しいマッピング規則を使用して２つのユーザ装置（モバイル端末）間又はモバイル端末とサーバ間において動作するセッションの例を示す図である。

Claims (4)

1. ２つのモバイル端末間又はモバイル端末とサーバ間におけるセッションの所定のメディアフローの最大認可トラフィッククラスを決定するためにモバイルネットワーク内に実装されたポリシー決定機能（ＰＤＦ）であって、
   確立された前記セッションが通信リンクを介して２つのモバイル端末間又はモバイル端末とサーバ間において修正される場合に、複数のメディアストリームの中の最上位のトラフィッククラスを必要としているメディアストリームが、セッションから除去されるかどうかを判定する段階と、
   前記最上位のトラフィッククラスを必要としている前記メディアストリームが、前記セッションから除去される場合に、該セッションの残りのメディアストリームの既存のトラフィッククラスを維持する段階と、
   を有するポリシー決定機能（ＰＤＦ）。
2. ２つのモバイル端末間又はモバイル端末とサーバ間におけるセッションの所定のメディアフローの最大認可トラフィッククラスを決定するためにモバイルネットワーク内に実装されたポリシー決定機能（ＰＤＦ）であって、
   前記セッションが通信リンクを介して２つのモバイル端末間又はモバイル端末とサーバ間において確立又は修正される場合に、双方向ストリームを有するセッションに単方向ストリームが追加されるかどうかを判定する段階と、
   前記双方向ストリームを有する前記セッションに前記単方向ストリームが追加される場合に、該セッションのメディアストリームのいずれかに割り当てられた最上位のトラフィッククラスを、該セッションの存続期間中において、該セッションのすべてのメディアストリームに適用する段階と、
   を有するポリシー決定機能（ＰＤＦ）。
3. ＩＰマルチメディアサービス用のＩＰマルチメディアサブシステム（ＩＭＳ）アーキテクチャであって、
   モバイル端末と、
   セッション期間中に、前記モバイル端末との間のパケット伝送を処理するべく構成されたゲートウェイサポートノード（ＧＧＳＮ）と、
   前記モバイル端末の第１コンタクトポイントとしての役目を果し、ＩＭＳ関連シグナリングのパケットデータプロトコル（ＰＤＰ）コンテキストの確立、登録、及び前記セッションのその他の手順を含むセッション管理サービスを前記セッション期間中に提供するべく構成されているプロキシ−呼セッション制御機能（Ｐ−ＣＳＣＦ）と、
   を備え、
   前記Ｐ−ＣＳＣＦは、
   確立された前記セッションが通信リンクを介して２つのモバイル端末間又はモバイル端末とサーバ間において修正されている場合に、複数のメディアストリームの中の最上位のトラフィッククラスを必要としているメディアストリームが該セッションから除去されるかどうかを判定する段階と、
   前記最上位のトラフィッククラスを必要とする前記メディアストリームが前記セッションから除去される場合に、該セッションの残りのメディアストリームに使用されたトラフィッククラスを維持する段階と、
   を実行するように構成されているポリシー決定機能（ＰＤＦ）を備えるＩＰマルチメディアサブシステム（ＩＭＳ）アーキテクチャ。
4. モバイルネットワークによって実行される際に、２つのモバイル端末間又はモバイル端末とサーバ間におけるセッションの所定のメディアフローの最大認可トラフィッククラスを決定する方法を実行する命令を有するコンピュータ可読媒体であって、
   前記方法は、
   前記セッションが通信リンクを介して２つのモバイル端末間又はモバイル端末とサーバ間において確立又は修正される場合に、双方向ストリームを有するセッションに単方向ストリームが追加されるかどうかを判定する段階と、
   前記双方向ストリームを有する前記セッションに前記単方向ストリームが追加される場合に、該セッションのメディアストリームのいずれかに割り当てられた最上位のトラフィッククラスを、該セッションの存続期間中に、該セッションのすべてのメディアストリームに適用する段階と、
   を有するコンピュータ可読媒体。

Images