JP5147953B2 - Ｉｍｓｉを備えるマルチメディアゲートウェイを制御するための方法及び装置 - Google Patents

Description

本発明は、クライアント端末とＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークとの間の通信を仲介するマルチメディアゲートウェイ、及び、このマルチメディアゲートウェイを制御する方法に関する。

第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって、「ＩＰマルチメディア・サブシステム」（ＩＭＳ）と呼ばれるネットワークアーキテクチャが、パケットドメインにおけるマルチメディアサービス及びマルチメディアセッションを処理するためのオープンな標準として開発されてきた（ＩＭＳの詳細については、http://www.3gpp.org/ftp/Specs/html-info/22173.htmを参照されたい）。ＩＭＳ標準に準拠した多様な通信端末及び通信デバイス（以下、ＩＭＳ端末と呼ぶ）が今日では知られている。ＩＭＳ端末の典型例はＩＭＳ機能を有する移動体電話である。パーソナルコンピュータ（ＰＣ）や携帯情報端末（ＰＤＡ）なども、ＩＭＳ機能を備える場合には、ＩＭＳ端末としての役割を果たすことができる。ＩＭＳ端末は、例えばＩＭＳネットワークを介してビデオストリーミングサーバからビデオストリーミングを受信することにより、マルチメディアサービスを提供することができる。

しかしながら、ＩＭＳ非対応の（即ち、ＩＭＳ機能を持たない）通信端末（以下、非ＩＭＳ端末と呼ぶ）が依然として多数存在する。国際公開第ＷＯ ２００６／０４５７０６号は、これらの非ＩＭＳ端末がＩＭＳネットワークにアクセスすることを可能にする、「ホームＩＭＳゲートウェイ」（ＨＩＧＡ）と呼ばれるマルチメディアゲートウェイを開示する。

ＷＯ ２００６／０４５７０６によれば、ＨＩＧＡは、少なくとも１つの非ＩＭＳ端末が接続されているプライベートネットワーク内に配置される。ＨＩＧＡは、非ＩＭＳ端末とＩＭＳネットワークとの間の通信のために、セッション開始プロトコル（ＳＩＰ） バック・ツー・バック・ユーザエージェント（Ｂ２ＢＵＡ）を含む。ＨＩＧＡはまた、（３ＧＰＰ ＴＳ ２４．２２９及びＩＥＴＦ ＲＦＣ ３２６１に従って実装される）ＳＩＰゲートウェイも含む。ＳＩＰゲートウェイは、多様なクライアント端末のシグナリングプロトコルとＩＭＳによって使用されるＳＩＰとの間の相互動作を可能にする。例えば、ＳＩＰゲートウェイは、ＩＳＤＮベースのシグナリングプロトコルとＳＩＰとの間の変換を提供することができる。従って、非ＩＭＳ端末は、ＳＩＰ機能を有してもよいし、有さなくてもよい。

図１は、背景技術において知られているＨＩＧＡの構造を概略的に示す。ＨＩＧＡ１００は、Ｂ２ＢＵＡ１０１と、デバイスデータベース（ＤＢ）１０２と、少なくとも１つのＩＭＳ加入者ＩＤモジュール・アプリケーション群（ＩＳＩＭ群）１５０と、を含む。ＨＩＧＡ１００はまた、ＳＩＰゲートウェイ（不図示）も有してもよい。一例として、図１では、ＩＳＩＭ群１５０は２つのＩＳＩＭ、ＩＳＩＭ１６０及びＩＳＩＭ１７０を含む。各ＩＳＩＭは、単一のＩＭＳプライベート・アイデンティティ（ＩＭＰＩ）と、複数でもよい少なくとも１つのＩＭＳパブリック・アイデンティティ（ＩＭＰＵ）を格納する。図１では、ＩＳＩＭ１６０は、ＩＭＰＩ１６１と、ＩＭＰＵ１６２及びＩＭＰＵ１６３とを格納する。ＩＳＩＭ１７０は、ＩＭＰＩ１７１と、ＩＭＰＵ１７２及びＩＭＰＵ１７３とを格納する。

プライベートネットワーク１８０内のＳＩＰクライアント１１０、１１１、及び１１２は、Ｂ２ＢＵＡ１０１に接続される。また、Ｂ２ＢＵＡ１０１は、背景技術において例えば３ＧＰＰ ＴＳ ２３．２２８ Ｖ７．６．０を通じて当業者に知られているようなＧｍインタフェースを介して、ＩＭＳネットワーク１８１と通信することができる。ＩＭＳネットワーク１８１は、呼セッション制御機能（ＣＳＣＦ）１２０及びＩＭＳアプリケーションサーバ（ＩＭＳ ＡＰ）１２１を含む。

ＳＩＰクライアントがＨＩＧＡに登録する際に、ＨＩＧＡはＩＭＰＵ群のうちの１つをＳＩＰクライアントに割り当てることで、ＩＭＳネットワークがＨＩＧＡを介してＳＩＰクライアントを特定できるようにする。ＨＩＧＡ内のＢ２ＢＵＡは、ローカルＳＩＰアイデンティティをＩＭＰＵに変換すること、及びその逆を担う。従って、ＳＩＰクライアント１１０、１１１、及び１１２がＨＩＧＡ１００に登録する場合、ＨＩＧＡは図２に示すようなデバイスＤＢ１０２の中にマッピングテーブルを格納する。Ｂ２ＢＵＡ１０１は、ＳＩＰクライアント１１０、１１１、及び１１２の代理でＩＭＳシグナリングを処理し、各ＳＩＰクライアントに関する全てのシグナリングがＩＳＩＭアプリケーション上の対応するＩＭＰＩに関連付けられるようになる。例えば、ＳＩＰクライアント１１０がＳＩＰ ＲｅｇｉｓｔｅｒメッセージをＨＩＧＡ１００へ送信する場合、Ｂ２ＢＵＡ１０１はこのメッセージを、ＳＩＰクライアント１１０に対応するＩＭＰＩ１６１及びＩＭＰＵ１６２の両方を含んだＩＭＳ ＲＥＧＩＳＴＥＲメッセージに変換する。それゆえ、ＨＩＧＡ１００は、ＳＩＰクライアント１１０、１１１、及び１１２の代理でＩＭＳ端末としての機能を果たし、これにより、ＳＩＰクライアント１１０、１１１、及び１１２がＩＭＳネットワーク１８１にアクセスすることを可能にする。

従来のＨＩＧＡは、Ｇｍインタフェースを介するＳＩＰクライアントとＩＭＳネットワークとの間の通信を仲介することに成功した。それゆえ、ＩＭＳ非対応のＳＩＰ電話機やインスタントメッセンジャーのようなＳＩＰクライアントは、ＨＩＧＡ経由でＩＭＳネットワークと通信することができる。

しかしながら、ＳＩＰクライアントの通信相手であるＩＭＳ ＡＳが汎用ブートストラッピング・アーキテクチャ（ＧＢＡ） ネットワークアプリケーション機能（ＮＡＦ）として機能する場合、従来のＨＩＧＡの機能は不十分である。ＧＢＡ ＮＡＦは、例えば"Generic Authentication Architecture (GAA); Generic bootstrapping architecture," 3GPP TS 33.220 V7.3.0 (2006-03)を通じて当業者に知られているようなものである。ＧＢＡ ＮＡＦとしても機能するＩＭＳ ＡＳの一例は、ＩＯＰテレビジョン（ＩＰＴＶ） ＡＳである。この場合、ＳＩＰクライアントとしてのＩＰＴＶクライアントは、Ｇｍインタフェースを介するだけではなく、例えば３ＧＰＰ ＴＳ ２４．１０９ Ｖ７．５．０を通じて当業者に知られているようなＵａインタフェースも介してＩＰＴＶ ＡＳにアクセスする必要がある。Ｕａインタフェースは、一般的には（ＨＴＴＰダイジェスト認証を伴う場合もある）トランスポート・レイヤ・セキュリティ（ＴＬＳ）接続を使用して達成される、ＩＰＴＶクライアントとＩＰＴＶ ＡＳとの間のセキュアな認証済みチャネルを提供する。ＩＰＴＶクライアントは、ＨＴＴＰやＲＴＳＰのようなアプリケーションプロトコルを使用して、このＴＬＳ接続を介してＩＰＴＶ ＡＳとセキュアに通信することができる。

図３は、ＩＰＴＶクライアントが従来のＨＩＧＡ経由でＩＰＴＶ ＡＳと通信することが不可能な状況を示す図である。図３において、図１と同一の参照符号は図１と同一又は同様のコンポーネントを示すので、その詳細な説明は省略する。

ＩＰＴＶクライアント３００は、ＳＩＰ機能３０１及びＩＰＴＶアプリケーション３０２を含む。ＩＰＴＶクライアント３００は、ＨＩＧＡ１００のＢ２ＢＵＡ１０１経由でＧｍインタフェースを介して、ＧＢＡ ＮＡＦとして機能するＩＰＴＶ ＡＳ３１０に対する「間接的な」アクセスを行うことができるが、Ｕａインタフェースを介してＩＰＴＶ ＡＳ３１０に対するアクセスを行うことはできない。換言すれば、ＳＩＰ機能３０１はＨＩＧＡ１００経由でＩＰＴＶ ＡＳ３１０と通信可能であるが、ＩＰＴＶアプリケーション３０２はＨＩＧＡ経由でＩＰＴＶ ＡＳ３１０と通信することが不可能である。その理由は、ＩＰＴＶクライアント３００がＩＳＩＭアプリケーションを持っておらず、それゆえ、Ｕａインタフェースをセキュアにするために必要とされるＫｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦと呼ばれるＮＡＦ固有の鍵を導出することができないことである。

