JP2010028622A

JP2010028622A - ネットワーク処理装置

Info

Publication number: JP2010028622A
Application number: JP2008189591A
Authority: JP
Inventors: Masatomo Ukeda; 賢知受田; Kazuhito Yaegashi; 一仁八重樫
Original assignee: Hitachi Kokusai Electric Inc
Current assignee: Hitachi Kokusai Electric Inc
Priority date: 2008-07-23
Filing date: 2008-07-23
Publication date: 2010-02-04
Anticipated expiration: 2028-07-23
Also published as: JP5213563B2

Abstract

【課題】WiMAXシステムにおいて、単一の事業者が自身のサービスのみを想定してシステムの構築を行う場合、NAPから接続されるNSPは一台だけとなることから、NSP選択手段は不要となる。しかし、システムでMVNO（Mobile Virtual Network Operator）を許可する場合、NSPは事業者毎に用意する必要があるため、NAPからのNSP選択手段が必要となるという問題があった。
【解決手段】MS、BS、ASN-GW、NSPからなる構成において、Network Entry時にASN-GWを選択する手段としてNSP IDまたはNAIを利用したASN-GWの選択を行う。そのために、ASN-GWとBSの間にWS(WiMAX Switch)を設置する。これにより、MS及びBSの仕様に影響を及ぼさずに、任意のNSPに関連づけられたGWを選択可能となる効果があり、また認証を要する処理と、それ以外の処理を分ける事により処理負荷が軽減する効果がある。
【選択図】図１

Description

本発明はネットワーク処理装置とネットワーク処理装置を利用するネットワーク構成に関する。

WiMAX（Worldwide Interoperability for Microwave Access）は中長距離向けの無線通信技術であり、IEEE( The Institute of Electrical and Electronic Engineers, Inc) 802.16作業部会及びWiMAX Forumで標準化が行われている技術規格である。WiMAXは最大10Kmまでの通信距離と、最大75Mbpsの通信速度を持ち、有線のケーブルを敷設することが困難な地域や、低価格の無線ブロードバンドサービス向け技術として期待されている。

WiMAXシステムは、主にMS（Mobile Station）、NAP（Network Access Provider）、NSP(Network Service Provider)から構成されている。
図８は本システムの構成モデルの一例を表している。ここで、MS８００は無線サービスを利用するユーザまたは機器のネットワーク接続装置であり、NAP８１０はMS８００に対して無線通信のためのインフラを提供する移動通信事業者の装置またはそのグループであり、NSP８２０及びNSP８３０は回線制御のほか、利用者の加入管理及びネットワークへの接続管理を行う事業者の装置またはそのグループである。

MS８００がNAP８１０への接続を開始すると、NAP８１０はMS８００から収集した情報を元にNSP８２０に、MS８００の接続可否を問い合わせる。このときNSP８２０はMS８００に対してサービス開始の許可を与えるための認証処理を行い、これにより接続を求めるMS８００が認可されればネットワークへの接続を許可し、課金処理を行う。この際の認証処理にはEAP（Extended Authentication Protocol）と呼ばれるプロトコルが用いられ、MS８００はEAPを通じてNSP８２０から要求された認証処理を行う。

またNAP８１０はBS（Base Station）８１２とASN-GW(Access Service Network - Gateway)８１３の組み合わせにより構成されても良く、両者を別の装置として分割し、１対多または多対多で接続することで、設置の自由度の向上が図れる。ASN-GW８１３は、BS８１２とNSP８２０をインターフェイスする機能を有したゲートウェイ装置であり、ルーティング機能の他に、MS８００のハンドオーバ管理機能やネットワークプロトコル変換機能、認証機能、接続認可機能、課金機能等、各種の機能を備えている。

WiMAXシステムにおいて、NAPを運用する単一の移動通信事業者が自身のサービスのみを想定してシステムの構築を行う場合、NAPから接続されるNSPは一台または一グループだけとなることから、NSP選択手段は不要である。しかし、移動通信サービスを提供するための無線局を自ら開設せず、無線設備を運用する他の移動通信事業者から借り受け利用することにより、独自の無線通信サービスを提供する事業者であるMVNO（Mobile Virtual Network Operator：仮想移動体通信事業者）をシステムにおいて許可する場合、NSPは事業者毎に用意する必要があり、NAPからのNSP選択手段が必要となる。

WiMAXシステムでは、MSからNSPを指定するための仕様を定義しており、その手段としてNSP Discoveryと呼ばれる手順を用いている。WiMAXシステムにおけるNSP Discoveryの手順は以下のとおりである。なお、非特許文献１ではNSP Discoveryに関する詳細が開示されている。
１. MSはNAPから送られてきたNAP IDの25bit目が0かどうかを調べる。0ならNAP＝NSPであるため、探索の必要はない。そうでない場合は、NAP≠NSPなのでNSPの探索を行う。
2. MSはSBC-REQ/RSPにより、NAPに対してNSPのリストを要求し、NAPからNSPのリストを獲得する。リストからのNSPの選択の方法は登録順序に応じて自動的に選択するものと、ユーザが手動で選ぶ場合の二種類がある。
3. 再び１及び２の手順を実行する。ただし、この時NAPへはNSPのリストを要求しない。
４. MSはNAPよりEAP Requestを受け取り、EAP ResponseのNAIまたはNSP IDを選択したNSPに変更してNAPに送信する。
5. NAPは受信したEAP ResponseのNAIまたはNSP IDを用いてNSPを選択する。
ここで述べた手順は接続先のNAPが目的のNSPへの接続をサポートしているかどうかを確かめるためのものであり、この手段を利用することで、MSからNSPの選択が可能になる。

しかし、WiMAXにおけるNAPの役割はMSとNSP間の処理を中継するだけではなく、MSとNAP間のデータの暗号化や、サービスの提供に応じた課金処理等も含まれる。このような処理を行うためには、NAPとNSP間で情報のやりとりをする必要があり、その情報は盗聴や改ざんから保護されている必要がある。これに対してWiMAXシステムではRADIUS（Remote Authentication Dial In User Service）プロトコルを利用することで、そのような問題から回線上のデータを保護している。しかし、RADIUSプロトコルをNAPとNSP間で接続するためには、お互いに秘密情報を共有しておく必要があり、NAPが全てのシステムで共有される構成である場合、NSPは自身の秘密情報を他のサービスに対して明示的に秘密にしておくことが難しくなる。また、VPN（Virtual Private Network）接続など、サービス毎に回線を論理的または物理的に分けたい場合にも、NAPがNSPに応じて複数に分割できれば、それらのシステム間の相関を少なくでき、セキュリティ及びメンテナンス性が向上する。

このとき、BSはサービスに依存しないと捉えると、NAPにおけるASN-GWのみを分割すればよいことになる。しかしNSP Discoveryを実行し、NSPの選択を行うためには、本来ASN-GWが実行するはずのEAP Request及びEAP Responseの処理を行う装置が必要になり、仕様に記載の方法だけではNSPに応じたASN-ＧＷの分割は困難であると考えられる。この問題の解決が、本発明における課題である。

WiMAX Forum Network Architecture Stage 3: Detailed Protocols and Procedures Release 1, Version 1.2 (January 11, 2008)

上記の課題を解決するため、本発明では末端装置がネットワークに接続する際に行う認証に用いられるデータを転送する機能を有するネットワーク処理装置が、論理的または物理的に複数存在する場合に、末端装置から送信される認証応答を用いてその選択を行う。そして、その選択を行うため、前記ネットワーク処理装置を第二のネットワーク処理装置として、当該第二のネットワーク処理装置と末端装置の間に以下の特徴を持つ第一のネットワーク処理装置を設置する。

