JP2005521337A

JP2005521337A - アプリケーション・プログラム・インタフェース

Info

Publication number: JP2005521337A
Application number: JP2003579453A
Authority: JP
Inventors: イー．ハミルトン、トーマス; エス．アットウッド、クリフォード
Original assignee: Proquent Systems Corp
Current assignee: Proquent Systems Corp
Priority date: 2002-03-18
Filing date: 2003-03-18
Publication date: 2005-07-14
Also published as: US20030177283A1; WO2003081885A9; WO2003081885A1; KR20040108673A; CN1653790A; AU2003225863A1; EP1491029A1; EP1491029A4

Abstract

ネットワークで使用する方法に関する。この方法は、アプリケーション・プログラム・インタフェース（ＡＰＩ，２８）内のアプリケーション・プログラムからのメッセージを受信するステップと、モバイル・サービス・スイッチング・プラットフォーム（ＭＳＳＰ，２２）内でＡＰＩから制御プロセス（２６）へのメッセージを送信するステップとを備える。システムは、モバイル・サービス・スイッチング・プラットフォーム（ＭＳＳＰ）内の制御プロセスにリンクしているゲートウェイ汎用パケット無線サービス・サポート・ノード（ＧＧＳＮ，２０）と、制御プロセスにリンクしているグローバルに接続しているコンピュータのグループと、制御プロセスに接続しているアプリケーション・プログラム・インタフェース（ＡＰＩ）と、ＡＰＩにリンクしているアプリケーション・プロセスを実行するアプリケーション・システム（３０）とを備える。

Description

本発明は、アプリケーション・プログラム・インタフェース（ＡＰＩ）に関する。

アプリケーション・プログラム・インタフェース（ＡＰＩ）は一般に、コンピュータ・オペレーティング・システム又はアプリケーション・プログラムによって規定された特定の方法であり、これによって、あるアプリケーション・プログラムを書くプログラマはオペレーティング・システム又は他のアプリケーションに要求を行うことができる。より詳細には、ＡＰＩとは、アプリケーション・プログラムがサポーティング・サービスにアクセスするために参照可能な、ソフトウェア呼出し及びルーチンを一組にフォーマライズしたものである。

ほぼ全てのコンピュータ・プラットフォーム上で使用可能な簡単なＴＣＰ／ＩＰネットワーク・サービスを使用するモバイル・サービス・スイッチング・プラットフォーム（ＭＳＳＰ）とメッセージを交換するためのアプリケーション層プロトコルを提供する。

本発明は一態様において、ネットワーク内でアプリケーション・プログラム・インタフェース（ＡＰＩ）にてアプリケーション・プログラムからのメッセージを受信するステップと、ＡＰＩからモバイル・サービス・スイッチング・プラットフォーム（ＭＳＳＰ）内の制御プロセスへ上記メッセージを送信するステップとを有する方法を特徴とする。

本発明の実施形態は、下記要件のうちの１つ以上を有していてもよい。ネットワークは無線ネットワークであってもよい。無線ネットワークは、第二世代無線ネットワーク、ＧＳＭネットワーク、ＧＰＲＳ使用可能ＧＳＭネットワーク、又はＴＤＭＡネットワークであってもよい。無線ネットワークは、ＣＤＭＡネットワーク、ＵＭＴＳネットワーク、ＴＥＴＲＡネットワーク、又はＴｅｔｒａｐｏｌネットワークであってもよい。無線ネットワークは、ＤＥＣＴネットワーク、ＡＭＰＳネットワーク、ＷＬＡＮ又は第三世代無線ネットワークであってもよい。

ＡＰＩは、アプリケーション・プログラムがＭＳＳＰ内で切替及び経路指定機能を制御可能とするためのプロトコルを提供し得る。
ＡＰＩは、アプリケーション・プログラムが流れをベースとしてＭＳＳＰを通るパケットの流れの向きを変えることを可能とさせるプロトコルを提供することができる。

ＡＰＩは、アプリケーション・プログラムがＭＳＳＰ内でのポリシー決定を制御することを可能とさせるプロトコルを提供することができる。
ＡＰＩは、アプリケーション・プログラムが制御プロセス中に、初期検出点（ＩＤＰ）及びサービス関連ＩＤＰイベントを着装することを可能とさせるプロトコルを備えていてもよい。

ＡＰＩは、アプリケーション・プログラムが、制御プロセス中に、ＩＤＰ及びサービスに関連するＩＣＰイベントを脱着装することを可能とさせるプロトコルを備えていてもよい。

ＡＰＩは、アプリケーション・プログラムが、イベント報告を要求することを可能とさせるプロトコルを備えていてもよい。
ＡＰＩは、アプリケーション・プログラムが、制御プロセス中に、検出点のところでプログラムされた行動を指定することを可能とさせるプロトコルを備えていてもよい。

ＡＰＩは、アプリケーション・プログラムが、ＭＳＳＰの制御プロセスにより測定するデータ要素を構成することを可能とさせるプロトコルを備えていてもよい。
ＡＰＩは、アプリケーション・プログラムが、バイトをベースとする報告を要求することを可能とさせるプロトコルを備えていてもよい。上記報告は、セッションをベースとするものであっても、又は流れをベースとするものであってもよい。

ＡＰＩは、アプリケーション・プログラムが、提供されるサービスのコストを指定することを可能とさせるプロトコルを備えていてもよい。
ＡＰＩは、アプリケーション・プログラムが、明細レコード内で使用する課金計画を記録することを可能とさせるプロトコル、及びアプリケーション・プログラムが、明細レコードが作成される時間を制御することを可能とさせるプロトコルを備えていてもよい。

ＡＰＩは、アプリケーション・プログラムが、アプリケーション・プログラムが管理するセッションの統計を入手することを可能とさせるプロトコルを備えていてもよい。
ＡＰＩは、アプリケーション・プログラムが、アプリケーション・プログラムが管理する流れの統計を入手することを可能とさせるプロトコルを備えていてもよい。

ＡＰＩは、アプリケーション・プログラムが、ＭＳＳＰの制御プロセスに接続している他のアプリケーションの状態を監視することを可能とさせるプロトコルを備えていてもよい。

他の態様においては、本発明は、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）ネットワーク・サービスを使用するモバイル・サービス・スイッチング・プラットフォーム（ＭＳＳＰ）のアプリケーション・プロセスと制御プロセスとの間でメッセージの交換ができるようにする一組のアプリケーション層プロトコルを含むアプリケーション・プログラム・インタフェース（ＡＰＩ）を特徴とする。

ある実施形態の場合には、上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、制御プロセス中に、初期検出点（ＩＤＰ）及びサービス関連ＩＤＰイベントを着装することを可能とさせるプロトコルを備えていてもよい。

上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、制御プロセス中に、初期検出点（ＩＤＰ）及びサービス関連ＩＤＰイベントを脱着装することを可能とさせるプロトコルを備えていてもよい。

上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、制御プロセスからイベント報告を要求することを可能とさせるプロトコルを備えていてもよい。
上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、制御プロセス中に、検出点のところでプログラムされた行動を指定することを可能とさせるプロトコルを備えていてもよい。

上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、制御プロセスにより測定するデータ要素を構成することを可能とさせるプロトコルを備えていてもよい。

上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、制御プロセス中に、バイトをベースとする報告を要求することを可能とさせるプロトコルを備えていてもよい。上記報告は、セッションをベースとする報告、又は流れをベースとする報告を備えていてもよい。

上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、ＭＳＳＰが提供するサービスのコストを指定することを可能とさせるプロトコルを備えていてもよい。

上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、ＭＳＳＰ内に記憶している明細レコード内で使用する課金計画を記録することを可能とさせるプロトコルを備えていてもよい。

上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、明細レコードが作成される時間を制御することを可能とさせるプロトコルを備えていてもよい。
上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、アプリケーション・プロセスが管理するセッションの統計を入手することを可能とさせるプロトコルを備えていてもよい。

上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、アプリケーション・プロセスが管理する流れの統計を入手することを可能とさせるプロトコルを備えていてもよい。

上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、制御プロセスに接続している他のアプリケーション・プロセスの状態を監視することを可能とさせるプロトコルを備えていてもよい。

もう１つの態様においては、本発明は、モバイル・サービス・スイッチング・プラットフォーム（ＭＳＳＰ）内で制御プロセスにリンクしているゲートウェイ汎用パケット無線サービス・サポート・ノード（ＧＧＳＮ）と、制御プロセスにリンクしているグローバルに接続しているコンピュータのグループと、制御プロセスに接続しているアプリケーション・プログラム・インタフェース（ＡＰＩ）と、ＡＰＩにリンクしているアプリケーション・プロセスを実行するアプリケーション・システムとを含むシステムを特徴とする。

ある実施形態の場合には、上記システムは、ＧＧＳＮにリンクしている汎用パケット無線サービス・サポート・ノードを備えていてもよい。上記システムは、汎用パケット無線サービス・サポート・ノードにリンクしている基地局コントローラ（ＢＳＣ）を備えていてもよい。上記システムは、ＢＳＣにリンクしている基地トランシーバ局（ＢＴＳ）、及びＢＴＳにリンクしている移動局（ＭＳ）を備えていてもよい。

ＡＰＩは、アプリケーション・プロセスと制御プロセスとの間でメッセージの交換ができるようにする一組のアプリケーション層プロトコルを備えていてもよい。
上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、制御プロセス中に、初期検出点（ＩＤＰ）及びサービス関連ＩＤＰイベントを着装することを可能とさせるプロトコルを備えていてもよい。

上記一組のアプリケーション層プロトコルは、アプリケーション・プロセスが、制御プロセス中に、バイトをベースとする報告を要求することを可能とさせるプロトコルを備えていてもよい。上記報告は、セッションをベースとするものであっても、又は流れをベースとするものであってもよい。

本発明の実施形態は、下記の利点の中の１つ又はそれ以上を有することができる。
ＡＰＩは、ほぼ全てのコンピュータ・プラットフォーム上で使用可能な簡単なＴＣＰ／ＩＰネットワーク・サービスを使用するモバイル・サービス・スイッチング・プラットフォーム（ＭＳＳＰ）とメッセージを交換するためのアプリケーション層プロトコルを提供する。

ＡＰＩは、外部アプリケーション・プログラムが内蔵するサービス・ロジックが、モバイル・サービス・スイッチング・プラットフォームの切替／経路指定機能を制御することを可能とさせる一組のプロトコルを提供する。

ＡＰＩは、ある検出点がアプリケーション・イベント報告及び／又は制御が可能な制御エンティティの状態機械内の定義された場所であるアプリケーションの検出点の範囲を制限するためのオペレータ用のプロトコルを提供する。

ＡＰＩは、アプリケーションの特権が何であろうと、全てのアプリケーションに共通するプロトコルを提供する。
ＡＰＩは、アプリケーションが、モバイル・サービス・スイッチング・プラットフォーム（ＭＳＳＰ）内の初期検出点（ＩＤＰ）及びサービス関連ＩＤＰイベントを着装及び脱着装することを可能とさせるプロトコルを提供する。ＩＤＰは、条件が所与の基準と一致した場合、アプリケーションとの新しい制御ダイアログを生成するために着装された検出点として定義される。

ＡＰＩは、アプリケーションが、初期検出点イベントの後で追加のイベント報告を要求することを可能とさせるプロトコルを提供する。制御ダイアログをスタートするＩＤＰがトリガである場合には、アプリケーションは、通常、追加のイベント報告を要求する。

ＡＰＩは、アプリケーションが、アプリケーションの介入を必要としない検出点（ＤＰ）のところで、プログラムされた行動を指定することを可能とさせるプロトコルを提供する。メッセージは、所定のサービスの相互作用を実行すべきかどうかを決定するために、入力要求を突き合わせるために使用される。突き合わせプロセスは、通常、初期検出点のために使用するプロセスに類似していて、突き合わせるフィールド内でワイルドカードを使用することができる。流れが基準に一致した場合には、メッセージの残りの部分内に指定されている行動が、アプリケーションの介入なしで実行される。指定することができる行動には、イベントの報告及び指定の転送先アドレス及びポート番号への要求の転送が含まれる。イベント報告が必要な場合には、流れに対して将来どのイベントを報告するのかを決定するためにメッセージが使用される。一致のための基準は、着装した初期検出点基準と重なってはならない。何らかの理由で要求を完了することができない場合には、突き合わせ要求ＩＤ及び失敗の性質を示すエラー・コードと一緒にメッセージが返送される。要求の完了に成功した場合には、他のメッセージが返送される。特定のメッセージ要求により取り消されるまでは、サービス・フィルタリングが引き続き行われる。

ＡＰＩは、ＭＳＳＰによって測定されたデータ要素をアプリケーションが構成することを可能とするプロトコルを提供する。
ＡＰＩは、アプリケーションが、バイトをベースとする報告を要求することを可能とさせるプロトコルを提供する。報告はセッションをベースとして要求することもできるし、又は流れをベースとして要求することもできる。セッションをベースとする課金通知は、効果的に同じ課金通知基準をセッション内の全ての流れに適用する。課金通知イベントを登録すると、アップリンク及びダウンリンク方向に転送される指定のタイプのバイト数を測定することができる。報告のしきい値に達する度に、すでに転送したバイト数を示すメッセージが、ＭＳＳＰからアプリケーションに送信され、カウンタがリセットされ、再びしきい値に向けてカウントがスタートする。課金通知は、流れが終了するまで継続して行われるか、又は課金通知は、取消し要求により明示的に取り消される。パケットはカウントされる最小単位であり、各パケットはカウントが評価される前か、又はカウントが評価された後かのいずれかで脱落する。その結果、課金通知は指定のバイト・カウント上で正確に行われない場合がある。例えば、１０Ｋバイト毎に通知が要求された場合には、１０Ｋを超えるカウントを運んだパケットが、５００バイトより若干大きい場合には、通知が１０．５Ｋバイトのところで行われる場合がある。実際のカウント値は、メッセージ内で提供される。

ＡＰＩは、アプリケーションが、提供されたサービスのコストを表示し、ＭＳＳＰ明細レコードで使用する課金計画を記録することを可能とさせるプロトコルを提供する。
ＡＰＩは、アプリケーションが、ＭＳＳＰ明細レコードが作成される時間を制御することを可能とさせるプロトコルを提供する。

