JP2009505609A - マルチメディア用通信セッションの確立方法及び装置 - Google Patents

Abstract

別のパーティ（Ｂ）と通信する移動端末（Ａ）に対するパケット交換マルチメディアセッションを確立する方法及び装置が提供される。ここで、プライマリＰＤＰ（パケットデータプロトコル）コンテキストは、移動端末に対する移動ネットワークでアクティベートされている。来るべきセッションにおける情報が受信され（ステップ５：３）、これは、通信するパーティ間でネゴシエートされ、かつ同意されている。次に、要求されるＱｏＳを提供するネットワークリソースが、移動ネットワークにおけるセッションに対して必要とされているかが判定され、また、セカンダリＰＤＰコンテキストが、移動端末と来たるべきセッションに対してアクティベートされるべきかが判定される（ステップ５：４）。ネットワークリソースが必要とされ、かつセカンダリＰＤＰコンテキストがアクティベートされるべきである場合、セカンダリＰＤＰコンテキストのアクティベーションがトリガーされる（ステップ５：５）。
【選択図】 なし

Description

技術分野
本発明は、一般的には、移動端末を介在して、マルチメディア用通信セッションを確立するための方法及び装置に関するものである。

本発明の背景及び従来技術
第３世代移動テレフォニーの出現に伴い、マルチメディア通信をサポートするために、新規のパケットベースの通信技術が開発されている。例えば、ＧＰＲＳ（汎用パケット無線サービス）とＷＣＤＭＡ（広帯域符号分割多元アクセス）技術は、伝統的な回線交換音声呼に加えて、画像、テキスト、文書、アニメーション、音声ファイル、ビデオファイル等を表現するデータのパケット交換通信を介在する無線マルチメディアテレフォニーサービスをサポートする。

マルチメディアサービスは、典型的には、異なるフォーマットかつ組み合わせで、テキスト、文書、画像、音声ファイル及びビデオファイルを表現する符号化データの送信を伴っている。この用語「マルチメディア」は、一般的には、パケットベースのＩＰ（インターネットプロトコル）トランスポート技術を使用することによって通信される任意のメディアを参照する表現として使用される。

「ＩＰマルチメディアサブシステム」（ＩＭＳ）と呼ばれるネットワークアーキテクチャは、パケットドメインでのマルチメディアサービス及びセッションを処理するためのオープンスタンダードとして、第３世代パートナシッププロジェクト（３ＧＰＰ）によって開発されている。ＩＭＳは、ＩＰトランスポートに基づくサービスを可能にするためのプラットホームであり、多かれ少なかれ、使用されるアクセス技術とは独立していて、また、任意の専用サービスに制限されるものではない。つまり、ＩＭＳネットワークはマルチメディアセッションを制御するが、アクセスネットワーク及び任意の中間トランスポートネットワークを介して転送されるペイロードデータの実際の転送に対して使用されることはない。

図１は、ＩＭＳサービスネットワークによって、マルチメディアサービスを提供するための基本ネットワーク構造を示している。第１移動端末Ａは、第１無線アクセスネットワーク１００に接続されていて、１つ以上のマルチメディアサービスを介在する通信セッションＳで、第２無線アクセスネットワーク１０２に接続される第２移動端末Ｂと通信する。この第１無線アクセスネットワーク１００及び第２無線アクセスネットワーク１０２にリンクしている、不図示の中間バックボーンネットワークが存在していても良い。

ＩＭＳネットワーク１０４は第１無線アクセスネットワーク１００に接続されていて、また、第１移動端末Ａに関するセッションを処理する。この図では、対応するＩＭＳネットワーク１０６は、第２移動端末Ｂに代ってセッションを処理し、２つのＩＭＳネットワーク１０４及び１０６は、異なるオペレータによって制御されていても良い。選択的には、第１移動端末Ａと第２移動端末Ｂは、同一のアクセスネットワークに接続されていても良く、及び／あるいは、同一のＩＭＳネットワークに属していても良い。第１移動端末Ａは、更に、他のパーティがＳＩＰ通信が可能である限り、例えば、インターネットを介していくつかのメディアをダウンロードするために、固定端末あるいはコンピュータ、これに代るサーバと通信することができる。また、端末が訪問先アクセスネットワークにローミングしている場合、マルチメディアサービスは、端末の「ホーム」ＩＭＳネットワークによって処理される。

図１に示されるセッションＳは、各ＩＭＳネットワークの専用ノード、ここでは、一般的には、「セッション管理ノード」１０８として参照される専用ノードによって管理される。これらのノードは、典型的には、Ｓ−ＣＳＣＦ（Serving Call Session Control Function：在圏呼セッション制御機能）、Ｉ−ＣＳＣＦ（Interrogating Call Session Control Function：尋問呼セッション制御機能）及びＰ−ＣＳＣＦ（Proxy Call Session Control Function：プロキシ呼セッション制御機能）を含んでいる。各ＩＭＳネットワーク１０４、１０６は、更に、様々なマルチメディアサービスを可能にするための１つ以上のアプリケーションサーバ１１０を含んでいる。また、メインデータベース要素ＨＳＳ（ホーム加入者サーバ）１１２は、加入者データ及び認証データに加えて、サービス情報を記憶している。この図示のネットワーク要素１０８−１１２の様々な専用の機能は、一般的には、従来より知られているものであるので、更に、本発明の内容を理解するために説明する必要はない。もちろん、ＩＭＳネットワーク１０４、１０６は、説明を簡単にするために図示はしていないが、いくつかの他のノード及び機能を含んでいる。

ＩＭＳネットワークにおけるセッションを処理するための仕様は、いわゆる「ＳＩＰ」（セッション開始プロトコル、規格ＩＥＴＦ ＲＦＣ３２６１に従う）で定義されている。ＳＩＰは、シグナリング用のアプリケーションレイヤ制御プロトコルであり、これは、パケット交換ロジックを介して一般的なセッションを生成して処理する。ＳＩＰ規格は、ＩＭＳシステムとＳＩＰを実現可能な端末によって使用され、ＩＰマルチメディア通信を確立し、制御する。ＳＩＰ自身は、マルチメディアサービスを提供しない代わりに、他のプロトコルあるいはアプリケーションが、実際のそのようなサービスを実現するために使用することができるプリミティブのセットを利用可能にする。