本発明は上述の課題に対処することを意図したものであり、本発明の特徴は、ＩＭＳ非対応のクライアント端末がＵａインタフェースを介してＩＭＳ ＡＳにアクセスすることを可能にする技術を導入することである。

本発明の第１の態様によれば、ＩＳＩＭと、クライアント端末と通信するための第１のインタフェースと、ＩＭＳネットワークに配置されたＧＢＡ ＮＡＦとして機能するＩＭＳ ＡＳと通信するための第２のインタフェースと、を有するマルチメディアゲートウェイが提供される。前記マルチメディアゲートウェイは、前記クライアント端末から受信した登録要求メッセージに応えて、前記ＩＳＩＭから取得したＩＭＰＵを前記クライアント端末に割り当て、前記クライアント端末に割り当てたＩＭＰＵを前記ＩＭＳネットワークに登録する登録手段と、宛先のＩＭＳ ＡＳ及び通信プロトコルを指定する要求メッセージを前記クライアント端末から受信し、当該クライアント端末に割り当てられたＩＭＰＵを特定する要求受信手段と、前記通信プロトコルを用いて前記ＩＭＳ ＡＳと通信するためのセッションを確立し、当該セッション上に前記ＩＭＳ ＡＳとの接続を確立する確立手段と、前記特定されたＩＭＰＵを含んだＩＳＩＭから導出される認証情報を前記ＩＭＳ ＡＳへ送信する認証情報送信手段と、前記要求メッセージを前記特定されたＩＭＰＵと共に、前記接続を介して前記ＩＭＳ ＡＳへ送信する要求送信手段と、前記要求メッセージに対する応答として、前記接続を介して前記ＩＭＳ ＡＳから応答メッセージを受信する応答受信手段と、前記応答メッセージを前記クライアント端末へ送信する応答送信手段と、を備える。

いくつかの実施形態では、前記確立手段は、前記要求受信手段が前記要求メッセージを受信した場合に、前記セッションが確立されているか否かを判定し、前記セッションが確立されていないと判定された場合に、前記セッションを確立する。

いくつかの実施形態では、前記確立手段は、前記宛先のＩＭＳ ＡＳと、前記通信プロトコルと、前記特定されたＩＭＰＵを含んだ前記ＩＳＩＭと、に関連付けて、前記セッションを特定するセッションＩＤを格納し、前記宛先のＩＭＳ ＡＳと、前記通信プロトコルと、前記特定されたＩＭＰＵを含んだ前記ＩＳＩＭと、に関連付けられた前記セッションＩＤが格納されている場合に、前記セッションが確立されていると判定する。

いくつかの実施形態では、前記確立手段は、前記要求受信手段が前記要求メッセージを受信した場合に、前記接続が確立されているか否かを判定し、前記接続が確立されていないと判定された場合に、前記接続を確立する。

いくつかの実施形態では、前記確立手段は、前記セッションＩＤと、前記特定されたＩＭＰＵと、に関連付けて、前記接続を特定する接続ＩＤを格納し、前記セッションＩＤと、前記特定されたＩＭＰＵと、に関連付けられた前記接続ＩＤが格納されている場合に、前記接続が確立されていると判定する。

いくつかの実施形態では、前記登録手段は、前記要求受信手段が前記クライアント端末からの前記要求メッセージを受信する、前記クライアント端末に固有のアドレスを割り当て、前記クライアント端末に割り当てられたＩＭＰＵに関連付けて前記アドレスを格納し、前記クライアント端末に対して前記アドレスを通知する。また、前記要求受信手段は、前記アドレスと前記ＩＭＰＵとの間の関連付けに基づいて、前記クライアント端末に割り当てられたＩＭＰＵを特定する。

いくつかの実施形態では、前記登録手段は、各々が異なる通信プロトコルに関連付けられた複数のアドレスを割り当て、前記クライアント端末に割り当てられたＩＭＰＵに関連付けて前記複数のアドレスを格納し、前記クライアント端末に対して前記複数のアドレスを通知する。

いくつかの実施形態では、前記登録要求メッセージは少なくとも１つの通信プロトコルを指定する。また、前記登録手段は、前記少なくとも１つの通信プロトコルの数と同数の、各々が異なる通信プロトコルに関連付けられたアドレスを割り当て、前記クライアント端末に割り当てられたＩＭＰＵに関連付けて前記同数のアドレスを格納し、前記クライアント端末に対して前記同数のアドレスを通知する。

いくつかの実施形態では、前記登録手段は、前記クライアント端末に割り当てられたＩＭＰＵに関連付けて、前記クライアント端末のユニバーサル・リソース・アイデンティファイア（ＵＲＩ）を格納し、前記要求受信手段は、前記要求メッセージに含まれるＵＲＩと前記ＩＭＰＵとの関連付けに基づいて、前記クライアント端末に割り当てられたＩＭＰＵを特定する。

いくつかの実施形態では、前記認証情報送信手段は、前記確立手段が前記セッションを確立する際に、前記認証情報を送信する。

いくつかの実施形態では、前記認証情報送信手段は、前記確立手段が前記接続を確立した後に前記ＩＭＳ ＡＳからの要求に応えて、前記認証情報を送信する。

いくつかの実施形態では、前記クライアント端末はセッション開始プロトコル（ＳＩＰ）対応であり、前記登録要求メッセージはＳＩＰ Ｒｅｇｉｓｔｅｒメッセージである。

いくつかの実施形態では、前記要求メッセージは、ＨＴＴＰ Ｒｅｑｕｅｓｔメッセージ、又はＲＴＳＰ Ｒｅｑｕｅｓｔメッセージである。

いくつかの実施形態では、前記セッションはＴＬＳセッションであり、前記接続はトランスポート・レイヤ・セキュリティ（ＴＬＳ）接続である。

本発明の第２の態様によれば、ＩＳＩＭと、クライアント端末と通信するための第１のインタフェースと、ＩＭＳネットワークに配置されたＧＢＡ ＮＡＦとして機能するＩＭＳ ＡＳと通信するための第２のインタフェースと、を有するマルチメディアゲートウェイを制御する方法が提供される。前記方法は、前記クライアント端末から受信した登録要求メッセージに応えて、前記ＩＳＩＭから取得したＩＭＰＵを前記クライアント端末に割り当て、前記クライアント端末に割り当てたＩＭＰＵを前記ＩＭＳネットワークに登録するステップと、宛先のＩＭＳ ＡＳ及び通信プロトコルを指定する要求メッセージを前記クライアント端末から受信し、当該クライアント端末に割り当てられたＩＭＰＵを特定するステップと、前記通信プロトコルを用いて前記ＩＭＳ ＡＳと通信するためのセッションを確立し、当該セッション上に前記ＩＭＳ ＡＳとの接続を確立するステップと、前記特定されたＩＭＰＵを含んだＩＳＩＭから導出される認証情報を前記ＩＭＳ ＡＳへ送信するステップと、前記要求メッセージを前記特定されたＩＭＰＵと共に、前記接続を介して前記ＩＭＳ ＡＳへ送信するステップと、前記要求メッセージに対する応答として、前記接続を介して前記ＩＭＳ ＡＳから応答メッセージを受信するステップと、前記応答メッセージを前記クライアント端末へ送信するステップと、を備える。

いくつかの実施形態では、前記方法は、前記確立するステップにおいて、前記要求メッセージを受信する前記ステップにおいて前記要求メッセージが受信された場合に、前記セッションが確立されているか否かを判定し、前記セッションが確立されていないと判定された場合に、前記セッションを確立する。

いくつかの実施形態では、前記方法は、前記確立するステップにおいて、前記宛先のＩＭＳ ＡＳと、前記通信プロトコルと、前記特定されたＩＭＰＵを含んだ前記ＩＳＩＭと、に関連付けて、前記セッションを特定するセッションＩＤを格納し、前記宛先のＩＭＳ ＡＳと、前記通信プロトコルと、前記特定されたＩＭＰＵを含んだ前記ＩＳＩＭと、に関連付けられた前記セッションＩＤが格納されている場合に、前記セッションが確立されていると判定する。

いくつかの実施形態では、前記方法は、前記確立するステップにおいて、前記要求メッセージを受信する前記ステップにおいて前記要求メッセージが受信された場合に、前記接続が確立されているか否かを判定し、前記接続が確立されていないと判定された場合に、前記接続を確立する。

いくつかの実施形態では、前記方法は、前記確立するステップにおいて、前記セッションＩＤと、前記特定されたＩＭＰＵと、に関連付けて、前記接続を特定する接続ＩＤを格納し、前記セッションＩＤと、前記特定されたＩＭＰＵと、に関連付けられた前記接続ＩＤが格納されている場合に、前記接続が確立されていると判定する。

いくつかの実施形態では、前記方法は、割り当て登録する前記ステップにおいて、前記要求メッセージを受信する前記ステップにおいて前記クライアント端末からの前記要求メッセージが受信される、前記クライアント端末に固有のアドレスを割り当て、前記クライアント端末に割り当てられたＩＭＰＵに関連付けて前記アドレスを格納し、前記クライアント端末に対して前記アドレスを通知する。また、前記方法は、前記要求メッセージを受信する前記ステップにおいて、前記アドレスと前記ＩＭＰＵとの間の関連付けに基づいて、前記クライアント端末に割り当てられたＩＭＰＵを特定する。

いくつかの実施形態では、前記方法は、割り当て登録する前記ステップにおいて、各々が異なる通信プロトコルに関連付けられた複数のアドレスを割り当て、前記クライアント端末に割り当てられたＩＭＰＵに関連付けて前記複数のアドレスを格納し、前記クライアント端末に対して前記複数のアドレスを通知する。