（１）本発明の第一のネットワーク処理装置は、ネットワークへ接続するために利用する末端装置から、ネットワークに接続するための認証要求の送信要求を受信する前に、前記第二のネットワーク処理装置から送信される前記第二のネットワーク処理装置で共通した認証要求を受信し、前記末端装置から前記認証要求の送信要求を受信したときに、前記認証要求を前記末端装置に送信し、その後に発生する前記末端装置からの前記認証要求に対する認証応答を受信し、前記受信した認証応答を用いて前記第二のネットワーク処理装置を選択し、前記第二のネットワーク処理装置に受信した前記認証応答を転送する機能を有することを特徴とする。

（２）また、前記第二のネットワーク処理装置は、前記第二のネットワーク処理装置内で処理可能なセッション数または処理負荷に応じて前記第一のネットワーク処理装置へ、前記認証要求を送信する機能を有することを特徴とするものであってもよい。

（３）また、前記第二のネットワーク処理装置は、セッションの情報を管理する第一のテーブルを有し、前記第一のテーブルに前記認証要求を送信したことを表す情報及び前記認証応答を受信したことを表す情報を登録し、該登録した情報を参照及び変更及び削除する機能を有することを特徴とするものであってもよい。

（４）また、前記第一のネットワーク処理装置は、セッションの情報を管理する第二のテーブルを有し、前記第二のテーブルに前記認証要求を受信及び送信したことを表す情報と、前記認証応答を受信及び送信したことを表す情報を登録し、該登録した情報を参照及び変更及び削除する機能を有することを特徴とするものであってもよい。

（５）また、前記（４）の第一のネットワーク処理装置は、前記第二のネットワーク処理装置はWiMAXシステムにおけるASN-GWであり、前記認証要求がEAP Requestであり、前記認証応答が EAP Responseであることを特徴とするものであってもよい。

（６）また、前記（５）の第一のネットワーク処理装置は、前記第一のネットワーク処理装置がEAP Responseを受信した際に、EAP Responseに含まれるNSP IDまたはNAIの情報に基づき前記第二のネットワーク処理装置を選択する機能を有することを特徴とするものであってもよい。

（７）また、前記（６）の第一のネットワーク処理装置は、前記第一のネットワーク処理装置がMS_Preattachent_Ackを受信した際に、前記第二のテーブルを参照し、前記認証要求を受信したことを示す情報に基づきEAP Requestを送信する機能を有することを特徴とするものであってもよい。

（８）また、前記（４）の第一のネットワーク処理装置は、前記認証要求を受信した際に、前記認証要求自身を保持せずに受信したことを示す最少１ビットの認証要求受信情報のみを保持し、送信の際に共通の認証要求を送信し、前記認証要求受信情報を削除することを特徴とするものであってもよい。

（９）また、前記（４）の第一のネットワーク処理装置は、前記認証要求を受信した際に、前記認証要求自身を保持せずに受信したことを認証要求受信カウンタをカウントアップすることで保持し、送信の際に共通の認証要求を送信し、前記認証要求受信カウンタをカウントダウンすることを特徴とするものであってもよい。

（１０）また、前記第二のネットワーク処理装置は、自身の処理性能や処理負荷に応じて前記認証要求を前記第一のネットワーク処理装置に対してあらかじめ送信しておく個数を制御する機能を有することを特徴とするものであってもよい。

（１１）また、前記（４）の第一のネットワーク処理装置は、前記認証要求を受信した後に、一定時間の経過後に前記末端装置からの前記認証要求の送信要求がない場合または特定の通信量に達した場合に、エラーメッセージを含む前記認証要求を前記第二のネットワーク処理装置に返す機能を有することを特徴とするものであってもよい。

（１２）また、前記（４）の前記第一のネットワーク処理装置は、前記認証要求の受信がない状態で、前記末端装置より前記認証要求の送信要求を受け取った場合に、前記末端装置に対して共通な前記認証要求を前記末端装置に送信し、前記第二のネットワーク処理装置に対して前記認証要求の受信予約を行い、前記第二のネットワーク処理装置から前記認証要求を受信した場合に前記受信予約を削除する機能を有することを特徴とするものであってもよい。

上記のようにMSもしくはBS（末端装置に相当）とASN-GW（第二のネットワーク処理装置に相当）の間にASN-GW選択のための装置またはモジュールを設置することにより、MS及びBSの仕様に影響を及ぼさずに、任意のNSPに関連づけられたASN-GWを選択可能となる効果があり、また認証を要する処理と、それ以外の処理を分ける事により処理負荷が軽減する効果がある。

本発明における実施例では、MS、BS、ASN-GW、NSPからなるWiMAXシステムにおいて、MSがネットワーク接続を行うためのNetwork Entry時にASN-GWを選択する手段としてNSP IDまたはNAI(Network Access Identifier)を利用したASN-GWの選択を行う。そしてそのために、ASN-GWとBSの間にWS(WiMAX Switch)を設置する。以下、このシステムの動作を説明する。

図6はWSが挿入されたWiMAXシステムにおける第1の実施例の構成を表している。MS６１０及び６１２及び６１４はWiMAXシステムにおける末端の送受信装置であり、BSとの間で電波を送受信することで互いを認識してデータの送受信を行う。以下で単にMSとだけ表記している場合はWiMAXシステムにおけるMSの一般的特徴を表したものとする。この定義は他の記述においても同様である。MSには通信モジュールまたは通信カードまたはユーザ端末またはアクセスポイント等の装置またはモジュールが該当するが、同等の機能要件を満たすものであれば、この限りではない。MSはWiMAXの末端の装置として、ユーザが携帯する装置に組み込まれている場合や、車両または船舶または航空機等に設置されている場合には、移動体として取り扱っても良い。

ここで移動体とはMSがあるBSの電話到達範囲を超えて移動する場合や、電波の送受信に影響を及ぼす範囲で高速に移動する場合、周囲の構造物が動的に電波を遮断する可能性がある場合にも通信可能な仕組みを持つ装置及びシステムを指す。以下では特に断りがない限り、本発明への影響がないことから移動体であるかどうかの区別は行わない。

MSが移動体を含む装置である場合、WiMAXシステムはMSの接続及び再接続のために、MSを個別に識別する必要がある。そこでMSは固有のIDを持ち、IDに関連づけられた認証情報及び接続先のNSP及びASN-GW及びBSの識別情報及び構成情報の全部または一部を有していても良い。ここでMSに固有のIDは乱数的に生成されるデータでも良く、また個別に与えられた意味のあるデータであっても良い。意味のあるデータとは、電話番号またはMAC（Media Access Control）アドレスまたはURL(Uniform Resource Locator)、規格またはサービス毎のプロファイルで定められたバイト列であっても良く、この発明はIDの割り当て方には依存するものではない。またIDに関連づけられた識別情報とは、ユーザのパスワードまたは機器構成情報に基づくデータのハッシュ値、機器証明書、加入者情報を記載したSIMカード等の、正規にIDを与えられた装置のものであることを確認するための情報であり、同様の要件を満たせる情報であればこの限りではない。また接続先のNSP及びASN-GW及びBSの識別情報及び構成情報とは、NSP及びASN-GW及びBSのIDや、これらの装置の利用するアルゴリズムやパラメータセットを選択するための情報を指す。

