JP2005267017A - サーバ装置 - Google Patents

Abstract

【課題】 無駄なトラフィックの発生やシステムリソースの浪費を回避する。
【解決手段】 ＧＧＳＮからのRADIUSアカウンティングリクエストを受け取ったRADIUSサーバは、各ユーザに固有の設定情報であるセルフケア・プロファイル情報を格納しているセルフケアデータベースを参照する(7)。そのユーザが初めてウェブアクセスする場合で、そのユーザの設定情報が格納されていないとき(14)は、ＷＡＰ−ＧＷ及びＪＳＰは、ユーザエージェントに対し、同意画面を送信し(15)、同意が得られると(16)、前記セルフケアデータベースにそのユーザのエントリを作成する(18)。
【選択図】 図３

Description

本発明は、携帯電話などの移動端末からインターネットに接続することができる移動体通信システムにおけるサーバ装置に関する。

携帯電話などの移動端末からインターネットに接続することのできる移動体通信システムが運用されている。このような従来の移動体通信システムにおいては、各移動体通信事業者ごとにそれぞれ独自の仕様が採用されていた。
また、近年、いわゆる第３世代と呼ばれる携帯電話サービスが導入されつつあるが、この第３世代の移動体通信システムにおいては同一の移動端末を世界中で共通に使用することができるように標準化が進められており、ＷＡＰ（Wireless Application Protocol）及びＭＭＳ（Multimedia Messaging Service）の規格が共通仕様として採用されている（非特許文献１）。
The WAP Forum Ltd., "WAP 2.0 Technical White Paper", [online], (2002.01.18)，［平成１５年１１月１５日検索］，インターネット<URL:http://www.wapforum.org/what/WAPWhite_Paper1.pdf>

上述のような移動体通信システムにおいては、各ユーザごとに、ウェブサービスなどに関する設定を行うことができるようになされている。例えば、各ユーザは、それぞれ、自己のユーザＩＤなどの情報をサーバに送出することを許可するか、特定のＵＲＬに対するアクセスを抑止するかなどといった事項につき、自ら設定することができる（セルフケア）ようになされている。
しかしながら、従来のシステムにおいては、ユーザがサービスを利用するか否かにかかわらず、契約時に発生するシステムオーダーによってそのユーザに固有の設定情報（のデフォルト値）がデータベースに登録されるようにされているため、全契約者に対する設定情報の登録が発生することとなり、膨大な処理を行う必要があった。

そこで、本発明は、ユーザごとの設定情報の登録に際し、無駄なトラフィックの発生やシステムリソースの浪費を最小限に押さえることができるサーバ装置を提供することを目的としている。

上記目的を達成するために、本発明のサーバ装置は、移動体通信網とインターネットなどのＩＰネットワークとの間に設けられるゲートウエイ装置と前記移動体通信網とに接続されたサーバ装置であって、ユーザからのＨＴＴＰリクエストが発生した際に、ユーザごとの設定情報を格納しているデータベースにそのユーザの情報が含まれているか否かを判定し、含まれていない場合に、そのユーザに関する設定情報を前記データベースに登録するようになされているものである。
また、サービス解約時などに前記データベースの当該ユーザのエントリを削除するようになされているものである。

本発明のサーバ装置によれば、契約時ではなく、ユーザからのリクエストが発生した時点、すなわち、設定情報が実際に必要となる時点で、そのユーザの設定情報をデータベースに登録するようにしているため、無駄なトラフィックの発生やシステムリソースの浪費を抑えることができる。
また、ユーザのサービス解約時などデータの削除が必要となった時点でそのユーザのエントリを削除するようにしているために、不必要なデータがシステム内に残ることがなく、システムリソースの有効利用が可能である。
さらに、前記データベースのエントリの数を計数することにより、契約者のうち、ウェブやメールなどの非音声サービスを利用したことのないユーザ数を知ることもできる。

図１は、本発明の移動体通信システムの実施例の全体構成を示すブロック図である。
この図において、１は携帯電話機等の移動端末（ＵＥ：User Equipment）、２は該移動端末１が接続されている無線基地局（ＢＴＳ：Base Transceiver Station）、３は複数の無線基地局２を管理する無線基地局制御装置（ＲＮＣ：Radio Network Controller）、４は移動端末１の呼接続制御やサービス制御等を行う移動通信交換局（ＭＳＣ：Mobile service Switching Center）、５は前記無線基地局制御装置（ＲＮＣ）３とコアネットワーク（パケット網）とのゲートウエイ（ＳＧＳＮ：Serving GPRS Support Node）、６はコアネットワーク（パケット網）とＩＰネットワークとのゲートウエイ（ＧＧＳＮ：Gateway GPRS Support Node）である。