例えば、「ＩＮＶＩＴＥ」と呼ばれるメッセージは、あるアプリケーションが起動されている場合のセッションセットアップ中に、マルチメディアセッションを開始するためにＳＩＰで定義されている。このＳＩＰのＩＮＶＩＴＥメッセージは、典型的には、セッションの記述、即ち、要求されるコーデック（群）における情報、及び来るべきセッションに対して必要とされる他の通信パラメータを含んでいる。

ＳＩＰは、マルチメディアセッションを記述するための追加のプロトコルである、セッション記述プロトコルと呼ばれるＳＤＰを使用する。これは、ＳＩＰメッセージ内で内蔵される本体として組み込まれる。従来より良く知られているように、ＳＤＰは、来るべきマルチメディアセッション中に使用するために、どのセッションパラメータ、特に、コーデックのパラメータでネゴシエートして同意するために、自身の専用の機能及びプリファレンスに関する情報を交換するための端末によって使用することができる。好ましいあるいは要求されるセッションパラメータは、ＳＤＰ情報中の「前提条件」として示される属性として示されても良い。

多くの移動アプリケーションは、満足な結果をエンドユーザに提供するために、サービスの品質であるＱｏＳを要求する。ＵＭＴＳネットワークに対しては、ビットレート及び遅延に関して異なる要件に分類するために、４つの主要なトラフィッククラスが定義されていて、これは、「会話クラス」、「ストリーミングクラス」、「インタラクティブクラス」及び「バックグランドクラス」である。これらのトラフィッククラスは、まずは、転送遅延に関するそれらの要件によって区別され、そうすることで、会話クラスのアプリケーションは、時には「リアルタイム」とも呼ばれる、わずかな遅延だけを容認し、一方で、バックグランドクラスは、時には「ベストエフォート」とも呼ばれる、最も遅延に敏感でないアプリケーションに適用される。

アプリケーションに対する、ＵＭＴＳトラフィッククラスの選択は、エンドユーザに対して許容される品質を維持しながら、アクセスネットワーク内の乏しい無線リソースを最適化するために、一般的には、ＲＡＢ（無線アクセスベアラ）と呼ばれる、アクセスネットワークの適切な物理チャネルを割り当てるために使用される。

マルチメディアが可能な移動端末は、典型的には、図２に示されるように、各固有のアプリケーションに対して、ＵＭＴＳトラフィッククラスを識別するように構成されている。つまり、移動端末は、Ａ１、Ａ２、Ａ３、Ａ４、Ａ５．．．で示されるように、いくつかのアプリケーション２００を保持することができる。移動端末のマッピング機能２０２は、各アプリケーションをＵＭＴＳトラフィッククラス２０４に変換し、ここでは、２つだけ示されている。この場合、アプリケーションＡ１、Ａ２及びＡ４は、同一のＵＭＴＳトラフィッククラス２にマッピングされる。これは、それらが、ビットレート及び遅延に関して同様の要件を有しているからである。一方で、アプリケーションＡ３及びＡ５は、ＵＭＴＳトラフィッククラス１にマッピングされる。このように、同様の特徴を有するアプリケーションは、それらの要件を満足する、同一のＲＡＢにマッピングすることができる。

しかしながら、移動端末がＩＭＳネットワークとＳＩＰメッセージを交換できる前には、「ＰＤＰ（パケットデータプロトコル）コンテキスト（context）」が、移動端末に対して確立されていなければならない。基本的には、ＰＤＰコンテキストは、移動端末が一旦電源が入ると起動され得る。移動端末に対するＰＤＰコンテキストをアクティベートすることは、移動端末とのデータパケットを通信することを可能にするための、移動端末への一時的なＩＰアドレスの割当を含んでいる。また、ＰＤＰコンテキストは、ＩＰ通信に対して、一般的にはＲＡＢ（無線アクセスベアラ）と呼ばれる物理チャネルがアクセスネットワークに割り当てられていることを意味する。つまり、ＳＩＰメッセージは、ＰＤＰコンテキストを介してのみ送信することができる。

図３は、別のパーティＢとのマルチメディア通信についての移動端末Ａの段階的なアクティベーション（activation）を示していて、これは、図示されるように、基本的には５つの段階３：１−３：５を含んでいて、それぞれの段階では、様々なメッセージが送受信される。これらのメッセージは従来よりよく知られており、詳細には説明しない。移動端末Ａは、移動アクセスネットワーク３００の無線範囲に配置されていて、この無線アクセスネットワーク３００は、無線ネットワーク部分３００ａとコアネットワーク部分３００ｂに分けられる。

図３に示されるコアネットワーク３００ｂは、ＧＧＳＮ（ゲートウェイＧＰＲＳ交換ノード）３０４と「ポリシーユニット」３０６とを含んでいて、この「ポリシーユニット」３０６は、通常は、ＰＤＦ（ポリシー決定機能）あるいはＰＣＲＦ（ポリシー及び課金ルール機能）と呼ばれる。このポリシーユニットは、基本的には、通信セッションの認可を担当する。もちろん、移動アクセスネットワーク３００は、本発明のコンテキストを理解するためには説明する必要のない、いくつかの他のノード及び要素を含んでいる。簡単のために、移動端末ＡのＩＭＳネットワークは、ここでは、単に、「ＩＭＳコア」３０８で示すことにする。これは、後述の処理に関与する、不図示の様々なノードを含んでいる。

第１段階３：１では、「プライマリ」と呼ばれる基本ＰＤＰコンテキストが、ＩＰ接続を取得するためにアクティベートされる。プライマリＰＤＰコンテキストをアクティベートすることには、ＩＰを介するパケット交換ＳＩＰシグナリングメッセージに対する、ＲＡＢを取得することを含んでいる。このＰＤＰコンテキストは、ＧＧＳＮ３０４によって生成される。このＲＡＢは、典型的には、ビットレート及び遅延に関して特に要件がない、いわゆる「ベストエフォート」通信に基づいている。これは、制限されたＳＩＰメッセージを時々搬送するためだけに意図されているからである。