BS６２０は、MS６１０及び６１２及び６１４とASN-GW６３０との通信を中継する装置であり、通常、MS６１０及び６１２及び６１４側とはWiMAXシステムにより定められた方式を用いた無線通信により接続され、ASN-GW６３０側との通信は、有線により接続された構成となる。WiMAXシステムでは、BSとASN-GWを併せてNAPと呼称しているが、ここでは便宜上BSとASN-GWを別の装置として記載している。しかし、本発明の主たる部分はASN-GW内部に関するものであるため、BSがASN-GWと同一装置でも別の装置であっても本発明の効果に影響を及ぼさない。すなわち、本発明におけるNSPに応じたGW選択処理は、BSの実装に影響を及ぼさず実現可能であるという効果がある。本発明におけるWSの機能をBSに持たせることも可能であるが、通常、一台のASN-GWに対して複数のBSが接続されることから、ASN-GW側に切り替え機能を集約できれば、システム構築のためのコストが安くなるという効果がある。

ASN-GW６３０はMS６１０及び６１２及び６１４の、WiMAXシステムにより提供されるネットワーク接続サービスへの参加可否を制御し、データ転送を制御し、ローミングなどのサービス間接続を制御し、課金処理のための情報の制御等を行う装置である。MSはネットワークに接続または再接続する際に、サービスへの参加が許可されているかどうかを認証されてもよい。その場合に、ASN-GWはMSが接続したいサービスに応じたNSPを選択し、そのNSPとMSとの間の認証処理を仲介するサービスを提供する。またサービスへの接続が認可された後に、必要ならばMSに対してIPアドレスを割り当てる処理の仲介も行う。

ASN-GWが単一のサービスにのみ利用される場合は、ASN-GWはNSPの選択を行う必要はないが、サービスがMVNOに対応し、利用者または端末が複数のサービスの中から一つを自動または手動で選択できる場合、ASN-GWはNSP選択の仕組みが必要になる。WIMAXシステムにおけるNSPの選択は、Network Entryにおける認証処理の最初のEAP Responseに含まれるNSP IDまたはNAIの情報に基づき選択することが可能である。

しかし、あるNSPと接続するためのASN-GWは、NSPに対応した秘密情報を保持する必要があるため、事業者によっては機密保持の観点から、ASN-GWを物理的または論理的に他のサービスのASN-GWから分離させたいと考えるかもしれない。この場合、既存の仕組みでは最初にEAP Requestを発行するASN-GWを選択する必要があるが、この段階ではASN-GWの選択に必要な情報を獲得できないため、どのASN-GWがEAP Requestを発行すべきかを決定することができない。このことによりASN-GWをサービス毎に物理的または論理的に分割することは困難であるという課題があった。

そこで本発明では課題を解決するために、ASN-GW６３０内に論理ASN-GW６４２及び６４４及び６４６を選択するための装置またはモジュールであるWS６５０を設置した構成をとる。WS６５０は論理ASN-GW６４２及び６４４及び６４６の機能の一部とテーブルに基づくデータの転送を行う装置である。また論理ASN-GW６４２及び６４４及び６４６は、NSP６６０及び６６２及び６６４に対応する論理ASN-GW６４２または６４４または６４６を表し、ここでは論理ASN-GW６４２はNSP６６０のためのGW装置であり、論理ASN-GW６４４はNSP６６２のためのGW装置であり、論理ASN-GW６４６はNSP６６４のためのGW装置である。

各論理ASN-GW６４２または６４４または６４６は、それぞれ一台のモジュールまたは装置またはCPUブレードまたはサーバであってもよく、また複数台のモジュールまたは装置またはCPUブレードまたはサーバであってもよい。また論理ASN-GW６４２または６４４または６４６の一つ以上が一台または複数台のモジュールまたは装置またはCPUブレードまたはサーバの任意の組み合わせを共有して利用する構成であっても良い。論理ASN-GW６４２または６４４または６４６がモジュールまたは装置またはCPUブレードまたはサーバを共有する方法としては、プロセス単位で分割されていても良いし、仮想マシン上にOSの単位で分割されていても良い。

WS６５０は、ASN-GW６３０へのデータの入出力において、データの種別または通信元及び通信先のIPアドレス及びポート番号に基づき、適したモジュールまたは装置にデータを転送する仕組みを有する装置であり、またWiMAXシステムにおいてASN-GW６３０の処理の一部を実現する機能を有する装置である。図6においては、WS６５０はBS６２０に接続されており、また論理ASN-GW６４２または６４４または６４６に接続されており、またNSP６６０及び６６２及び６６４に接続されており、またInternet６７０に接続されているものとする。ここでInternet６７０はWiMAXシステム外のネットワークの総称として用いている。すなわち、企業内ネットワークとして利用する場合は、社内ネットワーク網に相当し、携帯電話サービスとして利用する場合は、サービスの専用回線網に相当する。

ここでNSP６６０及び６６２及び６６４がネットワークに接続する際に特定のネットワークへの通信のみを許可したい場合、WS６５０に接続先の範囲を指定することで接続先を制限しても良い。このような機能を利用するサービスとしてVPN等がある。例えばNSP６６０の提供するネットワークに接続可能なMS６１０と、NSP６６２の提供するサービスに接続可能なMS６１２がある場合、同じASN-GWで認証された端末であっても、NSP６６０の提供するネットワークにはMS６１２は接続させず、NSP６６２の提供するネットワークにはMS６１０は接続させないようにしたい場合が相当する。図6の構成においてはWS６５０がASN-GW６３０へのデータの入出力を制御しているため、このような仮想的なネットワーク接続機能をWS６５０に持たせることができる。

このとき、WS６５０は、予め接続先を制限させるためのアドレス制限リストを保有しておいてもよい。アドレス制限リストは個々のMS６１０及び６１２及び６１４に応じて個別のリストが用意されていてもよいし、６１０及び６１２及び６１４で共通のリストが用意されていてもよい。また、共通リストとは別に、個別リストを有する構成であってもよい。

ここで共有リスト及び個別リストは、設定ファイルとして、装置の起動時よりファイルまたはデータベースとしてWS６５０が保有するものであってもよいし、ASN-GW６３０が接続された際に転送され保有されるものであってもよい。WS６５０はMS６１０及び６１２及び６１４からのデータ受信時に、これらのリストを利用することで、データをネットワークに送信するか否かを判断してもよい。このとき、WS６５０は、存在しないアドレス宛てのデータとみなし、受信したデータに対して応答を返さなくてもよい。上記の構成を採ることにより、論理ASN-GW６４２または６４４または６４６の負荷を分散させる効果がある。

また、このようなデータ転送が発生した場合にWS６５０がMS６１０または６１２または６１４のそれぞれのMSに応じた問い合わせを論理ASN-GW６４２または６４４または６４６に行う仕組みであってもよい。このとき、WS６５０は、MS６１０及び６１２及び６１４より送られてきたデータの通信先アドレスと、MS６１０及び６１２及び６１４のアドレスを含むデータを接続先である論理GW６４２または論理GW６４４または論理GW６４６に送信する。論理GW６４２または論理GW６４４または論理GW６４６はこのデータを受信すると、自身で保有する個別リスト及び共有リストを用いてデータをネットワークに送信することを許可されているかどうかを調べ、その結果をWS６５０に返してもよい。

個別リスト及び共有リストは、設定ファイルとして、装置の起動時よりファイルまたはデータベースとして論理GW６４２または論理GW６４４または論理GW６４６が保有するものであってもよいし、NSP６６０と接続した際に獲得するものであってもよい。獲得のタイミングは、初回接続時や定期的に更新される仕組みであってもよいし、MS６１０及びMS６１２及びMS６１４との認証が成功したときに合わせて送られてくるものであってもよい。WS６５０は、受け取った結果に応じて、データをネットワークに送信するか否かを判断してもよい。このとき、WS６５０は、存在しないアドレス宛てのデータとみなし、受信したデータに対して応答を返さなくてもよい。上記の構成においては、WS６５０内にテーブルを持つ必要がなくなることからメモリの削減の効果がある。