７は移動端末（ＵＥ）１からのWAP2.0プロトコルを終端し、ＨＴＴＰ（Hypertext Transfer Protocol ）を用いてオリジン・サーバ側へ転送するためのＷＡＰゲートウエイ（ＷＡＰ−ＧＷ：WAP-Gateway）、及び、受け付けたリクエストを適切な形式に変換して後段に送出するなどしてＷＡＰ標準機能と移動体通信事業者による拡張機能との調整を行うプロキシサーバ（ＪＳＰ：J-Phone Scheme Proxy）とを有するサーバ装置（ＷＡＰ−ＧＷ及びＪＳＰ）である。
また、８は、ＧＧＳＮ６からのRADIUS Accountingプロトコルを終端し、ユーザごとのセッション管理及びセッションログの生成などを行うＲＡＤＩＵＳサーバ８ａを備えるとともに、ＷＡＰ／ＭＭＳサービス加入者がウェブやメール等のサービスを利用する際に必要なユーザ情報や移動端末の能力に関する情報（UE-Profile）等を一元管理し、クライアント（サーバ装置７など）からの要求に応じて必要な情報を提供する情報管理サーバ（Ｒ２Ｍ：RADIUS & Repository Manager）である。

９は全加入者情報を一元管理するディレクトリ・サーバ（ＤＩＲ：Directory Server）である。この加入者情報は、全世代、全地域間で共用されるものであり、ＤＩＲ９はＤＲＳ１０の情報元になっている。１０はディレクトリ・レプリカ・サーバ（ＤＲＳ：Directory Replica Server）であり、一定間隔（例えば、１分間隔）でＤＩＲ９から加入者情報をローカルにコピーして保持することにより、照会要求に対して加入者情報を提供する。これにより、ＤＩＲ９の障害時においても、サービス（オーダー・エントリーを除く）を継続して提供することができる。
１１は、前記サーバ装置（ＷＡＰ―ＧＷ及びＪＳＰ）７の後段に接続され、クライアントからのリクエストをオリジン・サーバ１３との間で仲介するウェブ・ゲートウエイ（ＷＧＷ：Web Gateway）である。また、１２はインターネットであり、コンテンツ・プロバイダなどのオリジン・サーバ（Origin Server：指定されるリソースが存在するか、あるいは生成されるサーバ）１３が接続されている。

前記情報管理サーバ（Ｒ２M）８について図２を参照して説明する。なお、この図においては、前記サーバ装置（ＷＡＰ−ＧＷ及びＪＳＰ）７をＷＡＰゲートウエイ部（ＷＡＰ−ＧＷ）７ａとプロキシサーバ部（ＪＳＰ）７ｂに分割して示している。また、Ｒ２Ｍ８中のＲＡＤＩＵＳサーバ８ａについては明示していない。
図示するように、Ｒ２Ｍ８は、ＲＡＤＩＵＳサーバ８ａで管理されるユーザごとのセッション情報を保持するデータベース（RAD Master）２０、加入者に一意に割り当てられる移動体通信事業者独自のユーザＩＤ（ＵＩＤ：User ID）等の通知にユーザが同意したか否か、抑止対象とするＵＲＬ（Uniform Resource Locators）をユーザが持つか否かなどの各ユーザに固有の設定情報であるセルフケア・プロファイル（Selfcare-Profile）情報を保持するデータベースであるセルフケアＤＢ（Selfcare DB）２１、移動端末１の機種名および性能や能力を表すパラメータを機種ごとに保持しているCC/PP仕様（http://www.w3.org/Mobile/CCPP/）に準拠したデータベースであるＣＣ／ＰＰレポジトリ（CC/PP Repository：Composite Capability / Preference Profile Repository）２２、及び、前記セルフケアＤＢ２１、前記ＣＣ／ＰＰレポジトリ２２、前記ディレクトリ・レプリカ・サーバ（ＤＲＳ）１０、又は、機種情報や性能を示す情報からなる移動端末情報（UE-Profile）が格納されている移動端末製造業者が構築しているデータベースであるプロファイル・レポジトリ（Profile Repository）３０を参照して、セッション中のユーザにかかるセッション情報（Acct-Profile）、ユーザエージェントのプロファイル情報（UA-Profile）、移動端末情報（UE-Profile）、セルフケア・プロファイル情報（Selfcare-Profile）、ユーザ情報（User-Profile）からなるプロファイル情報を作成してセッションが継続している間はメモリ上にキャッシュしているプロファイル部（Profile）２３を備えており、前記プロキシサーバ部（ＪＳＰ）７ｂなどからのリクエストに応じて対応する情報を柔軟に提供することができるようになされている。
なお、ここで、前記セルフケア・プロファイル情報が前述した各ユーザごとの設定情報（各ユーザに固有の設定情報）に対応している。

