JP2007028623A - ネットワークストリームベースの伝送速度を加速するためにｂｅｒ／ｐｅｒを調整するためのシステムおよび方法 - Google Patents

Abstract

【課題】通信ネットワークの、特に無線ネットワークでの帯域の使用を改善し、有線システムと無線システムにおけるサービスの質（ＱｏＳ）機構の強化を実現する。
【解決手段】コンピュータネットワークを介して受信側システムに送信されるデータ型のデータパケットを取得することと、前記データ型に基づいており、エラーがデータパケットの中で推測されるときに受信側システムが再送を試みる必要があるかどうかを示すリトライフラグをデータパケットに付加することと、を含む。データ型がボイス、ビデオまたはオーディオデータの内の１つであるとき、リトライフラグは、データパケットの中でエラーが推測されるときに受信側システムが再送を試みてはならないことを示す。
【選択図】 図１

Description

本発明は一般的にはデジタルネットワーク上でのデータ通信に関し、さらに詳細にはネットワークストリームベースの伝送速度を加速するためにＢＥＲ／ＰＥＲを調整するためのシステムおよび方法を提供する。

従来、通信ネットワークは、要求の性質には関係なく、先着順方針を使用して帯域幅を割り当て、あらゆる要求に対応している。帯域幅が不十分である場合には、要求は拒絶できる。

最近、データ通信技術は一般的なデータをトランスポートするだけではなく、ボイスデータ、オーディオデータおよび／またはビデオデータ等のマルチメディアデータをトランスポートするためにもますます使用されている。しかしながら、マルチメディアストリームは（ジッタ、待ち時間、誤り率等）一般的なデータとは異なる配信の制約を有する。残念なことに、従来の通信ネットワークにはこれらの要件を満たす特殊な機構はない。

さまざまなレベルのサービスの質（ＱｏＳ）を提供することは、マルチメディアデータのトランスポートを改善するために最も重要な方法の１つとして幅広く認識されている。メインのＱｏＳ要因は帯域幅、待ち時間、ジッタ、パケット損失およびサービス可用性である。ＱｏＳはビジネスの課題でもある。いくつかのビジネス上の要求はサービスの差別化とサービスの可用性を提供することを希望している。

帯域幅、待ち時間およびジッタの影響が研究されてきた。例えば、許容可能なリアルタイムのボイス通信を維持するためには、ボイスパケットのためのエンドツーエンド遅延（待ち時間）は２５０ｍｓ未満でなければならない。パケットが２５０ｍｓを超える遅延で到着すると、パケットは、それがそのリアルタイムの意味を失ったため廃棄される可能性がある。信号処理およびプロトコル改善によって待ち時間に対処するシステムもある。大きなバッファは待ち時間の問題を生じるかも知れないが、いくつかの実施例では、バッファに入れることによってジッタを改善している。

リアルタイムトラフィックが一般的なデータトラフィックによって課される特定の要件を緩和することが注記されなければならない。特に、オーディオとビデオ等の現実世界の信号はいくぶんビットエラーに寛容である。オーディオおよびビデオの品質は偶然のビットエラーによって非常に大きな影響を及ぼされない。ただし、ＬＡＮではビットエラーの許容は無関係である。すなわち、単一のビットだけにエラーがある場合でもパケットは廃棄され、廃棄されたパケットはビットエラーの許容値に関係なく再送される。

無線ネットワークでは、帯域幅は非常に重大である。遅延されたパケットはそのリアルタイムの意味を失うため、無線ネットワーク内でのリアルタイムデータの再送はきわめて不必要であり、望ましくない。

したがって、通信ネットワーク、特に無線ネットワークでの帯域の使用を改善するシステムおよび方法が大いに必要とされている。

本発明の実施形態は有線システムと無線システムにおけるサービスの質（ＱｏＳ）機構の強化を実現する。一実施形態では、本発明は、順方向誤り訂正（ＦＥＣ）コード等の異なるエラー訂正アルゴリズムを適用することによってメディアストリームの処理を改善するための方法を提供する。一実施形態では、本発明はＭＡＣ層または物理層において適用されるネットワーク伝送プロトコルを制御するために新しい測定基準、つまりデータ型を提供する。許容可能な誤り率を定めるために（例えば、それはＢＥＲ／ＰＥＲに関するように）データ型を調べ、エラー訂正アルゴリズムを相応して選択することにより、ネットワークシステムは、ビデオ、ボイスおよび／またはオーディオ等のマルチメディアデータにより速いネットワーク速度を提供できる。本発明の特定の実施形態はジッタを削減し、待ち時間を短縮し、マルチメディアストリームのために平均的なスループットを強化し、従来の優先順位レベルとの互換性を維持することができる。