論理ASN-GW６４２または６４４または６４６はサービス毎に用意された論理的なASN-GWであり、MS６１０または６１２または６１４とNSP６６０または６６２または６６４の間の認証処理の仲介や、IPアドレスの割り当ての仲介等を行うモジュールまたは装置である。論理ASN-GW６４２または６４４または６４６の機能は通常のWiMAXシステムにおけるASN-GWと同等であるが、本発明におけるNSP選択の手続きと、データ転送、そのためのテーブル構成において差異がある。

図6の構成においては論理ASN-GW６４２または６４４または６４６は、NSP６６０または６６２または６６４またはInternet６７０への直接のデータ転送処理は行わないため、接続及び再接続のための認証処理に集中して処理を行えるようになるという効果がある。特に移動体が主となる利用方法においては、複数のMSが連続して再接続要求が発生させることが考えられ、この処理を遅延することなく行うためには高いピーク性能が必要になるが、これらの処理を一組の装置で行う場合、リソースの配分が課題となる。しかし、接続及び再接続のための認証処理を論理ASN-GW６４２または６４４または６４６が行い、データ転送処理をWS６５０が行うことで、処理効率が高まるという効果がある。

NSP６６０及び６６２及び６６４はサービス事業者の情報処理モジュールまたは装置またはサーバでありASN-GW６３０からの要求に基づいたMS６１０または６１２または６１４の認証や、認証結果に基づく暗号鍵やアドレスの配布、課金または登録処理を行う。

WiMAXシステムが図6のような構成である場合、ASN-GW６３０がMS６１０または６１２または６１４からのNSP選択のための情報に基づきWS６５０で論理ASN-GW６４２または６４４または６４６の選択を行うことができれば、サービスに応じてASN-GW６３０及び回線を仮想化し、分割することが可能になる。

図1は本発明を適用した場合の処理の流れを表している。WiMAXシステムでは、最初にMS１００とBS１１０の間でネゴシエーションを行い、MS１００はBS１１０の識別情報であるBS IDを獲得する。BS IDにはNSP IDが含まれており、MS１００はこの情報により接続先のネットワークを識別することが可能になる。しかし、そのネットワークが接続したいネットワークと異なる場合、MS１００はSBC-REQ１７２を利用してNSP IDのリストを要求することになる。NAP１２５が２つ以上のNSPをサポートしているかどうかは、BS IDの25bit目を見ることで判断できる。このビットが１である場合、NAP１２５が２つ以上のNSPをサポートしていると判断できる。また、SBC-REQ１７２がNSP IDのリストの要求を含んでいるかどうかは、SBC-REQ１７２にSIQ TLVが含まれており、かつそのビット０及びビット１が１にセットされているかどうかを調べることで判断可能である。

BS１１０はNSP IDのリストの要求を含んだSBC-REQ１７２を受け取ると、SII-ADVまたはSBC-RSP１７４を利用してNSP IDのリストを送る。MS１００はNSP IDのリストを受け取ると、再びNetwork Entryの処理をやり直し、今度はNSP IDのリストを要求しない手順で処理を行う。すなわちMS１００はBS１１０と再度ネゴシエーションを行い、NSP IDを獲得するが、その後、NSP IDリストの要求を行わないSBC-REQ１７６をBS１１０に送信する。

BS１１０はSBC-REQ１７６を受け取ると、データを確認し、SIQ TLVが含まれていないことを確認する。SIQ TLVが含まれていない場合、BS１１０は、ASN-GW１２０の構成情報を獲得するためにMS_PreAttchment_Req１７８をASN-GW１２０に送信する。

ASN-GW１２０はMS_PreAttchment_Req１７８を受け取ると、WS１３０にその内容を渡し、パケットの中身を調べる。このときWS１３０はあらかじめ用意しておいた構成情報をMS_PreAttachment_Rsp１８０に含めてBS１１０に送ることにしても良いし、過去の接続履歴などからMS IDに適したASN-GW１２０の構成情報を検索して送ることにしても良い。このときWS１３０はまだどの論理GWが利用されるかはわからないので、両方に共通の構成情報を送ることにしても良い。

BS１１０はWS１３０からASN-GW１２０の構成情報を受け取ると、SBC-RSP１８２にその情報を含めてMS１００に送信する。MS１００はSBC-RSP１８２を受け取ると、ASN-GW１２０からEAP Request１８６が発行されるのを待つ状態に遷移する。BS１１０はSBC-RSP１８２をMS１００に送信すると、ASN-GW１２０にMS_PreAttachment _Ack１８４を送信する。

ASN-GW１２０はMS_PreAttachment Ack １８４を受信すると、EAP Request１８６をBS１１０に送信する。BS１１０はEAP Request１８６を受け取ると、PKM-REQ１８８を利用してEAP Request１８６の情報をMS１００に送信する。MS１００はPKM-REQ１８８を受信すると、選択したNSP１５０に対応したNSP IDまたはNAIを含んだEAP Response１９２をPKM-RSP１９０を利用してBS１１０に送信する。

ＢＳ１１０はPKM-RSP１９０を受信すると、その中に含まれるEAP Response１９２をASN-GW１２０に送信する。ASN-GW１２０はEAP Response１９２を受け取ると、その中に含まれるNSPIDまたはNAIの値から適切なNSP１５０を選択して、EAP Response１９２の情報を含むデータをRADIUS Protocol１９５を利用してNSP１５０に送信する。

ここでRADIUS Protocolとは、RFC２８６５で規格化された、認証及び認可及び課金のためプロトコルである。RADIUS Protocolは、認証のためにEAPのような別のプロトコルを流すことが可能であり、図1のように受け取ったEAPパケットをNSP１５０のような別の装置で処理したい場合等に利用される。

NSP１５０は、RADIUS Protocol１９５によりEAP Response１９２を受け取ると、EAP Response１９２のMS IDやNAIの情報に基づき適切な認証のためのアルゴリズムを選択し、MS１００との認証を開始する（EAP Protocol １９６）。ここでEAP Protocol及びEAP Request及びEAP ResponseはRFC ３７４８で規格化された認証のためのプロトコルである。

EAP Protocol１９６を利用した認証に成功すると、RADIUS Protocol１９５はAccess AcceptパケットをASN-GW１２０に返す。Access Acceptパケットには処理完了の通知と、MSK（Master Session Key）、FA-RK Key等のWiMAXシステムで装置間の認証やデータの暗号化に必要となる鍵情報が含まれていてもよい。ASN-GW１２０は、MSKを受け取ると、MSKからAK(Authorization Key)を派生させ、Key_Change_Directive１９７を利用してAKをBS１１０に送信しても良い。

BS１１０はAKを受信すると、CMAC KEYを派生させてもよい。ここでMSKはEAP Protocol １９６のセッションの中でMS１００とNSP１５０で共有する情報を用いて作られるため、CMAC KEYはMS１００でも生成可能である。MS１００とBS１１０は、このCMAC KEYを利用してMS１００とBS１１０との間の通信を暗号化しても良い。このようにしてWiMAXシステムの無線部分のデータを保護することが可能なため、無線部分のデータの盗聴を困難にすることが可能となり、MS１００はInternet１６０上の装置とデータ通信１９８が可能になる。

