(57)【要約】【課題】  シーケンスの再現には呼処理装置が保持しているパケットには現れない情報が必要となる場合があり、既存のキャプチャ方法では全てのパケットに共通の呼情報が存在しない場合はシーケンスを再現できない。【解決手段】  呼処理装置は受信パケットと送信パケットにシーケンスの再現に必要な情報を付加し解析用パケットとして解析装置に送信する。  解析装置は再現しようとするシーケンスに関わる呼処理装置から解析用パケットを受け取り、同一シーケンスに属するパケットを識別する。シーケンスの識別には、前記呼処理装置が付加した解析用の情報と2つの装置間の送信パケットと受信パケットのペイロードが一致することを利用する。【選択図】  図１
2015204538.tif 000002
【特許請求の範囲】
【請求項１】
通信装置から受信するパケットと、当該通信装置を識別するための第１の識別情報と、を対応付けて記憶する第１の記憶部と、
前記第１の記憶部に記憶されたパケットのうち、互いに異なる前記第１の識別情報に対応付けて保持されている複数のパケットについて、当該パケットを構成する情報のうちの少なくとも一部どうしを比較して内容が一致するかどうか判断する処理部と、
前記処理部により内容が一致すると判断された複数の前記パケットの組み合わせを記憶する第２の記憶部と、を有することを特徴とする解析装置。
【請求項２】
請求項１に記載の解析装置において、
前記第１の識別情報と、当該第１の識別情報で特定される前記通信装置がネットワークで使用するアドレスと、を対応付けて記憶する第３の記憶部を有し、
前記処理部は、
前記第１の記憶部に記憶された任意のパケットの送信先もしくは送信元の前記アドレスに対応付けて前記第３の記憶部に記憶されている前記第１の識別情報を取得し、
前記取得した第１の識別情報と対応付けて前記第１の記憶部に記憶されているパケットを、前記任意のパケットの比較対象として選別することを特徴とする解析装置。
【請求項３】
請求項２に記載の解析装置において、
前記通信装置から受信するパケットには、当該パケットを前記通信装置が受信もしくは送信のいずれをしたのかを示す送受信情報が付加されており、
前記第１の記憶部は前記パケットに前記送受信情報も対応付けて保持しており、
前記処理部は、
前記任意のパケットに送信したことを示す前記送受信情報が付加されている場合には、当該任意のパケットの送信先の前記アドレスに対応付けて前記第３の記憶部に記憶されている前記第１の識別情報を取得し、
前記任意のパケットに受信したことを示す前記送受信情報が付加されている場合には、
当該任意のパケットの送信元の前記アドレスに対応付けて前記第３の記憶部に記憶されている前記第１の識別情報を取得することを特徴とする解析装置。
【請求項４】
請求項３に記載の解析装置において、
前記処理部は、
前記任意のパケットに送信したことを示す前記送受信情報が付加されている場合には、受信したことを示す前記送受信情報と対応付けて前記第１の記憶部に記憶されている前記パケットを比較の対象とし、
前記任意のパケットに受信したことを示す前記送受信情報が付加されている場合には、
送信したことを示す前記送受信情報と対応付けて前記第１の記憶部に記憶されている前記パケットを比較の対象とすることを特徴とする解析装置。
【請求項５】
請求項４に記載の解析装置において、
前記通信装置から受信するパケットには、当該パケットを前記通信装置が受信もしくは送信した時刻情報が付加されており、
前記第１の記憶部は前記パケットに前記時刻情報も対応付けて保持しており、
前記処理部は、前記第１の記憶部に記憶されたパケットどうしの前記時刻情報の差が所定の時間以内である場合に当該パケットどうしを比較することを特徴とする解析装置。
【請求項６】
請求項５に記載の解析装置において、
前記通信装置から受信するパケットには、前記通信装置により付与された、当該パケットが属する一連のシーケンスを識別する第２の識別情報が付加されており、
前記第１の記憶部は前記パケットに前記第２の識別情報も対応付けて保持しており、
前記処理部は、前記通信装置からパケットを受信すると、前記第１の識別情報および前記第２の識別情報の組み合わせごとに前記パケットを記憶することを特徴とする解析装置。
【請求項７】
ネットワークを介して受信した受信パケットと、当該受信パケットに基づき生成しネットワークを介して送信する送信パケットと、に自装置を識別する第１の識別情報をそれぞれ付加して送信する複数の通信装置と、
前記通信装置から受信した前記受信パケットに前記第１の識別情報を対応付け、および前記通信装置から受信した前記送信パケットに前記第１の識別情報を対応付け、それぞれ記憶する第１の記憶部と、
前記第１の記憶部に記憶された前記送信パケットおよび前記受信パケットのうち、互いに異なる前記第１の識別情報に対応付けて保持されている複数のパケットについて、当該パケットを構成する情報のうちの少なくとも一部どうしを比較して内容が一致するかどうか判断する処理部と、
前記処理部により内容が一致すると判断された、異なる前記第１の識別情報に対応付けて前記第１の記憶部に記憶されている前記送信パケットと前記受信パケットの組み合わせを記憶する第２の記憶部と、を有することを特徴とする通信システム。
【請求項８】
請求項７に記載の通信システムにおいて、
前記第１の識別情報と、当該第１の識別情報で特定される前記通信装置がネットワークで使用するアドレスと、を対応付けて記憶する第３の記憶部を有し、
前記処理部は、
前記第１の記憶部に記憶された任意の前記受信パケットの送信元の前記アドレスに対応付けて前記第３の記憶部に記憶されている前記第１の識別情報を取得し、
前記取得した第１の識別情報と対応付けて前記第１の記憶部に記憶されているパケットを、前記任意のパケットの比較対象として選別することを特徴とする通信システム。
【請求項９】
請求項８に記載の通信システムにおいて、
前記通信装置から受信するパケットには、当該パケットが前記送信パケットもしくは前記受信パケットのいずれであるかを示す送受信情報が付加されており、
前記第１の記憶部は前記パケットに前記送受信情報も対応付けて保持することを特徴とする通信システム。
【請求項１０】
請求項９に記載の通信システムにおいて、
前記通信装置から受信する前記受信パケットには、当該受信パケットを前記通信装置が受信した受信時刻情報が付加されており、かつ、前記通信装置から受信する前記送信パケットには、当該送信パケットを前記通信装置が送信した送信時刻情報が付加されており、  前記第１の記憶部は前記受信パケットに前記受信時刻情報を対応付け、前記送信パケットに前記送信時刻情報を対応付け、それぞれ保持しており、
前記処理部は、前記第１の記憶部に記憶された前記受信パケットの前記受信時刻情報と前記送信パケットの前記送信時刻情報との差が所定の時間以内である場合に当該パケットどうしを比較することを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モバイルネットワークにおける呼処理の解析に関する。
【背景技術】
【０００２】
本技術分野の背景技術として、3GPP(3rd Generation Partnership Project)で標準化されているLTE（Long Term Evolution）という移動体通信技術が普及している。本発明の再現対象となり得るシーケンスについては非特許文献1に記載されている。
【０００３】
また、特開２００４−２４８１９２号公報（特許文献１）がある。この公報には、VoIP（Voice Over IP）サービスにおける、Call・IDを利用した制御信号シーケンス生成方法が記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−２４８１９２号公報
【非特許文献】
【０００５】
【非特許文献１】3GPP標準文書(URL:http://www.3gpp.org/)
【非特許文献２】TS 23.401 General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access v 11.7.0
【発明の概要】
【発明が解決しようとする課題】
【０００６】
近年、LTEのようなモバイルネットワークは複雑化し、スマートフォンが普及し、制御パケットを処理するノード（以下、呼処理装置）の処理量も増大しているため、これら呼処理装置における問題の解析も複雑化している。保守者が呼処理装置における故障原因の分析や遅延原因を分析する際、１つの呼処理装置による原因で問題が発生するとは限らないため、故障や遅延等の問題が顕在化した呼処理装置のみを調査するだけでは不十分な場合がある。このようなとき、保守者は前記問題となる呼処理のシーケンスに沿って他の呼処理装置も含めた解析を要する。ここで呼処理のシーケンスとは端末の接続やハンドオーバ等のprocedureに従い、該procedureに関連する複数の呼処理装置間で交換される一連のパケット（メッセージ）列である。procedureとは例えば非特許文献２の5.3.2章に記載されるInitial Attachや5.3.8章に記載されるDetachが挙げられる。
【０００７】
保守者や保守用のシステムが呼処理装置に入力または呼処理装置から出力されるパケットをキャプチャし、そのキャプチャしたパケットを問題分析に利用することは一般的である。呼処理のシーケンスに沿った解析を行うためには、保守用のシステムがキャプチャされたパケットから同一のシーケンスに属するパケット列を抽出し、複数の呼処理装置にまたがって異なる種類のパケット（メッセージ）同士を紐付ける必要がある。ここで、本発明では前記パケットの紐付けによって、あるシーケンスに属するパケット列を抽出することをシーケンスの再現と呼ぶ。
【０００８】
特許文献１ではVoIPにおいて、シーケンス内の全ての呼処理装置で共通の呼情報となるCall-IDを利用して、キャプチャしたパケットからシーケンスを生成する技術が公開されている。しかし、パケットから得られる情報にCall-IDのような、複数の中継装置をまたがるシーケンス内で共通の呼情報がない場合には、シーケンスの再現は不可能となる。このような呼処理では、呼処理装置がパケットには現れない情報を保持し、呼情報の識別を行う。
【０００９】
例えば、非特許文献2、第5.3.2章より、Initial AttachにおいてMME(Mobile Management Entity)はeNodeB(evolved NodeB)からAttach requestを受信すると、GUTI(Global Unique Temporary Identity)により、UE (User Equipment)を識別する。次にHSS(Home Subscriber Server)にUpdate Location Requestを送信する際にはUE識別子としてIMSI（International Mobile Subscriber Identity）を利用する。ここで、GUTIとIMSIが呼情報である。このとき、MMEはテーブルの同一エントリーにGUTIとIMSIを登録するなどの方法で複数のUE識別子、つまりGUTIとIMSIから同一UEを識別する必要があり、該機能を備えている。該機能による呼情報の識別過程はパケットには現れない。また、前記例においてGUTIはNAS(Non Access Stratum)プロトコル、IMSIはDiameterプロトコルにより通信される。そのため、保守用のシステムがパケットのキャプチャデータのみからシーケンスの識別を行うことは困難または複雑なプロトコル解析が必要となる。
【００１０】
つまり、保守用のシステムは前記GUTIとIMSIが同一シーケンスに属している事を識別するために、呼処理装置が保持している情報を利用する必要がある。従って、本発明ではCall-IDのようなシーケンス内で共通の呼情報をパケットから得られない場合に、保守用のシステムが前記GUTIとIMSIのように異なる呼情報を紐付けられるようにするために、呼処理装置が保持する情報を利用し、シーケンスに沿った解析を可能とすることを課題とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するため、本発明の解析装置は、通信装置から受信するパケットと、当該通信装置を識別するための第１の識別情報と、を対応付けて記憶する第１の記憶部と、第１の記憶部に記憶されたパケットのうち、互いに異なる第１の識別情報に対応付けて保持されている複数のパケットについて、当該パケットを構成する情報のうちの少なくとも一部どうしを比較して内容が一致するかどうか判断する処理部と、処理部により内容が一致すると判断された複数のパケットの組み合わせを記憶する第２の記憶部と、を有するよう構成する。
【発明の効果】
【００１２】
呼処理装置が解析用の情報をパケットに付加することにより、パケットには現れない情報を用いた解析が可能となる。解析装置は同一シーケンスに属する異なる呼情報を持つパケットを識別でき、シーケンスの再現が可能となる。
【図面の簡単な説明】
【００１３】
【図１】LTEシステムでの本発明を適用したシステム例の構成図である。
【図２】LTEシステムにおけるInitial Attachの呼処理シーケンス例である。
【図３】解析用パケットのフォーマットの例である。
【図４】呼処理装置の構成図の例である。
【図５−Ａ】呼処理装置における、呼の種別を判定し呼処理IDテーブルに登録する処理フローの例である。
【図５−Ｂ】呼処理装置における、解析用パケットを生成する処理フローの例である。
【図６】呼処理IDを保持するテーブルの例である。
【図７】解析装置の構成図の例である。
【図８】解析装置が解析用パケットをバッファするための処理フローの例である。
【図９】正常なシーケンスを再現するための処理フローの例である。
【図１０】装置IDと呼処理ID別に分けられたパケット列である。
【図１１】パケットマッチの絞込み条件を保持するテーブル例である。
【図１２】IPアドレスから装置IDを解決するテーブル例である。
【図１３】解析装置により出力されるInitial attachメッセージ列である。
【図１４】パケットロスがある場合のシーケンスの例である。
【図１５】パケットロスがある場合のシーケンス再現処理フローの例である。
【図１６】異常シーケンスの分析処理フローである。
【発明を実施するための形態】
【００１４】
以下、実施例を図面を用いて説明する。
【実施例１】
【００１５】
本実施例では図1に示すLTEシステムの構成において図2のInitial attachの正常な呼処理シーケンスを再現する例を説明する。ここで、図2のInitial attachとはUE110の電源がONになった場合に、LTEシステムがUE110のアタッチ要求を契機として、UE110に対し認証、接続設定しLTEネットワークに登録を行う一連の呼制御処理である。Initial Attachにより、無線経路の設定、ユーザ認証、PDN(Packet Data Network)120への接続処理、eNodeB111-SGW113-PGW114の経路設定、課金情報の設定などが実施され、UE110が通信サービスを受けられる状態となる。なお、呼処理シーケンスの一例としてInitial attachを用いて説明するのであり、Initial attach以外の呼処理シーケンスに対しても本実施例を適用することができる。
【００１６】
図1を用いて本システムの構成要素について説明する。UE110は無線端末である。eNodeB111は無線基地局である。MME112は呼制御装置である。SGW(Serving GateWay)113、PGW(Packet data network GateWay)114はデータパケット転送を行うゲートウェイである。HSS115は加入者情報管理サーバーである。本実施例ではeNodeB111やMME112、SGW13、PGW114などのように、UE110からの制御メッセージを受信して処理する通信装置を呼処理装置と総称する。
【００１７】
解析装置101はeNode111、MME112、SGW113、PGW114、HSS115などの呼処理装置から図3の解析用パケット300を収集解析し、同一シーケンスに属するパケットを識別、紐付けし、シーケンスの異常を検出し、異常の解析を行う。本実施例では図1のように、解析装置101が全ての呼処理装置111-115から解析用パケット300を収集するが、呼処理装置の一部から解析用パケット300を収集しても良い。
【００１８】
ここで、各呼処理装置111-115が解析用のパケット300を生成する際の動作について説明する。ただし、非特許文献１の標準どおりに動作する部分の説明は省略する。呼処理装置111-115は、標準の動作に加え、受信パケットと送信パケットの複製を作成し、これら複製したパケットに図3の解析用ヘッダ情報301-306を付加し、解析装置101に送信する。
【００１９】
図3を用いて解析用パケット300のフォーマットについて説明する。装置ID301は複数の呼処理装置それぞれを識別する識別子である。監視対象の全ての装置に対してユニークな値が割り当てられている。装置ID301は解析装置101により呼処理装置別にユニークになるように管理され、解析装置101によって呼処理装置111-115に配布されるものとする。呼処理ID302は呼処理装置が実行する呼処理、つまりそのパケットが属する一連のシーケンスを識別する識別子である。呼処理ID302は各呼処理装置111-115の内部で呼毎にユニークな値となるように各呼処理装置111-115が個別に管理する。
【００２０】
送信・受信フラグ303はそのパケットが呼処理装置が受信したパケットか、送信したパケットかを示すフィールドであり、解析装置101が受信パケットと送信パケットとを判別できるようにするためのものである。送信・受信時刻304は呼処理装置における送信時刻または受信時刻を示す。呼処理装置は送信パケットには送信時刻を付加し、受信パケットには受信時刻を付加する。タイプ305は該当するパケットに対する呼処理が正常に行われたか、再送など異常処理が行われたかを示すフィールドである。例として正常送信:0、再送:1、フラグメント：2のように割り当てることで、解析装置101が呼処理装置111-115で実行された処理を識別するために利用する。フィールド306はパケット情報であり、呼処理装置111-115は受信パケットまたは送信パケットをフィールド306に格納する。ここで、受信パケットとはある呼処理装置が他の呼処理装置から受信したパケットを意味し、送信パケットはある呼処理装置が他の呼処理装置へ送信したパケットを意味する。
【００２１】
図4、図5、図6を用いて呼処理装置の構成と解析用情報の付与手順について説明する。図1に示す呼処理装置111-115に共通する構成を図4の呼処理装置119として説明する。
【００２２】
送受信部410は呼処理装置119の外部装置と通信回線を介して接続される。送受信判定部411は入力されたパケットに解析用ヘッダ情報301-306が付されていない場合は外部装置から受信したパケットであると判断し、付されている場合は自装置内部から外部へ送信されるパケットであると判定する。受信パケットの場合、送受信判定部411は受信パケットに解析用ヘッダ情報301-306を付与し、さらに送受信情報付与部412は送信・受信フラグ303に受信パケットであることを示す情報を格納し、また受信時刻304を登録して呼処理部420に送信する。
【００２３】
図5-Aおよび図5-Bに呼処理部420が実行する処理を示す。以降の呼処理部420の説明は図5を参照しながら行なう。呼処理部420は送受信部410から受信したパケットを受信パケット複製部441で複製した後(501)、プロトコル処理部430でプロトコルに従い処理を行う。ここで受信パケット複製部441が受信パケットの複製を行なうのは、受信パケットを解析装置101に送信するためである。複製元の受信パケットは呼処理部420で必要な処理をされた後に送信パケットとなる。
【００２４】
プロトコル処理部430の内、新規呼判定部431は該処理が新規呼に対する処理であるか否かを判定する。判定方法は呼処理の内容に依存する。ここでは、呼処理装置がMME112の場合にAttach Request202を受信した場合で説明する。
【００２５】
新規呼判定部431はパケットを受信すると、3gpp標準に従い、パケットからUE識別子とメッセージ識別子を抽出する(502)。ここでは、UE識別子はUE110のGUTIであり、メッセージ識別子はAttach Requestである。  MME112では、Attach Request202は呼処理を開始するメッセージである。ここで、新規呼判定部431は抽出したGUTIが呼情報管理テーブル610の呼情報611に登録されているか否かを確認し、登録されていない場合は新規呼であると判定する(503)。
【００２６】
新規呼であった場合は、新規呼判定部431は呼情報管理テーブル610の呼情報611にGUTIをGUTI613として登録する。また、呼処理ID生成部442は、呼処理装置119内でUE110を他のユーザ端末と一意に識別するための呼管理ID612を生成し呼情報識別テーブル610の呼管理ID612と呼処理ID管理テーブル620の呼管理ID621にそれぞれ登録する(504)。図6では呼管理IDが０の場合を図示している。また、新規呼判定部431は呼処理IDテーブル620に新規に登録した、呼管理ID621が０のエントリの状態622に「Attach開始」を書き込む事で、該当するUE110に対するAttach Request処理が開始したことを呼処理ID管理部440に通知する(505)。
【００２７】
プロトコル処理部430は3gpp標準に従い呼処理を行った後(図示せず)、送信パケットであるUpdateLocationRequest203に格納するIMSIを呼情報管理テーブル610の呼情報611にIMSI614として登録する。このIMSIは、UpdateLocationRequest203においてUE110を識別するための情報である。また、プロトコル処理部430による呼処理の結果からタイプ判定部432は処理のタイプを判定し(506)、呼処理ID管理テーブル620のタイプ624に保存する（507）。
【００２８】
プロトコル処理部430の処理が完了すると、プロトコル処理部430はステップ504で生成した呼管理ID612を呼処理ID管理部440へ渡す。呼処理ID管理部440は呼管理ID612を受け取ると、図5-Bの処理を開始する。呼処理ID管理部440はプロトコル処理部430から受け取った呼管理ID612を取得する(508)。呼処理ID生成部442は呼管理ID612をキーとして呼処理IDテーブル620を参照し、状態622を参照して新規呼であるかを判定する（509）。呼処理ID生成部442は、状態622がプロトコル処理部410が書き込んだ「Attach開始」を示す場合、新規呼であると判定し、新規の呼処理IDを生成し(510)、呼処理IDテーブル620の呼処理ID623に登録する(511)。なお、図6に示す例では、呼処理ID623は０であり呼管理ID621と同じ値であるが、呼管理ID621と呼処理IDとは同じ値でも異なる値でも良い。そして、呼処理ID生成部442は、状態622を「Attach開始」から「Attach処理中」に更新する。新規の呼で無い場合は、ステップ509で参照する状態622が「Attach処理中」を示している場合に、呼処理ID管理テーブル620に登録済みの呼処理ID623を取得する(512)。
【００２９】
解析情報付与部443は、ステップ510で新規に生成した又はステップ512で呼処理ID管理テーブル620から取得した呼処理ID623を呼処理ID302に格納する(513)。また、解析情報付与部443は、呼管理ID621をキーとして、タイプ624を取得し、解析用ヘッダ情報300のパケットタイプ305に、自らの装置IDを装置ID301に格納し、これら情報を格納された解析用ヘッダ情報300を受信パケットおよび送信パケットに付加する(514)。なお、解析情報付与部443は、送信パケットには送信フラグ304をさらにセットする。最後に呼処理部420は送受信部410に受信パケットと送信パケットを送信する(515)。
【００３０】
送受信部410の送受信情報付与部412は、呼処理部420から受け取った受信パケットおよび送信パケットについて、送信・受信フラグ304をチェックし、送信・受信フラグ304が送信を示している場合、送信するパケットの複製を作成し、複製した一方のパケットの解析用ヘッダを取り除く。そして送受信情報付与部412は、解析用ヘッダが付いている方の送信パケットの解析用ヘッダに送信時刻305を付加し、解析装置101に送信する。送信・受信フラグ304が受信を示す場合は送信情報を付加せず、解析用ヘッダ情報が付いた状態で解析装置101に送信する。
【００３１】
上記の処理により、呼処理装置119は、送受信部410でパケットを受信した後、呼処理部420で呼処理ID302を含む解析用情報を付与して、410から解析装置101へ解析用パケット300を送信する。以上の説明では、呼処理IDテーブル444のキーを選択することで、該当する呼処理装置111-115が実施するProcedureの開始から終了までの間で共通の呼処理IDを保持することができる。
【００３２】
次に、図7を用いて解析装置101について説明する。送受信部710は呼処理装置119とストレージ770に接続され、外部装置と処理部720の通信のインターフェースとなる。装置ID・呼処理ID分類処理部 730は装置ID301と呼処理ID302別に、呼処理装置119から受信した解析用パケット300を分類して図10に示す装置呼処理ID別パケット列として保持する。生成された装置呼処理ID別パケット列765は解析装置101のメモリ容量または、システム管理者が設定したデータ量もしくは制限時間に従いメモリ760に保持される。前記の条件により保持されなくなった装置呼処理ID別パケット列765はシステム管理者の設定により、廃棄またはストレージ770へ格納されることとする。
【００３３】
パケット紐付け処理部740は、装置呼処理ID別パケット列765から、同一シーケンスに属する解析用パケット300を抽出・紐付けしてまとめることで、図13に示すシーケンス収集結果パケット列767を作成する。具体的には、パケット紐付け処理部740は装置呼処理ID別パケット列765に格納された、2つの装置間の送信パケット300と受信パケット300を比較して一致するパケットを同じシーケンスに属するパケットとして紐付けしていく。なお、装置呼処理ID別パケット列767の全てのパケットについて逐一比較をしていくと時間がかかるため、後述するようにパケット紐付け処理部740は比較するパケットの絞り込みを行なう。
【００３４】
異常解析部750はパケット紐付け処理部740がシーケンス収集結果パケット列767として再現したシーケンスの異常を調べ、異常がある場合のみ、一連のシーケンスに属するものとして束ねたパケット列を、後の解析のためにストレージ770に格納するような判定処理を実行する。
【００３５】
解析装置101は呼処理装置119から受信した解析用パケット300の情報をキーとしてパケット比較用テーブル771、装置IDテーブル772を利用する。図11はパケット比較用テーブル771の一例である。パケット比較用テーブル771は、パケット紐付け処理部740が装置呼処理ID別パケット列765の中から比較するパケットを絞り込む際の閾値としてパケットマッチ用探索時刻範囲1104を、パケットのペイロード比較に利用するフィールドとしてパケット比較キー種別1103を、それぞれ格納する。これらの閾値とフィールドはシステム管理者が指定する。受信装置ID1101と送信装置ID1102はパケット比較用テーブル771で保持する値を利用する際のキーである。システム管理者は、パケットを送信した装置と受信した装置との装置IDの両方または一方をキーとして、パケットの比較に関する設定を行う。
【００３６】
図11では、パケット比較キー種別1103としてIPペイロードを格納している。システム管理者はネットワークの構成によってEtherのペイロードやTCPペイロードに変更を行う事ができる。パケットマッチ用探索時間範囲1104はペイロード比較部744が行う探索処理において、ペイロード比較の対象となる解析用パケット300の送信・受信時刻304の間隔を指定する。例えば、図2でeNodeB111がAttach Request202を送信した時刻をT_A、ME112が当該Attach Request202を受信した時刻をT_Bとしたとき、T_BとT_Aの差分がパケットマッチ用探索時刻範囲1104に格納された時間以内であれば、これらのパケットは比較対象とされる。パケットマッチ用探索時間範囲1104には隣接する装置にパケットが到着するまでの時間の目安を設定する。
【００３７】
パケット列用の探索時間範囲1105は装置ID・呼処理ID分類処理部730のタイマー監視部734に設定するタイムアウトの時間を設定する。この時間がタイムアウトになると、装置ID・呼処理ID分類処理部730は、同じ装置ID、呼処理IDを有する解析用パケット300を受信することはもはや無くシーケンスは終了したと判断して、その装置ID・呼処理IDを有する解析用パケット300の収集を終了する。パケット列用の探索時間範囲1105には、例えば1回のProcedureに要する時間を目安に設定することができる。この場合3gppでは100msが目標となっている。図１１の該探索時間範囲1105では再送があった場合にも収集可能とするため、1sとしている。
【００３８】
図12は装置IDテーブル772の内容例である。装置IDテーブル772には、各呼処理装置のIPアドレス1201と、解析装置101により付与された各呼処理装置の装置ID1202の組が記憶されている。後述するように、パケット絞込み部741が比較対象のパケットを絞り込む時に、装置呼処理ID別パケット列765に格納されたパケット本体の送信先もしくは送信元IPアドレスを参照することで当該パケットを受信もしくは送信した相手の装置を特定し、その特定した相手装置のIPアドレスで装置IDテーブル1201を検索することで、当該特定した相手装置の装置ID1202を取得するものである。
【００３９】
なお、装置IDとしてIPアドレスのように呼処理装置をネットワーク上で識別するための情報をそのまま用いても良い。この場合、図3の装置ID301、図10の装置ID1091、図11の受信装置ID1101、同図の送信装置ID1102、図13の装置ID1391等の本実施例における装置IDを示す情報にはアドレス情報がそのまま適用される。この場合、図12の装置IDテーブル772は不要となる。複数の呼処理装置でIPアドレスが重複して割り当てられてしまうような場合は、アドレス情報とは別に本実施例のように装置IDを用意する。
【００４０】
図8は装置ID呼処理ID分類処理部730の処理フローチャートを示す。また、図10は装置ID呼処理ID分類部730が図8の処理フローの結果出力する装置呼処理ID別パケット列765を示す。
【００４１】
まず、送受信部710が呼処理装置119から解析用パケット300を受信し（801）、送受信部710は処理部720に受信したパケットを渡す。装置ID・呼処理ID分類処理部730は受信した解析用パケット300から装置ID301と呼処理ID302を取得する(802)。次に、装置ID判定部731は受信した解析用パケット300の装置ID301と呼処理ID302の組（以下、これらIDの組を装置呼処理IDという）を調べ(803)、装置呼処理ID別パケット列765に登録されていない新規の装置呼処理ID301,302であった場合、該当する装置呼処理ID301、302を持つパケット300を格納するためのメモリ領域として装置呼処理ID別パケット列765の中の一領域を割り当てる(804)。ここで、受信した解析用パケット300の装置IDがMME112の”120”であり呼処理ID302が”100”であった場合、図10のパケット列1020の領域が割り当てられ、解析用パケット300はこの領域に格納される。なお、MME112の装置IDは、装置IDテーブル772に図示しているとおり”120”である。
【００４２】
このとき、装置呼処理ID判定部732は同じ呼処理IDを持つ解析用パケット300の収集が完了したかの判定を行うために、タイマー768の割り当ても行う(804)。ここで、タイマー768は装置ID301と呼処理ID302の組毎、つまり装置呼処理ＩＤ別パケット列毎に割り当てられる。該タイマー768は、タイマー監視部734がパケット列1020の生成完了を判定するために利用する。つまり、装置呼処理ID判定部732は、このタイマー768に設定された時間を過ぎても新たな解析用パケット300を受信しない場合は、一連のプロシージャに属するパケットのやり取りが終了したと推定してその装置呼処理ＩＤ別パケット列の生成を終了する判断をする。
【００４３】
ステップ803で、受信した解析用パケット300の装置呼処理IDが、装置呼処理ＩＤ別パケット列に既に存在していた場合、もしくはステップ804を処理した場合、装置呼処理ID判定部732は該当する装置呼処理ID別パケット列765のパケット1096に解析用パケット300のパケット本体306を格納し、タイマー768のリセットを行う(805)。また、その解析用パケット300の解析用ヘッダ情報に含まれる送信・受信フラグ303をパケット列1020の送信・受信フラグ1093に、送信・受信時刻304を送信・受信時刻1094に、タイプ305をタイプ1095に、それぞれ格納する。
【００４４】
タイマー監視部734はタイマー768とパケット比較用テーブル771のパケット列用探索時間範囲1105に設定した閾値を比較し、装置呼処理ID1101、1102のパケットを閾値時間以上受信しない場合はタイムアウトと判定する(806)。タイムアウトと判定された場合、ソート部733はタイムアウト判定された装置呼処理ＩＤ別パケット列765のパケットを送信・受信時刻1094の時刻順でソートして（807）、装置呼処理ID別パケット列765の生成を完了する。タイマー監視部734がタイムアウトと判定する前に同じ装置呼処理ＩＤの解析用パケット300を受信してその装置呼処理ＩＤ1101、1102に対応するタイマー768をリセットした場合は、タイムアウトとならず(806)、装置呼処理ID別パケット列765の生成を完了せず受信処理を継続する(801)。
【００４５】
以上で、全ての呼処理装置119から送信される解析用パケット300の装置ID301と呼処理ID303による分類が完了し、装置呼処理ID別パケット列765が出力される。図10は図2のInitial Attachのシーケンスについての出力例を示す。各装置の装置IDは図12の装置IDテーブルに図示したとおりである。
【００４６】
次に、図7と図9と図10を用いて、パケット紐付け処理部740が装置呼処理ID別パケット列765から複数の呼処理装置111-115にまたがって、同一シーケンスに属するパケットを収集して、図２のシーケンスを復元する処理について説明する。
【００４７】
図9はパケット紐付け処理部740が装置呼処理ＩＤ別パケット列765から、一連のシーケンスに属するパケットを紐付けていきシーケンスを復元する処理を示すフロー図である。パケット紐付け処理部740は、紐付け処理の開始トリガーを検出して処理の開始を指示する開始判定部746で監視している装置呼処理ID別パケット列765の数が、システム管理者が設定した一定量を超えた事を契機として、パケットの紐付け処理を開始する(900)。前記契機は呼処理装置119が解析用パケット300のタイプ305に呼処理の開始・終了を指定する情報を格納し、開始判定部746が装置呼処理ID別パケット列765を調べて開始の情報と終了の情報の両者が揃った事を契機としてもよい。または、開始判定部746がタイマーを備え、装置呼処理ID別パケット列765が生成され始めてから一定時間が経過したことを契機に紐付けを開始しても良い。
【００４８】
次にパケット紐付け処理部740は、装置呼処理ID別パケット列765の中で紐付けを開始するパケット列、例えばパケット列1020の先頭のパケット1021の装置ID1091と呼処理ID1092の組を取得する(901)。フローチャートでは簡単のため、ここで取得した装置呼処理ID1091,1092を「S」と表記する。ここでは「S」はパケット列1020の装置呼処理IDであるID=”120”、呼処理ID=”100”の組である。また、処理901では紐付けができるパケット列が複数ある場合、どの装置呼処理ID別パケット列765から処理を開始してもよい。
【００４９】
次にパケット絞込み部741は「S」で特定されるパケット列の先頭のパケット1021を取得する(902)。図9のフローチャートでは該当パケット1021を「P」と表記する。パケット絞込み部741は「P」に含まれるIPアドレスと、送信・受信フラグ1093と、送信・受信時刻1094と、を利用して比較するパケット数を絞り込む(903)。パケット絞込み部741は、送信・受信フラグ1092よりパケット1021は受信パケットなので送信元のIPアドレスを用いて、装置IDテーブル1200のIPアドレス1201をキーとして対応する装置、つまり当該パケットを送信した装置の装置ID1302を取得する。該当するIPアドレス1201はeNodeB111のもので、装置ID1202として”110”が得られる。
【００５０】
この例では、パケット1021を送信した装置はeNodeB111で、その装置IDは”110”であることが分かる。これにより比較対象の装置ID1091を”110”に絞り込む。図10のパケット列1010-1050の内、装置ID1091の値が”110”のものは、パケット列1010である。図10では省略しているが、解析装置101には装置ID1091＝”110”で他の呼処理ID1092を持ったパケット列も存在する。前記他のパケット列も含めて、「装置ID”110”のパケット列」と表記する。「装置ID”110”のパケット列」にはパケット列1010が含まれる。
【００５１】
次にパケット絞込み部741は、「装置ID”110”のパケット列」からさらに検索対象となるパケット列を絞り込む。パケット絞込み部741はパケット比較用テーブル1100の受信装置ID1101が”120”で、送信装置ID1102が”110”のエントリを検索し、当該エントリの探索時間範囲1104から絞り込む時間の範囲を取得し、該当する時間範囲外のパケットを「装置ID”110”のパケット列」から除外する。さらにパケット絞込み部741は、パケット1021の送信・受信フラグ1093が受信パケットを示すことから、「装置ID”110”のパケット列」から、送信パケットのみを抽出する。なお、この説明では時間で絞り込んだ後で送信・受信の別による絞込みを行なう例を記載したが、先に送信・受信の別での絞込みを行なってから、送受信時間での絞込みを後で行っても良い。前記処理によりパケット絞込み部741が抽出した、比較対象時間内かつ送信パケットのみのパケット列を「装置ID”110”の送信パケット列」と表記する。
【００５２】
次に、ペイロード比較部744はパケット比較用テーブル1100のパケット比較キー種別1103から比較するペイロードの設定を取得する。以下、ペイロード比較時にはIPペイロードを比較することとする。IPペイロードとする理由は、呼処理装置の間にスイッチやルーターがある場合に、IP以下のヘッダフィールドが編集されるからである。なお、パケット1096に含まれる情報のうち、IPペイロード以外の部分を比較対象としても良い。ペイロード比較部744はパケット1021のペイロードと「装置ID”110”の送信パケット列」のパケットのペイロードを時刻順に比較する(904)。
【００５３】
ペイロード比較部744は上記ペイロード比較を「装置ID”110”の送信パケット列」のすべてのパケットについて行う。「装置ID”110”の送信パケット列」の内、パケット列1010に含まれるパケット1011のパケット本体1096に含まれるパケットのペイロードと、パケット1021のパケット本体1096に含まれるパケットのペイロードとがマッチする(904)。フローチャートではマッチしたパケット1012を「Pt」と表記する。ここで、図10では「装置ID”110”の送信パケット列」について、呼処理ID1092の値が”100”以外のパケット列の記載を省略している。装置ID1091が同じで呼処理ID1092が異なるパケット列が複数混在していても、ペイロードの呼情報や他のメッセージ情報がパケット毎に異なる。そのためパケット1021と同一のペイロードを持つパケットを検出することで、「S」の装置呼処理ID1091、1092と同一シーケンスに属するパケット1012を抽出することができる。また、時刻順に比較し、パケット比較用テーブル1100のパケットマッチ用探索時間範囲1104で指定する時間内のパケットであるが、他の装置で送受信しているパケットと対応が取れない（マッチしない）パケットは、ミスマッチとなる。前記ミスマッチとなる場合は実施例2で説明するため、ここでは割愛する。
【００５４】
次にペイロード比較部744はパケット1021(Attach Request202)とパケット1012(Attach Request202)をシーケンス収集結果パケット列767に格納する。図13はシーケンス収集結果パケット列767の構成例であり、パケット1021はパケット列767のエントリ1302に格納され、パケット1012はパケット列767のエントリ1301に格納されている。ペイロード比較部744は、格納時に比較元にしたパケット1021の探査済み列1390に探査済みであることを保存する。ここでは、シーケンス収集結果パケット列767として図2のInitial Attachパケット列のパケット1301と1302を格納した場合を図示している(905)。
【００５５】
次にペイロード比較部744はパケット1021の装置呼処理ID1091、1092（装置ID=”120”、呼処理ID=”100”）に次のパケットがあるか、つまりパケット列1020に未処理のパケットがあるか否かを調べる(906)。パケット列1020のパケット1022があるため、判定はyesとなり、次の処理へ進む（907）。パケット紐付け処理部740は新たにパケット1022を「P」と置き(907)、前記処理(903-905)を繰り返す。以降、パケット紐付け部740はパケット列1020について処理をパケット1027まで繰り返す。ここでは、前述したパケット1021とパケット1012の他、パケット1022を元にパケット1051を、パケット1023を元にパケット1052を、パケット1024を元にパケット1031を、パケット1025を元にパケット1034を、パケット1026を元にパケット1013を、パケット1027を元にパケット1016をシーケンス収集結果パケット列767に格納する。
【００５６】
次に、未探索判定部745はシーケンス収集結果パケット列767に格納された、パケット列1020の装置呼処理ID1091,1092（装置ID=”120”、呼処理ID=“100”）、パケット列1010の装置呼処理ID1091,1092（装置ID=”110”、呼処理ID=”1”）とパケット列1050の装置呼処理ID1091,1092（装置ID=”150”、呼処理ID=”10”）とパケット列1030の装置呼処理ID1091,1092（装置ID=”130”、呼処理ID=”1000”）の内、Initial Attachのシーケンス収集結果パケット列1300の探査済み列1390から「S」と置いたことのない（比較元として扱っていない）装置呼処理IDを判定し(908)、それを新たに「S」と置いて(909)、絞込み処理を実行する(903)。ここでは、上記パケット列1010、1050、1030の装置呼処理ID1091,1092が処理対象となるため順次実行する。まず、パケット列1010の装置呼処理ID1091,1092を新たにSと置く。
【００５７】
次にペイロード比較部744は、パケット列1010の装置呼処理ID1091,1092について、紐付け処理（902-907）を実行する。このとき、パケット列1010には新たにペイロードがマッチするパケットはない。このとき、既にInitial Attachパケット列1300に保存しているパケット1012と1021のペイロードがマッチするが、ペイロード比較部744はInitial Attachのシーケンス収集結果パケット列1300にパケット1021を格納する前に、装置呼処理ID1091,1092（装置ID=”110”、呼処理ID=”1”）と送受信時刻304（T3、T2）が一致するパケットが格納されているかを調べ、格納されている場合はマッチしたパケット1021を保存しない。続いてペイロード比較部744はパケット列1050の装置呼処理ID1092,1092についても処理を行い、新たにマッチするパケットは無い。次にペイロード比較部744はパケット列1030の装置呼処理ID1092,1092を元に比較処理を行う（902-907）。ここでは、パケット1032を元にパケット1041が、パケット1033を元にパケット1042がInitial Attachパケット列1300 に保存される(903-907)。さらに、ペイロード比較部744は新たにパケット列1040の装置呼処理ID1092,1092を「S」と置き（908、909）同様の処理を繰り返す（902-907）。
【００５８】
以上のように、パケット紐付け処理部740はペイロードがマッチした装置呼処理ID1091,1092が複数ある場合は全ての装置呼処理ID1091,1092について図9に示す前述の処理を実行することで、全ての呼処理装置111-115について１つのProcedureの開始から終了までの呼処理パケット列1010-1050をシーケンス収集結果パケット列767に格納する事ができる。
【００５９】
新たに「S」とする装置呼処理ID1091,1092が無くなると、パケット紐付け処理部740は該当する呼処理のシーケンスを再現できたと判断し（908）、別の呼処理である新規のシーケンス再現処理へ移る(910)。処理部720は、「S」を新たな装置呼処理ID1091,1092とし（911）、該当するシーケンスに属するパケットを格納するメモリ領域を割り当て(912)、処理を繰り返す。
【００６０】
装置呼処理ID別パケット列765が生成されていない事を開始判定部746が判定(910)した場合は、そこでパケット紐付け処理部740の処理は終了となる。新たな解析用パケット300が呼処理装置111-115から解析装置101に送信されていれば、解析装置101は次々に前記処理を実行する。以上の実施例により、Initial Attachの正常なシーケンスが再現され、図10のパケット列を入力として、図13のInitial Attachの呼制御パケット列が出力される。
【００６１】
再現したシーケンスを利用し、呼処理のシーケンスが正常に処理されていることを一目で確認でき、呼処理装置増設時や切り替え時など、呼処理シーケンスを追って動作確認が容易になる効果が得られる。また、上記効果を得るに当たって、本手法では、呼処理装置が付加する専用のヘッダを解析装置が利用することと、ペイロードの比較とで実現するため、解析装置がLTEシステムの動作を模擬するような複雑な仕組みを必要としないメリットがある。
【実施例２】
【００６２】
本実施例では、正常シーケンスだけでなく、異常がある場合にもシーケンスの再現ができる例を示し、さらに、再現した後に正常・異常の判定を行い異常と判定されたシーケンスのみをストレージ770保存する例を説明する。
【００６３】
図14は、実施例２における再送パケットを含むシーケンスの例であり、図２に示したシーケンスの一部でもある。図14のパケット列のうち、既に説明した図2と同一の符号を付された部分については、説明を省略する。図14と図2の異なる点は、SGW113からPGW114に向けて送信される図2のCreate Session Request206が、図14では信号1401がパケットロスし、信号1402が再送されている点である。信号1401、1402も信号206と同じCreate Session Requestのメッセージである。
【００６４】
図15はパケットがロスして再送があった場合に、パケット紐付け処理部740がシーケンスを再現するためのフローチャートである。既に図９で説明した部分については、説明を省略する。ロスパケット1401が存在しても、パケット紐付け処理部740がシーケンスを再現するため、図15では図9の処理フローに分岐1501と処理1502を追加する。また、異常解析部750が異常の判定を行うために処理1503を追加する。
【００６５】
実施例１で、ペイロード比較部744が実行するペイロードの比較処理(904)において、「P」がロスしたパケット1401であった場合を考える。このとき、ペイロードの比較処理(904)で装置呼処理ID別パケット列765の中にマッチするパケットが無いため、判定結果はnoに分岐する(1501)。ここで、SGW113が送信するCreate Session Request1401のパケットと、PGW114が受信するCreate Session Request1402のパケットとがマッチしないのは、パケット1401の送信後、パケット1402を再送するまでの時間が、パケット比較用テーブル771のパケットマッチ用探索時刻範囲1104よりも長い場合であり、パケットマッチ用探索時刻範囲1104には通常、パケットの再送処理に要する時間よりも短い時間を設定しておく。マッチしなかった場合は、パケット紐付け処理部740は次のパケットの処理を開始する（906）。次のパケットは再送パケット1402であり、このパケットはPGW114で受信されているため、ペイロード比較処理でマッチする（904）。ペイロード比較部744はマッチしたパケット1402の比較先パケットと比較元のパケット1402および、比較元のパケット1402と同じ装置呼処理ID1901、1902を持つパケット列をシーケンス収集結果パケット列767に保存する(1502)。これにより、再送パケット1402と同じ装置呼処理ID1901、1902を持つロスパケットもシーケンス収集結果パケット列767 に格納することができる(905)。上記より、パケットロスがある場合にもシーケンスの再現が可能である。
【００６６】
また、上記処理で収集が完了したシーケンス収集結果パケット列767について、異常解析部750はタイプ1395をチェックすることで、はシーケンス内に異常があったことを識別できる(1503)。なお、プロトコル処理部430が、メッセージの送信や受信が正常に行なわれたか否かを、タイプ1395に登録する。
【００６７】
前記記録したタイプ1395の異常情報を利用することで、異常解析部750は異常シーケンスのみを保存する、ストレージ容量が限られる場合に、正常シーケンスよりも異常シーケンスを優先して保存する、正常シーケンスと異常シーケンスを分けて保存するなどの判定を行うことが可能となる。これにより、保守者が行う問題の分析の効率化やキャプチャデータ用のストレージ102の節約が可能となる。
【実施例３】
【００６８】
本実施例では、問題が現在化したノードからシーケンスを辿って解析することで、原因が特定され対策が可能となる例を説明する。実施例として、MME112がeNodeB111からAttachRequest202をバースト受信した場合に、バーストを構成するパケット列とMME112から送信されるCreate Session Request205を紐付け、Create Session Request205のIMEI(International Mobile Equipment Identity)から端末機種を特定する例を示す。ここで、IMEIとはユーザが使用する端末固有に割り当てられた識別番号であり、該端末の機種などの情報を持つ。また、バーストとは一定値以上の高帯域のトラフィックが一定時間続く状態を意味する。また、バースト受信とは、バーストトラフィックを呼処理装置111-115のような通信ノードが受信することを意味する。通信ノードがバースト受信した場合に処理能力が足りないときは、輻輳が起こり、対策が必要となる。
【００６９】
図16を用いて、異常解析部750による処理を説明する。まず、異常解析部750はシーケンス収集結果パケット列767の受信・送信時刻1394からバーストの検出を行う(1601)。バーストの検出方法は、例えば、前記受信・送信時刻1394を用いて、装置ID1391毎に送受信フラグ1393により一定時間内の受信量を計算し、受信パケット数が所定の閾値を超えていればバースト受信と判定することができる。バーストを検出した場合(1602)、異常解析部750は機種別の統計を取る(1603)。機種別の統計を取る方法について説明する。異常解析部750は装置ID1391を元にバーストを発生させたMME112を特定し、前記MME112が送信したCreate Session Request205のIMEIを調べることにより端末機種を識別する。識別した機種で統計値を計数することができる。
【００７０】
異常解析部750は前記統計情報を監視し、特定機種の統計情報が閾値以上となった場合に、その端末機種がバーストの原因であることを判定できる。異常解析部750は原因機種を判定すると保守者に通知を行う(1604)。ここで、バーストを起こす端末機種を特定するためには、バーストの検知と、前記検知したバーストを構成するパケットのIMEIを知る必要がある。また、eNodeB111とMME112間のパケットのIMEIを含むフィールドは暗号化されている。そのため本手法を用いてパケットの紐付けを行わない場合、暗号化されたIMEIを抽出する必要があり、困難となる。本件発明では、対抗装置間で送受信したパケット同士を比較するため、暗号化されたパケットも暗号化されたままマッチングすれば同じパケットかどうかを判断できるため、暗号を解く必要が無い。
【００７１】
上記により、バーストを起こすパケットとMME112の送信パケットを紐付けることで、バースト受信の原因となる端末機種を特定することが可能となる。機種を特定することで輻輳のような障害の原因の絞込みが可能となり、例えばその機種にのみ利用されるアプリケーションに絞って調査することで問題の原因特定を簡単化し、該当するアプリケーションを発見できた場合に、該アプリケーションの製造者に対策を依頼するなどの対策が可能となる。
【実施例４】
【００７２】
潜在する問題をかかえるノードが原因となり、他の正常ノードに障害が起こった場合に、シーケンスに沿って解析することで障害の元となる前記障害の原因となるノードを特定する例を説明する。本実施例では上記実施例2で再現した図13のパケット列によるシーケンスを利用する。シーケンスの再現方法は実施例2と同様とする。また、本実施例では実施例1、実施例2と同じ図を用いて説明し、追加部分については図を省略する。
【００７３】
実施例として、eNodeB111が異常動作し、Attach request202の再送を短時間で頻発させた場合に、他の呼処理装置が正常動作しているにも関わらず、MME112に接続されるSGW113やHSS115で負荷が増加してしまう場合を考える。このとき、例えばHSS115が輻輳し障害が起こってしまった場合に、eNodeB111に原因があることを検出する例を示す。
【００７４】
まず異常解析部750は、所定の方法により特定されたHSS115の障害時刻と、パケット列1300の送受信時刻1394と、装置ID1391と、を元に、HSS115に障害が起こる直前のシーケンス郡からHSS115の装置ID1391を持つパケット列1300を抽出する。障害時刻を特定する方法については、例えばシステム管理者が解析装置101に入力する、または異常解析部750がHSS115から受信した警報を契機にするなどの方法がある。
【００７５】
次に、異常解析部750は抽出した異常シーケンス郡についてタイプ1395別かつ装置ID1301別にパケット数を計数する。再送が繰り返されている場合、計数結果はタイプ1395については再送に偏り、さらに再送している装置ID1391と再送パケットを受信している装置ID1391が判明する。これにより、システム管理者は該HSS115宛にeNodeB111が再送を繰り返している事を発見できる。
【００７６】
以上のように再現したシーケンスのパケット列1300を利用して異常解析を行うことで、異常解析部750は障害が顕在化したHSS115の障害時刻とHSS115の装置ID1391とその他解析用の情報を元に、問題の原因となるeNodeB111に容易にたどり着くことが可能となる。
【００７７】
上記のような障害が、例えば、eNodeB111の再送タイム（再送時間間隔）の設定ミスによりおこった場合、障害が顕在化したHSS115やそれに隣接しているMME112が問題の原因であると誤解される可能性が高い。また、HSS115のパケットキャプチャと障害ログのみを利用して、前記障害の原因となるeNodeB111を特定することは困難である。このような場合であっても、本実施例により、障害の原因を素早く特定することが可能となる。
【００７８】
以上の複数の実施例では、呼処理装置が呼処理において装置内部に保持するシーケンスの再現に必要な情報（以下、解析用情報とする）を受信・送信パケットに付加し解析用パケットを生成するステップと、前記解析用パケットを、解析用に外部装置に送信するステップと、前記解析用パケットを受信して解析し、同一シーケンスに属するパケット列を紐付け、呼処理シーケンスを再現するステップと、再現したシーケンスについて、異常を検出する異常検出ステップと、前記検出した異常に基づいて、保存するパケット列を選択するステップと、を含む呼処理シーケンスを再現し保存する方法について具体的な実施例とともに説明した。
【００７９】
また、送信または受信した呼処理パケットに解析用情報を付加し、解析用パケットを生成し解析装置に送信する呼処理装置を有し、呼処理装置から解析用パケットを受け取り、解析・収集しシーケンスを再現する解析装置を有し、解析装置の解析と収集処理を効率化するためのデータを保持するデータベースを有し、前記呼処理装置は、呼処理において、処理中のシーケンスを識別するための情報と関連付けて、装置内の呼処理を識別する識別子（呼処理ID）を呼処理毎に生成し保持する手段と、呼処理IDを解析用情報の一部としてパケットに付加する手段と、前期解析用情報として、解析装置が呼処理装置を識別するための装置ID、パケットが受信パケットであるか、送信パケットであるかを示す送信・受信フラグ、パケットが送信・受信された物理ポート、パケットの送信・受信時刻、パケットの処理が正常に行われたか、再送のような異常であったかを示すタイプ情報を保持し、パケットに付加する手段を備え、前記解析装置は解析用パケットを受信し、装置IDと呼処理IDにより装置毎に同一シーケンスのパケットを分類する手段と、装置別・呼処理ID別に分類したパケット列から、2つの装置間のパケットについて送信パケットと受信パケットのペイロードを比較し、一致していれば同一のシーケンスに属していると判定し、該当するシーケンスに紐付ける手段と、前記ペイロード比較の前処理として、パケットの送信先・送信元アドレスと送信・受信時刻を利用して、比較対象のパケット数を絞り込む手段と、再現したシーケンスに属するパケット列の解析用情報を調べ、再送など異常が起こったシーケンスを識別する手段と、そのシーケンスに属する呼処理装置を特定し記録、表示する手段と、解析用情報または呼処理パケットのフィールド値をキーとして、データベースの情報を利用する手段とを備え、前記データベースは、比較するパケット数の絞込み処理において、解析用情報またはパケットのヘッダ情報をキーとして、絞り込み用の情報と、パケットのペイロード比較処理において、解析用情報をキーとしてペイロードのオフセット情報を保持し解析装置に提供する手段とを備えることを特徴とする呼処理のシーケンスを再現するシステムについて説明した。
【００８０】
これら複数の実施例による説明のとおり、これら実施例の少なくとも１つによると、以下の効果を得ることができる。保守者または、解析装置は再現されたシーケンスを利用することで、呼処理シーケンスに沿った分析が可能となり、異常原因の特定を効率化できる。呼処理装置が正常送信や再送などの処理内容をパケットに付加することで、解析装置は再現したシーケンスに異常が起こったかどうかを判定でき、また、前記異常シーケンスに関わる呼処理装置を抽出できる。また、解析装置が正常シーケンスと異常シーケンスを識別することで、例えば、異常が起こった場合のシーケンスのみを解析装置に保存させる等のストレージ利用方法が可能となり、保守者はパケットキャプチャ用のストレージ容量を削減できる。また、解析装置に異常なシーケンスについて統計を記録させることで、例えば、異常が起こりやすい経路や呼処理装置を分析するなどの傾向分析に応用するための基礎データを収集できる。
【００８１】
また、呼処理装置において呼処理に追加される処理は解析用情報の付加と解析装置への転送のみであり、本発明の実装による呼処理装置の負荷への影響は小さい。解析装置は受信した解析用パケットに付加された解析用情報を利用してシーケンスの再現を行うため、高いレイヤーを解析するDPI(Deep Packet Inspection)のような処理を必要としない。そのため解析装置の処理負荷は低付加に抑えることができる。呼処理装置が付加した受信・送信時刻情報を利用することにより、保守者または解析装置は再現したシーケンスに沿って全呼処理装置間の遅延時間を観測できる。
【符号の説明】
【００８２】
101 解析装置  
102 キャプチャ用ストレージ、DB用ストレージ
110 UE
111 eNodeB
112 MME
113 SGW
114 PGW
115 HSS
120 PDN
201,202 Attach Request
203 Update location request
204 Update location response
205,206 Create session request
207, 208 Create session response
209 Attach accept
210 RB establishment request
211 RB establishment response
212 Attach complete
300 解析用パケット
301 装置ID
302 送信・受信ポート
303 呼処理ID
304 送信・受信フラグ
305 送信・受信時刻
306 タイプ
307 呼制御用パケット
401 呼処理装置受信部
402 呼処理装置呼処理部
601 GUTIと呼処理ID
602 IMSIと呼処理ID 
701 送受信部
702 装置ID・呼処理ID分類処理部
703パケット紐付け処理部
704異常解析部
705 パケット格納用ストレージ
1010 eNodeBパケット列
1020 MMEパケット列
1030 SGWパケット列
1040 PGWパケット列
1050 HSSパケット列
1101 解析用条件テーブル
1201 装置ID解決テーブル
1401 破棄されたCreate session request
1402 再送されたCreate session request
【図１】
2015204538.tif 000003
【図２】
2015204538.tif 000004
【図３】
2015204538.tif 000005
【図４】
2015204538.tif 000006
【図５−Ａ】
2015204538.tif 000007
【図５−Ｂ】
2015204538.tif 000008
【図６】
2015204538.tif 000009
【図７】
2015204538.tif 000010
【図８】
2015204538.tif 000011
【図９】
2015204538.tif 000012
【図１０】
2015204538.tif 000013
【図１１】
2015204538.tif 000014
【図１２】
2015204538.tif 000015
【図１３】
2015204538.tif 000016
【図１４】
2015204538.tif 000017
【図１５】
2015204538.tif 000018
【図１６】
2015204538.tif 000019