JP2008518536A - Ｉｐマルチメディア・サブシステムにアクセスする方法および装置 - Google Patents

Abstract

ＩＭＳ非対応端末によるＩＰマルチメディア・サブシステム（ＩＭＳ）サービスへのアクセスを支援する方法である。本方法は、ＩＭＳ非対応端末をホームＩＭＳゲートウェイに登録する工程と、その登録に応えて、ホームＩＭＳゲートウェイにあるＵＭＴＳ用ＩＣカードの汎用ＳＩＭアプリケーションから取得した情報を使用して、前述した端末の代わりにホームＩＭＳゲートウェイが、ＩＭＳと協力してＩＭＳ登録を実行する工程とを備える。

Description

本発明は、ＩＰマルチメディア・サブシステムにアクセスする方法および装置に関し、より詳細には、家庭または小規模事業所（必ずしもこのような場所に限定されない。）からＩＰマルチメディア・サブシステムにアクセスするのに適した方法および装置に関する。

ＩＰマルチメディア（ＩＰＭＭ）サービスは、同じセッション内で音声、映像、メッセージ、データ及びその他の動的な組み合わせを提供するサービスである。組み合わせ可能な基本的アプリケーションとメディアの数が増加することにより、エンドユーザに提供されるサービス数は増加し、ユーザ間で通信により享受される経験（通信エクスペリエンス）が豊かのものになるであろう。このことは、以下で詳細を検討するいわゆる「組み合わせＩＰマルチメディア」サービスを含む、個人に合わせた豊かなマルチメディア通信サービスの新世代をもたらすであろう。

ＩＰマルチメディア・サブシステム（ＩＭＳ）は、第三世代パートナーシップ・プロジェクト（３ＧＰＰ）が規定した技術であり、３Ｇ移動体通信ネットワーク（３ＧＰＰ ＴＳ２３．２２８およびＴＳ２４．２２９リリース５およびリリース６）上でＩＰマルチメディア・サービスを提供する。ＩＭＳは、サービスの統合およびサービス間の相互作用を通して、エンドユーザ対エンドユーザの通信エクスペリエンスを豊かにするための主要な機能を提供する。ＩＭＳは、ＩＰベースのネットワーク上で今までのものとはまったく違う豊かな個人対個人（クライアント対クライアント）通信および個人対コンテンツ（クライアント対サーバ）通信を可能にする。ＩＭＳは、ユーザ端末間（またはユーザ端末とウェブサーバとの間）に呼またはセッションを確立して制御するために、セッション開始プロトコル（ＳＩＰ）を使用する。ＳＩＰシグナリングで運ばれるセッション記述プロトコル（ＳＤＰ）は、セッションのメディアコンポーネントを記述してネゴシエートするために使用される。ＲＴＰ／ＲＴＣＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ ＰｒｏｔｏｃｏｌおよびＲｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＭＳＲＰ（Ｍｅｓｓａｇｅ Ｓｅｓｓｉｏｎ Ｒｅｌａｙ Ｐｒｏｔｏｃｏｌ（ＭＳＲＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）などの他のプロトコルも、メディアの伝送と制御に使用される。ＩＭＳはアクセスネットワークを必要とし、これは、通常、第二世代／第三世代汎用パケット無線サービス（ＧＰＲＳ）／パケット交換（ＰＳ）ネットワークであるが、固定ブロードバンドまたはＷｉＦｉなどの他のアクセスネットワークであってもよい。図１は、ＧＰＲＳ／ＰＳ（パケット交換）アクセスネットワークの場合に、移動体ネットワーク・アーキテクチャにＩＭＳがどのように当てはまるかの概要を図解したものである。

欧州電気通信標準化機構（ＥＴＳＩ）のＴＩＳＰＡＮワーキンググループは、ＩＭＳに基づく固定ネットワーク向け次世代ネットワーク（ＮＧＮ）に関する提案に、現在、取組んでいる。このプロジェクトの一環として、非ＩＭＳ端末からＩＭＳサービスにアクセスすることを可能にする、いわゆるホームＩＭＳゲートウェイ（ＨＩＧ）の検討も行われるであろう。ＳＩＰ端末でもよいしそうでなくてもよい相当数のＩＭＳ非対応端末を使用して、ユーザがＩＭＳサービスにアクセスを希望する可能性のある家庭および小規模事業所環境において、ＨＩＧは利用されるようになると期待されている。非ＩＭＳでＳＩＰ対応端末の例に、ＳＩＰ電話機およびＰＣがあり、一方ＳＩＰ機能を持たない非ＩＭＳ端末の例に、ＤＥＣＴ電話機を含むレガシー電話機がある。ＨＩＧは、相互接続性問題（例えば、ＳＩＰとユーザ装置が必要とする他のシグナリング・プロトコルとの間の変換）を解決するためにＳＩＰゲートウェイを有するであろう。

ＨＩＧに関する現在の提案は、３ＧＰＰ技術仕様書３３．２０３に規定されるＩＭＳに対する現行アクセス・セキュリティ要件とある程度相反する。この要件は、ＩＭＳにアクセスする各端末がＩＭＳ ＳＩＭ（ＩＳＩＭ：ＩＭＳ加入者識別ＩＤモジュール）アプリケーションにアクセスすることを条件としている。ＩＳＩＭは、ネットワークオペレータに対して加入者を証明し、ネットワークで使用可能なサービスへのアクセスを正当とするのに必要な、加入者識別情報および他の情報を格納するモジュールである。ＩＳＩＭアプリケーションは、汎用ＩＣカード（ＵＩＣＣ、現在のＧＳＭ ＳＩＭカードに類似）により提供される。もちろん、レガシー装置などの非ＩＭＳ端末は、必要なＵＩＣＣカードリーダまたはＩＭＳ機能を有しないであろう。