ここで、ASN-GW１２０がNSPに対応した論理GWを持つ構成である場合、EAP Request送信において、論理GW１４０または１４５とBS１１０間の通信の仲介を行うWS１３０は、論理GW１４０または論理GW１４５にEAP Requestの送信を要求して、受け取ったEAP Request１４２または１４７をBS１１０に送信することになる。しかし、この段階ではMS１００からはどのNSPを利用するかの通知を受け取っていないため、WS１３０はどの論理GWを利用して処理を開始するべきかを判断できない。

そこで本発明では、論理GW１４０及び１４５はあらかじめWS１３０に対してEAP Request１４２及び１４７を送信しておくことにする。WS１３０は論理GW１４０及び１４５からEAP Requestを受信したことを記録及び管理することで論理GW１４０及び１４５のリソース管理を行うと共に、EAP Request１８６を送信した後に受け取ったEAP Response１９２に含まれるNSP IDまたはNAIの値を判断することで、論理GW１４０及び１４５の選択が可能になる。

EAP Requestの発行による認証処理の開始は通常ASN-GWが行うが、WS１３０に複数の論理GWが接続されている場合、WS１３０はどの論理GWからEAP-Requestの発行を受けるべきか判断する必要がある。しかし、予め EAP Requestを受け取っておけばこの判断をWS１３０行う必要がなくなる。すなわち、論理GWからEAP Requestを受け取ったことが、論理GW側にEAP処理を行うためのリソースが存在し、EAP Requestを受付け可能であることを示す指標となるためである。

ただし、論理GWから受け取ったEAP Requestがそれぞれで異なる情報を含んでいれば、やはりWS１３０側で、どの論理GWからのEAP RequestをBSに送信するべきかの判断が必要となってしまう。そこで、本発明における論理GWは、最初のEAP RequestのIDを固定値にすることで、全てのEAP Requestが同じ値になるようにする。最初のEAP Requestは処理の開始を通知するだけのパケットであり、論理GWに固有の情報を含まず、ある一台のMS１００に対して同じ論理GWから同時にEAP処理が発生しないため、最初のEAP Request のIDを固定値にしても問題はない。

このことにより、WS１３０は論理GWの種別によらずEAP Requestを送信することが可能となり、また共通の情報の受信及び未受信を管理するだけでよいため、複数の論理GWから複数のEAP Requestを一度に受け取っても、それぞれのEAP Requestに対して１ビットの管理領域を用意しておくだけでよく、EAP Requestをキャッシュするメモリを大幅に削減する効果がある。

図4はWS１３０が持つ管理テーブルの一例を表している。WS１３０は、WS共通パラメータテーブル４００と、論理GW共通パラメータテーブル４２０及び４２５及び４３０と、論理GW個別パラメータテーブル４５０及び４５５及び４６０を有していてもよい。

WS共通パラメータテーブル４００は、エントリ４９６を管理するためのハンドル（Handle ４０２）と、サポートしているNSPのリスト（NSP ID List ４０４）、BS側からアクセスする際のIPアドレス（BS側Address４０６）、BSとの接続に利用可能なポートのリスト（BS側Port List ４０８）、GWからアクセスする際のIPアドレス（GW側Address４１０）、GWとの接続に利用可能なポートのリスト（GW側Port List ４１２）、WAN側からアクセスする際のIPアドレス（WAN側Address４１４）、WAN側との接続に利用可能なポートのリスト（WAN側Port List ４１６）等を含んでもよい。

また論理GW共通パラメータテーブル４２０及び４２５及び４３０は、同じNSP IDを持つ論理GWが複数ある場合の、NSP IDを共有する論理GWのための共通パラメータのテーブルである。論理GW共通パラメータテーブル４２０及び４２５及び４３０は、エントリ４９４を管理するためのハンドル（Handle４３２）と、関連するNSPのID（NSP ID ４３４）と、このテーブルを共有する論理GWのIPアドレスのリスト（論理GW List ４３６）と、接続先NSPのIPアドレス（NSP Address ４３８）と、接続先NSPのPort番号（NSP Port Number ４４０）と、あるNSPに属する論理GWがどれだけの発行済みEAP Requestを有しているかを判断するためのカウンタのリスト(EAP CountList ４４２)等を含んでいてもよい。

また論理GW個別パラメータテーブル４５０及び４５５及び４６０は、各論理GW内で扱うセッションを管理するためのテーブルである。論理GW個別パラメータテーブル４５０及び４５５及び４６０は、各エントリ４９０及び４９２を管理するためのハンドル（Handle４６２）と、各セッションでBSと通信する場合のBS側Port番号（BS側Port Number ４６４）と、各セッションで論理GWと通信する場合のGW側Port番号（GW側Port Number ４６６）と、各セッションでWAN側と通信する場合のWAN側Port番号（WAN側Port Number ４６８）と、BSまたはGWまたはWAN側の通信元IP Address（通信元IPアドレス４７０）と、BSまたはGWまたはWAN側の通信元ポート番号（通信元Port Number４７２）と、BSまたはGWまたはWAN側の通信先IP Address（通信先IPアドレス４７４）と、BSまたはGWまたはWAN側の通信先ポート番号（通信先Port Number ４７６）と、通信におけるセッションの状態を登録するためのフラグ（Session Flag ４７８）と、接続先のMSのID（MS ID ４８０）、EAP Requestの受信フラグ（EAP Flag ４８２）等を含んでいてもよい。

ここで各テーブルの個数及びエントリの個数は説明のために便宜的に用意したものであり、これより多くの数を有していても良いし、これより少ない数であっても良い。また、それぞれのテーブルまたはエントリはこれ以外のパラメータを有していても良い。

各論理GWの各セッションは、EAP Flag４８２を有し、WS１３０はこの情報を元に論理GWがEAP Requestを発行可能かどうか判断することができる。WS１３０はEAP Flag４８２に基づきEAP Requestを発行した場合、発行先のMS ID４８０を登録し、またEAP Request送受信のために通信元アドレスとポート番号（４７０、４７２）として論理GWの情報を登録し、通信先アドレスとポート番号（４７４、４７６）としてBSの情報を登録しても良い。また、WS１３０のBS側ポート番号（４６４）とGW側ポート番号（４６６）を登録しても良い。WS１３０はこれらの情報を利用して、パケットのフィルタリングを行っても良い。ここで、BS１１０は、MS１００にNSP ID Listに送る前に、利用可能なNSPのListを更新しても良い。このときWS１３０は現在EAP Protocolの受付が出来ないNSPを、リストから外しても良い。

またWS１３０があるNSPに属する論理GWからEAP Requestが発行されているかどうかを、Network Entry毎に検索するのは効率が悪い。従って、WS１３０はEAP Count List４４２を利用し、各論理GWに対して最初のEAP Requestが何回発行されたかという情報を保持しておき、発行毎にこの値をカウントアップし、使用後にカウントダウンすることで論理GW個別パラメータテーブル４５０及び４５５及び４６０を検索する必要がなくなるという効果がある。

また各論理GWは、図５のように論理GW共通パラメータテーブル５２０及び５２５及び５３０と、論理GW個別パラメータテーブル５５０及び５５５及び５６０を有していても良い。

論理GW共通パラメータテーブル５２０及び５２５及び５３０は各論理GW共通のパラメータテーブルであり、エントリ５９４を管理するためのハンドル（Handle５３２）と、対応するNSPのID（NSP ID ５３４）と、WS側のIPアドレス（WS側 Address５３６）と、接続先NSPのIPアドレス（NSP Address ５３８）と、接続先NSPのPort番号（NSP Port Number ５４０）と、論理GWがどれだけの最初のEAP Requestを発行したかを登録するためのカウンタのリスト(EAP Count ５４２)等を含んでいてもよい。

