JP6580008B2 - 名前解決装置、名前解決システム、名前解決方法及び名前解決プログラム - Google Patents

Description

本発明は、送信元に応じて応答を変更する名前解決装置、名前解決システム、名前解決方法及び名前解決プログラムに関する。

ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）の普及により、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）及びスマートフォンなどの人が利用する端末だけでなく、監視カメラの画像センサ及び人感センサなどの多数のＭ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）デバイスがクライアントとしてインターネットに設置されたサーバに接続されることが予想される。

このような状況において、集中配備されたデータセンタなどに設置されたクラウドサーバによりサービスを提供する従来のクラウドコンピューティング環境では、トラフィック負荷の増大が問題となる。例えば、リアルタイム性を要件とするサービスにおいて許容される遅延時間を満足できない、あるいは、クライアントから大量のデータが流れることでネットワークが混雑し、結果としてデータが破棄されてしまうなどの問題が生じる。
そこで、多数のクライアントが配備される現場の近く、例えば携帯端末の基地局の近くに分散配備されたエッジサーバでクライアントから生じるデータの処理を行い、トラフィック及びクライアントへの応答時間を削減させるエッジコンピューティングが提案されている。

エッジコンピューティングでは、クライアントに近いエッジサーバでデータ処理し応答するために、クライアントからのデータパケットの宛先をエッジサーバのＩＰアドレスとするルーティング（ローカルブレイクアウト）を行なう必要がある。ローカルブレイクアウトの手法として、本出願人は、既存のＤＮＳサーバを利用し、ＤＮＳクエリの送信元のＩＰアドレスに応じて最寄りのエッジサーバのＩＰアドレスをクライアントに応答し、エッジサーバにルーティングする手法を提案した（特願２０１５−０９１１８３、特願２０１５−２４９８８５、特願２０１６−０６２５６９）。

既存のＤＮＳサーバを利用する手法では、ＤＮＳサーバは、クライアントのＩＰアドレスと、このクライアントの場所を示唆する情報（例えば、基地局ＩＤ）との対応関係（在圏状態）を把握すること、及び場所を示唆する情報と対応する最寄りのエッジサーバのＩＰアドレスとを設定ファイル（ＤＮＳゾーンファイル）に記載することが必要である。これにより、ＤＮＳサーバは、ＤＮＳクエリに含まれる送信元のＩＰアドレスをキーに、応答するエッジサーバのＩＰアドレスを変更できる。
ここで、設定ファイルは、運用者によって、エッジサーバを設置した時に最寄りの基地局ＩＤを調査し、エッジサーバに設定したＩＰアドレスと対応付けて作成される。

特開２０１５−２０７９５５号公報 特開２００４−１８７０４６号公報

ところで、基地局がクライアントを収容する方式としては、一旦ゲートウェイを仲介してクライアントを基地局に収容するゲートウェイ方式と、クライアントを直接基地局に収容する直収方式とが存在する。ゲートウェイ方式では、ゲートウェイが設置後に移動することは稀であり、ＤＮＳクエリの送信元であるゲートウェイのＩＰアドレスと、基地局ＩＤとの対応関係である在圏状態の更新頻度は低い。一方、直収方式では、クライアントが移動しハンドオーバが行われることにより、在圏状態の更新がより頻繁に行われる。

前述のＤＮＳサーバを利用する手法では、特に直収方式において、在圏状態の更新が頻繁に必要である。
特許文献１には、移動体通信システムの制御信号をトリガとして在圏状態を把握する技術が提案されている。しかしながら、移動体通信システム外のＤＮＳサーバがこの在圏状態を把握することは難しかった。
特許文献２には、移動体通信システム外の装置からの要求によりクライアントの在圏状態を通知する技術が提案されている。しかしながら、移動体通信システム外からは、要求を行うまで在圏状態を把握できず、クライアントの移動に伴うハンドオーバを即時に検知して、最新の在圏状態を把握することは難しかった。

本発明は、移動体通信システム外からクライアントの在圏状態の更新を即時に検知し、適切なエッジサーバのＩＰアドレスを応答できる名前解決装置、名前解決システム、名前解決方法及び名前解決プログラムを提供することを目的とする。

本発明に係る名前解決装置は、移動体通信システムにおける制御信号から抽出された、クライアントを特定する情報と基地局のＩＤとの対応関係を含む在圏状態の変更通知を受信する受信部と、前記変更通知に基づいて、前記クライアントの最新の在圏状態を記憶する記憶部と、ＤＮＳクエリの送信元である前記クライアントの前記在圏状態に基づいて、前記基地局のＩＤに対応付けられたアドレスを応答する処理部と、を備える。

前記受信部は、前記クライアントのネットワークへの接続処理時に、当該クライアントのアドレスを含む前記変更通知を受信し、前記処理部は、前記ＤＮＳクエリの送信元アドレスから前記基地局のＩＤを導出してもよい。

前記記憶部は、前記クライアントのハンドオーバ時に受信した前記変更通知に基づいて、当該クライアントを特定するセッションの識別子をキーにして、記憶している前記基地局のＩＤを更新してもよい。

前記記憶部は、前記クライアントのネットワークからの切断処理時に受信した前記変更通知に基づいて、記憶している前記基地局のＩＤを削除してもよい。

本発明に係る名前解決システムは、前記名前解決装置と、当該名前解決装置に情報提供する通知サーバとを備える名前解決システムであって、前記通知サーバは、移動体通信システムにおける制御信号を受信する受信部と、前記受信部により受信された制御信号から特定種類のパケットを抽出するフィルタ部と、前記フィルタ部により抽出された同一セッションのパケット内の情報から、クライアントの在圏状態として、当該クライアントを特定する情報と基地局のＩＤとの対応関係を取得する取得部と、前記在圏状態の変更通知を前記名前解決装置へ送信する送信部と、を備える。