アクセス・セキュリティ要件を満足しながら、非ＩＭＳ端末からＩＭＳサービスへのアクセスを可能にする課題の解決策は、非ＩＭＳ端末のおのおのにＩＳＩＭアプリケーションを有するＵＩＣＣを割当てることである。次いでユーザは、その端末をＩＭＳサービスのアクセスに使用したいとき、特定の非ＩＭＳ端末に関係するＵＩＣＣをＨＩＧに挿入しなければならない。この解決策は、柔軟性、便宜性および費用の点で明らかに不利である。

本発明の第１の実施形態では、ＩＭＳ非対応端末を使用してＩＰマルチメディア・サブシステム（ＩＭＳ）サービスにアクセスするのを支援する方法が提供される。その方法は、
ホームＩＭＳゲートウェイにＩＭＳ非対応端末を登録する工程と、
その登録に応えて、ホームＩＭＳゲートウェイにあるＵＭＴＳ用ＩＣカードの汎用ＳＩＭアプリケーションから取得した情報を使用して、前述したＩＭＳ非対応端末とホームＩＭＳゲートウェイとＩＭＳとの間でＩＭＳ登録を実行する工程と
を備える。

本発明の実施形態は、実際のところホームＩＭＳゲートウェイにＩＭＳ登録を委託する。したがって、ＩＭＳサービスを使用したいと望む各端末が、ＩＳＩＭアプリケーションを格納するＵＩＣＣカードにアクセスすることは必ずしも必要でない。

ホームＩＭＳゲートウェイは、ＵＩＣＣ上の前述したＩＳＩＭへのインターフェースを有するＳＩＰバックトゥバック・ユーザエージェントを備えるのが好ましい。前述したＩＭＳ非対応端末がＳＩＰ端末の場合、ホームＩＭＳゲートウェイへの端末の登録は、端末とＳＩＰバックトゥバック・ユーザエージェントとの間のＳＩＰ登録実施工程を備える。端末は、ＳＩＰバックトゥバック・ユーザエージェントに、端末に関係付けられたパブリック・ユーザＩＤを知らせてもよい。代わりに、端末はローカルＩＤを提供してもよく、そのローカルＩＤは、ＳＩＰバックトゥバック・ユーザエージェントによりあらかじめ格納されたパブリック・ユーザＩＤにマッピングされる。前述したＩＭＳ登録は、ＩＭＳネットワークに端末に関係付けられたパブリック・ユーザＩＤの通知を含む、バックトゥバック・ユーザエージェントとＩＭＳネットワークとの間のＳＩＰ登録の実行工程を備える。

ＩＭＳ非対応端末がＳＩＰ端末でない場合、ホームＩＭＳゲートウェイに端末を登録する工程は、例えばループ形成の検出を含み、ゲートウェイと端末との最初の接続に続いて実行されてもよい。すでに接続されている端末に関しては、登録はＨＩＧの電源オン時に行われてもよい。ゲートウェイは、非ＳＩＰ端末に割当てられＩＭＳ登録時に使用されるデフォルトのパブリック・ユーザＩＤを、自装置の中にあらかじめ格納しておいてもよい。より好ましいのは、ＵＩＣＣの前述したＩＳＩＭとのインターフェースを有するＳＩＰゲートウェイにより登録が実行されることである。ＳＩＰゲートウェイは、ＳＩＰとこれら非ＳＩＰ端末が使用するプロトコルとの間のプロトコル変換を実行する。

本発明の第２の様相によれば、ＩＭＳ非対応端末からＩＰマルチメディア・サブシステム（ＩＭＳ）サービスにアクセスするのを支援する、ホームＩＰマルチメディア・サブシステム・ゲートウェイを操作する方法が提供される。その方法は、
ホームＩＭＳゲートウェイにＩＭＳ非対応端末を登録する工程と、
前述した登録に応えて、ホームＩＭＳゲートウェイにあるＵＭＴＳ用ＩＣカードの汎用ＳＩＭアプリケーションから情報を取得する工程と、前述した端末の代わりにこの情報でＩＭＳにＩＭＳ登録を実行する工程と
を備える。

本発明の第３の実施形態によれば、ＩＭＳ非対応端末からＩＰマルチメディア・サブシステム（ＩＭＳ）サービスにアクセスするのを支援する用途向けに構成された、ホームＩＰマルチメディア・サブシステム・ゲートウェイが提供される。その装置は、
ゲートウェイと前述したＩＭＳ非対応端末とを接続する少なくとも１つのインターフェースと、
ＵＩＣＣカードからＩＳＩＭアプリケーションデータを読み出すためのＵＩＣＣカードリーダと、
ゲートウェイにＩＭＳ非対応端末を登録する第１の処理手段と、
ゲートウェイに登録されたＩＭＳ非対応端末をＩＭＳに登録する第２の処理手段と
を備える。

ゲートウェイと前述したＩＭＳ非対応端末とを接続するインターフェースは、例えばゲートウェイとブラックフォン（黒電話機）若しくはＤＥＣＴ電話機などのレガシー装置とを接続する回線インターフェースまたはＬＡＮインターフェース若しくはＷＬＡＮインターフェースであってもよい。

第１および第２の処理手段は、ＩＭＳが使用するセッション開始プロトコル（ＳＩＰ）とＩＭＳ非対応端末が使用するプロトコルとの間のプロトコル変換を実行するＳＩＰゲートウェイを実装する手段を備えてもよい。非ＳＩＰ端末に対しては、ＳＩＰゲートウェイは、ＩＳＩＭのプライベート・ユーザＩＤに関係するデフォルト・パブリック・ユーザＩＤをＩＭＳに登録してもよい。

