(57)【特許請求の範囲】
【請求項１】
モバイル環境を含むネットワーク上で通信制御を行うネットワークシステムにおいて、
通信端末のサービス内容を規定し、カスタマイズ可能なサービスプロファイルを格納して管理するサービス制御データベースと、
前記通信端末の通信初期化設定時に、前記サービス制御データベースにアクセスして前記サービスプロファイルを抽出し、前記通信端末が送受信するパケット経路上のネットワーク機器に前記サービスプロファイルを設定するサービスプロファイル設定制御手段と、前記サービスプロファイル内の規制条件にもとづいてイベントを発生し、前記イベントの発生時に、前記サービス制御データベースにアクセスして新たな前記サービスプロファイルを抽出し、前記ネットワーク機器に前記新たなサービスプロファイルを動的に再設定するサービスプロファイル再設定制御手段と、から構成され前記通信端末の加入契約先ドメイン内に配置されるホームサーバと、
前記加入契約先ドメインとは異なるドメインに配置されて、前記通信端末を収容し、前記ドメイン内のネットワーク機器に前記サービスプロファイルを回送するフォーリンサーバと、
前記通信端末と通信する相手端末を収容し、前記通信端末の位置を管理し、前記通信端末に対するパケット送出の中継制御を行って、前記サービスプロファイルを更新するホームエージェントと、
前記通信端末を収容し、前記通信端末に対するパケット送出の中継制御を行い、前記サービスプロファイルを更新するフォーリンエージェントと、
を有することを特徴とするネットワークシステム。
【請求項２】
前記ホームサーバは、ユーザ認証に関するイベント、ネットワーク資源の使用認可に関するイベント及び課金に関するイベントの少なくとも１つのイベントを自律的に発生し、前記イベントの発生時に前記サービスプロファイルの設定制御を行うことを特徴とする請求項１記載のネットワークシステム。
【請求項３】
前記ネットワークの監視及び管理を行い、内部で発生したイベントを前記ホームサーバへ通知するネットワーク制御機構部をさらに有することを特徴とする請求項１記載のネットワークシステム。
【請求項４】
前記ホームサーバは、前記ネットワーク制御機構部から送信された前記イベントを受信して、前記サービスプロファイルの設定制御を行うことを特徴とする請求項３記載のネットワークシステム。
【請求項５】
前記ホームエージェントは、前記相手端末から前記通信端末へ回送されるパケットを受信して前記相手端末に経路最適化を行った際に、前記相手端末の情報を記録しておき、前記ホームサーバから前記サービスプロファイルの変更要求があった場合、前記情報にもとづいて前記通信端末の現在の通信先である前記相手端末を特定することを特徴とする請求項１記載のネットワークシステム。
【請求項６】
前記通信端末の通信初期化設定時に、前記ホームサーバが前記ホームエージェントを割り当てた接続形態となることを特徴とする請求項１記載のネットワークシステム。
【請求項７】
前記接続形態に対し、前記通信端末が同一の前記フォーリンサーバ内の新フォーリンエージェント配下に移動した際は、前記新フォーリンエージェントは、旧フォーリンエージェントに対して前記サービスプロファイルの変更要求を送信することを特徴とする請求項６記載のネットワークシステム。
【請求項８】
前記接続形態に対し、前記通信端末が接続していた旧フォーリンサーバとは異なる新フォーリンサーバ内の新フォーリンエージェント配下に前記通信端末が移動した際は、前記ホームサーバは、前記新フォーリンサーバと前記旧フォーリンサーバの両方に、前記サービスプロファイルの変更要求を送信することを特徴とする請求項６記載のネットワークシステム。
【請求項９】
前記通信端末の通信初期化設定時に、前記フォーリンサーバが前記ホームエージェントを割り当てた接続形態となることを特徴とする請求項１記載のネットワークシステム。
【請求項１０】
前記接続形態に対し、前記通信端末が同一の前記フォーリンサーバ内の新フォーリンエージェント配下に移動した際は、前記新フォーリンエージェントは、旧フォーリンエージェントに対して前記サービスプロファイルの変更要求を送信することを特徴とする請求項９記載のネットワークシステム。
【請求項１１】
前記接続形態に対し、前記通信端末が接続していた旧フォーリンサーバとは異なる新フォーリンサーバ内の新フォーリンエージェント配下に前記通信端末が移動した際は、前記ホームサーバは、前記新フォーリンサーバと前記旧フォーリンサーバの両方に、前記サービスプロファイルの変更要求を送信することを特徴とする請求項９記載のネットワークシステム。
【請求項１２】
前記ホームサーバは、アドレス変換サーバを用いたサービスの実行中に、アドレス変換規則に関係するイベントが発生した場合は、前記アドレス変換サーバに前記サービスプロファイルの設定制御を行うことを特徴とする請求項１記載のネットワークシステム。
【請求項１３】
前記サービス制御データベース内の前記サービスプロファイルの変更処理と、前記ホームサーバでのイベント発生と、の競合を防止する競合防止処理手段をさらに有することを特徴とする請求項１記載のネットワークシステム。
【請求項１４】
前記競合防止処理手段は、競合時には、設定済みのイベントを棄却し、前記サービス制御データベース内の前記サービスプロファイルの変更処理後にサービスプロファイルの再配布及びイベントの再設定を行うことを特徴とする請求項１３記載のネットワークシステム。
【請求項１５】
通信端末の加入契約先ドメイン内に配置されるサーバであるホームサーバにおいて、
前記通信端末の通信初期化設定時に、サービス制御データベースにアクセスしてサービスプロファイルを抽出し、前記通信端末が送受信するパケット経路上のネットワーク機器に前記サービスプロファイルを設定するサービスプロファイル設定制御手段と、
前記サービスプロファイル内の規制条件にもとづいてイベントを発生し、前記イベントの発生時に、前記サービス制御データベースにアクセスして新たな前記サービスプロファイルを抽出し、前記ネットワーク機器に前記新たなサービスプロファイルを動的に再設定するサービスプロファイル再設定制御手段と、
を有することを特徴とするホームサーバ。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はネットワークシステムに関し、特にモバイル環境を含むＩＰ（Internet Protocol）ネットワーク上で通信制御を行うネットワークシステムに関する。
【０００２】
【従来の技術】
近年、インターネットの急速な発展により、ＩＰパケットのトラヒックが急増している。また、携帯電話機の普及に伴ってのＩＭＴ２０００（International Mobile Telecommunications 2000）の標準化もあり、モバイル環境での高速ＩＰ通信の開発が急速に進んでいる。
【０００３】
このような技術革新にも関わらず、ＩＰ通信の高度化、すなわち、端末毎のＱＯＳ、ＷＷＷサーバのネットワークワイドな負荷分散といった付加価値サービスを実現する技術は、現状では需要が見込まれる中で十分に成熟しているとは言えない。
【０００４】
また、より高度な付加価値サービスを実現するために、既存電話網のＩＮ（Intelligent Network)サービスと同様に、様々な条件や管理ポリシにしたがい、サービス制御情報（サービスプロファイル）を動的に変更したいという要求が出てきている。
【０００５】
【発明が解決しようとする課題】
アクセス回線の料金が次第に安価になっていく中で、キャリアやＩＳＰ（Internet Service Provider)は、ユーザに様々な付加価値サービスを提供し、ユーザの用途に応じたサービス形態を提供することで料金を回収する。
【０００６】
一方、ユーザの基本的な関心事項は、サービス品質と料金の相関関係であり、ユーザはなるべく安い料金で高品質なサービスを受けることを望むが、サービス品質は、ネットワークトラフィックにより影響を受けるために、料金の高い高品質サービスを契約していても、低トラフィックの時は低品質サービスと比べて料金の差別化が難しくなる。
【０００７】
したがって、トラフィックの比較的少ない時間のみに、インターネットを利用するユーザは、高品質サービスを契約してもほとんどメリットを受けられないような事態が発生する。
【０００８】
このように、ユーザが考えるサービス品質と、そのことに対する対価は一様ではないため、いくつかのメニュー形式の料金体系だけでは、かならずしもユーザを満足させることはできない。したがって、ユーザが自分の生活様式に合わせて、時間帯や使用料金を組み合わせて、自由にサービス品質を指定できるネットワークシステムの開発が必要である。すなわち、通信中に動的に条件が変化するようなサービスを、モバイルＩＰネットワークで実現する必要がある。
【０００９】
本発明はこのような点に鑑みてなされたものであり、モバイル環境を含むＩＰネットワークに対し、端末単位での付加価値サービスを定義し、ユーザ単位に自由にカスタマイズされた制御情報にもとづき、通信中でも動的にサービスが変更可能なネットワークシステムを提供することを目的とする。
【００１０】
【課題を解決するための手段】
本発明では上記課題を解決するために、図１に示すような、モバイル環境を含むネットワーク上で通信制御を行うネットワークシステム１において、通信端末６０のサービス内容を規定し、カスタマイズ可能なサービスプロファイルを格納して管理するサービス制御データベース１０と、通信端末６０の通信初期化設定時に、サービス制御データベース１０にアクセスしてサービスプロファイルを抽出し、通信端末６０が送受信するパケット経路上のネットワーク機器にサービスプロファイルを設定するサービスプロファイル設定制御手段２ａと、サービスプロファイル内の規制条件にもとづいてイベントを発生し、イベントの発生時に、サービス制御データベース１０にアクセスして新たなサービスプロファイルを抽出し、ネットワーク機器に新たなサービスプロファイルを動的に再設定するサービスプロファイル再設定制御手段２ｂと、から構成されて、通信端末６０の加入契約先ドメイン内に配置されるホームサーバ２０と、加入契約先ドメインとは異なるドメインに配置されて、通信端末６０を収容し、ドメイン内のネットワーク機器にサービスプロファイルを回送するフォーリンサーバ３０と、通信端末６０と通信する相手端末７０を収容し、通信端末６０の位置を管理し、通信端末６０に対するパケット送出の中継制御を行って、サービスプロファイルを更新するホームエージェント４０と、通信端末６０を収容し、通信端末６０に対するパケット送出の中継制御を行い、サービスプロファイルを更新するフォーリンエージェント５０と、を有することを特徴とするネットワークシステム１が提供される。
【００１１】
ここで、サービス制御データベース１０は、通信端末６０のサービス内容を規定し、カスタマイズ可能なサービスプロファイルを格納して管理する。サービスプロファイル設定制御手段２ａは、通信端末６０の通信初期化設定時に、サービス制御データベース１０にアクセスしてサービスプロファイルを抽出し、通信端末６０が送受信するパケット経路上のネットワーク機器にサービスプロファイルを設定する。サービスプロファイル再設定制御手段２ｂは、サービスプロファイル内の規制条件にもとづいてイベントを発生し、イベントの発生時に、サービス制御データベース１０にアクセスして新たなサービスプロファイルを抽出し、ネットワーク機器に新たなサービスプロファイルを動的に再設定する。フォーリンサーバ３０は、加入契約先ドメインとは異なるドメインに配置されて、通信端末６０を収容し、ドメイン内のネットワーク機器にサービスプロファイルを回送する。ホームエージェント４０は、通信端末６０と通信する相手端末７０を収容し、通信端末６０の位置を管理し、通信端末６０に対するパケット送出の中継制御を行って、サービスプロファイルを更新する。フォーリンエージェント５０は、通信端末６０を収容し、通信端末６０に対するパケット送出の中継制御を行い、サービスプロファイルを更新する。
【００１２】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。図１は本発明のネットワークシステムの原理図である。ネットワークシステム１は、モバイル環境を含むネットワーク上で通信制御を行う。
【００１３】
ホームサーバ２０は、サービス制御データベース１０とフォーリンサーバ３０とネットワーク制御機構部８０とホームエージェント４０と接続する。さらにフォーリンサーバ３０は、フォーリンエージェント５０と接続し、ＩＰネットワーク９０は、フォーリンエージェント５０とネットワーク制御機構部８０とホームエージェント４０と接続する。
【００１４】
通信端末６０は、移動端末に該当し、フォーリンエージェント５０と無線で接続する。また、通信端末６０の通信相手である相手端末７０は、ホームエージェント４０と接続する。
【００１５】
サービス制御データベース（以降、データベースをＤＢと呼ぶ）１０は、通信端末６０のサービス内容を規定し、カスタマイズ可能（通信端末６０を使用しているユーザから任意に設定可能）なサービスプロファイルを格納して管理する。
【００１６】
ホームサーバ２０は、サービスプロファイル設定制御手段２ａと、サービスプロファイル再設定制御手段２ｂを含む。サービスプロファイル設定制御手段２ａは、通信端末６０の通信初期化設定時（位置登録時）に、サービス制御ＤＢ１０にアクセスし、サービスプロファイルを抽出する。
【００１７】
そして、通信端末６０が送受信するパケット経路上の各種ネットワーク機器にサービスプロファイルを設定する。ネットワーク機器としては、例えばフォーリンサーバ３０やホームエージェント４０が該当する。
【００１８】
サービスプロファイル再設定制御手段２ｂは、サービスプロファイル内の規制条件にもとづいてイベントを発生し、イベントの発生時に、サービス制御ＤＢ１０にアクセスして新たなサービスプロファイルを抽出する。そして、ネットワーク機器に新たなサービスプロファイルを動的に再設定する。なお、サービスプロファイルの設定制御については図２、図３で後述する。
【００１９】
一方、ホームサーバ２０は、ユーザ認証に関するイベント、ネットワーク資源の使用認可に関するイベント及び課金に関するイベントの少なくとも１つのイベントを自律的に発生し、これらイベントの発生時にサービスプロファイルの設定制御を行う。
【００２０】
フォーリンサーバ３０は、通信端末６０の加入契約先ドメインとは異なるドメインに配置されて、フォーリンエージェント５０を介して通信端末６０を収容し、ドメイン内のネットワーク機器（フォーリンエージェント５０）にサービスプロファイルを回送する。
【００２１】
ホームエージェント４０は、通信端末６０と通信する相手端末７０を収容し、通信端末６０の位置を管理する。また、通信端末６０に対するパケット送出の中継制御を行って、サービスプロファイルを更新する。
【００２２】
フォーリンエージェント５０は、通信端末６０を収容し、通信端末６０に対するパケット送出の中継制御を行い、サービスプロファイルを更新する。
ネットワーク制御機構部８０は、ＩＰネットワーク９０の監視及び管理を行い、ネットワーク制御機構部８０内部で発生したイベントをホームサーバ２０へ通知する。
【００２３】
なお、ホームサーバ２０は、上記で説明した自律的に発生するイベントによるサービスプロファイルの設定制御だけでなく、ネットワーク制御機構部８０で発生したイベントに関してのサービスプロファイルの設定制御も行う。
【００２４】
次にサービスプロファイルの設定制御について図２、図３を用いて説明する。図２はサービスプロファイルの設定を説明するための図である。図は、通信端末６０の位置登録時のサービスプロファイルの設定を示している。なお、ネットワーク制御機構部８０は図中省略する。
【００２５】
また、以降の説明では、ホームサーバ２０はＡＡＡＨ（Authentication Authorization Accounting Home) ２０、ホームエージェント４０はＨＡ（Home Agent) ４０、フォーリンサーバ３０はＡＡＡＦ（Authentication Authorization Accounting Foreign)３０、フォーリンエージェント５０はＦＡ（Foreign Agent)５０、通信端末６０はＭＮ（Mobile Node)６０、相手端末７０はＣＮ（Correspondent Node) ７０と呼ぶ。
【００２６】
図のようなシステムに対し、サービス制御ＤＢ１０には、２３：００〜０１：００の時間帯をクラス１の通信、その他の時間帯をベストエフォート（Best Effort)の通信と規定されたサービスプロファイル１０ａが格納されている。なお、これらの時間帯の条件が規制条件となる。
〔Ｓ１〕ＭＮ６０は、ＣＮ７０と通信を行う場合の通信開始時に位置登録要求を行う。このアクセス開始時刻を２０：３０とする。
〔Ｓ２〕位置登録要求は、ＦＡ５０からＡＡＡＦ３０へ、ＡＡＡＦ３０からＡＡＡＨ２０へ送信される。
〔Ｓ３〕ＡＡＡＨ２０は、位置登録要求を受信すると、規制条件が時刻なので、時刻イベントの設定を行う。
〔Ｓ４〕ＡＡＡＨ２０は、サービス制御ＤＢ１０へアクセスし、サービスプロファイル１０ａを抽出する。
〔Ｓ５〕ＡＡＡＨ２０は、現在は２３：００〜０１：００以外の時刻なので、ベストエフォートのサービスプロファイルの設定をＡＡＡＦ３０とＨＡ４０に送信する。
〔Ｓ６〕ＡＡＡＦ３０は、ベストエフォートのサービスプロファイルの設定をＦＡ５０へ回送する。
【００２７】
このようにして、ＦＡ５０及びＨＡ４０にベストエフォートが設定される。したがって、ＭＮ６０とＣＮ７０は、ＩＰネットワーク９０を介して、ベストエフォート型のサービスを利用して通信を行うことができる。
【００２８】
図３はサービスプロファイルの設定を説明するための図である。図は、サービスの規制条件が変更した場合のサービスプロファイルの再設定を示している。
〔Ｓ１０〕ＭＮ６０とＣＮ７０との通信が継続し、時刻が２３：００になると、ＡＡＡＨ２０は自律的に時刻イベントを発生する。
〔Ｓ１１〕ＡＡＡＨ２０は、イベントが発生すると、サービス制御ＤＢ１０へアクセスし、サービスプロファイル１０ａを抽出する。
〔Ｓ１２〕ＡＡＡＨ２０は、時刻が２３：００になったので、クラス１のサービスプロファイルの設定をＡＡＡＦ３０とＨＡ４０に送信する。
〔Ｓ１３〕ＡＡＡＦ３０は、クラス１のサービスプロファイルの設定をＦＡ５０へ回送する。
【００２９】
このようにして、ＦＡ５０及びＨＡ４０にクラス１が設定される。したがって、ＭＮ６０とＣＮ７０は、ＩＰネットワーク９０を介して、クラス１型のサービスを利用して通信を行うことができる。
【００３０】
以上説明したように、本発明のネットワークシステム１は、端末の通信中にサービスが変更するような場合でも、サービスプロファイルを動的に再設定する構成とした。
【００３１】
従来では位置登録時に一度設定されたサービスプロファイルは、その後に変更しても、パケット経路上の各種ネットワーク機器に再設定することができなかったが、本発明では、サービスプロファイルの規制条件を満たせば位置登録以外の任意の時に、効率よくサービスプロファイルを再設定できるため、ユーザに対して高度なサービスを提供することが可能になる。
【００３２】
次にネットワークシステム１の詳細な構成及び動作について以降説明する。図４、図５はネットワークシステム１の機能ブロックを示す図である。サービス制御ＤＢ１０、ＡＡＡＨ２０、ＨＡ４０及びＨＴＴＰ−ＧＷ（Hyper Text Transfer Protocol-Graphics Windowing)２００は、ホームネットワークのサービスプロバイダ側に配置される。
【００３３】
また、ＡＡＡＦ３０、ＦＡ５０及びＭＮ６０は、外部ネットワークのアクセスプロバイダ側に配置され、ＣＮ７０はホームネットワークのサービスプロバイダ側に配置される。
【００３４】
ＡＡＡＨ２０は、パケット制御部２１、プロトコル制御部２２、認証制御部２３、認可制御部２４、課金制御部２５を含む。また、ＡＡＡＨ２０のサービスプロファイル設定制御手段２ａとサービスプロファイル再設定制御手段２ｂのそれぞれの機能は、上記の各構成要素で分散されて処理される。
【００３５】
ＡＡＡＦ３０は、パケット制御部３１、プロトコル制御部３２を含む。また、ＡＡＡＦ３０の、ＭＮ６０を収容する通信端末収容手段と、ネットワーク機器にサービスプロファイルを回送するサービスプロファイル回送手段のそれぞれの機能は、上記の各構成要素で分散されて処理される。
【００３６】
ＨＡ４０は、パケット制御部４１、プロトコル制御部４２、サービス制御部４３、ＭＩＰ (Mobile IP)制御部４４を含む。また、ＨＡ４０の、ＭＮ６０と通信するＣＮ７０を収容する相手端末収容手段と、ＭＮ６０の位置を管理し、ＭＮ６０に対するパケット送出の中継制御を行う中継制御手段と、サービスプロファイルを更新するサービスプロファイル更新手段のそれぞれの機能は、上記の各構成要素で分散されて処理される。
【００３７】
ＦＡ５０は、パケット制御部５１、プロトコル制御部５２、サービス制御部５３、ＭＩＰ制御部５４を含む。また、ＦＡ５０の、ＭＮ６０を収容する通信端末収容手段と、ＭＮ６０に対するパケット送出の中継制御を行う中継制御手段と、サービスプロファイルを更新するサービスプロファイル更新手段のそれぞれの機能は、上記の各構成要素で分散されて処理される。
【００３８】
ネットワーク制御機構部８０は、課金計測機構８１、ＮＭＳ（Network Management System)８２、サーバ監視機構８３、時間サーバ８４を含む。ＣＮ７０は、パケット制御部７１、プロトコル制御部７２、サービス制御部７３、ＭＩＰ制御部７４を含む。なお、上記の内部構成部の詳細動作の説明は後述する。
【００３９】
サービス制御ＤＢ１０は、サービスプロファイル格納手段（図示せず）とサービスプロファイル管理手段（図示せず）を含む。サービスプロファイル格納手段は、通信端末のサービス内容を規定し、カスタマイズ可能なサービスプロファイルを格納する。サービスプロファイル管理手段は、サービスプロファイルを管理する。
【００４０】
ＭＩＰは、ＲＦＣ２００２と将来の全ての拡張で規定されるMobile IP プロトコルである。ＡＡＡプロトコルは、ＡＡＡシステムが使用するプロトコルである。本発明の実施の形態では、現在ＩＥＴＦで検討中のDIAMETERプロトコルの使用を想定する。
【００４１】
ＡＡＡプロトコルは、認証、認可、課金、ポリシに関する情報を伝達できるあらゆるプロトコルで実装可能である。ＡＡＡは、Authentication（認証）、Authorization （認可）、Accounting（課金）を行うサーバ群のＩＥＴＦで用いられる名称である。本発明のＡＡＡは認証、認可、課金をそれぞれの制御ブロックが機能を担当する。
【００４２】
本発明で必要となる新たな情報の伝達には、DIAMETERプロトコルで定義されるＡＶＰ(Attribute Value Pair)と呼ばれる拡張可能な属性パラメータを用いる。拡張される属性は、サービス設定制御のポリシとそれに付随する情報である。また動的にサービスプロファイルを変更するための新メッセージを追加する。
【００４３】
ＤＢ検索プロトコルは、サービス制御ＤＢ１０を検索するためのプロトコルである。使用するプロトコルは、サービス制御ＤＢ１０を実装するＤＢの製品に依存し、ＬＤＡＰ（Light Directory Access Protocol ）が通常用いられる。
【００４４】
ＭＮ６０は、Mobile IP プロトコル機能を有する移動端末である。ＣＮ７０はＭＮ６０が通信を行う相手通信ノードである。
ＡＡＡＨ２０に対し、認証制御部２３は、ユーザのＮＡＩ（Network Access Identifier ）でサービス制御ＤＢ１０から認証情報を抽出し、ユーザの認証を行う。
【００４５】
課金制御部２５は、ユーザ毎の課金レコードを記録し、認可制御部２４からのイベント要求コマンドに従って、ユーザの課金レコードの監視を行い、条件を満たした時にイベントを発生し、認可制御部２４へ通知する。
【００４６】
認可制御部２４は、認証制御部２３でユーザの認証が成功した後、認証制御部２３により起動され、ユーザのサービスプロファイルをサービス制御ＤＢ１０から抽出する。また、認可制御部２４は、まず各サービスの制御ポリシを参照し、サービス使用可否を判定する。認可されたサービスについてネットワーク機器（ＦＡ５０、ＨＡ４０）に設定するサービスプロファイル（図６で詳細を示す）を生成する。
【００４７】
ポリシに何らかの条件が設定されていれば、条件に合わせてネットワーク制御機構部８０、または課金制御部２５へイベントの設定を行う。
なお、ＡＡＡＨ２０は、認証要求ユーザの加入者データを持つネットワークのＡＡＡであり、ＡＡＡＦ３０は、ユーザの加入者データを持たないネットワークのＡＡＡである。
【００４８】
ＦＡ５０は、ＲＦＣ２００２で定義される機能エンティティである。ＭＮ６０に割り付けられるホームアドレスを所有しないエージェントであり、自ノードのアドレスである気付アドレス(Care-of-Address) へカプセル化されて送出してきたパケットをデカプセル化し、ホームアドレスに対応したリンクレイヤアドレスへパケットを回送する。
【００４９】
ＨＡ４０は、ＲＦＣ２００２で定義される機能エンティティである。ＭＮ６０に割り付けられたホームアドレスを所有するエージェントであり、ＨＡ４０に回送されてきたＭＮ６０のホームアドレスを送信先とするパケットは、ホームアドレスに対応したＦＡ５０の気付アドレス(Care-of-Address) へカプセル化されて送出される。
【００５０】
ネットワーク制御機構部８０は、詳細を規定しないネットワークを制御するための機能群である。これらは既存あるいは今後新たに実現されるネットワーク監視や管理を行うための装置やソフトである。
【００５１】
代表的な主な機能は、データパケットを計測し料金を計算する課金計測機構８１、ネットワーク機器の設定やトラフィック監視を行うＮＭＳ(Network Management System) ８２、サーバの負荷状態を監視するサーバ監視機構８３、ネットワーク全体のクロックを統一する時間サーバ８４である。これらはＡＡＡＨ２０及びＩＰネットワーク９０とそれぞれの固有プロトコルで通信を行う。
【００５２】
固有プロトコルは、ＡＡＡＨ２０とネットワーク制御機構部８０間、ＩＰネットワーク９０とネットワーク制御機構部８０間で互いに通信を行うためのプロトコルである。固有プロトコルは例えば、SNMP, COPS, DIAMETER, RADIUS, NTP, Telnet, CL 等である。
【００５３】
ＨＴＴＰ−ＧＷ２００は、サービス制御ＤＢ１０をＩＳＰのオペレータまたはユーザが直接変更するためのアプリケーションインタフェースである。本発明ではＷｅｂベースを用いている。
【００５４】
次にサービスプロファイルについて説明する。図６はサービスプロファイルの一例を示す図である。サービスプロファイルは、プロファイル識別子１０−１、制御対象パケット情報１０−２、ルーティング／パケット編集情報１０−３、個別制御情報１０−４からなる。
【００５５】
プロファイル識別子１０−１は、サービスプロファイルをネットワークで一意に識別する値である。制御対象パケット情報１０−２は、受信したパケットを索引するためのフィルタ情報である。
【００５６】
ルーティング／パケット編集情報１０−３は、制御対象パケット情報１０−２にヒットしたパケットに対して適用されるＩＰヘッダの編集情報と、そのパケットの回送先とを示す情報である。個別制御情報１０−４は、制御対象パケット情報１０−２にヒットしたパケットが次に検索する個別制御テーブルである。
【００５７】
プロファイル識別子１０−１について、プロファイル識別子１０−１は、セッション識別子とプロファイル番号で構成される。セッション識別子は、セッションＩＤであり、プロファイル番号はセッション毎に一意につけられた値である。
【００５８】
プロファイル識別子１０−１は、各エンティティで共通の値を持ち、ユーザセッションに関係するサービスプロファイルの特定と、ユーザセッション内の固有サービスを識別するために用いる。セッションＩＤは、DIAMETERのセッションＩＤ−ＡＶＰで用いられるセッションＩＤを用いる。本発明では＜MNのNAI ＞＜３２ビット値＞＜オプション＞といったフォーマットを用いる。
【００５９】
制御対象パケット情報１０−２について、制御対象パケット情報１０−２は、送信元、受信先のＩＰアドレスとポート番号から構成される。任意の値はワイルドカード＊で示される。ワイルドカードはＩＰアドレスに部分的に使用することができる。この４つの値は論理積で検索され、全てが一致した時のみ、ヒットする。
【００６０】
例えば、ＩＰアドレスの設定例として、１７２．２７．１８０．＊、１７２．２７．＊．＊である。
ルーティング／パケット編集情報１０−３について、ルーティング／パケット編集情報１０−３は、カプセル化（暗号化）手法、転送先アドレス、ＴＯＳ（Type Of Service)、デカプセル指示から構成される。
【００６１】
カプセル化（暗号化）手法は、個別制御テーブルによらずにカプセル化する場合に、カプセル化の方法を指定する。
転送先アドレスは、個別制御テーブルによらずにパケットを転送する場合に、転送先アドレスを指定する。ＭＮ６０の気付アドレスへの転送は、移動性結合に従う。
【００６２】
ＴＯＳは、ＴＯＳフィールドに設定する値を指定する。この値が指定された場合は、制御対象パケット情報１０−２にヒットしたパケットのＩＰヘッダと、個別制御データで編集されたパケット（例えば、移動性結合参照によるカプセル化）の両方に適用される。
【００６３】
デカプセル指示は、制御対象パケット情報１０−２にヒットしたパケットがカプセル化されていた場合、デカプセル化するかどうかを指定する。デカプセル化は個別制御テーブルを検索する前に行われる。
【００６４】
個別制御情報１０−４について、個別制御情報１０−４は、次に索引する制御テーブルの種類を示すサービス制御種別と、そのテーブルでのリンク先を示す制御情報識別子とからなる。
【００６５】
個別制御テーブルは、サービスプロファイルキャッシュ、ＭＩＰ、固有制御データ（結合キャッシュ、移動性結合、訪問者リスト）、ルーティングテーブル、サービス固有制御データ（ANYCAST テーブル等）である。制御情報識別子は、それぞれの制御テーブルのエントリを識別する任意なＩＤ又はポインタである。
【００６６】
図７はサービスプロファイルキャッシュの構成を示す図であり、図８は検索ポリシ管理テーブルの一例を示す図である。
図７に示されるサービスプロファイルキャッシュ５０１は互いに独立であり、検索ポリシは、図８に示すような検索ポリシ管理テーブル５０２により管理される。検索ポリシ管理テーブル５０２の構成は実装依存であるが、固有サービスプロファイルから共通サービスプロファイルへと検索範囲が広くなるように設定される。
【００６７】
図９〜図１２は各エンティティのセッショントランザクションを示す図である。セッショントランザクションは、DIAMETERメッセージの送受と、サービスプロファイルとのリンクを維持するため、各エンティティで保持される。
【００６８】
図９はＦＡ５０のセッショントランザクション５１１、図１０はＡＡＡＦ３０のセッショントランザクション５１２、図１１はＡＡＡＨ２０のセッショントランザクション５１３、図１２はＨＡ４０のセッショントランザクション５１４を示している。  図１３は訪問者リストを示す図である。訪問者リスト５２０は、ＦＡ５０でＭＮ６０のＩＰアドレス（ホームアドレス）とリンクレイヤアドレスを関係付けるテーブルである。
【００６９】
図１４は移動性結合を示す図である。図の移動性結合テーブル５２１は、ＨＡ４０でＭＮ６０のＩＰアドレス（ホームアドレス）と現在ＭＮ６０が接続しているＦＡ５０のアドレス（気付アドレス）を関係付けるテーブルである。
【００７０】
ＭＮ６０宛てのパケットは、ＨＡ４０に回送され、このテーブルにしたがってＦＡ５０へカプセル化され送出される。本発明では、ＨＡ４０が、ＭＮ６０が現在通信中のＣＮ７０を特定するために、経路最適化を行ったＣＮ７０のＩＰアドレスを記録する領域を新たに持つ。本発明は、このような移動性結合の機能を持つために、シグナリング手順に依存しない。
【００７１】
図１５はサービス制御ＤＢ１０のエントリの構成例を示す図である。ユーザはＩＳＰとＳＬＡ(Service Level Agreement) を行う。ＳＬＡは様々であるが、例えば、図１６〜図１８のようなサービス品質テーブル５３１、課金方式テーブル５３２、規制方式テーブル５３３等が契約される。
【００７２】
次にＦＡ５０、ＨＡ４０、ＣＮ７０の機能ブロックについて説明する。図１９はＦＡ５０、ＨＡ４０、ＣＮ７０の機能ブロックを示す図である。
ＦＡ５０のパケット制御部５１と、ＨＡ４０のパケット制御部４１と、ＣＮ７０のパケット制御部７１とをパケット制御部１０１とする。ＦＡ５０のプロトコル制御部５２と、ＨＡ４０のプロトコル制御部４２と、ＣＮ７０のプロトコル制御部７２とをプロトコル制御部１０２とする。ＦＡ５０のサービス制御部５３と、ＨＡ４０のサービス制御部４３と、ＣＮ７０のサービス制御部７３とをサービス制御部１０３とする。
【００７３】
パケット制御部１０１はパケットのフィルタ機能を有し、パケットヘッダを判別してプロトコルとデータパケットの切り分け処理を行う。また、サービス制御部１０３の指示に従い、パケットの編集と回送処理を行う。
【００７４】
プロトコル制御部１０２は、Mobile IP とDIAMETERプロトコルの処理部分であり、プロトコルの規定に従い、必要な情報をＭＩＰ制御部１０４が所有するサービス個別制御データに設定する。また、DIAMETERセッションを管理するためのセッショントランザクション１０２ａを有し、サービスプロファイルが通知された場合は、サービスプロファイルキャッシュへサービスプロファイルを蓄積、変更する。
【００７５】
サービス制御部１０３は、サービスプロファイルの集合であるサービスプロファイルキャッシュ１０３ａと検索のポリシを示す検索ポリシ管理テーブル１０３ｂを有する。
【００７６】
ＭＩＰ制御部１０４は、ＭＩＰ固有制御データ１０４ａとして、Mobile IP を管理するための制御テーブルである訪問者リスト（ＦＡ５０が所有）、移動性結合（ＨＡ４０が所有）、結合キャッシュ（ＦＡ５０、ＨＡ４０が所有）、ルータ固有のパケット制御テーブルであるルーティングテーブルを有する。
【００７７】
次にＦＡ５０、ＨＡ４０、ＣＮ７０のサービスプロファイル変更処理について説明する。図２０はパケット制御部１０１の処理フローを示す図である。
〔Ｓ２０〕パケットを受信すると、パケットからＩＰヘッダ情報（図５６）を抽出する。
〔Ｓ２１〕ヘッダ情報の受信先アドレス及びポート番号からデータパケットかプロトコルパケットかを判定する。データパケットならステップＳ２２へ、プロトコルパケットならステップＳ２３へ行く。
〔Ｓ２２〕サービスプロファイルキャッシュを検索し、ヘッダ情報と一致したサービスプロファイルの情報に従い、パケットの編集とルーティング先の決定を行う。
〔Ｓ２３〕プロトコル制御部１０２へ処理を渡す。
〔Ｓ２４〕ネットワークへパケットを回送する。
【００７８】
図２１はプロトコル制御部１０２の処理フローを示す図である。
〔Ｓ３０〕ＵＤＰヘッダのポート番号を判定して、Mobile IP かDIAMETERの切り分けを行う。Mobile IP ならステップＳ３１へ、DIAMETERならステップＳ３３へ行く。
〔Ｓ３１〕ＭＩＰメッセージにサービスプロファイル拡張があるか判定する。あればステップＳ３２へ、なければステップＳ３６へ行く。
〔Ｓ３２〕サービス制御を登録で起動する。
〔Ｓ３３〕DIAMETERメッセージにサービスプロファイルＡＶＰがあるか判定する。あればステップＳ３４へ、なければステップＳ３５へ行く。
〔Ｓ３４〕サービス制御を登録で起動する。
〔Ｓ３５〕DIAMETERメッセージからＭＩＰメッセージを抽出する。
〔Ｓ３６〕ＭＩＰ制御を起動する。
〔Ｓ３７〕メッセージ編集を行う。
【００７９】
図２２、図２３はメッセージ編集の処理フローを示す図である。上記のステップＳ３７の詳細である。
〔Ｓ３７−１〕受信メッセージ種別を判定する。ＳＣＲ（サービス変更要求： Service Change Request ) 受信の時はステップＳ３７−２へ行き、その他はステップＳ３７−１０へ行く。
〔Ｓ３７−２〕処理エンティティを判定する。ＦＡ５０ならステップＳ３７−３へ、ＨＡ４０ならステップＳ３７−６へ行く。
〔Ｓ３７−３〕ＳＣＲメッセージに旧FA-NAI AVPが含まれるか判定する。含まれる場合はステップＳ３７−４へ行く、含まれない場合はステップＳ３７−５へ行く。
〔Ｓ３７−４〕旧ＦＡに送出する結合更新メッセージを編集する。結合更新には、ＳＣＲで通知されたサービスプロファイルを含める。
〔Ｓ３７−５〕ＳＣＲメッセージ送信元へ送出するＳＣＡ（サービス変更応答：：Service Change Answer ）メッセージを編集する。
〔Ｓ３７−６〕本発明のために拡張された移動性結合の結合更新送信ＣＮを調べ、ＩＰアドレスに0.0.0.0 以外が設定されているか判定する。設定される場合はステップＳ３７−７へ、そうでなければステップＳ３７−９へ行く。
〔Ｓ３７−７〕ＩＰアドレスが設定されていれば、ＣＮに送出する結合更新メッセージを編集する。結合更新には、ＳＣＲで通知されたサービスプロファイルを含める。
〔Ｓ３７−８〕セッショントランザクションのＳＣＲ要求フラグとＳＣＲ要求元アドレスを設定する。
〔Ｓ３７−９〕ＩＰアドレスが0.0.0.0 の場合、ＳＣＲメッセージ送信元へ送出するＳＣＡメッセージを編集する。
〔Ｓ３７−１０〕受信メッセージが結合承認ならステップＳ３７−１１へ、そうでなければステップＳ３７−１３へ行く。
〔Ｓ３７−１１〕セッショントランザクションのＳＣＲ要求フラグが設定されているか調べる。設定されている場合はステップＳ３７−１２へ、そうでなければ終了する。
〔Ｓ３７−１２〕セッショントランザクションに設定されたＳＣＲメッセージ送信元へ送出するＳＣＡメッセージを編集する。ＳＣＲ要求フラグとＳＣＲ要求元アドレスをクリアする。
〔Ｓ３７−１３〕後述の図２６に示す対応関係にしたがって、送信メッセージ種別を決定する。
【００８０】
図２４はサービス制御部１０３の処理フローを示す図である。
〔Ｓ４０〕サービスプロファイルキャッシュを入力されたプロファイル識別子で検索し、一致したサービスプロファイルを全て削除する。
〔Ｓ４１〕処理要求を判定し、削除要求なら処理を終了する。処理要求が登録の場合は、ステップＳ４２へ行く。
〔Ｓ４２〕サービスプロファイルキャッシュに新たに通知されたサービスプロファイルを追加する。
【００８１】
図２５はＭＩＰ制御部１０４の処理フローを示す図である。左側のフローチャートはメッセージ処理のフローであり、右側のフローチャートはメッセージ処理部分とは独立に動作する周期プログラムである管理テーブル監視のフローを示す。
〔Ｓ５０〕後述の図２７に示すエンティティと受信メッセージの対応関係にしたがって、該当する管理テーブルのエントリの内容を設定する。
〔Ｓ５１〕解放メッセージ（登録タイマ＝０の登録要求またはＳＦＲ（Session Free Request））ならステップＳ５２へ、解放メッセージでなければ終了する。〔Ｓ５２〕解放メッセージならサービス制御を削除で起動する。
〔Ｓ５３〕タイマ値が設定されたエントリを持つ管理テーブル（訪問者リスト、移動性結合、結合キャッシュ）を周期的に監視し、値を減算する。
〔Ｓ５４〕エントリが満了（タイマ値＝０）したか判定する。満了ならステップＳ５５へ、そうでなければステップＳ５３へ戻る。
〔Ｓ５５〕エントリが満了したならエントリのポインタやＩＤから対応するサービスプロファイルのプロファイル識別子を特定し、サービス制御を削除で起動する。
【００８２】
図２６はＦＡ５０、ＨＡ４０、ＣＮ７０の送信メッセージ決定テーブルを示す図である。テーブル６００は、上述のステップＳ３７−１３での送信メッセージ決定に用いるテーブルである。
【００８３】
図２７はメッセージ対応の管理テーブルを示す図である。テーブル６１０は、上述のステップＳ５０のエントリ内容を設定する際に用いるテーブルである。
次にＡＡＡＦ３０について説明する。図２８はＡＡＡＦ３０の機能ブロックを示す図である。ＡＡＡＦ３０はDIAMETERをサポートするためのパケット制御部３１とプロトコル制御部３２で構成されており、プロトコル制御部３２はDIAMETERセッションを管理するセッショントランザクション３２ａを有する。
【００８４】
図２９はＡＡＡＦ３０のパケット制御部３１の処理フローである。
〔Ｓ６０〕パケットを受信すると、パケットからＩＰヘッダ情報（図５６）を抽出し、DIAMETERプロトコルをプロトコル制御部３２へ通知する。
〔Ｓ６１〕受信したメッセージに従った、メッセージ回送処理を行う。
〔Ｓ６２〕ネットワークへパケットを回送する。
【００８５】
図３０、図３１はＡＡＡＦ３０のプロトコル制御部３２の処理フローである。
〔Ｓ７０〕受信メッセージ種別を判定する。ＳＣＲならステップＳ７１へ、ＳＣＡならステップＳ７５へ、その他ならステップＳ８２へ行く。
〔Ｓ７１〕メッセージのセッションＩＤが示すセッショントランザクションのＳＣＲ要求元アドレスに、メッセージの送信元ＩＰアドレスを設定する。
〔Ｓ７２〕セッショントランザクションのＨＡアドレスを参照し、ＡＡＡＦが割り付けたＨＡが存在するか調べる。存在する場合はステップＳ７３へ、存在しない場合（ＨＡアドレスが0.0.0.0 の場合）はステップＳ７６へ行く。
〔Ｓ７３〕割り付けたＨＡが存在する場合、セッショントランザクションの状態にＨＡ変更要求中を設定する。
〔Ｓ７４〕ＨＡに対して受信したＳＣＲメッセージを回送する。
〔Ｓ７５〕メッセージのセッションＩＤが示すセッショントランザクションの状態を調べる。ＨＡ変更要求中ならステップＳ７６へ、そうでなければステップＳ８０へ行く。
〔Ｓ７６〕セッショントランザクションの状態がＨＡ変更要求中なら、セッショントランザクションの旧ＦＡ−ＮＡＩを調べる。旧ＦＡ−ＮＡＩがあればステップＳ７７へ、なければステップＳ７８へ行く。
〔Ｓ７７〕ＳＣＲメッセージに旧FA-NAI AVPを追加する。
〔Ｓ７８〕セッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ７９〕セッショントランザクションの現FA-NAIからＦＡのＩＰアドレスを解決し、受信したＳＣＲメッセージを回送する。
〔Ｓ８０〕状態がＨＡ変更要求中でなければ、状態に処理待ち中を設定する。
〔Ｓ８１〕セッショントランザクションのＳＣＲ送信元アドレスに対してＳＣＡメッセージを編集して送出する。
〔Ｓ８２〕サービス変更要求メッセージ（ＳＣＲ、ＳＣＡ) 以外のDIAMETERメッセージの処理を行う。主なメッセージと処理を図３２に示す。この部分は本発明の主旨ではないため、詳細は省略する。
【００８６】
図３２はＡＡＡＦ３０での主なDIAMETERメッセージの処理を示す図である。テーブル６２０は、ステップＳ８２のメッセージ処理に用いられる。
次にＡＡＡＨ２０について説明する。図３３はＡＡＡＨ２０とネットワーク制御機構部８０の機能ブロックを示す図である。ＡＡＡＨ２０は、DIAMETERをサポートするパケット制御部２１とプロトコル制御部２２、サービス制御ＤＢ１０からユーザの認証情報を参照してユーザの正当性を検査する認証制御部２３、サービス制御ＤＢ１０からユーザのサービスプロファイルを参照し、ユーザのネットワーク資源の使用可否の判断とユーザに関するネットワークへの設定情報であるサービスプロファイルを生成する認可制御部２４、ユーザ毎の課金情報を管理する課金制御部２５から構成される。
【００８７】
認可制御部２４は、ユーザのサービスプロファイルに動的な変化要因（時刻、課金、ネットワークの負荷状態等）が設定されている場合は、外部のネットワーク制御機構部８０内のＮＭＳ（ネットワーク管理システム）８２、サーバ監視機構８３、時間サーバ８４等に適切なプロトコルを用いて、イベント送出条件を設定する。また、課金制御部２５へ課金イベントの設定を行う。
【００８８】
課金制御部２５は、認可制御部２４からの課金要求に従い、ユーザの課金レコードを通知する。または認可制御部２４に設定された課金イベントに従い、ユーザの課金レコードを監視し、設定された条件を満たした時に課金イベントを発生する。課金制御部２５は、必要ならネットワークの課金計測機構８１と連携をとり課金情報を収集する。
【００８９】
ネットワーク制御機構部８０は、ＡＡＡＨ２０に設定された条件に従って、それぞれの機能に応じた資源を監視し、条件を満たした時に、適切なプロトコルで通知する。
【００９０】
ネットワーク制御機構部８０のそれぞれの機能は、既存技術あるいは独自の実装で構成されるものであり、内部処理の詳細やそれに用いるプロトコルは本発明の主旨に直接関係しないため概略に触れるのみでとどめる。
【００９１】
また、ここで使用されるプロトコルは、パケット制御部２１とプロトコル制御部２２を介して認可制御部２４や課金制御部２５に通知されるが、図では簡略のため対応する制御部と直接メッセージ交換をしている。
【００９２】
サービス制御ＤＢ１０は、ユーザまたはＩＳＰのオペレータがデータを設定するためのＤＢ設定アプリケーション（例えばＷＥＢで設定が可能なＨＴＴＰ−ＧＷ２００）とリンクしている。
【００９３】
サービス制御ＤＢ１０は、一般的なＤＢの機能として多重同時アクセスによる矛盾の発生を防ぐため、ＤＢのロック機能を持つ。
次にＡＡＡＨ２０の処理手順についてフローチャートを用いて説明する。
図３４はＡＡＡＨ２０のパケット制御部２１の処理フローを示す図である。
〔Ｓ９０〕パケットを受信すると、パケットからＩＰヘッダ情報（図５６）を抽出し、DIAMETERプロトコルをプロトコル制御部２２へ通知する。
〔Ｓ９１〕受信したメッセージに従った、メッセージ回送処理を行う。
〔Ｓ９２〕ネットワークへパケットを回送する。
【００９４】
図３５、３６はＡＡＡＨ２０のプロトコル制御部２２の処理フローを示す図である。
〔Ｓ１００〕ＵＤＰポートを参照して、プロトコルを判定する。メッセージ送出要求ならステップＳ１１６へ、DIAMETERならステップＳ１０１へ、その他であればステップＳ１１７へ行く。
〔Ｓ１０１〕受信メッセージ種別を判断する。ＳＣＡならステップＳ１０７へ、その他であればステップＳ１０２へ行く。
〔Ｓ１０２〕セッションＩＤでセッショントランザクションを検索し、セッショントランザクションが有るか判断する。有ればステップＳ１０６へ、なければステップＳ１０３へ行く。
〔Ｓ１０３〕セッショントランザクションがなければ（すなわち、初回のＡＭＲ受信であれば）セッショントランザクションを生成する。
〔Ｓ１０４〕認証制御部２３を起動する。
〔Ｓ１０５〕認証制御部２３で決定されたメッセージの送出を行う（詳細後述）。
〔Ｓ１０６〕セッショントランザクションが有れば図３２に従って、受信メッセージに対応したDIAMETER処理を行う。
〔Ｓ１０７〕セッションＩＤでセッショントランザクションを索引し、状態がＨＡ変更要求中か調べる。変更要求中の場合はステップＳ１１２へ、そうでなければステップＳ１０８へ行く。
〔Ｓ１０８〕ＨＡ変更要求中でなければ、状態がＦＡ変更要求中２（最初の変更要求中をＦＡ変更要求中、次の変更要求中をＦＡ変更要求中２とする）か調べる。ＦＡ変更要求中２ならステップＳ１１０へ、そうでなければステップＳ１０９へ行く。
〔Ｓ１０９〕状態に処理待ち中を設定する。
〔Ｓ１１０〕ＦＡ変更要求中２ならセッショントランザクションに設定されている旧ＡＡＡＦ３０へＳＣＲメッセージを送出する。
〔Ｓ１１１〕セッショントランザクションにＦＡ変更要求中を設定する。
〔Ｓ１１２〕ＨＡ変更要求中なら、セッショントランザクションに位置登録時に設定された現ＡＡＡＦ３０を参照してＡＡＡＦ３０へＳＣＲを送出する。
〔Ｓ１１３〕セッショントランザクションの旧ＡＡＡＦ３０を調べ、旧ＡＡＡＦ３０が存在するか調べる。存在すればステップＳ１１５へ、存在しなければステップＳ１１４へ行く。
〔Ｓ１１４〕旧ＡＡＡＦ３０が存在しなければ、セッショントランザクションにＦＡ変更要求中を設定する。
〔Ｓ１１５〕旧ＡＡＡＦ３０が存在するなら、セッショントランザクションにＦＡ変更要求中２を設定する。
〔Ｓ１１６〕要求されたメッセージの送出を行う（詳細後述）。
〔Ｓ１１７〕課金プロトコルか判定する。課金プロトコルならステップＳ１１８へ、そうでなければステップＳ１１９へ行く。
〔Ｓ１１８〕課金プロトコルなら課金制御部２５を起動する。
〔Ｓ１１９〕課金プロトコル以外なら認可制御部２４を起動する。
【００９５】
図３７、図３８はメッセージ送出制御の詳細フローを示す図である。上述のステップＳ１０５のフローである。
〔Ｓ１０５−１〕処理要求を判定する。サービス変更要求ならステップＳ１０５−２へ、認証応答ならステップＳ１０５−１２、その他ならステップＳ１０５−１９へ行く。
〔Ｓ１０５−２〕ＳＣＲメッセージを編集する。
〔Ｓ１０５−３〕アドレスプロキシ変更要求か調べる。アドレスプロキシ変更要求ならステップＳ１０５−１０へ、そうでなければステップＳ１０５−４へ行く。
〔Ｓ１０５−４〕アドレスプロキシ変更要求でなければセッションＩＤでセッショントランザクションを索引し、セッショントランザクションのＨＡアドレスを調べる。ＡＡＡＨならステップＳ１０５−５へ、ＡＡＡＦならステップＳ１０５−６へ行く。
〔Ｓ１０５−５〕ＨＡアドレスが0.0.0.0 でなければ、ＨＡのＩＰアドレスへＳＣＲメッセージを送出する。
〔Ｓ１０５−６〕ＨＡアドレスが0.0.0.0 なら、セッショントランザクションのＨＡ割り当てＡＡＡＦを参照し、ＡＡＡＦのＩＰアドレスへＳＣＲメッセージを送出する。
〔Ｓ１０５−７〕ＨＡ管理ＡＡＡＦ＝現ＡＡＡＦと等しいか調べる。等しい場合はステップＳ１０５−８へ、そうでなければステップＳ１０５−９へ行く。
〔Ｓ１０５−８〕セッショントランザクションの状態にＦＡ変更要求中を設定しメッセージ送出処理を終了する。
〔Ｓ１０５−９〕セッショントランザクションの状態にＨＡ変更要求中を設定する。
〔Ｓ１０５−１０〕アドレスプロキシ変更要求ならアドレスプロキシにＳＣＲを送出する。
〔Ｓ１０５−１１〕セッショントランザクションの状態にアドレスプロキシ変更要求中を設定する。
〔Ｓ１０５−１２〕認証応答の結果を判定する。ＯＫならステップＳ１０５−１３へ、ＮＧならステップＳ１０５−１７へ行く。
〔Ｓ１０５−１３〕認証ＯＫならＨＡ割り付け管理元がＡＡＡＦかどうかを決定する（この決定はプロバイダのポリシにより判断される）。ＡＡＡＨならステップＳ１０５−１４へ、ＡＡＡＦならステップＳ１０５−１５へ行く。
〔Ｓ１０５−１４〕ＨＡ割り付け管理元がＡＡＡＨならＡＭＲメッセージで指定されたＨＡまたはＡＡＡＨが動的に割り付けたＨＡのＩＰアドレスへＨＡＲメッセージを送出する。
〔Ｓ１０５−１５〕ＨＡ割り付け管理元がＡＡＡＦならＡＭＲを送出したＡＡＡＦへＡＭＡメッセージを送出し、セッショントランザクションのＨＡ割り付けＡＡＡＦにこのＡＡＡＦのＩＰアドレスを設定する。
〔Ｓ１０５−１６〕セッショントランザクションの状態にＨＡ登録要求中を設定。
〔Ｓ１０５−１７〕認証ＮＧならＡＭＲ要求ＡＡＡＦに認証不可のコードを設定したＡＭＡを送出する。
〔Ｓ１０５−１８〕セッショントランザクションの状態に処理待ち中を設定する。
〔Ｓ１０５−１９〕要求された固有プロトコルの送出制御を行う。
【００９６】
図３９は認証制御部２３の処理フローを示す図である。
〔Ｓ１２０〕ユーザＮＡＩでサービス制御ＤＢ１０を検索する。
〔Ｓ１２１〕ＡＭＲメッセージ内のユーザ認証情報とＤＢから索引した認証情報を比較する。
〔Ｓ１２２〕認証情報が一致するか判定する。一致すればステップＳ１２３へ、一致しなければステップＳ１２６へ行く。
〔Ｓ１２３〕認証ＯＫなら認可制御部を起動する。
〔Ｓ１２４〕認可ＯＫか判定する。ＯＫならステップＳ１２５へ、ＮＧならステップＳ１２６へ行く。
〔Ｓ１２５〕認証応答に認証ＯＫを設定する。
〔Ｓ１２６〕認証失敗または認可ＮＧなら、認証応答に認証ＮＧを設定する。
【００９７】
図４０は認可制御部２４の処理フローを示す図である。
〔Ｓ１３０〕受信メッセージがＡＭＲメッセージであるか判断する。ＡＭＲメッセージならステップＳ１３１へ、その他の場合はステップＳ１３７へ行く。
〔Ｓ１３１〕ＡＭＲメッセージ内のユーザＮＡＩでサービス制御ＤＢ１０を検索する。
〔Ｓ１３２〕索引したユーザのサービス制御情報の規制条件等を判定し、ネットワーク資源やサービスの使用が認可されるか判定する。認可ＯＫならステップＳ１３３へ、ＮＧならステップＳ１３６へ行く。
〔Ｓ１３３〕ユーザのサービス制御情報より、ユーザのデータパケットを制御するためのサービスプロファイルを生成する。
〔Ｓ１３４〕サービス制御情報に時刻や課金等の動的な変更要因があれば、条件に応じて課金制御部またはネットワーク制御機構へ対応する固有プロトコルを用いてイベントを設定する。この部分の詳細は省略する。
〔Ｓ１３５〕サービス制御応答に認可ＯＫを設定する。
〔Ｓ１３６〕サービス制御応答に認可ＮＧを設定する。
〔Ｓ１３７〕イベント内に設定されたセッションＩＤ（もしくはイベント設定時に作成するプロトコルメッセージの識別番号とセッションＩＤの対応表よりセッションＩＤを求める）でセッショントランザクションを検索し、ユーザＮＡＩを抽出する。
〔Ｓ１３８〕ユーザＮＡＩでサービス制御ＤＢ検索する。
〔Ｓ１３９〕サービス制御ＤＢがロック（他者使用中）されているか判定する。ロックの場合はステップＳ１４０へ、そうでなければステップＳ１４２へ行く。〔Ｓ１４０〕受信したイベントを棄却する。
〔Ｓ１４１〕一定時間休止した後、再度ステップＳ１３８移行を繰り返す。
〔Ｓ１４２〕アクセス成功なら抽出したサービス制御情報よりユーザのデータパケットを制御するためのサービスプロファイルを生成する。サービスプロファイルの識別子のセッション番号は、イベントに設定されたセッションＩＤを設定する。
〔Ｓ１４３〕サービス制御情報に時刻や課金等の動的な変更要因があれば、条件に応じて課金制御部またはネットワーク制御機構へ対応する固有プロトコルを用いてイベントを設定する。
〔Ｓ１４４〕メッセージ送出要求にサービス変更要求を設定する。
【００９８】
図４１は課金制御部２５の処理フローを示す図である。左側のフローチャートは課金制御部２５の動作であり、右側のフローチャートは課金制御部内監視処理の動作である。この処理は周期処理であり、左側のフローとは独立に動作する。〔Ｓ１５０〕処理要求を判定する。処理要求が課金レポートならステップＳ１５１へ、その他ならステップＳ１５２へ行く。
〔Ｓ１５１〕ユーザの課金レコードに料金を加算する。
〔Ｓ１５２〕課金要求かどうか判定する。課金要求の場合はステップＳ１５３へ、そうでなければステップＳ１５５へ行く。
〔Ｓ１５３〕通知されたユーザＮＡＩで課金レコードを検索する。
〔Ｓ１５４〕課金応答に課金レコードの課金情報を設定する。
〔Ｓ１５５〕課金制御部２５内の監視テーブル（図４３）にイベント設定要求で通知されたＮＡＩ、セッションＩＤ、条件を設定する。
〔Ｓ１５６〕課金計測機構８１に条件に応じた精度のレポート送出条件を設定する。例えば、規制金額に対してまだ十分な余裕があればレポートの送出間隔はゆるやかで良いし、すでに規制金額に達する寸前であれば周期の短いレポートを必要とする。
〔Ｓ１５７〕監視テーブルのエントリに登録されたＮＡＩの課金レコードを索引する。
〔Ｓ１５８〕監視テーブルに設定された条件と課金レコードの情報を比較する。条件を満たさないならエントリへのポインタを更新し、ステップＳ１５７以降を繰り返す。条件を満たしているならステップＳ１５９へ行く。
〔Ｓ１５９〕監視テーブルに設定されたセッションＩＤを設定した課金イベントを発生する。
〔Ｓ１６０〕監視テーブルよりエントリを削除する。エントリへのポインタを更新し、ステップＳ１５７以降を繰り返す。
【００９９】
図４２はＡＡＡＨ２０での主なDIAMETERメッセージに対する処理概要を示す図である。テーブル７００はステップＳ１０６で用いるDIAMETERメッセージに対する処理概要を示している。図４３は監視テーブルを示す図である。監視テーブル７００は図４１で用いられるテーブルである。
【０１００】
次に本発明のネットワークシステム１の多様な接続形態におけるサービスプロファイルの設定制御について説明する。図４４はＡＡＡＨ２０がＨＡ４０割り当て時のＡＡＡＨ２０内部イベントによるサービスプロファイル変更処理を示す図である。
〔Ｓ２０１〕ＡＡＡＨ２０では、このユーザの位置登録手順時に設定したサービス実行条件を監視するイベントが、条件を満たしたために発生する。ＡＡＡＨ２０はイベントに設定されたセッションＩＤを元にユーザのセッショントランザクションを索引し、ＮＡＩを抽出してサービス制御ＤＢ１０を索引する。
【０１０１】
索引したサービス制御情報からユーザの新たなサービスプロファイルを生成する。プロファイル識別子のセッションＩＤはイベントで通知されたセッションＩＤを設定する。プロファイル番号は新たに付け直しても良いし、位置登録手順で作成されたプロファイル番号と対応するように付けても良い。また、セッショントランザクションに設定された情報からＨＡを管理しているかを調べる。
〔Ｓ２０２〕この想定ではＨＡ４０を管理しているので、ＨＡ４０に対して新サービスプロファイルを設定したＳＣＲを送出する。
〔Ｓ２０３〕ＨＡ４０はＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルと同じプロファイル識別子を持つサービスプロファイルをサービスキャッシュから削除し、新サービスプロファイルをサービスプロファイルキャッシュに設定する（置換方法はプロファイル識別子のセッションＩＤに対応するものを全て置換する方法もある）。
【０１０２】
ＨＡ４０はセッショントランザクションから移動性結合を索引し、経路最適化を実行したＣＮ７０が存在するか調べる。この想定ではこのようなＣＮ７０が存在しているとする（以下の例においても同様）。したがって、ＣＮ７０に対して新サービスプロファイルを設定した結合更新メッセージを送出する。
〔Ｓ２０４〕ＣＮ７０は結合更新を受信すると、結合更新に設定された新サービスプロファイルを旧サービスプロファイルと置換する。置換方法はＨＡ４０と同様である。ＣＮ７０は結合更新メッセージに対して、結合承認メッセージで応答する。
〔Ｓ２０５〕結合承認を受信したＨＡ４０はＳＣＲメッセージに対する応答としてＳＣＡメッセージをＳＣＲ要求元（ＡＡＡＨ２０) へ返す。
〔Ｓ２０６〕ＡＡＡＨ２０は、ＨＡ４０からＳＣＡを受信すると、セッショントランザクションの状態がＨＡ変更要求中か調べる、ＨＡ変更要求中であるので、セッショントランザクションの現ＡＡＡＦ３０に対して新サービスプロファイルを設定したＳＣＲを送出する。セッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２０７〕ＡＡＡＦ３０はＳＣＲを受信すると、セッションＩＤよりセッショントランザクションを索引し、セッショントランザクションに設定された情報からＨＡ４０を管理しているか調べる。この想定ではＨＡ４０を管理していないので、セッショントランザクションに設定されている現ＦＡ５０に対してＳＣＲメッセージを回送する。セッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２０８〕ＦＡ５０はＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルを旧サービスプロファイルと置換する置換方法はＨＡ４０と同様である。ＳＣＲメッセージに対する応答としてＳＣＡメッセージをＡＡＡＦ３０に返す。
〔Ｓ２０９〕ＳＣＡを受信したＡＡＡＦ３０は、状態がＦＡ変更要求中なのでＳＣＡメッセージをＳＣＲを要求したＡＡＡＨ２０へ回送する。ＳＣＡを受信したＡＡＡＨ２０は、今度は状態がＦＡ変更要求中なのでこのメッセージを無視する。
【０１０３】
図４５はＡＡＡＨ２０がＨＡ４０割り当て時にＭＮ６０が同一ＡＡＡＦ３０内の異なるＦＡ５０配下に移動した場合のＡＡＡＨ２０内部イベントによるサービスプロファイルの変更処理を示す図である。
〔Ｓ２１１〕ＡＡＡＨ２０ではこのユーザの位置登録手順時に設定したサービス実行条件を監視するイベントが条件を満たしたために発生する。ＡＡＡＨ２０はイベントに設定されたセッションＩＤを元にユーザのセッショントランザクションを索引し、ＮＡＩを抽出してサービス制御ＤＢを索引する。索引したサービス制御情報からユーザの新たなサービスプロファイルを生成する。プロファイル識別子のセッションＩＤはイベントで通知されたセッションＩＤを設定する。またセッショントランザクションに設定された情報からＨＡ４０を管理しているかを調べる。
〔Ｓ２１２〕この想定ではＨＡ４０を管理しているので、ＨＡ４０に対して新サービスプロファイルを設定したＳＣＲを送出する。
〔Ｓ２１３〕ＨＡ４０はＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルと同じプロファイル識別子を持つサービスプロファイルをサービスキャッシュから削除し、新サービスプロファイルをサービスプロファイルキャッシュに設定する。ＨＡ４０はセッショントランザクションから移動性結合を索引し、経路最適化を実行したＣＮ７０に対して新サービスプロファイルを設定した結合更新メッセージを送出する。
〔Ｓ２１４〕ＣＮ７０は、結合更新を受信すると、結合更新に設定された新サービスプロファイルを旧サービスプロファイルと置換する。ＣＮ７０は結合更新メッセージに対して、結合承認メッセージで応答する。
〔Ｓ２１５〕結合承認を受信したＨＡ４０はＳＣＲメッセージに対する応答としてＳＣＡメッセージをＳＣＲ要求元（ＡＡＡＨ２０) へ返す。
〔Ｓ２１６〕ＡＡＡＨ２０はＳＣＡを受信すると、セッショントランザクションの状態がＨＡ変更要求中か調べる。ＨＡ変更要求中であるので、セッショントランザクションの現ＡＡＡＦ３０に対して新サービスプロファイルを設定したＳＣＲを送出する。セッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２１７〕ＡＡＡＦ３０はＳＣＲを受信すると、セッションＩＤよりセッショントランザクションを索引し、セッショントランザクションに設定された情報からＨＡ４０を管理しているか調べる。この想定ではＨＡ４０を管理していないので、旧ＦＡ５０ａがセッショントランザクションに設定されているか調べる。
【０１０４】
この想定では旧ＦＡ５０ａが存在しているので、セッショントランザクションに設定されている新ＦＡ５０ｂに対して旧ＦＡ−ＮＡＩＡＶＰを付加したＳＣＲメッセージを回送する。セッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２１８〕ＦＡ５０ｂはＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルを旧サービスプロファイルと置換する。ＳＣＲに旧ＦＡ−ＮＡＩＡＶＰが含まれているので、旧ＦＡ−ＮＡＩＡＶＰより旧ＦＡのＩＰアドレスを求め旧ＦＡ５０ａにＳＣＲメッセージを回送する。
〔Ｓ２１９〕ＳＣＲメッセージに対する応答としてＳＣＡメッセージをＡＡＡＦ３０に返す。
〔Ｓ２２０〕ＳＣＡを受信したＡＡＡＦ３０は、状態がＦＡ変更要求中なのでＳＣＡメッセージをＳＣＲを要求したＡＡＡＨ２０へ回送する。ＳＣＡを受信したＡＡＡＨ２０は、今度は状態がＦＡ変更要求中なのでこのメッセージを無視する。
【０１０５】
図４６はＡＡＡＨ２０がＨＡ４０割り当て時にＭＮ６０が異なるＡＡＡＦ３０内のＦＡ５０配下に移動した場合のＡＡＡＨ２０内部イベントによるサービスプロファイル変更処理を示す図である。
【０１０６】
ユーザの移動端末がネットワークにアクセス後、位置登録手順でユーザのサービス制御情報が必要な経路に設定された後、ＣＮ７０と通信中に異なるＡＡＡＦ３０内のＦＡ配下に移動した時にこのユーザのサービス実行条件が変更したことを想定した場合のサービス制御情報の変更処理を述べる。
〔Ｓ２３１〕ＡＡＡＨ２０ではこのユーザの位置登録手順時に設定したサービス実行条件を監視するイベントが条件を満たしたために発生する。ＡＡＡＨ２０はイベントに設定されたセッションＩＤを元にユーザのセッショントランザクションを索引し、ＮＡＩを抽出してサービス制御ＤＢを索引する。
【０１０７】
索引したサービス制御情報からユーザの新たなサービスプロファイルを生成する。プロファイル識別子のセッションＩＤはイベントで通知されたセッションＩＤを設定する。またセッショントランザクションに設定された情報からＨＡ４０を管理しているかを調べる。
〔Ｓ２３２〕この想定ではＨＡ４０を管理しているので、ＨＡ４０に対して新サービスプロファイルを設定したＳＣＲを送出する。
〔Ｓ２３３〕ＨＡ４０はＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルと同じプロファイル識別子を持つサービスプロファイルをサービスキャッシュから削除し、新サービスプロファイルをサービスプロファイルキャッシュに設定する。ＨＡ４０はセッショントランザクションから移動性結合を索引し、経路最適化を実行したＣＮ７０に対して新サービスプロファイルを設定した結合更新メッセージを送出する。
〔Ｓ２３４〕ＣＮ７０は結合更新を受信すると、結合更新に設定された新サービスプロファイルを旧サービスプロファイルと置換する。ＣＮ７０は結合更新メッセージに対して、結合承認メッセージで応答する。
〔Ｓ２３５〕結合承認を受信したＨＡ４０はＳＣＲメッセージに対する応答としてＳＣＡメッセージをＳＣＲ要求元（ＡＡＡＨ２０）へ返す。
〔Ｓ２３６〕ＡＡＡＨ２０はＳＣＡを受信すると、セッショントランザクションの状態がＨＡ変更要求中か調べる、ＨＡ変更要求中であるので、セッショントランザクションの新ＡＡＡＦ３０ｂに対して新サービスプロファイルを設定したＳＣＲを送出する。この想定ではＡＡＡＦが変わっているので、セッショントランザクションの状態にＦＡ変更要求中２を設定する。
〔Ｓ２３７〕新ＡＡＡＦ３０ｂはＳＣＲを受信すると、セッションＩＤよりセッショントランザクションを索引し、セッショントランザクションに設定された情報からＨＡ４０を管理しているか調べる。
【０１０８】
この想定ではＨＡ４０を管理していないので、旧ＦＡ５０ａがセッショントランザクションに設定されているか調べる。この想定では旧ＦＡ５０ａはこのＡＡＡＦ配下に存在しないので、セッショントランザクションに設定されている新ＦＡ５０ｂに対してＳＣＲメッセージを回送する。セッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２３８〕新ＦＡ５０ｂはＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルを旧サービスプロファイルと置換する。ＳＣＲメッセージに対する応答としてＳＣＡメッセージを新ＡＡＡＦ３０ｂに返す。
〔Ｓ２３９〕ＳＣＡを受信した新ＡＡＡＦ３０ｂは、状態がＦＡ変更要求中なのでＳＣＡメッセージを、ＳＣＲを要求したＡＡＡＨ２０へ回送する。
〔Ｓ２４０〕ＳＣＡを受信したＡＡＡＨ２０は、状態がＦＡ変更要求中２なので旧ＡＡＡＦ３０ａに対して新ＡＡＡＦ３０ｂへ送出したのと同じＳＣＲを送出する。セッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２４１〕旧ＡＡＡＦ３０ａはＳＣＲを受信すると、セッションＩＤよりセッショントランザクションを索引し、セッショントランザクションに設定された情報からＨＡ４０を管理しているか調べる。
【０１０９】
この想定ではＨＡ４０を管理していないので、旧ＦＡ５０ａがセッショントランザクションに設定されているか調べる。この想定では旧ＦＡ５０ａはこのＡＡＡＦ配下に存在しないので、セッショントランザクションに設定されている現ＦＡ（新ＡＡＡＦから見た旧ＦＡ）に対してＳＣＲメッセージを回送する。セッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２４２〕ＦＡ（旧ＦＡ）５０ａはＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルを旧サービスプロファイルと置換する。ＳＣＲメッセージに対する応答としてＳＣＡメッセージをＡＡＡＦ３０に返す。
〔Ｓ２４３〕ＳＣＡを受信したＡＡＡＦ３０は、状態がＦＡ変更要求中なのでＳＣＡメッセージをＳＣＲを要求したＡＡＡＨ２０へ回送する。ＳＣＡを受信したＡＡＡＨ２０は、今度は状態がＦＡ変更要求中なのでこのメッセージを無視する。
【０１１０】
図４７はＡＡＡＦ３０がＨＡ４０割り当て時のＡＡＡＨ２０内部イベントによるサービスプロファイルの変更処理を示す図である。
ユーザの移動端末がネットワークにアクセス後、位置登録手順でユーザのサービス制御情報が必要な経路に設定された後、ＣＮ７０と通信中にこのユーザのサービス実行条件が変更したことを想定した場合のサービス制御情報の変更処理を述べる。
〔Ｓ２５１〕ＡＡＡＨ２０ではこのユーザの位置登録手順時に設定したサービス実行条件を監視するイベントが条件を満たしたために発生する。ＡＡＡＨ２０はイベントに設定されたセッションＩＤを元にユーザのセッショントランザクションを索引し、ＮＡＩを抽出してサービス制御ＤＢを索引する。
【０１１１】
索引したサービス制御情報からユーザの新たなサービスプロファイルを生成する。プロファイル識別子のセッションＩＤはイベントで通知されたセッションＩＤを設定する。セッショントランザクションに設定された情報からＨＡ４０を管理しているかを調べる。
〔Ｓ２５２〕この想定ではＡＡＡＦ３０がＨＡ４０を管理しているので、セッショントランザクションに設定されたＨＡ割り付けＡＡＡＦ３０に対して新サービスプロファイルを設定したＳＣＲを送出する。ＨＡ割り付けＡＡＡＦ３０は現ＡＡＡＦに等しいのでセッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２５３〕ＡＡＡＦ３０はＳＣＲを受信すると、セッションＩＤよりセッショントランザクションを索引し、セッショントランザクションに設定された情報からＨＡ４０を管理しているか調べる。
【０１１２】
この想定ではＨＡ４０を管理しているで、セッショントランザクションに設定されているＨＡ４０に対してＳＣＲメッセージを回送し、セッショントランザクションの状態にＨＡ変更要求中を設定する。
〔Ｓ２５４〕ＨＡ４０はＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルと同じプロファイル識別子を持つサービスプロファイルをサービスキャッシュから削除し、新サービスプロファイルをサービスプロファイルキャッシュに設定する。ＨＡ４０はセッショントランザクションから移動性結合を索引し、経路最適化を実行したＣＮ７０に対して新サービスプロファイルを設定した結合更新メッセージを送出する。
〔Ｓ２５５〕ＣＮ７０は結合更新を受信すると、結合更新に設定された新サービスプロファイルを旧サービスプロファイルと置換する。ＣＮ７０は結合更新メッセージに対して、結合承認メッセージで応答する。
〔Ｓ２５６〕結合承認を受信したＨＡ４０はＳＣＲメッセージに対する応答としてＳＣＡメッセージをＳＣＲ要求元（ＡＡＡＦ) へ返す。
〔Ｓ２５７〕ＡＡＡＦ３０はＳＣＡを受信すると、セッショントランザクションの状態がＨＡ変更要求中か調べる、ＨＡ変更要求中であるので、セッショントランザクションの現ＦＡに対して新サービスプロファイルを設定したＳＣＲを送出する。セッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２５８〕ＦＡ５０はＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルを旧サービスプロファイルと置換する。置換方法はＨＡ４０と同様である。ＳＣＲメッセージに対する応答としてＳＣＡメッセージをＡＡＡＦ３０に返す。
〔Ｓ２５９〕ＳＣＡを受信したＡＡＡＦ３０は、状態がＦＡ変更要求中なのでＳＣＡメッセージをＳＣＲを要求したＡＡＡＨ２０へ回送する。ＳＣＡを受信したＡＡＡＨ２０は、今度は状態がＦＡ変更要求中なのでこのメッセージを無視する。
【０１１３】
図４８はＡＡＡＦ３０がＨＡ４０割り当て時にＭＮ６０が同一ＡＡＡＦ３０内の異なるＦＡ配下に移動した場合のＡＡＡＨ２０内部イベントによるサービスプロファイルの変更処理を示す図である。
【０１１４】
ユーザの移動端末がネットワークにアクセス後、位置登録手順でユーザのサービス制御情報が必要な経路に設定された後、ＣＮ７０と通信中に同一ＡＡＡＦ内の異なるＦＡ配下に移動した時にこのユーザのサービス実行条件が変更したことを想定した場合のサービス制御情報の変更処理を述べる。
〔Ｓ２６１〕ＡＡＡＨ２０ではこのユーザの位置登録手順時に設定したサービス実行条件を監視するイベントが条件を満たしたために発生する。ＡＡＡＨ２０はイベントに設定されたセッションＩＤを元にユーザのセッショントランザクションを索引し、ＮＡＩを抽出してサービス制御ＤＢを索引する。索引したサービス制御情報からユーザの新たなサービスプロファイルを生成する。
【０１１５】
プロファイル識別子のセッションＩＤはイベントで通知されたセッションＩＤを設定する。セッショントランザクションに設定された情報からＨＡ４０を管理しているかを調べる。
〔Ｓ２６２〕この想定ではＡＡＡＦ３０がＨＡ４０を管理しているので、セッショントランザクションに設定されたＨＡ割り付けＡＡＡＦ３０に対して新サービスプロファイルを設定したＳＣＲを送出する。ＨＡ割り付けＡＡＡＦ３０は現ＡＡＡＦに等しいのでセッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２６３〕ＡＡＡＦ３０はＳＣＲを受信すると、セッションＩＤよりセッショントランザクションを索引し、セッショントランザクションに設定された情報からＨＡ４０を管理しているか調べる。
【０１１６】
この想定ではＨＡ４０を管理しているで、セッショントランザクションに設定されているＨＡ４０に対してＳＣＲメッセージを回送し、セッショントランザクションの状態にＨＡ変更要求中を設定する。
〔Ｓ２６４〕ＨＡ４０はＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルと同じプロファイル識別子を持つサービスプロファイルをサービスキャッシュから削除し、新サービスプロファイルをサービスプロファイルキャッシュに設定する。ＨＡ４０はセッショントランザクションから移動性結合を索引し、経路最適化を実行したＣＮ７０に対して新サービスプロファイルを設定した結合更新メッセージを送出する。
〔Ｓ２６５〕ＣＮ７０は結合更新を受信すると、結合更新に設定された新サービスプロファイルを旧サービスプロファイルと置換する。ＣＮ７０は結合更新メッセージに対して、結合承認メッセージで応答する。
〔Ｓ２６６〕結合承認を受信したＨＡ４０はＳＣＲメッセージに対する応答としてＳＣＡメッセージをＳＣＲ  要求元（ＡＡＡＦ３０) へ返す。
〔Ｓ２６７〕ＡＡＡＦ３０はＳＣＡを受信すると、セッショントランザクションの状態がＨＡ変更要求中か調べる、ＨＡ変更要求中であるので、旧ＦＡ５０ａがセッショントランザクションに設定されているか調べる。この想定では旧ＦＡ５０ａが存在しているので、セッショントランザクションに設定されている新ＦＡ５０ｂに対して旧ＦＡ−ＮＡＩＡＶＰを付加したＳＣＲメッセージを回送する。セッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２６８〕ＦＡ５０ａはＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルを旧サービスプロファイルと置換する。ＳＣＲに旧ＦＡ−ＮＡＩＡＶＰが含まれているので、旧ＦＡ−ＮＡＩＡＶＰより旧ＦＡのＩＰアドレスを求め旧ＦＡにＳＣＲメッセージを回送する。
〔Ｓ２６９〕ＳＣＲメッセージに対する応答としてＳＣＡメッセージをＡＡＡＦ３０に返す。
〔Ｓ２７０〕ＳＣＡを受信したＡＡＡＦ３０は、状態がＦＡ変更要求中なのでＳＣＡメッセージをＳＣＲを要求したＡＡＡＨ２０へ回送する。ＳＣＡを受信したＡＡＡＨ２０は、今度は状態がＦＡ変更要求中なのでこのメッセージを無視する。
【０１１７】
図４９はＡＡＡＦ３０がＨＡ４０割り当て時にＭＮ６０が異なるＡＡＡＦ３０内のＦＡ配下に移動した場合のＡＡＡＨ２０内部イベントによるサービスプロファイルの変更処理を示す図である。
【０１１８】
ユーザの移動端末がネットワークにアクセス後、位置登録手順でユーザのサービス制御情報が必要な経路に設定された後、ＣＮ７０と通信中に異なるＡＡＡＦ内のＦＡ配下に移動した時にこのユーザのサービス実行条件が変更したことを想定した場合のサービス制御情報の変更処理を述べる。
〔Ｓ２８１〕ＡＡＡＨ２０ではこのユーザの位置登録手順時に設定したサービス実行条件を監視するイベントが条件を満たしたために発生する。ＡＡＡＨ２０はイベントに設定されたセッションＩＤを元にユーザのセッショントランザクションを索引し、ＮＡＩを抽出してサービス制御ＤＢを索引する。
【０１１９】
索引したサービス制御情報からユーザの新たなサービスプロファイルを生成する。プロファイル識別子のセッションＩＤはイベントで通知されたセッションＩＤを設定する。またセッショントランザクションに設定された情報からＨＡ４０を管理しているかを調べる。
〔Ｓ２８２〕この想定ではＡＡＡＦ３０がＨＡ４０を管理しているので、セッショントランザクションに設定されたＨＡ割り付けＡＡＡＦ３０に対して新サービスプロファイルを設定したＳＣＲを送出する。ＨＡ割り付けＡＡＡＦ３０は現ＡＡＡＦに等しくないのでセッショントランザクションの状態にＨＡ変更要求中を設定する。
〔Ｓ２８３〕ＡＡＡＦ（旧ＡＡＡＦ）３０ａはＳＣＲを受信すると、セッションＩＤよりセッショントランザクションを索引し、セッショントランザクションに設定された情報からＨＡ４０を管理しているか調べる。この想定ではＨＡ４０を管理しているで、セッショントランザクションに設定されているＨＡ４０に対してＳＣＲメッセージを回送し、セッショントランザクションの状態にＨＡ変更要求中を設定する。
〔Ｓ２８４〕ＨＡ４０はＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルと同じプロファイル識別子を持つサービスプロファイルをサービスキャッシュから削除し、新サービスプロファイルをサービスプロファイルキャッシュに設定する。ＨＡ４０はセッショントランザクションから移動性結合を索引し、経路最適化を実行したＣＮ７０に対して新サービスプロファイルを設定した結合更新メッセージを送出する。
〔Ｓ２８５〕ＣＮ７０は結合更新を受信すると、結合更新に設定された新サービスプロファイルを旧サービスプロファイルと置換する。ＣＮ７０は結合更新メッセージに対して、結合承認メッセージで応答する。
〔Ｓ２８６〕結合承認を受信したＨＡ４０はＳＣＲメッセージに対する応答としてＳＣＡメッセージをＳＣＲ要求元（旧ＡＡＡＦ３０ａ) へ返す。
〔Ｓ２８７〕ＡＡＡＦ（旧ＡＡＡＦ３０ａ）はＳＣＡを受信すると、セッショントランザクションの状態がＨＡ変更要求中か調べる、ＨＡ変更要求中であるので、旧ＦＡがセッショントランザクションに設定されているか調べる。この想定ではこのＡＡＡＦ配下に旧ＦＡ５０ａが存在しないので、セッショントランザクションに設定されている現ＦＡ５０ｂに対してＳＣＲメッセージを回送する。セッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２８８〕ＦＡ( 旧ＦＡ) ５０ａはＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルを旧サービスプロファイルと置換する。ＳＣＲメッセージに対する応答としてＳＣＡメッセージをＡＡＡＦ３０に返す。
〔Ｓ２８９〕ＳＣＡを受信したＡＡＡＦ（旧ＡＡＡＦ）３０ａは、状態がＦＡ変更要求中なのでＳＣＡメッセージを、ＳＣＲを要求したＡＡＡＨ２０へ回送する。
〔Ｓ２９０〕ＡＡＡＨ２０はＳＣＡを受信すると、セッショントランザクションの状態がＨＡ変更要求中か調べる、ＨＡ変更要求中であるので、セッショントランザクションの新ＡＡＡＦ３０ｂに対して新サービスプロファイルを設定したＳＣＲを送出する。セッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２９１〕ＡＡＡＦ（新ＡＡＡＦ）３０ｂはＳＣＲを受信すると、セッションＩＤよりセッショントランザクションを索引し、セッショントランザクションに設定された情報からＨＡ４０を管理しているか調べる。この想定ではＨＡ４０を管理していないので、セッショントランザクションに設定されている現ＦＡ（新ＦＡ）５０ｂに対してＳＣＲメッセージを回送する。セッショントランザクションの状態にＦＡ変更要求中を設定する。
〔Ｓ２９２〕新ＦＡ５０ｂはＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルを旧サービスプロファイルと置換する。ＳＣＲメッセージに対する応答としてＳＣＡメッセージを新ＡＡＡＦ３０ｂに返す。
〔Ｓ２９３〕ＳＣＡを受信した新ＡＡＡＦ３０ｂは、状態がＦＡ変更要求中なのでＳＣＡメッセージをＳＣＲを要求したＡＡＡＨ２０へ回送する。ＳＣＡを受信したＡＡＡＨ２０は、今度は状態がＦＡ変更要求中なのでこのメッセージを無視する。  次にアドレスプロキシサーバへのＡＡＡＨ２０内部イベントによるサービスプロファイル変更について説明する。
【０１２０】
図５０はアドレスプロキシサーバへのＡＡＡＨ２０内部イベントによるサービスプロファイル変更処理を示す図である。
ANYCAST サービス等の任意の仮想アドレスに対して複数の物理アドレスを対応づけるアドレス選択論理をもつアドレスプロキシサーバ３００に対して、ネットワークの何らかの要因によるアドレス選択論理の変更処理を述べる。
〔Ｓ３０１〕ＡＡＡＨ２０ではアドレスプロキシに対するアドレスの選択論理を変更するイベントがネットワークの、何らかの条件の変更のために発生する。ＡＡＡＨ２０はイベントに設定されたセッションＩＤを元にアドレスプロキシのセッショントランザクションとアドレス管理テーブル（アドレス選択ポリシを作成するためにＡＡＡＨ２０が管理している、仮想アドレス単位で保持しているオンライン端末の一覧）を索引し、該当する全ての端末のＮＡＩを抽出してサービス制御ＤＢを索引する。索引したサービス制御情報からアドレスプロキシに通知する新たなサービスプロファイルを生成する。プロファイル識別子のセッションＩＤはイベントで通知されたセッションＩＤを設定する。
〔Ｓ３０２〕セッショントランザクションに設定されたアドレスプロキシに対して新サービスプロファイルを設定したＳＣＲを送出する。セッショントランザクションの状態にアドレスプロキシ変更要求中を設定する。
〔Ｓ３０３〕アドレスプロキシサーバ３００は、ＳＣＲを受信すると、ＳＣＲに設定された新サービスプロファイルを旧サービスプロファイルと置換する。ＳＣＲメッセージに対する応答としてＳＣＡメッセージをＡＡＡＨ２０に返す。
【０１２１】
次にユーザによるサービス制御ＤＢの変更とＡＡＡＨ内部イベントの競合処理（競合防止処理手段）について説明する。ＭＮ６０がネットワークにアクセス後、位置登録手順でユーザのサービスプロファイルが必要な経路に設定された後、ユーザが何らかの手段（例えば、プロバイダが提供するＷｅｂサーバを通じて）でサービス制御ＤＢ１０の自分の契約条件を変更している時に、このユーザのサービス実行条件が変更したことを想定した場合のサービスプロファイルの変更処理について述べる。
【０１２２】
まず、ＡＡＡＨ２０では、このユーザの位置登録手順時に設定したサービス実行条件を監視するイベントが条件を満たしたために発生する。ＡＡＡＨ２０は、イベントに設定されたセッションＩＤを元にユーザのセッショントランザクションを索引し、ＮＡＩを抽出してサービス制御ＤＢ１０を索引する。
【０１２３】
この時、サービス制御ＤＢ１０は、ユーザのアクセスによりロックされているから、ＡＡＡＨ２０はサービス制御ＤＢ１０にアクセスできない。この場合、ＡＡＡＨ２０はイベントを棄却し、適当なインターバルをとった後、アクセスできるようになるまで、サービス制御ＤＢ１０へのアクセスを繰り返す。
【０１２４】
そして、アクセスが成功するとユーザの新たなサービスプロファイルを生成し、イベントを再設定する。上記に述べたユーザの通信状況に応じて、適切な配布方式でサービスプロファイルの更新を行う。
【０１２５】
以上説明したように、本発明の競合防止処理手段は、サービス制御ＤＢ１０内のサービスプロファイルの変更処理と、ＡＡＡＨ２０でのイベント発生と、の競合処理を防止する構成とした。これにより、競合がなくなるので、ユーザが自由にサービスプロファイルの設定変更等を行うことが可能になる。
【０１２６】
次に通信中にサービス条件が動的に変更されるようなサービスとして、時間によってクラスが変更する場合を例として以下説明する。図５１はサービスプロファイルを示す図である。DIff-Serv を例にアクセス時間帯によりサービスクラスを変更するようなサービスを考える。今、あるユーザが22:00 〜24:00 にかけて通信を行った場合を考える。
【０１２７】
このユーザのDiff-Serv サービスプロファイルは、図５１に示す様に上りは無条件にクラスＣ、下りは08:00 〜23:00 まではクラスＣ、23:00 〜08:00 の間はクラスＢを適用するようなポリシが設定されている。
【０１２８】
ユーザがネットワークにアクセス時、認可制御部２４は現時刻（22:00 ）を参照し、上り、下り共にサービスクラスＣに対応したＴＯＳ値を設定したサービスプロファイルをネットワークに設定する。
【０１２９】
認可制御部２４は、制限条件として時間が設定されているので、23:00 に時刻イベントが発生するように時間サーバへ設定を行う。
23:00 になると時間サーバ８４より認可制御部２４へ時刻イベントが通知されるので、認可制御部２４は上りがクラスＣ、下りがクラスＢに対応したＴＯＳ値を設定した新サービスプロファイルを生成する。以降、新サービスプロファイルがネットワークに再配布される。
【０１３０】
次に課金によるクラス変更のサービスプロファイルの設定制御について説明する。DIff-Serv を例に課金がある一定額を超えるとサービスクラスをグレードダウンするようなサービスを考える。この場合Diff-Serv のサービス個別プロファイルは図５２のようになる。
【０１３１】
今、１万円を境にクラスを変更するような契約をしているユーザが通信中に課金が１万円を超えた場合を考える。
このユーザのDiff-Serv サービスプロファイルは、図５２に示すように上りはクラスＣ、下りはクラスＢが無条件に適用されるようになっている。また課金が１万円を超えると下りにクラスＣを適用するようなポリシが設定されている。
【０１３２】
ユーザがネットワークにアクセス時、認可制御部２４は現在の課金総額を課金制御部２５に訪ねる。課金は１万円未満であったため上りにクラスＣ、下りにクラスＢに対応したＴＯＳ値を設定したサービスプロファイルをネットワークに設定する。
【０１３３】
認可制御部２４は、制限条件として課金が設定されているので、１万円を超えると課金イベントが発生するように課金制御部２５へ設定を行う。
課金総額が１万円になると課金制御部２５から課金イベントが通知されるので、認可制御部２４は、上りがクラスＣ、下りがクラスＣに対応したＴＯＳ値を設定した新サービスキャッシュを生成する。以降、新サービスプロファイルがネットワークに再配布される。
【０１３４】
次に時間による規制アドレス変更のサービスプロファイルの設定制御について説明する。この場合パケットフィルタリングのサービスプロファイルは図５３のようになる。今、あるユーザが20:00 〜22:00 にかけて通信を行った場合を考える。
【０１３５】
このユーザのパケットフィルタリングサービスプロファイルは、図５３に示すように08:00 〜21:00 まではIPアドレスXXX.XXX.＊. ＊に規制がかけられている。ユーザがネットワークにアクセス時、ＡＡＡＨ２０の認可制御部２４は現時刻（20:00 ）を参照し、規制アドレスを設定したサービスプロファイルをネットワークに設定する。認可制御部２４は、制限条件として時間が設定されているので、21:00 に時刻イベントが発生するように設定を行う。
【０１３６】
21:00 になるとＡＡＡＨ２０で時刻イベントが発生するので、ＡＡＡＨ２０は規制アドレスを解除した新サービスプロファイルを生成する。以降、新サービスプロファイルがネットワークに再配布される。
【０１３７】
次にＭＩＰメッセージ、DIAMETERメッセージ及びＩＰヘッダの構成について示す。図５４はＭＩＰメッセージを示す図である。Ｍ１はＭＩＰメッセージを示しており、ＩＰヘッダ、ＵＤＰヘッダ、ＭＩＰヘッダ、ＭＩＰの拡張エリアから構成される。
【０１３８】
図５５はDIAMETERメッセージを示す図である。Ｍ２はDIAMETERメッセージを示しており、ＩＰヘッダ、ＵＤＰヘッダ、DIAMETERヘッダ、DIAMETERのＡＶＰ群から構成される。
【０１３９】
図５６はＩＰヘッダを示す図である。図は、ＭＩＰメッセージＭ１とDIAMETERメッセージＭ２の先頭ヘッダであるＩＰヘッダを示している。
以上説明したように、本発明のネットワークシステムは、サービスプロファイル内の規制条件にもとづいてイベントを発生し、サービスプロファイルを動的に設定する構成とした。
【０１４０】
これにより、モバイルＩＰネットワークでＭＮの通信経路にのみ設定可能な、位置登録手順と独立なネットワーク主体のサービスプロファイルの設定が可能になる。
【０１４１】
また、本発明では競合防止処理手段を設けたので、ユーザのサービス契約内容のカスタマイズ処理との競合回避が可能になる。
【０１４２】
【発明の効果】
以上説明したように、本発明のネットワークシステムは、サービスプロファイル内の規制条件にもとづいてイベントを発生し、イベント発生時にサービスプロファイルを動的に設定する構成とした。これにより、通信中であっても動的にサービス変更ができるので、ユーザに高度なサービスを提供することが可能になる。
【図面の簡単な説明】
【図１】本発明のネットワークシステムの原理図である。
【図２】サービスプロファイルの設定を説明するための図である。
【図３】サービスプロファイルの設定を説明するための図である。
【図４】ネットワークシステムの機能ブロックを示す図である。
【図５】ネットワークシステムの機能ブロックを示す図である。
【図６】サービスプロファイルの一例を示す図である。
【図７】サービスプロファイルキャッシュの構成を示す図である。
【図８】検索ポリシ管理テーブルの一例を示す図である。
【図９】各エンティティのセッショントランザクションを示す図である。
【図１０】各エンティティのセッショントランザクションを示す図である。
【図１１】各エンティティのセッショントランザクションを示す図である。
【図１２】各エンティティのセッショントランザクションを示す図である。
【図１３】訪問者リストを示す図である。
【図１４】移動性結合を示す図である。
【図１５】サービス制御ＤＢのエントリの構成例を示す図である。
【図１６】サービス品質を示す図である。
【図１７】課金方式を示す図である。
【図１８】規制方式を示す図である。
【図１９】ＦＡ、ＨＡ、ＣＮの機能ブロックを示す図である。
【図２０】パケット制御部の処理フローを示す図である。
【図２１】プロトコル制御部の処理フローを示す図である。
【図２２】メッセージ編集の処理フローを示す図である。
【図２３】メッセージ編集の処理フローを示す図である。
【図２４】サービス制御部の処理フローを示す図である。
【図２５】ＭＩＰ制御部の処理フローを示す図である。
【図２６】ＦＡ、ＨＡ、ＣＮの送信メッセージ決定テーブルを示す図である。
【図２７】メッセージ対応の管理テーブルを示す図である。
【図２８】ＡＡＡＦの機能ブロックを示す図である。
【図２９】ＡＡＡＦのパケット制御部の処理フローを示す図である。
【図３０】ＡＡＡＦのプロトコル制御部の処理フローを示す図である。
【図３１】ＡＡＡＦのプロトコル制御部の処理フローを示す図である。
【図３２】ＡＡＡＦでの主なDIMETER メッセージの処理を示す図である。
【図３３】ＡＡＡＨとネットワーク制御機構部の機能ブロックを示す図である。
【図３４】ＡＡＡＨのパケット制御部の処理フローを示す図である。
【図３５】ＡＡＡＨのプロトコル制御部の処理フローを示す図である。
【図３６】ＡＡＡＨのプロトコル制御部の処理フローを示す図である。
【図３７】メッセージ送出制御の詳細フローを示す図である。
【図３８】メッセージ送出制御の詳細フローを示す図である。
【図３９】認証制御部の処理フローを示す図である。
【図４０】認可制御部の処理フローを示す図である。
【図４１】課金制御部の処理フローを示す図である。
【図４２】ＡＡＡＨでの主なDIAMETERメッセージに対する処理概要を示す図である。
【図４３】監視テーブルを示す図である。
【図４４】ＡＡＡＨがＨＡ割り当て時のＡＡＡＨ内部イベントによるサービスプロファイルの変更処理を示す図である。
【図４５】ＡＡＡＨがＨＡ割り当て時にＭＮが同一ＡＡＡＦ内の異なるＦＡ配下に移動した場合のＡＡＡＨ内部イベントによるサービスプロファイルの変更処理を示す図である。
【図４６】ＡＡＡＨがＨＡ割り当て時にＭＮが異なるＡＡＡＦ内のＦＡ配下に移動した場合のＡＡＡＨ内部イベントによるサービスプロファイルの変更処理を示す図である。
【図４７】ＡＡＡＦがＨＡ割り当て時のＡＡＡＨ内部イベントによるサービスプロファイルの変更処理を示す図である。
【図４８】ＡＡＡＦがＨＡ割り当て時にＭＮが同一ＡＡＡＦ内の異なるＦＡ配下に移動した場合のＡＡＡＨ内部イベントによるサービスプロファイルの変更処理を示す図である。
【図４９】ＡＡＡＦがＨＡ割り当て時にＭＮが異なるＡＡＡＦ内のＦＡ配下に移動した場合のＡＡＡＨ内部イベントによるサービスプロファイルの変更処理を示す図である。
【図５０】アドレスプロキシサーバへのＡＡＡＨ内部イベントによるサービスプロファイル変更処理を示す図である。
【図５１】サービスプロファイルを示す図である。
【図５２】サービスプロファイルを示す図である。
【図５３】サービスプロファイルを示す図である。
【図５４】ＭＩＰメッセージを示す図である。
【図５５】  DIAMETERメッセージを示す図である。
【図５６】ＩＰヘッダを示す図である。
【符号の説明】
１  ネットワークシステム
１０  サービス制御データベース
２０  ホームサーバ
２ａ  サービスプロファイル設定手段
２ｂ  サービスプロファイル再設定手段
３０  フォーリンサーバ
４０  ホームエージェント
５０  フォーリンエージェント
６０  通信端末
７０  相手端末
８０  ネットワーク制御機構部
９０  ＩＰネットワーク
【図１】
0004162347.tif 000002
【図２】
0004162347.tif 000003
【図３】
0004162347.tif 000004
【図４】
0004162347.tif 000005
【図５】
0004162347.tif 000006
【図６】
0004162347.tif 000007
【図７】
0004162347.tif 000008
【図８】
0004162347.tif 000009
【図９】
0004162347.tif 000010
【図１０】
0004162347.tif 000011
【図１１】
0004162347.tif 000012
【図１２】
0004162347.tif 000013
【図１３】
0004162347.tif 000014
【図１４】
0004162347.tif 000015
【図１５】
0004162347.tif 000016
【図１６】
0004162347.tif 000017
【図１７】
0004162347.tif 000018
【図１８】
0004162347.tif 000019
【図１９】
0004162347.tif 000020
【図２０】
0004162347.tif 000021
【図２１】
0004162347.tif 000022
【図２２】
0004162347.tif 000023
【図２３】
0004162347.tif 000024
【図２４】
0004162347.tif 000025
【図２５】
0004162347.tif 000026
【図２６】
0004162347.tif 000027
【図２７】
0004162347.tif 000028
【図２８】
0004162347.tif 000029
【図２９】
0004162347.tif 000030
【図３０】
0004162347.tif 000031
【図３１】
0004162347.tif 000032
【図３２】
0004162347.tif 000033
【図３３】
0004162347.tif 000034
【図３４】
0004162347.tif 000035
【図３５】
0004162347.tif 000036
【図３６】
0004162347.tif 000037
【図３７】
0004162347.tif 000038
【図３８】
0004162347.tif 000039
【図３９】
0004162347.tif 000040
【図４０】
0004162347.tif 000041
【図４１】
0004162347.tif 000042
【図４２】
0004162347.tif 000043
【図４３】
0004162347.tif 000044
【図４４】
0004162347.tif 000045
【図４５】
0004162347.tif 000046
【図４６】
0004162347.tif 000047
【図４７】
0004162347.tif 000048
【図４８】
0004162347.tif 000049
【図４９】
0004162347.tif 000050
【図５０】
0004162347.tif 000051
【図５１】
0004162347.tif 000052
【図５２】
0004162347.tif 000053
【図５３】
0004162347.tif 000054
【図５４】
0004162347.tif 000055
【図５５】
0004162347.tif 000056
【図５６】
0004162347.tif 000057