JP2011505713A - インターネット・プロトコル・マルチメディア・コア・ネットワーク・サブシステムにおけるアプリケーションサーバによる発呼 - Google Patents

Abstract

インターネット・プロトコル・マルチメディア・コア・ネットワーク・サブシステム内のアプリケーションサーバによる発呼ためのシステムと方法は、ユーザにパブリックユーザＩＤを与えるという第１のステップを含む。次のステップは、アプリケーションサーバがパブリックユーザＩＤに代わって呼リクエストを開始することを許可するか、または却下するかを明示するサービスパラメータを、ユーザのサービスプロファイルに格納することを含む。アプリケーションサーバが呼リクエストを開始することがサービスパラメータによって許可されている場合、システムはユーザに代わってアプリケーションサーバによって開始された呼をブロック解除する。アプリケーションサーバが呼リクエストを開始することをサービスパラメータが却下している場合、システムは、ユーザに代わってアプリケーションサーバによって開始された呼をブロックする。

Description

本発明は、一般に通信システムに関し、詳細には、インターネット・プロトコル・マルチメディア・サブシステムにおける発呼のための技術に関する。

最近の技術革新は、インターネットの機能を拡張し、通信サービスを含むようになってきた。マルチメディア通信のためのかかるサービスの１つは、インターネット・プロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：ＩＰ）・マルチメディア・コア・ネットワーク・サブシステム（ＩＭＳ）で使用する呼制御プロトコルを提供する。当業者であれば周知のとおり、ＩＭＳはセッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＳＩＰ）とセッション記述プロトコル（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＳＤＰ）とに準拠しており、すべてのＩＭＳエンティティにＩＰアドレスが割り当てられる。ＩＭＳでは、本明細書においてユーザ機器（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ＵＥ）と呼ばれる携帯端末または通信装置が、ＳＩＰユーザエージェント（Ｕｓｅｒ Ａｇｅｎｔ：ＵＡ）の役割を提供する。呼セッション制御機能（Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ：ＣＳＣＦ）がＳＩＰプロキシの役割を提供する。

ＩＭＳでは、アプリケーションサーバ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ：ＡＳ）もＳＩＰ ＵＡの役割を提供することができ、サードパーティ登録者（ＵＥ等）に呼制御を提供することもできる。一般に、ＵＥまたは加入者には、ホーム加入者システム（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｙｓｔｅｍ：ＨＳＳ）等のホーム通信ネットワーク事業者によってプライベートユーザＩＤが割り当てられる。プライベートユーザＩＤは、ＵＥ内のＳＩＰアプリケーションよって利用可能である。ＵＥには、ＨＳＳ上でプロビジョニングされている（ｐｒｏｖｉｓｉｏｎｅｄ）少なくとも１つのパブリックユーザＩＤ（ｐｕｂｌｉｃ ｕｓｅｒ ｉｄｅｎｔｉｔｙ：ＰＵＩ）も割り当てられる。ＰＵＩは、ＳＩＰ ＵＲＩの形態をとる。ＰＵＩは、異なるプライベートユーザＩＤとＩＰアドレスとを有する複数のＵＥの間で共有されてもよい。ＩＭＳは、すべてが同じ事業者ネットワークに属するか、同じ事業者ネットワークとの以前の構成を有する、アサートされたＩＤの「信頼領域（ｔｒｕｓｔ ｄｏｍａｉｎ）」を提供する。アサートされたＩＤは、ＳＩＰプロトコルのＰ―Ａｓｓｅｒｔｅｄ―Ｉｄｅｎｔｉｔｙヘッダという形態をとる。ＩＭＳでは、ＵＥが、ＰＵＩ、プライベートユーザＩＤ、およびドメイン名を登録リクエストで送信する必要がある。かかる登録リクエストは、ＩＭＳから認可（Ａｕｔｈｏｒｉｚｅｄ）または不認可（Ｕｎａｕｔｈｏｒｉｚｅｄ）レスポンスを受け取ることができる。

アプリケーションサーバ（ＡＳ）は、既知のＵＥに代わって登録をサポートすることができる。特に、サードパーティの登録リクエストを受け取ったら、ＡＳは、サービングＣＳＣＦ（Ｓｅｒｖｉｎｇ ＣＳＣＦ：Ｓ―ＣＳＣＦ）で登録されたＰＵＩに代わって（ＳＩＰ ＵＲＩを使用して）承認（ｓｕｂｓｃｒｉｂｅ）してもよい。このようにして、ＡＳは発信側ＵＡとして機能することができる。今のケースにおいて、ＡＳは、リクエストの送信先Ｓ―ＣＳＣＦと同じ信頼領域内になくてはならない。ＡＳは、ＰＵＩに代わって初期リクエストを送信する際に、ＰＵＩが登録またはホスト（すなわち登録解除）されるＳ―ＣＳＣＦか、またはＩ―ＣＳＣＦを参照するルートヘッダを挿入し、このルートヘッダは、ＰＵＩネットワークのエントリポイントとして扱われる。ＡＳは、ＵＥのホーム加入者システムに問い合わせることにより、あるいはサードパーティ登録のときに、Ｓ―ＣＳＣＦのアドレスを取得することができる。