第１および第２の処理手段は、ＳＩＰ端末に対してはＳＩＰサーバの機能を果たし、ＩＭＳに対してはＳＩＰクライアントとして機能するＳＩＰバックトゥバック・ユーザエージェントを備えてもよい。ＳＩＰバックトゥバック・ユーザエージェントは、ＩＳＩＭのプライベート・ユーザＩＤに関係する個人用パブリック・ユーザＩＤをＩＭＳに登録してもよい。

前述したように、図１の一般的なＩＭＳアーキテクチャに、いわゆるホームＩＭＳゲートウェイ（ＨＩＧ）を導入することを提案している。図２は、家庭または小規模事業所内に設置され、レガシー装置とＳＩＰ対応端末の両方を含む相当数の端末に便宜をもたらすＨＩＧ（図では「住宅用ゲートウェイ」と呼ぶ）を図解する。図３は、様々な外部ユーザ端末とのインターフェースとともに、ＨＩＧの機能アーキテクチャを詳細に図解する。特に、ワイドエリアネットワーク（ＷＡＮ）／ローカルエリアネットワーク（ＬＡＮ）インターフェースが、ＨＩＧをＩＭＳに接続するために使用される。

ＳＩＰ端末でない様々なレガシー端末は、ＳＩＰゲートウェイに接続する回線インターフェースを介してＨＩＧに接続する。レガシー端末の例に、ＤＥＣＴ電話機および従来の電話機（「黒電話機」）がある。ＨＩＧは、セッション開始プロトコル（ＳＩＰ）ゲートウェイ（３ＧＰＰ ＴＳ２４．２２９およびＩＥＴＦ ＲＦＣ３２６１に準拠して実装）を有する。ＳＩＰゲートウェイは、様々なクライアント端末のシグナリング・プロトコルとＩＭＳが使用するＳＩＰプロトコルとの間の相互作用を可能にする。例えば、ＳＩＰゲートウェイは、黒電話機が使用するＩＳＤＮベースのシグナリング・プロトコルとＳＩＰとの間の変換を提供してもよい。ＳＩＰゲートウェイは、ＷＡＮ／ＬＡＮインターフェースに接続している。

デスクトップＰＣおよびノートＰＣならびにＳＩＰ電話機などのＩＭＳ対応ＳＩＰ端末は、ローカルエリアネットワーク（ＬＡＮ）および／または無線ローカルエリアネットワーク（ＷＬＡＮ）にアタッチ（接続）しており、それらネットワークに、ＨＩＧもＬＡＮ／ＷＬＡＮインターフェースを介して接続している。ネットワーク・アドレス変換（ＮＡＴ）／ファイアウォール（ＦＷ）レイヤが、ＨＩＧ内のアドレスのマッピングを提供するために使用される。ＮＡＴ／ＦＷレイヤは、ＷＡＮ／ＬＡＮインターフェースに接続している。これらの各端末は、それぞれのＩＳＩＭアプリケーションを格納する自端末のＵＩＣＣを有している。

ＩＳＩＭアプリケーションにアクセスできないＩＭＳ非対応ＳＩＰ端末も、端末のＬＡＮ／ＷＬＡＮインターフェースとＨＩＧのＬＡＮ／ＷＬＡＮインターフェースを介してＨＩＧに接続している。これらの端末に関するＩＭＳサービスへのアクセスは、ＮＡＴ／ＦＷエンティティを有するＳＩＰバックトゥバック・ユーザエージェント（Ｂ２ＢＵＡ）が支援する。ＳＩＰ Ｂ２ＢＵＡは、ユーザ装置に対してはＳＩＰサーバの機能を果たし、ＩＭＳに対してはＳＩＰクライアントとしての機能を果たす。

ＳＩＰ Ｂ２ＢＵＡとＳＩＰゲートウェイの両方とも、ＵＩＣＣに格納されるＩＳＩＭアプリケーションとのインターフェースを有する。このＵＩＣＣは、ＨＩＧハードウェアから取り外し可能であってもよいし、ＨＩＧに永久的に固定されてもよい。ＩＳＩＭアプリケーションは、ＨＩＧを介してＩＭＳに接続する非ＩＳＩＭ端末のすべてが利用可能であり、すべてに有効である。自端末のＩＳＩＭアプリケーションにアクセスできる端末は、ＨＩＧ内のＩＳＩＭをもちろん使用せず、上記のようにＨＩＧのＮＡＴ／ＦＷ機能だけを使用する。続く検討の中では、ＩＳＩＭアプリケーションのすべて、すなわちＨＩＧが利用可能なアプリケーションとユーザ端末装置が利用可能なアプリケーションとは、１回の加入申し込みでＩＭＳに関係付けられることに注意。

ＨＩＧの動作をさらに検討する前に、プライベート・ユーザＩＤおよびパブリック・ユーザＩＤの概念をまず導入する。これらはＩＭＳの動作に本質的に必要であり、３ＧＰＰ ＴＳ２３．２２８ ６．７．０で検討されている。プライベート・ユーザＩＤは、ＩＳＩＭに「結びついた」ＩＤであり、加入者を証明し正当とするために使用される。プライベート・ユーザＩＤは、サードパーティには通常開示されておらず、ＧＳＭネットワークで使用される国際移動電話加入者識別番号（ＩＭＳＩ）にいくぶん類似している。他方パブリック・ユーザＩＤは、ＩＭＳサービスに参加する目的で加入者および／またはそのユーザ装置を識別するために使用され、電子メールアドレスまたは電話番号にいくぶん類似している。パブリック・ユーザＩＤは、例えばＩＭＳサービス・セッション要求の宛先を識別するために使用される。加入者は、１つのプライベート・ユーザＩＤに関係付けられた幾つかのパブリック・ユーザＩＤを有してもよいし、それに対して所与の加入申し込みに関係付けられた異なる複数のプライベート・ユーザＩＤが、共通のパブリック・ユーザＩＤを共用してもよい。ＩＭＳ登録中に認証が成功したと仮定すると、ＩＭＳは加入者に関係付けられたパブリック・ユーザＩＤの通知を受ける。