ネットワークは２種類の異なるストリーム、つまり一般データ（ＦＴＰ、インターネット等）とマルチメディアデータ（ＩＰ電話、ビデオ会議、音楽ストリーミング等）を取り扱う。前述したように、これらのデータ型に対する要件は異なる。例えば、一般データが（ＭＡＣ層または上層で）ゼロパケット誤り率（ＰＥＲ）とビット誤り率（ＢＥＲ）を必要とするのに対し、マルチメディアストリームは（ＭＡＣ層または上層で）非ゼロＰＥＲとＢＥＲを有してよい。マルチメディアパケットを復号した後に数ビットが間違っている場合、マルチメディアパケットを捨てる必要はない。人間の観察者は通常、ビデオ、オーディオ、ボイス信号中の間違っている数ビットを検出できない。また、間違っている数ビットを「隠す」ことができるエラー隠蔽技法がある。さらに、ビデオ、オーディオおよびボイスはリアルタイムプロセスであるので、遅れているが正しいデータパケットは、1個または複数の間違っているビットを含むオリジナルのパケットより価値が低い。

一実施形態では、方法は、コンピュータネットワークを介して受信側システムに送信されるデータ型のデータパケットを取得することと、前記データ型に基づいており、エラーがデータパケットの中で推測されるときに受信側システムが再送を試みる必要があるかどうかを示すリトライフラグをデータパケットに付加することと、コンピュータネットワークを介して受信側システムに、リトライフラグが添付されたデータパケットを送信することとを備える。データ型がボイス、ビデオまたはオーディオデータの内の１つであるとき、リトライフラグは、データパケットの中でエラーが推測されるときに受信側システムが再送を試みてはならないことを示す可能性がある。前記方法はエラー検出情報をデータパケットに付加することも備えてよく、エラー検出情報は受信側システムによるデータパケットに対する妥当性検査のために使用され、妥当性検査が失敗すると、受信側システムはデータパケットの中のエラーを推定できる。前記エラー検出方法はCRC情報を含んでもよい。前記方法は、エラー訂正アルゴリズムＩＤをデータパケットに付加することも備えてよい。前記方法は、前記データ型に基づいてデータパケットに付加されるエラー訂正アルゴリズムＩＤを選択することも備えてよい。前記方法はデータパケットと関連するエラー訂正情報を生成するためにエラー訂正アルゴリズムを使用し、前記エラー訂正情報は受信システムがデータパケットの中で推定されるエラーを訂正できることを目的とすることと、データパケットと関連付けられたエラー訂正情報を受信側システムに送信すること、も備えてよい。

別の実施形態では、システムは、コンピュータネットワークを介して受信側システムに送信されるデータ型のデータパケットを取得するための上位層通信モジュールと、前記データ型に基づいており、データパケットでエラーが推定されるときに、受信側システムが再送を試行する必要があるかどうかを示すリトライフラグを前記データパケットに追加するためのヘッダエンコーダと、コンピュータネットワークを介してリトライフラグが追加されたデータパケットを受信側システムに送信するための物理層とを備える。データタイプがボイス、ビデオまたはオーディオデータの内の1つであるときには、リトライフラグは、エラーがデータパケットで推定されるときに受信側システムは再送を試行してはならないことを示す場合がある。ヘッダエンコーダはデータパケットにエラー検出情報を付加してよく、前記エラー検出情報は受信側システムにより前記データパケットに対する妥当性検査のために使用され、妥当性検査が失敗すると受信システムはデータパケット内でエラーを推測できる。エラー検出情報はＣＲＣ情報を含んでいてもよい。ヘッダエンコーダはデータパケットにエラー訂正アルゴリズムＩＤを付加してもよい。ヘッダエンコーダは、データ型に基づいてデータパケットにどのエラー訂正アルゴリズムＩＤを付加するのかを定めるＱｏＳモデルにアクセスしてもよい。システムは、データパケットと関連付けられたエラー訂正情報を生成するためにエラー訂正アルゴリズムを使用するためのエラー訂正モジュールをさらに備えていてもよく、前記エラー訂正情報は受信システムがデータパケットで推測されるエラーを訂正できるようにすることを目的とし、物理層は受信側システムにデータパケットと関連付けられた前記エラー訂正情報を送信してもよい。

別の実施形態では、方法は、エラー検出情報およびリトライフラグを有するデータパケットを受信することと、前記データパケットと対照して前記エラー検出情報の妥当性を確認することと、エラー検出情報の妥当性が確認できないときにデータパケットがエラーを含むと推測することと、前記データパケットがエラーを含むと推測するときに、前記リトライフラグが、再送が行われなければならないことを示す場合に再送を開始し、前記リトライフラグが、再送が行われてはならないことを示す場合に再送を開始しないこととを備える。前記方法は、前記データパケットがエラーを含み、前記リトライフラグが、再送が発生してはならないことを示すと推測するときに、前記エラーの訂正を試行するためにエラー訂正アルゴリズムを開始することをさらに備えてよい。前記データパケットは、前記エラー訂正アルゴリズムを識別するエラー訂正アルゴリズムＩＤを有してよい。