ＡＰＩは、アプリケーションが、アプリケーションが管理するセッション又は流れの種々の統計を入手することを可能とさせるプロトコルを提供する。
ＡＰＩは、アプリケーションが、同じＭＳＳＰ例に接続している他のアプリケーションの状態を監視することを可能とさせるプロトコルを提供する。

ＡＰＩは、流れをベースとしてパケットの流れの転送ができるようにするプロトコルを提供する。
説明を読み、図面を参照し、特許請求の範囲を読めば、本発明の他の特徴、目的及び利点を理解することができるだろう。

図１を参照すると、この図はネットワーク１０を示す。ネットワーク１０としては、例えば、無線ネットワークを使用することができる。無線ネットワークとしては、例えば、第二世代無線ネットワーク、広域自動車通信システム（ＧＳＭ）ネットワーク、又は汎用パケット無線システム（ＧＰＲＳ）使用可能ＧＳＭを使用することができる。無線ネットワークとしては、時分割多元接続（ＴＤＭＡ）ネットワーク、符号分割多元接続（ＣＤＭＡ）ネットワーク、又は汎用移動体通信システム（ＵＭＴＳ）ネットワークを使用することができる。無線ネットワークとしては、ＴＥＴＲＡネットワーク、Ｔｅｔｒａｐｏｌネットワーク、ＤＥＣＴネットワーク、ＡＭＰＳネットワーク、無線ローカル・エリア・ネットワーク（ＷＬＡＮ）、又は第三世代無線ネットワークを使用することができる。例として、ＧＰＲＳ使用可能ＧＳＭネットワークについて説明する。

ネットワーク１０は、基地トランシーバ局（ＢＴＳ）１４に接続している移動局（ＭＳ）１２を含む。ＢＴＳ１４は、基地局コントローラ（ＢＳＣ）１６に接続している。移動体通信の場合には、ＭＳ１２は、移動中又は指定されていない地点に停止中に使用するためのモバイル・サービス内に位置する局である。移動局の一例としては、ハンドヘルド・セルラーホンがある。

ＢＴＳ１４は、ＭＳ１２に関連するセル及び座標無線リンク・プロトコルを定義する無線トランシーバを含む。ＢＴＳ１４は、全ての信号が送受信されるネットワーク１０の１つの構成要素である。多くの場合、セルラーホン・タワーと呼ばれるＢＴＳ１４は、基地局コントローラ（ＢＳＣ）１６にリンクしていて、このコントローラにより制御される。ＢＳＣ１６は、例えば、ＢＴＳ１４のような１つ又はそれ以上の基地トランシーバ局用の無線リソースを管理するネットワーク１０内の構成要素である。

ＢＳＣ１６は、ＳＧＳＮ１８にリンクしている。ＳＧＳＮ１８は、ＢＳＣ１６を通してパケットを送受信することにより、ＧＰＲＳモバイルにサービスを提供する汎用パケット無線サービス・サポート（ＧＰＲＳ）ノードである。ＳＧＳＮ１８は、ゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）２０にリンクしている。ＧＧＳＮ２０は、汎用パケット無線サービス（ＧＰＲＳ）ネットワークとパケット交換公衆データ網（ＰＳＰＤＮ）との間でゲートウェイとしての働きをする。

ＧＧＳＮ２０は、モバイル・サービス・スイッチング・プラットフォーム（ＭＳＳＰ）サーバ２２にリンクしている。ＭＳＳＰサーバ２２は、ＧＧＳＮ２０とインターネット２４のようなコンピュータのグローバル・ネットワーク・グループとの間に常駐する。ＭＳＳＰサーバ２２は、ＭＳ１２とインターネット２４との間で交換される全てのインターネット・プロトコル（ＩＰ）データ・パケットを分析する。ＭＳＳＰ制御プロセス２６は、トリガ又はイベント通知を設定し、ＩＰ流れの特性に基づいてカウンタを増分する機能を提供する。ＩＰの流れは、ＭＳ１２とインターネット２４上に常駐するサーバ（図示せず
）のような２つの終点間のデータの動きを示す抽象概念であると見なすことができる。ＭＳＳＰ制御プロセス２６は、内部サービス及び明細報告書の作成を実施するためにこれらの機能を使用する。アプリケーション・プログラム・インタフェース（ＡＰＩ）２８は、外部アプリケーション３０にＭＳＳＰ制御プロセス２６をリンクする。ＡＰＩ２８は、インテリジェント・サービスを提供する目的で、ＭＳＳＰ制御プロセス２６を制御するために外部アプリケーション３０に対してある機構を提供する。種々の実施形態の場合には、ＡＰＩ２８は、例えば、ＣｏｒｂａをベースとするＡＰＩ、ＸＭＬをベースとするＡＰＩ、ＰＡＲＬＡＹサーバ、ＯＳＡサーバ、又はＪＡＩＮサーバとして実施することができる。

要するに、ＭＳＳＰサーバ２２は、インターネット・ルータ及びＩＰパケット分析装置の両方として機能する。ＩＰパケットのヘッダ・フィールドが内蔵するデータは、参照により本明細書に組み込むものとするインターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）ＲＦＣ７９１内に定義されている（ｗｗｗ．ｉｅｔｆ．ｏｒｇ参照）。ＩＥＴＦは、ネットワーク設計者、オペレータ、販売業者及びインターネット・アーキテクチャ及びインターネットのスムーズな運用の進化に関連する研究者の大規模な開かれた国際コミュニティである。

インターネット・プロトコル（ＩＰ）は、パケット交換コンピュータ通信ネットワークの相互接続システムで使用するために設計されている。ＩＰは、ソースから宛先へのデータグラムと呼ばれるデータのブロックを送信するためのものである。ソース及び宛先は、固定長アドレスにより識別されるホストである。ＩＰは、また、長いデータグラムの断片化及び再組立てを行うためのもので、必要な場合には、「小さいパケット」（ｓｍａｌｌ
ｐａｃｋｅｔ）ネットワークを通して送信を行う。

ＭＳＳＰ制御プロセス２６は、パケットの特徴が指定の条件に一致した場合に、カウンタ及び信号を管理するために、リアルタイムでＩＰパケット・ヘッダを分析するように設計されている。信号は、イベント報告であってもよいし、又はトリガであってもよい。イベント報告は、パケットの流れを継続的に監視しながらあるイベントの発生を報告する。トリガは、ＭＳＳＰ制御プロセス２６が、ＩＰパケットの処理を再開するための特定の命令で応答するまでＩＰパケットの処理を中断する。トリガ・レスポンスは、単にＩＰパケットの処理をそのまま継続するように命令することもできるし、又はパケットに対して異なる宛先を指定することにより、パケット処理を変更することもできるし、パケット全体を破棄することもできる。ＡＰＩ２８は、ある例の場合には、ＭＳＳＰ制御プロセス２６と通信し、イベント報告及びトリガを操作するために、他のアプリケーション３０に対する方法を提供する。

ＭＳＳＰ制御プロセス２６は、多くの異なるタイプのＩＰパケットを管理する。ある例の場合には、ＭＳＳＰ制御プロセス２６は、異なる状態機械（図示せず）に分割されるが、各状態機械は、異なるタイプのパケットを担当する。一般的に、状態機械は、所与の時点で何かの状態を記憶し、状態を変えるために及び／又は任意の所与の変化に対してある行動又は出力を行わせるために入力上で動作することができる任意のデバイスである。実際には、状態機械は、特定のデバイス又はプログラム相互作用を開発し、及び記述するために使用される。

ＭＳＳＰ制御プロセス２６の各状態機械には、戦略的位置が存在し、ここで重要な情報を入手することができ、重要な決定が行われる。これらの位置は、検出点と呼ばれる。検出点（ＤＰ）は、アプリケーション・イベント報告及び／又は制御を行うことができ、ＡＰＩ２８を通して管理することができる制御エンティティの状態機械内の定義された位置である。

イベント検出点（ＥＤＰ）は、既存の制御ダイアログのコンテキスト内に着装された検出点である。イベント検出点は、明示の基準を有さない。イベント検出点は、制御ダイアログを発生した制御エンティティの特定の状態機械例にだけ適用することができる。一般的に、ある制御ダイアログ内に設定されたイベント検出点は、その状態機械の任意の他の例の行動に影響を与えない。所与の状態機械内の検出点の完全な一組は検出点クラスと呼ばれる。

最も一般的に使用されるインターネット・プロトコルの一例としては、ＩＥＴＦＲＦＣ７９３内に定義されている伝送制御プロトコル（ＴＣＰ）がある。一例として、ＴＣＰ検出点クラスを使用する検出点について説明する。しかし、他のプロトコルも使用することができることを理解されたい。

ＴＣＰは、２つのアプリケーション・プロセス（通常、クライアントとサーバと呼ばれる）間に信頼性の高い接続指向の通信路を提供する。クライアントが接続をスタートし、サーバがその接続を受け入れた後で始めて任意のデータを交換することができる。ＴＣＰプロトコルは、送信された全てのデータが他方の側で、送信された順序で正しく受信することが確実にできるようにする。

サーバへのＴＣＰ接続をスタートするために、クライアントは、設定された「ＳＹＮ」フラグと一緒にＴＣＰヘッダを含み、自身が接続したいサーバ・アプリケーションのポート番号を指定しているサーバのＩＰアドレスにＩＰパケットを送信する。サーバは、クライアントに類似のＳＹＮパケットを返送することにより接続を受け入れ、クライアントは、設定された「ＡＣＫ」フラグと一緒にＴＣＰヘッダを含むＩＰパケットを送信することにより、サーバからのＳＹＮに肯定応答を行う。

パケットは、例えば、ＭＳ１２のようなクライアントと、インターネット２４上に常駐するサーバ（図示せず）との間の途中のＭＳＳＰサーバ２２内のＭＳＳＰ制御プロセス２６を通過する。パケットのＩＰヘッダをチェックすることにより、ＭＳＳＰ制御プロセス２６は、ＩＰパケットがＴＣＰデータを内蔵していると判断し、ＴＣＰ制御ロジックにパケットを割り当てる。ＩＰヘッダ内のデータと一緒にＴＣＰヘッダ内のデータをチェックすることにより、ＴＣＰ制御ロジックは、接続確立の各セグメントを区別することができる。

例えば、サービス・アプリケーション３０の中の１つが、インターネット２４上の特定のサーバへのＴＣＰ接続を「傍受」し、おそらく現在のサーバ・ロード状態のサービス・アプリケーションの知識に基づいて、インターネット２４上の異なるサーバへ上記接続を転送したい場合を考えてみよう。サービス・アプリケーション３０は、傍受するサーバに一致する宛先を有するＴＣＰＳＹＮパケットを監視するトリガを発生するように、ＡＰＩ２８を通してＭＳＳＰ制御プロセス２６に命令することができる。これは初期検出点（ＩＤＰ）と呼ばれる。ＩＤＰは、条件が所与の基準に一致した場合に、アプリケーションにより新しい制御ダイアログを生成するように着装された検出点である。

全ての他のＴＣＰパケット及び異なる宛先に向けられたＴＣＰＳＹＮパケットは、通常通り継続的に処理される。しかし、着装基準と一致する宛先を有するＴＣＰＳＹＮパケットは、そのパケットの処理を中断し、ＩＤＰイベント通知を、ＡＰＩ２８を通してＩＤＰを着装しているサービス・アプリケーション３０に送信する。

ＩＤＰイベント通知は、例えば、サービス・アプリケーション３０が、接続に対する正しい宛先を決定するために使用できる中断したパケットからの情報を備えていてもよい。
次に、サービス・アプリケーション３０は、ＡＰＩ２８を通してＭＳＳＰ制御プロセス２６に、異なる宛先アドレスでパケット処理を再開するように命令する。ＭＳＳＰ制御プロセス２６は、新しい宛先に修正したＴＣＰＳＹＮパケットを転送する。この場合、サーバは通常の方法で応答する。サービス・アプリケーションの介入は完全にトランスペアレントである。すなわち、例えば、ＭＳ１２のようなクライアントも、インターネット２４上のサーバ（図示せず）も方向が変わったことに全然気がつかない。

サービス・アプリケーション３０は、ＴＣＰ／ＩＰメッセージを交換することにより、ＭＳＳＰ制御プロセス２６と相互作用を行う。ＡＰＩ２８は、サービス・アプリケーション３０からの接続を聞く。アプリケーション接続が行われた場合、ＡＰＩ２８は、接続したサービス・アプリケーション３０の識別を認証し、アプリケーションがアクセスするために許可された特徴を参照する。

サービス・アプリケーション３０は、ＡＰＩ２８とのその通信セッションが確立した場合、ＭＳＳＰ制御プロセス２６から提供されると期待しているサービスのリストを要求し、次にこれらのサービスを実施するために必要な初期検出点を着装する。その後で、サービス・アプリケーション３０は、着装基準に一致するパケットを有する場合に、信号を送るためにＭＳＳＰ制御プロセス２６に対して待機する。

ＭＳＳＰ制御プロセス２６がＩＤＰイベントを送信した場合、サービス・アプリケーション３０は、ＡＰＩ２８を通してそのサービス・ロジック（図示せず）を適用する。このサービス・ロジックは、さらに選択した宛先にパケットを送るために、検出点に達したパケットの流れに対する追加の測定を構成し、この流れから追加のイベント報告を要求し、この流れに適用できる課金計画を表示し、周期的課金通知イベントを要求するか、又は流れの統計を要求する。

ある例の場合には、ＡＰＩ２８の作動サービス・フィルタリング要求メッセージを使用して、ＭＳＳＰ制御プロセス２６とアプリケーション３０のサービス・ロジックとの間のサービス相互作用のデフォルト行動を、トリガ検出点を実施しなくても指定することができる。ソース・アドレス、ソース・ポート、パケットのデータ部分及びプロトコル・ポート内の宛先アドレス・ストリングが、所定のサービス相互作用を実行すべきかどうかを決定する目的で、入力要求を突き合わせるために使用される。流れが基準に一致した場合には、メッセージの残りの部分に指定されている行動が実行される。指定することができる行動の例としては、イベントの報告及び指定した転送先アドレス及びポート番号への要求の転送等がある。