次の段階３：２では、移動端末Ａは、不図示のＳ−ＣＳＣＦノード及びＨＳＳによって基本的には処理されるように、ＩＭＳコア３０８に登録する。ＩＭＳ登録には、プライマリＰＤＰコンテキストを介する、ある程度のＳＩＰベースのシグナリングを含んでいる。

次に、マルチメディアセッションは、続く段階３：３で、パーティＢと確立されることである。この段階では、上述のプロトコルＰＤＰが、コーデックを含むセッション専用パラメータを通信するために、ＩＮＶＩＴＥのようなＳＩＰメッセージ内で使用され、ここで、いくつかのパラメータは、前提条件として示されても良い。

典型的には、呼出側（calling）端末は、ＩＮＶＩＴＥメッセージで特定されるような、セッション中に使用するための他のパラメータと一緒に１つ以上のコーデックを提案し、被呼出側（called）端末は、適切な提案されるコーデックと他の提案されるパラメータを確認することによって、「ＯＫ（ｉｎｖｉｔｅ）」メッセージで応答する。段階３：３では、更に、セッションデータと記憶されている加入者データに基づく、ポリシーユニット３０６内のセッションの認可を含んでいる。段階３：３は、更に、自身のＳＩＰダイアログにおいて両パーティで確認されているパラメータに従って、パーティＢとの来るべきセッションに適応する移動ネットワーク３００の通信リソースを予約するための処理を含んでいる。

セッション確立とリソース予約は、段階３：４で示されるように、移動端末Ａに対してセカンダリＰＤＰコンテキストがアクティベートされることを伴う。これは、来るべきセッションに関与するメディアタイプ（群）に適応していなければならない。以下のＱｏＳパラメータは、セカンダリＰＤＰコンテキストで示されていても良い。これは、トラフィッククラス、最大ビットレート（アップリンク／ダウンリンク）、保証ビットレート（アップリンク／ダウンリンク）、転送遅延（アップリンク／ダウンリンク）、配信順序、最大ＳＤＵ（サービスデータユニット）サイズ及びソース統計値記述子がある。

セカンダリＰＤＰコンテキストは、段階３：１におけるプライマリＰＤＰコンテキストに対する方法と同様の方法で、ＧＧＳＮによって処理される。つまり、セカンダリＰＤＰコンテキストは、ＱｏＳパラメータ情報と他の要素に関する、セッションの要件を満足するように定義されるべきであり、そうすることで、通信対象のメディアに対する適切なＲＡＢを取得する。新規のＲＡＢは、プライマリＰＤＰコンテキストで最初に関与するものと比べて、より安定し、かつ信頼性のあるものであり、これは、「保証」ＱｏＳを提供する。

セカンダリＰＤＰコンテキストが最終的に確立されると、そのセカンダリＰＤＰコンテキストを介して、段階３：６で示されるように、最終的な実際のセッションを開始する前に、セッションは応答確認されなければならず、また、予約されているリソースがアクティベートされなければならない。ネットワークリソースをアクティベートすることは、時には、「ゲートのオープン」と呼ばれる。

段階３：１−３：５で示される、セッションの確立、ネットワークリソースの予約、セカンダリＰＤＰコンテキストのアクティベート及び予約されたリソースのアクティベートのプロセスは、標準化プロトコルで指示される、膨大な量の連続的なシグナリングを必要とする。また、少なくとも他のパーティも移動端末である場合は、同様の処理が、他のパーティに対しても行わなければならない。特に、段階３：３は、送受信側の両方で同時に実行することはできない。これは、この場合、普及している規格に従えば、Ｂ側に対するセッションパラメータを確認する前には、Ｂ側は、ネットワークリソースを予約することになるからである。つまり、Ａ側でのネットワークリソースの予約は、確認されるセッションパラメータがＢ側から受信されるまで待機しなければならない。

つまり、メディアの通信は、マルチメディアセッションに対する従来のセットアップ処理に従って要求される大規模な連続的なシグナリングによって遅延する。移動通信の分野では、マルチメディアサービスを移動エンドユーザにより魅力あるものにするためには、このような遅延を最小化することが一般的には要望されている。例えば、ウォーキートーキーサービスをエミュレートする、「セルラーオーバプッシュツートーク（ＰｏＣ：Push-to-talk over Cellular）」と呼ばれるサービスを使用する場合は、ユーザは、プッシュツートークボタンあるいはその類を押下した後、直ちに会話したいが、これは、基本的には、上述の段階３：３−３：５のプロセス全体をトリガーする。

また、ネットワークリソースの予約は、移動端末によって開始され、それゆえ、ネットワークオペレータに対して部分的に制御が不能となる。つまり、一般的には、ネットワークオペレータにとっては、異なるユーザへのネットワークリソースの割当の完全な制御を行うことが要望されている。

本発明の要約
本発明の目的は、一般に、上述の問題を回避あるいは少なくとも軽減することを可能にすることである。より詳しくは、本発明の目的は、移動端末がメディア通信を開始する前の遅延を削減し、かつネットワークオペレータにネットワークリソースを介する制御を行うことを可能にすることである。

これらの目的及び他の目的は、添付の独立請求項に従う方法及び装置を提供することによって達成される。

本発明の１つの構成に従えば、別のパーティと通信する移動端末に対するパケット交換マルチメディアセッションを確立する方法が提供される。ここで、プライマリＰＤＰ（パケットデータプロトコル）コンテキストは、移動端末に対する移動ネットワークでアクティベートされている。本発明の方法は、移動ネットワークで実行することができる。来るべきセッションにおける情報が受信され、これは、通信するパーティ間でネゴシエートされ、かつ同意されている。次に、要求されるＱｏＳを提供するネットワークリソースが、移動ネットワークにおけるセッションに対して必要とされているかが判定される。また、セカンダリＰＤＰコンテキストが、移動端末と来たるべきセッションに対してアクティベートされるべきかが判定される。ネットワークリソースが必要とされ、かつセカンダリＰＤＰコンテキストがアクティベートされるべきである場合、セカンダリＰＤＰコンテキストのアクティベーションがトリガーされる。

