JP5632486B2 - 通信ネットワークにおいて伝送をスケジューリングする方法、対応する通信ノード及びコンピュータプログラム製品 - Google Patents

Description

本開示は、通信ネットワークにおいてデータ伝送をスケジューリングするための技術に関する。この開示は、ポイントツーマルチポイントの通信ノードにおいて、ボイス・オーバー・アイピー（ＶｏＩＰ）・データストリームのデータパケットをスケジューリングする際に使用できることに留意して開発された。

関連技術の説明
インターネットは当初、信頼できるパケット転送を念頭において設計された。事実、プロトコルスタックの全ての下位層は、例えばシーケンス番号、タイムアウト、チェックサム（巡回冗長検査等）、前方誤り訂正（ＦＥＣ）、自動再送要求（ＡＲＱ）等の、信頼できる通信を保証するためのメカニズムを含んでいる。これは、インターネットがまずはコンピュータデータネットワークであると考えられており、コンピュータデータの正確さ及び保全性がキー属性であるためである。

昨今、インターネットは、グローバルなマルチサービスのインフラストラクチャとして定着しており、リアルタイムサービスを絶えず支えている。ボイス・オーバー・アイピー（ＶｏＩＰ）等のパケット化された音声は、最も重要な新興のインターネット用リアルタイムアプリケーションの１つであり、高度なサービス品質（ＱｏＳ）の解決策を展開するための主要なドライバの役割を果たしている。

保全性と同程度にタイムラインが重要になるリアルタイムのトラフィックが非常に多く存在するにも関わらず、アプリケーションレベル以外では、決定を行うためのパラメータとして時間を実際に使用しているサービス品質（ＱｏＳ）の解決策はほとんどない。これは、２つの遠隔ポイントでグローバルに同期されたクロックを有することは難しいという、歴史的によく知られている、インターネットにわたるクロック同期の問題があるためであろう。

信頼できるクロック同期がないことは、長い測定間隔（数日から数週間）及び高精度が求められる（それゆえ、たとえ小さなクロックスキューであっても極めて有害になる）性能測定では問題になることが多い。最近ではクロック同期が進歩してきており、このような長期間でもミリ秒未満の正確さが達成可能である。しかし、音声による会話は数分間から数時間続くので、わずか数ミリ秒程度の同期誤差が人間の知覚に対して目立った影響を生じることはほとんどない。わずかなミリ秒までの絶対差でクロックの同期を数時間保持するために必要な正確性は、全地球測位システム（ＧＰＳ）チップ等による利用可能な技術を用いて、すでに低コストで達成可能であり、これらは安価ですでに多くのポータブル機器に搭載されているものであるが、同じ結果は、ユニバーサル移動体通信システム（ＵＭＴＳ）ネットワーク（ここでは、はるかに正確な同期がまさに主要な必要条件のひとつである）又は周知のネットワークタイムプロトコルにおいて利用可能なプロプライエタリ・ソリューション（ｐｒｏｐｒｉｅｔａｒｙ ｓｏｌｕｔｉｏｎｓ）によっても達成される。

図１は、典型的なＶｏＩＰシナリオを概略的に示している。２人のユーザＵ１及びＵ２は、通常のネットワークＮ（例えば、インターネット）に接続している２つのユーザ端末ＵＥ１及びＵＥ２を介して通信する。

センダ側（すなわちＵＥ１）では、第１のコンポーネントはエンコーダ１００であり、これは第１のユーザＵ１（すなわち話し手）の音声信号を周期的にサンプリングする。多種多様なエンコーダが利用可能であり、品質及び帯域幅消費間のバランスでトレードオフ点が異なる。エンコーダはサンプルベース又はフレームベースであることが通常である。前者のエンコーダ（例えば、Ｇ．７１１コーデックに基づく）は、個々の音声サンプルを周期的に符号化し、後者のエンコーダ（例えば、Ｇ．７２９コーデックに基づく）は、一定数のサンプルを数ミリ秒の時間ウィンドウ（すなわちフレーム）にグループ化する。そのため、フレームベースのエンコーダは、より高い圧縮率及びより小さいデータレートを達成することが多いが、ただし符号化／復号化の複雑度は上がることが通常である。

音声フレームの生成は、周期的間隔で生じるか、又はより一般的には音声区間検出（ＶＡＤ）によって調整され得る。ＶＡＤは、双方向の会話の単一の（一方向の）ストリームにおいてトークスパート（有音：ｔａｌｋｓｐｕｒｔ）期間及び無音（ｓｉｌｅｎｃｅ）期間が自然に交代することを利用する。無音期間には、音声フレームは、全く生成されないか、又は、低減されたレートで生成されること及び低減されたビット数を用いて生成されることのうちの一方又は双方をされて何らかのコンフォートノイズを聞き手に伝達するかのいずれかである。コンフォートノイズは、会話の当事者が相手の臨場感を得られるようにするもので、ローカルに生成することもできる。例えば、Ｇ．７１１コーデックは、トークスパートの間に１７２バイトのパケットを生成し、無音期間には何も情報を送信しないのが通常である。その一方で、汎欧州デジタル移動電話方式（ＧＳＭ）（登録商標）適応型マルチレート（ＡＭＲ）コーデックは、トークスパートの間に３１バイトのペイロードパケットを生成し、無音期間には０バイトの同期情報又は５バイトのコンフォートノイズパケットのいずれかを生成するのが通常である。

トランスポート、ネットワーク、及び媒体アクセス制御（ＭＡＣ）のヘッダのオーバーヘッドを低減するために、いくつかの音声フレームをマルチプレクサ１０２により同一パケットのペイロードに多重化することもできるが、その代わりに伝送遅延は増大してしまう。これは、冗長性のレベルを上げて、損失を隠蔽するために行うこともできる。音声多重化のレベルも、ネットワーク状況により時間とともに変化する。

最後に、ＶｏＩＰペイロードは、ＲＴＰ／ＵＤＰ／ＩＰパケット等のデータパケット、すなわち、リアルタイム転送プロトコル（ＲＴＰ）を介してアプリケーション層で通信されるパケット、ユーザデータグラムプロトコル（ＵＤＰ）を介してトランスポート層で通信されるパケット、及びインターネットプロトコル（ＩＰ）を介してインターネット層で通信されるパケットにカプセル化される。

レシーバ側（すなわち端末ＵＥ２）では、音声フレームは、デマルチプレクサ１０４により多重分離されてプレイアウトバッファ１０６に供給される。プレイアウトバッファ１０６は、音声フレームがエンコーダによる生成時と同一の間隔で復号されるようにする。そのため、予想再生時刻より後に音声フレームが到達すると、音声フレームの並べ替え（ｒｅ−ｏｒｄｅｒ）、遅延、又はドロップすらも必要になることがある。