図４は、図３のＨＩＧを使用して実装してもよい、パブリック・ユーザＩＤとプライベート・ユーザＩＤとのマッピングを図解する。この例では、同一のＩＭＳ加入申し込みに関係付けられた２つのプライベート・ユーザＩＤがある。「２３４１５０１２３４５６＠ｏｐｅｒａｔｏｒ．ｎｅｔ」は、幾つかのＳＩＰ対応ユーザ端末装置のＩＳＩＭに格納されているプライベート・ユーザＩＤであり、「２３４１５０６５４３２１＠ｏｐｅｒａｔｏｒ．ｎｅｔ」は、ＨＩＧのＩＳＩＭに格納されているプライベート・ユーザＩＤである。

デフォルト・パブリック・ユーザＩＤは、加入者に関係付けられていて、ＨＩＧを介してＩＭＳにアクセスし、加入申し込みを所有する家庭または小規模事業所を識別するグループＩＤと見なすことができる。デフォルト・パブリック・ユーザＩＤは、ＨＩＧに格納され、ＨＩＧ内のＩＳＩＭのプライベート・ユーザＩＤ２３４１５０６５４３２１＠ｏｐｅｒａｔｏｒ．ｎｅｔとだけ、ＳＩＰ Ｂ２ＢＵＡで関係付けられている。少なくともＳＩＰ非対応端末のすべて、すなわち関係するパブリック・ユーザＩＤをＨＩＧに通知することができない端末は、他のサードパーティのＩＭＳユーザがデフォルト・パブリックＩＤを使用して電話を掛けるとき、そのユーザから着信可能であるべきである。図４の例では、デフォルト・パブリック・ユーザＩＤは、ｓｍｉｔｈ＠ｏｐｅｒａｔｏｒ．ｎｅｔである。このデフォルト・パブリック・ユーザＩＤは、この例では「＋４４１１３１１１１２３４５６」など、Ｅ．１６４番号の形態で非開示のパブリックＩＤに関係付けることができる。非開示の回線ＩＤはネットワーク内で設定されており、Ｂ２ＢＵＡは登録手続きの一部としてこの回線ＩＤをダウンロードする。

ユーザ（例えば、家族の一員）Ａｌｉｃｅ Ｓｍｉｔｈは、２つの端末を連絡可能にしたいと考えているものとする。１つ目の端末は、プライベート・ユーザＩＤ２３４１５０１２３４５６＠ｏｐｅｒａｔｏｒ．ｎｅｔを割当てられているユーザ端末装置であり、2つ目の端末は、ＳＩＰ対応でかつＨＩＧに接続する非ＩＭＳのホームＰＣである。それ故、ＩＭＳネットワーク内では、Ａｌｉｃｅのパブリック・ユーザＩＤ「ａｌｉｃｅ．ｓｍｉｔｈ＠ｏｐｅｒａｔｏｒ．ｎｅｔ」は、両方のプライベート・ユーザＩＤに関係付けられなければならない。Ａｌｉｃｅはさらに、近い親族および親しい友人だけに知らせるパブリック・ユーザＩＤ「ａｌｉｃｅ＠ｏｐｅｒａｔｏｒ．ｎｅｔ」を有する。Ａｌｉｃｅは、自分のユーザ端末装置でだけこのパーソナルＩＤに到達可能にしたいと希望しているいものとする。それ故、このＩＤは、プライベート・ユーザＩＤである２３４１５０１２３４５６＠ｏｐｅｒａｔｏｒ．ｎｅｔだけに関係付けられている。

Ａｌｉｃｅの夫Ｂｏｂは、非ＩＭＳだがＳＩＰ対応の自分のノートパソコンを介してだけ連絡可能にしたいと希望しているものとする。それ故、Ｂｏｂのパブリック・ユーザＩＤ「ｂｏｂ．ｓｍｉｔｈ＠ｏｐｅｒａｔｏｒ．ｎｅｔ」は、ＨＩＧ内のＩＳＩＭのプライベート・ユーザＩＤである２３４１５０６５４３２１＠ｏｐｅｒａｔｏｒ．ｎｅｔだけにＩＭＳネットワーク内で関係付けられている。

ＢｏｂとＡｌｉｃｅの各端末内のＳＩＰユーザエージェント（ＵＡ）はそれぞれ、ＨＩＧ内のＳＩＰ Ｂ２ＢＵＡを介して、ＩＭＳネットワークでそれぞれのプライベート・ユーザＩＤに関係付けられる、それぞれのパーソナルＩＤを登録する。既に述べたように、プライベート・ユーザＩＤにも関係付けられるデフォルト・パブリック・ユーザＩＤは、ＩＭＳネットワークにも登録される。デフォルトのＩＤは、パーソナルＩＤの登録前または登録後のいずれのときに登録されてもよい。