いくつかの実施形態では、前記登録要求メッセージは少なくとも１つの通信プロトコルを指定する。また、前記方法は、割り当て登録する前記ステップにおいて、前記少なくとも１つの通信プロトコルの数と同数の、各々が異なる通信プロトコルに関連付けられたアドレスを割り当て、前記クライアント端末に割り当てられたＩＭＰＵに関連付けて前記同数のアドレスを格納し、前記クライアント端末に対して前記同数のアドレスを通知する。

いくつかの実施形態では、前記方法は、割り当て登録する前記ステップにおいて、前記クライアント端末に割り当てられたＩＭＰＵに関連付けて、前記クライアント端末のＵＲＩを格納する。また、前記方法は、前記要求メッセージを受信する前記ステップにおいて、前記要求メッセージに含まれるＵＲＩと前記ＩＭＰＵとの関連付けに基づいて、前記クライアント端末に割り当てられたＩＭＰＵを特定する。

いくつかの実施形態では、前記方法は、前記認証情報を送信する前記ステップにおいて、前記確立するステップで前記セッションが確立される際に、前記認証情報を送信する。

いくつかの実施形態では、前記方法は、前記認証情報を送信する前記ステップにおいて、前記確立するステップで前記接続が確立された後に前記ＩＭＳ ＡＳからの要求に応えて、前記認証情報を送信する。

いくつかの実施形態では、前記クライアント端末はＳＩＰ対応であり、前記登録要求メッセージはＳＩＰ Ｒｅｇｉｓｔｅｒメッセージである。

いくつかの実施形態では、前記要求メッセージは、ＨＴＴＰ Ｒｅｑｕｅｓｔメッセージ、又はＲＴＳＰ Ｒｅｑｕｅｓｔメッセージである。

いくつかの実施形態では、前記セッションはＴＬＳセッションであり、前記接続はＴＬＳ接続である。

本発明の主な利点は次の通りである。マルチメディアゲートウェイは、ＩＭＳ非対応のクライアント端末がＧＢＡ ＮＡＦとして機能するＩＭＳ ＡＳとＵａインタフェースを介して通信することを可能にする。なお、クライアント端末がＩＭＳ非対応の場合に本発明は特に利点を有するが、ＩＭＳ対応のクライアント端末もマルチメディアゲートウェイ経由でＩＭＳ ＡＳと通信可能である。

本発明の更なる特徴は、添付の図面を参照する典型的な実施形態に関する下記の説明から明らかになるであろう。図面においては、全図を通して、同種の参照符号は同一又は同様のパーツを示す。

背景技術において知られているホームＩＭＳゲートウェイ（ＨＩＧＡ）の構造を概略的に示す。 ＳＩＰクライアントとＩＭＰＵとの間のマッピングを維持管理するマッピングテーブルの一例を示す。 ＩＰテレビジョン（ＩＰＴＶ）クライアントが従来のＨＩＧＡ経由でＩＰＴＶ ＡＳと通信することが不可能な状況を示す。 本発明の典型的な実施形態の全体的なアーキテクチャを示す。 本発明の典型的な実施形態に係るＨＩＧＡの詳細な構成を示すブロック図である。 本発明の典型的な実施形態に係る、ＨＩＧＡがＩＰＴＶクライアントとＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークとの間の通信を仲介する手順を示すシーケンス図である。 本発明のいくつかの実施形態に係る、ＨＩＧＡがＩＰＴＶクライアントに対してＵａプロキシのアドレスを通知する手順を示すシーケンス図である。 本発明のいくつかの実施形態に係る、ＨＩＧＡからＩＰＴＶクライアントへの２００ＯＫ応答と一緒に返されるＸＭＬ文書の一例を示す。 本発明の他の実施形態に係る、ＨＩＧＡがＩＰＴＶクライアントに対してＵａプロキシのアドレスを通知する手順を示す。 本発明のいくつかの実施形態に係る、ＨＩＧＡのアイデンティティ・マッピング機能を概略的に示す。 ２つのＩＰＴＶクライアントが単一のＴＬＳセッションを共有する状況を概略的に示す。 ＴＬＳセッションがＩＰＴＶクライアント毎に確立される状況を概略的に示す。 本発明のいくつかの実施形態に係る、ＨＩＧＡの確立ユニットによって維持管理されるセッション／接続管理テーブルの一例を示す。 本発明のいくつかの実施形態に係る、ＨＩＧＡの確立ユニットがＴＬＳセッション及びＴＬＳ接続を確立する手順を示すフローチャートである。 本発明のいくつかの実施形態に係る、ＴＬＳセッション／接続管理機能を持つＨＩＧＡが要求メッセージ及び応答メッセージを処理する手順を示すシーケンス図である。

ここで、添付の図面を参照して本発明の実施形態を説明する。以下に説明される各実施形態は、一般的なものからより具体的なものまでの多様な概念を理解するのに役立つであろう。

なお、本発明の技術的範囲は請求項によって規定されるのであって、以下に説明される各実施形態によっては限定されない。加えて、実施形態で説明される特徴の全ての組み合わせが本発明にとって常に不可欠だという訳ではない。

図４は、本発明の典型的な実施形態の全体的なアーキテクチャを示す図である。図４において、図３と同一の参照符号は図３と同一又は同様のコンポーネントを示すので、その説明を省略する。

本実施形態では、Ｕａプロキシ４１０を備えるＨＩＧＡ４００が提供される。Ｕａプロキシ４１０は、ＩＰＴＶアプリケーション３０２とＩＰＴＶ ＡＳ３１０との間のＵａインタフェースを介した通信を仲介する。従って、ＩＭＳ非対応のクライアント端末としてのＩＰＴＶクライアント３００は、ＨＩＧＡ４００経由でＵａインタフェースを介して、ＧＢＡ ＮＡＦとして機能するＩＭＳ ＡＳとしてのＩＰＴＶ ＡＳ３１０と通信することができる。図４は単純化のために１つだけのＩＰＴＶクライアント３００を示すが、ＨＩＧＡ４００は複数のＩＰＴＶクライアントを同時にサポートすることができる。ＨＩＧＡ４００はまた、Ｂ２ＢＵＡ４２０と、例えば図２に示すマッピングテーブルを格納するメモリ４３０と、を備える。

ブートストラップサーバ機能（ＢＳＦ）４４０は、ＩＭＳネットワーク１８１のネットワークオペレータによってホスティングされる。例えば３ＧＰＰ ＴＳ ２２．１０９ Ｖ７．５．０を通じて当業者に知られているようなＵｂインタフェースは、３ＧＰＰ ＴＳ ３３．２２０ Ｖ７．３．０（２００６−０３）で定義されるブートストラップ手順を実行することにより、ＢＳＦ４４０とＨＩＧＡ４００との間で相互認証と共有鍵の確立とを提供する。ブートストラップ中に生成される共有鍵は、その後、ＩＰＴＶ ＡＳ３１０のようなＮＡＦとＨＩＧＡ４００との間でセキュアな認証済みチャネルを確立するために適用可能である。

図５は、本発明の典型的な実施形態に係るＨＩＧＡ４００の詳細な構成を示すブロック図である。

ＨＩＧＡ４００は、プライベートネットワーク１８０内のＩＰＴＶクライアント３００と通信するインタフェース５１０と、ＩＭＳネットワーク１８１と通信するインタフェース５２０とを備える。インタフェース５１０及び５２０は、例えばイーサネット（登録商標）インタフェース、又はＩＥＥＥ８０２．１１ａ／ｂ／ｇなどに準拠した無線インタフェースによって物理的に実装される。Ｕａインタフェース及びＧｍインタフェースのような論理インタフェースは、インタフェース５２０上に実装可能である。

ＳＩＰ Ｒｅｇｉｓｔｅｒメッセージのような登録要求メッセージをＢ２ＢＵＡ４２０がＩＰＴＶクライアント３００から受信すると、Ｂ２ＢＵＡ４２０はＩＳＩＭ群１５０のうちの１つからＩＭＰＵを取得し、ＩＰＴＶクライアント３００にＩＭＰＵを割り当てる。Ｂ２ＢＵＡ４２０は、ＩＭＰＵとＩＰＴＶクライアント３００との間の関連付けをメモリ４３０に格納する。次いで、Ｂ２ＢＵＡ４２０はＩＭＳネットワーク１８１にＩＭＰＵを登録する。なお、Ｂ２ＢＵＡ４２０の機能は、専用ハードウェアによって実装されてもよいし、プロセッサ（不図示）によって実行されるソフトウェアによって実装されてもよいし、その組み合わせでもよい。

Ｕａプロキシ４１０は、要求受信ユニット５０１と、確立ユニット５０２と、認証情報送信ユニット５０３と、要求送信ユニット５０４と、応答受信ユニット５０５と、応答送信ユニット５０６とを備える。なお、各ユニットは、専用ハードウェアによって実装されてもよいし、プロセッサ（不図示）によって実行されるソフトウェアによって実装されてもよいし、その組み合わせでもよい。

要求受信ユニット５０１は、ＨＴＴＰ ＲｅｑｕｅｓｔメッセージやＲＴＳＰ Ｒｅｑｕｅｓｔメッセージのような要求メッセージをＩＰＴＶクライアント３００から受信する。要求メッセージは、宛先ＩＭＳ ＡＳ（即ち、本実施形態ではＩＰＴＶ ＡＳ３１０）及び通信プロトコルを指し示す。要求受信ユニット５０１は、メモリ４３０内のマッピングテーブルを参照することにより、発信元ＩＰＴＶクライアント３００に割り当てられたＩＭＰＵを特定する。

確立ユニット５０２は、ＴＬＳセッションのようなセッションをＩＰＴＶ ＡＳ３１０との間で確立し、ＴＬＳ接続のような接続（コネクション）をＩＰＴＶ ＡＳ３１０との間で確立することで、Ｕａプロキシがこの接続を介してＩＰＴＶ ＡＳ３１０と通信できるようにする。以後、セッションはＴＬＳセッションであり、接続はＴＬＳ接続であるものとする。

