JP2006508609A - より正確な加入者装置課金を行うための方法およびデバイス - Google Patents

Abstract

加入者装置１２の課金できないアクティビティと課金できるアクティビティとを区別するための使用量記録エージェント（１９）を含むＰＤＳＮ（１８）。使用量記録エージェント（１９）は、ＰＤＳＮ（１８）からＲＡＮ（１４）に送信したバイトの全数の記録を生成し、再送信された全バイトを供給するためにＰＤＳＮ（１８）から再送信するバイトをカウントし、記録を再送信した全バイトにより調整できるように、再送信した全バイトおよび記録をＡＡＡ（２８）に転送する。

Description

本発明は、概して、無線通信システムに関し、特に、より正確な加入者装置課金情報を提供するための方法およびデバイスに関する。

符号分割多元接続（ＣＤＭＡ）システムのような加入者装置にサービスを提供する通信システムは、多くの場合、消費したまたは使用したサービスの量に基づいてこのようなサービスに対して課金を行っている。それ故、このようなシステムは、多くの場合、課金目的のために各加入者装置に対応する使用量データを収集する。パケット・データ・サービング・ノード（ＰＤＳＮ）のようなシステム要素は、通常、各加入者装置へ／から送信したバイト数のような使用量データを収集し、これらのバイトに対応する使用量データ記録（ＵＤＲ）を生成する。しかし、多くの場合、これらのバイトのすべてが、加入者装置による「使用量」を表しているわけではない。例えば、システムのオーバヘッド・アクティビティにより送信されるバイトは、当然ＵＲＤに含めるべきではない。オーバヘッドの例としては、加入者装置の移動および無線周波数伝送誤りによるトラヒック等がある。これらの例および他の例の両方とも、オーバヘッド、すなわち、加入者装置による使用量を表していない加入者装置へ／から送信したバイト数を増大する恐れがある。より正確な課金情報を提供するための方法およびデバイスの開発が待望されていることは明らかである。

類似の参照番号が同一または機能的に類似の要素を表している添付の図面は、下記の詳細な説明と一緒に本明細書に添付してあり、本明細書の一部を形成する。この図面は、種々の実施形態をさらに詳細に説明するためのものであり、本発明の種々の原理および本発明によるすべての利点を説明するためのものである。

全体的にいうと、本発明は、加入者装置に対する呼詳細記録、課金記録または使用量データ記録（ＵＤＲ）のような課金記録を提供する通信システムに関する。説明を簡単にするために、これら課金記録全体をＵＤＲと呼ぶことにする。本明細書においては、加入者装置またはユニットは、無線装置、移動局またはユニットと同じ意味を有し、これら各用語は、通常ユーザに関連するデバイス、および通常サービス協定による公衆網、または専用網で使用することができる無線装置を意味することに留意されたい。

以下にさらに詳細に説明するように、本発明の種々の原理およびその組合わせは、より正確なＵＤＲを提供するために、すなわち加入者装置により正確な課金を行うために有利に使用される。

本明細書は、実行可能な方法で、本発明による種々の実施形態を製造および使用する最善の形態をさらに詳細に説明するためのものである。本明細書は、さらに本発明の原理、その利点の理解および認識を深めるためのものであり、いかなる意味でも本発明を制限するものではない。本発明は、本願の出願中に行ったすべての補正を含む添付の特許請求の範囲および発行したこれら特許請求の範囲のすべての等価物によってだけ定義される。

第１および第２、頂部および底部等のような関連を表す用語が使用されている場合には、あるエンティティまたは行動を他のエンティティまたは行動から区別するためだけに使用しているのであって、このようなエンティティまたは行動間のこのような実際の関係または順序は必ずしもそうである必要もないし、そのような関係または順序を意味するものでもないことを理解されたい。本発明の機能の多くおよび本発明の原理の多くは、ソフト
ウェア・プログラムまたは命令によりまたはその内部で最もよく実施することができる。本明細書に開示したコンセプトおよび原理の助けを借りれば、通常の当業者であれば、例えば、利用可能時間、現在の技術および経済的考慮によりある程度努力しなければならないし、多くの設計上の選択をしなければならないかもしれないが、最小限度の実験でこのようなソフトウェア命令およびプログラムを容易に生成することができるものと考える。それ故、本発明による原理およびコンセプトを簡潔に説明し、できるだけ分かりやすくするために、このようなソフトウェアについてのこれ以上の説明は、好ましい実施形態が使用する原理およびコンセプトの本質的なものに限定することとする。