他の例の場合には、サービス・ロジックは、ＩＤＰが検出された場合に実行をスタートする。サービス・ロジックは、検出点に達したイベント通知を受信する。検出点が要求検出点として登録されている場合には、サービス・ロジックは、ＭＳＳＰ要求命令がまだ時間切れになっていない応答を行う。応答は、パケットを修正し、次にそれを転送し、流れ又はセッションを解放し、又は接続要求を使用してパケットを転送又は接続することができる。流れ又はセッションに適用されるプログラム・ポリシー・フィルタに、他の要求を行うこともできる。そうしたい場合には、サービス・ロジックは、検出点に達した場合にサービス相互作用を実行するように指定するために、サービス・フィルタ要求を使用することができる。

例えば、ＡＰＩ２８は、ＭＳＳＰ制御プロセス２６に、トリガ点で中断している流れ上の指定した宛先アドレスへの接続を確立するように命令する接続要求メッセージを提供する。宛先アドレスは、トリガ条件に一致したパケット内の宛先アドレスと異なるものであってもよい。その場合、サービス・アプリケーション３０内のサービス・ロジックは、例
えば、接続を、使用できる最善のリソースに経路指定することができる。

ＡＰＩ２８は、ＭＳＳＰ制御プロセス２６に能動流れを終了するように命令する解放流れメッセージを供給する。ＭＳＳＰ制御プロセス２６は、流れを終了し、終了を確認した後で任意のイベント又は測定メッセージを供給することができる。

それ故、ＡＰＩ２８を使用して、サービス・アプリケーション３０は、提供したパケット交換データ・サービスを管理し、制御する。上記パケット交換データ・サービスは、パケット交換データ・サービスを識別する任意の及び全ての一意のネットワーク・アドレス、ユーザをパケット交換データ・サービス・プロバイダに向ける方法及びどのパケット交換データ・サービス・プロバイダ（例えば、インターネット２４上の特定のサーバ）に向けるのかを決定するポリシー決定、セッションに対してどのスポンサに何に基づいて課金するのかを決定するポリシー決定を含む。ポリシー・フィルタは、ポート、プロトコル、ＩＰアドレス、クッキー、又は他の層の７つのプロトコル特徴に基づいて、いずれかの方向でＩＰトラヒックを阻止するために使用することができる。ポリシー・フィルタは、また、サービス・ロジックが、ウォールガーデン又は加入をベースとするモデルを生成及び管理することを可能とさせる。ポリシー・フィルタの性質は動的で、新しいサービスを動的に購入し、サービス・ロジックにより更新することができる。

選択及び課金のためのポリシー決定は、サービス・プロバイダ及びスポンサに対する支払い方法及び基準の選択に関して、オペレータと第三者、スポンサ又はサービス・プロバイダの間の事前の合意を盛り込んだ規則を備えていてもよい。どのサービス・プロバイダに接続するのかのポリシー決定は、ユーザ識別、ユーザの位置、時刻、ユーザ・クラス、サービス・プロバイダ・クラス、ネットワーク条件、事前合意規則及び／又は政府の規制のような要因に基づくサービス要求の時点で行うことができる。例えば、どのスポンサに課金するのかまたどんな基準によるのかのポリシー決定は、ユーザ識別、ユーザの位置、時刻、ユーザ・クラス、サービス・プロバイダ・クラス、ネットワーク条件、事前合意規則及び／又は政府の規制のような類似の要因に基づくサービス要求の時点で行うことができる。

サービス相互作用は、始め、中間及び終わりを有するサービス・ロジックにより定義される。サービス相互作用の始めは、通常、検出点に達した場合に、サービス・ロジックに送信されたＩＤＰ（初期検出点）イベントにより識別される。サービス相互作用は、サービス・ロジックが登録したイベントがもはや存在しないか、又はサービス・ロジックが明示的にダイアログを終了した場合に終了する。サービス相互作用は、イベントのシーケンス、及びＩＤＰと端末イベントとの間のサービス・ロジックにより受信し、行われたＡＰＩ呼出しにより囲まれている。サービス相互作用は、通常、サービス・ロジックに相互作用が終了した後でＣＤＲに書込みを行わせる課金対象イベントである。サービス相互作用の限界の詳細は、サービス・ロジックが決定する。例えば、株式相場サービスは、要求に一致しているＩＤＰが報告された場合にスタートし、相場を含む応答を入手した場合に終了する。この同じ例を、例えば、ファイル・ダウンロード及び電子メールの配信を含むように拡張することができる。ＭＳＳＰは、相互作用を検出し、制御するための手段を提供し、サービス・ロジックは、サービスを実施するためのＡＰＩ呼出し及びイベント処理を担当する。

ＴＣＰを例として使用しながら図２を参照すると、傍受プロセス５０は、サービス・アプリケーション始動段階５２、サービス初期化段階５４、サービス展開段階５６、サービス・ロジック段階５８及びシャットダウン段階６０を含む。

図３を参照すると、サービス・アプリケーション始動段階５２は、トランスポート層の
初期化（７０）を含む。トランスポート層は、ＴＣＰ／ＩＰソケットを生成し、このソケットをＡＰＩ２８を通して接続することにより初期化される（７０）。段階５２は、セッション層を初期化する（７２）。初期化（７２）は、ＭＳＳＰサーバ２２へのセッション・オープン要求の送信を含む。ＭＳＳＰサーバ２２は、アプリケーションの信用証明書を認証する。セッション・オープン確認は、ＭＳＳＰサーバ２２から受信される。段階５２は、アプリケーション層を初期化する（７４）。この初期化（７４）は交渉ＡＰＩバージョン要求の送信、及び交渉ＡＰＩバージョン確認の受信を含む。オープン要求が送信され確認される。

図４を参照すると、サービス初期化段階５４は、サービス・リスト入手要求の送信（８０）を含み、ＭＳＳＰサーバ２２は、このアプリケーションのためのサービスを参照する。段階５４は、サービス・リスト入手確認を受信し（８２）、サービス詳細入手要求を送信し（８４）、ＭＳＳＰサーバ２２はそのサービスに対する構成データを参照する。段階５４は、サービス詳細入手要求確認を受信する（８６）。

図５を参照すると、サービス展開段階５６は、ＩＤＰ着装要求の送信（９０）、ＩＤＰ着装確認の受信（９２）を含む。ＭＳＳＰサーバ２２は、着装基準がアプリケーション及びサービス用に構成された任意の制限に適合していることを確認し、ＩＣＰ基準をＭＳＳＰサーバ２２内にプログラムする。

図６を参照すると、サービス・ロジック段階５８は、初期ＤＰイベントの受信（１００）を含む。段階５８は、加入者接続に対する新しい宛先を決定し（１０２）、新しい宛先に接続要求を送信する（１０４）。段階５８は、接続確認を受信する（１０６）。

図７を参照すると、シャットダウン段階６０は、ＩＤＰ脱着装要求の送信（１１０）及びＩＤＰ脱着装確認の受信（１１２）を含む。段階６０は、終了要求を送信し（１１４）、終了確認を受信する（１１６）。段階６０は、セッション終了要求を送信し（１１８）、セッション終了確認を受信し（１２０）、ＴＣＰ／ＩＰソケットを終了する（１２２）。

図８を参照すると、表１３０は、ＡＰＩ２８が使用するメッセージ内のフィールドを定義するために使用する一組のデータ・タイプを示す。表１３０は、データ・タイプ名１３２、定義１３４、及びバイト・サイズ１３６を含む。ＣＨＡＲ［ｎ］は、ＵＴＦ−８文字列を参照する。ＵＴＦ−８は、全部のＡＳＣＩＩ文字が、ＡＳＣＩＩと同じコード化により１つのバイト内にコード化される文字コード化スキームである。一方、ユニコード（Ｕｎｉｃｏｄｅ）文字全体の中の任意のものを、バイトがＡＳＣＩＩ文字値を含んでいない複数のバイト・シーケンスによりコード化することができる。

長さが１バイトを超える全ての数値データは、ＴＣＰ／ＩＰ標準が定義する規範的ネットワーク・バイト順序、すなわち最上位バイトが最初に来て最下位バイトが最後に来る順序で送信される。アプリケーションの正確さ及び可搬性を確保するために、アプリケーション開発者は、ホスト・プラットフォームがネットワークのバイト順序を使用することを知っている場合でも、そのプラットフォームのホスト−ネットワーク及びネットワーク−ホスト変換機能（ｈｔｏｎｌ（）及びｎｔｏｈｌ（）など）を使用するように推奨される。ｈｔｏｎｌ（）は、３２ビット（４バイト）量をホスト・バイト順序からネットワーク・バイト順序に変換するＵＮＩＸ（登録商標）機能の一例である。一方、ｎｔｏｈｌ（）は、３２ビット量をネットワーク・バイト順序からホスト・バイト順序に変換するＵＮＩＸ（登録商標）機能の一例である。

図９を参照すると、アプリケーション・プログラム３０とＭＳＳＰサーバ２２間の通信
路１４０（矢印で示す）は、階層化アーキテクチャを使用する。アプリケーション・プログラム３０は、そのシステムのアプリケーション層１４２、プレゼンテーション層１４４、セッション層１４６、トランスポート層１４８、ＴＣＰ／ＩＰ層１５０及び下位層１５２を通して、ＭＳＳＰサーバ２２の対応する下位層１５４、ＴＣＰ／ＩＰ層１５６、トランスポート層１５８、セッション層１６０、プレゼンテーション層１６２及びアプリケーション層１６４にデータを送信する。

トランスポート層１５８は、セッション層１６０に信頼性の高いトランスポートを行うために使用される。トランスポート層１５８は比較的軽量である。何故なら、この層は定義により信頼性が高いローカルＴＣＰ／ＩＰ層１５６の一番上に位置しているからである。トランスポート層１５８は、セッション層１６０からメッセージを受信し、次にこのメッセージは送信される。トランスポート層１５８は、ＴＣＰ／ＩＰ層１５６が提供するバイト・ストリームを、トランスポート・ヘッダによりフレーム内に囲まれているメッセージに分割する。

一般的に、フレームは、ネットワーク点間でアドレス指定及び必要なプロトコル制御情報を含む１つの単位として送信されるデータである。フレームは、通常、直列に１ビットずつ送信され、データを「フレーム」状に囲んでいるヘッダ・フィールド及びトレーラ・フィールドを含む。

図１０を参照すると、この図は、トランスポート層によりセッション・メッセージに分割されたＴＣＰ／ＩＰバイト・ストリームを示す。フレーム・マーカは、ある種の他のプロトコルとは異なり、自分自身でトランスポート・メッセージ・ヘッダの境界を決定しない。また、フレーム・マーカ・データ・パターンは、悪影響を及ぼすことなく、特殊なコード化を行わなくても、ＴＣＰ／ＩＰバイト・ストリーム内の他の場所に存在することができる。フレーム・マーカは、普通のプログラミング・エラー（間違ったバイトの順序又は長さの計算間違いなど）を検出する手段を提供し、そうでない場合には、受信機が、ある他のデータをトランスポート・メッセージ・ヘッダを間違って解釈し、正しくない行動をとらせる恐れがある。

ＡＰＩ２８は、メッセージ内の最初の要素として８バイトのトランスポート・メッセージ・ヘッダを使用する。８バイトのトランスポート・メッセージ・ヘッダは、有効なトランスポート・メッセージ・ヘッダの存在を確認するために使用する一定の値の４バイトのＩＮＩＴ「フレーム・マーカ」フィールドを含む。任意の他の値は、メッセージのフレーミング・エラーを示す。８バイトのトランスポート・メッセージ・ヘッダは、また、４バイトの「メッセージ長さ」フィールドを含み、後に続くメッセージ・データの長さをバイト単位で示すＵＮＩＴデータ・タイプを含む。

ＡＰＩ２８は、メッセージの到着を保証する信頼性の高いＴＣＰ／ＩＰトランスポート層の頂部に形成されたセッション・レベル・インタフェースを使用する。このセッション層は、アプリケーション層に一組のセッション・レベル・サービスを提供する。これらのサービスは、認証、セッション・レベル・ハートビート、及びセッション・レベル肯定応答を含む。

一般的に、ハートビートは、通信リンクの状態を監視し、メッセージのストリングの最後を受信しなかった場合にはそれを識別する。接続のどちらかの端部が、指定の秒数の間データを全然送信しなかった場合には、その端部はハートビート・メッセージを送信する。接続のどちらかの端部が指定の秒数の間データを全然受信しなかった場合には、その端部は試験要求メッセージを送信する。ある同じ時間経過した後で依然としてハートビート・メッセージを受信しなかった場合には、接続は失われたものと見なされ、修正行動がス
タートする。

セッション層のところで交換した全てのメッセージは、４つのＵＳＨＯＲＴの２バイト・フィールドのヘッダをメッセージ内の最初の要素として含む。ヘッダはセッション・メッセージ・ヘッダと呼ばれ、セッション・メッセージ・タイプ・フィールド、セッション例フィールド、セッション送信シーケンス番号フィールド及びセッション受信シーケンス番号フィールドを含む。

セッション・メッセージ・タイプ・フィールドは、メッセージ・タイプを識別する値及びメッセージ・データのフォーマットを含む。セッション例フィールドは、接続例を一意に識別する値を含む。セッション送信シーケンス番号フィールドは、メッセージの送信シーケンス番号を含む。セッション受信シーケンス番号フィールドは、最後に受信したメッセージからの送信シーケンス番号を含む。

全てのセッション・メッセージは、送信側が設定し、受信側が確認するセッション・メッセージ・ヘッダ内にシーケンス番号のペアを含む。各送信側は、ゼロからスタートして、送信した各メッセージ毎に送信シーケンス番号を増分する。さらに、各送信側は、受信を予想している次のセッション送信シーケンス番号を継続的に追跡する。送信した各メッセージはこの番号のペアを含む。シーケンス番号は、喪失したセッション・メッセージを検出し、データの受信に肯定応答を行うための手段を提供するために使用される。セッション・ハートビート・メッセージ内のシーケンス番号の周期的交換は、セッションがセッション・データ（ＳｅｓｓＤａｔａ）メッセージについてアイドルであるイベント内で確実にシーケンス番号が最新の状態のままであるようにする。