セッションにおける情報は、呼出側パーティからのセッション招待に対する被呼出側パーティからの応答に含まれていても良く、この応答は、セッション招待で提案されるセッションパラメータを効果的に確認するものである。セッションにおける情報は、応答で与えられるＳＤＰ（セッション記述プロトコル）から導出することができる。

受信されるＳＤＰ内のメディアフラグの存在と、ＳＤＰ自身におけるセッションの記述は、要求されるＱｏＳを提供するネットワークリソースがセッションに対して必要とされるかを判定するために使用することができ、そうすることで、ＳＤＰのメディアフラグが「アクティブ」を示している場合は、ネットワークリソースが予約されているので、それが必要とされないことを意味し、一方で、ＳＤＰのメディアフラグが「インアクティブ」を示している場合は、ネットワークリソースが予約されていないので、それが必要とされることを意味するようにする。ＳＤＰにおける属性として与えられる前提条件は、要求されるＱｏＳを提供するネットワークリソースが必要とされるかを判定するために使用することができ、そうすることで、その与えられる前提条件が合致しない場合にはネットワークリソースが必要とされ、合致する場合には必要とされないようにする。

移動端末とそのユーザに対する加入及び認証データと、来るべきセッションに対して起動されているアプリケーションあるいはサービスのタイプは、セカンダリＰＤＰコンテキストが、来るべきセッションに対してアクティベートされるべきかを判定するために使用することができる。

上述の２つの判定とトリガーは、移動ネットワークにおいて通信セッションを認可することを基本的には担当するポリシーユニットによって実行されることが好ましい。このポリシーユニットは、ＰＤＦ（ポリシー決定機能）あるいはＰＣＲＦ（ポリシー及び課金ルール機能）であっても良い。

セカンダリＰＤＰコンテキストのアクティベーションは、移動端末に対するセカンダリＰＤＰコンテキストをアクティベートするためのリクエストを、移動ネットワークのＧＧＳＮへ送信することによってトリガーされても良い。このセカンダリＰＤＰコンテキストをアクティベートするためのリクエストは、ＤＩＡＭＴＥＲに基づくプロトコルＧｘを介してＧＧＳＮへ送信することができる、変更された既存メッセージ「クレジット制御リクエストＣＣＲ」に含まれていても良い。セカンダリＰＤＰコンテキストをアクティベートするためのリクエストの受信に応じて、ＧＧＳＮは、来るべきセッションに対するルールをインストールすることができ、また、セカンダリＰＤＰコンテキストを開始するための指示を移動端末へ送信することができる。

本発明の別の構成に従えば、別のパーティと通信する移動端末に対するパケット交換マルチメディアセッションを確立するための、移動ネットワークにおける装置が提供される。ここで、プライマリＰＤＰ（パケットデータプロトコル）コンテキストは、移動端末に対する移動ネットワークでアクティベートされている。この装置は、通信するパーティ間でネゴシエートされ、かつ同意されている来るべきセッションにおける情報を受信する手段と、保証されるＱｏＳを提供するネットワークリソースがセッションに対して必要とされているかを判定する手段と、セカンダリＰＤＰコンテキストが移動端末と来たるべきセッションに対してアクティベートされるべきかを判定する手段と、要求されるＱｏＳを提供するネットワークリソースが必要とされ、かつセカンダリＰＤＰコンテキストがアクティベートされるべきである場合、セカンダリＰＤＰコンテキストのアクティベーションをトリガーする手段とを備える。

この装置は、更に、呼出側パーティからのセッション招待に対する被呼出側パーティからの応答から、セッションにおける情報を抽出する手段を備えても良い。この応答は、セッション招待で提案されるセッションパラメータを効果的に確認するものである。この装置は、更に、応答で与えられるＳＤＰ（セッション記述プロトコル）から、セッションにおける情報を導出する手段を備えても良い。

この装置は、更に、要求されるＱｏＳを提供するネットワークリソースがセッションに対して必要とされるかを判定するために、受信されるＳＤＰ内のメディアフラグの存在と、ＳＤＰ自身におけるセッションの記述を使用する手段を備え、そうすることで、ＳＤＰのメディアフラグが「アクティブ」を示している場合は、ネットワークリソースが予約されているので、それが必要とされないことを意味し、ＳＤＰのメディアフラグが「インアクティブ」を示している場合は、ネットワークリソースが予約されていないので、それが必要とされることを意味するようにする。

この装置は、更に、要求されるＱｏＳを提供するネットワークリソースが必要とされるかを判定するために、ＳＤＰにおける属性として与えられる前提条件を使用する手段を備えても良く、そうすることで、与えられる前提条件が合致しない場合にはネットワークリソースが必要とされ、合致する場合には必要とされないようにする。

この装置は、更に、セカンダリＰＤＰコンテキストが、来るべきセッションに対してアクティベートされるべきかを判定するために、移動端末とそのユーザに対する加入及び認証データと、来るべきセッションに対して起動されているアプリケーションあるいはサービスのタイプを使用する手段を備えても良い。

２つの判定する手段と、トリガーする手段は、移動ネットワークにおいて通信セッションを認可することを基本的には担当するポリシーユニットに含まれていても良い。ポリシーユニットは、ＰＤＦ（ポリシー決定機能）あるいはＰＣＲＦ（ポリシー及び課金ルール機能）であっても良い。

この装置は、更に、移動端末に対するセカンダリＰＤＰコンテキストをアクティベートするためのリクエストを、移動ネットワークのＧＧＳＮへ送信することによって、セカンダリＰＤＰコンテキストのアクティベーションをトリガーする手段を備えても良い。この装置は、更に、セカンダリＰＤＰコンテキストをアクティベートするためのリクエストを、ＤＩＡＭＴＥＲに基づくプロトコルＧｘを介してＧＧＳＮへ送信される、変更された既存メッセージ「クレジット制御リクエストＣＣＲ」に含める手段を備えても良い。

この装置は、更に、セカンダリＰＤＰコンテキストをアクティベートするためのリクエストの受信に応じて、ＧＧＳＮにおいて、来るべきセッションに対するルールをインストールし、セカンダリＰＤＰコンテキストを開始するための指示を移動端末へ送信する手段を備えても良い。

