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

Description

【０００１】
発明の属する技術分野
本発明は、通信ネットワーク、とくに通信ネットワークにおける課金機構に関する。
【０００２】
従来の技術
従来の通信ネットワーク、例えば国内のＰＳＴＮ（公衆交換電話ネットワーク）において、相当な割合いのネットワーク資源はネットワーク使用の測定および請求書発行に専用である。調査ではこれらの資源は遠隔通信会社の運用コストの６％ほどを消費すると推定している。対照的にインターネットは概して、個々の顧客に対しての測定および請求書発行機構を組入れていない。計測および請求書発行をサポートするのに要求されるネットワークのインフラストラクチャがないので、インターネットの操作コストは従来の電話ネットワークと比較して低くなり、インターネットの急速な拡大を促進した。しかしながら適切な請求書発行機能がないことは、インターネットによって保持されるトラヒックの特徴における重要な欠点であり：インターネットではネットワーク資源の使用の浪費を助長し、例えば保証されたサービス品質（ＱｏＳ）を要求する新しいアプリケーションをサポートするネットワークのインフラストラクチャへの投資に対する誘因（インセンティブ）を低減する。
【０００３】
発明が解決しようとする課題
本発明の第１の態様にしたがって、通信ネットワークを動作する方法であって、
通信ネットワークを介して、該通信ネットワークに接続された多数の顧客端末へ料金を分配することと、
前記料金を使用して、料金が当てはめられるネットワークの顧客端末によって、使用に対する課金を計算することとを含む方法を提供する。
【０００４】
明細書および特許請求の範囲において“ネットワークに接続された”端末という表現は、ネットワークに一時的にログオンするモバイルワイヤレスデータ端末のような端末、ネットワークへワイヤレス接続をする他の端末、および固定ラインによってネットワークへ永久的に（常設）接続する端末に対して使用される。例えばモバイル端末はネットワークへログオンして、料金を受取り、次にオフライン中に課金を計算することができ、このような構成は本発明の第１の態様の技術的範囲内に含まれる。
本発明の別の態様にしたがって、該通信ネットワークを動作する方法であって、
通信ネットワークを介して、通信ネットワークに接続された多数の顧客端末へ料金を分配することと、
顧客端末において顧客端末によるネットワーク資源の使用を測定することと、
前記料金と一緒に測定する前記段階の結果を使用して、顧客端末による料金が当てはめられるネットワークの使用に対する課金を計算することとを含む方法を提供する。
【０００５】
本発明のこれらの態様は、例えばインターネットにおいて、または端末がデータ処理能力をもつ他のネットワーク内の従来の請求書発行機構に代わるものとして使用するのに適した重さが軽い課金機構を提供する。この軽量の課金機構はネットワークのインフラストラクチャから測定および請求書発行の負担を取除き、その代わりに料金を顧客端末へ分配して、ネットワークの端部において課金を計算することができる。このアプローチは従来のアプローチと比較してはるかに優れたスケーラビリティを提供し、したがってインターネットのような急速に増大しているネットワークにおいて使用するのにとくに適している。
料金アルゴリズムは、前記料金が当てられる通信ネットワークを介して多数の顧客端末へ分配されるのが好ましい。好ましい構成では、課金機構は、ネットワークを介して分配された料金メッセージが遅延または損失しても機能するように設計されている。料金を分配する段階は、ネットワーク使用の課金を計算する式、および前記式で使用する計数を別々に通信する段階を含むことが好ましい。
【０００６】
課金におけるネットワークのオーバーヘッドは課金アルゴリズムをユーザに与え、料金が課金されるときに関係する係数のみを更新することによってさらに低減することができる。
【０００７】
課金に対するネットワークのオーバーヘッドは、ユーザに料金アルゴリズムを与えて、料金が変化するとき、関係する係数のみを更新することによってさらに低減される。
【０００８】
この方法は、ネットワーク資源のローディングを測定し、ローディングを測定する前記段階の結果に依存して改定した料金を判断することを含むことが好ましい。
【０００９】
本発明の別の重要な長所は、これが特定の資源の不足を反映するように料金を修正することによってネットワーク資源の使用の制御を容易にすることである。
ローディングを測定し、修正した料金を判断する段階は、ネットワーク管理プラットフォームによって自動的に実行される。その代わりにおよび好ましくは輻輳を価格上昇にマッピングするアルゴリズムはネットワーク内に分配され、好ましくは顧客のところに置かれる。好ましくはこの方法は、通信ネットワーク上の複数の異なるサービスを実行すること、異なる各サービスに対する異なる料金を複数の顧客端末へ通信すること、および各サービスの実行条件に依存して各料金を選択的に変化させることを含む。
【００１０】
種々のサービスは、異なるレベルのＱｏＳのみによって識別されるか、または種類が異なっていてもよい。本発明のこの態様は、例えば請求書発行が中央で行われ、料金が情報のみにおいてエンドユーザへ通信されるとき、他の従来のネットワークでも使用することができる。
【００１１】
本発明のさらに別の態様にしたがって、通信ネットワークを動作する方法であって、
複数の異なるサービスをネットワーク上で実行すること、
異なるサービスに対する料金を共通の料金分配機構を介して多数の顧客端末へ通信することと、
各サービスの実行条件に依存して各料金を選択的に変更することとを含む方法を提供する。
【００１２】
本発明の別の態様にしたがって、通信ネットワークを動作する方法であって、
多数の顧客の各々に対して、複数の異なる料金から選択した１つの料金を使用して、ネットワークに接続された各顧客端末によってネットワーク資源の使用に対する課金を計算することと、
ネットワーク資源のローディングを測定すること、
ネットワーク資源のローディングに依存して複数の異なる料金の１以上（単数または複数の意）を変更して、複数の異なる料金中の異なる料金が異なるそれぞれの揮発性をもつようにすることとを含む方法を提供する。
【００１３】
この態様では、顧客に異なる揮発性の度合いで変化する料金を用意する。したがってより大きい安定性を必要とする顧客は、割り増し料金を支払って、この安定性を達成するが、一方で料金におけるより長い期間の変化が行われるまで、ネットワークオペレータが需要における短期間の変動を管理できる一定の範囲のより高い揮発性が依然として残ることになる。
【００１４】
本発明の別の態様にしたがって、通信ネットワークを動作する方法であって、ネットワークのアクセス点において単一のブロッキング試験のみをネットワークへ入るトラヒックに適用する方法を提供する。
【００１５】
これまでは、インターネットのようなネットワークは単一のサービスネットワークとして動作していた。しかしながら現在は、インターネットはマルチサービスネットワークになることが提案されている。インターネットは、例えば異なるアプリケーションに対する多数のＱｏＳレベルをサポートするか、または全顧客にではなく、一部の顧客に対するマルチキャストおよびユニキャストの両方のサービスを提供する。本発明の発明者は、従来のアクセス制御方法を使用して、これがマルチサービスネットワークへのアクセス時に多数の試験を積み重ねて（built-up）、各パケットにおいていずれのサービスが要求されるかを判断し、関係する顧客によって支払われたサービスであるか否かを検査することに通じていることを認識した。本発明のこの態様では、ネットワークの悪用に対して顧客を科料に処するか否かを検査する単一のブロッキング試験を行うことによってこの欠点を克服している。これが当てはまるときは、関係するパケットをネットワーク上で送って、全ての試験が通るのを待っている間パケットをブロックするのではなく、全ての他の適切な検査を並行して行なう。次の試験が失敗する、例えば顧客が支払っていないＱｏＳレベルをパケットが使用するとき、例えば顧客によってログされた手付金から科料を借り方へ記入することによって適切な処罰が課される。
【００１６】
本発明の別の態様にしたがって、通信ネットワークを動作する方法であって、
ａ）料金データを、ネットワークに接続されたユーザ端末へ通信することと、
ｂ）ユーザ端末において料金データを使用して、ネットワークと端末との間で通信されるトラヒックに対する課金を計算して、支払いを行うことと、
ｃ）ユーザとネットワークとの間で通信されるトラヒックの一部のみをサンプリングして、サンプル採りされたトラヒックにおいて、ユーザによって行われた支払いと料金の支払期限とを比較することとを含む方法を提供する。
【００１７】
本発明の別の態様にしたがって、通信ネットワークを動作する方法であって、
ａ）顧客端末においてネットワーク使用を測定することと、
ｂ）顧客端末からネットワークオペレータへネットワーク使用データを通信することと、
ｃ）ネットワークオペレータが顧客端末とネットワークとの間で通信されるトラヒックの一部のみをサンプリングし、サンプル採りされたトラヒックにおいてネットワーク使用と顧客端末からのネットワーク使用データとを比較し、不一致を検出することとを含む方法を提供する。
【００１８】
本発明のこの態様は、上述の態様の１つ以上に関連して使用することが好都合であるが、それらを別々に使用してもよい。例えば顧客端末が使用データを測定し、現在の料金へアクセスせずに、このデータをネットワークオペレータへ送ってもよい。したがってネットワークオペレータは関連する料金を適用して、ユーザ自身のデータに基いてユーザに請求書を発行してもよい。ネットワーク使用データが信頼できることを保証するために、このデータをサンプル採りされた期間においてネットワークオペレータ自身の測定に基いて期待される使用データと比較してもよい。データが一致するとき、他の期間のデータが信頼できると仮定される。その代わりに顧客端末に料金を与えることができ、使用データを明示的に通信するのではなく、顧客は使用に対する課金を計算する。使用に対する課金の支払、または相当する口座情報をネットワークオペレータに通信して、測定された使用データは通信中に暗黙のうちに存在する。
【００１９】
本発明の別の態様にしたがって、通信ネットワークを動作する方法であって、顧客端末において検出されたネットワークローディングに依存して、顧客端末によるネットワーク使用に対する料金を自動的に変化させることを含む方法を提供する。この態様は本発明の他の態様に関して使用してもよい。
【００２０】
後で開示し、また特許請求の範囲に記載したように、本発明の他の態様もある。本発明はさらに、通信ネットワーク、管理プラットフォーム、本発明の方法にしたがって動作するようにされたルータ並びにコンピュータ端末、および異なる態様の１以上において本発明を実行するプログラムを生成するコンピュータ可読メモリ媒体を含む。
【００２１】
発明の実施の形態
ここで本発明を具現するシステムを、例示的に添付の図面を参照してさらに詳しく記載することにする。
【００２２】
図１に示したように、通信ネットワーク１は多数のネットワークサブドメイン２Ａないし２Ｃを含む。ネットワークのサブドメインは、異なるオペレータの制御のもとに置かれるが、この異なるオペレータは互いに信頼していなくてもよい。ネットワークのサブドメインはゲートウエイルータ３，４によって相互接続されている。本発明において通信ネットワークはインターネットであり、ユニキャストおよびマルチキャストインターネットプロトコル（ＩＰ）と関係するプロトコルの両方をサポートする。顧客端末５は、公衆交換電話ネットワーク（ＰＳＴＮ）６およびアクセスルータ７を介してサブドメイン２Ａへ接続されている。このアクセス点において単一のブロッキング試験がトラヒックに適用される。ゲートウエイルータ３、４およびアクセスルータ７はそれぞれ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）”を規定し、例えばパケットをより低いまたはより高い優先度で一致させることによって、ルータがパケットをどのように処理するかをビットで示す。ＤＳバイトの特定の形態において、ビット６ないし７は明示的な輻輳通知（ＣＥＮ）に対して使用される。これらのビットの１つは、パケット通路内のルータがＥＣＮフィールドを設定することができるか否かを示し、他のビットは輻輳、または潜在的に輻輳を導くローディングが発生するときに、（ＥＣＮ能力ルータによって）設定されるフラグとして使用される。ランダムな初期検出（ＲＥＤ）アルゴリズムは現在ルータにおいて実行されている。これらのアルゴリズムは、ルータのパケットバッファ内の平均の待ち行列長を測定する。明示的な移動平均が計算される。平均待ち行列長が所定の閾値を越えるとき、ルータは輻輳が発生していることを信号で知らせる。通常このシグナリングは、単にパケットをドロップすることによって行われてきた。しかしながらＣＥＮ方式のコンテキストにおいて、ルータは、パケットをドロップする代わりに、パケットヘッダ内にＥＣＮビットを設定して、輻輳が発生していることを示す。これは確率的に達成される：すなわちルータを通るパケットの一部のみが指定される。指定されるパケットの確率は、平均的な待ち行列の大きさにしたがって増す。まれな場合には、待ち行列は、ルータバッファがいっぱいになる長さを増加し、次にＥＣＮビットを設定するのではなく、パケットをドロップする。この場合、ＥＣＮビットは全ての残りのパケットに対して設定される。
【００５６】
動作において、クライアント端末５がサーバ９上のデータ源にアクセスしているとすると、輻輳は、例えばネットワークサブドメイン２Ｂおよび２Ｃをリンクするルータ４において発生する。ルータ４におけるＲＥＤに類似したアルゴリズムは、指数関数的な移動平均を使用して計算されるように、ルータバッファの待ち行列長が、所定の閾値を越えていることを検出する。サーバ９からクライアント端末を経由するパケットのいくつかは、ルータ９によって設定されるＤＳバイトのＥＣＮビットをもち、輻輳が発生している事実に注目する。クライアント端末において、到来パケットのヘッダにおけるＤＳバイトが読み取られる。指定されたＥＣＮを含むパケット数の移動平均が計算される。この平均は、割り増し料金を計算するのに使用される輻輳パラメータＣ_１を与える：
ΔＰ＝ｆ（Ｃ_１）
次にユーザに対する合計金額Ｐ_ＴＯＴは主要な料金アルゴリズムおよび割り増し料金アルゴリズムによって判断される価格を一緒に加算することによって計算される：
Ｐ_ＴＯＴ＝Ｐ＋ΔＰ
この合計金額は、クライアント端末上で実行されるコスト決定エージェントへ送られる。このコスト決定エージェントは、ユーザの規定された規則でプログラムされる。これらは、例えば一定時間における平均をとられた合計コストが所定の閾値、毎分０．０１ポンドよりも低い限りシステムが接続の処理を進めることをコスト決定エージェントが承認すること、およびコスト決定エージェントが接続をサスペンドし、コストが閾値よりも高くなるときにユーザに警報することを記述している。その代わりに、既に記載したように、コスト決定エージェントは、いくつかのアプリケーションを同時に処理すること、およびアプリケーションの１つによってアクセスされるデータ源に対する割り増し料金が増加するとき、このアプリケーションの１つをスローダウンすることができる。
【００５７】
記述を簡単にするために、上述では輻輳に応答する料金のローカルな変化を独立させると記載した。実際には、この機構は概ね輻輳に対する他の応答および料金を変化する他の源と結合される。さらに、輻輳にも関らず伝送を進める決定は、概ね伝送の最初と最後の両方における当事者の同意を必要とする。データ源、ネットワーク、ルータ、およびデータ受信機をもつ全システムを検討するとき、局所的に検出された輻輳に応答する料金増加（ここでは“罰金もしくは科料”とも呼ばれる）の実行は最後の手段として行われる。他の応答は、最初に次に示す番号順に実行される：
１．ネットワークは輻輳の周辺で再ルート設定をする。
２．ネットワークは、最善を尽くすサービスを含むサービスの中で、より低いサービスレベル（すなわち、ＱｏＳの関連する大きさのコンテキストでみたときにより低いサービスレベル）から容量を借りる。
３．ネットワークは余分の容量を（おそらくは自動的に）採入れる。
４．エンドシステムは、単にアクセスリンクまたはエンドシステムではなく、共有ネットワーク上に輻輳が存在するように設定する。
５．エンドシステムは、（現在のレベルの輻輳を無視することに対する罰金よりも安いときに）ＱｏＳ要求を“より高い”レベルにセットする。
６．エンドシステムは、現在のレベルの輻輳を無視したことに対する罰金が比較的に高いときに、輻輳を無視することが本質的であると決定する。
７．両方の（全ての）エンドシステムは、輻輳を無視するのに賛成する。
【００５８】
一般的に段階４においてＥＣＮ信号が生成される。段階１ないし３はこの信号の生成に先立って行われ、段階５ないし７はＥＣＮ信号を生成の後に行われる。
【００５９】
接続する処理を進め、接続に対して割り増し料金を支払う前の最後の段階は、両方の当事者による協定を設定している。したがって顧客端末が明示的な輻輳通知を受信するか、またはパケット損失のような関連するパラメータの検出することによって輻輳を検出するとき、顧客端末はこの事実を該または各エンドシステムへ戻す信号を送る。したがって本発明の例では、クライアント端末５はデータサーバ９へ信号を送り、輻輳が発生していることを知らせる。データサーバは、顧客においてエージェントと同様に実行でき、このような信号に対する応答を判断する規則でプログラムされる。例えばサーバはこれらの条件ではサービスを拒否してもよい。図１に関係して既に記載したように、この例では料金はネットワークオペレータからネットワークを通って顧客端末へマルチキャストされ、課金は“支払いおよび表示”プロセスを使用して実行される。図４および５は、この場合、課金アーキテクチャを構成するのに使用されるオブジェクトを示している。図４はより高いレベルのオブジェクトを示し、図５は、図５のアーキテクチャのソフトウエア構成で使用される構成要素のオブジェクトを示す。図４において、クライアント端末上のオブジェクトは図面の半分に“顧客”と記載して示され、アクセスルータ７および対応するネットワークサブドメイン上のオブジェクトは図面の残りの半分に“エッジネットワーク(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つのチャンネルにおいて実行することができる。最大の効率については、この１つのチャンネルは最高の揮発性をもついくつかのチャンネルに何度かにわたり分割されて、より安定した期間で単一のチャンネルに再び集められてよい。
【００６８】
使用に基いて各顧客に標準の料金を課金する代わりに、プロバイダは個々のサービスレベルの協定（ＳＬＡ）を各顧客に販売することを所望してもよい。その代わりに、顧客は（おそらくは大きい）範囲のＳＬＡの１つのもとでサービスを受けることを選択できることもある。このようなＳＬＡは、プロバイダに対して一定の割り合いのサービスのアベイラビリティ（利用可能性）、および通信トラヒックでは直接に処理できない品質の他のアスペクトを与えるという義務を含んでもよい。しかしながら、ＳＬＡはトラヒック調整協定（ＴＣＡ）を含んでもよく、提案されたＩＥＴＦ差動サービスアーキテクチャにおいてプロバイダ間およびプロバイダと主要な顧客との間であると考えられる。ＴＣＡは、顧客のトラヒックが一定のプロフィール内にあるという条件でのプロバイダのサービス品質に対する義務を含む。しばしば、トラヒックがプロフィールの外にあるという条件のもとで、ＴＣＡは依然として、プロフィール内のトラヒックのバランスに対して適用する。プロフィールは、顧客が生成すべきバーストについての最大の大きさおよび継続期間、またはピークレート、または特定のパラメータのもとでの移動平均レートを規定してもよい。理論的に、ＴＣＡは、顧客がレート制御プロトコルを使用して遠隔の送信者のレートを制御できるという仮定に基いて受取ったトラヒックに供給することができる。diffservの提案では、ＴＣＡはプロバイダのネットワークへの入り口にインストールされたトラヒック管理者によって管理される。これらは、専門のハードウエア、またはルータの機能と結合されていてもよい。トラヒックの管理者は、管理者に構成された協定されたプロフィール外にトラヒックをドロップするかまたは指定する。指定するパケットの選択はランダムである。diffservの提案では、ＤＳバイトの最初の６ビットはコードポイント（code-point）と呼ばれる。コードポイントの最後の５ビットが一定の範囲内にあるとすると、ＤＳバイトの最初のビットは、パケットがプロフィールの外にあるか否かを示すフラグとして使用することができる。プロフィールの外のパケットは依然として送られるが、パケットは下流ルータの輻輳した待ち行列にドロップする最初の優先順位をとる。diffservの提案はさらに、管理者をプロバイダの管理者と直列に動作して、プロフィール外のパケットを指定してもよい。顧客のアプリケーションの制御のもとで行われるとき、これは、アプリケーションに対する重要性に基いて何れのパケットを指定するかを顧客が選択できる。
【００６９】
別のアプローチでは、プロバイダが従来のトラヒック管理者を動作する必要をなくした。顧客は依然として、diffservの提案によって示されるようにパケットを指定する。しかしながらプロバイダはサンプルごとにトラヒックを測定するだけである。測定値はＴＣＡに対するトラヒックの一致を検査するが、送ることができるデータ流と並列して動作し、一方でルータ内のパケットヘッダのメモリコピーの測定を進める。トラヒックがプロフィール外であるとき、顧客は科料に処される。例えば、顧客は切り捨てられるか、罰金を負わすか、またはクレジットレーティングが低減する。これは、パケットを指定するかまたはドロップすることによってプロフィール外のパケットを‘科料’を課す従来のトラヒック管理者とは対照的である。この従来のアプローチにおいて、パケットは管理検査を通過するまで送付できない。パケットは送付されると、指定したり、ドロップしたりできなくなる。
【００７０】
このアプローチの長所は、送信が管理よりもかなり迅速なことである。例えば全ての光技術を送信に使用すると、管理を実行することはかなり複雑になるので、将来光学系で達成する可能性は低い。提案されたアプローチを使用すると、トラヒックのサンプルは、帯域外の電子回路内で管理されることになる光流をタップオフすることができる。サンプリングレートを選択して、トラヒックは管理者へ送られる前にバッファをいっぱいにすることができる。したがって管理者は、バッファを空にすることによってサンプル間の光学系に‘追いつく’ことができる。これは、臨界の（最も遅い）経路によって強制される平行なプロセスからの最大の振舞いの利得に関するアムダール（Amdahl）の法則を応用している。
【００７１】
後に記載した表１ないし７は、２つの異なる料金を構成するのに使用されるジャバ源コードを示している。表１のコードは、顧客システムと顧客システムによってダウンロードされる料金アルゴリズムとの間の通信に使用される動作を設定する。表２は線形料金アルゴリズムを示し、このアルゴリズムにおいて料金は輻輳パラメータと一緒に顧客によって送られたパケットと受取られたパケットの合計に依存する。表３はこの場合に顧客のディスプレイを生成するコードを示す。表４はネットワークオペレータサーバにおいて料金を表示するのに使用されるコードを示す。表５は明示的な料金アルゴリズムを示す。表６は顧客表示を生成し、表７および表８は明示的な料金アルゴリズムに対するオペレータ表示を示す。ジャバコードをダウンロードして、ユーザインターフェイスを生成することによって、このインターフェイスを特定の料金の条件に合わせて作り、料金の変化に適合させることができる。
【００７２】
料金のマルチキャスティングを使用して、異なるサービスプロバイダからネットワークサービスにおけるマーケットをサポートすることができる。図１７はこの場合に顧客端末に採用された変更形のユーザインターフェイスを示す。このユーザインターフェイスは、例えば顧客が、データ、オーディオ、およびビデオアプリケーションを含むマルチキャストオーディオ−ビデオ会議を要求するときに適応することができる。スライダ式の制御インターフェイスを使用して、各構成要素のデータ流に対する要求される品質Ｑレベルを設定する。したがって基礎となるアプリケーションは、Ｑパラメータを、要求されるバンド幅、パケット損失、および待ち時間のような適切な実行パラメータへ変換する。顧客端末は２つのサービスプロバイダまたはネットワークオペレータ、ＳＰ１およびＳＰ２からマルチキャスト料金を受取る。ユーザインターフェイスは、現在選択されたサービスプロバイダＳＰ１におけるコストを表示することに加えて、さらに他のサービスプロバイダＳＰ２を選択したときのコストを表示する。ユーザはデータ流の１または全てに対して第２のサービスプロバイダＳＰ２にスイッチすることを選択してもよい。例えば図に示した例におけるビデオデータ流の現在のコストは、第２のサービスプロバイダへスイッチすることによって相当に低減される。スイッチをする決定は、ユーザによって手作業で行われることができるか、または顧客端末上で実行されているソフトウエアエージェントを通して自動化してもよい。図１に示したネットワークのコンテキストにおいて、異なるプロバイダへのスイッチは、顧客端末モデムを使用して異なる番号をダイヤルすることによって行うことができ、したがってＰＰＰ接続は、恐らくは異なるネットワークドメイン上で異なるアクセスプロバイダを介して行われる。サービスプロバイダ間のこのようなスイッチングは、インターネットプロトコルバージョン６のようなプロトコルを使用するときに容易になり、インターネットプロトコルバージョン６は、提案された構成において、ホストおよびサイトアドレスの両方を提供し、ホストアドレスは、サイトＩＰアドレスが変化しても安定したままである。この場合に、顧客端末はホストアドレスとサイトアドレスの両方をもち、サイトアドレスはサービスプロバイダをスイッチするときに変化するが、ＩＰアドレスは一定のままである。
【００７３】
上述ではインターネットのような連結されたパケットデータネットワークコンテキストにおける例を開示したが、本発明の多くの態様は回路交換ＰＳＴＮ（公衆交換電話ネットワーク）のような他のタイプのネットワークにも利用できる。図１６はこのコンテキストに応用される本発明の例を示す。このネットワークでは、顧客端末81、この例ではマイクロプロセッサとデータインターフェイスを組込んだ電話である、いわゆるインテリジェント電話は、ローカル交換82およびトランク交換３を介して電話ネットワークへ接続される。トランク交換83は、ＳＳ７（シグナリングシステム番号７）のシグナリングネットワークを介して、高度な呼制御機能を実行する責務を負うサービス制御ポイント85へ接続される。サービス制御ポイント85は、請求書発行オペレーションに対して責務を負い、さらにこの例では、ネットワークにおける料金設定を制御するオペレーショナルサポートサーバ86へも接続される。ＯＳＳサーバおよび顧客端末は、料金エンティティ（ＴＥ）を含む。固定ＰＳＴＮネットワークはさらに、ゲートウエイ87を介してセルラＧＳＭネットワーク88へ接続される。セルラネットワーク内の基地局ＢＳは、インテリジェント移動電話89へ信号を通信する。動作において、ネットワーク料金は、ＰＳＴＮネットワークおよびＧＳＭネットワークを介して顧客端末へ分配される。従来料金はここでも、顧客端末内のプロセッサ上で実行されるジャバ機能の形態を取ってもよい。ジャバ機能は、インターネットパケットとしてストリームにされる。１つの構成では、これらのインターネットパケットは、ＰＳＴＮネットワークおよびＧＳＭネットワーク、それら自体を介して分配することができる。例えば、パケットは、ＭＴＰ（メッセージトランスポートパート）のトランスポート層を使用してトランク交換へエンカプシュレートして、移送され、バンド外シグナリングを使用して顧客端末へオンワードへ通信することができる。その代わりに、別々のデータ接続をＯＳＳサーバと顧客端末との間で公衆インターネットを介して設定することができる。上述の例では、ネットワークオペレータはネットワーク内の資源のローディングをモニタし、顧客端末内の料金エンティティに信号を送って、不足または他の関連する資源を反映するように料金を変更することができる。顧客端末、それら自体はネットワークローディングをモニタし、自動的に種々の料金を生成することができる。ネットワーク資源の使用度は、ネットワーク内で実行される従来の請求書発行の代わりに顧客端末によってローカルに測定することができる。ネットワークオペレータは、上述のように、サンプリングを実行することによって使用データの測定を管理することができる。
【００７４】
【表１】

【００７５】
【表２】

【００７６】
【表３】

【００７７】
【表４】

【００７８】
【表５】

【００７９】
【表６】

【００８０】
【表７】

【００８１】
【表８】

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

Claims (28)

1. パケットベースのインターネットワーキングプロトコルをサポートする通信ネットワークを動作する方法であって、
   該通信ネットワークの顧客端末による使用に関して該通信ネットワークの負荷の関数として料金を計算するための計算式をタリフとして生成するのに使用できるタリフ情報を、該通信ネットワークを介して、該通信ネットワークに接続された多数の顧客端末へ配送するステップと、
   顧客端末で、前記タリフを使用して、該通信ネットワークの顧客端末による使用に対する料金を計算するステップとを含み、
   該タリフにおいて使用されるパラメータは顧客端末において局所的に測定可能である、方法。
2. 該タリフ情報を配送するステップは、ネットワーク使用料金の計算のための計算式と、前記計算式で使用する係数とを別々に通信するステップを含む請求項１に記載の方法。
3. 該タリフ情報が、マルチキャスティングによって顧客端末へ配送される請求項１または請求項２に記載の方法。
4. 顧客端末へ改定されたタリフ情報を配送する別のステップを含む請求項１ないし請求項３の何れか1項に記載の方法。
5. 改定されたタリフ情報を配送する前記ステップが、顧客端末へ前に配送された計算式の中で使用する改定された係数を通信するステップを含む請求項４に記載の方法。
6. ネットワーク資源の負荷を検出するステップと、負荷を検出する前記ステップの結果に依存して改定されたタリフを判断するステップとを含む請求項４または請求項５に記載の方法。
7. 負荷を検出する前記ステップと改定されたタリフを判断する前記ステップが、ネットワーク管理プラットフォームによって自動的に実行される請求項６に記載の方法。
8. 負荷を検出する前記ステップと改定されたタリフを判断する前記ステップが、顧客端末で自動的に実行される請求項６に記載の方法。
9. 第１の所定の通信チャンネルを識別するデータを顧客端末に通信し、次に顧客端末において前記タリフに関係する通信に対して前記通信チャンネルをモニタするステップを含む請求項１ないし請求項８の何れか1に項記載の方法。
10. 少なくとも１の別の通信チャンネルを識別するデータを前記第１の通信チャンネル上で通信するステップを含み、顧客端末が次に該または各別のチャンネルを加えてモニタする請求項９に記載の方法。
11. 新しい通信チャンネルを採り入れるステップと、以前に識別された通信チャンネルの負荷に依存して顧客端末への以前に識別された通信チャンネル上で前記新しい通信チャンネルを識別するステップとを含む請求項１０に記載の方法。
12. 暗号化されたタリフデータを顧客端末へ通信し、顧客端末で前記タリフデータを復号するステップを含む請求項１ないし請求項１１の何れか1項に記載の方法。
13. 該タリフデータは顧客端末に位置した保安モジュール内で復号される請求項１２に記載の方法。
14. 複数の異なる通信チャンネル上で異なるタリフデータを通信し、顧客端末において複数の通信チャンネルの1つでタリフデータに特定のキーを提供するステップを含む請求項１２または請求項１３に記載の方法。
15. 異なるそれぞれの変動率を有する異なるタリフを多数の顧客端末の異なるそれぞれの１へ通信するステップを含む請求項１ないし請求項１４の何れか１項に記載の方法。
16. 多数の顧客の各々に対して、複数の異なるタリフの中から選択された１を用いて、ネットワークに接続されたそれぞれの顧客端末によるネットワーク資源の使用に対する料金を計算するステップと、
    ネットワーク資源の負荷を測定するステップと、
    ネットワーク資源の負荷に依存して複数の異なるタリフの少なくとも１を変更するステップとを含む請求項１５に記載の通信ネットワークを動作する方法。
17. 顧客端末においてタリフデータを用いてネットワークと端末との間で通信されたトラフィックに対する料金を計算し、支払を行うステップと、
    顧客端末のユーザとネットワークとの間で通信されたトラフィックの一部のみをサンプリングし、該サンプリングされたトラフィックに関して該ユーザによって行われた支払とタリフにしたがった支払期限とを比較するステップと、
    を含む請求項１ないし請求項１６のいずれか１項に記載された方法。
18. ａ）ネットワークユーザとネットワークオペレータとの間の契約を設定し、ユーザ契約データを記憶するステップと、
    ｂ）該ネットワーク上のユーザに対する或いはユーザからのトラフィックの一部のみをサンプリングするステップと、
    ｃ）サンプリングされたトラフィックと該ユーザにより契約されたトラフィックとを比較するステップと、
    ｄ）サンプリングされたパラメータと契約されたパラメータとの間に不一致が検出されたときにユーザ状態を修正するステップと、
    を含む請求項１ないし請求項１７のいずれか１項に記載された方法。
19. ネットワークユーザとネットワークオペレータとの間で契約を設定するステップが、ネットワーク使用に対して前払いするステップを含む請求項１８記載の方法。
20. 契約を設定するステップが、トラヒック調整協定ＴＣＡを各顧客と関係付けるステップを含む請求項１８または請求項１９に記載の方法。
21. ユーザ状態を修正するステップがユーザに罰金を科すステップを含む請求項１８ないし請求項２０のいずれか１項に記載の方法。
22. ステップａ）においてユーザがネットワークオペレータへデポジットを送り、このデポジットが、サンプリングされたパラメータと契約されたパラメータとの間の不一致が検出されたときにステップｄ）においてデビットされる請求項１８に記載の方法。
23. 通信ネットワークを介して、該通信ネットワークに接続された多数の顧客端末へタリフ情報を配送するステップと、
    顧客端末において該顧客端末によるネットワーク資源の使用を測定するステップと、
    前記タリフ情報と共に前記測定するステップの結果を使用して、該顧客端末によるネットワークの使用に対する料金を計算するステップと、
    を含む請求項１ないし請求項２２のいずれか１項に記載の方法。
24. 複数の異なるサービスプロバイダから各顧客端末へ異なるタリフを通信して、顧客端末においてサービスプロバイダを選択して、選択されたサービスプロバイダを介してネットワークサービスを受け取るステップを含む請求項１ないし請求項２３の何れか1項に記載の方法。
25. 通信ネットワーク上で複数の異なるサービスを実行して、異なるそれぞれのサービスに対する異なるタリフを多数の顧客端末へ通信して、それぞれのサービスの実行条件に依存するそれぞれのタリフを選択的に変更するステップを含む請求項１ないし請求項２４の何れか1項に記載の方法。
26. パケットベースインターネットワーキングプロトコルをサポートする通信ネットワークであって、
    該通信ネットワークに接続された多数の顧客端末へ該通信ネットワークを介してタリフ情報を配送するタリフ配送手段を備え、前記タリフ情報は通信ネットワークの顧客端末による使用に対して、通信ネットワークの負荷の関数として料金を計算するための計算式を、タリフとして生成するのに使用でき、
    該タリフにおいて使用されるパラメータは顧客端末において局所的に測定可能である、通信ネットワーク。
27. 多数の顧客端末をさらに備え、それぞれの顧客端末は、前記タリフを用いて通信ネットワークの顧客端末による使用に対する料金を計算する計算手段を含む、請求項２６に記載された通信ネットワーク。
28. パケットベースインターネットワーキングプロトコルをサポートする通信ネットワークで使用する顧客端末であって、
    通信ネットワークを介して通信ネットワークの負荷の関数である計算式を、タリフとして生成するために使用できるタリフ情報を受信するために動作可能なネットワークインターフェイスと、
    前記インターフェイスにおいて受け取られたタリフ情報でプログラムされたメモリと、
    ネットワークの負荷を測定するためのメータと、
    前記メータおよびメモリに接続され、前記タリフ情報とネットワーク情報の測定された負荷を使用して、ネットワーク使用料金を計算するように構成されたプロセッサと、を含み、
    該タリフにおいて使用されるパラメータは顧客端末において局所的に測定可能である、顧客端末。

Images