論理GW個別パラメータテーブル５５０及び５５５及び５６０は、各エントリ５９０及び５９２を管理するためのハンドル（Handle５６２）と、各セッションでWS１３０と通信する場合のWS側Port番号（WS側Port Number ５６４）と、各セッションで利用するパラメータのためのテーブル（Parameter Table ５６６）と、セッションで利用する暗号鍵等の情報を管理するためのテーブル（Keys Table ５６８）と、RADIUS Account Protocolで利用する、課金のための情報を管理するためのテーブル（Account Info. Table５７０）と、Mobile IPで割り当てられたIPアドレスを管理するためのテーブル（MIP Address Table５７２）と、セッションの状態に関する情報を管理するためのテーブル（Session Info. Table ５７４）と接続先のMSのID（MS ID ５７６）、EAP Requestの送信フラグ（EAP Flag ５７８）等を含んでいてもよい。

ここでParameter Table５６６は、WiMAXの通信に利用するTransaction IDや、RADIUS Protocolで利用するIdentifier及びAuthenticator及びSPI等を格納するために利用しても良い。Keys Table５６８はRADISU ProtocolやEAP Protocolであらかじめ格納または獲得したMSK、MN-FA Key、FA-HA Key等を格納するために利用しても良い。Account Info. Table ５７０は、接続開始日時や、通信データ量などの情報を格納するために利用しても良い。MIP Address Table５７２は、HA Addressや、Care of Address等を格納するために利用しても良い。Session Info. Table５７４はRADIUS Protocolのセッションの状態等を含んでいても良い。論理GW１４０及び１４５はWS１３０と接続されている場合に、論理GW１４０及び１４５の処理負荷の状態を判断し、最初のEAP Requestを発行しておく数を制御しても良い。

ASN-GW１２０はEAPを利用した認証処理に伴い、NSP１５０との間でRADIUS Protocol１９５を用いたEAPパケットの転送処理を行うことで、データの仲介を行う。このときASN-GW１２０は、RADIUS Protocol１９５により送受信するデータが改ざんされていないことを確かめるためにAuthenticator等を利用し、改ざん検知を行う。この処理にはMD5やSHA1等のハッシュ関数を利用した演算が含まれるため、複数のセッションを同時に制御する場合に、一時的に論理GWに割り当てられた処理能力を使い切る可能性がある。しかしながら、論理GWの役割には他にハンドオーバーに伴う処理やMIP処理、Accounting処理等も存在し、特にハンドオーバーに伴う処理は、移動体としてWiMAXシステムを利用する場合の接続性に影響を及ぼす。例えば、処理能力が足りずに計算結果の遅延が発生した場合、車両及び船舶及び航空機等の高速に移動する装置に設置された端末で利用する際に、通信が断続的になる可能性がある。これは電話等の低遅延な処理が求められる利用においてユーザビリティに大きな影響を及ぼす。

しかしながら、Network Entryに関わる処理の数秒の遅延は、通信の遅延に比べてユーザビリティへの影響が、頻度の点から見て軽微であると判断できる。また、通常一度ネットワークに端末が接続されると、端末が移動することで、基地局間のハンドオーバーが発生したり、MIP処理によるデータのトンネリング処理が発生する可能性が高くなり、平均的な処理負荷も高まると考えられる。このことからNetwork Entryを許可する数を制御することは、論理GWの処理負荷の制御にも繋がると判断できる。

したがって、処理能力が処理量に対して十分でないときに、論理GWは処理量の調整を行う処理が要求される。そしてこの処理は、前記の分析から判断して、Network Entryに関わる処理を制御することにより達成される。本発明は論理GWがあらかじめEAP Requestを発行しておくことで、NSPに対応した論理GWの選択を行うことを可能にするものであるが、本発明を適用した論理GWがEAP Requestの発行量を制御することで、論理GWの処理負荷の制御が可能になるという効果も併せ持つ。通常、論理GWの処理負荷の制御方法としては、別の管理システムから各論理GWの処理負荷を観察し、処理負荷に応じて、WS等の制御装置に対してその情報を伝達する等の方法が考えられるが、この仕組みを用いれば、WiMAXシステム上に流れる通常のプロトコル処理に沿ったデータのみで可能になるという効果がある。

図２は論理GW１４０及び１４５における、EAP処理の手順を表すフローチャートである。論理GWはEAP開始処理２１０を実行する。この手続き２１０は、あらかじめEAP RequestをWS１３０に発行しておくためのものである。

まず、論理GW１４０及び１４５は、内部の負荷分析を行う（２１２）。負荷分析の方法としては、論理GW個別パラメータテーブル５５０または５５５または５６０に登録されている有効なエントリの数を元に判断しても良いし、現在のCPUの処理負荷や、時間帯及び地域及び過去の統計に基づき負荷を予測してもよい。この分析の結果（２１４）、新規のセッションを受入可能と判断した場合、論理GW１４０及び１４５は、GW個別パラメータテーブル５５０または５５５または５６０のEAP Flag５７８に情報を登録したエントリを作成しても良い（２１６）。またこの時に、接続に利用したポート番号５６４を記録しておく。

登録が完了すると、WS１３０に対してEAP Requestを発行し（２１８）、再び負荷分析手続き２１２に移行する。この間隔を制御するためにある一定期間の待ち時間を入れても良い。また、手続き２１４において新しいセッションの受入が出来ないと判断した場合も、再び負荷分析手続き２１２に移行する。この間隔を制御するためにある一定期間の待ち時間を入れても良い。これにより、論理GWは受入可能なセッションに応じたEAP Requestをあらかじめ発行しておくことが可能になる。

また図２において、論理GW１４０及び１４５は、EAP処理２２０を行っても良い。この手続き２２０は手続き２１０によりEAP処理が開始されていることを前提とするため、通常のEAPの手続きとは異なり、EAP Responseを受信することを基に手続きが開始するフローチャートとなる。

EAP処理２２０が開始すると、論理GW１４０及び１４５は、EAP Responseの受信を待つ。そこでEAP Responseを受信すると(２２２)、それが論理GW個別パラメータテーブル５５０または５５５または５６０のEAP Flag５７８に情報を登録してあるエントリに含まれるポート５６４からの受信であるかどうかを判断する（２２４）。本発明では、複数のEAP Requestをあらかじめ発行しておくことが可能であるが、その際にどのポートが使われたかを管理する必要がある。このようにポートに関連づけてEAP Responseを処理することで、不正なポートからのアクセスを阻止することが可能となると言う効果がある。

論理GW１４０及び１４５は、EAP Requestを発行した後、長時間EAP Responseを待ち続けることは、論理GWの管理の面で都合が悪い場合がある。例えば、一台の装置に複数の論理GWが存在する場合、物理的な一台の装置のリソースを複数の論理GWが共有することになる。その場合、ある処理が頻繁でない論理GWに割り当てられたリソースが解放されないままだと、装置のリソースに余裕があるにもかかわらず、別の処理が頻繁な論理GWの処理が遅延するおそれがある。またNSPとの契約により、あるNSPへの接続数を制限したい場合がある。そのような場合、EAP Requestが発行されてから一定時間処理がない場合や、WS１３０に登録してある最大接続数を超えてEAP Requestを登録しようとした場合にWS１３０がBS１１０へのEAP Requestの送信を行わずにエラーメッセージを含むEAP Responseを返すことで、適切な登録数を制御可能になると言う効果がある。