図１を参照しながら、その内部で動作している１つまたは複数の加入者装置に対してより正確な課金を行うための簡単で、代表的な通信システム１０について説明し、記述する。１つまたは複数の加入者装置１２は、周知の無線アクセス・ネットワーク（ＲＡＮ）１４へ／から無線リンクを通してデータのようなトラヒックを送受信するように配置され、構成されている。ＲＡＮ１４は、周知のパケット・データ・サービング・ノード（ＰＤＳＮ）１８と結合している。ＲＡＮ１４は、ＰＤＳＮ１８に対してインタフェースとして機能するパケット制御機能（ＰＣＦ）１６を含む。ＰＣＦ１６は周知のもので、当業者であれば理解できるものである。ＰＤＳＮ１８は、同様に周知の使用量記録エージェント１９（以下に説明する）を含み、インターネット２０へのネットワーク接続を有する。システム１０も、ブローカ認証、許可および課金サーバ（ブローカ）２２およびホーム・ネットワーク２４を含む。ホーム・ネットワーク２４は、例えば、加入者装置のユーザのインターネット・サービス・プロバイダであってもよく、ＰＤＳＮ１８から受信したＵＤＲに基づいて加入者装置請求書を生成する。ホーム・ネットワーク２４は、加入者装置１２へ／からインターネット・トラヒックを経路指定し、トンネリングするためのホーム・エージェント２６、およびセキュリティおよび加入者装置１２との課金上の関係を維持するためのホーム認証、許可および課金サーバ（ＡＡＡ）２８を含む。ブローカ２２は、例えば、加入者装置のユーザの電話サービス・プロバイダであってもよく、加入者装置のユーザが、ホーム・ネットワークおよびすべての共有リソースにアクセスすることができるようにするために、ログイン手順（許可および確認）を提供する。また、ブローカ２２は、認証および課金メッセージを転送するために、ＡＡＡ２８とセキュリティ関係を持つ。

ＰＤＳＮ１８のところの使用量記録エージェント１９は、例えば、ＰＤＳＮ１８上にロードされた関連命令を含むソフトウェア・プログラム、またはその上に設けられている追加のハードウェア構成要素（図示せず）であってもよい。図では使用量記録エージェント１９はＰＤＳＮ１８の一部となっているが、このエージェントは、独立していて識別できるエンティティであってもよい。いかなる場合でも、使用量記録エージェント１９が設置され、ＰＤＳＮ１８のところで実行されるか、ＰＤＳＮ１８と一緒に実行される場合はいつでも、ＰＤＳＮ１８は、ある時間の間に所定の課金できないアクティビティが行われたか否かを判断し、課金できないアクティビティに対応する記録を生成し、この記録をブローカ２２を介してＡＡＡ２８のような課金ノードに転送する。そのため、全バイトを記録に従って調整することができる。別の方法としては、ＰＤＳＮ１８は、自分自身で、記録に従って全バイトを調整することができる。以下にさらに詳細に説明するように、所定の課金できない行動としては、ＰＤＳＮによるバイトの再送信、信号データの送信または加入者装置がデータの到着通知に応答しない間のデータの送信等がある。この記録は、加入者装置１２が使用できないバイトのカウントを含む。図２〜図６を参照しながら、使用量記録エージェント１９の結果としてのＰＤＳＮ１８の動作をより詳細に説明する。