本発明の更なる特徴及び利点は、以下の詳細で説明する。

実施形態の詳細
本発明では、移動端末に対するセカンダリＰＤＰコンテキストのアクティベーションをトリガーするタスクが、その移動端末から自身の移動コアネットワークにシフトされる、あるいは、移動端末がローミングしている場合には、「ホーム」移動コアネットワークにシフトされる。これによって、ネットワークオペレータは、自身のネットワークリソースを介する完全な制御を行うことができ、セッション開始前の遅延を削減することができ、また、シグナリングの衝突を回避することができる。

本発明の１つの構成に従えば、移動端末を含む２つの通信パーティに対するマルチメディアセッションを確立するための処理を、図４に示されるフローチャートを参照して説明する。ここでは、移動端末が介在する通信セッションが、その移動端末あるいはそれに対するパーティによってリクエストされていると想定する。第１ステップ４００では、通信パーティ間でネゴシエートされ、かつ同意されている、来るべきセッションにおける情報が受信される。このセッションの情報は、セッション招待（インビテーション：invitation）に対する被呼側パーティからの応答に応じて与えられるＳＤＰから導出されても良く、その応答は、効果的に提案されるセッションパラメータを確認するものであり、例えば、上述のＯＫ（ｉｎｖｉｔｅ）と呼ばれる応答メッセージである。

次のステップ４０２で、要求されているＱｏＳを提供する任意のネットワークリソースがそのセッションに対して必要であるかが判定される。別の実施形態に従えば、これは、「インアクティブ」と呼ばれる「メディアフラグ」の存在をチェックすることによって判定することができ、このメディアフラグは、メディアリソースがインアクティブである場合を示すために使用される、ＳＤＰで現在存在する属性である。一方、「インアクティブ」のメディアフラグが存在しない場合、メディアリソースはアクティブとなる。本発明の一実施形態では、メディアフラグが存在しない（アクティブである）場合に、ネットワークリソースが予約されている、つまり、セカンダリＰＤＰコンテキストをアクティベートすることによって、リソース予約が必要とされないことを示すようにメディアフラグを使用することが提案される。しかしながら、メディアフラグが存在する（インアクティブである）場合、ネットワークリソースは予約されない、これは、必要とされていないからである。

選択的には、ＳＤＰで前提条件としてマークされている属性は、要求されるＱｏＳを提供するネットワークリソースが必要であるかどうかを判定するために使用することができ、そうすることで、与えられる前提条件が現在合致しない場合は、そのようなネットワークリソースは必要とされ、逆の場合は、必要とされないことになる。

リソース予約の必要性を示すための任意のメカニズムを使用することができ、本発明は、上述の例に限定されないことに注意するべきである。

ステップ４０２で、要求されるＱｏＳを提供するネットワークリソースが実際に必要とされないと判定される場合、セカンダリＰＤＰコンテキストをアクティベートする必要はなく、それに従って、ステップＳ４０４に示されるように、通常処理を、セッションセットアップを完了するために使用することができる。

しかしながら、ステップ４０２で、要求されるＱｏＳを提供するネットワークリソースが必要とされると判定される場合、更に、ステップ４０６で、セカンダリＰＤＰコンテキストが来るべきセッションに対してアクティベートされるべきであるかどうかが判定される。このセカンダリＰＤＰコンテキストをアクティベートするための決定は、更に、様々な加入及び認証データに基づいていて、また、来るべきセッションに対して起動されているアプリケーションあるいはサービスのタイプにも基づいている。例えば、あるアプリケーションは、セカンダリＰＤＰコンテキストを要求するＱｏＳを要求することができ、一方で、他のアプリケーションは要求することができない。移動体ユーザの加入は、あるＱｏＳ及びあるサービスに対するあるプリファレンスの少なくとも一方に対して可能であり、あるいは、他のサービスへのアクセスを禁止することも可能である。

ステップ４０６で、セカンダリＰＤＰコンテキストがアクティベートされないと判定される場合、ステップ４０４で示される通常処理が、セッションセットアップを完了するために使用されても良い。セカンダリＰＤＰコンテキストが実際にアクティベートされる場合、即ち、セッションが認可される場合、プロセスは、ステップＳ４０８で示される最終処理である、移動端末及び来たるべきセッションに対するセカンダリＰＤＰコンテキストのアクティベーションをトリガーするための処理へ進む。本発明の処理が、上述のステップ４００、４０２、４０６及び４０８に従って実行される場合、ネットワークオペレータは、セカンダリＰＤＰコンテキストのアクティベーションに通常は関連付けられているリソース割当の完全な制御を行うことになる。セットアップ遅延も削減することができる。これは、以下の図５の説明から明らかとなるように、このプロセスは、通常は、より少ないシグナリングを要求し、かつ受信側の端末に対して同時かつ独立して行うことができるからである。

以下で説明される実施形態から明らかなように、図４に示されるフローチャートに従うマルチメディアセッションを確立するための処理は、基本的には、図３に示されるユニット３０６のような、移動アクセスネットワークに属するポリシーユニットあるいはその類において実現することができる。このポリシーユニットは、ＰＤＦ（ポリシー決定機能）あるいはＰＣＲＦ（ポリシー及び課金ルール機能）であっても良く、また、基本的には、通信セッションを認可することを担当する。また、図３のＧＧＳＮ３０４とＩＭＳコア３０８は、ポリシーユニット３０６の新規の動作との適合を必要とする場合がある。

図５は、実施形態に従う、移動端末Ａと別のパーティＢ間のマルチメディアセッションを確立するためのステップを示す図である。この実施形態は、セッションセットアップに対する、ある既存の標準的なメッセージを、必要な場合に、セカンダリＰＤＰコンテキストのアクティベーションに対して必要とされる情報を搬送するためにどのように利用することができるかを示している。図３と同様に、関与するネットワーク要素には、ＧＧＳＮ５００、端末Ａのホーム移動ネットワークに属するポリシーユニット５０２、及びそれと同一の移動ネットワークに関連するＩＭＳコア５０４を含んでいる。受信側のネットワークは、不図示ではあるが、パーティＢも移動端末である場合は、基本的には同様の構成となる。