なお、本願では、ＴＬＳ「セッション」は、ＴＬＳハンドシェイク・プロトコルによって確立されたＵａプロキシとＧＢＡ ＮＡＦとの間の論理的なセキュリティ関連付け（セキュリティアソシエーション）を表す。Ｕａプロキシは、ＲＦＣ２２４６で定義されるＴＬＳセッション・アイデンティファイアを用いて各ＴＬＳセッションを識別することができる。一方、ＴＬＳ「接続」は、ＲＦＣ２２４６で定義されるＴＬＳレコード・プロトコルによって暗号化された実際の伝送チャネルを表す。Ｕａプロキシは、http://www.openssl.org/から知ることができるＯｐｅｎＳＳＬ ＡＰＩにおける「ＳＳＬ」オブジェクトのようなＴＬＳプログラミングＡＰＩを介して、自分のＴＬＳ接続の各々を識別することができる。

認証情報送信ユニット５０３は、ＩＰＴＶ ＡＳ３１０がＵａプロキシ４１０を認証することを可能にする認証情報を送信する。より具体的には、可能なソリューションのうちの一例として、認証情報送信ユニット５０３は、ＴＬＳセッションが確立された後にＩＰＴＶ ＡＳ３１０に対して、ＲＦＣ２６１７で規定されるＨＴＴＰ Ｄｉｇｅｓｔ認証を実行することができる。この手順は、３ＧＰＰ ＴＳ ３３．２２２ Ｖ７．１．０（２００６−０３）のセクション５．３に示されている。この例では、最初にＩＰＴＶ ＡＳ３１０のサーバ証明書を使用してＴＬＳセッションが確立され、その後、ＩＰＴＶ ＡＳ３１０が、ＩＳＩＭから導出される共有鍵である「Ｋｓ＿（ｅｘｔ）＿ＮＡＦ」をパスワードとして使用することによりＨＴＴＰ Ｄｉｇｅｓｔを介してＵａプロキシ４１０を認証する。なお、Ｋｓ＿（ｅｘｔ）＿ＮＡＦのマスター鍵は、Ｕｂインタフェースで規定されるブートストラップ手順の間に生成される。他の例として、認証情報送信ユニット５０３は、共有鍵Ｋｓ＿（ｅｘｔ）＿ＮＡＦに基づいてＩＰＴＶ ＡＳ３１０との相互認証を実行することができる。Ｋｓ＿（ｅｘｔ）＿ＮＡＦはＴＬＳセッション鍵を生成するためのマスター鍵として使用される。この場合、Ｕａプロキシ４１０及びＩＰＴＶ ＡＳ３１０は、ＴＬＳセッションを確立する際にお互いを認証する。この手順は、３ＧＰＰ ＴＳ ３３．２２２ Ｖ７．１．０（２００６−０３）のセクション５．４に示されている。

要求送信ユニット５０４は、受信した要求メッセージを特定されたＩＭＰＵと共に、ＴＬＳ接続を介してＩＰＴＶ ＡＳ３１０へ送信する。

応答受信ユニット５０５は、要求送信ユニット５０４によって送信された要求メッセージに対する応答として、応答メッセージをＴＬＳ接続を介してＩＰＴＶ ＡＳ３１０から受信する。

応答送信ユニット５０６は、ＩＰＴＶクライアント３００へ応答メッセージを送信する。それゆえ、ＩＰＴＶクライアント３００はＨＩＧＡ４００経由でＵａインタフェースを介して、要求メッセージをＩＰＴＶ ＡＳ３１０へ送信し応答メッセージをＩＰＴＶ ＡＳ３１０から受信することができる。

図６は、ＨＩＧＡ４００がＩＰＴＶクライアント３００とＩＭＳネットワーク１８１との間の通信を仲介する手順を示すシーケンス図である。このシーケンス図では、ＩＰＴＶクライアント３００はＢ２ＢＵＡ４２０及びＵａプロキシ４１０のアドレスを事前に知っているものとする。例えば、ＩＰＴＶクライアント３００は、ユニバーサル・プラグアンドプレイ（ＵＰｎＰ）技術を用いてＨＩＧＡ４００を発見可能であり、ＨＩＧＡ４００は、ＵＰｎＰ技術に基づく通信を介してＩＰＴＶクライアント３００に対してアドレスを知らせる。なお、ＢｌｕｅｔｏｏｔｈやＢｏｎｊｏｕｒなどのＵＰｎＰ以外のメカニズムも、ＩＰＴＶクライアント３００がＨＩＧＡ４００を発見することを可能にするために使用可能である。

ステップＳ６０１で、ＳＩＰ機能３０１は、ＳＩＰ ＲｅｇｉｓｔｅｒメッセージをＢ２ＢＵＡ４２０へ送信することにより、ＩＰＴＶクライアント３００をＨＩＧＡ４００に登録する。

ステップＳ６０２で、Ｂ２ＢＵＡ４２０は、ＩＳＩＭ群１５０から取得したＩＭＰＵを割り当て、ＩＭＰＵとＩＰＴＶクライアント３００との間の関連付けをメモリ４３０に格納する。次いで、Ｂ２ＢＵＡ４２０は、Ｇｍインタフェースを介してＳＩＰ ＲｅｇｉｓｔｅｒメッセージをＣＳＣＦ１２０へ送信することにより、割り当てられたＩＭＰＵをＩＭＳネットワーク１８１に登録する。

ステップＳ６０３で、Ｂ２ＢＵＡ４２０は、Ｇｍインタフェースを介してＣＳＣＦ１２０から成功応答（２００ＯＫ応答）を受信する。

ステップＳ６０４で、Ｂ２ＢＵＡ４２０はＳＩＰ機能３０１へ２００ＯＫ応答を送信し、これにより、ＩＰＴＶクライアント３００は、自分がＢ２ＢＵＡ４２０に成功裏に登録されたということを認識する。

ステップＳ６０５で、ＣＳＣＦ１２０は、ＩＭＰＵが登録されたということをＩＰＴＶ ＡＳ３１０に通知するために、ＩＰＴＶ ＡＳ３１０に対してサードパーティー登録（第三者登録）を実行する。

ステップＳ６０６で、ＩＰＴＶアプリケーション３０２は、アプリケーションプロトコルでの要求メッセージ（例えば、ＨＴＴＰ Ｒｅｑｕｅｓｔメッセージ）をＵａプロキシ４１０へ送信する。Ｕａプロキシ４１０は、ステップＳ６０２で格納した関連付けに基づいて、ＩＰＴＶクライアント３００に割り当てられたＩＭＰＵを特定する。

ステップＳ６０７で、Ｕａプロキシ４１０は、ＧＢＡ仕様に従って、ＩＰＴＶ ＡＳ３１０とのＴＬＳセッションを確立し、ＴＬＳセッションを介してＩＰＴＶ ＡＳ３１０とのＴＬＳ接続を確立する（ＧＢＡ仕様の詳細については、"Bootstrap interface (Ub) and network application function interface (Ua); Protocol details," 3GPP TS 24.109 V7.5.0 (2006-12)を参照されたい）。いくつかの実施形態では、ＧＢＡによって規定されるＴＬＳセッション／接続の確立に続いて、ＨＴＴＰ Ｄｉｇｅｓｔ認証が実行されてもよい。その結果、ＩＰＴＶ ＡＳはＵａプロキシ４１０を認証する。

ステップＳ６０８で、Ｕａプロキシ４１０は、ステップＳ６０６で受信した要求メッセージを、ＴＬＳ接続の中にカプセル化することによってＵａインタフェース上のＴＬＳ接続を介してＩＰＴＶ ＡＳ３１０へ送信する。このステップでは、Ｕａプロキシ４１０はまた、ＩＭＰＵを伴うX-3GPP-Intended-Identityヘッダを要求メッセージに挿入することにより、ＩＰＴＶクライアント３００に割り当てられたＩＭＰＵを送信する。

ステップＳ６０９で、Ｕａプロキシ４１０は、Ｕａインタフェース上のＴＬＳ接続を介してＩＰＴＶ ＡＳ３１０から応答メッセージを受信する。

ステップＳ６１０で、Ｕａプロキシ４１０は、ステップＳ６０９においてＴＬＳ接続から受信した応答メッセージのカプセル化を解除し、応答メッセージをＩＰＴＶアプリケーション３０２へ送信する。

いくつかの実施形態では、ＨＩＧＡ４００は更に、ＨＩＧＡ４００の性能を向上させる以下の機能を備えてもよい。
− Ｕａプロキシアドレス広告機能
− アイデンティティ・マッピング機能
− ＴＬＳセッション／接続管理機能

（Ｕａプロキシアドレス広告機能）
上述したように、Ｕａプロキシ４１０は例えばＵＰｎＰ技術に従って、ＩＰＴＶクライアント３００に対して、ＩＰＴＶアプリケーション３０２による要求メッセージの送信先としてのアドレス（ＩＰアドレス及びＴＣＰポート）を通知することができる。しかしながら、この代替実施例では、Ｕａプロキシ４１０は、ＳＩＰ Ｒｅｇｉｓｔｅｒメッセージに対する応答を活用することによりＩＰＴＶクライアント３００に対してアドレスを通知する。

図７は、ＨＩＧＡ４００がＩＰＴＶクライアントに対してＵａプロキシ４１０のアドレスを通知する手順を示すシーケンス図である。