図５は、ＳＩＰ対応でかつ非ＩＭＳ端末である１組のＵＡ１とＵＡ２を、ＨＩＧのＢ２ＢＵＡに登録し、続いてＢ２ＢＵＡとＩＭＳとの間で認可する手順に関連したシグナリングを示す図である。図に示すのは、ＩＭＳネットワークのプロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）ノードおよびサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）ノード、それにネットワークオペレータに属し加入データおよびアクセスデータを有するホーム加入者サーバ（ＨＳＳ）である。シグナリング手順は、３ＧＰＰ ＴＳ２４．２２９およびＴＳ２４．２２８に基づく。

１．ＵＡ１は、ＩＳＩＭに関する加入申し込みと関係するローカル・ユーザネーム（「ｂｏｂ」）を含む「Ｔｏ」ヘッダを使用して、ＨＩＧのＳＩＰ Ｂ２ＢＵＡに登録する。

２．Ｂ２ＢＵＡは、状況に応じてユーザに身元確認を要求する。加入者はローカル（局所的）に、ローカルユーザが身元確認を要求されるべきか否かを設定することと、ローカルユーザが使用するパスワードを設定することができる。

３．ＵＡ１は、身元確認を要求された場合、登録メッセージを再送する。その場合、メッセージは、ユーザネーム・パラメータに含まれる身元確認要求されたユーザのＩＤ（ｂｏｂ）を含む「Ａｕｔｈｏｒｉｚａｔｉｏｎ」ヘッダを有する。

４．ＳＩＰ Ｂ２ＢＵＡは、Ｐ−ＣＳＣＦとの間でＴＣＰ接続（通常はポート５０６１番）を確立する。

５．ＳＩＰ Ｂ２ＢＵＡは、ＴＬＳハンドシェイクを行い、ＴＬＳ接続を確立する。ＴＬＳハンドシェイクは、既存のＴＬＳセッションを再び用いてもよい。３ＧＰＰで現在規定されているＩＰｓｅｃは、ＮＡＴを越えることができないので、選択の余地はない。それ故、ＴＬＳがこの例では使用される。

６．Ｂ２ＢＵＡは、ユーザネームとしてＨＩＧのＩＳＩＭに格納されたプライベート・ユーザＩＤ（２３４１５０６５４３２１＠ｏｐｅｒａｔｏｒ．ｎｅｔ）を使用する。Ｃｏｎｔａｃｔヘッダは、Ｂ２ＢＵＡのＩＰアドレス（またはドメインネーム）を有する。通常このＩＰアドレスは動的ホスト設定プロトコル（ＤＨＣＰ）により割当てられる。Ｐ−ＣＳＣＦのアドレスまたは名前も、ＤＨＣＰにより割当てられる。Ｔｏヘッダ内の選択されたパブリック・ユーザＩＤは、ＵＡ１から送信されたＴｏヘッダ内の値かまたはマッピングされた名前（すなわちｂｏｂ．ｓｍｉｔｈ＠ｏｐｅｒａｔｏｒ．ｎｅｔ）である。ＵＡ１が使用するローカル・ユーザネームは、ＨＩＧによりパブリック・ユーザＩＤにマッピングされる。加入者は、そのようなマッピングをローカルに構成することができる。

７．Ｐ−ＣＳＣＦは、幾つかのヘッダ（Ｐｒｏｘｙ−ＲｅｑｕｉｒｅおよびＳｅｃｕｒｉｔｙ−Ｃｌｉｅｎｔ）と幾らかのヘッダ情報（例えば、Ｒｅｑｕｉｒｅヘッダのｓｅｃ−ａｇｒｅｅ）を除いた後、Ｓ−ＣＳＣＦに要求を送信する。

８．クライアントが認証されなければならず、Ｓ−ＣＳＣＦに（この加入申し込み）に対する認証ベクトルがまだ存在しない場合には、Ｓ−ＣＳＣＦは、ＨＳＳに認証ベクトルを要求する。通常、加入申し込みコンテキストは、Ｓ−ＣＳＣＦ内で各加入申し込みに対して作成され、その加入申し込みに対する新規登録に続いて、コンテキストのフラグは、「未認証」から「認証済」状態に切替えられる。

９．ＨＳＳは、Ｓ−ＣＳＣＦに１つまたは複数の認証ベクトルを返信する。

１０．Ｓ−ＣＳＣＦは、クライアント認証が必要な場合、ＲＡＮＤおよびＡＵＴＮを有するＳＩＰ４０１メッセージでＢ２ＢＵＡ／ＩＳＩＭに身元確認を要求する。

１１．Ｐ−ＣＳＣＦは、４０１メッセージに幾つかのヘッダを加えてから、Ｂ２ＢＵＡに４０１メッセージを送信する。

１２．４０１により身元確認を要求された場合、Ｂ２ＢＵＡは、ＲＥＳを計算するとともに、ＡＵＴＮを確かめる。次いでＢ２ＢＵＡは、ＲＥＳを共有鍵として使用したダイジェストを有するＡｕｔｈｏｒｉｚａｔｉｏｎヘッダを含む新しいＲＥＧＩＳＴＥＲメッセージを送信する。

１３．Ｐ−ＣＳＣＦは、幾つかのヘッダ（Ｐｒｏｘｙ−Ｒｅｑｕｉｒｅ、Ｓｅｃｕｒｉｔｙ−Ｖｅｒｉｆｙ、Ｓｅｃｕｒｉｔｙ−Ｃｌｉｅｎｔ）と幾らかのヘッダ情報（例えば、Ｒｅｑｕｉｒｅヘッダのｓｅｃ−ａｇｒｅｅ）とを除外した後、Ｓ−ＣＳＣＦにリクエストを送信する。Ｓ−ＣＳＣＦは、Ｂ２ＢＵＡからのＲＥＳに基づくダイジェストとＸＲＥＳから計算したダイジェストを照合する。これが必要なのは、Ｂ２ＢＵＡが身元確認要求された場合だけである。