上述のステップ３：１で示されるように、プライマリＰＤＰコンテキストが、シグナリングメッセージに対する端末Ａに対してアクティベートされると想定する。端末ＡがパーティＢに向けてＩＮＶＩＴＥメッセージを送信する場合、片方向あるいは両方向でのメディアの通信に一般的に関与するマルチメディアセッションを実行するために、ステップ５：１によるプロセスが開始する。このＩＮＶＩＴＥメッセージは、提案されるセッションパラメータを有するＳＤＰを含んでいていて、破線で示されるように、ＩＭＳコア５０４を介してパーティＢ側へ搬送される。この時点ではメディアは通信されていないので、端末Ａは、ＩＮＶＩＴＥメッセージのＳＤＰでは、「インアクティブ」とするメディアフラグを設定していると想定する。

受信されるＩＮＶＩＴＥメッセージで示される、提案されるセッションパラメータを検討した後、パーティＢは、次のステップ５：２で、応答ＯＫ（ｉｎｖｉｔｅ）メッセージを端末Ａへ返信する。上述のように、パーティＢは、確認されているセッションパラメータを含むＯＫ（ｉｎｖｉｔｅ）メッセージに対応するＳＤＰを含め、これは、パーティＡ及びＢの両方によって、来るべきセッションで使用することができる。また、パーティＢは、このメッセージでは、ＳＤＰでインアクティブとするメディアフラグを保持していると予想される。

ステップ５：２で、ＩＭＳコア５０４が、パーティＢからＯＫ応答メッセージを検出すると、ＳＤＰ情報は、プロトコルＲｘに基づいて、ＤＩＡＭＥＴＥＲに変換され、これには、端末Ａの加入の詳細が、通常の認可／認証ルーチンに対する基礎として追加されている。次のステップ５：３で、この情報のすべてが、端末Ａに対する「認可／認証リクエストＡＡＲ」と呼ばれる既存のメッセージで、ポリシーユニット５０２へ出力される。今までのところで、このプロセスは、セッションを開始し、かつ認可するための通常処理に従って実行されている。

次のステップ５：４で、ポリシーユニット５０６は、端末Ａ及び来たるべきセッションに対して、セカンダリＰＤＰコンテキストがアクティベートされるべきに関しての決定を行う。この決定は、基本的には、図４のステップ４０２及び４０６のように実行され、それゆえ、ここでは、その詳細については再度繰り返さない。但し、既存のＡＡＲメッセージは、本実施形態では、その決定の根拠とともに、ＳＤＰ及び加入の詳細で与えられるアプリケーションアイデンティティを提供するためのメディアフラグを搬送するために利用されることに注意すべきである。選択的には、前提条件は、上述のように、この決定の同様の根拠としてＳＤＰに提供することができる。

本例では、ステップ５：４で、ポリシーユニット５０２は、例えば、インアクティブのメディアフラグの読出後、あるいは、与えられる前提条件が合致しないことの検出後に、セカンダリＰＤＰコンテキストをアクティベートすることを決定すると想定する。次のステップ５：５で、端末Ａに対するセカンダリＰＤＰコンテキストを開始するためのリクエストが、ポリシーユニット５０２からＧＧＳＮ５００へ送信される。このリクエストは、例えば、標準クレジット制御メッセージを使用して搬送されても良い。本例では、既存のメッセージ「クレジット制御リクエストＣＣＲ」は、このリクエストを含むように変更され、かつＤＩＡＭＴＥＲに基づくプロトコルＧｘを介してＧＧＳＮ５００へ送信される。このメッセージは、通常の従来の処理において、逆の手順で、ＰＤＰコンテキストアクティベーション中にＧＧＳＮからポリシーユニットへ送信され、こうして、端末Ａに対するセカンダリＰＤＰコンテキストを開始するための、特に、ＱｏＳ要件を含むリクエストを搬送するために利用することができる。このメッセージは、ＲＡＢを含むネットワークリソースを端末Ａへ割り当てることができるＧＧＳＮ５００によって実行されるような、セカンダリＰＤＰコンテキストアクティベーションを効果的にトリガーする。これによって、このトリガーは、ポリシーユニットによって制御される、即ち、端末に代えてネットワークオペレータによって効果的に制御される。

次に、ＧＧＳＮノードは、例えば、開始リクエストで定義されるパラメータを用いてセカンダリＰＤＰコンテキストのアクティベーション用の通常処理を起動するためのリクエストを端末に送信することによって、セカンダリＰＤＰコンテキストを開始する。しかしながら、本発明はこれに制限されるものではなく、端末に関与するかしないかに関わらず、任意のメカニズムをセカンダリＰＤＰコンテキストをアクティベートするために使用することができる。但し、この例では、ＧＧＳＮ５００は、ステップ５：６で、メッセージ「ＰＤＰコンテキストのリクエスト」を端末Ａへ送信する。このメッセージは、通常の方法で、セカンダリＰＤＰコンテキストを「開始」することを端末Ａへ効果的に指示する。この時点で、ＧＧＳＮ５００も、ステップ５：７で示されるような「ルール」をインストールし、これは、メディアの転送を制御するためのセッション中に使用されることになる。ルールのインストールには、セッション専用ＱｏＳパラメータ及び課金パラメータの記憶、加えて、ＩＰアドレス及び、使用される端末Ａの番号等の記憶を含んでいる。ステップ５：６で受信されるメッセージの応答では、それに従って、端末Ａは、ステップ５：８で、メッセージ「ＰＤＰコンテキストの開始」をＧＧＳＮ５００へ送信し、これは、ステップ５：９で、ＧＧＳＮから返信されるメッセージ「ＰＤＰコンテクキトの受付」によって応答確認される。