プレイアウトバッファは、固定型又は適応型である。固定型バッファは、ネットワーク遅延は会話の間は不変であると見なすので、一定量の時間でトークスパートの第１のパケットを遅延させる。適応型バッファは、プレイバック点（ｐｌａｙｂａｃｋ ｐｏｉｎｔ）を変化しているネットワーク状況に動的に適応させるよう努めるものであり、通常はトークスパート毎の単位で行われる（ただし、スプリアス周波数の影響を生じるというリスクを負って、トークスパート内のプレイアウト遅延を変動させるものもある）。

プレイアウトバッファは、音声フレームをデコーダ１０８に配送し、これが実際にそれらをユーザＵ２（すなわち聞き手）に対してプレイバックする。いくつかのデコーダは、パケット損失の隠蔽（ＰＬＣ）法を実施し、これにより、正しく受信された周囲のフレームを補間することにより紛失した音声フレームをいくらか再構築することができる。ＰＬＣ法は、限定数の損失しかマスキングすることができないが、聞き手に感知されるような損失による劣化を効率的に低減する。

ＶｏＩＰによる会話の品質の評価は、広範な調査の対象になっている。もっとも広く用いられるＶｏＩＰの評価フレームワークは、いわゆるＥモデルであり、これは国際電気通信連合（ＩＴＵ）の電気通信標準化部門（ＩＴＵ−Ｔ）により標準化されたものである。この評価フレームワークは、パケット化された音声の主観的品質の予測評価を伝送パラメータから計算することを含む。

Ｅモデルの計算の出力は、「Ｒ要因」と呼ばれるスカラ数であり、遅延要因、パケット損失要因、装置劣化要因、及びユーザによる呼の品質に対する期待（ｕｓｅｒ ｑｕａｌｉｔｙ ｃａｌｌ ｅｘｐｅｃｔａｔｉｏｎ）の関数として計算される。

Ｒ＝Ｒ_０−Ｉ_ｓ−Ｉ_ｄ−Ｉ_{ｅ，ｅｆｆ}＋Ａ （１）
ここでＲ_０は、基本信号対ノイズ比（回線ノイズ及び音響ノイズに対する受信音声レベル）であり、Ｉ_ｓは音声信号と共に発生する劣化であり、Ｉ_ｄは遅延及びエコーの影響による全ての劣化の合計であり、Ｉ_{ｅ，ｅｆｆ}は、実効装置劣化要因であって、コーデック及び、ランダムなパケット損失に対するその耐性を考慮するものである。

さらに、Ａは採用されている技術に対するユーザの期待をモデル化する「ボーナス」要因である。例えば、Ａの値は、古典的な回線交換ネットワークよりも衛星ネットワークにおける方が大きいが、これは衛星ネットワークへのユーザの期待が、有線ネットワークよりも低いからである。Ａ要因の典型的な幅は、［０，２０］であり、ＩＴＵにより提案されている例示的な値を下記のテーブルに記す。

最後にＩ_{ｅ，ｅｆｆ}は、
Ｉ_{ｅ，ｅｆｆ}＝Ｉ_ｅ＋（９５−Ｉ_ｅ）・Ｐ_ｐｌ／（Ｐ_ｐｌ＋Ｂ_ｐｌ） （２）
のように計算され、ここでＩ_ｅは装置劣化要因であり、これは低ビットレートのコーデックの振る舞いを特徴づけるために用いられ、Ｐ_ｐｌはパケット損失の確率であり、Ｂ_ｐｌはコーデックのパケット損失頑健性要因である。

Ｒ要因が取得されると、それは推定される平均オピニオン評点（ＭＯＳ）に直接マッピングされる。例えば、ＩＴＵ−Ｔ Ｇ１０７の仕様書（ＩＴＵ−Ｔ勧告Ｇ．１０７（０４−２００９）、「Ｅモデル、伝送計画のための計算モデル“Ｔｈｅ Ｅ−ｍｏｄｅｌ， ａ ｃｏｍｐｕｔａｔｉｏｎａｌ ｍｏｄｅｌ ｆｏｒ ｕｓｅ ｉｎ ｔｒａｎｓｍｉｓｓｉｏｎ ｐｌａｎｎｉｎｇ”」）には、Ｒ要因とその推定されるＭＯＳとの間の可能な関係が記載されている。平均オピニオン評点は、このようにして体感品質（ＱｏＥ）又はＱｏＳの解決策の向上のために用いることができる。このような最適化は、ＱｏＥが測定されるアプリケーションレベルで実行されるのが通常である。

例えば、Ｌ．Ａｔｚｏｒｉ、Ｍ．Ｌ．Ｌｏｂｉｎａ、及びＭ．Ｃｏｒｏｎａによる論文である、“Ｐｌａｙｏｕｔ ｂｕｆｆｅｒｉｎｇ ｏｆ ｓｐｅｅｃｈ ｐａｃｋｅｔｓ ｂａｓｅｄ ｏｎ ａ ｑｕａｌｉｔｙ ｍａｘｉｍｉｚａｔｉｏｎ ａｐｐｒｏａｃｈ”， ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｍｕｌｔｉｍｅｄｉａ，Ｖｏｌ．８ Ｎｏ．２， ｐａｇｅｓ ４２０−４２６， ２００６は、これからのトークスパート（ｉｎｃｏｍｉｎｇ ｔａｌｋｓｐｕｒｔ）のプレイアウト遅延を予測するために、最適なプレイアウトバッファをレシーバにおいて使用することを提案している。詳細には、次のトークスパートのためのプレイアウト時点（ｐｌａｙｏｕｔ ｉｎｓｔａｎｔ）が、最後のＮ個のトークスパートの品質を最大にしたであろうものに設定される。

さらに、Ａ．Ｂａｃｉｏｃｃｏｌａ、Ｃ．Ｃｉｃｃｏｎｅｔｔｉ、及びＧ．Ｓｔｅａによる論文である、“Ｕｓｅｒ ｌｅｖｅｌ ｐｅｒｆｏｒｍａｎｃｅ ｅｖａｌｕａｔｉｏｎ ｏｆ ＶｏＩＰ ｕｓｉｎｇ ｎｓ−２”， Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＮＳＴＯＯＬＳ’０７， Ｆｉｒｓｔ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｎｅｔｗｏｒｋ Ｓｉｍｕｌａｔｉｏｎ Ｔｏｏｌｓ， Ｎａｎｔｅｓ （ＦＲ，Ｏｃｔｏｂｅｒ ２２， ２００７には、可能な最適再生アルゴリズムが記載されている。

