(57)【要約】      （修正有）【課題】リアルタイムのデータ・パケット・トラヒックのスケジューリング及び受入れ制御について、方法、装置及びソフトウェア・プログラムを提供する。【解決手段】データ・パケットは、パケット・スケジューラのスループット能力に従い、リアルタイム処理に対して受け入れられ、あるいは、拒否される。パケット・スケジューラにおいてそれぞれのペイロード・データ・パケットについて配信デッドラインが判断され、パケットは、タイム−スタンプ−ベースの待ち行列中にソートされる。デッドラインの超過が監視され、必要に応じて安定状態に入るようにペイロード・データ・パケットの適応化を起動することができる。【選択図】図１
2007312413.tif 000002
【特許請求の範囲】
【請求項１】
通信システムにおいてデータ・パケット・ストリームを処理する方法であって、
複数の受入れ制御パラメータを含む第１の受入れ制御パケット（ＡＣＰ）を受信する過程と、
前記第１の受入れ制御パケット（ＡＣＰ）に関するデータ・パケットのサブ−ストリームのリアルタイム処理のために要求されるスループット（Ｒｌ）を示す少なくとも１つの受入れ制御パラメータを前記第１の受入れ制御パケット（ＡＣＰ）から読み取る過程と、
現在利用可能なスループット（Ｖ）を判断する過程と、
前記利用可能なスループット（Ｖ）と前記要求されるスループット（Ｒｌ）とを比較する過程と、
前記利用可能なスループット（Ｖ）が前記要求されたスループット（Ｒｌ）より高いか若しくはこれに等しい場合に、前記サブ−ストリームのリアルタイム処理を受け入れる過程と、
を含む方法。
【請求項２】
請求項１記載の方法において、
前記少なくとも１つの受入れ制御パラメータを読み取る前記過程は、最大スループット（Ｒｈ）を読み取ることを含み、
要求されたスループット（Ｒｌ）と、前記最大のスループット（Ｒｈ）及び前記利用可能なスループット（Ｖ）のうちの最小値との間でスループットをサブ−ストリームのために選択する過程をさらに含む方法。
【請求項３】
請求項１又は２記載の方法において、
当該サブ−ストリームは、それがリアルタイム処理に受け入れられる場合に、リアルタイム処理のためにパケット・スケジューラへ送信される方法。
【請求項４】
請求項３記載の方法において、
リアルタイム処理に受け入れられるサブ−ストリームのペイロード・データ・パケットの配信デッドラインを決定する過程と、
ペイロード・データ・パケットを第１の待ち行列（ＥＤＦ）にソートする過程と、
第１の待ち行列（ＥＤＦ）における、ソートされたペイロード・データ・パケットに関するタイム・スタンプを、決定された配信デッドラインに設定する過程と、
をさらに含む方法。
【請求項５】
請求項１又は２記載の方法において、
サブ−ストリームは、それがリアルタイム処理に受け入れられない場合、非リアルタイム処理のためのパケット・スケジューラに送信される方法。
【請求項６】
請求項５記載の方法において、
リアルタイム処理に対して拒否されたサブ−ストリームのデータ・パケットをそれらが現れた順序で第２の待ち行列（ＦＩＦＯ）にソートする過程をさらに含む方法。
【請求項７】
請求項１ないし６の何れかに記載の方法において、
受入れ制御装置（ＡＣ）から、当該受入れ制御装置（ＡＣ）のスループット能力パラメータを含む修正した受入れ制御パケットを生成してサブ−ストリームの伝送路に沿って返送する過程をさらに含む方法。
【請求項８】
請求項１ないし７のいずれかに記載の方法であって、
−下層にあるネットワーク・プロトコルのヘッダから少なくとも１つの受入れ制御パラメータを受信する過程をさらに含む方法。
【請求項９】
請求項６ないし８の何れかに記載の方法において、  
第１の待ち行列（ＥＤＦ）からのデータ・パケットをそれらの配信デッドラインに従ってさらに処理する過程と、
第２の待ち行列からのデータ・パケットをファースト・イン−ファースト・アウトの方策に従ってさらに処理する過程と、
をさらに含む方法。
【請求項１０】
請求項９記載の方法において、
前記さらなる処理のための出力インタフェースにより、前記第１の待ち行列（ＥＤＦ）に含まれるデータ・パケット及び前記第２の待ち行列（ＦＩＦＯ）に含まれるデータ・パケットを優先するものから順に処理する過程をさらに含む方法。
【請求項１１】
請求項１ないし１０の何れかに記載の方法において、
前記第１の待ち行列（ＥＤＦ）中にソートされたペイロード・パケットについてそれらの当該第１の待ち行列内で費やした実際の時間をそれらのタイム・スタンプに基づくそれらのデッドラインと繰り返し比較することによりデッドライン超過を検出する過程をさらに含む方法。
【請求項１２】
請求項１１に記載の方法において、
前記デッドライン超過を検出した後に前記第１の待ち行列（ＥＤＦ）の少なくとも１つのペイロード・データ・パケットの適応化を実行する過程をさらに含む方法。
【請求項１３】
トラヒック・フローに埋め込まれた少なくとも１つの制御パケット（ＡＣＰ）により与えられる少なくとも１つの制御パラメータを評価する評価手段と、
ネットワーク・ノードの現在利用可能なスループット（Ｖ）を判断する判断ユニットと、
入来するデータ・パケット・トラヒック・フローがネットワーク・ノードにおいて受入れ制御パラメータにより与えられるリアルタイムの要求特性に従って処理できるか否かを、現在利用可能なスループット（Ｖ）を考慮に入れて判断する判断手段と、
を含む通信システムにおける装置。
【請求項１４】
請求項１３に記載の装置において、
リアルタイム処理に受け入れられるデータ・パケットのための第１の待ち行列（ＥＤＦ）と、
リアルタイム処理に受け入れられないデータ・パケットのための第２の待ち行列（ＦＩＦＯ）と、
前記判断手段による肯定的な判断後にデータ・パケット・トラフィック・フローを第１の待ち行列（ＥＤＦ）に転送するか、或いは、前記判断手段による否定的な判断後にデータ・パケット・トラフィック・フローを第２の待ち行列（ＦＩＦＯ）に転送するための転送ユニットと、
をさらに具備する装置。
【請求項１５】
請求項１３又は１４に記載の装置において、
第１及び第２の待ち行列の優先順位をつけると共に、第１及び第２の待ち行列からデータ・パケットを読み出す出力インタフェース（ＯＩ）をさらに具備する装置。
【請求項１６】
請求項１３ないし１５の何れかに記載の装置において、
データ・パケットについてのデッドラインを計算する計算機ユニットをさらに具備する装置。
【請求項１７】
請求項１６に記載の装置において、
前記第１の待ち行列（ＥＤＦ）は、最早期デッドライン・ファーストの方策に従い、前記第１の待ち行列中にデータ・パケットをそれらのデッドラインに基づいてソートするソーティング・ユニットを有し、
前記ソーティング・ユニットは、計算されたデッドラインに基づいて前記第１の待ち行列（ＥＤＦ）のタイム・スタンプを設定する装置。
【請求項１８】
請求項１６又は１７に記載の装置において、
データ・パケットのデッドラインを監視し、少なくとも１つのデッドライン超過を検出し、かつ、少なくとも一つのデータ・パケットの適応化を起動するデッドライン超過処理機と、
少なくとも一つのデータ・パケットの前記適応化のための適応化ユニットと、
をさらに具備する装置。
【請求項１９】
請求項１３ないし１８の何れかに記載の装置において、
データ・パケット・トラフィックの送受信ための無線基地局をさらに含む装置。
【請求項２０】
請求項１ないし１２の何れかに記載の方法を実行するためのソフトウェア・コード部を含むディジタルコンピュータメモリにロード可能なコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、通信システムにおけるパケット・データ・トラヒックの処理に関する。また特に、本発明は、データの各パケットのスケジューリング及び受入れ制御（admission control）に関する。
【背景技術】
【０００２】
従来技術によれば、パケット指向の通信ネットワークにおける品質条件の規定（the provision of quality of service）に関しては、既知のコンセプトが２つある。
【０００３】
一つのコンセプトは、専用のデータ・パケット・ストリームのためにリソースを予約（reservation）することに基づくいわゆる総合サービス・コンセプト（Integrated Service Concept）である。それらのリソースの予約をするためには、ペイロード・データの伝送前に要求特性のピア・ツー・ピア信号授受（peer-to-peer signalling of requirements）をする必要がある。伝送路の間にあるすべてのネットワーク・ノードに対しては、対応するリソースを予約することが要求される。総合サービス・コンセプトについては、D. Clark等のSupporting Real-time Applications in an Integrated Services Packet Network: Architecture and Mechanisms, Proceedings SIGCOMM 92, August 1992に開示されている。
【０００４】
公知の信号授受プロトコルとしては、L. Zhang等のRSVP: A New Resource Reservation Protocol, IEEE Network Magazine, Sept. 1993に開示されたいわゆるリソース予約プロトコルＲＳＶＰ（Resource Reservation Protocol）がある。ＲＳＶＰは、通信路に沿った一方の方向におけるリソースを予約する受信側指向の単信方式プロトコルである。データ・フロー（データの流れ）の受信側には、リソース予約の開始をすることが課される。
【０００５】
いわゆるＴＥＮＥＴ方式は、総合サービス・コンセプトに類似している（D. Ferrari等のA Scheme for Real-Time Channel Establishment in Wide Area Networks, IEEE Journal on Selected Areas of Communications, Vol. 8, pp. 368-379, 1990参照）。それは、パケット交換による広域のネットワークにおけるリアルタイムのサービスのために保証される遅延を定めており、パケット・フロー（パケットの流れ）毎に帯域幅（回線容量）の割当ができるものとなっている。この方式においては、通信チャネルを確立する時に各クライアントが自身のトラヒックの特性とパフォーマンスの要求特性を宣言する。データ・パケットは、チャネルが確立された後に、各ホストコンピュータや各ネットワーク・ノードにおけるデッドライン（deadlines）に基づいてスケジューリングされる。そのようにするために、スケジューラは、少なくとも３つの待ち行列（queues）を保持している。ここにいう３つの待ち行列とは、確定的パケット（deterministic packets）のための待ち行列、統計的パケット（statistical packets）のための待ち行列、並びに他のすべてのタイプのパケット及びすべてのローカル・タスクのための第３の待ち行列である。
【０００６】
品質条件を規定するためのもう一つのコンセプトは、いわゆる差別化サービス・コンセプト（Differentiated Service Concept）である。差別化サービス・コンセプトは、プロトコル・ヘッダにおける優先順位ビット（priority bits）の利用により、品質条件の要求特性によるパケットの分類及びスケジューリングを簡略化することを図ったものである。特定の品質条件クラスに属しているすべてのパケットは、対応する優先順位ビットの組合せをインターネット・プロトコルのヘッダ中に付されることになる。各パケット・フローは、ネットワークの端部（edge）におけるサービス水準契約（Service Level Agreement）に従い、優先順位ビットを付され、かつ、規制される。ネットワークの内部では、各パケットが優先順位ビットに基づいてスケジューリングされる。差別化サービス・コンセプトについては、S. Blake等のAn Architecture for Differentiated Services, IETF RFC 2475, December 1998が参考になる。
【０００７】
ボトルネック（bottlenecks（隘路））を含む通信ネットワークにおいては、リアルタイムないしほぼリアルタイムのマルチメディア・アプリケーションのデッドライン超過（deadline violations）を最小にするための、データ・パケット・ストリームの受入れ制御とデータ・パケットの伝送順序のスケジューリングとが重要なタスクとなる。以下、‘リアルタイム’（‘real-time’）の用語は、‘ほぼリアルタイム’（‘near real-time’）とも解釈され、また、概して‘タイム−クリティカル’（‘time-critical’）とも解釈されるものとする。複数の異種ネットワークにおいては、一つのネットワークからのトラヒックが別のネットワークへと進行する所のネットワークの境界にボトルネックが生じる。
【０００８】
一つのデータ・パケットだけが遅延される場合では、通常は期待されるリアルタイムのデッドラインを超えない。その代わりに、複数データ・パケットの組は、例えばマルチメディア出力の一部を表示するのに間に合うように宛先へ到達する必要がある同期エンティティ（synchronisation entity）にまで広がるのが通常である。
【０００９】
アプリケーションや中間ノード（intermediate nodes）は、ますます高度なものとなってきており、マルチメディアへの適応化を考慮している。このため、ある種のマルチメディアのオブジェクトないしプレゼンテーション（通知）を伝送するために必要なデータ帯域幅（データの回線容量）の総量は固定的でないものとなる。適応化のプロセスは、低優先順位のパケットの削減（dropping（落としないし減らすこと））や階層マルチメディア符号化（hierarchical multimedia coding）、適応アプリケーション（adaptive application）、帯域幅適応化ゲートウェイ（bandwidth adaptation gateways）、あるいは、ネットワーク・ノード内に処理素子を配備している対等動作ネットワーク（even active networks）のような、いくつかの手段によって行うことができる。これにより、輻湊（congestion）しているケースでは、ある間隔で帯域幅を変えることができる。必要とされる適応化のタスクをアプリケーションやネットワーク自体が遂行することにより、実際の伝送速度を変化させてデッドライン超過を避けるようにすることもできる。
【００１０】
既存の受入れ制御とスケジューリングの方式は、バースト形態のパケット・ソース（bursty packet sources）に対して与えられるピーク・レート割当及び遅延保証による低度の帯域幅利用しか考慮していない。改良された方式は、過去の帯域幅使用を測定することによって実際に使用可能な帯域幅を予測する測定アルゴリズムを適用することにより、より高度な帯域幅利用に到達している。しかしながら、測定に基づくアルゴリズムは、薄弱な保証しか与えず、かつ、大量の統計的多重化によってのみ効率的に機能するに過ぎない。特に無線ネットワークに関しては帯域幅の加入者容量に限界があるのが通常であり、このことから測定に基づく確定的受入れ制御の方式ではパフォーマンスが乏しい。一つの理由は、パケット・スケジューリングのための既存の方式がそれぞれのパケットを同じ取扱い方で処理している点にある。それらの方式は、受信する各アプリケーションに関係する過去のデッドラインを検出することができず、このことから現在（その時点）のシステムを誤り無し状態（error-free state）にするプロセスを起動することもできない。
【００１１】
伝統的な方式では、それぞれのパケット・ストリームを優先順位クラス（priority class）に分類する。総合サービス・コンセプトにおいては、この優先順位クラスは、個別のストリームのパケットが受ける（経験する）ことになる平均遅延に属する。差別化サービスのアプローチにおいては、この優先順位クラスは、他のものよりも少ない遅延を有するものとすべきトラヒック・タイプに属する。優先順位クラスは、通常は平均遅延に制限され、パケットは、その優先順位クラスに受け入れられるときにその平均遅延を受けるものと予定される。可変のビット・レートを伴う（画像ストリーム（video streams）のような）マルチメディア・ストリームを考える場合には、単一のストリームの各パケットが終始同じ遅延の要求特性を有することにはならない。その代わりに、本発明によって提案されるようなそれぞれの個々のパケットに対する配信デッドラインの決定（determination of a delivery deadline）によるスケジューリングは、優先順位に基づくスケジューリングよりも良好なパフォーマンスを提供する。
【００１２】
このようなことから、本発明は、それらの問題及び他の問題を克服し、特にリアルタイムのデータ・トラヒックを伝えるデータ・パケットのデッドライン指向のスケジューリング（deadline-oriented scheduling）を可能にする、パケット指向の通信システムに対する改良されたアプローチを提供することを目的としている。
【００１３】
この目的は、請求項１、１５及び２１に基づく過程及び特徴を有する方法、システム及びソフトウェア・プログラムによって達成される。
【００１４】
本発明で述べられる解決手段は、リアルタイム処理の対象とされるペイロード・データ・パケットに対して個々の配信デッドラインを割り当てるという理由から有利（advantageous）なものとなっている。これは、パケットが終始有するそれぞれ異なる遅延の要求特性のために、可変ビット・レートを伴う単一のマルチメディア・ストリームのデータ・パケットに対して、特に有効である。それぞれの個々のペイロード・データ・パケットについての配信デッドラインの計算は、タイム−スタンプに基づく待ち行列によるペイロード・データ・パケットの最適なスケジューリングを可能にする。有利なことに、デッドラインの判断に必要な同期制御パラメータは、入来するデータ・パケット・ストリームにおいて埋め込まれる同期制御パケットＳＣＰから読み取られる。これは、制御パラメータの容易な処理を保証すると共に、追加の信号授受や複雑なプロトコル構造を回避する。
【００１５】
好ましい利用においては、同期制御パラメータとは別に、データ・パケット用の伝送チャネルのパケット誤り率Ｐｊ及びビット・レートＲｊのようなパラメータをデッドラインの計算に取り入れる。これにより、その時点での（現在ないし最新の）システム特性を容易に考慮することができ、それによってパフォーマンスが向上することになる。
【００１６】
さらなる好ましい実施形態は、請求項２ないし１４、１６ないし２０及び２２ないし３０に基づいて実現される。
【００１７】
請求項４によれば、パケット・スケジューラにおいて各ペイロード・データ・パケットについて配信デッドラインが計算される前に受入れ制御を実行する、という点がさらに有利となっている。データ・パケットのサブ−ストリームのリアルタイム処理を受け入れる判断は、受入れ制御パラメータによって与えられる最小のスループット要求特性に応じて行われ、受入れ制御パラメータは、受入れ制御パケットＡＣＰから容易に読み取ることができる。有利なことに、利用可能なスループットより高いスループットを要求するデータ・パケットがリアルタイム処理に受け入れられないことから、スループット不足のためのデータ・パケットについての配信デッドライン超過を回避することができる。また、配信デッドラインの無駄な計算も回避される。
【００１８】
請求項５によれば、受入れ制御が最大スループット・パラメータＲｈを考慮するという点が有利である。これは、最大スループットＲｈまでの範囲で利用可能なスループットから独立して、サブ−ストリームについて最小の要求されたスループットＲｌよりもコスト的に効率の良いスループットを選択することを可能にする。
【００１９】
さらに、高い方のスループット限界値Ｒｈは、データ・パケットの伝送速度が速過ぎることがないことを保証するので、通信システム内ないしデータ・パケット・ストリームの受信側におけるバッファのオーバーフローを回避することができる。
【００２０】
請求項６によれば、リアルタイム処理に対して受け入れられないデータ・パケットのサブ−ストリームを拒否し、かつ、それをパケット・スケジューラに送るという点が有利である。これは、なおも最善努力型の処理を可能にするからである。したがって、データ・パケットの削減や関連して生じる情報の損失を回避することができる。
【００２１】
請求項７によれば、リアルタイム処理に対して拒否されたデータ・パケットは、パケット・スケジューラにおいて第２の待ち行列ＦＩＦＯ中にそれらの現れた順序で格納される。これにより、第２の待ち行列ＦＩＦＯのデータ・パケットについてファースト・イン−ファースト・アウトの方策による最善努力型の処理が可能になる。
【００２２】
請求項８によれば、第１の待ち行列ＥＤＦからのデータ・パケットは、それらの配信デッドラインに基づいてさらに処理され、第２の待ち行列ＦＩＦＯからのデータ・パケットは、ファースト・イン−ファースト・アウトの方策によって処理される。これにより、有利なことに、確立された品質条件の要求特性の下でのデータ・パケットのさらなる処理が作動される。
【００２３】
請求項９によれば、出力インタフェースＯＩは、第１のＥＤＦ及び第２の待ち行列ＦＩＦＯにおけるデータ・パケットを優先するものから順に処理する。有利なことに、一方の待ち行列におけるデータ・パケットのブロッキング（blocking）は、双方の待ち行列からのデータ・パケットのある程度の読出を保証する、優先順位付けの方策を選択することによって回避することができる。
【００２４】
請求項１０によれば、修正された受入れ制御パケットを通じてスループット能力のフィードバックがデータ・パケット・サブ−ストリームの伝送路に沿って送り返される。有利なことに、これは、中間の通信システム・ノードやトラヒック・ソースがトラヒックを利用可能なスループット能力に適応させることを可能にする。これにより、リアルタイム処理に対するデータ・パケットの拒否を高度に（相当程度）回避することができる。修正した受入れ制御パケットの利用は、信号授受のオーバーヘッド（overhead）や複雑なプロトコル構造を回避することができる。
【００２５】
請求項１１によれば、同期制御パラメータは、下層にあるネットワーク・プロトコルのヘッダから受信される。これは、同期制御パラメータを読み取らせないようにはなっていないことから、ペイロードの秘匿及び認証を可能とする上に、いわゆるインターネット・プロトコルのＩＰｖ４、ＩＰｖ６及びＩＰＳｅｃの使用をサポートする。
【００２６】
請求項１２によれば、デッドライン超過を検出することができる。これにより、有利なことに、データ・パケットのリアルタイム処理を保証するための対策を起動することが可能になる。
【００２７】
請求項１３によれば、ペイロード・データ・パケットの適応化が行われる。これは、データ・パケットに対して配信デッドラインを維持することを可能にする。さらに、それは、パケット・スケジューラ及び他のシステム・リソースの効率的な使用をサポートすると共に、データ・パケットの拒否や削減を回避することができる。
【００２８】
請求項１４によれば、受入れ制御パラメータは、下層にあるネットワーク・プロトコルのヘッダから受信される。これは、受入れ制御パラメータを読み取らせないようになっていないことから、ペイロードの秘匿及び認証を可能とする上に、いわゆるインターネット・プロトコルのＩＰｖ４、ＩＰｖ６及びＩＰＳｅｃの使用をサポートする。
【００２９】
請求項１７によれば、リアルタイムのデータ・トラヒックを処理するネットワーク・ノードは、さらに、現在利用可能なスループットＶを判断する判断ユニットと、入来するデータ・トラヒック・フローのリアルタイム処理についての判断をする判断手段とを有する。それらの判断ユニット及び判断手段により、パケット・スケジューラでペイロード・データ・パケットについてデッドラインが計算される前に受入れ制御を実行することが可能となっている。有利なことに、利用可能なスループットよりも高いスループットを要求するデータ・パケットがリアルタイム処理に受け入れられないことから、スループット不足によるデータ・パケットについての配信デッドライン超過を回避することができる。また、配信デッドラインの無駄な計算も回避される。
【００３０】
請求項１８によれば、ネットワーク・ノードは、さらに、リアルタイム処理に対して受け入れられるデータ・パケットを第１の待ち行列ＥＤＦに転送し、かつ、リアルタイム処理に対して拒否されるデータ・パケットを第２の待ち行列ＦＩＦＯに転送する、転送ユニットを有する。これは、すべてのタイプのトラヒックを処理できることを保証する。リアルタイム処理に対して拒否されたデータ・パケットは、なおも最善努力型の品質で処理することができる。
【００３１】
また、出力インタフェースＯＩは、第１のＥＤＦ及び第２の待ち行列ＦＩＦＯにおけるデータ・パケットを優先するものから順に処理する。有利なことに、一方の待ち行列におけるデータ・パケットのブロッキングは、双方の待ち行列からのデータ・パケットのある程度の読出を保証する、優先順位付けの方策を選択することによって回避することができる。
【００３２】
請求項１９によれば、ネットワーク・ノードは、さらに、デッドライン超過処理機及び適応化ユニットを有する。これにより、データ・パケットのリアルタイム処理を保証するように配信デッドライン超過に対する対策を容易に起動することができる。好ましい対策としては、配信デッドラインの維持を可能にするペイロード・データ・パケットの適応化が挙げられる。それは、さらに、システム・リソースの効率的な使用をサポートし、かつ、データ・パケットの拒否や削減を回避することができる。
【００３３】
請求項２０によれば、ネットワーク・ノードは、さらに、無線基地局を含む。セルラー通信ネットワークや特に無線アクセス・ネットワークにおいては、利用可能な周波数が限られたリソースとなる。この結果、通信チャネルの帯域幅が制限される。有利なことに、本発明は、リアルタイムのマルチメディア・サービスを要求するクライアントに対して効率的に品質条件を規定することをサポートする。特に、無線基地局は、その通信の要求を満たすことが可能なクライアントだけを収容することができる。
【００３４】
請求項２３によれば、データ・パケット・ストリームに埋め込まれる受入れ制御パケットＡＣＰから読み取られる１つ又は２つ以上の受入れ制御パラメータＲｌに基づき、受入れ制御を容易に実行することができる、という点が有利になっている。データ・パケットのサブ−ストリームのリアルタイム処理を受け入れる判断は、当該受入れ制御パラメータによって与えられる最小のスループット要求特性に応じて行われる。有利なことに、利用可能なスループットよりも高いスループットを要求するデータ・パケットがリアルタイム処理に受け入れられないことから、ネットワーク・ノードないしアプリケーションにおけるスループット不足のための輻湊を回避することができる。また、受入れ制御は、最大スループット・パラメータＲｈを考慮することができる。したがって、受入れ制御装置は、最大スループットＲｈまでの範囲で利用可能なスループットから独立して、データ・パケットのサブ−ストリームについて最小の要求されたスループットＲｌよりもコスト的に効率の良いスループットを選択することができる。
【００３５】
ネットワーク事業者は、顧客に対して提供する異なるスループット・レートについて異なる料金を課金することができる。事業者の利益を増やすためには、サブ−ストリームについてのスループット・レートの当該選択は、事業者によって与えられる利得関数に基づくものとすることができる。当該利得関数は、例えば、通信システム、ネットワーク・ノードないし伝送チャネルについてのスループット−レート毎のコストを示すものである。
【００３６】
さらに、高い方のスループット限界値Ｒｈは、データ・パケットが速く伝送され過ぎないことを保証するので、通信システム内ないしデータ・パケット・ストリームの受信側でのバッファのオーバーフローを回避することができる。
【００３７】
さらに、ペイロード・データ・パケットについてデッドラインが計算される前に受入れ制御を実行することが有利である。受入れ制御パラメータにより与えられるデータ・パケットのサブ−ストリームのリアルタイム処理に対するスループット要求特性が利用可能なスループット能力を考慮しつつそれらのデッドラインを維持できないことを示している場合には、デッドラインを計算する必要は全くない。有利なことに、利用可能なスループットとは別のスループットを要求しているデータ・パケットがリアルタイム処理に受け入れられないことから、スループット不足によるデータ・パケットについての配信デッドライン超過を回避することができる。
【００３８】
請求項２４によれば、修正した受入れ制御パケットを通じてスループット能力のフィードバックがデータ・パケット・サブ−ストリームの伝送路に沿って送り返される。これにより、有利なことに、中間の通信システム・ノードやトラヒック・ソースは、トラヒックを利用可能なスループット能力に適応させることが可能になる。このようにして、リアルタイム処理に対するデータ・パケットの拒否を高度に回避することができる。また、修正された受入れ制御パケットの利用は、信号授受のオーバーヘッドや複雑なプロトコル構造を回避することもできる。
【００３９】
請求項２５によれば、リアルタイム処理に対して拒否されたデータ・パケットは、それらが現れた順序で第２の待ち行列ＦＩＦＯ中にソートされる。これにより、それらのデータ・パケットについてファースト・イン−ファースト・アウトの方策に基づく最善努力型の処理を容易に行うことが可能になる。
【００４０】
請求項２６によれば、データ・パケットは、第１の待ち行列ＥＤＦ及び第２の待ち行列ＦＩＦＯからの読出のために優先するものから順に処理される。有利なことに、一方の待ち行列におけるデータ・パケットのブロッキングは、双方の待ち行列からのデータ・パケットのある程度の読出を保証する、優先順位付けの方策を選択することによって回避することができる。
【００４１】
請求項２７記載の発明によれば、デッドライン超過を検出することができる。これにより、有利なことに、データ・パケットのリアルタイム処理を保証するための対策を起動することが可能になる。
【００４２】
請求項２８によれば、ペイロード・データ・パケットの適応化が実行される。これにより、特に輻湊ないしトラヒック負荷がピークのケースにおいて、データ・パケットについての配信デッドラインを維持することが可能になる。さらに、それは、システム・リソースの効率的な使用をサポートし、かつ、データ・パケットの拒否や削減を回避することができる。
【００４３】
請求項２９によれば受入れ制御パラメータが、請求項３０によれば同期制御パラメータが、下層にあるネットワーク・プロトコルのヘッダから受信される。これは、受入れ制御パラメータを読み取らせないようにはなっていないことから、ペイロードの秘匿及び認証を可能とする上に、いわゆるインターネット・プロトコルのＩＰｖ４、ＩＰｖ６及びＩＰＳｅｃの使用をサポートする。
【００４４】
本発明の方法、システム及びコンピュータ・プログラムは、図面を併せて参照した以下の詳細な説明により、さらによく理解され、さらにその価値が認められることであろう。以下の図面は次のものを示している。
【００４５】
（図面の簡単な説明）
図１ａは、それぞれ異なる同期エンティティを伴う画像ストリームを示し、
図１ｂは、それぞれ異なる同期エンティティを伴う他の画像ストリームを示し、
図１ｃは、受入れ制御パケットＡＣＰ（admission control packet）及び同期制御パケットＳＣＰｓ（synchronisation control packets）を伴うデータ・パケット・ストリームを示し、
図２ａは、ＳＣＰ中に含まれるパラメータを示し、
図２ｂは、ＡＣＰ中に含まれるパラメータを示し、
図３は、受入れ制御装置（admission controller）のタスクを流れ図に示し、
図４は、パケット・スケジューラの機能図（functional view）を示し、
図５は、パケット・スケジューラのタスクを流れ図に示している。
【００４６】
（発明の詳細な説明）
図１ａは、ペイロード・データ・パケット・トラヒックのストリームを時間軸ｔに沿って示している。そのストリームは、通信システムにおけるトラヒック・ソース（traffic source（トラヒック源））ないし中間ネットワーク・ノードによって送ることができるものであり、また、それは、パケット・スケジューラないし受入れ制御装置のようなネットワーク・ノードで受信することができるものであり、また、それは、マルチメディア・ビューア（multimedia viewer）のようなソフトウェア・アプリケーションから受信することができるものである。そのペイロード・データ・パケットのストリームは、いくつかのペイロード・データ・パケット１、２及び３から構成されており、それらのペイロード・データ・パケット１、２及び３が終始に亘って送信ないし受信される。
【００４７】
ペイロードの特性（characteristic）に応じて、一揃いになっているデータ・パケットがあり、それらのデータ・パケットがいわゆる同期エンティティＳＥ（synchronisation entity）を形成している。一つの同期エンティティＳＥに属している各データ・パケットは、リアルタイムの要求特性のために固定された時間間隔の範囲内でそれらのデータ・パケットの宛先にそれらのデータ・パケットのすべてが共に到達しなければならないという特性を共通して持っている。さらに、それぞれの同期エンティティＳＥは、他の続く同期エンティティＳＥのすべてのパケットから独立して受信側のアプリケーションにより処理されるという属性（property）を有するべきものとなっている。
【００４８】
画像通信を考える場合では、同期エンティティＳＥは、受信側でのリアルタイム特性及び再生バッファ（playback buffer）に応じて、１つ又は２つ以上の画像フレームにより構成することができる。インターネット・プロトコルのストリーム上での音声に関しては、同期エンティティＳＥを単一のパケットにすることさえも可能である。いわゆるワールド−ワイド−ウェブＷＷＷ（World-Wide-Web）のセッションにおいては、同期エンティティＳＥは、画像やハイパーテキスト・マークアップ言語ＨＴＭＬ（Hypertext Markup Language）文書構造のようなすべてのオブジェクトを含んだウェブ・ページ全体を表すデータ・パケットによって構成することができる。
【００４９】
図１ａにおいて、すべてのペイロード・データ・パケット１は第１の同期エンティティＳＥ１に属し、すべてのペイロード・データ・パケット２は第２の同期エンティティＳＥ２に属し、すべてのペイロード・データ・パケット３は第３の同期エンティティＳＥ３に属している。この構成（configuration）は、通信ネットワークにおいてデータ・パケット・ストリームを受信するパケット・スケジューラに対して、エンド・ツー・エンドの終始に亘る遅延に関して制限のある遅延の要求特性を課す。
【００５０】
図１ｂは、別形態のトラヒック・シナリオ（traffic scenario）において、１つの同期エンティティ内に２つの画像フレームを有する画像ストリーム（ビデオ・ストリーム）を示している。第１の画像フレームはペイロード・データ・パケット１を含み、第２のフレームはペイロード・データ・パケット２を含んでいる。このシナリオは、再生前に２つの同期エンティティをバッファリングすることを受信側に強制する。ここで、同期エンティティＳＥ１は同期エンティティＳＥ２にオーバーラップしている。
【００５１】
図１ｃは、オーバーラップした同期エンティティがないデータ・パケット・ストリームを示している。そのストリーム中には、トラヒック・ソースないし中間のゲートウェイによって一定の制御データ・パケットＳＣＰ、ＡＣＰが埋め込まれている。同期制御パケットＳＣＰ（synchronisation control packet）は、同期エンティティＳＥに先行し、一つの同期エンティティを他の同期エンティティから区別する。それは、続く同期エンティティＳＥに関係する同期制御パラメータを含んでいる。
【００５２】
本発明の好ましい実施形態においては、さらに加えてトラヒック・ソースがパケット・ストリーム中に受入れ制御パケットＡＣＰ（admission control packets）を挿入する。受入れ制御パケットＡＣＰは、リアルタイム処理のためのデータ・パケットのサブ−ストリーム（sub-stream）のスループット要求特性（throughput requirements）に関して、そのデータ・パケットのサブ−ストリームを特徴付けるパラメータを含む。サブ−ストリームとは、受入れ制御パケットＡＣＰに続いている、別の受入れ制御パケットに至るまでの、データ・パケットの組と解釈されるものとする。あるいは他の形態として、受入れ制御パケットに割り当てられたデータ・パケットの個数を制御パラメータ（サブ−ストリームをその長さによって定義する制御パラメータ）としてその受入れ制御パケットに含めることもできる。
【００５３】
一つのパケット・データ・ストリームにおいてリアルタイムのデータ・トラヒックと最善努力型トラヒック（best-effort traffic）のような他のデータ・トラヒックとを混在させる場合には、同期制御パケットＳＣＰ内ないし受入れ制御パケットＡＣＰ内の制御パラメータとして含まれて同期エンティティないしサブ−ストリームの長さを定義する数により、各ペイロード・データ・パケットが一定の同期エンティティＳＥないし一定のサブ−ストリームに属するものとする識別（identification）を好適に利用することができる。
【００５４】
受入れ制御パケットＡＣＰは、データ伝送が持続しているときに繰り返して送ることにしてもよい。トラヒック・ソースは、このようにして自身のリソース使用における信号の変化に対して受入れ制御パケットＡＣＰを利用することにしてもよい。
【００５５】
本発明のさらなる実施形態においては、受入れ制御装置が修正した受入れ制御パケットＡＣＰをパケット・ソース（パケット源）に向けて送り返す。このメカニズムは、中間ノードないしパケット・ソースがリアルタイム処理のためにデータ・パケットの非受入れ（negative admissions）に対して作用し合うことを可能にする。
【００５６】
また、受入れ制御パケットＡＣＰは、リソース予約をリフレッシュするために、任意の時間間隔で繰り返すこともできる。それらを繰返し送るのが可能であることは、移動通信ネットワークの固定網（fixed network）部分のような、マルチメディア・ストリームのルーチング・パスが変化し得るネットワークにおいて、特に有用である。その場合、ネットワークのボトルネックにおける制御ノードが実際のリソース要求特性を判断することができるように、実際の受入れ制御パケットＡＣＰのコピーを専用の制御ノードから転送することができ、あるいは、同コピーを規則的な時間間隔でパケット・ストリーム中に繰り返すこともできる。
【００５７】
本発明のさらなる実施形態においては、下層にあるネットワーク・プロトコルのヘッダ中にトラヒック・ソースないし中間ゲートウェイから同期制御パラメータ及び受入れ制御パラメータが挿入される。これは、ペイロード秘匿（payload encryption）と認証メカニズム（authentication mechanisms）が用いられている場合に特に有用である。ＩＰｖ４やＩＰｖ６のようなインターネット・プロトコルは、受入れ制御及び同期制御のパラメータを伝えることができるオプションの（任意選択的な）ヘッダ拡張部（optional header extension）の挿入を許容している。いわゆるＩＰＳｅｃプロトコルを用いている場合では、インターネット・プロトコルのヘッダは、付加された認証ヘッダによって認証される。したがって、受入れ制御及び同期制御のパラメータを読み取ることは妨げられない。
【００５８】
本発明のさらなる実施形態においては、ソースとパケット・スケジューラの間の中間局（intermediate station）が伝送されるデータ・パケット・ストリームのキー（key）を認識している情報として有している。それは、例えばネットワーク提供者によって維持されている移動性ゲートウェイ（mobility gateway）のような、エンド−ユーザにとって信頼性のある装置を形成する。このケースにおいては、通信の当事者機器（parties）間でいわゆるＩＰトンネリング（IP tunnelling）が行われるときに、無線リンクを通じた伝送のための特別なヘッダ及びペイロード秘匿が用いられる。
【００５９】
本発明は、同期制御パケットＳＣＰに含まれる同期情報の援助により、例えばパケット・スケジューラにおいて、同期エンティティＳＥのそれぞれのペイロード・データ・パケットに対する個々の配信デッドラインを判断（決定）することを可能にする。図２ａは、同期制御パケットＳＣＰの内容についての好ましい実施形態を示している。それは、パラメータとして、それの示す同期エンティティＳＥに属するパケットの個数Ｎ、その同期エンティティＳＥのすべてのペイロード・データ・パケットの全体サイズＳ、及び同期エンティティＳＥの全体がパケット・スケジューラを通過しなければならない最大伝送時間Ｉを含んでいる。
【００６０】
他の形態として、最大伝送時間Ｉは、その間に同期エンティティＳＥがその最終的な宛先に到達しなければならない時間として定義することもできる。このケースにおいては、パケット・スケジューラは、同期エンティティＳＥの処理をするためにその伝送時間の一部までだけを使うことが許容されることになる。
【００６１】
また、同期制御パケットＳＣＰは、属する受入れ制御パケットＡＣＰを示す識別子ＩＤを含むものとしてもよい。この識別子は、同期エンティティが一定のサブ−ストリームに属しているかどうかを検証（verify）するのに利用することができる。
【００６２】
加えて、同期制御パケットは、他のパラメータを含むものとしてもよい。この他のパラメータとしては、その同期制御パケットの制御パラメータに属するとのペイロード・データ・パケットの識別をサポートするものが挙げられる。これは、トラヒック・ソース若しくは中間ネットワーク・ノードからパケット・スケジューラ若しくは他のネットワーク・ノードないし一般的には同期制御パラメータを利用する装置若しくはアプリケーションへのデータ・パケットの伝送の間にそれらのデータ・パケットの伝送順序が変更される場合において、必要となり得るものである。
【００６３】
データ・パケットの伝送順序が変わっていないものとすると、パケットは、同期制御パケットＳＣＰの直後に続く最初のパケットで始まり、それらがその同期制御パケットＳＣＰに追従し続け、かつ、Ｎよりも大きいインデックス（index）を有していない場合の、特定の同期エンティティＳＥに属している。それぞれの異なるパケット・フローに属している各同期エンティティＳＥを区別するためには、下層にあるネットワーク・プロトコルによって各データ・パケットがフロー・ラベル（flow label）も付されるものとすることができる。同期制御パケットＳＣＰは、そのデータ・パケットの他に同じフロー・ラベルを搬送する。
【００６４】
通常では、同期制御パケットＳＣＰは、同期エンティティＳＥに属するペイロード・データ・パケットの配信デッドラインを判断（決定）するために必要なパラメータを含んでいる。トラヒック・タイプ及び対応するアプリケーションに応じて、本発明の一定の実施形態においては、デッドラインについての絶対時間値又は相対時間値（an absolute or relative time value）のようなただ一つのパラメータを同期制御パケットＳＣＰが含むことにしてもよい。別のシナリオにおいては、同期制御パケットは、とりわけデータ・パケットの順序を再配列（re-arrangement）するために用いる追加の制御パラメータを含むものとしてもよい。したがって、図２ａに示したような同期制御パケットＳＣＰの内容は、採用可能な実施形態の一例に過ぎないと解釈すべきものである。
【００６５】
図２ｂは、受入れ制御パケットＡＣＰに含まれる受入れ制御パラメータの好ましい実施形態を示している。受入れ制御パケットＡＣＰは、概して、パケット・スケジューラによりデータ・パケットのサブ−ストリームを処理するためのリアルタイム制約（real-time constraints）によるスループット要求特性を特徴付ける（示し表す）スループット・パラメータを含んでいる。本発明の観念におけるスループット要求特性は、固定的な要求特性とすることも平均的な要求特性とすることもでき、それは、固定的なスループット・レートのパラメータによって与えることも平均的なスループットのパラメータによって与えることもできる。
【００６６】
パラメータＲｌは、サブ−ストリームのリアルタイム処理に必要である最低の要求されるスループットを与える。この最小の要求特性を満たすことができない場合には、リアルタイム処理に対してサブ−ストリームを拒否する（受け入れない）か、あるいは、最善努力型の方策（best effort strategy）の下でサブ−ストリームを処理するかの、いずれかにしなければならない。例えば、移動端末機は、このパラメータを通じて、アクセス・ネットワークの無線基地局（radio base station）により与えられるべき一定のデータ・スループット条件を要求することができる。その場合、無線基地局は、移動局（mobile station）がクライアントと認められるかどうかを判断する。
【００６７】
さらに加えて、オプションの（任意選択的な）パラメータＲｈにより、最高の希望されるスループットを要求することができる。これにより、受入れ制御装置又は一般的にはネットワーク・ノード若しくはアプリケーションは、最小の要求されたスループットＲｌと最大の希望されたスループットＲｈの、与えられたスループット間の範囲内で、スループット・レートを選択することが可能になる。当該選択は、例えばスループット毎のコストないし利益（profit）を示す線形利得関数等の、ネットワーク事業者によって与えられる利得関数（gain-function）に基づくものとしてもよく、あるいはそれは他のコスト推定（cost-estimations）に基づくものとしてもよい。また、利得関数に従った一定スループットの当該選択は、データ・パケットの１つ又は２つ以上のサブ−ストリームに影響するものとしてもよく、あるいは一般的には、それぞれ一定のスループットにより、パケット・スケジューラでのリアルタイム処理のために受入れ制御装置によって既に受け入れられている通信接続に、影響するものとしてもよい。それらのスループットを減少させ、サブ−ストリーム用に利用可能なスループットを増加させるようにしてもよく、あるいは一般的には、その時点で受入れ制御装置による受入れ処理の下にある通信接続用に利用可能なスループットを増加させるようにしてもよい。したがって、高い方のスループット値Ｒｈに至るまでに最も金銭的に有益なスループット要求特性を実現することにより、ネットワーク事業者にとっての利益を増大させることもできる。
【００６８】
さらに、データ・パケットの宛先アプリケーション（destination-application）におけるバッファの限界ないし処理速度の制限により、データ・スループットの限界値Ｒｈが必要となることもある。最大のデータ・スループット条件を超えると、受信側のサイトでは、とりわけバッファのオーバーフロー・エラー（overflow errors）やペイロード・データ・パケットの受入れ拒否（rejection）が発生し得ることになる。
【００６９】
さらにオプションのパラメータとして、ペイロード・データ・パケットの配信デッドライン超過のケースにおいて利用するための最大スケジューリング許容限度（maximum scheduling tolerance）Ｄがある。このパラメータＤは、単一のペイロード・データ・パケット、同期エンティティ又はサブ−ストリーム全体が遅延され得る、許容限度を与える。
【００７０】
さらに、オプションのタイプ・パラメータＴは、例えばＭＰＥＧ、ボイス・オーバーＩＰ（Voice over IP）若しくはこれら以外の、データ・トラヒックのタイプを特徴付ける（示し表す）。そのトラヒックのタイプに基づき、パケット・スケジューラは、デッドライン超過のケースにおいてペイロード・データ・パケットに対する適切な適応化方法を選択することができる。
【００７１】
また、受入れ制御パケットＡＣＰは、受入れ制御パケットＡＣＰにより制御されるサブ−ストリームに属する同期制御パケットを識別するのに利用する識別子ＩＤを含むものとしてもよい。
【００７２】
加えて、受入れ制御パケットは、他のパラメータを含むものとしてもよい。この他のパラメータとしては、その受入れ制御パケットに属するとのデータ・パケットの識別をサポートするものが挙げられる。これは、トラヒック・ソース若しくは中間ネットワーク・ノードからパケット・スケジューラ若しくはネットワーク・ノードないし一般的には受入れ制御パラメータを利用する装置若しくはアプリケーションへのデータ・パケットの伝送の間にそれらのデータ・パケットの伝送順序が変更される場合において、必要となり得るものである。
【００７３】
図３は、本発明の好ましい実施形態において受入れ制御を記述したものである。受入れ制御パケットＡＣＰは、受入れ制御装置で受信され（１０）、あるいは一般的には、ネットワーク・ノード若しくはアプリケーションで受信される。その受入れ制御パケットＡＣＰは、リアルタイムのデータ・トラヒックを運ぶ次に来るサブ−ストリームと関係している。受入れ制御装置は、その受入れ制御パケットＡＣＰから受入れ制御パラメータＲｌ、Ｒｈ、Ｔを読み取る（２０）。一つの実施形態としては、制御装置が最小スループット・パラメータＲｌだけを読み取る。図３に示した別の実施形態では、制御装置が３つのパラメータＲｌ、Ｒｈ、Ｔを読み取る。
【００７４】
次に、受入れ制御装置は、制御装置において現行スループット（currently used throughput（現時点で用いられているスループット））Ｖｃを判断する（３０）。これは、とりわけ受入れ制御装置が現在時間毎に送信しているビットの数をカウントすることによって行うことができる。特に、リアルタイムのデータ・トラヒック以外のトラヒック・タイプの配信が何等の時間的な制約も超過せずに容易く遅延させることができるので、現行スループットの測定は、リアルタイムのデータ・トラヒックだけを考慮するものとしてもよい。後者のケースにおいては、現在処理されているトラヒックのタイプをパケット・スケジューラが認識しているので、現行スループットのパラメータＶｃをパケット・スケジューラが与えることにしてもよい。
【００７５】
次のステップ４０において、受入れ制御装置は、制御装置での利用可能な最大のスループットＶｍａｘと現行スループットＶｃとの差を計算することにより、利用可能なスループットＶを判断する。受入れ制御装置は、チャネル測定（channel measurements）、メッセージング（messaging）又は要求（a request）により、ルックアップ−テーブル（lookup-table）から、固定値として最大スループット能力（maximum throughput capability）Ｖｍａｘを認識する。
【００７６】
次に、制御装置は、要求されたスループットＲｌと利用可能なスループットＶを比較する（５０）。利用可能なスループットＶが要求されたスループットＲｌより高いか又はこれに等しい場合には、制御装置は、その受入れ制御パケットＡＣＰに属するデータ・パケットのサブ−ストリームのリアルタイム処理を受け入れることができる。図３に示した実施形態では、受入れ制御装置は、さらに、利用可能なスループットＶ及び最大の希望されたスループットＲｈの、最小Ｍを計算する（６０）。次のステップ７０において、受入れ制御装置は、最小の要求されたスループットＲｌと最小Ｍとによって与えられる範囲からサブ−ストリームに対して最も金銭的に有益なスループット・レートを選択する。これは、例えば線形スループット−利益関数（linear throughput-profit function）等の、ネットワーク事業者により与えられる利得関数に従った選択によって、行うことができる。
【００７７】
他の実施形態としては、最小の要求されたスループットＲｌ及び最大のスループットＲｈによって与えられる範囲のうちから金銭的に有益なスループット・レートを制御装置が暫定的に選択するものとすることができる。その選択されたスループット値が利用可能でない場合には、パケット・スケジューラでリアルタイム処理に対して既に受け入れられているサブ−ストリームの適応化を制御装置が起動して当該選択されたスループット値を利用可能とするようにすることができる。リアルタイム処理に対して受け入れられているサブ−ストリームの各データ・パケットは、パケット・スケジューラに送られる（８０）。それらがリアルタイム処理に受け入れられるかどうかの情報は、信号授受（signalling）を通じて、あるいは、リアルタイムのトラヒック用に予約されたパケット・スケジューラにおける専用の伝送チャネルないし専用のポートを利用することにより、受入れ制御装置からスケジューラへと与えることができる。スループット・レートが選択されている場合、それを伝える通信は、同様にしてパケット・スケジューラないし出力インタフェースＯＩ（output interface）に対して行い、サブ−ストリームのさらなる処理のために考慮されるようにすることができる。
【００７８】
リアルタイム処理に対して受け入れられないサブ−ストリームのデータ・パケットは拒否される。この受入れ拒否を実行する一つの方法としては、トラヒック・ソース、中間ゲートウェイないし受信側（受信機）等の他の当事者機器に対してさらなる警告（notice）を行い、あるいは、これを行わずに、受入れ制御装置によってデータ・パケットの削減（dropping）をすることが挙げられる。警告通知（notification）の一つの方法としては、否受信応答（negative acknowledgement）を含む修正された受入れ制御パケットＡＣＰを受入れ制御装置から送ることができるが、他の信号授受メカニズムを利用することも可能である。あるいは他の形態としては、受入れ拒否の対象となるデータ・パケットをバッファリングすると共に、（例えば受入れ制御パケットの交換を通じて）スループット要求特性についての送信側（トラヒック・ソースないし中間ゲートウェイ）とのネゴシエーション（negotiation）を開始するものとすることができる。本発明の他の実施形態では、サブ−ストリームのデータ・パケットは、リアルタイム処理ではなく通常の処理（regular processing）のためにパケット・スケジューラへ送られる。通常の処理は、その後、例えば最善努力型のアプローチやＦＩＦＯ方策（FIFO-strategy）（ファースト・イン−ファースト・アウト）に従って行われる。パケット・スケジューラへ送られるデータ・パケットがリアルタイム処理に対して受け入れられるかどうかの情報は、上述したように、信号授受を通じて、あるいは、その伝送のための専用の伝送チャネルないし専用のポートを利用することにより、スケジューラに対して与えられる。
【００７９】
図３に示した本発明の実施形態においては、パケット・スケジューラにおいて現在リアルタイム処理のためにスケジューリングされており、かつ、現在利用可能なスループットＶｃを占有している、データ・パケットの適応化の実現可能性（feasibility）がチェックされ（９０）、実現可能であれば、パケット・スケジューラにおいて利用可能なスループットＶを増加させることが実行される（１１０）。その適応化が実現可能でなければ、サブ−ストリームは最終的に拒否される（１００）。
【００８０】
例えば最早期−デッドライン−ファースト待ち行列ＥＤＦ（earliest-deadline-first queue EDF）において、リアルタイム処理のために現在スケジューリングされているペイロード・データ・パケットの適応化は、例えば、異なる圧縮方式（compression scheme）若しくはより効率的な圧縮方式を用いることによって行うこともでき、一定のパケットを削減することによって行うこともでき、あるいは、他のトラヒック・タイプに応じて定まるメカニズムによって行うこともできる。適切な適応化の方法は、データ・トラヒック・タイプＴを考慮して選択し、例えば、ＭＰＥＧ画像ストリームの解像度の低減、いくつかのボイス・オーバーＩＰパケットの削減、２５６色画質（256-colour pictures）の１６色画質への変換等のようにする。通常、これらのよく知られた適応化の方法は、‘作動中に’（‘on the fly’）実行することができ、その結果として利用可能なスループットＶをより高くする。
【００８１】
前記適応化の後に、現行のスループットＶｃが判断され（１２０）、そして利用可能なスループットＶが計算される（１３０）。その後、上述した規準（criteria）に基づく最終的な判断（５０）と上述したスループット値の選択（６０、７０）を伴う処理が、リアルタイム処理のためのサブ−ストリームの、受入れについて行われ（８０）、あるいは、受入れ拒否について行われる（１００）。
【００８２】
図４は、リアルタイム処理に対するデータ・パケットのサブ−ストリームの受入れないし拒否をする受入れ制御装置ＡＣと、リアルタイム処理に対して受け入れられたデータ・パケットのための第１の待ち行列ＥＤＦと、ファースト・イン−ファースト・アウトのような最善努力型の方策に従って処理されるデータ・パケットのための第２の待ち行列ＦＩＦＯとを有する、パケット・スケジューラを示している。第２の待ち行列ＦＩＦＯは、リアルタイム処理に対して拒絶されるデータ・パケットのために使用される。パケット・スケジューラのさらなる実施形態としては、例えばスケジューラの容量を増大させるために、一つ以上のタイム−スタンプ・ベース（time-stamp based）のＥＤＦ待ち行列及び一つ以上のＦＩＦＯ待ち行列を有するものとしてもよい。
【００８３】
第１の待ち行列ＥＤＦにデータ・パケットのサブ−ストリームを送ることにより、受入れ制御装置は、リアルタイム処理にデータ・パケットを受け入れる。この第１の待ち行列ＥＤＦは、タイム−スタンプ・ベースであり、かつ、最早期−デッドライン−ファーストの方策に従って動作する。ＥＤＦ待ち行列中に格納（記憶ないし蓄積）された各データ・パケットは、タイム・スタンプを取得し、そのタイム・スタンプの値は、当該各データ・パケットの配信デッドラインに設定される。ここでタイム・スタンプの値として設定される配信デッドラインは、同期制御パケットによって与えられる同期制御パラメータから計算することができる。読出については、ＥＤＦ待ち行列は、常に、最も近い配信デッドラインを有するデータ・パケットを供給する。したがって、ＥＤＦ待ち行列は、最も近い配信デッドラインを有するデータ・パケットの直接アクセス処理（direct-access processing）のために、すべての配信デッドライン及び対応するデータ・パケットの経過を監視できるものとなっており、あるいは他の形態として、それは、新たなデータパケットがＥＤＦ待ち行列中に伝送される度にペイロード・データ・パケットをそれらの配信デッドラインに基づいて再ソート（re-sort）し、ＥＤＦ待ち行列の出力において常に最も近い配信デッドラインを有するデータ・パケットをシーケンシャル処理（sequential processing（順序処理））の形態で供給できるものとなっている。
【００８４】
パケット・スケジューラは、出力インタフェースＯＩを有し、この出力インタフェースＯＩがさらなる処理のために各待ち行列に含まれているデータ・パケットに優先順位を付ける（prioritise（優先するものから順に処理する））。これは、待ち行列の選択、その待ち行列からのデータ・パケットの読出、及びさらなる処理に対するそのデータ・パケットの供給を含む。待ち行列の選択については、種々の方策を採ることが可能であり、ＥＤＦ待ち行列が空（empty）になるまでないしは一定の閾値に到達するまで常にＥＤＦ待ち行列の方を選択するようにしたり、あるいは、待ち行列毎に固定的な読出の速度に基づく方策や例えばトラヒック・タイプＴを考慮して動的に読出速度を決定する方策を採用したりすることも可能である。さらなる処理に対するデータ・パケットの供給は、ポーリング（polling）のメカニズムや他のメカニズムにより、通信チャネルを通じてデータ・パケットを伝送することによって行うことができる。
【００８５】
図５は、受入れ制御装置から送られるデータ・パケットの入来（incoming）サブ−ストリームに対するパケット・スケジューラのタスクを示している。サブ−ストリームがリアルタイム処理に受け入れられると（２１０）、それぞれのペイロード・データ・パケットについて個々の配信デッドラインが計算される（２３０）。リアルタイム処理に対する受入れは、パケット・スケジューラにより、受入れ制御装置から受信される信号授受メッセージを通じて、あるいは、リアルタイム・トラヒック用に予約された専用の通信チャネル上ないし専用のポートでのデータ・パケットの到達を通じて、認定（recognise）することができる。図５に示した実施形態においては、パケット・スケジューラで受信され、かつ、リアルタイム処理に受け入れられるすべてのデータ・パケットは、ＥＤＦ待ち行列に転送され（２２０）、他のすべてのデータ・パケットは、それらが現れた順に、第２の待ち行列ＦＩＦＯに転送され（２５０）、かつ、第２の待ち行列ＦＩＦＯ内にソート（整列ないし並べ替え）される（２６０）。この第２の待ち行列ＦＩＦＯは、最善努力型の方策に従って処理される。
【００８６】
パケット・スケジューラは、ＥＤＦ待ち行列で受信された同期制御パケットＳＣＰから同期制御パラメータを読み取り、ＥＤＦ待ち行列に送られたそれぞれのペイロード・データ・パケットについて個々の配信デッドラインを計算によって判断（決定）する。好ましい実施形態では、このデッドラインは、パケット・スケジューラにより許容された最新の配信時間を表す。他の実施形態としては、そのデッドラインは、データ・パケットの宛先における最新の到達時間を表すものとすることができる。デッドラインについては、絶対時間ないしタイマ−ベース（timer-based）の時間の値を用いることができる。次のステップ２４０においては、ペイロード・データ・パケットがＥＤＦ待ち行列中に格納されると共に、ＥＤＦ待ち行列のタイム・スタンプが配信デッドラインに設定される。各待ち行列中にソートされたペイロード・データ・パケットは、上での説明に従い、例えば出力インタフェースＯＩにより、さらなる処理に対する準備ができているものとなる。
【００８７】
本発明の好ましい実施形態においては、個々のペイロード・データ・パケットについての配信デッドラインは、同期制御パラメータＳ、Ｎ及びＩから計算する。さらに、パケットの番号ｉ及び現時点でのパケットの到達時間ｔを計算のために利用する。また、パケット・スケジューラがさらなる伝送のためにパケット転送をスケジューリングする、チャネルｊのパケット誤り率Ｐｊ及びビット・レートＲｊを計算において利用する。後者の各値は、リアルタイムの待ち行列がどの程度速く空になるかを示す。
【００８８】
番号ｉは、同期エンティティＳＥにおけるパケットのシーケンス番号であり、ｉ∈｛１…Ｎ｝に従う。それは、例えばパケット・スケジューラにおいて、一定の同期エンティティＳＥに属している入来ペイロード・データ・パケットをカウントすることによって判断される。
【００８９】
時間の値ｔは、受入れ制御装置における個々のペイロード・データ・パケットの到達時間を表す。それは、受入れ制御装置によって判断することができ、パケット・スケジューラに対して信号で伝えることができる。他の形態としては、パケット・スケジューラにおける到達時間が著しく異なるものでなければ、代わりにそのパケット・スケジューラにおける到達時間を用いることもできる。後者のケースにおいては、パケット・スケジューラがパケットの到達時間を判断する。
【００９０】
通常では、パケット誤り率Ｐｊは、リンク・レイヤ測定（link layer measurements）から取得される。例えば、いわゆるＷＣＤＭＡシステムにおいては、チャネルのパケット誤り率Ｐｊをいわゆる閉ループ電力制御による信号対雑音割当量（signal to noise ration）から判断することができる。
【００９１】
本発明の他の実施形態としては、タイムスロット毎の誤り率、クライアント毎の誤り率又はネットワーク毎の誤り率を配信デッドラインの判断（決定）に利用することもできる。好ましい実施形態では、選択的な繰返し（selective repeat）をリンク・レイヤの誤り訂正として利用する。
【００９２】
ビット・レートＲｊは、例えば入来するビットをカウントすることにより、受入れ制御装置やパケット・スケジューラにおいて判断することができる。
【００９３】
本発明の好ましい実施形態においては、それぞれのペイロード・データ・パケットについてのデッドラインを次のように計算する。
【数３】
2007312413.tif 000003
【００９４】
さらに好ましい実施形態においては、ＥＤＦ待ち行列中にソートされたペイロード・データ・パケットについての配信デッドラインの超過をパケット・スケジューラが検出する。この超過の検出は、それらの配信デッドラインを、システム時間（system time）を用いて判断される、例えばデータ・パケットがＥＤＦ待ち行列中で費やした時間等の、実際の時間の値と比較することによって行う。超過が検出された場合には、先に説明した方法に従ってペイロード・データ・パケットの適応化を実行する。
【００９５】
異なるリアルタイム・アプリケーションが許容する遅延の許容限度はそれぞれ異なる。この状況において適応化を実行する一つのやり方としては、データ・パケットの特定のサブ−ストリームについて遅延の許容限度を定義する、受入れ制御パラメータＤを利用することが挙げられる。一定レベルのデッドライン超過が検出された場合には、適応フレームワーク（adaptive framework）が１つ又は２つ以上のサブ−ストリームを降格（degrade）させて安定状態に入るようにすることができる。
【００９６】
本発明は、概してパケット・スケジューラ及び受入れ制御装置を含む、通信システムのネットワーク・ノードにおいて具現することができる。特に、当該ネットワーク・ノードにおいて、そのネットワーク・ノードからのデータ・パケットのさらなる伝送のために使用される通信チャネルｊのパケット誤り率Ｐｊを判断するパケット誤り率判断ユニットと、当該チャネルのビット・レートＲｊを判断するビット・レート判断ユニットと、そのネットワーク・ノードにおいてデータ・パケットの現時点での到達時間ｔを判断するタイマと、データ・パケット・トラヒック・フローに埋め込まれた制御データ・パケットＳＣＰ、ＡＣＰにより与えられる制御パラメータＩ、Ｓ、Ｎ、Ｒｈ、Ｒｌ、Ｄ、Ｔを評価する評価手段（evaluation means）と、配信デッドラインを計算する計算機ユニットと、それぞれのデッドラインに基づいてスケジューリングされるデータ・パケットを受信する第１の待ち行列ＥＤＦとにより、本発明を具現することができる。
【００９７】
さらなる実施形態として、第１の待ち行列ＥＤＦは、第１の待ち行列ＥＤＦ中にデータ・パケットをソートすると共に、計算された配信デッドラインをタイム−スタンプとしてそれらのデータ・パケットに割り当てる、ソーティング・ユニットを含むものとすることができる。そのソーティング・ユニットは、最早期−デッドライン−ファーストの方策に従って処理をする。
【００９８】
さらに、ネットワーク・ノードは、例えば先に説明した方法に従って、現在利用可能なスループットＶを判断する判断ユニットを有するものとしてもよい。判断手段（decision means）は、受入れ制御パラメータにより与えられるスループット要求特性と利用可能なスループットＶをチェックした後に、リアルタイム処理に対して入来するトラヒック・フローないしデータ・パケットのサブ−ストリームを受け入れる。また、その判断手段は、例えば、トラヒック・フローないしサブ−ストリームに対して最も金銭的に有益なスループット・レートを選択するためのルック−アップ・テーブルによる利得関数を有するものとしてもよい。その判断手段は、上述した方法に従い、データ・パケットのリアルタイム処理を受入れ、あるいは、拒否することができる。
【００９９】
第２の待ち行列ＦＩＦＯは、リアルタイム処理について拒否されたデータ・パケットを受信することができる。データ・パケット、サブ−ストリームないしトラヒック・フローを適切な待ち行列に分配（配信）するためのインタフェース、すなわち、拒否されたサブ−ストリームを第２の待ち行列ＦＩＦＯに分配すると共に受け入れられたサブ−ストリームを第１の待ち行列ＥＤＦに分配するためのインタフェースを、転送ユニットが形成する。
【０１００】
出力インタフェースは、記述の方法に従ってすべての待ち行列を優先するものから順に処理する。
【０１０１】
ネットワーク・ノードは、さらに、少なくとも一つのペイロード・データ・パケットの適応化のための適応化ユニットを有するものとすることができる。その適応化は、第１の待ち行列ＥＤＦに含まれるデータ・パケットに対して実行することができ、また、ネットワーク・ノードに到達したデータ・パケットに対して実行することもできる。さらに、ネットワーク・ノードは、第１の待ち行列ＥＤＦ中にソートされたペイロード・データ・パケットの配信デッドラインを監視すると共に、安定したシステム状態を取り戻すために配信デッドライン超過のケースにおいてペイロード・データ・パケットの適応化を開始する、デッドライン超過処理機（deadline violation handler）を有するものとすることができる。その適応化は、例えば事業者の利益を最適化するための利得関数に基づき、前記判断手段によって起動することもできる。
【０１０２】
他の好ましい実施形態としては、パケット・スケジューリング及び受入れ制御をパケット交換セルラー無線アクセス・ネットワーク（packet switched cellular radio access network）の無線基地局において実行する。また、他の形態として、本発明は、エンド−ユーザの端末機上で実行されるアプリケーションにおいて利用することにしてもよい。
【０１０３】
他の実施形態として、本発明は、コンピュータ・プログラム（アプリケーションとも呼ばれる）、又はコンピュータ、移動機若しくは他の通信装置のような処理装置と共に使用するためのコンピュータ・プログラム製品（computer program product）として、実現するものとしてもよい。そのコンピュータ・プログラムの当該処理装置に対する配信（頒布）は、特に、リード・オンリ・メモリＲＯＭ（read only memory）装置、いわゆるＣＤ−ＲＯＭディスク、フロッピー（登録商標）・ディスク若しくはハード・ディスクにより、若しくはネットワークのような通信媒体を通じて、若しくはモデムを介して、又はエア・インタフェース（air interface）を介した無線により、行うことができる。
【０１０４】
処理装置の通常の処理に加えて、その処理装置上でそのコンピュータ・プログラムが実行される場合には、それの記憶されたプログラムによるそれぞれのコンピュータ・プログラム製品である、そのコンピュータ・プログラムのソフトウェア・コード部分（software code portions）が、パケット・スケジューリング及び／又は受入れ制御を実行する。
【０１０５】
通常では、前記コンピュータ・プログラムは、パケット・スケジューリング及び／又は受入れ制御のための先に説明した方法の観念における命令を実行する間に作動する。
【０１０６】
特に、受入れ制御については、そのコンピュータ・プログラムのソフトウェア・コード部分は、デジタル・コンピュータのメモリ内にロードされてそのデジタル・コンピュータ上で実行され、始めにデータ・パケット・ストリームにおける受入れ制御パケットＡＣＰを検出するステップを実行する。これは、それぞれの時点で受信したデータ・パケットの構造と受入れ制御パケットＡＣＰの既知の構造を比較することによって行うことができる。受入れ制御パケットＡＣＰが見つかった場合には、その制御パラメータＲｈ、Ｒｌを読み取る。次のステップでは、処理装置で取り扱うことができ、かつ、アプリケーションに対して固定された値として与えられる全体のスループットＶｍａｘと、例えばリンク・レイヤ測定により、処理装置が与えることが可能な現在占有しているスループットとの、差として、処理装置において利用可能なスループットＶを計算する。さらに次のステップでは、そのコンピュータ・プログラムは、要求されたスループットＲｌを利用可能なスループットＶと比較する。利用可能なスループットＶが要求されたスループットＲｌよりも低い場合には、受入れ制御パケットＡＣＰに属するサブ−ストリームが拒否される。そうでない場合には、要求されたスループットＲｌと第２のスループット値とによって与えられる範囲のうちからスループット値を選択する。ここにいう第２のスループット値とは、利用可能なスループットＶ及び最高の希望されたスループットＲｈのうちの最小値である。他の実施形態としては、その第２のスループット値は、利得関数によって処理装置から先に説明したのと同様にして供給される。前記スループット値の選択後に、サブ−ストリームがリアルタイム処理に受け入れられる。
【０１０７】
さらなる実施形態として、受入れ制御を実行するソフトウェア・コード部分は、処理装置のＶｍａｘ及びＶ等のようなスループット能力を含む、修正した受入れ制御パケットを生成する。その修正した受入れ制御パケットは、先に述べた理由により、サブ−ストリームの伝送路に沿って送り返される。
【０１０８】
コンピュータ・プログラムの追加のソフトウェア・コード部分、あるいは他の形態のさらなるコンピュータ・プログラムのソフトウェア・コード部分は、実行中にパケット・スケジューリングを実行する。始めに、データ・パケット・ストリームにおいて同期制御パケットを検出する。次に、それの同期制御パラメータＮ、Ｉ及びＳを読み取る。パケット・スケジューリング・アプリケーションからのペイロード・データ・パケットの伝送用に予見（foresee）される伝送チャネルｊのパケット誤り率、当該チャネルのビット・レート、及び当該アプリケーションにおけるペイロード・データ・パケットの現時点での到達時間を示すタイマの値ｔを、例えば処理装置からの測定ないしポーリングのルーチンによって判断した後に、同期制御パケットＳＣＰが関係する（示す）同期エンティティＳＥに属するそれぞれのペイロード・データ・パケットについて配信デッドラインを計算する。ペイロード・データ・パケットは、それらのデッドラインの順序で待ち行列ＥＤＦ内にソートされ、待ち行列ＥＤＦがそれぞれのデータ・パケット・スロット（data packet slot）に対してタイム・スタンプを与える。それぞれのスロットのタイム・スタンプは、個々に、そのスロット中に格納されたデータ・パケットの計算された配信デッドラインに設定される。
【０１０９】
本発明のさらなる好ましい実施形態としては、リアルタイム処理に受け入れられるデータ・パケットについてのみ配信デッドラインを計算する。
【０１１０】
コンピュータ・プログラムによりリアルタイム処理に対して拒否されるデータ・パケットは、第２の待ち行列ＦＩＦＯに格納し、最善努力型の方策によって処理されるようにすることができる。
【０１１１】
さらに、コンピュータ・プログラムは、データ・パケットの読出をしている間の双方の待ち行列に対する優先順位付け（prioritisation）を実行してリアルタイム処理に受け入れられたデータ・パケットの処理の方を選ぶように、処理装置に対する命令をするものとしてもよい。
【０１１２】
さらなる実施形態としては、コンピュータ・プログラムのソフトウェア・コード部分は、処理装置に対し、絶対時間ないし相対時間を与える実際の時間値を各タイム・スタンプに格納された配信デッドラインと比較することにより、第１の待ち行列ＥＤＦ中に格納されたペイロード・データ・パケットの配信デッドラインを監視することを命令する。そのようにすると、コンピュータ・プログラムは、配信デッドライン超過を検出できることになる。さらなるステップでは、第１の待ち行列ＥＤＦのペイロード・データ・パケットの適応化を実行することができ、あるいは他の形態として、その適応化を別個のアプリケーションから要求することができる。
【０１１３】
ペイロード・データ秘匿や他のセキュリティ・メカニズムを利用するデータ・パケット・ストリームをも取り扱うためには、コンピュータ・プログラムは、同期制御パラメータ及び／又は受入れ制御パラメータをデータ・パケットＳＣＰ、ＡＣＰ自体から読み取るのに加えて、あるいは、これに代えて、その同期制御パラメータ及び／又は受入れ制御パラメータを下層にあるネットワーク・プロトコルのヘッダから読み取る、ソフトウェア・コード部分を与えるものとすることができる。
【０１１４】
さらに、以下の過程を有する方法を実行することができる。すなわち、リアルタイムのデータ・トラヒックを搬送し、かつ、受入れ制御装置ＡＣで受信されるデータ・パケット・ストリームにおいて、受入れ制御パラメータを含む第１の受入れ制御パケットＡＣＰを検出する過程と、前記第１の受入れ制御パケットから少なくとも２つの受入れ制御パラメータＲｌ、Ｒｈを読み取る過程と、前記受入れ制御装置ＡＣで利用可能な全体のスループットＶｍａｘと現在占有されているスループットＶｃとの差としてスループットＶを計算する過程と、スループットＶを要求されたスループットＲｌと比較する過程と、利用可能なスループットＶが最低の要求されたスループットＲｌよりも低い場合に前記第１の受入れ制御パケットと第２の受入れ制御パケットとの間に続いて来るデータ・パケットのサブ−ストリームのリアルタイム処理を拒否する過程、又はそれ以外の場合に最低の要求されたスループットＲｌと第２のスループット値Ｒｈ、Ｍを限界値として含むスループット値の範囲からスループット値を選択すると共に前記サブ−ストリームのリアルタイム処理を受け入れる過程とを、有する方法を実行することができる。さらなる実施形態においては、好ましくは、上記過程に加えて、前記受入れ制御装置ＡＣのスループット能力パラメータを含む修正した受入れ制御パケットを生成して受入れ制御装置ＡＣからサブ−ストリームの伝送路に沿って送り返す過程を実行する。
【０１１５】
特許請求の範囲においては双方の特徴を組み合わせて記載しているだけだが、より後で述べた受入れ制御の特徴と関係する実施形態の過程については、オプションとして（任意選択的に）同期制御の特徴と関係する過程から独立したものとすることができる。双方の特徴は、例えば、対応する方法ないし対応するコンピュータ・プログラムにより、互いに対して独立して、実現することができる。
【０１１６】
現在実践的と考えられるものと好ましい実施形態に関連して本発明の説明をしたが、本発明は、開示した実施形態に限定されるものではなく、それどころか逆に、本発明は、特許請求の範囲の精神及び領域の中に含まれる様々な変形や均等な装置を包含するものと解釈される。
【図面の簡単な説明】
【０１１７】
【図１】図１ａがそれぞれ異なる同期エンティティを伴う画像ストリームを示し、図１ｂがそれぞれ異なる同期エンティティを伴う他の画像ストリームを示し、図１ｃが受入れ制御パケットＡＣＰ及び同期制御パケットＳＣＰｓを伴うデータ・パケット・ストリームを示す。
【図２】図２ａがＳＣＰ中に含まれるパラメータを示し、図２ｂがＡＣＰ中に含まれるパラメータを示す。
【図３】受入れ制御装置のタスクを流れ図に示したものである。
【図４】パケット・スケジューラの機能図を示したものである。
【図５】パケット・スケジューラのタスクを流れ図に示したものである。
【図１】
2007312413.tif 000004
【図２】
2007312413.tif 000005
【図３】
2007312413.tif 000006
【図４】
2007312413.tif 000007
【図５】
2007312413.tif 000008
【手続補正書】
【提出日】平成19年8月7日(2007.8.7)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、通信システムにおけるパケット・データ・トラヒックの処理に関する。また特に、本発明は、データの各パケットのスケジューリング及び受入れ制御（admission control）に関する。
【背景技術】
【０００２】
従来技術によれば、パケット指向の通信ネットワークにおける品質条件の規定（the provision of quality of service）に関しては、既知のコンセプトが２つある。
【０００３】
一つのコンセプトは、専用のデータ・パケット・ストリームのためにリソースを予約（reservation）することに基づくいわゆる総合サービス・コンセプト（Integrated Service Concept）である。それらのリソースの予約をするためには、ペイロード・データの伝送前に要求特性のピア・ツー・ピア信号授受（peer-to-peer signalling of requirements）をする必要がある。伝送路の間にあるすべてのネットワーク・ノードに対しては、対応するリソースを予約することが要求される。総合サービス・コンセプトについては、D. Clark等のSupporting Real-time Applications in an Integrated Services Packet Network: Architecture and Mechanisms, Proceedings SIGCOMM 92, August 1992に開示されている。
【０００４】
公知の信号授受プロトコルとしては、L. Zhang等のRSVP: A New Resource Reservation Protocol, IEEE Network Magazine, Sept. 1993に開示されたいわゆるリソース予約プロトコルＲＳＶＰ（Resource Reservation Protocol）がある。ＲＳＶＰは、通信路に沿った一方の方向におけるリソースを予約する受信側指向の単信方式プロトコルである。データ・フロー（データの流れ）の受信側には、リソース予約の開始をすることが課される。
【０００５】
いわゆるＴＥＮＥＴ方式は、総合サービス・コンセプトに類似している（D. Ferrari等のA Scheme for Real-Time Channel Establishment in Wide Area Networks, IEEE Journal on Selected Areas of Communications, Vol. 8, pp. 368-379, 1990参照）。それは、パケット交換による広域のネットワークにおけるリアルタイムのサービスのために保証される遅延を定めており、パケット・フロー（パケットの流れ）毎に帯域幅（回線容量）の割当ができるものとなっている。この方式においては、通信チャネルを確立する時に各クライアントが自身のトラヒックの特性とパフォーマンスの要求特性を宣言する。データ・パケットは、チャネルが確立された後に、各ホストコンピュータや各ネットワーク・ノードにおけるデッドライン（deadlines）に基づいてスケジューリングされる。そのようにするために、スケジューラは、少なくとも３つの待ち行列（queues）を保持している。ここにいう３つの待ち行列とは、確定的パケット（deterministic packets）のための待ち行列、統計的パケット（statistical packets）のための待ち行列、並びに他のすべてのタイプのパケット及びすべてのローカル・タスクのための第３の待ち行列である。
【０００６】
品質条件を規定するためのもう一つのコンセプトは、いわゆる差別化サービス・コンセプト（Differentiated Service Concept）である。差別化サービス・コンセプトは、プロトコル・ヘッダにおける優先順位ビット（priority bits）の利用により、品質条件の要求特性によるパケットの分類及びスケジューリングを簡略化することを図ったものである。特定の品質条件クラスに属しているすべてのパケットは、対応する優先順位ビットの組合せをインターネット・プロトコルのヘッダ中に付されることになる。各パケット・フローは、ネットワークの端部（edge）におけるサービス水準契約（Service Level Agreement）に従い、優先順位ビットを付され、かつ、規制される。ネットワークの内部では、各パケットが優先順位ビットに基づいてスケジューリングされる。差別化サービス・コンセプトについては、S. Blake等のAn Architecture for Differentiated Services, IETF RFC 2475, December 1998が参考になる。
【０００７】
ボトルネック（bottlenecks（隘路））を含む通信ネットワークにおいては、リアルタイムないしほぼリアルタイムのマルチメディア・アプリケーションのデッドライン超過（deadline violations）を最小にするための、データ・パケット・ストリームの受入れ制御とデータ・パケットの伝送順序のスケジューリングとが重要なタスクとなる。以下、‘リアルタイム’（‘real-time’）の用語は、‘ほぼリアルタイム’（‘near real-time’）とも解釈され、また、概して‘タイム−クリティカル’（‘time-critical’）とも解釈されるものとする。複数の異種ネットワークにおいては、一つのネットワークからのトラヒックが別のネットワークへと進行する所のネットワークの境界にボトルネックが生じる。
【０００８】
一つのデータ・パケットだけが遅延される場合では、通常は期待されるリアルタイムのデッドラインを超えない。その代わりに、複数データ・パケットの組は、例えばマルチメディア出力の一部を表示するのに間に合うように宛先へ到達する必要がある同期エンティティ（synchronisation entity）にまで広がるのが通常である。
【０００９】
アプリケーションや中間ノード（intermediate nodes）は、ますます高度なものとなってきており、マルチメディアへの適応化を考慮している。このため、ある種のマルチメディアのオブジェクトないしプレゼンテーション（通知）を伝送するために必要なデータ帯域幅（データの回線容量）の総量は固定的でないものとなる。適応化のプロセスは、低優先順位のパケットの削減（dropping（落としないし減らすこと））や階層マルチメディア符号化（hierarchical multimedia coding）、適応アプリケーション（adaptive application）、帯域幅適応化ゲートウェイ（bandwidth adaptation gateways）、あるいは、ネットワーク・ノード内に処理素子を配備している対等動作ネットワーク（even active networks）のような、いくつかの手段によって行うことができる。これにより、輻湊（congestion）しているケースでは、ある間隔で帯域幅を変えることができる。必要とされる適応化のタスクをアプリケーションやネットワーク自体が遂行することにより、実際の伝送速度を変化させてデッドライン超過を避けるようにすることもできる。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
既存の受入れ制御とスケジューリングの方式は、バースト形態のパケット・ソース（bursty packet sources）に対して与えられるピーク・レート割当及び遅延保証による低度の帯域幅利用しか考慮していない。改良された方式は、過去の帯域幅使用を測定することによって実際に使用可能な帯域幅を予測する測定アルゴリズムを適用することにより、より高度な帯域幅利用に到達している。しかしながら、測定に基づくアルゴリズムは、薄弱な保証しか与えず、かつ、大量の統計的多重化によってのみ効率的に機能するに過ぎない。特に無線ネットワークに関しては帯域幅の加入者容量に限界があるのが通常であり、このことから測定に基づく確定的受入れ制御の方式ではパフォーマンスが乏しい。一つの理由は、パケット・スケジューリングのための既存の方式がそれぞれのパケットを同じ取扱い方で処理している点にある。それらの方式は、受信する各アプリケーションに関係する過去のデッドラインを検出することができず、このことから現在（その時点）のシステムを誤り無し状態（error-free state）にするプロセスを起動することもできない。
【００１１】
伝統的な方式では、それぞれのパケット・ストリームを優先順位クラス（priority class）に分類する。総合サービス・コンセプトにおいては、この優先順位クラスは、個別のストリームのパケットが受ける（経験する）ことになる平均遅延に属する。差別化サービスのアプローチにおいては、この優先順位クラスは、他のものよりも少ない遅延を有するものとすべきトラヒック・タイプに属する。優先順位クラスは、通常は平均遅延に制限され、パケットは、その優先順位クラスに受け入れられるときにその平均遅延を受けるものと予定される。可変のビット・レートを伴う（画像ストリーム（video streams）のような）マルチメディア・ストリームを考える場合には、単一のストリームの各パケットが終始同じ遅延の要求特性を有することにはならない。その代わりに、本発明によって提案されるようなそれぞれの個々のパケットに対する配信デッドラインの決定（determination of a delivery deadline）によるスケジューリングは、優先順位に基づくスケジューリングよりも良好なパフォーマンスを提供する。
【課題を解決するための手段】
【００１２】
このようなことから、本発明は、それらの問題及び他の問題を克服し、特にリアルタイムのデータ・トラヒックを伝えるデータ・パケットのデッドライン指向のスケジューリング（deadline-oriented scheduling）を可能にする、パケット指向の通信システムに対する改良されたアプローチを提供することを目的としている。
【００１３】
この目的は、請求項の記載に基づく過程及び特徴を有する方法、装置及びソフトウェア・プログラムによって達成される。
【００１４】
本発明で述べられる解決手段は、リアルタイム処理の対象とされるペイロード・データ・パケットに対して個々の配信デッドラインを割り当てるという理由から有利（advantageous）なものとなっている。これは、パケットが終始有するそれぞれ異なる遅延の要求特性のために、可変ビット・レートを伴う単一のマルチメディア・ストリームのデータ・パケットに対して、特に有効である。それぞれの個々のペイロード・データ・パケットについての配信デッドラインの計算は、タイム−スタンプに基づく待ち行列によるペイロード・データ・パケットの最適なスケジューリングを可能にする。有利なことに、デッドラインの判断に必要な同期制御パラメータは、入来するデータ・パケット・ストリームにおいて埋め込まれる同期制御パケットＳＣＰから読み取られる。これは、制御パラメータの容易な処理を保証すると共に、追加の信号授受や複雑なプロトコル構造を回避する。
【００１５】
好ましい利用においては、同期制御パラメータとは別に、データ・パケット用の伝送チャネルのパケット誤り率Ｐｊ及びビット・レートＲｊのようなパラメータをデッドラインの計算に取り入れる。これにより、その時点での（現在ないし最新の）システム特性を容易に考慮することができ、それによってパフォーマンスが向上することになる。
【００１６】
本発明によれば、パケット・スケジューラにおいて各ペイロード・データ・パケットについて配信デッドラインが計算される前に受入れ制御を実行する、という点がさらに有利となっている。データ・パケットのサブ−ストリームのリアルタイム処理を受け入れる判断は、受入れ制御パラメータによって与えられる最小のスループット要求特性に応じて行われ、受入れ制御パラメータは、受入れ制御パケットＡＣＰから容易に読み取ることができる。有利なことに、利用可能なスループットより高いスループットを要求するデータ・パケットがリアルタイム処理に受け入れられないことから、スループット不足のためのデータ・パケットについての配信デッドライン超過を回避することができる。また、配信デッドラインの無駄な計算も回避される。
【００１７】
本発明によれば、受入れ制御が最大スループット・パラメータＲｈを考慮するという点が有利である。これは、最大スループットＲｈまでの範囲で利用可能なスループットから独立して、サブ−ストリームについて最小の要求されたスループットＲｌよりもコスト的に効率の良いスループットを選択することを可能にする。
【００１８】
さらに、高い方のスループット限界値Ｒｈは、データ・パケットの伝送速度が速過ぎることがないことを保証するので、通信システム内ないしデータ・パケット・ストリームの受信側におけるバッファのオーバーフローを回避することができる。
【００１９】
本発明によれば、リアルタイム処理に対して受け入れられないデータ・パケットのサブ−ストリームを拒否し、かつ、それをパケット・スケジューラに送るという点が有利である。これは、なおも最善努力型の処理を可能にするからである。したがって、データ・パケットの削減や関連して生じる情報の損失を回避することができる。
【００２０】
本発明によれば、リアルタイム処理に対して拒否されたデータ・パケットは、パケット・スケジューラにおいて第２の待ち行列ＦＩＦＯ中にそれらの現れた順序で格納される。これにより、第２の待ち行列ＦＩＦＯのデータ・パケットについてファースト・イン−ファースト・アウトの方策による最善努力型の処理が可能になる。
【００２１】
本発明によれば、第１の待ち行列ＥＤＦからのデータ・パケットは、それらの配信デッドラインに基づいてさらに処理され、第２の待ち行列ＦＩＦＯからのデータ・パケットは、ファースト・イン−ファースト・アウトの方策によって処理される。これにより、有利なことに、確立された品質条件の要求特性の下でのデータ・パケットのさらなる処理が作動される。
【００２２】
本発明によれば、出力インタフェースＯＩは、第１のＥＤＦ及び第２の待ち行列ＦＩＦＯにおけるデータ・パケットを優先するものから順に処理する。有利なことに、一方の待ち行列におけるデータ・パケットのブロッキング（blocking）は、双方の待ち行列からのデータ・パケットのある程度の読出を保証する、優先順位付けの方策を選択することによって回避することができる。
【００２３】
本発明によれば、修正された受入れ制御パケットを通じてスループット能力のフィードバックがデータ・パケット・サブ−ストリームの伝送路に沿って送り返される。有利なことに、これは、中間の通信システム・ノードやトラヒック・ソースがトラヒックを利用可能なスループット能力に適応させることを可能にする。これにより、リアルタイム処理に対するデータ・パケットの拒否を高度に（相当程度）回避することができる。修正した受入れ制御パケットの利用は、信号授受のオーバーヘッド（overhead）や複雑なプロトコル構造を回避することができる。
【００２４】
本発明によれば、同期制御パラメータは、下層にあるネットワーク・プロトコルのヘッダから受信される。これは、同期制御パラメータを読み取らせないようにはなっていないことから、ペイロードの秘匿及び認証を可能とする上に、いわゆるインターネット・プロトコルのＩＰｖ４、ＩＰｖ６及びＩＰＳｅｃの使用をサポートする。
【００２５】
本発明によれば、デッドライン超過を検出することができる。これにより、有利なことに、データ・パケットのリアルタイム処理を保証するための対策を起動することが可能になる。
【００２６】
本発明によれば、ペイロード・データ・パケットの適応化が行われる。これは、データ・パケットに対して配信デッドラインを維持することを可能にする。さらに、それは、パケット・スケジューラ及び他のシステム・リソースの効率的な使用をサポートすると共に、データ・パケットの拒否や削減を回避することができる。
【００２７】
本発明によれば、受入れ制御パラメータは、下層にあるネットワーク・プロトコルのヘッダから受信される。これは、受入れ制御パラメータを読み取らせないようになっていないことから、ペイロードの秘匿及び認証を可能とする上に、いわゆるインターネット・プロトコルのＩＰｖ４、ＩＰｖ６及びＩＰＳｅｃの使用をサポートする。
【００２８】
本発明によれば、リアルタイムのデータ・トラヒックを処理するネットワーク・ノードは、さらに、現在利用可能なスループットＶを判断する判断ユニットと、入来するデータ・トラヒック・フローのリアルタイム処理についての判断をする判断手段とを有する。それらの判断ユニット及び判断手段により、パケット・スケジューラでペイロード・データ・パケットについてデッドラインが計算される前に受入れ制御を実行することが可能となっている。有利なことに、利用可能なスループットよりも高いスループットを要求するデータ・パケットがリアルタイム処理に受け入れられないことから、スループット不足によるデータ・パケットについての配信デッドライン超過を回避することができる。また、配信デッドラインの無駄な計算も回避される。
【００２９】
本発明によれば、ネットワーク・ノードは、さらに、リアルタイム処理に対して受け入れられるデータ・パケットを第１の待ち行列ＥＤＦに転送し、かつ、リアルタイム処理に対して拒否されるデータ・パケットを第２の待ち行列ＦＩＦＯに転送する、転送ユニットを有する。これは、すべてのタイプのトラヒックを処理できることを保証する。リアルタイム処理に対して拒否されたデータ・パケットは、なおも最善努力型の品質で処理することができる。
【００３０】
また、出力インタフェースＯＩは、第１のＥＤＦ及び第２の待ち行列ＦＩＦＯにおけるデータ・パケットを優先するものから順に処理する。有利なことに、一方の待ち行列におけるデータ・パケットのブロッキングは、双方の待ち行列からのデータ・パケットのある程度の読出を保証する、優先順位付けの方策を選択することによって回避することができる。
【００３１】
本発明によれば、ネットワーク・ノードは、さらに、デッドライン超過処理機及び適応化ユニットを有する。これにより、データ・パケットのリアルタイム処理を保証するように配信デッドライン超過に対する対策を容易に起動することができる。好ましい対策としては、配信デッドラインの維持を可能にするペイロード・データ・パケットの適応化が挙げられる。それは、さらに、システム・リソースの効率的な使用をサポートし、かつ、データ・パケットの拒否や削減を回避することができる。
【００３２】
本発明によれば、ネットワーク・ノードは、さらに、無線基地局を含む。セルラー通信ネットワークや特に無線アクセス・ネットワークにおいては、利用可能な周波数が限られたリソースとなる。この結果、通信チャネルの帯域幅が制限される。有利なことに、本発明は、リアルタイムのマルチメディア・サービスを要求するクライアントに対して効率的に品質条件を規定することをサポートする。特に、無線基地局は、その通信の要求を満たすことが可能なクライアントだけを収容することができる。
【００３３】
本発明によれば、データ・パケット・ストリームに埋め込まれる受入れ制御パケットＡＣＰから読み取られる１つ又は２つ以上の受入れ制御パラメータＲｌに基づき、受入れ制御を容易に実行することができる、という点が有利になっている。データ・パケットのサブ−ストリームのリアルタイム処理を受け入れる判断は、当該受入れ制御パラメータによって与えられる最小のスループット要求特性に応じて行われる。有利なことに、利用可能なスループットよりも高いスループットを要求するデータ・パケットがリアルタイム処理に受け入れられないことから、ネットワーク・ノードないしアプリケーションにおけるスループット不足のための輻湊を回避することができる。また、受入れ制御は、最大スループット・パラメータＲｈを考慮することができる。したがって、受入れ制御装置は、最大スループットＲｈまでの範囲で利用可能なスループットから独立して、データ・パケットのサブ−ストリームについて最小の要求されたスループットＲｌよりもコスト的に効率の良いスループットを選択することができる。
【００３４】
ネットワーク事業者は、顧客に対して提供する異なるスループット・レートについて異なる料金を課金することができる。事業者の利益を増やすためには、サブ−ストリームについてのスループット・レートの当該選択は、事業者によって与えられる利得関数に基づくものとすることができる。当該利得関数は、例えば、通信システム、ネットワーク・ノードないし伝送チャネルについてのスループット−レート毎のコストを示すものである。
【００３５】
さらに、高い方のスループット限界値Ｒｈは、データ・パケットが速く伝送され過ぎないことを保証するので、通信システム内ないしデータ・パケット・ストリームの受信側でのバッファのオーバーフローを回避することができる。
【００３６】
さらに、ペイロード・データ・パケットについてデッドラインが計算される前に受入れ制御を実行することが有利である。受入れ制御パラメータにより与えられるデータ・パケットのサブ−ストリームのリアルタイム処理に対するスループット要求特性が利用可能なスループット能力を考慮しつつそれらのデッドラインを維持できないことを示している場合には、デッドラインを計算する必要は全くない。有利なことに、利用可能なスループットとは別のスループットを要求しているデータ・パケットがリアルタイム処理に受け入れられないことから、スループット不足によるデータ・パケットについての配信デッドライン超過を回避することができる。
【００３７】
本発明によれば、修正した受入れ制御パケットを通じてスループット能力のフィードバックがデータ・パケット・サブ−ストリームの伝送路に沿って送り返される。これにより、有利なことに、中間の通信システム・ノードやトラヒック・ソースは、トラヒックを利用可能なスループット能力に適応させることが可能になる。このようにして、リアルタイム処理に対するデータ・パケットの拒否を高度に回避することができる。また、修正された受入れ制御パケットの利用は、信号授受のオーバーヘッドや複雑なプロトコル構造を回避することもできる。
【００３８】
本発明によれば、リアルタイム処理に対して拒否されたデータ・パケットは、それらが現れた順序で第２の待ち行列ＦＩＦＯ中にソートされる。これにより、それらのデータ・パケットについてファースト・イン−ファースト・アウトの方策に基づく最善努力型の処理を容易に行うことが可能になる。
【００３９】
本発明によれば、データ・パケットは、第１の待ち行列ＥＤＦ及び第２の待ち行列ＦＩＦＯからの読出のために優先するものから順に処理される。有利なことに、一方の待ち行列におけるデータ・パケットのブロッキングは、双方の待ち行列からのデータ・パケットのある程度の読出を保証する、優先順位付けの方策を選択することによって回避することができる。
【００４０】
本発明によれば、デッドライン超過を検出することができる。これにより、有利なことに、データ・パケットのリアルタイム処理を保証するための対策を起動することが可能になる。
【００４１】
本発明によれば、ペイロード・データ・パケットの適応化が実行される。これにより、特に輻湊ないしトラヒック負荷がピークのケースにおいて、データ・パケットについての配信デッドラインを維持することが可能になる。さらに、それは、システム・リソースの効率的な使用をサポートし、かつ、データ・パケットの拒否や削減を回避することができる。
【００４２】
本発明によれば受入れ制御パラメータが、請求項３０によれば同期制御パラメータが、下層にあるネットワーク・プロトコルのヘッダから受信される。これは、受入れ制御パラメータを読み取らせないようにはなっていないことから、ペイロードの秘匿及び認証を可能とする上に、いわゆるインターネット・プロトコルのＩＰｖ４、ＩＰｖ６及びＩＰＳｅｃの使用をサポートする。
【００４３】
本発明の方法、装置及びコンピュータ・プログラムは、図面を併せて参照した以下の詳細な説明により、さらによく理解され、さらにその価値が認められることであろう。以下の図面は次のものを示している。
【００４４】
（図面の簡単な説明）
図１ａは、それぞれ異なる同期エンティティを伴う画像ストリームを示し、
図１ｂは、それぞれ異なる同期エンティティを伴う他の画像ストリームを示し、
図１ｃは、受入れ制御パケットＡＣＰ（admission control packet）及び同期制御パケットＳＣＰｓ（synchronisation control packets）を伴うデータ・パケット・ストリームを示し、
図２ａは、ＳＣＰ中に含まれるパラメータを示し、
図２ｂは、ＡＣＰ中に含まれるパラメータを示し、
図３は、受入れ制御装置（admission controller）のタスクを流れ図に示し、
図４は、パケット・スケジューラの機能図（functional view）を示し、
図５は、パケット・スケジューラのタスクを流れ図に示している。
【発明を実施するための最良の形態】
【００４５】
図１ａは、ペイロード・データ・パケット・トラヒックのストリームを時間軸ｔに沿って示している。そのストリームは、通信システムにおけるトラヒック・ソース（traffic source（トラヒック源））ないし中間ネットワーク・ノードによって送ることができるものであり、また、それは、パケット・スケジューラないし受入れ制御装置のようなネットワーク・ノードで受信することができるものであり、また、それは、マルチメディア・ビューア（multimedia viewer）のようなソフトウェア・アプリケーションから受信することができるものである。そのペイロード・データ・パケットのストリームは、いくつかのペイロード・データ・パケット１、２及び３から構成されており、それらのペイロード・データ・パケット１、２及び３が終始に亘って送信ないし受信される。
【００４６】
ペイロードの特性（characteristic）に応じて、一揃いになっているデータ・パケットがあり、それらのデータ・パケットがいわゆる同期エンティティＳＥ（synchronisation entity）を形成している。一つの同期エンティティＳＥに属している各データ・パケットは、リアルタイムの要求特性のために固定された時間間隔の範囲内でそれらのデータ・パケットの宛先にそれらのデータ・パケットのすべてが共に到達しなければならないという特性を共通して持っている。さらに、それぞれの同期エンティティＳＥは、他の続く同期エンティティＳＥのすべてのパケットから独立して受信側のアプリケーションにより処理されるという属性（property）を有するべきものとなっている。
【００４７】
画像通信を考える場合では、同期エンティティＳＥは、受信側でのリアルタイム特性及び再生バッファ（playback buffer）に応じて、１つ又は２つ以上の画像フレームにより構成することができる。インターネット・プロトコルのストリーム上での音声に関しては、同期エンティティＳＥを単一のパケットにすることさえも可能である。いわゆるワールド−ワイド−ウェブＷＷＷ（World-Wide-Web）のセッションにおいては、同期エンティティＳＥは、画像やハイパーテキスト・マークアップ言語ＨＴＭＬ（Hypertext Markup Language）文書構造のようなすべてのオブジェクトを含んだウェブ・ページ全体を表すデータ・パケットによって構成することができる。
【００４８】
図１ａにおいて、すべてのペイロード・データ・パケット１は第１の同期エンティティＳＥ１に属し、すべてのペイロード・データ・パケット２は第２の同期エンティティＳＥ２に属し、すべてのペイロード・データ・パケット３は第３の同期エンティティＳＥ３に属している。この構成（configuration）は、通信ネットワークにおいてデータ・パケット・ストリームを受信するパケット・スケジューラに対して、エンド・ツー・エンドの終始に亘る遅延に関して制限のある遅延の要求特性を課す。
【００４９】
図１ｂは、別形態のトラヒック・シナリオ（traffic scenario）において、１つの同期エンティティ内に２つの画像フレームを有する画像ストリーム（ビデオ・ストリーム）を示している。第１の画像フレームはペイロード・データ・パケット１を含み、第２のフレームはペイロード・データ・パケット２を含んでいる。このシナリオは、再生前に２つの同期エンティティをバッファリングすることを受信側に強制する。ここで、同期エンティティＳＥ１は同期エンティティＳＥ２にオーバーラップしている。
【００５０】
図１ｃは、オーバーラップした同期エンティティがないデータ・パケット・ストリームを示している。そのストリーム中には、トラヒック・ソースないし中間のゲートウェイによって一定の制御データ・パケットＳＣＰ、ＡＣＰが埋め込まれている。同期制御パケットＳＣＰ（synchronisation control packet）は、同期エンティティＳＥに先行し、一つの同期エンティティを他の同期エンティティから区別する。それは、続く同期エンティティＳＥに関係する同期制御パラメータを含んでいる。
【００５１】
本発明の好ましい実施形態においては、さらに加えてトラヒック・ソースがパケット・ストリーム中に受入れ制御パケットＡＣＰ（admission control packets）を挿入する。受入れ制御パケットＡＣＰは、リアルタイム処理のためのデータ・パケットのサブ−ストリーム（sub-stream）のスループット要求特性（throughput requirements）に関して、そのデータ・パケットのサブ−ストリームを特徴付けるパラメータを含む。サブ−ストリームとは、受入れ制御パケットＡＣＰに続いている、別の受入れ制御パケットに至るまでの、データ・パケットの組と解釈されるものとする。あるいは他の形態として、受入れ制御パケットに割り当てられたデータ・パケットの個数を制御パラメータ（サブ−ストリームをその長さによって定義する制御パラメータ）としてその受入れ制御パケットに含めることもできる。
【００５２】
一つのパケット・データ・ストリームにおいてリアルタイムのデータ・トラヒックと最善努力型トラヒック（best-effort traffic）のような他のデータ・トラヒックとを混在させる場合には、同期制御パケットＳＣＰ内ないし受入れ制御パケットＡＣＰ内の制御パラメータとして含まれて同期エンティティないしサブ−ストリームの長さを定義する数により、各ペイロード・データ・パケットが一定の同期エンティティＳＥないし一定のサブ−ストリームに属するものとする識別（identification）を好適に利用することができる。
【００５３】
受入れ制御パケットＡＣＰは、データ伝送が持続しているときに繰り返して送ることにしてもよい。トラヒック・ソースは、このようにして自身のリソース使用における信号の変化に対して受入れ制御パケットＡＣＰを利用することにしてもよい。
【００５４】
本発明のさらなる実施形態においては、受入れ制御装置が修正した受入れ制御パケットＡＣＰをパケット・ソース（パケット源）に向けて送り返す。このメカニズムは、中間ノードないしパケット・ソースがリアルタイム処理のためにデータ・パケットの非受入れ（negative admissions）に対して作用し合うことを可能にする。
【００５５】
また、受入れ制御パケットＡＣＰは、リソース予約をリフレッシュするために、任意の時間間隔で繰り返すこともできる。それらを繰返し送るのが可能であることは、移動通信ネットワークの固定網（fixed network）部分のような、マルチメディア・ストリームのルーチング・パスが変化し得るネットワークにおいて、特に有用である。その場合、ネットワークのボトルネックにおける制御ノードが実際のリソース要求特性を判断することができるように、実際の受入れ制御パケットＡＣＰのコピーを専用の制御ノードから転送することができ、あるいは、同コピーを規則的な時間間隔でパケット・ストリーム中に繰り返すこともできる。
【００５６】
本発明のさらなる実施形態においては、下層にあるネットワーク・プロトコルのヘッダ中にトラヒック・ソースないし中間ゲートウェイから同期制御パラメータ及び受入れ制御パラメータが挿入される。これは、ペイロード秘匿（payload encryption）と認証メカニズム（authentication mechanisms）が用いられている場合に特に有用である。ＩＰｖ４やＩＰｖ６のようなインターネット・プロトコルは、受入れ制御及び同期制御のパラメータを伝えることができるオプションの（任意選択的な）ヘッダ拡張部（optional header extension）の挿入を許容している。いわゆるＩＰＳｅｃプロトコルを用いている場合では、インターネット・プロトコルのヘッダは、付加された認証ヘッダによって認証される。したがって、受入れ制御及び同期制御のパラメータを読み取ることは妨げられない。
【００５７】
本発明のさらなる実施形態においては、ソースとパケット・スケジューラの間の中間局（intermediate station）が伝送されるデータ・パケット・ストリームのキー（key）を認識している情報として有している。それは、例えばネットワーク提供者によって維持されている移動性ゲートウェイ（mobility gateway）のような、エンド−ユーザにとって信頼性のある装置を形成する。このケースにおいては、通信の当事者機器（parties）間でいわゆるＩＰトンネリング（IP tunnelling）が行われるときに、無線リンクを通じた伝送のための特別なヘッダ及びペイロード秘匿が用いられる。
【００５８】
本発明は、同期制御パケットＳＣＰに含まれる同期情報の援助により、例えばパケット・スケジューラにおいて、同期エンティティＳＥのそれぞれのペイロード・データ・パケットに対する個々の配信デッドラインを判断（決定）することを可能にする。図２ａは、同期制御パケットＳＣＰの内容についての好ましい実施形態を示している。それは、パラメータとして、それの示す同期エンティティＳＥに属するパケットの個数Ｎ、その同期エンティティＳＥのすべてのペイロード・データ・パケットの全体サイズＳ、及び同期エンティティＳＥの全体がパケット・スケジューラを通過しなければならない最大伝送時間Ｉを含んでいる。
【００５９】
他の形態として、最大伝送時間Ｉは、その間に同期エンティティＳＥがその最終的な宛先に到達しなければならない時間として定義することもできる。このケースにおいては、パケット・スケジューラは、同期エンティティＳＥの処理をするためにその伝送時間の一部までだけを使うことが許容されることになる。
【００６０】
また、同期制御パケットＳＣＰは、属する受入れ制御パケットＡＣＰを示す識別子ＩＤを含むものとしてもよい。この識別子は、同期エンティティが一定のサブ−ストリームに属しているかどうかを検証（verify）するのに利用することができる。
【００６１】
加えて、同期制御パケットは、他のパラメータを含むものとしてもよい。この他のパラメータとしては、その同期制御パケットの制御パラメータに属するとのペイロード・データ・パケットの識別をサポートするものが挙げられる。これは、トラヒック・ソース若しくは中間ネットワーク・ノードからパケット・スケジューラ若しくは他のネットワーク・ノードないし一般的には同期制御パラメータを利用する装置若しくはアプリケーションへのデータ・パケットの伝送の間にそれらのデータ・パケットの伝送順序が変更される場合において、必要となり得るものである。
【００６２】
データ・パケットの伝送順序が変わっていないものとすると、パケットは、同期制御パケットＳＣＰの直後に続く最初のパケットで始まり、それらがその同期制御パケットＳＣＰに追従し続け、かつ、Ｎよりも大きいインデックス（index）を有していない場合の、特定の同期エンティティＳＥに属している。それぞれの異なるパケット・フローに属している各同期エンティティＳＥを区別するためには、下層にあるネットワーク・プロトコルによって各データ・パケットがフロー・ラベル（flow label）も付されるものとすることができる。同期制御パケットＳＣＰは、そのデータ・パケットの他に同じフロー・ラベルを搬送する。
【００６３】
通常では、同期制御パケットＳＣＰは、同期エンティティＳＥに属するペイロード・データ・パケットの配信デッドラインを判断（決定）するために必要なパラメータを含んでいる。トラヒック・タイプ及び対応するアプリケーションに応じて、本発明の一定の実施形態においては、デッドラインについての絶対時間値又は相対時間値（an absolute or relative time value）のようなただ一つのパラメータを同期制御パケットＳＣＰが含むことにしてもよい。別のシナリオにおいては、同期制御パケットは、とりわけデータ・パケットの順序を再配列（re-arrangement）するために用いる追加の制御パラメータを含むものとしてもよい。したがって、図２ａに示したような同期制御パケットＳＣＰの内容は、採用可能な実施形態の一例に過ぎないと解釈すべきものである。
【００６４】
図２ｂは、受入れ制御パケットＡＣＰに含まれる受入れ制御パラメータの好ましい実施形態を示している。受入れ制御パケットＡＣＰは、概して、パケット・スケジューラによりデータ・パケットのサブ−ストリームを処理するためのリアルタイム制約（real-time constraints）によるスループット要求特性を特徴付ける（示し表す）スループット・パラメータを含んでいる。本発明の観念におけるスループット要求特性は、固定的な要求特性とすることも平均的な要求特性とすることもでき、それは、固定的なスループット・レートのパラメータによって与えることも平均的なスループットのパラメータによって与えることもできる。
【００６５】
パラメータＲｌは、サブ−ストリームのリアルタイム処理に必要である最低の要求されるスループットを与える。この最小の要求特性を満たすことができない場合には、リアルタイム処理に対してサブ−ストリームを拒否する（受け入れない）か、あるいは、最善努力型の方策（best effort strategy）の下でサブ−ストリームを処理するかの、いずれかにしなければならない。例えば、移動端末機は、このパラメータを通じて、アクセス・ネットワークの無線基地局（radio base station）により与えられるべき一定のデータ・スループット条件を要求することができる。その場合、無線基地局は、移動局（mobile station）がクライアントと認められるかどうかを判断する。
【００６６】
さらに加えて、オプションの（任意選択的な）パラメータＲｈにより、最高の希望されるスループットを要求することができる。これにより、受入れ制御装置又は一般的にはネットワーク・ノード若しくはアプリケーションは、最小の要求されたスループットＲｌと最大の希望されたスループットＲｈの、与えられたスループット間の範囲内で、スループット・レートを選択することが可能になる。当該選択は、例えばスループット毎のコストないし利益（profit）を示す線形利得関数等の、ネットワーク事業者によって与えられる利得関数（gain-function）に基づくものとしてもよく、あるいはそれは他のコスト推定（cost-estimations）に基づくものとしてもよい。また、利得関数に従った一定スループットの当該選択は、データ・パケットの１つ又は２つ以上のサブ−ストリームに影響するものとしてもよく、あるいは一般的には、それぞれ一定のスループットにより、パケット・スケジューラでのリアルタイム処理のために受入れ制御装置によって既に受け入れられている通信接続に、影響するものとしてもよい。それらのスループットを減少させ、サブ−ストリーム用に利用可能なスループットを増加させるようにしてもよく、あるいは一般的には、その時点で受入れ制御装置による受入れ処理の下にある通信接続用に利用可能なスループットを増加させるようにしてもよい。したがって、高い方のスループット値Ｒｈに至るまでに最も金銭的に有益なスループット要求特性を実現することにより、ネットワーク事業者にとっての利益を増大させることもできる。
【００６７】
さらに、データ・パケットの宛先アプリケーション（destination-application）におけるバッファの限界ないし処理速度の制限により、データ・スループットの限界値Ｒｈが必要となることもある。最大のデータ・スループット条件を超えると、受信側のサイトでは、とりわけバッファのオーバーフロー・エラー（overflow errors）やペイロード・データ・パケットの受入れ拒否（rejection）が発生し得ることになる。
【００６８】
さらにオプションのパラメータとして、ペイロード・データ・パケットの配信デッドライン超過のケースにおいて利用するための最大スケジューリング許容限度（maximum scheduling tolerance）Ｄがある。このパラメータＤは、単一のペイロード・データ・パケット、同期エンティティ又はサブ−ストリーム全体が遅延され得る、許容限度を与える。
【００６９】
さらに、オプションのタイプ・パラメータＴは、例えばＭＰＥＧ、ボイス・オーバーＩＰ（Voice over IP）若しくはこれら以外の、データ・トラヒックのタイプを特徴付ける（示し表す）。そのトラヒックのタイプに基づき、パケット・スケジューラは、デッドライン超過のケースにおいてペイロード・データ・パケットに対する適切な適応化方法を選択することができる。
【００７０】
また、受入れ制御パケットＡＣＰは、受入れ制御パケットＡＣＰにより制御されるサブ−ストリームに属する同期制御パケットを識別するのに利用する識別子ＩＤを含むものとしてもよい。
【００７１】
加えて、受入れ制御パケットは、他のパラメータを含むものとしてもよい。この他のパラメータとしては、その受入れ制御パケットに属するとのデータ・パケットの識別をサポートするものが挙げられる。これは、トラヒック・ソース若しくは中間ネットワーク・ノードからパケット・スケジューラ若しくはネットワーク・ノードないし一般的には受入れ制御パラメータを利用する装置若しくはアプリケーションへのデータ・パケットの伝送の間にそれらのデータ・パケットの伝送順序が変更される場合において、必要となり得るものである。
【００７２】
図３は、本発明の好ましい実施形態において受入れ制御を記述したものである。受入れ制御パケットＡＣＰは、受入れ制御装置で受信され（１０）、あるいは一般的には、ネットワーク・ノード若しくはアプリケーションで受信される。その受入れ制御パケットＡＣＰは、リアルタイムのデータ・トラヒックを運ぶ次に来るサブ−ストリームと関係している。受入れ制御装置は、その受入れ制御パケットＡＣＰから受入れ制御パラメータＲｌ、Ｒｈ、Ｔを読み取る（２０）。一つの実施形態としては、制御装置が最小スループット・パラメータＲｌだけを読み取る。図３に示した別の実施形態では、制御装置が３つのパラメータＲｌ、Ｒｈ、Ｔを読み取る。
【００７３】
次に、受入れ制御装置は、制御装置において現行スループット（currently used throughput（現時点で用いられているスループット））Ｖｃを判断する（３０）。これは、とりわけ受入れ制御装置が現在時間毎に送信しているビットの数をカウントすることによって行うことができる。特に、リアルタイムのデータ・トラヒック以外のトラヒック・タイプの配信が何等の時間的な制約も超過せずに容易く遅延させることができるので、現行スループットの測定は、リアルタイムのデータ・トラヒックだけを考慮するものとしてもよい。後者のケースにおいては、現在処理されているトラヒックのタイプをパケット・スケジューラが認識しているので、現行スループットのパラメータＶｃをパケット・スケジューラが与えることにしてもよい。
【００７４】
次のステップ４０において、受入れ制御装置は、制御装置での利用可能な最大のスループットＶｍａｘと現行スループットＶｃとの差を計算することにより、利用可能なスループットＶを判断する。受入れ制御装置は、チャネル測定（channel measurements）、メッセージング（messaging）又は要求（a request）により、ルックアップ−テーブル（lookup-table）から、固定値として最大スループット能力（maximum throughput capability）Ｖｍａｘを認識する。
【００７５】
次に、制御装置は、要求されたスループットＲｌと利用可能なスループットＶを比較する（５０）。利用可能なスループットＶが要求されたスループットＲｌより高いか又はこれに等しい場合には、制御装置は、その受入れ制御パケットＡＣＰに属するデータ・パケットのサブ−ストリームのリアルタイム処理を受け入れることができる。図３に示した実施形態では、受入れ制御装置は、さらに、利用可能なスループットＶ及び最大の希望されたスループットＲｈの、最小Ｍを計算する（６０）。次のステップ７０において、受入れ制御装置は、最小の要求されたスループットＲｌと最小Ｍとによって与えられる範囲からサブ−ストリームに対して最も金銭的に有益なスループット・レートを選択する。これは、例えば線形スループット−利益関数（linear throughput-profit function）等の、ネットワーク事業者により与えられる利得関数に従った選択によって、行うことができる。
【００７６】
他の実施形態としては、最小の要求されたスループットＲｌ及び最大のスループットＲｈによって与えられる範囲のうちから金銭的に有益なスループット・レートを制御装置が暫定的に選択するものとすることができる。その選択されたスループット値が利用可能でない場合には、パケット・スケジューラでリアルタイム処理に対して既に受け入れられているサブ−ストリームの適応化を制御装置が起動して当該選択されたスループット値を利用可能とするようにすることができる。リアルタイム処理に対して受け入れられているサブ−ストリームの各データ・パケットは、パケット・スケジューラに送られる（８０）。それらがリアルタイム処理に受け入れられるかどうかの情報は、信号授受（signalling）を通じて、あるいは、リアルタイムのトラヒック用に予約されたパケット・スケジューラにおける専用の伝送チャネルないし専用のポートを利用することにより、受入れ制御装置からスケジューラへと与えることができる。スループット・レートが選択されている場合、それを伝える通信は、同様にしてパケット・スケジューラないし出力インタフェースＯＩ（output interface）に対して行い、サブ−ストリームのさらなる処理のために考慮されるようにすることができる。
【００７７】
リアルタイム処理に対して受け入れられないサブ−ストリームのデータ・パケットは拒否される。この受入れ拒否を実行する一つの方法としては、トラヒック・ソース、中間ゲートウェイないし受信側（受信機）等の他の当事者機器に対してさらなる警告（notice）を行い、あるいは、これを行わずに、受入れ制御装置によってデータ・パケットの削減（dropping）をすることが挙げられる。警告通知（notification）の一つの方法としては、否受信応答（negative acknowledgement）を含む修正された受入れ制御パケットＡＣＰを受入れ制御装置から送ることができるが、他の信号授受メカニズムを利用することも可能である。あるいは他の形態としては、受入れ拒否の対象となるデータ・パケットをバッファリングすると共に、（例えば受入れ制御パケットの交換を通じて）スループット要求特性についての送信側（トラヒック・ソースないし中間ゲートウェイ）とのネゴシエーション（negotiation）を開始するものとすることができる。本発明の他の実施形態では、サブ−ストリームのデータ・パケットは、リアルタイム処理ではなく通常の処理（regular processing）のためにパケット・スケジューラへ送られる。通常の処理は、その後、例えば最善努力型のアプローチやＦＩＦＯ方策（FIFO-strategy）（ファースト・イン−ファースト・アウト）に従って行われる。パケット・スケジューラへ送られるデータ・パケットがリアルタイム処理に対して受け入れられるかどうかの情報は、上述したように、信号授受を通じて、あるいは、その伝送のための専用の伝送チャネルないし専用のポートを利用することにより、スケジューラに対して与えられる。
【００７８】
図３に示した本発明の実施形態においては、パケット・スケジューラにおいて現在リアルタイム処理のためにスケジューリングされており、かつ、現在利用可能なスループットＶｃを占有している、データ・パケットの適応化の実現可能性（feasibility）がチェックされ（９０）、実現可能であれば、パケット・スケジューラにおいて利用可能なスループットＶを増加させることが実行される（１１０）。その適応化が実現可能でなければ、サブ−ストリームは最終的に拒否される（１００）。
【００７９】
例えば最早期−デッドライン−ファースト待ち行列ＥＤＦ（earliest-deadline-first queue EDF）において、リアルタイム処理のために現在スケジューリングされているペイロード・データ・パケットの適応化は、例えば、異なる圧縮方式（compression scheme）若しくはより効率的な圧縮方式を用いることによって行うこともでき、一定のパケットを削減することによって行うこともでき、あるいは、他のトラヒック・タイプに応じて定まるメカニズムによって行うこともできる。適切な適応化の方法は、データ・トラヒック・タイプＴを考慮して選択し、例えば、ＭＰＥＧ画像ストリームの解像度の低減、いくつかのボイス・オーバーＩＰパケットの削減、２５６色画質（256-colour pictures）の１６色画質への変換等のようにする。通常、これらのよく知られた適応化の方法は、‘作動中に’（‘on the fly’）実行することができ、その結果として利用可能なスループットＶをより高くする。
【００８０】
前記適応化の後に、現行のスループットＶｃが判断され（１２０）、そして利用可能なスループットＶが計算される（１３０）。その後、上述した規準（criteria）に基づく最終的な判断（５０）と上述したスループット値の選択（６０、７０）を伴う処理が、リアルタイム処理のためのサブ−ストリームの、受入れについて行われ（８０）、あるいは、受入れ拒否について行われる（１００）。
【００８１】
図４は、リアルタイム処理に対するデータ・パケットのサブ−ストリームの受入れないし拒否をする受入れ制御装置ＡＣと、リアルタイム処理に対して受け入れられたデータ・パケットのための第１の待ち行列ＥＤＦと、ファースト・イン−ファースト・アウトのような最善努力型の方策に従って処理されるデータ・パケットのための第２の待ち行列ＦＩＦＯとを有する、パケット・スケジューラを示している。第２の待ち行列ＦＩＦＯは、リアルタイム処理に対して拒絶されるデータ・パケットのために使用される。パケット・スケジューラのさらなる実施形態としては、例えばスケジューラの容量を増大させるために、一つ以上のタイム−スタンプ・ベース（time-stamp based）のＥＤＦ待ち行列及び一つ以上のＦＩＦＯ待ち行列を有するものとしてもよい。
【００８２】
第１の待ち行列ＥＤＦにデータ・パケットのサブ−ストリームを送ることにより、受入れ制御装置は、リアルタイム処理にデータ・パケットを受け入れる。この第１の待ち行列ＥＤＦは、タイム−スタンプ・ベースであり、かつ、最早期−デッドライン−ファーストの方策に従って動作する。ＥＤＦ待ち行列中に格納（記憶ないし蓄積）された各データ・パケットは、タイム・スタンプを取得し、そのタイム・スタンプの値は、当該各データ・パケットの配信デッドラインに設定される。ここでタイム・スタンプの値として設定される配信デッドラインは、同期制御パケットによって与えられる同期制御パラメータから計算することができる。読出については、ＥＤＦ待ち行列は、常に、最も近い配信デッドラインを有するデータ・パケットを供給する。したがって、ＥＤＦ待ち行列は、最も近い配信デッドラインを有するデータ・パケットの直接アクセス処理（direct-access processing）のために、すべての配信デッドライン及び対応するデータ・パケットの経過を監視できるものとなっており、あるいは他の形態として、それは、新たなデータパケットがＥＤＦ待ち行列中に伝送される度にペイロード・データ・パケットをそれらの配信デッドラインに基づいて再ソート（re-sort）し、ＥＤＦ待ち行列の出力において常に最も近い配信デッドラインを有するデータ・パケットをシーケンシャル処理（sequential processing（順序処理））の形態で供給できるものとなっている。
【００８３】
パケット・スケジューラは、出力インタフェースＯＩを有し、この出力インタフェースＯＩがさらなる処理のために各待ち行列に含まれているデータ・パケットに優先順位を付ける（prioritise（優先するものから順に処理する））。これは、待ち行列の選択、その待ち行列からのデータ・パケットの読出、及びさらなる処理に対するそのデータ・パケットの供給を含む。待ち行列の選択については、種々の方策を採ることが可能であり、ＥＤＦ待ち行列が空（empty）になるまでないしは一定の閾値に到達するまで常にＥＤＦ待ち行列の方を選択するようにしたり、あるいは、待ち行列毎に固定的な読出の速度に基づく方策や例えばトラヒック・タイプＴを考慮して動的に読出速度を決定する方策を採用したりすることも可能である。さらなる処理に対するデータ・パケットの供給は、ポーリング（polling）のメカニズムや他のメカニズムにより、通信チャネルを通じてデータ・パケットを伝送することによって行うことができる。
【００８４】
図５は、受入れ制御装置から送られるデータ・パケットの入来（incoming）サブ−ストリームに対するパケット・スケジューラのタスクを示している。サブ−ストリームがリアルタイム処理に受け入れられると（２１０）、それぞれのペイロード・データ・パケットについて個々の配信デッドラインが計算される（２３０）。リアルタイム処理に対する受入れは、パケット・スケジューラにより、受入れ制御装置から受信される信号授受メッセージを通じて、あるいは、リアルタイム・トラヒック用に予約された専用の通信チャネル上ないし専用のポートでのデータ・パケットの到達を通じて、認定（recognise）することができる。図５に示した実施形態においては、パケット・スケジューラで受信され、かつ、リアルタイム処理に受け入れられるすべてのデータ・パケットは、ＥＤＦ待ち行列に転送され（２２０）、他のすべてのデータ・パケットは、それらが現れた順に、第２の待ち行列ＦＩＦＯに転送され（２５０）、かつ、第２の待ち行列ＦＩＦＯ内にソート（整列ないし並べ替え）される（２６０）。この第２の待ち行列ＦＩＦＯは、最善努力型の方策に従って処理される。
【００８５】
パケット・スケジューラは、ＥＤＦ待ち行列で受信された同期制御パケットＳＣＰから同期制御パラメータを読み取り、ＥＤＦ待ち行列に送られたそれぞれのペイロード・データ・パケットについて個々の配信デッドラインを計算によって判断（決定）する。好ましい実施形態では、このデッドラインは、パケット・スケジューラにより許容された最新の配信時間を表す。他の実施形態としては、そのデッドラインは、データ・パケットの宛先における最新の到達時間を表すものとすることができる。デッドラインについては、絶対時間ないしタイマ−ベース（timer-based）の時間の値を用いることができる。次のステップ２４０においては、ペイロード・データ・パケットがＥＤＦ待ち行列中に格納されると共に、ＥＤＦ待ち行列のタイム・スタンプが配信デッドラインに設定される。各待ち行列中にソートされたペイロード・データ・パケットは、上での説明に従い、例えば出力インタフェースＯＩにより、さらなる処理に対する準備ができているものとなる。
【００８６】
本発明の好ましい実施形態においては、個々のペイロード・データ・パケットについての配信デッドラインは、同期制御パラメータＳ、Ｎ及びＩから計算する。さらに、パケットの番号ｉ及び現時点でのパケットの到達時間ｔを計算のために利用する。また、パケット・スケジューラがさらなる伝送のためにパケット転送をスケジューリングする、チャネルｊのパケット誤り率Ｐｊ及びビット・レートＲｊを計算において利用する。後者の各値は、リアルタイムの待ち行列がどの程度速く空になるかを示す。
【００８７】
番号ｉは、同期エンティティＳＥにおけるパケットのシーケンス番号であり、ｉ∈｛１…Ｎ｝に従う。それは、例えばパケット・スケジューラにおいて、一定の同期エンティティＳＥに属している入来ペイロード・データ・パケットをカウントすることによって判断される。
【００８８】
時間の値ｔは、受入れ制御装置における個々のペイロード・データ・パケットの到達時間を表す。それは、受入れ制御装置によって判断することができ、パケット・スケジューラに対して信号で伝えることができる。他の形態としては、パケット・スケジューラにおける到達時間が著しく異なるものでなければ、代わりにそのパケット・スケジューラにおける到達時間を用いることもできる。後者のケースにおいては、パケット・スケジューラがパケットの到達時間を判断する。
【００８９】
通常では、パケット誤り率Ｐｊは、リンク・レイヤ測定（link layer measurements）から取得される。例えば、いわゆるＷＣＤＭＡシステムにおいては、チャネルのパケット誤り率Ｐｊをいわゆる閉ループ電力制御による信号対雑音割当量（signal to noise ration）から判断することができる。
【００９０】
本発明の他の実施形態としては、タイムスロット毎の誤り率、クライアント毎の誤り率又はネットワーク毎の誤り率を配信デッドラインの判断（決定）に利用することもできる。好ましい実施形態では、選択的な繰返し（selective repeat）をリンク・レイヤの誤り訂正として利用する。
【００９１】
ビット・レートＲｊは、例えば入来するビットをカウントすることにより、受入れ制御装置やパケット・スケジューラにおいて判断することができる。
【００９２】
本発明の好ましい実施形態においては、それぞれのペイロード・データ・パケットについてのデッドラインを次のように計算する。
【数３】
2007312413.tif 000009
【００９３】
さらに好ましい実施形態においては、ＥＤＦ待ち行列中にソートされたペイロード・データ・パケットについての配信デッドラインの超過をパケット・スケジューラが検出する。この超過の検出は、それらの配信デッドラインを、システム時間（system time）を用いて判断される、例えばデータ・パケットがＥＤＦ待ち行列中で費やした時間等の、実際の時間の値と比較することによって行う。超過が検出された場合には、先に説明した方法に従ってペイロード・データ・パケットの適応化を実行する。
【００９４】
異なるリアルタイム・アプリケーションが許容する遅延の許容限度はそれぞれ異なる。この状況において適応化を実行する一つのやり方としては、データ・パケットの特定のサブ−ストリームについて遅延の許容限度を定義する、受入れ制御パラメータＤを利用することが挙げられる。一定レベルのデッドライン超過が検出された場合には、適応フレームワーク（adaptive framework）が１つ又は２つ以上のサブ−ストリームを降格（degrade）させて安定状態に入るようにすることができる。
【００９５】
本発明は、概してパケット・スケジューラ及び受入れ制御装置を含む、通信システムのネットワーク・ノードにおいて具現することができる。特に、当該ネットワーク・ノードにおいて、そのネットワーク・ノードからのデータ・パケットのさらなる伝送のために使用される通信チャネルｊのパケット誤り率Ｐｊを判断するパケット誤り率判断ユニットと、当該チャネルのビット・レートＲｊを判断するビット・レート判断ユニットと、そのネットワーク・ノードにおいてデータ・パケットの現時点での到達時間ｔを判断するタイマと、データ・パケット・トラヒック・フローに埋め込まれた制御データ・パケットＳＣＰ、ＡＣＰにより与えられる制御パラメータＩ、Ｓ、Ｎ、Ｒｈ、Ｒｌ、Ｄ、Ｔを評価する評価手段（evaluation means）と、配信デッドラインを計算する計算機ユニットと、それぞれのデッドラインに基づいてスケジューリングされるデータ・パケットを受信する第１の待ち行列ＥＤＦとにより、本発明を具現することができる。
【００９６】
さらなる実施形態として、第１の待ち行列ＥＤＦは、第１の待ち行列ＥＤＦ中にデータ・パケットをソートすると共に、計算された配信デッドラインをタイム−スタンプとしてそれらのデータ・パケットに割り当てる、ソーティング・ユニットを含むものとすることができる。そのソーティング・ユニットは、最早期−デッドライン−ファーストの方策に従って処理をする。
【００９７】
さらに、ネットワーク・ノードは、例えば先に説明した方法に従って、現在利用可能なスループットＶを判断する判断ユニットを有するものとしてもよい。判断手段（decision means）は、受入れ制御パラメータにより与えられるスループット要求特性と利用可能なスループットＶをチェックした後に、リアルタイム処理に対して入来するトラヒック・フローないしデータ・パケットのサブ−ストリームを受け入れる。また、その判断手段は、例えば、トラヒック・フローないしサブ−ストリームに対して最も金銭的に有益なスループット・レートを選択するためのルック−アップ・テーブルによる利得関数を有するものとしてもよい。その判断手段は、上述した方法に従い、データ・パケットのリアルタイム処理を受入れ、あるいは、拒否することができる。
【００９８】
第２の待ち行列ＦＩＦＯは、リアルタイム処理について拒否されたデータ・パケットを受信することができる。データ・パケット、サブ−ストリームないしトラヒック・フローを適切な待ち行列に分配（配信）するためのインタフェース、すなわち、拒否されたサブ−ストリームを第２の待ち行列ＦＩＦＯに分配すると共に受け入れられたサブ−ストリームを第１の待ち行列ＥＤＦに分配するためのインタフェースを、転送ユニットが形成する。
【００９９】
出力インタフェースは、記述の方法に従ってすべての待ち行列を優先するものから順に処理する。
【０１００】
ネットワーク・ノードは、さらに、少なくとも一つのペイロード・データ・パケットの適応化のための適応化ユニットを有するものとすることができる。その適応化は、第１の待ち行列ＥＤＦに含まれるデータ・パケットに対して実行することができ、また、ネットワーク・ノードに到達したデータ・パケットに対して実行することもできる。さらに、ネットワーク・ノードは、第１の待ち行列ＥＤＦ中にソートされたペイロード・データ・パケットの配信デッドラインを監視すると共に、安定したシステム状態を取り戻すために配信デッドライン超過のケースにおいてペイロード・データ・パケットの適応化を開始する、デッドライン超過処理機（deadline violation handler）を有するものとすることができる。その適応化は、例えば事業者の利益を最適化するための利得関数に基づき、前記判断手段によって起動することもできる。
【０１０１】
他の好ましい実施形態としては、パケット・スケジューリング及び受入れ制御をパケット交換セルラー無線アクセス・ネットワーク（packet switched cellular radio access network）の無線基地局において実行する。また、他の形態として、本発明は、エンド−ユーザの端末機上で実行されるアプリケーションにおいて利用することにしてもよい。
【０１０２】
他の実施形態として、本発明は、コンピュータ・プログラム（アプリケーションとも呼ばれる）、又はコンピュータ、移動機若しくは他の通信装置のような処理装置と共に使用するためのコンピュータ・プログラム製品（computer program product）として、実現するものとしてもよい。そのコンピュータ・プログラムの当該処理装置に対する配信（頒布）は、特に、リード・オンリ・メモリＲＯＭ（read only memory）装置、いわゆるＣＤ−ＲＯＭディスク、フロッピー（登録商標）・ディスク若しくはハード・ディスクにより、若しくはネットワークのような通信媒体を通じて、若しくはモデムを介して、又はエア・インタフェース（air interface）を介した無線により、行うことができる。
【０１０３】
処理装置の通常の処理に加えて、その処理装置上でそのコンピュータ・プログラムが実行される場合には、それの記憶されたプログラムによるそれぞれのコンピュータ・プログラム製品である、そのコンピュータ・プログラムのソフトウェア・コード部分（software code portions）が、パケット・スケジューリング及び／又は受入れ制御を実行する。
【０１０４】
通常では、前記コンピュータ・プログラムは、パケット・スケジューリング及び／又は受入れ制御のための先に説明した方法の観念における命令を実行する間に作動する。
【０１０５】
特に、受入れ制御については、そのコンピュータ・プログラムのソフトウェア・コード部分は、デジタル・コンピュータのメモリ内にロードされてそのデジタル・コンピュータ上で実行され、始めにデータ・パケット・ストリームにおける受入れ制御パケットＡＣＰを検出するステップを実行する。これは、それぞれの時点で受信したデータ・パケットの構造と受入れ制御パケットＡＣＰの既知の構造を比較することによって行うことができる。受入れ制御パケットＡＣＰが見つかった場合には、その制御パラメータＲｈ、Ｒｌを読み取る。次のステップでは、処理装置で取り扱うことができ、かつ、アプリケーションに対して固定された値として与えられる全体のスループットＶｍａｘと、例えばリンク・レイヤ測定により、処理装置が与えることが可能な現在占有しているスループットとの、差として、処理装置において利用可能なスループットＶを計算する。さらに次のステップでは、そのコンピュータ・プログラムは、要求されたスループットＲｌを利用可能なスループットＶと比較する。利用可能なスループットＶが要求されたスループットＲｌよりも低い場合には、受入れ制御パケットＡＣＰに属するサブ−ストリームが拒否される。そうでない場合には、要求されたスループットＲｌと第２のスループット値とによって与えられる範囲のうちからスループット値を選択する。ここにいう第２のスループット値とは、利用可能なスループットＶ及び最高の希望されたスループットＲｈのうちの最小値である。他の実施形態としては、その第２のスループット値は、利得関数によって処理装置から先に説明したのと同様にして供給される。前記スループット値の選択後に、サブ−ストリームがリアルタイム処理に受け入れられる。
【０１０６】
さらなる実施形態として、受入れ制御を実行するソフトウェア・コード部分は、処理装置のＶｍａｘ及びＶ等のようなスループット能力を含む、修正した受入れ制御パケットを生成する。その修正した受入れ制御パケットは、先に述べた理由により、サブ−ストリームの伝送路に沿って送り返される。
【０１０７】
コンピュータ・プログラムの追加のソフトウェア・コード部分、あるいは他の形態のさらなるコンピュータ・プログラムのソフトウェア・コード部分は、実行中にパケット・スケジューリングを実行する。始めに、データ・パケット・ストリームにおいて同期制御パケットを検出する。次に、それの同期制御パラメータＮ、Ｉ及びＳを読み取る。パケット・スケジューリング・アプリケーションからのペイロード・データ・パケットの伝送用に予見（foresee）される伝送チャネルｊのパケット誤り率、当該チャネルのビット・レート、及び当該アプリケーションにおけるペイロード・データ・パケットの現時点での到達時間を示すタイマの値ｔを、例えば処理装置からの測定ないしポーリングのルーチンによって判断した後に、同期制御パケットＳＣＰが関係する（示す）同期エンティティＳＥに属するそれぞれのペイロード・データ・パケットについて配信デッドラインを計算する。ペイロード・データ・パケットは、それらのデッドラインの順序で待ち行列ＥＤＦ内にソートされ、待ち行列ＥＤＦがそれぞれのデータ・パケット・スロット（data packet slot）に対してタイム・スタンプを与える。それぞれのスロットのタイム・スタンプは、個々に、そのスロット中に格納されたデータ・パケットの計算された配信デッドラインに設定される。
【０１０８】
本発明のさらなる好ましい実施形態としては、リアルタイム処理に受け入れられるデータ・パケットについてのみ配信デッドラインを計算する。
【０１０９】
コンピュータ・プログラムによりリアルタイム処理に対して拒否されるデータ・パケットは、第２の待ち行列ＦＩＦＯに格納し、最善努力型の方策によって処理されるようにすることができる。
【０１１０】
さらに、コンピュータ・プログラムは、データ・パケットの読出をしている間の双方の待ち行列に対する優先順位付け（prioritisation）を実行してリアルタイム処理に受け入れられたデータ・パケットの処理の方を選ぶように、処理装置に対する命令をするものとしてもよい。
【０１１１】
さらなる実施形態としては、コンピュータ・プログラムのソフトウェア・コード部分は、処理装置に対し、絶対時間ないし相対時間を与える実際の時間値を各タイム・スタンプに格納された配信デッドラインと比較することにより、第１の待ち行列ＥＤＦ中に格納されたペイロード・データ・パケットの配信デッドラインを監視することを命令する。そのようにすると、コンピュータ・プログラムは、配信デッドライン超過を検出できることになる。さらなるステップでは、第１の待ち行列ＥＤＦのペイロード・データ・パケットの適応化を実行することができ、あるいは他の形態として、その適応化を別個のアプリケーションから要求することができる。
【０１１２】
ペイロード・データ秘匿や他のセキュリティ・メカニズムを利用するデータ・パケット・ストリームをも取り扱うためには、コンピュータ・プログラムは、同期制御パラメータ及び／又は受入れ制御パラメータをデータ・パケットＳＣＰ、ＡＣＰ自体から読み取るのに加えて、あるいは、これに代えて、その同期制御パラメータ及び／又は受入れ制御パラメータを下層にあるネットワーク・プロトコルのヘッダから読み取る、ソフトウェア・コード部分を与えるものとすることができる。
【０１１３】
さらに、以下の過程を有する方法を実行することができる。すなわち、リアルタイムのデータ・トラヒックを搬送し、かつ、受入れ制御装置ＡＣで受信されるデータ・パケット・ストリームにおいて、受入れ制御パラメータを含む第１の受入れ制御パケットＡＣＰを検出する過程と、前記第１の受入れ制御パケットから少なくとも２つの受入れ制御パラメータＲｌ、Ｒｈを読み取る過程と、前記受入れ制御装置ＡＣで利用可能な全体のスループットＶｍａｘと現在占有されているスループットＶｃとの差としてスループットＶを計算する過程と、スループットＶを要求されたスループットＲｌと比較する過程と、利用可能なスループットＶが最低の要求されたスループットＲｌよりも低い場合に前記第１の受入れ制御パケットと第２の受入れ制御パケットとの間に続いて来るデータ・パケットのサブ−ストリームのリアルタイム処理を拒否する過程、又はそれ以外の場合に最低の要求されたスループットＲｌと第２のスループット値Ｒｈ、Ｍを限界値として含むスループット値の範囲からスループット値を選択すると共に前記サブ−ストリームのリアルタイム処理を受け入れる過程とを、有する方法を実行することができる。さらなる実施形態においては、好ましくは、上記過程に加えて、前記受入れ制御装置ＡＣのスループット能力パラメータを含む修正した受入れ制御パケットを生成して受入れ制御装置ＡＣからサブ−ストリームの伝送路に沿って送り返す過程を実行する。
【０１１４】
特許請求の範囲においては双方の特徴を組み合わせて記載しているだけだが、より後で述べた受入れ制御の特徴と関係する実施形態の過程については、オプションとして（任意選択的に）同期制御の特徴と関係する過程から独立したものとすることができる。双方の特徴は、例えば、対応する方法ないし対応するコンピュータ・プログラムにより、互いに対して独立して、実現することができる。
【０１１５】
現在実践的と考えられるものと好ましい実施形態に関連して本発明の説明をしたが、本発明は、開示した実施形態に限定されるものではなく、それどころか逆に、本発明は、特許請求の範囲の精神及び領域の中に含まれる様々な変形や均等な装置を包含するものと解釈される。
【図面の簡単な説明】
【０１１６】
【図１】図１ａがそれぞれ異なる同期エンティティを伴う画像ストリームを示し、図１ｂがそれぞれ異なる同期エンティティを伴う他の画像ストリームを示し、図１ｃが受入れ制御パケットＡＣＰ及び同期制御パケットＳＣＰｓを伴うデータ・パケット・ストリームを示す。
【図２】図２ａがＳＣＰ中に含まれるパラメータを示し、図２ｂがＡＣＰ中に含まれるパラメータを示す。
【図３】受入れ制御装置のタスクを流れ図に示したものである。
【図４】パケット・スケジューラの機能図を示したものである。
【図５】パケット・スケジューラのタスクを流れ図に示したものである。
【外国語明細書】
2007312413000001.pdf
2007312413000002.pdf
2007312413000003.pdf
2007312413000004.pdf