ＡＳによってＰ―Ａｓｓｅｒｔｅｄ―Ｉｄｅｎｔｉｔｙが使用される場合、リクエストは、ＵＥが起点であるかのように生成される（この場合、ＡＳは、ＵＥのＰＵＩを表すＰ―Ａｓｓｅｒｔｅｄ―Ｉｄｅｎｔｉｔｙを挿入する）か、Ｐｕｂｌｉｃ Ｓｅｒｖｉｃｅ Ｉｄｅｎｔｉｔｙ（ＰＳＩ：パブリックサービスＩＤ）によって特定されるサービスをサポートしているＡＳによって生成される。この場合、ＡＳは、ＡＳのＰＳＩを含んでいるＰ―Ａｓｓｅｒｔｅｄ―Ｉｄｅｎｔｉｔｙを挿入する。

ただし、これらの手順は、ＡＳとＳ―ＣＳＣＦとの信頼領域内でしか適用されない。特に、現在のＩＭＳプロトコルでは、ＡＳはローカルネットワークのＩＭＳ加入者に代わって呼を開始し、発信側加入者のサービングＣＳＣＦに呼を送信することのみ許可されている。この状況は、ＡＳのニーズに対して必ずしも十分ではない。どのＩＭＳ ＡＳも、ＡＳがホストするサービスにも偶然加入しているＩＭＳ加入者について把握するに過ぎない。加入者に代わってＡＳが発呼することは、ＩＭＳの発信パスだけでなく、着信パスでも起こり得る。そのためには、このような発呼を受信するＳ―ＣＳＣＦ（発信または着信Ｓ―ＣＳＣＦ）が、論理的な発呼者である加入者のＳ―ＣＳＣＦに呼を送信できる必要がある。ただし、このシナリオだと、非加入ＵＥに割り当てが行われない。

必要なことは、非加入のＵＥに変わってＩＭＳが発呼できるようにＩＭＳを強化することである。

本発明に係る例示的なＩＭＳ呼環境を示すダイアグラムである。 本発明に係る方法を示すフローチャートである。

添付の図面において、同じ参照番号は、別々の図の全体にわたって同一であるか機能上同様の要素を言及し、下記の詳細な説明と共に本明細書に組み込まれ、明細書の一部を形成する。添付の図面は、本発明に係る各種実施形態をさらに示し、各種原理と効果とを説明する役割を果たす。

本発明は、インターネット・プロトコル・マルチメディア・コア・ネットワーク・サブシステム（ＩＭＳ）で使用する呼制御プロトコルを定義する。概して本発明は、ＩＭＳ非加入者を含むあらゆるユーザに代わってＡＳが発呼するのをサポートするために、ＩＭＳネットワークを強化する。従来技術では、ＡＳが非ＩＭＳユーザに代わって呼を開始すると、その呼はネットワークによって拒否されていた。

本発明は、ＡＳがユーザ（パブリックユーザＩＤ）に代わって呼を開始できる／できないようにするためにＩＭＳ標準規格を強化する。本明細書には、次の２つの異なる実施形態が記載されている。ａ）発信側ＩＭＳネットワークに属していないユーザ（すなわち、ＨＳＳでそのようにプロビジョニングされていない（ｎｏｔ ｐｒｏｖｉｓｉｏｎｅｄ）ユーザ）の場合であって、ユーザは、ＩＭＳユーザの可能性があるが別のＩＭＳネットワークに属しているか、またはユーザはＩＭＳユーザではない場合。ｂ）発信側ＩＭＳネットワークに属しているユーザ（すなわち、ＨＳＳでそのようにプロビジョニングされている（ｐｒｏｖｉｓｉｏｎｅｄ）ユーザ）の場合。これは以下に記載する強化点が追加されたＩＭＳ標準規格における既存事例と類似している。

本発明には、ユーザに代わってＡＳが開始した呼をブロック／ブロック解除する機能を認めるという利点がある。これは、現在のＩＭＳ標準規格において、「信頼領域」という概念の一部として定義されているに過ぎないが、この概念は、ユーザごとに呼をブロック／ブロック解除する機能を認めていない。加えて、本発明は、発信側ネットワークにおけるトランジット機能によって通信がネットワークを通過できるようにしているのに対し、現在のＩＭＳ標準規格は、通信の着信側ネットワークにおけるトランジット機能を記載しているに過ぎない。

本明細書で使用されているとおり、ユーザ機器（ＵＥ）や通信装置等の用語は、固定または／およびＷｉＦｉ ＳＩＰフォン、携帯型または移動型無線電話機、ＷｉＭａｘ ＳＩＰ ＵＡ、２ウェイ無線機、メッセージング装置、パーソナル・デジタル・アシスタント、パーソナル・アサイメント・パッド、無線操作対応型パーソナルコンピュータ、携帯型ハンドセットまたは装置等のエンドユーザ装置またはその等価物を一般に表し、かかる機器は、本発明の様々な概念や原理に係る動作のために構成および考案されたものであり、本明細書に記述および記載される適切な仕様、規準、およびプロトコルの下で動作していることを条件とする。本明細書の実施例において、ＩＭＳは、層下でアドレス指定されないオーバレイ技術であり、取り得る形態としては、イーサネット、ＷｉＦｉ、ＷｉＭａｘ、セルラー方式を始め、ケーブル・セット・トップ・ボックスやＤＳＬ／ＤＳＬＡＭに至る。なお、本発明は、ＩＭＳをアプリケーション層として使用したいＩＰネットワーク層を提供する任意の種類のアクセスに適用可能である。