本発明に係る名前解決方法は、移動体通信システムにおける制御信号から抽出された、クライアントを特定する情報と基地局のＩＤとの対応関係を含む在圏状態の変更通知を受信する受信ステップと、前記変更通知に基づいて、前記クライアントの最新の在圏状態を記憶する記憶ステップと、ＤＮＳクエリの送信元である前記クライアントの前記在圏状態に基づいて、前記基地局のＩＤに対応付けられたアドレスを応答する処理ステップと、をコンピュータが実行する。

本発明に係る名前解決プログラムは、移動体通信システムにおける制御信号から抽出された、クライアントを特定する情報と基地局のＩＤとの対応関係を含む在圏状態の変更通知を受信する受信ステップと、前記変更通知に基づいて、前記クライアントの最新の在圏状態を記憶する記憶ステップと、ＤＮＳクエリの送信元である前記クライアントの前記在圏状態に基づいて、前記基地局のＩＤに対応付けられたアドレスを応答する処理ステップと、をコンピュータに実行させる。

本発明によれば、移動体通信システム外からクライアントの在圏状態の更新を即時に検知し、適切なエッジサーバのＩＰアドレスを応答できる。

実施形態に係る名前解決システムの全体構成を示す図である。 実施形態に係る通知サーバの機能構成を示す図である。 実施形態に係る在圏状態取得の流れを例示する図である。 実施形態に係る名前解決装置の機能構成を示す図である。 実施形態に係るＤＮＳメッセージ及び在圏状態ＤＢを例示する図である。 実施形態に係る接続時の処理シーケンスを示す図である。 実施形態に係る通知サーバの処理を示すフローチャートである。 実施形態に係るＳ１ハンドオーバ時の処理シーケンスを示す図である。 実施形態に係るＸ２ハンドオーバ時の処理シーケンスを示す図である。 実施形態に係るＬＴＥから３Ｇへのハンドオーバ時の処理シーケンスを示す図である。 実施形態に係る３ＧからＬＴＥへのハンドオーバ時の処理シーケンスを示す図である。 実施形態に係る切断時の処理シーケンスを示す図である。

以下、本発明の実施形態の一例について説明する。
図１は、本実施形態に係る名前解決システム１００の全体構成を示す図である。
名前解決システム１００は、クライアント１と、モバイルネットワーク２と、クラウドサーバ３と、通知サーバ４と、名前解決装置５を備える。

クライアント１は、クラウドサーバ３が提供するサービスを利用するデバイスである。具体的には、クライアント１は、ＰＣ、スマートフォン又はセンサなど、種々のＭ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）デバイスであってよい。

モバイルネットワーク２は、３ＧＰＰ又は３ＧＰＰ２で規定される移動体通信システムのネットワークである。モバイルネットワーク２は、例えば、３ＧＰＰで既定されているＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）に対応する場合、ｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ）２１と、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）２２と、ＳＧＷ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）２３と、ＰＧＷ（ＰＤＮ Ｇａｔｅｗａｙ）２４とを備える。さらに、モバイルネットワーク２は、エッジサーバ２５と、スイッチ２６とを備える。

ｅＮＢ２１は、クライアント１が無線接続する基地局である。各基地局には、ＥＣＧＩ（Ｅ−ＵＴＲＡＮ Ｃｅｌｌ Ｇｌｏｂａｌ Ｉｄｅｎｔｉｆｉｅｒ）と呼ばれるＩＤが割当てられている。
ＭＭＥ２２は、各クライアント１がどのｅＮＢ２１に接続して、モバイルネットワーク２内でどのような転送経路をとるかを管理する通信装置である。
ＳＧＷ２３は、１つ又は複数のｅＮＢを収容し、後述のＰＧＷ２４とｅＮＢとの間でデータを伝送する通信装置である。
ＰＧＷ２４は、外部のネットワークとのインタフェースを有する通信装置である。

エッジサーバ２５は、クライアント１に対してクラウドサーバ３に代わりサービスを提供するサーバであり、クライアント１が配備される現場付近、すなわち基地局（ｅＮＢ２１）それぞれに対応して分散配備される。
スイッチ２６はＭＭＥ２２とＳＧＷ２３との間に設置され、この区間を伝送するモバイルネットワーク２の制御信号（例えば、３ＧＰＰ ＴＳ ２９．２７４で規定されているＧＴＰｖ２−Ｃプロトコル）をミラーリングし、通知サーバに伝送する。

クラウドサーバ３は、クライアント１に対してサービスを提供するサーバであり、データセンタなどに集中配備される。
通知サーバ４は、モバイルネットワーク２の制御信号を受信し、クライアント１の在圏状態の変更通知を名前解決装置５へ提供する。
名前解決装置５は、クライアント１からの要求（ＤＮＳクエリ）に応じて名前解決（ＤＮＳレスポンス）を行うＤＮＳサーバである。

図２は、本実施形態に係る通知サーバ４の機能構成を示す図である。
通知サーバ４は、受信部４１と、キャプチャ部４２と、フィルタ部４３と、記憶部４４と、通知作成部４５（取得部）と、送信部４６とを備える。

受信部４１は、スイッチ２６でミラーリングされたモバイルネットワーク２の制御信号を受信する。
キャプチャ部４２は、受信部４１により受信された制御信号を、ＧＴＰｖ２−Ｃプロトコル仕様に則り解析する。

フィルタ部４３は、制御信号の全てがクライアント１の在圏状態の把握に必要ではないため、必要な特定種類の制御信号パケット（例えば、Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ及びＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅなど）を抽出する。