セッション層プロトコル・バージョンは、オープン・セッション中に取り決められる。クライアントは、セッション中に使用するプロトコルの所望するバージョンを指定する。クライアントは、最初に、クライアントがサポートしているプロトコルの最新のバージョンを指定する。サーバは、必要なバージョン番号をチェックして、それをそれがサポートしているバージョンと比較する。必要なバージョンがサーバがサポートしているバージョンの範囲内にある場合には、そのバージョンの受け入れが、セッション・オープン構成（ＳｅｓｓＯｐｅｎＣｏｎｆ）メッセージ内に表示される。クライアントがサーバがサポートしているバージョンを超えるバージョンを要求した場合には、サーバはそのセッションが、サーバがサポートしている最新のバージョンにより確立されていることを示すセッション・オープン構成メッセージで応答する。このバージョンは、クライアントが最初に要求したバージョンとは異なるものである。サーバが相互にサポートしているプロトコルのバージョンを発見できなかった場合には、ＭＳＳＰ＿Ｅ＿ＩＮＶＡＬＩＤ＿ＶＥＲＳＩＯＮのエラー・コードを含むセッション・エラー（ＳｅｓｓＥｒｒｏｒ）メッセージが送信され、セッションが終了する。

同様に、セッション層オプションは、オープン・シーケンス中に取り決められる。クライアントは、セッション中に使用する所望のプロトコル・オプションを指定する。クライアントは、いつでも最初に、クライアントがサポートしている全てのオプションを指定しなければならない。サーバは、要求されたオプション・マスクをチェックして、自身がサポートしているこれらオプションを選択する。結果としての相互セッション・オプションは、以降のセッション・オープン構成メッセージによりクライアントに送られる。クライアントがサーバがオプションを低減したために機能することができない場合には、ＭＳＳＰ＿Ｅ＿ＩＮＶＡＬＩＤ＿ＯＰＴＩＯＮＳのエラー・コードを含むセッション・エラー・メッセージがサーバに送られ、セッションは終了する。

同様に、ハートビート間隔は、オープン・シーケンス中に取り決められる。クライアン
トは、セッション・オープン要求（ＳｅｓｓＯｐｅｎＲｅｑ）メッセージ内にその所望のハートビート間隔を指定し、サーバは、クライアントが以降のセッション・オープン構成メッセージで使用しなければならないハートビート間隔で応答する。

クライアント及びサーバは、セッション確立シーケンス中に信用証明書を交換する。クライアントは、公開／秘密鍵のペアの秘密鍵を使用して暗号化したセッション・オープン要求メッセージ（セッション・セキュリティ記述子フィールドを除く）のＭＤ５メッセージのダイジェストである暗号化セッション・セキュリティ記述子を供給する。ＭＤ５メッセージ・フォーマットは、ＲＳＡＤａｔａＳｅｃｕｒｉｔｙ社が設計しているもので、ＩＥＴＦＲＦＣ１３２１（ｗｗｗ．ｉｅｔｆ．ｏｒｇ参照）内に定義されている。所与のアプリケーションは、毎回同じ方法でそのセッションを開く傾向があるので、「一定の」メッセージ・ダイジェスト値及び結果として予測できるセッション・セキュリティ記述子が発生するのを防止するために、メッセージは乱数フィールドを含む。アプリケーションのＭＳＳＰサーバ２２構成は、公開／秘密鍵のペアの公開鍵を含む。セッション・オープン要求メッセージ内でセキュリティ記述子を受信した場合には、サーバは、クライアントの公開鍵を入手し、この公開鍵により所与のセキュリティ記述子を解読し、解読した結果が受信メッセージから生成したＭＤ５メッセージ・ダイジェストと正確に一致することを確認するために、ＭＳＳＰサーバ２２構成のアプリケーションを参照する。信用証明書の確認に失敗した場合には、サーバは、ＭＳＳＰ＿Ｅ＿ＡＵＴＨ＿ＦＡＩＬＵＲＥのエラー・コードを含むセッション・エラー・メッセージで応答する。単位時間内に連続して多数の失敗が起こった場合には、サーバは１分以上の間接続要求の聴取を中断する。

信用証明書が確認された場合には、サーバは、セッション・オープン構成メッセージ内でクライアントに、異なる公開鍵／秘密鍵のペアの秘密鍵を使用して暗号化した（セッション・オープン構成メッセージ（セッション・セキュリティ記述子フィールドを除く）のＭＤ５メッセージ・ダイジェストである）セッション・セキュリティ記述子を提供する。クライアントは、サーバの公開鍵を使用して記述子を解読し、サーバを認証する。接続のクライアント側でサーバの信用証明書の確認に失敗した場合には、クライアントは、ＭＳＳＰ＿Ｅ＿ＡＵＴＨ＿ＦＡＩＬＵＲＥのエラー・コードを含むセッション・エラー・メッセージを送信する。単位時間内に連続して多数の失敗が起こった場合には、サーバは１分以上の間接続要求を中断する。

セッション・オープン要求メッセージは、アプリケーションとＡＰＩ２８との間で情報のセッション・レベルの交換をスタートするために使用される。セッション・オープン要求メッセージは、上記のようにトランスポート層接続が確立された後に位置する最初のメッセージである。セッション・オープン要求メッセージは、下記のフォーマットを有する：
セッション・オープン要求に等しいセッション・メッセージ・タイプを含むセッション・ヘッダである８バイトのセッション・ヘッダ・フィールド。クライアントがサポートしているセッション・プロトコル・バージョンを表す４バイトのＵＮＩＴセッション・バージョン・フィールド。クライアントがサポートしている全てのセッション層オプションのビット単位の組合わせを表す４バイトのＵＮＩＴセッション・オプション・マスク・フィールド。数秒間のセッション・ハートビート・メッセージの交換の間の公称間隔を表す４バイトのＵＮＩＴセッション・ハートビート間隔フィールド。ＭＳＳＰサーバ２２内でこのクライアント・アプリケーションを一意に識別するＭＳＳＰサーバ２２が決定した値を表す４バイトのＵＮＩＴセッション・アプリケーションＩＤフィールド。４バイトのＵＮＩＴセッション乱数フィールドは、任意の予測できない値を表し、予測できるセッション・セキュリティ記述子を防止するために使用される。公開鍵／秘密鍵のペアのクライアントの秘密鍵を使用して暗号化したメッセージ（このフィールドを除く）のＭＤ５メッセージ・ダイジェストであるセッション・セキュリティ記述子を表す１６バイトのＢＹＴＥ［
１６］セッション・セキュリティ記述子フィールド。サーバは、クライアントを認証するために、クライアントの公開鍵のそのコピーによりセッション・セキュリティ記述子を解読する。

セッション・オープン構成メッセージは、セッションの確立を完成し、取り決めたパラメータの結果を送るために使用される。このメッセージは、成功応答としてセッション・オープン要求メッセージに送信され、下記のフォーマットを有する：
セッション・メッセージ・タイプ＝ＳＥＳＳ＿ＯＰＥＮ＿ＣＯＮＦを含むセッション・ヘッダを表す８バイトのセッション・ヘッダ・フィールド。サーバが使用するために選択したセッション・プロトコル・バージョンを表す４バイトのＵＮＩＴセッション・バージョン・フィールド。サーバが選択した全てのクライアント・セッション層オプションのビット単位の組合わせを表す４バイトのＵＮＩＴセッション・オプション・マスク・フィールド。数秒間にセッション・ハートビート・メッセージの交換の間の公称間隔を表す４バイトのＵＮＩＴセッション・ハートビート間隔フィールド。４バイトのＵＮＩＴセッション・サーバＩＤフィールドは、このＭＳＳＰサーバ２２例を一意に識別するある値を表す。４バイトのＵＮＩＴセッション乱数フィールドは、任意の予測できない値を表し、予測できるセッション・セキュリティ記述子を防止するために使用される。公開鍵／秘密鍵のペアのサーバの秘密鍵を使用して暗号化したメッセージ（このフィールドを除く）のＭＤ５メッセージ・ダイジェストであるセッション・セキュリティ記述子を表す１６バイトのＢＹＴＥ［１６］セッション・セキュリティ記述子フィールド。クライアントは、サーバを認証するために、サーバの公開鍵のそのコピーによりセッション・セキュリティ記述子を解読しなければならない。

セッションは、クライアント及びサーバがセッション維持手順に参加することを要求する。セッション維持手順は、確実に非能動又はアイドル・セッションを機能的にし、また確実に応答時間を妥当な制限内に入れる。セッション維持手順は、セッション中に他のデータが送信されていてもいなくてもそれとは無関係に行われる。セッション維持手順は、セッション・ハートビート要求（ＳｅｓｓＨｅａｒｔｂｅａｔＲｅｑ）メッセージの交換を含む。このメッセージの後にはセッション・ハートビート構成（ＳｅｓｓＨｅａｒｔｂｅａｔＣｏｎｆ）メッセージが続く。セッション維持手順は、セッション・ハートビート要求メッセージを送信することにより接続のクライアント側からスタートする。サーバは、サーバが確実に正しく機能していることを確認するために一組の動作を行い、全てうまくいっている場合には、セッション・ハートビート構成メッセージを返送する。サーバがハートビート間隔中に応答するのに失敗した場合には、クライアントは、サーバにＭＳＳＰ＿Ｅ＿ＨＥＡＲＴＢＥＡＴ＿ＴＩＭＥＯＵＴのエラー・コードを含むセッション・エラー・メッセージを送信することにより、セッションを打ち切る。クライアントは、セッションが確立された時点で、セッション・オープン構成メッセージ内に指定されている周期的間隔でハートビート要求を行う。クライアントの最初のハートビートは、セッション・オープン構成メッセージを受信した時に送信される。セッション・ハートビート要求メッセージを送信した場合には、クライアント・タイマは、ハートビート間隔に設定され、セッション・ハートビート要求は、タイマが時間切れになった場合に送信される。サーバは、指定のハートビート間隔中にハートビート要求を入手することを予想する。サーバは、セッション・オープン構成メッセージの送信後にタイマを設定し、時間切れの長さはハートビート間隔の２倍に設定される。タイマが時間切れになり、ハートビート要求を受信しなかった場合には、ＭＳＳＰ＿Ｅ＿ＨＥＡＲＴＢＥＡＴ＿ＴＩＭＥＯＵＴのエラー・コードを含むセッション・エラー・メッセージを送信することにより、サーバはセッションを打ち切る。新しいハートビート要求を受信する度に、サーバ側のタイマはリセットされる。任意の所与の瞬間に、ハートビート要求の１つだけが未決状態になる。ハートビート・メッセージは、データ・メッセージの肯定応答を行うために、又はアイドル・セッション接続上のシーケンス番号の管理ミスに関連するエラーを検出するためにも使用されること
に留意されたい。

セッション・ハートビート要求メッセージは、セッションのパートナーが正常に動作していて、下記のフォーマットを有することの確認を要求するために使用される：
セッション・メッセージ・タイプ＝ＳＥＳＳ＿ＨＥＡＲＴＢＥＡＴ＿ＲＥＱを含むセッション・ヘッダを表す８バイトのセッション・ヘッダ・フィールド。セッション内の所与のハートビートを一意に識別するある値を表す４バイトのＵＮＩＴセッション・ハートビート例フィールド。ハートビート要求が発行された時間を表す４バイトのＴＩＭＥセッション・タイムスタンプ・フィールド。数秒のセッション・ハートビート・メッセージの交換の間の公称間隔を表す４バイトのＵＮＩＴセッション・ハートビート間隔フィールド。この間隔は、送信側が新しいハートビート間隔を取り決めたい場合には、現在のハートビート間隔と異なる場合がある。

セッション・ハートビート構成メッセージは、セッションのパートナーの正常な動作状態の確認を完了するために使用される。このメッセージはセッション・ハートビート要求メッセージに成功応答として送信される。セッション・ハートビート構成メッセージは、下記のフォーマットを有する：
ＳＥＳＳ＿ＨＥＡＲＴＢＥＡＴ＿ＣＯＮＦに等しいセッション・メッセージ・タイプを含むセッション・ヘッダを表す８バイトのセッション・ヘッダ・フィールド。対応するハートビート要求中に与えられた同じセッション・ハートビート例の値を表す４バイトのＵＮＩＴセッション・ハートビート例フィールド。対応するハートビート要求中に与えられた同じセッション・タイムスタンプ値を表す４バイトのＴＩＭＥセッション・タイムスタンプ・フィールド。数秒内のセッション・ハートビート・メッセージの交換の間の公称間隔を表す４バイトのＵＮＩＴセッション・ハートビート間隔フィールド。これは、新しいハートビート間隔が取り決められた場合、現在のハートビート間隔とは異なる場合がある。

セッションはセッションの確立が成功した後でいつでも、クライアント又はサーバにより終了することができる。クライアント又はサーバは、セッション終了要求（ＳｅｓｓＣｌｏｓｅＲｅｑ）メッセージをセッション・パートナーに送信することにより終了手順をスタートする。セッション終了要求メッセージは、終了の理由を示すコードを含む。要求セッション・パートナーは、セッション終了要求メッセージを送信した後でトランスポート層を（ソケット感覚で）シャットダウンする。受信セッション・パートナーは、アプリケーション層にセッション上の任意の未決の要求を完了することができることを通知する。任意の待ち行列内のセッション・メッセージは、セッション終了構成（ＳｅｓｓＣｌｏｓｅＣｏｎｆ）メッセージを送信する前に送信される。セッション終了構成メッセージが送信されると、トランスポート接続がシャットダウンし、ソケット接続がセッションの終了を要求した側から終了する。クライアントは、サーバが妥当な時間内に応答できなかった場合には、終了要求を時間切れにすることができる。クライアントが終了要求を時間切れにすると、セッション・エラー・メッセージが、ＭＳＳＰ＿Ｅ＿ＣＬＯＳＥ＿ＴＩＭＥＯＵＴのエラー・コードと一緒にサーバに送信される。終了要求の時点でセッションがまだスタートしていないために、セッション・パートナーが終了要求を処理できない場合には、セッション・エラー・メッセージがＭＳＳＰ＿Ｅ＿ＮＯ＿ＳＥＳＳＩＯＮのエラー・コードと一緒に要求しているパートナーに送信される。セッションが能動状態にあるか初期化され、セッション・パートナーが何らかの理由で終了要求を処理できない場合には、受信機は、要求側にＭＳＳＰ＿Ｅ＿ＵＮＳＰＥＣＩＦＩＥＤ＿ＦＡＩＬＵＲＥのエラー・コードと一緒にセッション・エラー・メッセージを送信する。