記述および記載されている原理と概念とは、パケットベースのマルチメディア情報提供サービスや、通信ネットワーク経由の音声、データ、またはメッセージングサービスを提供または簡便化する通信ユニット、装置、およびシステムに適用できる可能性がある。具体的には、従来の２ウェイシステムや装置、アナログおよびデジタルセルラー方式、ＣＤＭＡ（ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ：符号分割多重接続）およびその異型を含む各種携帯電話システム、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ：モバイル通信のためのグローバルシステム）、ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｙｓｔｅｍ：汎用パケット無線システム）、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ：ユニバーサル移動電話サービス）システム等の第２．５世代および第３世代システム、Ｉｎｔｅｇｒａｔｅｄ Ｄｉｇｉｔａｌ Ｅｎｈａｎｃｅｄ Ｎｅｔｗｏｒｋｓおよびそれらの異型または進化型等が挙げられる。本明細書に記載されている原理および概念はさらに、ＩＥＥＥ ８０２．ｘｘ、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ−Ｆｉ、ＷｉＭＡＸ等、通信範囲が狭い装置またはシステムでも適用され得る。それらの装置またはシステムでは、ＣＤＭＡ、周波数ホッピング、直角周波数分割多重、ＴＤＭＡアクセス技術と、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（伝送制御プロトコル／インターネットプロトコル））、ＩＰＸ／ＳＰＸ（Ｉｎｔｅｒ−Ｐａｃｋｅｔ Ｅｘｃｈａｎｇｅ／Ｓｅｑｕｅｎｔｉａｌ Ｐａｃｋｅｔ Ｅｘｃｈａｎｇｅ（インターパケット交換／順次パケット交換））、Ｎｅｔ ＢＩＯＳ（Ｎｅｔｗｏｒｋ Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ：ネットワーク基本入出力システム）または他のプロトコル構造等の各種ネットワーキングプロトコルのうち１つ以上とを利用することが望ましい。

さらに各種典型的および代替例示的実施形態に従って、パケットベースのＲＡＮは、Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ（ＣＤＭＡ）ＲＡＮ、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ Ｍｏｂｉｌｅ（ＧＳＭ）ＲＡＮ、Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ（ＵＭＴＳ）ＲＡＮ、Ｄａｔａ Ｏｎｌｙ（ＤＯ）ＲＡＮ、Ｈｉｇｈ Ｒａｔｅ Ｐａｃｋｅｔ Ｄａｔａ Ａｃｃｅｓｓ（ＨＲＰＤＡ）ＲＡＳ、Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＬＡＮ）ＲＡＮ、またはＥｖｏｌｕｔｉｏｎ Ｄａｔａ Ｖｏｉｃｅ（ＥＶＤＶ）ＲＡＮを含み得る。例示的なＲＡＮは、ＩＰマルチメディア・コア・ネットワーク・サブシステム（ＩＭＳ）仕様の下、例えば第３世代パートナーシッププロジェクト（３ＧＰＰ）技術仕様（ＴＳ）２４．２２９に概説されるとおりに通信をサポートして、セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＳＩＰ）、セッション記述プロトコル（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＳＤＰ）およびその異型を使用した通信を実現する必要がある。なお、３ＧＰＰリリース７ ＩＭＳ仕様ＴＳ ２４．２２９等の上記標準規格に従い、ＲＴＰ／ＵＤＰ（Ｒｅａｌ Ｔｉｍｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ／Ｕｎｉｖｅｒｓａｌ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）でマルチメディアストリームを送信することができる。

他の３ＧＰＰ仕様および標準規格も本明細書では関連する可能性があることは理解されよう。さらに各種例示的な実施形態に従い、本発明は、アプリケーション層ソフトウェアアプリケーション等の上位層として実装することできる。その場合には、パケット交換通信をサポートすることを条件に、本発明の意図する範囲を逸脱することなく、データリンク層等の下位プロトコル層を代替可能としてもよい。

本開示は、本発明に係る各種実施形態を製作および使用する最良の態様を効果的な方法でさらに説明するために提供されている。本開示は、本発明を何らかの方法で制限するのではなく、本発明の原理と利点とに対する理解と評価とを高める目的でさらに提供される。本発明は、本願係属中に成されたあらゆる補正を含む添付の請求項と、発行された請求項のすべての均等物とによってのみ定義される。

第１および第２、最上部および最下部等の関係的用語が使用されている場合には、ある事物または行為と別の事物または行為を区別することだけを目的に使用されており、必ずしも、かかる事物または行為の間の実際の関係や順序を必要としたり、示唆したりすることはないという点はさらに理解されよう。本発明は、ステップや手順等を伴うプロセスをさらに含むことがある。複数のプロセスまたはステップが明示されている場合、特定の順序に明示的かつ必然的に限定されるとの記載がない限り、それらは任意の順序で実行されてよい。そのように制限されないステップまたはプロセスは、任意の順序で実行されてよい。特定のケースにおいて、これらのステップまたはプロセスは、一定回数繰り返されてもよく、必要に応じて、または特定の事象が発生するまで等の条件で無限にループしてもよい。

本発明の機能の多くと本発明の原理の多数は、ソフトウェアプログラムまたは命令と、特定用途向け集積回路等の集積回路（ＩＣ）とを使用して、またはそれらの中で最良に実装される。当業者であれば、本明細書に開示される概念と原理とによって導かれた場合に、使用可能時間、現在の技術、および経済的考慮事項等によって動機付けされる相当の労力と多数の形状の選択肢にもかかわらず、この種のソフトウェア命令およびプログラムとＩＣとを、最低限の実験で容易に生成できるであろうと予想される。したがって、本発明に係る原理および概念を不明瞭にするというリスクの簡潔化と最小化のため、かかるソフトウェアとＩＣとに関してさらに記述されるとしても、それは本発明に関する本質的事項に制限される。