例えば、ASN-GW１２０が１００００セッションを処理可能な性能を持つとき、WS１３０は、一度にEAP Requestを受付可能なセッション数を１００と定義しておくことにする。この時、論理GW１４０及び１４５は、最初１００個のEAP Requestを発行し、EAP処理２２０が行われる度にEAP開始処理により新しいセッションを登録していくことにする。この仕組みを取れば、論理GW１４０及び１４５のどちらがどれだけのセッション数を受入可能かどうかは、特別な処理無しに論理GW１４０及び１４５の処理負荷に応じて決定されることになる。そこで互いの受け入れ済みセッションの合計が１００００に達したならば、WS１３０は、論理GW１４０または１４５からEAP Requestを受け取るとBS１１０と通信すること無しにEAP Responseを返すことで、新規のセッションを受け入れることが出来ない事を通知することが出来る。

手続き２２４において登録済みポートからの受信がある場合、論理GW１４０及び１４５は、EAP Responseの処理を行う（２２６）。ここで行うEAP Responseの処理とは、RADIUS Protocol１９５を利用して、NSP１５０にEAP Responseを送信する処理と、最初に送信したEAP Requestに対するエラーを含んだEAP Responseの場合のエントリ削除処理が該当する。前者の場合、NSP１５０からのEAP Request待ちとなるため（２２８）、NSP１５０からのEAP Requestを待ち、NSP１５０からEAP Requestを受信すると（２３０）、WS１３０経由でBS１１０にEAP Requestの送信を行う（２３６）。

手続き２２６において、最初に送信したEAP Requestに対するエラーを含んだEAP Responseの場合、エントリの登録の削除を行い(２３４)、再びEAP Response 受信待ちの状態(２２２)に移行する。また手続き２２４において、登録済みポートからの受信でない場合は、エラー処理を行い、再びEAP Response 受信待ちの状態(２２２)に移行する。通常、エラー処理としては受信したパケットの破棄を行う。

図3はWS１３０における認証処理の動作手順を表すフローチャートである。WS１３０はデータを受信すると（３１２）、それがMS_PreAttachmen_Ackであるかどうかを判断する（３７２）。MS_PreAttachmen_Ackである場合、EAP Request転送処理３７０を実行する。MS_PreAttachmen_Ackは、MS_PreAttachmet_Rspに対応してBSより送られてくるデータであり、受信したデータがMS_PreAttachmen_Ackであるかどうかの判断にはセッション情報やデータ転送元等を併せて用いても良い。

次にMS_PreAttachmen_Ackでない場合、それがAuthRelay Protocolにより転送されてきたデータであるかを判断する（３１４）。このときWS１３０は送信元のIPアドレス及びポート番号から、データがBS１１０から送信されたものか、論理GW１４０または１４５から送信されたものか、NSP１５０またはInternet １６０に接続されたその他の端末から送信されたものであるかという情報を併せて判断しても良い。

ここでAuthRelay Protocolとは、WiMAX Forumで定義されたBSとASN-GW間でEAP Protocolのデータを流すためのプロトコルであり、本発明では、論理GW１４０及び１４５とWS１３０の間でのEAPパケットの交換と、WS１３０とBS１１０間のEAPパケットの交換にAuthRelay Protocolを利用することにしている。これにより、論理GWへの実装上の変更を軽微にし、BSからもASN-GWが本発明に基づいた構成であるかどうかに関わらず通信可能となる効果がある。

データがAuthRelay Protocol上のデータでない場合、パケットはUDP/IPのIPアドレスとポート番号に基づき、適切な装置に転送され（３１６）、再びデータの受信待ち状態に遷移してもよい（３１２）。このとき必要ならば図4に記載のパラメータテーブルを入出力のアドレスに併せて変更しても良い。

データがAuthRelay Protocol上のデータである場合、次にその中のデータがEAP RequestかEAP Responseであるかどうかを確認する（３１８）。EAP Requestである場合、それは論理GW１４０または１４５からBS１１０に流れるデータである。このときWS１３０は、論理GW１４０または１４５から転送されてきたパケットの通信元IPアドレスが論理GW List４３６に登録済みのアドレスかどうかを判断する（３２０）。登録されていない場合、エラーを送信元に返してもよい（３５０）。また手続き３５０が完了した後に、再びデータの受信待機をしても良い（３１２）。

ただし、WS１３０は未登録の論理GWが存在する場合、新規に論理GW個別パラメータテーブルを作成し、論理GW共通パラメータテーブル４２０または４２５または４３０の論理GW Listに登録しても良い。どの論理GWがどのNSP IDと関連づけるかは、あらかじめ新規に論理GWが割り当てられる場合のアドレス予約テーブルを共有していても良いし、アドレスの範囲で区別できるような仕組みであっても良いし、別のプロトコルを用いて論理GWまたはNSP１５０に問い合わせる仕組みであっても良い。ここでは説明のためにエラーとして返す事としているが、前記の通り、その限りではない。

登録済み論理GWである場合、データパケットの送信先ポート番号が0または固定値かどうかを調べる（３２２）。WiMAXシステムでは、データ通信にUDP／IPを用いているが、論理GW１４０及び１４５からデータを転送する場合にWS１３０のどのポートにデータを転送すべきかについては不明である。したがって、最初の通信ではポート番号は０または固定値としておいてもよい。ポート番号が0または固定値でない場合、既に過去に通信が行われていると推測できることから、WSは、論理GW個別パラメータテーブルを参照することで指定されたIPアドレスにデータを送信してもよい（３２４）。また手続き３２４が完了した後に、再びデータの受信待機をしても良い（３１２）。

ポート番号が0または固定値である場合、それは最初のEAP Requestであると予測できることから、さらにEAP パケットのIDが0または固定値かどうかを調べる（３２６）。IDが０又は固定値であることで、本発明の機能を有するWS１３０は、それが最初のEAP Requestであると判断できるため、EAP Requestが届いたことを論理GW個別パラメータテーブル４５０または４５５または４６０に登録してもよい（３３０）。また手続き３３０が完了した後に、再びデータの受信待機をしても良い（３１２）。

もしもIDが０または固定値でないならば、送信元の論理GWに対してエラーを返しても良い（３３２）。また手続き３３２が完了した後に、再びデータの受信待機をしても良い（３１２）。

手続き３１８において、パケットがEAP Responseである場合、EAP パケットのIDが0または固定値かどうかを調べる（３５２）。IDが０または固定値でない場合、最初のEAP Requestに関連する処理ではないので、対応するAddressにデータを転送する（３５６）。一方、IDが０または固定値である場合は、最初のEAP Requestに関連する処理であるため、論理GW割り当てのための処理を行う。

まずWS１３０は、パケットに含まれるNSP IDまたはNAIに基づきGWを選択する（３５４）。ただし、NSPに関わる固有の値であり、それを用いてWS１３０がNSPを識別できるならばこの限りではない。このときWS１３０は対応するNSPに属する論理GW個別パラメータテーブルを調べ、予約済みのEAP Requestがあるかどうかを調べる（３５８）。存在する場合、そのエントリにMS IDを登録し、EAP Flag４８２を送信済みに変更し（３６０）、その論理GWにデータを送信する。

