JP4361214B2 - 通信ネットワーク - Google Patents

Description

【０００１】
発明の属する技術分野
本発明は、通信ネットワーク、とくに通信ネットワークにおける課金機構に関する。本発明は、１９９８年６月５日に出願された本発明の発明者の現在審査中のイギリス特許出願第9812161.9号（発明者の参照番号:A25547）に記載され、権利を主張された発明の態様を含み、前記出願第9812161.9号に先行する出願の内容は参考文献として本明細書に組込まれる。
【０００２】
従来の技術
従来の通信ネットワーク、例えば国内のＰＳＴＮ（公衆交換電話ネットワーク）において、相当な割合いのネットワーク資源はネットワーク使用の測定および請求書発行に専用である。調査ではこれらの資源は遠隔通信会社の歳入の６％ほどを消費すると推定している。対照的にインターネットは概して、個々の顧客に対しての測定および請求書発行機構を組入れていない。計測および請求書発行をサポートするのに要求されるネットワークのインフラストラクチャがないので、インターネットの操作コストは従来の電話ネットワークと比較して低くなり、インターネットの急速な拡大を促進した。しかしながら適切な請求書発行機能がないことは、インターネットによって保持されるトラヒックの特徴における重要な欠点であり：インターネットではネットワーク資源の使用の浪費を助長し、例えば保証されたサービス品質（ＱｏＳ）を要求する新しいアプリケーションをサポートするネットワークのインフラストラクチャへの投資に対する誘因（インセンティブ）を低減する。
【０００３】
発明が解決しようとする課題
本発明の第１の態様にしたがって、通信ネットワークを動作する方法において、顧客端末において検出されたネットワークローディング（network loading）に依存して、顧客端末によるネットワーク使用料金を自動的に変更することを含む方法を提供する。
【０００４】
このドキュメントにおいて料金変更に対する参照は、例えば輻輳パラメータの関数として、価格を変更することを含む。料金構造は変更してもよい。
【０００５】
本発明は、ネットワークロードをほとんどまたは全く含まず、さらにネットワークローディングにおいてローカルな変更を反映できるネットワーク使用に対する課金へのアプローチを提供する。これは顧客端末におけるネットワークローディングの測度を検出することによって達成される。この測度は、特定の時間に顧客端末に使用されている資源を反映することになる。例えば、インターネットのような多数のサブドメインを含む連合形のデータネットワークにおいて、１つのサブドメイン内の顧客端末は、顧客端末からサーバへの通路内のどこかにルータのオーバーローディングがあるとき別のサブドメインにおいて一度にサーバへアクセスすることを試行することができる。したがってネットワークの平均ローディングが全体的に低くても、顧客端末によって知覚されるローディングは高く、顧客端末によるネットワーク使用料金は、関連するネットワーク資源の不足を反映するように増加する。同様に同じルータを介してデータへアクセスする試行を行う他の端末もネットワークローディングが高いと知覚し、それにしたがって料金も増加する。適切な勾配で料金を増加して、少なくともいくつかの顧客端末は問題となっているネットワーク資源を使用する試行を放棄するかまたは据置くことを選択して、ルータのローディングを軽減する。
【０００６】
本発明のこの態様は、エンドユーザが料金および口座についてほとんど知らされず、請求書発行がネットワークプロバイダによって実行されるシステム、エンドユーザが自分の使用度（usage）を測定し、この情報をネットワークプロバイダへ供給するシステム、および両エンドユーザが自分の使用度を測定し、ネットワークプロバイダによって支払いを計算するシステムにおいて使用することができる。
【０００７】
この方法は、顧客端末においてネットワークローディングに依存するネットワーク動作パラメータを検出し、ネットワーク動作パラメータに依存して料金を変更することを含んでもよい。ネットワークがパケットネットワークであるとき、ネットワーク実行パラメータはデータ源と顧客端末との間を伝送中に損失したパケット数であってもよい。このアプローチは、この方法がパケットネットワーク内の既存の輻輳制御機構（コンジェスチョン・コントロール・メカニズム）を使用して実行するのに適しているという長所をもつ。例えばインターネットにおいて、ルータはパケットをドロップすることによって輻輳に応答し、ＴＣＰ（トランスポート制御プロトコル）を使用する顧客端末はパケット損失を検出し、それにしたがって端末において輻輳ウインドウを制御する。本発明では、検出したパケット損失を使用して、端末に適用可能な料金増加を開始することができる。これは、受信端末による輻輳をデータ源へシグナリングすることを伴っていてもよい。
【０００８】
代わりの、または好ましいアプローチでは、ネットワーク内で輻輳が検出されると、明示的な輻輳信号が生成されて、顧客端末へ送られ、顧客端末において明示的な輻輳信号を受信すると、料金増加を開始することができる。このアプローチは、適切な輻輳信号を、ネットワーク動作に相当な劣化が生じる前に生成して、要求されるサービス品質を維持するのをより容易にするという長所をもつ。明示的な輻輳信号が通信ネットワーク上でデータパケットを使用して搬送されることが好ましい。ネットワーク内のルータは、輻輳が該ルータにおいて検出されるときにパケット内の明示的な輻輳信号を書込むことが好ましい。
【０００９】
また別のアプローチでは、輻輳通知信号は、ルータにおいて生成され、データ源へ送り戻される源抑制信号（ソース・クエンチ・シグナル）であってもよい。
【００１０】
料金増加と検出されたネットワークローディングとの間の非線形の関係があることが好ましい。この方法は、輻輳が最初に検出されたときに最初の比較的に小さい料金増加を行なうこと、および輻輳が持続するときに、少なくとも別の1つの比較的に大きい増加を行うことを含むことが好ましい。この動作は、料金アルゴリズムに予めプログラムしてもよい。このやり方では、ネットワークの振動性動作を避け、一方で十分に増加することによってネットワーク資源に対する要求に所望の影響を与えることを保証することができる。
【００１１】
この方法は、ユーザによって判断される価格基準（プライス・クライテリア）を使用して顧客端末において決定エージェントをプログラムし、この料金を使用して計算される価格を前記価格基準をもつ料金と比較することとを含む。例えばパケット毎の課金がゼロであるかまたは所定の閾値よりも低い限り、決定エージェントはデータ通信を続けるようにプログラムすることができる。したがって輻輳によって課金が閾値よりも高くなるとき、データ通信は中断され、決定エージェントは顧客端末の動作を変更する。例えば決定エージェントは、コストの閾値を越えるまで通信をスローダウンしてもよい。次にユーザは、通信を続けることを選択してもよく、または特定の源からデータにアクセスする試行を放棄することを選択してもよい。決定エージェントは、多数の同時送信に対する全体的な価格に関係し、異なる重み付けをそれぞれ異なるアプリケーションに一致させる規則を使用してプログラムしてもよい。
【００１２】
この方法は、料金アルゴリズムを通信ネットワークを介して複数の端末へ分配し、各端末において料金を使用して端末によるネットワーク使用に対する課金を計算することを含むことが好ましい。この場合にこの方法は、ネットワークオペレータが顧客端末とネットワークとの間のトラヒックを断続的にサンプル採りし、このサンプル採りの一部として、顧客端末へ影響を与えるネットワークローディングを記録する段階と；
サンプル採りされたトラヒックにおいて、顧客端末によって計算される課金と予測される課金を比較して、不一致を検出する段階とを含む。
【００１３】
ネットワークローディングを記録する段階は、例えばパケットのドロップ、明示的な輻輳通知（ＥＣＮ）ビット、または源抑制メッセージを記録することを含む。
【００１４】
本発明はさらに、本発明の第１の態様にしたがう方法によって動作するネットワークと、このようなネットワークで使用する顧客端末、ネットワークルータ、および他のネットワークノードとを含む。
【００１５】
ここで本発明を実現するシステムを添付の図面を参照して例示的に記載することにする。
【００１６】
発明の実施の形態
図１に示したように、通信ネットワーク１は多数のネットワークサブドメイン２Ａないし２Ｃを含む。ネットワークのサブドメインは、異なるオペレータの制御のもとに置かれるが、この異なるオペレータは互いに信頼していなくてもよい。ネットワークのサブドメインはゲートウエイルータ３，４によって相互接続されている。本発明において通信ネットワークはインターネットであり、ユニキャストおよびマルチキャストインターネットプロトコル（ＩＰ）と関係するプロトコルの両方をサポートする。顧客端末５は、公衆交換電話ネットワーク（ＰＳＴＮ）６およびアクセスルータ７を介してサブドメイン２Ａへ接続されている。このアクセス点において単一のブロッキング試験がトラヒックに適用される。ゲートウエイルータ３、４およびアクセスルータ７はそれぞれCISCOシリーズ7500ルータおよびCISCOシリーズAS5800ユニバーサルアクセスサーバのような市販のデバイスであってもよい。他の顧客端末、例えばジャバイネーブルのモバイル端末８およびデータサーバ９がネットワークに接続されている。顧客端末５はＬＡＮを介して口座サーバへ接続してもよい。口座サーバは、後述するように顧客端末から測定データを受取る口座オブジェクトを含んでもよい。
【００１７】
後述のローカルな料金表変形機構（タリフバリエーションメカニズム）に加えて、ネットワークはさらに多数の料金団（タリフバリエーション）のネットワーク応用制御を使用する。ネットワーク管理プラットフォーム10は各サブドメインに接続される。各ネットワーク管理プラットフォームは、例えばユニックス（Solaris）をネットワーク管理アプリケーションと一緒に実行するＳＰＡＲＣワークステーションを含むコンピュータ処理システムを含んでもよい。ネットワーク管理プラットフォーム10は管理エンティティの料金エンティティのホストとなる。ネットワーク管理プラットフォームは、例えばＳＮＭＰ（簡単なネットワーク管理プロトコル）を使用して、各サブドメインへ接続された管理デバイスにおいてエージェント100と通信する。管理プラットフォームは各サブドメイン内のネットワーク資源の全体的なローディングをモニタし、さらに後述するように、それにしたがってネットワーク使用料金を調節する。ネット管理プラットフォーム（ＮＭＰ）はエージェントにデバイスをモニタし、正規の間隔で集められた結果をＮＭＰへ報告して、ＮＭＰが全ての報告の組み合わせをモニタできるように命令する。
【００１８】
料金データは、他のサブドメイン内のピア料金エンティティおよび顧客端末へ通信される。料金データは、例えば距離ベクトルマルチキャストルート設定プロトコル（Distance Vector Multicast Routing Protocol,ＤＶＭＲＰ）またはプロトコル独立マルチキャスト（Protocol Independent Multicast, ＰＩＭ）稠密（デンス）モードを使用してマルチキャストされる。料金データチャンネルは、ＳＤＰ（セッション記述プロトコル）に基くプロトコルを使用してアナウンスおよびモニタされ、ＳＡＰ（セッションアナウンスメントプロトコル）の課金は“支払および表示”モデルにおいて実行される。各顧客端末は、例えば、それがネットワークインターフェイスにおいて送受信するパケット数、およびこのパケット内のデータ品質（バイトで）を係数することによって、それ自身のネットワーク使用をモニタする。各顧客端末は、ネットワークを介して受取った料金を使用して、ネットワークオペレータによる支払い期限を計算し、ネットワークオペレータの口座へ対応する支払いを行う。ネットワークオペレータは、特定の顧客との間でトラヒックを断続的にサンプリングし、行われた使用と支払われた使用とを比較することによって、端末の顧客によって行われる使用を管理する。
【００１９】
顧客端末へ供給される料金（タリフ）は、異なる揮発性をもつグループ（バンド、集団）へ分割される。料金は異なるネットワークオペレータの制御のもとで、ネットワークの全体的なローディングを反映するように変化する。すなわちネットワークローディングが高くなるとき、ネットワーク資源の希少性を反映するように料金を増してもよい。
【００２０】
サービスプロバイダは、異なるサービスレベル協定または異なる価格の揮発性、あるいはこの両者によって規定された異なる製品を提供することができる。例えば製品Ａは最善を尽くすサービスを固定価格（プライス）で提供し、一方で異なる製品Ｂは可変価格で最善を尽くすサービスを提供してもよい。サービスプロバイダは、次のパラメータ：すなわちサービスプロバイダが卸売りプロバイダに支払う価格；競争相手の価格；現在の資源利用；異なる製品に対する関連する需要に基いて製品の価格を調節してもよい。これらのパラメータにおける変化に応答して、料金調節を３つのやり方の１つにおいて実行することができる。第１に、プロバイダからの明らかな通信を必要とせずに、ネットワークローディングのローカルな観察に基いて料金を調節する。このアプローチは、後でさらに記載するが、最初に料金表（タリフ）に組込む必要があり、専らローカルな観察に依存している料金変動に制限される。第２に、プロバイダはパラメータの一部を調節することによって料金に適合することができる。顧客端末によって直接にできないパラメータ、例えばネットワーク資源の卸売価格の変化に依存するときに、このような調節が要求される。第３に、プロバイダは料金表を完全に置換してもよい。これは、既存の料金が要求される変化に適応できないときに要求される。
【００２１】
上述の第1の料金変更は必ず自動的に行われる。第２のタイプの課金は手操作で、またはサービスプロバイダシステムによって行われる観察に応答して自動的に調節を送るエージェントによって行うことができる。第３のタイプの変更は手操作で実行される可能性が高く、新しい料金に代わるものとして、一般的に人間による入力を要求する設計要素を要求する。しかしながら1組の特定の規則に基づいて製品の料金を自動的に交換するようにエージェントを採用することができる。
【００２２】
この段落では、上述で概略的に示した料金のサブシステムを説明するのに我々が構成したプロトタイプを記載した。この設計の特徴は次のもの、すなわち：
・料金および関係するユーザインターフェイス構成要素を表わすモバイルコードを使用することと；
・反復されるマルチキャストアナウンスメントプロトコルを使用して、料金および料金調節を効率的に通信することと；
・ダイナミックなクラスのローディングおよび反映を使用して、料金を受取って適合させることとを含む。
【００２３】
プロトタイプは、一般目的のジャバクラスのライブラリおよび２つの特定のアプリケーション、すなわち：
・プロバイダが多数の製品の料金（表）を導入、置換、および適合できるプロバイダシステムと；
・課金の追跡がユーザが使用している製品に加えられ続けることを可能にする顧客システムを含む。
【００２４】
プロバイダシステムは、マルチキャストイネーブルのネットワーク内の異なるホスト上で実行されている顧客システムの多数のインスタンス（例）をサービスする。マルチキャストアナウンスメントプロトコルを使用して、プロバイダシステムから顧客システムへ料金変更を通信する。
【００２５】
料金規定に対する柔軟性を最大にするために、我々はジャバクラスを使用して料金を表示することを選択した。この技術は、顧客へのユーザインターフェイス構成要素（コンポーネント）に供給して、料金の動きの視覚化をサポートするのにも使用される。
【００２６】
料金インターフェイスは、全ての料金に対する基本クラスとして働く。これは単一の操作get GUI()を規定して、顧客のＧＵＩ（グラフィカルユーザインターフェイス）へ組込むことができるジャバＳＷＩＮＧ構成要素として戻す。ＧＵＩ構成要素は、料金に適した技術を使用して、顧客が料金の動きを視覚化できるようにする。
【００２７】
料金インターフェイスのサブクラスは、各々が異なる組の測定および入力パラメータと関係する1組の料金タイプを設定する。これらのパラメータは、getCharge()方法のサイン内にパラメータを記載することによって識別される。例えばインターフェイスRSVPTariffは、n RSVP TSPECを受取り、RSVP BLB98の特徴に基いて価格をコンピュータ処理する料金規定を許可するとき、getCharge()を規定する。他方でインターフェイスPacketCountTariffはgetCharge()を規定するパケットイン、パケットアウト、および現在の輻輳（一般的にパケットドロップ関数として測定される）の測定値を受取り、パケット係数に依存し、輻輳を感知する料金の規定を許可する。他の料金は、使用測定の新しい形態が現れるときに加えることができる。
【００２８】
料金は、上述の種々の料金インターフェイスの構成を用意することによって規定される。例えば、料金PacketCountLinearはPacketCountTariffがパケットカウントに比例して課金をコンピュータ処理するように構成する。別の料金CongestionSensitiveLinearは同様に働くが、顧客が輻輳中に特定の料金制限内に留まらないときに、科料の課金を加える。
【００２９】
料金インターフェイス構成に加えて、料金は他の‘ヘルパ’クラスを使用して、その動作を補助し、さらに、プロバイダが料金調整できるようにするために１以上のユーザインターフェイスを要求してもよい。プロバイダサイドユーザインターフェイスを要求して、プロバイダは料金調整することができる。
【００３０】
完全な料金表の記述は１組のジャバクラスから構成されており、その一部は顧客システム用に定められ、その残りはプロバイダシステムによって使用することが意図されている。顧客サイドクラスは、ジャバアーカイブ（ＪＡＲ）ファイルに纏められて、プロバイダシステムによる処理を容易にする。
【００３１】
新しい料金を展開するために、プロバイダシステムは最初に、実行環境へ要求する料金クラスをロードする。次にプロバイダシステムは、顧客サイドバンドルをロードし、それを直列化し、それを私設キーでサインし、アナウンスメントプロトコルを使用して、それを顧客システムに分配する。サインを使用すると、受取った料金が認証できることを顧客が確認できるようにする。
【００３２】
バンドル（束）を受取ると、各顧客システムは（プロバイダの私設キーを整合する公衆キーを使用して）サインを確認し、アナウンスメントプロトコルヘッダにおいて特定される作動時間は、例えば数時間または数日などのように相当に遅くなることもあるが、バンドルをアンパックし（パックを解いて）、特別の目的のために構成されたダイナミッククラスローダを使用してその実行環境へこれらのクラスをロードする。受取った料金表クラスのインスタンス（例）を生成して、先の料金の代わりにインストールする。料金が、（料金オブジェクトのgetGUI()方法を呼ぶことによって得られる）ユーザインターフェイス構成要素をもつとき、これは先の料金表のユーザインターフェイスを置換する。ユーザインターフェイスの変更は、料金が変更したことをユーザに知らせるようにサービスする。
【００３３】
料金調整は、現在実行中の料金に特定の動作の遠隔からの呼び出しを含む。したがって顧客システムは、料金を受取る前にこの動作のサインを知ることができない、すなわち動作が顧客システムに知られている料金（表）インターフェイスの何れにも記載されない。
【００３４】
この問題を克服するために、ジャバによってサポートされる“反映（reflection）”特徴を使用する。料金調整を送達するために、プロバイダはInvocationオブジェクトの例を生成し、呼ばれる動作名を、それに供給されるパラメータと一緒に記憶する。次にこのオブジェクトはアナウンスメントプロトコルを使用して直列化し、サインし、アナウンスする。顧客システムによって調整を受取り、確認するとき、Invocationオブジェクトは直列化を解除して、反映を使用して記載した動作を呼び出すことによって現在の料金に適用される。
【００３５】
アナウンスメントプロトコルを簡単にするために、べき等元および完全(idempotent and complete)であることを要求される。べき等元は、１回以上行うときに、不利に料金に影響を与えないことを保証する。完全性とは、調整が料金オブジェクトの全体的なパラメータの組を判断して、前もって加えた調整の影響を完全に取除くことを示唆する。
【００３６】
顧客システムは、毎秒料金によってサポートされるgetCharge()動作を繰り返し呼出し、戻された値に累積的な課金を加えることによって料金を適用することができる。getCharge()に供給されるパラメータは、現在実行中の料金に依存する。例えば料金がPacketCountTariffの構成であるとき、過ぎた時間におけるインバウンドパケット、アウトバンドパケット、および輻輳の測定が要求される。しかしながら料金がRsvpTariffの構成であるとき、現在の予約を記述しているTSPECのみが要求される。これは、顧客システムがハット製品(hat product)と関係する料金によるパラメータ要求を供給できるときのみ、顧客システムは製品に加入できることを示唆している。
【００３７】
getCharge()方法の各呼び出しは、さらに料金に特定のユーザインターフェイスの更新を行う。例えばCongestionSensitiveLinear料金において、getCharge()に供給される使用パラメータを使用して、トラヒックおよび輻輳のグラフィック表示を更新する。
【００３８】
アナウンスメントプロトコルを使用して、直列化された料金および調整をプロバイダシステムから、多数の顧客システムへ通信する。多数の顧客システムは大きいと仮定され、反復されるマルチキャストの解決案が適用される。
【００３９】
プロバイダによってサポートされる各製品は、アナウンスメントのためにマルチキャストチャンネルに割り当てられる。顧客システムは、それらが使用している製品に対応するチャンネルを聞く。現在の構成では、各顧客が関心をもっている製品の周知のマルチキャストアドレスの知識をもつと仮定される。
【００４０】
各製品のチャンネルにおいて、プロバイダは現在の料金および（もしあれば）各製品に対して最も最近行われた調整を繰り返しアナウンスする。各アナウンスメントはバージョン数を保持し、バージョン数はアナウンスメントが変更されるたびごとにインクリメントされる。顧客システムのみが、バージョン数の変化が検出されるたびに処理する。新しい顧客がチャンネルに加わると、顧客システムは調整アナウンスメントを処理する前に料金を受取るまで待機する。さらに、アナウンスメントバージョンが現在の料金のバージョンよりも大きいときのみ調整が加えられて、失われた料金アナウンスメントは、古い料金に対して次の調整を加えないことを保証する。
【００４１】
ネットワーク管理プラットフォームによって料金を中央で監視および制御するのは、ネットワークのローディングにおけるグローバルな変化に応答するのに効果的であるが、このやり方でローカル化された輻輳を処理するのは困難である。パケットを輻輳点を通して通信することを試行することによって、信号のみを受取るように、値上げ信号をマルチキャストすることは困難である。したがってインターネットにおいて各要素に対して個々にマルチキャストすること、例えば各ルータの各インターネットにおいて各異なるシーケンスに対してマルチキャストすることが要求される。その代わりに、ローカル資源のローディングによってトリガされる値上げ集合(アグレゲーション)を使用してもよい。しかしながらこれは値上げ信号が、輻輳した資源を使用しないユーザへ送られることを意味する。したがって値上げ信号を減衰して、値上げし難くくして、輻輳した資源に対する要求を減らすことが必要である。
【００４２】
これらの問題を克服するために、顧客端末にインストールされる料金アルゴリズムは、端末によって使用されているネットワーク資源における輻輳に自動的に応答するようにされている。各アルゴリズムは、検出された輻輳レベルに依存してネットワーク使用に対して料金を変化させる関数を含む。この関数は、主要な料金アルゴリズムに統合されるか、または本明細書において記載した例のように別々のアルゴリズムを使用して主要な料金アルゴリズムにしたがって計算された料金に加えられる割増料金を計算してもよい。
【００４３】
主要な料金アルゴリズムは、多数の品質パラメータＱ_１、Ｑ_２、Ｑ_３の関数として値段Ｐを計算し、例えばＱ_１は顧客端末とネットワークとの間のインターフェイスにおいて通信されるパケットに対する特定の待ち時間(latency、遅れ)であり、Ｑ_２は送信における予約されたバンド幅であり、Ｑ_３はパケット損失の最大許容可能レベルに対応する信頼性の特定のレベルである。
【００４４】
料金Ｐは次の式によって得られる：
Ｐ＝ｆ（Ｑ_１、Ｑ_２、Ｑ_３……）
品質パラメータＱの1つにおける料金設定機能の例は、図２ａに模式的に示した。
【００４５】
輻輳料金アルゴリズムは、１以上の輻輳パラメータＣの関数である割り増し料金（価格）ΔＰを計算する：
ΔＰ＝ｆ（Ｃ_１，Ｃ_２…）
輻輳パラメータは、所定の時刻に顧客端末を使用する資源のローディングの速度を与える。この例では失ったパケット対受取ったパケットの比を輻輳パラメータとして使用する。例えばＴＣＰ（転送制御プロトコル）、またはＵＤＰ（ユーザデータグラムプロトコル）におけるＲＴＰ（実時間プロトコル）を使用するパケット例では、このようなパケットはシーケンス番号を含むので、このパラメータは容易に計算される。図２ｂは、割り増し料金を生成する関数の１例を示す。この例では、割増料金は、輻輳についての近似指数関数として増加して、低い輻輳レベルにおいて僅かな割り増し料金を課金し、一方で輻輳がさらに相当に増加するときは、さらに高いレベルの輻輳において割り増し料金を著しく増加する。
【００４６】
別の構成では、明示的な輻輳信号はネットワーク内の輻輳したルータによって顧客端末へ送られるパケットへ加えられる。輻輳がパケットのドロップによって明示的にまたは暗示的に知らされても、価格アルゴリズムは輻輳の表示に対して直接に課金しない。その代わりに価格アルゴリズムは、顧客端末が輻輳の表示に応答して輻輳ウインドウを半分にしないときは課金してもよい。輻輳ウインドウが半分になることは、伝送レートは半分になり、これはＴＣＰおよび他の互換性のある輻輳制御プロトコルにおいて使用される輻輳の表示に対する標準的な応答である。伝送レートの変更はネットワークプロバイダによって、顧客端末でと同様に、測定できるが、これは資源を処理するルータ上に重いロードを置く。プロバイダが単に一定の顧客をサンプル採りして、自分自身の測定を監査すると、これは受理できるロードを生成する。
【００４７】
本明細書では単一の主要な料金および割り増し料金のみを記載したが、実際には異なるサブドメイン、および各サブドメインに関係する異なるサービスプロバイダでは、各々が異なる主要な料金および割り増し料金をもつ異なる料金設定構造をもっている。しかしながら全てのサブドメインにおいて、ネットワークローディングレベルと輻輳シグナリングとの間に共通の関係がある。
【００４８】
ここで第２の構成の実行を作動するサービスを使用するネットワーク動作のコンテキストにおいて記載することにし、なおこの差動するサービスはInternet Engineering Task Forceの文献（“Differentiated Services Operational Model and Definitions”）、およびDavid D Clark (MIT)による文献（“A Model for Cost Allocation and Pricing in the Internet”,MIT Workshop on Internet Economics, Mar 1995, URL:http://www.press.umich.edu/jep/works/ClarkModel.html.）に記載されている。差動サービスを実行するネットワークにおいて、ノードは異なるレベルのサービスを提供するためにパケット間で差動するようにされている。この能力を使用して、例えばＩＰ電話クライアントによって生成されたデータのような遅延感知データを、ｅメールデータのような他のデータに比べてより高い優先度をもつデータに一致させることができる。ネットワークの端部、例えばＩＰ電話クライアントを実行する顧客端末において、各パケットヘッダ内に含まれるＴＯＳ（サービスタイプ、type of service）オクテットにおけるビットは、適切なサービスレベルを示すように設定される。これらのビットはネットワーク内のルータによって使用されて、関連するパケットをどのように処理するかを判断する。
【００４９】
ＴＯＳオクテットは、このやり方で使用されるとき、ＤＳ（差動サービス）バイトと呼ばれる。差動サービスバイトのフォーマットは図３に示した。ビットゼロは“ＩＮ”と記載され、パケットが規定のプロフィールの内側にあるかまたは外側にあるかを示す。“ＰＨＢ”と記載されるビット１ないし５は“ホップごとの振舞い（per-hop-behaviour）”を規定し、例えばパケットをより低いまたはより高い優先度で一致させることによって、ルータがパケットをどのように処理するかをビットで示す。ＤＳバイトの特定の形態において、ビット６ないし７は明示的な輻輳通知（ＣＥＮ）に対して使用される。これらのビットの１つは、パケット通路内のルータがＥＣＮフィールドを設定することができるか否かを示し、他のビットは輻輳、または潜在的に輻輳を導くローディングが発生するときに、（ＥＣＮ能力ルータによって）設定されるフラグとして使用される。ランダムな初期検出（ＲＥＤ）アルゴリズムは現在ルータにおいて実行されている。これらのアルゴリズムは、ルータのパケットバッファ内の平均の待ち行列長を測定する。明示的な移動平均が計算される。平均待ち行列長が所定の閾値を越えるとき、ルータは輻輳が発生していることを信号で知らせる。通常このシグナリングは、単にパケットをドロップすることによって行われてきた。しかしながらＣＥＮ方式のコンテキストにおいて、ルータは、パケットをドロップする代わりに、パケットヘッダ内にＥＣＮビットを設定して、輻輳が発生していることを示す。これは確率的に達成される：すなわちルータを通るパケットの一部のみが指定される。指定されるパケットの確率は、平均的な待ち行列の大きさにしたがって増す。まれな場合には、待ち行列は、ルータバッファがいっぱいになる長さを増加し、次にＥＣＮビットを設定するのではなく、パケットをドロップする。この場合、ＥＣＮビットは全ての残りのパケットに対して設定される。
【００５０】
動作において、クライアント端末５がサーバ９上のデータ源にアクセスしているとすると、輻輳は、例えばネットワークサブドメイン２Ｂおよび２Ｃをリンクするルータ４において発生する。ルータ４におけるＲＥＤに類似したアルゴリズムは、指数関数的な移動平均を使用して計算されるように、ルータバッファの待ち行列長が、所定の閾値を越えていることを検出する。サーバ９からクライアント端末を経由するパケットのいくつかは、ルータ９によって設定されるＤＳバイトのＥＣＮビットをもち、輻輳が発生している事実に注目する。クライアント端末において、到来パケットのヘッダにおけるＤＳバイトが読み取られる。指定されたＥＣＮを含むパケット数の移動平均が計算される。この平均は、割り増し料金を計算するのに使用される輻輳パラメータＣ_１を与える：
ΔＰ＝ｆ（Ｃ_１）
次にユーザに対する合計金額Ｐ_ＴＯＴは主要な料金アルゴリズムおよび割り増し料金アルゴリズムによって判断される価格を一緒に加算することによって計算される：
Ｐ_ＴＯＴ＝Ｐ＋ΔＰ
この合計金額は、クライアント端末上で実行されるコスト決定エージェントへ送られる。このコスト決定エージェントは、ユーザの規定された規則でプログラムされる。これらは、例えば一定時間における平均をとられた合計コストが所定の閾値、毎分０．０１ポンドよりも低い限りシステムが接続の処理を進めることをコスト決定エージェントが承認すること、およびコスト決定エージェントが接続をサスペンドし、コストが閾値よりも高くなるときにユーザに警報することを記述している。その代わりに、既に記載したように、コスト決定エージェントは、いくつかのアプリケーションを同時に処理すること、およびアプリケーションの１つによってアクセスされるデータ源に対する割り増し料金が増加するとき、このアプリケーションの１つをスローダウンすることができる。
【００５１】
ある環境におけるある顧客については、ネットワーク使用に対する料金変化によって問題が生じることがある。例えば、顧客は、例として２０の参加者と、この顧客とのマルチキャストのオーディオ−ビデオ会議をスケジュールすることを望んでもよく、この場合はこの顧客が全参加者に対するネットワーク使用コストを支払うことを意図している。会議は１日以上前にスケジュールされるが、料金は時間で変化するので、会議がスケジュールされている地点で顧客が支払うことになるコストは顧客には分からない。本発明の好ましい構成では、顧客におけるこの問題を克服し、さらにネットワークオペレータに対する追加の収入源を用意する。これは、所定の顧客端末に対して料金安定性の割り増し料金を規定する別の料金を当てることによって達成され、したがって安定性期間に対して要求される継続期間が増加するとき、割り増し料金の値が増加する。上述で参照した例では、１日前に会議をスケジュールした顧客は、現在の料金を参照して、現在適用可能な輻輳の割り増し料金を含む要求されるネットワーク資源の現在のコストを判断し、次に別の料金を参照して、現在の値のコストを１日の一定期間の間維持する割り増し料金を判断する。次にユーザが固定料金を使用することを決めると、メッセージはユーザからネットワークオペレータへ送られる。メッセージは、例えばＩＰアドレスおよび参加者間のオーディオおよびビデオデータ流に対するサービスレベルを、ユーザが契約を結んでいる固定期間内の現在の時刻、固定期間の要求される継続期間、およびメッセージに対する識別コードと共に特定することによって問題のデータ流を識別する。その代わりに、これらの詳細を含むメッセージは適切な暗号機能（例えば、ＭＤ５）で追跡され、ハッシュ値のみが最初にプロバイダへ通信されて、後で口座データを確認するのに使用される。続いて特定期間の継続期間、この場合は1日の中で、ユーザは固定料金を当てる。ユーザ自身が口座データを生成し、ネットワークの使用に適用できる課金を計算することに責務を負うシステムにおいては、ユーザは固定料金を使用して課金を計算し、口座データを固定料金の契約に対する識別コードと一緒にネットワークオペレータへ戻す。
【００５２】
本発明のこの態様は、輻輳の検出に応答して料金変更が局所的に実行されるシステムに応用可能なだけでなく、ネットワークオペレータによって唯一の変更が加えられるシステムにも使用することができる。
【００５３】
安定性割り増し料金（スタビリティ・プレミアム）は、先の他の料金に対して既に記載したのと同じやり方で、ネットワークオペレータプラットフォームにおける料金エンティティから顧客端末へマルチキャストすることによって分配することができる。他の料金に関して、異なる料金、および選択的に異なる安定性期間は異なるサービスレベルに適用することができる。上述の段落で記載したシナリオにおいて、異なるサービスレベルを、マルチキャスト会議に必要とされるオーディオおよびビデオデータ流の異なる要素に使用してもよい。
【００５４】
図２ｃは安定性割り増し料金における１つの可能性を示している。この料金はユーザへのジャバ機能マルチキャストにおいて実現することができる。曲線Ｃは、主要な料金アルゴリズムに役立つ別の補助アルゴリズムとして顧客端末へ通信される。顧客は、価格安定性期間を選択し、曲線Ｃを使用して顧客が要求するスポット価格より高い割り増し料金を計算する。曲線Ｂは特定の場合に選択される安定価格の例である。安定性期間が終了すると、そのときのスポット価格の割り増し料金で新しいものを買うことができる。一定期間の価格安定性を購入するために、顧客は要求される期間、およびそれが顧客のプロバイダに適用する一定の範囲のアドレスをアナウンスしなければならない。（例えば、単一の人に対するインターネット電話呼の継続期間における）1つのアドレスまたは（例えば、ビデオ会議における）一定の範囲のアドレスにおいて要求してもよい。ある種の危険を嫌がる顧客（risk-averse customers）に、いつでも全てのアドレスに対して安定した価格設定を要求することができる。
【００５５】
記述を簡単にするために、上述では輻輳に応答する料金のローカルな変化を独立させると記載した。実際には、この機構は概ね輻輳に対する他の応答および料金を変化する他の源と結合される。さらに、輻輳にも関らず伝送を進める決定は、概ね伝送の最初と最後の両方における当事者の同意を必要とする。データ源、ネットワーク、ルータ、およびデータ受信機をもつ全システムを検討するとき、局所的に検出された輻輳に応答する料金増加（ここでは“罰金もしくは科料”とも呼ばれる）の実行は最後の手段として行われる。他の応答は、最初に次に示す番号順に実行される：
１．ネットワークは輻輳の周辺で再ルート設定をする。
２．ネットワークは、最善を尽くすサービスを含むサービスの中で、より低いサービスレベル（すなわち、ＱｏＳの関連する大きさのコンテキストでみたときにより低いサービスレベル）から容量を借りる。
３．ネットワークは余分の容量を（おそらくは自動的に）採入れる。
４．エンドシステムは、単にアクセスリンクまたはエンドシステムではなく、共有ネットワーク上に輻輳が存在するように設定する。
５．エンドシステムは、（現在のレベルの輻輳を無視することに対する罰金よりも安いときに）ＱｏＳ要求を“より高い”レベルにセットする。
６．エンドシステムは、現在のレベルの輻輳を無視したことに対する罰金が比較的に高いときに、輻輳を無視することが本質的であると決定する。
７．両方の（全ての）エンドシステムは、輻輳を無視するのに賛成する。
【００５６】
一般的に段階４においてＥＣＮ信号が生成される。段階１ないし３はこの信号の生成に先立って行われ、段階５ないし７はＥＣＮ信号を生成の後に行われる。
【００５７】
接続する処理を進め、接続に対して割り増し料金を支払う前の最後の段階は、両方の当事者による協定を設定している。したがって顧客端末が明示的な輻輳通知を受信するか、またはパケット損失のような関連するパラメータの検出することによって輻輳を検出するとき、顧客端末はこの事実を該または各エンドシステムへ戻す信号を送る。したがって本発明の例では、クライアント端末５はデータサーバ９へ信号を送り、輻輳が発生していることを知らせる。データサーバは、顧客においてエージェントと同様に実行でき、このような信号に対する応答を判断する規則でプログラムされる。例えばサーバはこれらの条件ではサービスを拒否してもよい。図１に関係して既に記載したように、この例では料金はネットワークオペレータからネットワークを通って顧客端末へマルチキャストされ、課金は“支払いおよび表示”プロセスを使用して実行される。図４および５は、この場合、課金アーキテクチャを構成するのに使用されるオブジェクトを示している。図４はより高いレベルのオブジェクトを示し、図５は、図５のアーキテクチャのソフトウエア構成で使用される構成要素のオブジェクトを示す。図４において、クライアント端末上のオブジェクトは図面の半分に“顧客”と記載して示され、アクセスルータ７および対応するネットワークサブドメイン上のオブジェクトは図面の残りの半分に“エッジネットワーク(edge network)”と記載して示されている。顧客端末上のオブジェクトは、セッション制御オブジェクトＳ、顧客ビジネス規則Ｂ_ｃ、顧客価格設定オブジェクトＰｒ_ｃ、ＱｏＳマネージャＱ、顧客口座オブジェクトＡｃｔ_ｃ、および顧客測定オブジェクトＭ_ｃを含む。ビジネス規則オブジェクトＢ_ｃは、支払いに対する信頼性を含むセッションの観点において情報を受取り、価格設定オブジェクトＰｒ_ｃから現在の価格設定データを受取る。課金可能なサービスが利用される顧客方策制御のもとで、および課金可能なサービスがどのくらい使用されるかにおいて、顧客ビジネスオブジェクトは決定を行う。これらの決定はＱｏＳマネージャＱへ供給され、ＱｏＳマネージャＱでは何れかの機構を使用して要求を達成するかを決定する。次にＱｏＳマネージャは顧客測定オブジェクトＭ_ｃを制御し、トラヒックおよび測定サービスにおけるアスペクト（観点）および無視するアスペクト（観点）を判断する。次に測定オブジェクトは、選択したトラヒックのアスペクト、例えば顧客端末によって受取られるパケット数を計数することと、これらのパケットのＱｏＳレベルとを記録する。これらのデータは、輻輳に対する割り増し料金を含む現在の料金と一緒に、顧客端末によって使用され、ネットワークオペレータに支払い可能な課金を判断する。測定オブジェクトＭ_ｃも、それが顧客口座オブジェクトＡｃｔ_ｃへデータを送る頻度を判断する命令でプログラムされる。顧客口座オブジェクトＡｃｔ_ｃはネットワークプロバイダドメイン内の口座オブジェクトＡｃｔ_ｐへの支払いを送る。
【００５８】
顧客端末上の口座オブジェクトは、小さいエンクリプトされたフラットファイルデータベースを使用して構成することができる。ネットワークプロバイダサイドでは、例えば数万の顧客口座を取扱うのにスケーラブルなより大きいデータベースを使用して、等価のオブジェクトを構成することができる。オブジェクト要求ブローカ（ＯＲＢ）は顧客サイドのオブジェクトとネットワークサイドのオブジェクトとの間の通信に使用され、これはIona Technologies plc.のＯＲＢＩＸ（商標）のような市販のツールを使用して構成されている。
【００５９】
ネットワークプロバイダのサイド、すなわち顧客端末が接続されているサブドメイン内では、顧客のトラヒックはＭの１つのバージョン、すなわちＭｐによって、管理機能(policing function)Ｐ_ｏによって判断されるサンプリングのみに基いて判断される。したがって、ネットワークオペレータは断続的にのみ顧客のトラヒックをサンプル採りする。Ｐ_ｏはネットワーク内で測定を行って、特定の顧客のトラヒックの全てを捕捉するところを制御する。バルク測定機能Ｍｂは、ルータの待ち行列長の変化する平均に反映されるように、総トラヒックレベルを価格設定オブジェクトＰｒ_ｐへ報告する責務を負う。バルク測定は一般的に、プロバイダのドメインから（確実とするために複製される）集中型価格設定機能へ集められることになる。Ｐｒ_ｐは、ネットワークプロバイダのビジネスオブジェクトＢｐからのビジネス規則を考慮した価格、およびＭｂによって報告され、隣り合うプロバイダから価格設定する現在のトラヒックレベルを設定する（下記参照）。管理機能Ｐ_ｏはＭ_ｐからのサンプル測定と、顧客自身の測定結果としてのＡｃｔ_ｐにおいて受取られた口座メッセージとを比較する。管理機能Ｐ_ｏは、口座が不十分であると確認すると、アクセス制御ゲートウエイＡｃｓにおけるサービスを制限するか、または他の科料（懲らしめ）を開始する。口座オブジェクト内にエンカプシュレートされると、別の管理オブジェクトは支払いのために契約時間内の支払に整合する口座を検査する。最後に、識別子マッピング機能Ｉは、顧客の識別子（口座、ディジタルサイン、など）と現在のネットワークアドレス（一般的に、ユニキャストまたはマルチキャストでＩＳＰによって割り当てられる）とをマッピングする。
【００６０】
図６は、口座オブジェクト間で送られるデータを示す。この例では、口座データは：口座識別子；請求書発行記録識別子；サービスタイプ識別子；送信元アドレス；送信先アドレス；料金識別子；時刻；期間（すなわち、請求書発行記録によってカバーされる期間）；ユニット；コスト；および通貨（カレンシイ）を含む。加えて、支払いデータは総額および支払われた通貨を含む。
【００６１】
図７は、顧客端末上のプロトコルスタックおよびネットワークドメイン内の測定領域を示す。理想的にはこの領域内には２つの測定点があり、例えば図７において（ａ）で参照される２つの地点では、一方は顧客によって委託され、他方はネットワークによって委託される。構成を簡単にするために、両方の当事者によって委託される単一の測定点（ｂ）を使用することができる。これは、例えばクライアント端末上の暗号カードのような保安モジュール内に構成される。その代わりに、測定は異なる地点で行ってもよく、このときは測定が一致しない可能性がある。ネットワーク上では、実際の測定点は、各顧客において、ネットワーク層のヘッダ（ｃ）（この場合はＩＰ）を検査する第１のアクセスデバイスにある。そのアクセスネットワークおよびシステムが遅延および損失を導くので、ＩＳＰはネットワーク（ｄ）へ向かってより深部を測定しない。
【００６２】
（例えば、ダイヤルアップアクセスの際に）個々の顧客において、測定実行点は、ネットワーク層と一緒であるが、エンドシステムのスタック（ｅ）内である。理想的にはこれらの測定点は、各スタックのより低いところにあり、２つの当事者間のインターフェイスにより近く、スタック内の競合によって影響される可能性は低くなることが多い。しかしながらリンク層（ｆ−ｆ）における測定は、ネットワーク層に設定された課金可能なパラメータのみが常にリンク層フレーム；すなわちネットワークレベルマルチキャストにおいて反映されるので不適切であり、二点間の待ち時間要求などはリンク層において見えないことがある。さらにリンク層のヘッダは、異なるリンク方式が一緒に連結されるところで明らかな不一致するのを避けるために帯域幅の計算におけるパケットの大きさを測定するときに無視される必要がある。
【００６３】
（スタックの上の）受信方向では、この測定点選択は、より高い層の最も厳格なＱｏＳ要求に対処するように、より低い層が（バッファの大きさ、割込み妨害、およびスレッドスケジューリング優先順位を）測寸されていなければならないことを示唆されている。フレームが物理的媒体を取り去られるとき、この機械は、使用により課金するデータがネットワーク層を得る前に（例えば、中断コンテンションによって生じるバッファのオーバーフローによって）このデータが捨てられることなくスタック上にデータを送ることができなければならない。ネットワーク層では、ＩＳＰのサービスが測定され、ＱｏＳ要求が（エンドシステムにおいて）さらにスタック上へ送られるか、または（ルータ上を）送られるときにＱｏＳ要求が種々のフローの正しい差動処理を制御するのに最も便利なところである。
【００６４】
上述の測定オブジェクトは、一般的に市販されているネットワーク測定ソフトウエア、例えばNevil Brownlee’s NeTraMetシステムを適切に変更をして使用して実施することができる。これは、RFC 2063およびRFC 2064に記載されたアーキテクチャにしたがうＩＥＴＦインターネットに一致するソフトウエアメータである。このメータは、“パケットスニッフィング（packet sniffing）”を使用して、エンドポイントアドレスによって定められるトラヒックフローにおけるパケットおよびバイト計数値（カウント）を構築する。しかしながら一般的にアドレスはイーサネットアドレス、プロトコルアドレス（ＩＰ、DECNet、EtherTalk、ＩＰＸ、またはＣＬＮＳ）、またはトランスポート（移送）アドレス（ＩＰポート番号、など）、またはこれらの組み合わせであってもよいが、この構成ではＩＰアドレスのみが使用される。観察されるトラヒックフローは1組の規則によって特定され、‘マネージャ’プログラムによってNeTraMetへダウンロードされる。トラヒックフローデータは、‘コレクタ’プログラムからＳＮＭＰ（簡単なネットワーク管理プロトコル、Simple Network Management Protocol）を介して集められる。
【００６５】
図８は、ネットワークオペレータによって判断される主要な料金が時間においてどのくらい変化するかを示している。図８において、曲線Ａはある瞬間におけるネットワークのローディングを反映するように計算されたスポット価格である。曲線Ｂは多数の異なる料金バンドの１つである。異なる料金バンドは、異なる持続性をもち、顧客はより大きい安定性を与える帯域に対して割り増し料金を支払う。料金は、ネットワークによって保持されるチャンネル階層を使用して顧客端末に通信される。顧客とサービスプロバイダとの間の最初の契約において、単一のチャンネルアドレスは一般的に数ヶ月離れて分配された新しいアナウンスメントを保持する（新しいアナウンスメントは、例えば、契約変更、傾聴用の第２のレベルのチャンネルを料金用に特定する新しいサービス、または新しい料金構造を取扱うための新しいコードをダウンロードするために行われる）。第２のレベルのチャンネルは、最も持続性の情報に対して第３のチャンネルのアドレスを単にアナウンスする更新を数時間後に伝える。これらの第３のレベルのチャンネルは、１秒未満の間隔で更新を実行することができる。多くのサービスの価格は、1つのチャンネルにおいて実行することができる。最大の効率については、この１つのチャンネルは最高の揮発性をもついくつかのチャンネルに何度かにわたり分割されて、より安定した期間で単一のチャンネルに再び集められてよい。
【００６６】
後に記載した表１ないし７は、２つの異なる料金を構成するのに使用されるジャバ源コードを示している。表１のコードは、顧客システムと顧客システムによってダウンロードされる料金アルゴリズムとの間の通信に使用される動作を設定する。表２は線形料金アルゴリズムを示し、このアルゴリズムにおいて料金は輻輳パラメータと一緒に顧客によって送られたパケットと受取られたパケットの合計に依存する。表３はこの場合に顧客のディスプレイを生成するコードを示す。表４はネットワークオペレータサーバにおいて料金を表示するのに使用されるコードを示す。表５は明示的な料金アルゴリズムを示す。表６は顧客表示を生成し、表７および表８は明示的な料金アルゴリズムに対するオペレータ表示を示す。ジャバコードをダウンロードして、ユーザインターフェイスを生成することによって、このインターフェイスを特定の料金の条件に合わせて作り、料金の変化に適合させることができる。
【００６７】
上述ではインターネットのような連結されたパケットデータネットワークコンテキストにおける例を開示したが、本発明の多くの態様は回路交換ＰＳＴＮ（公衆交換電話ネットワーク）のような他のタイプのネットワークにも利用できる。図１６はこのコンテキストに応用される本発明の例を示す。このネットワークでは、顧客端末81、この例ではマイクロプロセッサとデータインターフェイスを組込んだ電話である、いわゆるインテリジェント電話は、ローカル交換82およびトランク交換３を介して電話ネットワークへ接続される。トランク交換83は、ＳＳ７（シグナリングシステム番号７）のシグナリングネットワークを介して、高度な呼制御機能を実行する責務を負うサービス制御ポイント85へ接続される。サービス制御ポイント85は、請求書発行オペレーションに対して責務を負い、さらにこの例では、ネットワークにおける料金設定を制御するオペレーショナルサポートサーバ86へも接続される。ＯＳＳサーバおよび顧客端末は、料金エンティティ（ＴＥ）を含む。固定ＰＳＴＮネットワークはさらに、ゲートウエイ87を介してセルラＧＳＭネットワーク88へ接続される。セルラネットワーク内の基地局ＢＳは、インテリジェント移動電話89へ信号を通信する。動作において、ネットワーク料金は、ＰＳＴＮネットワークおよびＧＳＭネットワークを介して顧客端末へ分配される。従来料金はここでも、顧客端末内のプロセッサ上で実行されるジャバ機能の形態を取ってもよい。ジャバ機能は、インターネットパケットとしてストリームにされる。１つの構成では、これらのインターネットパケットは、ＰＳＴＮネットワークおよびＧＳＭネットワーク、それら自体を介して分配することができる。例えば、パケットは、ＭＴＰ（メッセージトランスポートパート）のトランスポート層を使用してトランク交換へエンカプシュレートして、移送され、バンド外シグナリングを使用して顧客端末へオンワードへ通信することができる。その代わりに、別々のデータ接続をＯＳＳサーバと顧客端末との間で公衆インターネットを介して設定することができる。上述の例では、ネットワークオペレータはネットワーク内の資源のローディングをモニタし、顧客端末内の料金エンティティに信号を送って、不足または他の関連する資源を反映するように料金を変更することができる。顧客端末、それら自体はネットワークローディングをモニタし、自動的に種々の料金を生成することができる。ネットワーク資源の使用度は、ネットワーク内で実行される従来の請求書発行の代わりに顧客端末によってローカルに測定することができる。ネットワークオペレータは、上述のように、サンプリングを実行することによって使用データの測定を管理することができる。
【００６８】
【表１】