図１は、本発明に係る例示的なＩＭＳの呼環境を示すダイアグラムである。例えばユーザ機器（ＵＥ）Ａと関連付けられている発信側通信ユニット１１０は、例えばＩＭＳ（インターネット・プロトコル・マルチメディア・サブシステム）とＳＩＰ手順とに従って映像メディアストリーム１０２と音声メディアストリーム１０３とがそれらの間で交換できるように、例えばＵＥ Ｂと関連付けられている対象通信ユニット１２０との通信セッションを実行したい。このセッションは、発信側および／または着信側インターネット・プロトコル・マルチメディア・サブシステム（Ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ：ＩＭＳ）コア１３０、１３２と関連して実行され、呼内の対象通信ユニット１２０または他のユニットと音声および映像ストリームとの通信を簡便化することができるアプリケーションサーバ（ＡＳ）１４０等を通じて確立されることは理解されよう。発信側ＩＭＳコア１３０は、プロキシ・サービング呼状態制御機能（ｐｒｏｘｙ Ｓｅｒｖｉｎｇ Ｃａｌｌ Ｓｔａｔｅ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ：Ｐ―ＣＳＣＦ）として働く。これは、発信側通信ユニット１１０と発信側ＩＭＳコア１３０との間の初期インターフェース（ＳＩＰサーバ）である。Ｐ―ＣＳＣＦは、ＵＥ ＩＤの基本的な検証を実行した後、発信側Ｓ―ＣＳＣＦ １３０として割り当てられている登録プロセスにそのＵＥ ＩＤを渡す。なお、ＩＭＳ呼処理は発信処理と着信処理に分割され、各々が異なるＣＳＣＦとＡＳとを有することができる。

本発明は、ＡＳ １４０が、ＩＭＳネットワークの加入者でないＵＥ Ａ １１０等のユーザ（パブリックユーザＩＤ）に代わって呼を開始できる／できないようにするために、３ＧＰＰ ＴＳ ２４．２２９のセクション５．７．３ ＩＭＳ標準規格を強化する。本明細書には、２つの異なる実施形態が記載されている。第１実施形態は、発信側ＩＭＳネットワークに属していない（すなわち、ホーム加入者システム（ＨＳＳ）１５０でそのようにプロビジョニングされていない）ユーザを伴う。これは、ＩＭＳユーザでないユーザや、ＩＭＳユーザであっても異なるＩＭＳネットワークに属しているユーザ等を含んでもよい。第２実施形態は、発信側ＩＭＳネットワークに属している（すなわち、ＨＳＳでそのようにプロビジョニングされている）ユーザを伴う。この実施形態は、３ＧＰＰ ＴＳ ２４．２２９標準規格にすでに記載されているケースと類似しているが、以下に記載する新たな違いを伴う。

本発明の第１実施形態は、発信側ＩＭＳネットワークに属さないＩＭＳユーザ１１０に代わってＡＳ １４０によって開始される呼のルーティングを可能にする。本実施形態では、ユーザが発信側ネットワークのＩＭＳユーザでない（ＨＳＳでそのようにプロビジョニングされていない）ことから、ＡＳがこの外部ユーザに代わって呼リクエストを開始することができる／できないようにするために、ＳＩＰシグナリング１０１に対して、問い合わせＣＳＣＦ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ ＣＳＣＦ：Ｉ―ＣＳＣＦ）における新たなグローバル・システム・レベル・パラメータが定義される。

動作時、第１実施形態では、ＡＳ １４０が、発信側ネットワークに属していないユーザ１１０に代わって呼リクエストを開始する。特に、ＡＳ １４０は、シグナリング１０１のＳＩＰ ＩＮＶＩＴＥ（ＳＩＰ招待）に、発信側ユーザのパブリックユーザＩＤを表すＰ―Ａｓｓｅｒｔｅｄ―Ｉｄｅｎｔｉｔｙを挿入する。特に、ＡＳは、信頼領域内のＡＳからの発呼におけるハードトークンである「ｏｒｉｇ」パラメータを、最上部のルート（Ｒｏｕｔｅ）ヘッダにおけるＵＲＩに添付する。一部のケースでは、（Ｓｈインタフェース経由でＨＳＳに問い合わせない限り）ユーザがＩＭＳ加入者であるかどうかをＡＳが把握できない可能性がある。そのため、これらのケースにおいて、ＡＳ １４０は、事前に構成されている発信側Ｉ―ＣＳＣＦ １３０にリクエストを送信することができる。

（発信側Ｉ−ＣＳＣＦとして働く）Ｉ−ＣＳＣＦ １３０は、ＨＳＳ １５０に対してＣｘ ＬＩＲを実行する。ユーザ１１０はそのＩＭＳネットワークの加入者でないことから、当該技術分野において周知のとおり、ＨＳＳはＳＩＰ Ｄｉａｍｅｔｅｒエラーを返す。非加入（外部）ユーザ向けの上記定義済みＩ―ＣＳＣＦネットワークサーバ発呼許可、または却下パラメータに設定された値に応じて、Ｉ―ＣＳＣＦ １３０は次のとおりリクエストを許可する、またはしない。パラメータが（外部ユーザについて）「許可（ａｌｌｏｗ）」に設定されている場合、Ｉ―ＣＳＣＦは、リクエスト―ＵＲＩ／ルート（Ｒｅｑｕｅｓｔ―ＵＲＬ／Ｒｏｕｔｅ）ヘッダに従い、適切な着信側Ｉ―ＣＳＣＦ １３２にリクエストをルーティングする。この場合、発信側Ｉ―ＣＳＣＦ １３０は、ＩＭＳトランジットが着信側でのみ定義さている現在の３ＧＰＰ ＴＳ ２４．２２９ リリース７標準規格とは異なり、トランジットＩ―ＣＳＣＦとして機能している。これは、ユーザがそのネットワークのユーザでない場合にＩ―ＣＳＣＦが４０４ （Ｎｏｔ ｆｏｕｎｄ（発見されず））または６０４ （Ｄｏｅｓ ｎｏｔ ｅｘｉｓｔ ａｎｙｗｈｅｒｅ（何処にも存在しない））という不成功のＳＩＰレスポンスを返す現在の標準規格に対する強化である。この新機能は、非ＩＭＳユーザがＦｉｎｄ―ｍｅ ＆ Ｆｏｌｌｏｗ―ｍｅやＣｌｉｃｋ−ｔｏ−Ｄｉａｌのような機能を享受できる等、数々のアプリケーションサービスをＡＳが実行するのに役立つ。パラメータが（外部ユーザについて）「却下（ｎｏｔ ａｌｌｏｗ）」に設定されている場合、Ｉ―ＣＳＣＦはリクエストを拒否する。