別の実施形態では、システムは、エラー検出情報およびリトライフラグを有するデータパケットを受信するための物理層と、前記データパケットと対照して前記エラー検出情報の妥当性を確認し、前記エラー検出情報の妥当性が確認できないときに前記データパケットがエラーを含んでいると推測するためのエラーチェックモジュールと、前記データパケットがエラーを含み、前記リトライフラグが、再送が行われなければならないことを示すと推測するときには再送を開始し、前記データパケットがエラーを含み、前記リトライフラグが、再送が行われてはならないことを示すと推測するときには再送を開始しないための再送マネージャとを備えていてもよい。前記システムは、前記データパケットがエラーを含み、前記リトライフラグが、再送が行われてはならないことを示すと推測するときに、エラーの訂正を試行するためにエラー訂正アルゴリズムを開始するためのエラー訂正モジュールをさらに備える。前記データパケットは、前記エラー訂正アルゴリズムを識別するエラー訂正アルゴリズムＩＤを有していてもよい。

有線システムと無線システムにおけるサービスの質（ＱｏＳ）機構の強化を実現する。

順方向誤り訂正（ＦＥＣ）コード等の異なるエラー訂正アルゴリズムを適用することによってメディアストリームの処理を改善する。

ネットワークシステムにおいて、ビデオ、ボイスおよび／またはオーディオ等のマルチメディアデータにおけるネットワーク速度をより高速化できる。

ジッタを削減し、待ち時間を短縮できる。

マルチメディアストリームのために平均的なスループットを強化し、従来の優先順位レベルとの互換性を維持することができる。

以下の説明は、当業者が本発明を製造および使用できるようにするために提供され、特定の応用例およびその要件のコンテクストで提供される。実施形態に対する多様な変型は当業者にとって可能であり、ここに定義されている一般的な原則は、本発明の精神および範囲から逸脱することなくこれらのおよび他の実施形態および応用例に適用することができる。したがって、本発明は示されている実施形態に制限されることを目的とするのではなく、ここに開示されている原則、特徴および教示と一貫する最大の範囲を与えられなければならない。

本発明の実施形態は、有線システムと無線システムにおけるサービスの質（ＱｏＳ）機構の質の向上を提供する。一実施形態では、本発明は、順方向誤り訂正（ＦＥＣ）コード等、異なるエラー訂正アルゴリズムを適用することによってメディアストリームの処理を改善する方法を提供する。一実施形態では、本発明はＭＡＣ層内または物理層内で適用されるネットワーク伝送プロトコルを制御するために、データ型等の新しいメトリックないし測定基準を提供する。許容できる誤り率を設定するために（例えば、それはＢＥＲ／ＰＥＲに関係するので）データ型を調査し、それに従ってエラー訂正アルゴリズムを選択することによって、ネットワークシステムはビデオ、ボイスおよび／またはオーディオ等のマルチメディアデータにさらに高速のネットワーク速度を提供できてよい。本発明の特定の実施形態は、ジッタを削減し、待ち時間を短縮し、マルチメディアストリームのための平均的なスループットを改善し、従来の優先順位レベルとの互換性を維持する。

ネットワークは２種類の異なるストリーム、つまり一般データ（ＦＴＰ、インターネット等）とマルチメディアデータ（ＩＰ電話、ビデオ会議、音楽ストリーミング等）を取り扱う。前述したように、これらのデータ型に対する要件は異なる。例えば、一般データが（ＭＡＣ層または上層で）ゼロパケット誤り率（ＰＥＲ）とビット誤り率（ＢＥＲ）を必要とするのに対し、マルチメディアストリームは（ＭＡＣ層または上層で）非ゼロＰＥＲとＢＥＲを有してもよい。マルチメディアパケットを復号した後に数ビットが間違っている場合、マルチメディアパケットを捨てる必要はない。人間の観察者は通常、ビデオ、オーディオ、またはボイス信号の中の間違っている数ビットを検出できない。また、間違っている数ビットを「隠す」ことができるエラー隠蔽技法がある。さらに、ビデオ、オーディオおよびボイスはリアルタイムプロセスであるので、遅れているが正しいデータパケットは、1個または複数の間違っているビットを含むオリジナルのパケットより価値が低い。

図１は、本発明の実施形態に従ったネットワークアーキテクチャ１００のブロック図である。ネットワークアーキテクチャ１００は受信側（ＲＸ）コンピュータシステム１１５にコンピュータネットワーク１１０を介して結合される送信側（ＴＸ）コンピュータシステム１０５を含む。送信側コンピュータシステム１０５は、上層１２０を含み、この上層１２０はＭＡＣ層１２５に結合され、このＭＡＣ層１２５は、コンピュータネットワーク１１０に結合される物理層１３０に結合される。受信側コンピュータシステム１１５は、上層１５５を含み、この上層１５５はＭＡＣ層１６０に結合され、このＭＡＣ層１６０は、コンピュータネットワーク１０に結合される物理層１６５に結合される。コンピュータ１０５とコンピュータ１１５のそれぞれは同一であり、双方向通信可能であってよい一方、便宜上、コンピュータ１０５は送信機として説明され、コンピュータ１１５は受信機として説明されている。この例のケースでは、データは送信側コンピュータシステム１０５の上層１２０からコンピュータネットワーク１１０を介して下層まで下方に、および受信側コンピュータシステム１１５の下層を通って上方に、それが上層１５５に達するまで流れる。