１４．Ｓ−ＣＳＣＦは、Ｐａｔｈヘッダ、Ｓｅｒｖｉｃｅ−ＲｏｕｔｅヘッダおよびＰ−Ａｓｓｏｃｉａｔｅｄ−ＵＲＩヘッダを有する、ＳＩＰ２００メッセージで返答する
１５．Ｂ２ＢＵＡは、Ｓｅｒｖｉｃｅ−ＲｏｕｔｅヘッダおよびＰ−Ａｓｓｏｃｉａｔｅｄ−ＵＲＩヘッダの中身を格納し、次にＰａｔｈヘッダ、Ｓｅｒｖｉｃｅ−ＲｏｕｔｅヘッダおよびＰ−Ａｓｓｏｃｉａｔｅｄ−ＵＲＩヘッダを除去してから、ＵＡ１に２００メッセージを送信する。
これで、ＵＡ１に関する登録手続きが完了する。

１６．ＵＡ２は、ＩＳＩＭの加入申し込みに関係するローカル・ユーザネーム（「ａｌｉｃｅ」）を有するＴｏヘッダを使用して、ＳＩＰ Ｂ２ＢＵＡに登録する。

１７．Ｂ２ＢＵＡは、状況に応じてユーザに身元確認を要求する。

１８．ＵＡ２は、身元確認要求された場合、登録メッセージを再送する。その場合メッセージは、ユーザネーム・パラメータに含まれる身元確認要求されたユーザのＩＤ（ａｌｉｃｅ）を含むＡｕｔｈｏｒｉｚａｔｉｏｎヘッダを有する。

１９．Ｂ２ＢＵＡは、ユーザネームとしてＩＳＩＭに格納されたプライベート・ユーザＩＤ（２３４１５０６５４３２１＠ｏｐｅｒａｔｏｒ．ｎｅｔ）を使用する。Ｔｏヘッダ内の選択されたパブリック・ユーザＩＤは、マッピングされた名前（ａｌｉｃｅ．ｓｍｉｔｈ＠ｏｐｅｒａｔｏｒ．ｎｅｔ）である。

２０．Ｐ−ＣＳＣＦは、幾つかのヘッダ（Ｐｒｏｘｙ−Ｒｅｑｕｉｒｅ、Ｓｅｃｕｒｉｔｙ−Ｖｅｒｉｆｙ、Ｓｅｃｕｒｉｔｙ−Ｃｌｉｅｎｔ）および幾らかのヘッダ情報（例えば、Ｒｅｑｕｉｒｅヘッダのｓｅｃ−ａｇｒｅｅ）を除外した後、Ｓ−ＣＳＣＦに要求を送信する。

２１．Ｓ−ＣＳＣＦはプライベート・ユーザＩＤを既に認証しているので（サービス・コンテキストがある）、認証を再び行う必要はない。

２２．Ｓ−ＣＳＣＦは、Ｐａｔｈヘッダ、Ｓｅｒｖｉｃｅ−ＲｏｕｔｅヘッダおよびＰ−Ａｓｓｏｃｉａｔｅｄ−ＵＲＩヘッダを有するＳＩＰ２００メッセージで応答する。

２３．Ｂ２ＢＵＡは、Ｓｅｒｖｉｃｅ−ＲｏｕｔｅヘッダおよびＰ−Ａｓｓｏｃｉａｔｅｄ−ＵＲＩヘッダの中身を格納し、次にＰａｔｈヘッダ、Ｓｅｒｖｉｃｅ−ＲｏｕｔｅヘッダおよびＰ−Ａｓｓｏｃｉａｔｅｄ−ＵＲＩヘッダを除去してから、ＵＡ１に２００メッセージを送信する。
これで、端末ＵＡ２はＩＭＳに登録される。

図６は、レガシー電話機すなわち「黒電話機」の登録に関連するシグナリングを図解する。黒電話機はＳＩＰ端末ではないので、ＨＩＧへの端末の登録は、ＨＩＧの電源オン（または黒電話機とＨＩＧとの接続）に続いてＳＩＰゲートウェイで行われる。ＲＥＧＩＳＴＥＲメッセージのＴｏヘッダ内のパブリック・ユーザＩＤに関して、ＨＩＧは、デフォルト・ユーザＩＤであるｓｍｉｔｈ＠ｏｐｅｒａｔｏｒ．ｎｅｔを選択する（図６）。

ＳＩＰ対応端末のシナリオをまた考慮して、図７は、ＨＩＧの後方にあるＵＡ１がセッションの始端となる場合の、ＩＭＳセッション確立に関連するシグナリングを図解する。シグナリングの工程は以下の通りである。

１．ＵＡ１は、Ｂ２ＢＵＡにＳＩＰ ＩＮＶＩＴＥを送信する。

２．Ｂ２ＢＵＡは、１００Ｔｒｙｉｎｇで応答する。

３．Ｂ２ＢＵＡは、ＩＮＶＩＴＥメッセージに幾つかのヘッダを加える。Ｆｒｏｍヘッダは、ユーザに対するパーソナルＩＤに等しいパブリック・ユーザＩＤに変換される。Ｐ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙヘッダも、パーソナルＩＤを有する。Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏは、アクセス名を有する。場合によっては、アプリケーションはこのアクセス名を知らず、その場合はアクセスネットワークのどこかで加えられてもよいし、加入者が設定してもよい。電話番号は、ＩＳＩＭに格納された回線ＩＤに基づき加えることができる。Ｂ２ＢＵＡは、Ｃｏｎｔａｃｔヘッダを変更し、Ｐ−ＣＳＣＦにＩＮＶＩＴＥを送信する。