図２を参照しながら、第１の実施形態のフローチャートについて説明する。一般的に、第１の実施形態は、加入者装置１２に対して送信制御プロトコル・インターネット・プロトコル（ＴＣＰ／ＩＰ）パケットが再送信された状況に対してより正確な課金を行う。方法２００は、１つまたは複数のパケットが加入者装置に再送信される再送信アクティビテ
ィを適用する状況を示す。方法２００は、ステップ２０２からスタートし、この場合ＰＤＳＮ１８は、例えば、インターネット２０からパケットを受信する。当業者であれば、パケットは複数のバイトを含んでいることを理解されたい。ステップ２０４において、ＰＤＳＮ１８は、加入者に送信するパケットが、加入者装置に再送信する第１のパケットであるか否かを検出する。例えば、ステップ２０４において、加入者装置１２がＰＰＰ（ポイント・ツー・ポイント）フレームを正しく復号できないことを判断することができる。加入者装置１２は、例えば、信号の歪みまたは例えばチャネルによる過度の誤りの他の原因のために、フレームを復号できない場合がある。この判断は、例えば、加入者装置１２からの二重ＴＣＰ肯定応答（ｄｕｐｌｉｃａｔｅ ＴＣＰ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）の受信、またはインターネット２０からの再送信されたＴＣＰパケットの受信を監視することにより行うことができる。この判断は、一般的に再送信検出と呼ばれる。

ステップ２０４において、ＰＤＳＮ１８が再送信のための第１のパケットを検出した場合には、ステップ２０６において、ＰＤＳＮ１８は再送信したバイト・カウンタを起動し、次にステップ２０８において、加入者装置に再送信するバイトをカウントし、ステップ２１０において再送信バイト・カウンタを更新する。ステップ２１２において、ＰＤＳＮ１８は、ＴＣＰパケットをＰＰＰフレーム内に置き、ステップ２２２においてＰＰＰフレームに対するチェックサムが計算される。ステップ２２４において、ＰＤＳＮ１８は、ＰＰＰフレームをＲＡＮを介して加入者に送信する。ヘッダ圧縮に関して加入者装置１２をＰＤＳＮ１８に再度同期させるために、圧縮していないパケットが再送信される。ステップ２２６において、再送信した全バイトによりＵＤＲが調整され、次に、プロセスは終了する。

ステップ２０４において、パケットが再送信した第１のパケットでないと判断した場合には、ステップ２１４において、ＰＤＳＮ１８は、加入者装置に送信するバイトをカウントする。ステップ２１６において、ＰＤＳＮ１８は、再送信バイト・カウンタを更新する。ステップ２１８において、ＰＤＳＮ１８は、パケットからＴＣＰヘッダを除去し、ステップ２２０において、ＰＤＳＮ１８は、好適には、ＶＪヘッダ圧縮と呼ばれる圧縮アルゴリズムによりＴＣＰ／ＩＰを圧縮し、パケットをＰＰＰフレーム内に置く。ステップ２２２において、ＰＤＳＮ１８によりＰＰＰフレームに対するチェックサムが計算される。ステップ２２４において、ＰＤＳＮ１８は、ＰＰＰフレームをＲＡＮを介して加入者に送る。ステップ２２６において、再送信した全バイトによりＵＤＲが調整され、次に、プロセスは終了する。

その結果、カウンタは、再送信した全バイトを供給するために、圧縮しなかったおよび圧縮した再送信バイトの全数をカウントする。ＰＤＳＮ１８は、元の送信バイトから再送信バイトを区別することができる。何故なら、再送信バイトは、パケット・ソースから送信されたバイトの一連番号を含むヘッダを有しているからである。一連番号が増大しない場合、または一連番号が減少する場合には、ＰＤＳＮ１８は、これらのバイトを再送信バイトとして認識することができる。もちろん、追加のアクティビティに対してこのプロセスは反復して行われる。使用量記録エージェント１９は、例えば、加入者装置１２に送信した（フレーム内の）バイトの全数の記録から再送信した全バイトを差し引くことにより、または単に再送信した全バイトおよびバイトの全数の記録をブローカ２２に転送することによりこれを行うことができる。次に、ブローカ２２は、ホーム・ネットワーク２４のところでＡＡＡ２８にこの情報を転送することができるので、再送信した全バイトにより記録を調整することができる。いかなる場合も、最終的には、より正確なＵＤＲが提供される。