送信側コンピュータシステム１０５の上層はデータ伝送側（ＴＸ）アプリケーション（例えば、ビデオストリーミングエンジン、インスタントメッセンジャアプリケーション、オーディオストリーミングアプリケーション、インターネット電話、ウェブサーバ等）１３５等をアプリケーション層に含む。送信側アプリケーション１３５はＭＡＣ層１２５にデータを送信する。データは、ウェブサイトのウェブページ等の一般データ、あるいはボイス、ビデオおよび／またはオーディオ等のマルチメディアデータであってよい。上層１２０は伝送の優先順位付けのためにデータに優先順位情報を付加してもよい。

送信側コンピュータシステム１０５のＭＡＣ層１２５は、パケットエンコーダ１４０とエラー訂正（ＥＣ）モジュール１４５のセットを含む。パケットエンコーダ１４０は上層１２０の送信側アプリケーション１３５からデータを受信し、データ型に基づいてパケット生成プロトコルに適用するためにある特定のＥＣモジュール１４５を選択する。例えば、パケットエンコーダ１４０が、前記データ型が一般データであると判断する場合、パケットエンコーダ１４０はさらに高いＢＥＲ／ＰＥＲ（例えばパリティチェックだけ）およびさらに長い待ち時間（さらに低い優先順位）を有するＥＣアルゴリズムを達成するＥＣモジュール１４５を選択してよい。パケットエンコーダ１４０が、データ型がマルチメディアであると判断すると、パケットエンコーダ１４０はさらに低いＢＥＲ／ＰＥＲ（例えば、ＦＥＣ、チェックビット、ビタビアルゴリズム、冗長性チェック等）およびさらに低い待ち時間（さらに高い優先順位）を有するＥＣアルゴリズムを達成するＥＣモジュール１４５を選択してよい。同様に、パケットエンコーダ１４０は、さまざまなタイプの一般データとさまざまなタイプのマルチメディアデータを区別できる。異なるデータ型はさまざまなエラーチェックアルゴリズムを使用してよい。１つのデータ型は複数の異なるエラーチェックアルゴリズムを使用してよい。すべてのデータ型は前記同じタイプのエラーチェックアルゴリズムを使用してよい。多くの実施形態が考えられる。

送信側コンピュータシステム１０５のパケットエンコーダ１４０は、パケットエラーまたはビットエラーの場合に再送信が行われなければならないかどうかを示すために、および使用されるＥＣアルゴリズムを識別するために、追加ビットを各パケットのヘッダに付加してよい。パケットエンコーダ１４０はＣＲＣ情報、パリティビット等のエラー検出情報も付加してよい。図２は、再送が行われなければならないかどうかを示すためにリトライフラグ２０５（例えば１ビット）、使用されているＥＣコードを特定するためのＥＣコードＩＤ（例えば２ビット）２１０、他のヘッダ情報２１５、ペイロード２２０、および受信側コンピュータシステム１１５が、データ内にエラーが存在するかどうかを判断するのを補助するエラー検出（ＥＤ）情報２２５を含むパケット２００の一例を示す。パケットエンコーダ１４０が、データが一般データであると判断する場合には、パケットエンコーダ１４０はパケットエラーまたはビットエラーの場合に再送が行われてよいかどうかを示すためにリトライフラグ２０５を設定してよい。パケットエンコーダ１４０が、データがマルチメディアデータであると判断する場合には、パケットエンコーダ１４０は、パケットエラーまたはビットエラーの場合には再送が行われてはならないことを示すためにリトライフラグ２０５を設定してもよい。

送信側コンピュータシステム１０５の物理層１３０は、データ型に関係なく、コンピュータネットワーク１１０の上に、受信側コンピュータシステム１１５にパケットを送信する通信モジュール１５０を含む。

受信側コンピュータシステム１１５の物理層１６５は、データ型に関係なくコンピュータネットワーク１１０からデータパケットを受信し、受信側コンピュータ１１５のＭＡＣ層１６０にパケットを転送する通信モジュール１８５を含む。

受信側コンピュータシステム１１５のＭＡＣ層１６０はパケットデコーダ１７５、およびＥＣモジュール１８０のセットを含む。一実施形態では、送信側コンピュータシステム１１５のＥＣモジュール１８０のセットは、受信側コンピュータシステム１０５が備えるＥＣモジュール１４５のセットを含む。パケットデコーダ１７５はビットエラーチェック（例えば、パリティ、反復、ＣＲＣ）およびパケットアセンブリを実施する。ビットエラーまたはパケットエラーが発生した場合、パケットデコーダ１７５は、パケット２００のリトライフラグ２０５が、再送が行われなければならないことを示す場合にだけ再送を要求する。リトライフラグ２０５が、再送が行われてはならないことを示す場合には、パケットデコーダ１７５は、エラー訂正（または他のエラーマスク技法）を適用するかどうかを判断するために、ＥＣコードＩＤ２１０を読み取る。ＥＣコードＩＤ２１０がＥＣアルゴリズムを特定ないし識別する場合には、パケットデコーダ１４０は、対応するＥＣモジュール１８０と協調してパケットエラーまたはビットエラーの訂正を試行するためにエラー訂正を適用する。ＭＡＣ層１６０は、受信側コンピュータシステム１１５の上層１５５に、訂正されたとおりのパケットを転送する。

