JP4662670B2 - パケット・データ・トラヒックのスケジューリング及び受入れ制御 - Google Patents
パケット・データ・トラヒックのスケジューリング及び受入れ制御 Download PDFInfo
- Publication number
- JP4662670B2 JP4662670B2 JP2001511039A JP2001511039A JP4662670B2 JP 4662670 B2 JP4662670 B2 JP 4662670B2 JP 2001511039 A JP2001511039 A JP 2001511039A JP 2001511039 A JP2001511039 A JP 2001511039A JP 4662670 B2 JP4662670 B2 JP 4662670B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- time
- queue
- throughput
- deadline
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
- H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
- H04N21/64738—Monitoring network characteristics, e.g. bandwidth, congestion level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/822—Collecting or measuring resource availability data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
- H04N21/64784—Data processing by the network
- H04N21/64792—Controlling the complexity of the content stream, e.g. by dropping packets
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
（発明の分野）
本発明は、概して、通信システムにおけるパケット・データ・トラヒックの処理に関する。また特に、本発明は、データの各パケットのスケジューリング及び受入れ制御（admission control）に関する。
【０００２】
（発明の背景）
Liebeherr 等の論文“ Workconserving vs. non-workconserving packet scheduling: an issue revisited ” , 1999 Seventh International Workshop on Quality of Service, Proceedings of IWQOS'99, p.248-256 を参照すると、品質条件ネットワークにおいて用いるためのいわゆる最早期−デッドライン−ファーストのスケジューリングが開示されている。スケジューラにおいて、それぞれのデータ・パケットは、その到達時間と遅延制約の合計に等しく設定されるデッドラインによってタイムスタンプを付され、パケットは、デッドラインの増大する順に伝送される。
さらに、パケット指向の通信ネットワークにおける品質条件の規定（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）をリンク・レイヤの誤り訂正として利用する。
【００９２】
ビット・レートＲｊは、例えば入来するビットをカウントすることにより、受入れ制御装置やパケット・スケジューラにおいて判断することができる。
【００９３】
本発明の好ましい実施形態においては、それぞれのペイロード・データ・パケットについてのデッドラインを次のように計算する。
【数３】
【００９４】
さらに好ましい実施形態においては、ＥＤＦ待ち行列中にソートされたペイロード・データ・パケットについての配信デッドラインの超過をパケット・スケジューラが検出する。この超過の検出は、それらの配信デッドラインを、システム時間（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）を実行してリアルタイム処理に受け入れられたデータ・パケットの処理の方を選ぶように、処理装置に対する命令をするものとしてもよい。
【０１１２】
さらなる実施形態としては、コンピュータ・プログラムのソフトウェア・コード部分は、処理装置に対し、絶対時間ないし相対時間を与える実際の時間値を各タイム・スタンプに格納された配信デッドラインと比較することにより、第１の待ち行列ＥＤＦ中に格納されたペイロード・データ・パケットの配信デッドラインを監視することを命令する。そのようにすると、コンピュータ・プログラムは、配信デッドライン超過を検出できることになる。さらなるステップでは、第１の待ち行列ＥＤＦのペイロード・データ・パケットの適応化を実行することができ、あるいは他の形態として、その適応化を別個のアプリケーションから要求することができる。
【０１１３】
ペイロード・データ秘匿や他のセキュリティ・メカニズムを利用するデータ・パケット・ストリームをも取り扱うためには、コンピュータ・プログラムは、同期制御パラメータ及び／又は受入れ制御パラメータをデータ・パケットＳＣＰ、ＡＣＰ自体から読み取るのに加えて、あるいは、これに代えて、その同期制御パラメータ及び／又は受入れ制御パラメータを下層にあるネットワーク・プロトコルのヘッダから読み取る、ソフトウェア・コード部分を与えるものとすることができる。
【０１１４】
さらに、以下の過程を有する方法を実行することができる。すなわち、リアルタイムのデータ・トラヒックを搬送し、かつ、受入れ制御装置ＡＣで受信されるデータ・パケット・ストリームにおいて、受入れ制御パラメータを含む第１の受入れ制御パケットＡＣＰを検出する過程と、前記第１の受入れ制御パケットから少なくとも２つの受入れ制御パラメータＲｌ、Ｒｈを読み取る過程と、前記受入れ制御装置ＡＣで利用可能な全体のスループットＶｍａｘと現在占有されているスループットＶｃとの差としてスループットＶを計算する過程と、スループットＶを要求されたスループットＲｌと比較する過程と、利用可能なスループットＶが最低の要求されたスループットＲｌよりも低い場合に前記第１の受入れ制御パケットと第２の受入れ制御パケットとの間に続いて来るデータ・パケットのサブ−ストリームのリアルタイム処理を拒否する過程、又はそれ以外の場合に最低の要求されたスループットＲｌと第２のスループット値Ｒｈ、Ｍを限界値として含むスループット値の範囲からスループット値を選択すると共に前記サブ−ストリームのリアルタイム処理を受け入れる過程とを、有する方法を実行することができる。さらなる実施形態においては、好ましくは、上記過程に加えて、前記受入れ制御装置ＡＣのスループット能力パラメータを含む修正した受入れ制御パケットを生成して受入れ制御装置ＡＣからサブ−ストリームの伝送路に沿って送り返す過程を実行する。
【０１１５】
特許請求の範囲においては双方の特徴を組み合わせて記載しているだけだが、より後で述べた受入れ制御の特徴と関係する実施形態の過程については、オプションとして（任意選択的に）同期制御の特徴と関係する過程から独立したものとすることができる。双方の特徴は、例えば、対応する方法ないし対応するコンピュータ・プログラムにより、互いに対して独立して、実現することができる。
【０１１６】
現在実践的と考えられるものと好ましい実施形態に関連して本発明の説明をしたが、本発明は、開示した実施形態に限定されるものではなく、それどころか逆に、本発明は、特許請求の範囲の精神及び領域の中に含まれる様々な変形や均等な装置を包含するものと解釈される。
【図面の簡単な説明】
【図１】 図１ａがそれぞれ異なる同期エンティティを伴う画像ストリームを示し、図１ｂがそれぞれ異なる同期エンティティを伴う他の画像ストリームを示し、図１ｃが受入れ制御パケットＡＣＰ及び同期制御パケットＳＣＰｓを伴うデータ・パケット・ストリームを示す。
【図２】 図２ａがＳＣＰ中に含まれるパラメータを示し、図２ｂがＡＣＰ中に含まれるパラメータを示す。
【図３】 受入れ制御装置のタスクを流れ図に示したものである。
【図４】 パケット・スケジューラの機能図を示したものである。
【図５】 パケット・スケジューラのタスクを流れ図に示したものである。
（発明の分野）
本発明は、概して、通信システムにおけるパケット・データ・トラヒックの処理に関する。また特に、本発明は、データの各パケットのスケジューリング及び受入れ制御（admission control）に関する。
【０００２】
（発明の背景）
Liebeherr 等の論文“ Workconserving vs. non-workconserving packet scheduling: an issue revisited ” , 1999 Seventh International Workshop on Quality of Service, Proceedings of IWQOS'99, p.248-256 を参照すると、品質条件ネットワークにおいて用いるためのいわゆる最早期−デッドライン−ファーストのスケジューリングが開示されている。スケジューラにおいて、それぞれのデータ・パケットは、その到達時間と遅延制約の合計に等しく設定されるデッドラインによってタイムスタンプを付され、パケットは、デッドラインの増大する順に伝送される。
さらに、パケット指向の通信ネットワークにおける品質条件の規定（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）をリンク・レイヤの誤り訂正として利用する。
【００９２】
ビット・レートＲｊは、例えば入来するビットをカウントすることにより、受入れ制御装置やパケット・スケジューラにおいて判断することができる。
【００９３】
本発明の好ましい実施形態においては、それぞれのペイロード・データ・パケットについてのデッドラインを次のように計算する。
【数３】
さらに好ましい実施形態においては、ＥＤＦ待ち行列中にソートされたペイロード・データ・パケットについての配信デッドラインの超過をパケット・スケジューラが検出する。この超過の検出は、それらの配信デッドラインを、システム時間（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）を実行してリアルタイム処理に受け入れられたデータ・パケットの処理の方を選ぶように、処理装置に対する命令をするものとしてもよい。
【０１１２】
さらなる実施形態としては、コンピュータ・プログラムのソフトウェア・コード部分は、処理装置に対し、絶対時間ないし相対時間を与える実際の時間値を各タイム・スタンプに格納された配信デッドラインと比較することにより、第１の待ち行列ＥＤＦ中に格納されたペイロード・データ・パケットの配信デッドラインを監視することを命令する。そのようにすると、コンピュータ・プログラムは、配信デッドライン超過を検出できることになる。さらなるステップでは、第１の待ち行列ＥＤＦのペイロード・データ・パケットの適応化を実行することができ、あるいは他の形態として、その適応化を別個のアプリケーションから要求することができる。
【０１１３】
ペイロード・データ秘匿や他のセキュリティ・メカニズムを利用するデータ・パケット・ストリームをも取り扱うためには、コンピュータ・プログラムは、同期制御パラメータ及び／又は受入れ制御パラメータをデータ・パケットＳＣＰ、ＡＣＰ自体から読み取るのに加えて、あるいは、これに代えて、その同期制御パラメータ及び／又は受入れ制御パラメータを下層にあるネットワーク・プロトコルのヘッダから読み取る、ソフトウェア・コード部分を与えるものとすることができる。
【０１１４】
さらに、以下の過程を有する方法を実行することができる。すなわち、リアルタイムのデータ・トラヒックを搬送し、かつ、受入れ制御装置ＡＣで受信されるデータ・パケット・ストリームにおいて、受入れ制御パラメータを含む第１の受入れ制御パケットＡＣＰを検出する過程と、前記第１の受入れ制御パケットから少なくとも２つの受入れ制御パラメータＲｌ、Ｒｈを読み取る過程と、前記受入れ制御装置ＡＣで利用可能な全体のスループットＶｍａｘと現在占有されているスループットＶｃとの差としてスループットＶを計算する過程と、スループットＶを要求されたスループットＲｌと比較する過程と、利用可能なスループットＶが最低の要求されたスループットＲｌよりも低い場合に前記第１の受入れ制御パケットと第２の受入れ制御パケットとの間に続いて来るデータ・パケットのサブ−ストリームのリアルタイム処理を拒否する過程、又はそれ以外の場合に最低の要求されたスループットＲｌと第２のスループット値Ｒｈ、Ｍを限界値として含むスループット値の範囲からスループット値を選択すると共に前記サブ−ストリームのリアルタイム処理を受け入れる過程とを、有する方法を実行することができる。さらなる実施形態においては、好ましくは、上記過程に加えて、前記受入れ制御装置ＡＣのスループット能力パラメータを含む修正した受入れ制御パケットを生成して受入れ制御装置ＡＣからサブ−ストリームの伝送路に沿って送り返す過程を実行する。
【０１１５】
特許請求の範囲においては双方の特徴を組み合わせて記載しているだけだが、より後で述べた受入れ制御の特徴と関係する実施形態の過程については、オプションとして（任意選択的に）同期制御の特徴と関係する過程から独立したものとすることができる。双方の特徴は、例えば、対応する方法ないし対応するコンピュータ・プログラムにより、互いに対して独立して、実現することができる。
【０１１６】
現在実践的と考えられるものと好ましい実施形態に関連して本発明の説明をしたが、本発明は、開示した実施形態に限定されるものではなく、それどころか逆に、本発明は、特許請求の範囲の精神及び領域の中に含まれる様々な変形や均等な装置を包含するものと解釈される。
【図面の簡単な説明】
【図１】 図１ａがそれぞれ異なる同期エンティティを伴う画像ストリームを示し、図１ｂがそれぞれ異なる同期エンティティを伴う他の画像ストリームを示し、図１ｃが受入れ制御パケットＡＣＰ及び同期制御パケットＳＣＰｓを伴うデータ・パケット・ストリームを示す。
【図２】 図２ａがＳＣＰ中に含まれるパラメータを示し、図２ｂがＡＣＰ中に含まれるパラメータを示す。
【図３】 受入れ制御装置のタスクを流れ図に示したものである。
【図４】 パケット・スケジューラの機能図を示したものである。
【図５】 パケット・スケジューラのタスクを流れ図に示したものである。
Claims (21)
- 通信システムにおいてリアルタイムのデータ・トラヒックを搬送するデータ・パケット・ストリームを処理する方法であって、
−ｐ＝１、２、３、…として、ｐ個の同期制御パラメータの数を含む第１の同期制御パケット（ＳＣＰ）を受信する過程と、
−同期制御パケット（ＳＣＰ）から少なくとも一つの同期制御パラメータを読み取る過程と、
−少なくとも一つのペイロード・データ・パケットを受信する過程と、
−それぞれのペイロード・データ・パケットについて配信デッドラインを判断する過程であって、前記同期制御パケット（ＳＣＰ）から読み取られる前記少なくとも一つの同期制御パラメータによって前記配信デッドラインを判断する過程と、
−前記少なくとも一つのペイロード・データ・パケットをその判断された配信デッドラインに従って第１の待ち行列（ＥＤＦ）中にソートすると共に、前記判断された配信デッドラインに対して前記第１の待ち行列（ＥＤＦ）にタイム・スタンプを設定する過程と
を有し、
少なくとも一つの同期制御パラメータを読み取る前記過程は、
−同期エンティティにおけるパケットの個数（Ｎ）と、
−最大伝送時間（Ｉ）と、
−それぞれのペイロード・パケットについてのバイト−サイズ（Ｓ）と
を読み取ることを含み、それぞれのペイロード・データ・パケットについての配信デッドラインの前記判断は、
−前記同期エンティティを伝送するのに使用するチャネル（ｊ）のパケット誤り率（Ｐｊ）を判断する過程と、
−当該チャネル（ｊ）のビット・レート（Ｒｊ）を判断する過程と、
−ペイロード・データ・パケットの現時点での到達時間を示す時間値（ｔ）を判断する過程と、
−前記パケットの個数（Ｎ）、前記最大伝送時間（Ｉ）、前記バイト−サイズ（Ｓ）、前記パケット誤り率（Ｐｊ）、前記ビット・レート（Ｒｊ）及び前記時間値（ｔ）によって前記配信デッドラインを計算する過程と
を含む方法。 - 現時点でのペイロード・データ・パケットｉについての前記配信デッドラインを
- 請求項１又は２記載の方法であって、
−ｑ＝１、２、３、…として、ｑ個の受入れ制御パラメータの数を含む第１の受入れ制御パケット（ＡＣＰ）を受信する過程と、
−前記第１の受入れ制御パケットの後でかつ第２の受入れ制御パケットの前に受信される、データ・パケットのサブ−ストリームのリアルタイム処理のために要求されるスループット（Ｒｌ）を示す少なくとも一つの受入れ制御パラメータを当該第１の受入れ制御パケット（ＡＣＰ）から読み取る過程と、
−現在利用可能なスループット（Ｖ）を判断する過程と、
−要求されたスループット（Ｒｌ）と前記利用可能なスループット（Ｖ）を比較する過程と、
−前記利用可能なスループット（Ｖ）が前記要求されたスループット（Ｒｌ）より高いか若しくはこれに等しい場合に、前記サブ−ストリームのリアルタイム処理を受け入れ、そして当該サブ−ストリームをパケット・スケジューラへ送る過程と
をさらに有する方法。 - 請求項３記載の方法において、
−前記少なくとも一つの受入れ制御パラメータを読み取る前記過程は、最大スループット（Ｒｈ）を読み取ることを含み、
−最小の要求されたスループット（Ｒｌ）と前記最大のスループット（Ｒｈ）及び前記利用可能なスループット（Ｖ）のうちの最小との間のスループットをサブ−ストリーム用に選択する過程
をさらに有する方法。 - 請求項３又は４記載の方法において、
−当該サブ−ストリームがリアルタイム処理に受け入れられない場合に、サブ−ストリームのリアルタイム処理を拒否し、そして当該サブ−ストリームを前記パケット・スケジューラへ送る過程
をさらに有する方法。 - 請求項５記載の方法であって、リアルタイム処理に対してサブ−ストリームを拒否するケースにおいて、
−前記パケット・スケジューラでデータ・パケットをそれらの現れた順序で第２の待ち行列（ＦＩＦＯ）中にソートする過程
をさらに有する方法。 - 請求項６記載の方法であって、
−前記第１の待ち行列（ＥＤＦ）からのデータ・パケットをそれらの配信デッドラインに従ってさらに処理する過程と、
−前記第２の待ち行列からのデータ・パケットをファースト・イン−ファースト・アウトの方策に従ってさらに処理する過程と
をさらに有する方法。 - 請求項５、６又は７記載の方法であって、
−前記さらなる処理のための出力インタフェースにより、前記第１の待ち行列（ＥＤＦ）に含まれるデータ・パケット及び前記第２の待ち行列（ＦＩＦＯ）に含まれるデータ・パケットを優先するものから順に処理する過程
をさらに有する方法。 - 請求項３ないし８のいずれかに記載の方法であって、
−受入れ制御装置（ＡＣ）から、当該受入れ制御装置（ＡＣ）のスループット能力パラメータを含む修正した受入れ制御パケットを生成してサブ−ストリームの伝送路に沿って返送する過程
をさらに有する方法。 - 請求項１ないし９のいずれかに記載の方法であって、
−下層にあるネットワーク・プロトコルのヘッダから同期制御パラメータを受信するさらなる過程
を有する方法。 - 請求項１ないし１０のいずれかに記載の方法であって、
−前記第１の待ち行列（ＥＤＦ）中にソートされたペイロード・パケットについてそれらの当該第１の待ち行列内で費やした実際の時間をそれらのタイム・スタンプに基づくそれらのデッドラインと繰り返し比較することによりデッドライン超過を検出するさらなる過程
を有する方法。 - 請求項１１記載の方法であって、
−前記デッドライン超過を検出した後に前記第１の待ち行列（ＥＤＦ）の少なくとも一つのペイロード・データ・パケットの適応化を実行するさらなる過程
を有する方法。 - 請求項１ないし１２のいずれかに記載の方法であって、
−下層にあるネットワーク・プロトコルのヘッダから受入れ制御パラメータを受信するさらなる過程
を有する方法。 - リアルタイムのデータ・パケット・トラヒックを処理するための通信システムにおけるネットワーク・ノードであって、
−通信チャネル（ｊ）のパケット誤り率（Ｐｊ）を判断するパケット誤り率判断ユニットと、
−当該通信チャネル（ｊ）のビット・レート（Ｒｊ）を判断するビット・レート判断ユニットと、
−前記ネットワーク・ノードにおいて受信される少なくとも一つのデータ・パケットについて現時点での時間値（ｔ）を判断するタイマと、
−トラヒック・フローに埋め込まれた少なくとも一つの制御パケット（ＡＣＰ、ＳＣＰ）により与えられる制御パラメータを評価する評価手段と、
−前記パケット誤り率判断ユニットにより与えられるパケット誤り率（Ｐｊ）、前記ビット・レート判断ユニットにより与えられるビット・レート（Ｒｊ）、前記タイマにより与えられる時間値（ｔ）及び前記評価手段により与えられる少なくとも一つの評価された制御パラメータによって少なくとも一つのデータ・パケットについてのデッドラインを計算する計算機ユニットと、
−前記計算機ユニットにより与えられるデータ・パケットのデッドラインに基づいてそれらのデータ・パケットのスケジューリングをするための第１の待ち行列（ＥＤＦ）と
を有するネットワーク・ノード。 - 請求項１４記載のネットワーク・ノードにおいて、
前記第１の待ち行列（ＥＤＦ）は、最早期デッドライン・ファーストの方策に従い、前記第１の待ち行列中にデータ・パケットをそれらのデッドラインに基づいてソートするソーティング・ユニットを有し、
前記ソーティング・ユニットは、計算されたデッドラインに基づいて前記第１の待ち行列（ＥＤＦ）のタイム・スタンプを設定する、ネットワーク・ノード。 - 請求項１４又は１５記載のネットワーク・ノードであって、
−前記ネットワーク・ノードの現在利用可能なスループット（Ｖ）を判断する判断ユニットと、
−入来するデータ・パケット・トラヒック・フローが前記ネットワーク・ノードにおいて受入れ制御パラメータにより与えられるリアルタイムの要求特性に従って処理できるかどうかを判断する判断手段と
をさらに有するネットワーク・ノード。 - 請求項１４ないし１６のいずれかに記載のネットワーク・ノードであって、
−リアルタイム処理に受け入れられないデータ・パケットのための第２の待ち行列と、
−データ・パケット・トラヒック・フローを、前記判断手段による肯定的な判断の後に前記第１の待ち行列（ＥＤＦ）に転送し、あるいは、否定的な判断の後に前記第２の待ち行列（ＦＩＦＯ）に転送する転送ユニットと、
−すべての待ち行列を優先するものから順に処理すると共にすべての待ち行列からデータ・パケットを読み出す出力インタフェース（ＯＩ）と
をさらに有するネットワーク・ノード。 - 請求項１４ないし１７のいずれかに記載のネットワーク・ノードであって、
−データ・パケットのデッドラインを監視し、少なくとも一つのデッドライン超過を検出し、かつ、少なくとも一つのデータ・パケットの適応化を起動するデッドライン超過処理機と、
−少なくとも一つのデータ・パケットの前記適応化のための適応化ユニットと
をさらに有するネットワーク・ノード。 - 請求項１４ないし１８のいずれかに記載のネットワーク・ノードであって、当該リアルタイムのデータ・パケット・トラヒックの受信及び送信を行う無線基地局をさらに有するネットワーク・ノード。
- デジタル・コンピュータのメモリ内にロード可能なコンピュータ・プログラムを記憶した記憶媒体であって、
当該コンピュータ・プログラムがコンピュータ上で実行されるときに、
−リアルタイムのデータ・トラヒックを搬送し、かつ、パケット・スケジューラで受信されるデータ・パケット・ストリームにおいて、少なくとも一つのペイロード・データ・パケットを含む同期エンティティが続いて来る、同期制御パラメータを含む少なくとも一つの同期制御パケット（ＳＣＰ）を検出する過程と、
−前記同期エンティティにおけるパケットの個数（Ｎ）、前記同期エンティティのリアルタイム伝送に対して許容された最大伝送時間（Ｉ）及び前記同期エンティティのバイト−サイズ（Ｓ）を、前記同期制御パケットから読み取る過程と、
−当該サブ−ストリームを伝送するために使用するチャネル（ｊ）のパケット誤り率（Ｐｊ）を判断する過程と、
−当該チャネルのビット・レート（Ｒｊ）を判断する過程と、
−ペイロード・データ・パケットの現時点での到達時間を示す時間値（ｔ）を判断する過程と、
−前記パケットの個数（Ｎ）、前記最大伝送時間（Ｉ）、前記バイト−サイズ（Ｓ）、前記パケット誤り率（Ｐｊ）、前記ビット・レート（Ｒｊ）及び前記時間値（ｔ）によってそれぞれのペイロード・データ・パケットについて配信デッドラインを計算する過程と、
−それぞれのペイロード・パケットをそのデッドラインに基づいてタイム・スタンプ・ベースの第１の待ち行列（ＥＤＦ）中にソートすると共に、前記第１の待ち行列のタイム・スタンプを計算されたデッドラインに設定する過程と
を実行するためのソフトウェア・コード部分を有するコンピュータ・プログラムを記憶した記憶媒体。 - 現時点でのペイロード・データ・パケット（ｉ）についての配信デッドラインを
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP99113820.7 | 1999-07-15 | ||
| EP99113820A EP1069736B1 (en) | 1999-07-15 | 1999-07-15 | Scheduling and admission control of packet data traffic |
| PCT/EP2000/006526 WO2001006714A1 (en) | 1999-07-15 | 2000-07-10 | Scheduling and admission control of packet data traffic |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007179432A Division JP4964046B2 (ja) | 1999-07-15 | 2007-07-09 | パケット・データ・トラヒックのスケジューリング及び受入れ制御 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003505931A JP2003505931A (ja) | 2003-02-12 |
| JP4662670B2 true JP4662670B2 (ja) | 2011-03-30 |
Family
ID=8238602
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001511039A Expired - Lifetime JP4662670B2 (ja) | 1999-07-15 | 2000-07-10 | パケット・データ・トラヒックのスケジューリング及び受入れ制御 |
| JP2007179432A Expired - Lifetime JP4964046B2 (ja) | 1999-07-15 | 2007-07-09 | パケット・データ・トラヒックのスケジューリング及び受入れ制御 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007179432A Expired - Lifetime JP4964046B2 (ja) | 1999-07-15 | 2007-07-09 | パケット・データ・トラヒックのスケジューリング及び受入れ制御 |
Country Status (8)
| Country | Link |
|---|---|
| US (2) | US6728270B1 (ja) |
| EP (2) | EP1069736B1 (ja) |
| JP (2) | JP4662670B2 (ja) |
| AU (1) | AU763220B2 (ja) |
| ES (2) | ES2394623T3 (ja) |
| HU (1) | HU229717B1 (ja) |
| IL (3) | IL147513A0 (ja) |
| WO (1) | WO2001006714A1 (ja) |
Families Citing this family (106)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6654933B1 (en) | 1999-09-21 | 2003-11-25 | Kasenna, Inc. | System and method for media stream indexing |
| US6721789B1 (en) * | 1999-10-06 | 2004-04-13 | Sun Microsystems, Inc. | Scheduling storage accesses for rate-guaranteed and non-rate-guaranteed requests |
| CN1321889C (zh) * | 1999-11-09 | 2007-06-20 | 花王株式会社 | 制备细沸石颗粒的方法 |
| GB0006230D0 (en) * | 2000-03-16 | 2000-05-03 | Univ Strathclyde | Mobile communications newworks |
| US7277956B2 (en) * | 2000-07-28 | 2007-10-02 | Kasenna, Inc. | System and method for improved utilization of bandwidth in a computer system serving multiple users |
| US7310678B2 (en) * | 2000-07-28 | 2007-12-18 | Kasenna, Inc. | System, server, and method for variable bit rate multimedia streaming |
| US7725587B1 (en) | 2000-08-24 | 2010-05-25 | Aol Llc | Deep packet scan hacker identification |
| GB2367459A (en) * | 2000-09-28 | 2002-04-03 | Roke Manor Research | Method of compressing data packets |
| EP1235405A4 (en) * | 2000-10-06 | 2005-08-10 | Mitsubishi Electric Corp | DATA TRANSMISSION METHOD AND DATA TRANSMISSION DEVICE |
| SE517721C2 (sv) * | 2000-11-10 | 2002-07-09 | Ericsson Telefon Ab L M | Metod att generera och upprätthålla önskad tjänstekvalitet för datatrafik i ett kommunikationssystem |
| US20020071388A1 (en) * | 2000-11-16 | 2002-06-13 | Einar Bergsson | Selectable network protocol |
| US6930982B2 (en) * | 2000-12-12 | 2005-08-16 | Cisco Technology, Inc. | Devices, software and methods for measuring packet loss burstiness to determine quality of voice data transmission through a network |
| US6925063B2 (en) * | 2000-12-14 | 2005-08-02 | Shmuel Goldshtein | Voice over internet communications algorithm and related method for optimizing and reducing latency delays |
| US20020147834A1 (en) * | 2000-12-19 | 2002-10-10 | Shih-Ping Liou | Streaming videos over connections with narrow bandwidth |
| US8069254B2 (en) | 2001-02-28 | 2011-11-29 | Sharp Laboratories Of America, Inc. | Communication period management in a communication system |
| US7024482B2 (en) * | 2001-02-28 | 2006-04-04 | Sharp Laboratories Of America, Inc. | Pseudo-random dynamic scheduler for scheduling communication periods between electronic devices |
| US20030018978A1 (en) * | 2001-03-02 | 2003-01-23 | Singal Sanjay S. | Transfer file format and system and method for distributing media content |
| EP1374080A2 (en) * | 2001-03-02 | 2004-01-02 | Kasenna, Inc. | Metadata enabled push-pull model for efficient low-latency video-content distribution over a network |
| WO2002073865A2 (en) * | 2001-03-09 | 2002-09-19 | Vitesse Semiconductor Corporation | Time based packet scheduling and sorting system |
| US6879596B1 (en) * | 2001-04-11 | 2005-04-12 | Applied Micro Circuits Corporation | System and method for systolic array sorting of information segments |
| US20030026279A1 (en) * | 2001-06-08 | 2003-02-06 | Tetsuya Onoda | Resource reservation scheme and packet scheduling scheme for file transfer |
| US7006536B1 (en) * | 2001-07-12 | 2006-02-28 | Lighthouse Capital Partners Iv, Lp | System and method for transporting multiple low-bit-rate signals over a single high-bit-rate medium |
| US7170900B2 (en) * | 2001-07-13 | 2007-01-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for scheduling message processing |
| US7904931B2 (en) * | 2001-09-12 | 2011-03-08 | Cox Communications, Inc. | Efficient software bitstream rate generator for video server |
| US7194263B2 (en) * | 2001-09-17 | 2007-03-20 | Microsoft Corporation | System and method for concurrent operation of a wireless device in two disjoint wireless networks |
| US7126945B2 (en) * | 2001-11-07 | 2006-10-24 | Symbol Technologies, Inc. | Power saving function for wireless LANS: methods, system and program products |
| DE10156889A1 (de) * | 2001-11-20 | 2003-06-12 | Siemens Ag | Verfahren zur Paketdatenübertragung in einem Funkkommunikationssystem |
| US6981052B1 (en) * | 2001-12-07 | 2005-12-27 | Cisco Technology, Inc. | Dynamic behavioral queue classification and weighting |
| JP3848145B2 (ja) * | 2001-12-10 | 2006-11-22 | 株式会社エヌ・ティ・ティ・ドコモ | 通信制御システム、通信制御方法及び基地局 |
| US7596089B2 (en) * | 2002-06-04 | 2009-09-29 | Alcatel-Lucent Usa Inc. | Scheduler method and apparatus for communication systems |
| AU2003254004A1 (en) * | 2002-07-18 | 2004-02-09 | Koninklijke Philips Electronics N.V. | Adaptive dropping of prioritized transmission packets |
| US20040199650A1 (en) * | 2002-11-14 | 2004-10-07 | Howe John E. | System and methods for accelerating data delivery |
| US7046677B2 (en) * | 2002-11-27 | 2006-05-16 | Rgb Networks, Inc. | Method and apparatus for time-multiplexed processing of multiple digital video programs |
| AU2003291193A1 (en) * | 2002-11-27 | 2004-06-23 | Rgb Media, Inc. | Apparatus and method for dynamic channel mapping and optimized scheduling of data packets |
| US20040160922A1 (en) | 2003-02-18 | 2004-08-19 | Sanjiv Nanda | Method and apparatus for controlling data rate of a reverse link in a communication system |
| US7155236B2 (en) | 2003-02-18 | 2006-12-26 | Qualcomm Incorporated | Scheduled and autonomous transmission and acknowledgement |
| JP3979306B2 (ja) * | 2003-02-25 | 2007-09-19 | 日本電気株式会社 | 無線端末装置および無線通信システム |
| WO2004088858A2 (en) * | 2003-03-29 | 2004-10-14 | Regents Of University Of California | Method and apparatus for improved data transmission |
| CN1778062A (zh) * | 2003-04-21 | 2006-05-24 | Rgb网络有限公司 | 时分复用多程序加密系统 |
| US7317727B2 (en) * | 2003-05-21 | 2008-01-08 | International Business Machines Corporation | Method and systems for controlling ATM traffic using bandwidth allocation technology |
| DE10327545B4 (de) * | 2003-06-18 | 2005-12-01 | Infineon Technologies Ag | Verfahren und Vorrichtung zur Verarbeitung von Echtzeitdaten |
| US20040258026A1 (en) * | 2003-06-19 | 2004-12-23 | Lau Kin Nang | Method of uplink scheduling for multiple antenna systems |
| US8489949B2 (en) | 2003-08-05 | 2013-07-16 | Qualcomm Incorporated | Combining grant, acknowledgement, and rate control commands |
| CA2537293C (en) | 2003-08-29 | 2014-04-01 | Rgb Networks, Inc. | Advanced, adaptive video multiplexer system |
| US7369559B2 (en) * | 2003-10-06 | 2008-05-06 | Cisco Technology Inc. | Adaptive call admission control for calls handled over a compressed clear channel |
| US7444419B2 (en) * | 2003-10-10 | 2008-10-28 | Microsoft Corporation | Media stream scheduling for hiccup-free fast-channel-change in the presence of network chokepoints |
| US8406235B2 (en) * | 2003-11-26 | 2013-03-26 | Qualcomm Incorporated | Quality of service scheduler for a wireless network |
| AU2003292275A1 (en) * | 2003-12-19 | 2005-07-05 | Nokia Corporation | Selection of radio resources in a wireless communication device |
| US7546357B2 (en) * | 2004-01-07 | 2009-06-09 | Microsoft Corporation | Configuring network settings using portable storage media |
| US7522609B2 (en) * | 2004-01-14 | 2009-04-21 | Cisco Technology, Inc | Propagation of minimum guaranteed scheduling rates among scheduling layers in a hierarchical schedule |
| US7436770B2 (en) * | 2004-01-21 | 2008-10-14 | Alcatel Lucent | Metering packet flows for limiting effects of denial of service attacks |
| GB0402739D0 (en) * | 2004-02-09 | 2004-03-10 | Saviso Group Ltd | Methods and apparatus for routing in a network |
| US8583739B2 (en) | 2004-03-02 | 2013-11-12 | International Business Machines Corporation | Facilitating the sending of mail from a restricted communications network |
| US8046464B2 (en) * | 2004-03-10 | 2011-10-25 | The Boeing Company | Quality of service resource management apparatus and method for middleware services |
| US20050262245A1 (en) * | 2004-04-19 | 2005-11-24 | Satish Menon | Scalable cluster-based architecture for streaming media |
| KR20070058567A (ko) * | 2004-09-02 | 2007-06-08 | 더 리젠트스 오브 더 유니이버시티 오브 캘리포니아 | 콘텐트 및 채널 인식 객체 스케쥴링 및 오류 제어 |
| US7408886B2 (en) | 2004-09-20 | 2008-08-05 | Sony Ericsson Mobile Communication Ab | Method for providing mobile phone user with accurate capability indicator |
| US20070283036A1 (en) * | 2004-11-17 | 2007-12-06 | Sujit Dey | System And Method For Providing A Web Page |
| US20060133513A1 (en) * | 2004-12-22 | 2006-06-22 | Kounnas Michael K | Method for processing multimedia streams |
| US9462333B2 (en) * | 2010-09-27 | 2016-10-04 | Intel Corporation | Method for processing multimedia streams |
| US20080137540A1 (en) * | 2004-12-23 | 2008-06-12 | Corvil Limited | Method And Apparatus For Analysing Traffic In A Network |
| US7715341B2 (en) * | 2005-01-28 | 2010-05-11 | Nortel Networks Limited | Optimized scheduling method for delay-sensitive traffic on high speed shared packet data channels |
| US8259861B2 (en) * | 2005-03-31 | 2012-09-04 | At&T Intellectual Property I, L.P. | Methods and systems for providing bandwidth adjustment |
| US7801043B2 (en) * | 2005-04-01 | 2010-09-21 | Interdigital Technology Corporation | Method and apparatus for admission control and resource tracking in a wireless communication system |
| US7836488B2 (en) * | 2005-08-18 | 2010-11-16 | Hong Kong Applied Science And Technology Research Institute Co. Ltd. | Authentic device admission scheme for a secure communication network, especially a secure IP telephony network |
| JP2007074218A (ja) * | 2005-09-06 | 2007-03-22 | Toyota Infotechnology Center Co Ltd | パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法 |
| US20070070894A1 (en) * | 2005-09-26 | 2007-03-29 | Fan Wang | Method to determine a scheduling priority value for a user data connection based on a quality of service requirement |
| US7529189B2 (en) * | 2005-09-29 | 2009-05-05 | Via Technologies, Inc. | Mechanism for imposing a consistent delay on information sets received from a variable rate information stream |
| US20070116007A1 (en) * | 2005-11-18 | 2007-05-24 | Weimin Xiao | Method and system for scheduling and resource allocation in a data communication network |
| US9002258B2 (en) | 2006-01-18 | 2015-04-07 | Dongju Chung | Adaptable audio instruction system and method |
| US7751317B2 (en) * | 2006-01-26 | 2010-07-06 | Microsoft Corporation | Cost-aware networking over heterogeneous data channels |
| US7793329B2 (en) * | 2006-02-06 | 2010-09-07 | Kasenna, Inc. | Method and system for reducing switching delays between digital video feeds using multicast slotted transmission technique |
| US20080109557A1 (en) * | 2006-11-02 | 2008-05-08 | Vinay Joshi | Method and system for reducing switching delays between digital video feeds using personalized unicast transmission techniques |
| KR101345373B1 (ko) * | 2007-01-05 | 2013-12-24 | 삼성전자주식회사 | 실시간 시스템의 송신 방법 및 장치, 수신 방법 및 장치 |
| US7848237B2 (en) * | 2007-01-18 | 2010-12-07 | Ineoquest Technologies, Inc. | System and method for selective packet discard for the transport of multiple transportation streams of streaming media in packet-based networks |
| CN104754658B (zh) | 2007-07-13 | 2019-08-27 | 苹果公司 | 多跳无线通信环境中的服务质量控制 |
| CN101796775B (zh) | 2007-09-07 | 2014-03-12 | 爱立信电话股份有限公司 | 用于媒体网关的动态准许控制 |
| US7797391B2 (en) | 2007-09-19 | 2010-09-14 | The Chinese University Of Hong Kong | Load balancing and admission scheduling in pull-based parallel video servers |
| US8601069B1 (en) | 2007-11-21 | 2013-12-03 | Marvell International Ltd. | Method and apparatus for message multicasting |
| US9229792B1 (en) | 2007-11-21 | 2016-01-05 | Marvell International Ltd. | Method and apparatus for weighted message passing |
| EP2073459A1 (en) * | 2007-12-17 | 2009-06-24 | Alcatel-Lucent Deutschland AG | Transmission via a burst or frame switched network with timing preservation of the transmitted client packets |
| US8451719B2 (en) * | 2008-05-16 | 2013-05-28 | Imagine Communications Ltd. | Video stream admission |
| US8351449B1 (en) * | 2008-08-07 | 2013-01-08 | Bee Networx Inc. | Scheduling data communication for mobile communication devices with multiple wireless network interfaces associated with differing costs |
| US8743906B2 (en) * | 2009-01-23 | 2014-06-03 | Akamai Technologies, Inc. | Scalable seamless digital video stream splicing |
| US8325764B2 (en) * | 2009-02-24 | 2012-12-04 | Verivue, Inc. | Canonical scheduling for heterogeneous content delivery |
| US8089870B2 (en) * | 2009-07-22 | 2012-01-03 | Cisco Technology, Inc. | QoE based admission control |
| JP5588001B2 (ja) * | 2009-08-21 | 2014-09-10 | ザ チャイニーズ ユニバーシティー オブ ホンコン | メディアデータの転送時間をスケジューリングするための装置及び方法 |
| EP2471313B1 (en) * | 2009-08-25 | 2018-07-25 | Telefonaktiebolaget LM Ericsson (publ) | Admission control in a wireless communication system |
| US20110158182A1 (en) * | 2009-12-24 | 2011-06-30 | Alvarion Ltd. | Method and system of packet scheduling |
| TWI521985B (zh) | 2010-07-08 | 2016-02-11 | 瑞昱半導體股份有限公司 | 無線通訊系統以及在無線通訊系統中調整緩衝單元之使用深度的方法 |
| GB201101709D0 (en) | 2011-02-01 | 2011-03-16 | Transpacket As | A method and a node arrangement for optimizing traffic processing in integrated hybrid networks |
| US8909764B2 (en) * | 2011-07-28 | 2014-12-09 | Xyratex Technology Limited | Data communication method and apparatus |
| TWI443974B (zh) * | 2011-12-07 | 2014-07-01 | Mstar Semiconductor Inc | 封包接收器及其封包處理方法 |
| KR20130068789A (ko) * | 2011-12-16 | 2013-06-26 | 한국전자통신연구원 | 방송 채널 결합 장치 및 방법 |
| US9509529B1 (en) * | 2012-10-16 | 2016-11-29 | Solace Systems, Inc. | Assured messaging system with differentiated real time traffic |
| US9026077B2 (en) | 2013-03-30 | 2015-05-05 | International Business Machines Corporation | Delayed delivery with bounded interference in a cellular data network |
| US9137044B2 (en) | 2013-10-15 | 2015-09-15 | National Instruments Corporation | System and method for interoperability between multiple networks |
| US10164793B2 (en) * | 2013-10-15 | 2018-12-25 | National Instruments Corporation | System and method for interoperability between multiple networks |
| US11695847B2 (en) * | 2014-08-14 | 2023-07-04 | Nokia Solutions And Networks Oy | Throughput guidance based on user plane insight |
| US10721178B2 (en) | 2016-01-22 | 2020-07-21 | Medtronic, Inc. | Systems, apparatus and methods facilitating data buffering and removal |
| WO2018078678A1 (ja) * | 2016-10-31 | 2018-05-03 | 日本電気株式会社 | 通信装置、通信システム、通信方法、及び非一時的なコンピュータ可読媒体 |
| US10505859B2 (en) * | 2016-11-10 | 2019-12-10 | The Government Of The United States Of America, As Represented By The Secretary Of The Navy | Packet deadlines in a queue to control the age of information |
| CN107067759B (zh) * | 2017-03-20 | 2020-12-15 | 长沙理工大学 | 一种基于acp的平行交通信号灯实时控制方法 |
| US10754689B1 (en) * | 2019-02-13 | 2020-08-25 | GM Global Technology Operations LLC | Architecture and device for multi-stream vision processing on shared devices |
| US11329747B2 (en) * | 2020-07-10 | 2022-05-10 | Nokia Solutions And Networks Oy | Scheduling deterministic flows in time synchronized networks |
| TWI733635B (zh) * | 2020-12-18 | 2021-07-11 | 瑞昱半導體股份有限公司 | 分時多工排程器與裝置 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07254906A (ja) * | 1994-03-16 | 1995-10-03 | Mitsubishi Electric Corp | 優先処理機能を有するシフトレジスタ、それを用いたパケット通信用スイッチング装置及びそれを用いたａｔｍネットワーク並びに優先処理を伴うパケット通信方式及び優先処理を伴うａｔｍ通信方式 |
| JPH09168031A (ja) * | 1995-12-15 | 1997-06-24 | Hitachi Ltd | パケット送出に関する実時間スケジューリング方法 |
| JPH10229404A (ja) * | 1997-02-14 | 1998-08-25 | Nippon Telegr & Teleph Corp <Ntt> | セルスイッチ |
| JPH10276221A (ja) * | 1997-03-25 | 1998-10-13 | Internatl Business Mach Corp <Ibm> | セル伝送のスケジューリング方法および装置 |
| JPH10322338A (ja) * | 1997-05-14 | 1998-12-04 | Nippon Telegr & Teleph Corp <Ntt> | Ａｔｍブロック転送ノード |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04326836A (ja) * | 1991-04-26 | 1992-11-16 | Nippon Telegr & Teleph Corp <Ntt> | バーチャルパス容量制御装置 |
| JP2968143B2 (ja) * | 1993-03-04 | 1999-10-25 | 沖電気工業株式会社 | バーチャルパス容量可変制御方法及びその装置 |
| JP2776301B2 (ja) * | 1994-08-30 | 1998-07-16 | 日本電気株式会社 | 回線予約装置および方法、回線予約受付装置および方法 |
| JP3145874B2 (ja) * | 1994-09-06 | 2001-03-12 | 日本電気株式会社 | 仮想パス設定装置 |
| AU720173B2 (en) * | 1995-03-08 | 2000-05-25 | British Telecommunications Public Limited Company | Broadband switching network |
| JP3085515B2 (ja) * | 1995-07-03 | 2000-09-11 | 日本電信電話株式会社 | 帯域可変通信装置 |
| US5881060A (en) | 1996-05-30 | 1999-03-09 | Northern Telecom Limited | Integrated cellular voice and digital packet data telecommunications systems and methods for their operation |
| US6058114A (en) * | 1996-05-20 | 2000-05-02 | Cisco Systems, Inc. | Unified network cell scheduler and flow controller |
| JP3436845B2 (ja) * | 1996-06-18 | 2003-08-18 | 日本電信電話株式会社 | マルチクラスａｔｍ呼受付制御方法及び装置 |
| JP3492466B2 (ja) * | 1996-06-20 | 2004-02-03 | 日本電気株式会社 | 帯域可変制御方法 |
| US6049549A (en) * | 1997-08-14 | 2000-04-11 | University Of Massachusetts | Adaptive media control |
| US6169740B1 (en) * | 1997-10-30 | 2001-01-02 | Nortel Networks Limited | Method of and apparatus for virtual link management |
| CA2233491A1 (en) * | 1998-03-30 | 1999-09-30 | Newbridge Networks Corporation | Atm adaption layer traffic scheduling |
| US6272131B1 (en) * | 1998-06-11 | 2001-08-07 | Synchrodyne Networks, Inc. | Integrated data packet network using a common time reference |
| US6580721B1 (en) * | 1998-08-11 | 2003-06-17 | Nortel Networks Limited | Routing and rate control in a universal transfer mode network |
| US6801943B1 (en) * | 1999-04-30 | 2004-10-05 | Honeywell International Inc. | Network scheduler for real time applications |
| US6876668B1 (en) * | 1999-05-24 | 2005-04-05 | Cisco Technology, Inc. | Apparatus and methods for dynamic bandwidth allocation |
-
1999
- 1999-07-15 ES ES99113820T patent/ES2394623T3/es not_active Expired - Lifetime
- 1999-07-15 EP EP99113820A patent/EP1069736B1/en not_active Expired - Lifetime
- 1999-07-15 ES ES09005702.7T patent/ES2557892T3/es not_active Expired - Lifetime
- 1999-07-15 EP EP09005702.7A patent/EP2109265B1/en not_active Expired - Lifetime
-
2000
- 2000-07-10 IL IL14751300A patent/IL147513A0/xx active IP Right Grant
- 2000-07-10 JP JP2001511039A patent/JP4662670B2/ja not_active Expired - Lifetime
- 2000-07-10 AU AU66909/00A patent/AU763220B2/en not_active Expired
- 2000-07-10 WO PCT/EP2000/006526 patent/WO2001006714A1/en active Search and Examination
- 2000-07-10 HU HU0201961A patent/HU229717B1/hu unknown
- 2000-07-13 US US09/615,446 patent/US6728270B1/en not_active Expired - Lifetime
-
2002
- 2002-01-08 IL IL147513A patent/IL147513A/en unknown
-
2004
- 2004-03-09 US US10/796,600 patent/US7457243B2/en not_active Expired - Lifetime
-
2006
- 2006-11-26 IL IL179576A patent/IL179576A/en active IP Right Grant
-
2007
- 2007-07-09 JP JP2007179432A patent/JP4964046B2/ja not_active Expired - Lifetime
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07254906A (ja) * | 1994-03-16 | 1995-10-03 | Mitsubishi Electric Corp | 優先処理機能を有するシフトレジスタ、それを用いたパケット通信用スイッチング装置及びそれを用いたａｔｍネットワーク並びに優先処理を伴うパケット通信方式及び優先処理を伴うａｔｍ通信方式 |
| JPH09168031A (ja) * | 1995-12-15 | 1997-06-24 | Hitachi Ltd | パケット送出に関する実時間スケジューリング方法 |
| JPH10229404A (ja) * | 1997-02-14 | 1998-08-25 | Nippon Telegr & Teleph Corp <Ntt> | セルスイッチ |
| JPH10276221A (ja) * | 1997-03-25 | 1998-10-13 | Internatl Business Mach Corp <Ibm> | セル伝送のスケジューリング方法および装置 |
| JPH10322338A (ja) * | 1997-05-14 | 1998-12-04 | Nippon Telegr & Teleph Corp <Ntt> | Ａｔｍブロック転送ノード |
Also Published As
| Publication number | Publication date |
|---|---|
| US20040170198A1 (en) | 2004-09-02 |
| HUP0201961A2 (en) | 2002-10-28 |
| HU229717B1 (en) | 2014-05-28 |
| JP2003505931A (ja) | 2003-02-12 |
| US6728270B1 (en) | 2004-04-27 |
| IL147513A0 (en) | 2002-08-14 |
| EP2109265B1 (en) | 2015-09-30 |
| IL179576A (en) | 2007-10-31 |
| EP1069736A1 (en) | 2001-01-17 |
| AU6690900A (en) | 2001-02-05 |
| WO2001006714A1 (en) | 2001-01-25 |
| ES2557892T3 (es) | 2016-01-29 |
| IL147513A (en) | 2007-05-15 |
| JP4964046B2 (ja) | 2012-06-27 |
| AU763220B2 (en) | 2003-07-17 |
| EP1069736B1 (en) | 2012-09-05 |
| US7457243B2 (en) | 2008-11-25 |
| EP2109265A1 (en) | 2009-10-14 |
| JP2007312413A (ja) | 2007-11-29 |
| ES2394623T3 (es) | 2013-02-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4662670B2 (ja) | パケット・データ・トラヒックのスケジューリング及び受入れ制御 | |
| EP1796332B1 (en) | Token bucket dynamic bandwidth allocation | |
| US6839767B1 (en) | Admission control for aggregate data flows based on a threshold adjusted according to the frequency of traffic congestion notification | |
| US7327681B2 (en) | Admission control method in internet differentiated service network | |
| JP4474192B2 (ja) | ネットワークにおけるサービス品質の暗黙的弁別のための方法及び装置 | |
| JP4058326B2 (ja) | 無線基地局、制御装置、無線通信システム及び通信方法 | |
| CA2168485C (en) | A delay-minimizing system with guarenteed bandwidth delivery for real-time traffic | |
| KR100592907B1 (ko) | 큐오에스를 향상시키기 위한 무선 인터넷 단말 장치 및패킷 전송 방법 | |
| Vogt et al. | HeiRAT-quality-of-service management for distributed multimedia systems | |
| JP2005513917A (ja) | 異なる品質を有するアプリケーションのデータの伝送方法 | |
| US9043468B2 (en) | Method and arrangement for network resource management | |
| EP1376948A1 (en) | Quality of service scheduling for packet switched data services | |
| US20050052997A1 (en) | Packet scheduling of real time packet data | |
| Baumgartner et al. | Differentiated Services: A new approach for Quality of Service in the Internet | |
| JP4272322B2 (ja) | 情報廃棄方法および情報廃棄装置 | |
| KR20110012115A (ko) | 무선 통신망에서의 실시간 트래픽 ＱｏＳ 보장을 위한 프레임 전달 방법 | |
| JP2004166080A (ja) | パケットシェーパ、パケット中継装置 | |
| Nahrstedt | Quality of service in networked multimedia systems | |
| Barretta et al. | Integrate Dynamic Service Classes for Real Time Multimedia Communication on Cellular IP Environment | |
| Prasad et al. | Quality of Service | |
| JP2004080523A (ja) | パケット中継装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070709 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090924 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20091218 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20100106 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20100122 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20100129 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100223 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100511 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100810 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20101207 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110104 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4662670 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140114 Year of fee payment: 3 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |