(57)【要約】【課題】対応表を持たずに、保守機能の実行要否を判断すること。【解決手段】本発明の通信システムは、端末と、前記端末の移動を管理する第１のサーバ装置と、前記端末に対する認証を行う第２のサーバ装置と、を有する。ここで、前記第１のサーバ装置は、前記端末の疑似のＮＡＩを含む第１のメッセージを、ＡＡＡプロトコルを用いて前記第２のサーバ装置に送信する。また、前記第２のサーバ装置は、前記端末のＮＡＩの疑似のＮＡＩと真のＮＡＩとを対応付けて記録するとともに、前記端末に対する保守機能の実行要否を表す保守機能実行要否情報を該端末の真のＮＡＩと対応付けて記録し、前記第１のサーバ装置から前記第１のメッセージを受信すると、該第１のメッセージに含まれる疑似のＮＡＩと対応付けられた保守機能実行要否情報を含む第２のメッセージを、ＡＡＡプロトコルを用いて前記第１のサーバ装置に送信する。【選択図】図２
2010041590.tif 000002
【特許請求の範囲】
【請求項１】
端末と、前記端末の移動を管理する第１のサーバ装置と、前記端末に対する認証を行う第２のサーバ装置と、を有してなる通信システムであって、
前記第１のサーバ装置は、
前記端末の疑似のＮＡＩ（Network Access Identity）を含む第１のメッセージを、ＡＡＡ（Authentication, Authorization, Accounting）プロトコルを用いて前記第２のサーバ装置に送信し、
前記第２のサーバ装置は、
前記端末のＮＡＩの疑似のＮＡＩと真のＮＡＩとを対応付けて記録するとともに、前記端末に対する保守機能の実行要否を表す保守機能実行要否情報を該端末の真のＮＡＩと対応付けて記録し、
前記第１のサーバ装置から前記第１のメッセージを受信すると、該第１のメッセージに含まれる疑似のＮＡＩと対応付けられた保守機能実行要否情報を含む第２のメッセージを、ＡＡＡプロトコルを用いて前記第１のサーバ装置に送信する、通信システム。
【請求項２】
前記第１のメッセージはＡｃｃｅｓｓ  Ｒｅｑｕｅｓｔメッセージであり、
前記第２のメッセージはＡｃｃｅｓｓ  Ａｃｃｅｐｔメッセージである、請求項１に記載の通信システム。
【請求項３】
前記第１のサーバ装置は、
前記Ａｃｃｅｓｓ  ＲｅｑｕｅｓｔメッセージにＡｔｔｒｉｂｕｔｅフィールドを追加し、該Ａｔｔｒｉｂｕｔｅフィールドに前記疑似のＮＡＩを含め、
前記第２のサーバ装置は、
前記Ａｃｃｅｓｓ  ＡｃｃｅｐｔメッセージにＡｔｔｒｉｂｕｔｅフィールドを追加し、該Ａｔｔｒｉｂｕｔｅフィールドに前記保守機能実行要否情報を含める、請求項２に記載の通信システム。
【請求項４】
端末に対する認証を行うサーバ装置であって、
前記端末のＮＡＩの疑似のＮＡＩと真のＮＡＩとを対応付けて記録するとともに、前記端末に対する保守機能の実行要否を表す保守機能実行要否情報を該端末の真のＮＡＩと対応付けて記録する記録部と、
前記端末の移動を管理する他のサーバ装置からＡＡＡプロトコルを用いて送信されてきた、前記端末の疑似のＮＡＩを含む第１のメッセージを受信する受信部と、
前記他のサーバ装置から前記第１のメッセージを受信すると、該第１のメッセージに含まれる疑似のＮＡＩと対応付けられた保守機能実行要否情報を第２のメッセージに含める制御部と、
前記第２のメッセージを、ＡＡＡプロトコルを用いて前記他のサーバ装置に送信する送信部と、を有するサーバ装置。
【請求項５】
前記第１のメッセージはＡｃｃｅｓｓ  Ｒｅｑｕｅｓｔメッセージであり、
前記第２のメッセージはＡｃｃｅｓｓ  Ａｃｃｅｐｔメッセージである、請求項４に記載のサーバ装置。
【請求項６】
前記制御部は、
前記Ａｃｃｅｓｓ  ＡｃｃｅｐｔメッセージにＡｔｔｒｉｂｕｔｅフィールドを追加し、該Ａｔｔｒｉｂｕｔｅフィールドに前記保守機能実行要否情報を含める、請求項５に記載のサーバ装置。
【請求項７】
端末に対する認証を行うサーバ装置による情報通知方法であって、
前記端末のＮＡＩの疑似のＮＡＩと真のＮＡＩとを対応付けて記録するとともに、前記端末に対する保守機能の実行要否を表す保守機能実行要否情報を該端末の真のＮＡＩと対応付けて記録する記録ステップと、
前記端末の移動を管理する他のサーバ装置からＡＡＡプロトコルを用いて送信されてきた、前記端末の疑似のＮＡＩを含む第１のメッセージを受信する受信ステップと、
前記他のサーバ装置から前記第１のメッセージを受信すると、該第１のメッセージに含まれる疑似のＮＡＩと対応付けられた保守機能実行要否情報を第２のメッセージに含める制御ステップと、
前記第２のメッセージを、ＡＡＡプロトコルを用いて前記他のサーバ装置に送信する送信ステップと、を有する情報通知方法。
【請求項８】
前記第１のメッセージはＡｃｃｅｓｓ  Ｒｅｑｕｅｓｔメッセージであり、
前記第２のメッセージはＡｃｃｅｓｓ  Ａｃｃｅｐｔメッセージである、請求項７に記載の情報通知方法。
【請求項９】
前記制御ステップでは、
前記Ａｃｃｅｓｓ  ＡｃｃｅｐｔメッセージにＡｔｔｒｉｂｕｔｅフィールドを追加し、該Ａｔｔｒｉｂｕｔｅフィールドに前記保守機能実行要否情報を含める、請求項８に記載の情報通知方法。
【請求項１０】
端末に対する認証を行うサーバ装置に、
前記端末のＮＡＩの疑似のＮＡＩと真のＮＡＩとを対応付けて記録するとともに、前記端末に対する保守機能の実行要否を表す保守機能実行要否情報を該端末の真のＮＡＩと対応付けて記録する記録手順と、
前記端末の移動を管理する他のサーバ装置からＡＡＡプロトコルを用いて送信されてきた、前記端末の疑似のＮＡＩを含む第１のメッセージを受信する受信手順と、
前記他のサーバ装置から前記第１のメッセージを受信すると、該第１のメッセージに含まれる疑似のＮＡＩと対応付けられた保守機能実行要否情報を第２のメッセージに含める制御手順と、
前記第２のメッセージを、ＡＡＡプロトコルを用いて前記他のサーバ装置に送信する送信手順と、を実行させるプログラム。
【請求項１１】
前記第１のメッセージはＡｃｃｅｓｓ  Ｒｅｑｕｅｓｔメッセージであり、
前記第２のメッセージはＡｃｃｅｓｓ  Ａｃｃｅｐｔメッセージである、請求項１０に記載のプログラム。
【請求項１２】
前記制御手順では、
前記Ａｃｃｅｓｓ  ＡｃｃｅｐｔメッセージにＡｔｔｒｉｂｕｔｅフィールドを追加し、該Ａｔｔｒｉｂｕｔｅフィールドに前記保守機能実行要否情報を含める、請求項１１に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システム、サーバ装置、情報通知方法、プログラムに関する。
【背景技術】
【０００２】
ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）  Ｆｏｒｕｍで策定されたＳｐｅｃには、図３に示すような無線通信システムが規定されている。
【０００３】
図３に示すように、ＷｉＭＡＸの無線通信システムは、ＭＳ（Mobile Station）１０と、ＡＳＮ（Access Service Network）内に配置されたＢＳ（Base Station）２０およびＡＳＮ−ＧＷ（ASN-Gateway）３０と、ＣＳＮ（Connectivity Service Network）内に配置されたＨＡ（Home Agent）４０およびＡＡＡ（Authentication, Authorization, Accounting）サーバ５０と、を有している（例えば、特許文献１，２参照）。
【０００４】
ＢＳ２０は、端末であるＭＳ１０と無線通信を行う基地局であり、ＡＳＮ−ＧＷ３０は、ＭＳ１０をＢＳ２０を介してＣＳＮと接続するゲートウェイ装置である。
【０００５】
ＨＡ４０は、ＭＳ１０の移動を管理するサーバ装置であり、ＡＡＡサーバ５０は、ＭＳ１０に対する認証、許可、および課金を行うサーバ装置である。なお、図３においては、ＨＡ４０は、インターネットと接続されているが、インターネット以外のＩＰ（Internet Protocol）ネットワーク（企業内ネットワークなど）にも接続可能である。
【０００６】
ＷｉＭＡＸの無線通信システムにおいては、ＭＳ１０に対する認証として、ＭＳ１０がＡＳＮに接続されているかを認証するデバイス認証と、ＭＳ１０のユーザがＡＳＮのサービスの契約者であるかを認証するユーザ認証と、が行われる。
【０００７】
ここで、関連するＷｉＭＡＸの無線通信システムにおけるデバイス／ユーザ認証シーケンスについて、図４を参照して説明する。
【０００８】
なお、ここでは、Ｐｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ４を適用した場合のデバイス／ユーザ認証シーケンスについて説明する。
【０００９】
また、ここでは、図４に示したデバイス／ユーザ認証シーケンスの前に、不図示のＤＬ（Down Link）−ＭＡＰシーケンスにおいて、ＢＳ２０は、ＭＳ１０からＭＳ１０のＭＡＣ（Media Access Control）アドレスを取得し、また、不図示のＭＳ−ＰｒｅＡｔｔａｃｈｍｅｎｔシーケンスにおいて、ＡＳＮ−ＧＷ３０は、ＢＳ２０からＭＳ１０のＭＡＣアドレスを取得し、ＡＳＮ内ではＭＳ１０をＭＡＣアドレスにより識別可能になっているものとする。
【００１０】
図４に示すように、まず、ＡＳＮ−ＧＷ３０は、ステップ４０１において、ＢＳ２０を介してＭＳ１０に対し、Ａｕｔｈ．Ｒｅｌａｙプロトコルを用いて、ＥＡＰ（Extensible Authentication Protocol）によるデバイス／ユーザ認証の開始およびＩｄｅｎｔｉｔｙの送付を要求するＥＡＰ  ＲＱ（Request）／Ｉｄｅｎｔｉｔｙメッセージを送信する。
【００１１】
次に、ＭＳ１０は、ステップ４０２において、ＢＳ２０およびＡＳＮ−ＧＷ３０を介してＡＡＡサーバ５０に対し、ＥＡＰ  ＲＱ／Ｉｄｅｎｔｉｔｙメッセージに対する応答として、ＥＡＰを用いて、ＭＳ１０の疑似のＮＡＩ（Network Access Identity）であるＰｓｅｕｄｏ−ＩｄｅｎｔｉｔｙおよびＭＡＣアドレスを含む、ＥＡＰ  ＲＰ（Response）／Ｉｄｅｎｔｉｔｙメッセージを送信する。
【００１２】
これにより、ＡＳＮ−ＧＷ３０は、ＭＳ１０のＰｓｅｕｄｏ−Ｉｄｅｎｔｉｔｙを取得し、取得済みのＭＡＣアドレスと対応付ける。また、ＡＡＡサーバ５０は、ＭＳ１０のＰｓｅｕｄｏ−ＩｄｅｎｔｉｔｙおよびＭＡＣアドレスを取得する。
【００１３】
次に、ＡＡＡサーバ５０は、ＭＳ１０に対するデバイス認証に成功すると、ステップ４０３において、ＡＳＮ−ＧＷ３０およびＢＳ２０を介してＭＳ１０に対し、ＥＡＰを用いて、デバイス認証に成功したことを通知するメッセージ（このメッセージの名称は認証方式によって異なる）を送信する。さらに、ＡＡＡサーバ５０は、ステップ４０４において、ＡＳＮ−ＧＷ３０およびＢＳ２０を介してＭＳ１０に対し、ＭＳ１０の真のＮＡＩであるＴｒｕｅ−Ｉｄｅｎｔｉｔｙの送付を要求するＥＡＰ  ＲＱメッセージを送信する。
【００１４】
次に、ＭＳ１０は、ステップ４０５において、ＢＳ２０およびＡＳＮ−ＧＷ３０を介してＡＡＡサーバ５０に対し、ＥＡＰ  ＲＱメッセージに対する応答として、ＥＡＰを用いて、ＭＳ１０のＴｒｕｅ−Ｉｄｅｎｔｉｔｙを含む、ＥＡＰ  ＲＰメッセージを送信する。
【００１５】
これにより、ＡＡＡサーバ５０は、ＭＳ１０のＴｒｕｅ−Ｉｄｅｎｔｉｔｙを取得し、取得済みのＰｓｅｕｄｏ−Ｉｄｅｎｔｉｔｙと対応付ける。
【００１６】
次に、ＡＡＡサーバ５０は、ＭＳ１０に対するユーザ認証に成功すると、ステップ４０６において、ＡＳＮ−ＧＷ３０に対し、ＥＡＰを用いて、ユーザ認証に成功したことを通知するＥＡＰ  Ｓｕｃｃｅｓｓメッセージを送信する。続いて、ＡＳＮ−ＧＷ３０は、ステップ４０７において、ＢＳ２０を介してＭＳ１０に対し、Ａｕｔｈ．Ｒｅｌａｙプロトコルを用いて、ＥＡＰ  Ｓｕｃｃｅｓｓメッセージを転送する。
【００１７】
次に、ＭＳ１０は、セッションを確立するために、ステップ４０８において、ＢＳ２０を介してＡＳＮ−ＧＷ３０に対し、ＤＨＣＰ（Dynamic Host Configuration Protocol）を用いて、ＩＰ（Internet Protocol）アドレスの割当を要求するＤＨＣＰ  Ｄｉｓｃｏｖｅｒメッセージを送信する。
【００１８】
次に、ＡＳＮ−ＧＷ３０は、ステップ４０９において、ＨＡ４０に対し、Ｍｏｂｉｌｅ  ＩＰを用いて、ＭＳ１０のＰｓｅｕｄｏ−Ｉｄｅｎｔｉｔｙを含む、ＭＳ１０のＣＳＮへの接続を要求するＲＲＱ（Registration Request）メッセージを送信する。
【００１９】
これにより、ＨＡ４０は、ＭＳ１０のＰｓｅｕｄｏ−Ｉｄｅｎｔｉｔｙを取得する。よって、ＨＡ４０は、以降、ユーザ識別情報として、ＮＡＩを使用可能となる。
【００２０】
このとき、ＨＡ４０に通知されるＮＡＩがＰｓｅｕｄｏ−Ｉｄｅｎｔｉｔｙである理由は以下の通りである。すなわち、ＡＳＮ−ＧＷ３０からＨＡ４０に通知されるＮＡＩは、Ｍｏｂｉｌｅ  ＩＰのＥｘｔｅｎｓｉｏｎフィールドに含まれるものであるため、ＩＰｓｅｃ（Security Architecture for IP）などのセキュリティトンネルを使用しなければ、プレーンデータがＡＳＮおよびＣＳＮ上に流れてしまう。このことから、ＷｉＭＡＸの無線通信システムでは、ＭＳ１０とＡＡＡサーバ５０だけが、ｔｒｕｅ−ｉｄｅｎｔｉｔｙを使用し、他のノードはｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙを使用することとしている。このため、ＡＳＮ−ＧＷ３０からＨＡ４０に通知されるＮＡＩは、ｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙとなる。なお、ｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙとｔｒｕｅ−ｉｄｅｎｔｉｔｙとの対応表も、ＭＳ１０とＡＡＡサーバ５０だけがもつことになる。
【００２１】
次に、ＨＡ４０は、ステップ４１０において、ＡＡＡサーバ５０に対し、ＡＡＡプロトコル（例えば、ＲＡＤＩＵＳ（Remote Access Dial In User Service）プロトコル）を用いて、ＭＳ１０のＰｓｅｕｄｏ−Ｉｄｅｎｔｉｔｙを含む、ＭＳ１０に対する認証結果を要求するＡｃｃｅｓｓ  Ｒｅｑｕｅｓｔメッセージを送信する。
【００２２】
次に、ＡＡＡサーバ５０は、ステップ４１１において、ＨＡ４０に対し、Ａｃｃｅｓｓ  Ｒｅｑｕｅｓｔメッセージに対する応答として、ＡＡＡプロトコルを用いて、ＭＳ１０に対する認証結果を通知するＡｃｃｅｓｓ  Ａｃｃｅｐｔメッセージを送信する。
【００２３】
これにより、ＨＡ４０は、ＭＳ１０に対する認証結果を確認する。
【００２４】
次に、ＨＡ４０は、ステップ４１２において、ＡＳＮ−ＧＷ３０に対し、ＲＲＱメッセージに対する応答として、Ｍｏｂｉｌｅ  ＩＰを用いて、ＭＳ１０のＣＳＮへの接続を許可することを通知するＲＲＰ（Registration Response）メッセージを送信する。
【００２５】
その後、ＡＳＮ−ＧＷ３０は、ステップ４１３において、ＢＳ２０を介してＭＳ１０に対し、ＤＨＣＰ  Ｄｉｓｃｏｖｅｒメッセージに対する応答として、ＤＨＣＰを用いて、ＭＳ１０に割り当てるＩＰアドレスの候補を通知するＤＨＣＰ  Ｏｆｆｅｒメッセージを送信する。
【００２６】
これにより、ＭＳ１０は、ＩＰアドレスを取得し、セッション確立のための処理を開始する。
【００２７】
このように、ＷｉＭＡＸの無線通信システムにおいては、ＭＳ１０は、自己のユーザ識別情報として、Ｔｒｕｅ−Ｉｄｅｎｔｉｔｙ、Ｐｓｅｕｄｏ−Ｉｄｅｎｔｉｔｙ、およびＭＡＣアドレスの３つを使用している。
【００２８】
また、ＢＳ２０およびＡＳＮ−ＧＷ３０は、ＭＳ１０のユーザ識別情報として、Ｐｓｅｕｄｏ−ＩｄｅｎｔｉｔｙおよびＭＡＣアドレスの２つを使用可能である。
【００２９】
また、ＨＡ４０は、ＭＳ１０のユーザ識別情報として、Ｐｓｅｕｄｏ−Ｉｄｅｎｔｉｔｙの１つのみを使用可能である。
【００３０】
また、ＡＡＡサーバ５０は、ＭＳ１０のユーザ識別情報として、Ｔｒｕｅ−Ｉｄｅｎｔｉｔｙ、Ｐｓｅｕｄｏ−Ｉｄｅｎｔｉｔｙ、およびＭＡＣアドレスの３つを使用可能である。
【特許文献１】特開２００８−３５２４８号公報
【特許文献２】特開２００８−９２５７７号公報
【発明の開示】
【発明が解決しようとする課題】
【００３１】
ところで、ＭＳ１０、ＢＳ２０、ＡＳＮ−ＧＷ３０、ＨＡ４０、およびＡＡＡサーバ５０の各ノードは、ＭＳ１０のユーザに対して実行する保守機能を備えている。保守機能の一例を以下に示す。
・信号モニタリング機能
指定ユーザに関連する信号を記録する機能。例えば、ＨＡ４０は、Ｍｏｂｉｌｅ  ＩＰおよびＡＡＡプロトコルを用いて転送された信号のうち、指定ユーザに関連する信号を記録する。
・接続規制機能
指定ユーザの接続要求を拒否（Reject）する機能。例えば、ＨＡ４０は、指定ユーザのＣＳＮへの接続を要求するＲＲＱメッセージに対する応答として、ＲＲＰメッセージでエラーを返す。
・輻輳規制除外機能
一般ユーザからの接続要求を破棄する状態でも、指定ユーザのみＲＲＱメッセージによる接続要求を受付ける機能。例えば、ＨＡ４０は、ＨＡ輻輳状態でも、指定ユーザのみ接続要求を受付ける。
・通信傍受機能
指定ユーザの通信データを記録する機能。例えば、ＨＡ４０は、Ｍｏｂｉｌｅ  ＩＰを用いて転送される通信データを通すトンネルを生成した後に、このトンネルを介してＭＳ１０とＣＳＮ間を実際に転送される通信データを記録する。
【００３２】
ただし、ユーザごとに、そのユーザに対して実行する保守機能は異なっている。例えば、あるユーザに対しては、上述した４つの保守機能を全て実行するが、別のユーザに対しては、上述した４つの保守機能のうち輻輳規制除外機能のみを実行する等である。
【００３３】
したがって、各ノードは、保守機能を実行するには、まず、自己に接続されるユーザを指定して、そのユーザに対する保守機能の実行要否を判断する必要がある。
【００３４】
ＭＳ１０およびＡＡＡ５０は、ｔｒｕｅ−ｉｄｅｎｔｉｔｙを使用してユーザ管理を行うことができるので、ユーザ指定を行うのに問題はない。
【００３５】
また、ＢＳ２０およびＡＳＮ−ＧＷ３０は、ｔｒｕｅ−ｉｄｅｎｔｉｔｙを知らないものの、ＮＡＩとは別にＭＡＣアドレスでもユーザ管理を行っているため、ユーザ指定を行うことができる。
【００３６】
しかし、ＨＡ４０は、ユーザ管理をｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙでしか行うことができない。
【００３７】
個々のセッションは、ｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙの一意性が保障されているので、セッション確立後であれば、ＨＡ４０は、そのセッションからユーザ指定を行うことが可能である。しかし、ｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙは、ＥＡＰによる認証シーケンスにおいてＭＳ１０により乱数生成される場合があるため、ＨＡ４０は、セッション確立前に、ユーザを指定できず、保守機能の実行要否を判断できないという課題がある。
【００３８】
また、ＨＡ４０は、他ノードが保持するｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙとｔｒｕｅ−ｉｄｅｎｔｉｔｙとの対応表がないと、Ｍｏｂｉｌｅ  ＩＰセッションのユーザを指定できず、保守機能の実行要否を判断できないという課題がある。
【００３９】
そこで、本発明の目的は、上述した課題のいずれかを解決することができる通信システム、サーバ装置、情報通知方法、プログラムを提供することにある。
【課題を解決するための手段】
【００４０】
本発明の通信システムは、
端末と、前記端末の移動を管理する第１のサーバ装置と、前記端末に対する認証を行う第２のサーバ装置と、を有してなる通信システムであって、
前記第１のサーバ装置は、
前記端末の疑似のＮＡＩを含む第１のメッセージを、ＡＡＡプロトコルを用いて前記第２のサーバ装置に送信し、
前記第２のサーバ装置は、
前記端末のＮＡＩの疑似のＮＡＩと真のＮＡＩとを対応付けて記録するとともに、前記端末に対する保守機能の実行要否を表す保守機能実行要否情報を該端末の真のＮＡＩと対応付けて記録し、
前記第１のサーバ装置から前記第１のメッセージを受信すると、該第１のメッセージに含まれる疑似のＮＡＩと対応付けられた保守機能実行要否情報を含む第２のメッセージを、ＡＡＡプロトコルを用いて前記第１のサーバ装置に送信する。
【００４１】
本発明のサーバ装置は、
端末に対する認証を行うサーバ装置であって、
前記端末のＮＡＩの疑似のＮＡＩと真のＮＡＩとを対応付けて記録するとともに、前記端末に対する保守機能の実行要否を表す保守機能実行要否情報を該端末の真のＮＡＩと対応付けて記録する記録部と、
前記端末の移動を管理する他のサーバ装置からＡＡＡプロトコルを用いて送信されてきた、前記端末の疑似のＮＡＩを含む第１のメッセージを受信する受信部と、
前記他のサーバ装置から前記第１のメッセージを受信すると、該第１のメッセージに含まれる疑似のＮＡＩと対応付けられた保守機能実行要否情報を第２のメッセージに含める制御部と、
前記第２のメッセージを、ＡＡＡプロトコルを用いて前記他のサーバ装置に送信する送信部と、を有する。
【００４２】
本発明の情報通知方法は、
端末に対する認証を行うサーバ装置による情報通知方法であって、
前記端末のＮＡＩの疑似のＮＡＩと真のＮＡＩとを対応付けて記録するとともに、前記端末に対する保守機能の実行要否を表す保守機能実行要否情報を該端末の真のＮＡＩと対応付けて記録する記録ステップと、
前記端末の移動を管理する他のサーバ装置からＡＡＡプロトコルを用いて送信されてきた、前記端末の疑似のＮＡＩを含む第１のメッセージを受信する受信ステップと、
前記他のサーバ装置から前記第１のメッセージを受信すると、該第１のメッセージに含まれる疑似のＮＡＩと対応付けられた保守機能実行要否情報を第２のメッセージに含める制御ステップと、
前記第２のメッセージを、ＡＡＡプロトコルを用いて前記他のサーバ装置に送信する送信ステップと、を有する。
【００４３】
本発明のプログラムは、
端末に対する認証を行うサーバ装置に、
前記端末のＮＡＩの疑似のＮＡＩと真のＮＡＩとを対応付けて記録するとともに、前記端末に対する保守機能の実行要否を表す保守機能実行要否情報を該端末の真のＮＡＩと対応付けて記録する記録手順と、
前記端末の移動を管理する他のサーバ装置からＡＡＡプロトコルを用いて送信されてきた、前記端末の疑似のＮＡＩを含む第１のメッセージを受信する受信手順と、
前記他のサーバ装置から前記第１のメッセージを受信すると、該第１のメッセージに含まれる疑似のＮＡＩと対応付けられた保守機能実行要否情報を第２のメッセージに含める制御手順と、
前記第２のメッセージを、ＡＡＡプロトコルを用いて前記他のサーバ装置に送信する送信手順と、を実行させる。
【発明の効果】
【００４４】
本発明の通信システムによれば、第２のサーバ装置は、第１のサーバ装置に対し、第１のサーバ装置から受信した第１のメッセージに含まれる疑似のＮＡＩに対応する保守機能実行要否情報を含む第２のメッセージを、ＡＡＡプロトコルを用いて送信する。
【００４５】
したがって、第１のサーバ装置は、第２のメッセージの受信以降に、保守機能実行要否情報を確認可能となるため、疑似のＮＡＩと真のＮＡＩとの対応表を持たなくても、保守機能の実行要否を判断できるという効果が得られる。
【発明を実施するための最良の形態】
【００４６】
以下に、本発明を実施するための最良の形態について図面を参照して説明する。
【００４７】
なお、以下で説明する実施形態では、本発明の通信システムが、ＷｉＭＡＸの無線通信システムである場合を例に挙げて説明するが、本発明はこれに限定されず、他の通信方式の無線通信システム、有線通信システム、有線無線混在通信システムであってもよい。
【００４８】
本実施形態の無線通信システムは、図３の無線通信システムの構成要素のうち、ＨＡ４０およびＡＡＡサーバ５０を、それぞれＨＡ４０ＡおよびＡＡＡサーバ５０Ａに変更し、図４のデバイス／ユーザ認証シーケンス内の処理のうち、Ａｃｃｅｓｓ  ＲｅｑｕｅｓｔメッセージおよびＡｃｃｅｓｓ  Ａｃｃｅｐｔメッセージに係るステップ４１０，４１１を、それぞれステップ４１０Ａ，４１１Ａに変更したものである。
【００４９】
そこで、以下では、Ａｃｃｅｓｓ  ＲｅｑｕｅｓｔメッセージおよびＡｃｃｅｓｓ  Ａｃｃｅｐｔメッセージに係る処理を行うＨＡ４０ＡおよびＡＡＡサーバ５０Ａを中心に説明する。
【００５０】
図１は、本実施形態におけるＨＡ４０ＡおよびＡＡＡサーバ５０Ａの構成を示すブロック図である。なお、図１は、Ａｃｃｅｓｓ  ＲｅｑｕｅｓｔメッセージおよびＡｃｃｅｓｓ  Ａｃｃｅｐｔメッセージに係る処理を行う部分の構成のみを示している。
【００５１】
図１に示すように、本実施形態におけるＨＡ４０Ａは、制御部４１と、送信部４２と、受信部４３と、を有している。
【００５２】
制御部４１は、Ａｃｃｅｓｓ  ＲｅｑｕｅｓｔメッセージにＡｔｔｒｉｂｕｔｅフィールドを追加し、そのＡｔｔｒｉｂｕｔｅフィールドにＭＳ１０のｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙを含める。
【００５３】
送信部４２は、制御部４１によりＡｔｔｒｉｂｕｔｅフィールドにｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙを含めたＡｃｃｅｓｓ  Ｒｅｑｕｅｓｔメッセージを、ＡＡＡプロトコルを用いてＡＡＡサーバ５０Ａに送信する。
【００５４】
受信部４３は、ＡＡＡサーバ５０ＡからＡＡＡプロトコルを用いて送信されてきたＡｃｃｅｓｓ  Ａｃｃｅｐｔメッセージを受信する。
【００５５】
また、図１に示すように、本実施形態におけるＡＡＡサーバ５０Ａは、記録部５１と、受信部５２と、制御部５３と、送信部５４と、を有している。
【００５６】
記録部５１は、対応表５１１と保守機能管理リスト５１２とを記録する。
【００５７】
対応表５１１には、デバイス／ユーザ認証シーケンスにおいて取得されるＭＳ１０のｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙとＴｒｕｅ−Ｉｄｅｎｔｉｔｙとが対応付けられて記録される。
【００５８】
保守機能管理リスト５１２には、ＨＡ４０ＡがＭＳ１０に対して実行する保守機能の実行要否を表す保守機能実行要否情報が、ＭＳ１０のＴｒｕｅ−Ｉｄｅｎｔｉｔｙと対応付けられて、Ｔｒｕｅ−Ｉｄｅｎｔｉｔｙごと（ユーザごと）に記録される。例えば、記録部５１は、Ｔｒｕｅ−Ｉｄｅｎｔｉｔｙごとに、表１に示すような保守機能管理リスト５１２を記録することになる。
【００５９】
【表１】
2010041590.tif 000003
【００６０】
受信部５２は、ＨＡ４０ＡからＡＡＡプロトコルを用いて送信されてきたＡｃｃｅｓｓ  Ｒｅｑｕｅｓｔメッセージを受信する。
【００６１】
制御部５３は、受信部５２にてＡｃｃｅｓｓ  Ｒｅｑｕｅｓｔメッセージが受信されると、受信されたＡｃｃｅｓｓ  ＲｅｑｕｅｓｔメッセージのＡｔｔｒｉｂｕｔｅフィールドに含まれるｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙに対応するＴｒｕｅ−Ｉｄｅｎｔｉｔｙを対応表５１１から抽出する。
【００６２】
また、制御部５３は、上記で抽出されたＴｒｕｅ−Ｉｄｅｎｔｉｔｙに対応する保守機能実行要否情報を保守機能管理リスト５１２から抽出する。
【００６３】
さらに、制御部５３は、Ａｃｃｅｓｓ  ＡｃｃｅｐｔメッセージにＡｔｔｒｉｂｕｔｅフィールドを追加し、そのＡｔｔｒｉｂｕｔｅフィールドに上記で抽出された保守機能実行要否情報を含める。
【００６４】
送信部５４は、制御部５３によりＡｔｔｒｉｂｕｔｅフィールドに保守機能実行要否情報を含めたＡｃｃｅｓｓ  Ａｃｃｅｐｔメッセージを、ＡＡＡプロトコルを用いてＨＡ４０Ａに送信する。
【００６５】
以下、本実施形態におけるデバイス／ユーザ認証シーケンスについて、図２を参照して説明する。なお、図２において、図４と同様のステップには同様の符号を付す。
【００６６】
図２に示すように、まず、図４と同様のステップ４０１〜４０９の処理が行われる。
【００６７】
次に、ステップ４１０Ａにおいて、ＨＡ４０Ａは、ステップ４０９でＡＳＮ−ＧＷ３０から受信したＲＲＱメッセージに含まれるｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙをＡｃｃｅｓｓ  ＲｅｑｕｅｓｔメッセージのＡｔｔｒｉｂｕｔｅフィールドに含め、そのＡｃｃｅｓｓ  Ｒｅｑｕｅｓｔメッセージを、ＡＡＡプロトコルを用いてＡＡＡサーバ５０Ａに送信する。
【００６８】
次に、ステップ４１１Ａにおいて、ＡＡＡサーバ５０Ａは、ＨＡ４０Ａから受信したＡｃｃｅｓｓ  Ｒｅｑｕｅｓｔメッセージに含まれるｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙに対応するＴｒｕｅ−Ｉｄｅｎｔｉｔｙを対応表５１１から抽出する。続いて、ＡＡＡサーバ５０Ａは、上記で抽出されたＴｒｕｅ−Ｉｄｅｎｔｉｔｙに対応する保守機能実行要否情報を保守機能管理リスト５１２から抽出する。続いて、ＡＡＡサーバ５０Ａは、Ａｃｃｅｓｓ  ＡｃｃｅｐｔメッセージのＡｔｔｒｉｂｕｔｅフィールドに上記で抽出された保守機能実行要否情報を含め、そのＡｃｃｅｓｓ  Ａｃｃｅｐｔメッセージを、ＡＡＡプロトコルを用いてＨＡ４０Ａに送信する。
【００６９】
その後、図４と同様のステップ４１２，４１３の処理が行われる。
【００７０】
上述したように本実施形態においては、ＡＡＡサーバ５０Ａは、ＨＡ４０Ａに対し、セッションを確立しようとしているＭＳ１０に対する保守機能の実行要否を表す保守機能実行要否情報を、ＡＡＡプロトコルを用いてＡｃｃｅｓｓ  Ａｃｃｅｐｔメッセージにより通知する。
【００７１】
そのため、ＨＡ４０Ａは、Ａｃｃｅｓｓ  Ａｃｃｅｐｔメッセージの受信以降に、ＭＳ１０が確立しようとしているセッションに必要な保守機能実行要否情報を確認可能となる。
【００７２】
よって、ＨＡ４０Ａは、ｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙ以外のユーザ識別情報や、ｐｓｅｕｄｏ−ｉｄｅｎｔｉｔｙとｔｒｕｅ−ｉｄｅｎｔｉｔｙとの対応表を持たなくても、セッション確立前に、保守機能の実行要否を判断できる。
【００７３】
なお、本実施形態においては、Ｐｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ４を適用した場合のデバイス／ユーザ認証シーケンスについて説明したが、本発明はこれに限定されず、その他のデバイス／ユーザ認証シーケンス（例えば、Ｃｌｉｅｎｔ  Ｍｏｂｉｌｅ  ＩＰｖ４を適用したもの）を適用してもよい。
【００７４】
また、本発明のＨＡ４０ＡおよびＡＡＡサーバ５０Ａにて行われる方法は、コンピュータに実行させるためのプログラムに適用してもよい。また、そのプログラムを記憶媒体に格納することも可能であり、ネットワークを介して外部に提供することも可能である。
【図面の簡単な説明】
【００７５】
【図１】本発明の一実施形態の無線通信システムにおけるＨＡおよびＡＡＡサーバの構成を示すブロック図である。
【図２】本発明の一実施形態の無線通信システムにおけるデバイス／ユーザ認証シーケンスを説明するシーケンス図である。
【図３】無線通信システムの全体構成を示す図である。
【図４】関連する無線通信システムにおけるデバイス／ユーザ認証シーケンスを説明するシーケンス図である。
【符号の説明】
【００７６】
１０    ＭＳ
２０    ＢＳ
３０    ＡＳＮ−ＧＷ
４０，４０Ａ    ＨＡ
４１    制御部
４２    送信部
４３    受信部
５０，５０Ａ    ＡＡＡサーバ
５１    記録部
５２    受信部
５３    制御部
５４    送信部
５１１    対応表
５１２    保守機能管理リスト
【図１】
2010041590.tif 000004
【図２】
2010041590.tif 000005
【図３】
2010041590.tif 000006
【図４】
2010041590.tif 000007