フィルタ部４３は、リクエスト信号を抽出した場合、パケットの中の情報、例えばＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔの場合は、セッションを識別するためのＴＥＩＤ（Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ＩＤ）と、クライアントを識別するためのＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）と、ＥＣＧＩとを、記憶部４４に格納する。
また、フィルタ部４３は、レスポン信号を抽出した場合には、パケットの中情報、例えばＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅの場合は、ＴＥＩＤと、クライアント１に割り当てるＩＰアドレスであるＰＡＡ（ＰＤＮ Ａｄｄｒｅｓｓ ａｎｄ Ｐｒｅｆｉｘ）とを、通知作成部４５に転送する。

通知作成部４５は、フィルタ部４３から転送されてきたＴＥＩＤ及びＰＡＡを基に、記憶部４４対して同じＴＥＩＤのＩＭＳＩ及びＥＣＧＩを照会し、あるＴＥＩＤにおけるクライアント１のＩＤ（ＩＭＳＩ）と、基地局（ｅＮＢ２１）のＩＤ（ＥＣＧＩ）と、ＩＰアドレス（ＰＡＡ）との対応関係を、在圏状態として取得する。

送信部４６は、取得した在圏状態を、変更通知として名前解決装置５に送信する。この変更通知は、例えば、ＳＱＬコマンドの形式であってよい。

図３は、本実施形態に係る通知サーバ４における在圏状態取得の流れを例示する図である。
記憶部４４には、リクエスト信号から抽出されたＴＥＩＤ、ＩＭＳＩ及びＥＣＧＩが保持される。これに対して、通知作成部４５は、レスポンス信号から抽出されたＴＥＩＤ及びＰＡＡを照合し、ＴＥＩＤが一致するデータを対応付け、ＴＥＩＤ、ＰＡＡ、ＩＭＳＩ及びＥＣＧＩの組み合わせを、クライアント１の在圏状態として送信部４６に提供する。

なお、在圏状態としてＴＥＩＤ、ＰＡＡ、ＩＭＳＩ及びＥＣＧＩの組み合わせが名前解決装置５に登録されると、これ以降の同一クライアント１の在圏状態の変更通知には、クライアント１を特定する情報としてのＴＥＩＤ又はＩＭＳＩと、基地局のＩＤであるＥＣＧＩとの組み合わせが含まれていればよい。

図４は、本実施形態に係る名前解決装置５の機能構成を示す図である。
名前解決装置５は、プラグインソフトウェアにより実装されるプラグイン機能部５０と、標準ＤＮＳ機能部６０と、通信制御部７０とを備える。
プラグイン機能部５０は、クエリ受信部５１と、送信元変換部５２（受信部）と、クエリ処理部５３（処理部）と、レスポンス送信部５４とを備える。
標準ＤＮＳ機能部６０は、ＢＩＮＤなどのオープンソースとして公開されているバイナリファイルにより実装される名前解決処理部６１と、設定ファイル群６２（ｎａｍｅｄ．ｃｏｎｆファイル、ゾーンファイル、ｒｏｏｔ．ｈｉｎｔファイル）とを備える。

通信制御部７０は、プラグイン機能部５０又は標準ＤＮＳ機能部６０から送信されるＤＮＳメッセージについて、送信先ＩＰアドレス及びポート番号の組合せに基づいて、ルーティングテーブルを参照することにより、実際の送信先を決定する。

クエリ受信部５１は、クライアント１からＤＮＳクエリを受信し、ＦＱＤＮ及び送信元ＩＰアドレスを読み取る。送信元ＩＰアドレスは、送信元変換部５２に渡される。

送信元変換部５２は、在圏状態が格納された在圏状態ＤＢ５２１（記憶部）を保持しており、送信元ＩＰアドレスを、標準ＤＮＳ機能部６０へ問い合わせるための送信元情報、すなわち送信元の在圏状態を識別可能な文字列へ変換し、クエリ処理部５３に通知する。
例えば、送信元変換部５２は、「１２．０．０．１」という送信元ＩＰアドレスを、在圏状態ＤＢ５２１に照会して、対応する基地局のＩＤである「４４０ ９９ ０００００００１ ２５５」という送信元情報に変換して、クエリ処理部５３に通知する。
また、送信元変換部５２は、通知サーバ４から在圏状態の変更通知を受信した場合には、変更通知の内容に応じて在圏状態ＤＢ５２１を書き換える。

クエリ処理部５３は、クエリ受信部５１がクライアント１から受信したＤＮＳクエリを受け取る。さらに、クエリ処理部５３は、送信元変換部５２から送信元情報として基地局のＩＤ（ＥＣＧＩ）を受け取る。
クエリ処理部５３は、ＤＮＳクエリの一部を変換して、標準ＤＮＳ機能部６０にＤＮＳメッセージ（Ａレコードリクエスト）を送信する。具体的には、ＤＮＳクエリのＦＱＤＮにホスト名の形式で基地局のＩＤ（ＥＣＧＩ）に対応する文字列が加えられる。
また、クエリ処理部５３は、標準ＤＮＳ機能部６０から受け取ったＤＮＳメッセージ（Ａレコードレスポンス）を一部変換して、クライアント１への応答内容（応答ＩＰアドレス）を、レスポンス送信部５４に通知する。具体的には、加えられた基地局のＩＤ（ＥＣＧＩ）に対応する文字列が取り外される。

レスポンス送信部５４は、クエリ処理部５３から応答内容（応答ＩＰアドレス）を受け取り、ＤＮＳメッセージの形式にパケットを構成して、クライアント１に送信する。

名前解決処理部６１は、既存のＤＮＳサーバが標準的に備える名前解決機能を有し、設定ファイル群６２に含まれるサービス（ドメイン）毎のゾーンファイル６２１を参照し、ＦＱＤＮに対応するＩＰアドレスを回答する。

設定ファイル群６２は、ゾーンファイル６２１の他、ゾーンファイル６２１の格納場所などの設定情報が記述されるｎａｍｅｄ．ｃｏｍｆファイル６２２、及びルートネームサーバのＩＰアドレスが記述されるｒｏｏｔ．ｈｉｎｔファイル６２３を含む。

図５は、本実施形態に係る名前解決装置５のクエリ処理部５３で扱われるＤＮＳメッセージ、及び在圏状態ＤＢ５２１を例示する図である。

クエリ受信部５１が受信するＤＮＳクエリ（１）は、送信元ＩＰアドレス、送信先ＩＰアドレス、送信先ポート番号及びＦＱＤＮを含む。
送信元変換部５２は、在圏状態ＤＢ５２１を参照し、送信元アドレス（ＰＡＡ）「１２．０．０．１」に対応する基地局のＩＤ（ＥＣＧＩ）「４４０ ９９ ０００００００１ ２５５」を取得し、クエリ処理部５３に提供する。

クエリ処理部５３は、Ａレコードリクエスト（２）において、送信元ＩＰアドレスに自分自身「１０．０．０．１」を、送信先ＩＰアドレスに自分自身を表す仮想アドレスであるループバックアドレス「１２７．０．０．１」を設定する。また、ＦＱＤＮには、送信元変換部５２から受け取った基地局のＩＤ（ＥＣＧＩ）を表す文字列「４４０９９０００００００１２５５」が付加されて設定される。
ここで、ポート番号は、プラグイン機能部５０及び標準ＤＮＳ機能部６０のそれぞれにおいて、ＤＮＳメッセージを受信する際に衝突が発生しないように別々に設定される。具体的には、名前解決装置５がＤＮＳメッセージを受信するポート番号である５３番がプラグイン機能部５０に割り当てられ、未使用の特定ポート（例えば、１００５３番）が標準ＤＮＳ機能部６０に割り当てられる。

名前解決処理部６１からクエリ処理部５３に返信されるＡレコードレスポンス（３）には、ＦＱＤＮに対応するエッジサーバ２５のＩＰアドレス「１１．０．０．１」が回答として設定される。
なお、ポート番号には、クエリ処理部５３がＡレコードリクエストを送信した際に使用した送信元ポート番号が設定される。

レスポンス送信部５４は、ＤＮＳレスポンス（４）において、送信先ＩＰアドレスをクライアント１に、ポート番号をクライアント１がＤＮＳクエリ送信時に使用した番号に設定する。そして、ＦＱＤＮは、クエリ処理部５３によりＤＮＳクエリ（１）と同じ文字列に復元される。

次に、クライアント１の在圏状態が変更される時の、モバイルネットワーク２の制御信号、及び通知サーバ４の処理の流れについて説明する。
ここで、クライアント１の在圏状態が変更される時とは、モバイルネットワーク２への接続、異なるＭＭＥ２２間でのＳ１ハンドオーバ、同一のＭＭＥ２２でのＸ２ハンドオーバ、ＬＴＥから３Ｇへのハンドオーバ、３ＧからＬＴＥへのハンドオーバ、モバイルネットワーク２からの切断などである。
在圏状態が変更される各ケースにおいて、３ＧＰＰ ＴＳ ２３．４０１に既定される処理シーケンスに、スイッチ２６、通知サーバ４及び名前解決装置５が介在する。

図６は、本実施形態に係るクライアント１のモバイルネットワーク２への接続時の処理シーケンスを示す図である。

クライアント１がモバイルネットワーク２への接続を開始する時には、クライアント１からｅＮＢ２１を経由してＭＭＥ２２に対して、Ａｔｔａｃｈ Ｒｅｑｕｅｓｔメッセージが送信され（図中の１．，２．）、接続処理が開始される。ＭＭＥ２２は、クライアント１に対して認証手順とセキュリティの確保手順（図中の３．Ａｕｔｈｅｎｔｉｃａｔｉｏｎ／Ｓｅｃｕｒｉｔｙ Ｐｒｏｃｅｄｕｒｅ）を実行する。

続いて、ＭＭＥ２２からＳＧＷ２３に対してＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔが送信される。この時に、ＭＭＥ２２とＳＧＷ２３との間に設置されたスイッチ２６で、ミラーリング（Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔの複製）が行われ、通知サーバ４にもＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔが送信される（図中の４．）。ＳＧＷ２３は、さらに、ＰＧＷ２４に対してＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔを送信する（図中の５．）。

ＰＧＷ２４は、クライアント１に割り当てるＩＰアドレスを決定して、Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ ＲｅｓｐｏｎｓｅをＳＧＷ２３に送信し（図中の６．）、さらに、ＳＧＷ２３からＭＭＥ２２にＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅが送信される。この時に、Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔの場合と同様に、スイッチ２６でミラーリング（Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅの複製）が行われ、通知サーバ４にもＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅが送信される（図中の７．）。

この時点で、通知サーバ４は、名前解決装置５に対して在圏状態を通知するのに十分な情報（ＴＥＩＤ、ＩＭＳＩ、ＥＣＧＩ、ＰＡＡ）を収集できるので、これらの情報を含むＳＱＬコマンドによって名前解決装置５に在圏状態の変更通知を行う（図中の１０１．）。
Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅを受信したＭＭＥ２２は、ｅＮＢ２１及びクライアント１に対して残りの接続処理を実行する（図中の８．〜１３．）。接続処理が完了した後、クライアント１は、エッジサーバ２５との通信が可能となる（図中の１４．）。

図７は、本実施形態に係る通知サーバ４の処理を示すフローチャートである。
クライアント１がモバイルネットワーク２へ接続する際には、通知サーバ４がスイッチ２６から受信すべき制御信号は、Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ及びＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅである。