Ｚ．Ｑｉａｏ、Ｌ．Ｓｕｎ、Ｎ．Ｈｅｉｌｅｍａｎｎ、及びＥ．Ｉｆｅａｃｈｏｒによる、“Ａ ｎｅｗ ｍｅｔｈｏｄ ｆｏｒ ＶｏＩＰ ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ ｃｏｎｔｒｏｌ ｕｓｅ ｃｏｍｂｉｎｅｄ ａｄａｐｔｉｖｅ ｓｅｎｄｅｒ ｒａｔｅ ａｎｄ ｐｒｉｏｒｉｔｙ ｍａｒｋｉｎｇ”， ＩＥＥＥ ＩＣＣ ２００４， Ｐａｒｉｓ， Ｆｒａｎｃｅ， Ｊｕｎｅ ２０−２４， ｐａｇｅｓ １４７３−１４７７では、ＧＳＭ−ＡＭＲコーデックのレートを適応させて、送信レートを現在のネットワーク状況に適応させるためのＱｏＳ制御スキームが提案されている。この適応は、ＶｏＩＰデコーダによって測定されるＭＯＳに基づき、ＶｏＩＰデコーダは、リアルタイム制御プロトコル（ＲＴＣＰ）メッセージを介して、フィードバック情報をＶｏＩＰエンコーダに報告する。

本発明の目的及び概要
本発明の発明者は、フィードバック情報に基づくアプリケーションレベルにおけるＱｏＥの最適化にはいくつかの欠点があることに注目した。例えば、このようなフィードバックベースの技術はアプリケーションを過度に複雑化し、そして同期を必要とするか、又はラウンドトリップタイムに頼るかのいずれかであるが、ラウンドトリップタイムは対称ではないので片道遅延よりもはるかに不正確である。

したがって、このような欠点を解決し、例えば、集中型の（有線又は無線）ポイントツーポイントネットワークにおいてダウンリンクの音声フローをスケジューリングする際に、ネットワーク資源の効果的な割り当てを可能にする、改善された解決策の必要性が感じられる。

本発明によれば、本発明の目的は、以下に記す請求項に記載の特徴を有する方法によって達成される。本発明はさらに、対応する通信ノード及び、コンピュータプログラム製品に関し、プログラム製品は、少なくとも１つのコンピュータのメモリにロード可能であって、コンピュータ上で実行される場合に本発明の方法のステップを行うためのソフトウェアコード部分を含む。本明細書では、そのようなコンピュータプログラム製品への言及は、コンピュータシステムを制御して本発明の方法の実行を調整させるための命令を備えるコンピュータ可読媒体への言及に等しいものとする。「少なくとも１つのコンピュータ」への言及は、本発明が分散／モジュール方式で実装される可能性を強調することを意図している。

請求項は、本明細書で規定される本開示の不可欠な部分である。
本明細書に記載のさまざまな実施形態は、通信ノード（例えば、基地局）からレシーバ（例えば、移動体端末）に向けたデータストリームの伝送をスケジューリングするために用いられ、データパケットは、レシーバの復元バッファを介してのプレイアウトのためのものである。

さまざまな実施形態において、データパケットは、ノードにおいてスケジューリングキュー内に配置され、そしてキューにおける該データパケットの滞在時間が所与のドロップの期限を超えた場合に、スケジューリングキューからドロップされる。

さまざまな実施形態において、レシーバの復元バッファは、データパケットの個々の予想プレイアウト時点を求めるために、ノードでエミュレートされる。続いて、データパケットのドロップの期限が、ノードでエミュレートされた通りに復元バッファを介して求められた個々の予想プレイアウト時点の関数として、データパケットに割り当てられる。

さまざまな実施形態は、例えばＵＭＴＳロング・ターム・エボリューション（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ：ＬＴＥ）又はハイスピード・ダウンリンク・パケット・アクセス（Ｈｉｇｈ−Ｓｐｅｅｄ Ｄｏｗｎｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ：ＨＳＤＰＡ）を含むセルラーネットワーク等の、いくつかのアクセス技術に適用することができる。

さまざまな実施形態は、これらのセルラーネットワーク技術において、絶対時刻が帯域外ネットワーク同期手続きを介して通常は既知である、という認識に依存している。
さまざまな実施形態は、絶対時刻の参照が付加されると、ＭＡＣレベルでの集中型制御を有するブロードバンド無線ネットワークにおいて適用することもでき、この集中型制御は、例えば、８０２．１１ｅ ハイブリッドコーディネーション機能（Ｈｙｂｒｉｄ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ：ＨＣＦ）集中制御アクセス（Ｃｅｎｔｒａｌｉｚｅｄ Ｃｏｎｔｒｏｌ Ａｃｃｅｓｓ：ＨＣＣＡ）、８０２．１６、又はＴＤＭＡシステム（例えば、微調整されたＴＤＭＡドライバを有する８０２．１１ ＷＬＡＮ）である。

さまざまな実施形態は、中央のスイッチがデータパケットをクライアントに送信する有線ネットワークに適用することも可能である。
さまざまな実施形態は、平均オピニオン評点（ＭＯＳ）は通信ネットワークレベルで直接使用することができる、という認識に依存する。

さまざまな実施形態は、ダウンリンクフローに適用され、このダウンリンクフローは、エンドツーエンドパス（ここにアプリケーション部分が含まれる）のダウンストリームセグメントの（損失及び遅延）振る舞いの予測に依存する。

さまざまな実施形態は、例えば、ＲＴＰタイムスタンプの形式等の（絶対）タイムスタンプに基づいて、クロスレイヤ（ｃｒｏｓｓ−ｌａｙｅｒ）方式でスケジューリングの決定を行うものであり、この（絶対）タイムスタンプは、データソースでデータパケットに導入される。このような絶対タイムスタンプは、ＧＰＳ同期、ＵＭＴＳネットワーク同期、ネットワークプロトコル及びタイムサーバのうちの１以上を含む多様な手段により得ることができる。

さまざまな実施形態は、ポイントツーマルチポイントネットワーク（例えば、ＬＴＥ若しくはＵＭＴＳセル、又はＴＤＭＡネットワーク）、すなわち、ネットワーク資源が複数のユーザ又は端末間で共有されている通信ネットワークにおいて、ダウンリンクフローをスケジューリングするために、絶対時刻を活用する。

本明細書に示す例示的な実施形態は主としてダウンリンクの音声フローに関し、それにおいては、
−損失及び遅延等の（客観的な）エンドツーエンドネットワークレベルの測定値からユーザが感知した（主観的）品質を推定するための確立した手段、すなわちＥモデル又は平均オピニオン評点（ＭＯＳ）があり、かつ
−レシーバ側（詳細には、レシーバ側のプレイアウトバッファリング機構）における音声アプリケーションの振る舞いは、極めて予測可能であるため、音声レシーバの損失及び遅延への（無視できない）寄与を推測することが可能である。

当業者であれば、さまざまな実施形態は、ビデオストリーム等の他のリアルタイムトラフィックストリームにも応用できることが理解できるであろう。そのために、ビデオトレース（ｖｉｄｅｏ ｔｒａｃｅ）のためのＥモデルに類似のフレームワークを開発することができる。