ＵＥがＩＭＳ加入者である場合、発信側Ｉ―ＣＳＣＦはまず、発信側ユーザに割り当てられている発信側Ｓ―ＣＳＣＦを見つけ、そこに呼をルーティングする。次に、いったん発信側サービス手順を終えた発信側Ｓ―ＣＳＣＦは、リクエストＵＲＩに基づいて着信側Ｉ―ＣＳＣＦ １３２に呼をルーティングする。

本発明の第２実施形態は、発信側ＩＭＳネットワークに加入しているＩＭＳユーザ１１０に代わってＡＳ １４０によって開始される呼のルーティングについて記載している。この場合、ユーザは発信側ＩＭＳネットワークのＩＭＳユーザである（ＨＳＳ １５０にそのようにプロビジョニングされている）ことから、ユーザ（すなわちパブリックユーザＩＤ）に代わってＡＳが呼リクエストを開始することができる、またはできないようにするために、ユーザのサービスプロファイル内の新しいＳＩＰパラメータが定義される。なお、新しいＳＩＰパラメータは、第１実施形態で定義されたグローバルパラメータとは異なるものの、その同じ機能を実行することから、本明細書では「サービスパラメータ」と称される。

動作時、ＡＳ １４０は、ＩＭＳユーザ１１０に代わって呼リクエストを開始する。特に、ＡＳ １４０は、シグナリング１０１のＳＩＰ ＩＮＶＩＴＥに、ユーザの（初期ＩＭＳ登録に基づく）パブリックユーザＩＤを表すＰ―Ａｓｓｅｒｔｅｄ―Ｉｄｅｎｔｉｔｙを挿入する。特に、ＡＳは、信頼領域内のＡＳからの発呼におけるハードトークンである「ｏｒｉｇ」パラメータを、最上部のルートヘッダにおけるＵＲＩに添付する。既存の３ＧＰＰ ＴＳ ２４．２２９標準規格により、リクエストが代理生成されたパブリックユーザＩＤのＳ―ＣＳＣＦをＡＳが把握しているかどうかに応じて、２つの異なるケースがある。リクエストが代理生成されたパブリックユーザＩＤが（未登録ケースでの問い合わせによって）登録またはホストされているそのユーザ用のＳ―ＣＳＣＦのアドレスをＡＳが把握していれば、ＡＳ １４０はリクエストをＳ―ＣＳＣＦ １３０に直接送信する。ただし、リクエストが代理生成されたパブリックユーザＩＤが（未登録ケースでの問い合わせによって）登録またはホストされているそのユーザ用のＳ―ＣＳＣＦのアドレスをＡＳが把握していなければ、ＡＳは、Ｉ―ＣＳＣＦ等、パブリックユーザＩＤのネットワークのエントリポイントにリクエストを送信する。

第１のケースでは、（発信側Ｓ―ＣＳＣＦとして働く）Ｓ―ＣＳＣＦ １３０が、Ｐ―Ａｓｓｅｒｔｅｄ―Ｉｄｅｎｔｉｔｙに明示されるユーザのサービスプロファイルをダウンロードし、ユーザの上記定義済みサービスプロファイルにおける新しいＳＩＰパラメータの設定値に応じて、リクエストを許可するか、またはしない。

第２のケースでは、（発信側Ｉ―ＣＳＣＦとして働く）Ｉ―ＣＳＣＦ １３０がＨＳＳ １５０に対してＣｘ ＬＩＲ（位置情報リクエスト（Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ））を実行する。（Ｐ―Ａｓｓｅｒｔｅｄ―Ｉｄｅｎｔｉｔｙによって明示された）発信側ユーザがローカルＩＭＳネットワークユーザでないと、ＨＳＳは、上記定義済みの新しいＩ―ＣＳＣＦ ＳＩＰパラメータの設定値に応じて適切なＤｉａｍｅｔｅｒエラー（ｕｓｅｒ ｎｏｔ ｆｏｕｎｄ）を表すＣｘ ＬＩＡメッセージを返し、リクエストを許容する／しない。発信側ユーザがローカルＩＭＳネットワークユーザであり、かつＳＩＰパラメータが（そのユーザについて）「許可」に設定されている場合、ＨＳＳ １５０は現在の標準規格に従ってＣｘ ＬＩＡ（Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ａｕｔｈｏｒ）メッセージを返す。ＳＩＰパラメータが（そのユーザについて）「却下」に設定されている場合、ＨＳＳは、適切なＤｉａｍｅｔｅｒエラー（リクエスト却下（ｒｅｑｕｅｓｔ ｎｏｔ ａｌｌｏｗｅｄ））を明示するＣｘ ＬＩＡメッセージを返す。この場合、Ｉ―ＣＳＣＦ １３０は、ＡＳ １４０からのリクエストを拒否する。