図３を参照しながら、第２の実施形態のフローチャートについて説明する。一般的に、第２の実施形態は、ＰＤＳＮ１８がＰＣＦから受信し、ＵＤＲの通信時間の分数を含む役
割に移る状況に対してより正確な課金を行う方法３００を提供する。しかし、ＰＤＳＮ１８のオペレータは、移動を厳密に維持するために使用する通信時間の分数に対して加入者装置のユーザに課金したがらない。また、加入者装置のユーザが、データ・セッションに対して通信時間に基づいて課金されている場合には、ＲＡＮ１４が、ユーザ情報を送受信するための専用の無線周波通信経路を設定しなければならない多くの例がある。加入者装置のユーザに対してトラヒック・チャネルと呼ばれるこの通信経路は、ユーザ・データを全然転送しなくても設定することができる。このようなトラヒック・チャネルを通して転送したユーザ・データのどれも信号データとは呼ばれない。信号データがトラヒック・チャネルを通して転送される状況の例としては、例えば、ＰＰＰ始動およびハンドシェイク、移動ＩＰ登録を含むがこれに限定されない加入者装置ＩＰ登録、データの送受信が行われないパケット間制御機能ハンドオフ、および送受信されたリンク制御プロトコル・エコーまたは応答等がある。

方法３００は、ステップ３０２からスタートする。この場合、ＰＤＳＮ１８は、ＲＡＮ１４のＰＣＦ１６から通信時間記録を受信する。当業者であれば、通信時間記録は、加入者装置１２がトラヒック・チャネル上に位置している通信時間中のデータ・アクティビティの記録であることを理解されたい。ステップ３０４において、ＰＤＳＮ１８は、ベアラ・データが通信時間記録の通信時間中に送信されたか否かを判断する。この判断は、信号データだけが、通信時間記録中に送受信されたか否かを判断するために、トラヒック・チャネルを通して送信したデータのプロトコル識別を監視することにより行うことができる。ステップ３０４において、通信時間記録中に信号データだけが送信されたと判断した場合には、ステップ３０６において、ＰＤＳＮ１８はＡＡＡ２８に通信時間記録を転送しない。

ステップ３０４において、通信時間記録中にベアラ・データが送信されたと判断した場合には、ステップ３０８において、ＰＤＳＮ１８はＡＡＡ２８に通信時間記録を転送する。その結果、信号データは、全通信時間中に全データ・アクティビティの全記録を歪ませることがなくなる。

ＰＣＦ１６は、ＰＤＳＮ１８に通信時間記録を送信することができない。ＰＣＦ１６は、例えば、エアリンク・スタートおよびストップ記録だけを送信することができる。このような場合には、ＰＤＳＮ１８は、通信時間記録を計算しなければならない。図４の方法４００のステップ４０２がこのことを示す。通信時間記録の計算を除いて、ステップ４０４、４０６および４０８を含む方法４００は、図３の方法３００に類似している。

図５を参照しながら、第３の実施形態のフローチャートについて説明する。通常、第３の実施形態は、加入者装置１２が休止状態（ｄｏｒｍａｎｔ ｓｔａｔｅ）にあり，ＲＡＮ１４からのデータ到着通知に応答しない状態に対して、より正確な課金を行うための方法５００を提供する。データ到着通知は、例えば、ＲＡＮ１４が加入者装置１２に送信するデータ転送ページまたはショート・メッセージであってもよい。加入者装置１２は、トラヒック・チャネルが割り当てられたが、エアリソースを全然使用していない場合には、データ転送の点で休止状態でいることができる。例えば、加入者装置１２がウェブ・ページをダウンロードした後で、加入者装置１２は、ユーザがウェブ・ページを読んでいる間に休止状態に入ることができる。