さまざまな実施形態では、各パケットには、想定又は予想のプレイバック時点（ｐｌａｙｂａｃｋ ｉｎｓｔａｎｔ）と等しい期限が割り当てられる。そうすることにより、遅れたパケット、すなわちレシーバでドロップされることになるものを、スケジューラで直接ドロップすることができるので、帯域幅を節約し、かつネットワーク資源の割り当てを最適化できる。

さまざまな実施形態では、スケジューラは、早いパケットを該パケットの実際のプレイバック点まで遅延させることもでき、ユーザの知覚に影響を与えることもないので、より切迫した期限を有するパケットが遅れずにレシーバに配送される見込みが高くなる。

さまざまな実施形態では、レシーバにおけるプレイバック点は、単純化されたレシーバ及びプレイアウトバッファ（「復元バッファ」）のうちの一方又は双方をコネクションのためにエミュレートすることにより推定される。

例えば、ＶｏＩＰストリームの場合であれば、単純化された適応プレイアウトバッファ、すなわちプレイバック点が各トークスパートで動的に変動するようなバッファ、もエミュレートすることができる。例えば、トークスパートの終わりで、計算により、最適事後的なプレイバック時点、すなわち、そのトークスパートの最も高いＭＯＳを保証したであろうもの、を推測することが可能である。次に、それらの最適なプレイバック時点の履歴が、後続のトークスパートの新しい想定されるプレイバック時点を推測するために用いられる。

さまざまな実施形態では、最適なプレイバック時点を事後的に計算するために、Ｅモデルの式が用いられる。これらは、口から耳への遅延（ｍｏｕｔｈ−ｔｏ−ｅａｒ ｄｅｌａｙ）を考慮しており、この口から耳への遅延は、パケット生成時刻及び（想定される）再生時刻をクロック同期に基づいて求めることができるならば、計算することができる。そのような理由により、パケットは正確なクロックからサンプリングされた絶対時刻を有するソースアプリケーションでタイムスタンプすることができ、スケジューラは、パケットがレシーバに配送されるときに正確な絶対クロックを再び読むことにより、絶対時刻を知ることができる。さまざまな実施形態では、ＲＴＰプロトコル、特にＲＴＰタイムスタンプフィールド、がこのような目的のために用いられる。例えば、ＲＴＰヘッダはパケットにつき２回読まれることがある。すなわち、パケット到着時の、シーケンス番号及びパケットタイムスタンプをパケット期限を計算するために用いることがあるときと、パケットの送出時の、スケジューラが、ウォールクロックタイム（すなわち、パケットがスケジューラのキューを離れた時である絶対時刻）をパケットのタイムスタンプと比較することにより口から耳への遅延を推定することがあるときとである。

本明細書に記載の実施形態は、いくつかの利点を有する。それは例えば以下のようなものである。
−復元バッファエミュレーションの空間コストは非常に手頃であり、実装フレームワーク全体で必要とするのはフローにつき通常１００バイト未満であることから、廉価である。
−各フローには一定数のオペレーションが必要とされるのが通常であることから、時間オーバーヘッドを無視できる。
−最も複雑な計算（すなわち、最適事後的なプレイバック時点の計算）にほんの少しのメモリアクセスしか必要としないのが通常であり、無音期間すなわち数百ミリ秒の間に完了する。
−結果として生じる構成が頑健である。かなり粗いクロック誤差（＋−１０ミリ秒程度）であっても許容され、また感知できるほどの品質の劣化もない。そのため一時的な同期の損失は（長時間であっても）スケジューリングのプロセスに影響を与えることがほとんどない。
−結果として生じる構成は、例えば周知のアーリエスト・デュー・デート（Ｅａｒｌｉｅｓｔ Ｄｕｅ Ｄａｔｅ：ＥＤＤ）等の任意の期限ベースのスケジューラ、又はユーザ依存型及び時間依存型チャネル状況の無線ネットワークであれば、期限及びチャネル状態の両方を考慮するスケジューラと協働することができる。
−フレームワークは、とりわけ次のような条件に合う通信シナリオを含む多様な通信技術に適用することができる。
ａ）パケットソース及びスケジューリングノードが（例えば、ＧＰＳを通じて）同期される。
ｂ）各パケットがタイムスタンプを含む。
ｃ）スケジューリングコンポーネントが、到着時のパケットタイムスタンプ及び送出時の絶対時刻を読むことができる。
ｄ）パスのダウンストリームセグメントのみが、プレイアウトバッファに加えて、追加的な遅延であってオンラインで測定可能なもの（例えば、Ｈ−ＡＲＱ再送による遅延）及び推定可能なもの（例えば、伝搬遅延及び処理遅延）のうちの一方又は双方を含む。

したがって、さまざまな実施形態は、上述した前提のもと、調整されたポイントツーマルチポイントスケジューリングを有する任意のアクセスネットワークに実装することができる。

本発明を添付図面を参照して記載するが、これはほんの一例である。
図１は、すでに上述した。 図２は、例示的な通信シナリオを示す。 図３は、一実施形態のブロック図である。 図４は、一実施形態のオペレーションのタイミング図である

以下の記載には、実施形態の完全な理解を提供するために多数の特定の詳細が含まれている。実施形態は、１又は複数のこれらの特定の詳細を用いずに実施してもよいし、あるいは他の方法、コンポーネント、材料等を用いて実施してもよい。また、周知の構造、材料、又は動作を詳細に表示又は記載していないのは、実施形態の態様が曖昧にならないようにするためである。

本明細書全体において、「一実施形態」又は「一つの実施形態」への言及は、その実施形態に関して記載された特定の特徴、構造、又は特性が少なくとも１つの実施形態に含まれていることを意味する。したがって、「一実施形態では」又は「一つの実施形態において」という語句が本明細書全体を通じ随所に現れるが、それらが全て同一の実施形態を指しているわけではない。さらに、特定の特徴、構造、又は特性は、１又は複数の実施形態において任意の適宜の方法で組み合わせてもよい。

本明細書において、見出しは便宜上記載しただけであり、実施形態の範囲又は意味を説明するものではない。
図２は例示的な通信シナリオを示しており、データパケット内で整理された音声ストリームが、ＲＴＰプロトコルを用いて２つのＬＴＥモバイル機器ＵＥ１及びＵＥ２の間で伝送される。

考慮される実施形態では、第１のモバイル機器ＵＥ１が、通信ネットワークＮを介してモバイル機器ＵＥ２が関連付けられている基地局ＢＳ（すなわち、ＬＴＥネットワークにおけるｅＮｏｄｅＢ）にデータを送信する。

各データパケットはｎ個の音声フレームを含むことができ、各パケットはｍ個のプロトコルデータユニット（ＰＤＵ）を介して送信することができる。さらに、ｍの値はコネクションによって異なることがあり、かつ、時とともに、例えばＨ−ＡＲＱプロセスからのフィードバックが再送の数が大きく増加／低減したことを示す時に、変化することができる。ｍの値は設定時に固定して事前設定してもよい。

本説明の理解を促進するために、初めにいくつかの単純化した仮定を行う。ただし説明を読み進めれば、このような仮定は全く必須ではないことが明らかであろう。詳細には、各ＲＴＰパケットは１つの音声フレームのみを含み、かつ音声パケットはｅＮｏｄｅＢで分割されず、それゆえ、１つのＰＤＵが１つの音声フレームを搬送すると仮定する。

考慮される実施形態では、パケットは、作成時のフレーム生成時刻でタイムスタンプされる。ここでｇ_ｉ，ｋはｉ番目のトークスパートのｋ番目のパケットの生成時刻であり、ｉ，ｋ≧０であり、ａ_ｉ，ｋはｅＮｏｄｅＢにおける到着時刻である。

パケットは、ネットワークＮにおける可変遅延を蓄積することがあり、また、いくつかのパケットは、シーケンスからドロップされること及びシーケンスから外れて配送されることのうちの一方又は双方がある。

図３は、本発明に従った基地局ＢＳの可能な実装のブロック図を示す。
考慮される実施形態では、パケットが基地局ＢＳに時刻ａ_ｉ，ｋに到着する場合、それらには制御モジュール２００で期限ｄ_ｉ，ｋが割り当てられる。割り当てられた期限ｄ_ｉ，ｋを有し、制御モジュール２００から出たパケットは、次に、スケジューラＳによりスケジューリングされ、スケジューラＳは、該パケットの期限を考慮して、パケットを、ｅＮｏｄｅＢキューにおける該パケットの滞在時間が期限ｄ_ｉ，ｋを超えた場合にドロップすることができる。なぜなら、これらパケットはレシーババッファでドロップされる可能性が高く、したがってこのようなパケットを送信することは無線資源の無駄遣いにすぎないであろうからである。

考慮される実施形態において、スケジューラＳは、それぞれのデータストリームのデータパケットが記憶されている複数のキューＳＱを備える。例えば、キューＳＱは、先入先出（ＦＩＦＯ）メモリを用いて実装される。続いて、スケジューリングモジュールＳＭがどのパケットが伝送又はドロップされるかを決定する。例えば、考慮される実施形態では、パケットのスケジューリングされた伝送時刻ｔ_ｉ，ｋがパケットの期限ｄ_ｉ，ｋを超えるとき、すなわちｔ_ｉ，ｋ＞ｄ_ｉ，ｋの場合にパケットはドロップされる。

さまざまな実施形態では、スケジューラＳにより時刻ｔ_ｉ，ｋに伝送されるために選ばれたパケットは、Ｈ−ＡＲＱプロセスにより処理され、測定可能な遅延ｄｌ_ｉ，ｋの後、モバイル機器ＵＥ２でプレイアウト可能になる。

考慮される実施形態では、遅延ｄｌ_ｉ，ｋは、そのパケットの可能なＨ−ＡＲＱ再送、並びに、通常は実質的に一定である無線インターフェース及びモバイルノードにおける物理遅延の推定を含む。

さまざまな実施形態では、推定される遅延ｄｌは、次のように設定される。
ｄｌ＝Ｔ_ｐｒｏｃ＋Ｔ_ｏｗ＋（ｍ−１）・Ｔ_{Ｈ−ＡＲＱ} （３）
ここで、Ｔ_ｐｒｏｃは、レシーバの物理層及びＭＡＣ層における処理遅延の推定を表す。Ｔ_ｏｗは、ダウンリンクセグメントを介してＰＤＵを送信するための時間（すなわち、Ｈ−ＡＲＱプロセスからパケットをレシーバへ配送するのにかかる時間であり、そこにＡＣＫ／ＮＡＣＫの生成及び報告は含まれない）であり、Ｔ_{Ｈ−ＡＲＱ}はＨ−ＡＲＱ伝送サイクルのための時間であり、ｍは、パケットのための考慮される伝送数である。

遅延ｄｌ_ｉ，ｋに加えて、音声サンプルが時刻ｐ_ｉ，ｋにプレイアウトされる前にパケットが受ける唯一のさらなる遅延は、レシーバにおけるプレイアウトバッファのものである。

したがって、レシーバのプレイアウトバッファへの到着時刻ｑ_ｉ，ｋは、
ｑ_ｉ，ｋ＝ｔ_ｉ，ｋ＋ｄｌ_ｉ，ｋ （４）
であり、ネットワーク全体でのフレームｉの遅延は、次のように定められる。

δ_ｉ，ｋ＝ｑ_ｉ，ｋ−ｇ_ｉ，ｋ （５）
さまざまな実施形態では、δ_ｉ，ｋのシーケンスは、エミュレートされたプレイアウトバッファＢに入力として与えられ、期限ｄ_ｉ，ｋを求めることが可能になる。詳細には、エミュレートされた最適なプレイアウトバッファＢは、モバイル機器ＵＥ２のプレイアウトバッファをエミュレートし、その目的は、最適なプレイアウト時点ｐｏ_ｉは何であればよかったか、つまり、そのトークスパートの最も高いＭＯＳを保証したであろうものを、事後的に（すなわち、トークスパートｉの終了後に）特定することである。

考慮される実施形態では、期限ｄ_ｉ，ｋは次のように計算される。
ｄ_ｉ，ｋ＝ｐｏ_ｉ−（ａ_ｉ，ｋ−ｇ_ｉ，ｋ）−ｄｌ （６）
ｐｏ_ｉは、レシーバでのｉ番目のトークスパートの推定プレイアウト遅延であり、プレイアウト遅延は、トークスパート中の首尾よく再生された任意のパケットの生成時刻とプレイアウト時刻との間隔として定められる。そしてｄｌは、レシーバにおける無線インターフェース及び処理（プレイアウトバッファにより生成されるもの以外）による遅延の推定である。

そして、過去の最適なプレイアウト遅延ｐｏ_ｉ、０≦ｊ≦ｉの履歴が用いられて、これからのトークスパートの新しいプレイアウト遅延ｐｏ_ｉ＋１が推測される。
さまざまな実施形態では、非因果的な最適再生アルゴリズムが用いられる。より詳細には、さまざまな実施形態では、プレイアウトバッファは、所与のトークスパートのフレームの全ての組がスケジューラに到着して伝送（又はドロップ）されるのを待ち、それから、それに従えば最善の音声品質が達成されたであろう再生遅延を―到着、伝送、及びドロップのパターンに基づいて―選択する。このような最適なプレイアウトバッファを含むことの目的は、巧妙な応用プレイアウトバッファリングアルゴリズムがすることを予測するためである。例えば、これは、早いパケットを遅延させること及びプレイアウトされる可能性の低いパケットをドロップすることのうちの一方又は双方を可能にする。