図７のステップＳ７０１に示すように、ＩＰＴＶクライアント３００は、ＳＩＰ Ｒｅｇｉｓｔｅｒメッセージ中のＡｃｃｅｐｔヘッダ内に"application/x-ua-proxy-address+xml"というＭＩＭＥタイプを指定する。ＨＩＧＡ４００のＢ２ＢＵＡ４２０がこのＳＩＰ Ｒｅｇｉｓｔｅｒメッセージを受信すると、ステップＳ７０２に示すように、Ｂ２ＢＵＡ４２０は、クライアントがＵａプロキシ機能を要求しているということを理解し、それゆえ、Ｕａプロキシのアドレスを列挙したＸＭＬ文書を伴う２００ＯＫ応答を返す。ステップＳ７０３及びＳ７０４に示すように、他のＩＰＴＶクライアント７００は、ＩＰＴＶクライアント３００と同様のやり方でアドレスを取得することができる。

図８は、２００ＯＫ応答と一緒に返されるＸＭＬ文書の一例を示す図である。このＸＭＬ文書は、仲介対象のアプリケーションプロトコルでの要求をＵａプロキシ４１０が待ち受けているアドレスのリストを含む。

各＜Addr＞エレメントはＵａプロキシのアドレス（ＩＰアドレス：ＴＣＰポート）を含み、各アドレスは"scheme"属性によって区別可能である。この属性は、指定されたアドレス上ではどのスキームのアプリケーションプロトコルでの要求がＵａプロキシ４１０によって受け付け可能であるかを指定する。スキームの例は、ＨＴＴＰ及びＲＴＳＰである。

他の実施形態では、図９に示すように、ＩＰＴＶクライアント３００はＳＩＰ Ｒｅｇｉｓｔｅｒメッセージに拡張ヘッダ（例えば、"X- Ua-Proxy-Scheme"）を追加する。このヘッダフィールドはスキームのリスト（例えば、ｈｔｔｐ，ｒｔｓｐ）を含み、ＩＰＴＶクライアント３００がＨＩＧＡ４００に対してこのスキームのためのＵａプロキシ４１０のアドレスを提供することを要求する。ＨＩＧＡ４００は、次いで、２００ＯＫ応答内で搬送される拡張ヘッダ（例えば、"X-Ua-Proxy-Address"）によって、各スキームのためのＵａプロキシ４１０のアドレスのリストを返す。この実施形態の利点は、ＩＰＴＶクライアント３００が特定のスキームのためのＵａプロキシ４１０のアドレスを要求できることである。例えばＩＰＴＶクライアント３００がＨＴＴＰスキームを使用することを望むがＲＴＳＰスキームを使用することを望まない場合、ＩＰＴＶクライアント３００はＨＴＴＰスキームのためのＵａプロキシのアドレスだけを要求することになろう。

各ＩＰＴＶクライアントに対して固有のアドレスが提供されることが好ましい。この場合、Ｕａプロキシ４１０は、要求メッセージの送信元のＩＰＴＶクライアントに割り当てられたＩＭＰＵを効果的に特定することができる。このことは、次のセクションにおける「アイデンティティ・マッピング機能」に関連して詳細に説明する。

なお、ＨＩＧＡ４００が異なる通信プロトコル（即ち、スキーム）に対して異なるアドレスを割り当てることは、必須ではない。

（アイデンティティ・マッピング機能）
上述したように、Ｕａプロキシ４１０がアプリケーションプロトコルでの要求（例えば、ＨＴＴＰ又はＲＴＳＰのＲｅｑｕｅｓｔメッセージ）をＩＰＴＶ ＡＳ３１０へ送信する際に、Ｕａプロキシ４１０はX-3GPP-Intended-Identityヘッダを全ての要求メッセージに挿入する。このヘッダには、Ｕａプロキシ４１０によって、要求側ＩＰＴＶクライアントに対して割り当てられたＩＭＰＵが埋め込まれる。これにより、ＩＰＴＶ ＡＳ３１０は、ＨＩＧＡ４００経由でＵａインタフェースを介してＩＰＴＶクライアントと通信している場合であってさえも、要求側ＩＰＴＶクライアントを特定することができる（図７参照）。図１０におけるアイデンティティ・マッピング機能１０００は、図５における要求受信ユニット５０１、Ｂ２ＢＵＡ４２０、及びメモリ４３０の組み合わせによって実装可能である。

アイデンティティ・マッピング機能のための１つの可能なメカニズムは、対応するアプリケーションプロトコルでの要求からソースＩＰアドレスとして取得される要求側ＩＰＴＶクライアントのＩＰアドレスを、Ｂ２ＢＵＡ４２０によってメモリ４３０に格納されたマッピングテーブル（図２参照）と比較するものである。Ｕａプロキシ４１０は、その結果、そのＩＰアドレスに割り当てられたＩＭＰＵを特定する。

しかしながら、単一のＩＰアドレスに対して複数のＩＭＰＵが割り当てられる場合（例えば、単一のデバイス内に複数のＩＰＴＶクライアントが備えられる場合）、このメカニズムは正しく機能しないかもしれない。以下の２つのメカニズムは、そのような場合に対処することができる。

（１）各ＩＰＴＶクライアントに対して固有のＵａプロキシアドレスを広告する
このメカニズムは、前のセクションの最後で説明した論点に関連する。即ち、固有のアドレスが各ＩＰＴＶクライアントへ提供される。より具体的には、Ｂ２ＢＵＡ４２０がＩＰＴＶクライアントからＳＩＰ Ｒｅｇｉｓｔｅｒメッセージを受信すると、Ｂ２ＢＵＡ４２０は、このＩＰＴＶクライアントに対して個別に（即ち、一意に）割り当てられたＴＣＰポート（例えば、ＨＴＴＰスキーム及びＲＴＳＰスキームそれぞれのためのもの）を広告する。次いでＢ２ＢＵＡ４２０は、このＩＰＴＶクライアントにちょうど割り当てられたＩＭＰＵに対してＴＣＰポートをマッピングするマッピングテーブルを生成する。換言すれば、Ｂ２ＢＵＡ４２０はＩＰＴＶクライアントに対して固有のアドレスを割り当て、割り当てられたアドレスを割り当てられたＩＭＰＵと関連付けてメモリ４３０内に格納し、割り当てられたアドレスを通知する。そして、Ｕａプロキシ４１０（の要求受信ユニット５０１）が特定のアドレスにおいてアプリケーションプロトコルでのリクエストを受信した場合、Ｕａプロキシはメモリ４３０内に格納されたマッピングテーブルを参照し、その特定のアドレスに割り当てられたＩＭＰＵを特定する。

（２）ＩＰＴＶクライアントが各自のローカルＳＩＰ ＵＲＩをアプリケーションプロトコルでの要求の中に挿入することを義務化する
このソリューションでは、各ＩＰＴＶクライアントは、自分のローカルＳＩＰ ＵＲＩを、例えばＨＴＴＰ／ＲＴＳＰに対する拡張ヘッダフィールドとして全てのアプリケーションプロトコルでの要求内に挿入することを要求される。ＨＩＧＡ４００はローカルＳＩＰ ＵＲＩをＩＭＰＵに変換可能なマッピングテーブル（図２参照）を持っているため、Ｕａプロキシ４１０は要求側ＩＰＴＶクライアントに割り当てられたＩＭＰＵを特定することができる。

（ＴＬＳセッション／接続管理機能）
Ｕａプロキシ４１０は、複数のＩＰＴＶクライアントに対してサービス提供するための複数のＴＬＳセッション及びＴＬＳ接続を維持管理することができる。ＴＬＳセッション及びＴＬＳ接続を管理するために、Ｕａプロキシ４１０の確立ユニット５０２は、ＴＬＳセッション／接続管理機能を備える。

この機能は、既存のＴＬＳセッションをできるだけ多数のＩＰＴＶクライアントで共有することを通じてＵａプロキシ４１０が確立するＴＬＳセッションの数を削減することにより、Ｕａプロキシ４１０がより効率的にＴＬＳセッションを確立することを可能にする。この状況は、２つのＩＰＴＶクライアントが単一のＴＬＳセッションを共有する図１１ＡをＩＰＴＶクライアント毎にＴＬＳセッションが図１１Ｂと比較すると、より良く理解できるであろう。

ＴＬＳセッションの確立は、いずれもコストのかかる大量の暗号演算と多数のメッセージ交換とをＴＬＳハンドシェイクの間に必要とするので、複数のＩＰＴＶによってＴＬＳセッションを共有することは利点がある。

ＴＬＳセッション／接続管理機能によれば、要求受信ユニット５０１（図５参照）が要求メッセージを受信すると、確立ユニット５０２は、受信された要求メッセージのために使用可能なＴＬＳセッションが既に確立されているか否かを判定する。使用可能なＴＬＳセッションが既に確立されている場合、確立ユニット５０２は確立済みＴＬＳセッションを再利用する。そうでない場合、確立ユニット５０２は新たなＴＬＳセッションを確立する。

また、確立ユニット５０２は、可能であれば確立済みＴＬＳ接続を再利用する。より具体的には、要求受信ユニット５０１が要求メッセージを受信すると、確立ユニット５０２は、受信された要求メッセージのために使用可能なＴＬＳ接続が確立されているか否かを判定する。使用可能なＴＬＳ接続が確立されている場合、確立ユニット５０２は確立済みＴＬＳ接続を再利用する。そうでない場合、確立ユニット５０２は新たなＴＬＳ接続を確立する。

いくつかの実施形態では、確立ユニット５０２は、メモリ４３０内にセッション／接続管理テーブルを維持管理する。図１２は、セッション／接続管理テーブルの一例を示す図である。