４．１００Ｔｒｙｉｎｇ。

５．ネットワークの視点からは認証された場合、Ｐ−ＣＳＣＦは、Ｐ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙを除去し、Ｐ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙの中身を有するＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙを代わりに挿入する。次いでＰ−ＣＳＣＦは、Ｓ−ＣＳＣＦにＩＮＶＩＴＥを送信する。

６．１００Ｔｒｙｉｎｇ。

７．Ｓ−ＣＳＣＦは、ＩＮＶＩＴＥがネットワークから送信される前に、Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏを除去する。

８．１００Ｔｒｙｉｎｇ。

９．着信側ＵＡは、１８０Ｒｉｎｇｉｎｇを送信する。

１０．着信側ＵＡは、２００ＯＫを送信する。

１１．ＵＡ１は、ＡＣＫで２００ＯＫの受信を通知する。

図８は、ＵＡ１がセッションの終端となる場合において、ＩＭＳセッションの確立に関連するシグナリングを図解する。シグナリング工程は、以下の通りである。

１．遠くにあるＵＡが、Ｓ−ＣＳＣＦにＳＩＰ ＩＮＶＩＴＥを送信する。

２．Ｓ−ＣＳＣＦは、１００Ｔｒｙｉｎｇで応答する。

３．Ｓ−ＣＳＣＦは、登録時に格納された連絡アドレスを抽出し、Ｒｅｑｕｅｓｔ−ＵＲＩとして挿入する。Ｓ−ＣＳＣＦは、Ｐ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤヘッダに元のＲｅｑｕｅｓｔ−ＵＲＩを挿入し、Ｐ−ＣＳＣＦにＩＮＶＩＴＥを送信する。

４．Ｐ−ＣＳＣＦは、１００Ｔｒｙｉｎｇで応答する。

５．Ｐ−ＣＳＣＦは、Ｐ−Ｃｈａｒｇｉｎｇ−Ｖｅｃｔｏｒを除去し、Ｂ２ＢＵＡにＩＮＶＩＴＥを送信する。

６．Ｂ２ＢＵＡは、１００Ｔｒｙｉｎｇで応答する。

７．Ｂ２ＢＵＡは、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙを移動する（実行可能手段は、Ｆｒｏｍヘッダ内の中身をＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ内の中身で置き換える）。Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダが移動される。実行可能手段は、Ｂ２ＢＵＡがＴｏヘッダの中身を置き換えるためにＰ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤの中身を使用することである。Ｂ２ＢＵＡは、前に登録したホームユーザを見つけるため、受信要求内のＲｅｑｕｅｓｔ−ＵＲＩを使用する。Ｒｅｑｕｅｓｔ−ＵＲＩは、ローカルに格納された連絡アドレスで置き換えられる。Ｂ２ＢＵＡは、ＵＡ１にＩＮＶＩＴＥを送信する。

８．ＵＡ１は、１００Ｔｒｙｉｎｇで応答する。

９．ＵＡ１は、１８０Ｒｉｎｇｉｎｇで応答する。

１０．遠くのＵＡは、Ｓ−ＣＳＣＦおよびＰ−ＣＳＣＦを介して、ＵＡ１にＡＣＫを送信する。

相当数の重要な利点が、上記手順の実装から生じる。特に、幾つかのユーザに対してＩＳＩＭは１つしか必要ない。これにより、システムの費用が減少し、柔軟性が増大する一方で、ＵＩＣＣが提供するセキュリティ向上の利点を依然として活かすことができる。他の利点は次の通りである。

●ＩＳＩＭを有しない端末は、ＨＩＧから延びている保護されたトンネル、ならびにＨＩＧ内のＮＡＴとファイアウォールの境界防護を利用できる。

●オペレータは、パスワードを提供し維持する必要がない。ローカルパスワードの設定は、加入者にまかせる。

●非ＩＭＳでＳＩＰ対応ＰＣが使用するローカル・パーソナルＩＤをＩＭＳネットワークの特定のパブリック・ユーザＩＤにマッピングするとき、パーソナルＩＤを使用することはまだ可能である。

本発明の範囲から逸脱することなしに上記の実施形態に対して、様々な変更形態の作成が可能であることは、当業者なら理解するであろう。

３Ｇネットワーク内のＩＭＳアーキテクチャの概要図である。 ＩＭＳユーザ端末装置と非ＩＭＳユーザ端末装置の両方にサービスするホームＩＭＳゲートウェイの概要図である。 ホームＩＭＳゲートウェイのアーキテクチャの概要図である。 パブリック・ユーザＩＤおよびプライベート・ユーザＩＤの例示的割当ての概要図である。 図３のゲートウェイを介するＳＩＰ対応ユーザ装置のＩＭＳ登録に関連するシグナリングを示すシグナリング図である。 図３のゲートウェイを介するレガシー・ユーザ装置のＩＭＳ登録に関連するシグナリングを示すシグナリング図である。 図３のゲートウェイの後方のユーザ装置が始端となるＩＭＳセッションの設定に関連するシグナリングを示すシグナリング図である。 図３のゲートウェイの後方のユーザ装置に終端するＩＭＳセッションの設定に関連するシグナリングを示すシグナリング図である。

Claims (14)

1. ＩＭＳ非対応端末を使用してＩＰマルチメディア・サブシステム（ＩＭＳ）のサービスにアクセスするのを支援する方法であって、
   ホームＩＭＳゲートウェイに対してＩＭＳ非対応端末を登録する工程と、
   前記ＩＭＳ非対応端末の登録に応えて、前記ホームＩＭＳゲートウェイに存在するＵＭＴＳ用ＩＣカード（ＵＩＣＣ）の汎用ＳＩＭアプリケーションから取得した情報を使用して、前記ＩＭＳ非対応端末に成り代わって、前記ホームＩＭＳゲートウェイと前記ＩＭＳとの間でＩＭＳ登録を実行する工程と
   を含むことを特徴とする方法。