【００６９】
【表２】

【００７０】
【表３】

【００７１】
【表４】

【００７２】
【表５】

【００７３】
【表６】

【００７４】
【表７】

【００７５】
【表８】

【００７６】
【図面の簡単な説明】
【図１】 本発明を実現するネットワークを示す模式図。
【図２】 料金関数を示すグラフ（図２ａ、２ｂ、および２ｃ）。
【図３】 異なるサービスバイトのフォーマット。
【図４】 図１のネットワークで使用する課金アーキテクチャの構成要素のオブジェクトを示す模式図。
【図５】 図１のネットワークで使用する課金アーキテクチャの構成要素のオブジェクトを示す模式図。
【図６】 図４および５の口座オブジェクト間で送られるデータを示す図（図６ａおよび６ｂ）。
【図７】 ネットワークドメイン内の顧客端末上のプロトコルスタックを示す模式図。
【図８】 時間にしたがう料金変化を示すグラフ。
【図９】 ソフトウエアおよび測定オブジェクトに対するクラスダイヤグラム。
【図１０】 ソフトウエアおよび測定オブジェクトに対するクラスダイヤグラム。
【図１１】 ソフトウエアおよび測定オブジェクトに対するクラスダイヤグラム。
【図１２】 ソフトウエアおよび測定オブジェクトに対するクラスダイヤグラム。
【図１３】 ソフトウエアおよび測定オブジェクトに対するクラスダイヤグラム。
【図１４】 図９ないし１３のオブジェクトで使用するグラフィックユーザインターフェイス（ＧＵＩ）を示すダイヤグラム。
【図１５】 料金オブジェクトを構成するソフトウエアに対するクラスダイヤグラム。
【図１６】 別の実施形態を示すダイヤグラム。

