(57)【特許請求の範囲】
【請求項１】
各端末から無線ベアラを介して受信するパケットを中継するパケット中継装置と、前記無線ベアラが未設定の端末から送信されるリソース設定要求を受け付けて前記リソース設定要求の送信元の端末と前記パケット中継装置との間の前記無線ベアラを設定する端末信号処理装置とを含み、前記パケット中継装置が一定時間パケットを受信しない端末と前記パケット中継装置との間の前記無線ベアラを前記端末信号処理装置が解放し、その後、前記無線ベアラが解放された端末がパケットを前記パケット中継装置に送信する前にリソース再設定要求を前記端末信号処理装置に送信し、前記リソース再設定要求を受信した前記端末信号処理装置が前記リソース再設定要求の送信元の端末と前記パケット中継装置との間の前記無線ベアラを再設定し、前記リソース再設定要求の送信元の端末が再設定された前記無線ベアラを用いてパケットを前記パケット中継装置へ送信するネットワークシステムにおいて、前記端末信号処理装置が集中的に受信する前記リソース再設定要求の送信元の端末を検出する方法であって、
前記各端末について、前記パケット中継装置におけるパケットの受信間隔が前記一定時間より長いか否かを判定し、
前記判定の結果を用いて、前記パケット中継装置が前記一定時間より長い受信間隔で端末からパケットを受信することを１つのイベントとし、時間帯毎に、前記イベントが発生した数と、前記イベントを発生させたパケットの送信元の各端末の識別子とを記憶装置に記憶し、
毎日の前記時間帯毎の前記イベントが発生した数及び前記イベントを発生させたパケットの送信元の端末の識別子の記憶を所定期間に亘って行い、毎日前記イベント数が閾値を超える時間帯があるとされる条件を満たす場合に、前記閾値を超える時間帯において前記イベントを発生させたパケットの送信元の端末となっている端末を、前記端末信号処理装置が集中的に受信する前記リソース再設定要求の送信元の端末として検出する
ことを含む端末検出方法。
【請求項２】
前記閾値を超える時間帯において前記イベントを発生させたパケットの送信元の端末となっている各端末が前記端末信号処理装置へ前記リソース再設定要求を送信するタイミングを、前記端末信号処理装置への前記リソース再設定要求の到着時刻が分散するように調整する処理を行うことを決定する
ことをさらに含む請求項１に記載の端末検出方法。
【請求項３】
各端末から無線ベアラを介して受信するパケットを中継するパケット中継装置と、前記無線ベアラが未設定の端末から送信されるリソース設定要求を受け付けて前記リソース設定要求の送信元の端末と前記パケット中継装置との間の前記無線ベアラを設定する端末信号処理装置とを含み、前記パケット中継装置が一定時間パケットを受信しない端末と前記パケット中継装置との間の前記無線ベアラを前記端末信号処理装置が解放し、その後、前記無線ベアラが解放された端末がパケットを前記パケット中継装置に送信する前にリソース再設定要求を前記端末信号処理装置に送信し、前記リソース再設定要求を受信した前記端末信号処理装置が前記リソース再設定要求の送信元の端末と前記パケット中継装置との間の前記無線ベアラを再設定し、前記リソース再設定要求の送信元の端末が再設定された前記無線ベアラを用いてパケットを前記パケット中継装置へ送信するネットワークシステムに含まれる情報処理装置であって、
記憶装置と、制御装置とを含み、
前記制御装置が、
前記各端末について、前記パケット中継装置におけるパケットの受信間隔が前記一定時間より長いか否かを判定する処理と、
前記判定の結果を用いて、前記パケット中継装置が前記一定時間より長い受信間隔で端末からパケットを受信することを１つのイベントとし、時間帯毎に、前記イベントが発生した数と、前記イベントを発生させたパケットの送信元の各端末の識別子とを前記記憶装置に記憶する処理と、
毎日の前記時間帯毎の前記イベントが発生した数及び前記イベントを発生させたパケットの送信元の端末の識別子の記憶を所定期間に亘って行い、毎日前記イベント数が閾値を超える時間帯があるとされる条件を満たす場合に、前記閾値を超える時間帯において前記イベントを発生させたパケットの送信元の端末となっている端末を、前記端末信号処理装置が集中的に受信する前記リソース再設定要求の送信元の端末として検出する処理とを行う
情報処理装置。
【請求項４】
各端末から無線ベアラを介して受信するパケットを中継するパケット中継装置と、前記無線ベアラが未設定の端末から送信されるリソース設定要求を受け付けて前記リソース設定要求の送信元の端末と前記パケット中継装置との間の前記無線ベアラを設定し、前記パケット中継装置が一定時間パケットを受信しない端末と前記パケット中継装置との間の前記無線ベアラを解放し、その後、前記無線ベアラが解放された端末がパケットを前記パケット中継装置へ送信する前に送信するリソース再設定要求を受信した場合に前記リソース再設定要求の送信元の端末と前記パケット中継装置との間の無線ベアラを再設定する、端末信号処理装置と、情報処理装置とを含む情報処理システムにおいて、
前記情報処理装置は、記憶装置と、制御装置とを含み、
前記制御装置は、
前記各端末について、前記パケット中継装置におけるパケットの受信間隔が前記一定時間より長いか否かを判定する処理と、
前記判定の結果を用いて、前記パケット中継装置が前記一定時間より長い受信間隔で端末からパケットを受信することを１つのイベントとし、時間帯毎に、前記イベントが発生した数と、前記イベントを発生させたパケットの送信元の各端末の識別子とを前記記憶装置に記憶する処理と、
毎日の前記時間帯毎の前記イベントが発生した数及び前記イベントを発生させたパケットの送信元の端末の識別子の記憶を所定期間に亘って行い、毎日前記イベント数が閾値を超える時間帯があるとされる条件を満たす場合に、前記閾値を超える時間帯において前記イベントを発生させたパケットの送信元の端末となっている端末を、前記端末信号処理装置が集中的に受信する前記リソース再設定要求の送信元の端末として検出する処理とを行
う
情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報処理装置の端末検出方法，情報処理装置，及び情報処理システムに関する。
【背景技術】
【０００２】
無線網とコア網とで形成されるLong Term Evolution（ＬＴＥ）網では、端末（User Equipment:ＵＥと呼ばれる）が通信を行う場合、無線網及びコア網に亘って相手方と通信を行うためのセッションが確立される。セッションの確立後において、一定期間通信がない（ユーザパケットが転送されない）場合、当該セッションに関して割り当てられた無線網やコア網のリソースが解放される。
【０００３】
端末が通信を再開する（ユーザパケットを送信する）ときにリソースが解放されていると、端末は、コアネットワークにある端末信号処理装置へリソース再設定要求のメッセージを送信する。リソース再設定要求を受けた端末信号処理装置は、当該端末のユーザパケットを中継するパケット中継装置に対してリソースの再設定要求を送る。パケット中継装置は、リソース再設定（再割り当て）を行う。これによって、端末は、ユーザパケットを送信することができる。
【０００４】
ところで、端末にインストールされたアプリケーションには、或る時刻（定時）に自動的にユーザパケットを送信するものがある。定時においてユーザパケットを送信するためのリソースが解放されていれば、上記したように、端末はリソース再設定要求を端末信号処理装置へ送る。
【０００５】
上記アプリケーションがインストールされた端末の数が少なくない場合、図１２に示すように、複数の端末が一斉にリソース再設定要求を送信し、複数のリソース再設定要求が集中的に端末信号処理装置に到着することが起こり得る。このようなリソース再設定要求の集中によって、端末信号処理装置及びパケット中継装置におけるリソース再設定処理に係る負荷がバースト的に上昇し、当該処理の輻輳が発生するおそれがあった。
【０００６】
上記のようなバースト的な負荷上昇及び輻輳の発生を回避するための処理が行われている。例えば、Ｃプレーンでのバースト監視によって、リソース再設定要求が集中的に発生する時刻と、リソース再設定要求を送信する端末とを把握する。コアネットワーク側の装置は、上記或る時刻となる前に、各端末を呼び出し、リソース再設定要求の送信を促す。各端末の呼び出しは、タイミングをずらした状態で行われる。このようにして、リソース再設定要求が端末信号処理装置に到来するタイミングを分散させるとともに、上記の或る時刻に到来するリソース再設定要求の数を減らす。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０００−３５４０６５号公報
【特許文献２】特開２００３−００９２２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上記した呼び出し処理の実施に関しては、以下の問題があった。コアネットワーク側で呼び出しを行うことが決定されている端末の中には、上記アプリケーションの動作停止の設定がなされたもの、或いはアプリケーションが削除されたものが含まれ得る。このよう
な端末は、或る時刻となってもリソース再設定要求を送信しないので、上記した呼び出し処理の実施は不要である。
【０００９】
しかしながら、Ｃプレーンの監視では、呼び出し処理の実行によってリソース再設定要求の集中が回避されるため、各端末に対して呼び出し処理が実際に必要か否かを判断することができなった。
【００１０】
本開示は、各端末から送信されるユーザパケットの受信状況に基づき各端末が集中的に発生するリソース設定要求を送信する端末を検出可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本開示は、パケット送信用のリソースが未設定の各端末から送信されるリソース設定要求を受け付けてリソースの設定を行い、その後に各端末から送信されるパケットを中継するネットワークと接続された情報処理装置の端末検出方法であって、
前記情報処理装置が、
前記各端末から送信されたパケットが前回の受信時刻から所定時間経過後に受信されたか否かを判定し、
前記判定の結果を用いて、時間帯毎に、パケットが前記所定時間経過後に受信された数と、前記所定時間経過後に受信されたパケットの送信元の各端末の識別子とを記憶装置に記憶する
ことを含む情報処理装置の端末検出方法である。
【発明の効果】
【００１２】
本開示によれば、各端末から送信されるユーザパケットの受信状況に基づき各端末が集中的に発生するリソース設定要求を送信する端末かを検出可能となる。
【図面の簡単な説明】
【００１３】
【図１】実施形態に係るネットワークシステムの構成例を示す。
【図２】図１に示したＳ−ＧＷのハードウェア構成例を示す。
【図３】図３は、ＣＰＵがプログラムを実行することによってＳ−ＧＷが行う動作を模式的に示す図である。
【図４】図４は、図３に示したＣＰＵの各処理に基づく動作を模式的に示す図である。
【図５】図５は、ＣＰＵで実行される無通信監視処理の例を示すフローチャートである。
【図６】図６は、ＣＰＵで実行されるバースト抑止制御処理の例を示すフローチャートである。
【図７】図７は、ユーザＩＤテーブルのデータ構造例を示す図である。
【図８】図８は、バースト管理ＤＢのデータ構造例を示す図である。
【図９】図９は、ユーザ挙動管理ＤＢのデータ構造例を示す図である。
【図１０】図１０は、実施形態における動作例１を示すシーケンス図である。
【図１１】図１１は、実施形態における動作例１を示すシーケンス図である。
【図１２】図１２は、関連技術の説明図である。
【発明を実施するための形態】
【００１４】
以下、図面を参照して本発明の実施形態について説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
【００１５】
以下の実施形態では、ネットワークにおいて、Ｕプレーン（ユーザプレーン）側の挙動
（パケット受信状況）を分析することにより、Ｃプレーン（制御プレーン）側で発生している、あるいは発生する可能性のあるバースト負荷を推定し、バースト抑止のための処理を行うことを可能とするネットワークシステムについて説明する。
＜ネットワークシステムの構成例＞
図１は、実施形態に係るネットワークシステムの構成例を示す図である。図１において、ネットワークシステムは、ＬＴＥネットワークシステムを例示している。ＬＴＥ網は、無線網１のEvolved Universal Terrestrial Radio Network（ｅＵＴＲＡＮ）とコア網２
のEvolved Packet Core（ＥＰＣ： SAE（System Architecture Evolution）とも呼ばれる）とで形成されている。
【００１６】
無線網１は、無線基地局（基地局：ｅＮｏｄｅＢ（ｅＮＢ）と呼ばれる）３で形成される。基地局３は、無線端末（端末：ＵＥ）４とのランダムアクセス手順を通じて端末４と無線接続される。
【００１７】
コア網２は、Ｃプレーンを扱うMobility Management Entity（ＭＭＥ）５と、ユーザパケットを扱うサービングゲートウェイ（Ｓ−ＧＷ）６と、パケットデータネットワークゲートウェイ（Ｐ−ＧＷ）７とを含んでいる。また、コア網２には、後述するバースト抑止処理を実行するアクセス管理装置９が配置され、Ｓ−ＧＷ６と接続されている。ユーザパケットは、「パケット」の一例である。
【００１８】
ＭＭＥ５は、ネットワーク制御を扱うＣプレーンのアクセスゲートウェイである。ＭＭＥ５は、基地局３を介して端末４と通信する端末信号処理装置であり、端末４の呼制御（呼確立や呼切断）を行う。また、ＭＭＥ５は、シーケンス制御及びハンドオーバ制御，端末４の待受時の位置管理（無線端末の位置登録），基地局３に対する着信時の呼び出し（ページング），端末４の認証（ＮＡＳ（Non Access Stratum））などを行う。ＭＭＥ５は、「リソース設定を制御する装置」の一例である。
【００１９】
Ｓ−ＧＷ６は、ユーザパケットを中継するゲートウェイ（パケット中継装置）であり、ＬＴＥのユーザデータを２Ｇ（例えばＧＳＭなど）や３Ｇ（Ｗ−ＣＤＭＡ）のシステムに接続する処理を行う。Ｓ−ＧＷ６は、「情報処理装置」の一例である。
【００２０】
Ｐ−ＧＷ６は、Packet Data Network（ＰＤＮ）８のゲートウェイであり、ユーザパケ
ットをＰＤＮ８と接続された外部ネットワーク（インターネットやイントラネット）に接続するためのゲートウェイである。Ｐ−ＧＷ６は、課金用データ収集，Quality of Service(ＱｏＳ)制御，パケットフィルタリングなどを行う。
【００２１】
端末４は、無線通信機能を有する情報処理装置（通信機器）であり、例えば、スマートフォン，タブレット端末などである。端末４は、基地局３と無線接続（Radio Resource Connection(ＲＲＣ)接続）を行い、基地局３やＭＭＥ５と制御信号のやりとり（Ｃプレー
ンの通信）を行う。
【００２２】
具体的には、基地局３と無線接続された端末４は、アタッチ手順と呼ばれる端末４をＬＴＥ網に登録する処理を行う。アタッチ手順はＣプレーンで行われる。端末４は、アタッチ要求信号と呼ばれる制御信号を基地局３経由でＭＭＥ５へ送る。ＭＭＥ５は、アタッチ要求を受け付けると、端末４の認証を行う。また、ＭＭＥ５は、Home Subscriber Server（ＨＳＳ：加入者サーバ。図示せず）に対して端末４の位置登録を行う。
【００２３】
続いてＭＭＥ５は、ベアラ（ユーザパケットの経路）設定要求信号と呼ばれる制御信号をＳ−ＧＷ６に送る。Ｓ−ＧＷ６は、ベアラ設定要求信号に従い、Ｓ−ＧＷ６とＰ−ＧＷ７との間でベアラ設定を行う。ベアラ設定が行われると、ＭＭＥ５は、無線ベアラ設定要
求（アタッチ受け入れ）信号と呼ばれる制御信号を基地局３を介して端末４に送る。
【００２４】
このとき、端末４と基地局３との間で無線ベアラが設定される。その後、端末４がアタッチ完了信号を基地局３を介してＭＭＥ５に送る。すると、ＭＭＥ５は、Ｓ−ＧＷ６にベアラ更新の制御信号を与え、Ｓ−ＧＷ６は、Ｓ−ＧＷ６と基地局３との間に無線ベアラを設定する。
【００２５】
このようにして、端末４〜基地局３〜Ｓ−ＧＷ６〜Ｐ−ＧＷ７を経由するベアラが設定され、端末４から送信されるユーザパケットが上記ベアラを通ってＰ−ＧＷ７へ到達し、ＰＤＮ８へ送信される。ベアラ設定において、無線網１やコア網２のリソースが使用される。すなわち、リソース設定がなされる。
【００２６】
端末４と基地局３との間は、Packet Data Convergence Protocol（ＰＤＣＰ）と呼ばれるプロトコルを用いてユーザパケット（例えば、ＩＰパケット）が転送される。一方、基地局３とＳ−ＧＷ６との間には、General Packet Radio Service Tunneling Protocol for User Plane（ＧＴＰ−Ｕ）と呼ばれるプロトコルを用いたトンネル（ＧＴＰ−Ｕパス）が生成され、ユーザパケットはＧＴＰ−Ｕパスを通ってＳ−ＧＷ６へ転送される。
【００２７】
端末４がユーザパケットを送信しない状態になってから一定時間が経過すると、端末４と基地局３との間の無線ベアラと基地局３とＳ−ＧＷ６との無線ベアラとが解放される。無線ベアラの解放により、無線ベアラ設定に用いたリソースが解放される。解放されたリソースは他の用途に使用できる。このため、無線リソースの効率利用が図られる。
【００２８】
その後、端末４がユーザパケットの送信を開始するにあたり、無線ベアラが解放されている場合には、端末４はＭＭＥ５にサービス要求（リソース再設定要求に相当する）の制御信号（以下「サービス要求」と表記）を送る。ＭＭＥ５は、Ｓ−ＧＷ６に対し無線ベアラ設定要求信号を送る。これによって、端末４からＳ−ＧＷ６までの無線ベアラが再設定され、端末４はユーザパケットを送信可能となる。サービス要求は、「リソース再設定要求」の一例である。
【００２９】
図１には、複数の（ｎ個（ｎは自然数））の端末４（端末＃１〜＃ｎ）が示されている。複数の端末４のそれぞれには、例えば、毎日決まった時刻（定時）にユーザパケットを送信するアプリケーションプログラムがインストールされていると仮定する。この仮定において、定時となったときに、各端末＃１〜＃ｎにおいて無線ベアラが解放されていると、各端末＃１〜＃ｎが一斉にサービス要求（リソース再設定要求）をＭＭＥ５へ送信する。
【００３０】
この場合、サービス要求がＭＭＥ５に集中し、無線ベアラ設定要求信号をＳ−ＧＷ６へ送るＭＭＥ５、及び無線ベアラ設定信号に従って無線ベアラを設定するＳ−ＧＷ６でバースト的な負荷（バースト負荷）が発生し、処理が輻輳し得る。以下、上記のようなバースト負荷を回避するためにＣプレーンでの制御を要する端末４を検出（識別）するＳ−ＧＷ６について説明する。
＜Ｓ−ＧＷのハードウェア構成例＞
図２は、Ｓ−ＧＷ６として使用可能な情報処理装置（コンピュータ）のハードウェア構成例を示す。Ｓ−ＧＷ６のハードウェア構成としては、パーソナルコンピュータ（ＰＣ）やワークステーション（ＷＳ）のような汎用のコンピュータ，或いはサーバマシンのような専用のコンピュータが備えるハードウェアアーキテクチャを適用可能である。
【００３１】
図２において、Ｓ−ＧＷ（情報処理装置）６は、バスＢ（内部通信路）を介して接続された通信インタフェース（通信Ｉ／Ｆ）１１と、Central Processing Unit（ＣＰＵ）１
２と、メインメモリ（ＭＭ：主記憶装置）１３と、ハードウェアディスクドライブ（ＨＤＤ）１４とを含む。
【００３２】
通信Ｉ／Ｆ１１は、Ｐ−ＧＷ７，ＭＭＥ５，基地局３と接続される物理回線（物理リンク）を収容する。通信Ｉ／Ｆ１１は、例えば、ネットワークインタフェースカード（ＮＩＣ）やＬＡＮ（構内交換網）カードを適用することができる。通信Ｉ／Ｆ１１は、「通信装置」の一例である。
【００３３】
ＭＭ１３は、揮発性記録媒体の一例であるRandom Access Memory（ＲＡＭ）と、不揮発性記録媒体の一例であるRead Only Memory（ＲＯＭ）とを含む。ＭＭ１３におけるＲＡＭはＣＰＵ１１の作業領域として使用される。
【００３４】
ＨＤＤ１４は、補助記憶装置の一例である。ＭＭ１３中のＲＯＭ及びＨＤＤ１４は、オペレーティングシステム（ＯＳ）及び様々なアプリケーションプログラムを含む複数のコンピュータプログラムと、各プログラムの実行に際して使用されるデータとを記憶する。
【００３５】
ＭＭ１３及びＨＤＤ１４は、「記憶装置」、「記憶媒体」、「記憶部」の一例である。不揮発性記憶媒体又は補助記憶装置としては、Electrically Erasable Programmable ROM（ＥＥＰＲＯＭ），フラッシュメモリ，Solid State Drive（ＳＳＤ）などの少なくとも
１つを用いることもできる。
【００３６】
ＣＰＵ１２は、ＨＤＤ１４やＲＯＭに記憶（インストール）されたプログラムをＲＡＭにロードして実行する。これによって、Ｓ−ＧＷ８は、ベアラ設定（ＧＴＰ−Ｕパスの設定など）のようなＣプレーンに係る処理と、ユーザパケット（Ｕプレーン）の転送に係る処理と、以下に説明するＣプレーンのバースト負荷発生の要因となる端末４を検出（識別）する処理などを実行する。ＣＰＵ１２は、「プロセッサ」、「制御装置」、「制御部」の一例である。また、ＣＰＵ１２は、「判定部」、「記憶処理部」の一例である。
【００３７】
なお、ＣＰＵ１２によって実行される処理の一部又は全部は、ハードウェアロジックによって実装されることができる。ハードウェアロジックを実行する機構としては、例えば、集積回路（ＩＣ，ＬＳＩ，Application Specific Integrated Circuit（ＡＳＩＣ））
を適用することができる。或いは、プログラマブルロジックデバイス（ＰＬＤ，例えばField Programmable Gate Array（ＦＰＧＡ））を適用することができる。
【００３８】
図３は、ＣＰＵ１２がプログラムを実行することによってＳ−ＧＷ６が行う動作を模式的に示す図である。図４は、図３に示したＣＰＵの各処理に基づく動作を模式的に示す図である。図５は、ＣＰＵ１２で実行される無通信監視処理２４の例を示すフローチャートである。図６は、ＣＰＵ１２で実行されるバースト抑止制御処理３１の例を示すフローチャートである。
【００３９】
図３において、ＣＰＵ１２は、Ｕプレーン処理２０と、Ｃプレーン処理３０とを行う。Ｕプレーン処理２０では、パケット受信処理２１と、転送処理２２と、パケット送信処理２３と、無通信監視処理２４と、タイマ管理２５とが実行される。また、無通信監視処理２４において用いられるユーザＩＤテーブル２６がＭＭ１３又はＨＤＤ１４に記憶される。
【００４０】
一方、Ｃプレーン処理３０では、バースト抑止制御処理３１が実行される。また、Ｃプレーン処理３０に係る情報を記憶するデータベース（ＤＢ）として、バースト管理ＤＢ３２と、ユーザ挙動管理ＤＢ３３とがＭＭ１３又はＨＤＤ１４に記憶される。
【００４１】
図４において、パケット受信処理２１では、基地局３から送信され通信Ｉ／Ｆ１１で受信されたユーザパケットの受信処理が実行される。転送処理２２では、ユーザパケットの転送先が決定される。転送処理２２では、受信されたユーザパケットに関する受信通知が無通信監視処理に与えられる（図４）。
【００４２】
受信通知は、ユーザパケットに設定されていたＴＥＩＤ−Ｕ（Tunnel Endpoint Identifier for User Plane：ＧＴＰ−Ｕパスの識別子）を含む。パケット送信処理２３では、
転送先へ向けたユーザパケットを通信Ｉ／Ｆ１１から送信するための処理が実行される。なお、図４に示す複数の円柱は、ユーザパケットの転送経路を示す。
【００４３】
無通信監視処理２４では、タイマ管理２５で管理されるタイマを用いた無通信監視が行われる。タイマ管理２５は、ＧＴＰ−Ｕパス（端末４）毎に用意された複数のタイマを管理している。各タイマは、ＴＥＩＤ−Ｕと関連づけられている。
【００４４】
無通信監視処理２４にてタイマの満了がタイマ管理２５から通知されると、Ｓ−ＧＷ６は、対応する端末４に関する無線ベアラの解放処理を行う。これによって、Ｓ−ＧＷ６と端末４との間の無線ベアラが解放される。
【００４５】
また、無通信監視処理２４は、転送処理２５からユーザパケットの受信通知を受け取ると（図５，０１）、タイマ管理２５に対し、受信通知に含まれたＴＥＩＤ−Ｕに対応するタイマのリセットを指示する。タイマ管理２５は、リセット指示に応じたタイマをリセットするとともに、当該タイマの計時時間（リセット時の経過時間）を無通信監視処理２４に返す。
【００４６】
計時時間を受け取った無通信監視処理２４は、当該計時時間（経過時間）が所定の閾値（所定値）以上か否かを判定する（図５，０２）。計時時間が閾値以下であれば（０２，ＮＯ）、処理が０１に戻る。これに対し、計時時間が閾値以上であれば（０２，ＹＥＳ）、無通信監視処理２４は、バースト管理ＤＢ３２の更新処理を行う（図５,０３）。
【００４７】
所定の閾値は、端末４がユーザパケット送信のためにＭＭＥ５にリソース再設定要求を送信し、リソース（無線ベアラ）再設定の後にユーザパケットが送信され、Ｓ−ＧＷ６に受信される時間を考慮して設定される。計時時間が閾値以上である場合、当該端末４が上記したリソース再設定の後にユーザパケットを送信した可能性が高い。
【００４８】
バースト管理ＤＢ３２の更新処理（図５，０３）では、以下のような処理が実行される。すなわち、無通信監視処理２４は、ユーザＩＤテーブル２６を参照し、ＴＥＩＤ−Ｕに対応するユーザＩＤ（端末４の識別子）を得る。
【００４９】
図７は、ユーザＩＤテーブル２６（テーブル２６）のデータ構造例を示す図である。図４において、テーブル２６は、ＴＥＩＤ−ＵとInternational Mobile Subscriber Identity（ＩＭＳＩ）とのペアを格納する複数のエントリで形成されている。
【００５０】
ユーザＩＤ（端末識別子）として使用されるＩＭＳＩは、端末４（ユーザ）のユニークな識別子である。ＩＭＳＩは、端末４の位置登録に際して、端末４からＭＭＥ５に送られる。Ｓ−ＧＷ６は、例えば、端末４毎のＧＴＰ−Ｕパスの設定を行う場合に、各端末４に対応するＩＭＳＩをＭＭＥ５から受け取り、各ＩＭＳＩと設定したＧＴＰ−Ｕパスとを関連づけてテーブル２６に格納する。これによって、テーブル２６を生成することができる。
【００５１】
本実施形態では、Ｃプレーンにて端末４がＩＭＳＩで管理されることから、ＩＭＳＩを
ユーザＩＤとして用いている。また、Ｓ−ＧＷ６で中継されるユーザパケットは、暗号化されたＩＰパケットがＴＥＩＤ−Ｕでカプセル化されたパケットである。このため、Ｓ−ＧＷ６が、パケットの送信元ＩＰアドレスを得ることができない場合があり得るからでもある。さらに、ＴＥＩＤ−Ｕは、同一の端末４に対して変更され得るものであるのに対し、ＩＭＳＩは、端末４に対して不変の識別子であることも考慮されている。但し、ユーザＩＤは、端末４を一意に識別可能な識別子であれば、ＩＭＳＩ以外の識別子を使用することができる。
【００５２】
無通信監視処理２４は、計時時間が閾値以上、すなわち、前回の受信から今回の受信までの時間長が閾値以上である端末４のユーザパケットの受信をイベントとして検知する。無通信監視処理２４は、当該イベントの発生と、当該イベントに係るユーザＩＤとをバースト管理ＤＢ３２に登録する。
【００５３】
図８は、バースト管理ＤＢ３２のデータ構造例を示す図である。図８において、バースト管理ＤＢ３２は、単位時間（図８の例では１分）の時間帯毎に、各時間帯（時刻）で発生したイベント発生の件数（イベント数）が格納されるように形成されている。さらに、バースト管理ＤＢ３２には、各イベント数と関連づけて、イベント発生の契機となったユーザパケットを送信した端末４（ＩＭＳＩ）のリスト（ユーザリスト）が記憶される。単位時間長（時間帯の長さ）は適宜設定可能である。単位時間長の調整によりユーザパケットの揺らぎや遅延を吸収することができる。
【００５４】
無通信監視処理２４は、イベントが発生した場合、バースト管理ＤＢ３２を参照し、イベントに係るパケットの受信時刻が属する時間帯に対応するイベント数をインクリメントするとともに、当該イベントに対応するＩＭＳＩをユーザリストに登録する。
【００５５】
図４に戻って、バースト抑止制御処理３１は、例えば、定期的に起動し、以下の処理を行う。バースト抑止制御処理３１は、無通信監視処理２４と非同期で行われる。但し、両者が同期するようにバースト抑止制御処理３１が実行されても良い。バースト抑止制御処理３１は、バースト管理ＤＢ３２の読み込みを行う（図６，１１）。
【００５６】
次に、バースト抑止制御処理３１は、バースト的なユーザパケットの受信がなされた時間帯があるか否かを判定する（図６，１２）。当該判定は、各時間帯のイベント数に関して、イベント数が予め用意された（例えばＨＤＤ１４に記憶された）閾値を超過するか否かによって行われる。１２の処理においてイベント数が閾値を超える時間帯がなければ（１２，ＮＯ）、バースト抑止制御処理３１は終了する。これに対し、イベント数が閾値を超える時間帯があれば（１２，ＹＥＳ）、処理が１３に進む。
【００５７】
１３以降の処理は、１２の処理で発見されたイベント数が閾値を超過する時間帯のそれぞれに対して行われる。１３において、バースト抑止制御処理３１は、イベント数が閾値を超過する時間帯と関連づけられたユーザリストに登録された各ユーザＩＤ（端末４）に関する挙動分析を行う（図６，１３）。挙動分析は、ユーザ挙動管理ＤＢ３３における該当ユーザＩＤの挙動情報を取得することで行われる。
【００５８】
図９は、ユーザ挙動管理ＤＢ３３のデータ構造例を示す図である。図９において、ユーザ挙動管理ＤＢ３３には、ユーザＩＤ毎に、所定期間内のパケットの受信状況（挙動）を示す情報（挙動情報）が記憶される。ユーザＩＤは、バースト管理ＤＢ３２のユーザリストに登録された（バースト受信の発生に関与した端末４の）ＩＭＳＩ（ユーザＩＤ）である。挙動情報は、対応するユーザＩＤ（ＩＭＳＩ）を有する端末４の所定期間（図９では数日内）における挙動を示す情報が記憶される。
【００５９】
挙動情報は、ＣＰＵ１２（例えば無通信監視処理２４）が以下のようにして作成する。ＣＰＵ１２は、バースト管理ＤＢ３２にユーザＩＤ（ＩＭＳＩ）を登録したとき、当該ユーザＩＤに係るエントリを作成する。ＣＰＵ１２は、作成したエントリにおける挙動情報として、バースト管理ＤＢ３２にてユーザＩＤが属する時間帯を記憶する。このような時間帯の記憶は、各ユーザＩＤに関して所定期間分行われる。
【００６０】
或るユーザＩＤの挙動情報が、毎日のユーザパケット受信（時間帯）を示し、且つこれらの時間帯が完全一致、或いは一致と認められる範囲内に収まる条件を満たす場合、端末４が当該時間帯にＳ−ＧＷ６で受信されるユーザパケットを毎日送信していることが分かる。すなわち、当該端末４に関して、定時のユーザパケット送信を継続的に行っていると判定することができる。従って、当該端末４がＣプレーンでのバースト負荷の要因となるリソース再設定要求（サービス要求）をほぼ定時で送信していると推定することができる。
【００６１】
なお、上記条件の「毎日」は、「ほぼ毎日」とすることもできる。このようにすれば、数日のうちの１日だけユーザパケットが送信されなかったケースについても継続性判断を行うことができる。上記ケースとしては、１日だけ端末４の電源がオフにされ、その日だけ定時のユーザパケット送信が行われなかったケースや、アプリケーションの仕様により或る曜日（例えば、日曜日）にユーザパケットが送信されないケースが考えられる。
【００６２】
上記のような条件が満たされない場合には、端末４は、定時のユーザパケット送信を継続的に行っていないと判定することができる。なお、例えば、挙動情報として蓄積された時間帯の情報に関して、時間帯が所定日数分揃わない、時間帯がバラバラである（規則性がない）のような、継続性なしの判定要素を積極的に判定しても良い。時間帯の代わりにユーザパケットの受信時刻を用いてもよい。
【００６３】
図９に示す例では、挙動情報として、上記した数日分の「時間帯」の情報を用いて判定した判定結果（定時のユーザパケット送信の継続性あり、継続性なし）が記憶された例を示している。挙動情報としては、上記したように、継続性判定に用いる「時間帯」のような情報が蓄積され、１３の処理において継続性の有無の判定がなされるようにしても良い。或いは、図９に示すように、判定結果を示す情報が挙動情報として予め記憶され、１３の分析処理において、継続性の有無が挙動情報の参照によって判定されるようにしても良い。この場合、判定結果の更新が適宜のタイミングで行われる。
【００６４】
図４（図６）に戻って、バースト抑止制御処理３１は、１３の分析処理において、ユーザリストに登録された全てのユーザＩＤに対して継続性の有無の判定を行う。当該判定により、ユーザリストに登録された複数のユーザＩＤは、二つのグループに分類される。一つは、定時のユーザパケット送信の継続性がある端末４のグループ（第１グループ）であり、もう一つは、定時のユーザパケット送信の継続性がない端末４グループ（第２グループ）である。換言すれば、１３の分析処理によって、ユーザＩＤ（端末４）が第１グループと第２グループとのいずれに属するかを識別することができる。第１グループに属する端末４がリソース再設定要求の集中を引き起こす要因となる端末４として検出される。
【００６５】
バースト抑止制御処理３１は、第１グループに属するユーザＩＤを有する各端末４についてバースト抑止処理３４を実行することを決定し、アクセス管理装置９にバースト抑止処理を起動させる（図６,１４）。
【００６６】
アクセス管理装置９は、例えば、図２に示したハードウェアアーキテクチャと同様のハードウェア構成を有する情報処理装置である。アクセス管理装置９は、Ｓ−ＧＷ６と通信を行い、バースト抑止処理３４の起動指示（バースト抑止指示）を得る。バースト抑止指
示は、第１グループ及び第２グループの情報（各グループに属するＩＭＳＩを示す情報）と、ユーザパケットのバースト的な受信発生の時間帯を示す情報とを含む。
【００６７】
図１０は、バースト抑止処理３４に係る動作例１を示すシーケンス図である。図１０の動作例の前提として、各端末＃１〜＃ｎは、定時にユーザパケットを送信すべく、リソース再設定要求を一斉にＭＭＥ５へ送信する環境となっている（図１０＜１＞〜＜６＞）。バースト抑止処理３４は「所定処理」の一例である。
【００６８】
Ｓ−ＧＷ６は、バースト抑止制御処理３１の結果として、バースト抑止指示（時間帯情報及び第１グループ及び第２グループの情報を含む）をアクセス管理装置９へ送る（図１０＜７＞）。このとき、第１グループの情報には、各端末＃１〜＃ｎのＩＭＳＩが含まれており、第２グループに属するＩＭＳＩは存在しないと仮定する。
【００６９】
アクセス管理装置９は、バースト抑止指示中の時間帯に到来すると予測される各端末＃１〜＃ｎからのリソース再設定要求の到着時刻を分散させるために、各端末＃１〜＃ｎに無線ベアラの再設定指示をＭＭＥ５に送る（図１０＜８＞〜＜１０＞）。再設定指示には、各端末＃１〜＃ｎのＩＭＳＩと上記時間帯の情報が含まれる。
【００７０】
ＭＭＥ５は、各端末＃１〜＃ｎのＩＭＳＩに基づき各端末＃１〜＃ｎに対して端末呼び出しを行い、リソース再設定要求（サービス要求）の送信を促す（図１０＜１１＞,＜１
２＞,＜１６＞,＜１７＞,＜２１＞,＜２２＞）。呼び出しに対して、各端末＃１〜＃ｎは、リソース再設定要求を送信する（図１０＜１３＞,＜１４＞,＜１８＞,＜１９＞,＜２３＞,＜２４＞）。
【００７１】
ＭＭＥ５は、リソース再設定要求を受けて、Ｓ−ＧＷ６に無線ベアラ設定要求信号を送信し、Ｓ−ＧＷ６は、各端末＃１〜＃ｎに関する無線ベアラの再設定を行う（図１０＜１５＞,＜２０＞,＜２４＞）。
【００７２】
呼び出しに当たり、ＭＭＥ５は、各端末＃１〜＃ｎからのリソース再設定要求がＭＭＥ５に分散して到達するように、所定の間隔を空けて各端末＃１〜＃ｎに呼び出し信号を送る。このとき、ＭＭＥ５は、各端末＃１〜＃ｎのうち、最初の端末＃１に対する呼び出しを、再設定指示に含まれた時間帯（時刻）からタイマ満了時間だけ遡った時刻より遅いタイミングで開始する。当該再設定で設定された無線ベアラが定時前にタイマ満了で解放されるのを回避するためである。
【００７３】
各端末＃１〜＃ｎにおけるアプリケーションの起動時刻になると（図１０＜２６＞）、アプリケーションは、送信対象のユーザパケットを発生させる。このとき、各端末＃１〜＃ｎからＳ−ＧＷ６までの無線ベアラは既に設定されている。このため、各端末＃１〜＃ｎは、リソース再設定要求を送信することなく、ユーザパケットの送信を行う（図１０＜２７＞）。
【００７４】
バースト抑止制御処理３１は、定期的又は周期的に実行される。もっとも、マニュアル操作や所定アルゴリズムによるトリガ発生に応じて、適宜のタイミングでバースト抑止制御処理３１が実行開始されるようにすることもできる。アクセス管理装置９は、バースト抑止指示をＳ−ＧＷ６から受け取った場合には、当該指示に含まれる第１グループの情報中のＩＭＳＩのリスト（無線ベアラ再設定対象リスト）を作成し、ＭＭやＨＤＤのような記憶装置に記憶する。そして、アクセス管理装置９は、バースト抑止指示に含まれた時間帯の前の適宜のタイミングで、リスト中のＩＭＳＩを対象とする無線ベアラの設定指示をＭＭＥ５に送る。
【００７５】
図１１は、バースト抑止処理３４に係る動作例２を示すシーケンス図である。図１１に示す動作例２は、動作例１の後における動作例を示す。動作例２の前提として、各端末＃１〜＃ｎ（図１１ではｎ＝３とする）のうち、端末＃１及び＃２は、アプリケーションによって定時にユーザパケットを送信する環境を維持している（図１０＜１＞〜＜４＞）。これに対し、端末＃ｎ（端末＃３）は、アプリケーションの削除、アプリケーションの仕様変更、或いはアプリケーションの設定変更のいずれかによって、定時のユーザパケット送信を行わない状態となっている（図１１の破線矢印参照）。
【００７６】
Ｓ−ＧＷ６では、バースト抑止制御処理３１が実行された結果、端末＃１，＃２が第１グループに属することを識別する。これに対し、端末＃ｎの挙動情報は、アプリケーションの削除によって定時のユーザパケット送信の継続性がないことを示す。このため、端末＃ｎは、第２グループに属する端末４として識別される。
【００７７】
バースト抑止制御処理３１の結果を受けて、Ｓ−ＧＷ６は、バースト抑止指示（時間帯情報及び第１グループ及び第２グループの情報を含む）をアクセス管理装置９へ送る（図１１＜７＞）。このとき、第１グループの情報には、各端末＃１,＃２のＩＭＳＩが含ま
れ、第２グループの情報には、端末＃ｎのＩＭＳＩが含まれる。
【００７８】
アクセス管理装置９は、バースト抑止指示を受信したとき、当該指示中の第２グループの情報を発見すると、第２グループの情報中のＩＭＳＩと同一のＩＭＳＩを無線ベアラ再設定対象リストから探索する。無線ベアラ再設定対象リスト中に同一のＩＭＳＩが発見された場合には、アクセス管理装置９は、当該ＩＭＳＩを無線ベアラ再設定対象リストから削除する。これによって、アクセス管理装置９は、ＭＭＥ５へ無線ベアラの再設定指示を送る対象の端末４から端末＃ｎを除外する（図１１＜８＞）。
【００７９】
アクセス管理装置９は、端末＃１,＃２に対する無線ベアラの再設定指示をＭＭＥ５に
送る（図１０＜９＞,＜１０＞）。ＭＭＥ５は、各端末＃１,＃２に関して端末呼び出しを行い、リソース再設定要求（サービス要求）の送信を促す（図１０＜１１＞,＜１２＞,＜１６＞,＜１７＞）。これに対し、端末＃ｎに対する呼び出しは行われない（図１１＜２
１＞）。
【００８０】
各端末＃１,＃２は、リソース再設定要求を送信する（図１０＜１３＞,＜１４＞,＜１
８＞,＜１９＞,＜２３＞,＜２４＞）。ＭＭＥ５は、リソース再設定要求を受けて、Ｓ−
ＧＷ６に無線ベアラ設定要求信号を送信し、Ｓ−ＧＷ６は、各端末＃１,＃２に関する無
線ベアラの再設定を行う（図１０＜１５＞,＜２０＞）。
【００８１】
＜実施形態の作用効果＞
以上説明した実施形態によれば、ＣＰＵ１２の無通信監視処理２４によって、バースト管理ＤＢ３２が生成される。すなわち、バースト管理ＤＢ３２には、時間帯（時刻）毎に、イベント数と、ユーザリストが記憶される（図５，０３）。イベント数は、「各端末４から送信された（ユーザ）パケットが所定時間経過後に受信された数（受信（ユーザ）パケット数）」を示す。
【００８２】
このようなパケットの受信は、上記したように、ユーザリストにＩＭＳＩが登録された各端末４がユーザパケットの送信のためにリソース再設定要求を送信し、リソースの再設定がなされた後にユーザパケットを送信した可能性が高い。従って、各時刻に対応するイベント数は、Ｃプレーンのリソース再設定要求の送信（発生）数の推定値として利用することができる。
【００８３】
さらに、ＣＰＵ１２のバースト抑止制御処理３１において、イベント数が閾値を超える
時間帯（時刻）が抽出される（図６,１２）。当該時刻は、Ｕプレーンにおいてバースト
的なユーザパケットが受信されているため、Ｃプレーンにてリソース再設定要求が集中的に発生したと推定することができる。そして、ユーザリストにＩＭＳＩが登録された端末４を、Ｃプレーンでのリソース再設定要求の集中の要因となる端末４として検出することができる。
【００８４】
さらに、ＣＰＵ１２は、ユーザ挙動管理ＤＢ３３を用いて、当該ユーザ（端末４）が定時のパケット送信を行っているか否かを挙動情報（パケット受信状況）から判定し、端末４を第１グループと第２グループとに分けることができる。第１グループに属する端末４は、定時のパケット送信を行っている端末４と識別される。このような端末は、将来に亘って定時のパケット送信を行う可能性が高く、バースト抑止処理３４（所定処理）の対象に決定される。
【００８５】
この結果、動作例１に示したように、第１グループに属する各端末４のリソース再設定要求の送信タイミングが調整されることで、バースト的な負荷上昇が発生し、処理が輻輳するのを回避（抑止）することができる。このように、図６の１３の処理によれば、バースト抑止処理３４を要する端末４の識別（検出）精度を、当該処理を行わない場合に比べて高めることができる。
【００８６】
また、１３の処理によれば、バースト抑止処理３４を要しない端末４を検出（識別）することができるので、各端末４に対するバースト抑止処理３４の実施の要否を判定することができる。
【００８７】
第２グループに属する端末４は、定時のパケット送信を行っていない端末４と識別することができる。このような端末４は、偶然にリソース再設定を行いユーザパケットを送信した結果、当該時間帯で受信された可能性が高い。換言すれば、将来において定時のパケット送信を行う可能性は低いので、バースト抑止処理３４の対象から除外される。この結果、動作例２に示したように、無駄な端末呼び出し及び無線ベアラ再設定を回避し、リソースの有効活用を図ることが可能となる。
【００８８】
以上のように、本実施形態では、Ｕプレーンの挙動（ユーザパケットの受信状況）を元に、Ｃプレーンにおけるリソース再設定要求の集中（バースト的な負荷発生）の要因となる端末４を検出することができる。このため、関連技術で説明したようなＣプレーンにおけるリソース再設定要求の監視は不要となり、上記した効果を得ることができる。
＜変形例＞
本実施形態では、ユーザパケットの中継装置であるＳ−ＧＷ６が「情報処理装置」である例について示した。これに代えて、Ｓ−ＧＷ６と通信可能なコンピュータ（例えば、アクセス管理装置９や、別個のサーバ装置）の記憶装置にテーブル２６，バースト管理ＤＢ３２，ユーザ挙動管理ＤＢ３３が記憶され、コンピュータのＣＰＵがＳ−ＧＷ６から受信されるパケット受信通知を用いて、無通信監視処理２４，タイマ管理２５，バースト抑止制御処理３１を実行するようにしても良い。すなわち、「情報処理装置」は、中継装置（Ｓ−ＧＷ６）であることに限定されず、Ｓ−ＧＷ６でのユーザパケットの受信状況を監視する監視サーバであっても良い。
【００８９】
また、本実施形態で説明した構成に代えて、バースト管理ＤＢ３２の記憶内容が、所定のディスプレイ装置に表示されるようにしても良い。この場合、当該記憶内容を参照する者が、バースト発生の時間帯（時刻）を把握するとともに、ユーザリスト（ＩＭＳＩ）を参照することで、バースト抑止処理３４の実施が好ましい端末４を特定することができる。この場合、バースト抑止制御処理３１は、オプションとなる。
【００９０】
また、本実施形態では、ユーザの挙動分析（図６，１３）が実行されているが、これはオプションとすることができる。すなわち、バーストの時間帯とされた時刻（時間帯）のユーザリストに登録された全ての端末４を対象として、バースト抑止処理３４を実行することができる。以上の実施形態で示した構成は、適宜組み合わせることができる。
【符号の説明】
【００９１】
３・・・基地局（無線基地局）
４・・・端末（無線端末）
５・・・ＭＭＥ
６・・・Ｓ−ＧＷ
１２・・・ＣＰＵ
１３・・・メインメモリ
【図１】
0006387717.tif 000002
【図２】
0006387717.tif 000003
【図３】
0006387717.tif 000004
【図４】
0006387717.tif 000005
【図５】
0006387717.tif 000006
【図６】
0006387717.tif 000007
【図７】
0006387717.tif 000008
【図８】
0006387717.tif 000009
【図９】
0006387717.tif 000010
【図１０】
0006387717.tif 000011
【図１１】
0006387717.tif 000012
【図１２】
0006387717.tif 000013