セッション終了要求メッセージは、セッションの正しい順序での終了をスタートするために使用され、下記のフォーマットを有する：
セッション・メッセージ・タイプ＝ＳＥＳＳ＿ＣＬＯＳＥ＿ＲＥＱを含むセッション・ヘッダを表す８バイトのセッション・ヘッダ・フィールド。セッション終了の理由を示すある値を表す４バイトのＵＮＩＴセッション終了理由コード・フィールド。ＭＳＳＰ理由コードは、例えば、正常な動作、正常な動作中の部分的詳細、通常のシャットダウン、加入者ログアウト、流れの時間切れ、及びセッションの時間切れを含む。

セッション終了構成メッセージは、セッションの正しい順序での終了を完了するために使用される。このメッセージは、セッション終了要求メッセージに成功応答として送信され、下記のフォーマットを有する：
セッション・メッセージ・タイプ＝ＳＥＳＳ＿ＣＬＯＳＥ＿ＣＯＮＦを含むセッション・ヘッダを表す８バイトのセッション・ヘッダ・フィールド。

セッションを確立する１つの目的は、クライアントとサーバとの間でデータを交換するためである。データ・メッセージは、セッション・オープン・シーケンスの完了の後で当事者間で交換することができる。セッション層は、データ・メッセージを解釈しない。受信したデータ・メッセージは、処理のためにアプリケーション層に転送される。セッション・データ・メッセージのセッション・データ・フィールド内に含まれているバイトだけが、アプリケーション層に転送される。こうすることにより、アプリケーションに送る前にメッセージのセッション部分が効果的に除去される。また、トランスポート層から受信したメッセージは、全てのトランスポート層ヘッダ又はデータを含んでいないで、処理の前にメッセージは完全なものになる。データを送信する場合にはこの逆になる。セッション層は、送信のためにトランスポート層に転送されるセッション・データ・メッセージ内にアプリケーション・データを収容する。

セッション・データ・メッセージのセッション・データは、セッション・パートナーにアプリケーション層データを送信するために使用され、下記のフォーマットを有する：
セッション・メッセージ・タイプ＝ＳＥＳＳ＿ＤＡＴＡを含むセッション・ヘッダを表す８バイトのセッション・ヘッダ・フィールド。アプリケーション層に配信されるデータを表す可変長セッション・データ・フィールド。

通信又はプロセスの故障のために、セッションを時々打ち切ることができる。セッションが故障した場合には、故障を検出するセッション・パートナーのコンテキストの下で故障が非同期で報告される。クライアント側又はサーバ側は、セッション・エラー・メッセージを送信することができる。セッション・エラー・メッセージは、セッション・オープン要求メッセージの後でクライアント側からいつでも送信することができる。セッション・オープン要求への応答を含むセッション・エラー・メッセージは、サーバ側からいつでも送信することができる。セッション・エラー・メッセージは、故障の理由を示すエラー・コードを含む。セッション・パートナーは、エラーの性質によりセッション・エラー・メッセージを受信することもできるし、受信しないこともできる。セッション・エラー・メッセージの送信又は受信の後では、セッション中にデータを送ることができないし、重要なトランスポート接続をシャットダウンし、終了しなければならない。

セッション・エラー・メッセージは、セッション・パートナーに、さらなるセッション・レベル通信を防止するエラー条件を通知するために使用される。このメッセージは下記のフォーマットを有する：
セッション・メッセージ・タイプ＝ＳＥＳＳ＿ＥＲＲＯＲを含むセッション・ヘッダを表す８バイトのセッション・ヘッダ・フィールド。４バイトのＵＮＩＴセッション・エラー・コード・フィールドは、セッションの故障の原因を示すある値を表す。

図１１を参照すると、この図はサンプル・エラー・コードを含む表１７０を示す。
ＭＳＳＰサーバ２２の機能は、機能分類にグループ分けすることができる。アプリケーション３０が、ＭＳＳＰサーバ２２とのそのセッションを開いた場合、アプリケーション３０は、ＡＰＩ２８を通して自身が使用したい機能を指定する。各ＭＳＳＰ機能は対応する特権ビットを有する。アプリケーション用のＭＳＳＰ記憶デバイス３４内に常駐しているＭＳＳＰ構成データベース３２内の構成エントリは、アプリケーション３０のどんな機能を使用できるようにするのかを制御する一組の機能特権を含む。アプリケーション３０に許可される要求された機能だけが許可され、アプリケーション３０には、要求への応答で入手に成功した機能が通知される。許可されなかった機能分類内のメッセージを使用しようとするアプリケーションの試みは、特権エラーにより拒否される。

図１２を参照すると、この図は、機能分類を示す表１８０である。機能分類は、共通のサービス機能分類１８２、初期検出点機能分類１８４、イベント報告機能分類１８６、サービス・フィルタ機能分類１８８、メータ構成機能分類１９０、課金通知機能分類１９２、課金計画機能分類１９４、明細レコード制御機能分類１９６、統計機能分類１９８、及びアプリケーション監視機能分類２００を含む。各機能分類１８２〜２００に関連するメッセージが、そのそれぞれのフォーマットと一緒に付録Ａに記載されていて、参照により本明細書に組み込むものとする。

他の実施形態も特許請求の範囲内に含まれる。
（付録Ａ）
共通のサービス
説明：このセクション内のメッセージは、アプリケーション特権とは無関係に、ＡＰＩを使用している全てのアプリケーションに対して共通である。
必要な特権：なし。
メッセージのリスト：MSSPNegotiateAPIVersionReq、MSSPNegotiateAPIVersionConf 、MSSPOpenReq 、MSSPOpenConf、MSSPCloseReq、MSSPCloseConf 、MSSPFailureConf 、MSSPFailureEvent、MSSPGetSystemTimeReq、MSSPGetSystemTimeConf 、MSSPGetServiceListReq 、MSSPGetServiceListConf、MSSPGetServiceDetailReq 、MSSPGetServiceDetailConf．
MSSPNegotiateAPIVersionReq
説明：このメッセージは、アプリケーションがアプリケーション・レベルの通信のために使用したいＡＰＩのバージョンを示すために、ＭＳＳＰ２２にそのアプリケーションによって送信される。メッセージのフォーマットが変化するので、他のアプリケーション・メッセージを交換できるようになる前にＡＰＩのバージョンが取り決められなければならない。MSSPNegotiateAPIVersionReq、MSSPNegotiateAPIVersionConf 、及びMSSPFailureConf だけが、全てのＡＰＩバージョンにおいて同じメッセージ・フォーマットを有することが保証されている。これは、前のセクションにおいて説明したように通信セッションが確立された後で送信されなければならない最初のメッセージである。

ＭＳＳＰ２２はそれ以降の全てのアプリケーション・メッセージに対して使用される取り決められたＡＰＩバージョンを指定するMSSPNegotiateAPIVersionConf メッセージで応答する。これは、アプリケーションが要求したバージョンより低いか、又はそれに等しい、ＭＳＳＰ２２によってサポートされている最高のＡＰＩバージョンである。両方の当事者に対して共通のＡＰＩバージョンを識別することができない場合、ＭＳＳＰ＿Ｅ＿ＩＮＶＡＬＩＤ＿ＶＥＲＳＩＯＮのエラー・コードを含むMSSPFailureConf メッセージがＭＳＳＰ２２から返送される。

MSSPNegotiateAPIVersionConf
説明：このメッセージは、MSSPNegotiateAPIVersionReq要求メッセージの受信に肯定応答を行うためにＭＳＳＰ２２によって送信され、それ以降の全てのアプリケーション層のメッセージに対して選択されたＡＰＩバージョンを提供する。

MSSPOpenReq
説明：このメッセージは、アプリケーションとＭＳＳＰ２２との間での情報のアプリケーション・レベルの交換を開始するために使用される。これは上記のようにＡＰＩバージョンが確立された後で送信される最初のメッセージである。アプリケーションはこのメッセージを使用してＭＳＳＰ２２の１つ又はそれ以上の機能にアクセスを要求する。

MSSPOpenConf
説明：このメッセージは、MSSPOpenReq 要求メッセージの受信に肯定応答を行うために、ＭＳＳＰ２２によって送信される。このメッセージは、MSSPOpenReq で要求されたサービスのうちのどれが実際に許可されているかを示す。

MSSPCloseReq
説明：このメッセージは、アプリケーションとＭＳＳＰ２２との間の情報のアプリケーション・レベルの交換を終了するために使用される。

MSSPCloseConf
説明：このメッセージは、MSSPCloseReq要求メッセージの受信に肯定応答を行うために、ＭＳＳＰ２２によって送信される。それ以上のアプリケーション・レベルのメッセージはＭＳＳＰ２２からは送信されず、アプリケーションから受け付けられもしない。

MSSPFailureConf
説明：このメッセージは、エラー状態が以前のアプリケーション要求メッセージの正しい処理を妨げる時に、ＭＳＳＰ２２によって送信される。このメッセージは、アプリケーションの要求メッセージ内で指定された要求ＩＤ及びその失敗の理由を示すエラー・コードを含む。

MSSPFailureEvent
説明：このメッセージは、以前のアプリケーション要求メッセージの処理に直接には関連しないエラー状態が発生した時に、ＭＳＳＰ２２によって送信される。このメッセージは、その故障の理由を示すエラー・コードを含む。

MSSPGetSystemTimeReq
説明：このメッセージは、ＭＳＳＰ２２から現在の時刻を要求するために使用される。

MSSPGetSystemTimeConf
説明：このメッセージは、MSSPGetSystemTimeReq要求メッセージに対する応答において、ＭＳＳＰ２２によって送信される。

MSSPGetServiceListReq
説明：このメッセージは、そのアプリケーションが提供するように構成されているＭＳＳＰ２２のサービス識別子のリストを要求するために使用される。

MSSPGetServiceListConf
説明：このメッセージは、MSSPGetServiceListReq 要求メッセージに対する応答において、ＭＳＳＰ２２によって送信される。

MSSPGetServiceDetailReq
説明：このメッセージは、指定されたＭＳＳＰ２２のサービスの構成に関する詳細情報を要求するために使用される。アプリケーションは提供するように構成されているサービスに対する詳細だけを要求することができる。

MSSPGetServiceDetailConf
説明：このメッセージは、MSSPGetServiceDetailReq 要求メッセージに対する応答において、ＭＳＳＰ２２によって送信される。

MSSPServiceRemovedEvent
説明：このメッセージは、アプリケーションがＭＳＳＰ２２に接続されている間に提供するように構成されているサービスのリストからサービスが取り除かれる時に、ＭＳＳＰ２
２によって送信される。そのアプリケーションによって使用されていた任意のサービスリソース（検出点など）は、ＭＳＳＰ２２によって自動的に解放される。

MSSPResourceUnavailableEvent
説明：このメッセージは、故障状態又はＭＳＳＰ２２ハードウェアの再構成によって、そのアプリケーションによって使用されているリソースが利用できなくなった時に、ＭＳＳＰ２２によって送信される。そのリソースが正常な動作を回復した時、MSSPResourceAvailableEvent メッセージが送信される。

MSSPResourceAvailableEvent
説明：このメッセージは、MSSPResourceUnavailableEvent内で以前に利用不可能と報告されたリソースが正常動作を回復した時に、ＭＳＳＰ２２によって送信される。

初期検出点（ＩＤＰ）機能
説明：このセクション内のメッセージは、アプリケーションがＭＳＳＰ２２内で初期検出点を着装及び脱着装することができ、その関連するＩＤＰイベントをサービスすることを可能とさせる。
必要な特権：ＩＤＰ。
メッセージのリスト：MSSPArmIDPReq 、MSSPArmIDPConf、MSSPDisarmIDPReq、MSSPDisarm
IDPConf 、MSSPInitialIDPEvent 、MSSPContinueReq 、MSSPContinueConf、MSSPConnectReq、MSSPConnectConf 、MSSPReleaseReq、MSSPReleaseConf 、MSSPActivityTestReq 、MSSPActivityTestConf

MSSPArmIDPReq
説明：この要求は、初期検出点を識別し、アプリケーションが通知されるトラヒック基準を指定するために使用される。初期検出点は、制御取得フィールドの設定に依存して、単純なイベント通知に対して、又はトリガとして着装することができる。制御取得フィールドをＭＳＳＰ＿ＴＲＩＧＧＥＲに設定すると、トリガが着装される。

流れがトリガ付きの検出点に達すると、パケットの転送が停止され、そのアプリケーションが通知される。アプリケーションは次の要求の１つで応答することによってパケットの転送の回復を制御する。

MSSPContinueReq 、
MSSPConnectReq、
MSSPControlReq、又は
MSSPReleaseReq
これらの要求はどのように進行するかをＭＳＳＰ２２に指示し、その流れの中のパケットはそれに従って配信される。アプリケーションはトリガに対して迅速に応答しなければ
ならない。トリガとそれに関連する応答との間の遅延時間はサービスによって、及びアプリケーションによって測定され、１０００ｍｓ以内にトリガに応答しなかった場合、ＭＳＳＰ２２はそのサービス及びアプリケーションのトリガのタイムアウト・カウンタを増分し、「継続」応答が受信されたかのように通常のパケット処理を再開する。検出点がイベント通知に対してのみ着装された場合、トリガの場合と同様にアプリケーションにイベント通知が送信される。ただし、パケット転送は停止されず、アプリケーションからの応答は期待されない。

基準の文字列は、広い範囲のトリガを指定するために使用することができるワイルド・カード値を備えていてもよい。ＭＳＳＰ２２は、ＩＤＰの着装が成功した後、MSSPArmIDPConfメッセージを送信する。エラー状態によってＩＤＰの着装が妨げられた場合、その故障に対する理由を示す代わりに、MSSPFailureConf メッセージが返送される。

以下のセクションではこれらの各検出点クラスについてさらに詳しく説明する。各セッションにおいて、そのクラスで利用できる検出点のリストが各検出点に関連する属性及び着装基準に沿って列挙される。「ＩＤＰ」属性付きの検出点は初期検出点として着装することができる。「トリガ」属性付きの検出点はトリガ又はイベント報告のいずれかとして着装することができる。「トリガ」属性を伴ってリストされていない検出点はイベント報告を提供することができるだけである。
セッション・グループ検出点クラス
このクラスの検出点によって、アプリケーションは種々の加入者グループ制限値が超過されたときにポリシー決定を実施することができる。アプリケーションはＩＤＰ着装基準内に制限値を提供する。ＩＤＰがトリガとして着装されている場合、アプリケーションは継続又は解放のトリガ応答をそれぞれ送信することによって、その制限値を超過することを許可するか否かを決定することができる。