Claims (16)

1. 通信ネットワーク内で使用されるタリフを変更する方法において、顧客端末において検出されたネットワークローディングに依存して、顧客端末によるネットワーク使用に対するタリフを顧客端末において自動的に変更するステップを含む方法。
2. 顧客端末においてネットワークローディングに依存するネットワーク動作パラメータを検出して、ネットワーク動作パラメータに依存してタリフを変更するステップを含む請求項１に記載の方法。
3. ネットワークがパケットネットワークであり、ネットワーク動作パラメータがデータ源と顧客端末との間の伝送中に損失したパケット数である請求項２に記載の方法。
4. 顧客端末において輻輳信号を検出し、該輻輳信号に応答してタリフを変更するステップを含む請求項１に記載の方法。
5. 顧客端末において受け取られたデータパケットから顧客端末における輻輳信号を読み取るステップを含む請求項４に記載の方法。
6. ルータにおける輻輳の検出に応答してネットワーク内のルータにおいて輻輳信号を生成するステップを含む請求項４または請求項５に記載の方法。
7. 最初に輻輳が検出されたときに、最初のタリフの増加を行い、輻輳が持続する場合には、少なくとも１つのさらなる大きいタリフの増加を行うステップを含む請求項１ないし請求項６の何れか１項に記載の方法。
8. ユーザが判断する価格基準で顧客端末において決定エージェントをプログラムし、前記価格基準でタリフを使用して計算された価格を比較するステップを含む請求項１ないし請求項７の何れか１項に記載の方法。
9. 通信ネットワークを介して複数の端末へタリフアルゴリズムを配送し、各端末においてこのタリフを使用して、端末によるネットワーク使用に対する料金を計算するステップを含む請求項１ないし請求項８の何れか1項に記載の方法。
10. ネットワークによって実行されるステップとして、
    顧客端末とネットワークとの間のトラヒックを断続的にサンプリングし、このサンプリングの一部として、顧客端末に影響を与えるネットワークローディングを記録するステップと、
    サンプリングされたトラヒックに関して、顧客端末によって計算される料金と予想される料金とを比較して、不一致を検出するステップ、
    とをさらに含む請求項９に記載の方法。