受信部４１がスイッチ２６から制御信号を受信すると（Ｓ１）、キャプチャ部４２は、受信した制御信号のパケットキャプチャ及び解析を行う（Ｓ２）。
ここで、制御信号は、ＧＴＰｖ２−Ｃプロトコル仕様に則っており、制御信号の種類（Ｍｅｓｓａｇｅ Ｔｙｐｅ ｖａｌｕｅ）が決められている。また、制御信号の種類に応じて、格納される情報（Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔｓ）が決められている。例えば、Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔの場合は、Ｍｅｓｓｓａｇｅ Ｔｙｐｅは３２であり、Ｉｎｆｏｒｍａｔｉｏｎ ＥｌｅｍｅｎｔｓはＴＥＩＤ、ＩＭＳＩ及びＥＣＧＩである。また、Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅの場合は、Ｍｅｓｓｓａｇｅ Ｔｙｐｅは３３であり、Ｉｎｆｏｒｍａｔｉｏｎ ＥｌｅｍｅｎｔｓはＴＥＩＤ及びＰＡＡである。
フィルタ部４３は、制御信号のヘッダ部にあるＭｅｓｓａｇｅ Ｔｙｐｅ ｖａｌｕｅを調べ、対象の制御信号のみ（図６の接続時の場合は、３２及び３３）にフィルタリングを行う（Ｓ３）。

制御信号がＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ、すなわちＭｅｓｓａｇｅ Ｔｙｐｅ ｖａｌｕｅが３２であれば（Ｓ４でＹＥＳ）、フィルタ部４３は、記憶部４４に制御信号の情報であるＴＥＩＤ、ＩＭＳＩ及びＥＣＧＩを格納する（Ｓ５）。
制御信号がＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔでなく（Ｓ４でＮＯ）、Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅ、すなわちＭｅｓｓａｇｅ Ｔｙｐｅ ｖａｌｕｅが３３であれば（Ｓ６でＹＥＳ）、通知作成部４５は、制御信号の情報であるＴＥＩＤ及びＰＡＡを受信すると、ＴＥＩＤの値をキーに、記憶部４４に記憶されているリクエスト信号の情報の組み合わせ（ＴＥＩＤ、ＩＭＳＩ及びＥＣＧＩ）を照会する（Ｓ７）。なお、照会結果が得られた場合、この情報は、記憶部４４から消去される。

通知作成部４５は、対応するリクエスト信号及びレスポンス信号から、ＩＭＳＩ、ＥＣＧＩ、ＰＡＡの組み合わせである在圏状態の情報を取得する（Ｓ８）。
得られた在圏状態の情報は、送信部４６により在圏状態の変更通知として名前解決装置５に送信され、在圏状態ＤＢ５２１に格納される（Ｓ９）。
なお、Ｓ６において、Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅでもないと判定された場合には、フィルタ部４３は、この制御信号を破棄する（Ｓ１０）。

図８は、本実施形態に係るクライアント１のＳ１ハンドオーバ時の処理シーケンスを示す図である。
なお、図中のｅＮＢ、ＭＭＥ、ＳＧＷの前に付く接頭文字のＳ又はＴは、それぞれハンドオーバ元（Ｓｏｕｒｃｅ）又はハンドオーバ先（Ｔａｒｇｅｔ）であることを示している。例えば、ＳｅＮＢは、ハンドオーバ元のｅＮＢ２１を意味する。また破線矢印で示している手順は、ＳＧＷ２３を跨ぐハンドオーバが行われる際に実行される。

クライアント１がＳ１ハンドオーバを行う時には、ハンドオーバ元の基地局（ＳｅＮＢ）からのトリガ（図中の１．Ｈａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄ）により、ＭＭＥ２２が中心となって手順が実行される（図中の２．〜１３ｂ．）。そして、ハンドオーバ先のＭＭＥ２２（ＴＭＭＥ）とＳＧＷ２３（ＴＳＧＷ）との間で、Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ（図中の１４．）とＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅ（図中の１６．）とが交換されてハンドオーバ先での通信が確立され、ハンドオーバ元での通信が切断される（図中の１６ａ．〜１８ｂ．）。

Ｓ１ハンドオーバ時に、ＭＭＥ２２とＳＧＷ２３との間に設置されたスイッチ２６で、ミラーリング（Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔの複製）が行われ、通知サーバ４にもＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔが送信される（図中の１４．）。
また、Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅも、同様にミラーリング（Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅの複製）が行われ、通知サーバ４にもＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅが送信される（図中の１６．）。

Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ及びＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅを受信した通知サーバ４は、在圏状態の変更を知らせる情報（ＴＥＩＤ、ＥＣＧＩ）を、ＳＱＬコマンドによって名前解決装置５に通知する（図中の１０１．）。

ここで、再び図７を参照し、通知サーバ４の処理を説明する。
クライアント１がＳ１ハンドオーバをする際には、通知サーバ４がスイッチ２６から受信すべき制御信号は、Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ及びＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅである。

受信部４１がスイッチ２６から制御信号を受信し（Ｓ１）、キャプチャ部４２がパケットキャプチャ及び解析を行う（Ｓ２）。
ここで、制御信号には、種類に応じて、例えば、Ｍｏｄｉｆｙ Ｂｅａｒｅｒ ＲｅｑｕｅｓｔにはＴＥＩＤ、及びハンドオーバ先の基地局のＩＤであるＥＣＧＩが、Ｍｏｄｉｆｙ Ｂｅａｒｅｒ ＲｅｓｐｏｎｓｅにはＴＥＩＤとＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔの結果を示すＣａｕｓｅの値とが格納されている。
フィルタ部４３は、制御信号のヘッダ部にあるＭｅｓｓａｇｅ Ｔｙｐｅ ｖａｌｕｅを調べ、対象の制御信号のみ（図８のＳ１ハンドオーバの場合は３４及び３５）にフィルタリングを行う（Ｓ３）。