また、前記プロキシサーバ部７ｂには、その内容が教育上好ましくないＵＲＬなどがグループ又はジャンル別に記録されたリスト（抑止ＵＲＬリスト）が複数記録されており、前記Ｒ２Ｍ８には、各ユーザごとにその抑止対象とするＵＲＬを前記抑止ＵＲＬリストを指示する情報で指定したユーザごとのアクセス情報も記憶されている。

このように構成された本発明の移動体通信システムにおいて移動端末からウェブサービスを利用するときのシーケンスについて図３を参照して説明する。
移動端末（ＵＥ）１上で動作しているウェブブラウザなどのユーザエージェント（ＵＡ）がウェブコンテンツを取得するとき、「1) Activate PDP Context Request」がＳＧＳＮ５に送出される。ＳＧＳＮ５は、これを受けて、移動端末１の加入者に割り当てられた国際識別番号（ＩＭＳＩ：International Mobile Subscriber Identity）及び移動端末１の電話番号（ＭＳＩＳＤＮ：Mobile Station ISDN number）などが添付された「2) Create PDP Context Request」を生成し、ＧＧＳＮ６に送る。

「2) Create PDP Context Request」を受信したＧＧＳＮ６は、前記移動端末１に割り当てるＩＰアドレスを払い出し、前記情報管理サーバ（Ｒ２Ｍ）８内のＲＡＤＩＵＳサーバ８ａに対して、RADIUSアカウンティングリクエスト「3) Radius Accounting Request (Accounting-start)」を送出する。このRADIUSアカウンティングリクエストには、払い出されたＩＰアドレス、ＭＳＩＳＤＮあるいはＩＭＳＩなどが添付されている。

「3) Radius Accounting Request (Accounting-start)」を受信したＲＡＤＩＵＳサーバ８ａは、それに添付されている情報をユーザごとのセッション情報としてデータベース（RAD Master）２０に登録する（図２の(1)）とともに、「4) Radius Accounting Replication」を前記サーバ装置ＷＡＰ−ＧＷ及びＪＳＰ７に送出して、該セッション情報の複製（レプリカ）を保持させる（図２の(2)）。ここで、保持させるセッション情報には、少なくとも、クライアント（ＵＥ）のＩＰアドレス、ＭＳＩＳＤＮ、ＩＭＳＩが含まれている。また、前記ＲＡＤＩＵＳサーバ８ａは、情報管理サーバ（Ｒ２Ｍ）８のプロファイル部２３にも前記セッション情報を保存させる。
前記ＲＡＤＩＵＳサーバ８ａは、前記「4) Radius Accounting Replication」を送信したＷＡＰ−ＧＷ及びＪＳＰ７からレスポンス「5) Radius Accounting Replication Ack」を受信すると、ＧＧＳＮ６に「6) Radius Accounting Response (Accounting-start)」を送出する。これを受けてＧＧＳＮ６は、クライアント（ＵＥ）に対して払い出されたＩＰアドレスが添付された「Create PDP Context Response」をＳＧＳＮ５に対して送信し、以後、ユーザエージェント（ＵＡ）とＷＡＰ−ＧＷ及びＪＳＰ７との間でＴＣＰ（Transmission Control Protocol）セッションを確立することができるようになる。

ここで、前記Ｒ２Ｍ８は、「3) Radius Accounting Request (Accounting-start)」を受信すると、そのユーザのセルフケア・プロファイル情報を取得して前記プロファイル部２３にキャッシュしておくために、前記セルフケアＤＢ２１に「7) Get Selfcare-Profile」リクエストを送る。前記セルフケアＤＢ２１にそのユーザのセルフケア・プロファイル情報が格納されているときは、取得されたセルフケア・プロファイル情報は、前記プロファイル部２３にキャッシュされる。また、User-Profile情報やUE-Profile情報なども前記プロファイル部２３にキャッシュされる（図２の(3)）。
また、前記Ｒ２Ｍ８は、「3) RADIUS Accounting Request (Acct-start)」を受信すると、前記ＤＲＳ１０に対してそのユーザのＭＳＩＳＤＮを添付した「8) User-Profile get Req」リクエストを送信する。そして、前記ＤＲＳ１０から「9) User-Profile get Res」により、そのユーザのユーザ情報（User-Profile）を取得して、その情報を前記プロファイル部２３にキャッシュする。