11. 顧客端末が、データ源からネットワークを介して顧客端末へ送られるデータにおける輻輳を検出するとき、顧客端末が輻輳通知信号をデータ源へ戻す請求項１ないし請求項１０の何れか1項に記載の方法。
12. 顧客端末において、タリフが固定される期間を選択し、前記期間の継続期間に依存して割り増しを支払うステップを含む請求項１ないし請求項１１の何れか1項に記載の方法。
13. 端末が検出された輻輳に応答して出力を減じない場合にのみタリフが変更される請求項１ないし請求項１２の何れか1項に記載の方法。
14. 通信ネットワークにおいて使用する顧客端末において、
    使用の際に、顧客端末が接続されているネットワークのローディングを検出する手段と、
    前記検出する手段に応答し、顧客端末によるネットワーク使用タリフを自動的に変更するように構成された手段とを含む顧客端末。
15. 前記検出する手段とタリフを変更する手段は、
    顧客端末が接続されたネットワーク内で資源のローディングを検出するステップと、
    顧客端末によるネットワーク使用に対するタリフを検出されたローディングに依存して自動的に変更するステップと、
    を連続的に実行するように構成された少なくとも１のプロセッサを備える、請求項１４に記載の顧客端末。
16. 顧客端末において局所的にネットワークローディングを検出する手段と、
    前記検出する手段に応答して、顧客端末によるネットワーク使用に関するタリフを自動的に変更する手段であって、該タリフは該顧客端末に特定のものであるものと、
    を含む通信ネットワーク。

Images