制御信号がＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ、すなわちＭｅｓｓａｇｅ Ｔｙｐｅ ｖａｌｕｅが３４であれば（Ｓ４でＹＥＳ）、フィルタ部４３は、記憶部４４にＴＥＩＤ、及びハンドオーバ先のＥＣＧＩを格納する（Ｓ５）。
制御信号がＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅ、すなわちＭｅｓｓａｇｅＴｙｐｅ ｖａｌｕｅが３５であれば（Ｓ６でＹＥＳ）、通知作成部４５は、ＴＥＩＤ及びＣａｕｓｅを受信すると、Ｃａｕｓｅの値がハンドオーバの成功を示すものであればＴＥＩＤの値をキーに、記憶部４４に記憶されているリクエスト信号の情報の組み合わせ（ＴＥＩＤ、ＥＣＧＩ）を照会する（Ｓ７）。なお、照会結果が得られた場合、この情報は、記憶部４４から消去される。

通知作成部４５は、対応するリクエスト信号及びレスポンス信号から、ＴＥＩＤ及びＥＣＧＩの組み合わせである在圏状態の変更に関わる情報を取得する（Ｓ８）。
得られた在圏状態の情報は、送信部４６により変更通知として名前解決装置５に送信される（Ｓ９）。名前解決装置５では、変更通知のＴＥＩＤをキーにして、在圏状態ＤＢ５２１のＥＣＧＩが書き換えられる。
なお、Ｓ６において、Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅでもないと判定された場合には、フィルタ部４３は、この制御信号を破棄する（Ｓ１０）。

図９は、本実施形態に係るクライアント１のＸ２ハンドオーバ時の処理シーケンスを示す図である。
なお、図中のｅＮＢの前に付く接頭文字のＳ又はＴは、それぞれハンドオーバ元（Ｓｏｕｒｃｅ）又はハンドオーバ先（Ｔａｒｇｅｔ）であることを示している。例えば、ＳｅＮＢは、ハンドオーバ元のｅＮＢ２１を意味する。

クライアント１がＸ２ハンドオーバを行う時には、ハンドオーバ先の基地局（ＴｅＮＢ）からのトリガ（図中の１．Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ）により、ＭＭＥ２２とＳＧＷ２３との間で、Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ（図中の２．）とＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅ（図中の５．）とが交換されてハンドオーバ先での通信が確立され、ハンドオーバ元での通信が切断される（図中６．〜８．）。

Ｘ２ハンドオーバ時に、ＭＭＥ２２とＳＧＷ２３との間に設置されたスイッチ２６で、ミラーリング（Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔの複製）が行われ、通知サーバ４にもＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔが送信される（図中の２．）。
また、Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅも、同様にミラーリング（Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅの複製）が行われ、通知サーバ４にもＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅが送信される（図中の５．）。

Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ及びＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅを受信した通知サーバ４は、在圏状態の変更を知らせる情報（ＴＥＩＤ、ＥＣＧＩ）を、ＳＱＬコマンドによって名前解決装置５に通知する（図中の１０１．）。
なお、通知サーバ４においては、Ｓ１ハンドオーバの場合（図８）と同じ処理が実行される。

図１０は、本実施形態に係るクライアント１のＬＴＥから３Ｇへのハンドオーバ時の処理シーケンスを示す図である。
なお、図中のＲＮＣ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）及びＳＧＮＳ（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）は、それぞれ３Ｇシステムにおいて、ＬＴＥシステムのｅＮＢ２１及びＭＭＥ２２に相当する通信装置である。
また、図中のｅＮＢ、ＲＮＣ、ＭＭＥ、ＳＧＳＮ、ＳＧＷの前に付く接頭文字のＳ又はＴは、それぞれハンドオーバ元（Ｓｏｕｒｃｅ）又はハンドオーバ先（Ｔａｒｇｅｔ）であることを示している。例えば、ＳｅＮＢは、ハンドオーバ元のｅＮＢ２１を意味する。また、破線矢印で示している手順は、ＳＧＷ２３を跨ぐハンドオーバが行われる際に実行される。

クライアント１がハンドオーバを行う時には、ハンドオーバ元のｅＮＢ２１からのトリガ（図中の１．Ｈａｎｄｏｖｅｒ Ｃｏｍｍａｎｄ）により、ハンドオーバ先のＳＧＳＮとＳＧＷ２３との間で、Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ（図中の６．）とＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅ（図中の８．）とが交換されてハンドオーバ先での通信が確立され、ハンドオーバ元での通信が切断される（図中の９．〜１１ａ．）。

ＬＴＥから３Ｇへのハンドオーバ時に、ＭＭＥ２２とＳＧＷ２３との間に設置されたスイッチ２６で、ミラーリング（Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔの複製）が行われ、通知サーバ４にもＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔが送信される（図中の６．）。
また、Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅも、同様にミラーリング（Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅの複製）が行われ、通知サーバ４にもＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅが送信される（図中の８．）。

Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ及びＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅを受信した通知サーバ４は、在圏状態の変更を知らせる情報（ＴＥＩＤ、ＥＣＧＩ）を、ＳＱＬコマンドによって名前解決装置５に通知する（図中の１０１．）。
なお、通知サーバ４においては、Ｓ１ハンドオーバの場合（図８）と同じ処理が実行される。

図１１は、本実施形態に係るクライアント１の３ＧからＬＴＥへのハンドオーバ時の処理シーケンスを示す図である。
なお、図中のｅＮＢ、ＲＮＣ、ＭＭＥ、ＳＧＳＮ、ＳＧＷの前に付く接頭文字のＳ又はＴは、それぞれハンドオーバ元（Ｓｏｕｒｃｅ）又はハンドオーバ先（Ｔａｒｇｅｔ）であることを示している。例えば、ＳｅＮＢは、ハンドオーバ元のｅＮＢ２１を意味する。また、破線矢印で示している手順は、ＳＧＷ２３を跨ぐハンドオーバが行われる際に実行される。