ＩＤＰイベントの注：初期ＤＰイベントメッセージ内の数値１及び数値２のパラメータは、検出点が評価されたときのパラメータの実際の値を含み、制限値ではない。

基準の注：全ての基準が完全に規定されなければならず、ワイルド・カードの値は受け入れられない。
制御動作：なし。
セッション検出点クラス
このクラスの検出点によって、アプリケーションはモバイル加入者セッションの確立及び終了を監視及び制御することができる。ＩＤＰがトリガとして着装されている場合、アプリケーションは、連続又は解放のトリガ応答をそれぞれ送信することによって、その加入者セッションが進行するか、又は進行しないかを決定することができる。

基準の注：オペレータＩＤ及び加入者グループＩＤに対してワイルド・カード値を指定することができる。長さゼロの文字列値を、任意の加入者に一致するワイルド・カードとして指定することができる。

制御動作：なし。
ＲＡＤＩＵＳ検出点クラス
このクラスの検出点によって、アプリケーションはモバイル加入者セッションのユーザ・サービスにおけるリモート認証ダイヤル（ＲＡＤＩＵＳ）プロトコルのアクティビティを監視及び制御することができる。ＩＤＰがトリガとして着装されている場合、アプリケーションは、制御操作を発行して加入者の受入れを制御し、ＲＡＤＩＵＳメッセージの属性を変更することができる。

基準の注：オペレータＩＤ及び加入者グループＩＤに対してワイルド・カード値を指定することができる。長さゼロの文字列値を、任意の加入者に一致するワイルド・カードとして指定することができる。
制御動作：次の制御動作が定義されている。

ＤＨＣＰ検出点クラス
このクラスの検出点によって、アプリケーションはモバイル加入者セッションの動的ホスト構成プロトコル（ＤＨＣＰ）のアクティビティを監視及び制御することができる。

ＩＤＰイベントの注：ＤＰ＿ＤＨＣＰ＿ＡＣＫ検出点からの初期ＤＰイベント・メッセージ内の宛先ＩＰパラメータは、加入者に割り当てられているＩＰアドレスを含む。

基準の注：ワイルド・カード値をオペレータＩＤに対して指定することができる。長さゼロの文字列値を任意の加入者に一致するワイルド・カードとして指定することができる。

制御動作：なし。
ＤＮＳ検出点クラス
このクラスの検出点によって、アプリケーションはモバイル加入者セッションのドメイン名システム（ＤＮＳ）プロトコルのアクティビティを監視及び制御することができる。アプリケーションがＩＰアドレスを提供してモバイル加入者ＤＮＳクエリを解決することができる制御動作が定義されている。

ＩＤＰイベントの注：ＤＰ＿ＤＮＳ＿ＱＵＥＲＹ＿ＲＥＳＰＯＮＳＥ検出点からの初期ＤＰイベント・メッセージ内の宛先ＩＰパラメータは、ＤＮＳサーバから返送されるＩＰアドレスを含む。
基準の注：ワイルド・カード値をオペレータＩＤ及び加入者グループＩＤに対して指定することができる。文字列値は、「＊．ｙａｈｏｏ．ｃｏｍ」などのように、「＊．ｄｏｍａｉｎ」の形式の部分的ワイルド・カードを指定することができる。長さゼロの文字列値も任意のホスト名に一致するワイルド・カードとして指定することができる。
制御動作：次の制御動作が定義されている。

ＴＣＰ検出点クラス
このクラスの検出点によって、アプリケーションはモバイル加入者セッションの送信制御プロトコル（ＴＣＰ）のアクティビティを監視及び制御することができる。

基準の注：オペレータＩＤ、加入者グループＩＤ、セッションＩＤ、ソース・ポート、及び宛先ポートに対してワイルド・カード値を指定することができる。ソースＩＰアドレス及び宛先ＩＰアドレスは、一致しなければならないアドレス・ビットの数を指定する（左から右へ）ことによって、部分的ワイルド・カードＩＰアドレスとして指定することができる。長さゼロのＩＰアドレスを、任意のＩＰアドレスに一致するワイルド・カードとして指定することができる。

制御動作：なし。
ＩＰ検出点クラス
このクラスの検出点によって、アプリケーションは最も低いレベル、すなわち、他の全てのプロトコルがその層の上に置かれているインターネット・プロトコル（ＩＰ）層においてモバイル加入者セッションのアクティビティを監視及び制御することができる。

基準の注：オペレータＩＤ、加入者グループＩＤ、セッションＩＤ、及びＩＰプロトコル番号（数値１）に対してワイルド・カード値を指定することができる。ソースＩＰアドレス及び宛先ＩＰアドレスは、一致しなければならないアドレス・ビットの数を指定する（左から右へ）ことによって、部分的ワイルド・カードＩＰアドレスとして指定することができる。長さゼロのＩＰアドレスは、任意のＩＰアドレスに一致するワイルド・カードとして指定することができる。長さゼロの文字列値を、任意の加入者に一致するワイルド・カードとして指定することができる。

このレベルにおいて検出点を着装している時、特にワイルド・カード値を使用する時、ネットワーク性能に大きく影響するのを避けるために、極端な注意が払われなければならない（そのアプリケーションは全てのインターネット・トラヒックのスループットを制限するボトルネックとなる）。全ての基準をワイルド・カードとして指定することによってトリガを着装することができるが、そうすることは動作環境においては明らかに不適切であり、行うべきではない。

制御動作：なし。
MSSPArmIDPConf
説明：このメッセージは、以前のMSSPArmIDPReq メッセージによって初期検出点の着装が成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

M SSPDisarmIDPReq
説明：この要求は初期検出点を脱着装し、以前に確立されたトラヒック基準のセットが破棄されるようにするために使用される。

MSSPDisarmIDPConf
説明：このメッセージは、以前のMSSPDisarmIDPReqメッセージによって初期検出点の脱着装が成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

ＭＳＳＰＩｎｉｔｉａｌＤＰＥｖｅｎｔ
説明：初期検出点イベントは、以前に着装された初期検出点における基準によって記述された条件が満足されたことを示すために使用される。検出点は特定のパターンに一致しているデータの流れの可視性又は制御を得るために着装される。ＩＤＰイベント指示は、その着装基準内でワイルド・カードが使用されたかどうかには無関係に、その検出点に関連する全ての基準に対して完全修飾データ（fully qualified data）を提供する。

制御取得オプションがセットされて着装された初期検出点は、トリガとして知られている。トリガ又はイベント検出点がヒットしていることを示すために関連するアプリケーションに送信される初期検出点イベントは、イベント・メッセージ内で制御取得フラグをＭＳＳＰ＿ＴＲＩＧＧＥＲに設定することによって、その検出点がトリガ検出点に起因するものであるかどうかを示す。

アプリケーションは次の要求のうちの１つを送信することによって、トリガ検出イベントに応答しなければならない：
MSSPContinueReq 、MSSPConnectReq、MSSPControlReq、又はMSSPReleaseReq。

非トリガの初期検出点イベント・メッセージに対しては応答は不要であるか、又は期待されない。

MSSPContinueReq
説明：この継続要求によって、トリガ点において以前に中断されていたパケットについて
再開するための正規の処理が生じる。この要求はアプリケーションが接続要求の歩調を整えることができるアプリケーション同期点を提供するために使用することができる。継続されるパケット及びその関連するコンテキストはその要求メッセージ内の制御ＩＤフィールドによって識別される。

制御ＩＤが有効でなかった場合、MSSPFailureConf メッセージがＭＳＳＰ＿Ｅ＿ＩＮＶＡＬＩＤ＿ＣＯＮＴＲＯＬ＿ＩＤの故障コードを伴って確認として送信される。制御ＩＤが有効であるがトリガ検出点において待っていない場合、MSSPFailureConf メッセージがＭＳＳＰ＿Ｅ＿ＩＮＶＡＬＩＤ＿ＳＴＡＴＥの故障コードを伴って確認として送信される。継続動作が成功した場合、パケットの処理が継続されていることを肯定的に確認するためにMSSPContinueConfが送信される。

MSSPContinueConf
説明：このメッセージは、以前のMSSPContinueReq メッセージによるパケット処理の継続が成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

MSSPConnectReq
説明：この接続要求は、以前にトリガ点において中断されたパケット上で指定された宛先アドレスに対する接続を確立するよう、ＭＳＳＰ２２に指示する。その宛先アドレスはそのトリガ条件に一致したパケット内の宛先アドレスとは異なっている場合がある。これによりアプリケーションは、最善の利用可能なリソースに対する接続を経路指定すること、及びＰａｃｋｅｔ８００サービスの仮想化のための手段を提供することができる。

中断されているパケット及びその関連するコンテキストは、その要求メッセージ内の制御ＩＤフィールドによって識別され、その宛先フィールドはその接続が確立されるＩＰアドレス及びポート番号を提供する。イベント報告マスク及びトリガ・マスクを使用して、それ以降のイベント報告及びトリガをその検出点クラスのこの例から要求することができる。

制御ＩＤが有効でなかった場合、MSSPFailureConf メッセージがＭＳＳＰ＿Ｅ＿ＩＮＶＡＬＩＤ＿ＣＯＮＴＲＯＬ＿ＩＤの故障コードを伴って確認として送信される。制御ＩＤが有効であるが、トリガ検出点において待っていない場合、MSSPFailureConf メッセージがＭＳＳＰ＿Ｅ＿ＩＮＶＡＬＩＤ＿ＳＴＡＴＥの故障コードを伴って確認として送信される。接続動作が成功した場合、MSSPConnectConf が、パケット処理が再開されたことを肯定的に確認するために送信される。

MSSPConnectConf
説明：このメッセージは、以前のMSSPConnectReqメッセージの実行が成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

MSSPControlReq
説明：このメッセージは、中断されているパケット上での制御動作を実行するために発行
される。その中断されているパケット及びその関連するコンテキストは要求メッセージ内の制御ＩＤフィールドによって識別される。制御ＩＤが有効でなかった場合、MSSPFailureConf メッセージがＭＳＳＰ＿Ｅ＿ＩＮＶＡＬＩＤ＿ＣＯＮＴＲＯＬ＿ＩＤの故障コードを伴って確認として送信される。制御ＩＤが有効であるが、トリガ検出点において待っていない場合、MSSPFailureConf メッセージがＭＳＳＰ＿Ｅ＿ＩＮＶＡＬＩＤ＿ＳＴＡＴＥの故障コードを伴って確認として送信される。制御ＩＤが有効であってトリガ検出点において待っているが、その検出点クラスが要求された制御動作をサポートしない場合、MSSPFailureConf メッセージがＭＳＳＰ＿Ｅ＿ＩＮＶＡＬＩＤ＿ＣＯＮＴＲＯＬ＿ＯＰの故障コードを伴って確認として送信される。制御動作が成功した場合、ＭＳＳＰＣｏｎｔｒｏｌＣｏｎｆが送信される。

このセクションは、全ての検出点クラスによって共有されるこのメッセージの一般的な定義を規定する。そのメッセージの内容の残りの部分は各検出点クラスに固有である。これらの検出点クラス固有のフィールドは、共通メッセージ・フォーマッティング・スキームに従い、各フィールドが２バイトのタグによって識別され、その後にデータのバイト・サイズを指定する２バイトの長さのフィールドが続き、その後にデータが続く。追加の各メッセージ・フィールドは単純にそのメッセージに付加される。そのメッセージの全体の長さ（底流にあるトランスポート・メカニズムによって提供される）を使用してこれらの「フローティング」フィールドの存在を判定することができる。

MSSPControlConf
説明：このメッセージは、以前のMSSPControlReqメッセージの実行が成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

MSSPReleaseReq
説明：このメッセージは、能動流れを終了するために発行される。終了する流れはトリガにおいて中断されているか、又は能動状態になっていてもよい。ＭＳＳＰ２２は、その流れを終了し、MSSPReleaseConf メッセージの送信に続いて任意のイベント又は測定メッセージを提供する。その確認はその流れの終了から結果として生じる任意のイベント又は測定メッセージに先立って順序付けられる。このメッセージがトリガに応答として送信されている時、その中断されたパケット及びその関連するコンテキストは、その要求メッセージ内の制御ＩＤフィールドによって識別される。メッセージ内の制御ＩＤの値がゼロであ
った場合、終了する（能動）流れは流れＩＤフィールドによって識別される。

理由コードフィールドはその流れを終了するための理由を示す１つの数値を含む。理由コードの値はその流れに対して生成される任意の明細レコード内に記憶される。流れの解放動作を肯定的に確認するためにMSSPReleaseConf メッセージが送信される。制御ＩＤフィールドが無効であった場合、ＭＳＳＰ＿Ｅ＿ＩＮＶＡＬＩＤ＿ＣＯＮＴＲＯＬ＿ＩＤのエラー・コードを伴ったMSSPFailureConf メッセージが返送される。流れＩＤフィールドが無効であった場合、ＭＳＳＰ＿Ｅ＿ＩＮＶＡＬＩＤ＿ＦＬＯＷ＿ＩＤのエラー・コードを伴ったMSSPFailureConf メッセージが返送される。

MSSPReleaseConf
説明：このメッセージは、以前のMSSPReleaseReqのメッセージの実行が成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

MSSPActivityTestReq
説明：この要求は以前に報告された流れ又はセッションの状態をチェックするために使用することができる。指定された流れがまだ有効（能動）である場合、MSSPActivityTestConfが返送される。流れＩＤによって識別される流れが有効でなかった場合、ＭＳＳＰ＿Ｅ＿ＩＮＶＡＬＩＤ＿ＦＬＯＷ＿ＩＤの故障コードを伴った確認としてM SSPFailureConf
メッセージが送信される。

MSSPActivityTestConf
説明：このメッセージは、以前のMSSPActivityTestReq メッセージの実行が成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