受信側コンピュータシステム１１５の上層１５５は、ビデオ信号、ボイス信号またはオーディオ信号をプレイバックするため、ウェブページを表示するため、ファイルを作成するため等にデータパケット等を使用する受信側（ＲＸ）アプリケーション１７０を含む。

図３は、優先順位レベル（０から７）が一次元であり、ＰＥＲおよび／またはＢＥＲ（低、中、高）が二次元である例示的な二次元ＱｏＳモデル３００を示す。図示されているように、一般データは、優先順位レベル０等の低優先順位として設定されてよく、長い待ち時間が許容できることを意味する。オーディオデータとビデオデータは、優先順位レベル５等の中−高優先順位として設定されてよく、最小待ち時間から待ち時間なしが好ましいことを意味する。ボイスデータは、優先順位レベル６等の高優先順位に設定されてよく、待ち時間なしが好ましいことを意味する。やはり図示されているように、データは高ＢＥＲおよび／またはＰＥＲに耐えるように設定され、再送されてよい。データが高ＢＥＲおよび／またはＰＥＲに耐えるように設定される場合、弱いＥＣからＥＣなしが必要とされる場合がある。図示されているように、ビデオはいくらかの（中位の）ＢＥＲおよび／またはＰＥＲに耐えるように設定される。中位のＢＥＲおよび／またはＰＥＲを許容する場合は、再送を可能とせず、中レベルのＥＣアルゴリズム（または複数のＥＣアルゴリズム）を適用するように設定されてよい。ボイスおよびオーディオは低ＢＥＲおよび／またはＰＥＲだけに耐えるように設定される。低いＢＥＲおよび／またはＰＥＲを許容する場合は再送を可能とせず、より強力なＥＣアルゴリズム（または複数のＥＣアルゴリズム）を使用するように設定されてよい。相応して、各データ型ごとに、異なるＥＣアルゴリズムが使用されてよい。ＥＣアルゴリズムの強度は、冗長な情報を送信するための追加の帯域幅に対する必要性、およびＥＣアルゴリズムが複数のパケットがビットおよび／またはパケットエラー訂正を達成することを必要とする場合に考えられる遅延に対して平衡されることが注記されなければならない。

図４は、本発明の実施形態によるパケットエンコーダ１４０の詳細を示すブロック図である。パケットエンコーダ１４０は上層通信モジュール４０５、データ型識別モジュール４１０、ヘッダエンコーダ４１５、ＥＣモジュールマネージャ４２０、二次元ＱｏＳモデル４２５（例えば、二次元ＱｏＳモデル３００）、および物理層通信モジュール４３０を含む。

上層通信モジュール４０５は上層１２０からデータを取得する。上層通信モジュール４０５はバッファ、待ち行列等を含んでよい。データ型識別モジュール４１０はデータの中に提供されたヘッダ情報からデータ型を決定してよい。ヘッダ情報は優先順位情報、データ型情報、アプリケーション識別情報および／または類似物を含んでよい。ヘッダエンコーダ４１５はデータ型識別モジュール４０５によって決定されるデータ型、および二次元ＱｏＳモデル４２５内に定められるようなデータ型に対するＢＥＲ／ＰＥＲ設定値に基づいて、リトライフラグ２０５とＥＣコードＩＤ２１０を上層１２０からデータに付加する。ヘッダエンコーダ４１５は、ＣＲＣパリティ等のエラー検出情報等の他のヘッダ情報も追加してよい。ＥＣモジュールマネージャ４２０は、データ型に、および二次元ＱｏＳモデル４２５に定められるようにデータ型のためのＢＥＲ／ＰＥＲ設定値に基づいて、上層１２０から受信側コンピュータシステム１１５にオリジナルデータとともに送信されるＥＣデータパケットまたは追加のヘッダ情報を生成するために、ＥＣモジュール１４５と動作する。物理層通信モジュール４３０は、物理層１３０への伝送のためにデータパケットに優先順位を付けるために二次元ＱｏＳモデル４２５で定められるようなデータ型の優先順位レベル設定値を使用する。物理層通信モジュール４３０は、優先順位がつけられるように物理層１３０にデータパケットを転送する。

図５は、本発明の実施形態に従ってパケットデコーダ１７５の詳細を示すブロック図である。パケットデコーダ１７５は物理層通信モジュール５０５、エラーチェックモジュール５１０、ヘッダデコーダ５１５、再送マネージャ５２０、ＥＣモジュールマネージャ５２５、および上層通信モジュール５３０を含む。