このとき、同時に複数のセッションがMSとの間で処理されており、そのエントリがこのパケットを送出する契機となったエントリでなかったとしても、そのエントリに登録してもよい。もしも予約済みのEAP Requestが存在しなければ、エラーを通信元に返して（３５０）、データ受信待ち状態に遷移してもよい（３１２）。ここで手続き３１２は、現在処理中のセッションがある場合でも、データの受信が発生する度に新しいセッションとしてタスクが生成されても良い。その場合、タスク生成時に、トランザクションのID及び通信相手のIPアドレス及びポート番号等の情報から、論理GW個別パラメータテーブル４５０及び４５５及び４６０に含まれるエントリを検索し、その情報を利用してもよい。

またWS１３０はEAP Request転送処理３７０を有していてもよい。EAP Request転送処理３７０において、WS１３０は、論理GW共通パラメータテーブル４２０または４２５または４３０のEAP Count List４４２を参照し、少なくとも一つのEAP Requestが利用可能であるかどうかを判断する（３７４）。EAP Count List４４２により有効なEAP Requestが存在しないと判断できる場合には、論理GW個別パラメータテーブル４５０または４５５または４６０に有効なEAP Requestが登録されるまで待っても良い。

また、論理GW個別パラメータテーブル４５０または４５５または４６０がEAP Requestの受信予約が可能な場合には、有効なEAP Requestが存在しない場合でも、EAP Requestを発行しても良い。このとき、WS１３０は、論理GW１４０または１４５からEAP Requestが発行されると、優先的に要求をEAP Requestの受信予約を行ったエントリに割り当てて登録し、状態を送信予約に移行させてもよい。この処理を行う場合、EAP Requestの発行が一時的に間に合わない場合でも処理を継続させることが出来ることと、論理GWがセッションを受け入れられない場合の通知を次のEAP Requestで送信可能であることから、本発明のような構成を取る場合においても、セッションの受付可否をMS１００に通知可能となる効果がある。またこれにより、ASN-GW１２０の処理待ちにより、MS１００がEAP Requestの未受信によるタイムアウトが発生しにくくなるという効果がある。

有効なEAP Requestが存在する場合には、MS_PreAttachment_Ackの送信元にEAP Requestを送信しても良い（３７６）。このとき、WS１３０は論理GW個別パラメータテーブル４５０または４５５または４６０のEAP Flag４８２に送信済みであることを示す、送信予約に変更しても良い（３７８）。この後、ＷＳ１３０は状態をデータ受信待ち３１２に移行させる。

このような仕組みによりＷＳ１３０は動作するが、ＷＳ１３０が有効なのは図６のような構成に限らない。

図７は、ＷＳ７５０は論理ＧＷ選択処理のみを行い、その後の処理は論理ＡＳＮ−ＧＷ７４２または７４４または７４６が行う場合の構成を表している。この場合でも論理ＧＷ７４２または７４４または７４６は図２に示すフローチャートと図５のテーブルに基づいた処理を行い、ＷＳ７５０は図３に示すフローチャートと図４のテーブルに基づいた処理を行うことで同様の論理ＧＷ選択の効果が得られることは言うまでもない。この時、ＷＳ７５０は認証処理の開始手続きに関わる処理を中心に行うことになるため、図６の構成に比べて負荷が少なく、また各論理ＡＳＮ−ＧＷ７４２または７４４または７４６の処理もＷＳ７５０がない場合に近い構成で動作可能であるため、変更のためのコストがより少なくてすむ。

本発明の実施例によるNetwork Discovery及びSelectionと、認証処理の流れを示すフローチャートである。本発明の実施例による論理ＧＷ内の認証処理手順を示すフローチャートである。本発明の実施例によるWiMAX Switch内の認証処理手順を示すフローチャートである。本発明の実施例によるWiMAX Switch内のテーブル構成例を表すテーブルである。本発明の実施例による論理ＧＷ内のテーブル構成例を表すテーブルである。本発明の実施例によるWiMAX SwitchがASN-GWに対して入出力されるデータの制御を行う際の構成図である。本発明の実施例によるWiMAX Switchが論理ASN-GWを選択し、その後のデータWAN側のデータ入出力に対しては各論理ASN-GWに処理させる場合の構成図である。本発明が適用されるWiMAXシステムの基本構成を表す構成図である。

符号の説明

１００…MS
１１０…BS
１２０…ASN-GW
１３０…WS
１４０…論理GW
１５０…NSP
１９５…RADIUS Protocol
１９６…EAP Protocol
１６０…Internet
８００…MS
８１０…NAP
８１１…ASN（Access Service Network）
８１２…BS
８１３…ASN-GW
８２０…NSP１
８２１、８３１…CSN（Connectivity Service Network）
８２２、８３２…AAA（Authentication Authorization &Accounting）
８２３、８３３…HA(Home Agent)
８４０…Internet

Claims

ネットワークのデータ入出力機能を有する第一のネットワーク処理装置と、
ネットワークへ接続するために利用する末端装置がネットワークに接続する際に行われる認証に用いられるデータを転送する機能を有し、論理的または物理的に複数存在する第二のネットワーク処理装置とによって構成されるネットワーク処理システムであって、
前記第一のネットワーク処理装置は前記末端装置からネットワークに接続するための認証要求の送信要求を受信する前に、前記第二のネットワーク処理装置から送信される前記第二のネットワーク処理装置で共通した認証要求を受信し、
前記末端装置は前記認証要求の送信要求を前記第一のネットワーク処理装置に送信し、
前記第一のネットワーク処理装置は前記認証要求の送信要求を受信したときに、前記認証要求を前記末端装置に送信し、
前記末端装置は前記認証要求に対する認証応答を前記第一のネットワーク処理装置に送信し、
前記第一のネットワーク処理装置は受信した前記認証応答を用いて前記第二のネットワーク処理装置を選択して前記認証応答を転送することを特徴としたネットワーク処理システム。
ネットワークのデータ入出力機能を有する第一のネットワーク処理装置であって、
ネットワークへ接続するために利用する末端装置がネットワーク接続する際に行われる認証に用いられるデータを転送する機能を有する第二のネットワーク処理装置が論理的または物理的に複数存在する場合に、
ネットワークへ接続するために利用する末端装置から、ネットワークに接続するための認証要求の送信要求を受信する前に、前記第二のネットワーク処理装置から送信される前記第二のネットワーク処理装置で共通した認証要求を受信し、
前記末端装置から前記認証要求の送信要求を受信したときに、前記認証要求を前記末端装置に送信し、
その後に発生する前記末端装置からの前記認証要求に対する認証応答を受信し、
前記受信した認証応答を用いて前記第二のネットワーク処理装置を選択し、
前記第二のネットワーク処理装置に受信した前記認証応答を転送する
機能を有することを特徴とする前記第一のネットワーク処理装置。
請求項１記載の第二のネットワーク処理装置であって、
前記第二のネットワーク処理装置内で処理可能なセッション数または処理負荷に応じて前記第一のネットワーク処理装置へ前記認証要求を送信する機能を有することを特徴とする前記第二のネットワーク処理装置。
請求項１記載の第二のネットワーク処理装置であって、
セッションの情報を管理する第一のテーブルを有し、
前記第一のテーブルに前記認証要求を送信したことを表す情報及び前記認証応答を受信したことを表す情報を登録し、該登録した情報を参照及び変更及び削除する機能を有することを特徴とする前記第二のネットワーク処理装置。
請求項２記載の前記第一のネットワーク処理装置であって、
セッションの情報を管理する第二のテーブルを有し、
前記第二のテーブルに前記認証要求を受信及び送信したことを表す情報と、前記認証応答を受信及び送信したことを表す情報を登録し、該登録した情報を参照及び変更及び削除する機能を有することを特徴とする前記第一のネットワーク処理装置。