さまざまな実施形態では、制御モジュール２００及びエミュレートされたバッファＢはソフトウェアコード部分を用いて実装され、これは基地局ＢＳのプロセッサにより実行される。しかし、これらのモジュールは、専用デジタル回路の形で実装されてもよい。

図４は、等しい時間差Ｐで時点ｇ_ｉ，１、ｇ_ｉ，２、ｇ_ｉ，３、ｇ_ｉ，４、及びｇ_ｉ，５において生成される５つのＶｏＩＰフレームを有するトークスパートの伝送フェーズ４００、バッファリングフェーズ４０２、及びプレイアウトフェーズ４０４を含む例示的なシナリオを示す。

考慮される実施形態では、トークスパートｉのｋ番目のフレームは時刻Ｐ_ｉ，ｋにデコーダに（事実上）伝えられる、すなわち、プレイアウトされる。そして実際に再生されるトークスパートの全パケットについてのプレイアウト遅延ｐｏ_ｉは、実際に再生されるｋ、ｊのそれぞれについて一定、すなわちｐ_ｉ，ｋ−ｐ_ｉ，ｊ＝ｇ_ｉ，ｋ−ｇ_ｉ，ｊであるとする。

一般性を失うことなしに、ネットワークにより失われた各フレームｉについて、ｑ_ｉ，ｋ＝∞と仮定することができる。同様に、レシーバのプレイアウトバッファは、非常に遅れて受信された全てのフレーム、すなわちδ_ｉ，ｋ＞ｐｏ_ｉであるパケットを直接廃棄すると仮定することができ、これはδ_ｉ，ｋ＝ｑ_ｉ，ｋ＝∞である全てのフレームがｐｏ_ｉの値に関係なく廃棄されることを示唆する。プレイアウトバッファにより廃棄されるフレームは、損失率Ｌ_ｉに寄与し、損失率は廃棄されたフレーム数とトークスパート内のフレーム数との比率と定められる。

図４の例では、第１番目以外の全てのフレームが「時間内」に受信されているので、Ｌ_ｉ＝１／５である。
したがって、プレイアウトバッファＢの自由度は、プレイアウト遅延ｐｏ_ｉである。

さまざまな実施形態では、最適なプレイアウト遅延ｐｏ_ｉ ^ｏｐｔ∈｛δ_ｉ，ｋ｝は、ＱｏＳ及びＱｏＥのうちの一方又は双方の基準を考慮するＭＯＳ関数に基づいて求められる。例えば、考慮される実施形態では、ｐｏ_ｉ ^ｏｐｔの値は、Ｒ要因を最大化する可能なプレイアウト遅延として計算される。しかし当業者であれば、最適なプレイアウト遅延ｐｏ_ｉ ^ｏｐｔを計算するために用いられる式は、使用される特定のコーデックに依存することが理解できるであろう。

さまざまな実施形態では、ｐｏ_ｉ ^ｏｐｔの値は、本明細書に記載の式（１）及び（２）を合わせ、Ａｔｚｏｒｉらの論文の劣化Ｉ_ｄ式（２）を用いることにより計算される。

さまざまな実施形態では、式（７）におけるパケット損失の可能性Ｐ_ｐｌは、

で置き換えられる。ここで、Ｎ_ｉはｉ番目のトークスパートのパケットの数（例えば、シーケンス番号を調べることにより測定できる）であり、１_（ｘ）という表記は、ｘが真であれば結果は１であり、そしてそうでない場合は０であることを意味している。したがって、その合計は、ｉ番目のトークスパート内のｐｏ_ｉよりも大きな遅延δ_ｋ，ｉを有するパケット、すなわちネットワーク内でドロップされたもの（つまりδ_ｋ，ｉ＝＋∞）又はプレイアウトバッファ自体においてドロップされたもの（つまりδ_ｋ，ｉ＞ｐｏ_ｉ）のいずれか、の計数になる。

したがって、式（７）は次のように記されてもよい。

当業者であれば、上記の式は、単なる１つの実施例であり、他のＲ要因の計算も用いることができることが理解できるであろう。いずれの場合でも、すでに上述したように、ｐｏ_ｉ ^ｏｐｔはＲ要因を最大化する可能なプレイアウト遅延の値として計算される。

通常は、ＭＯＳはｐｏ_ｉ及びＬ_ｉの非増加関数を介して取得され、またＬ_ｉ自体がｐｏ_ｉの非増加関数である。したがって、トークスパートのＲ要因を最大化させる最適な値ｐｏ_ｉ ^ｏｐｔが存在する。例えば、このような最適な値ｐｏ_ｉ ^ｏｐｔは、トークスパート内の可能なネットワーク遅延の集合｛δ_ｉ，ｋ｝における検索により計算することができる。

したがって、プレイアウトバッファは、プレイバック点をトークスパート毎の単位で設定するので適応型であるが、全ての音声フレームの遅延がプレイバック点を選択する以前に既知でなければならないので、非因果的である。

さまざまな実施形態では、最適なプレイアウトバッファは、次のように用いられる。
−トークスパートｉが終わってから、最適なプレイアウト遅延ｐｏ_ｉ ^ｏｐｔが計算される。
−その後、指数平均（ｅｘｐｏｎｅｎｔｉａｌ ａｖｅｒａｇｅ）を用いて、次のトークスパート（ｉ＋１）について生じ得るプレイアウト遅延を推測する。

ｐｏ_ｉ＋１＝ａ・ｐｏ_ｉ＋（１−ａ）・ｐｏ_ｉ ^ｏｐｔ，ここで０＜ａ＜１ （１１）
−そして、ｐｏ_ｉ＋１は次のトークスパートにおけるパケットの期限を式（６）に従って設定するために用いられる。

このようにして、プレイアウト時点が過去の履歴に基づいて選択される。ただし、第１のトークスパートのプレイアウト遅延の選択という問題が残る。これはその時点では利用できる推定がないためである。この問題を克服するために、デフォルト値が初期値に選択され、ここで初期値は呼のエンドポイントに関する情報にも基づく。例えば、初めのプレイアウト遅延の典型的なデフォルト値は、２００ミリ秒である。さらに、重みパラメータもヒューリスティックに最適化される。

上述したように、ＲＴＰパケットもｎ個の音声フレームを含むことができ。ここでｎ＞１である。
さまざまな実施形態は、ＲＴＰタイムスタンプが第１の（又は最後の）音声フレームの生成時刻を意味するものとする。その場合、各フレームの生成時刻は、例えばコーデック周期（ｃｏｄｅｃ ｐｅｒｉｏｄ）に基づいて計算される。

さまざまな実施形態では、パケットの期限及び廃棄時刻（これまでは等しいものとされていた）は別々であると見なされる。例えば、期限は第１の音声フレームの生成時点に基づいて計算されるが、パケットの廃棄時刻は、最後の音声フレームの、事前に想定されるプレイアウト時点に設定される。つまり、パケットは、なんらかの有益な内容を搬送する限りは伝送される。