クライアント１がハンドオーバを行う時には、ハンドオーバ元のＳＧＳＮからのトリガ（図中の１．Ｒｅｌｏｃａｔｉｏｎ Ｃｏｍｍａｎｄ）により、ハンドオーバ先のＭＭＥ２２とＳＧＷ２３との間で、Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ（図中の６．）とＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅ（図中の８．）とが交換されてハンドオーバ先での通信が確立され、ハンドオーバ元での通信が切断される（図中の９．〜１１ａ．）。

３ＧからＬＴＥへのハンドオーバ時に、ＭＭＥ２２とＳＧＷ２３との間に設置されたスイッチ２６で、ミラーリング（Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔの複製）が行われ、通知サーバ４にもＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔが送信される（図中の６．）。
また、Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅも、同様にミラーリング（Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅの複製）が行われ、通知サーバ４にもＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅが送信される（図中の８．）。

Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ及びＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅを受信した通知サーバ４は、在圏状態の変更を知らせる情報（ＴＥＩＤ、ＥＣＧＩ）を、ＳＱＬコマンドによって名前解決装置５に通知する（図中の１０１．）。
なお、通知サーバ４においては、Ｓ１ハンドオーバの場合（図８）と同じ処理が実行される。

図１２は、本実施形態に係るクライアント１のモバイルネットワーク２からの切断時の処理シーケンスを示す図である。

クライアント１が通信を切断する時には、クライアント１からｅＮＢ２１を経由してＭＭＥ２２に対して、Ｄｅｔａｃｈ Ｒｅｑｕｅｓｔメッセージが送信され（図中の１．）、切断処理が開始される。そして、ＭＭＥ２２とＳＧＷ２３との間で、Ｄｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ（図中の２．）とＤｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅ（図中の５．）とが交換され、クライアント１の通信が切断される（図中の６．〜７．）。

クライアント１の通信の切断の時に、ＭＭＥ２２とＳＧＷ２３との間に設置されたスイッチ２６で、ミラーリング（Ｄｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔの複製）が行われ、通知サーバ４にもＤｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔが送信される（図中の２．）。
また、Ｄｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅも、同様にミラーリング（Ｄｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅの複製）が行われ、通知サーバ４にもＤｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅが送信される（図中の５．）。

Ｄｅｌｅｔｅ ＳｅｓｓｉｏｎＲｅｑｕｅｓｔ及びＤｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅを受信した通知サーバ４は、在圏状態の変更を知らせる情報（ＴＥＩＤ、ＥＣＧＩ）を、ＳＱＬコマンドによって名前解決装置５に通知する（図中の１０１．）。

なお、通知サーバ４においては、Ｓ１ハンドオーバの場合（図８）のＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ及びＭｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅを、それぞれＤｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ及びＤｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅに置き換えた場合と同じ処理が実行される。
名前解決装置５では、変更通知に基づいて、在圏状態ＤＢ５２１におけるクライアント１のＩＭＳＩに対応するＥＣＧＩが削除される。あるいは、この切断されたクライアント１のレコードが在圏状態ＤＢ５２１から削除されてもよい。

本実施形態によれば、名前解決装置５は、モバイルネットワーク２の制御信号から抽出されたクライアント１の在圏状態の変更通知を受信し、最新の在圏状態を記憶することにより、クライアント１からのＤＮＳクエリに対して、基地局のＩＤ（ＥＣＧＩ）に対応づけられたエッジサーバ２５のＩＰアドレスを応答する。
したがって、名前解決装置５は、クライアント１が位置登録する基地局が頻繁に変更される移動体通信システム（モバイルネットワーク２）から、クライアント１の在圏状態の更新を即時に検知できるので、在圏状態ＤＢ５２１を動的に更新して、クライアント１の最寄りの適切なエッジサーバ２５のＩＰアドレスを応答できる。
さらに、クライアント１の接続、ハンドオーバ、切断など、在圏状態が変化する度に設定ファイル群６２の更新・リロードを行う必要が無くなり、名前解決装置５の運用が自動化される。

名前解決装置５は、クライアント１のモバイルネットワーク２への接続処理時に、クライアント１のＩＰアドレスを含む在圏状態を受信して記憶する。したがって、名前解決装置５は、クライアント１からＤＮＳクエリを受信した際に、送信元ＩＰアドレスから容易に対応する基地局のＩＤ（ＥＣＧＩ）を導出し、適切なエッジサーバ２５のＩＰアドレスを応答できる。

名前解決装置５は、クライアント１がハンドオーバした際には、変更通知に含まれるクライアントのＩＤ（ＩＭＳＩ）をキーとして在圏状態ＤＢ５２１における基地局のＩＤ（ＥＣＧＩ）を更新する。したがって、名前解決装置５は、モバイルネットワーク２の制御信号からクライアント１のＩＰアドレスを検知できないケースにおいても、在圏状態ＤＢ５２１を更新でき、クライアント１のアドレス（ＰＡＡ）と基地局のＩＤ（ＥＣＧＩ）との対応付けを容易に取得できる。

名前解決装置５は、クライアント１がモバイルネットワーク２から切断された際には、変更通知に基づいて在圏状態ＤＢ５２１の基地局のＩＤ（ＥＣＧＩ）を削除する。したがって、名前解決装置５は、在圏状態ＤＢ５２１から不要な情報を削除でき、データ容量を削減できると共に、誤動作を防止できる。