オプションとして、発信側ユーザがローカルＩＭＳユーザであり、ユーザのサービスプロファイルが、そのユーザの代理発呼が許可されているネットワークが存在しないことを明示している場合には、現在の標準規格に従い、エラーすることなくＣｘ ＬＩＡメッセージを返すことも可能であり、割り当てられたＳ―ＣＳＣＦ １３０がＰ―Ａｓｓｅｒｔｅｄ―Ｉｄｅｎｔｉｔｙに明示されるユーザのサービスプロファイルをダウンロードするとき、上記定義済みの新しいＳＩＰパラメータの設定値に応じて、Ｓ―ＣＳＣＦがリクエストを許可するか、またはしない。

本明細書に記載されている各種モジュール間のインタフェースは、例えば関数呼び出し等の形態をとるソフトウェアインタフェースとして存在するか、リアルタイム割込み処理やその他のソフトウェア関連処理という形態をとってもよいことは、当業者によって理解されるであろう。あるいは、機能とインタフェースとが、ハードウェアに存在しても、ハードウェアとソフトウェアとの組み合せであってもよい。ベアラ要件は、アプリケーションフローを本明細書で述べられているとおりに移送するためにベアラを提供している例示的な無線アクセスネットワークを含む。本明細書に記載されているサービスをサポートするベアラ要件は、ＴＳ ２４．２２９のセクション５．７．３と整合している。

本発明の特徴の多数が、アプリケーションプログラム等のソフトウェアプログラムや、一連の相互通信ソフトウェアプログラム、アプリケーション、ルーチン、モジュール、オペレーティングシステム等で実装されることは、これまでの記述から理解されるであろう。さらに、機能の多くは、一連のステップ等を伴う方法または手順として実行することができる。

図２は、インターネット・プロトコル・マルチメディア・コア・ネットワーク・サブシステム（ＩＭＳ）内のアプリケーションサーバによる発呼のための例示的な方法を示す。この方法は、ユーザにパブリックユーザＩＤを与えるという第１のステップ２００を含む。次のステップ２０２は、アプリケーションサーバがパブリックユーザＩＤに変わって呼リクエストを開始することを許可するべきか却下するべきかを表すサービスパラメータを提供することを含む。次のステップ２０４は、ユーザのパブリックユーザＩＤを表すＰ―Ａｓｓｅｒｔｅｄ―Ｉｄｅｎｔｉｔｙ（ＰＡＩ）を挿入することを含む。次のステップ２０６は、最上部のルートヘッダにおけるＵＲＩに発呼パラメータを添付することを含む。次のステップ２０８は、ユーザに代わって呼を開始することを含む。

次のステップ２２４は、リクエストがパブリックユーザＩＤ（すなわちＰＡＩ）に代わって生成される場合において、ユーザが発信側ＩＭＳネットワークの加入者であるかどうか、及びそのユーザ用のサービング呼セッション制御機能（Ｓ―ＣＳＣＦ）のアドレスをアプリケーションサーバが把握しているかどうかをアプリケーションサーバが判断する（２２４）ことを含む。

ＡＳがＰＡＩ Ｓ―ＣＳＣＦアドレスを把握している場合、ステップ２０２のサービスパラメータは、そのユーザのサービスプロファイルに含まれている。このプロファイルは、その後ユーザのホーム加入者システムからダウンロードされる（２２８）。この場合、ユーザ・サービス・プロファイル・フラグは、ユーザプロファイルの一部となり、ＨＳＳからＣｘ Ｄｉａｍｅｔｅｒインタフェースを介してＳ―ＣＳＣＦに届けられる。次のステップ２２６は、ＡＳがサービング呼セッション制御機能にリクエストを直接送信することを含む。次のステップ２２８は、サービスパラメータを取得するために、サービング呼セッション制御機能（Ｓ―ＣＳＣＦ）によってＰ―Ａｓｓｅｒｔｅｄ―Ｉｄｅｎｔｉｔｙに明示されるユーザのサービスプロファイルをダウンロードすることを含む。ＰＡＩサービスプロファイルのサービスパラメータが「許可」に設定されている（２３０）場合、次のステップ２３２は、ユーザに代わってアプリケーションサーバによって開始された呼をブロック解除することにより、アプリケーションサーバがユーザのための呼を開始するリクエストを許可することを含む。サービスパラメータが「却下」に設定されている（２３０）場合、次のステップ２３１は、ユーザに代わってアプリケーションサーバによって開始された呼をブロックすることにより、アプリケーションサーバがユーザのための呼を開始するリクエストを拒否することを含む。

ユーザが発信側ＩＭＳネットワークの加入者でないかどうかを判断できない（２２４）場合、あるいはリクエストが代理生成されたパブリックユーザＩＤ（すなわちＰＡＩ）用のサービング呼セッション制御機能（Ｓ―ＣＳＣＦ）アドレスをアプリケーションサーバが把握していない（２２４）場合、ステップ２０２のサービスパラメータは、問い合わせサービング呼セッション制御機能におけるグローバル・システム・レベル・パラメータと定義される。グローバルパラメータは、Ｉ―ＣＳＣＦプロビジョニングに対してローカルである。