方法５００はステップ５０２からスタートする。この場合、データはＰＤＳＮ１８に到着し、その後で、ＰＤＳＮ１８はデータをＲＡＮ１４に転送する。ＰＤＳＮ１８は、ＲＡＮ１４に転送したデータ内のバイト数に対応するバイト・カウントを増分する。このことは使用量記録エージェント１９により行われる。ステップ５０４において、ＲＡＮ１４は、データを受信し、データ到着通知を加入者装置１２に送信する。ステップ５０６におい
て、ＰＤＳＮ１８は、加入者装置１２がデータ到着通知に応答したか否かを判断する。この判断は、例えば、ＲＡＮ１４が加入者装置１２とのトラヒック・チャネルの設定に成功したか否かを判断することにより行うことができる。ＰＣＦ１６は、ＲＡＮ１４がトラヒック・チャネルの設定に成功し、トラヒック・チャネル上で加入者装置１２を入手した場合にだけ、ＰＤＳＮ１８にエアリンク・スタート・メッセージのような能動スタート表示を送信する。ステップ５０６において、加入者装置１２がデータ到着通知に応答しなかったと判断された場合には、ステップ５０８において、ＰＤＳＮ１８の使用量記録エージェント１９は、バイト・カウントをユーザのＵＤＲに加算しない。

ステップ５０６において、加入者装置１２がデータ到着通知に応答したと判断された場合には、ステップ５１０において、ＰＤＳＮ１８の使用量記録エージェント１９は、ユーザのＵＤＲにバイト・カウントを加算する。

図６を参照しながら、本発明の第４の実施形態のフローチャートについて説明する。一般的に、第４の実施形態は、ＰＤＳＮ１８が加入者装置１２にパケットを再送信した状況により正確な課金を行うための方法６００を提供する。図２に戻って説明すると、方法２００は、ＰＤＳＮ１８が、ＶＪヘッダ圧縮中に、ＴＣＰ／ＩＰパケットを加入者装置１２に再送信した状況に適用された。しかし、ユーザ・データグラム・プロトコルのような他のプロトコルは接続を持たないし、プロトコルの一部として再送信を含まない。それ故、再送信は、アプリケーション層のようなもっと高い層で行われる。これらの再送信も、より正確な課金を行うためにカウントしなければならない。方法２００の場合には、カウントは、圧縮していないフレームを再送信した後で、再送信したＴＣＰパケットをカウントすることにより行った。しかし、もっと高い層での再送信を判断する技術は異なる技術であってもよい。それ故、ＰＤＳＮ１８は、もっと高い層のプロトコルを識別できなければならないし、再送信したバイトをカウントできなければならない。この識別およびカウントは、アプリケーション層ヘッダ情報を認識することにより行うことができ、アプリケーション層ヘッダからの再送信を検出することができる。この認識および検出は、パケットの一連番号のマイナス方向への増大を探索するために、プロトコル・ヘッダ内に設置する外部スニファ（ｅｘｔｅｒｎａｌ ｓｎｉｆｆｅｒ）により、またパケットのバイトの長さを再送信したバイトと見なすことにより行うことができる。外部スニファは、例えば、Ｓｎｉｆｆｅｒ（登録商標）Ｐｒｏ製のＳｎｉｆｆｅｒ（登録商標）ＤｉｓｔｒｉｂｕｔｅｄまたはＳｎｉｆｆｅｒ（登録商標）Ｐｏｒｔａｂｌｅであってもよい。スニファは、またＥｔｈｅｒｅａｌ（登録商標）製のスニファであってもよい。次に、注目したバイトの長さをＡＡＡ２８に転送することができ、そのためＵＤＲを再送信した全バイトにより調整することができる。