物理層通信モジュール５０５は物理層１６５からデータパケットを受信する。エラーチェックモジュール５１０は、ビットエラーまたはパケットエラーを検出するためにＣＲＣ等のビット／パケットエラーチェックを実行する。エラーが存在する場合、ヘッダデコーダ５１５は、データパケット２００のリトライフラグ２０５が再送を許容するかどうかを判断する。許容する場合には、再送マネージャ５２０が物理層通信モジュール５０５に返す再送要求を開始する。許容しない場合には、ヘッダデコーダ５１５はパケットヘッダ内でＥＣコード２１０を識別する。ＥＣモジュールマネージャ５２５はエラー訂正を実施するためにＥＣコードＩＤ２１０に対応するＥＣモジュール１８０と動作する。上層通信モジュール５３０は、アセンブルされかつ訂正されたデータパケットを上層１５５に転送する。

図６は、コンピュータシステム６００の詳細を示すブロック図であり、その送信側コンピュータシステム１０５と受信側コンピュータシステム１１５はそれぞれ例示的インスタンスであってよい。コンピュータシステム６００は、通信チャネル６２０に結合されるインテルペンティアム（登録商標）（Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ（登録商標））またはモトローラパワーＰＣ（Ｍｏｔｏｒｏｌａ Ｐｏｗｅｒ ＰＣ：登録商標）等のプロセッサ６０５を含む。コンピュータシステム６００は、キーボードまたはマウス等の入力装置６１０、陰極線管ディスプレイ等の出力装置６１５、通信インタフェース６２５、磁気ディスク等のデータ記憶装置６３０、およびそれぞれ通信チャネル６２０に結合されるランダムアクセスメモリ（ＲＡＭ）等のメモリ６３５をさらに含む。通信インタフェース６２５は、インターネットと一般的に呼ばれている広域ネットワーク等のネットワークに結合されてよい。当業者は、データ記憶装置６３０とメモリ６３５は異なる装置として描かれているが、データ記憶装置６３０とメモリ６５は同じ装置、分散装置、仮想メモリ等の部分である場合があることを認識するであろう。

データ記憶装置６３０および／またはメモリ６３５は、マイクロソフトウィンドウズ（登録商標）ＸＰ（Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） ＸＰ）、リナックス（Ｌｉｎｕｘ）、ＩＢＭ ＯＳ／２オペレーティングシステム、ＭＡＣ ＯＳ、またはＵＮＩＸ（登録商標）オペレーティングシステム、および／または他のプログラム６４５等のオペレーティングシステム６４０を格納していてもよい。好適な実施形態は、前述されたもの以外のプラットホームおよびオペレーティングシステムで実現されてもよいと理解される。実施形態は、おそらくオブジェクト指向プログラミング方法論を使用して、ＪＡＶＡ（登録商標）、Ｃおよび／またはＣ＋＋言語、あるいは他のプログラミング言語を使用して作成されてよい。

当業者は、コンピュータシステム６００がハードウェアチャネル、インターネットまたはイントラネット等全体で情報を転送するためのネットワーク接続、追加メモリ、追加プロセッサ、ＬＡＮ、入力／出力回線等の追加情報も含んでよいことを認識するであろう。当業者は、プログラムとデータが代わりにシステムによって受信され、システムに記憶されてよいことも認識するであろう。例えば、磁気ディスクドライブ、ハードディスクドライバ、磁気光学読取装置、ＣＰＵ等のコンピュータ読み取り可能な記憶媒体（ＣＲＳＭ）読取装置６５０は、磁気ディスク、ハードディスク、磁気光学ディスク、ＲＡＭ等のコンピュータ読み取り可能な記憶媒体（ＣＲＳＭ）６５５を読み取るための通信バス６２０に結合されてよい。したがって、コンピュータシステム６００はＣＲＳＭ読取装置６５０を介してプログラムおよび／またはデータを受信してよい。さらに、ここでは用語「メモリ」が、恒久的であるのか一時的であるのかに関係なく、すべてのデータ記憶装置メディアを意味することを目的としていることが理解される。

図７は、本発明の実施形態に従ってデータパケットを符号化し、送信する方法７００を示すフローチャートである。方法７００は、伝送のためにデータを生成する伝送アプリケーション１３５とステップ７０５で始まる。ステップ７１０では、上層１２０がデータ型情報をデータに付加する。データ型、および二次元ＱｏＳモデル４２５に基づいて、パケットエンコーダ１４０のヘッダエンコーダ４１５がステップ７１５で、ＥＣコードＩＤ２１０等のエラー訂正コード識別を付加し、ステップ７２０でデータパケット２００にリトライフラグ２０５等のリトライフラグ情報を付加する。物理層通信モジュール４３０は、物理層１３０に送信するために、ステップ７２５で、ＥＣアルゴリズムによって生成されるパケットを含むデータパケットに優先順位を付ける。優先順位は８０２．１１ｅのＥＤＣＡアルゴリズムを含んでよい。ステップ７３０での物理層１３０の通信モジュール１５０は、優先順位が付けられたとしてデータパケットを送信する。方法７００はそれから終了する。