ステップ５：５のＧｘ ＣＣＲメッセージの応答として、ＧＧＳＮ５００が、ステップ５：１０で、変更された標準メッセージＧｘ ＣＣＡである「クレジット制御回答（Credit Control Answer）」をポリシーユニット５０２へ送信する時点より前ではあるが、ステップ５：５の後の任意の時点でステップ５：７を実行することができることに注意すべきである。従来技術に従って、逆の手順で、ポリシーユニットからＧＧＳＮへ通常は送信されるメッセージＧｘ ＣＣＡは、ここでは、アクティベートされているセカンダリＰＤＰコンテキストにおける情報を含むように変更されている。これによって、既存のＧｘ ＣＣＡメッセージは、ステップ５：１０で、この情報をポリシーユニットへ搬送するために利用されるが、ここでも、最初に意図されているように、これは、以前として、ステップ５：５のＧｘ ＣＣＲメッセージとともに、通常のクレジット制御用に使用することができる。

そして、ポリシーユニット５０２は、ステップ５：１１で、Ｒｘ ＡＡＡ「認可／認証回答」と呼ばれる、ステップ５：３で受信される、Ｒｘ ＡＡＲメッセージの標準的な応答の送信に進むことができる。このメッセージは、セッションが認可され、また、ネットワークリソースが予約され、それによって、セッションを開始することを可能にすることを示している。ステップ５：９でのメッセージ「ＰＤＰコンテキストの受付」の受信後、端末Ａは、ステップ５：１２で、新規のＩＮＶＩＴＥメッセージをパーティＢへ送信し、この時点では、ＳＤＰのメディアフラグは「インアクティブ」とはなっていない、つまり、「アクティブ」を示していて、それに従い、受信側のパーティは、続くステップ５：１３で、「アクティブ」を示すＳＤＰを有するＯＫ（ＩＮＶＩＴＥ）メッセージで応答する。最後の２つのステップはセッションをアクティブとして応答確認し、メディアの通信を、最終ステップ５：１４で実行することができる。

例えば、上述の実施形態に従う、本発明を実現することによって、ネットワークオペレータは、移動端末に対するマルチメディアセッションを確立する場合に自身のネットワークリソースを介する完全な制御を行うことになる。これは、端末に代って、オペレータが、セカンダリＰＤＰコンテキストをトリガーする時点を決定することができるからである。セッションが開始する前の遅延も削減することができる。

従来技術に従う既存の処理は、ＳＤＰのメディアフラグをインアクティブに設定する場合、「競合状態」と呼ばれるシグナリングの衝突をもたらす可能性がある。これは、応答するユーザ（例えば、ユーザＢ）が、セッション記述を受け付ける場合に、ＳＤＰをアクティブ（即ち、「インアクティブ」のメディアフラグでない）にするからである。この応答するユーザは、セッション受付メッセージ（ＳＩＰ ＯＫ Ｉｎｖｉｔｅ）と、リソース予約メッセージをほぼ同時に送信することができる。これは、セッション受付回答によってトリガーされるリソース予約信号がポリシーユニットに到達して、競合状態にならない限り、ＰＤＰ確立時に失敗となる、移動ネットワーク内のポリシーユニットでリソースが予約される前に、応答するユーザに、セカンダリＰＤＰコンテキストを開始することを可能にする。本発明を使用することは、このような衝突を回避することになる。

本発明は、特定の実施形態を参照して説明されているが、この説明は、一般的には、本発明の概念を示すことを意図するものであり、本発明の範囲を制限するものとするべきでない。例えば、ＳＩＰシグナリングプロトコルとＩＭＳの概念は、上述の実施形態で説明する場合では全体に渡って使用しているが、マルチメディア通信を可能にするための任意の他の規格及びサービスネットワークを、基本的には使用することができる。本発明は、添付の特許請求の範囲によって定義される。

２つの移動端末間でのマルチメディア通信を行うための従来のネットワーク構造を示す図である。 移動端末のＵＭＴＳトラフィッククラスへのアプリケーションのマッピングを示す図である。 従来技術に従うマルチメディアセッションを確立するためのプロセスの各段階を示すシグナリング図である。 本発明の一構成に従う、マルチメディアセッションを確立するための処理を示すフローチャートである。 実施形態に従う、マルチメディアセッションを確立するためのメッセージングステップを示すシグナリング図である。

Claims (22)

1. プライマリＰＤＰ（パケットデータプロトコル）コンテキストが移動端末に対する移動ネットワークでアクティベートされている、別のパーティと通信する前記移動端末に対するパケット交換マルチメディアセッションを確立する方法であって、
   前記通信するパーティ間でネゴシエートされ、かつ同意されている来るべきセッションにおける情報を受信するステップと、
   要求されるＱｏＳを提供するネットワークリソースが、前記移動ネットワークにおける前記セッションに対して必要とされているかを判定するステップと、
   セカンダリＰＤＰコンテキストが、前記移動端末と前記来たるべきセッションに対してアクティベートされるべきかを判定するステップと、
   ネットワークリソースが必要とされ、かつセカンダリＰＤＰコンテキストがアクティベートされるべきである場合、前記セカンダリＰＤＰコンテキストのアクティベーションをトリガーするステップと
   を備えることを特徴とする方法。
2. 前記セッションにおける情報は、呼出側パーティからのセッション招待に対する被呼出側パーティからの応答に含まれていて、
   前記応答は、前記セッション招待で提案されるセッションパラメータを効果的に確認するものである
   ことを特徴とする請求項１に記載の方法。
3. 前記セッションにおける情報は、前記応答で与えられるＳＤＰ（セッション記述プロトコル）から導出される
   ことを特徴とする請求項２に記載の方法。
4. 前記受信されるＳＤＰ内のメディアフラグの存在と、前記ＳＤＰ自身における前記セッションの記述は、要求されるＱｏＳを提供するネットワークリソースが前記セッションに対して必要とされるかを判定するために使用され、そうすることで、前記ＳＤＰのメディアフラグが「アクティブ」を示している場合は、前記ネットワークリソースが予約されているので、それが必要とされないことを意味し、一方、前記ＳＤＰのメディアフラグが「インアクティブ」を示している場合は、前記ネットワークリソースが予約されていないので、それが必要とされることを意味するようにする
   ことを特徴とする請求項３に記載の方法。
5. ＳＤＰにおける属性として与えられる前提条件は、要求されるＱｏＳを提供するネットワークリソースが必要とされるかを判定するために使用され、そうすることで、前記与えられる前提条件が合致しない場合にはネットワークリソースが必要とされ、合致する場合には必要とされないようにする
   ことを特徴とする請求項３に記載の方法。