一方、「6) Radius Accounting Response (Accounting-start)」を受信し、前記移動端末１との間でＴＣＰセッションが張られると、ユーザエージェントからオリジン・サーバ１３に対してＨＴＴＰリクエスト「10) HTTP Req」が送出される（図２の(4)）。
前記「10) HTTP Req」を受信したＷＡＰ−ＧＷ及びＪＳＰ７は、前述のようにして保管しているセッション情報のレプリカを参照して、対応するセッション情報のレプリカが存在するとともに加入者情報が一致した場合にのみ、そのＨＴＴＰリクエストを受け付ける。

「10) HTTP Req」を受け付けたＷＡＰ−ＧＷ及びＪＳＰ７は、前記Ｒ２Ｍ８に対し、「11) Profile get Request」を送信し、Ｒ２Ｍ８から「14) Profile get Response」を受け取って、プロファイル情報の取得と補完を行う。ここで、前記プロファイル部２３には、「12) Get UE-Profile」により前記ＣＣ／ＰＰレポジトリ２２からUE-Profile情報がキャッシュされるなどして、必要なプロファイル情報がキャッシュされている（「13) Complete Profile」）。
しかし、そのユーザが初めてウェブアクセスをしたときには、前記セルフケアＤＢ２１にそのユーザの設定情報が格納されていないため、前記Ｒ２Ｍ８は、ＷＡＰ−ＧＷ及びＪＳＰ７に対して「14) Profile get Response(Selfcare-Profileなし)」を送信する。
ＷＡＰ−ＧＷ及びＪＳＰ７は、「14) Profile get Response(Selfcare-Profileなし)」を受信すると、移動端末１のユーザに対し、その固有の設定情報を保存することに同意するかどうかの回答を求める「15) 同意画面」を送出し、ユーザから「16) 同意」の返信があると、Ｒ２Ｍ８に対し「17) Selfcare-Entry作成指示」を送信する。
そして、該「17) Selfcare-Entry作成指示」を受信したＲ２Ｍ８は、セルフケアＤＢ２１に該ユーザのエントリを作成する（「18) Create Selfcare-Profile」）。
なお、同意の返信がないときは、セルフケアＤＢ２１にそのユーザのエントリは作成されない。

図２に戻って、前記プロキシサーバ部７ｂは、まず、Ｒ２Ｍ８のプロファイル部２３にキャッシュされているそのユーザに関するプロファイル情報を取得する（図２の(5)）。ここで、そのセルフケア・プロファイル情報中の前記ＵＲＬ抑止フラグがセットされているときは、そのユーザのＭＳＩＳＤＮをキーとして前記アクセス情報を参照し、そのユーザがアクセスを制限すべきとして設定している抑止ＵＲＬリスト名を取得する。そして、そのＨＴＴＰリクエストに含まれているRequest-URIが設定されている抑止ＵＲＬリスト中のＵＲＬと一致しているか否かを判定し、一致しているときは、ユーザエージェントに対してエラー応答（HTTP Status Code 403 Forbidden）を返す。このようにして、好ましくないウェブページの閲覧を抑止することができる。

Request-URIがそのユーザが設定している抑止ＵＲＬリスト中に含まれていないとき（抑止対象でないとき）は、その「HTTP Req」の拡張ヘッダに移動端末情報（UE-Profile）を補完する必要があるか否かを判定し、必要があるときには、前記プロファイル部２３から取得したプロファイル情報の移動端末情報（UE-Profile）に基づいてＨＴＴＰ拡張ヘッダを補完する（図２の(6)）。
すなわち、移動体通信事業者の独自規格に対応した移動端末におけるユーザエージェントは、移動体通信事業者が独自に定義した各種のＨＴＴＰ拡張ヘッダを送出しているが、ＷＡＰ対応端末においては、そのような拡張ヘッダを送出させることはできない。そこで、前記プロキシサーバ部７ｂは、前記ＨＴＴＰリクエストのUser-Agentヘッダの一部に指定の文字列が含まれていた場合に、そのＨＴＴＰリクエストを送出した移動端末がその移動体通信事業者の独自規格に対応した移動端末であると判定し、含まれていないときにＷＡＰ対応端末であると判定する。そして、ＷＡＰ対応端末からのＨＴＴＰリクエストについては、前記プロファイル部２３などに記憶されているプロファイル情報を用いて、受け付けたＨＴＴＰリクエストの拡張ヘッダに不足している移動端末情報などを補完して後続するノードに転送するようにしている。これにより、移動体通信事業者の独自規格に対応した移動端末と同等のサービスをＷＡＰ対応端末にも提供することができる。