イベント報告機能
説明：このセクション内のメッセージによって、アプリケーションは初期検出点イベントの後に追加のイベント報告を要求することができる。制御ダイアログを開始するＩＤＰがトリガである時、そのアプリケーションは、通常、そのＩＤＰイベントに対するMSSPContinueReq 又はMSSPConnectReq応答内のイベント報告マスク及び／又はトリガ・マスク・フィールドを介して追加のイベント報告を普通に要求する。そのＩＤＰがトリガでない時（すなわち、パケット処理の中断なしでのイベント報告のみである時）、そのMSSPEventReportReq要求は、追加のイベント報告を要求する唯一の手段である。
必要な特権：ＥＤＰ。
メッセージのリスト：MSSPEventReportReq、MSSPEventReportConf 、MSSPEventReportEvent。

MSSPEventReportReq
説明：このメッセージは、イベント報告の検出点を着装するために使用することができる。その検出点は示された流れだけに対するイベント検出点として着装され、任意のイベント報告又はトリガ・マスク内で指定されている制御状態を流れが通過する場合に対してイベントが送信される。イベント報告要求が受信されると、ＭＳＳＰ２２はその検出点を着装し、その着装動作の成功を示す確認を送信する。要求された検出点を着装しようとしている間に故障が発生した場合、その故障の理由を示すMSSPFailureConf が返送される。

この要求の結果、その流れが指定された状態を遷移したことを示すために、MSSPEventReportEventメッセージが送信される。この要求は、それが単独の既存の流れに対するイベント報告を変えるために使用されるという意味で、MSSPArmIDPReq とは異なっている。一方、MSSPArmIDPReq 要求は流れが最初に監視される場所の開始点を確立する。

流れが終了した後に残っている全てのイベント報告検出点は、ＭＳＳＰ２２によって自動的に脱着装される。イベント報告検出点が既に着装されている流れに対するMSSPEventReportReqは、以前の要求にとって代わる効果を有する。その制御ダイアログのために以前に要求されたイベント報告及びトリガを全て取り消すために、イベント報告マスク又はトリガ・マスクの値がセットされていないMSSPEventReportReqを使用することができる。

MSSPEventReportConf
説明：このメッセージは、以前のMSSPEventReportReqメッセージの実行が成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

EventReportEvent
説明：このメッセージは、以前のMSSPActivityTestReq メッセージの実行が成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

サービス・フィルタ機能
説明：このセクション内のメッセージによって、アプリケーションはそのアプリケーションの関与を必要としない検出点においてプログラムされた行動を指定することができる。
所定のサービスの相互作用が実行されるべきかどうかを決定するために入力要求を突き合わせるためにソースＩＰアドレス、ソース・ポート、宛先ＩＰアドレス、及びＩＰプロトコル番号のフィールドが使用される。その突合せプロセスは一般に初期検出点に対して使用されるプロセスと同様であり、突き合わせるフィールド内でワイルド・カードを使用することができる。

流れが基準に一致した場合、そのメッセージの残りの部分で指定されている行動がアプリケーションの関与なしで実行される。指定することができる行動は、イベントの報告、及び指定の転送先アドレス及びポート番号に要求を転送することを含む。イベント報告が必要な場合、その流れに対して将来においてどのイベントが報告されるかを決定するためにイベント報告マスクが使用される。突き合わせる基準は着装された初期検出点の基準と重なってはいけない。その要求が何らかの理由のために完了できない時、突合せ要求ＩＤ及びその故障の性質を示すエラー・コードを伴ったMSSPFailureConf メッセージが返送される。その要求の完了に成功した場合には、MSSPActivateServiceFilterConf が返送される。サービス・フィルタリングはMSSPCancelServiceFilterReq要求によって取り消されるまで能動状態のままになっている。
必要な特権：サービス・フィルタ。
メッセージのリスト：MSSPActivateServiceFilterReq、MSSPActivateServiceFilterConf 、MSSPCancelServiceFilterReq、MSSPCancelServiceFilterConf 。

MSSPActivateServiceFilterReq
説明：この要求は、初期検出点を識別するため、及び適用される所定の行動を生じさせる必要があるトラヒック基準を指定するために使用される。

流れがサービス・フィルタを伴う初期検出点に達し、条件がそのサービス・フィルタの基準に一致した時、そのサービス・フィルタ内で所定の行動がそのパケットに適用され、パケット処理が指示されたように進行する。基準文字列は広範囲のトリガを指定するために使用することができるワイルド・カード文字を備えていてもよい。ＭＳＳＰ２２は、ＩＤＰがサービス・フィルタの着装に成功した後、MSSPActivateServiceFilterConf メッセージを送信する。エラー状態のためにそのＩＤＰの着装が妨げられた場合、その故障の理由を示すMSSPFailureConf メッセージが代わりに返送される。

MSSPActivateServiceFilterConf
説明：このメッセージは、以前のMSSPActivateServiceFilterReqメッセージによってサービス・フィルタ初期検出点の着装が成功したことを肯定応答するために、ＭＳＳＰ２２に
よって送信される。

MSSPCancelServiceFilterReq
説明：この要求は、MSSPActivateServiceFilterReq要求によって以前に確立されたサービス・フィルタを取り消すために使用される。

MSSPCancelServiceFilterConf
説明：このメッセージは、以前のMSSPCancelServiceFilterReqメッセージによるサービス・フィルタの取消しが成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

メータ構成機能
説明：このセクション内のメッセージによって、アプリケーションはＭＳＳＰ２２によって測定されるデータ要素を構成することができる。このメータ構成は、MSSPGetStatsConf及びMSSPPeriodicStatsEventメッセージ内に入っている測定要素、及びＭＳＳＰ２２のデータベース内に記憶している明細レコードに影響する。
必要な特権：メータ構成。
メッセージのリスト：MSSPConfigureMetersReq、MSSPConfigureMetersConf 。

MSSPConfigureMetersReq
説明：このメッセージは、ＭＳＳＰ２２によって最低レベルで実行される測定を構成するために使用される。メータ・クラス・フィールドは、２つの値、すなわち、ＭＳＳＰ＿ＭＥＴＥＲ＿ＣＬＡＳＳ＿ＳＥＳＳＩＯＮ又はＭＳＳＰ＿ＭＥＴＥＲ＿ＣＬＡＳＳ＿ＦＬＯＷのうちの１つを含む。このクラス・フィールドは測定要求の範囲を示すために使用される。オブジェクトＩＤフィールドは、メータ・クラスに基づいて測定されるオブジェクトの例を識別する。例えば、メータ・クラスがＭＳＳＰ＿ＭＥＴＥＲ＿ＣＬＡＳＳ＿ＳＥＳＳＩＯＮであった場合、そのオブジェクトＩＤはセッション識別子を表し、メータ・タイプがＭＳＳＰ＿ＭＥＴＥＲ＿ＣＬＡＳＳ＿ＦＬＯＷであった場合、オブジェクトＩＤは流れ識別子を表す。メータ使用可能フィールドは、メータ・クラス・フィールドによって指定されたクラス内で使用することを可能とさせる特定のメータを識別するビット・マスクを含む。

既にメータが構成されているオブジェクトに対してMSSPConfigureMetersReqが送信される時、メータ使用可能フィールドは、そのオブジェクトに対する新しいメータ構成を指定する。以前に構成されたメータのマスク位置における値がゼロの場合、そのメータを使用できないようにし、以前に構成されていないメータのマスク位置内の値がゼロでない場合、そのメータを使用できるようにする。メータの構成は、MSSPGetStatsConf及びMSSPPeriodicStatsEventメッセージ内に入れられている測定要素、及びＭＳＳＰ２２のデータベース内に記憶している明細レコードに影響する。

ＭＳＳＰ２２は、要求が成功した場合には、その要求を処理し、肯定応答としてMSSPConfigureMetersConf メッセージを返送する。要求が成功しなかった場合には、否定応答としてMSSPFailureConf メッセージが送信される。故障コードの値は、検証に失敗した要求パラメータに依存して次の値のうちの１つを含む。

MSSP_E_INVALID_METER_CLASS、
MSSP_E_INVALID_FLOW_ID、
MSSP_E_INVALID_SESSION_ID 、又は
MSSP_E_INVALID_FLOW_METER_MASK。

MSSPConfigureMetersConf
説明：このメッセージは、以前のM SSPConfigureMetersReqメッセージの実行が成功した
ことを肯定応答するために、ＭＳＳＰ２２によって送信される。

課金通知機能
説明：このセクション内のメッセージによって、アプリケーションはバイトをベースとする報告を要求することができる。報告はセッション又は流れのベースで要求することができる。セッションをベースとする課金通知によって、そのセッション内の全ての流れに対して同じ課金通知の基準が効果的に適用される。

課金通知イベントに対する登録によって、アップリンク及びダウンリンクの方向において転送される指定されたタイプのバイトの数が測定される。報告のしきい値に達する度に、転送されたバイトの数を示すMSSPNotifyChargeEvent メッセージが、ＭＳＳＰ２２からそのアプリケーションに送信され、カウンタがリセットされ、しきい値に向けて再びカウントがスタートする。課金通知はその流れが終了するか、又は課金通知がMSSPCancelNotifyChargeReq 要求によって明示的に取り消されるまで継続する。

パケットはカウントされる最小単位であり、各パケットはそのカウントが評価される前に又はカウントが評価された後で脱落する。その結果、課金通知は、指定のバイト・カウント上で正確に行われない場合がある。例えば、１０Ｋバイト毎に通知が要求された場合には、１０Ｋを超えるカウントを運んだパケットが、５００バイトより少し大きい場合には、通知が１０．５Ｋバイトのところで行われる場合がある。実際のカウンタの値は、MSSPNotifyChargeEvent メッセージ内で提供される。
必要な特権：課金通知。
メッセージのリスト：MSSPNotifyChargeReq 、MSSPNotifyChargeConf、MSSPCancelNotifyChargeReq 、MSSPCancelNotifyChargeConf、MSSPNotifyChargeEvent 。

MSSPNotifyChargeReq
説明：この要求はセッション全般又は流れ単位のいずれかでの報告に基づいてバイトを登録するために使用される。課金通知を使用可能にすることに成功したことを示すために、MSSPNotifyChargeConfメッセージが送信される。課金通知を使用可能にできなかった場合、故障を示すためにＳＴＬ＿ＦＡＩＬＵＲＥ＿ＣＯＮＦメッセージが送信され、エラー・コードのフィールドは、その故障の理由を識別する。

MSSPNotifyChargeConf
説明：このメッセージは、以前のMSSPNotifyChargeReq メッセージの実行が成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

MSSPCancelNotifyChargeReq
説明：この要求は以前のMSSPNotifyChargeReq 要求によって確立されたバイトをベースとする報告を取り消すために使用される。

MSSPCancelNotifyChargeConf
説明：このメッセージは、以前のMSSPCancelNotifyChargeReq メッセージの実行が成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

MSSPNotifyChargeEvent
説明：このメッセージは、以前に登録した課金通知のしきい値を超過したことをアプリケーションに通知するために使用される。

課金計画機能
説明：このセクション内のメッセージによって、アプリケーションは提供されるサービスのコストを示し、ＭＳＳＰ２２明細レコード内で使用される課金計画を記録することができる。
必要な特権：課金計画。
メッセージのリスト：MSSPSetChargePlanReq, MSSPSetChargePlanConf

MSSPSetChargePlanReq
説明：このメッセージは、ＭＳＳＰ２２明細レコード内のサービスに対して使用される課金計画を記録するために使用される。

MSSPSetChargePlanConf
説明：このメッセージは、以前のMSSPSetChargePlanReqメッセージの実行が成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

明細レコード制御機能
説明：このセクション内のメッセージによって、アプリケーションはＭＳＳＰ２２明細レコードが作成される時間を制御することができる。
必要な特権：明細レコード制御。
メッセージのリスト：MSSPWriteDetailRecordReq、MSSPWriteDetailRecordConf 。

MSSPWriteDetailRecordReq
説明：このメッセージによって、アプリケーションはＭＳＳＰ２２のデータベースに明細レコードが作成される時間を制御することができる。この要求により作成される明細レコードには、ＭＳＳＰ＿ＲＣ＿ＰＡＲＴＩＡＬ＿ＤＥＴＡＩＬの理由コードが自動的に割り当てられる。部分明細レコードは、通常、回復不能エラーが発生した場合に、加入者相互作用の最近のアクティビティ以外の全てが課金の目的のために捕捉されることを保証するために使用される。

MSSPWriteDetailRecordConf
説明：このメッセージは、以前のMSSPWriteDetailRecordReqメッセージの実行が成功したことを肯定応答するために、ＭＳＳＰ２２によって送信される。

統計機能
説明：このセクション内のメッセージによって、アプリケーションはそのアプリケーションによって管理されているセッション又は流れに対する種々の統計を取得することができる。
必要な特権：統計。
メッセージのリスト：MSSPGetStatsReq, MSSPGetStatsConf, MSSPPeriodicStatsEvent

MSSPGetStatsReq
説明：この要求はセッション又は流れの統計を要求するために使用される。統計の現在の値の他に、この要求はオプションとして将来の更新を、周期的に、又は流れ又はセッションの終了時のいずれかにおいて要求することができる。統計値は以前のMSSPConfigureMetersReq要求によって構成されたメータによって変わる。

ＭＳＳＰ２２は要求を処理し、その要求の完了に成功した場合には、現在の統計値を伴うMSSPGetStatsConfメッセージを肯定応答として返送する。さらに、間隔］フィールドを介して将来の更新が要求された場合には、MSSPPeriodicStatsEventメッセージが送信される。要求の完了に失敗した場合には、MSSPFailureConf メッセージが否定応答として送信される。その故障コードの値は、検証に失敗した要求パラメータにより次の値のうちの１つを含む。
MSSP_E_INVALID_STATS_TYPE 、
MSSP_E_INVALID_FLOW_ID、
MSSP_E_INVALID_SESSION_ID 、又は
MSSP_E_INVALID_INTERVAL 。

MSSPGetStatsConf
説明：この要求は以前のMSSPGetStatsReq 要求によって要求されたセッション又は流れの統計を返送するために使用される。統計の値は以前のMSSPConfigureMetersReq要求によって構成されたメータによって変わる。

MSSPPeriodicStatsEvent
説明：この要求は、以前のMSSPGetStatsReq 要求によって要求されたセッション又は流れの統計の周期的更新を返送するために使用される。統計の値は以前のMSSPConfigureMetersReq要求によって構成されたメータによって変わる。