次のステップ２３４は、パブリックユーザＩＤのネットワークのエントリポイント、すなわち、事前にプロビジョニングされている問い合わせ呼セッション制御機能（Ｉ―ＣＳＣＦ）にリクエストを送信して、ユーザがＩＭＳ加入者であるかどうかを判断することを含む。次のステップ２３６は、ユーザのローカルネットワークのホーム加入者システム（ＨＳＳ）に対してＣｘ位置情報リクエストを実行することを含む。このステップは、成功または失敗（すなわちエラーの有無）を表すＣｘ位置情報応答（Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ａｎｓｗｅｒ：Ｃｘ ＬＩＡ）メッセージを返す。

成功の場合、次のステップ２２１は、ＨＳＳレスポンス（発信側ユーザ用に割り当てられたＳ―ＣＳＣＦ）に明示されたとおりに適切な発信側サービング呼セッション制御機能（Ｓ―ＣＳＣＦ）に呼をルーティングすることを含む。この流れはステップ２２８で続く。

失敗の場合、すなわち、ＩＭＳユーザでないことを明示する「ｕｓｅｒ ｎｏｔ ｆｏｕｎｄ」エラーをＨＳＳが返した場合（注：この流れは、ＩＭＳユーザのプロファイルでユーザ・レベル・ネットワークの発信が許可されているか却下されているかに関係なく、ＩＭＳユーザに対して常に肯定的なレスポンスを返す１つのオプションを示す。ＨＳＳがＩ―ＣＳＣＦ Ｃｘ ＬＩＲクエリの受信時にユーザのプロファイルを調べる別のオプションは、このフローチャートに示されていない）には、問い合わせ呼セッション制御機能が、非ＩＭＳユーザによる発呼を許可するかどうかを判断する（２１８）。許可しない場合には、発信側Ｉ―ＣＳＣＦが、ユーザに代わってアプリケーションサーバによって開始される呼をブロックすることにより、そのユーザのために呼を開始するというアプリケーションサーバによるリクエストを拒否する（２３１）。許可する場合には、発信側Ｉ―ＣＳＣＦが、Ｒｅｑｕｅｓｔ―ＵＲＬに従って適切な着信側問い合わせ呼セッション制御機能（Ｉ―ＣＳＣＦ）に呼をルーティングする（２２２）。

要するに、本発明は、アプリケーションサーバが任意のネットワークユーザに代わって呼を開始する方法を提供する。そのために、Ｉ―ＣＳＣＦと、ＨＳＳのユーザのサービスプロファイルで新しいパラメータを提供して、ＡＳがパブリックユーザＩＤに代わって、さらには非ＩＭＳユーザのＩＤに代わって呼リクエストを開始することを許可／却下する。新しい呼処理メカニズムがＩ／Ｓ―ＣＳＣＦで導入されており、上記の新しいサービスパラメータを利用して、ＩＭＳおよび非ＩＭＳ加入者のためにＡＳが呼を処理することを許可／却下する。これらのルーティングストリング／インジケータをＨＳＳ上で加入者またはＰＳＩとしてプロビジョニングする必要なしに、ネットワークが所有するルーティングインジケータを処理することにより、このメカニズムは、ＩＭＳネットワークに数々の魅力ある先進のサービス機能を付与するであろう。

本発明には、信頼領域という概念の外にいるユーザに代わってＡＳが開始した呼をブロック、またはブロック解除できる機能を提供するという利点がある。信頼領域という概念は現在の標準規格で定義されてはいるものの、この概念は、ＩＰ ＩＭＳネットワークをトランジットする必要性から、着信側ネットワークで回路間ネットワーク呼としてトランジット機能を許可しているに過ぎず、本発明に記載しているような、ユーザごとに呼をブロック／ブロック解除するためのプロビジョニングを許可してはいない。加えて、本発明は、従来技術とは異なり、発信側ネットワークでトランジット機能を実行する。

本明細書に表示および記載されている手順と方法とは、記載の順序とは異なる順序で実行してもよい。図面に描かれている特定の手順、機能、および動作は、本発明の１つ以上の実施形態を示しているに過ぎず、当業者にとっては他の実装が明らかであろう。図面は、当業者が理解でき、適切に実施できる本発明の各種実装形態を示すことを目的としている。同じ目的を達成するために計算された任意の構成によって、提示されている具体的な実施形態を代用してもよい。

本発明は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせを含む任意の適切な形態で実装してよい。本発明は、１つ以上のデータプロセッサおよび／またはデジタル信号プロセッサで実行するコンピュータソフトウェアとして、任意で部分的に実装してもよい。本発明の実施形態の要素と構成部分とは、任意の適切な方法で物理的、機能的、そして論理的に実装してよい。機能は、単一のユニットまたは複数のユニットで実装しても、あるいは他の機能ユニットの一部として実装してもよい。このように、本発明は、単一ユニットで実装してもよく、異なるユニットとプロセッサとの間で物理的および機能的に分散していてもよい。

本発明は、一部の実施形態と関連付けて記載したものの、本明細書に記載された具体的な形態のみに制限することを意図するものではなく、本発明の範囲は、添付の請求項によってのみ制限される。さらに、特定の実施形態と関連付けて特徴が記載されているように見えるかもしれないが、当業者であれば、記載されている実施形態の各種特徴は本発明に従って組み合わせてよいことを認識するであろう。請求項において、「備える」および「含む」という用語は、他の要素またはステップの存在を除外しない。

