(57)【要約】【課題】ＩＰなどのパケットネットワーク上において提供されるサービスの効果的な識別手法を提供する。【解決手段】パケットデータシステムを介して提供されるサービスを識別する方法が提供される。この方法は、通信ネットワーク内においてデータ伝送サービスをサポートする通信リンクを流れるデータパケットを監視するステップと、データ伝送サービスに関係するアクセスポイントを識別する第１情報をデータパケットの内容に従って導出するステップと、データ伝送サービスに関係する提供アプリケーションサービスと関連したネットワークアドレス及びポート番号を識別する第２情報をデータパケットの内容に従って導出するステップと、データ伝送サービスに関連するＵＲＩを有する第３情報をデータパケットの内容に従って導出するステップと、これら第１、第２、及び第３情報を結び付けてデータ伝送サービスのＩＤを提供するステップと、を有する。【選択図】図３
2005184810.tif 000002
【特許請求の範囲】
【請求項１】
パケットデータシステムを介して提供されるサービスを識別する方法であって、
通信ネットワーク内のデータ伝送サービスをサポートする通信リンクを通過するデータパケットを監視するステップと、
前記データ伝送サービスに関係するアクセスポイントを識別する第１情報を前記データパケットの内容に従って導出するステップと、
前記データ伝送サービスと関係する提供アプリケーションサービスと関連したネットワークアドレス及びポート番号を識別する第２情報を前記データパケットの内容に従って導出するステップと、
前記データ伝送サービスに関係するＵＲＩを有する第３情報を前記データパケットの内容に従って導出するステップと、
前記第１、第２、及び第３情報を結び付けて前記データ伝送サービスのＩＤを提供するステップと、を有する方法。
【請求項２】
前記データ伝送サービスは、ＧＰＲＳ又はＵＭＴＳであり、前記第１情報は、ＡＰＮとなるように導出される、請求項１記載の方法。
【請求項３】
前記データ伝送サービスは、ＧＰＲＳ又はＵＭＴＳ以外であり、前記第１情報は、ＮＵＬＬ値となるように導出される、請求項１記載の方法。
【請求項４】
パケットデータシステムを介して提供されるサービスを識別する装置であって、
通信ネットワーク内のデータ伝送サービスをサポートする通信リンクを通過するデータパケットを監視するモニタと、
前記データ伝送サービスに関係するアクセスポイントを識別する第１情報を前記データパケットの内容に従って導出する第１導出器と、
前記データ伝送サービスと関係する提供アプリケーションサービスと関連したネットワークアドレス及びポート番号を識別する第２情報を前記データパケットの内容に従って導出する第２導出器と、
前記データ伝送サービスに関連するＵＲＩを有する第３情報を前記データパケットの内容に従って導出する第３導出器と、
前記第１、第２、及び第３情報を結び付けて前記データ伝送サービスのＩＤを提供するコンカテネータと、を有する装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、ＧＳＭ携帯電話ネットワーク内において提供可能なＧＰＲＳ（General Packet Radio Service、汎用パケット無線サービス）を介するものなどの、ＩＰ（Internet Protocol、インターネットプロトコル）並びに類似のパケットネットワークを介して提供されるサービスの識別と、これらサービスの使用状況を要約するサービス使用状況レコード（service usage record、ＳＵＲ）の生成のための方法及び装置に関するものである。
【背景技術】
【０００２】
ＧＳＭ携帯電話ネットワークにおいては、シグナリングシステムを使用してその動作を調整している。このシグナリングシステムは、通常、ＩＴＵのＳＳ７（Signalling System No. 7）プロトコルスイートに従って動作している。ネットワークの稼働状況を観測すると共に、ネットワーク設備の使用状況に関する情報を取得するべく、このシグナリングシステムを流れるＳＳ７シグナリングメッセージを監視することが知られている。このような情報は、しばしば、ＣＤＲ（Call Detail Records）（例：音声通話の場合）及びＴＤＲ（Transaction Detail Records）（例：その他のＧＳＭサービスを使用する場合）によって収集される。例えば、音声サービスの使用状況を要約するＣＤＲを作成するには、ＳＳ７のＩＳＵＰ（ISDN User Part）プロトコルメッセージが使用され、メッセージング、モビリティ、及びアクセス管理活動のサマリを取りまとめるには、ＴＣＡＰ（Transaction Capabilities Application Part）プロトコルによってサポートされているＳＳ７のＭＡＰ（Mobile Application Part）プロトコルメッセージが使用される。
【０００３】
ＧＰＲＳネットワークにおいて類似の機能を提供するには、例えば、ウェブの閲覧や電子メールサービスなどのＩＰサービス使用状況を要約するべく、トランザクションビルダを追加することが必要となる。この結果生成されるトランザクションサマリは、通常、ＩＰＤＲ（IP Data Record）又はＳＵＲ（Service Usage Record）と呼ばれている。尚、このＳＵＲを作成するシステムの一例については、特許文献１に記述されている。
【０００４】
データサービス使用状況レコードを作成する際には、使用されている実際のデータサービスを識別できることが望ましい。ＧＰＲＳネットワークに現在導入されている無線アプリケーションにおいては、ＧＰＲＳのＡＰＮ（Access Point Name、アクセスポイント名）とアプリケーションプロトコルを使用することにより、これらのサービス間を弁別している。例えば、１つのＡＰＮを使用することにより、複数のＷＡＰ（Wireless Application Protocol）サービスをホスティングすることが可能であり、ＧＰＲＳコアネットワーク内のすべてのＷＡＰトラフィックが、このＡＰＮを通じてルーティングされる。従って、関連するＡＰＮを識別するだけで、ネットワーク内のＷＡＰトラフィックフローを十分に識別することができる。このＡＰＮに関して生成されるすべてのサービス使用状況レコードには、「ＷＡＰサービス」とタグ付けすることが可能であり、管理及び報告アプリケーションは、このタグを使用して、ネットワーク内におけるＷＡＰアクティビティをモデル化並びに報告することができる。
【特許文献１】英国特許出願公開第０３１３８１２．０号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、１つのＡＰＮ上において、多数のサービスを多重化することが可能である。例えば、システムは、１つのＡＰＮを使用することにより、着信音のダウンロード、ＭＭＳ（Multimedia Messaging Service）メッセージ、オーディオクリップ、及び道路交通サービスのすべてを提供する設備をサポートすることができる。これらのサービス間を弁別するには、基本的にＡＰＮとアプリケーションプロトコルを組み合わせて使用することが考えられよう。しかしながら、このシステム上のクライアントは、このＡＰＮ内のサービスのアプリケーションプロトコルとしてＷＡＰを使用しており、大部分のＧＰＲＳ装置においては、サービスのアクセスにＷＡＰのみを使用している。従って、異なるサードパーティの供給者が提供している着信音のダウンロードと道路交通サービスを互いに区別することは不可能である。ＡＰＮを使用する際の更なる欠点は、これが、ＧＰＲＳ及びＵＭＴＳ（Universal Mobile Telecommunications System）における概念でしかなく、有線やＣＤＭＡ２０００ネットワークには、この等価物が存在しないことである。
【０００６】
ＩＰ並びに類似のネットワーク上において提供されるサービスの効果的な識別に対する要件は、次のとおりである。
【０００７】
（１）その方法は、無線（ＧＰＲＳ、ＵＭＴＳ、及びＣＤＭＡ２０００）及び有線データネットワークの両方に適用可能である必要がある。
【０００８】
（２）ＩＰｖ４又はＩＰｖ６プロトコルを使用するネットワークのいずれにおいても機能する必要がある。
【０００９】
（３）コンテンツに基づいたサービスの弁別が非常に望ましい。データサービスのモデル化と管理は、実際には、データ供給に使用するアプリケーションプロトコルやトランスポートプロトコルではなく、コンテンツタイプにより密接に関連している。
【００１０】
ＩＰネットワークにおいて現在最も頻繁に使用並びに遭遇するサービス識別メカニズムは、Ｕｎｉｘ（登録商標）オペレーティングシステムが提供しているstandard/etc/servicesファイルを使用をして成し遂げた単純なポートマッピングである。例えば、電子メールサービスは、ＳＭＴＰ（Simple Mail Transfer Protocol）、ＰＯＰ（Post Office Protocol）、及びＩＭＡＰ（Internet Message Access Protocol）によって提供され、ＩＰ上において提供されているサービスに関係するプロトコルメッセージ内に、ポート番号２５（ＳＭＴＰ）、１０９（ＰＯＰｖ２）、１１０（ＰＯＰｖ３）、又は１４３（ＩＭＡＰ）が観測された場合に、この旨を報告することができる。しかしながら、電子メールプロトコルを使用すれば、多数の異なる種類のコンテンツ（テキスト、ＨＴＭＬ、オーディオ、及びビデオ）を供給可能であり、ポート番号のみの使用によってコンテンツのタイプを識別することはできない。即ち、更に複雑且つ費用を要するコンテンツ分析を実行することにより、コンテンツのタイプを判定しなければならないのである。従って、ポート番号又はアプリケーションプロトコルに依存してコンテンツタイプを判定する方法も、ＡＰＮを使用する場合と同様に、満足できるものではない。
【課題を解決するための手段】
【００１１】
本発明の一態様によれば、パケットデータシステムを介して提供されるサービスを識別する方法が提供され、この方法は、通信ネットワーク内においてデータ伝送サービスをサポートする通信リンクを流れるデータパケットを監視するステップと；データ伝送サービスに関係するアクセスポイントを識別する第１情報をデータパケットの内容に従って導出するステップと；データ伝送サービスに関係する提供アプリケーションサービスと関連したネットワークアドレス及びポート番号を識別する第２情報をデータパケットの内容に従って導出するステップと；データ伝送サービスに関連するＵＲＩ（Uniform Resource Identifier）を有する第３情報をデータパケットの内容に従って導出するステップと；これら第１、第２、及び第３情報を結び付けてデータ伝送サービスのＩＤを提供するステップと；を有している。
【００１２】
従って、例えば、データパケット（シグナリング及びデータ）から観測される４つの変数を使用することにより、コンテンツを表すことができる。そして、サーバーとクライアント間において伝達されるコンテンツ又はそのデータ転送の理由を実際にチェックする必要性なしに、サービス使用状況をモデル化することができる。
【００１３】
本発明の別の態様によれば、パケットデータシステムを介して提供されるサービスを識別するための装置が提供され、この装置は、通信ネットワーク内におけるデータ伝送サービスをサポートする通信リンクを流れるデータパケットを監視するモニタと；データ伝送サービスに関係するアクセスポイントを識別する第１情報をデータパケットの内容に従って導出する第１導出器（Deriver）と；データ伝送サービスに関係する提供アプリケーションサービスと関連したネットワークアドレス及びポート番号を識別する第２情報をデータパケットの内容に従って導出する第２導出器と；データ伝送サービスに関係するＵＲＩ（Uniform Resource Identifier）を有する第３情報をデータパケットの内容に従って導出する第３導出器と；これら第１、第２、及び第３情報を結び付けてデータ伝送サービスのＩＤを提供するコンカテネータ（Concatenator、連結器）と；を有している。
【発明を実施するための最良の形態】
【００１４】
以下、システムを介して提供されるサービスの識別を含む、ＧＰＲＳシステムの使用状況を要約するＳＵＲを生成する本発明による方法及び装置について、一例として、添付の図面を参照して説明する。
【００１５】
図１は、ＧＰＲＳサービスを提供するべく構成されたＧＳＭネットワーク１０の主要機能コンポーネントを示している。図１を参照すれば、移動局（Mobile Station：ＭＳ）１２は、基地局コントローラ（Base Station Controller：ＢＳＣ）１６の制御の下に、無線（ＲＦ）インターフェイスにより、基地トランシーバ局（Base Transceiver Station：ＢＴＳ）１４と通信している。ＭＳ１２への音声通話の接続は、移動通信交換局（Mobile Switching Center：ＭＳＣ）１８によって調整されており、ショートメッセージサービス（Short Message Service：ＳＭＳ）機能は、ＳＭＳゲートウェイ（SMS Gateway：ＳＭＳＧ）２０によって提供される。ＭＳ１２及び加入者に関する管理情報は、機器識別レジスタ（Equipment Identity Register：ＥＩＲ）２２とホームロケーションレジスタ（Home Location Register：ＨＬＲ）２４からなるデータベース内に保持されている。当業者であれば、完全なＧＳＭシステムには、通常、ビジタロケーションレジスタ（Visitor Location Register：ＶＬＲ）などの図１には示されていない更なる機器が含まれることを認識するであろう。しかしながら、本発明の実装に直接的に関係しないこれらの機器については、わかりやすくするべく、この図から省略されている。
【００１６】
このシステムには、ＧＰＲＳサービスを提供するべく、ＳＧＳＮ（Serving GPRS Support Node）２６とＧＧＳＮ（Gateway GPRS Support Node）２８も含まれている。ＳＧＳＮ２６は、自身がサービスするエリア内においてＭＳとの間のパケット交換データのルーティングを行う。この主な機能は、パケットのルーティング、携帯電話の接続／切断手順、ロケーション管理、チャネル及び時間スロットの割り当て、認証、及び通話の課金である。一方、ＧＧＳＮ２８は、ＧＰＲＳシステムと外部パケットデータネットワーク（即ち、図１に示されているインターネット３０）間におけるインターフェイスとして機能している。ＧＧＳＮは、ＳＧＳＮ２６を介して受信したＧＰＲＳパケットを適切なパケットデータプロトコルフォーマット（例：ＩＰ（Internet Protocol））に変換し、外部インターネット３０に転送する。同様に、ＧＧＳＮは、受信したパケット内のＩＰアドレスを宛先ＭＳのＧＳＭアドレスに変換し、この変換済みのパケットを適切なＳＧＳＮ２６にルーティングする。
【００１７】
ＧＰＲＳの仕様によれば、次のように、ＳＧＳＮ２６及びＧＧＳＮ２８をＧＰＲＳシステムのその他のコンポーネントに接続するための様々なインターフェイスが定義されている。
【００１８】
・Ｇｉ（ＧＧＳＮ２８と外部インターネット３０間における通信用）
・Ｇｃ（ＧＧＳＮ２８とＨＬＲ２４間における通信用）
・Ｇｎ（ＧＧＳＮ２８とＳＧＳＮ２６間における通信用）
・Ｇｒ（ＳＧＳＮ２６とＨＬＲ２４間における通信用）
・Ｇｆ（ＳＧＳＮ２６とＥＬＲ２２間における通信用）
・Ｇｄ（ＳＧＳＮ２６とＳＭＳＧ２０間における通信用）
・Ｇｓ（ＳＧＳＮ２６とＭＳＣ１８間における通信用）
・Ｇｂ（ＳＧＳＮ２６とＢＳＣ１６間における通信用）
・Ｇｐ（ＳＧＳＮ２６及びＧＧＳＮ２８からその他のＧＰＲＳネットワーク３２のＧＳＮへの通信用）
これらのインターフェイスを実装したシグナリングリンクは、ＧＰＲＳ接続を生成、更新、及び削除するためのシグナリング情報と、認証、ＭＳロケーション、及びモビリティサポートなどのこれらの機能のサポートに必要なその他の情報を含むシグナリングパケットを伝送する。又、これらリンクの中には、データペイロードパケット（即ち、ＭＳ１２と外部インターネット３０間において交換されるデータを格納するパケット）を伝送するものも存在する（例：Ｇｉ、Ｇｎ、及びＧｂインターフェイス用のもの）。
【００１９】
それぞれのインターフェイスは、プロトコルスタックによって実装されており、必要な機能をＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）、ＧＴＰ、及びＩＰなどの広く使用されている様々な通信プロトコルを参照して定義することができる。図２には、ＳＧＳＮ２６とＧＧＳＮ２８間におけるＧｎインターフェイス用のプロトコルスタックが示されている。図２を参照すれば、レイヤ３４におけるユーザーアプリケーションプロトコルデータは、次のレイヤ３６を構成するＴＣＰ又はＵＤＰパケット内にカプセル化され、これらが、次にＩＰ（レイヤ３８：図示のごとく、これには、ＩＰｖ４又はＩＰｖ６のいずれかを使用可能である）によって伝送される。これらのレイヤ３４〜３８は、ＧＰＲＳによって提供されるＩＰサービスの加入者が使用するトランスポート及びアプリケーションレイヤを構成している。
【００２０】
ＧＰＲＳの場合には、レイヤ３８におけるＩＰパケットは、ＧＰＲＳのネットワーク要素（特に、ＳＧＳＮ２６及びＧＧＳＮ２８）に向かうＩＰリンク上において「トンネリング」される（即ち、それぞれのパケットは、別のＩＰパケット内にカプセル化され、このカプセル化されたパケットの内容が変更されることなしに、宛先に対して伝送される）。これは、ネットワーク要素がネットワークの外部から直接アドレッシングされることを防止し、これによってセキュリティを向上させるべく採用された方法である。このカプセル化を行うパケットは、参照符号４０によって示されているように、そのパケットがユーザーデータを格納していることを示す２５５というパケットヘッダ内のＭＴ（Message Type）値を有するようにＧＴＰにおいて指定されフォーマットされている。このＧＴＰメッセージは、ＵＤＰパスプロトコル（レイヤ４２）を使用し、ＩＰｖ４又はＩＰｖ６（レイヤ４４）上において転送される。これらのレイヤ４０〜４４は、通信（telecoms）トンネルシグナリングレイヤを構成している。
【００２１】
前述の特許文献１に記述されているように、Ｇｎインターフェイスリンクを流れるパケットを（後述するように）監視することにより、通信シグナリングの分析とサービス使用状況の分析を同時に実行可能である（この理由は、この目的のための十分な情報がＧｎプロトコルスタックに含まれているからである）。ＧＰＲＳネットワークトンネルを維持するシグナリングトランザクションは、このスタックの最下位の３つのレイヤ（４０〜４２）のみを参照する監視システム内の状態機械によって監視することができる。一方、加入者によるサービスの使用状況については、このスタックの上位の３レイヤ（３４〜３８）のみを使用して監視可能であり、これを実行する状態機械は、シグナリング分析を行う状態機械が提供するシグナリング情報に対して即時にアクセスすることができる。
【００２２】
実際には、ＳＵＲ生成器は、例えば、次の３つの補完的な状態機械を組み合わせることによって実装可能である。
【００２３】
・通信トンネルレイヤ（４０〜４４）において稼働するＧＴＰフォロワ状態機械
・サービストランスポートレイヤ（３６及び３８）用のＣＲＧ（Call Record Generator）
・サービスアプリケーションレイヤ（３４）用の１つ又は複数のＣＡ（Content Analysis）状態機械
ＧＴＰフォロワ状態機械は、Ｇｎインターフェイスリンク上における監視対象のすべてのメッセージを処理する。メッセージがＧＴＰシグナリングメッセージである場合には、これは、次のように処理される。
【００２４】
・「ＰＤＰコンテキスト生成要求（Create PDP Context Request）」メッセージと「ＰＤＰコンテキスト生成応答（Create PDP Context Response）」メッセージを使用し、トンネルレコードのＣＲＥＡＴＥトランザクションを作成すると共に、要求されたコンテキストと関連するトンネルの使用状況を追跡するための内部アカウンティング及び制御構造を生成する。この時点で、加入者ＩＭＳＩ及びネットワークＡＰＮフィールドをトンネル寿命にわたって保存する。又、この時点で、ネットワークＱｏＳ値も設定されるが、これは後から変更可能である。
【００２５】
・「ＰＤＰコンテキスト更新要求（Update PDP Context Request）」及び「ＰＤＰコンテキスト更新応答（Update PDP Context Response）」メッセージを使用し、ＵＰＤＡＴＥトランザクションを作成する。これは、主にトンネルのネットワークＱｏＳ値を維持するために使用される。
【００２６】
・「ＰＤＰコンテキスト削除要求（Delete PDP Context Request）」及び「ＰＤＰコンテキスト削除応答（Delete PDP Context Response）」メッセージを使用し、ＤＥＬＥＴＥトランザクションを作成する。これは、サービス使用状況の分析活動を終了すると共に、トンネル用のアカウンティング及び制御構造を破棄するために使用される。
【００２７】
２５５のＭＴ値を有するすべてのＧＴＰメッセージは、監視システム内の既存の制御構造に照らして検証された後に、更なる分析のために、ＣＲＧ及びＣＡ状態機械に伝達される。そして、これらの状態機械がＳＵＲをリリースする準備が整い次第、ＧＴＰフォロワによって実行されたシグナリング分析から得られた通信コンテキスト情報が直ちに手に入り、このＳＵＲと組み合わせることができる。
【００２８】
以下、これらのプロセスを実装する装置内の主要機能ブロックを示す図３を参照し、この概説したプロセスについて更に詳細に説明することとする。図３を参照すれば、Ｇｎリンク４６がリンク監視カード４８に接続されており、これらのリンクを流れるパケットを受動的に監視できるようになっている。尚、この監視は、リンク４６の動作が、カード４８に対する接続の存在によって妨げられない、という意味において受動的である。それぞれのカード４８は、メモリ（これは、データの保存にも使用される）内のソフトウェアプログラム命令の制御下において稼働するインターフェイスとプロセッサを有している。このインターフェイスは、リンクの動作特性が変化しないように、個々のカード４８をリンク４６に接続している。例えば、光リンク４６の場合には、この接続は、光パワースプリッタから構成され、電気リンクの場合には、この接続は、ブリッジングアイソレータ（Bridging Isolator）であり、Ethernetネットワークの場合には、ＬＡＮタップを使用することができる。
【００２９】
それぞれの監視カード４８におけるプロセッサ用のプログラム命令には、ＩＰシグナリングユニットの内容に関するレコードを生成するべくＧＴＰパーサー（parser）５０を実装するためのコードが含まれている。このＧＴＰパーサー５０は、ネットワークからＧＴＰシグナリング及びプロトコルメッセージを選択する。ＧＴＰパーサーは、Ｇｎインターフェイスリンク上のＩＰトラフィックを監視し、３３８６（ＧＴＰ  ｖ０）、２１２３（ＧＴＰ  ｖ１、ＧＴＰ−Ｃ制御プレーンメッセージ）、又は２１５２（ＧＴＰ  ｖ１、ＧＴＰ−Ｕユーザープレーンメッセージ）という発信元又は宛先ポート番号を有するＵＤＰトラフィックを選択することにより、これを実行する。
【００３０】
任意選択によって、ＩＰｖ４／ＩＰｖ６のアウターレイヤの宛先ＩＰアドレスに対してフィルタリングを実行することにより、ネットワークからのトラフィックの選択に更なるステップを施すことも可能である。この結果、１つの特定のネットワーク要素（ＧＧＳＮ又はＳＧＳＮ）のインターフェイス宛てのトラフィックを選択できるようになる。又、これにより、アドレス空間によるＩＰトラフィックのパーティショニングも容易になり、この結果、監視カード４８のレベルにおいて処理能力を管理できるようになる。
【００３１】
選択したそれぞれのパケットのＧＴＰヘッダを解析してＭＴフィールド値を抽出し、更なる処理のために、次のタイプを有するパケットを選択してタイムスタンプを付加する。
【００３２】
・「ＰＤＰコンテキスト生成要求（Create PDP Context Request）」（ＭＴ＝１６）
・「ＰＤＰコンテキスト生成応答（Create PDP Context Response）」（ＭＴ＝１７）
・「ＰＤＰコンテキスト更新要求（Update PDP Context Request）」（ＭＴ＝１８）
・「ＰＤＰコンテキスト更新応答（Update PDP Context Response）」（ＭＴ＝１９）
・「ＰＤＰコンテキスト削除要求（Delete PDP Context Request）」（ＭＴ＝２０）
・「ＰＤＰコンテキスト削除応答（Delete PDP Context Response）」（ＭＴ＝２１）
・「ＳＧＳＮコンテキスト要求（SGSN Context Request）」（ＭＴ＝５０）
・「ＳＧＳＮコンテキスト応答（SGSN Context Response）」（ＭＴ＝５１）
・「ＳＧＳＮコンテキストアクノリッジ（SGSN Context Acknowledge）」（ＭＴ＝５２）
・Ｔ−ＰＤＵ（ＧＴＰ  ｖ０）、Ｇ−ＰＤＵ（ＧＴＰ  ｖ１）（ＭＴ＝２５５）
その他のＧＴＰメッセージタイプは、すべて破棄する。
【００３３】
次いで、これらの選択されたＧＴＰメッセージは、更なる処理のために、リンク監視カード４８によって中央（例：サイトレベル）サーバー５２に転送され、入力マネージャモジュール５４によって受信される。このモジュールは、監視カードのＧＴＰパーサーから転送されたＧＴＰメッセージを照合し、時系列にソートする。この時系列のソートは、ＧＴＰパーサーによって付加されたタイムスタンプのスライディングウィンドウに基づいて実行され、このスライディングウィンドウのサイズは、入力ソースからのトラフィックの量とスループットに適合されている。次いで、入力マネージャモジュールは、これらの時系列にソートされたメッセージを、ＧＰＴフォロワ状態機械を実装するＧＴＰモジュール５６に伝達する。
【００３４】
このＧＴＰモジュール５６は、２つの機能を提供している。即ち、まず第１に、ＧＴＰシグナリングメッセージを処理し、そのトンネル状態情報の追跡を維持すると共に、第２に、ＧＴＰヘッダ内にゼロを上回るペイロード長の値を格納するすべてのプロトコルメッセージを転送する。
【００３５】
それぞれのトンネルごとに提供される情報は、次のとおりである。
【００３６】
・ＩＭＳＩ及びＮＳＡＰＩ（Network Service Access Point Identifier）
・ＡＰＮ
・ＱｏＳプロファイル
・トンネル開始アドレス（ＳＧＳＮ）
・トンネル終了アドレス（ＧＧＳＮ）
ＧＴＰモジュール５６によって処理されたそれぞれのメッセージは、それがＴ−ＰＤＵ／Ｇ−ＰＤＵであるか、或いはＧＴＰパーサー５０によって選択されたシグナリングメッセージの中の１つであるかに関してチェックを受ける。そして、シグナリングメッセージの場合には、トンネル状態情報を維持するべくＧＴＰモジュール５６によって使用され、その他のコンポーネントには伝達されない。
【００３７】
Ｔ−ＰＤＵ／Ｇ−ＰＤＵメッセージの場合には、それらが現在伝送されているトンネルコンテキストに関連付けられ、更なる処理のために、ＣＲＧモジュールに伝達される。
【００３８】
ＧＴＰモジュール５６は、その他のシステムコンポーネントがトンネルごとのデータエリアにアクセスするのに使用するサービスインターフェイスを提供している（それぞれのコンポーネントは、プライベートな状態情報をこのエリアに保存可能であり、ＳＵＲは、このエリアにおいて出力用に取りまとめられる）。
【００３９】
ＧＴＰモジュール５６が提供する更なるサービスは、その他のシステムモジュールに提供される「トラフィックフローの方向」情報の識別である。ＧＴＰモジュール５６が使用するパケットの方向判定方法は、単純であり、効率的且つ動的なものである。ＧＴＰシグナリング情報を処理することにより、ＧＴＰモジュール５６は、ネットワーク内における比較的少数のＧＧＳＮアドレスのキャッシュを識別及び維持することができる。すべてのトンネル活動は、ＧＧＳＮにおいて始まり、ＧＧＳＮにおいて終了しなければならないため、それぞれの監視対象のメッセージに対して、このモジュールは、携帯電話発（Mobile Originated）又は携帯電話着（Mobile Terminated）というタグを付加することができる。図２に示されているように、プロトコルスタックの最下位レイヤ４４は、トンネルＩＰレイヤであり、アドレスは、常に、ＳＧＳＮ２６又はＧＧＳＮ２８のアドレスである。「ＰＤＰコンテキスト生成（Create PDP Context）」メッセージ（ＭＴ＝１６）の分析により、ＧＧＳＮアドレスの組を動的に生成することができる。
【００４０】
例えば、ＧＴＰｖ０及びＧＴＰｖ１のCreateメッセージは、いずれも、常にＳＧＳＮインターフェイスである発信元アドレスとＧＧＳＮインターフェイスである宛先アドレスを有している。シグナリングメッセージを処理する際に（及び、新しいＧＧＳＮをネットワークに追加する際に）、これらのシグナリングメッセージを監視することにより、新しいインターフェイスアドレスが判明する。ＧＧＳＮアドレスがキャッシュ内に配置され次第、「トンネル宛先アドレスがＧＧＳＮの場合には、トンネリングされているデータは、携帯電話発（Mobile Originated）であり、さもなければ、トンネリングされているデータは、携帯電話着（Mobile Terminated）である」という規則により、トンネリングされているデータの方向（これは、図２内の上位ＩＰレイヤにおいて始まる）を判定することができる。
【００４１】
従って、数十万もの無線装置アドレスと数万ものコアネットワークアドレスについて考慮する必要はない。システムは、数十のトンネルエンドポイントアドレスに関する知識だけで、パケットが携帯電話発（Mobile Originated）であるか、或いは携帯電話着（Mobile Terminated）であるか、を全く確実に判定することができる。又、この方法によれば、トンネルシグナリングメッセージを使用して、トンネルエンドポイントのＩＰアドレスが動的に判定される。データトンネルのCreate、Update、及びDeleteシグナリングメッセージを使用し、ネットワークトンネルを提供するサーバーのＩＰアドレスをキャッシングする。ＧＰＲＳ又はＵＭＴＳネットワークの場合には、存在するトンネルサーバーは比較的少数であり、トンネルは、ＳＧＳＮにおいて始まり、ＧＧＳＮにおいて終了する。ネットワーク内に存在するＧＧＳＮの数は常に少なく、従って、これらのためのアドレスセットは、ＳＧＳＮ用のものよりも小さい。大規模なネットワークの場合には、例えば、６つのＳＧＳＮと４つのＧＧＳＮを有し、それぞれのＧＧＳＮが２つのＩＰネットワークインターフェイスを有している。従って、ネットワーク内のすべての無線データトラフィックの伝送方向を判定するのに、８要素のＩＰアドレスセットで十分であろう。
【００４２】
ＩＰパケットによって伝送されるデータサービスを識別するために、ＧＴＰモジュール５６は、ＧＴＰシグナリングパケットの内容を検査することによって導出されるＧＰＲＳ又はＵＭＴＳのＡＰＮ（Access  Point Name）をも保存する。これらのＡＰＮは、後述するＳＵＲフォーマッタ６２の一部を形成するＳＤＩ（Service Discovery Interface）モジュールに提供される。
【００４３】
ＣＲＧモジュール５８は、インナー又はトンネリングされているＩＰ及びＴＣＰ／ＵＤＰヘッダ（図２のレイヤ３６及び３８）のみを使用し、転送されたＴ−ＰＤＵ／Ｇ−ＰＤＵプロトコルメッセージからＴＣＰ及びＵＤＰトランザクションのレコード（即ち、「フローサマリ」を作成する。
【００４４】
ＣＲＧモジュールの機能の１つは、個々の計測値を単一のサマリレコードに取りまとめることである。このモジュールによって生成される計測値には、それぞれのサービスの起動に起因するパケット及びオクテットの計数とネットワーク性能に悪影響を与える異常なパケット及びオクテットシーケンスのＩＤが含まれる。この計数情報は、好都合なことに、アップストリーム（携帯電話発（Mobile Originated））とダウンストリーム（携帯電話着（Mobile Terminated））の計数に分割されている。
【００４５】
ＣＲＧモジュール５８は、ＧＴＰモジュール５６から転送されるすべてのＴ−ＰＤＵ／Ｇ−ＰＤＵメッセージを処理する。しかしながら、伝達されるのは、実際にアプリケーションレイヤコンテンツを格納するもののみであり、トランスポートシグナリングしか格納していないものは、このモジュールにより、処理ストリームからフィルタリングによって除去される。
【００４６】
図３に示されている例においては、単一のＣＲＧモジュール５８により、サービス起動ＴＣＰ及びＵＤＰトランスポートレイヤのサマリレコードが作成されている。システムの能力をＷＡＰ（wireless Application Protocol）サービスの提供に使用されるＷＳＰ（wireless Session Protocol）やＷＤＰ（wireless Datagram Protocol）などのその他のトランスポートに拡張することが望ましい場合には、別個のＷＣＲＧ（wireless CRG）モジュールを導入することができよう。そして、この新しいモジュールが、ＣＲＧモジュール５８として、同一のシステム内においてデータを処理することになろう。
【００４７】
一時点においては１つのサービスのみが有効であるものと仮定されているが、このサービスは、複数の同時トランスポートレイヤフローサマリ（Ｔフロー）から構成可能である。従って、ＣＲＧモジュール５８は、所与のＧＴＰフローサマリ（Ｇフロー）を有する同時Ｔフローの数を監視し、（後述するようにＣＡモジュールによって通知される）サービス起動の完了時に、ＳＵＲ全体を利用可能にする。ＣＡペイロードを有していないＴフローや、ＴＣＰではないプロトコル、或いは、６又は１７ではないＵＤＰの場合には、ＣＲＧモジュール５８は、タイマの満了に基づいて、或いは、ＣＡモジュール６０の中の１つによって指示された場合に、ＳＵＲレコードを出力する。
【００４８】
ＣＲＧモジュールの更なる機能は、トランスポートヘッダからＡＳＰ（Application Service Provider）ネットワークアドレス及び関連するポート番号を導出し、データサービスを識別するためにＳＤＩモジュールに提供するべく、これらを保存することである。
【００４９】
このＣＲＧモジュール５８による処理に続いて、メッセージは、ＣＡ（Content Analysis）モジュール６０の組に転送される。それぞれのモジュールは、アプリケーションレイヤ（図２のレイヤ３４）の特定のコンテンツの識別及び分析用に専用となっている。このアプリケーションコンテンツは、単一のプロトコルであるか、或いは、サービスの提供に使用されるプロトコルの組であってよい。
【００５０】
一般に、ＣＡモジュール６０は、実際のメッセージデータではなく、アプリケーションメッセージヘッダのコンテンツをチェックする。メッセージヘッダは、ＩＥＴＦのＲＦＣ（Request for Comments）８２２「Format of ARPA Internet Text Messages」に規定されている標準的なインターネットヘッダであるものと仮定されている。これらのＣＡモジュールは、例えば、ネットワーク内におけるサービスの使用量を反映した順番に従って処理チェーンに編成されている。それぞれのモジュール６０は、メッセージをチェックする際に、試験を行い、そのメッセージを処理するべきか、或いは次に渡すべきかを判定する。そして、この試験に不合格となった場合に、そのメッセージは、チェーン内の次のＣＡモジュール６０に伝達される。
【００５１】
適切なＣＡモジュール６０をアレンジして、ＨＴＴＰ及びＷＡＰプロトコルメッセージ内において観測されるＵＲＩ（Uniform Resource Identifier）を抽出し、この結果抽出されたＵＲＩを、データサービスの識別に使用するべくＳＤＩモジュールに提供する。
【００５２】
それ以前のＣＡモジュールによって認識されていないコンテンツを捕捉するべく、ＣＡモジュール処理チェーンの末尾に、ヌルＣＡモジュールと呼ばれる特殊なＣＡモジュール６０が配置されている。このヌルモジュールは、メッセージ間ギャップ分析、メッセージ交換署名、及びポート番号の分析により、セッション起動の開始及び終了時期を判定するべく試みる。その他のＣＡモジュールとは異なり、このモジュールは、一度に１つのトンネル内において１つのサービス起動のみが有効であるという事実に依存しており、これにより、分析を単純化している。
【００５３】
このヌルＣＡモジュールの主な利点は、暗号化されたトラフィックを処理する際にも正常に動作を継続できるという点である。このモジュールが実行する分析は、純粋にタイミングとトラフィック交換パターンに基づいており、実際の内容には基づいていない。
【００５４】
ＣＡモジュール６０の後には、必要なフォーマットでＳＵＲ（Service Usage Record）を生成し、指定された出力ストリーム（ファイル、ＦＩＦＯバッファ、又はソケット）に出力モジュール６４を介して書き込む出力フォーマッタ６２が配置されている。これらの出力フォーマッタは、例えば、ＸＭＬ（Extensible Markup Language）フォーマットＳＵＲ、バイナリフォーマットＶ３６構造、又はＣＳＶ（Comma-Separated Variable）ファイルを生成可能である。
【００５５】
ＳＵＲは、ヘッダと、これに続く３つの独立したセクション（Ｇフロー、Ｔフロー、及びサービスフローサマリ（Ｓフロー））から構成されている。それぞれのセクションは、その他のレイアを参照することなしに、スタックの異なるレイヤを使用して作成されるため、独立している。
【００５６】
ＳＵＲは、ＳＵＲフォーマットのバージョンを識別するショートヘッダセクションを有している。Ｇフローセクションは、スタックのアウターＩＰ、ＵＤＰ、及びＧＴＰレイヤ（図２のレイヤ４０〜４４）からＧＴＰモジュール５６によって導出された情報を格納し、後続の２つのセクションに「通信コンテキスト」を提供する。又、このセクションは、ＧＴＰトンネルに関するサマリ情報をも提供する。
【００５７】
Ｔフローセクションは、トンネリングされているＩＰ及びＴＣＰ／ＵＤＰレイヤ（図２の３６及び３８）からＣＲＧモジュール５８によって導出された計測値を格納している。
【００５８】
Ｓフローセクションは、専用のＣＡモジュール６０によって生成されたサービス又はプロトコル固有の計測値グループである。Ｓフローセクションは、サービス起動が成功したかどうかを「サービストランザクション」として通知する。尚、サービスプロバイダシステムとのやり取りが可能であった場合に、サービスは成功したと見なされる。
【００５９】
ＳＵＲ内のすべての情報をその独自の目的に使用し、サービス起動の成功又は失敗の報告を所望するかどうかを決定するのは、ＳＵＲの利用者に任されている。ＧＰＲＳ  ＱｏＳ計測エンジンなどのアプリケーションがＳＳ７のＴＣＡＰトランザクションと同一の方式でサービス起動を計数することを可能にするべく、起動状態コード値が存在している。セッション内において、それぞれの電子メールアイテムの転送の後に、ＩＰＤＲが出力される場合には、サービス状態コードをプロトコルから直接取得可能である。
【００６０】
特許文献１には、ＳＵＲの様々なセクションの可能なフォーマットに関する更なる詳細事項が記載されている。
【００６１】
データサービスを識別するために、サービス間を弁別する「サービスキー（service key）」は、次のように生成される。
【００６２】
サービスキー＝ＡＰＮ＋ＡＳＰネットワークアドレス＋ＡＳＰポート番号＋ＵＲＩ
このＡＰＮ（ＧＲＲＳ又はＵＭＴＳのＡＰＮ（Access Point Name））は、完全修飾（fully qualified）ドメイン名（例：phonecompany.co.uk）であって、ＧＰＲＳ及びＵＭＴＳネットワークの場合には、値が割り当てられ、それ以外の場合には、ＮＵＬＬである（例：後述するＣＤＭＡ２０００ネットワークを監視する場合）。このＡＰＮは、前述のように、無線ネットワークとＧＰＲＳコアネットワーク間のＧＰＲＳ「接続」をセットアップするＧＴＰシグナリングメッセージの分析からＧＴＰモジュール５６によって抽出される。そして、ＡＳＰネットワークアドレスとは、ＡＳＰホストネットワークアドレスであって、通常、ドット付き十進フォーマットのＩＰｖ４又はＩＰｖ６ネットワークアドレスである。ＡＳＰポート番号とは、サービスの提供に使用されるＡＳＰサーバーのポート番号であり、これは、単純な整数値である。尚、基本的に、「ＡＳＰネットワークアドレス」フィールドには、あらゆるネットワークアドレスタイプを表示可能であり、「ＡＳＰポート番号」フィールドには、あらゆる種類のサービスアクセスポイント識別子を使用可能であるが、実際に遭遇する可能性が最も高いネットワークプロトコルはＩＰであろう。ＵＲＩは、ＨＴＴＰ及びＷＡＰプロトコルを使用してデータサービスを提供する場合には、ＧＥＴ又はＰＯＳＴ操作要求により、関連するＣＡモジュール６０によって抽出することができる。
【００６３】
ＳＤＩモジュール内においては、設定ファイルを使用し、サービスキー定義をサービス名と関連付ける「サービスキー」マッピングを提供している。単純なマッチングプロセスを適用することにより、ＳＵＲのサービス名を見いだすことができる。ＳＵＲが生成されると、前述のように、プロトコルスタック内の異なるレベルにおいて稼働している状態機械が、観測されたトラフィックから「サービスキー」要素を抽出する。そして、モジュール６２がＳＵＲを出力する準備が整った際に、ＳＵＲ内の「サービス名」フィールドに書き込む手順が、ＳＤＩモジュールにおいて起動される。この時点では、その他のすべてのＳＵＲフィールド値が判明している。ＳＤＩモジュールは、設定ファイル内に一覧表示されている「サービスキー」定義を使用し、適切なサービス名を見いだす。尚、設定ファイル内においては、最初の一致をトリガとして使用しサービス名のサーチを終了できるよう、一般キーよりも前に詳細キーを定義するほうが便利である。
【００６４】
ＢＢＣウェブサイトの「サービス名」エントリの例が次に一覧表示されている（この場合には、「サービスキー」定義において、区切り文字として「！」文字を、単語ワイルドカードとして「＊」文字を使用する表記法が採用されている）。
【００６５】
web-apn.mcc.mnc.gprs!212.58.240.111!*!www.bbc.co.uk/radio4    “BBC Radio4”
web-apn.mcc.mnc.gprs!212.58.240.111!*!www.bbc.co.uk/radio    “BBC Radio”
web-apn.mcc.mnc.gprs!212.58.240.111!*!www.bbc.co.uk/news    “BBC News”
web-apn.mcc.mnc.gprs!212.58.240.111!*!*    “BBC UK”
更なる例は、キャリア間ＭＭＳトラフィックを供給するべくＭＭＳＣが使用するＳＭＴＰに関係するものである。この例においては、モバイル装置とサーバーではなく、ネットワーク内の２つのサーバー間におけるサービスのケースであって、ネットワークアドレス１０．２２４．５４．２０〜２２が、キャリア間トラフィックを処理するＭＭＳＣリレーインターフェイスである。
【００６６】
*!10．224．54．20!25!*    “Inter-carrier  MMS”
*!10．224．54．21!25!*    “Inter-carrier  MMS”
*!10．224．54．22!25!*    “Inter-carrier  MMS”
*!*!25!*                          “E-mail”
以上において説明した特定の実装例は、ＧＰＲＳシステムの監視に関するものであり、このサービスの識別は、同様に、その他の種類のネットワークを監視する際にも提供可能である。例えば、ＣＤＭＡ２０００ネットワークの場合には、ＧＰＲＳのＧＧＳＮに類似したホームエージェントとＧＲＰＳのＳＧＳＮに類似したＰＤＳＮ（Packet Data Serving Node）間で交換されるパケットを監視することにより、提供することができる。
【図面の簡単な説明】
【００６７】
【図１】ＧＰＲＳサービスを提供するための機器を含むＧＳＭモバイル通信ネットワークの概略ブロック図である。
【図２】ＳＧＳＮをＧＧＳＮに接続するＧＰＲＳのＧｎインターフェイス上で使用されるプロトコルスタックを示している。
【図３】提供されているデータサービスの識別を含むＳＵＲを生成するシステム内の主要機能ブロックの概略図である。
【符号の説明】
【００６８】
４８  リンク監視カード（モニタ）
５６  ＧＴＰモジュール（第１導出器）
５８  ＣＲＧモジュール（第２導出器）
６０  ＣＡモジュール（第３導出器）
６２  ＳＵＲ生成モジュール（コンカテネータ）
【図１】
2005184810.tif 000003
【図２】
2005184810.tif 000004
【図３】
2005184810.tif 000005