アプリケーション監視機能
説明：このセクション内のメッセージによって、アプリケーションは同じＭＳＳＰ２２例に接続されている他のアプリケーションの状態を監視することができる。
必要な特権：アプリケーション監視。
メッセージのリスト：MSSPAppSessionEvent 。
MSSPAppSessionEvent
説明：このメッセージは、１つのアプリケーション・セッション・イベントの発生を報告するために、ＭＳＳＰ２２によって送信される。また、このメッセージは、そのセッションがオープンされた直後に、アプリケーション監視特権を備えているアプリケーションにＭＳＳＰ２２によって送信され、他の（あらかじめ存在している）アプリケーション・セッションについて知らせる。

ネットワークを示すブロック図。傍受プロセスを示すフローチャート。図２のサービス・アプリケーション始動段階を示すフローチャート。図２のサービス初期化段階を示すフローチャート。図２のサービス展開段階を示すフローチャート。図２のサービス・ロジック段階を示すフローチャート。図２のシャットダウン段階を示すフローチャート。図１のＡＰＩが使用するデータ・タイプを示す表。通信路を示すブロック図。トランスポート層によりセッション・メッセージに分割されたＴＣＰ／ＩＰバイト・ストリームを示すブロック図。サンプル・エラー・コードを示す表。サンプル機能分類を示す表。

Claims

ネットワークにおいて、アプリケーション・プログラム・インタフェース（ＡＰＩ）内のアプリケーション・プログラムからメッセージを受信するステップと、
前記メッセージを前記ＡＰＩからモバイル・サービス・スイッチング・プラットフォーム（ＭＳＳＰ）内の制御プロセスに送信するステップとを備える方法。
前記ネットワークは無線ネットワークである請求項１に記載の方法。
前記無線ネットワークは第二世代無線ネットワークである請求項２に記載の方法。
前記無線ネットワークはＧＳＭネットワークである請求項２に記載の方法。
前記無線ネットワークはＧＰＲＳ使用可能ＧＳＭネットワークである請求項２に記載の方法。
前記無線ネットワークはＴＤＭＡネットワークである請求項２に記載の方法。
前記無線ネットワークはＣＤＭＡネットワークである請求項２に記載の方法。
前記無線ネットワークはＵＭＴＳネットワークである請求項２に記載の方法。
前記無線ネットワークはＴＥＴＲＡネットワークである請求項２に記載の方法。
前記無線ネットワークはＴｅｔｒａｐｏｌネットワークである請求項２に記載の方法。
前記無線ネットワークはＤＥＣＴネットワークである請求項２に記載の方法。
前記無線ネットワークはＡＭＰＳネットワークである請求項２に記載の方法。
前記無線ネットワークはＷＬＡＮネットワークである請求項２に記載の方法。
前記無線ネットワークは第三世代無線ネットワークである請求項２に記載の方法。
前記ＡＰＩは、前記アプリケーション・プログラムが前記ＭＳＳＰ内で切替及び経路指定機能を制御することを可能とさせるプロトコルを提供する請求項１に記載の方法。
前記ＡＰＩは、前記アプリケーション・プログラムが前記ＭＳＳＰを通るパケットの流れの方向を流れをベースとして変えることを可能とさせるプロトコルを提供する請求項１に記載の方法。
前記ＡＰＩは、前記アプリケーション・プログラムが前記ＭＳＳＰ内でのポリシー決定を制御することを可能とさせるプロトコルを提供する請求項１載の方法。
前記ＡＰＩは、前記アプリケーション・プログラムが前記制御プロセス内にて初期検出点（ＩＤＰ）及びサービス関連ＩＤＰイベントを着装することを可能とさせるプロトコルを提供する請求項１に記載の方法。
前記ＡＰＩは、前記アプリケーション・プログラムが前記制御プロセス内にてＩＤＰ及びサービス関連ＩＤＰイベントを脱着装することを可能とさせるプロトコルを提供する請
求項１に記載の方法。
前記ＡＰＩは、前記アプリケーション・プログラムがイベント報告を要求することを可能とさせるプロトコルを提供する請求項１に記載の方法。
前記ＡＰＩは、プログラムされた行動を前記制御プロセス内の検出点の箇所で指定することを前記アプリケーション・プログラムが可能とさせるプロトコルを提供する、請求項１に記載の方法。
前記ＡＰＩは、前記ＭＳＳＰの制御プロセスによって測定されたデータ要素を前記アプリケーション・プログラムが構成することを可能とさせるプロトコルを提供する、請求項１に記載の方法。
前記ＡＰＩは、前記アプリケーション・プログラムがバイトをベースとする報告を要求することを可能とさせるプロトコルを提供する、請求項１に記載の方法。
前記報告はセッションをベースとする報告である請求項２３に記載の方法。
前記報告はサービス相互作用をベースとする報告である請求項２３に記載の方法。
前記報告は流れをベースとする報告である請求項２３に記載の方法。
前記ＡＰＩは、前記アプリケーション・プログラムが提供されたサービスのコストを指定することを可能とさせるプロトコルを提供する請求項１に記載の方法。
前記プロトコルは、明細レコードにて使用される課金計画を前記アプリケーション・プログラムが記録することを可能とさせる請求項２７に記載の方法。
前記プロトコルは、前記アプリケーション・プログラムが前記明細レコードを書く時間を制御することを可能とさせる請求項２８に記載の方法。
前記ＡＰＩは、前記アプリケーション・プログラムが前記アプリケーション・プログラムによって管理されているセッションの統計を入手することを可能とさせるプロトコルを提供する請求項１に記載の方法。
前記ＡＰＩは、前記アプリケーション・プログラムが前記アプリケーション・プログラムによって管理されている流れの統計を入手することを可能とさせるプロトコルを提供する請求項１に記載の方法。
前記ＡＰＩは、前記アプリケーション・プログラムが前記ＭＳＳＰの制御プロセスに接続している他のアプリケーションの状態を監視することを可能とさせるプロトコルを提供する請求項１に記載の方法。
伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）ネットワーク・サービスを使用することによって、外部アプリケーション・プロセスとモバイル・サービス・スイッチング・プラットフォーム（ＭＳＳＰ）内に常駐している制御プロセスとの間でメッセージの交換を行うことを可能とさせる一組のアプリケーション層プロトコルを備える、アプリケーション・プログラム・インタフェース（ＡＰＩ）。
前記一組は、前記アプリケーション・プロセスが前記ＭＳＳＰ内で切替及び経路指定を
制御することを可能とさせるプロトコルを含む、請求項３３に記載の方法。
前記一組は、前記アプリケーション・プロセスが流れをベースとして前記ＭＳＳＰを通るパケットの流れの方向を変えることを可能とさせるプロトコルを備える請求項３３に記載の方法。
前記一組は、前記アプリケーション・プログラムが前記ＭＳＳＰ内のポリシー決定を制御することを可能とさせるプロトコルを備える請求項３３に記載の方法。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスが前記制御プロセス内にて初期検出点（ＩＤＰ）及びサービス関連ＩＤＰを着装することを可能とさせるプロトコルを備える請求項３３に記載のＡＰＩ。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスが前記制御プロセス内にて初期検出点（ＩＤＰ）及びサービス関連ＩＤＰを脱着装することを可能とさせるプロトコルを備える請求項３３に記載のＡＰＩ。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスが前記制御プロセスからイベント報告を要求することを可能とさせるプロトコルを備える請求項３３に記載のＡＰＩ。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスがプログラムされた行動を前記制御プロセス内の検出点で指定することを可能とさせるプロトコルを備える請求項３３に記載のＡＰＩ。
前記一組のアプリケーション層プロトコルは、前記制御プロセスによって測定されたデータ要素を前記アプリケーション・プロセスが構成することを可能とさせるプロトコルを備える請求項３３に記載のＡＰＩ。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスが前記制御プロセス中にバイトをベースとする報告を要求することを可能とさせるプロトコルを備える請求項３３に記載のＡＰＩ。
前記報告はセッションをベースとする報告である請求項４２に記載のＡＰＩ。
前記報告はサービス相互作用をベースとする報告である請求項４２に記載のＡＰＩ。
前記報告は流れをベースとする報告である請求項４２に記載のＡＰＩ。
前記一組のアプリケーション層プロトコルは、前記ＭＳＳＰによって提供されたサービスのコストを前記アプリケーション・プロセスが指定することを可能とさせるプロトコルを備える請求項３３に記載のＡＰＩ。
前記一組のアプリケーション層プロトコルは、前記ＭＳＳＰ内に記憶されている明細レコードで使用される課金計画を前記アプリケーション・プロセスが記録することを可能とさせるプロトコルを備える請求項３３に記載のＡＰＩ。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスが前記明細レコードを書く時間を制御することを可能とさせるプロトコルを備える請求項３３に記載のＡＰＩ。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスによって管理されているセッションの統計を前記アプリケーション・プロセスが入手することを可能とさせるプロトコルを備える請求項３３に記載のＡＰＩ。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プログラムによって管理されている流れの統計を前記アプリケーション・プロセスが入手することを可能とさせるプロトコルを備える請求項３３に記載のＡＰＩ。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスが前記制御プロセスに接続している他のアプリケーション・プロセスの状態を監視することを可能とさせるプロトコルを備える請求項３３に記載のＡＰＩ。
モバイル・サービス・スイッチング・プラットフォーム（ＭＳＳＰ）内の制御プロセスにリンクされたゲートウェイ汎用パケット無線サービス・サポート・ノード（ＧＧＳＮ）と、
前記制御プロセスにリンクされ、グローバルに接続しているコンピュータのグループと、
前記制御プロセスに接続されたアプリケーション・プログラム・インタフェース（ＡＰＩ）と、
前記ＡＰＩにリンクされたアプリケーション・プロセスを実行するアプリケーション・システムとを備えるシステム。
前記ＧＧＳＮにリンクされた汎用パケット無線サービス・サポート・ノードをさらに備える請求項５２に記載のシステム。
前記汎用パケット無線サービス・サポート・ノードにリンクされた基地局コントローラ（ＢＳＣ）をさらに備える請求項５３に記載のシステム。
前記ＢＳＣにリンクされた基地トランシーバ局（ＢＴＳ）を備える請求項５４に記載のシステム。
前記ＢＴＳにリンクされた移動局（ＭＳ）をさらに備える請求項５５に記載のシステム。
前記ＡＰＩは、前記アプリケーション・プロセスと前記制御プロセスとの間でメッセージを交換することができる一組のアプリケーション層プロトコルを備える請求項５２に記載のシステム。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスが前記制御プロセス内にて初期検出点（ＩＤＰ）及びサービス関連ＩＤＰイベントを着装することを可能とさせるプロトコルを備える請求項５７に記載のシステム。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスが前記制御プロセス内にて初期検出点（ＩＤＰ）及びサービス関連ＩＤＰイベントを脱着装することを可能とさせるプロトコルを備える請求項５７に記載のシステム。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスが前記制御プロセスからイベント報告を要求することを可能とさせるプロトコルを備える請求項５７に記載のシステム。
前記一組のアプリケーション層プロトコルは、プログラムされた行動を前記アプリケーション・プロセスが前記制御プロセス内の検出点で指定することを可能とさせるプロトコルを備える請求項５７に記載のシステム。
前記一組のアプリケーション層プロトコルは、前記制御プロセスによって測定されたデータ要素を前記アプリケーション・プロセスが構成することを可能とさせるプロトコルを備える請求項５７に記載のシステム。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスが前記制御プロセス内にてバイトをベースとする報告を要求することを可能とさせるプロトコルを備える請求項５７に記載のシステム。
前記報告はセッションをベースとする報告である請求項６３に記載のシステム。
前記報告は流れをベースとする報告である請求項６３に記載のシステム。
前記報告はサービス相互作用をベースとする報告である請求項６３に記載のシステム。
前記一組のアプリケーション層プロトコルは、前記ＭＳＳＰによって提供されたサービスのコストを前記アプリケーション・プロセスが指定することを可能とさせるプロトコルを備える請求項５７に記載のシステム。
前記一組のアプリケーション層プロトコルは、前記ＭＳＳＰ内に記憶されている明細レコードによって使用される課金計画を、前記アプリケーション・プロセスが記録することを可能とさせるプロトコルを備える請求項５７に記載のシステム。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスが前記明細レコードを書く時間を制御することを可能とさせるプロトコルを備える請求項６８に記載のシステム。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスによって管理されているセッションの統計を前記アプリケーション・プロセスが入手することを可能とさせるプロトコルを備える請求項５７に記載のシステム。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスによって管理されている流れの統計を前記アプリケーション・プロセスが入手することを可能とさせるプロトコルを備える請求項５７に記載のシステム。
前記一組のアプリケーション層プロトコルは、前記アプリケーション・プロセスが前記制御プロセスに接続されている他のアプリケーションの状態を監視することを可能とさせるプロトコルを備える請求項５７に記載のシステム。
前記メッセージはインターネット・プロトコル（ＩＰ）を備える請求項１に記載の方法。
前記メッセージは伝送制御プロトコル（ＴＣＰ）を備える請求項１に記載の方法。
前記メッセージはユーザ・データ・データグラム・プロトコル（ＵＤＰ）を備える請求項１に記載の方法。
前記メッセージはハイパーテキスト転送プロトコル（ＨＴＰ）を備える請求項１に記載の方法。
前記メッセージはシンプル・メール転送プロトコル（ＳＭＴＰ）を備える請求項１に記載の方法。
前記メッセージはインターネット・メッセージ・アクセス・プロトコル（ＩＭＡＰ）を備える請求項１に記載の方法。
前記メッセージはポストオフィスプロトコル（ＰＯＰ）を備える請求項１に記載の方法。
前記メッセージはファイル転送プロトコル（ＦＴＰ）を備える請求項１に記載の方法。
前記メッセージはリアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）を備える請求項１に記載の方法。
前記メッセージはリアルタイム転送プロトコル（ＲＴＰ）を備える請求項１に記載の方法。
前記メッセージはセッション開始プロトコル（ＳＩＰ）を備える請求項１に記載の方法。
前記メッセージはＨ．３２３プロトコルを備える請求項１に記載の方法。
前記メッセージは媒体ゲートウェイ制御プロトコル（ＭＧＣＰ）を備える請求項１に記載の方法。
前記メッセージは直径ベース・プロトコルを備える請求項１に記載の方法。