2. 前記ホームＩＭＳゲートウェイは、前記ＵＭＴＳ用ＩＣカード上のＩＳＩＭへのインターフェースを有するＳＩＰバックトゥバック・ユーザエージェントを含むことを特徴する請求項１に記載の方法。
3. 前記ＩＭＳ非対応端末がＳＩＰ端末である場合に、前記ホームＩＭＳゲートウェイに対してＩＭＳ非対応端末を登録する前記工程には、前記ＳＩＰ端末と前記ＳＩＰバックトゥバック・ユーザエージェントとの間でＳＩＰ登録を実行する工程を含むことを特徴とする請求項２に記載の方法。
4. 前記ＳＩＰ端末は、前記ＳＩＰバックトゥバック・ユーザエージェントに対して、該ＳＩＰ端末に対して関係付けられることになっているパブリック・ユーザ識別情報を通知することを特徴とする請求項３に記載の方法。
5. 前記ＳＩＰ端末は、前記ＳＩＰバックトゥバック・ユーザエージェントによって、あらかじめ記憶されているパブリック・ユーザ識別情報に対してマッピングされるローカル識別情報を供給することを特徴とする請求項３に記載の方法。
6. 前記ＩＭＳ登録には、
   前記ＩＭＳ非対応端末に関係付けられた前記パブリック・ユーザ識別情報をＩＭＳネットワークに対して通知するとともに、前記ＩＭＳネットワークと前記ＳＩＰバックトゥバック・ユーザエージェントとの間でＳＩＰ登録を実行する工程
   が含まれることを特徴とする請求項２乃至５のいずれか１項に記載の方法。
7. 前記ＩＭＳ非対応端末がＳＩＰ端末でない場合に、
   前記ホームＩＭＳゲートウェイに対してＩＭＳ非対応端末を登録する前記工程には、前記ＩＭＳ非対応端末の端末入線上でのループを検出する工程を含むことを特徴とする請求項１に記載の方法。
8. 前記ホームＩＭＳゲートウェイには、前記ＩＭＳ非対応端末に対して割当てられ、かつ、前記ＩＭＳに対して登録する際に使用されるデフォルトのパブリック・ユーザ識別情報があらかじめ記憶されていることを特徴とする請求項１または７に記載の方法。
9. 前記ホームＩＭＳゲートウェイに対する前記ＩＭＳ非対応端末の登録は、前記ＵＭＴＳ用ＩＣカード上のＩＳＩＭへのインターフェースを有するＳＩＰゲートウェイによって実行されることを特徴とする請求項１、７または８に記載の方法。
10. ＩＭＳ非対応端末を使用してＩＰマルチメディア・サブシステム（ＩＭＳ）のサービスにアクセスするのを支援するためのホームＩＭＳゲートウェイを動作させる方法であって、
    前記ホームＩＭＳゲートウェイに対してＩＭＳ非対応端末を登録する工程と、
    前記ＩＭＳ非対応端末の登録に応えて、前記ホームＩＭＳゲートウェイに存在するＵＭＴＳ用ＩＣカード（ＵＩＣＣ）の汎用ＳＩＭアプリケーションから情報を取得し、取得した該情報を使用して、前記ＩＭＳ非対応端末に成り代わって、前記ＩＭＳに対してＩＭＳ登録を実行する工程と
    を含むことを特徴とする方法。
11. ＩＭＳ非対応端末を使用してＩＰマルチメディア・サブシステム（ＩＭＳ）のサービスにアクセスするのを支援するためのホームＩＭＳゲートウェイであって、
    前記ホームＩＭＳゲートウェイをＩＭＳ非対応端末へ接続するための少なくとも１つのインターフェースと、
    ＵＭＴＳ用ＩＣカード（ＵＩＣＣ）からＩＳＩＭアプリケーションデータを読み出すＵＩＣＣリーダ装置と、
    ＩＭＳ非対応端末を前記ホームＩＭＳゲートウェイに対して登録する第１処理手段と、
    前記ホームＩＭＳゲートウェイに登録されたＩＭＳ非対応端末を、前記ＩＭＳに対して登録する第２処理手段と
    を含むことを特徴とするホームＩＭＳゲートウェイ。
12. 前記ホームＩＭＳゲートウェイをＩＭＳ非対応端末へ接続するための前記インターフェースは、
    前記ホームＩＭＳゲートウェイとレガシー機器とを接続するための回線インターフェース、
    ＬＡＮインターフェース、または、
    無線ＬＡＮインターフェース
    であることを特徴とする請求項１１に記載のホームＩＭＳゲートウェイ。
13. 前記第１処理手段及び前記第２処理手段は、
    前記ＩＭＳによって使用されるセッション開始プロトコル（ＳＩＰ）と前記ＩＭＳ非対応端末によって使用されているプロトコルとの間でプロトコル変換を実行するＳＩＰゲートウェイを実現する手段
    を含むことを特徴とする請求項１１または１２に記載のホームＩＭＳゲートウェイ。
14. 前記第１処理手段及び前記第２処理手段は、
    ＳＩＰ端末に対してはＳＩＰサーバとして動作し、前記ＩＭＳに対してはＳＩＰクライアントとして動作するＳＩＰバックトゥバック・ユーザエージェントを実現する手段を含むことを特徴とする請求項１１または１２に記載のホームＩＭＳゲートウェイ。

Images