方法６００はステップ６０２からスタートする。この場合、ＰＤＳＮ１８は、Ｎ個のパケットを加入者装置１２に送る。ステップ６０４において、ＰＤＳＮ１８は、Ｎ個のパケットからバイトをカウントし、それをバイト・カウントに加算する。ステップ６０６において、ＰＤＳＮ１８は、起こり得る伝送誤りまたは受信誤りにより加入者装置に再送信したＮ個のパケットの一部（Ｍ）を検出する。ステップ６０８において、ＰＤＳＮ１８は、再送信したＭ個のパケットのプロトコル・ヘッダ内に入れられ、これらのＭ個のパケットを再送信として認識する。ＰＤＳＮ１８は、再送信したＭ個のバイトの記録を生成し、この記録をＡＡＡ２８に転送する。ＡＡＡ２８は、再送信したＭ個のバイトの記録に従ってバイト・カウントを調整する。そのため、再送信したＭ個のバイトはＵＤＲ内でカウントされない。別の方法としては、ＰＤＳＮ１８は、ＡＡＡ２８のところで調整を行うのではなくて、全部のＮ個のバイトからＭ個の再送信したバイトを差し引くことができる。

ＵＤＲは、第三世代パートナーシップ・プロジェクト２（３ＧＰＰ２）仕様に適合するシステムで実施することができる。このような場合、再送信したＭ個のバイトは、追加の
３ＧＰＰ２属性（パラメータ）としてＡＡＡ２８に転送することができる。そのため、再送信したＭ個のバイトにより課金を調整することができる。

それ故、本発明は、課金できる行動からオーバヘッド関連行動を区別し、それにより、より正確な加入者装置課金を行う方法およびデバイスを提供する。通常の当業者であれば、上記の原理、コンセプトおよび例を読めば、上記説明の範囲内で他の別の手順を実施することができるだろう。

本明細書は、本発明による種々の実施形態の構成方法および使用方法を説明するためのもので、本発明の真の意図するおよび公平の範囲および精神を制限するものではない。上記説明は、全部を網羅するためのものでもなければ、本発明を開示の正確な形態に制限するためのものでもない。上記説明を読めば、種々の修正および変更を行うことができる。上記実施形態は、本発明の原理およびその実際の適用を最も分かり易く説明するために、また通常の当業者が、本発明を種々の実施形態において、また目的の特定の使用に適する種々の修正と一緒に使用することができるように選択し、記述した。公正に、合法的におよび公平に見て適用可能な考えの範囲に従って解釈した場合に、このようなすべての修正および変更は、本願の出願中に補正することができる添付の特許請求の範囲およびそのすべての等価物に記載した本発明の範囲内に含まれる。

加入者装置に対して、より正確な課金を行うための通信システムの略図。 加入者装置に対して、より正確な課金を行うための第１の実施形態のフローチャート。 加入者装置に対して、より正確な課金を行うための第２の実施形態のフローチャート。 ＰＣＦが通信時間記録を送らなかった場合の第２の実施形態のフローチャート。 加入者装置に対して、より正確な課金を行うための第３の実施形態のフローチャート。 加入者装置に対して、より正確な課金を行うための第４の実施形態のフローチャート。

Claims (16)

1. 加入者装置のアクティビティをより正確に記録するための方法であって、
   パケット・データ・サービング・ノードから送信したバイトの全数を含む記録を生成するステップと、
   再送信したバイトの全数を提供するために、前記パケット・データ・サービング・ノードから再送信するバイトをカウントするステップと、
   前記再送信したバイトの全数により前記記録を調整することができるように、前記再送信したバイトの全数を課金ノードに転送するステップとを備える方法。
2. バイトの再送信を検出するステップをさらに備え、パケット・データ・サービング・ノードから再送信するバイトのカウントが、バイトの再送信を検出した後で行われる請求項１に記載の方法。
3. バイトの再送信を検出する前記ステップが、加入者装置からの二重送信制御プロトコル肯定応答、およびインターネットへの接続からの再送信した送信制御プロトコル・パケットのうちの一方を監視することにより行われる請求項２に記載の方法。
4. 前記パケット・データ・サービング・ノードから再送信されるバイトをカウントする前記ステップが、圧縮したヘッダと一緒に送信されるバイトをカウントするステップをさらに備える請求項１に記載の方法。
5. 再送信したバイトの全数を提供するために、前記パケット・データ・サービング・ノードから再送信されるバイトをカウントする前記ステップが、再送信されるアプリケーション層バイトをカウントするステップをさらに含み、
   前記再送信した全バイトにより前記記録を調整することができるように、課金ノードに前記再送信した全バイトを転送する前記ステップが、前記課金ノードに３ＧＰＰ２属性として前記再送信した全バイトを転送するステップをさらに含む請求項１に記載の方法。