したがって、フレームをプレイアウトバッファに挿入するとき、各フレームは正しい生成時刻と関連付けられる。さらに、ＲＴＰパケットがどの程度の大きさであるか、並びに、ＰＤＵ長がどのようにＬＴＥセルに設定されているかに依存して、１つのパケットは、ｅＮｏｄｅＢにおいて、最終的にいくつかのＰＤＵに分割されることになる。この場合、全てのＰＤＵが同一の期限及び廃棄時刻に関連付けられ、パケットのネットワーク遅延がパケットの最後のＰＤＵの伝送時刻に基づいて設定されてもよい。

ネットワークは、パケットをドロップするがそのシーケンスを保存することにはなっていないという事実により、時刻

に基地局ＢＳに到着するトークスパートｉの第１のパケットが、実はｋ_０番目、ここでｋ_０≧０、の可能性がある。
したがって、さまざまな実施形態は、パケットがシーケンス番号を搬送できるようにする。このようにして、スケジューラは他にｋ_０個のパケットが紛失しているとこれらパケットの生成時刻にかかわらずに判定することができる。

さまざまな実施形態では、このように、スケジューラは以前のパケットのネットワーク遅延の下界を、パケットｋ_０の到着時にすぐに計算する。したがって、これらのパケットは、システム内ですでにキューされているパケットよりも早い期限を必然的に有している。

さまざまな実施形態では、スケジューラはＰＤＵを再統合（ｒｅ−ａｌｉｇｎ）しようと試みる。例えば、パケットｋ＜ｋ_０が到着した場合に、関連するＰＤＵは、より後のパケットより先にバッファに配置される。

これは、バッファとしてＦＩＦＯメモリを使用しているスケジューラには実行可能ではないので、関連するＰＤＵは、ＦＩＦＯの順番で配置されるが、式（６）により計算される正しい期限及び廃棄時刻を有することができる。その場合、期限は、同じフローでは非単調に増加していく。しかし、これはスケジューリングに影響するものではなく、また、より後のパケットが期限のかなり前に伝送されれば、該パケットより前のパケットを伝送する余裕が依然としてあり得る。

前述した例示的な解決策は、トークスパートを区別する。全てではないにせよ、ほとんどのコーデックで、パケット生成周期は一定であるので、このようなタスクが容易になる。ＲＴＰパケットは、タイムスタンプ及びシーケンス番号の両方を搬送する。したがって、無音期間には情報を何も生成及び送信しないこれらのコーデックでは、トークスパートのｔｓがｔｓ（ｋ_２）＞ｔｓ（ｋ_１）＋Ｐ・（ｋ_２−ｋ_１）であるものは確実に異なるトークスパートに属するように、シーケンス番号ｋ_１、ｋ_２を持ち生成タイムスタンプを有する連続して基地局ＢＳに到着する任意の２つのパケットを観測することができる。実際の場合には、ジッタ源を考慮するために安全マージン（例えば、一周期）が上述の不等式の右側に追加されてもよい。

それに対し、無音期間は事後的にのみ、すなわち新しいトークスパートが開始するときに、推定しなければならない。これは連続する損失のバーストが無音期間と間違えられるからである。

無音期間にも低減された情報を送信するコーデックについては、無音期間はパケットサイズを調べることにより即座に検出される。
最適なプレイアウト遅延の計算は、ネットワーク遅延をソートして、可能なネットワーク遅延のそれぞれについてＲ要因を計算することにより実行することができる。Ｍ個のパケットがトークスパート内にあると仮定すると、時間のオーバーヘッドＯ（Ｍ）をもたらすことになる。実際の場合には、Ｍは非常に大きな数になるとは予想されないが（トークスパートの長さの平均はおよそ１秒である）、時間のオーバーヘッドは、この仮定によらず制限されてもよい。

例えば、ネットワーク遅延は、かなり粗い分解能、例えば１０ミリ秒、で量子化されてもよく、これによって感知できる程の品質劣化を生じることはないのが通常である。
さらに、可能なネットワーク遅延の全てを記憶するかわりに、限定数であるＢ＋１整数の遅延カウンタが用いられてもよい。

例えばさまざまな実施形態では、カウンタｌ、ここで０≦ｌ≦Ｂ−１、は［ｉ・Ｑ＋Ｃ，（ｉ＋１）・Ｑ＋Ｃ［と等しいネットワーク遅延幅に関連し、Ｑは量子化間隔、Ｃは遅延オフセットであり、後者が既知であれば、パスに沿って固定遅延コンポーネントに設定され得る（又は安全な推定としてＣはゼロに設定されてもよい）。

それに対し、最後のカウンタ、すなわちＢ番目のカウンタは遅延幅［Ｂ・Ｑ＋Ｃ，∞［に関係する。
このようにして、パケットが最適なプレイアウトバッファに到着するときは常に、関係するカウンタが一定時間で増加し、コストはＯ（Ｂ）に低減される。実際のところ、遅延がＱ個のバケットに分割されると（例えば、０から１０ミリ秒の遅延幅を有するバケット、１１から２０ミリ秒の遅延幅を有するバケット、２１から３０ミリ秒の遅延幅を有するバケット等）、所与の遅延を有するパケットの到着が即座に個々のバケットに関連付けされる。したがって、可能な遅延のアレイをスキャンする必要がなく、１つのオペレーションのみが必要とされる。したがって、このオペレーションを実行するために必要な時間は、全ての可能な遅延で一定である。

例えば、量子化間隔が１０ミリ秒、最大遅延が５００ミリ秒に設定されている場合、Ｂは５０になり、これはかなり手頃である。
一般に、バケットの遅延幅は、同一サイズである必要がないこと及び時間とともに変動してもよいことのうちの一方又は双方のことがある。実のところ、特に長距離の呼（ｌｏｎｇ−ｒａｎｇｅ ｃａｌｌ）には、プログレッシブ遅延幅（ｐｒｏｇｒｅｓｓｉｖｅ ｄｅｌａｙ ｒａｎｇｅ）が実行可能な解決策である。

さらに、フローにおけるＱ及びＣの最適な値は、接続が進むにつれて遅延分布を調べることにより動的に推定される。これはさらに、最適なプレイアウト遅延を計算するために必要なオペレーションの量を低減する。

すでに述べたように、本明細書に記載の解決策は、どのＰＤＵを伝送するかを選択するために期限を考慮している任意のスケジューラとともに用いられる。例えば、周知のアーリエスト・デュー・デート（Ｅａｒｌｉｅｓｔ Ｄｕｅ Ｄａｔｅ：ＥＤＤ）アルゴリズムが用いられる。