6. 前記移動端末とそのユーザに対する加入及び認証データと、前記来るべきセッションに対して起動されているアプリケーションあるいはサービスのタイプは、セカンダリＰＤＰコンテキストが、前記来るべきセッションに対してアクティベートされるべきかを判定するために使用される
   ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. 前記２つの判定するステップと、前記トリガーするステップは、前記移動ネットワークにおいて通信セッションを認可することを基本的には担当するポリシーユニットによって実行される
   ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. 前記ポリシーユニットは、ＰＤＦ（ポリシー決定機能）あるいはＰＣＲＦ（ポリシー及び課金ルール機能）である
   ことを特徴とする請求項７に記載の方法。
9. 前記セカンダリＰＤＰコンテキストのアクティベーションは、前記移動端末に対するセカンダリＰＤＰコンテキストをアクティベートするためのリクエストを、前記移動ネットワークのＧＧＳＮへ送信することによってトリガーされる
   ことを特徴とする請求項８に記載の方法。
10. 前記セカンダリＰＤＰコンテキストをアクティベートするためのリクエストは、ＤＩＡＭＴＥＲに基づくプロトコルＧｘを介してＧＧＳＮへ送信される、変更された既存メッセージ「クレジット制御リクエストＣＣＲ」に含まれている
    ことを特徴とする請求項９に記載の方法。
11. 前記セカンダリＰＤＰコンテキストをアクティベートするためのリクエストの受信に応じて、前記ＧＧＳＮは、前記来るべきセッションに対するルールをインストールし、セカンダリＰＤＰコンテキストを開始するための指示を前記移動端末へ送信する
    ことを特徴とする請求項９または１０に記載の方法。
12. プライマリＰＤＰ（パケットデータプロトコル）コンテキストが移動端末に対する移動ネットワークでアクティベートされている、別のパーティと通信する前記移動端末に対するパケット交換マルチメディアセッションを確立するための、移動ネットワークにおける装置であって、
    前記通信するパーティ間でネゴシエートされ、かつ同意されている来るべきセッションにおける情報を受信する手段と、
    要求されるＱｏＳを提供するネットワークリソースが、前記セッションに対して必要とされているかを判定する手段と、
    セカンダリＰＤＰコンテキストが、前記移動端末と前記来たるべきセッションに対してアクティベートされるべきかを判定する手段と、
    要求されるＱｏＳを提供するネットワークリソースが必要とされ、かつセカンダリＰＤＰコンテキストがアクティベートされるべきである場合、前記セカンダリＰＤＰコンテキストのアクティベーションをトリガーする手段と
    を備えることを特徴とする装置。
13. 呼出側パーティからのセッション招待に対する被呼出側パーティからの応答から、前記セッションにおける情報を抽出する手段を更に備え、
    前記応答は、前記セッション招待で提案されるセッションパラメータを効果的に確認するものである
    ことを特徴とする請求項１２に記載の装置。
14. 前記応答で与えられるＳＤＰ（セッション記述プロトコル）から、前記セッションにおける情報を導出する手段を更に備える
    ことを特徴とする請求項１３に記載の装置。
15. 要求されるＱｏＳを提供するネットワークリソースが前記セッションに対して必要とされるかを判定するために、前記受信されるＳＤＰ内のメディアフラグの存在と、前記ＳＤＰ自身における前記セッションの記述を使用する手段を更に備え、そうすることで、前記ＳＤＰのメディアフラグが「アクティブ」を示している場合は、前記ネットワークリソースが予約されているので、それが必要とされないことを意味し、前記ＳＤＰのメディアフラグが「インアクティブ」を示している場合は、前記ネットワークリソースが予約されていないので、それが必要とされることを意味するようにする
    ことを特徴とする請求項１４に記載の装置。
16. 要求されるＱｏＳを提供するネットワークリソースが必要とされるかを判定するために、ＳＤＰにおける属性として与えられる前提条件を使用する手段を更に備え、そうすることで、前記与えられる前提条件が合致しない場合にはネットワークリソースが必要とされ、合致する場合には必要とされないようにする
    ことを特徴とする請求項１４または１５に記載の装置。
17. セカンダリＰＤＰコンテキストが、前記来るべきセッションに対してアクティベートされるべきかを判定するために、前記移動端末とそのユーザに対する加入及び認証データと、前記来るべきセッションに対して起動されているアプリケーションあるいはサービスのタイプを使用する手段を更に備える
    ことを特徴とする請求項１２乃至１６のいずれか１項に記載の装置。
18. 前記２つの判定する手段と、前記トリガーする手段は、前記移動ネットワークにおいて通信セッションを認可することを基本的には担当するポリシーユニットに含まれている
    ことを特徴とする請求項１２乃至１７のいずれか１項に記載の装置。
19. 前記ポリシーユニットは、ＰＤＦ（ポリシー決定機能）あるいはＰＣＲＦ（ポリシー及び課金ルール機能）である
    ことを特徴とする請求項１８に記載の装置。
20. 前記移動端末に対するセカンダリＰＤＰコンテキストをアクティベートするためのリクエストを、前記移動ネットワークのＧＧＳＮへ送信することによって、前記セカンダリＰＤＰコンテキストのアクティベーションをトリガーする手段を更に備える
    ことを特徴とする請求項１９に記載の装置。
21. 前記セカンダリＰＤＰコンテキストをアクティベートするためのリクエストを、ＤＩＡＭＴＥＲに基づくプロトコルＧｘを介してＧＧＳＮへ送信される、変更された既存メッセージ「クレジット制御リクエストＣＣＲ」に含める手段を更に備える
    ことを特徴とする請求項２０に記載の装置。
22. 前記セカンダリＰＤＰコンテキストをアクティベートするためのリクエストの受信に応じて、前記ＧＧＳＮにおいて、前記来るべきセッションに対するルールをインストールし、セカンダリＰＤＰコンテキストを開始するための指示を前記移動端末へ送信する手段を更に備える
    ことを特徴とする請求項２０または２１に記載の装置。

Images