図１２に示すように、セッション／接続管理テーブルは２つのテーブルを含む。第１のテーブルは、確立済みＴＬＳセッションを特定するＴＬＳセッション・アイデンティティ（ＩＤ）と、各ＴＬＳセッションに関する３つの属性（ＮＡＦ−ＩＤ、スキーム、ＩＳＩＭ−ＩＤ）とを含む。ＮＡＦ−ＩＤは、例えば、宛先ＩＭＳ ＡＳを特定するFully Qualified Domain Name（ＦＱＤＮ）である。各ＴＬＳセッションは更に、第２のテーブルにおけるエントリを指し示しており、第２のテーブルでは同一のＴＬＳセッションを共有するＴＬＳ接続が維持管理される。

確立ユニット５０２がＴＬＳセッションを確立する際に、確立ユニット５０２はＴＬＳセッションＩＤを、ＮＡＦ−ＩＤ、スキーム（通信プロトコル）、及びＩＳＩＭ−ＩＤと関連付けて第１のテーブル内に格納する。格納されたＩＳＩＭ−ＩＤは、要求受信ユニット５０１によって特定されたＩＭＰＵを含むＩＳＩＭを特定する。確立ユニット５０２がＴＬＳ接続を確立する際に、確立ユニット５０２は確立済みＴＬＳ接続を特定するＴＬＳ接続ＩＤを、ＴＬＳセッションＩＤ、及び要求受信ユニット５０１によって特定されたＩＭＰＵと関連付けて格納する。

要求受信ユニット５０１が要求メッセージを受信すると、確立ユニット５０２は、要求中のＮＡＦ−ＩＤ及びスキーム、並びに要求受信ユニット５０１によって特定されたＩＳＩＭ−ＩＤに関連付けられたＴＬＳセッションＩＤが第１のテーブル内に格納されている場合に、要求メッセージのために使用可能なＴＬＳセッションが既に確立されている（即ち、存在する）と判断することができる。使用可能なＴＬＳセッションが存在する場合、確立ユニット５０２は第２のテーブルを参照し、そのＴＬＳセッションＩＤ及び要求受信ユニット５０１によって特定されたＩＭＰＵに関連付けられたＴＬＳ接続ＩＤが第２のテーブル内に格納されている場合に、要求メッセージのために使用可能なＴＬＳ接続が既に確立されている（即ち、存在する）と判断することができる。

図１３は、確立ユニット５０２がＴＬＳセッション及びＴＬＳ接続を確立する手順を示すフローチャートである。受信ユニット５０１が要求メッセージを受信すると、確立ユニット５０２は図１３の手順を実行する。

ステップＳ１３０１で、受信ユニット５０１は、要求側ＩＰＴＶクライアントに割り当てられたＩＭＰＵを特定し、特定されたＩＭＰＵを含むＩＳＩＭを特定する。受信ユニット５０１は確立ユニット５０２に対して、特定されたＩＭＰＵ及びＩＳＩＭのＩＭＰＵ−ＩＤ及びＩＳＩＭ−ＩＤを知らせる。受信ユニット５０１は、このステップにおける特定を、要求メッセージが受信されたアドレスとメモリ４３０内に格納されているマッピングテーブルの内容とに基づいて実行する。

ステップＳ１３０２で、受信ユニット５０１は、要求メッセージ内で指定されたＮＡＦ−ＩＤ及びスキームを特定し、確立ユニット５０２に対して特定されたＮＡＦ−ＩＤ及びスキームを通知する。ＮＡＦ−ＩＤは例えば、要求メッセージの"Host"ヘッダフィールド内で指定される。

ステップＳ１３０３で、確立ユニット５０２は、メモリ４３０内に格納されたセッション／接続管理テーブルを検索して、通知されたＮＡＦ−ＩＤ、スキーム、及びＩＳＩＭ−ＩＤに合致するエントリを探す。エントリが発見された場合、処理はステップＳ１３０４に進み、そうでない場合、処理はステップＳ１３０７に進む。

ステップＳ１３０４で、確立ユニット５０２は、セッション／接続管理テーブルを検索して、通知されたＩＭＰＵ−ＩＤ及びステップＳ１３０３で特定されたエントリのＴＬＳセッションＩＤに合致するエントリを探す。合致するエントリが発見された場合、処理はステップＳ１３０５に進み、そうでない場合、処理はステップＳ１３０６に進む。

ステップＳ１３０５で、確立ユニット５０２は、ステップＳ１３０４で特定されたエントリのＴＬＳ接続ＩＤによって特定される確立済みＴＬＳ接続を再利用することを決定する。

ステップＳ１３０６で、確立ユニット５０２は、ステップＳ１３０３で特定されたエントリのＴＬＳセッションＩＤによって特定される確立済みＴＬＳセッションの上に新たなＴＬＳ接続を確立する。確立ユニット５０２は、確立されたＴＬＳ接続を特定するＴＬＳ接続ＩＤを生成し、このＴＬＳ接続ＩＤと特定されたＩＭＰＵ−ＩＤとを含んだ新たなエントリをセッション／接続管理テーブルの第２のテーブルに追加する。

ステップＳ１３０７で、確立ユニット５０２は、指定されたスキームのための新たなＴＬＳセッションを確立する。確立ユニット５０２は、確立されたＴＬＳセッションを特定するＴＬＳセッションＩＤを生成し、このＴＬＳセッションＩＤと、特定されたＮＡＦ−ＩＤ、スキーム、及びＩＳＩＭ−ＩＤとを含んだ新たなエントリをセッション／接続管理テーブルの第１のテーブルに追加する。いくつかの実施形態では、ＴＬＳセッションを確立する際に、確立ユニット５０２は（認証情報送信ユニット５０３に関連して）、ステップＳ１３０１で特定されたＩＳＩＭから導出されるＫｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦを使用することができる。

ステップＳ１３０８で、確立ユニット５０２は、ステップＳ１３０７で確立されたセッションの上に新たなＴＬＳ接続を確立する。確立ユニット５０２は、確立されたＴＬＳ接続を特定するＴＬＳ接続ＩＤを生成し、このＴＬＳ接続ＩＤと特定されたＩＭＰＵ−ＩＤとを含んだ新たなエントリをセッション／接続管理テーブルの第２のテーブルに追加する。

なお、単一のＴＬＳセッションを複数のＩＰＴＶクライアントのための複数のＴＬＳ接続で共有することを何らかの理由により拒否するＮＡＦ（即ち、ＩＰＴＶ ＡＳ）が存在する場合もある。そのような場合、ＴＬＳセッションは各ＴＬＳ接続について新たに確立されるであろう。ＴＬＳセッションの共有を拒絶するこの種のＮＡＦにＵａプロキシ４１０が出くわした場合、Ｕａプロキシ４１０はこのＮＡＦを記憶し、次回はこのＮＡＦとのＴＬＳセッションを共有しようと試みることをしない。

（手順例）
図１４は、ＴＬＳセッション／接続管理機能を持つＨＩＧＡ４００が要求メッセージ及び応答メッセージを処理する手順を示すシーケンス図である。図１４では、Ｕｂインタフェースを介して実行されるＩＳＩＭ毎の全てのＧＢＡブートストラップをＨＩＧＡ４００が既に実行しているものとし、また、全てのＩＰＴＶクライアントがＨＩＧＡ４００に登録しており、それゆえ、ＨＩＧＡ４００はＩＰＴＶクライアントに割り当てられた全てのＩＭＰＵをＩＭＳネットワークに登録しているものとし、また、ＨＩＧＡ４００は図７乃至９を参照して上述したようにＵａプロキシのアドレスを既に広告しているものとする。

ステップＳ１４０１で、ＩＰＴＶクライアント３００は、ＨＴＴＰスキームに関連付けられたＵａプロキシのアドレスに対してＨＴＴＰ要求（即ち、アプリケーションプロトコルでの要求）を送信する。ＨＴＴＰ要求は"Host"ヘッダを含み、"Host"ヘッダには目標（即ち、宛先）ＩＰＴＶ ＡＳのＦＱＤＮ（即ち、ＮＡＦ−ＩＤ）が埋め込まれている。

ステップＳ１４０２で、Ｕａプロキシ４１０は、ＩＰＴＶクライアント３００に割り当てられたＩＭＰＵを特定する。Ｕａプロキシ４１０はまた、前のセクションで論じたＴＬＳセッション／接続管理機能に従い、新たなＴＬＳセッションが確立されるべきであるか否かを判定する。この例では、新たなＴＬＳセッションが確立されるべきであると判定される。

ステップＳ１４０３で、Ｕａプロキシ４１０は、ＧＢＡ＿ＭＥ又はＧＢＡ＿Ｕを用いて、ステップＳ１４０２で特定されたＩＭＰＵを含む特定のＩＳＩＭからＮＡＦ固有の鍵を導出し、ＩＰＴＶ ＡＳ３１０とのＴＬＳセッション及びＴＬＳ接続を確立する。

ステップＳ１４０４で、必要であれば（即ち、ステップＳ１４０３においてＮＡＦ固有の鍵なしで証明書ベースのＴＬＳ確立が実行される場合）、ＨＴＴＰ Ｄｉｇｅｓｔ認証がＧＢＡ Ｕａインタフェース毎に実行される。

ステップＳ１４０５で、Ｕａプロキシ４１０は、ステップＳ１４０２で特定されたＩＭＰＵが埋め込まれたX-3GPP-Intended-IdentityヘッダをＨＴＴＰ要求に挿入し、ＨＴＴＰ要求をＴＬＳ接続内にカプセル化する。

ステップＳ１４０６で、ＩＰＴＶ ＡＳ３１０はＨＴＴＰ要求を処理し、２００ＯＫ応答を返す。

ステップＳ１４０７で、Ｕａプロキシ４１０は、ＴＬＳ接続から２００ＯＫ応答のカプセル化を解除し、ステップＳ１４０２で特定されたＩＭＰＵに関連付けられているＩＰＴＶクライアント３００に対して２００ＯＫ応答を転送する。