さらに、個々に列記した複数の手段、要素、または方法のステップは、例えば単一のユニットまたはプロセッサによって実装してもよい。加えて、個々の特徴は異なる請求項に含まれることがあるものの、これらは有利に組み合わせられる可能性があり、異なる請求項における包含は、特徴の組み合せが可能でない、および／または有利でないことを示唆するものではない。また、請求項の１つの範疇にある特徴を包含することは、この範疇への限定を示唆するものではなく、むしろその特徴が他の請求項の範疇に適宜等しく適用可能であることを示している。

さらに、請求項における特徴の順序は、それらの特徴を作用させるべき具体的な順序を示唆するものではなく、特に方法クレームにおける個々のステップの順序は、それらのステップがこの順序で実行されなければならないことを示唆するものではない。むしろこれらのステップは、任意の適切な順序で実行してよい。加えて、単数での言及は複数を排除するものではない。したがって、「１つの」、「第１の」、「第２の」等は複数を除外しない。

Claims (10)

1. インターネット・プロトコル・マルチメディア・コア・ネットワーク・サブシステム（ＩＭＳ）におけるアプリケーションサーバによる発呼のための方法であって、前記方法は、
   ユーザにパブリックユーザＩＤを提供するステップと、
   前記パブリックユーザＩＤに代わって前記アプリケーションサーバが呼リクエストを開始することを許可するか、または却下するかを明示するサービスパラメータを提供するステップと
   を含み、
   前記アプリケーションサーバが呼リクエストを開始することを前記サービスパラメータが許可した場合には、前記ユーザに代わって前記アプリケーションサーバによって開始された呼をブロック解除し、
   前記アプリケーションサーバが呼リクエストを開始することを前記サービスパラメータが却下した場合には、前記ユーザに代わって前記アプリケーションサーバによって開始された呼をブロックする、方法。
2. 前記ユーザが発信側ＩＭＳネットワークに属していないことを判断するステップをさらに含み、前記サービスパラメータが、問い合わせ呼セッション制御機能におけるグローバル・システム・レベル・パラメータである、請求項１に記載の方法。
3. 前記ユーザが発信側ＩＭＳネットワークに属していることを判断するステップをさらに含み、前記サービスパラメータが、前記ユーザのホーム加入者システムのユーザ・サービス・プロファイルにおけるセッション開始プロトコル・パラメータである、請求項１に記載の方法。
4. 前記ユーザに代わって呼を開始するステップと、
   前記ユーザの前記パブリックユーザＩＤを表すＰ―Ａｓｓｅｒｔｅｄ―Ｉｄｅｎｔｉｔｙを挿入するステップと、
   最上部のルートヘッダにおけるＵＲＩに発呼パラメータを添付するステップと
   をさらに含む、請求項１に記載の方法。
5. 前記ユーザがＩＭＳ加入者であるかどうかを判断しないステップをさらに含み、事前に構成された問い合わせ呼セッション制御機能にリクエストを送信して、前記ユーザがＩＭＳ加入者であるかどうかを判断するステップをさらに含む、請求項１に記載の方法。
6. 前記ユーザのホーム加入者システムに対してＣｘ位置情報リクエストを実行するステップと、
   前記ホーム加入者システムによってエラーメッセージを返すステップと、
   前記グローバル・システム・レベル・パラメータが「許可」に設定されている場合に、リクエスト―ＵＲＩ／ルートヘッダに従って適切な着信側問い合わせ呼セッション制御機能に前記リクエストをルーティングするステップと、
   前記グローバル・システム・レベル・パラメータが「却下」に設定されている場合に、前記問い合わせ呼セッション制御機能が前記リクエストを拒否するステップと
   をさらに含む、請求項５に記載の方法。
7. 前記ユーザ用のサービング呼セッション制御機能のアドレスを前記アプリケーションサーバが把握しており、前記パブリックユーザＩＤに代わって前記リクエストが生成される場合に、前記サービング呼セッション制御機能に前記リクエストを直接送信するステップをさらに含む、請求項１に記載の方法。
8. 前記サービング呼セッション制御機能によって前記Ｐ―Ａｓｓｅｒｔｅｄ―Ｉｄｅｎｔｉｔｙにおいて明示される前記ユーザの前記サービスプロファイルをダウンロードするステップと、
   前記サービスパラメータが「許可」に設定されている場合に、前記リクエストを許可するステップと、
   前記サービスパラメータが「却下」に設定されている場合に、前記リクエストを拒否するステップと
   をさらに含む、請求項７に記載の方法。
9. 前記ユーザ用のサービング呼セッション制御機能のアドレスを前記アプリケーションサーバが把握しておらず、前記パブリックユーザＩＤに代わって前記リクエストが生成される場合に、前記パブリックユーザＩＤのネットワークのエントリポイントに前記リクエストを送信するステップをさらに含む、請求項１に記載の方法。
10. インターネット・プロトコル・マルチメディア・コア・ネットワーク・サブシステムにおけるアプリケーションサーバによる発呼のためのシステムであって、前記システムは、
    パブリックユーザＩＤを有する通信装置と、
    前記アプリケーションサーバが前記パブリックユーザＩＤに代わって呼リクエストを開始することを許可するか、または却下するかどうかを明示するサービスパラメータと、
    前記サービスパラメータに応答して発呼を制御するプロキシサーバと
    を備え、
    前記サービスパラメータによって前記アプリケーションサーバが呼リクエストを開始することが許可された場合には、前記プロキシサーバが、前記ユーザに代わって前記アプリケーションサーバによって開始された呼をブロック解除し、
    前記サービスパラメータによって前記アプリケーションサーバが呼リクエストを開始することが却下された場合には、前記プロキシサーバが、前記ユーザに代わって前記アプリケーションサーバによって開始された呼をブロックする、システム。

Images