図８は、本発明の実施形態に従ってデータパケットを受信し、復号する方法８００を示すフローチャートである。方法８００は、ステップ８０５で開始し、このステップ８０５では、物理層１６５の通信モジュール１８５はデータパケットを受信し、それらをＭＡＣ層１６０の物理層通信モジュール５０５に転送する。ＭＡＣ層１６０のエラーチェックモジュール５１０は、ステップ８１０において、エラーチェックを実施する。ステップ８１５では、エラーチェックモジュール５１０はビットエラーまたはパケットエラーがあったかどうかを判断する。なかった場合には、上層通信モジュール５３０は、ステップ８２０で、１つまたは複数のデータパケットを上層１５５に転送する。エラーが検出された場合、ヘッダデコーダ５１５はステップ８２５でリトライフラグ２０５を読み取り、ステップ８３０でリトライフラグ２０５が再送を許容するかどうかを判断する。許容する場合には、再送マネージャ５２０はステップ８３５で１つまたは複数のエラーのある１つまたは複数のデータパケットの再送を要求する。許容しない場合には、ヘッダデコーダ５１５は、ステップ８４０でエラー訂正モジュールＩＤ、例えばＥＣコードＩＤ２１０を読み取る。ＥＣモジュールマネージャ５２５は、ステップ８４５で、注記された１つまたは複数のエラーを訂正するために、例えばＥＣモジュール１８０の１つまたは複数と協調してエラー訂正を実施する。上層通信モジュール５３０はステップ８５０で、訂正されたパケットを上層１５５に転送する。方法８００はそれから終了する。

前述された実施形態は物理層１３０／１６５またはＭＡＣ層１２５／１６０の中でのものとして説明されてきたが、本発明の原則は上層１２０／１５５に適用されてもよい。例えば、パケットエンコーダ１４０、エラー訂正モジュール１４５／１８０、およびパケットデコーダ１７５は上層１２０／１５５で実現されてもよい。

本発明の好適実施形態の前記説明は例示としてのみであり、前述された実施形態および方法の他の変形と変更は前記教示を鑑みて可能である。ネットワークサイトは別個の、異なったサイトとして説明されているが、当業者は、これらのサイトは一体化されたサイトの一部であってよい、それぞれ複数のサイトの部分を含んでよい、あるいは単独または複数のサイトの組み合わせを含んでよいことを認識するであろう。ここに述べられた多様な実施形態はハードウェア、ソフトウェア、またはその任意の所望される組み合わせを活用して実現されてもよい。そのためには、ここに述べられている多様な機能性を実現できる任意のタイプの論理回路が活用されてよい。構成要素は、プログラミングされた汎用デジタルコンピュータを使用して、特定用途向け集積回路を使用して、または相互接続される従来の構成要素および回路を使用して実現されてよい。接続は有線、無線、モデム等であってよい。ここで説明されている実施形態は排他的または制限的であることを意図していない。本発明は以下の特許請求の範囲によってのみ制限される。

本発明の実施形態によるネットワークアーキテクチャのブロック図である。 本発明の実施形態によるパケットの詳細を示すブロック図である。 本発明の実施形態における二次元のサービスモデルを示す表である。 本発明の実施形態によるパケットエンコーダの詳細を示すブロック図である。 本発明の実施形態によるパケットデコーダの詳細を示すブロック図である。 コンピュータシステムの詳細を示すブロック図である。 本発明の実施形態に従ってデータパケットを符号化および送信する方法を示すフローチャートである。 本発明の実施形態に従ってデータパケットを受信および復号する方法を示すフローチャートである。

符号の説明

１００： ネットワークアーキテクチャ
１０５： 送信側コンピュータシステム
１１０： コンピュータネットワーク
１１５： 受信側コンピュータシステム
１２０： 上層
１２５： ＭＡＣ層
１３０： 物理層
１３５： 送信側アプリケーション
１４０： パケットエンコーダ
１４５： ＥＣモジュール
１５０： 通信モジュール
１５５： 上層
１６０： ＭＡＣ層
１６５： 物理層
１７０： 受信側アプリケーション
１７５： パケットデコーダ
１８０： ＥＣモジュール
１８５： 通信モジュール

Claims (20)

1. コンピュータネットワークを介して受信側システムに送信されるデータ型のデータパケットを取得するステップと、
   前記データ型に基づいて、前記受信側システムが前記データパケットの中でエラーが推測されるときに再送を試みなければならないかどうかを示すリトライフラグを前記データパケットに付加するステップと、
   前記リトライフラグが追加された前記データパケットを、前記コンピュータネットワークを介して前記受信側システムに送信するステップと
   を備えることを特徴とする方法。
2. 請求項１において、
   前記データ型がボイスデータ、ビデオデータまたはオーディオデータの内の１つであり、前記リトライフラグは、エラーが前記データパケット内で推測されるときには前記受信側システムが再送を試みてはならないことを示すことを特徴とする方法。
3. 請求項１において、
   前記データパケットにエラー検出情報を付加することをさらに備え、前記エラー検出情報は前記受信側システムによって前記データパケットに対する妥当性検査に使用され、妥当性検査が失敗すると、前記受信側システムが前記データパケット内でエラーを推測できるようになることを特徴とする方法。