ステップＳ１４０８で、ＩＰＴＶクライアント７００は、ＨＴＴＰスキームに関連付けられたＵａプロキシのアドレスに対してＨＴＴＰ要求（即ち、アプリケーションプロトコルでの要求）を送信する。ＨＴＴＰ要求は"Host"ヘッダを含み、"Host"ヘッダには宛先ＩＰＴＶ ＡＳ３１０のＮＡＦ−ＩＤが埋め込まれている。この事例では、ＮＡＦ−ＩＤはステップＳ１４０１におけるものと同一である。

ステップＳ１４０９で、Ｕａプロキシ４１０は、ＩＰＴＶクライアント７００に割り当てられたＩＭＰＵを特定する。Ｕａプロキシ４１０はまた、新たなＴＬＳセッションが確立されるべきであるか否かを判定する。この例では、ＨＴＴＰプロトコルのためのＩＰＴＶ ＡＳ３１０との既存のＴＬＳセッションが既に存在するので、このＴＬＳセッションが再利用されるべきであると判定される。

ステップＳ１４１０で、Ｕａプロキシ４１０は、ステップＳ１４０３で確立された既存のＴＬＳセッションを再利用することにより、ＩＰＴＶ ＡＳ３１０とのＴＬＳ接続を確立する。

ステップＳ１４１１で、Ｕａプロキシ４１０は、ステップＳ１４０９で特定されたＩＭＰＵが埋め込まれたX-3GPP-Intended-IdentityヘッダをＨＴＴＰ要求に挿入し、ＨＴＴＰ要求をＴＬＳ接続内にカプセル化する。

ステップＳ１４１２で、ＩＰＴＶ ＡＳ３１０はＨＴＴＰ要求を処理し、２００ＯＫ応答を返す。

ステップＳ１４１３で、Ｕａプロキシ４１０は、ＴＬＳ接続から２００ＯＫ応答のカプセル化を解除し、ステップＳ１４０９で特定されたＩＭＰＵに関連付けられているＩＰＴＶクライアント７００に対して２００ＯＫ応答を転送する。

（本発明の利点）
本発明は、ＨＩＧＡを用いることにより、ＩＭＳ非対応のクライアント端末がＧＢＡ ＮＡＦとして機能するＩＭＳ ＡＳとＵａインタフェースを介して通信することができるという点で、利点がある。また、いくつかの実施形態によれば、ＨＩＧＡは各クライアント端末を効果的に区別可能であり、ＨＩＧＡは確立済みのセッション及び接続を効果的に共有可能である。

典型的な実施形態を参照して本発明を説明してきたが、理解すべきこととして、本発明は開示された典型的な実施形態に限定されない。以下の請求項の範囲には、修正、及び、均等な構造及び機能を全て包含するように、最も広い解釈が与えられる。なお、本発明はクライアント端末がＩＭＳ非対応の場合に特に利点を有するが、ＩＭＳ対応のクライアント端末もマルチメディアゲートウェイ経由でＩＭＳ ＡＳと通信することができる。

Claims (24)

1. ＩＰマルチメディア・サブシステム（ＩＭＳ）加入者ＩＤモジュール（ＩＳＩＭ）と、クライアント端末と通信するための第１のインタフェースと、呼セッション制御機能（ＣＳＣＦ）とＧｍインタフェースを介して通信するための、そしてＩＭＳネットワークに配置された汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）ネットワークアプリケーション機能（ＮＡＦ）として機能するＩＭＳアプリケーションサーバ（ＩＭＳ ＡＳ）とＵａインタフェースを介して通信するための第２のインタフェースと、を有するマルチメディアゲートウェイであって、
   前記クライアント端末から受信したＳＩＰ登録要求メッセージに応えて、前記ＩＳＩＭから取得したＩＭＳパブリック・アイデンティティ（ＩＭＰＵ）を前記クライアント端末に割り当て、前記クライアント端末に割り当てたＩＭＰＵを前記ＩＭＳネットワークに登録するために前記ＳＩＰ登録要求メッセージを前記Ｇｍインタフェースを介して送信する登録手段（４２０）と、
   ＧＢＡ ＮＡＦとして機能する宛先のＩＭＳ ＡＳ及びアプリケーションプロトコルを指定するアプリケーションプロトコルでの要求メッセージを前記クライアント端末から受信し、当該クライアント端末に割り当てられたＩＭＰＵを特定する要求受信手段（５０１）と、
   前記アプリケーションプロトコルを用いてＧＢＡ ＮＡＦとして機能する前記ＩＭＳ ＡＳと通信するためのＴＬＳセッションを確立し、当該ＴＬＳセッション上にＧＢＡ ＮＡＦとして機能する前記ＩＭＳ ＡＳとのＴＬＳ接続を確立する確立手段（５０２）と、
   前記特定されたＩＭＰＵを含んだＩＳＩＭから導出されるＮＡＦ固有鍵であって、ＧＢＡ ＮＡＦとして機能する前記ＩＭＳ ＡＳに固有のＮＡＦ固有鍵から導出される、認証情報をＧＢＡ ＮＡＦとして機能する前記ＩＭＳ ＡＳへ送信する認証情報送信手段（５０３）と、
   前記アプリケーションプロトコルでの要求メッセージを前記特定されたＩＭＰＵと共に、前記Ｕａインタフェース上で前記ＴＬＳ接続を介してＧＢＡ ＮＡＦとして機能する前記ＩＭＳ ＡＳへ送信する要求送信手段（５０４）と、
   前記アプリケーションプロトコルでの要求メッセージに対する応答として、前記ＴＬＳ接続を介してＧＢＡ ＮＡＦとして機能する前記ＩＭＳ ＡＳからアプリケーションプロトコルでの応答メッセージを受信する応答受信手段（５０５）と、
   前記アプリケーションプロトコルでの応答メッセージを前記クライアント端末へ送信する応答送信手段（５０６）と、
   を備えることを特徴とするマルチメディアゲートウェイ。
2. 前記確立手段は、
   前記要求受信手段が前記アプリケーションプロトコルでの要求メッセージを受信した場合に、前記ＴＬＳセッションが確立されているか否かを判定する判定手段と、
   前記ＴＬＳセッションが確立されていないと判定された場合に、前記ＴＬＳセッションを確立する確立手段と、
   を備えることを特徴とする請求項１に記載のマルチメディアゲートウェイ。
3. 前記確立手段は、
   ＧＢＡ ＮＡＦとして機能する前記宛先のＩＭＳ ＡＳと、前記アプリケーションプロトコルと、前記特定されたＩＭＰＵを含んだ前記ＩＳＩＭと、に関連付けて、前記ＴＬＳセッションを特定するＴＬＳセッションＩＤを格納する格納手段と、
   ＧＢＡ ＮＡＦとして機能する前記宛先のＩＭＳ ＡＳと、前記アプリケーションプロトコルと、前記特定されたＩＭＰＵを含んだ前記ＩＳＩＭと、に関連付けられた前記ＴＬＳセッションＩＤが格納されている場合に、前記ＴＬＳセッションが確立されていると判定する判定手段と、
   を備えることを特徴とする請求項２に記載のマルチメディアゲートウェイ。
4. 前記確立手段は、
   前記要求受信手段が前記アプリケーションプロトコルでの要求メッセージを受信した場合に、前記ＴＬＳ接続が確立されているか否かを判定する判定手段と、
   前記ＴＬＳ接続が確立されていないと判定された場合に、前記ＴＬＳ接続を確立する確立手段と、
   を備えることを特徴とする請求項３に記載のマルチメディアゲートウェイ。
5. 前記確立手段は、
   前記ＴＬＳセッションＩＤと、前記特定されたＩＭＰＵと、に関連付けて、前記ＴＬＳ接続を特定するＴＬＳ接続ＩＤを格納する格納手段と、
   前記ＴＬＳセッションＩＤと、前記特定されたＩＭＰＵと、に関連付けられた前記ＴＬＳ接続ＩＤが格納されている場合に、前記ＴＬＳ接続が確立されていると判定する判定手段と、
   を備えることを特徴とする請求項４に記載のマルチメディアゲートウェイ。
6. 前記登録手段は、
   前記要求受信手段が前記クライアント端末からの前記アプリケーションプロトコルでの要求メッセージを受信する、前記クライアント端末に固有のアドレスを割り当てる割り当て手段と、
   前記クライアント端末に割り当てられたＩＭＰＵに関連付けて前記アドレスを格納する格納手段と、
   前記クライアント端末に対して前記アドレスを通知する通知手段と、
   を備え、
   前記要求受信手段は、前記アドレスと前記ＩＭＰＵとの間の関連付けに基づいて、前記クライアント端末に割り当てられたＩＭＰＵを特定する
   ことを特徴とする請求項１乃至５のいずれか１項に記載のマルチメディアゲートウェイ。
7. 前記登録手段は、
   各々が異なるアプリケーションプロトコルに関連付けられた複数のアドレスを割り当てる割り当て手段と、
   前記クライアント端末に割り当てられたＩＭＰＵに関連付けて前記複数のアドレスを格納する格納手段と、
   前記クライアント端末に対して前記複数のアドレスを通知する通知手段と、
   を備えることを特徴とする請求項６に記載のマルチメディアゲートウェイ。
8. 前記ＳＩＰ登録要求メッセージは少なくとも１つのアプリケーションプロトコル・スキームを指定し、
   前記登録手段は、
   前記少なくとも１つのアプリケーションプロトコル・スキームの数と同数の、各々が異なるアプリケーションプロトコル・スキームに関連付けられたアドレスを割り当てる割り当て手段と、
   前記クライアント端末に割り当てられたＩＭＰＵに関連付けて前記同数のアドレスを格納する格納手段と、
   前記クライアント端末に対して前記同数のアドレスを通知する通知手段と、
   を備えることを特徴とする請求項６に記載のマルチメディアゲートウェイ。
