プロトコル変換システム、プロトコル変換装置、ゲートウェイサーバおよびプロトコル変換方法
【課題】サーバおよびストレージのなりすましを困難にするセキュアな広帯域のＩＰ−ＳＡＮを構成できるプロトコル変換システム、プロトコル変換装置、ゲートウェイサーバおよびプロトコル変換方法を提供する。
【解決手段】ｉＳＮＳプロトコルとＳＩＰプロトコルを変換するｉＳＮＳプロキシ１７、１８をｉＳＮＳクライアント１２、１３とＩＭＳコア２０との間に設置する。また、ＩＭＳのＳＩＰ−ＡＳ（アプリケーションサーバ）として、ｉＳＮＳプロキシ１７、１８から発行されたＳＩＰ信号からｉＳＮＳプロトコルを復元し、ｉＳＮＳサーバ１９にアクセス可能なｉＳＮＳゲートウェイサーバ１１を、ＩＭＳコア２０とｉＳＮＳサーバ１９との間に設置する。
【解決手段】ｉＳＮＳプロトコルとＳＩＰプロトコルを変換するｉＳＮＳプロキシ１７、１８をｉＳＮＳクライアント１２、１３とＩＭＳコア２０との間に設置する。また、ＩＭＳのＳＩＰ−ＡＳ（アプリケーションサーバ）として、ｉＳＮＳプロキシ１７、１８から発行されたＳＩＰ信号からｉＳＮＳプロトコルを復元し、ｉＳＮＳサーバ１９にアクセス可能なｉＳＮＳゲートウェイサーバ１１を、ＩＭＳコア２０とｉＳＮＳサーバ１９との間に設置する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ストレージとサーバ間の接続管理を行うためのプロトコルであるｉＳＮＳ（Ｉｎｔｅｒｎｅｔ Ｓｔｏｒａｇｅ Ｎａｍｅ Ｓｅｒｖｉｃｅ）のクライアントとサーバ間の通信を、ＳＩＰプロトコルベースのＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）ネットワークを中継機能として利用することで、広帯域のＩＰ−ＳＡＮ（ＩＰ−Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）管理を可能とするプロトコル変換技術に関する。
【背景技術】
【０００２】
単体、もしくは複数のハードディスクドライブの集合体、あるいは専用の制御部で複数のハードディスクドライブを制御するディスクアレイ装置等から構成されるストレージ装置が実用化されている。ストレージ装置とホスト装置（サーバ、ＰＣ）間を接続するインターフェース技術としては、ファイバチャネル（Ｆｉｂｅｒ ｃｈａｎｎｅｌ）、インフィニバンド（ＩｎｆｉｎｉＢａｎｄ）、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ）などがある。ＳＣＳＩインターフェースは、近距離間を経済的に接続する用途として優れ、既に広く普及している。当該インターフェースでは、クライアントに相当する機能をイニシエータ、サーバに相当する機能をターゲットと呼び、イニシエータとターゲット間でＳＣＳＩコマンド（ＣＤＢ：Ｃｏｍｍａｎｄ Ｄｅｓｃｒｉｐｔｏｒ Ｂｌｏｃｋ）を交換する。ｉＳＣＳＩ（ｉｎｔｅｒｎｅｔ ＳＣＳＩ）技術は、２００４年にネットワークプロトコルであるＴＣＰ／ＩＰの上位プロトコルとしてＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）でＲＦＣ３７２０によって標準化された（非特許文献１参照）。現在、ｉＳＣＳＩ技術は、ギガビット以上の回線品質、特にデータセンター内、データセンター間や大規模ＬＡＮシステム等の基幹回線で利用されている。ｉＳＣＳＩ技術は、非特許文献１でＴＣＰコネクションを複数利用する方法を規定しているが、オプション機能のため必ずしも実装されているわけではない。
【０００３】
ｉＳＮＳ（Ｉｎｔｅｒｎｅｔ Ｓｔｏｒａｇｅ Ｎａｍｅ Ｓｅｒｖｉｃｅ）技術は、ＴＣＰ／ＩＰネットワーク上で、上記ｉＳＣＳＩ、ｉＦＣＰ（Ｉｎｔｅｒｎｅｔ Ｆｉｂｅｒ ｃｈａｎｎｅｌ Ｐｒｏｔｏｃｏｌ）デバイスの検出、構成管理等の機能を提供するインターネット標準のストレージ専用のネームサービス（名前解決）規格であり、２００５年９月にＲＦＣ４１７１として制定された（非特許文献２参照）。ｉＳＮＳサーバは、管理デバイスに実装されたｉＳＮＳクライアント機能を通じて各デバイスのプロファイル情報、例えば、ＩＰアドレスやＲＦＣ３７２１（非特許文献３参照）で定義されたｉＳＣＳＩ名を管理する他、ｉＳＮＳサーバとｉＳＮＳクライアント間の相互死活管理、デバイス間のアクセス関係を定義するディスカバリドメインの管理、同一ドメイン内でのプロファイル共有等を実現する。特に、ドメイン内のプロファイル共有によってドメイン所属デバイスのＩＰアドレスリストを取得できることから、これをアクセスコントロールリスト（ＡＣＬ）に適用して各デバイスからのアクセスに対して動的Ｌ３制御を行うことができる。
【０００４】
ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）は、固定電話網や移動体通信網など、回路スイッチやパケットスイッチが異なっていた公衆通信サービスを、ＩＰ技術やインターネット電話で使われるプロトコルであるＳＩＰ（非特許文献４参照）で統合し、マルチメディアサービスを実現させる通信方式である。第３世代携帯電話規格の標準化団体であり、Ｗ−ＣＤＭＡ方式を策定した３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）と、ＣＤＭＡ２０００方式を策定した３ＧＰＰ２（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ ２）によって標準化が行われている。
ＩＭＳは、３ＧＰＰリリース５（ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｓｐｅｃｉｆｉｃａｔｉｏｎｓ）で、ＮＧＮ（Ｎｅｗ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）向けのＳＩＰベースＭｕｌｔｉｍｅｄｉａ Ｄｏｍａｉｎが加えられたことに起因する。このため、３ＧＰＰではＩＭＳと呼ばれているが、３ＧＰＰ２ではＭＭＤ（Ｍｕｌｔｉｍｅｄｉａ Ｄｏｍａｉｎ）と呼ばれている。
【０００５】
ＳＩＰを利用したプレゼンス情報の記述には、ＲＦＣ３８６３（非特許文献６参照）で標準化されたＸＭＬ形式のデータフォーマットＰＩＤＦ（Ｐｒｅｓｅｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｄａｔａ Ｆｏｒｍａｔ）がある。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ（ｉＳＣＳＩ）， ＲＦＣ３７２０（Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ）， Ａｐｒ ２００４． Ｕｐｄａｔｅｄ ｂｙ ＲＦＣｓ３９８０， ４８５０， ５０４８．
【非特許文献２】Ｉｎｔｅｒｎｅｔ Ｓｔｏｒａｇｅ Ｎａｍｅ Ｓｅｒｖｉｃｅ（ｉＳＮＳ）， ＲＦＣ４１７１（Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ）， Ｓｅｐ ２００５．
【非特許文献３】Ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ（ｉＳＣＳＩ） Ｎａｍｉｎｇ ａｎｄ Ｄｉｓｃｏｖｅｒｙ， ＲＦＣ３７２１（Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ）， Ａｐｒ ２００４．
【非特許文献４】ＳＩＰ： Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ， ＲＦＣ３２６１（Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ）， Ｊｕｎｅ ２００２． Ｕｐｄａｔｅｄ ｂｙ ＲＦＣｓ３２６５， ３８５３， ４３２０， ４９１６．
【非特許文献５】Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）−Ｓｐｅｃｉｆｉｃ Ｅｖｅｎｔ Ｎｏｔｉｆｉｃａｔｉｏｎ， ＲＦＣ３２６５（Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ）， Ｊｕｎｅ ２００２．
【非特許文献６】Ｐｒｅｓｅｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｄａｔａ Ｆｏｒｍａｔ（ＰＩＤＦ）， ＲＦＣ３８６３（Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ）， Ａｕｇ ２００４．
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ｉＳＣＳＩを代表とするＩＰストレージの普及が進んだことから、ＩＰストレージと当該ストレージに接続する機能（イニシエータ）を実装した機器が増えている。この結果、遠隔地にあるＩＰストレージとの接続など、広帯域網を想定した需要が増えると見込まれる。ＩＰストレージの接続管理機能として、ＲＦＣ４１７１で制定されたｉＳＮＳが存在する。しかし、ｉＳＮＳは、ＬＡＮ向け、あるいは狭い管理エリアを想定して設計された経緯から、サーバおよびストレージのなりすまし等に対応するセキュリティ機能をもたないという課題がある。
【０００８】
本発明は、このような問題点に鑑みてなされたものであり、本発明の目的は、サーバおよびストレージのなりすましを困難にするセキュアな広帯域のＩＰ−ＳＡＮを構成できるプロトコル変換システム、プロトコル変換装置、ゲートウェイサーバおよびプロトコル変換方法を提供することにある。
【課題を解決するための手段】
【０００９】
通信事業者の運用する広帯域ＩＰ網では、ＩＰ−ＳＡＮにも適用可能な回線の高品質化や帯域保証機能の実装が進み、併せて、回線認証機能を伴う将来的なＩＭＳの導入の可能性がある。当該網を利用して、実際にＩＰ−ＳＡＮを経済的に、かつ大規模に実現するには、既に普及の進んでいるｉＳＮＳクライアント機能を前提に、ｉＳＮＳクライアント機能を有する機器とＩＭＳネットワークの間にプロトコル変換機能を用意する方法が考えられる。
本発明は、ＩＭＳ網へのｉＳＮＳクライアント収容に際して、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換する機能を設置することで、回線認証機能を利用した、なりすまし対応などのセキュリティ機能を備えるとともに、ＩＭＳコアとｉＳＮＳサーバ間のＳＩＰ−ＡＳサーバに、ｉＳＮＳサーバとＩＭＳコア間のプロトコル変換を実現するゲートウェイ機能を配置するシステム構成をとるものである。この結果、既存のｉＳＮＳサーバとｉＳＮＳクライアントを経済的に、かつセキュアに広帯域ＩＰ網（ＩＭＳネットワーク）収容することを可能とするものである。
【００１０】
即ち、本発明は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムであって、前記プロトコル変換装置が、前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、前記ＳＩＰサーバに対してＳＩＰ信号を発行する手段と、前記ＳＩＰサーバから受信したＳＩＰ信号を受けて、前記ｉＳＮＳクライアントに対して前記ｉＳＮＳサーバ信号を発行する手段とを備えることを特徴とする。
【００１１】
また、本発明は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムであって、前記ゲートウェイサーバが、前記プロトコル変換装置から発行されたＳＩＰ信号を受けて、前記ｉＳＮＳサーバに対するｉＳＮＳクライアント端末のバイナリー信号を発行する手段と、前記ｉＳＮＳサーバが発行する前記ｉＳＮＳクライアントへのバイナリー信号を受けて、前記プロトコル変換装置へのＳＩＰ信号を発行する手段とを備えることを特徴とする。
【００１２】
また、本発明は、前記プロトコル変換装置が、前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、登録信号からＥＳＩ信号の送信間隔を抽出し、ｉＳＮＳクライアント端末に対して、指定の送信間隔で疑似ＥＳＩ信号を送出する手段を更に備えることが好ましい。
【００１３】
また、本発明は、前記プロトコル変換装置が、ＥＳＩＲｓｐ信号を監視する手段と、ＥＳＩＲｓｐ信号の未到達を検出した場合に、自律的に登録削除要求ＤｅｖＤｅｒｅｇ信号に相当するＳＩＰ ＰＵＢＬＩＳＨ信号を前記ゲートウェイサーバに送信する手段とを更に備えることが好ましい。
【００１４】
また、本発明は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおけるプロトコル変換装置であって、前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、前記ＳＩＰサーバに対してＳＩＰ信号を発行する手段と、前記ＳＩＰサーバから受信したＳＩＰ信号を受けて、前記ｉＳＮＳクライアントに対して前記ｉＳＮＳサーバ信号を発行する手段とを備えることを特徴とする。
【００１５】
また、本発明は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおけるゲートウェイサーバであって、前記プロトコル変換装置から発行されたＳＩＰ信号を受けて、前記ｉＳＮＳサーバに対するｉＳＮＳクライアント端末のバイナリー信号を発行する手段と、前記ｉＳＮＳサーバが発行する前記ｉＳＮＳクライアントへのバイナリー信号を受けて、前記プロトコル変換装置へのＳＩＰ信号を発行する手段とを備えることを特徴とする。
【００１６】
また、本発明は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたシステムのプロトコル変換方法であって、前記プロトコル変換装置の処理手順が、前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、前記ＳＩＰサーバに対してＳＩＰ信号を発行するステップと、前記ＳＩＰサーバから受信したＳＩＰ信号を受けて、前記ｉＳＮＳクライアントに対して前記ｉＳＮＳサーバ信号を発行するステップとを含むことを特徴とする。
【００１７】
また、本発明は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたシステムのプロトコル変換方法であって、前記ゲートウェイサーバの処理手順が、前記プロトコル変換装置から発行されたＳＩＰ信号を受けて、前記ｉＳＮＳサーバに対するｉＳＮＳクライアント端末のバイナリー信号を発行するステップと、前記ｉＳＮＳサーバが発行する前記ｉＳＮＳクライアントへのバイナリー信号を受けて、前記プロトコル変換装置へのＳＩＰ信号を発行するステップとを含むことを特徴とする。
【発明の効果】
【００１８】
本発明は、通信事業者が広域に運用するＮＧＮなどのＩＭＳネットワークを、ｉＳＮＳプロトコルの中継機能として利用することで、なりすましを困難にするセキュアなＩＰ−ＳＡＮを構成できる。また、ｉＳＮＳプロトコルとＩＭＳネットワークのインターフェース機能により、ホームネットワークのローカルネットワークに接続されたデバイス同士を接続することが可能となる。また、ＩＭＳネットワークが備える課金機能や帯域保証機能などとの連携が容易となり、ＩＰ−ＳＡＮに新しいサービス機能を追加、構成することが可能となる。
【図面の簡単な説明】
【００１９】
【図１】ＩＭＳネットワークにゲートウェイ装置を介して２つのホームネットワークが接続された構成を示す図である。
【図２】図１の構成において、４つの動作処理例を示す図である。
【図３】図２の処理のプロトコル処理シーケンスを示す図である。
【発明を実施するための形態】
【００２０】
本発明の実施の形態について図面を参照して説明する。
ＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）や将来の携帯電話網で採用が見込まれるＩＭＳでは、ＩＰネットワークに接続されるデバイスに関して回線認証など、なりすましに対応した仕組みを備え、エンド−エンドのセキュアな通信を保証する仕組みが備わっている。ＩＭＳネットワークが、ｉＳＮＳプロトコルに類似したＳＩＰプレゼンス機能を有することから、本発明は、ｉＳＮＳクライアントとサーバ間の中継機能としてＩＭＳネットワークを利用することで、ＩＰストレージやＩＰストレージを利用するサーバのなりすましが困難なＷＡＮを構成するものである。具体的には、ｉＳＮＳＰ（ｉＳＮＳプロトコル）とＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を変換するプロキシ機能をｉＳＮＳクライアントとＩＭＳネットワークの間に設置する。また、ＩＭＳのＳＩＰ−ＡＳ（アプリケーションサーバ）として、プロキシ機能から発行されたＳＩＰ信号からｉＳＮＳプロトコルを復元し、ｉＳＮＳサーバにアクセス可能なゲートウェイ機能を設置する。ゲートウェイ機能とプロキシ機能には、上記の逆方向のプロトコル変換機能も用意する。
【００２１】
以下、図１から図３を参照して本発明の実施例を詳細に説明する。図１は、広域ＩＰネットワークであるＩＭＳネットワークにゲートウェイ装置を介して、２つのホームネットワークが接続された構成を示す。各ホームネットワーク内には、ｉＳＮＳクライアント１２を備えたｉＳＣＳＩターゲット（ストレージ）１４と、ｉＳＮＳクライアント１３を備えたｉＳＣＳＩイニシエータ（ＰＣ、あるいはサーバ）１５が存在する。また、ｉＳＮＳクライアント１２は、ｉＳＮＳプロキシ１７に接続され、ｉＳＮＳクライアント１３は、ｉＳＮＳプロキシ１８に接続されている。
一方、ＩＭＳネットワークには、ＳＩＰアプリケーションサーバ（ＳＩＰ−ＡＳ）の１種であるｉＳＮＳゲートウェイサーバ１１が設置される。ｉＳＮＳゲートウェイサーバ１１は、ＩＳＣ（ＩＭＳ Ｓｅｒｖｉｃｅ Ｃｏｎｔｒｏｌ）インターフェースを介してＩＭＳコア２０に接続され、ｉＳＮＳサーバ１９とＩＭＳコア２０との間の通信を仲介する。
【００２２】
ＩＭＳコア２０は、ＣＳＣＦ（Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）サーバ２１と、ホーム加入者サーバ（ＨＳＳ：Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）２２とにより構成され、ＣＳＣＦサーバ２１は、ＳＩＰに基づくセッション制御を行うＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ−ＣＳＣＦ）２３と、問い合わせを受け付けるＩ−ＣＳＣＦ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ−ＣＳＣＦ）２４と、ユーザ端末（ＵＥ）がアクセスするＰ−ＣＳＣＦ（Ｐｒｏｘｙ−ＣＳＣＦ）２５とにより構成されている。ホーム加入者サーバ（ＨＳＳ）２２は、ｉＳＮＳプロキシ１７，１８の情報などを登録格納しているデータベースサーバである。ホーム加入者サーバ（ＨＳＳ）２２と、Ｓ−ＣＳＣＦ２３およびＰ−ＣＳＣＦ２５との間の情報の交換には、Ｄｉａｍｅｔｅｒプロトコルが用いられる。
【００２３】
本発明は、ｉＳＮＳゲートウェイサーバ１１とｉＳＮＳプロキシ１７，１８の機能により実現され、両者は、ｉＳＮＳＰ（ｉＳＮＳプロトコル）とＳＩＰを中継するプロトコル変換機能を有する。
各機能ブロックに付記した記号ＩＰ−は、ＩＰアドレスを意味し、ＩＰアドレス下部の数字は、受信ポート番号を意味する。また、ｉＳＮＳクライアント１２，１３、ｉＳＮＳプロキシ１７，１８、およびｉＳＮＳゲートウェイサーバ１１にはそれぞれ固有の名称（ｉＳＣＳＩ ｎａｍｅ、ＳＩＰ ＵＲＩ）が与えられる。
ｉＳＮＳゲートウェイサーバ１１には、ＸＭＬデータベース１６が付属し、ｉＳＣＳＩ ｎａｍｅとＳＩＰ ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）のマッピング情報が保存される。なお、当該データベースは、ＩＭＳコア２０のホーム加入者サーバ（ＨＳＳ）２２への統合も可能であるが、実施例では独立機能として扱う。
【００２４】
図２は、図１の構成よりＩＭＳコア２０を省略し、以下の４つの動作例に関する処理過程を更に詳細に示す図である。
（１）ｉＳＣＳＩイニシエータのｉＳＮＳサーバへの登録
（２）ｉＳＣＳＩターゲットのｉＳＮＳサーバへの登録
（３）ｉＳＮＳサーバからｉＳＣＳＩイニシエータへのＳＣＮ（Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ）送信
（４）ｉＳＣＳＩイニシエータからｉＳＮＳサーバへの問い合わせ
以下、処理動作を説明する。なお、ＳＩＰ ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）機能を有するｉＳＮＳプロキシ１７，１８は、ＩＭＳネットワーク（ＩＭＳコア２０）に対して、ＳＩＰ ＵＥとしてのデバイス登録を完了しているものとする。
例えば、ＩＰアドレスＩＰ−ｇｉを有するｉＳＮＳプロキシ１８は、
ＳＩＰ ＵＲＩ： ＳＩＰ ＵＲＩ−ｉ
ＩＰ ａｄｄｒｅｓｓ： ＩＰ−ｇｉ
Ｐｏｒｔ ｎｕｍｂｅｒ： ５０６０（ＴＣＰ／ＵＤＰ）
としてＩＭＳコア２０のホーム加入者サーバ（ＨＳＳ）２２に登録済みであるとする。また、ＳＩＰ ＵＥ機能を有するｉＳＮＳプロキシ１７，１８は、ｉＳＮＳゲートウェイサーバ１１のＳＩＰ ＵＲＩであるＳＩＰ ＵＲＩ−ｇｗを既知とする。ＳＩＰ ＵＲＩについては、非特許文献４に規定されたフォーマットが存在するが、本発明の本質ではないため省略形式で記載する。
【００２５】
＜ｉＳＣＳＩイニシエータのｉＳＮＳサーバへの登録＞
ｓ１からｓ８までの処理が、ｉＳＣＳＩイニシエータ１５のｉＳＮＳサーバ１９への登録処理を示す。
【００２６】
［ｓ１の処理］
ｉＳＮＳクライアント１３は、ｉＳＮＳプロキシ（ＩＰアドレス：ＩＰ−Ｐｉ）１８をｉＳＮＳサーバとして設定し、ｉＳＮＳプロキシ１８との間で確立したＴＣＰコネクションを通して、以下の情報を持ったｉＳＮＳプロトコル（非特許文献２参照）のデバイス登録要求ＤｅｖＡｔｔｒＲｅｇを発行する。なお、ｉＳＣＳＩイニシエータ１５、ｉＳＣＳＩターゲット１４ともにＴＣＰポート番号は、デフォルトの３２６０を使用するものとする。
Ｓｒｃ：（ｔａｇ＝３２）ｉＳＣＳＩ ｎａｍｅ−ｉ
Ｋｅｙ： ＜ｎｏｎｅ ｐｒｅｓｅｎｔ＞
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ＮＵＬＬ
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｉ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｉ
ｔａｇ３３： ｉｎｉｔｉａｔｏｒ
ｔａｇ３４： ｄｉｓｋ １
上記のとおり、ｉＳＮＳクライアント１３は、ｉＳＮＳネームとしてｉＳＣＳＩ ｎａｍｅ−ｉを有する。ｉＳＣＳＩ ｎａｍｅは、非特許文献３で規定されたフォーマットが存在するが、本発明の本質ではないため省略形式で記載する。登録するＩＰアドレス（ｔａｇ１６）は、ホームネットワークで使用するローカルアドレスである。
【００２７】
［ｓ２の処理］
ＤｅｖＡｔｔｒＲｅｇを受信したｉＳＮＳプロキシ１８は、自らに付与された固有のＳＩＰ ＵＲＩであるＳＩＰ ＵＲＩ−ｉを用いて、ｉＳＮＳゲートウェイサーバ１１のＵｔインターフェースに対して、ＸＣＡＰ（ＸＭＬ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）のＰＵＴ操作で、以下の情報を登録する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ＳＩＰ ＵＲＩ＞ ＳＩＰ ＵＲＩ−ｉ
＜ｔａｇ１＞ ＮＵＬＬ
＜ｔａｇ２＞ ｉＳＣＳＩ
＜ｔａｇ１６＞ ＩＰ−ｈｉ
＜ｔａｇ１７＞ ３２６０
＜ｔａｇ３２＞ ｉＳＣＳＩ ｎａｍｅ−ｉ
＜ｔａｇ３３＞ ｉｎｉｔｉａｔｏｒ
＜ｔａｇ３４＞ ｄｉｓｋ １
すなわち、処理ｓ１で発行されたＤｅｖＡｔｔｒＲｅｇのタグ付き情報とＳＩＰ ＵＲＩの組情報として登録を行う。
【００２８】
［ｓ３の処理］
ｉＳＮＳプロキシ（ＳＩＰ ＵＥ）１８から処理ｓ２の情報を受け取ったｉＳＮＳゲートウェイサーバ１１は、当該情報をＸＭＬデータベース１６に登録し、ＳＩＰ ＵＲＩをキーとしたｔａｇ付き情報の検索と、ｉＳＣＳＩ ｎａｍｅをキーとしたＳＩＰ ＵＲＩの検索を可能とする。ＸＭＬデータベース１６への情報登録の後、ｉＳＮＳプロキシ１８に対して登録完了のＳＩＰ信号である２００ ＯＫを発行する。
【００２９】
［ｓ４の処理］
ｉＳＮＳプロキシ１８は、処理ｓ３の２００ ＯＫ受信後、ｉＳＮＳゲートウェイサーバ（ＳＩＰ ＵＲＩ−ｇｗ）１１に対して、以下の情報を持つＳＩＰ ＰＵＢＬＩＳＨ信号（ＳＩＰ Ｐｒｅｓｅｎｃｅの登録「利用可能」）をＰＩＤＦ形式で発行する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ｓｔａｔｕｓ＞ ｏｐｅｎ
＜ｃｏｎｔａｃｔ＞ ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
【００３０】
［ｓ５の処理］
ＳＩＰ ＰＵＢＬＩＳＨ信号を受信したｉＳＮＳゲートウェイサーバ１１は、ｃｏｎｔａｃｔに記載されたＳＩＰ ＵＲＩをキーとして、ＸＭＬデータベース１６からｉＳＣＳＩ ｎａｍｅを含むｔａｇ付き情報を検索する。検索結果から処理ｓ１のＤｅｖＡｔｔｒＲｅｇを再構成し、ｉＳＮＳサーバ１９に対して発行する。
【００３１】
［ｓ６の処理］
ｉＳＮＳサーバ１９は、ｉＳＮＳサーバ１９からはｉＳＮＳクライアントに見えるｉＳＮＳゲートウェイサーバ（ＳＩＰ−ＡＳ）１１の発行したデバイス登録要求ＤｅｖＡｔｔｒＲｅｇに基づき、ｉＳＣＳＩ ｎａｍｅ−ｉの登録（利用可能）を行い、ｉＳＮＳゲートウェイサーバ１１に対して、以下の応答（登録完了）信号ＤｅｖＡｔｔｒＲｅｇＲｅｐを発行する。ここで、ｉＳＮＳサーバ１９の固有の識別ＩＤは、ｉｓｎｓ：０００１とする。
ＳＵＣＣＥＳＳ
Ｋｅｙ：（ｔａｇ＝１）ｉｓｎｓ：０００１
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ｉｓｎｓ：０００１
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｉ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｉ
ｔａｇ３３： ｉｎｉｔｉａｔｏｒ
ｔａｇ３４： ｄｉｓｋ １
【００３２】
［ｓ７の処理］
処理ｓ６のＤｅｖＡｔｔｒＲｅｇＲｅｐを受信したｉＳＮＳゲートウェイサーバ１１は、ｔａｇ３２のｉＳＣＳＩ ｎａｍｅを検索キーとして、ＸＭＬデータベース１６からＳＩＰ ＵＲＩを検索し、当該ＳＩＰ ＵＲＩに対して、処理ｓ４への応答信号としての２００ ＯＫを発行する。
【００３３】
［ｓ８の処理］
ｉＳＮＳプロキシ１８は、処理ｓ７の２００ ＯＫを受けて、処理ｓ６のＤｅｖＡｔｔｒＲｅｇＲｅｐを再構成する。当該信号は、処理ｓ１で確立したＴＣＰコネクションを通して、ｉＳＮＳクライアント１３に発行される。
【００３４】
＜ｉＳＣＳＩターゲットのｉＳＮＳサーバへの登録＞
ｓ９からｓ１６までの処理が、ｉＳＣＳＩターゲット１４のｉＳＮＳサーバ１９への登録処理を示す。
【００３５】
［ｓ９の処理］
処理ｓ１と同様に、ｉＳＮＳクライアント１２は、ｉＳＮＳプロキシ１７をｉＳＮＳサーバに設定し、以下の登録要求ＤｅｖＡｔｔｒＲｅｇを発行する。
Ｓｒｃ：（ｔａｇ＝３２）ｉＳＣＳＩ ｎａｍｅ−ｔ
Ｋｅｙ： ＜ｎｏｎｅ ｐｒｅｓｅｎｔ＞
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ＮＵＬＬ
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３３： ｔａｒｇｅｔ
ｔａｇ３４： ｄｉｓｋ ２
【００３６】
［ｓ１０の処理］
処理ｓ２と同様に、ｉＳＮＳプロキシ１７は、以下の情報をｉＳＮＳゲートウェイサーバ１１に登録する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ＳＩＰ ＵＲＩ＞ ＳＩＰ ＵＲＩ−ｔ
＜ｔａｇ１＞ ＮＵＬＬ
＜ｔａｇ２＞ ｉＳＣＳＩ
＜ｔａｇ１６＞ ＩＰ−ｈｔ
＜ｔａｇ１７＞ ３２６０
＜ｔａｇ３２＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
＜ｔａｇ３３＞ ｔａｒｇｅｔ
＜ｔａｇ３４＞ ｄｉｓｋ ２
【００３７】
［ｓ１１の処理］
処理ｓ１０の情報を受け取ったｉＳＮＳゲートウェイサーバ１１は、情報をＸＭＬデータベース１６に登録し、ｉＳＮＳプロキシ１７に対して応答信号２００ ＯＫを発行する。
【００３８】
［ｓ１２の処理］
ｉＳＮＳプロキシ１７は、処理ｓ１１の応答信号を受信後、ｉＳＮＳゲートウェイサーバ１１に対して、以下のＳＩＰ ＰＵＢＬＩＳＨ信号を発行する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ｓｔａｔｕｓ＞ ｏｐｅｎ
＜ｃｏｎｔａｃｔ＞ ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
【００３９】
［ｓ１３の処理］
ＳＩＰ ＰＵＢＬＩＳＨ信号を受信したｉＳＮＳゲートウェイサーバ１１は、ｃｏｎｔａｃｔに記載されたＳＩＰ ＵＲＩをキーとして、ＸＭＬデータベース１６からｉＳＣＳＩ ｎａｍｅを含むｔａｇ付き情報を検索する。検索結果から処理ｓ９のＤｅｖＡｔｔｒＲｅｇを再構成し、ｉＳＮＳサーバ１９に対して発行する。
【００４０】
［ｓ１４の処理］
ｉＳＮＳサーバ１９は、デバイス登録要求ＤｅｖＡｔｔｒＲｅｇに基づき、ｉＳＣＳＩ ｎａｍｅ−ｔの登録（利用可能）を行い、ｉＳＮＳゲートウェイサーバ１１に対して、以下の応答（登録完了）信号ＤｅｖＡｔｔｒＲｅｇＲｅｐを発行する。
ＳＵＣＣＥＳＳ
Ｋｅｙ：（ｔａｇ＝１）ｉｓｎｓ：０００１
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ｉｓｎｓ：０００１
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３３： ｔａｒｇｅｔ
ｔａｇ３４： ｄｉｓｋ ２
【００４１】
［ｓ１５の処理］
処理ｓ１４のＤｅｖＡｔｔｒＲｅｇＲｅｐを受信したｉＳＮＳゲートウェイサーバ１１は、ｔａｇ３２のｉＳＣＳＩ ｎａｍｅを検索キーとして、ＸＭＬデータベース１６からＳＩＰ ＵＲＩを検索し、当該ＳＩＰ ＵＲＩに対して、処理ｓ１２への応答信号としての２００ ＯＫを発行する。
【００４２】
［ｓ１６の処理］
ｉＳＮＳプロキシ１７は、処理ｓ１５の２００ ＯＫを受けて、処理ｓ１４のＤｅｖＡｔｔｒＲｅｇＲｅｐを再構成する。当該信号は、処理ｓ９で確立したＴＣＰコネクションを通して、ｉＳＮＳクライアント１２に発行される。
【００４３】
＜ｉＳＮＳサーバからｉＳＣＳＩイニシエータへのＳＣＮ送信＞
ｓ１７からｓ２２までの処理が、ｉＳＮＳサーバ１９からｉＳＣＳＩイニシエータ１５へのＳＣＮ（Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ）送信処理を示す。
【００４４】
［ｓ１７の処理］
ｉＳＮＳサーバ１９は、処理ｓ１３で受信した登録要求の結果、登録デバイス（ターゲット）が、処理ｓ５で登録された登録デバイス（イニシエータ）のディスカバリドメインと同一である場合、ｉＳＮＳゲートウェイサーバ１１に対して、以下の情報を包含したｉＳＮＳプロトコルのＳＣＮ信号（ターゲットデバイスの追加）を登録デバイス（イニシエータ）に発行（通知）する。
ｄｅｓｔ：（ｔａｇ＝３２）ｉＳＣＳＩ ｎａｍｅ−ｉ
ｔｉｍｅ：（ｒａｇ＝４）＜ｃｕｒｒｅｎｔ ｔｉｍｅ＞
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３５： ２８（ｏｂｊｅｃｔ ａｄｄｅｄ）
【００４５】
［ｓ１８の処理］
ｉＳＮＳゲートウェイサーバ１１は、受信したＳＣＮ信号を以下のＳＩＰ ＮＯＴＩＦＹ信号に構成し、ｉＳＮＳプロキシ１８に発行する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
＜ｄｅｓｔ＞ ｉＳＣＳＩ ｎａｍｅ−ｉ
＜ｔｉｍｅ＞ “ｃｕｒｒｅｎｔ ｔｉｍｅ”
＜ｔａｇ３２＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
＜ｔａｇ３５＞ ２８
【００４６】
［ｓ１９の処理］
ｉＳＮＳプロキシ１８は、受信したＳＩＰ ＮＯＴＩＦＹ信号を処理ｓ１７と同じＳＣＮ信号に再構成し、ｉＳＮＳクライアント１３に発行する。
【００４７】
［ｓ２０の処理］
ｉＳＮＳクライアント１３は、処理ｓ１９のＳＣＮ信号に対する応答ＳＣＮＲｅｓをｉＳＮＳプロキシ１８に発行する。
【００４８】
［ｓ２１の処理］
ｉＳＮＳプロキシ１８は、受信したＳＣＮＲｅｓ信号を契機に、処理ｓ１８のＳＩＰ ＮＯＴＩＦＹ信号に対する応答２００ ＯＫをｉＳＮＳゲートウェイサーバ１１に発行する。
【００４９】
［ｓ２２の処理］
ｉＳＮＳゲートウェイサーバ１１は、処理ｓ１７で受信したＳＣＮ信号への応答信号ＳＣＮＲｅｓを、処理ｓ２１の２００ ＯＫの受信を契機としてｉＳＮＳサーバ１９に発行する。
【００５０】
＜ｉＳＣＳＩイニシエータからｉＳＮＳサーバへの問い合わせ＞
ｓ２３からｓ２８までの処理が、ｉＳＣＳＩイニシエータ１５からｉＳＮＳサーバ１９への問い合わせ処理を示す。
【００５１】
［ｓ２３の処理］
ｉＳＮＳクライアント１３は、処理ｓ１９のＳＣＮ信号によって利用可能であることを検知できたｉＳＣＳＩターゲット１４に対して、当該ターゲットのｉＳＣＳＩ ｎａｍｅをキーとして検索し、ＩＰアドレスとポート番号の要求信号ＤｅｖＡｔｔｒＱｒｙを発行する。
Ｓｒｃ：（ｔａｇ＝３２）ｉＳＣＳＩ ｎａｍｅ−ｉ
Ｋｅｙ： ｉＳＣＳＩ ｎａｍｅ−ｔ
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１６： ＮＵＬＬ
ｔａｇ１７： ＮＵＬＬ
ｔａｇ３２： ＮＵＬＬ
【００５２】
［ｓ２４の処理］
ｉＳＮＳプロキシ１８は、以下のＸＣＡＰによりｉＳＮＳゲートウェイサーバ１１へ問い合わせを行う。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜Ｓｒｃ＞ ｉＳＣＳＩ ｎａｍｅ−ｉ
＜Ｋｅｙ＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
【００５３】
［ｓ２５の処理］
ｉＳＮＳゲートウェイサーバ１１は、ＸＣＡＰによる検索要求に対して、ＸＭＬデータベース１６への検索処理を行わず、処理ｓ２３のＤｅｖＡｔｔｒＱｒｙに再構成し、ｉＳＮＳサーバ１９へ問い合わせる。
【００５４】
［ｓ２６の処理］
ｉＳＮＳサーバ１９は、問い合わせ結果を以下のＤｅｖＡｔｔｒＱｒｙＲｅｐ信号として構成し、ｉＳＮＳゲートウェイサーバ１１に応答する。
ＳＵＣＣＥＳＳ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
【００５５】
［ｓ２７の処理］
ｉＳＮＳゲートウェイサーバ１１は、処理ｓ２４の問い合わせに対する応答２００ ＯＫをｉＳＮＳプロキシ１８に発行する。この時、応答信号には、以下の情報が含まれる。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
＜Ｓｒｃ＞ ｉＳＣＳＩ ｎａｍｅ−ｉ
＜Ｋｅｙ＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
＜ｔａｇ１６＞ ＩＰ−ｈｔ
＜ｔａｇ１７＞ ３２６０
＜ｔａｇ３２＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
＜ＳＩＰ ＵＲＩ＞ ＳＩＰ ＵＲＩ−ｔ
【００５６】
［ｓ２８の処理］
ｉＳＮＳプロキシ１８は、処理ｓ２７の応答信号２００ ＯＫを契機に、以下の処理ｓ２３への応答信号ＤｅｖＡｔｔｒＱｒｙＲｅｐ信号を構成し、ｉＳＮＳクライアント１３に発行する。
ＳＵＣＣＥＳＳ
ｔａｇ１６： ＩＰ−ｐｔ
ｔａｇ１７： ４９１５２
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
この際に発行されるＤｅｖＡｔｔｒＱｒｙＲｅｐは、処理ｓ２６で発行されるＤｅｖＡｔｔｒＱｒｙＲｅｐと、ｔａｇ１６、ｔａｇ１７が異なる。ｔａｇ１６には、ｉＳＮＳプロキシ１７のホームネットワーク側のＩＰアドレスを割り当て、ｔａｇ１７には、処理ｓ２６のｔａｇ１６毎に１対１にマッピングするプライベートポート（４９１５２番以降）を割り当てる。この結果、プライベートポート４９１５２へのアクセスを、ＳＩＰ ＵＲＩ−ｔに接続されたＩＰアドレスＩＰ−ｈｔ、ポート番号３２６０へのアクセスであると識別することが可能となる。この時、管理されるレコードは以下のとおりとなる。
＜Ａｃｃｅｓｓ Ｐｏｒｔ＞ ４９１５２
＜ＳＩＰ ＵＲＩ＞ ＳＩＰ ＵＲＩ−ｔ
＜ＩＰ ａｄｄｒｅｓｓ＞ ＩＰ−ｈｔ
＜Ｐｏｒｔ ｎｕｍｂｅｒ＞ ３２６０
【００５７】
図３は、図２の処理に対応したコマンドシーケンスを示す図である。ｉＳＮＳプロキシよりｉＳＮＳクライアントに対して発行されるＥＳＩ（Ｅｎｔｉｔｙ Ｓｔａｔｕｓ Ｉｎｑｕｉｒｙ）信号のインターバル（ｓｅｃ）とポート番号は、ＤｅｖＡｔｔｒＲｅｇのｔａｇ１９、ｔａｇ２０の値を用いて、ＤｅｖＡｔｔｒＲｅｇＲｅｐの発行後より開始する。ｉＳＮＳプロキシは、ＥＳＩ信号への応答信号ＥＳＩＲｓｐの受信を検知しなくなった際に、登録削除要求ＤｅｖＤｅｒｅｇ信号に相当する以下のＳＩＰ ＰＵＢＬＩＳＨ信号を送信する（イニシエータ対応のｉＳＮＳプロキシの場合）。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ｓｔａｔｕｓ＞ ｃｌｏｓｅ
＜ｃｏｎｔａｃｔ＞ ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
【符号の説明】
【００５８】
１１ ｉＳＮＳゲートウェイサーバ
１２，１３ ｉＳＮＳクライアＦント
１４ ｉＳＣＳＩターゲット
１５ ｉＳＣＳＩイニシエータ
１６ ＸＭＬデータベース
１７，１８ ｉＳＮＳプロキシ
１９ ｉＳＮＳサーバ
２０ ＩＭＳコア
２１ ＣＳＣＦサーバ
２２ ホーム加入者サーバ
２３ Ｓ−ＣＳＣＦ
２４ Ｉ−ＣＳＣＦ
２５ Ｐ−ＣＳＣＦ
ｓ１ ｉＳＮＳプロトコルによるデバイス属性登録要求
ｓ２ ＸＭＬ文書の登録（ＰＵＴ）
ｓ３ ｓ２に対する応答（成功）
ｓ４ ＳＩＰプロトコルによる属性登録要求
ｓ５ ｉＳＮＳプロトコルによるデバイス属性登録要求
ｓ６ ｓ５に対する応答（登録成功）
ｓ７ ｓ４に対する応答（登録成功）
ｓ８ １に対する応答（登録成功）
ｓ９ ｉＳＮＳプロトコルによるデバイス属性登録要求
ｓ１０ ＸＭＬ文書の登録（ＰＵＴ）
ｓ１１ ｓ１０に対する応答（成功）
ｓ１２ ＳＩＰプロトコルによる属性登録要求
ｓ１３ ｉＳＮＳプロトコルによるデバイス属性登録要求
ｓ１４ ｓ１３に対する応答（登録成功）
ｓ１５ ｓ１２に対する応答（登録成功）
ｓ１６ ｓ９に対する応答（登録成功）
ｓ１７ ｉＳＮＳプロトコルによる状態変化の通知
ｓ１８ ＳＩＰプロトコルによる通知
ｓ１９ ｉＳＮＳプロトコルによる状態変化の通知
ｓ２０ ｓ１９に対する応答（通知の受信）
ｓ２１ ｓ１８に対する応答（通知の受信）
ｓ２２ ｓ１７に対する応答（通知の受信）
ｓ２３ ｉＳＮＳプロトコルによる登録デバイスの問い合わせ
ｓ２４ ＸＭＬ文書の検索・問い合わせ
ｓ２５ ｉＳＮＳプロトコルによる登録デバイスの問い合わせ
ｓ２６ ｓ２５の問い合わせに対する応答（回答）
ｓ２７ ｓ２４に対する結果通知
ｓ２８ ｓ２３の問い合わせに対する応答（回答）
【技術分野】
【０００１】
本発明は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ストレージとサーバ間の接続管理を行うためのプロトコルであるｉＳＮＳ（Ｉｎｔｅｒｎｅｔ Ｓｔｏｒａｇｅ Ｎａｍｅ Ｓｅｒｖｉｃｅ）のクライアントとサーバ間の通信を、ＳＩＰプロトコルベースのＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）ネットワークを中継機能として利用することで、広帯域のＩＰ−ＳＡＮ（ＩＰ−Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）管理を可能とするプロトコル変換技術に関する。
【背景技術】
【０００２】
単体、もしくは複数のハードディスクドライブの集合体、あるいは専用の制御部で複数のハードディスクドライブを制御するディスクアレイ装置等から構成されるストレージ装置が実用化されている。ストレージ装置とホスト装置（サーバ、ＰＣ）間を接続するインターフェース技術としては、ファイバチャネル（Ｆｉｂｅｒ ｃｈａｎｎｅｌ）、インフィニバンド（ＩｎｆｉｎｉＢａｎｄ）、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ）などがある。ＳＣＳＩインターフェースは、近距離間を経済的に接続する用途として優れ、既に広く普及している。当該インターフェースでは、クライアントに相当する機能をイニシエータ、サーバに相当する機能をターゲットと呼び、イニシエータとターゲット間でＳＣＳＩコマンド（ＣＤＢ：Ｃｏｍｍａｎｄ Ｄｅｓｃｒｉｐｔｏｒ Ｂｌｏｃｋ）を交換する。ｉＳＣＳＩ（ｉｎｔｅｒｎｅｔ ＳＣＳＩ）技術は、２００４年にネットワークプロトコルであるＴＣＰ／ＩＰの上位プロトコルとしてＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）でＲＦＣ３７２０によって標準化された（非特許文献１参照）。現在、ｉＳＣＳＩ技術は、ギガビット以上の回線品質、特にデータセンター内、データセンター間や大規模ＬＡＮシステム等の基幹回線で利用されている。ｉＳＣＳＩ技術は、非特許文献１でＴＣＰコネクションを複数利用する方法を規定しているが、オプション機能のため必ずしも実装されているわけではない。
【０００３】
ｉＳＮＳ（Ｉｎｔｅｒｎｅｔ Ｓｔｏｒａｇｅ Ｎａｍｅ Ｓｅｒｖｉｃｅ）技術は、ＴＣＰ／ＩＰネットワーク上で、上記ｉＳＣＳＩ、ｉＦＣＰ（Ｉｎｔｅｒｎｅｔ Ｆｉｂｅｒ ｃｈａｎｎｅｌ Ｐｒｏｔｏｃｏｌ）デバイスの検出、構成管理等の機能を提供するインターネット標準のストレージ専用のネームサービス（名前解決）規格であり、２００５年９月にＲＦＣ４１７１として制定された（非特許文献２参照）。ｉＳＮＳサーバは、管理デバイスに実装されたｉＳＮＳクライアント機能を通じて各デバイスのプロファイル情報、例えば、ＩＰアドレスやＲＦＣ３７２１（非特許文献３参照）で定義されたｉＳＣＳＩ名を管理する他、ｉＳＮＳサーバとｉＳＮＳクライアント間の相互死活管理、デバイス間のアクセス関係を定義するディスカバリドメインの管理、同一ドメイン内でのプロファイル共有等を実現する。特に、ドメイン内のプロファイル共有によってドメイン所属デバイスのＩＰアドレスリストを取得できることから、これをアクセスコントロールリスト（ＡＣＬ）に適用して各デバイスからのアクセスに対して動的Ｌ３制御を行うことができる。
【０００４】
ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）は、固定電話網や移動体通信網など、回路スイッチやパケットスイッチが異なっていた公衆通信サービスを、ＩＰ技術やインターネット電話で使われるプロトコルであるＳＩＰ（非特許文献４参照）で統合し、マルチメディアサービスを実現させる通信方式である。第３世代携帯電話規格の標準化団体であり、Ｗ−ＣＤＭＡ方式を策定した３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）と、ＣＤＭＡ２０００方式を策定した３ＧＰＰ２（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ ２）によって標準化が行われている。
ＩＭＳは、３ＧＰＰリリース５（ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｓｐｅｃｉｆｉｃａｔｉｏｎｓ）で、ＮＧＮ（Ｎｅｗ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）向けのＳＩＰベースＭｕｌｔｉｍｅｄｉａ Ｄｏｍａｉｎが加えられたことに起因する。このため、３ＧＰＰではＩＭＳと呼ばれているが、３ＧＰＰ２ではＭＭＤ（Ｍｕｌｔｉｍｅｄｉａ Ｄｏｍａｉｎ）と呼ばれている。
【０００５】
ＳＩＰを利用したプレゼンス情報の記述には、ＲＦＣ３８６３（非特許文献６参照）で標準化されたＸＭＬ形式のデータフォーマットＰＩＤＦ（Ｐｒｅｓｅｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｄａｔａ Ｆｏｒｍａｔ）がある。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ（ｉＳＣＳＩ）， ＲＦＣ３７２０（Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ）， Ａｐｒ ２００４． Ｕｐｄａｔｅｄ ｂｙ ＲＦＣｓ３９８０， ４８５０， ５０４８．
【非特許文献２】Ｉｎｔｅｒｎｅｔ Ｓｔｏｒａｇｅ Ｎａｍｅ Ｓｅｒｖｉｃｅ（ｉＳＮＳ）， ＲＦＣ４１７１（Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ）， Ｓｅｐ ２００５．
【非特許文献３】Ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ（ｉＳＣＳＩ） Ｎａｍｉｎｇ ａｎｄ Ｄｉｓｃｏｖｅｒｙ， ＲＦＣ３７２１（Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ）， Ａｐｒ ２００４．
【非特許文献４】ＳＩＰ： Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ， ＲＦＣ３２６１（Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ）， Ｊｕｎｅ ２００２． Ｕｐｄａｔｅｄ ｂｙ ＲＦＣｓ３２６５， ３８５３， ４３２０， ４９１６．
【非特許文献５】Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）−Ｓｐｅｃｉｆｉｃ Ｅｖｅｎｔ Ｎｏｔｉｆｉｃａｔｉｏｎ， ＲＦＣ３２６５（Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ）， Ｊｕｎｅ ２００２．
【非特許文献６】Ｐｒｅｓｅｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｄａｔａ Ｆｏｒｍａｔ（ＰＩＤＦ）， ＲＦＣ３８６３（Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ）， Ａｕｇ ２００４．
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ｉＳＣＳＩを代表とするＩＰストレージの普及が進んだことから、ＩＰストレージと当該ストレージに接続する機能（イニシエータ）を実装した機器が増えている。この結果、遠隔地にあるＩＰストレージとの接続など、広帯域網を想定した需要が増えると見込まれる。ＩＰストレージの接続管理機能として、ＲＦＣ４１７１で制定されたｉＳＮＳが存在する。しかし、ｉＳＮＳは、ＬＡＮ向け、あるいは狭い管理エリアを想定して設計された経緯から、サーバおよびストレージのなりすまし等に対応するセキュリティ機能をもたないという課題がある。
【０００８】
本発明は、このような問題点に鑑みてなされたものであり、本発明の目的は、サーバおよびストレージのなりすましを困難にするセキュアな広帯域のＩＰ−ＳＡＮを構成できるプロトコル変換システム、プロトコル変換装置、ゲートウェイサーバおよびプロトコル変換方法を提供することにある。
【課題を解決するための手段】
【０００９】
通信事業者の運用する広帯域ＩＰ網では、ＩＰ−ＳＡＮにも適用可能な回線の高品質化や帯域保証機能の実装が進み、併せて、回線認証機能を伴う将来的なＩＭＳの導入の可能性がある。当該網を利用して、実際にＩＰ−ＳＡＮを経済的に、かつ大規模に実現するには、既に普及の進んでいるｉＳＮＳクライアント機能を前提に、ｉＳＮＳクライアント機能を有する機器とＩＭＳネットワークの間にプロトコル変換機能を用意する方法が考えられる。
本発明は、ＩＭＳ網へのｉＳＮＳクライアント収容に際して、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換する機能を設置することで、回線認証機能を利用した、なりすまし対応などのセキュリティ機能を備えるとともに、ＩＭＳコアとｉＳＮＳサーバ間のＳＩＰ−ＡＳサーバに、ｉＳＮＳサーバとＩＭＳコア間のプロトコル変換を実現するゲートウェイ機能を配置するシステム構成をとるものである。この結果、既存のｉＳＮＳサーバとｉＳＮＳクライアントを経済的に、かつセキュアに広帯域ＩＰ網（ＩＭＳネットワーク）収容することを可能とするものである。
【００１０】
即ち、本発明は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムであって、前記プロトコル変換装置が、前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、前記ＳＩＰサーバに対してＳＩＰ信号を発行する手段と、前記ＳＩＰサーバから受信したＳＩＰ信号を受けて、前記ｉＳＮＳクライアントに対して前記ｉＳＮＳサーバ信号を発行する手段とを備えることを特徴とする。
【００１１】
また、本発明は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムであって、前記ゲートウェイサーバが、前記プロトコル変換装置から発行されたＳＩＰ信号を受けて、前記ｉＳＮＳサーバに対するｉＳＮＳクライアント端末のバイナリー信号を発行する手段と、前記ｉＳＮＳサーバが発行する前記ｉＳＮＳクライアントへのバイナリー信号を受けて、前記プロトコル変換装置へのＳＩＰ信号を発行する手段とを備えることを特徴とする。
【００１２】
また、本発明は、前記プロトコル変換装置が、前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、登録信号からＥＳＩ信号の送信間隔を抽出し、ｉＳＮＳクライアント端末に対して、指定の送信間隔で疑似ＥＳＩ信号を送出する手段を更に備えることが好ましい。
【００１３】
また、本発明は、前記プロトコル変換装置が、ＥＳＩＲｓｐ信号を監視する手段と、ＥＳＩＲｓｐ信号の未到達を検出した場合に、自律的に登録削除要求ＤｅｖＤｅｒｅｇ信号に相当するＳＩＰ ＰＵＢＬＩＳＨ信号を前記ゲートウェイサーバに送信する手段とを更に備えることが好ましい。
【００１４】
また、本発明は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおけるプロトコル変換装置であって、前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、前記ＳＩＰサーバに対してＳＩＰ信号を発行する手段と、前記ＳＩＰサーバから受信したＳＩＰ信号を受けて、前記ｉＳＮＳクライアントに対して前記ｉＳＮＳサーバ信号を発行する手段とを備えることを特徴とする。
【００１５】
また、本発明は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおけるゲートウェイサーバであって、前記プロトコル変換装置から発行されたＳＩＰ信号を受けて、前記ｉＳＮＳサーバに対するｉＳＮＳクライアント端末のバイナリー信号を発行する手段と、前記ｉＳＮＳサーバが発行する前記ｉＳＮＳクライアントへのバイナリー信号を受けて、前記プロトコル変換装置へのＳＩＰ信号を発行する手段とを備えることを特徴とする。
【００１６】
また、本発明は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたシステムのプロトコル変換方法であって、前記プロトコル変換装置の処理手順が、前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、前記ＳＩＰサーバに対してＳＩＰ信号を発行するステップと、前記ＳＩＰサーバから受信したＳＩＰ信号を受けて、前記ｉＳＮＳクライアントに対して前記ｉＳＮＳサーバ信号を発行するステップとを含むことを特徴とする。
【００１７】
また、本発明は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたシステムのプロトコル変換方法であって、前記ゲートウェイサーバの処理手順が、前記プロトコル変換装置から発行されたＳＩＰ信号を受けて、前記ｉＳＮＳサーバに対するｉＳＮＳクライアント端末のバイナリー信号を発行するステップと、前記ｉＳＮＳサーバが発行する前記ｉＳＮＳクライアントへのバイナリー信号を受けて、前記プロトコル変換装置へのＳＩＰ信号を発行するステップとを含むことを特徴とする。
【発明の効果】
【００１８】
本発明は、通信事業者が広域に運用するＮＧＮなどのＩＭＳネットワークを、ｉＳＮＳプロトコルの中継機能として利用することで、なりすましを困難にするセキュアなＩＰ−ＳＡＮを構成できる。また、ｉＳＮＳプロトコルとＩＭＳネットワークのインターフェース機能により、ホームネットワークのローカルネットワークに接続されたデバイス同士を接続することが可能となる。また、ＩＭＳネットワークが備える課金機能や帯域保証機能などとの連携が容易となり、ＩＰ−ＳＡＮに新しいサービス機能を追加、構成することが可能となる。
【図面の簡単な説明】
【００１９】
【図１】ＩＭＳネットワークにゲートウェイ装置を介して２つのホームネットワークが接続された構成を示す図である。
【図２】図１の構成において、４つの動作処理例を示す図である。
【図３】図２の処理のプロトコル処理シーケンスを示す図である。
【発明を実施するための形態】
【００２０】
本発明の実施の形態について図面を参照して説明する。
ＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）や将来の携帯電話網で採用が見込まれるＩＭＳでは、ＩＰネットワークに接続されるデバイスに関して回線認証など、なりすましに対応した仕組みを備え、エンド−エンドのセキュアな通信を保証する仕組みが備わっている。ＩＭＳネットワークが、ｉＳＮＳプロトコルに類似したＳＩＰプレゼンス機能を有することから、本発明は、ｉＳＮＳクライアントとサーバ間の中継機能としてＩＭＳネットワークを利用することで、ＩＰストレージやＩＰストレージを利用するサーバのなりすましが困難なＷＡＮを構成するものである。具体的には、ｉＳＮＳＰ（ｉＳＮＳプロトコル）とＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を変換するプロキシ機能をｉＳＮＳクライアントとＩＭＳネットワークの間に設置する。また、ＩＭＳのＳＩＰ−ＡＳ（アプリケーションサーバ）として、プロキシ機能から発行されたＳＩＰ信号からｉＳＮＳプロトコルを復元し、ｉＳＮＳサーバにアクセス可能なゲートウェイ機能を設置する。ゲートウェイ機能とプロキシ機能には、上記の逆方向のプロトコル変換機能も用意する。
【００２１】
以下、図１から図３を参照して本発明の実施例を詳細に説明する。図１は、広域ＩＰネットワークであるＩＭＳネットワークにゲートウェイ装置を介して、２つのホームネットワークが接続された構成を示す。各ホームネットワーク内には、ｉＳＮＳクライアント１２を備えたｉＳＣＳＩターゲット（ストレージ）１４と、ｉＳＮＳクライアント１３を備えたｉＳＣＳＩイニシエータ（ＰＣ、あるいはサーバ）１５が存在する。また、ｉＳＮＳクライアント１２は、ｉＳＮＳプロキシ１７に接続され、ｉＳＮＳクライアント１３は、ｉＳＮＳプロキシ１８に接続されている。
一方、ＩＭＳネットワークには、ＳＩＰアプリケーションサーバ（ＳＩＰ−ＡＳ）の１種であるｉＳＮＳゲートウェイサーバ１１が設置される。ｉＳＮＳゲートウェイサーバ１１は、ＩＳＣ（ＩＭＳ Ｓｅｒｖｉｃｅ Ｃｏｎｔｒｏｌ）インターフェースを介してＩＭＳコア２０に接続され、ｉＳＮＳサーバ１９とＩＭＳコア２０との間の通信を仲介する。
【００２２】
ＩＭＳコア２０は、ＣＳＣＦ（Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）サーバ２１と、ホーム加入者サーバ（ＨＳＳ：Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）２２とにより構成され、ＣＳＣＦサーバ２１は、ＳＩＰに基づくセッション制御を行うＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ−ＣＳＣＦ）２３と、問い合わせを受け付けるＩ−ＣＳＣＦ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ−ＣＳＣＦ）２４と、ユーザ端末（ＵＥ）がアクセスするＰ−ＣＳＣＦ（Ｐｒｏｘｙ−ＣＳＣＦ）２５とにより構成されている。ホーム加入者サーバ（ＨＳＳ）２２は、ｉＳＮＳプロキシ１７，１８の情報などを登録格納しているデータベースサーバである。ホーム加入者サーバ（ＨＳＳ）２２と、Ｓ−ＣＳＣＦ２３およびＰ−ＣＳＣＦ２５との間の情報の交換には、Ｄｉａｍｅｔｅｒプロトコルが用いられる。
【００２３】
本発明は、ｉＳＮＳゲートウェイサーバ１１とｉＳＮＳプロキシ１７，１８の機能により実現され、両者は、ｉＳＮＳＰ（ｉＳＮＳプロトコル）とＳＩＰを中継するプロトコル変換機能を有する。
各機能ブロックに付記した記号ＩＰ−は、ＩＰアドレスを意味し、ＩＰアドレス下部の数字は、受信ポート番号を意味する。また、ｉＳＮＳクライアント１２，１３、ｉＳＮＳプロキシ１７，１８、およびｉＳＮＳゲートウェイサーバ１１にはそれぞれ固有の名称（ｉＳＣＳＩ ｎａｍｅ、ＳＩＰ ＵＲＩ）が与えられる。
ｉＳＮＳゲートウェイサーバ１１には、ＸＭＬデータベース１６が付属し、ｉＳＣＳＩ ｎａｍｅとＳＩＰ ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）のマッピング情報が保存される。なお、当該データベースは、ＩＭＳコア２０のホーム加入者サーバ（ＨＳＳ）２２への統合も可能であるが、実施例では独立機能として扱う。
【００２４】
図２は、図１の構成よりＩＭＳコア２０を省略し、以下の４つの動作例に関する処理過程を更に詳細に示す図である。
（１）ｉＳＣＳＩイニシエータのｉＳＮＳサーバへの登録
（２）ｉＳＣＳＩターゲットのｉＳＮＳサーバへの登録
（３）ｉＳＮＳサーバからｉＳＣＳＩイニシエータへのＳＣＮ（Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ）送信
（４）ｉＳＣＳＩイニシエータからｉＳＮＳサーバへの問い合わせ
以下、処理動作を説明する。なお、ＳＩＰ ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）機能を有するｉＳＮＳプロキシ１７，１８は、ＩＭＳネットワーク（ＩＭＳコア２０）に対して、ＳＩＰ ＵＥとしてのデバイス登録を完了しているものとする。
例えば、ＩＰアドレスＩＰ−ｇｉを有するｉＳＮＳプロキシ１８は、
ＳＩＰ ＵＲＩ： ＳＩＰ ＵＲＩ−ｉ
ＩＰ ａｄｄｒｅｓｓ： ＩＰ−ｇｉ
Ｐｏｒｔ ｎｕｍｂｅｒ： ５０６０（ＴＣＰ／ＵＤＰ）
としてＩＭＳコア２０のホーム加入者サーバ（ＨＳＳ）２２に登録済みであるとする。また、ＳＩＰ ＵＥ機能を有するｉＳＮＳプロキシ１７，１８は、ｉＳＮＳゲートウェイサーバ１１のＳＩＰ ＵＲＩであるＳＩＰ ＵＲＩ−ｇｗを既知とする。ＳＩＰ ＵＲＩについては、非特許文献４に規定されたフォーマットが存在するが、本発明の本質ではないため省略形式で記載する。
【００２５】
＜ｉＳＣＳＩイニシエータのｉＳＮＳサーバへの登録＞
ｓ１からｓ８までの処理が、ｉＳＣＳＩイニシエータ１５のｉＳＮＳサーバ１９への登録処理を示す。
【００２６】
［ｓ１の処理］
ｉＳＮＳクライアント１３は、ｉＳＮＳプロキシ（ＩＰアドレス：ＩＰ−Ｐｉ）１８をｉＳＮＳサーバとして設定し、ｉＳＮＳプロキシ１８との間で確立したＴＣＰコネクションを通して、以下の情報を持ったｉＳＮＳプロトコル（非特許文献２参照）のデバイス登録要求ＤｅｖＡｔｔｒＲｅｇを発行する。なお、ｉＳＣＳＩイニシエータ１５、ｉＳＣＳＩターゲット１４ともにＴＣＰポート番号は、デフォルトの３２６０を使用するものとする。
Ｓｒｃ：（ｔａｇ＝３２）ｉＳＣＳＩ ｎａｍｅ−ｉ
Ｋｅｙ： ＜ｎｏｎｅ ｐｒｅｓｅｎｔ＞
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ＮＵＬＬ
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｉ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｉ
ｔａｇ３３： ｉｎｉｔｉａｔｏｒ
ｔａｇ３４： ｄｉｓｋ １
上記のとおり、ｉＳＮＳクライアント１３は、ｉＳＮＳネームとしてｉＳＣＳＩ ｎａｍｅ−ｉを有する。ｉＳＣＳＩ ｎａｍｅは、非特許文献３で規定されたフォーマットが存在するが、本発明の本質ではないため省略形式で記載する。登録するＩＰアドレス（ｔａｇ１６）は、ホームネットワークで使用するローカルアドレスである。
【００２７】
［ｓ２の処理］
ＤｅｖＡｔｔｒＲｅｇを受信したｉＳＮＳプロキシ１８は、自らに付与された固有のＳＩＰ ＵＲＩであるＳＩＰ ＵＲＩ−ｉを用いて、ｉＳＮＳゲートウェイサーバ１１のＵｔインターフェースに対して、ＸＣＡＰ（ＸＭＬ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）のＰＵＴ操作で、以下の情報を登録する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ＳＩＰ ＵＲＩ＞ ＳＩＰ ＵＲＩ−ｉ
＜ｔａｇ１＞ ＮＵＬＬ
＜ｔａｇ２＞ ｉＳＣＳＩ
＜ｔａｇ１６＞ ＩＰ−ｈｉ
＜ｔａｇ１７＞ ３２６０
＜ｔａｇ３２＞ ｉＳＣＳＩ ｎａｍｅ−ｉ
＜ｔａｇ３３＞ ｉｎｉｔｉａｔｏｒ
＜ｔａｇ３４＞ ｄｉｓｋ １
すなわち、処理ｓ１で発行されたＤｅｖＡｔｔｒＲｅｇのタグ付き情報とＳＩＰ ＵＲＩの組情報として登録を行う。
【００２８】
［ｓ３の処理］
ｉＳＮＳプロキシ（ＳＩＰ ＵＥ）１８から処理ｓ２の情報を受け取ったｉＳＮＳゲートウェイサーバ１１は、当該情報をＸＭＬデータベース１６に登録し、ＳＩＰ ＵＲＩをキーとしたｔａｇ付き情報の検索と、ｉＳＣＳＩ ｎａｍｅをキーとしたＳＩＰ ＵＲＩの検索を可能とする。ＸＭＬデータベース１６への情報登録の後、ｉＳＮＳプロキシ１８に対して登録完了のＳＩＰ信号である２００ ＯＫを発行する。
【００２９】
［ｓ４の処理］
ｉＳＮＳプロキシ１８は、処理ｓ３の２００ ＯＫ受信後、ｉＳＮＳゲートウェイサーバ（ＳＩＰ ＵＲＩ−ｇｗ）１１に対して、以下の情報を持つＳＩＰ ＰＵＢＬＩＳＨ信号（ＳＩＰ Ｐｒｅｓｅｎｃｅの登録「利用可能」）をＰＩＤＦ形式で発行する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ｓｔａｔｕｓ＞ ｏｐｅｎ
＜ｃｏｎｔａｃｔ＞ ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
【００３０】
［ｓ５の処理］
ＳＩＰ ＰＵＢＬＩＳＨ信号を受信したｉＳＮＳゲートウェイサーバ１１は、ｃｏｎｔａｃｔに記載されたＳＩＰ ＵＲＩをキーとして、ＸＭＬデータベース１６からｉＳＣＳＩ ｎａｍｅを含むｔａｇ付き情報を検索する。検索結果から処理ｓ１のＤｅｖＡｔｔｒＲｅｇを再構成し、ｉＳＮＳサーバ１９に対して発行する。
【００３１】
［ｓ６の処理］
ｉＳＮＳサーバ１９は、ｉＳＮＳサーバ１９からはｉＳＮＳクライアントに見えるｉＳＮＳゲートウェイサーバ（ＳＩＰ−ＡＳ）１１の発行したデバイス登録要求ＤｅｖＡｔｔｒＲｅｇに基づき、ｉＳＣＳＩ ｎａｍｅ−ｉの登録（利用可能）を行い、ｉＳＮＳゲートウェイサーバ１１に対して、以下の応答（登録完了）信号ＤｅｖＡｔｔｒＲｅｇＲｅｐを発行する。ここで、ｉＳＮＳサーバ１９の固有の識別ＩＤは、ｉｓｎｓ：０００１とする。
ＳＵＣＣＥＳＳ
Ｋｅｙ：（ｔａｇ＝１）ｉｓｎｓ：０００１
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ｉｓｎｓ：０００１
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｉ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｉ
ｔａｇ３３： ｉｎｉｔｉａｔｏｒ
ｔａｇ３４： ｄｉｓｋ １
【００３２】
［ｓ７の処理］
処理ｓ６のＤｅｖＡｔｔｒＲｅｇＲｅｐを受信したｉＳＮＳゲートウェイサーバ１１は、ｔａｇ３２のｉＳＣＳＩ ｎａｍｅを検索キーとして、ＸＭＬデータベース１６からＳＩＰ ＵＲＩを検索し、当該ＳＩＰ ＵＲＩに対して、処理ｓ４への応答信号としての２００ ＯＫを発行する。
【００３３】
［ｓ８の処理］
ｉＳＮＳプロキシ１８は、処理ｓ７の２００ ＯＫを受けて、処理ｓ６のＤｅｖＡｔｔｒＲｅｇＲｅｐを再構成する。当該信号は、処理ｓ１で確立したＴＣＰコネクションを通して、ｉＳＮＳクライアント１３に発行される。
【００３４】
＜ｉＳＣＳＩターゲットのｉＳＮＳサーバへの登録＞
ｓ９からｓ１６までの処理が、ｉＳＣＳＩターゲット１４のｉＳＮＳサーバ１９への登録処理を示す。
【００３５】
［ｓ９の処理］
処理ｓ１と同様に、ｉＳＮＳクライアント１２は、ｉＳＮＳプロキシ１７をｉＳＮＳサーバに設定し、以下の登録要求ＤｅｖＡｔｔｒＲｅｇを発行する。
Ｓｒｃ：（ｔａｇ＝３２）ｉＳＣＳＩ ｎａｍｅ−ｔ
Ｋｅｙ： ＜ｎｏｎｅ ｐｒｅｓｅｎｔ＞
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ＮＵＬＬ
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３３： ｔａｒｇｅｔ
ｔａｇ３４： ｄｉｓｋ ２
【００３６】
［ｓ１０の処理］
処理ｓ２と同様に、ｉＳＮＳプロキシ１７は、以下の情報をｉＳＮＳゲートウェイサーバ１１に登録する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ＳＩＰ ＵＲＩ＞ ＳＩＰ ＵＲＩ−ｔ
＜ｔａｇ１＞ ＮＵＬＬ
＜ｔａｇ２＞ ｉＳＣＳＩ
＜ｔａｇ１６＞ ＩＰ−ｈｔ
＜ｔａｇ１７＞ ３２６０
＜ｔａｇ３２＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
＜ｔａｇ３３＞ ｔａｒｇｅｔ
＜ｔａｇ３４＞ ｄｉｓｋ ２
【００３７】
［ｓ１１の処理］
処理ｓ１０の情報を受け取ったｉＳＮＳゲートウェイサーバ１１は、情報をＸＭＬデータベース１６に登録し、ｉＳＮＳプロキシ１７に対して応答信号２００ ＯＫを発行する。
【００３８】
［ｓ１２の処理］
ｉＳＮＳプロキシ１７は、処理ｓ１１の応答信号を受信後、ｉＳＮＳゲートウェイサーバ１１に対して、以下のＳＩＰ ＰＵＢＬＩＳＨ信号を発行する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ｓｔａｔｕｓ＞ ｏｐｅｎ
＜ｃｏｎｔａｃｔ＞ ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
【００３９】
［ｓ１３の処理］
ＳＩＰ ＰＵＢＬＩＳＨ信号を受信したｉＳＮＳゲートウェイサーバ１１は、ｃｏｎｔａｃｔに記載されたＳＩＰ ＵＲＩをキーとして、ＸＭＬデータベース１６からｉＳＣＳＩ ｎａｍｅを含むｔａｇ付き情報を検索する。検索結果から処理ｓ９のＤｅｖＡｔｔｒＲｅｇを再構成し、ｉＳＮＳサーバ１９に対して発行する。
【００４０】
［ｓ１４の処理］
ｉＳＮＳサーバ１９は、デバイス登録要求ＤｅｖＡｔｔｒＲｅｇに基づき、ｉＳＣＳＩ ｎａｍｅ−ｔの登録（利用可能）を行い、ｉＳＮＳゲートウェイサーバ１１に対して、以下の応答（登録完了）信号ＤｅｖＡｔｔｒＲｅｇＲｅｐを発行する。
ＳＵＣＣＥＳＳ
Ｋｅｙ：（ｔａｇ＝１）ｉｓｎｓ：０００１
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ｉｓｎｓ：０００１
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３３： ｔａｒｇｅｔ
ｔａｇ３４： ｄｉｓｋ ２
【００４１】
［ｓ１５の処理］
処理ｓ１４のＤｅｖＡｔｔｒＲｅｇＲｅｐを受信したｉＳＮＳゲートウェイサーバ１１は、ｔａｇ３２のｉＳＣＳＩ ｎａｍｅを検索キーとして、ＸＭＬデータベース１６からＳＩＰ ＵＲＩを検索し、当該ＳＩＰ ＵＲＩに対して、処理ｓ１２への応答信号としての２００ ＯＫを発行する。
【００４２】
［ｓ１６の処理］
ｉＳＮＳプロキシ１７は、処理ｓ１５の２００ ＯＫを受けて、処理ｓ１４のＤｅｖＡｔｔｒＲｅｇＲｅｐを再構成する。当該信号は、処理ｓ９で確立したＴＣＰコネクションを通して、ｉＳＮＳクライアント１２に発行される。
【００４３】
＜ｉＳＮＳサーバからｉＳＣＳＩイニシエータへのＳＣＮ送信＞
ｓ１７からｓ２２までの処理が、ｉＳＮＳサーバ１９からｉＳＣＳＩイニシエータ１５へのＳＣＮ（Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ）送信処理を示す。
【００４４】
［ｓ１７の処理］
ｉＳＮＳサーバ１９は、処理ｓ１３で受信した登録要求の結果、登録デバイス（ターゲット）が、処理ｓ５で登録された登録デバイス（イニシエータ）のディスカバリドメインと同一である場合、ｉＳＮＳゲートウェイサーバ１１に対して、以下の情報を包含したｉＳＮＳプロトコルのＳＣＮ信号（ターゲットデバイスの追加）を登録デバイス（イニシエータ）に発行（通知）する。
ｄｅｓｔ：（ｔａｇ＝３２）ｉＳＣＳＩ ｎａｍｅ−ｉ
ｔｉｍｅ：（ｒａｇ＝４）＜ｃｕｒｒｅｎｔ ｔｉｍｅ＞
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３５： ２８（ｏｂｊｅｃｔ ａｄｄｅｄ）
【００４５】
［ｓ１８の処理］
ｉＳＮＳゲートウェイサーバ１１は、受信したＳＣＮ信号を以下のＳＩＰ ＮＯＴＩＦＹ信号に構成し、ｉＳＮＳプロキシ１８に発行する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
＜ｄｅｓｔ＞ ｉＳＣＳＩ ｎａｍｅ−ｉ
＜ｔｉｍｅ＞ “ｃｕｒｒｅｎｔ ｔｉｍｅ”
＜ｔａｇ３２＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
＜ｔａｇ３５＞ ２８
【００４６】
［ｓ１９の処理］
ｉＳＮＳプロキシ１８は、受信したＳＩＰ ＮＯＴＩＦＹ信号を処理ｓ１７と同じＳＣＮ信号に再構成し、ｉＳＮＳクライアント１３に発行する。
【００４７】
［ｓ２０の処理］
ｉＳＮＳクライアント１３は、処理ｓ１９のＳＣＮ信号に対する応答ＳＣＮＲｅｓをｉＳＮＳプロキシ１８に発行する。
【００４８】
［ｓ２１の処理］
ｉＳＮＳプロキシ１８は、受信したＳＣＮＲｅｓ信号を契機に、処理ｓ１８のＳＩＰ ＮＯＴＩＦＹ信号に対する応答２００ ＯＫをｉＳＮＳゲートウェイサーバ１１に発行する。
【００４９】
［ｓ２２の処理］
ｉＳＮＳゲートウェイサーバ１１は、処理ｓ１７で受信したＳＣＮ信号への応答信号ＳＣＮＲｅｓを、処理ｓ２１の２００ ＯＫの受信を契機としてｉＳＮＳサーバ１９に発行する。
【００５０】
＜ｉＳＣＳＩイニシエータからｉＳＮＳサーバへの問い合わせ＞
ｓ２３からｓ２８までの処理が、ｉＳＣＳＩイニシエータ１５からｉＳＮＳサーバ１９への問い合わせ処理を示す。
【００５１】
［ｓ２３の処理］
ｉＳＮＳクライアント１３は、処理ｓ１９のＳＣＮ信号によって利用可能であることを検知できたｉＳＣＳＩターゲット１４に対して、当該ターゲットのｉＳＣＳＩ ｎａｍｅをキーとして検索し、ＩＰアドレスとポート番号の要求信号ＤｅｖＡｔｔｒＱｒｙを発行する。
Ｓｒｃ：（ｔａｇ＝３２）ｉＳＣＳＩ ｎａｍｅ−ｉ
Ｋｅｙ： ｉＳＣＳＩ ｎａｍｅ−ｔ
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１６： ＮＵＬＬ
ｔａｇ１７： ＮＵＬＬ
ｔａｇ３２： ＮＵＬＬ
【００５２】
［ｓ２４の処理］
ｉＳＮＳプロキシ１８は、以下のＸＣＡＰによりｉＳＮＳゲートウェイサーバ１１へ問い合わせを行う。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜Ｓｒｃ＞ ｉＳＣＳＩ ｎａｍｅ−ｉ
＜Ｋｅｙ＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
【００５３】
［ｓ２５の処理］
ｉＳＮＳゲートウェイサーバ１１は、ＸＣＡＰによる検索要求に対して、ＸＭＬデータベース１６への検索処理を行わず、処理ｓ２３のＤｅｖＡｔｔｒＱｒｙに再構成し、ｉＳＮＳサーバ１９へ問い合わせる。
【００５４】
［ｓ２６の処理］
ｉＳＮＳサーバ１９は、問い合わせ結果を以下のＤｅｖＡｔｔｒＱｒｙＲｅｐ信号として構成し、ｉＳＮＳゲートウェイサーバ１１に応答する。
ＳＵＣＣＥＳＳ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
【００５５】
［ｓ２７の処理］
ｉＳＮＳゲートウェイサーバ１１は、処理ｓ２４の問い合わせに対する応答２００ ＯＫをｉＳＮＳプロキシ１８に発行する。この時、応答信号には、以下の情報が含まれる。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
＜Ｓｒｃ＞ ｉＳＣＳＩ ｎａｍｅ−ｉ
＜Ｋｅｙ＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
＜ｔａｇ１６＞ ＩＰ−ｈｔ
＜ｔａｇ１７＞ ３２６０
＜ｔａｇ３２＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
＜ＳＩＰ ＵＲＩ＞ ＳＩＰ ＵＲＩ−ｔ
【００５６】
［ｓ２８の処理］
ｉＳＮＳプロキシ１８は、処理ｓ２７の応答信号２００ ＯＫを契機に、以下の処理ｓ２３への応答信号ＤｅｖＡｔｔｒＱｒｙＲｅｐ信号を構成し、ｉＳＮＳクライアント１３に発行する。
ＳＵＣＣＥＳＳ
ｔａｇ１６： ＩＰ−ｐｔ
ｔａｇ１７： ４９１５２
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
この際に発行されるＤｅｖＡｔｔｒＱｒｙＲｅｐは、処理ｓ２６で発行されるＤｅｖＡｔｔｒＱｒｙＲｅｐと、ｔａｇ１６、ｔａｇ１７が異なる。ｔａｇ１６には、ｉＳＮＳプロキシ１７のホームネットワーク側のＩＰアドレスを割り当て、ｔａｇ１７には、処理ｓ２６のｔａｇ１６毎に１対１にマッピングするプライベートポート（４９１５２番以降）を割り当てる。この結果、プライベートポート４９１５２へのアクセスを、ＳＩＰ ＵＲＩ−ｔに接続されたＩＰアドレスＩＰ−ｈｔ、ポート番号３２６０へのアクセスであると識別することが可能となる。この時、管理されるレコードは以下のとおりとなる。
＜Ａｃｃｅｓｓ Ｐｏｒｔ＞ ４９１５２
＜ＳＩＰ ＵＲＩ＞ ＳＩＰ ＵＲＩ−ｔ
＜ＩＰ ａｄｄｒｅｓｓ＞ ＩＰ−ｈｔ
＜Ｐｏｒｔ ｎｕｍｂｅｒ＞ ３２６０
【００５７】
図３は、図２の処理に対応したコマンドシーケンスを示す図である。ｉＳＮＳプロキシよりｉＳＮＳクライアントに対して発行されるＥＳＩ（Ｅｎｔｉｔｙ Ｓｔａｔｕｓ Ｉｎｑｕｉｒｙ）信号のインターバル（ｓｅｃ）とポート番号は、ＤｅｖＡｔｔｒＲｅｇのｔａｇ１９、ｔａｇ２０の値を用いて、ＤｅｖＡｔｔｒＲｅｇＲｅｐの発行後より開始する。ｉＳＮＳプロキシは、ＥＳＩ信号への応答信号ＥＳＩＲｓｐの受信を検知しなくなった際に、登録削除要求ＤｅｖＤｅｒｅｇ信号に相当する以下のＳＩＰ ＰＵＢＬＩＳＨ信号を送信する（イニシエータ対応のｉＳＮＳプロキシの場合）。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ｓｔａｔｕｓ＞ ｃｌｏｓｅ
＜ｃｏｎｔａｃｔ＞ ｓｉｐ：“ＳＩＰ ＵＲＩ−ｉ”
【符号の説明】
【００５８】
１１ ｉＳＮＳゲートウェイサーバ
１２，１３ ｉＳＮＳクライアＦント
１４ ｉＳＣＳＩターゲット
１５ ｉＳＣＳＩイニシエータ
１６ ＸＭＬデータベース
１７，１８ ｉＳＮＳプロキシ
１９ ｉＳＮＳサーバ
２０ ＩＭＳコア
２１ ＣＳＣＦサーバ
２２ ホーム加入者サーバ
２３ Ｓ−ＣＳＣＦ
２４ Ｉ−ＣＳＣＦ
２５ Ｐ−ＣＳＣＦ
ｓ１ ｉＳＮＳプロトコルによるデバイス属性登録要求
ｓ２ ＸＭＬ文書の登録（ＰＵＴ）
ｓ３ ｓ２に対する応答（成功）
ｓ４ ＳＩＰプロトコルによる属性登録要求
ｓ５ ｉＳＮＳプロトコルによるデバイス属性登録要求
ｓ６ ｓ５に対する応答（登録成功）
ｓ７ ｓ４に対する応答（登録成功）
ｓ８ １に対する応答（登録成功）
ｓ９ ｉＳＮＳプロトコルによるデバイス属性登録要求
ｓ１０ ＸＭＬ文書の登録（ＰＵＴ）
ｓ１１ ｓ１０に対する応答（成功）
ｓ１２ ＳＩＰプロトコルによる属性登録要求
ｓ１３ ｉＳＮＳプロトコルによるデバイス属性登録要求
ｓ１４ ｓ１３に対する応答（登録成功）
ｓ１５ ｓ１２に対する応答（登録成功）
ｓ１６ ｓ９に対する応答（登録成功）
ｓ１７ ｉＳＮＳプロトコルによる状態変化の通知
ｓ１８ ＳＩＰプロトコルによる通知
ｓ１９ ｉＳＮＳプロトコルによる状態変化の通知
ｓ２０ ｓ１９に対する応答（通知の受信）
ｓ２１ ｓ１８に対する応答（通知の受信）
ｓ２２ ｓ１７に対する応答（通知の受信）
ｓ２３ ｉＳＮＳプロトコルによる登録デバイスの問い合わせ
ｓ２４ ＸＭＬ文書の検索・問い合わせ
ｓ２５ ｉＳＮＳプロトコルによる登録デバイスの問い合わせ
ｓ２６ ｓ２５の問い合わせに対する応答（回答）
ｓ２７ ｓ２４に対する結果通知
ｓ２８ ｓ２３の問い合わせに対する応答（回答）
【特許請求の範囲】
【請求項１】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムであって、
前記プロトコル変換装置は、
前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、前記ＳＩＰサーバに対してＳＩＰ信号を発行する手段と、
前記ＳＩＰサーバから受信したＳＩＰ信号を受けて、前記ｉＳＮＳクライアントに対して前記ｉＳＮＳサーバ信号を発行する手段と、
を備えることを特徴とするプロトコル変換システム。
【請求項２】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムであって、
前記ゲートウェイサーバは、
前記プロトコル変換装置から発行されたＳＩＰ信号を受けて、前記ｉＳＮＳサーバに対するｉＳＮＳクライアント端末のバイナリー信号を発行する手段と、
前記ｉＳＮＳサーバが発行する前記ｉＳＮＳクライアントへのバイナリー信号を受けて、前記プロトコル変換装置へのＳＩＰ信号を発行する手段と、
を備えることを特徴とするプロトコル変換システム。
【請求項３】
前記プロトコル変換装置は、前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、登録信号からＥＳＩ信号の送信間隔を抽出し、ｉＳＮＳクライアント端末に対して、指定の送信間隔で疑似ＥＳＩ信号を送出する手段を更に備えることを特徴とする請求項１に記載のプロトコル変換システム。
【請求項４】
前記プロトコル変換装置は、ＥＳＩＲｓｐ信号を監視する手段と、ＥＳＩＲｓｐ信号の未到達を検出した場合に、自律的に登録削除要求ＤｅｖＤｅｒｅｇ信号に相当するＳＩＰ ＰＵＢＬＩＳＨ信号を前記ゲートウェイサーバに送信する手段とを更に備えることを特徴とする請求項３に記載のプロトコル変換システム。
【請求項５】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおけるプロトコル変換装置であって、
前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、前記ＳＩＰサーバに対してＳＩＰ信号を発行する手段と、
前記ＳＩＰサーバから受信したＳＩＰ信号を受けて、前記ｉＳＮＳクライアントに対して前記ｉＳＮＳサーバ信号を発行する手段と、
を備えることを特徴とするプロトコル変換装置。
【請求項６】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおけるゲートウェイサーバであって、
前記プロトコル変換装置から発行されたＳＩＰ信号を受けて、前記ｉＳＮＳサーバに対するｉＳＮＳクライアント端末のバイナリー信号を発行する手段と、
前記ｉＳＮＳサーバが発行する前記ｉＳＮＳクライアントへのバイナリー信号を受けて、前記プロトコル変換装置へのＳＩＰ信号を発行する手段と、
を備えることを特徴とするゲートウェイサーバ。
【請求項７】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたシステムのプロトコル変換方法であって、
前記プロトコル変換装置の処理手順は、
前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、前記ＳＩＰサーバに対してＳＩＰ信号を発行するステップと、
前記ＳＩＰサーバから受信したＳＩＰ信号を受けて、前記ｉＳＮＳクライアントに対して前記ｉＳＮＳサーバ信号を発行するステップと、
を含むことを特徴とするプロトコル変換方法。
【請求項８】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたシステムのプロトコル変換方法であって、
前記ゲートウェイサーバの処理手順は、
前記プロトコル変換装置から発行されたＳＩＰ信号を受けて、前記ｉＳＮＳサーバに対するｉＳＮＳクライアント端末のバイナリー信号を発行するステップと、
前記ｉＳＮＳサーバが発行する前記ｉＳＮＳクライアントへのバイナリー信号を受けて、前記プロトコル変換装置へのＳＩＰ信号を発行するステップと、
を含むことを特徴とするプロトコル変換方法。
【請求項１】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムであって、
前記プロトコル変換装置は、
前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、前記ＳＩＰサーバに対してＳＩＰ信号を発行する手段と、
前記ＳＩＰサーバから受信したＳＩＰ信号を受けて、前記ｉＳＮＳクライアントに対して前記ｉＳＮＳサーバ信号を発行する手段と、
を備えることを特徴とするプロトコル変換システム。
【請求項２】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムであって、
前記ゲートウェイサーバは、
前記プロトコル変換装置から発行されたＳＩＰ信号を受けて、前記ｉＳＮＳサーバに対するｉＳＮＳクライアント端末のバイナリー信号を発行する手段と、
前記ｉＳＮＳサーバが発行する前記ｉＳＮＳクライアントへのバイナリー信号を受けて、前記プロトコル変換装置へのＳＩＰ信号を発行する手段と、
を備えることを特徴とするプロトコル変換システム。
【請求項３】
前記プロトコル変換装置は、前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、登録信号からＥＳＩ信号の送信間隔を抽出し、ｉＳＮＳクライアント端末に対して、指定の送信間隔で疑似ＥＳＩ信号を送出する手段を更に備えることを特徴とする請求項１に記載のプロトコル変換システム。
【請求項４】
前記プロトコル変換装置は、ＥＳＩＲｓｐ信号を監視する手段と、ＥＳＩＲｓｐ信号の未到達を検出した場合に、自律的に登録削除要求ＤｅｖＤｅｒｅｇ信号に相当するＳＩＰ ＰＵＢＬＩＳＨ信号を前記ゲートウェイサーバに送信する手段とを更に備えることを特徴とする請求項３に記載のプロトコル変換システム。
【請求項５】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおけるプロトコル変換装置であって、
前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、前記ＳＩＰサーバに対してＳＩＰ信号を発行する手段と、
前記ＳＩＰサーバから受信したＳＩＰ信号を受けて、前記ｉＳＮＳクライアントに対して前記ｉＳＮＳサーバ信号を発行する手段と、
を備えることを特徴とするプロトコル変換装置。
【請求項６】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおけるゲートウェイサーバであって、
前記プロトコル変換装置から発行されたＳＩＰ信号を受けて、前記ｉＳＮＳサーバに対するｉＳＮＳクライアント端末のバイナリー信号を発行する手段と、
前記ｉＳＮＳサーバが発行する前記ｉＳＮＳクライアントへのバイナリー信号を受けて、前記プロトコル変換装置へのＳＩＰ信号を発行する手段と、
を備えることを特徴とするゲートウェイサーバ。
【請求項７】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたシステムのプロトコル変換方法であって、
前記プロトコル変換装置の処理手順は、
前記ｉＳＮＳクライアント端末が発行するバイナリー信号を受信し、前記ＳＩＰサーバに対してＳＩＰ信号を発行するステップと、
前記ＳＩＰサーバから受信したＳＩＰ信号を受けて、前記ｉＳＮＳクライアントに対して前記ｉＳＮＳサーバ信号を発行するステップと、
を含むことを特徴とするプロトコル変換方法。
【請求項８】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたシステムのプロトコル変換方法であって、
前記ゲートウェイサーバの処理手順は、
前記プロトコル変換装置から発行されたＳＩＰ信号を受けて、前記ｉＳＮＳサーバに対するｉＳＮＳクライアント端末のバイナリー信号を発行するステップと、
前記ｉＳＮＳサーバが発行する前記ｉＳＮＳクライアントへのバイナリー信号を受けて、前記プロトコル変換装置へのＳＩＰ信号を発行するステップと、
を含むことを特徴とするプロトコル変換方法。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２０１１−２２７５９３（Ｐ２０１１−２２７５９３Ａ）
【公開日】平成２３年１１月１０日（２０１１．１１．１０）
【国際特許分類】
【出願番号】特願２０１０−９４６４９（Ｐ２０１０−９４６４９）
【出願日】平成２２年４月１６日（２０１０．４．１６）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２３年１１月１０日（２０１１．１１．１０）
【国際特許分類】
【出願日】平成２２年４月１６日（２０１０．４．１６）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]