4. 請求項３において、
   前記エラー検出情報がＣＲＣ情報を含むことを特徴とする方法。
5. 請求項１において、
   エラー訂正アルゴリズムＩＤを前記データパケットに付加することをさらに備えることを特徴とする方法。
6. 請求項５において、
   前記データ型に基づいて前記データパケットに付加される前記エラー訂正アルゴリズムＩＤを選択することをさらに備えることを特徴とする方法。
7. 請求項１において、
   前記データパケットと関連付けられたエラー訂正情報を生成するためにエラー訂正アルゴリズムを使用し、前記エラー訂正情報が、前記受信システムが前記データパケット内で推測されるエラーを訂正できるようにすることを目的とするステップと、
   前記データパケットと関連付けられた前記エラー訂正情報を前記受信側システムに送信するステップと
   をさらに備えることを特徴とする方法。
8. 通信ネットワークを介して受信側システムに送信されるデータ型のデータパケットを取得するための上位層通信モジュールと、
   前記データ型に基づいて、エラーが前記データパケット内で推測されるときに前記受信側システムが再送を試みなければならないのかどうかを示すリトライフラグを前記データパケットに付加するためのヘッダエンコーダと、
   前記リトライフラグが付加された前記データパケットを、前記コンピュータネットワークを介して前記受信側システムに送信するための物理層と
   を備えることを特徴とするシステム。
9. 請求項８において、
   前記データ型がボイスデータ、ビデオデータまたはオーディオデータの内の１つであり、前記リトライフラグは、エラーが前記データパケット内で推測されるときには前記受信側システムが再送を試みてはならないことを示すことを特徴とするシステム。
10. 請求項８において、
    前記ヘッダエンコーダがエラー検出情報を前記データパケットに付加し、前記エラー検出情報は前記受信側システムによって前記データパケットを対照とした妥当性検査に使用され、妥当性検査が失敗すると、前記受信システムが前記データパケット内のエラーを推測できるようになることを特徴とするシステム。
11. 請求項１０において、
    前記エラー検出情報がＣＲＣ情報を含むことを特徴とするシステム。
12. 請求項８において、
    前記ヘッダエンコーダが前記データパケットにエラー訂正アルゴリズムＩＤを付加することを特徴とするシステム。
13. 請求項１２において、
    前記ヘッダエンコーダが、前記データ型に基づいてどのエラー訂正アルゴリズムＩＤを前記データパケットに付加するのかを定義するＱｏＳモデルにアクセスすることを特徴とするシステム。
14. 請求項８において、
    前記データパケットと関連付けられたエラー訂正情報を生成するためにエラー訂正アルゴリズムを使用するためのエラー訂正モジュールをさらに備え、
    前記エラー訂正情報は、前記受信側システムが前記データパケット内で推測されるエラーを訂正できるようにすることを目的とし、
    前記物理層が、前記データパケットと関連付けられる前記エラー訂正情報を前記受信側システムに送信する
    ことを特徴とするシステム。
15. エラー検出情報とリトライフラグを有するデータパケットを受信するステップと、
    前記データパケットに対照して前記エラー検出情報の妥当性を確認するステップと、
    前記エラー検出情報の妥当性が確認できないときに、前記データパケットがエラーを含むと推測するステップと、
    前記データパケットがエラーを含むと推測するときに、前記リトライフラグが、再送が行われなければならないことを示す場合には再送を開始し、前記リトライフラグが、再送が行われてはならないことを示す場合には再送を開始しないステップと
    を備えることを特徴とする方法。
16. 請求項１５において、
    前記データパケットがエラーを含み、前記リトライフラグが、再送が行われてはならないことを示すと推測するときに、前記エラーの訂正を試みるためにエラー訂正アルゴリズムを開始するステップ
    をさらに備えることを特徴とする方法。
17. 請求項１６において、
    前記データパケットが、前記エラー訂正アルゴリズムを識別するエラー訂正アルゴリズムＩＤを有することを特徴とする方法。
18. エラー検出情報とリトライフラグを有するデータパケットを受信するための物理層と、
    前記データパケットに対照して前記エラー検出情報の妥当性を確認し、前記エラー検出情報の妥当性が確認できないときに前記データパケットがエラーを含むと推測するためのエラーチェックモジュールと、
    前記データパケットがエラーを含み、前記リトライフラグが、再送が行われなければならないことを示すと推測するときには再送を開始し、前記データパケットがエラーを含み、前記リトライフラグが、前記再送が行われてはならないことを示すと推測するときには再送を開始しないための再送マネージャと
    を備えることを特徴とするシステム。
19. 請求項１８において、
    前記データパケットがエラーを含み、前記リトライフラグが再送が行われてはならないことを示すと推測するときに、前記エラーの訂正を試行するためにエラー訂正アルゴリズムを開始するためのエラー訂正モジュールをさらに備えることを特徴とするシステム。
20. 請求項１８において、
    前記データパケットが、前記エラー訂正アルゴリズムを識別するエラー訂正アルゴリズムＩＤを有することを特徴とするシステム。

Images