名前解決システム１００は、モバイルネットワーク２の制御信号をミラーリングして、通知サーバ４において特定種類のパケットの組み合わせを抽出することにより、クライアントのＩＤ（ＩＭＳＩ）とクライアントのアドレス（ＰＡＡ）と基地局のＩＤ（ＥＣＧＩ）との対応関係を含む在圏状態を取得する。したがって、名前解決システム１００は、モバイルネットワーク２における既存の処理シーケンスを改変することなく、名前解決装置５で最新の在圏状態を保持できる。

以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、本実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本実施形態に記載されたものに限定されるものではない。

名前解決装置５の機能構成は、図４には限定されず、ＤＮＳクエリの処理方法は、本実施形態には限られない。例えば、標準ＤＮＳ機能部６０を備えず、専用の設定ファイル及び処理部により名前解決が行われてもよいし、標準ＤＮＳ機能部６０と共に、プラグインの処理部により名前解決が行われてもよい。
本発明は、クライアント１のＩＰアドレスと、このクライアント１の場所を示す情報（地名、基地局のＩＤ（ＥＣＧＩ）など）との対応関係を保持し、さらに、場所を示す情報と対応する最寄りのエッジサーバのＩＰアドレスとを設定ファイルに記載する既知の名前解決の手法に適用可能である。

本実施形態では、モバイルネットワーク２において在圏状態が更新される複数のケースを例示したが、これらの他、３Ｇ内でのハンドオーバ、３Ｇへの接続及び切断などについても同様の処理シーケンスが実行されるので、所定のリクエスト信号及びレスポンス信号の組み合わせが抽出可能である。
また、本実施形態で抽出した制御信号は一例であり、在圏状態を取得可能な他の制御信号が用いられてもよい。

名前解決システム１００による名前解決方法は、ソフトウェアにより実現される。ソフトウェアによって実現される場合には、このソフトウェアを構成するプログラムが、情報処理装置にインストールされる。また、これらのプログラムは、ＣＤ−ＲＯＭのようなリムーバブルメディアに記録されてユーザに配布されてもよいし、ネットワークを介してユーザのコンピュータにダウンロードされることにより配布されてもよい。

１ クライアント
２ モバイルネットワーク
３ クラウドサーバ
４ 通知サーバ
５ 名前解決装置
２５ エッジサーバ
２６ スイッチ
４１ 受信部
４２ キャプチャ部
４３ フィルタ部
４４ 記憶部
４５ 通知作成部
４６ 送信部
５０ プラグイン機能部
５１ クエリ受信部
５２ 送信元変換部
５３ クエリ処理部
５４ レスポンス送信部
６０ 標準ＤＮＳ機能部
６１ 名前解決処理部
６２ 設定ファイル群
７０ 通信制御部
１００ 名前解決システム
５２１ 在圏状態ＤＢ
６２１ ゾーンファイル
６２２ ｎａｍｅｄ．ｃｏｎｆファイル
６２３ ｒｏｏｔ．ｈｉｎｔファイル

Claims (7)

1. 移動体通信システムにおける制御信号から抽出された、クライアントを特定する情報と基地局のＩＤとの対応関係を含む在圏状態の変更通知を受信する受信部と、
   前記変更通知に基づいて、前記クライアントの最新の在圏状態を記憶する記憶部と、
   ＤＮＳクエリの送信元である前記クライアントの前記在圏状態に基づいて、前記基地局のＩＤに対応付けられたアドレスを応答する処理部と、を備える名前解決装置。
2. 前記受信部は、前記クライアントのネットワークへの接続処理時に、当該クライアントのアドレスを含む前記変更通知を受信し、
   前記処理部は、前記ＤＮＳクエリの送信元アドレスから前記基地局のＩＤを導出する請求項１に記載の名前解決装置。
3. 前記記憶部は、前記クライアントのハンドオーバ時に受信した前記変更通知に基づいて、当該クライアントを特定するセッションの識別子をキーにして、記憶している前記基地局のＩＤを更新する請求項１又は請求項２に記載の名前解決装置。
4. 前記記憶部は、前記クライアントのネットワークからの切断処理時に受信した前記変更通知に基づいて、記憶している前記基地局のＩＤを削除する請求項１から請求項３のいずれかに記載の名前解決装置。
5. 請求項１から請求項４のいずれかに記載の名前解決装置と、当該名前解決装置に情報提供する通知サーバとを備える名前解決システムであって、
   前記通知サーバは、
   移動体通信システムにおける制御信号を受信する受信部と、
   前記受信部により受信された制御信号から特定種類のパケットを抽出するフィルタ部と、
   前記フィルタ部により抽出された同一セッションのパケット内の情報から、クライアントの在圏状態として、当該クライアントを特定する情報と基地局のＩＤとの対応関係を取得する取得部と、
   前記在圏状態の変更通知を前記名前解決装置へ送信する送信部と、を備える名前解決システム。
6. 移動体通信システムにおける制御信号から抽出された、クライアントを特定する情報と基地局のＩＤとの対応関係を含む在圏状態の変更通知を受信する受信ステップと、
   前記変更通知に基づいて、前記クライアントの最新の在圏状態を記憶する記憶ステップと、
   ＤＮＳクエリの送信元である前記クライアントの前記在圏状態に基づいて、前記基地局のＩＤに対応付けられたアドレスを応答する処理ステップと、をコンピュータが実行する名前解決方法。
7. 移動体通信システムにおける制御信号から抽出された、クライアントを特定する情報と基地局のＩＤとの対応関係を含む在圏状態の変更通知を受信する受信ステップと、
   前記変更通知に基づいて、前記クライアントの最新の在圏状態を記憶する記憶ステップと、
   ＤＮＳクエリの送信元である前記クライアントの前記在圏状態に基づいて、前記基地局のＩＤに対応付けられたアドレスを応答する処理ステップと、をコンピュータに実行させるための名前解決プログラム。

Images