(57)【要約】【課題】  システムリソースの浪費や処理の遅延を防止する。【解決手段】  GGSN６からのRADIUSアカウントリクエスト(4)を受信したRADIUSサーバ９ａは、そのアトリビュート情報をユーザごとのセッション情報としてデータベースに保存するとともに、クライアントのＩＰアドレスとノードのグループとを対応させた設定ファイルを参照して、セッション情報のレプリケーション先を決定し、決定されたグループに属するノード（WAP-GW）にセッション情報のレプリカを送信する(5)。対象とされた全ノードから完了通知(6)を受信するとRADIUSアカウントレスポンスが返され、その後、移動端末１とWAP-GWとの間でセッションが確立される。移動端末１からのリクエストは、ロード・バランサ１１により前記設定ファイルと同様のルールにより選択されるWAP-GWにルーティングされる。【選択図】  図２
2005267016.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードにより処理を分散するようになされたインターネット接続サービスを提供する移動体通信システムにおけるサーバ装置であって、
前記ノードを複数のグループに分割し、該複数のグループのうちの選択されたグループに属するノードにセッション情報のレプリカを保持させる手段を有することを特徴とするサーバ装置。
【請求項２】
クライアントのＩＰアドレスに応じて、前記セッション情報を保持させるノードの属するグループを決定するようになされていることを特徴とする請求項１記載のサーバ装置。
【請求項３】
前記ノードは、ＷＡＰゲートウエイ又はＰＰＧであることを特徴とする請求項１又は２記載のサーバ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯電話などの移動端末からインターネットに接続することができる移動体通信システムにおけるサーバ装置に関する。
【背景技術】
【０００２】
従来より、移動体通信システムにおいてインターネット接続サービスが提供されている。
また、近年、いわゆる第３世代と呼ばれる携帯電話サービスが導入されつつある。この第３世代の移動体通信システムにおいては同一の移動端末を世界中で共通に使用することができるように標準化が進められており、ＷＡＰ（Wireless Application Protocol）及びＭＭＳ（Multimedia Messaging Service）の規格が共通仕様として採用されている（非特許文献１）。
【非特許文献１】The WAP Forum Ltd., "WAP 2.0 Technical White Paper", [online], (2002.01.18), ［平成15年11月15日検索］ , インターネット <URL:http://www.wapforum.org/what/WAPWhite_Paper1.pdf>
【発明の開示】
【発明が解決しようとする課題】
【０００３】
上述のようなインターネット接続サービスを提供する移動体通信システムにおいては、移動体通信網とインターネットとの間に設けられるゲートウエイなどのノードが複数設けられており、クライアントからのリクエストを分散して処理するようになされている。このときに、各ノードにユーザのセッション情報（RADIUSセッション情報）のレプリカ（複製）を保持させておくことにより、アクセスごとにクライアントを特定することができるようになされている。
しかしながら、従来においては、どのノードが対象となるリクエストを受信するのかを把握することができなかったため、どのノードがユーザリクエストを受信しても処理が可能であるように、全てのノードにセッション情報をレプリケーション（複製）するようにしていた。したがって、レプリケーションの対象となるノード数が増加すると、レプリケーション処理に要する時間やシステムリソースの消費が大きくなり、サービスの遅延を招くという問題があった。
【０００４】
そこで、本発明は、無駄なレプリケーションの発生を抑制することで、システムリソースの浪費と処理の遅延を回避することができる移動体通信システムにおけるサーバ装置を提供することを目的としている。
【課題を解決するための手段】
【０００５】
上記目的を達成するために、本発明のサーバ装置は、複数のノードにより処理を分散するようになされたインターネット接続サービスを提供する移動体通信システムにおけるサーバ装置であって、前記ノードを複数のグループに分割し、該複数のグループのうちの選択されたグループに属するノードにセッション情報のレプリカを保持させる手段を有するものである。
また、クライアントのＩＰアドレスに応じて、前記セッション情報を保持させるノードの属するグループを決定するようになされているものである。
さらに、前記ノードは、ＷＡＰゲートウエイ又はＰＰＧとされているものである。
【発明の効果】
【０００６】
本発明のサーバ装置によれば、セッション情報を全ノードにレプリケーションすることなく、必要なノードに対してのみレプリケーションされるようにしたため、無駄なレプリケーションの発生を抑制することができ、システムリソースの浪費や処理の遅延を回避することができる。
また、ＩＰアドレスごとにセッション情報がレプリケーションされるグループを決定し、グループ内の全ノードに同一情報が複製されるようにしているため、同一グループ内であれば、どのノードがユーザからのリクエストを受け付けても、セッション情報とリクエストの２つの情報を紐付けることができる。
【発明を実施するための最良の形態】
【０００７】
図１は、本発明の移動体通信システムの実施例の全体構成を示すブロック図である。
この図において、１は携帯電話機等の移動端末（ＵＥ：User Equipment）、２は該移動端末１が接続されている無線基地局（ＢＴＳ：Base Transceiver Station）、３は複数の無線基地局２を管理する無線基地局制御装置（ＲＮＣ：Radio Network Controller）、４は移動端末１の呼接続制御やサービス制御等を行う移動通信交換局（ＭＳＣ：Mobile service Switching Center）、５は前記無線基地局制御装置（ＲＮＣ）３とコアネットワーク（パケット網）とのゲートウエイ（ＳＧＳＮ：Serving GPRS Support Node）、６はコアネットワーク（パケット網）とＩＰネットワークとのゲートウエイ（ＧＧＳＮ：Gateway GPRS Support Node）である。
【０００８】
７はサービスごとのユーザのアクセス権限のチェックを行う移動体通信システムの加入者認証機構（ＪＳＲ：J-SKY RADIUS）、８は移動端末１からのWAP2.0プロトコルを終端し、ＨＴＴＰ（HyperText Transfer Protocol ）を用いてオリジン・サーバ側へ転送するためのＷＡＰゲートウエイ（ＷＡＰ−ＧＷ：WAP-Gateway）、及び、受け付けたリクエストを適切な形式に変換して後段に送出するなどしてＷＡＰ標準機能と移動体通信事業者による拡張機能との調整を行うプロキシサーバ（ＪＳＰ：J-Phone Scheme Proxy）とを有するノード（ＷＡＰ−ＧＷ及びＪＳＰ）である。
また、９はＧＧＳＮ６からのRADIUS アカウンティングプロトコル（RADIUS：Remote Authentication Dial-In User Service, RFC2138）を終端するとともに、ユーザごとのセッション管理及びセッションログの生成などを行うRADIUS（アカウンティング）サーバ９ａを備えるとともに、ＷＡＰ／ＭＭＳサービス加入者がウェブやメール等のサービスを利用する際に必要なユーザ情報や移動端末の能力に関する情報（UE-Profile）等を一元管理し、クライアント（ノード８など）からの要求に応じて必要な情報を提供する情報管理サーバ（Ｒ２Ｍ：RADIUS & Repository Manager）、１０はＷＡＰプッシュやメールの配信などのプッシュサービスを実行するノード（プッシュ・プロキシ・ゲートウエイ，ＰＰＧ：Push Proxy Gateway）である。
【０００９】
なお、前記ノード（WAP-GW及びJSP）８は、図１においては1個しか図示していないが、実際には処理を分散することができるように、複数のノードが設けられており、それぞれ１又は複数のノードを含む複数のグループに分割されて管理されている。
各ノードのＷＡＰ−ＧＷは、アクセスがどのクライアントからのものであるのかを特定するためにユーザごとのセッション情報を保持するようになされており、セッション情報が保持されている間のみユーザからのリクエストが有効になるように制御している。後述するように、このセッション情報は、前記Ｒ２Ｍ９のRADIUSサーバ９ａにより、クライアントのＩＰアドレスに基づいて選択されたノードのＷＡＰ−ＧＷにRADIUSセッション情報をレプリケーションされることにより、ＷＡＰ−ＧＷ中に保持されるようになされている。
そして、ロード・バランサ１１は、ユーザエージェントからのリクエストをクライアントのＩＰアドレスに基づいて決定されるグループに属するノードにルーティングするようにしている。このルーティング先の決定は、上記セッション情報がレプリケーションされるＷＡＰ−ＧＷの選択と同一のルールにより行われるようになされている。
また、前記プッシュ・プロキシ・ゲートウエイ（ＰＰＧ）１０も、前記ノード８と同様に複数設けられており、１又は複数のＰＰＧを含む複数のグループに分割されて管理されている。そして、クライアントのＩＰアドレスに基づいてセッション情報のレプリカが保持されるＰＰＧのグループが選択されるようになされており、また、ルーティング先のＰＰＧも同一のルールで選択されるようになされている。
このように、本発明においては、クライアントのＩＰアドレスに基づいて選択されたＷＡＰ−ＧＷ又はＰＰＧに対してのみユーザのセッション情報をレプリケーションするようにしている。
【００１０】
１２は全加入者情報を一元管理するディレクトリ・サーバ（ＤＩＲ：Directory Server）である。この加入者情報は、全世代、全地域間で共用されるものであり、ＤＩＲ１２はＤＲＳ１３の情報元になっている。１３はディレクトリ・レプリカ・サーバ（ＤＲＳ：Directory Replica Server）であり、一定間隔（例えば、１分間隔）でＤＩＲ１２から加入者情報をローカルにコピーして維持することにより、照会要求に対して加入者情報を提供する。これにより、ＤＩＲ１２の障害時においても、サービス（オーダー・エントリーを除く）を継続して提供することができる。
１４は、前記ノード（ＷＡＰ―ＧＷ及びＪＳＰ）８の後段に接続され、クライアントからのリクエストをオリジン・サーバ１６との間で仲介するウェブ・ゲートウエイ（ＷＧＷ：Web Gateway）である。また、１５はインターネットであり、コンテンツ・プロバイダなどのオリジン・サーバ（Origin Server：指定されるリソースが存在するか、あるいは生成されるサーバ）１６が接続されている。
【００１１】
前記セッション情報のレプリケーションの処理について、移動体通信システムの要部構成を示す図２を参照して説明する。
この図において、前記図１と同一の構成要素には同一の番号を付して説明を省略する。８−１，８−２，８−３は、前述したノード（ＷＡＰ−ＧＷ及びＪＳＰ）８のグループである。なお、ここでは、３つのグループがあるものとしているが、グループの数は任意とすることができ、各グループには任意の数のノードを所属させることができる。
移動端末１においてウェブアクセスなどの操作が行われると、ＳＧＳＮ５に「Activate PDP Context Request」が発せられ（１）、これにより、ＳＧＳＮ５からＧＧＳＮ６に「Create PDP Context Request」が送られる（２）。この「Create PDP Context Request」には、移動端末１の加入者に割り当てられた国際識別番号（ＩＭＳＩ：International Mobile Subscriber Identity）と移動端末１の電話番号（ＭＳＩＳＤＮ：Mobile Station ISDN number）が添付される。
ＧＧＳＮ６は、「Create PDP Context Request」に応答して、前記ＪＳＲ７に対して、認証要求「Radius Access Request」を送出する。ＪＳＲ７でユーザの認証に成功すると、認証成功を示す「Radius Access Accept」がＧＧＳＮ６に返され、前記移動端末１にＩＰアドレスが払い出される（３）。
その後、ＧＧＳＮ６は、前記Ｒ２Ｍ９中のRADIUSサーバ９ａに対し、RADIUSアカウンティングリクエスト「Radius Accounting Request (Accounting-start)」を送出する（４）。このRADIUSアカウンティングリクエストには、払い出されたＩＰアドレス、ＭＳＩＳＤＮあるいはＩＭＳＩなどがアトリビュート（attribute）情報として含まれている。
【００１２】
前記RADIUSサーバ９ａは、この「Radius Accounting Request (Accounting-start)」を受信すると、そのアトリビュート情報をユーザごとのセッション情報（RADIUSセッション情報）としてデータベースに登録するとともに、そのセッション情報の複製（レプリカ）を保持すべきノード（WAP-GW／PPG）のグループ（８−１〜８−３）をそのクライアントＩＰアドレスに基いて決定する。そして、該決定されたグループに属するノードに対して、「Radius Accounting Replication」を送出して、そのRADIUSセッション情報の複製を保持させる（５）。図示する例では、グループ８―１に属する各ノード（のＷＡＰ−ＧＷ）にセッション情報の複製を保持させるようにしている。ここで、保持させるセッション情報には、少なくとも、クライアント（ＵＥ）に払い出されたＩＰアドレス、ＭＳＩＳＤＮ、ＩＭＳＩが含まれている。
そして、グループ８―１に属する全てのノードから完了通知「Radius Accounting Replication Ack」を受信すると（６）、前記ＧＧＳＮ６に対し、アカウンティングリクエストを受け入れたことを示す「Radius Accounting Response」を返す（７）。
前記ＧＧＳＮ６は、これにより、クライアント（ＵＥ１）に対して払い出されたＩＰアドレスが添付された「Create PDP Context Response」を前記ＳＧＳＮ５に送信し、ＳＧＳＮ５は「Activate PDP Context Accept」を前記移動端末１に送信する。
【００１３】
この後、ユーザエージェントと前記決定されたグループ８−１に属するノードのＷＡＰ−ＧＷとの間でＴＣＰ（Transmission Control Protocol）セッションを確立するための「TCP Handshake」が行われてＴＣＰセッションが確立（Session Connected）される。
ＴＣＰセッションが確立されると前記ユーザエージェントは、そのノードにＨＴＴＰリクエスト（１０）を送る。ＨＴＴＰリクエスト（１０）を受信したノードは、前述のようにして保管しているセッション情報のレプリカを参照して、対応するセッション情報のレプリカが存在するとともに加入者情報が一致する場合にのみ、そのＨＴＴＰリクエストを受け付ける。そして、ＨＴＴＰリクエスト（１１）をオリジン・サーバ１６に送る。
オリジン・サーバ１６が、ＨＴＴＰリクエスト（１１）により要求された全てのコンテンツを送出すると、ＴＣＰセッションが閉じられてそのノードとオリジン・サーバ１６間におけるＴＣＰセッションが終了（Session Disconnected）する。
【００１４】
移動端末１から要求されたコンテンツを取得したノードは、コンテンツを要求した移動端末１の性能を表す移動端末情報を参照し、この移動端末情報に基づいて移動端末１の性能を十二分に発揮できるようにコンテンツの変換処理を行う。次いで、そのノードは変換後のコンテンツを返送する「HTTP Res」をユーザエージェントに送出する。「HTTP Res」を受信したユーザエージェントは、取得したコンテンツを表示すると共に受信したことを通知するAckとＴＣＰセッションを閉じるための「TCP Fin + Ack」をノードに送出する。これを受信したノードは、「TCP Ack」を返送し、ユーザエージェントとノード間におけるＴＣＰセッションが終了する。
次いで、ユーザエージェントからの通信を終了させるための通信終了要求に応じてＧＧＳＮ６から「Radius Accounting Req(Accounting-stop)」が送出される。このリクエストを受信したRADIUSサーバ９ａは該当するRADIUSセッション情報を破棄し「Radius Accounting Res」をＧＧＳＮ６に送出する。
これにより、ユーザエージェントとノードとの間の通信が終了する。
【００１５】
このように、移動端末１のユーザエージェントからＨＴＴＰリクエスト（１０）が送信されると、該ＨＴＴＰリクエストは、ロード・バランサ１１により、グループ８−１に属するノードにルーティングされ、そのリクエストを受信したノードがプロキシとなってオリジンサーバに送信される。
ここで、前記ロード・バランサ１１によるルーティングのルールは、前記RADIUSサーバ９ａにおけるレプリケーション先を決定するルールと同一のルールとされている。
【００１６】
図３は、上述したセッション情報のレプリケーション先となるノード（ＷＡＰ−ＧＷ又はＰＰＧ）のグループを決定するために用いられる設定ファイルの一例を示す図である。この設定ファイルは、前記RADIUSサーバ９ａに記憶されるが、前記ロード・バランサ１１も同一内容の設定ファイルによりリクエストのルーティング先を決定するようにしている。そして、この設定ファイルを書き換えることにより、レプリケーション先のノード（のグループ）の指定及び変更を行うことができるようになされている。また、この設定ファイルの書き換えによる変更は、システムを停止することなく即時反映することができる。さらに、レプリケーションの対象ノードは重複して設定することが可能であり、レプリケーション先として複数のグループを指定することや複数のクライアントのIPアドレス群を同一グループへ指定することも可能である。
【００１７】
図３に示すように、設定ファイルは、（ａ）移動端末に割り当てられたＩＰアドレスとノード（ＷＡＰ−ＧＷ又はＰＰＧ）のグループとの対応関係を示すファイルと、（ｂ）ノード（ＷＡＰ−ＧＷ又はＰＰＧ）のグループを定義するファイルである。図示するように、（ａ）のＩＰアドレスとグループと対応を示すファイルは、移動端末に割り当てられるＩＰアドレスの帯域ごとに、それに対応する１又は複数のノードのグループ名を記述したものであり、（ｂ）のグループ定義ファイルは、各グループごとにそのグループに属するノード（ＷＡＰ−ＧＷ又はＰＰＧ）のＩＰアドレスを記述したものである。
前記RADIUSサーバ９ａは、（ａ）及び（ｂ）の２つの設定ファイルを参照して、前記「RADIUS Accounting Req (Accounting-start)」に添付される当該移動端末のＩＰアドレスをキーとして、前記（ａ）のファイルを参照して、レプリケーションの対象となるノードのグループ（８−１〜８−３）を決定し、次に、（ｂ）のグループ定義ファイルを参照して、選択されたグループに属するノードのＩＰアドレスを取得して、それらに対し、前記「RADIUS Accounting Replication」を送出する。
【００１８】
図４は、セッション確立の際に、ＧＧＳＮ６から送出される「RADIUS Accounting Req (Accounting-start)」を受信したときの、前記RADIUSサーバ９ａの処理の流れを示すフローチャートである。
RADIUSサーバ９ａは、前記ＧＧＳＮ６からのRADIUSアカウンティングリクエストを待ち受け（Ｓ１）、「RADIUS Accounting Req (Accounting-start)」を受信すると（Ｓ２）、該リクエストのアトリビュート（attribute）情報の検査を行い（Ｓ３）、ＮＧであるときは、ＧＧＳＮ６へレスポンスを送ることなく、そのパケットを廃棄する（Ｓ１１）。ＯＫであるときは、そのリクエストのアトリビュート情報をそのユーザのセッション情報として保存する（Ｓ４）。そして、前記図３に示した設定ファイルを参照して、そのユーザのＩＰアドレスをルーティングするノード（ＷＡＰ−ＧＷ）を特定し、そのセッション情報をレプリケーションする（Ｓ５）。そして、レプリケーションタイマーをスタートさせ（Ｓ６）、レプリケーションしたノードからレプリケーション完了通知を受け取るのを待つ（Ｓ７）。前記レプリケーションタイマーの計数が終了するまでに、対象となる全ノードのＷＡＰ−ＧＷから「RADIUS Accounting Replication Ack」を受け取ったときは、ＧＧＳＮ６に対し、「RADIUS Accounting Res(Accounting-start)」を送信する（Ｓ１２）。一方、全ＷＡＰ−ＧＷから完了通知を受け取る前に、レプリケーションタイマーの計数が終了したときは（Ｓ８）、あらかじめ指定されている回数だけリトライを行う（Ｓ９、Ｓ１０）。そして、指定された回数だけリトライを繰り返しても、全てのＷＡＰ−ＧＷからレプリケーション完了通知を受け取れなかったときは、ＧＧＳＮ６へレスポンスを送ることなく、そのリクエストを破棄する。
このように、RADIUSセッション情報のレプリケーションが完了するまで、ユーザからのリクエストが送出されることがないようにしており、セッション情報とユーザからのリクエストの同期を取ることができるようになされている。
【００１９】
図５は、セッション終了の際にＧＧＳＮ６から送出される「RADIUS Accounting Req (Accounting-stop)」を受信したときの、前記RADIUSサーバ９ａの処理の流れを示すフローチャートである。
前記図４の場合と同様に、RADIUSサーバ９ａは、前記ＧＧＳＮ６からのRADIUSアカウンティングリクエストを待ち受け（Ｓ２１）、「RADIUS Accounting Req (Accounting-stop)」を受信すると（Ｓ２２）、該リクエストのアトリビュート（attribute）情報の検査を行い（Ｓ２３）、ＮＧであるときは、ＧＧＳＮ８へレスポンスを送ることなく、そのパケットを破棄する（Ｓ２６）。また、そのリクエストに含まれているクライアントのＩＰアドレス（Framed-IP-Address）が既にRADIUSサーバ９ａ内に保存されているときなどには、そのＩＰアドレスをキーとしてRADIUSサーバ９ａ内に保存されているセッション情報を削除（Ｓ２４）した後、「RADIUS Accounting Res(Accounting-stop)」をＧＧＳＮ８に送信する（Ｓ２５）。
これにより、RADIUSセッションの終了後、保持されていた情報は全て破棄される。
なお、以上のように、ユーザごとのRADIUSセッションの確立〜終了は、RADIUS Accounting Request(Accounting-start)〜(Accounting-stop)で判別しているが、(Accounting-on/off)のような準正常系やタイムアウトのように異常系の処理においても、不整合が発生しないようにしている。
【００２０】
このようにして、クライアントのＩＰアドレスに対応して選択されたノードのグループに属するノード（ＷＡＰ−ＧＷ）に確実にセッション情報を存在させることができる。グループ内の全ノードに同一情報がレプリケーションされるため、同一グループ内であれば、どのノードもユーザからのリクエストを受け付けることができ、リクエスト受信時にセッション情報の不足を理由にユーザに対してエラーを返信することがなくなる。
また、レプリケーションの対象とするノードを最小限とすることができ、処理に要する時間とトラフィックの増加を抑えることができる。したがって、システムリソースの浪費と処理の遅延を回避することが可能となる。
【００２１】
なお、上記においては、ＷＡＰ−ＧＷ８−１〜８−３に対するセッション情報のレプリケーションについて説明したが、ＰＰＧ１０−１〜１０−３についても、全く同様の手法でセッション情報をレプリケーションすることができる。すなわち、前記図３に示したと同様の設定ファイルを用いてクライアントのＩＰアドレスに基づきセッション情報をレプリケートするＰＰＧのグループを決定し、該決定されたグループに属するＰＰＧにセッション情報の複製を保持させるとともに、同一のルールに基づきルーティングすべきＰＰＧを決定すればよい。
【図面の簡単な説明】
【００２２】
【図１】本発明の移動体通信システムの実施例の全体構成を示すブロック図である。
【図２】本発明の移動体通信システムの要部構成を示すブロック図である。
【図３】セッション情報のレプリケーション先の選択に用いられる設定ファイルの一例を示す図である。
【図４】RADIUS Accounting Req (Accounting-start)を受信したときの、RADIUSサーバの処理の流れを示すフローチャートである。
【図５】RADIUS Accounting Req (Accounting-stop)を受信したときの、RADIUSサーバの処理の流れを示すフローチャートである。
【符号の説明】
【００２３】
１：移動端末（ＵＥ）、２：無線基地局（ＢＴＳ）、３：無線基地局制御装置（ＲＮＣ）、４：移動通信交換局（ＭＳＣ）、５：ゲートウエイ（ＳＧＳＮ）、６：ゲートウエイ（ＧＧＳＮ）、７：加入者認証機構（ＪＳＲ）、８：ノード（ＷＡＰ−ＧＷ及びＪＳＰ）、９：情報管理サーバ（Ｒ２Ｍ）、９ａ：RADIUSサーバ、１０：プッシュ・プロキシ・ゲートウエイ（ＰＰＧ）、１１：ロード・バランサ、１２：ディレクトリ・サーバ（ＤＩＲ）、１３：ディレクトリ・レプリカ・サーバ（ＤＲＳ）、１４：ウェブ・ゲートウエイ（ＷＧＷ）、１５：インターネット、１６：オリジン・サーバ
【図１】
2005267016.tif 000003
【図２】
2005267016.tif 000004
【図３】
2005267016.tif 000005
【図４】
2005267016.tif 000006
【図５】
2005267016.tif 000007