9. 前記登録手段は、前記クライアント端末に割り当てられたＩＭＰＵに関連付けて、前記クライアント端末のユニバーサル・リソース・アイデンティファイア（ＵＲＩ）を格納し、
   前記要求受信手段は、前記アプリケーションプロトコルでの要求メッセージに含まれるＵＲＩと前記ＩＭＰＵとの関連付けに基づいて、前記クライアント端末に割り当てられたＩＭＰＵを特定する
   ことを特徴とする請求項１乃至５のいずれか１項に記載のマルチメディアゲートウェイ。
10. 前記認証情報送信手段は、前記確立手段が前記ＴＬＳセッションを確立する際に、前記認証情報を送信する
    ことを特徴とする請求項１乃至９のいずれか１項に記載のマルチメディアゲートウェイ。
11. 前記認証情報送信手段は、前記確立手段が前記ＴＬＳ接続を確立した後に前記ＩＭＳ ＡＳからの要求に応えて、前記認証情報を送信する
    ことを特徴とする請求項１乃至９のいずれか１項に記載のマルチメディアゲートウェイ。
12. 前記アプリケーションプロトコルでの要求メッセージは、ＨＴＴＰ Ｒｅｑｕｅｓｔメッセージ、又はＲＴＳＰ Ｒｅｑｕｅｓｔメッセージである
    ことを特徴とする請求項１乃至１１のいずれか１項に記載のマルチメディアゲートウェイ。
13. ＩＳＩＭと、クライアント端末と通信するための第１のインタフェースと、ＣＳＣＦとＧｍインタフェースを介して通信するための、そしてＩＭＳネットワークに配置されたＧＢＡ ＮＡＦとして機能するＩＭＳ ＡＳとＵａインタフェースを介して通信するための第２のインタフェースと、を有するマルチメディアゲートウェイための方法であって、
    前記クライアント端末からＳＩＰ登録要求メッセージを受信するステップ（Ｓ６０１）と、
    前記クライアント端末から受信した前記ＳＩＰ登録要求メッセージに応えて、前記ＩＳＩＭから取得したＩＭＰＵを前記クライアント端末に割り当て、前記クライアント端末に割り当てたＩＭＰＵを前記ＩＭＳネットワークに登録するために前記ＳＩＰ登録要求メッセージを前記Ｇｍインタフェースを介して送信するステップ（Ｓ６０２）と、
    ＧＢＡ ＮＡＦとして機能する宛先のＩＭＳ ＡＳ及びアプリケーションプロトコルを指定するアプリケーションプロトコルでの要求メッセージを前記クライアント端末から受信し、当該クライアント端末に割り当てられたＩＭＰＵを特定するステップ（Ｓ６０６）と、
    前記アプリケーションプロトコルを用いてＧＢＡ ＮＡＦとして機能する前記ＩＭＳ ＡＳと前記Ｕａインタフェースを介して通信するためのＴＬＳセッションを確立し、当該ＴＬＳセッション上にＧＢＡ ＮＡＦとして機能する前記ＩＭＳ ＡＳとのＴＬＳ接続を確立するステップ（Ｓ６０７）と、
    前記特定されたＩＭＰＵを含んだＩＳＩＭから導出されるＮＡＦ固有鍵であって、ＧＢＡ ＮＡＦとして機能する前記ＩＭＳ ＡＳに固有のＮＡＦ固有鍵から導出される、認証情報をＧＢＡ ＮＡＦとして機能する前記ＩＭＳ ＡＳへ前記Ｕａインタフェースを介して送信するステップ（Ｓ６０７，Ｓ１４０４）と、
    前記アプリケーションプロトコルでの要求メッセージを前記特定されたＩＭＰＵと共に、前記Ｕａインタフェース上で前記ＴＬＳ接続を介してＧＢＡ ＮＡＦとして機能する前記ＩＭＳ ＡＳへ送信するステップ（Ｓ６０８）と、
    前記アプリケーションプロトコルでの要求メッセージに対する応答として、前記ＴＬＳ接続を介してＧＢＡ ＮＡＦとして機能する前記ＩＭＳ ＡＳからアプリケーションプロトコルでの応答メッセージを受信するステップ（Ｓ６０９）と、
    前記アプリケーションプロトコルでの応答メッセージを前記クライアント端末へ送信するステップ（Ｓ６１０）と、
    を備えることを特徴とする方法。
14. 前記確立するステップにおいて、
    前記アプリケーションプロトコルでの要求メッセージを受信する前記ステップにおいて前記アプリケーションプロトコルでの要求メッセージが受信された場合に、前記ＴＬＳセッションが確立されているか否かを判定し、
    前記ＴＬＳセッションが確立されていないと判定された場合に、前記ＴＬＳセッションを確立する
    ことを特徴とする請求項１３に記載の方法。
15. 前記確立するステップにおいて、
    ＧＢＡ ＮＡＦとして機能する前記宛先のＩＭＳ ＡＳと、前記アプリケーションプロトコルと、前記特定されたＩＭＰＵを含んだ前記ＩＳＩＭと、に関連付けて、前記ＴＬＳセッションを特定するＴＬＳセッションＩＤを格納し、
    ＧＢＡ ＮＡＦとして機能する前記宛先のＩＭＳ ＡＳと、前記アプリケーションプロトコルと、前記特定されたＩＭＰＵを含んだ前記ＩＳＩＭと、に関連付けられた前記ＴＬＳセッションＩＤが格納されている場合に、前記ＴＬＳセッションが確立されていると判定する
    ことを特徴とする請求項１４に記載の方法。
16. 前記確立するステップにおいて、
    前記アプリケーションプロトコルでの要求メッセージを受信する前記ステップにおいて前記アプリケーションプロトコルでの要求メッセージが受信された場合に、前記ＴＬＳ接続が確立されているか否かを判定し、
    前記ＴＬＳ接続が確立されていないと判定された場合に、前記ＴＬＳ接続を確立する
    ことを特徴とする請求項１５に記載の方法。
17. 前記確立するステップにおいて、
    前記ＴＬＳセッションＩＤと、前記特定されたＩＭＰＵと、に関連付けて、前記ＴＬＳ接続を特定するＴＬＳ接続ＩＤを格納し、
    前記ＴＬＳセッションＩＤと、前記特定されたＩＭＰＵと、に関連付けられた前記ＴＬＳ接続ＩＤが格納されている場合に、前記ＴＬＳ接続が確立されていると判定する
    ことを特徴とする請求項１６に記載の方法。
18. 割り当て登録する前記ステップにおいて、
    前記アプリケーションプロトコルでの要求メッセージを受信する前記ステップにおいて前記クライアント端末からの前記アプリケーションプロトコルでの要求メッセージが受信される、前記クライアント端末に固有のアドレスを割り当て、
    前記クライアント端末に割り当てられたＩＭＰＵに関連付けて前記アドレスを格納し、
    前記クライアント端末に対して前記アドレスを通知し、
    前記アプリケーションプロトコルでの要求メッセージを受信する前記ステップにおいて、前記アドレスと前記ＩＭＰＵとの間の関連付けに基づいて、前記クライアント端末に割り当てられたＩＭＰＵを特定する
    ことを特徴とする請求項１３乃至１７のいずれか１項に記載の方法。
19. 割り当て登録する前記ステップにおいて、
    各々が異なるアプリケーションプロトコル・スキームに関連付けられた複数のアドレスを割り当て、
    前記クライアント端末に割り当てられたＩＭＰＵに関連付けて前記複数のアドレスを格納し、
    前記クライアント端末に対して前記複数のアドレスを通知する
    ことを特徴とする請求項１８に記載の方法。
20. 前記登録要求メッセージは少なくとも１つのアプリケーションプロトコル・スキームを指定し、
    割り当て登録する前記ステップにおいて、
    前記少なくとも１つのアプリケーションプロトコル・スキームの数と同数の、各々が異なるアプリケーションプロトコル・スキームに関連付けられたアドレスを割り当て、
    前記クライアント端末に割り当てられたＩＭＰＵに関連付けて前記同数のアドレスを格納し、
    前記クライアント端末に対して前記同数のアドレスを通知する
    ことを特徴とする請求項１８に記載の方法。
21. 割り当て登録する前記ステップにおいて、前記クライアント端末に割り当てられたＩＭＰＵに関連付けて、前記クライアント端末のＵＲＩを格納し、
    前記アプリケーションプロトコルでの要求メッセージを受信する前記ステップにおいて、前記アプリケーションプロトコルでの要求メッセージに含まれるＵＲＩと前記ＩＭＰＵとの関連付けに基づいて、前記クライアント端末に割り当てられたＩＭＰＵを特定する
    ことを特徴とする請求項１３乃至１７のいずれか１項に記載の方法。
22. 前記認証情報を送信する前記ステップにおいて、前記確立するステップで前記ＴＬＳセッションが確立される際に、前記認証情報を送信する
    ことを特徴とする請求項１３乃至２１のいずれか１項に記載の方法。
23. 前記認証情報を送信する前記ステップにおいて、前記確立するステップで前記ＴＬＳ接続が確立された後にＧＢＡ ＮＡＦとして機能する前記ＩＭＳ ＡＳからの要求に応えて、前記認証情報を送信する
    ことを特徴とする請求項１３乃至２１のいずれか１項に記載の方法。
24. 前記アプリケーションプロトコルでの要求メッセージは、ＨＴＴＰ Ｒｅｑｕｅｓｔメッセージ、又はＲＴＳＰ Ｒｅｑｕｅｓｔメッセージである
    ことを特徴とする請求項１３乃至２３のいずれか１項に記載の方法。

Images