しかし、移動性が重要な必要条件であってチャネル状況がすぐに変動するセルラーネットワークでは、高度なスケジューラは、モバイルユーザからのチャネル品質フィードバック等の他の情報も考慮する。例えば、ＵＭＴＳハイスピードパケットアクセス（Ｈｉｇｈ Ｓｐｅｅｄ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）のために考案されたハイブリッド・チャネルアウェア・リアルタイム（Ｈｙｂｒｉｄ Ｃｈａｎｎｅｌ−Ａｗａｒｅ ａｎｄ Ｒｅａｌ−Ｔｉｍｅ：ＨＹ−ＣＡＲＴ）スケジューラは、チャネル及び期限情報を混合することにより計算される優先順位に従ってユーザをソートする。このような場合、本明細書に記載した解決策の役割は、意味のある期限を提供することであり、またこれにより、スケジューラでより良い決定を行うことを可能にすることである。

本発明の基本的な原理を侵害することなく、本発明の詳細及び実施形態は、一例として記載されたことに対し、かなり大きな変更であっても添付の請求項で規定される本発明の範囲から逸脱しないかぎりは変更することができる。

Claims (14)

1. 通信ネットワークにおいてノード（ＢＳ）からレシーバ（ＵＥ２）へのデータストリームの伝送をスケジューリングする方法であって、前記データストリームは、前記レシーバ（ＵＥ２）の復元バッファ（Ｂ）を介してプレイアウトするためのデータパケットを含み、該方法は、前記ノード（ＢＳ）において前記データパケットを少なくとも１つのスケジューリングキュー（ＳＱ）に配置するステップと、データパケットを前記スケジューリングキュー（ＳＱ）から、前記スケジューリングキュー（ＳＱ）における該データパケットの滞在時間（ｔ）が所与のドロップの期限（ｄ）を超えた場合にドロップするステップとを含み、該方法は、
   前記ノード（ＢＳ）において前記データのための前記復元バッファ（Ｂ）をエミュレートして、サービス品質及び体感品質のうちの一方又は双方の関数として、前記データパケットの個々のプレイアウト値（ｐｏ）を求めるステップであって、該個々のプレイアウト値（ｐｏ）は、前記データパケットに対する前記復元バッファ（Ｂ）による予想プレイアウト時点（ｐ）を示す、ステップと、
   前記ドロップの期限（ｄ）を、前記個々のプレイアウト値（ｐｏ）の関数として、前記データパケットに割り当てるステップ（２００）と
   を含む、方法。
2. 請求項１記載の方法において、前記データパケットは、該データパケットの生成時刻を示すタイムスタンプ（ｇ）を含む、方法。
3. 請求項１又は請求項２記載の方法において、該方法は、推定伝送遅延（δ）の関数として、前記個々のプレイアウト値（ｐｏ）を求めるステップを含み、該推定伝送遅延（δ）は、前記通信ネットワークにおけるセンダ（ＵＥ１）での前記パケットの生成時刻（ｇ）と前記レシーバ（ＵＥ２）での前記パケットの到着時刻（ｑ）との間の推定伝送遅延である、方法。
4. 請求項３記載の方法において、前記推定伝送遅延（δ）は、
   前記データパケットが前記センダ（ＵＥ１）で生成される時刻（ｇ）を示す第１の値と、
   前記データパケットが前記ノード（ＢＳ）で受けられる時刻（ａ）を示す第２の値と、
   前記データパケットが前記ノード（ＢＳ）から前記レシーバ（ＵＥ２）へ伝送される予想時刻（ｔ）を示す第３の値と、
   前記データパケットの前記通信ノード（ＢＳ）から前記レシーバ（ＵＥ２）へ伝送するための推定遅延を示す第４の値と
   の関数として求められる、方法。
5. 請求項３又は請求項４のいずれかに記載の方法において、該方法は、前記復元バッファ（Ｂ）を、前記ノード（ＢＳ）において、適応プレイアウトバッファとしてエミュレートするステップを含む、方法。
6. 請求項１から５の何れか一項に記載の方法において、前記個々のプレイアウト値（ｐｏ）は、平均オピニオン評点すなわちＭＯＳの関数として求められる、方法。
7. 請求項６記載の方法において、前記データストリームは、ボイス・オーバー・アイピー・データストリームであり、前記平均オピニオン評点はＥモデルにより計算される、方法。
8. 請求項５から７のいずれか一項に記載の方法において、前記個々のプレイアウト値（ｐｏ）は、最適なプレイアウト遅延（ｐｏ）を以前の伝送遅延（δ）の関数として求めることにより、事後的に求められることを特徴とする方法。
9. 請求項８記載の方法において、前記データストリームは、ボイス・オーバー・アイピー・データストリームであり、前記個々のプレイアウト値（ｐｏ）は、所与のトークスパートの全てのデータパケットの予想プレイアウト時点（ｐ）を示すように、それ以前のトークスパートの最適なプレイアウト値（ｐｏ）を求めることにより求められる、方法。
10. 請求項８又は請求項９記載の方法において、前記個々のプレイアウト値（ｐｏ）は、該個々のプレイアウト値にとっての以前の値（ｐｏ）も考慮した指数平均により求められる、方法。
11. 請求項１から１０のいずれか一項に記載の方法において、前記ドロップの期限（ｄ）を、前記個々のプレイアウト値（ｐｏ）の関数として、前記データパケットに割り当てる前記ステップ（２００）は、前記データストリームの各データパケットに期限（ｄ）を割り当てるステップ（２００）であって、データパケットが、該データパケットの予想伝送時刻（ｔ）が該データパケットの予想プレイアウト時点（ｐ）を超える場合にドロップされるようにする、ステップ（２００）を含む、方法。
12. 通信ネットワークにおけるレシーバ（ＵＥ２）へのデータストリームのスケジューリングされた伝送のための通信ノード（ＢＳ）であって、前記データストリームは、前記レシーバ（ＵＥ２）の復元バッファ（Ｂ）を介してプレイアウトするためのデータパケットを含み、該通信ノード（ＢＳ）は制御モジュール（２００）を備え、該制御モジュール（２００）は、前記少なくとも１つのスケジューリングキュー（ＳＱ）に前記データパケットを配置するステップと、前記少なくとも１つのスケジューリングキュー（ＳＱ）から前記データパケットをドロップするステップと、前記復元バッファ（Ｂ）をエミュレートするステップとを、請求項１から１１のいずれか一項に記載の方法に従って実行する、通信ノード（ＢＳ）。
13. 請求項１２記載の通信ノード（ＢＳ）において、前記通信ノード（ＢＳ）は、ユニバーサル移動体通信システム・ロング・ターム・エボリューション及びハイスピード・ダウンリンク・パケット・アクセスのうちの一方又は双方の通信ノードである、通信ノード（ＢＳ）。
14. コンピュータプログラムであって、少なくとも１つのコンピュータのメモリにロード可能であり、該プログラムがコンピュータ上で実行されたときに請求項１から１１のいずれか一項に記載の方法のステップを実行するためのソフトウェアコード部分を含むコンピュータプログラム。

Images