6. 加入者装置のアクティビティをより正確に記録するための方法であって、
   パケット・データ・サービング・ノードから送信したバイトの全数を含む記録を生成するステップと、
   再送信したバイトの全数を提供するために、前記パケット・データ・サービング・ノードから再送信するバイトをカウントするステップと、
   調整した記録を提供するために、バイトの全数から前記再送信したバイトの全数を差し引くことにより、前記再送信した全バイトにより前記記録を調整するステップとを備える方法。
7. 加入者装置のアクティビティをより正確に記録するための方法であって、
   加入者装置が、トラヒック・チャネル上に位置している通信時間中に、ベアラ・データが送信されたか否かを判断するステップと、
   通信時間中にベアラ・データが送信されたか否かを判断する前記ステップが、ベアラ・データが送信されたと判断した場合だけ、前記通信時間中のデータ・アクティビティの通信時間記録を認証、許可および課金ノードに転送し、それにより信号データが全通信時間中の全データ・アクティビティの全記録の歪みを防止するステップとを備える方法。
8. 通信時間中にベアラ・データが送信されたかど否かを判断する前記ステップが、前記トラヒック・チャネルを通して送信されたデータのプロトコル識別を監視するステップをさらに含む請求項７に記載の方法。
9. 通信時間中にベアラ・データが送信されたか否かを判断する前記ステップが、前記通信時間記録中に二点間プロトコル・スタートおよびハンドシェイクが行われたか否かを判断するステップをさらに含む請求項８に記載の方法。
10. 通信時間中にベアラ・データが送信されたか否かを判断する前記ステップが、前記通信時間記録中に加入者装置・プロトコル登録が行われたか否かを判断するステップをさらに含む請求項８に記載の方法。
11. 通信時間中にベアラ・データが送信されたか否かを判断する前記ステップが、パケット間制御機能ハンドオフが行われたか否か、またデータが前記通信時間記録中に送信または受信されなかったか否かを判断するステップをさらに含む請求項８に記載の方法。
12. 通信時間中にベアラ・データが送信されたか否かを判断する前記ステップが、前記通信時間記録中にリンク制御プロトコル・エコーまたは応答が送信されたかまたは受信されたか否かを判断するステップをさらに含む請求項８に記載の方法。
13. 加入者装置のアクティビティをより正確に記録するための方法であって、
    加入者装置が、無線アクセス・ネットワークから送信したデータ到着通知に応答したか否かを判断するステップと、
    加入者装置が、無線アクセス・ネットワークから送信されたデータ到着通知に応答したか否かを判断する前記ステップが、前記加入者装置がデータ到着通知に応答したと判断した場合だけ、バイト・カウントを加算するステップと含む方法。
14. 加入者装置が、無線アクセス・ネットワークから送信されたデータ到着通知に応答したか否かを判断する前記ステップが、能動スタート表示をパケット制御機能から受信したか否かを判断するステップをさらに含む請求項１３に記載の方法。
15. 加入者装置が無線アクセス・ネットワークから送信されたデータ到着通知に応答したか否かを判断する前記ステップが、前記加入者装置がデータ到着通知に応答したと判断した場合だけバイト・カウントを加算する前記ステップが、パケット制御機能から能動スタート表示を受信したか否かを判断する前記ステップが、前記パケット制御機能が能動スタート表示を送信したと判断した場合だけ、使用データ記録にバイト・カウントを加算するステップを含む請求項１４に記載の方法。
16. 加入者装置の正確な課金を行うように配置されている使用量記録エージェントであって、サービング・ノードになるサービング・ノードのところに設置し実行した場合に、前記使用量記録エージェントが、通信時間中に所定の課金できないアクティビティが行われたか否かを判断し、
    前記課金できないアクティビティに対応する記録を生成し、
    送信した全バイトを前記記録により調整することができるように前記記録を課金ノードに転送する使用量記録エージェント。

Images