次に、プロキシサーバ部７ｂは、この拡張ヘッダとRequest-URIが少なくとも添付されているＨＴＴＰリクエストをＷＧＷ１１を介してオリジン・サーバ１３に送信する（図２の(7)）。
オリジン・サーバ１３は、要求されたコンテンツを返送するＨＴＴＰレスポンスを前記プロキシサーバ部７ｂに送出する（図２の(8)）。このとき、オリジン・サーバ１３はＨＴＴＰリクエストの拡張ヘッダを参照することにより移動端末１の性能を知ることができ、移動端末１の性能を十二分に発揮できるように性能に応じたコンテンツを返送することができる。
このようにして、移動端末１から要求されたコンテンツを取得したプロキシサーバ部７ｂは、コンテンツを要求した移動端末１の性能を表す移動端末情報を参照し、必要に応じて、この移動端末情報に基づいて移動端末１の性能を十二分に発揮できるようにコンテンツの変換処理を行う（図２の(9)）。

次いで、ＷＡＰ−ＧＷ７ａは変換後のコンテンツを返送するＨＴＴＰレスポンスをＧＧＳＮ６を介してユーザエージェントに送出する（図２の(10)）。
ＨＴＴＰレスポンスを受信したユーザエージェントは、取得したコンテンツを表示し、ユーザエージェントと前記ＷＡＰ−ＧＷ７ａ間のＴＣＰセッションが終了される。次いで、ユーザエージェントからの通信を終了させるための通信終了要求に応じてＧＧＳＮ６から「19) Radius Accounting Req(Accounting-stop)」が送出される（図３）。
このリクエストを受信したＲＡＤＩＵＳサーバ８ａは、該当するユーザのプロファイル情報及びRADIUS情報を破棄し（「20) Delete Profile」）、「21) Radius Accounting Response (Accounting-stop)」をＧＧＳＮ６に送出する（図３）。
これにより、ユーザエージェントとサーバ装置（ＷＡＰ−ＧＷ及びＪＳＰ）７との間の通信が終了する。

このように、本発明によれば、ユーザからのアクセスが発生したときに、前記セルフケアＤＢ２１を参照し、そのユーザのエントリがないときに、そのユーザのセルフケア・プロファイル情報（設定情報）を記憶するようにしている。したがって、従来のように、ユーザが契約したときに、そのユーザがウェブサービスを利用するか否かにかかわらず一律にそのユーザの設定情報をデータベースに格納する場合と比較して、無駄なトラフィックの発生やシステムリソースの浪費を回避することができる。
なお、このようにして作成した前記セルフケアＤＢ２１の各エントリは、ユーザのサービス解約などにより発生される「Del_Sub」のオーダーエントリ（Ｏ／Ｅ）を受け取ったときに削除されるようになされている。これにより、不必要なデータがシステム内に残ることがなく、システムリソースの浪費を防止することができる。

本発明の移動体通信システムの全体構成を示すブロック図である。 情報管理サーバ（Ｒ２Ｍ）について説明するための図である。 移動端末からウェブサービスを利用するときのシーケンスの要部を示す図である。

符号の説明

１：移動端末（ＵＥ）、２：無線基地局（ＢＴＳ）、３：無線基地局制御装置（ＲＮＣ）、４：移動通信交換局（ＭＳＣ）、５：ゲートウエイ（ＳＧＳＮ）、６：ゲートウエイ（ＧＧＳＮ）、７：サーバ装置（ＷＡＰ−ＧＷ及びＪＳＰ）、７ａ：ＷＡＰゲートウエイ部（ＷＡＰ−ＧＷ）、７ｂ：プロキシサーバ部（ＪＳＰ）、８：情報管理サーバ（Ｒ２Ｍ）、８ａ：ＲＡＤＩＵＳサーバ、９：ディレクトリ・サーバ（ＤＩＲ）、１０：ディレクトリ・レプリカ・サーバ（ＤＲＳ）、１１：ウェブ・ゲートウエイ（ＷＧＷ）、１２：インターネット、１３：オリジン・サーバ

Claims (2)

1. 移動体通信網とインターネットなどのＩＰネットワークとの間に設けられるゲートウエイ装置と前記移動体通信網とに接続されたサーバ装置であって、
   ユーザからのＨＴＴＰリクエストが発生した際に、ユーザごとの設定情報を格納しているデータベースにそのユーザの情報が含まれているか否かを判定し、含まれていない場合に、そのユーザに関する設定情報を前記データベースに登録するようになされていることを特徴とするサーバ装置。
2. サービス解約時などに前記データベースの当該ユーザのエントリを削除するようになされていることを特徴とする請求項１記載のサーバ装置。

Images